In <Pine.GSO.4.10.10005220353050.15123-100000@weyl.math.psu.edu> Alexander Viro (viro@math.psu.edu) 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.
It sounds pretty good but I've not seen prototype yet :-( When something to
play with will be ready ? Something pretty minimal - just enough to boot
system in single mode from IDE drive (not SCSI - for SCSI you need to add
support for few tens of SCSI drivers but there are just one IDE diriver in
Linux) and see how it works in such minimal configuration ?
>> 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.
You need some iteraction back. For example when I'm trying to use my cd
(/dev/ide/host0/bus0/target1/lun0/cd) ide-cd is loaded automagically...
Of course it's done by "automount daemond" (devfsd) but to do so kernel
should ask automount daemon to do so ! We have working (but not very pretty)
devfs (with devfsd) but we can not compare this solution with driver==fs
solution -- there are none. How heavyweight this driver=fs solution will be
when all stuff needed to load things on demand, to do lookups (you NEED
kernel support to do this - not all information is available in userspace and
/dev/kmem parsion is not an option) and so on will be added ? We can not say
for sure without prototype :-(
> 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.
What done is done. Devfs is here. So any other solution should be here in
next 1-2 years (before end of 2.5 that is): otherwise devfs will be adopted
in absence of alternative. In all it's uglyness...
P.S. And "don't put into the kernel things that can be done outside" not
always good BTW. If you need 10000 times bigger and more complex userspace
daemon (in comparision to devfsd) or if all programs should be modified to
work with "new, improved scheme" just to make kernel 10K smaller then no,
thnx.
-
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