On Sun, 21 May 2000, Kent Overstreet wrote:
> 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.
Really? What's the problem with having driver==fs? Considering that all
fs-related code would be standard and driver just had to populate its tree
with objects I wouldn't call it horrible.
> 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?
What the fuck? You can move the crap from one steaming pile to another
(procfs <-> devfs) and back, but pray tell me, what are you going to win
from such exercises? Yes, if you put everything exported by all drivers
into one tree... Guess what, it will make for a huge pile. What I don't
see is how moving the pile from one mountpoint to another is going to help
you.
That's precisely the reason why we'ld better go for driver==fs and let
admin (or automount) decide what should be mounted and where it should be
mounted. It had been done before and it actually works. Across the
network, by the way. And we have almost all infrastructure for that. Right
now. In the tree. No, I don't want to turn Linux into Plan 9 clone, but I
don't see a reason to ignore the existing solution when using the ideas
behind it is well within our reach.
And yes, I'll take reading from file over the ioctl(), thank you very
much. Especially if that file always comes together with the devices.
-
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