On Monday 05 August 2002 07:19 pm, Greg KH wrote:
> > By the way, why doesn't imposing consistent predefined major/minor
> > numbers (0x0301 instead of "hda1") count as "policy"? I'm honestly
> > curious...
>
> It does. I want to get rid of it too :) But that's still a ways away...
The user needs some kind of API. Some way for a program to say "Could I
please talk to the slave drive on the second IDE controller". What I'm
wondering is where's the line between "policy" and "API"? You can't have a
standard API without SOME level of "policy".
Major/minor device numbers suck because the namespace is too small (for
historical reasons), it's randomly organized (again for historical reasons),
it's almost exhausted (due to the first two), making it bigger will just help
the clutter breed, and it's almost impossible to recycle old numbers as long
as three people out there are still using the floppy tape controller or
whatever. Plus humans really do think in words (or at least text strings),
hence the phone book and DNS to access numbers via strings. (And the /dev
directory.)
There already ARE standardized text based APIs, and internationalization
people object to them for political correctness reasons and that's just
stupid. If somebody is REALLY stupid enough to translate the standard C
library function names into chinese unicode, and then try to actually link a
program against it, they deserve what they get. Same with the standard unix
commands: awk, grep, and sed aren't english. (They're posix. :)
Internationalizing the data going through an API is one thing, trying to
internationalize the API itself is just silly. Might as well encourage
non-english posts on linux-kernel...
I've noticed a bias against actually using strings to interface the kernel
with userspace (the module autoloader being one relatively obvious example),
but it's still done in a bunch of places anyway ("/sbin/init", "linuxrc",
"hotplug", "modprobe", the text command line for kernel booting with "init=",
"root=", "initrd="...). The kernel talks to other parts of the kernel by
exporting text symbols, userspace talks to userspace with strings, why is
kernel to userspace fundamentally different? The problem with the horror
that is /proc is that it's not ORGANIZED, not that it's text. People put so
much stuff into /proc because they WANT a text API, and for a long time that
was their only real outlet.
The problems with devfs are, well, numerous, but the fundamental idea of
automatically mounting a /dev directory with the available devices into it
rather than a MAKEDEV script to create 8 zillion nodes for devices you might
conceivably want to borrow from a museum someday... Implementation issues
aside, what was wrong with the idea itself? The rebellion against using the
existing names there makes devfs a lot less interesting to me, I know that
much. It doesn't provide the same API the /dev directory does, and half the
software I use won't compile against it without a chainsaw and a bullwhip, or
the daemon kludge. Code quality aside, the new devfs api never struck me as
an improvement over the old one. (I STILL don't know why a change of
implementation mandated a change of API.)
I'm under the vague impression that devicefs may somehow become the new
driver API at some point after Buck Rogers returns from his frozen orbit.
The whole POINT of devicefs seems to be to expose new data through a fresh
API that's designed to grow without getting disorganized. This implies (to
me) a move towards a device API defined in the context of a text namespace.
If there's some move underway to avoid doing so (because any standard API is
"policy"), what exactly is the better alternative?
Rob
-
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/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:30 EST