Re: 2.6.17-mm6

[Jeff Garzik]

Alan Cox wrote:
> Ar Gwe, 2006-07-07 am 15:59 -0400, ysgrifennodd Jeff Garzik:
> > The circumstances you cite happened, yes, but I think you exaggerate the 
> > renaming.  Several soldered bridge solutions are already supported by 
> > libata.
> >
> > Several do need to be renamed to ata_*.c, though.
>
> If we work on the "commonly found" basis then it would be
>
> pata_atiixp
> pata_hpt37x
> pata_hpt3x2n
> pata_pdc2027x
>
> All four commonly are found with SATA bridges, ATIIXP especially.
>
> On the "almost any obscure case basis" would add
>
> pata_ali
> pata_sis
> pata_via
>
> and depending how far pushed
>
> pata_sil680
>
> and one or two others
>
> Which do you want renamed ?

See, out of 37 pata_*.c files, you still have 25+ with pata_ prefix.

Use your judgement, based on the guidelines described:  outside of 
weirdo pre-production cases, are users going to be plugging PATA cables 
or SATA cables into the hardware in question?

I'm a bit surprised to see pata_sis and pata_via:  are you certain there 
is not confusion based on the fact that newer SiS, ULi and VIA 
controllers provide both SATA and PATA on the same controller?

That's a common __known painful__ area of libata.  The libata API needs 
to be fixed such that port_operations can be vastly different.  Right 
now, probe_ent requires some attributes to be common across all ports, 
when they are not in real life.  This leads to improper creation of

	if (this port is sata)
		...
	else
		...

code inside hooks, when the libata-with-fixed-API solution looks like

	static void pata_doit() { ... }
	static void sata_doit() { ... }

	static struct ata_port_operations pata_ops = {...};
	static struct ata_port_operations sata_ops = {...};

For such cases, PATA support for these _new_ controllers needs to be 
added to sata_via.c, sata_uli.c, sata_sis.c, and they should then be 
renamed.  Or whatever similar renaming/code-shuffle solution brings 
about the same end result.

	Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/