All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.