cvs commit: src/sys/dev/kbd kbd.c src/sys/dev/syscons syscons.c

[Alexey Dokuchaev]

On Tue, Feb 28, 2006 at 07:36:25PM -0800, Maksim Yevmenkin wrote:
> On 2/28/06, Scott Long <scottl at samsco.org> wrote:
> > Maksim Yevmenkin wrote:
> 
> [...]
> 
> > >>Ultimately I would like to see this enabled by default so that
> > >>everything 'just works', but with a way to easily disable it in case
> > >>something goes wrong.  Would that be possible?
> > >
> > > right now i can think of two ways to make it enabled by default:
> > >
> > > 1) add 'device kbdmux' to the kernel config (or even make it required)
> >
> > Could you add a check to the probe/attach routines of kbdmux so that it
> > could be disabled via a loader hint?  I assume that there will only be
> > one instance of the kbdmux device, so this should be easy to do.
> > Something similar is possible with acpi, fwiw.
> 
> sure. i can add check in kbdmux_probe().
> 
> > > 2) set kbdmux_load to "YES" somewhere in loader.* files (somewhat
> > > similar to acpi).
> >
> > Actually, acpi is much more evil.  The loader probes the BIOS to see if
> > ACPI tables are present, and then sets the acpi_load variable based on
> > that.  So no variables in loader.* are present in the default install.
> > If we wanted to add the kbdmux_load variable in the default system then
> > we will need to add /usr/src/sys/boot/forth/loader.conf, or add magic
> > to the installkernel target to handle it similar to device.hints.
> 
> ok. i will add check for hints then. so, i guess, the plan is to add
> 
> device kbdmux
> 
> into default kernel config and use hints do enable/disable kbdmux, right?

I would still prefer to be able to have a slim kernel with as mush as
possible done via modules, e.g. I'd like to see kbdmux(4) optional in
kernel (I don't really care if it would present in default GENERIC though).

./danfe