* Re: Event API changes - EVIOCGID [not found] ` <200207281745.37751.bhards@bigpond.net.au> @ 2002-07-28 8:22 ` Vojtech Pavlik 2002-07-28 8:42 ` Brad Hards 0 siblings, 1 reply; 4+ messages in thread From: Vojtech Pavlik @ 2002-07-28 8:22 UTC (permalink / raw) To: Brad Hards; +Cc: Vojtech Pavlik, linuxconsole-dev, linux-kernel On Sun, Jul 28, 2002 at 05:45:37PM +1000, Brad Hards wrote: > On Tue, 23 Jul 2002 02:04, Vojtech Pavlik wrote: > > On Sun, Jul 21, 2002 at 08:50:56PM +1000, Brad Hards wrote: > > > G'day, > > > > > > The attached patch basically implements: > > > +struct input_devinfo { > > > + uint16_t bustype; > > > + uint16_t vendor; > > > + uint16_t product; > > > + uint16_t version; > > > +}; > > > + > > > > > > -#define EVIOCGID _IOR('E', 0x02, short[4]) > > > /* get device ID */ +#define EVIOCGID _IOR('E', 0x02, > > > struct input_devinfo) /* get device ID */ > > > > > > It affects just about every input driver, as a result of some associated > > > cleanups that I applied, and its about 40K uncompressed - hence the gzip. > > > > > > Is there anything that would stop this being applied? > > > > No, the patch is OK. > I am not happy about the change from uint16_t to __u16, which you appear > to have made before sending this to Linus. > > That is a broken change - there is a standard type, and you've changed > it to a non-standard type. This is confusing to userspace programmers, and > I cannot provide a satisfactory explaination for this in documentation. > > Please change it back. Well, I know this has been discussed back and forth. __u16 is a kernel type and is defined if you #include <linux/input.h>. uint16_t isn't. __u* is used extensively in the input API anyway, so you'd have to explain it to userspace programmers nevertheless. So I prefer keeping the input.h include use just one type of explicit sized types. Sure, we can change them all to uint*_t, but then do it all at once and provide a satisfactory explanation for it. ;) -- Vojtech Pavlik SuSE Labs ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Event API changes - EVIOCGID 2002-07-28 8:22 ` Event API changes - EVIOCGID Vojtech Pavlik @ 2002-07-28 8:42 ` Brad Hards 2002-07-28 8:50 ` Vojtech Pavlik 2002-07-28 10:38 ` Johann Deneux 0 siblings, 2 replies; 4+ messages in thread From: Brad Hards @ 2002-07-28 8:42 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: linuxconsole-dev, linux-kernel On Sun, 28 Jul 2002 18:22, Vojtech Pavlik wrote: > On Sun, Jul 28, 2002 at 05:45:37PM +1000, Brad Hards wrote: <snip> > > I am not happy about the change from uint16_t to __u16, which you appear > > to have made before sending this to Linus. > > > > That is a broken change - there is a standard type, and you've changed > > it to a non-standard type. This is confusing to userspace programmers, > > and I cannot provide a satisfactory explaination for this in > > documentation. > > > > Please change it back. > > Well, I know this has been discussed back and forth. And I was right last time too :-) > __u16 is a kernel type and is defined if you #include <linux/input.h>. > uint16_t isn't. __u16 is no more a kernel type than uint16_t. It is a one line fix: include <linux/types.h> instead of <asm/types.h> Which you probably should be doing anyway, since there is no reason to rely on any assembler types in <linux/input.h> > __u* is used extensively in the input API anyway, so you'd have to > explain it to userspace programmers nevertheless. So I prefer keeping > the input.h include use just one type of explicit sized types. So do I, and it had better be a standard type. Note that the input API does *NOT* use __u* extensively. In fact if you take out the force feedback stuff (which Johannes already agreed to change:), this is the *only* _u* usage in any part of the input API. > Sure, we can change them all to uint*_t, but then do it all at once and > provide a satisfactory explanation for it. ;) I am doing it all. Johannes agreed to the change, and I did the only other required entry. If Johannes agrees, I'll do the trivial changes for force-feedback. The reason why I am not doing it all at once is to provide patches that do one API change at a time. Or, depending on how you look at it, I did the only change all-at-once, and you reverted it :) Brad -- http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Event API changes - EVIOCGID 2002-07-28 8:42 ` Brad Hards @ 2002-07-28 8:50 ` Vojtech Pavlik 2002-07-28 10:38 ` Johann Deneux 1 sibling, 0 replies; 4+ messages in thread From: Vojtech Pavlik @ 2002-07-28 8:50 UTC (permalink / raw) To: Brad Hards; +Cc: Vojtech Pavlik, linuxconsole-dev, linux-kernel On Sun, Jul 28, 2002 at 06:42:18PM +1000, Brad Hards wrote: > > > I am not happy about the change from uint16_t to __u16, which you appear > > > to have made before sending this to Linus. > > > > > > That is a broken change - there is a standard type, and you've changed > > > it to a non-standard type. This is confusing to userspace programmers, > > > and I cannot provide a satisfactory explaination for this in > > > documentation. > > > > > > Please change it back. > > > > Well, I know this has been discussed back and forth. > And I was right last time too :-) > > > __u16 is a kernel type and is defined if you #include <linux/input.h>. > > uint16_t isn't. > __u16 is no more a kernel type than uint16_t. > It is a one line fix: include <linux/types.h> instead of <asm/types.h> > Which you probably should be doing anyway, since there is no > reason to rely on any assembler types in <linux/input.h> > > > __u* is used extensively in the input API anyway, so you'd have to > > explain it to userspace programmers nevertheless. So I prefer keeping > > the input.h include use just one type of explicit sized types. > So do I, and it had better be a standard type. > > Note that the input API does *NOT* use __u* extensively. In fact > if you take out the force feedback stuff (which Johannes already > agreed to change:), this is the *only* _u* usage in any part of the > input API. > > > Sure, we can change them all to uint*_t, but then do it all at once and > > provide a satisfactory explanation for it. ;) > I am doing it all. Johannes agreed to the change, and I did the only > other required entry. If Johannes agrees, I'll do the trivial changes > for force-feedback. Please do then. Together with the change of <asm/types.h> to <linux/types.h>. I hope it doesn't conflict if the user also #includes "stdint.h" in the userspace program, though. > The reason why I am not doing it all at once is to provide patches > that do one API change at a time. Or, depending on how you look > at it, I did the only change all-at-once, and you reverted it :) -- Vojtech Pavlik SuSE Labs ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Event API changes - EVIOCGID 2002-07-28 8:42 ` Brad Hards 2002-07-28 8:50 ` Vojtech Pavlik @ 2002-07-28 10:38 ` Johann Deneux 1 sibling, 0 replies; 4+ messages in thread From: Johann Deneux @ 2002-07-28 10:38 UTC (permalink / raw) To: Brad Hards; +Cc: Vojtech Pavlik, linuxconsole-dev, linux-kernel Brad Hards wrote: > On Sun, 28 Jul 2002 18:22, Vojtech Pavlik wrote: > > [...] > >>__u* is used extensively in the input API anyway, so you'd have to >>explain it to userspace programmers nevertheless. So I prefer keeping >>the input.h include use just one type of explicit sized types. > > So do I, and it had better be a standard type. > > Note that the input API does *NOT* use __u* extensively. In fact > if you take out the force feedback stuff (which Johannes already (Just a detail: my name is Johann) > agreed to change:), this is the *only* _u* usage in any part of the > input API. > I did this change in the past, but it was undone (not by me), as it would break user-space applications. I definitely agree to use uint16_t. > >>Sure, we can change them all to uint*_t, but then do it all at once and >>provide a satisfactory explanation for it. ;) > > I am doing it all. Johannes agreed to the change, and I did the only > other required entry. If Johannes agrees, I'll do the trivial changes > for force-feedback. Ok with me. > The reason why I am not doing it all at once is to provide patches > that do one API change at a time. Or, depending on how you look > at it, I did the only change all-at-once, and you reverted it :) > > Brad > -- Johann Deneux ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-07-28 11:27 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200207212050.56616.bhards@bigpond.net.au>
[not found] ` <20020722180431.A18282@ucw.cz>
[not found] ` <200207281745.37751.bhards@bigpond.net.au>
2002-07-28 8:22 ` Event API changes - EVIOCGID Vojtech Pavlik
2002-07-28 8:42 ` Brad Hards
2002-07-28 8:50 ` Vojtech Pavlik
2002-07-28 10:38 ` Johann Deneux
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox