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

[Jeff Garzik <jgarzik@pobox.com>]

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.

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.

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/