Re: [PATCH v2 1/2] mmc: Add ioctl to let userspace apps send ACMDs

["Michał Mirosław" <mirqus@gmail.com>]

W dniu 6 kwietnia 2011 19:37 użytkownik John Calixto
<john.calixto@modsystems.com> napisał:
> On Wed, 6 Apr 2011, Michał Mirosław wrote:
>> 2011/4/5 John Calixto <john.calixto@modsystems.com>:
>> > +#ifdef CONFIG_COMPAT
>> > +struct sd_ioc_cmd32 {
>> > +       u32 write_flag;
>> > +       u32 opcode;
>> > +       u32 arg;
>> > +       u32 response[4];
>> > +       u32 flags;
>> > +       u32 blksz;
>> > +       u32 blocks;
>> > +       u32 postsleep_us;
>> > +       u32 force_timeout_ns;
>> > +       compat_uptr_t data_ptr;
>> > +};
>> > +#define SD_IOC_ACMD32 _IOWR(MMC_BLOCK_MAJOR, 0, struct sd_ioc_cmd32)
>> [...]
>>
>> Since your implementing a new ioctl you can make the structure the
>> same for 64 and 32-bit archs and avoid all this compat crap.
> I was also less than pleased with this, but I chose to implement the
> compat crap because it allow a "natural" userspace API for both the
> kernel32+user32 and kernel64+user64 environments.  The ugliness in the
> kernel is just when you have defined CONFIG_COMPAT.  I think 32-bit-only
> is still an important target for this functionality (think set-top media
> players, mobile devices; basically, anything running on ARM) so always
> having to cast your data pointer to 64-bit is not appealing.  I suspect
> it will be very unlikely to see people using this in the kernel64+user32
> environment.

The problem is only with data_ptr field. If you make it the same size
whether it's for 32-bit or 64-bit arch then you don't need all that
compat code for user32 on kernel64 except for pointer translation when
there's 32-bit process calling.

Best Regards,
Michał Mirosław