On Mon, May 22, 2000 at 04:13:15AM -0400, Alexander Viro wrote:
>
> 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.
Ok, that's an interesting idea - a fs for every driver. But pray tell, which
_are_ you arguing for - staying with major/minor naming, or a fs for every
driver? Maybe I missed it, but this is the first time I've seen that idea...
> > 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.
Procfs != devfs. Get that through your head first. Let's see what /proc is for:
I see a bunch of dirs for processes, some text files telling me about my system,
and a tree corrisponding to sysctl()s. Those ascii text files are decent for the
admin, but they've never been designed for programs to use them - and anyways,
it's a disorganized mess. If we started putting in ascii text files telling
programs what's hooked up, that _would_ be a shitty mess.
Devfs is perfect for this sort of thing. If I or a program need to check if
there's a hard drive on the second interface of the first ide controller,
all it has to do is check if the block device is there. Devfs is
_designed_ for this sort of thing, proc isn't. That simple.
In the case of devfs, putting everything in one tree makes _perfect
sense_. Standardize the location so if a program (or admin) needs
something, it knows where to look. As for your idea of a bunch of little
fs's... Al, you're on crack. Plain and simple. If you honestly think
chopping a devfs up into little pieces will make things any better,
you need to get your head checked.
-
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