Subject: Re: Mac mini and keyboard
To: None <port-macppc@NetBSD.org>
From: Tim Kelly <hockey@dialectronics.com>
List: port-macppc
Date: 03/02/2005 21:41:45
My ISP is generally blacklisted, so my posts are delayed several hours. If
this becomes redundant, my apologies in advance.
At 8:37 PM -0500 3/2/05, Michael wrote:
>> I would think that ideally, you'd want the USB baseline drivers started very
>> early, and the USB mass storage detection to happen "much later".
>Exactly. So we have keyboard control as soon as possible - this deadlock
>when the kernel asks for a root device needs to be dealt with.
>
>> I bet the USB drivers don't "factor" nicely like that. ;->
>It would be enough to postpone configuration of any removable storage
>until all the built-in >stuff is done - not easy to do, we'd need to run
>autoconfig twice. But then it would be easy to >add some option to move
>any driver into the 2nd run and this way enforce some kind of load >order.
>Could be useful for other things as well, like console drivers - we'd move
>the generic >driver ( like macppc's ofb ) into the 2nd run to make sure
>it's probed after all other possible >matches.
It seems to me it would be much simpler to replace the console input device
while in cpu_rootconf() in macppc/macppc/autoconf.c before calling
setroot() and then restore it afterward. setroot calls cngetsn when the
root device is required to be entered manually. cngetsn calls cngetc, which
calls the installed console getc handler. If the installed console input
handler was temporarily replaced with ofkbd_cngetc from machdep.c, OF could
do the polling for the root device.
tim