Date: Wed, 18 Apr 2007 02:17:20 +0400 From: "Maxim Zhuravlev" <thIOretic@FreeBSD.org> To: "Marcel Moolenaar" <xcllnt@mac.com> Cc: freebsd-hackers@freebsd.org, thIOretic@yandex.ru, nsouch@free.fr, freebsd-arch@freebsd.org Subject: Re: GSoC <Generic input device layer> project community intro and sync Message-ID: <fe052a80704171517x75ecc278qb0304dedb2293684@mail.gmail.com> In-Reply-To: <AD126480-D9D1-4472-8C5E-C37D6CD7C47E@mac.com> References: <46250237.000008.20157@mfront8.yandex.ru> <AD126480-D9D1-4472-8C5E-C37D6CD7C47E@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. Thanks, - Maxim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fe052a80704171517x75ecc278qb0304dedb2293684>