public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Tom Zanussi <zanussi@us.ibm.com>
Cc: Paul Mundt <lethal@linux-sh.org>, Greg KH <greg@kroah.com>,
	linux-kernel@vger.kernel.org, karim@opersys.com,
	compudj@krystal.dyndns.org
Subject: Re: [PATCH, RFC] sysfs: relay channel buffers as sysfs attributes
Date: Mon, 20 Feb 2006 10:20:09 +0100	[thread overview]
Message-ID: <20060220092008.GZ8852@suse.de> (raw)
In-Reply-To: <17401.21427.568297.830492@tut.ibm.com>

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


  reply	other threads:[~2006-02-20  9:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-19 17:17 [PATCH, RFC] sysfs: relay channel buffers as sysfs attributes Paul Mundt
2006-02-19 17:21 ` Christoph Hellwig
2006-02-19 17:56 ` Greg KH
2006-02-19 18:52   ` Paul Mundt
2006-02-20  5:29     ` Tom Zanussi
2006-02-20  9:20       ` Jens Axboe [this message]
2006-02-20 11:17       ` Paul Mundt
2006-02-20 13:05       ` Mathieu Desnoyers
2006-02-20 14:17         ` Christoph Hellwig
2006-02-20 17:15         ` Paul Mundt
2006-02-20 17:37           ` Mathieu Desnoyers
2006-02-20 22:27             ` Greg KH
2006-02-21 15:21             ` Paul Mundt
2006-02-21 16:48               ` Mathieu Desnoyers
2006-02-21 17:43                 ` Greg KH
2006-02-22 21:27                   ` Karim Yaghmour
2006-02-22 21:32                     ` Greg KH
2006-02-20 22:24     ` Greg KH
2006-02-21 15:10       ` [PATCH] sysfs: Add __ATTR_RELAY() helper for relay attributes Paul Mundt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060220092008.GZ8852@suse.de \
    --to=axboe@suse.de \
    --cc=compudj@krystal.dyndns.org \
    --cc=greg@kroah.com \
    --cc=karim@opersys.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zanussi@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox