> No major issues here; however does it not stomp on the preloaded defaults?
Well, the patch cleans up the fact that preloaded defaults are stomped on
by uninitialised data. Now they are stomped on by 0 !! Gradual
improvement.
Actually, if the patch that moves ide_init_default_hwifs() is applied then
maybe this isn't strictly necessary. The whole area needs cleaning up, but
I was loathe to start doing major changes. I've done large parts of the
call tree for the ide driver, and I _still_ don't fully understand what
should be called when. Just as a sample, there's:
ide_init_data
ide_init_default_hwifs
ide_init_hwif_ports
init_hwif_data
ideprobe_init
probe_hwif_init
hwif_init
etc.
with little or no explanation as to what they do, but more crucially, when
they should be called. You can work out what they each do, but an idea of
the initialisation architecture would really help sort out if there are
branches that can now be got rid of.
> On Sun, 27 Oct 2002, Peter Denison wrote:
>
> > Summary: Initialise all parts of hw_regs_t structures before passing them
> > to ide_register_hw
> >
> > The hw structure (specifically the hw->chipset field) held uninitialised
> > data. This (before the initialisation order fixup recently posted) meant
> > that no chipset could ever get selected by an idex=<chipset> commandline
> > (silently!).
> >
> > Only occurs on non-PCI platforms. All ARM platforms have already been
> > fixed - though slightly differently.
-- Peter Denison <peterd at marshadder dot uklinux dot net> Please use the address above only for personal mail, not copied to any lists that are gatewayed to news or web pages unless the addresses are removed.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/