The Linux Trace Kit (LTT) and relayfs were merged into Andrew Morton [interview]'s -mm patchset [forum] with the release of 2.6.11-rc1-mm1 [story]. At the time, Andrew encouraged a discussion into the merits of both to determine if they should ultimately be merged into the mainline kernel. The feedback to relayfs suggested that while it worked as advertised, it tended to be overly complicated providing more than was necessary.

Karim Yaghmour reworked the relayfs patch, purging the API and internal code. He notes, "the patch is in fact almost HALF! its original size, loosing 90KB and going from 200KB to 110KB". He went on to list some of the differences explaining, "basically this is about making relayfs do one thing and do it good: transfer high volumes of data to user-space as efficiently as possible." Karim also noted that the updated relayfs patch currently no longer works with LTT as merged in -mm, a temporary state while he waits for feedback on the direction to take. For example, Greg KH noticed some similarities between relayfs and his recently merged debugfs [story], offering suggestions for combining functionality to futher minimize the size of the relayfs patch. Discussion is ongoing.

From: Karim Yaghmour [email blocked]
To: linux-kernel [email blocked]
Subject: [PATCH] relayfs redux for 2.6.10: lean and mean
Date: 	Thu, 20 Jan 2005 01:23:48 -0500


I've reworked the relayfs patch extensively. The API and internals
have been heavily purged. The patch is in fact almost HALF! its
original size, loosing 90KB and going from 200KB to 110KB.

Here's a summary of changes:
- Dropped the lockless scheme (complaints from Christoph, Arjan,
  Ingo, Andrew, etc. regarding the debatable efficiency of cmpxchng
  over traditional locks.)
- Dropped the resizing capabilities (Andi, Christoph, etc.)
- Dropped all user-space read/write capabilities (Andi, Christoph,
  Roman, Tim, etc.) Basically this is about making relayfs do
  one thing and do it good: transfer high volumes of data to
  user-space as efficiently as possible.
- Implemented the ad-hoc mode. This mode contrasts with the
  managed mode (old locking scheme) in that it manages only
  one ring buffer, doesn't care about outside synchronization,
  and is basically the most basic buffer scheme one could have.
  (ongoing discussion with Roman on this issue.)
- Dropped the klog client (Greg).
- Modified API to use pointers instead of IDs (Roman).
- Miscallaneous cleanups (Domen).
- Miscallaneous rearrangement of code (me).

I've tested this with a hacked ltt patch and I can get it
to collect data in the managed mode without a problem.
Reading the data though is another story, I'll update the
LTT patch once I know where the relayfs stuff is heading.
Beware: don't try to use the ltt code in Andrew's tree with
this relayfs, it's a completely different beast.

So without further ado, here's the code. I've removed the
Documentation/filesystems/relayfs.txt file for now (no, don't
worry that's not part of the 90KB that went away ;). It's
probably going to need some rewriting before we're done,
so let's not get distracted by it for now.

Karim

The full patch is here:
http://www.opersys.com/ftp/pub/relayfs/patch-relayfs-redux-2.6.10-050120-real
http://www.opersys.com/ftp/pub/relayfs/patch-relayfs-redux-2.6.10-050120-real.bz2

Signed-off-by: Karim Yaghmour [email blocked]

diffstat:
 fs/Kconfig                            |   18
 fs/Makefile                           |    4
 fs/relayfs/Makefile                   |    8
 fs/relayfs/buffers.c                  |  202 +++++
 fs/relayfs/buffers.h                  |   33
 fs/relayfs/inode.c                    |  520 ++++++++++++++
 fs/relayfs/relay.c                    | 1193 ++++++++++++++++++++++++++++++++++
 fs/relayfs/relay.h                    |   62 +
 fs/relayfs/relay_adhoc.c              |  109 +++
 fs/relayfs/relay_adhoc.h              |   26
 fs/relayfs/relay_managed.c            |  270 +++++++
 fs/relayfs/relay_managed.h            |   26
 include/linux/relayfs_fs.h            |  378 ++++++++++
 14 files changed, 3659 insertions(+), 2 deletions(-)




From: Greg KH [email blocked]
Subject: Re: [PATCH] relayfs redux for 2.6.10: lean and mean
Date: 	Thu, 20 Jan 2005 06:50:46 -0800

On Thu, Jan 20, 2005 at 01:23:48AM -0500, Karim Yaghmour wrote:
> 
> I've reworked the relayfs patch extensively. The API and internals
> have been heavily purged. The patch is in fact almost HALF! its
> original size, loosing 90KB and going from 200KB to 110KB.

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.

Just an idea...

thanks,

greg k-h



From: Karim Yaghmour [email blocked]
Subject: Re: [PATCH] relayfs redux for 2.6.10: lean and mean
Date: 	Thu, 20 Jan 2005 20:38:25 -0500


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 blocked] || 1-866-677-4546



From: Greg KH [email blocked]
Subject: Re: [PATCH] relayfs redux for 2.6.10: lean and mean
Date: 	Thu, 20 Jan 2005 22:43:41 -0800

On Thu, Jan 20, 2005 at 08:38:25PM -0500, Karim Yaghmour wrote:
> 
> 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.

That is true.

> 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.

Are they willing to trade off the performance of LTT to get this?  I
thought this was being touted as a "when you need to test" type of
thing, not a "run it all the time" type of feature.

> 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.

And a driver will never want to have both a relay channel, and a simple
debug output at the same time?  You are now requiring them to look for
that data in two different points in the fs.

> 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.)

So, since you are proposing that relayfs be mounted all the time, where
do you want to mount it at?  I had to provide a "standard" location for
debugfs for people to be happy with it, and the same issue comes up
here.

Also, why not export your relayfs ops so that someone useing debugfs can
create a relay channel in it, or in any other type of fs they might
create?

thanks,

greg k-h

• Archive of above thread