lkml.org 
[lkml]   [2005]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.11-rc1-mm1
    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:09    [W:4.053 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site