From owner-freebsd-arch@FreeBSD.ORG Thu Jan 31 21:34:59 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FD7C16A417; Thu, 31 Jan 2008 21:34:59 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.swipnet.se [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id D518413C447; Thu, 31 Jan 2008 21:34:58 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [85.19.218.18] (account mc467741@c2i.net [85.19.218.18] verified) by mailfe12.swip.net (CommuniGate Pro SMTP 5.1.13) with ESMTPA id 614935817; Thu, 31 Jan 2008 21:34:55 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Thu, 31 Jan 2008 21:35:47 +0100 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801312135.48600.hselasky@c2i.net> Cc: Maxim Zhuravlev Subject: Re: [RFC] Some new generic device features. 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: Thu, 31 Jan 2008 21:34:59 -0000 Hi, Some general comments: Must be detach safe. Does it support non-giant enabled input drivers? How does it handle mutexes? --HPS On Thursday 31 January 2008, Maxim Zhuravlev wrote: > Hi. > > I'm currently working on project named *Enhanced NewBus*. It's a > successor of *Generic Input Device Layer Project* I've been working on > for GSoC2007 [1]. > As the project is to be quite an extensive one, I would like to get > some comments/suggestions on the design[2] first. It can be found > here:http://wiki.freebsd.org/EnhancedNewBus. > > In brief, the design suggests to implement in-kernel device piping. > There are two types of devices: logical (ex. console device, demuxing > device) and hardware (mices, displays). I suggest to add logical > devices to NewBus domain. Side effect is that device tree will > transform to a graph (ex. two mice can be parents of a demuxing > device, while being children of a same bus). The approach lets to > implement a generic way of ex. device demuxing, cause it's obvious > that functionality, provided by logical devices may be useful not just > for input devices, while some kind of devices may require some > specific features. Also it will be easier to implement such complex > device drivers, like a console driver is, by abstracting work with > underlying devices. To make it possible one needs to implement a way > to track input/output requests through the graph. The generic device > input/output subsystem is internally asynchronous for the sake of > flexibility. New logical drivers require a new more intellectual > autoconfiguration process. > > More here: [2]. > > [1] http://wiki.freebsd.org/GenericInputDeviceLayer > [2] http://wiki.freebsd.org/EnhancedNewBus > > -- > Maxim Zhuravlev > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"