On 08/26/2014 11:34 PM, Ross Zwisler wrote: > On Tue, 2014-08-26 at 20:36 +0300, Boaz Harrosh wrote: >> Meanwhile without any explanations, these will come tomorrow, I'm attaching >> the most interesting bit which you have not seen before. >> >> If you want you can inspect a preview of what's to come here: >> http://git.open-osd.org/gitweb.cgi?p=pmem.git;a=summary > > Regarding the top patch "pmem: KISS, remove the all pmem_major registration", > I like that we're getting rid of lots of dead code. The only issue I have is > that I'm pretty sure we aren't supposed to register our disks directly with a > major of BLOCK_EXT_MAJOR. Why not? if you inspect the code you will see that the system will do that assignment regardless of what we put there. Actually I agree we should just leave it ZERO and not touch it at all. More clear this way. (And better for me it is a complete red "remove lines" patch I love those patches) > I think we still need to register our own major via > register_blkdev(), and use that. I'm fine with getting rid of the module > parameter though, and always getting a major dynamically. > > If you look at the other block devices that use the GENHD_FL_EXT_DEVT flag > (nvme, loop, md, etc.) they all register their own major. You can't see this > major by doing 'ls -l' on the resulting devices in /dev, but you can see it by > looking at /proc/devices: > > # ls -l /dev/pmem0 > brw-rw---- 1 root disk 259, 0 Aug 26 12:37 /dev/pmem0 > > # grep pmem /proc/devices > 250 pmem > But why? all these you mentioned nvme, loop, md, they are all the case of copy/paste and dead code. Which is never use and is actually misleading. Like the /proc/devices thing, so "250 pmem" what does it means? It use to mean that any 250 major will be my device and any of my device will be 250, but here it is not. In fact you will not find any 250 related to devices in the system anywhere. It is just dead code. A user that will ever look at /proc/devices will just get confused assuming there is some error in the system because he loaded pmem and no 250 device is found. As I said in my patch. This looks revolutionary at first because it has never been done before, but this is the proper code, in current Kernel, and the modern udev rules all this legacy device major is not needed, and actually not used at all when you are a dynamic device, Just bunch of dead code that does nothing. [In old times /proc/devices was the only communication to user mode plumbing to create (mknod) node device-files at /dev/. X device files where created then accessed and if the Kernel returned -ENODEV it was deleted, I still remember those scripts that one had at your driver development project that would create the device-nodes at /dev/ for you. Actually it was before my time I never used a system that did not have udev. But I inherited a project that had that script and I remember one of the first things I did was to "git rm" that script. Funny I guess it is in my Karma to get rid of static device registration ] > - Ross > > I'll let you get used to it for a while, but think about it. It is dead code Thanks Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
