Re: [PATCH 1/2] Add userspace device-mapper target

[Dan Smith <danms@us.ibm.com>]

-----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@us.ibm.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFzJkmwtEf7b4GJVQRAsvPAKCCCmKCPqziEGA39pbpNB8rPm/URgCdFLQg
7zvBXPLXRhvsdezVQRAGMyg=
=r63I
-----END PGP SIGNATURE-----