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
(text/plain)