linuxconsole-dev

Re: [Linuxconsole-commit]CVS: ruby/linux/include/linux input.h,1.65,1.66

[Johann D. <joh...@la...>]

Rodrigo Damazio wrote:
> Update of /cvsroot/linuxconsole/ruby/linux/include/linux
> In directory usw-pr-cvs1:/tmp/cvs-serv2684/linux/include/linux
> 
> Modified Files:
> 	input.h 
> Log Message:
> Fix for the types problem - uint16_t and similars are not exported outside the kernel.
> They were replaced by __u16 and similars. fftest and other utils should now compile OK.
> 

No, uint16_t is not a kernel specific thing. __u16 is. I prefered it the 
other way.

I switched from __u16 to uint16_t on the advice of Brad Hards. The point 
is that uint16_t is apparently a standard type (C99). __u16 is a 
linux-kernel specific thing (16 bit unsigned integer visible from user 
space).
The discussion went on on linux-usb, and apparently no agreement was 
reached.
The point is that input.h should include the header defining uint16_t. 
That would be a more proper fix.
I don't really care what we actually use. After all, an unsigned 16 bit 
int remains an unsigned 16 bit int whatever we call it. But we should 
settle this at once and make up our minds.

> 
> Index: input.h
> ===================================================================
> RCS file: /cvsroot/linuxconsole/ruby/linux/include/linux/input.h,v
> retrieving revision 1.65
> retrieving revision 1.66
> diff -u -d -r1.65 -r1.66
> --- input.h	15 Apr 2002 19:14:22 -0000	1.65
> +++ input.h	3 May 2002 18:47:12 -0000	1.66
> @@ -522,62 +522,62 @@
>   */
>  
>  struct ff_replay {
> -	uint16_t length; /* Duration of an effect in ms. All other times are also expressed in ms */
> -	uint16_t delay;  /* Time to wait before to start playing an effect */
> +	__u16 length; /* Duration of an effect in ms. All other times are also expressed in ms */
> +	__u16 delay;  /* Time to wait before to start playing an effect */
>  };
>  
> [And so on. Other undos of my earlier change]

-- 
Johann Deneux

Re: [Linuxconsole-commit]CVS: ruby/linux/include/linux input.h,1.65,1.66

[Brad H. <bh...@bi...>]

On Sat, 4 May 2002 08:21, Johann Deneux wrote:
> Rodrigo Damazio wrote:
> > Update of /cvsroot/linuxconsole/ruby/linux/include/linux
> > In directory usw-pr-cvs1:/tmp/cvs-serv2684/linux/include/linux
> >
> > Modified Files:
> > 	input.h
> > Log Message:
> > Fix for the types problem - uint16_t and similars are not exported
> > outside the kernel. They were replaced by __u16 and similars. fftest and
> > other utils should now compile OK.
>
> No, uint16_t is not a kernel specific thing. __u16 is. I prefered it the
> other way.
>
> I switched from __u16 to uint16_t on the advice of Brad Hards. The point
> is that uint16_t is apparently a standard type (C99). __u16 is a
> linux-kernel specific thing (16 bit unsigned integer visible from user
> space).
> The discussion went on on linux-usb, and apparently no agreement was
> reached.
My reference was the Linux Device Drivers book (from O'Reilly, also available 
on-line). Read the chapter on types for more info.

> The point is that input.h should include the header defining uint16_t.
I don't think so. The kernel routines using uint16_t should include the kernel 
header <linux/types.h>, while the userspace routines should use the standard 
header (<stdint.h>).

> I don't really care what we actually use. After all, an unsigned 16 bit
> int remains an unsigned 16 bit int whatever we call it. But we should
> settle this at once and make up our minds.
I only care for not confusing user-space programmers. Why use a non-standard 
type, when a standard one is available?

Brad

Re: [Linuxconsole-commit]CVS: ruby/linux/include/linux input.h,1.65,1.66

[Johann D. <joh...@la...>]

Brad Hards wrote:
> On Sat, 4 May 2002 08:21, Johann Deneux wrote:
> 
>>Rodrigo Damazio wrote:
>>
>>>Update of /cvsroot/linuxconsole/ruby/linux/include/linux
>>>In directory usw-pr-cvs1:/tmp/cvs-serv2684/linux/include/linux
>>>
>>>Modified Files:
>>>	input.h
>>>Log Message:
>>>Fix for the types problem - uint16_t and similars are not exported
>>>outside the kernel. They were replaced by __u16 and similars. fftest and
>>>other utils should now compile OK.
>>>
>>No, uint16_t is not a kernel specific thing. __u16 is. I prefered it the
>>other way.
>>
>>I switched from __u16 to uint16_t on the advice of Brad Hards. The point
>>is that uint16_t is apparently a standard type (C99). __u16 is a
>>linux-kernel specific thing (16 bit unsigned integer visible from user
>>space).
>>The discussion went on on linux-usb, and apparently no agreement was
>>reached.
>>
> My reference was the Linux Device Drivers book (from O'Reilly, also available 
> on-line). Read the chapter on types for more info.

