Re: PATA transition
(Please CC on replies.)
On Thursday 18 March 2010, Ben Hutchings wrote:
> On Thu, Mar 18, 2010 at 05:05:47PM +0100, Frans Pop wrote:
> > On Thursday 18 March 2010, Ben Hutchings wrote:
> > > PATA drivers of either flavour are mostly selected on a
> > > per-architecture basis, and no change has been made to non-x86. If
> > > people are willing to test on the non-x86 architectures then we may
> > > have a chance to change them over as well.
> >
> > Does that mean that for other arches the kernel config remains
> > unchanged, or that they will get the new pata drivers, but without
> > automatic conversion support?
>
> The kernel config remains unchanged.
Ugh. That really seems like a bad idea. And waiting for testers seems like
a guarantee the transition will never complete: I doubt you'll ever be
able to find testers for _all_ possible IDE drivers.
I think it would be good to discuss this on d-devel, or at least
communicate this very clearly on d-d-a. It's completely new (and
unexpected) to me that the kernel team is not actually planning a complete
IDE->PATA transition for all architectures.
IMO it would be better to force the issue now in unstable and testing and
try to correct as much fallout as possible before the release and anything
not caught in stable updates than to stay with IDE and risk bugs due to
increasing reduced upstream maintenance of IDe drivers.
> There is code to display a warning for files that require manual
> conversion. And that would be needed for architectures/boot loaders that
> do not support an initramfs or initrd, since we cannot use LABEL/UUID
> specifications for them.
Ack. That's why I said that IMO not supporting automatic conversion for all
architectures is not a problem. Better to leave it up to the admins than
to promise automated conversion and have it fail because of arch-specific
corner cases.
> > As to testing. I have in the past tested the pata_cmd64x driver, and
> > can confirm that it works fine for my Ultra10.
>
> I'm more concerned about boot loader config than the drivers themselves.
Agreed. silo (sparc bootloader) isn't a problem in that respect. When I
tested pata_cmd64x I only changed the root fs in silo.conf from hda to sda
and it worked. I've not tested UUID as it is simply not needed on my box.
> > [1] Although it could be painful for e.g. headless NAS systems.
>
> Why so?
Because they often also don't have a serial port or other form of (boot)
console access, so if a kernel/initrd update results in a failed boot (for
whatever reason) the only option left in a lot of cases is relatively a
complex and at least partly blind rescue procedure.
Reply to: