[Ksummit-2013-discuss] [ATTEND] Interface stability guarantees

[KOSAKI Motohiro]

On Mon, Jul 22, 2013 at 9:40 PM, Li Zefan <lizefan at huawei.com> wrote:
> On 2013/7/22 6:58, H. Peter Anvin wrote:
>> We all, hopefully, know that the maxim is "don't break userspace".
>> However, there are clearly some limitations to that.  For example, Linus
>> recently made the distinction between "userspace" and "kernel support",
>> when some scripts designed to set up Grub2 groped around the kernel
>> configuration file left by the build and broke.
>>
>> However, "broken kernel support" itself is not a killer, obviously; we
>> already have a whole bunch of workarounds for broken bootloaders (which
>> gets really gnarly, because different bootloaders are broken in
>> different ways.)
>>
>> "Breaking userspace" clearly also doesn't extend to userspace which does
>> things like "build a kernel module and insert it" (and yes, there are
>> applications that do that), or a number of similar extremely low level
>> manipulations.  In the extreme case, fixing a security holes is
>> "breaking userspace" in the sense that some malware would no longer run
>> -- but neither might some very bizarre real-life usecase.
>>
>> We talked a little about this last year, already, but there has been
>> some interesting corner cases that have reared their heads this past year.
>>
>
> We're going to change cgroup interfaces, which will of course break
> userspace, so we promise to keep the old interfaces for a very long
> time, and the new interfaces will be enabled via a mount option.
>
> But the truth is, the old interfaces and new ones can't both be used.
> So if an application, say systemd, starts to use new interfaces, what
> can other applications do? That's one of the reasons some heavy cgroup
> users scream at the planned cgroup changes.

Hi Li,

I'm very much interesting in this topic.

What's happen if /mnt-A is mounted w/o the flag and /mnt-B is mounted
w/ the flag?
If it works, applications already have a workaround. Don't mind.

However, your mail brings me a few more wondering. The question is, If
we need to
maintain old and new interface _very_ _long_ _time_, the
simplification is not real
simplification. We just need doubly complicated code. Moreover, if
"All your cgroups
are belong to us!" is true, no application developers can get the
benefit of the simplification.

Hmmm. I think we should discuss the migration scenario again and how
to get real simplification and easy maintenance.