Wait a second, I thought proc was here to stay. Wait another
second, device nodes are already magic. Magic is magic, just
choose your color ;-)
This set of magic dirs is supposed to clean things up, not mess things
up. We already saw how the side-effects-on-open problem in ls -l goes
away. There's a much bigger problem I'd love to deal with: the 'no
heirarchy can please everybody' problem. In database terms, aheirarchy
is an insufficiently general model for real-world problems, in other
words, they never worked. Tables work. That's where I'm trying to go
with this, so please bear with me. This is not just a solution in
search of a problem.
> > Correct me if I'm wrong, but what we learn from the proc example
> > is that tarring your whole source tree starting at / is not
> > something you want to do.
>
> IMHO it would be better to fix proc instead of adding more magic. At
> the moment you have to exclude /proc. You want to add /dev.
Well, actually no, ls -R, tar, zip, etc, work pretty well with the
scheme I've described.
> And
> next? Exclude all $HOME/dev (in case process name spaces get added)?
> Or make fifos magic too and add all of them to the exclude list? But
> there's no central place for fifos. So lets add more magic :-(
No, no, no, agreed and sometimes magic is good. It's not deep magic.
The only new thing here is the interpretation of the O_DIRECTORY flag,
or rather, the lack of it.
> > What *won't* happen is, you won't get side effects from opening
> > your serial ports (you'd have to open them without O_DIRECTORY
> > to get that) so that seems like a little step forward.
>
> As already said: depending on O_DIRECTORY breaks POSIX compliance
> and that alone should kill this idea...
Thanks, two good points:
- libc5 will get confused when doing ls in /magicdev
- POSIX specifically forbids this
I'll put this away until I've specifically dug into both of them. OK,
over and out, thanks for your commentary.
/me peruses man pages
Oops, oh wait, there's already another open point: your breakage
examples both rely on opening ".". You're right, "." should always be
a directory and I believe that's enforced by the VFS. So we don't have
an example of breakage yet.
-- Daniel- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/