Good research!

For now I would like to point out a few lines from the patch propossal you said:

> > Is it thus a kernel-related issued rather than an udev one?
> > Other architectures have it and I am not going to revert this change
> > again, so this will have to be fixed in the kernel.

I understand that there is a kernel-related issue, so there is not still development on it, and well we talked many times about that. :D
So we should fix 'kernel/efikamx' which is the only device involved in the problem, and not should be 'ports/core-arm' the place to do it.

The patch seems ok to me, better than port overlays.
I'll try to explain that:

Since the unique recent ARM device we have are efikamx boxes (capable of running recent software), then the kernel affected in our repos would be 'kernel/efikamx' but that doesn't means that we should work exclusively for ports based on efikamx. So IMHO before adding a port in overlays we should try to reproduce the issues on other devices like qemu-arm could be. All we can say now is that 'hardfp' branches requires to have udev as a part of port overlays because there is no more hardfp devices for now, as you done right in this revision: https://crux-arm.nu/gitweb?p=ports/core-arm.git;a=blob;f=udev/Pkgfile;hb=2.7-hardfp (and also in the exported overlay collection: https://crux-arm.nu/ports/crux-2.7/core-armhf/udev/Pkgfile)

On the other side, we should maintaing both branches (core-arm and core-armhf) synced and homogeneous, and ATM core-arm doesn't have and overlay for udev, and that is due to we have more than 1 device in core-arm, as for example qemu-arm which is not affected by the problem

Anyways I think we could fix that in many ways:

a) edit this ticket and change Category to kernel/efikamx, then we could try to solve problems with efikamx devices and his kernels
b) merge udev overlay from core-armhf to core-arm and wait for upstream efikamx kernel
c) create one overlay per device to fix problems related only to one device and not to all possible devices. In this case we should have as many branches as toolchains being used, I mean that this will result in ports/efikamx ports/efikamx-hardfp or similars

Personally I prefer option a) whenever be possible, but b) would be ok to me too.

Sorry if I missed something or I have not explained my POV very well.

There are more things related. I started researching about the problem and it's directly related to kernel and libc headers.

I made a kernel patch for kernel/efikamx and there are still problems. That's why seems that it can be related to libc headers but here I'm quite lost. I put hands on glibc using kernel headers from 2.6.38 but the problem persist. I'm using a little test file which is provided in one of the threads to test accept4 calls and nothing to do. Always same results with function not implemented.

I marked it as core-arm(hf) problem because the only port affected was udev which need these calls (sys_accept4) but really it's a kernel problem.
I don't know which solution we can take, as I finished in the same state as we were. Same timeout booting with udev175.

About both ports collections core-arm and core-armhf as you said they should be synced. I'll take a look to both collections and remove udev from core-armhf (not sure why it's there because there isn't any change) This means option b) will be a good choice to keep work homogeneous and probably option a) should be selected to put this bug in the right category (this ticket was a remember and a start point to look into udev 175 problem keeping some good resources together)

Thank you very much for your research and report too.

I'll do both tasks a) b) along this morning.

as in our last talks, we finally adopted c) method, so after you removed udev (https://crux-arm.nu/gitweb?p=ports/core-arm.git;a=commit;h=2880346b015cefc0bfc1bf02d3367714c4ade89b) we should create per-device-collection, so the problem affects only to efikamx devices and the version of the kernel shipped with crux-arm

during the installation on efikamx devices the installer stuff should have a PKGDIR containing core packages, and in that place we should put the right udev version per device

anyways there some parallel talks related to this one that we must solve first

oooops

======⇒ ERROR: Footprint mismatch found:
MISSING -rwxr-xr-x root/root lib/udev/ata_id
MISSING -rwxr-xr-x root/root lib/udev/cdrom_id
MISSING -rwxr-xr-x root/root lib/udev/collect
MISSING -rwxr-xr-x root/root lib/udev/create_floppy_devices
MISSING -rwxr-xr-x root/root lib/udev/edd_id
MISSING -rwxr-xr-x root/root lib/udev/firmware
MISSING -rwxr-xr-x root/root lib/udev/input_id
MISSING -rwxr-xr-x root/root lib/udev/path_id
MISSING -rw-r–r– root/root lib/udev/rules.d/50-firmware.rules
MISSING -rw-r–r– root/root lib/udev/rules.d/60-cdrom_id.rules
MISSING -rw-r–r– root/root lib/udev/rules.d/60-floppy.rules
MISSING -rw-r–r– root/root lib/udev/rules.d/60-persistent-v4l.rules
MISSING -rw-r–r– root/root lib/udev/rules.d/61-persistent-storage-edd.rules
MISSING -rwxr-xr-x root/root lib/udev/scsi_id
MISSING -rwxr-xr-x root/root lib/udev/usb_id
MISSING -rwxr-xr-x root/root lib/udev/v4l_id
MISSING -rw-r–r– root/root usr/man/man8/scsi_id.8.gz
======⇒ ERROR: Building '/usr/ports/efikamx/udev/udev#167-1.pkg.tar.gz' failed.

– Packages where update failed
udev