Re: Golden rule: don't break userland (was Re: RFC: Starting a stable kernel series off the 2.6 kernel)

Michael Frank
2005-12-04T16:22:56Z

On Saturday 03 December 2005 19:43, Jeff Garzik wrote:
> Adrian Bunk wrote:
> > IOW, we should e.g. ensure that today's udev will still
> > work flawlessly with kernel 2.6.30 (sic)?
> >
> > This could work, but it should be officially announced
> > that e.g. a userspace running kernel 2.6.15 must work
> > flawlessly with _any_ future 2.6 kernel.
>
> Fix the real problem: publicly shame kernel hackers that
> change userland ABI/API without LOTS of notice, and
> hopefully an old-userland compatibility solution
> implemented.
>
> We change kernel APIs all the time. Having made that
> policy decision, we have the freedom to rapidly improve
> the kernel, and avoid being stuck with poor designs of
> the past.
>
> Userland isn't the same. IMO sysfs hackers have
> forgotten this. Anytime you change or remove sysfs
> attributes these days, you have the potential to break
> userland, which breaks one of the grand axioms of Linux.
> Everybody knows "the rules" when it comes to removing
> system calls, but forgets/ignores them when it comes to
> ioctls, sysfs attributes, and the like.

WRT sysfs, sysfs is dynamic by design to accommodate
individual HW configuration. Thus isn't this really a fault
of user-space implementation?

>
> Thus, I've often felt that heavy sysfs (and procfs) use
> made it too easy to break userland. Maybe we should
> change the sysfs API to include some sort of interface
> versioning, or otherwise make it more obvious to the
> programmer that they could be breaking userland compat.

You might need versions for every entry. I'd go for more
documentation on proper use.

>
> Offhand, once implemented and out in the field, I would
> say a userland interface should live at least 1-2 years
> after the "we are removing this interface" warning is
> given.
>
> Yes, 1-2 years. Maybe even that is too small. We still
> have old_mmap syscall around :)
>
> Jeff
>