On Thu, Jan 16, 2020 at 10:09:46AM -0800, Dan Williams wrote: > On Wed, Jan 15, 2020 at 1:08 PM Jeff Moyer <jmoyer@xxxxxxxxxx> wrote: > > > > Hi, Dan, > > > > Dan Williams <dan.j.williams@xxxxxxxxx> writes: > > > > > I'm going to take a look at how hard it would be to develop a kpartx > > > fallback in udev. If that can live across the driver transition then > > > maybe this can be a non-event for end users that already have that > > > udev update deployed. > > > > I just wanted to remind you that label-less dimms still exist, and are > > still being shipped. For those devices, the only way to subdivide the > > storage is via partitioning. > > True, but if kpartx + udev can make this transparent then I don't > think users lose any functionality. They just gain a device-mapper > dependency. Hi Dan, Are you planning to look into making this work? We can easily disable partition scanning by specifying gendisk GENHD_FL_NO_PART_SCAN flag. But what about partition additiona path, ioctl(BLKPG_ADD_PARTITION). That does not seem to do any checks whether block device supports in kernel partitions or not. So kernel partitions (hence /dev/pmemXpY) objects are created anyway and this will conflict with all the new planned udev rules. If you block ioctl(BLKPG_ADD_PARTITION), then user space tools like parted and fdisk started breaking when trying to create a partition on /dev/pmeme0. IIUC, we have to allow partition table creation on /dev/pmem0 so that later kpartx can parse it and create dm-linear partitions. Thanks Vivek
