From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 23:26:52 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E524316A41F for ; Thu, 27 Oct 2005 23:26:51 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BBC043D45 for ; Thu, 27 Oct 2005 23:26:50 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-217-136-130.daxnet.no ([193.217.136.130] verified) by mailfe06.swip.net (CommuniGate Pro SMTP 4.3.8) with ESMTP id 11744433; Fri, 28 Oct 2005 01:26:48 +0200 From: Hans Petter Selasky To: tech-kern@netbsd.org, freebsd-hackers@freebsd.org Date: Fri, 28 Oct 2005 01:27:49 +0200 User-Agent: KMail/1.7 References: <200510242235.48403.hselasky@c2i.net> <20051027072952.GA505@beta.martani.repy.czf> <20051027161005.GB16197@netbsd.org> In-Reply-To: <20051027161005.GB16197@netbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200510280127.50156.hselasky@c2i.net> Cc: Subject: Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2005 23:26:52 -0000 On Thursday 27 October 2005 18:10, Bill Studenmund wrote: > On Thu, Oct 27, 2005 at 09:29:52AM +0200, pcah8322@artax.karlin.mff.cuni.= cz=20 wrote: > > On Wed, Oct 26, 2005 at 05:48:06PM -0700, Bill Studenmund wrote: > > > The reason I'm interested in locators is so that if devices renumber > > > themselves, the permissions follow. I am assuming, but I think we'd > > > rather not use locators for names (/dev/sd.52004567BA64678D anyone?). > > > But if we can tie the permissions to a locator, then it doesn't matter > > > if it's sd2 or sd12. :-) > > > > I think it does matter, because all userland programs use device names, > > not locators. If permissions are enforced by an userland program, they > > will not follow locators. > > Oh, but part of all of this would be that userland would be able to find > out the locators for a device! It won't work any other way. > I was thinking that one could mount devfs on /dev/dev, and then make some=20 symlinks from /dev/ to /dev/dev/, hence it is not possible to union mount=20 anything on /dev. Then symlinks and permissions can be managed by a daemon= =20 reading the configuration from "/etc/devfs.conf", like on "FreeBSD". Another problem about /dev as a file system, is that one will possibly not= =20 find all the devices on the system, without being a kernel expert. And the= =20 major/minor numering is not easy, like mentioned by someone else. On Wednesday 26 October 2005 02:09, Lennart Augustsson wrote: > You'll never get a driver that looks exactly right for one > OS to work with another, even with an emulation layer. That is what I have done. Remember, my emulator is not sandwitched between = the=20 driver and the NetBSD kernel. It is more like something that sits beside th= e=20 NetBSD kernel. Else this task would be nearly impossible, due to the=20 differences between NetBSD and FreeBSD. So if you put a driver under my emulation layer, it will not be a child of = the=20 NetBSD device system, but the FreeBSD device system.=20 > For instance, FreeBSD doesn't have an activate method for > device drivers whereas NetBSD and OpenBSD do. There is no problem adding a "device_activate" method to the FreeBSD driver= s,=20 though it will only be used on NetBSD/OpenBSD and alike=B7 In fact, you can= add=20 any method you like to any device. > And there are examples of the reverse. =A0So shared drivers > will have some clutter. I see that there are some problems, but no big problems. For example on=20 =46reeBSD there is no parent bus_dma_tag for PCI devices. But there is no=20 problem to add something like "device_get_parent_dma_tag(device_t *dev)" th= at=20 will return "NULL" on FreeBSD and the correct value on NetBSD. Merging thes= e=20 smaller differences will be the least problem. The situation is like this, that having two branches of a driver is double= =20 work for the maintainer. And maybe this is the reason some drivers are only= =20 available on one system. And when one can spend twice as much time on=20 something, it should be better. Shouldn't it be easier to port kernel=20 software between FreeBSD and NetBSD? When it comes to mutexes I want to say that FreeBSD's "struct mtx" is porta= ble=20 to NetBSD without any problems. But when a NetBSD driver is ported to=20 =46reeBSD, it will fall under the Giant lock, possibly forcing other parts = of=20 the kernel under Giant aswell. Giant is bad, because it puts a single lock = on=20 the kernel. Moving some piece of code out of Giant is sometimes easy, but=20 from my experience, it can require a lot of work. Locking is not just that= =20 simple. An advantage about non-tsleep-able mutexes, is that one can warn th= e=20 user when a function that can sleep is called, depending on the context. Th= is=20 might be as innocent as allocating some memory while holding a mutex, which= =20 many think will not cause a sleep. So code using its own mutexes, is really= =20 preferred, or is it not so important with mutexes? =2D-HPS