Messages in this thread | | | Date | Mon, 20 Feb 2006 08:05:56 -0500 | From | Mathieu Desnoyers <> | Subject | Re: [PATCH, RFC] sysfs: relay channel buffers as sysfs attributes |
| |
* Tom Zanussi (zanussi@us.ibm.com) wrote: > Paul Mundt writes: > > On Sun, Feb 19, 2006 at 09:56:23AM -0800, Greg KH wrote: > > > > [...] > > > > And I agree with Christoph, with this change, you don't need a separate > > > relayfs mount anymore. > > > > > Yes, that's where I was going with this, but I figured I'd give the > > relayfs people a chance to object to it going away first. > > > > If with this in sysfs and simple handling through debugfs people are > > content with the relay interface for whatever need, then getting rid of > > relayfs entirely is certainly the best option. We certainly don't need > > more pointless virtual file systems. > > > > I'll work up a patch set for doing this as per Cristoph's kernel/relay.c > > suggestion. Thanks for the feedback. > > Considering that I recently offered to post a patch that would do > essentially the same thing, I can't have any objections to this. ;-) > > But just to make sure I'm not missing anything in the patches, please > let me know if any of the following is incorrect. What they do is > remove the fs part of relayfs and move the remaining code into a > single file, while leaving everthing else basically intact i.e. the > relayfs kernel API remains the same and existing clients would only > need to make relatively minor changes: > > - find a new home for their relay files i.e. sysfs, debufs or procfs. > > - replace any relayfs-specific code with their counterparts in the new > filesystem i.e. directory creation/removal, non-relay ('control') > file creation/removal. > > - change userspace apps to look for the relay files in the new > filesystem instead of relayfs e.g. change /relay/* to /sys/* > in the relay file pathnames. > > Although I personally don't have any problems with doing this, I've > added some of the authors of current relayfs applications to the cc: > list in case they might have any objections to it. The major relayfs > applications I'm aware of are: > > - LTT, not sure where LTT would want to move. >
Hi,
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.
The two operations marked with a * would need supplementary parameters to sysfs_create_relay_file. Or is there something I missed ?
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |