Re: [PATCH, RFC] sysfs: relay channel buffers as sysfs attributes

[Paul Mundt <lethal@linux-sh.org>]

On Mon, Feb 20, 2006 at 08:05:56AM -0500, Mathieu Desnoyers wrote:
> LTTng currently uses some particular features from relayfs. I would like to make
> sure that they will still be available.
> 
> * LTTng uses the "void *private" private data pointer extensively. It's very
>   useful to pass a kernel client specific data structure to the client
>   callbacks.
> * LTTng does have its own ltt_poll and ltt_ioctl that are all what is needed to
>   control the interaction with the file (along with the relayfs mmap/unmap).
> 
> In this scenario, the sysfs relay attribute creation would look like :
> 
> - create an empty attr
> - fill some of attr members
> - sysfs_create_relay_file(kobj, attr);
>   (it will overwrite some attr members : kobj, rchan, rchan_buf)
>   * set specific LTTng file operations on the inode
>   * set the "private" field of the rchan structure.
> 
->rchan is set after sysfs_create_relay_file(), you can set
->rchan->private after it's created. All that happens in
sysfs_create_relay_file() as far as the relay interface is concerned is
wrapping relay_open(), where ->rchan is first allocated.

As far as setting specific file operations for the inode, that's
definitely not in line with the sysfs way of doing things. If you need
to do this, go with debugfs, or stick with the relayfs patch on top of
CONFIG_RELAY as this stuff is clearly not going to be merged into
mainline as Cristoph also pointed out.

debugfs gives you roughly all of the same functionality, and the kernel
side implementation for what LTTng will need should be quite trivial. LTT
is arguably a debugging thing anyways, so debugfs seems like a more
appropriate match than trying to beat sysfs into submission with this
workload.
-
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/