lkml.org 
[lkml]   [2013]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFC Block Layer Extensions to Support NV-DIMMs
On Thu, Sep 05, 2013 at 08:12:05AM -0400, Jeff Moyer wrote:
> If the memory is available to be mapped into the address space of the
> kernel or a user process, then I don't see why we should have a block
> device at all. I think it would make more sense to have a different
> driver class for these persistent memory devices.

We already have at least two block devices in the tree that provide
this kind of functionality (arch/powerpc/sysdev/axonram.c and
drivers/s390/block/dcssblk.c). Looking at how they're written, it
seems like implementing either of them as a block device on top of a
character device that extended their functionality in the direction we
want would be a pretty major bloating factor for no real benefit (not
even a particularly cleaner architecture).

> > Different applications, filesystem and drivers may wish to share
> > ranges of PMEM. This is analogous to partitioning a disk that is
> > using multiple and different filesystems. Since PMEM is addressed
> > on a byte basis rather than a block basis the existing partitioning
> > model does not fit well. As a result there needs to be a way to
> > describe PMEM ranges.
> >
> > struct pmem_layout *(*getpmem)(struct block_device *bdev);
>
> If existing partitioning doesn't work well, then it sounds like a block
> device isn't the right fit (again). Ignoring that detail, what about
> requesting and releasing ranges of persistent memory, as in your
> "partitioning" example? Would that not also be a function of the
> driver?

"existing partitioning" doesn't even work well for existing drives!
Nobody actually builds a drive with fixed C/H/S any more.


\
 
 \ /
  Last update: 2013-09-05 19:21    [W:0.881 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site