Xen devel - Apr 2013 - blktap2 header consistency between userspace and kernel space

Hi,


I''m wondering what''s up with the blktap device info structure
in blktap2.

Here''s the one from the blktap2 userspace utilities:
(it''s the same in debian package source, xen git tree and the github
blktap2 repo)

struct blktap_device_info {
        unsigned long long      capacity;
        unsigned int            sector_size;
        unsigned int            physical_sector_size;
        unsigned long           flags;
        unsigned long           __rsvd[4];
};


And this is the one in the kernel :
(as found on the debian dkms or some blktap patch for kernel 3.2)

struct blktap_device_info {
        unsigned long long      capacity;
        unsigned int            sector_size;
        unsigned long           flags;
        unsigned int            phys_block_size;
        unsigned int            phys_block_offset;
        unsigned int            trim_block_size;
        unsigned int            trim_block_offset;
};


Now the fields phys_XXX and trim_XXX won''t be accessed by the kernel
until it find the appropriate flag.

But the position of the ''flags'' field is not the same AFAICT !
I''m
under 64bits, so it just happen to work because the ''unsigned long
flags'' will be 64 bits aligned leaving a hole after sector_size in the
kernel structure, but on 32 bits arch, I think it''ll start using
''physical_sector_size'' as the flag field.

Am I missing something here ?


Cheers,

    Sylvain

On Tue, Apr 23, 2013 at 02:58:46PM +0200, Sylvain Munaut
wrote:
> Hi,
> 
> 
> I''m wondering what''s up with the blktap device info
structure in blktap2.
> 
> Here''s the one from the blktap2 userspace utilities:
> (it''s the same in debian package source, xen git tree and the
github
> blktap2 repo)
> 
> struct blktap_device_info {
>         unsigned long long      capacity;
>         unsigned int            sector_size;
>         unsigned int            physical_sector_size;
>         unsigned long           flags;
>         unsigned long           __rsvd[4];
> };
> 
> 
> And this is the one in the kernel :
> (as found on the debian dkms or some blktap patch for kernel 3.2)
> 
> struct blktap_device_info {
>         unsigned long long      capacity;
>         unsigned int            sector_size;
>         unsigned long           flags;
>         unsigned int            phys_block_size;
>         unsigned int            phys_block_offset;
>         unsigned int            trim_block_size;
>         unsigned int            trim_block_offset;
> };
> 
> 
> Now the fields phys_XXX and trim_XXX won''t be accessed by the
kernel
> until it find the appropriate flag.
> 
> But the position of the ''flags'' field is not the same
AFAICT !  I''m
> under 64bits, so it just happen to work because the ''unsigned long
> flags'' will be 64 bits aligned leaving a hole after sector_size in
the
> kernel structure, but on 32 bits arch, I think it''ll start using
> ''physical_sector_size'' as the flag field.
> 
> Am I missing something here ?
> 
Is this something related to blktap2 vs. blktap2.5 ? 

IIRC blktap2.5 userland requires blktap2.5 kernel modules..

-- Pasi

Hi,
> Is this something related to blktap2 vs. blktap2.5 ?
>
> IIRC blktap2.5 userland requires blktap2.5 kernel modules..
Honestly ... I''m not sure. Where are the reference/authoritative tree
for blktap2 and 2.5, both kernel and userspace ?

Since I took those headers from the debian repo, blktap-utils and
blktap-dkms, I would have expected them to be compatible ...

Cheers,

    Sylvain

On Tue, Apr 23, 2013 at 04:08:08PM +0200, Sylvain Munaut
wrote:
> Hi,
> 
> > Is this something related to blktap2 vs. blktap2.5 ?
> >
> > IIRC blktap2.5 userland requires blktap2.5 kernel modules..
> 
> Honestly ... I''m not sure. Where are the reference/authoritative
tree
> for blktap2 and 2.5, both kernel and userspace ?
> 
> Since I took those headers from the debian repo, blktap-utils and
> blktap-dkms, I would have expected them to be compatible ...
> 
Ok so this all is very confusing.. but I''ll try to explain it:

for userspace blktap tools:

	- blktap2: it''s in Xen hypervisor sources, so the latest version is in
xen-unstable (xen.git master branch).

	- blktap2.5: This is a blktap2 fork (and most "recent" version with
additional features) that''s being used in XenServer/XCP and with xapi
toolstack in general: https://github.com/xen-org/blktap .


for blktap kernel modules:

	- blktap2: I think Suse/Novell is maintaining these patches in their classic
"xenlinux" kernels, and they''re also in Jeremy''s
(now abandoned) xen.git Linux dom0 kernel tree based on Linux 2.6.32. These
patches newer went into upstream Linux, and probably never will. There are also
various forward- and back-ports of these to some newer Linux 3.x kernels. These
patches also exist in xen.org linux-2.6.18-xen classic xenlinux tree.
I''m not aware of any "official" kernel tree with up-to-date
blktap2 patches for recent Linux kernels.

	- blktap2.5: These drivers can be found from XenServer/XCP 2.6.32 classic
xenlinux dom0 kernel trees, and also from dstodden''s (now abandoned)
git repo at http://xenbits.xen.org/gitweb/?p=people/dstodden/linux.git;a=summary
and http://xenbits.xen.org/gitweb/?p=people/dstodden/blktap-dkms.git;a=summary .
dstodden switched jobs, so those are unmaintained repos. CentOS6 Linux 3.4 Xen
dom0 kernel also has the blktap2.5 patches/drivers included.


If I remembered something wrong, or pointed to wrong places, or forgot
something, please correct me :)

And then the good news: blktap3 is in the works, see patches on xen-devel
mailinglist, and it won''t need any blktap kernel driver! It''s
purely an userspace solution, with an active maintainer/developer.

-- Pasi

Hi,

Thanks for the explanation, it''s indeed confusing :p

>         - blktap2: it''s in Xen hypervisor sources, so the latest
version is in xen-unstable (xen.git master branch).
>
>         - blktap2.5: This is a blktap2 fork (and most "recent"
version with additional features) that''s being used in XenServer/XCP
and with xapi toolstack in general: https://github.com/xen-org/blktap .
I based my RBD driver on that github code, so I guess I use blktap2.5
then. And you can see the header here :

https://raw.github.com/xen-org/blktap/master/drivers/linux-blktap.h

>         - blktap2.5: These drivers can be found from XenServer/XCP 2.6.32
classic xenlinux dom0 kernel trees, and also from dstodden''s (now
abandoned) git repo at
http://xenbits.xen.org/gitweb/?p=people/dstodden/linux.git;a=summary and
http://xenbits.xen.org/gitweb/?p=people/dstodden/blktap-dkms.git;a=summary .
dstodden switched jobs, so those are unmaintained repos. CentOS6 Linux 3.4 Xen
dom0 kernel also has the blktap2.5 patches/drivers included.
And if you look at the header in those tree :

http://xenbits.xen.org/gitweb/?p=people/dstodden/linux.git;a=blob;f=include/linux/blktap.h;h=2cbefe97a4ab191dab5aae3d65df611ec9d9d557;hb=blktap/next-2.6.39

You can see they don''t match the userspace either.

The kernel blktap also seems to have FLUSH and TRIM support which are
not supported in any blktap userspace I could find.

> And then the good news: blktap3 is in the works, see patches on xen-devel
mailinglist, and it won''t need any blktap kernel driver! It''s
purely an userspace solution, with an active maintainer/developer.
Yes, I''ve seen :)  But it''s probably going to be a while until
it''s in debian :p
But at least the drivers should be compatible with the one I wrote for blktap2.5

Cheers,

    Sylvain