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