Console patch part II...

[Ken Smith]

On Tue, Mar 16, 2004 at 02:34:06AM -0500, Ken Smith wrote:

[ ... ]

> As far as I can tell these are the possible solutions:
> 
> 	- Find out what the *minimum* stuff needed to make make_dev()
> 	  happy and move that above the current location of cninit()
> 	  I tried that but wasn't very successful, I can try harder I
> 	  guess.

This doesn't appear to be feasible.  You don't want to know what it took
to learn this but ...

	- mutex_init() doesn't work before cpu_setregs() gets called.
	  This appears to be related to getting the per-cpu data page
	  to the point it's usable.
	- cpu_setregs() doesn't work before pc->pc_curpcb gets set,
	  I think because it's forcing a trap as part of its implementation.
	- pc->pc_curpcb can't be set until thread0.td_pcb gets set
	  on sparc64 (it apparently can be on powerpc, which is what
	  I was using as a guide for some of this...)
	- thread0.td_pcb can't be set until kstack0 is available
	- kstack0 isn't ready before pmap_bootstrap() is done.
	- there are lots of calls to panic() in pmap_bootstrap() so
	  moving it in front of cninit() would be bad.

> 	- Move cninit() to after proc0 gets set up and live with not
> 	  seeing anything useful printf()-wise or panic()-wise. :-)

That's obviously a joke... :-)

> 	- The current suggested solution - minimal and omniscent
> 	  console setup early on, ditch it and call cninit() once it's
> 	  safe to do that.
> 
> 	- [ This is a new thought... ] Restructure all the potential
> 	  console drivers to be like ofw_console is.  ofw_console doesn't
> 	  call make_dev() in its attach routine.  Instead it uses a
> 	  sysinit() to handle the make_dev() later in the boot sequence
> 	  instead of doing at attach time.

If I'm correct that leaves us with the above two possibilities.  The
patch I posted last night does the first one and I admit it's a kluge,
to the point I was willing to kill a fair chunk of time to work out
the above dependencies... :-)

I'm sort of inclined to go with the kluge despite it apparently needing
more work on the uart code to not cause a regression mainly because
as we expand off into Sunblade's and whatnot we might be able to steal
drivers for consoles that more or less work with other PCI bus based
architectures and I'm not sure we'd get all console driver writers
to abide by doing things like ofw_console does.  However the more I
think about it that method really does seem like a better solution
if we got everyone to buy into it (and if there aren't limitations to
that method I don't know about...).

Any further thoughts?  Stuff I'm missing?  Anyone with a bigger clue
than me out there?  If this results in silence I'll go ahead with the
kluge but only because I need a default thing to do - if anyone has
other things I should try or if anyone wants to try other stuff themselves
feel free, just let me know...

-- 
						Ken Smith
- From there to here, from here to      |       kensmith at cse.buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |