W dniu 6 kwietnia 2011 19:37 użytkownik John Calixto
<john.calixto@xxxxxxxxxxxxxx> napisał:
> On Wed, 6 Apr 2011, Michał Mirosław wrote:
>> 2011/4/5 John Calixto <john.calixto@xxxxxxxxxxxxxx>:
>> > +#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
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
