-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FT> We need a pointer and length (or size) but not an offset. This FT> enables an user-space to pass the kernel data to write. Why not an offset? If the kernel knows nothing of the format of the metadata, then userspace needs to be able to say "Put 512 bytes from this buffer at sector 23 on the disk". FT> You need to set bio->bi_sector. bio_map_user() just grabs user's FT> pages and put them into a bio. Users of blk_rq_map_user (like FT> SG_IO) doesn't need bio->bi_sector. Right, ok, I've looked through scsi_ioctl.c and cdrom.c and I have a much better idea of how it is currently used. FT> Yeah, as you said, you can just allocate buffer and use it. If FT> buffer is properly aligned, we can do zero-copy. But if not, the FT> kernel allocates pages and copies user's pages FT> (bio_copy_user). Right. I think this would be very good for both performance and ease of use. Keeping track of requests in userspace to properly handle the endio and corresponding metadata flush can be a pain. I don't think, however, that we should completely get rid of the DMU_FLAG_SYNC behavior, because if someone wanted to use dm-userspace block block debugging or something, they may want to be able to intercept both the request and the endio. I'll take a stab at making this change and will post it when I have something working... - -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@xxxxxxxxxx -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFzJkmwtEf7b4GJVQRAsvPAKCCCmKCPqziEGA39pbpNB8rPm/URgCdFLQg 7zvBXPLXRhvsdezVQRAGMyg= =r63I -----END PGP SIGNATURE----- -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
