On Mon, Mar 07, 2011 at 01:01:35PM -0800, K. Y. Srinivasan wrote: > Hyper-V has maintained both its class independent driver and > device state in two independent data structures: > Driver state: struct driver_context (vmbus.h) and struct hv_driver > (vmbus_api.h) > Device state: struct vm_device (vmbus.h) and struct hv_device (vmbus_api.h) > > While sruct driver_context and struct vm_device embed generic > Linux abstractions of struct device_driver and struct device respectively; > the lower level hyperv abstraction: struct hv_driver and struct hv_device > have maintained state needed to communicate with the host. This partitioning > made sense at a point in time when it was not clear how much of > the hypervisor interaction would be open sourced. Given where we are > today, there is no reason to keep this layering. This patchset > consolidates all the driver state into a single structure: > struct hv_driver while all the device state is consolidated into > a single structure: struct hv_device. This consolidation simplifies > the code while simultaneously getting rid of redundant state - > for instance in the current code, both struct driver_context and > struct hv_driver both have state to represent the class as well as > instance id. We do this consolidation by moving state from higher > level structures (struct driver_context and struct vm_device) to > lower level structures (struct hv_driver and hv_device) respectively. > > While it has not been a goal of this effort to cleanup structure and > variable names, this consolidation effort has resulted in some cleanup > with regards to structure and variable names: a) Some of the badly > named structures have been eliminated (struct driver_context etc.) > while hopefully all newly introduced names are acceptable. > > Patches 1 through 11 deal with consolidating the device driver > state while patches 12 through 16 deal with consolidating > device state. Very nice job, now that's the way to break up and send a patch series. I've queued them all up now. I'm guessing that you will have follow-on patches now to complete the migration to the correct driver core use (i.e. proper driver and device usage?) Or do you want me to look into doing this? thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
