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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/