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.) Karim -- Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546 - 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/
