Re: 2.6.16-rc4: known regressions

[David Zeuthen <david@fubar.dk>]

(agreeing with you on lots of counts so cutting to the chase)

On Wed, 2006-02-22 at 09:08 -0800, Linus Torvalds wrote:
> THIS IS WHY WE MUST MAKE THE KERNEL INTERFACES STABLE!

You really need to sit down and define what you mean by stable then. For
example the syscall interface is somewhat well defined.

This is how the world looks like today from a consumer of sysfs with
little or no kernel programming experience. Just a few examples:

 1. There is little or no documentation sans kernel sources for
    the meaning nor range of the values of sysfs files. You have to
    lookup the kernel source... Maybe it would be useful to have
    some kind of auto-documentation feature that _forces_ kernel
    developers to provide docs along with the sysfs files..
    Then I would have

     /sys/block/hda/removable

    and 

     /sys/block/hda/docs_removable

    Of course make this an optional feature. Noteworthy this is how
    gconf in GNOME works.. sure, now I get flamed for bloat and, sure,
    this may be a stupid idea... Mostly I'm just trying to outline
    the problem here...

 2. Some of the interesting information we want isn't actually
    available even though the kernel has it already (can we please
    get an event when the kernel has finished scanning for partitions
    for example?). We're pretty fine getting some high-level information
    ourselves, like probing for file system for example.. but some
    things we can't really get at.. 

 3. User space needs to reorder hotplug events; that's fine but we get
    to play a lot of tricks because there are races everywhere (look at
    some of the udev rules for working around this).. I'm not sure how
    this is fixable...

 4. Back in 2.6.9 or 2.6.10 someone yanked the SCSI targets into the
    sysfs chain and that did break HAL. Depending on who you ask this
    is acceptable, other people says it's ABI breakage. Again, need to
    define what's stable means; I don't think it's good enough to just
    wait until it happens and then let yourself or some other high-level
    person decide whether a change is acceptable or not. We need
    predictability.

All these things.. what sysfs files to expect.. proper documentation..
what values a sysfs file can assume.. is, to me at least, all part of an
"interface"... an ABI.

The root problem, I think, here is really the lack of communication
between kernel developers and user space people. It's not like HAL is
closed source nor a lot of code. 

I believe that the problems we have in HAL are very fixable but the
thing is that with the "documentation" and "stability guarantees" that
the kernel today gives us... you pretty much have to be a kernel
developer to figure when or if some sysfs file can assume a new value..
or that there's a better sysfs file to check that this or that one...
Sorry, but I'd rather spend my time making the desktop bits use HAL to
implement a nice user-visible feature... than spending time figuring out
the exact semantics of some arcane file in sysfs. 

At this point I would welcome any kernel developer to help review the
HAL code and send patches for stupid assumptions made in HAL. I would
really appreciate it. I'm not kidding. Thanks.

    David


-
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/