On Mon, Aug 1, 2016 at 1:57 PM, Linda Knippers <[email protected]> wrote: >> What's missing in here is a) the glue code to drivers/acpi/nfit.c and b) the >> implementations of HPE1 DSMs. >> >> Once I have these two I'll post a RFC patch series to the ML, but in the >> meanwhile I'm already open to comments. >> >> The glue code to nfit will be a bus so we have all the nice and shiny >> .probe() >> .remove() .uevent() and what not. > > There are some things I like about this approach. What I like most is > that it add modularity. I think that when the ACPI tables for NVDIMM > devices were designed, the idea was that you could have different types > of NVDIMMs with different capabilities and management requirements, and > have generic as well as device-specific software. Section 9.20.5 > describes the different fields that might be used to distinguish the > hardware and load device or vendor-specific drivers. We don't have > flexibility in the current code. Perhaps it makes sense to evolve our > current code base to one where the root functions are in the Generic NVDIMM > management driver and we have vendor-specific management drivers for the > non-root device DSMs. I don't know if we need that for the other driver > types but management is becoming more complicated without them.
I don't think that is quite what Johannes is proposing. This isn't a management model per-vendor, this is a scheme to have the kernel present unified management model across vendors and minimize the surface area of the userspace ABI as much as possible. _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
