[PATCH] evdev: add phys property (EVIOCGPHYS) as stable identifier

[Peter Hutterer]

On Wed, Apr 28, 2010 at 05:13:10PM +0200, Peter Korsgaard wrote:
> >>>>> "Peter" == Peter Hutterer <peter.hutterer at who-t.net> writes:
> 
> Hi,
> 
>  >> EVIOCGPHYS is evdev specific ofcourse, but I guess we could parse
>  >> the commonOptions and add the device property in
>  >> xf86ProcessCommonOptions().
>  >> 
>  >> Does that sound good to you?
> 
>  Peter> yeah, that's what I had in mind. two-string property, one being
>  Peter> the /dev/input/XXX string, the second one being the Phys (if
>  Peter> available)
> 
> Ok, good.
>  
>  >> Really? That sounds like a bug in valgrind then. EVIOCGPHYS is correctly
>  >> marked as an input ioctl (_IOC(_IOC_READ, 'E', 0x07, len)), so it should
>  >> know that phys contains valid data after the ioctl.
>  >> 
>  >> But I can certainly add the initializer, even though it's unneeded
>  >> bloat.
> 
>  Peter> I'll double-check again, but I saw those warnings this
>  Peter> morning. Don't know which distro and what version of valgrind
>  Peter> though...
> 
> I had a look, and it was a bug in valgrind. I sent them a patch:
> 
> http://thread.gmane.org/gmane.comp.debugging.valgrind.devel/11049
> 
>  Peter> meanwhile, the 6 extra bytes won't make a difference ;)
> 
> Sorry, I'm coming from a kernel/busybox/embedded background, I'm used to
> care about such things ;)
> 
> Why do you expect it to take up 6 bytes? 

two spaces, one = and the {0} (I didn't say the estimate was precise ;)

"bloat" for me is more an issue in code, not so much in the binaries.
Haven't worked with embedded for quite a while, so I didn't do the
comparison you did on the resulting binary.

> I would expect it would have to copy 256 bytes from somewhere to
> initialize unless gcc is clever.
> 
> .. Which it is, it ends up doing a rep stos loop - Which adds something
> like 10-15 bytes.
> 
> I'll add the initializer and resend.

If it's a bug that's being fixed in valgrind, don't worry about it.

Cheers,
  Peter