> > For that matter, a *driver* should never create its own device node(s)
I don't follow. If it's host-specific, then it's easy enough to
have a host-specific routine creating those platform devices.
A different host wouldn't call that routine.
Embedded Linux platforms do that *ALL* the time. ARM keys on a
board ID provided early in boot (e.g. by U-Boot). PowerPC uses
a device tree, which ISTR evolved from the OpenBoot as first used
on SPARC. Worst comes to worst, the kernel command line can say
which board is involved, and thus which setup code to run.
(Also, note that "platform", "host", and "board" are ambiguous.
In some contexts each is synonymous; in others, not. I avoid
using "host" except in the protocol sense. Usually "board" is
pretty specific -- this cpu, those peripherals -- although it
gets messy when the system is really a board stack, or when the
CPU may be socketed or be in a customizable FPGA etc.)
See above ... most embedded systems aren't x86, so lack of PNP is
less of an issue than plain old legacy system designs -- designed
in ways that complicate or prevent probe/discovery schemes, which
gets to be a mess (like the one preceding PNP with DOS/x86/ISA).
Less clear cases include orphaned drivers, especially ones for
hardware that's on its way out or already obsolete. Most folk
don't want to touch those, for fear of getting stuck to them. :)
- Dave
-
