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 - 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/