* Paul Mundt ([email protected]) 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
