Phillip, do you recall when dmraid support was added to libparted?
Phillip Susi wrote in comment #17:
> It sounds like dmraid.cc can be removed then. Libparted now directly
> supports dmraid devices and handles the dev node creation. Actually now
> we are using devfs for /dev, so the kernel creates the dev nodes, rather
> than either udev or libdevmapper.
Unfortunately I do not think that dmraid can simply be removed at this point in time. Following are the reasons that I believe DMRaid.cc is needed for at least a while longer (perhaps a year or more):
1) To maintain backward compatibility with current GNU/Linux distributions.
Parted 1.9.0 was released on July 23, 2009. Newer versions like 2.2 were only released in February of 2010. This means that these versions have been available for less than a year, and are not likely included with Long Term Support Gnu/Linux distributions.
2) To avoid some problems with libparted device detection.
Following are two reasons why GParted performs it's own device detection:
A) If libparted device detection is used, it takes an inordinate amount of time to scan devices on computer systems that do not have a physical floppy drive installed, but do have the BIOS set to indicate a floppy drive is present.
This problem was tracked in GParted bug #351753.
Missing floppy causes loop on scanning devices. https://bugzilla.gnome.org/show_bug.cgi?id=351753
B) If libparted device detection is used, some versions of libparted might not detect dmraid devices, or will list all partitions as dmraid devices as well.
I remember this problem from past testing because I do not recall documenting this problem elsewhere.
Do the above explanations help describe why it might not be prudent to remove DMRaid.cc at this time?
Phillip, do you recall when dmraid support was added to libparted?
Phillip Susi wrote in comment #17:
> It sounds like dmraid.cc can be removed then. Libparted now directly
> supports dmraid devices and handles the dev node creation. Actually now
> we are using devfs for /dev, so the kernel creates the dev nodes, rather
> than either udev or libdevmapper.
Unfortunately I do not think that dmraid can simply be removed at this point in time. Following are the reasons that I believe DMRaid.cc is needed for at least a while longer (perhaps a year or more):
1) To maintain backward compatibility with current GNU/Linux distributions.
Parted 1.9.0 was released on July 23, 2009. Newer versions like 2.2 were only released in February of 2010. This means that these versions have been available for less than a year, and are not likely included with Long Term Support Gnu/Linux distributions.
2) To avoid some problems with libparted device detection.
Currently GParted contains it's own code to detect disk devices. git.gnome. org/browse/ gparted/ tree/src/ GParted_ Core.cc
Search for method "set_devices" in GParted_Core.cc:
http://
Following are two reasons why GParted performs it's own device detection:
A) If libparted device detection is used, it takes an inordinate amount of time to scan devices on computer systems that do not have a physical floppy drive installed, but do have the BIOS set to indicate a floppy drive is present. /bugzilla. gnome.org/ show_bug. cgi?id= 351753
This problem was tracked in GParted bug #351753.
Missing floppy causes loop on scanning devices.
https:/
This problem was also reported in Parted ticket #194.
ped_ device_ probe_all( ) returns /dev/fd0 when no physical floppy device present. parted. alioth. debian. org/cgi- bin/trac. cgi/ticket/ 194
http://
B) If libparted device detection is used, some versions of libparted might not detect dmraid devices, or will list all partitions as dmraid devices as well.
I remember this problem from past testing because I do not recall documenting this problem elsewhere.
Do the above explanations help describe why it might not be prudent to remove DMRaid.cc at this time?