On Thu, Jan 18, 2018 at 11:51 AM, David Hildenbrand <david@xxxxxxxxxx> wrote: > >>> 1] Existing pmem driver & virtio for region discovery: >>> ----------------------------------------------------- >>> Use existing pmem driver which is tightly coupled with concepts of namespaces, labels etc >>> from ACPI region discovery and re-implement these concepts with virtio so that existing >>> pmem driver can understand it. In addition to this, task of pmem driver to send flush command >>> using virtio. >> >> It's not tightly coupled. The whole point of libnvdimm is to be >> agnostic to ACPI, e820 or any other range discovery. The only work to >> do beyond identifying the address range is teaching libnvdimm to pass >> along a flush control interface to the pmem driver. >> >>> >>> 2] Existing pmem driver & ACPI NFIT for region discovery: >>> ---------------------------------------------------------------- >>> - If we use NFIT ACPI, we need to teach existing ACPI driver to add this new memory >>> type and teach existing pmem driver to handle this new memory type. Still we need >>> an asynchronous(virtio) way to send flush commands. We need virtio device/driver >>> or arbitrary key/value like pair just to send commands from guest to host using virtio. >>> >>> 3] New Virtio pmem driver & paravirt device: >>> ---------------------------------------- >>> Third way is new virtio pmem driver with less work to support existing features of different protocols, >>> and with asynchronous way of sending flush commands. >>> >>> But this needs to duplicate some of the work which existing pmem driver does but as discussed >>> previously we can separate common code from existing pmem driver and reuse it. >>> >>> Among these approaches I also prefer 3]. >> >> I disagree, the reason we went down this ACPI path was to limit the >> needless duplication of most of the pmem driver. >> > > I have way to little insight to make qualified statements to different > approaches here. :) > > All I am interesting in is making this as independent of architecture > specific technologies (e.g. ACPI) as possible. We will want this e.g. > for s390x too. Rather sooner than later. So trying to couple this > (somehow) to ACPI just for the sake of less code to copy will not pay of > in the long run. > > Better have a clean virtio interface / design right from the start. > > So I hope my words will be heard :) I think that's reasonable. Once we have the virtio based discovery I think the incremental changes to libnvdimm core and the pmem driver are small.
