[lkml]   [2006]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-02-20 10:22    [W:0.098 / U:14.312 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site