AV> 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.
AV> And it shares helluva lot of basic design. Which is all that matter when
AV> you are working with it. You are not hacking or using the certificate.
Correct. But just since it shareds "helluva lot of basic design" is not reason
to share ALL BASIC DESIGN...
>> 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
AV> No, it wasn't. Directories were different kind of inodes from the very
AV> beginning.
At least it was possible to open them as [almost] text file. There was inode
number and filename on each line. It was long, long ago.
>> 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 ?
AV> Sigh...
AV> a) special filesystem might be nice, but not with the _current_
AV> _devfs_ _design_.
AV> b) our VFS is not well-suited for mounting the same fs in several
AV> places.
Yes, and it's not good :-/ I wanted to mount my FAT partiton in two chroot'ed
environments and was unable to do such...
AV> It can be kludged with revalidate and friends but it means races.
AV> 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 ?
AV> Damn!!! One. More. Fscking. Time. I'm talking about _my_ problems with
AV> devfs. I'm not a telepath. I don't have a habit of speaking for other
AV> folks. _MY_ (moi, b...) problems with devfs are VFS-related.
Great. Such problems should be and can be fixed before devfs will be accepted
(in 2.5.x -- it's to late for 2.3.x) even if they are not trivial. But looks
like you are the only one who cares about technical problems with devfs and
not political ones :-/ All other folks (including Theodore Y. Ts'o and
H. Peter Anvin) object against devfs IDEA, not against IMPLEMENTATION.
It' stupid to clean up implementation if something is rejected on bad idea
basis.
>> 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.
AV> Boga-dushu-mat'! No, it is not the only real problem.
Misunderstanding. By "the only real problem" I mean "problems with VFS", not
"problems with rename".
AV> Just from the quick look at the latest patch: there is an interesting race
AV> between lookup and unregistering an intermediate directory.
It's still "problems with VFS".
AV> _Lack_ of rename() kinda sucks, but it's not a VFS problem per se.
AV> But races between the operations on different instances of devfs (mounted
AV> several times) _are_.
And it's interesting question: is devfs the only filesystem with needs to be
mounted few times ?
AV> And we don't
AV> have any protection other than the big lock here - i_sem doesn't help
AV> here. AFAICS the same applies to a bunch of sweet races between lookup()
AV> and (e.g.) rmdir() (in the moment of blocking revalidate on dentry).
Yes, this exactly type of problems where noone will object that problem exists
in first place and that it should be solved somehow. Unfortunatelly you are the
only one who raise such REAL problem with devfs. Most users are angry on IDEA
not IMPLEMENTATION :-/
>> 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...
AV> devpts is definitely better. procfs ;-/ Kinda-sorta. proc_unregister()
AV> sucks hard and the fact that calls are scattered over the crapload of
AV> 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...
AV> Yup. As for the good places for discussing that stuff - heck, Richard is
AV> more than welcome to fsdevel.
Devfs is MUCH more then filesystem :-/ For better and for worse. fsdevel is
place to discuss interaction between devfs and VFS, races in devfs and so on.
But it's not all story with devfs ...
AV> _If_ devfs is going to go into the standard tree at all it will not happen
AV> in one huge gulp. Patch is too big and affects too many places. Both devfs
AV> and the standard tree have problems and I'm more than sure that Richard will
AV> not object to getting the patch smaller.
AV> [snip]
>> has it AFAIK. Why it's Ok for procfs and not Ok for devfs ?
AV> Procfs sucks. It's a PITA and will remain such for quite a while,
AV> I'm afraid. It got into the kernel and too many utilities depend on its
AV> current form to fix it fast. Worse yet, it doesn't have a coherent
AV> interface and calls are scattered all over the tree + 3rd-party drivers.
AV> Heck, that's one of the reasons why additional interfaces are not too
AV> welcome, to put it mildly. They tend to stick. If they are local enough
AV> they can be fixed later, but otherwise they'ld bloody better be good from
AV> 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/