On 8/11/2017 12:48 PM, Dan Williams wrote:
On Fri, Aug 11, 2017 at 6:36 AM, Linda Knippers <linda.knipp...@hpe.com> wrote:


On 8/10/2017 10:27 PM, Dan Williams wrote:

On Thu, Aug 10, 2017 at 7:12 PM, Jerry Hoemann <jerry.hoem...@hpe.com>
wrote:

On Thu, Aug 10, 2017 at 05:47:10PM -0700, Dan Williams wrote:

On Thu, Aug 10, 2017 at 5:00 PM, Jerry Hoemann <jerry.hoem...@hpe.com>
wrote:

Add structure definitions newly published/modified in v0.85:


https://github.com/HewlettPackard/hpe-nvm/blob/master/Documentation/NFIT_DSM_DDR4_NVDIMM-N_v85.pdf


Are there going to be follow-on patches that make use of these
definitions? I would save this update for when those follow-on patches
are ready.


There are multiple projects both inside and outside of HPE that need to
make DSM calls.

The DSM ioctl is an interface exported to user applications.  Customers
and vendors can and will use this interface for their own tools and this
use need not result in patches sent back to the ndctl project.


My hope was that the existing extra definitions in ndctl-hpe1.h would
gain some users at some point in the future,


It hasn't been easy to add things to ndctl but we would like to add more.
Otherwise we'll have to create yet another tool.

Understood. The goal I've had with ndctl is to be vendor agnostic out
of the gate. The trajectory of vendor tools is that each vendor
releases their own special sauce and sometime later someone who is
tired of dealing with that differentiation writes a library to undo
it, like system-storage-manager or smartmontools, and provide a
unified interface. If you need to do truly vendor specific things that
probably needs a new tool, but if there's any commonality for a
feature across vendors then I think we should look to add a common
ndctl front-end for it. For example, I'm looking to add a firmware
update mechanism that provides a framework to hide all the "if (vendor
== X)" details behind the libndctl api.

but there's otherwise no
need to add dead code to ndctl-hpe1.h. That header is only used at
compile time it's not shipped so it doesn't provide any benefit to
those third party applications that you mention.


We've thought about shipping this include file.  I think there's
a library or developer package for ndctl?

It does have a devel package for users to write against the libndctl.h
api. There's also general if 'platform == NFIT' vs 'platform == e820'
differentiation. What it doesn't have is any api that externally
presents a vendor specific interface.

I don't think we actually need a vendor-specific interface.  We just
need an easy/common way to pass through the commands.  That's why it
seemed natural to add the new DSM structure definitions to the ones
that are already there.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Reply via email to