Subject: Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
To: None <firstname.lastname@example.org, email@example.com>
From: Hans Petter Selasky <firstname.lastname@example.org>
Date: 10/28/2005 01:27:49
On Thursday 27 October 2005 18:10, Bill Studenmund wrote:
> On Thu, Oct 27, 2005 at 09:29:52AM +0200, email@example.com.=
> > 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=
reading the configuration from "/etc/devfs.conf", like on "FreeBSD".
Another problem about /dev as a file system, is that one will possibly not=
find all the devices on the system, without being a kernel expert. And the=
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 =
driver and the NetBSD kernel. It is more like something that sits beside th=
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 =
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=
though it will only be used on NetBSD/OpenBSD and alike=B7 In fact, you can=
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=
will return "NULL" on FreeBSD and the correct value on NetBSD. Merging thes=
smaller differences will be the least problem.
The situation is like this, that having two branches of a driver is double=
work for the maintainer. And maybe this is the reason some drivers are only=
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=
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 =
the kernel under Giant aswell. Giant is bad, because it puts a single lock =
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=
simple. An advantage about non-tsleep-able mutexes, is that one can warn th=
user when a function that can sleep is called, depending on the context. Th=
might be as innocent as allocating some memory while holding a mutex, which=
many think will not cause a sleep. So code using its own mutexes, is really=
preferred, or is it not so important with mutexes?