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>