Date: Fri, 28 Oct 2005 01:27:49 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: tech-kern@netbsd.org, freebsd-hackers@freebsd.org Subject: Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x Message-ID: <200510280127.50156.hselasky@c2i.net> In-Reply-To: <20051027161005.GB16197@netbsd.org> References: <200510242235.48403.hselasky@c2i.net> <20051027072952.GA505@beta.martani.repy.czf> <20051027161005.GB16197@netbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510280127.50156.hselasky>