Hi, I'm looking for a way to get a lot of information generated by the kernel to user space. Here comes why: I'm working on btrfs send, which should generate a full or incremental stream of a file system to be received elsewhere. I don't want to send data and metadata from the internal trees for various reasons. But to efficiently detect hardlinks and clones (reflinks), kernel help is required. It would be most efficient (ram and runtime) to generate a list of file names in kernel in a certain order and annotate each such record with hardlink- and clone-specific information. I'd like to leave it at that for the moment, please just think of it as a bunch of really useful information that can only be generated by the kernel and is needed by user space. However, I can write a lot more on the background and why I think this should really be the way to go, if anyone wishes. Now I'm a bit at a loss, though. I have two (and a half) ideas how to push that bunch of data to user space, and both feel ugly a different way. And for each of them, I could need a hint for the right direction: (1) Normally, requests to the file system go through ioctls (on the fd of the mountpoint) and the result is small enough to be returned when the ioctl finishes. That said, I thought of passing a user land fd along with this ioctl to the kernel and make it dump the generated bits there. Only, I don't see how to turn a fd into a struct file pointer. And I don't know if that would be considered really ugly by a lot of people. (2) In btrfs, we have an additional control device, /dev/btrfs-control. The read(2) call seems a good interface to use. Only, noone talks to /dev/btrfs-control about file systems right now. The only call it implements is BTRFS_IOC_SCAN_DEV to scan a device whether it contains a btrfs file system. I'm uncertain whether a completely different mechanism of triggering some action on the file system is a good solution. And, if it really was, I'm not sure how this would be best implemented. (3) The last idea is a combination of the other two: Use the good part from (1), which is doing the ioctl on the fd of the mountpoint, telling the fs what we want. Then (this is the part from (2)) open /dev/btrfs-control for reading and grab the output. Only, I have no plan how to tie those two distinct kernel requests together in a way that call (1) triggers output on device (2)... And would that really make it any less ugly? Any hints on /how/ to implement /which/ of those (or even something completely different, of course) would be really helpful. I'm trying to avoid botching up a solution that no one considers appropriate :-) Thanks, -Jan -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
