re: i386 vs radeondrmkms problem - isa attachments suck

[matthew green <mrg%eterna.com.au@localhost>]

> > Is the ignoring of attach priority a general characteristic of
> > indirect buses, and might it make sense for config to be able to
> > explicitly prioritise the order the cfdata[] entries? I know uebayasi@
> > has been rototilling config and wondered if he could be interested...
> > :)
> 
> The problem is that there is no notion of priority for indirect buses
> because it is up to the attaching driver to determine if it should
> attach or not.
> 
> You could imagine working around that by adding code to check whether
> two drivers claim conflicting resources, and then the idea of priority
> would work.
> 
> GSoC project maybe?

the problem is that the relevant kernel resources *are already*
mapped by the vga driver, just well before it attaches.  that
happens before the copyright is printed in consinit().  otherwise
we'd get no kernel output..

i have a hack on the radeon@pci driver to do this, and it works..
on serial console.

i figured out the ordering problem with doing radeonhack@isa, and
got it to attach first, but it doesn't help since vga already has
claimed those registers, and knows it should attach, which it
does.. and then attaches wsdisplay.

basically, the only real solution is to get vga to give up these
entirely (ie, to detach itself and its wsdisplays) and that's
proven to be more tricky than hoped.  at this point i'm going with
my LEGACY kernel idea.

> I'd actually create a i386-legacy arch and get rid of all the crud in
> i386 that deals with stuff built before 2005 or so.  And move that to
> tier-infinity and let it die peacefully.

they still sell i586 based systems so this seems like a fairly
early cut off.  also sounds a like a lot more effort than simply
having an relatively small LEGACY kernel that has it (i'm thinking
of releng work, source code additions, etc., not just my effort.)

thanks.


.mrg.