> > For that matter, a *driver* should never create its own device node(s) > > in the first place. Device creation belongs elsewhere, like as part of > > platform setup or, for busses with integral enumeration support like > > PCI or USB, bus glue. Linux is moving away from that legacy model. > > This assumes that we have a better bus than "platform" to dump drivers like > thinkpad-acpi, hdaps, and a host of other host-specific stuff.
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.) > > I realize that may be more easily said than done in some cases, > > like i8042 on non-PNP systems. > > Yes, and there is a LOT of non-PNP stuff involved, since platform became the > dumping ground for host-specific devices (as opposed to platform-specific > devices). 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/