On Mon, May 22, 2000 at 02:09:43AM -0400, Alexander Viro wrote:
>
> On 22 May 2000 jmcmullan@linuxcare.com wrote:
>
> > As for network devices, we have Berkely Unix to thank. Although
> > the premise of a separate namespace for network devices was arguably
> > an excellent move at the time (don't need to worry about namespace
> > collision in /dev, no need to write a new filesystem - and at that time
> > many UNIX systems didn't have a VFS-style layer), it is flawed
> > by its diversion from the UNIX ideal - "Everything's a File(tm)"
> >
> > Network devices, the network sockets, etc. were pushed into
> > a namespace that could not be inspeced from userspace without
> > special tools such as ifconfig, route, netstat, etc. Call me
> > SysV, but I am a firm believer in presenting the network namespace
> > in the UNIX tradition.
>
> <rant>
> Tell that to fsckwits who
> a) added Missed'em'V IPC - magic API for shm instead of plain and simple
> mmap() on files on a swappable memfs.
> b) added pearls like sysfs() and zillion of other stupid warts when all
> that was needed was open() and read().
> c) took the original streams design (beautiful and lightweight) and had
> turned it into the bloated piece of shit.
> d) kept bloating the API and making it as unorthogonal as they could.
> e) kept breeding ioctls for no good reason.
> f) invented the abortion knows as SIGPOLL - with Missed'em'V signals'
> semantics in bargain.
> g) brought us byte-range locks API.
>
> Now, who made all that mess? Precisely. Missed'em'V, aka.
> "Perverts Of No Taste And What Had They Done To UNIX", rated from R to
> X.
> </rant>
>
> Sorry, I've dealt with a lot of Missed'em'Visms lately and
> compared to them all sucking interfaces introduced by BSD simply pale.
>
> > Certain things are crucial for a device driver application
> > API (ie, a filesystem) to present:
> >
> > * Topology-based lookup - What devices are on USB bus 2?
> > * Superclass-based lookup - What block devices are online?
> > * Class-based lookup - What IDE devices are online?
> > * Instance-based lookup - Where is IDE0 on the bus layout?
>
> _All_ of that stuff can be handled in userland. Remember another mantra?
> "Don't put into the kernel things that can be done outside".
So, I can find out whether hdc is online, right now, and _without kernel support_?
True, we can find this out right now - but you need the kernel to do it, and
usually it ain't pretty. Quick, tell me, how do you tell whether hdc is hooked up,
using stock 2.2.15? Let's see, we could go ioctl() /dev/hdc. Not too bad... but
what if, for example, I'm writing a program like cdparanoia that needs to find the
cdrom drive. Well, /dev/cdrom is common - but not enough. And what standard is there
for if you have multiple cdrom drives? Sure you and I know where it's going to be,
but what if my mom's learning to rip mp3s, and I'm not around? Well, cdparanoia can
scan each ide and scsi device, but that's Messy (TM), and slow. Now that's one of the
simpler cases. What if someone just installed linux, and wants to set up their modem?
Ever have to play with com ports in DOS? It's a pain in the ass then, and it only gets
worse in Linux.
And that's still a pretty simple case. What if I've got 2 usb keyboards? I would, if
Linux could handle it. Or four usb cameras? Someone has a reason for doing it, and
we aren't the ones to say he can't just because of some naming problems. I'm not
going to repeat the problems usb poses for the major/minor device # system - it's
pretty clear that they just don't work. Same goes for firewire. Are we going to
have a new fs every time something like this comes out? It'll be worse than
anything SysV ever did.
And why the hell do I have 1826 inodes in /dev right now? What's the point? I _could_
take out the ones I don't use, but what if I need to plug in someone's hard drive
because windows died and they want me to fix it without losing everything? How's a
user-space tool going to find anything out from that? If we want to be able do all
that cool stuff from user space with the ide bus that you said we could, where's it
going to find the information? We could maybe make another namespace just for it, or
we could define a bunch of ioctl()s just for it. But no, that's a SysV evil.
Guess we'll have to toss it into the steaming pile of crap that is /proc. That's
real clean, isn't it?
No, devfs isn't perfect. In some areas, it sucks. There still isn't a decent way to
save state. But you know what, that is the ONLY THING conventional major/minor
naming has over it, and it does NOTHING with it. Major/minor naming was pretty
decent for its time, but today, it's broken. Devfs even gives us a decent
way to clean up after some of the mistakes of SysV.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:21 EST