Arnd Bergmann wrote: > I think drivers/misc is not the right place for this, but I'm not completely > sure what is. drivers/firmware would be better at least, but virt/fsl might > also be ok. I don't think it's correct to think of a hypervisor as firmware, so I don't think drivers/firmware is better. I'm not sure that creating virt/fsl and putting the driver in there is a good idea, because it will be the only driver in that directory. Unlike KVM, this driver is just a collection of front-ends to our hypervisor API. The actual hypervisor is completely separate. That's why I put it in drivers/misc, because it's just a single driver with a miscellaneous collection of interfaces. We also don't want to have any Kconfig options that "turn on" hypervisor support. I've intentionally made support for the hypervisor part of the normal platform code, and the device tree is used to determine whether that code is active or not. So virt/fsl seems like overkill to me. > I'm not convinced that an ioctl interface is the right way to work with > device tree properties. A more natural way would be to export it as > a file system, or maybe as a flattened device tree blob (the latter option > would require changing the hypervisor interface, which might not be > possible). As Scott said, this is just a front-end to the hypervisor API, and we already have applications that depend on the ioctl interface. Considering that this driver is specific to the Freescale hypervisor, so I don't see any harm in using ioctls. > For an ioctl, please follow the normal pattern of defining a separate > structure for each case, no union. Ok. This will break our existing applications, but it's a minor fix. -- Timur Tabi Linux kernel developer at Freescale -- To unsubscribe from this list: send the line "unsubscribe linux-console" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
