On 12.08.2011 14:31, Matthew Wilcox wrote:
> On Fri, Aug 12, 2011 at 02:14:15PM +0200, Jan Schmidt wrote:
>> (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.
>
> struct file *filp = fget(fd);
> ...
> fput(filp);
>
> That said, why not have the ioctl mutate the existing fd?
> ie in userspace:
>
> int fd = open("/mnt/btrfs");
> ioctl(fd, BTRFS_IOC_STREAM);
> while (...) {
> read(fd, buf, 4096);
> ...
> }
> close(fd);
After thinking twice, this has a drawback: I'd have to track state
between two read(2) calls, waiting for userspace to "pull" more data.
In contrast, I'd rather use a "push" like approach, having the buffering
done for me. Getting back to my suggestion (1, giving a fd to the kernel
where the output is expected), that should look like this in userspace:
-
int fd;
int pipefd[2];
struct io_args io_args;
fd = open("/mnt/btrfs");
pipe(pipefd);
io_agrs.dest = pipefd[0];
/* thread 1 */
ioctl(fd, BTRFS_IOC_STREAM, &io_args);
/* thread 2 */
while (...) {
read(pipefd[1], buf, 4096);
...
}
-
Any suggestions and opinions appreciated. 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
