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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/