On Mon, 22 May 2000, Kent Overstreet wrote:
> 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...
You've missed it. Major/minor is there to stay _for_ _existing_ _devices_.
Trivial requirements of staying compatible with 2.2. For anything else we
can have a small static trees exported by drivers. It _is_ trivial to
implement, trust me.
> 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.
_B-u-l-l-s-h-i-t_. First of all, what's you problem with ASCII? If you are
of "ASCII is tough" persuasion - sorry, I couldn't care less.
As for the mess - yeah, splitting the per-process stuff is a Good Thing.
The only problem being: it's not enough. And renaming the rest into devfs
will not make the mess smaller. And if you prefer ioctl() over the read()
- well, go play with VMS or OS/360. Or CP/M - there you will find a lot of
redundant binary interfaces. You will probably like NT Registry too - they
are also convinced that special-case binary interfaces are good.
> 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.
Maybe. You got to admit that I'm in a good company, though - that's
precisely the way Thompson, Pike et.al. implemented devices in the Plan 9.
Moreover, I actually _know_ what I am talking about. Have you actually
read the devfs code? No? Same question for procfs. Also no? Then go and
_do_ it - pay attention to the stinking mess in revalidate code and in the
way we treat the invalidation of tree chunks/removal of drivers. Compare
and contrast with stuff done by mount and automounter. And tell me why
do we need to replicate it in the kernel, outside of the VFS at it.
And I'm not talking about the horrors on the drivers' side - nothing of
that kind. See ramfs for the skeleton code and keep in mind that it will
become a bunch of library functions, so the amount of glue in drivers will
not go up.
-
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:23 EST