lkml.org 
[lkml]   [2005]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 01/13] [RFC] ipath basic headers
From
Date
Andi Kleen <ak@suse.de> writes:

> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> Christoph Hellwig <hch@infradead.org> writes:
>>
>> > please always used fixes-size types for user communication. also please
>> > avoid ioctls like the rest of the IB codebase.
>>
>> Could someone please explain to me how the uverbs abuse of write
>> is better that ioctl?
>
> It's actually worse because if they have a 32bit compat issue
> then ioctl can be fixed up, but read/write can't.
>
> I wish the people arguing against ioctl all the time would
> just stop that because the alternatives are usually worse.

Some of the suggestions like using sysfs aren't too bad.
One value per file in text format is clean and not going
to change when you switch architectures :)

The rule should really be that you can't just argue against ioctl but
instead you must argue for something.

>> - 64bit compilers will not pad every structure to 8 bytes. This
>> only will happen if you happen to have an 8 byte element in your
>> structure that is only aligned to 32bits by a 32bit structure.
>> Unfortunately the 32bit gcc only aligns long long to 32bits on
>> x86, which triggers the described behavior.
>
> Exactly - and driver writers usually don't get that right so we
> need to have a tool to fix it up in the end. And with ioctl
> that's easiest.

In this case I don't see any current problems. But I don't
think this is a pattern we want to encourage, and if there
is a more maintainable pattern now would be the time to fix it.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-12-18 16:09    [W:0.094 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site