[Qemu-devel] [RFC][PATCH] Modify loop device to be able to manage partitions of the image disk

[Qemu-devel] [RFC][PATCH] Modify loop device to be able to manage partitions of the image disk

[Laurent Vivier]

As it should be useful to be able to mount partition from a disk image, (and as I need a break in my bug hunting) I've modified the loop driver to mount raw disk image.

To not break original loop device, as we have to change minor numbers to manage partitions, a new parameter is added to the module:

max_part which define the maximum number of partitions by loop device.

By default max_part is equal to 1.

The patch has been created against the current KVM kernel source tree (2.6.24-rc6).

Example:

# insmod drivers/block/loop.ko
# ls -ld /dev/loop*
drwxr-xr-x 2 root root     60 2008-01-15 18:49 /dev/loop
brw-rw---- 1 root disk 7, 0 2008-01-15 19:07 /dev/loop0
brw-rw---- 1 root disk 7, 1 2008-01-15 19:07 /dev/loop1
brw-rw---- 1 root disk 7, 2 2008-01-15 19:07 /dev/loop2
brw-rw---- 1 root disk 7, 3 2008-01-15 19:07 /dev/loop3
brw-rw---- 1 root disk 7, 4 2008-01-15 19:07 /dev/loop4
brw-rw---- 1 root disk 7, 5 2008-01-15 19:07 /dev/loop5
brw-rw---- 1 root disk 7, 6 2008-01-15 19:07 /dev/loop6
brw-rw---- 1 root disk 7, 7 2008-01-15 19:07 /dev/loop7
# rmmod loop
# insmod drivers/block/loop.ko max_part=16
# ls -ld /dev/loop*
drwxr-xr-x 2 root root     60 2008-01-15 18:49 /dev/loop
brw-rw---- 1 root disk 7,   0 2008-01-15 19:08 /dev/loop0
brw-rw---- 1 root disk 7,  16 2008-01-15 19:08 /dev/loop1
brw-rw---- 1 root disk 7,  32 2008-01-15 19:08 /dev/loop2
brw-rw---- 1 root disk 7,  48 2008-01-15 19:08 /dev/loop3
brw-rw---- 1 root disk 7,  64 2008-01-15 19:08 /dev/loop4
brw-rw---- 1 root disk 7,  80 2008-01-15 19:08 /dev/loop5
brw-rw---- 1 root disk 7,  96 2008-01-15 19:08 /dev/loop6
brw-rw---- 1 root disk 7, 112 2008-01-15 19:08 /dev/loop7
# losetup /dev/loop0 etch.img
# ls -ld /dev/loop*
drwxr-xr-x 2 root root     60 2008-01-15 18:49 /dev/loop
brw-rw---- 1 root disk 7,   0 2008-01-15 19:08 /dev/loop0
brw-rw---- 1 root disk 7,   1 2008-01-15 19:09 /dev/loop0p1
brw-rw---- 1 root disk 7,   2 2008-01-15 19:09 /dev/loop0p2
brw-rw---- 1 root disk 7,   5 2008-01-15 19:09 /dev/loop0p5
brw-rw---- 1 root disk 7,  16 2008-01-15 19:08 /dev/loop1
brw-rw---- 1 root disk 7,  32 2008-01-15 19:08 /dev/loop2
brw-rw---- 1 root disk 7,  48 2008-01-15 19:08 /dev/loop3
brw-rw---- 1 root disk 7,  64 2008-01-15 19:08 /dev/loop4
brw-rw---- 1 root disk 7,  80 2008-01-15 19:08 /dev/loop5
brw-rw---- 1 root disk 7,  96 2008-01-15 19:08 /dev/loop6
brw-rw---- 1 root disk 7, 112 2008-01-15 19:08 /dev/loop7
# mount /dev/loop0p1 /mnt
# ls /m  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
# rmmod loop

