Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

[Oliver]

On Thu, Jul 6, 2017 at 12:11 PM, hch@xxxxxx <hch@xxxxxx> wrote:
> On Wed, Jul 05, 2017 at 07:08:54PM -0700, Dan Williams wrote:
>> [ adding Jeff, and Johannes ]
>>
>> On Wed, Jul 5, 2017 at 6:17 PM, Kani, Toshimitsu <toshi.kani@xxxxxxx> wrote:
>> > On Wed, 2017-07-05 at 17:07 -0700, Dan Williams wrote:
>> [..]
>> >> We have symlinks in /dev/disk/by* to make it easier to identify
>> >> storage devices, I think it makes sense to add udev rules for
>> >> identifying volatile pmem and not try to differentiate this in the
>> >> default kernel device name.
>> >
>> > I am not sure what might be a good way, but I am concerned because a
>> > single block device naming do not represent both volatile and
>> > persistent media today.
>>
>> We do have time to changes this if we find out this is critical. Maybe
>> it's best to ask Linux distro folks what would be easier for them?
>
> I'm not really concerned about it, because SCSI devices for example
> might not be persistent as well with Ñcsi_debug, target_core_rd or
> volatile qemu devices.
>
> That being said I really don't understand the purpose of these volatile
> nfit ranges.  Are they seen in the wild?  If yes what's the use case?
> If not why do we even need to support them?

The main use case is provisioning install media for bare metal
servers. Traditionally that's been handled by having the BMC emulate a
USB CD drive. Unfortunately, most BMCs have limited CPU, limited
memory and a wet-string network connection so a host based alternative
is nice to have.