linuxconsole-dev

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Pavel M. <pa...@el...>]

Hi!

> > > > ICBW, but wasn't uint<n>_t only promised to be at least <n> bits?
> 
> As the matter of fact, IHBW.

pavel@Elf:~$ wtf ICBW
Gee...  I don't know what ICBW means...
pavel@Elf:~$ wtf IHBW
Gee...  I don't know what IHBW means...
pavel@Elf:~$
 
Would you care to submit patch for wtf(6)? ;-)
								Pavel
-- 
I'm pa...@uc.... "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at di...@li...

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Linus T. <tor...@tr...>]

On Wed, 31 Jul 2002, Brad Hards wrote:
>
> Here is an extract from <linux/types.h>
> typedef         __u8            uint8_t;
> typedef         __u16           uint16_t;

Yes, and the thing you snipped from it was that it's inside a #ifdef.

Now, that #ifdef will be on for the __KERNEL__, but somebody else might
have compiled with some -traditional switch or other that disabled
"uint8_t" or just screwed it up some other way.

> > ICBW, but wasn't uint<n>_t only promised to be at least <n> bits?
> I am not sure I understand the point you are trying to make.

I think the point Viro is making is that uint8_t actually exists on things 
like old cray's too, even if end sup being a 64-bit entity.

I don't think that is correct, though. I think that comes from another
(proposed but not implemented) C language extension that would have
allowed something like that, namely the

	int X:17;

syntax, where X would be guaranteed to be "17 bits or more". I don't 
remember.

		Linus

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Vojtech P. <vo...@su...>]

On Wed, Jul 31, 2002 at 07:26:05AM +1000, Brad Hards wrote:
> On Wed, 31 Jul 2002 07:09, Greg KH wrote:
> > On Tue, Jul 30, 2002 at 03:23:42PM +0200, Vojtech Pavlik wrote:
> > > -#include <asm/types.h>
> > > +#include <stdint.h>
> >
> > Why?  I thought we were not including any glibc (or any other libc)
> > header files when building the kernel?
> Should be <linux/types.h>

It's #ifndef __KERNEL__ and if we #include <linux/types.h> and the user
#includes <stdint.h> elsewhere, we're going to get collisions.

I guess __u16 is really the safe way here.

> > > -	__u16 bustype;
> > > -	__u16 vendor;
> > > -	__u16 product;
> > > -	__u16 version;
> > > +	uint16_t bustype;
> > > +	uint16_t vendor;
> > > +	uint16_t product;
> > > +	uint16_t version;
> >
> > {sigh}  __u16 is _so_ much nicer, and tells the programmer, "Yes I know
> > this variable needs to be the same size in userspace and in
> > kernelspace."
> I'll harp some more.
> 1. __u16 isn't really any nicer - its just what you (as a kernel programmer) are used to.
> 2. uint16_t is a *standard* type. Userspace programmer know it, even if they don't know Linux. 
> 
> We shouldn't arbitrarily invent new types that could be trivially done with 
> standard types. Maybe we could retain existing usage for ABIs that are
> unchanged from 2.0 days, but we certainly shouldn't be making the ABI
> any worse.

-- 
Vojtech Pavlik
SuSE Labs

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Jeff G. <jg...@ma...>]

Greg KH wrote:
> On Tue, Jul 30, 2002 at 03:23:42PM +0200, Vojtech Pavlik wrote:
>>-	__u16 bustype;
>>-	__u16 vendor;
>>-	__u16 product;
>>-	__u16 version;
>>+	uint16_t bustype;
>>+	uint16_t vendor;
>>+	uint16_t product;
>>+	uint16_t version;
> 
> 
> {sigh}  __u16 is _so_ much nicer, and tells the programmer, "Yes I know
> this variable needs to be the same size in userspace and in
> kernelspace."


Agreed, but u16 is even better :)  Why use the '__' prefix when standard 
kernel types do not need them?

	Jeff

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Linus T. <tor...@tr...>]

On Tue, 30 Jul 2002, Jeff Garzik wrote:
> 
> Agreed, but u16 is even better :)  Why use the '__' prefix when standard 
> kernel types do not need them?

The __ thing is actually fairly useful, for a few reasons

 - "u16" is namespace pollution and mustn't be exported by standard 
   user-level header files, since a program might use it as a variable 
   name.

 - it shows which things are purely krnel internal (u16 is 
   kernel-internal, but a structure with __u16 is in a structure exported
   to user space. Of course, some people seem to think that you should 
   always use the __u16 form, which is wrong. The underscores have
   meaning, and the meaning is exactly that: exported to user space
   headers as a size)

 - typedef's are nasty, in that you cannot mix them. With a #define, you 
   can just have

	#ifndef NULL
	#define NULL ((void *)0)
	#endif

   and if everybody follows that convention, duplicating a few #defines 
   isn't a problem.

   The same is _not_ true of typedefs. With typedefs, there can be only 
   one, and trying to avoid duplication with magic preprocessor rules 
   easily gets nasty. Sure, you can make up a rule like

	#ifndef __typedef_xxxx_t
	typedef ... xxxx_t;
	#endif

   but it's nowhere near as convenient as for #defines, and there is no 
   standard for this.

   This nastiness is why everybody (including things like glibc) ends up 
   having to have an internal type and an external type anyway. Have you
   ever wondered by the glibc header files internally use things like
   __off_t, __locale_t etc? This is why. To avoid duplicate defines, 
   especially in the presense of complex #ifdef __BSD_SOURCE__ etc, the 
   internal type is defined unconditionally. The externally visible type 
   is only defined if it should be.

See the crap in <linux/types.h> on how the linux headers define things
like u_int8_t int8_t uint8_t depending on different #defines. Which is why 
it is so convenient to have _one_true_ internal type (__u8) which you can 
always depend on, regardless of who compiles you and with what options. 

All the other types (inluding the "standard" uint8_t) simply cannot be 
depended on. 

		Linus