All comments are welcome, perhaps it is stupid idea...

Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net>
---
 drivers/block/loop.c |   43 ++++++++++++++++++++++++++++++++++++-------
 1 files changed, 36 insertions(+), 7 deletions(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 56e2304..f601633 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -82,6 +82,8 @@
 static LIST_HEAD(loop_devices);
 static DEFINE_MUTEX(loop_devices_mutex);
 
+static int part_shift;
+
 /*
  * Transfer functions
  */
@@ -819,6 +821,7 @@ static int loop_set_fd(struct loop_device *lo, struct file *lo_file,
 	}
 	lo->lo_state = Lo_bound;
 	wake_up_process(lo->lo_thread);
+	ioctl_by_bdev(bdev, BLKRRPART, 0);
 	return 0;
 
 out_clr:
@@ -1352,6 +1355,9 @@ static struct block_device_operations lo_fops = {
 static int max_loop;
 module_param(max_loop, int, 0);
 MODULE_PARM_DESC(max_loop, "Maximum number of loop devices");
+static int max_part = 1;
+module_param(max_part, int, 0);
+MODULE_PARM_DESC(max_part, "Maximum number of partition by loop device");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS_BLOCKDEV_MAJOR(LOOP_MAJOR);
 
@@ -1404,7 +1410,7 @@ static struct loop_device *loop_alloc(int i)
 	if (!lo->lo_queue)
 		goto out_free_dev;
 
-	disk = lo->lo_disk = alloc_disk(1);
+	disk = lo->lo_disk = alloc_disk(1 << part_shift);
 	if (!disk)
 		goto out_free_queue;
 
@@ -1414,7 +1420,7 @@ static struct loop_device *loop_alloc(int i)
 	init_waitqueue_head(&lo->lo_event);
 	spin_lock_init(&lo->lo_lock);
 	disk->major		= LOOP_MAJOR;
-	disk->first_minor	= i;
+	disk->first_minor	= i << part_shift;
 	disk->fops		= &lo_fops;
 	disk->private_data	= lo;
 	disk->queue		= lo->lo_queue;
@@ -1466,7 +1472,7 @@ static struct kobject *loop_probe(dev_t dev, int *part, void *data)
 	struct kobject *kobj;
 
 	mutex_lock(&loop_devices_mutex);
-	lo = loop_init_one(dev & MINORMASK);
+	lo = loop_init_one((dev & MINORMASK) & 0x0F);
 	kobj = lo ? get_disk(lo->lo_disk) : ERR_PTR(-ENOMEM);
 	mutex_unlock(&loop_devices_mutex);
 
@@ -1477,7 +1483,7 @@ static struct kobject *loop_probe(dev_t dev, int *part, void *data)
 static int __init loop_init(void)
 {
 	int i, nr;
-	unsigned long range;
+	unsigned long range, bitfield;
 	struct loop_device *lo, *next;
 
 	/*
@@ -1494,7 +1500,11 @@ static int __init loop_init(void)
 	 *     themselves and have kernel automatically instantiate actual
 	 *     device on-demand.
 	 */
-	if (max_loop > 1UL << MINORBITS)
+
+	bitfield = max_part;
+	part_shift = find_first_bit(&bitfield, sizeof(bitfield));
+
+	if (max_loop > 1UL << (MINORBITS - part_shift))
 		return -EINVAL;
 
 	if (max_loop) {
@@ -1502,7 +1512,7 @@ static int __init loop_init(void)
 		range = max_loop;
 	} else {
 		nr = 8;
-		range = 1UL << MINORBITS;
+		range = 1UL << (MINORBITS - part_shift);
 	}
 
 	if (register_blkdev(LOOP_MAJOR, "loop"))
@@ -1541,7 +1551,7 @@ static void __exit loop_exit(void)
 	unsigned long range;
 	struct loop_device *lo, *next;
 
-	range = max_loop ? max_loop :  1UL << MINORBITS;
+	range = max_loop ? max_loop :  1UL << (MINORBITS - part_shift);
 
 	list_for_each_entry_safe(lo, next, &loop_devices, lo_list)
 		loop_del_one(lo);
@@ -1561,4 +1571,23 @@ static int __init max_loop_setup(char *str)
 }
 
 __setup("max_loop=", max_loop_setup);
+
+static int __init max_part_setup(char *str)
+{
+	max_part = simple_strtol(str, NULL, 0);
+	if (max_part < 1) {
+		/* there is at least one partition */ 
+		printk(KERN_ERR "loop: max_part cannot be lesser than 1\n");
+		return 0;
+	}
+        if (max_part > MINORBITS - 1) {
+		/* we must keep at least one bit for loop device number */
+		printk(KERN_ERR "loop: max_part cannot be greater than %d\n",
+			MINORBITS - 1);
+		return 0;
+	}
+	return 1;
+}
+
+__setup("max_part=", max_part_setup);
 #endif
-- 
1.5.2.4

[Qemu-devel] Re: [kvm-devel] [RFC][PATCH] Modify loop device to be able to manage partitions of the image disk

[Daniel P. Berrange]

On Tue, Jan 15, 2008 at 07:22:53PM +0100, Laurent Vivier wrote:
> As it should be useful to be able to mount partition from a 
> disk image, (and as I need a break in my bug hunting) I've 
> modified the loop driver to mount raw disk image.
> 
> To not break original loop device, as we have to change minor 
> numbers to manage partitions, a new parameter is added to the module:

I don't see the point in modifying the loop device driver when you
can already access the partitions with existing device mapper
functionality & tools.

# losetup  -f /var/lib/xen/images/fc6pvi386.img
# kpartx -l /dev/loop0
loop0p1 : 0 208782 /dev/loop0 63
loop0p2 : 0 10265535 /dev/loop0 208845
# kpartx -a /dev/loop0
# ls /dev/mapper/loop0p*
/dev/mapper/loop0p1  /dev/mapper/loop0p2
# mount /dev/mapper/loop0p1  /mnt/
# ls /mnt/
config-2.6.18-20.el5xen      lost+found                   vmlinuz-2.6.18-20.el5xen
grub                         symvers-2.6.18-20.el5xen.gz  xen.gz-2.6.18-20.el5
initrd-2.6.18-20.el5xen.img  System.map-2.6.18-20.el5xen  xen-syms-2.6.18-20.el5

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: [Qemu-devel] Re: [kvm-devel] [RFC][PATCH] Modify loop device to be able to manage partitions of the image disk

[Laurent Vivier]

[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]

Le mardi 15 janvier 2008 à 18:27 +0000, Daniel P. Berrange a écrit :
> On Tue, Jan 15, 2008 at 07:22:53PM +0100, Laurent Vivier wrote:
> > As it should be useful to be able to mount partition from a 
> > disk image, (and as I need a break in my bug hunting) I've 
> > modified the loop driver to mount raw disk image.
> > 
> > To not break original loop device, as we have to change minor 
> > numbers to manage partitions, a new parameter is added to the module:
> 
> I don't see the point in modifying the loop device driver when you
> can already access the partitions with existing device mapper
> functionality & tools.

There are two reasons:

1- I didn't know kpartx (thank you for the tip)

but using loop device, you will be able to use all partition tables
known by the kernel (acorn,  atari,  efi,  karma,  mac, osf, sun,
ultrix, amiga, ibm, ldm, msdos, sgi, sysv68), whereas kpartx can use
only partition tables it knows (bsd, dasd, dos, mac, sun, efi, sun,
unixware).

2- I'd like to mount qcow2 or others disk image formats, so perhaps it's
easier to modify loop device driver (but perhaps you know another magic
tool ?)

Regards,
Laurent
-- 
----------------- Laurent.Vivier@bull.net  ------------------
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Qemu-devel] Re: [kvm-devel] [RFC][PATCH] Modify loop device to be able to manage partitions of the image disk

[Daniel P. Berrange]

On Wed, Jan 16, 2008 at 12:40:06AM +0100, Laurent Vivier wrote:
> Le mardi 15 janvier 2008 à 18:27 +0000, Daniel P. Berrange a écrit :
> > On Tue, Jan 15, 2008 at 07:22:53PM +0100, Laurent Vivier wrote:
> > > As it should be useful to be able to mount partition from a 
> > > disk image, (and as I need a break in my bug hunting) I've 
> > > modified the loop driver to mount raw disk image.
> > > 
> > > To not break original loop device, as we have to change minor 
> > > numbers to manage partitions, a new parameter is added to the module:
> > 
> > I don't see the point in modifying the loop device driver when you
> > can already access the partitions with existing device mapper
> > functionality & tools.
> 
> There are two reasons:
> 
> 1- I didn't know kpartx (thank you for the tip)
> 
> but using loop device, you will be able to use all partition tables
> known by the kernel (acorn,  atari,  efi,  karma,  mac, osf, sun,
> ultrix, amiga, ibm, ldm, msdos, sgi, sysv68), whereas kpartx can use
> only partition tables it knows (bsd, dasd, dos, mac, sun, efi, sun,
> unixware).

This is an argument for extending kpartx to cope with the other
partition tables :-)  I have 50/50 split between VMs using files
vs VMs using LVM volumes - the loop driver patches only help you
access partitions within a file based image, whereas kpartx can
access the partitions within any block device, so can support 
files (via existing loop device) & LVM vols & nested partitions.

> 2- I'd like to mount qcow2 or others disk image formats, so perhaps it's
> easier to modify loop device driver (but perhaps you know another magic
> tool ?)

There has been some work in this area wrt to Xen - the DM-Userspace project
had some working code providing a device mapper target calling out to a 
userspace daemon to handle non-raw file formats like qcow. I don't
know what the state of it is now wrt to upstream kernel / device-mapper,
or even whether it is more than just 'proof of concept', but the project
page is here with some info:

  http://wiki.xensource.com/xenwiki/DmUserspace

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: [Qemu-devel] Re: [kvm-devel] [RFC][PATCH] Modify loop device to be able to manage partitions of the image disk

[Laurent Vivier]

[-- Attachment #1: Type: text/plain, Size: 2970 bytes --]

Le mardi 15 janvier 2008 à 23:54 +0000, Daniel P. Berrange a écrit :
> On Wed, Jan 16, 2008 at 12:40:06AM +0100, Laurent Vivier wrote:
> > Le mardi 15 janvier 2008 à 18:27 +0000, Daniel P. Berrange a écrit :
> > > On Tue, Jan 15, 2008 at 07:22:53PM +0100, Laurent Vivier wrote:
> > > > As it should be useful to be able to mount partition from a 
> > > > disk image, (and as I need a break in my bug hunting) I've 
> > > > modified the loop driver to mount raw disk image.
> > > > 
> > > > To not break original loop device, as we have to change minor 
> > > > numbers to manage partitions, a new parameter is added to the module:
> > > 
> > > I don't see the point in modifying the loop device driver when you
> > > can already access the partitions with existing device mapper
> > > functionality & tools.
> > 
> > There are two reasons:
> > 
> > 1- I didn't know kpartx (thank you for the tip)
> > 
> > but using loop device, you will be able to use all partition tables
> > known by the kernel (acorn,  atari,  efi,  karma,  mac, osf, sun,
> > ultrix, amiga, ibm, ldm, msdos, sgi, sysv68), whereas kpartx can use
> > only partition tables it knows (bsd, dasd, dos, mac, sun, efi, sun,
> > unixware).
> 
> This is an argument for extending kpartx to cope with the other
> partition tables :-)  I have 50/50 split between VMs using files

