Re: RFC: proposal for handling isw dmraid -> mdraid upgrade path

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 06/30/2009 11:36 PM, Bill Nottingham wrote:
Hans de Goede (hdegoede@xxxxxxxxxx) said:
... why do we want to do this? Supporting two entirely separate code paths
for a single device is *bad*.

Because we will need both code paths anyways as for some bios-raid's mdraid
will be the preferred method, while others will only be supported by dmraid.

Sure, you have to keep dmraid around for some legacy BIOSes, but...

Given that we need the 2 code paths anyways, making which one to use
configurable when both support the type of bios-raid is much easier, and
certainly much less error prone, then trying to handle device name changes
when upgrading.

This means that for users of a particular BIOS, you get to write "If X, do
Y. If A, do B" sort of docs, which are always bad. You get to wire
distro-specific magic into anaconda, rc.sysinit, mkinitrd, dracut, etc.,
etc. You ensure that the old, dead, no longer maintained support for
whichever tool is non-default for a format can never be turned off.

Erm:

And
you require the user to pass magic options anyway.


Only if the user wants to deviate from the default in a fresh install, in all
other cases things will just work.

It's best to just cut the cord for people who need to migrate. It's a
one-time user cost, as opposed to an ongoing maintenance cost.


So you propose we just release note this and be done with it ?

Regards,

Hans

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux