>Writing a plugin (not necessarily r4 specific) that changes the semantics >of objects based on context (i.e. turning a file into a dir) is a bad idea >IMHO. I'm with you on that, but I don't believe the Reiser4 plugins that have been proposed do that. In fact, I'm not sure they could, because the plugin probably doesn't get much context information. In the file/directory thing, we're really talking about a filesystem object which is both at the same time, not one that is one or the other depending on context. Being both at the same time causes some problems with classifying it. When a product is both a floor wax and a dessert topping, on what aisle do you stock it? The idea of having standard Unix filesystem operations mean different things on different objects is well established and fully user-pluggable. A write() of a device special file for a terminal does a rather different thing from a write() of a regular file. And, of course, there's proc. So there are valid objections to installing a plugin that lets you 'ls' a tar file, but Reiser4 plugins per se don't seem to be the problem. >Actually, BSD has this double-semantic to a limited degree: you can call >`/usr/bin/vi /usr/bin` and get some binary representation of readdir. I think that's actually more of a vestige than an innovation. Linux is more evolved in failing an attempt to read() a directory. In original Unix, the directory system was almost completely separate from the flat file system, with each directory being implemented as a file. It would have taken work _not_ to let the user read() it. This was very bad for forward compatibility, and was one of the ways that it's apparent that the designers couldn't make up their mind whether the directory layer should be separate or not. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
