On Sun, Jan 16, 2005 at 01:05:19PM -0600, Tom Zanussi wrote: > One of the things that uses these functions to read from a channel > from within the kernel is the relayfs code that implements read(2), so > taking them away means you wouldn't be able to use read() on a relayfs > file.
Removing them from the public API is different from disallowing the read operation. > That wouldn't matter for ltt since it mmaps the file, but there > are existing users of relayfs that do use relayfs this way. In fact, > most of the bug reports I've gotten are from people using it in this > mode. That doesn't mean though that it's necessarily the right thing > for relayfs or these users to be doing if they have suitable > alternatives for passing lower-volume messages in this way. As others > have mentioned, that seems to be the major question - should relayfs > concentrate on being solely a high-speed data relay mechanism or > should it try to be more, as it currently is implemented? I'd say let it do one thing well, that is high-volume data transfer. > If the > former, then I wonder if you need a filesystem at all - all you have > is a collection of mmappable buffers and the only thing the filesystem > provides is the namespace. Removing read()/write() and filesystem > support would of course greatly simplify the code; I'd like to hear > from any existing users though and see what they'd be missing. What else would manage the namespace? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
