Messages in this thread | | | Date | Tue, 21 Feb 2006 17:21:02 +0200 | From | Paul Mundt <> | Subject | Re: [PATCH, RFC] sysfs: relay channel buffers as sysfs attributes |
| |
On Mon, Feb 20, 2006 at 12:37:32PM -0500, Mathieu Desnoyers wrote: > Those inode operations are generic enough to eventually be integrated to > relayfs. The poll is enhanced to support multiple readers. For the ioctl, it's > just a matter of getting/pulling buffer segments, reading the number of > subbuffers and their size, which I think really fits the i/o control purpose for > such a file. > Wait a minute, you're talking about inode operations, but then talking about poll() and ioctl(), which are clearly file operations. Can you clarify what exactly it is you want to overload? Changing inode operations seems like a really bad design decision..
> debugfs seems to offer really too much flexibility for what LTTng needs. It > doesn't really have to redefine "new" operations : the poll/ioctl used by LTTng > could in fact be integrated into RelayFS and simplify the file reading > operation. > Too much flexibility is not something people usually argue as a a point against adoption, especially for something as lightweight as debugfs, that's certainly a new one :-)
If you're talking about struct file_operations, then it would seem you would be best off sticking with debugfs. If the improved file operations are suitable for kernel/relay.c then they can be integrated there and then you don't have to worry about overloading the normal relay_file_operations through some helper functions to hand off to debugfs..
If you add native debugfs helper functions for creating relay files and working in line with CONFIG_RELAY, then I'm sure these can be rolled back in to debugfs proper, which should ease some of the LTTng maintenance.
I don't really see what having your own mount point and stubbed file system would buy you over this.. - 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/
| |