linux-kernel - Re: [PATCH] Modify loop device to be able to manage partitions of the disk image

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1204798585.4325.8.camel@frecb07144>
Date:	Thu, 06 Mar 2008 11:16:25 +0100
From:	Laurent Vivier <Laurent.Vivier@...l.net>
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Modify loop device to be able to manage partitions of
	the disk image


Le jeudi 06 mars 2008 à 20:57 +1100, Nick Piggin a écrit :
> On Thursday 06 March 2008 20:43, Laurent Vivier wrote:
> > This patch allows to use loop device with partitionned disk image.
> >
> > Original behavior of loop is not modified.
> >
> > A new parameter is introduced to define how many partition we want to be
> > able to manage per loop device. This parameter is "max_part".
> >
> > For instance, to manage 63 partitions / loop device, we will do:
> > # modprobe max_part=63
> > # ls -l /dev/loop?*
> > brw-rw---- 1 root disk 7,   0 2008-03-05 14:55 /dev/loop0
> > brw-rw---- 1 root disk 7,  64 2008-03-05 14:55 /dev/loop1
> > brw-rw---- 1 root disk 7, 128 2008-03-05 14:55 /dev/loop2
> > brw-rw---- 1 root disk 7, 192 2008-03-05 14:55 /dev/loop3
> > brw-rw---- 1 root disk 7, 256 2008-03-05 14:55 /dev/loop4
> > brw-rw---- 1 root disk 7, 320 2008-03-05 14:55 /dev/loop5
> > brw-rw---- 1 root disk 7, 384 2008-03-05 14:55 /dev/loop6
> > brw-rw---- 1 root disk 7, 448 2008-03-05 14:55 /dev/loop7
> >
> > And to attach a raw partitionned disk image, the original losetup is used:
> >
> > # losetup -f etch.img
> > # ls -l /dev/loop?*
> > brw-rw---- 1 root disk 7,   0 2008-03-05 14:55 /dev/loop0
> > brw-rw---- 1 root disk 7,   1 2008-03-05 14:57 /dev/loop0p1
> > brw-rw---- 1 root disk 7,   2 2008-03-05 14:57 /dev/loop0p2
> > brw-rw---- 1 root disk 7,   5 2008-03-05 14:57 /dev/loop0p5
> > brw-rw---- 1 root disk 7,  64 2008-03-05 14:55 /dev/loop1
> > brw-rw---- 1 root disk 7, 128 2008-03-05 14:55 /dev/loop2
> > brw-rw---- 1 root disk 7, 192 2008-03-05 14:55 /dev/loop3
> > brw-rw---- 1 root disk 7, 256 2008-03-05 14:55 /dev/loop4
> > brw-rw---- 1 root disk 7, 320 2008-03-05 14:55 /dev/loop5
> > brw-rw---- 1 root disk 7, 384 2008-03-05 14:55 /dev/loop6
> > brw-rw---- 1 root disk 7, 448 2008-03-05 14:55 /dev/loop7
> > # mount /dev/loop0p1 /mnt
> > # ls /mnt
> > bench  cdrom  home        lib         mnt   root     srv  usr
> > bin    dev    initrd      lost+found  opt   sbin     sys  var
> > boot   etc    initrd.img  media       proc  selinux  tmp  vmlinuz
> > # umount /mnt
> > # losetup -d /dev/loop0
> >
> > Of course, the same behavior can be done using kpartx on a loop device,
> > but modifying loop avoids to stack several layers of block device (loop +
> > device mapper), this is a very light modification (40% of modifications
> > are to manage the new parameter). Moreover all partition tables known
> > by the kernel are managed (kpartx implements only a subset).
> 
> Do you think we do something similar for drivers/block/brd.c too? I'd
> like to try to maintain parity between them where possible...

I think it is possible  (I've the same patch for NBD too), but I think
it is completely useless.

For loop, it is another story because it uses disk images that can be
created from a partition or a real device (or a virtual disk).

Regards,
Laurent
-- 
----------------- Laurent.Vivier@...l.net  ------------------
"Programmers who subconsciously view themselves as artists
 will enjoy what they do and will do it better." D. Knuth

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