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

[Michael Frank <mhf@users.berlios.de>]

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
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/