USB devices on boot

[CentralWare]

Scenario:
TCL 4.7 launches using an onboard DOC/DOM or other similar flash drive using IDE or SATA interfaces.  This will be a small flash device (64MB and 128MB expected)
There will be two USB 2.0 ports, one of which is intended to take a USB based flash reader (ie: Micro/SD, USB to IDE/SATA or similar)
The USB device will not have a known UUID or LABEL we can rely on (for waitusb=#:ID=Something)
firmware (3.0.21) is installed

What I need to do is monitor the system for when usb_storage devices are detected (prior to tc-config's functionality kicking in) but I don't know the kernel modules well enough to determine which mod gets loaded for USB mass-storage in order to start a timeout loop.

The anticipated logic is:
1) Scan IDs (blkid) for all detected storage devices
2) Wait for kernel/drivers/something to load by pinging modprobe
3) Determine the boot drive (and remove it from the list in #1 above)
4) Once loaded, start a check loop that uses blkid to see if any new devices were detected.
    IF SO, break the loop, otherwise TIMEOUT would break the loop.

If memory serves, lsusb tells a good story regarding a given device, but I don't remember it giving details as to which driver is being used in order to give those details.  If anyone knows where usb_storage lives within the TC drivers it would be very helpful!

[gerald_clark]

The loadable drivers are in the initrd.
It is not possible to determine the boot drive, as the bootloader that loads the kernel and initrd has no way of passing this information to the kernel.
The best you can do is use a boot option to give a hint you can parse in your startup program.

[curaga]

If you only need to separate SATA/IDE from USB, there's easier ways than timing loops and whatnot.

It's late and I have a hard time coming up with something elegant, but you can tell the two apart with udev.

udevinfo -a -p /sys/block/sda

Look in particular at SUBSYSTEM and the parent devices - those lines will differ for USB and ATA.

[CentralWare]

@gerald: Sadly, I have to scan/mount/check to determine the boot drive, but it's saved to init.d/tc-boot for later reference,
               (ie: [ -f /mnt/test/tce/boot/core.gz ] or what-not) but for the most part, it works for what's needed.
               It opens doors for not being fool-proof (ie: two partitions with core.gz) but odds are against that here.

@curaga: udevinfo (adm info) - I'm going to experiment as it looks promising, especially considering it accepts wildcards (ie: sys/block/sd* )  (Tired or not, it's plenty elaborate enough for me...  thank you for your insight regardless!)  The only catch will be waiting for USB devices to settle, so I may still be sitting in a loop until trigger / --add are finished.

Thanks guys!