On 06-07-25 08:56 +0100, Nick Bane wrote:
> 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.

Well done that man.
 
> 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.

Aha - now you've explained this, I know what it's about. Sorry not to
spot it in advance. The syscall convention has changed in the arm kernel
from v2.6.16. This change is happening at the same time as the change
to EABI on the principle that if we are going to break everything,
then now is the time to do it. The two changes are actually
inependent, but tend to be considered together so people use old
systcalls with old ABI and new syscalls with new ABI.

This explains it:
http://wiki.debian.org/ArmEabiPort (see System Call Interface).

Is the problem that your tolchain was looking at the wrong headers
(mismatched version of linux-kernel-headers-arm-cross and kernel
source, or is there actually something wrong with the udev code that
needs fixing in debian?)


Wookey
-- 
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK  Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/                 play: http://wookware.org/