Re: [linux-usb] Re: USB device allocation

Martin Dalecki (dalecki@cs.net.pl)
Sat, 09 Oct 1999 18:34:30 +0200

Alexander Viro wrote:
>
> On Sat, 9 Oct 1999, Khimenko Victor wrote:
>
> > In <Pine.GSO.4.10.9910090525450.14121-100000@weyl.math.psu.edu> Alexander Viro (viro@math.psu.edu) wrote:
> >
> >
> > AV> On Sat, 9 Oct 1999, Khimenko Victor wrote:
> >
> > >> AV> Learn. This place is not exactly UNIX 101, you know...
> > >>
> > >> Yes. I know. I know even more: Linux is NOT Unix.
> >
> > AV> Yes, it is. Sorry to break it upon you, but..
> >
> > 1. It's NOT certified as Unix.
> > 2. It's NOT derived from Unix sources.
>
> And it shares helluva lot of basic design. Which is all that matter when
> you are working with it. You are not hacking or using the certificate.
>
> > Hmm. I think. Think once more. Directory was text file initially and was
> > modified by suid mkdir program when needed. It's changed now. Why ? It was
>
> No, it wasn't. Directories were different kind of inodes from the very
> beginning.
>
> > so wonderfull idea ! /dev is not filesystem now but bunch of special files.
> > Why to have special files and not special filesystem is so wonderfull idea ?
>
> Sigh...
> a) special filesystem might be nice, but not with the _current_
> _devfs_ _design_.
> b) our VFS is not well-suited for mounting the same fs in several
> places. It can be kludged with revalidate and friends but it means races.
> Yes, procfs is not better.
>
> > AV> One more time. Slowly. Take. Care. To. Look. At. The. Code. That. Is.
> > AV> Supposed. To. Work. With. Devfs. Look. At. The. VFS. Code.
> > AV> Sheesh...
> >
> > You mean that the only reason to reject devfs is troubles with VFS ?
>
> Damn!!! One. More. Fscking. Time. I'm talking about _my_ problems with
> devfs. I'm not a telepath. I don't have a habit of speaking for other
> folks. _MY_ (moi, b...) problems with devfs are VFS-related.
>
> > AV> Though luck, then. What you are telling boils down to: "I want it; I don't
> > AV> give a damn for the problems; code around and I can't be even bothered to
> > AV> figure out what those problems _are_." Do you really expect to be taken
> > AV> seriously?
> >
> > Problems are solved by Richard mostly. So far I hear only about one technical
> > problem with devfs (from you BTW): problems with VFS (which one BTW: rename is
> > not implemented in procfs and procfs is included in kernel; what's is so
> > different in devfs?). This is THE ONLY REAL problem.
>
> Boga-dushu-mat'! No, it is not the only real problem. Just from the quick
> look at the latest patch: there is an interesting race between lookup and
> unregistering an intermediate directory. _Lack_ of rename() kinda sucks,
> but it's not a VFS problem per se. But races between the operations on
> different instances of devfs (mounted several times) _are_. And we don't
> have any protection other than the big lock here - i_sem doesn't help
> here. AFAICS the same applies to a bunch of sweet races between lookup()
> and (e.g.) rmdir() (in the moment of blocking revalidate on dentry).
>
> > BTW what about devpts and procfs: are they any better from VFS side ? They are
> > both in kernel and devpts was added when devfs already existed...
>
> devpts is definitely better. procfs ;-/ Kinda-sorta. proc_unregister()
> sucks hard and the fact that calls are scattered over the crapload of
> drivers doesn't make life easier. Sigh...
>
> > AV> No, sir. You will have to deal with the technical reasons. "Purely" has
> > AV> nothing to this sad fact. BTW, may I also remind you that l-k is a
> > AV> _technical_ list?
> >
> > Hmm. Looking on messages published there for last few days you hardly can say
> > that :-) If the only reasons to not include devfs in kernel are technical ones
> > then what are they ? If there are some reasons then WHERE should are they be
> > discussed ? For devfs to be included in kernel ALL reasons should be
> > resolved...
>
> Yup. As for the good places for discussing that stuff - heck, Richard is
> more than welcome to fsdevel. _If_ devfs is going to go into the standard
> tree at all it will not happen in one huge gulp. Patch is too big and
> affects too many places. Both devfs and the standard tree have problems
> and I'm more than sure that Richard will not object to getting the patch
> smaller.
>
> [snip]
> > has it AFAIK. Why it's Ok for procfs and not Ok for devfs ?
> Procfs sucks. It's a PITA and will remain such for quite a while,
> I'm afraid. It got into the kernel and too many utilities depend on its
> current form to fix it fast. Worse yet, it doesn't have a coherent
> interface and calls are scattered all over the tree + 3rd-party drivers.
> Heck, that's one of the reasons why additional interfaces are not too
> welcome, to put it mildly. They tend to stick. If they are local enough
> they can be fixed later, but otherwise they'ld bloody better be good from
> the very beginning _and_ remain so.

Thank's! Finally a single only developer on linux-kernel who has enough
of guts to admit to design errors here in a crear nonnebulous way :-).

--Marcin

-
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/