Re: [PATCH, RFC] sysfs: relay channel buffers as sysfs attributes

[Tom Zanussi]

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.

- LTT, not sure where LTT would want to move.

- systemtap.  sytemtap uses relayfs as one possible transport.  The
  other is a proc-based transport, so logically it would make sense
  for systemtap to move its relay files to /proc.


Tom


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/