Good try... but IMHO, I think it is better to let the kernel decode the
partition table...

> vs VMs using LVM volumes - the loop driver patches only help you
> access partitions within a file based image, whereas kpartx can
> access the partitions within any block device, so can support 
> files (via existing loop device) & LVM vols & nested partitions.

I think you're wrong (but you seem to know the subject better than me,
so ...): you should be able to use the modified loop device on the
logical volume to decode partition table.

> 
> > 2- I'd like to mount qcow2 or others disk image formats, so perhaps it's
> > easier to modify loop device driver (but perhaps you know another magic
> > tool ?)
> 
> There has been some work in this area wrt to Xen - the DM-Userspace project
> had some working code providing a device mapper target calling out to a 
> userspace daemon to handle non-raw file formats like qcow. I don't
> know what the state of it is now wrt to upstream kernel / device-mapper,
> or even whether it is more than just 'proof of concept', but the project
> page is here with some info:
> 
>   http://wiki.xensource.com/xenwiki/DmUserspace

It seems a very good idea, but what I don't like:
- it seems very complex (like IBM guys like ;-) )
- it is one and a half year old

To be honest, if something good already exists, I take it...

Laurent
-- 
----------------- Laurent.Vivier@bull.net  ------------------
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [kvm-devel] [Qemu-devel] Re: [RFC][PATCH] Modify loop device to be able to manage partitions of the image disk

[Anthony Liguori]

Laurent Vivier wrote:
> Le mardi 15 janvier 2008 à 23:54 +0000, Daniel P. Berrange a écrit :
>   
>> On Wed, Jan 16, 2008 at 12:40:06AM +0100, Laurent Vivier wrote:
>>     
>>> Le mardi 15 janvier 2008 à 18:27 +0000, Daniel P. Berrange a écrit :
>>>       
>>>> On Tue, Jan 15, 2008 at 07:22:53PM +0100, Laurent Vivier wrote:
>>>>         
>>>>> As it should be useful to be able to mount partition from a 
>>>>> disk image, (and as I need a break in my bug hunting) I've 
>>>>> modified the loop driver to mount raw disk image.
>>>>>
>>>>> To not break original loop device, as we have to change minor 
>>>>> numbers to manage partitions, a new parameter is added to the module:
>>>>>           
>>>> I don't see the point in modifying the loop device driver when you
>>>> can already access the partitions with existing device mapper
>>>> functionality & tools.
>>>>         
>>> There are two reasons:
>>>
>>> 1- I didn't know kpartx (thank you for the tip)
>>>
>>> but using loop device, you will be able to use all partition tables
>>> known by the kernel (acorn,  atari,  efi,  karma,  mac, osf, sun,
>>> ultrix, amiga, ibm, ldm, msdos, sgi, sysv68), whereas kpartx can use
>>> only partition tables it knows (bsd, dasd, dos, mac, sun, efi, sun,
>>> unixware).
>>>       
>> This is an argument for extending kpartx to cope with the other
>> partition tables :-)  I have 50/50 split between VMs using files
>>     
>
> Good try... but IMHO, I think it is better to let the kernel decode the
> partition table...
>
>   
>> vs VMs using LVM volumes - the loop driver patches only help you
>> access partitions within a file based image, whereas kpartx can
>> access the partitions within any block device, so can support 
>> files (via existing loop device) & LVM vols & nested partitions.
>>     
>
> I think you're wrong (but you seem to know the subject better than me,
> so ...): you should be able to use the modified loop device on the
> logical volume to decode partition table.
>
>   
>>> 2- I'd like to mount qcow2 or others disk image formats, so perhaps it's
>>> easier to modify loop device driver (but perhaps you know another magic
>>> tool ?)
>>>       
>> There has been some work in this area wrt to Xen - the DM-Userspace project
>> had some working code providing a device mapper target calling out to a 
>> userspace daemon to handle non-raw file formats like qcow. I don't
>> know what the state of it is now wrt to upstream kernel / device-mapper,
>> or even whether it is more than just 'proof of concept', but the project
>> page is here with some info:
>>
>>   http://wiki.xensource.com/xenwiki/DmUserspace

