On 8/1/2016 6:31 PM, Dan Williams wrote:
On Mon, Aug 1, 2016 at 1:57 PM, Linda Knippers
>> 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.
I don't think having multiple modules means there have to be multiple
management models, it just allows for multiple management implementations.
ACPI is all about abstracting differences. The userspace ABI could be
more generic where the hardware-specific module is responsible for doing
the right thing for that piece of hardware to make it happen, whether
it's getting health information or creating a namespace. Right now we
have multiple userspace ABIs because the DSMs are exposed directly and
except for the root device, there is no standard.