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
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
