On Tue, 16 Apr 2002 07:39, Greg KH wrote: > On Tue, Apr 16, 2002 at 08:00:53AM +1000, Brad Hards wrote: > > On Tue, 16 Apr 2002 02:54, Greg KH wrote: > > > If the structure is going to be exported from the kernel, then __u16 > > > and __u32 should be used, as they are the proper types for this. These > > > types are portable accross all platforms. > > > > They are not portable outside Linux. This is inappropriate in what needs > > to become a _standardised_ interface. > > Standardized across what? Different OS's? I'm not going down the UDI > rathole, been there before with the OpenUSBDI spec, and I don't want to > go back :) Settle down. Right now, the USB Uninterruptable Power Supply people only do Linux, because of Paul's work on hiddev. But applications like apcupsd and NUT are cross platform - they have to be, because this stuff gets deployed in server rooms, and the whole world is not Linux. There are moves to implement a hiddev style interface for the *BSD people. The BSD guys helped us plenty - we shouldn't make their life hard now.
> > My source: > > http://www.xml.com/ldd/chapter/book/ch10.html#t2 > > which states (on the _ _ types ): > > <quote> > > It's important to remember that these types are Linux specific, and using > > them hinders porting software to other Unix flavors. Systems with recent > > compilers will support the C99-standard types, such as uint8_t and > > uint32_t; when possible, those types should be used in favor of the > > Linux-specific variety. </quote> > > To quote 4 paragraphs down from your quote: > If a user-space program needs to use these types, it can prefix > the names with a double underscore: __u8 and the other types are > defined independent of __KERNEL__. Actually, this is directly above the bit that I quoted. So it should be understood that the bit I have quoted is meant to be read as a caution against portability problems associated with the bit that you have quoted. > > I do not disagree that the _t notation is ugly. However it is at least > > standard in availability on modern operating systems, and has unambiguous > > meaning. > > It is not standard in the Linux kernel. What is standard today is '__' > to mark a variable with a type that can be accessed from user space. If > you don't care about userspace, then just use 'u16' and 'u32'. __ is legacy from 2.0 series kernels, that we shouldn't be continuing with, and certainly shouldn't be advocating. Go back and read the guidance again. > > The double underscore notation (which is also pretty ugly) is neither > > standard nor unambiguous. In particular, it is ambiguous because __ on an > > identifier normally means "this is the internal version, you shouldn't > > normally use this". > > No, this is not what "__" means in this connotation. It is used to > prevent collisions in POSIX namespace. See include/asm/types.h for more > info about this. I think that this proves my point about this notation not being unambiguous. User space programmers shouldn't need to know about internal kernel issues. They should reasonably expect to see standard data types. And we should not unreasonably withhold them. > > As Dave pointed out, it would be nice if we could use the "in kernel" u32 > > and s16 stype notation in user spacce. Bute we can't, so using <stdint.h> > > is the next best option. > > We can't use <stdint.h> from kernel space, which is what _I_ care about. Please don't get pedantic. "The types defined in <stdint.h>". Per the C99 _standard_. <linux/types.h> in kernel space. > If you want to provide a version of hiddev.h for userspace only, feel > free to use whatever _t typedefs you want to. Either way, it looks like > we should clean up hiddev.h to use __ style variables. I would be glad > to take a patch to do this. There is no reason to split kernel and userspace (given the possibility of subtle bugs arising from the two files diverging. The current <linux/hiddev.h> can be cleanly converted to use standard integer types, which would be cleanly usable by the *BSD people and by application programmers. Trust me, I won't be rushing to add __crudtype to anything... Brad _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