That's actually this chapter that convinced me to change to uint16_t.

> 
> 
>>The point is that input.h should include the header defining uint16_t.
>>
> I don't think so. The kernel routines using uint16_t should include the kernel 
> header <linux/types.h>, while the userspace routines should use the standard 
> header (<stdint.h>).
> 

Perhaps a conditional include would do it ? I personally hate it when 
headers depending on other headers don't handle these dependencies by 
themselves, forcing the user to guess what could be the right thing to 
include in order to use some header.

> 
>>I don't really care what we actually use. After all, an unsigned 16 bit
>>int remains an unsigned 16 bit int whatever we call it. But we should
>>settle this at once and make up our minds.
>>
> I only care for not confusing user-space programmers. Why use a non-standard 
> type, when a standard one is available?
> 
> Brad
> 
> 


-- 
Johann Deneux

Re: [Linuxconsole-commit]CVS: ruby/linux/include/linux input.h,1.65,1.66

[Rodrigo D. <cu...@uo...>]

Johann Deneux wrote:

>>> The point is that input.h should include the header defining uint16_t.
>>>
>> I don't think so. The kernel routines using uint16_t should include 
>> the kernel header <linux/types.h>, while the userspace routines 
>> should use the standard header (<stdint.h>).
>>
>
> Perhaps a conditional include would do it ? I personally hate it when 
> headers depending on other headers don't handle these dependencies by 
> themselves, forcing the user to guess what could be the right thing to 
> include in order to use some header. 

        Me too...I'm not exactly sure what uint16_t would conflict with 
if it were defined outside the kernel, but the fact is that it is only 
defined within kernel code(see asm/types.h)...About being 
kernel-specific, the linux/input.h is kernel-dependant too, so I guess 
maybe it's ok to use __u16??
        How about making it more practical - will everything work if we 
leave __u16?? 'cause non-kernel programs(such as fftest.c) have trouble 
compiling with uint16_t...I don't see a reason not to leave it __u16 if 
it works fine...

Rodrigo

-- 
* Rodrigo Damazio
* cu...@uo.../rod...@po.../rda...@ls...
* ICQ: #3560450         Homepage: http://www.vros.com/cuddly/
* Engenharia da Computação / Laboratório de Sistemas Integráveis(LSI)
* Escola Politécnica - USP - São Paulo

Re: [Linuxconsole-commit]CVS: ruby/linux/include/linux input.h,1.65,1.66

[Johann D. <jo...@do...>]

Rodrigo Damazio wrote:
> Johann Deneux wrote:
> 
>>>> The point is that input.h should include the header defining uint16_t.
>>>>
>>> I don't think so. The kernel routines using uint16_t should include 
>>> the kernel header <linux/types.h>, while the userspace routines 
>>> should use the standard header (<stdint.h>).
>>>
>>
>> Perhaps a conditional include would do it ? I personally hate it when 
>> headers depending on other headers don't handle these dependencies by 
>> themselves, forcing the user to guess what could be the right thing to 
>> include in order to use some header. 
> 
> 
>        Me too...I'm not exactly sure what uint16_t would conflict with 
> if it were defined outside the kernel, but the fact is that it is only 
> defined within kernel code(see asm/types.h)...About being 

No. I think you completely missed the point. uint16_t *is* a standard 
C99 type defined in <stdint.h>. Did you have a look at the chapter 
indicated by Brad about the use of types in Linux drivers ?
See there: http://www.xml.com/ldd/chapter/book/ch10.html

> kernel-specific, the linux/input.h is kernel-dependant too, so I guess 
> maybe it's ok to use __u16??

Sure, it will still work.

>        How about making it more practical - will everything work if we 
> leave __u16?? 'cause non-kernel programs(such as fftest.c) have trouble 
> compiling with uint16_t...I don't see a reason not to leave it __u16 if 
> it works fine...

The argument would be "Why use the kernel-specific standard if there 
already is a C99 standard for this type ?".

The danger would be that a userland developer notices these __u16 types 
and starts using them in other places in his program. Later, he needs an 
unsigned 16-bits int. What type will he use ? He could be mislead into 
using __u16. The problem will arise when he wants to port his software 
to some other OS. __u16 won't be there. uint16_t will.

We could warn people and tell them not to use __u16. A better solution 
is not to show it at all.

Btw, I wonder what were hackers thinking when they decided to use u16 
for kernel-specific values and __u16 for public interfaces. Saying it's 
counter-intuitive is quite an understatement.


-- 
Johann Deneux