Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup) | Date | Fri, 25 May 2001 13:00:00 +0200 |
| |
On Thursday 24 May 2001 22:59, Edgar Toernig wrote: > Daniel Phillips wrote: > > > > Readdir fills in a directory type, so ls sees it as a directory > > > > and does the right thing. On the other hand, we know we're on > > > > a device filesystem so we will next open the name as a regular > > > > file, and find ISCHR or ISBLK: good. > > > > > > ??? The kernel may know it, but the app? Or do you really want > > > to give different stat data on stat(2) and fstat(2)? These flags > > > are currently used by archive/backup prgs. It's a hint that > > > these files are not regular files and shouldn't be opened for > > > reading. Having a 'd' would mean that they would really try to > > > enter the directory and save it's contents. Don't know what > > > happens in this case to your "special" files ;-) > > > > I guess that's much like the question 'what happens in proc?'. > > And that's already bad enough. Most of the "files" in proc should > be fifos! And using proc as an excuse to introduce another set of > magic dirs? No, thanks.
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/
| |