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

[Mathieu Desnoyers]

* Paul Mundt (lethal@xxxxxxxxxxxx) wrote:
> 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.
> 

I though about it, but it would create a race where the channel could be
accessed from user space before the private data pointer is set or the specific
inode operations are set.

> 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.
> 

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.


> 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.
> 

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.


Mathieu


OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/