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 wantit during normal system operation. This is an assumption that failswith at least LTT as it is targeted at sysadmins, application developersand 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, butunlike debugfs, relayfs is meant for general use, and all files in thereare of the same type: relay channels for dumping huge amounts of datato user-space. It seems to me the target audience and basic idea (relaychannels only in the fs) are different, but let me know if there's acompeling argument for doing this in another way without making it tooconfusing for users of those special "files" (IOW, when this startsbeing used in distros, it'll be more straightforward for users tounderstand if all files in a mounted fs behave a certain way than ifthey have certain "odd" files in certain directories, even if it's/proc.)