> 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...
Probably you can hack around it with NFS... oh, crap, you've said FAT
partition. Well, it's going to suck. CODA might help here, though.
Basically the problem is that we have no way in hell to check when the
negative dentry becomes positive just because somebody created a file
using another instance. Plus we are SOL wrt the locking - multiple
dentries for directory are bad enough, but multiple in-core inodes...
<shudder>. And there is quite a bunch of nice places where filesystems
decide to do their own thing and hold VFS fast - attempts to change the
behavior mean fs breakage.
> 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.
Let me put it that way: I care for this kind of technical problems in the
main tree. devfs joining the show will mean a neat addition to this pile
of troubles. OTOH, some parts of devfs look suspiciously similar to
possible fixes of VFS problems. Not 1-to-1, but close quite enough to give
ugly interferention with the fixes-to-come. Another thing being that part
of devfs problems resembles procfs ones and here implementation _does_
matter.
There is no devfs IDEA - there is a collection of stuff that manages to
touch almost all sore points of VFS _and_ device detection/bus
structure/etc. In the all-or-nothing form it's fairly intrusive and I
doubt that anybody can accurately evaluate the results. Almost everyone
has objections against some part. Splitting it into more-or-less compact
pieces so that impact of each would be understandable would help big way.
I don't want to go into UI part - I'm not too fond of the way it's done
and I see that there is more than it. Chances that someday the patch will
be just applied to the main tree are 0. It's too big for that and parts
that I can comment on definitely have problems. Ditto for everybody else
and UI is probably the most controversial part. Tie the idea to UI and
there you go... Yes, somebody could try to learn the patch and do the
splitting. It's not a trivial work and in all honesty it should be done by
proponents of devfs. Every (or almost every) part can probably be modified
so that it would go. But there is no way to tell it unless the parts
are edible for those who will deal with them.
> It' stupid to clean up implementation if something is rejected on bad idea
> basis.
It's stupid _not_ to do it if one of the ideas is considered bad and
blocks the whole thing simply because everone sees (a) implementation in
need of fixes in the part he can read, (b) entangled mix of code in
less familiar areas and (c) couple of things that Just Look Wrong(tm).
Oh, and a bunch of advocates in bargain...
> 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".
No, it's "problems in the patch". Sorry.
> 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 ?
devpts is OK since it's a flat namespace and there is no
create/unlink/etc. stuff. procfs has its own set of problems, but they
differ depending on the part of tree. IMO there are 3 filesystems
struggling to get out. And the code is full of anachronisms. Plus
everybody and its mom are directly exporting initialized structures
(directory entry templates) making the structure essentially frozen.
It has problems with multiple mounting in the dynamic part, all right.
Not exactly the same (you have less methods and it makes life somewhat
simpler), but they are close enough.
> 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 ...
Then separate it into more or less independent pieces so that they
could be discussed _somewhere_, damnit! And for $DEITY sake, keep the
advocacy out of the whole thing. It only pisses off - those who can be
affected by advocacy can't write, so you are unlikely to find them
helpful. It's bad enough that Linux is often associated with the howling
crowds of SplashSnort imbecils, but reproducing it here is outright
ridiculous.
-
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/