lkml.org 
[lkml]   [2006]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/5] relay: Migrate from relayfs to a generic relay API.
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-02-19 22:30    [W:0.630 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site