[lkml]   [2005]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] relayfs redux for 2.6.10: lean and mean
    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. 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.
    > 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. 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.)

    Perhaps the logical solution is to implement debugfs in terms of relayfs?

    Peter Williams

    "Learning, n. The kind of ignorance distinguishing the studious."
    -- Ambrose Bierce
    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.032 / U:15.732 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site