re: i386 vs radeondrmkms problem - isa attachments suck

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello.  Here is a very naive question.  Could the vga driver be
altered to not do its mapping until the Radeon, or other graphics driver,
has had a chance to map and/or attach?

	To solve the loss of the printed copyright messages, perhaps a buffer
could be allocated, much like the dmesg buffer, which could be written to
while things are still attaching.  Then, once all is attached, a function
could be called to print the contents of the accumulated buffer to the
final, correct, device.  Doing things this way could also allow us to have 
serial consoles using usb attached serial ports.  I've thought about trying
something like this, but haven't gotten  frustrated enough yet to do it.

Thoughts?

-Brian

On Mar 4,  9:10am, matthew green wrote:
} Subject: re: i386 vs radeondrmkms problem - isa attachments suck
} 
} > > 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.
>-- End of excerpt from matthew green