From: Paul Mundt <lethal@linux-sh.org>
To: Dave Jones <davej@redhat.com>
Cc: Greg KH <greg@kroah.com>, Christoph Hellwig <hch@infradead.org>,
zanussi@us.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/5] relay: Migrate from relayfs to a generic relay API.
Date: Sun, 19 Feb 2006 23:27:48 +0200 [thread overview]
Message-ID: <20060219212748.GA4690@linux-sh.org> (raw)
In-Reply-To: <20060219212122.GA7974@redhat.com>
On Sun, Feb 19, 2006 at 04:21:22PM -0500, Dave Jones wrote:
> On Sun, Feb 19, 2006 at 11:07:33PM +0200, Paul Mundt wrote:
> > This is a small patch set for getting rid of relayfs, and moving the core of
> > its functionality to kernel/relay.c. The API is kept consistent for everything
> > but the relayfs-specific bits, meaning people will have to use other file
> > systems to implement relay channel buffers.
>
> What about the userspace visible API for things already using relayfs,
> like systemtap ? Whilst technically these patches may make sense,
> yanking the rug underneath applications as soon as they've started
> using it without warning or a migration period doesn't sound too good an idea.
>
Yes, that's why this is only done in the last two patches. The rest are
completely independent and don't interfere with the API (well, ok,
FIX_SIZE() needs to be dropped in fs/relayfs if it's fetching it from the
header, but that's it).
> It's taken us *years* to try and get rid of devfs, why should relayfs
> get ripped out any quicker, when it has valid users?
>
I'm not advocating its removal, I'm more interested in using it from
sysfs and debugfs where it makes more sense. Splitting up CONFIG_RELAY
and CONFIG_RELAYFS_FS will allow for both, and it'll also be possible to
migrate the existing CONFIG_RELAYFS_FS code to use CONFIG_RELAY without
breaking the userspace APIs if we want to get rid of the duplication. The
only issue will be wrapping up the default callbacks, but that's a
trivial ifdef.
next prev parent reply other threads:[~2006-02-19 21:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-19 21:07 [PATCH 0/5] relay: Migrate from relayfs to a generic relay API Paul Mundt
2006-02-19 21:07 ` [PATCH 1/5] sysfs: relay channel buffers as sysfs attributes Paul Mundt
2006-02-23 10:59 ` Maneesh Soni
2006-02-24 8:34 ` Paul Mundt
2006-02-24 9:35 ` Maneesh Soni
2006-02-19 21:08 ` [PATCH 2/5] relay: Consolidate relayfs core into kernel/relay.c Paul Mundt
2006-02-19 21:08 ` [PATCH 3/5] sysfs: Update relay file support for generic relay API Paul Mundt
2006-02-19 21:08 ` [PATCH 4/5] relayfs: Remove relayfs in favour of CONFIG_RELAY Paul Mundt
2006-02-19 21:09 ` [PATCH 5/5] relay: relay header cleanup Paul Mundt
2006-02-19 21:21 ` [PATCH 0/5] relay: Migrate from relayfs to a generic relay API Dave Jones
2006-02-19 21:27 ` Paul Mundt [this message]
2006-02-19 21:54 ` [PATCH] relayfs: Convert to " Paul Mundt
2006-02-19 22:09 ` Christoph Hellwig
2006-02-19 22:08 ` [PATCH 0/5] relay: Migrate from relayfs to a " Christoph Hellwig
2006-02-19 22:13 ` Dave Jones
2006-02-19 22:17 ` Christoph Hellwig
2006-02-19 22:29 ` Dave Jones
2006-02-19 22:48 ` Christoph Hellwig
2006-02-19 22:54 ` Dave Jones
2006-02-20 16:03 ` Christoph Hellwig
2006-02-20 20:05 ` Frank Ch. Eigler
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=20060219212748.GA4690@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=davej@redhat.com \
--cc=greg@kroah.com \
--cc=hch@infradead.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