Hi busybox folks! I have discovered a situation on a particularly slow device where the system's init (openrc) is starting busybox acpid BEFORE the kernel is done loading modules for devices. This results in a race between my input device initializing (and creating itself in /dev/input/eventN) and acpid... acpid loses every time because it starts first. This 'issue' also comes about if I plug in a new device that I want to be handled by acpid *after* acpid has been started.. acpid will not pick up and monitor the new device.
After reviewing the source code for acpid, it looks like it doesn't do any checking of *new* devices in /dev/input/eventN once the main loop has started. I've considered submitting a patch that basically places the device detection loop inside the main polling loop, so new devices are checked for and enumerated continuously, but this seems hackish. I would like to get an opinion on how to proceed here... should I implement this solution I have just described and submit a patch, should I file a bugzilla and report this as an 'issue', or should I just go away because this is intended behavior for some reason? Thank you! Clayton
signature.asc
Description: PGP signature
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
