Davids/Chris et al

Just had a major breakthrough with udev (ver 096) using inotify. It needs a 
bit more work to make the ipkg and check that it performs of course but the 
showstopper is removed.

The problem was a right bas^&d to find and needed some sleuthing to tease 
out the problem. But thank goodness for open source ....

Nick
cc Balloonboard in case others have similar problems.

<TechhieBit> ........... interesting for those that are interested

The problem was centred around calling system function sys_inotify_init 
(syscall number 316) from the udevd daemon in userspace.

When udevd was calling it the reply was -ENOSYS ie not available. This was 
unexpected as inotify was built into the kernel.

Close scrutiny of the 2.6.16.5-tcl1 kernel showed that not only did it 
exist but it was also present in the main system table available to user 
space via syscall (not necessarily the same thing) as opposed to its entry 
being filled by pointing to the default "not available" function.

I trapped the "not available" function and showed that it was indeed being 
called - as opposed to some other bit of the chain returning -ENOSYS to 
deliberately fool me.

Using strace I saw that syscall(316) seemed to be instead reported as being 
vm86old(316). Wah! vm86old is an x86 call and nothing to do with arm. After 
several hours of messing about it turns out to be an strace bug. Using a 
newer version of strace changed the legend to syscall(316) - grrr, timewaste.

Was this libc/udev being a pain I wondered? Close scrutiny of the 
relationship between libc and udevd showed that if the syscall for 
sys_inotify_init wasn't declared in the standard headers then it was 
defined by udev_libc_wrapper.h as 316 (but only for arm - bewilderingly it 
varies from processor to processor). This was as expected so was parked as 
being the problem till revisited.

Now, the OLD kernel headers used in stable Debian do not declare 
sys_inotify_init so it is set to 316 by the wrapper but the NEWER headers 
in testing Debian DO include it so it is left to the definition in asm/unistd.h

Here is the important bit. The Debian stable unistd.h starts with syscalls 
at offset 0x900000 unless one is arm-thumb. The Debian testing unistd.h 
does the same unless either arm-thumb or EABI. The udev_libc_wrapper didn't 
take account of that and seems to either assume EABI or is just broken.

That was the problem, using syscall(0x900000+316) and now all is well if 
untested.

</TecchieBit>

Nick