From owner-freebsd-arch@FreeBSD.ORG Tue Apr 17 22:43:25 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C074D16A401; Tue, 17 Apr 2007 22:43:25 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.174]) by mx1.freebsd.org (Postfix) with ESMTP id A0AE113C4CA; Tue, 17 Apr 2007 22:43:25 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/smtpout04/MantshX 4.0) with ESMTP id l3HMhNVl028678; Tue, 17 Apr 2007 15:43:23 -0700 (PDT) Received: from [172.24.104.161] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id l3HMhHA3003388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Apr 2007 15:43:18 -0700 (PDT) In-Reply-To: References: <46250237.000008.20157@mfront8.yandex.ru> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Tue, 17 Apr 2007 15:42:19 -0700 To: Maxim Zhuravlev X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: freebsd-hackers@FreeBSD.org, thIOretic@yandex.ru, philip@FreeBSD.org, nsouch@free.fr, freebsd-arch@FreeBSD.org Subject: Re: GSoC project community intro and sync X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 22:43:25 -0000 On Apr 17, 2007, at 3:17 PM, Maxim Zhuravlev wrote: > 2007/4/17, Marcel Moolenaar : > > 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