On 2/17/2015 8:41 PM, Jake Oshins wrote:
This patch adds some wrapper functions in the pnp layer. The intent is
to allow memory address space claims by devices which are descendants
(a child or grandchild of) a device which is already part of the pnp
layer. This allows a device to make a resource claim that doesn't
conflict with its "aunts" and "uncles."
How is this going to happen?
This is useful in a Hyper-V VM because some paravirtual "devices" need
memory-mapped I/O space, and their aunts and uncles can be PCI devices.
Furthermore, the hypervisor expresses the possible memory address
combinations for the devices in the VM through the ACPI namespace.
The paravirtual devices need to suballocate from the ACPI nodes, and
they need to avoid conflicting with choices that the Linux PCI code
makes about the PCI devices in the VM.
It might seem like this should be done in the platform layer rather
than the pnp layer, but the platform layer assumes that the
configuration of the devices in the machine are static, or at least
expressed by firmware in a static fashion.
I'm not sure if I'm following you here.
Where exactly do we make that assumption?
Yes, some code to support platform device hotplug may be missing, but I'd
very much prefer to add it instead of reviving the dead man walking which is
the PNP subsystem today.
The nature of a Hyper-V
VM is that new devices can be added while the machine is running,
and the potential configurations for them are expressed as part of
the paravirtual communications channel. This much more naturally
aligns with the pnp layer.
That's debatable.
That aside, it would help a lot if you described your design in plain
English
and added some useful kerneldoc comments to the new functions.
Kind regards,
Rafael
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
