[lkml]   [2005]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] relayfs redux for 2.6.10: lean and mean
    On Thu, Jan 20, 2005 at 08:38:25PM -0500, Karim Yaghmour wrote:
    > Greg KH wrote:
    > > Hm, how about this idea for cutting about 500 more lines from the code:
    > >
    > > Why not drop the "fs" part of relayfs and just make the code a set of
    > > struct file_operations. That way you could have "relayfs-like" files in
    > > any ram based file system that is being used. Then, a user could use
    > > these fops and assorted interface to create debugfs or even procfs files
    > > using this type of interface.
    > >
    > > As relayfs really is almost the same (conceptually wise) as debugfs as
    > > far as concept of what kinds of files will be in there (nothing anyone
    > > would ever rely on for normal operations, but for debugging only) this
    > > keeps users and developers from having to spread their debugging and
    > > instrumenting files from accross two different file systems.
    > However this assumes that the users of relayfs are not going to want
    > it during normal system operation.

    That is true.

    > This is an assumption that fails with at least LTT as it is targeted
    > at sysadmins, application developers and power users who need to be
    > able to trace their systems at any time.

    Are they willing to trade off the performance of LTT to get this? I
    thought this was being touted as a "when you need to test" type of
    thing, not a "run it all the time" type of feature.

    > I don't mind piggy-backing off another fs, if it makes sense, but
    > unlike debugfs, relayfs is meant for general use, and all files in there
    > are of the same type: relay channels for dumping huge amounts of data
    > to user-space.

    And a driver will never want to have both a relay channel, and a simple
    debug output at the same time? You are now requiring them to look for
    that data in two different points in the fs.

    > It seems to me the target audience and basic idea (relay
    > channels only in the fs) are different, but let me know if there's a
    > compeling argument for doing this in another way without making it too
    > confusing for users of those special "files" (IOW, when this starts
    > being used in distros, it'll be more straightforward for users to
    > understand if all files in a mounted fs behave a certain way than if
    > they have certain "odd" files in certain directories, even if it's
    > /proc.)

    So, since you are proposing that relayfs be mounted all the time, where
    do you want to mount it at? I had to provide a "standard" location for
    debugfs for people to be happy with it, and the same issue comes up

    Also, why not export your relayfs ops so that someone useing debugfs can
    create a relay channel in it, or in any other type of fs they might


    greg k-h
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:09    [W:0.021 / U:5.820 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site