Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Apr 2007 15:42:19 -0700
From:      Marcel Moolenaar <xcllnt@mac.com>
To:        Maxim Zhuravlev <thIOretic@FreeBSD.org>
Cc:        freebsd-hackers@FreeBSD.org, thIOretic@yandex.ru, philip@FreeBSD.org, nsouch@free.fr, freebsd-arch@FreeBSD.org
Subject:   Re: GSoC <Generic input device layer> project community intro and sync
Message-ID:  <C81CA213-C52F-4430-B028-1158B89488EA@mac.com>
In-Reply-To: <fe052a80704171517x75ecc278qb0304dedb2293684@mail.gmail.com>
References:  <46250237.000008.20157@mfront8.yandex.ru> <AD126480-D9D1-4472-8C5E-C37D6CD7C47E@mac.com> <fe052a80704171517x75ecc278qb0304dedb2293684@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Apr 17, 2007, at 3:17 PM, Maxim Zhuravlev wrote:

> 2007/4/17, Marcel Moolenaar <xcllnt@mac.com>:
>
> Thanks for detailed useful reply.
>
>> As for vtc(4): I've not been working on input devices because of the
>> lack of a generic layer. Note that vtc(4) deals with the low-level
>> console as much as it deals with user-visible terminals, so from that
>> point of view, a user space stack will not address the need for  
>> having
>> console input when there's no (functional) user space -- this  
>> includes
>> early boot, the kernel debugger and single-user mode. I therefore  
>> doubt
>> that it will sufficiently (or at all) solve problems we already have.
>
> Yup. That's what I'm thinking about right now.
> One of possible decisions is to move stacking into the kernel and have
> an optional usermode part 'stacked' through a 2 'stub' drivers.

That's a possibility. I think it's reasonable to not provide a
fully-fledged stack when there's no user space. For example,
while i18n and l10n are important, I think that an english-only
or a Latin-only fallback mode makes matters simpler in case of
an emergency. The user interacting with the boot process or
working in single user mode is not an average user and can be
expected to adjust to the more limited fallback mode.

The question becomes to what extend the stack would live in
kernel space and to what extend there will be duplication or
control from user space.

>> Also, while multiplexing is an important feature I think that de-
>> multiplexing is important too.
>
> I guess, demux can be done by 'top' driver or by drivers layout. There
> are several ways, that have little impact on the total design.

Unfortunately, this goes beyond just input-stack only. A terminal
consists typically of input and output devices and can even include
audio devices for the historical beeps, keyclicks and other audible
cues. There needs to be a higher entity, like vtc(4), that manages
terminals and that will be in control of bundling devices into a
functional terminal. This would imply that any logic to control the
bundling would be part of that higher entity and not of the input
stack itself. This would significantly alter the design of the input
stack if the design of the input stack incorporates such control
(as I think is the case here).

Not to worry, I'm going to ask you to change your design :-)
Just think of it as food for thought.

-- 
Marcel Moolenaar
xcllnt@mac.com





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C81CA213-C52F-4430-B028-1158B89488EA>