I'm having a hard time figuring out a good way to solve this problem. I have two SBCs running Buildroot Linux that are almost completely identical except for a USB ACM card that I am trying to detect at startup and loadup services dynamically based on what SBC it is (so for example, have a script "touch sbc1" if card is detected or "touch sbc2" if it is not and then use this file to load up different configurations for the network).
I am using a static dev table, Busybox init, and the 3.12.20 kernel (with which USB CDC is compiled in as a built-in driver; I disabled modules). Here is the problem: I write a script (S00setup, so it is the first script in rcS that should run; this script MUST run before the network script) to check for the presence of this card. It seems the CDC ACM driver loads on both boards regardless if it is there or not so that check does not work (buffer always says usbcore: registered new interface driver cdc_acm followed by cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters). Also, my dmesg output cuts out at about 2 seconds calling it from the script and it is only after that that it will actually assign /dev/ttyACM0 to the device. How do I force the kernel to finish booting before processing this init file so I can properly detect it? Would a "sleep" here work? If not, then what? Is there some type of DoEvents() for Bash/Linux? It is the same case with detecting the card with lsusb in that the device will not show up until after the scripts are processed, which doesn't make sense to me. So to ask a similar question, I guess another way for this to work is to force poll USB devices; is there anyway at all to do that?
I posted this question here instead of Unix&Linux since you guys here seem to be more experienced with this and in case there was any quick program I can write to force the kernel to finish processing. I am only missing an additional 1-2 seconds of the kernel buffer when it actually assigns devices to ttys and whatnot. This is the output I need to differentiate the two boards. Obviously, the reason I am doing this is because I want to use the same OS image on both systems; for configuration management purposes, it is much easier this way.