Messages in this thread | | | Date | Sun, 19 Feb 2006 23:27:48 +0200 | From | Paul Mundt <> | Subject | Re: [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/
| |