FWIW, I still think a userspace block device is the Right Way to support 
these sort of things.  dm-userspace turned out to be difficult as device 
mapper has some rather strict requirements about alignment that some 
formats (like qcow) cannot satisfy.

The loop driver is a terrible base to start from as it does not preserve 
data integrity.

Regards,

Anthony Liguori

>> It seems a very good idea, but what I don't like:
>> - it seems very complex (like IBM guys like ;-) )
>> - it is one and a half year old
>>
>> To be honest, if something good already exists, I take it...
>>
>> Laurent
>>     
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>   

Re: [kvm-devel] [Qemu-devel] Re: [RFC][PATCH] Modify loop device to be able to manage partitions of the image disk

[Laurent Vivier]

[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]

Le mercredi 16 janvier 2008 à 08:57 -0600, Anthony Liguori a écrit :
> > Le mardi 15 janvier 2008 à 23:54 +0000, Daniel P. Berrange a écrit :
[...]
> >>> 2- I'd like to mount qcow2 or others disk image formats, so perhaps it's
> >>> easier to modify loop device driver (but perhaps you know another magic
> >>> tool ?)
> >>>       
> >> There has been some work in this area wrt to Xen - the DM-Userspace project
> >> had some working code providing a device mapper target calling out to a 
> >> userspace daemon to handle non-raw file formats like qcow. I don't
> >> know what the state of it is now wrt to upstream kernel / device-mapper,
> >> or even whether it is more than just 'proof of concept', but the project
> >> page is here with some info:
> >>
> >>   http://wiki.xensource.com/xenwiki/DmUserspace
> 
> FWIW, I still think a userspace block device is the Right Way to support 

I agree with you, it was my first idea too, but it introduces complexity
to manage communications between the kernel part of the driver and the
userspace daemon: I don't like complexity.

> these sort of things.  dm-userspace turned out to be difficult as device 
> mapper has some rather strict requirements about alignment that some 
> formats (like qcow) cannot satisfy.
> 
> The loop driver is a terrible base to start from as it does not preserve 
> data integrity.
[...]

But everyone already uses loop as it is currently, so why not to add
more supported formats for the disk image ?
Why do you say it doesn't preserve data integrity ?

Regards,
Laurent
-- 
----------------- Laurent.Vivier@bull.net  ------------------
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Qemu-devel] [RFC][PATCH] Modify loop device to be able to managepartitions of the image disk

[Sergey Bychkov]

> All comments are welcome, perhaps it is stupid idea...

Exellent thing.  I wonder why loop device in linux kernel haven't this 
functionality yet.
Don't You think to try to add this patch to linux kernel source tree?

Sergey Bychkow
ICQ: 21014758
FTN: 2:450/118.55 

Re: [Qemu-devel] [RFC][PATCH] Modify loop device to be able to managepartitions of the image disk

[Laurent Vivier]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

Le mercredi 16 janvier 2008 à 13:51 +0200, Sergey Bychkov a écrit :
> > All comments are welcome, perhaps it is stupid idea...
> 
> Exellent thing.  I wonder why loop device in linux kernel haven't this 
> functionality yet.
> Don't You think to try to add this patch to linux kernel source tree?

Yes, if everybody thinks it should be, but it needs some more work
before.

Regards,
Laurent
-- 
----------------- Laurent.Vivier@bull.net  ------------------
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]