(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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
