Re: [Xen-devel] blktap2 header consistency between userspace and kernel space

[Pasi Kärkkäinen <pasik@xxxxxx>]

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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel