Alexander Viro writes:
>
>
> On 17 Apr 2000, david parsons wrote:
>
> > I'd think it would be somewhat better to patch devfs so that it can
> > only be mounted once (as a quick fix to the technical issues that
> > are now being mentioned; if there are other technical issues with
>
> Erm... David, unfortunately Richard wants to be able to have subsets
> of the tree to be mounted in chroot jails. It's trivial if we just
> union-mount pieces (each piece shared between all mountpoints where
> it's going to be visible) and it's a huge PITA if we keep them as
> parts of one fs. Notice that all _code_ may be very well shared -
> just that you want to have a separate struct super_block and a
> dentry tree for each piece.
Please tell me if there's a way of applying different permissions for
different devices *in the same tree/mini-devfs*. I'm concerned that
the union-mount approach is too coarse-grained.
> Basically that's the how Richard had managed to piss me off _big_
> _way_ - he had heard about that problem many times and he just keeps
> ignoring it.
I haven't ignored it. I will be addressing the race conditions in due
course. I've said this to you in another thread. I am, however, very
busy. Didn't I just see you flame the other day for David pushing you
to deliver some code? You said you were busy. So if you don't like
being pushed, don't push others.
Crikey! Between work, linux hacking and having a life, I'm lucky to
get as much done as I do.
> > david parsons \bi/ automount. Shudder.
>
> Shudder, indeed. Now, guess what devfs _already_ contains?
> Right-o. Close analog of automount, complete with the userland
> daemon, yodda, yodda. IOW, it's the same kind of problem, same kind
> of gotchas and these beasts really ought to be joined - autofs
> misses several pieces of functionality needed for the stuff wanted
> by devfs. Easier to merge them than to keep two independent pieces
> of code that do subsets of the same thing, each with its own warts.
It would be interesting to see if a merged FS could be produced that
suported all the existing features of devfs and autofs. I suspect it
would be hard, and may end up being more messy than you expect.
> _If_ we are getting a unform facility that would pass
> lookups/revalidations on given dentries/in given directories/etc. to
> the userland daemon and provide the list of non-busy filesystems
> (doable without tree-walking, BTW) - then both autofs and relevant
> pieces of devfs become trivial. And I can easily see dozen of other
> applications for the same thing.
Yes, it would be good if this can be done. But I wouldn't want to see
existing devfs features removed for the sake of merging.
> Then devfs can really forget about directory-related code - it
> will be the same as for devpts/kernfs/shmfs/ramfs/etc. Literally the
> same, I mean.
If I can get the same functionality with much less code, I'm all for
it. As I've said before, Al, build me a better VFS and I'll use it.
But just as it's taking you a long time to clean up the VFS, expect it
will take me a fair bit of time to carefully consider the
implications. I don't want to be pushed to rush headlong into massive
changes without thinking about them.
Patience goes both ways :-)
BTW: this isn't a flame, but I often find it difficult to parse what
you're saying. Between the flames, and The. Use. Of. Punctuation. And.
Capitalisation. In. Your. Sentences. When. You'Re. Trying To. Make.
A. Point. and the resorting to excessive or obscure jargon, it's
difficult to understand what you mean.
Bear in mind also that a lot of these discussions would be aided by
having a whiteboard and talking face-to-face, so email is pretty
inefficient at the best of times. Please try to make it easier on us
all. I'd prefer to to be able to discuss and debate productively,
rather than sifting through endless emails and bickering.
It would help me if you spent a little more time crafting you emails
so they were easy for me to grok.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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 : Sun Apr 23 2000 - 21:00:15 EST