Messages in this thread | | | Date | Mon, 20 Feb 2006 10:20:09 +0100 | From | Jens Axboe <> | Subject | Re: [PATCH, RFC] sysfs: relay channel buffers as sysfs attributes |
| |
On Sun, Feb 19 2006, Tom Zanussi wrote: > Paul Mundt writes: > > On Sun, Feb 19, 2006 at 09:56:23AM -0800, Greg KH wrote: > > > > [...] > > > > And I agree with Christoph, with this change, you don't need a separate > > > relayfs mount anymore. > > > > > Yes, that's where I was going with this, but I figured I'd give the > > relayfs people a chance to object to it going away first. > > > > If with this in sysfs and simple handling through debugfs people are > > content with the relay interface for whatever need, then getting rid of > > relayfs entirely is certainly the best option. We certainly don't need > > more pointless virtual file systems. > > > > I'll work up a patch set for doing this as per Cristoph's kernel/relay.c > > suggestion. Thanks for the feedback. > > Considering that I recently offered to post a patch that would do > essentially the same thing, I can't have any objections to this. ;-) > > But just to make sure I'm not missing anything in the patches, please > let me know if any of the following is incorrect. What they do is > remove the fs part of relayfs and move the remaining code into a > single file, while leaving everthing else basically intact i.e. the > relayfs kernel API remains the same and existing clients would only > need to make relatively minor changes: > > - find a new home for their relay files i.e. sysfs, debufs or procfs. > > - replace any relayfs-specific code with their counterparts in the new > filesystem i.e. directory creation/removal, non-relay ('control') > file creation/removal. > > - change userspace apps to look for the relay files in the new > filesystem instead of relayfs e.g. change /relay/* to /sys/* > in the relay file pathnames. > > Although I personally don't have any problems with doing this, I've > added some of the authors of current relayfs applications to the cc: > list in case they might have any objections to it. The major relayfs > applications I'm aware of are: > > - blktrace, currently in the -mm tree. This could probably move its > relayfs files to sysfs using your new interface.
blktrace just needs minor file location changes to work with this scheme, so no problem for me.
I think the patch is a good idea, it's a lot nicer than a separate fs.
-- Jens Axboe
- 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/
| |