Consider the following scenario:
We have a modular device driver, let's call it xxxmod. The driver's
xxx_modcmd(MODULE_CMD_INIT, ...) routine handles all of its initialization,
including interaction with autoconf(9). It therefore might attempt to use
an optional module (e.g., zzzverbose) to
Hi all,
I'm looking for comments about what I call device flavours. The best
example of the kind of situation it tries to be an answer for is the
multiplicity of drivers one can find around the source tree for PCI-ISA
bridges (mostly on x86). An even older idea of mine is to finally see
legacy
I'm looking for comments about what I call device flavours. [...]
I'm having trouble seeing what this offers over things (like scsibus)
where an abstraction attaches at real hardware and then other things
attach to the abstraction.
flavour acpiib at pci: acpinodebus
filedev/acpi/acpiib.c
On Mon, 26 Jul 2010, matthew green wrote:
it seems to me the root problem is that module_mutex is held while
calling into the module startup routines.
thus, the right solution is to remove this requirement.
Yes, that's what is needed.
But it sounds a lot simpler than it is.
On Sun, Jul 25, 2010 at 05:54:01PM -0400, der Mouse wrote:
I'm looking for comments about what I call device flavours. [...]
I'm having trouble seeing what this offers over things (like scsibus)
where an abstraction attaches at real hardware and then other things
attach to the abstraction.
On Sun, Jul 25, 2010 at 09:22:53PM +, Quentin Garnier wrote:
bridges (mostly on x86). An even older idea of mine is to finally see
legacy devices listed in the ACPI tables attached to the PCI-ISA bridge
where they logically belong, and device flavours can be used for that,
too.
I am not
On Mon, Jul 26, 2010 at 06:41:11AM +1000, matthew green wrote:
it seems to me the root problem is that module_mutex is held while
calling into the module startup routines.
Here is one related question: is it ensured that the module lock is dropped
immediately after a modular device driver
