FreeBSD 5/6/7 kernel emulator for NetBSD 2.x

[Hans Petter Selasky]

On Thursday 27 October 2005 18:10, Bill Studenmund wrote:
> On Thu, Oct 27, 2005 at 09:29:52AM +0200, pcah8322 at artax.karlin.mff.cuni.cz 
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 
symlinks from /dev/ to /dev/dev/, hence it is not possible to union mount 
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 the 
driver and the NetBSD kernel. It is more like something that sits beside the 
NetBSD kernel. Else this task would be nearly impossible, due to the 
differences between NetBSD and FreeBSD.

So if you put a driver under my emulation layer, it will not be a child of the 
NetBSD device system, but the FreeBSD device system. 

> 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 drivers, 
though it will only be used on NetBSD/OpenBSD and alike· In fact, you can add 
any method you like to any device.

> And there are examples of the reverse.  So shared drivers
> will have some clutter.

I see that there are some problems, but no big problems. For example on 
FreeBSD there is no parent bus_dma_tag for PCI devices. But there is no 
problem to add something like "device_get_parent_dma_tag(device_t *dev)" that 
will return "NULL" on FreeBSD and the correct value on NetBSD. Merging these 
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 
something, it should be better. Shouldn't it be easier to port kernel 
software between FreeBSD and NetBSD?


When it comes to mutexes I want to say that FreeBSD's "struct mtx" is portable 
to NetBSD without any problems. But when a NetBSD driver is ported to 
FreeBSD, it will fall under the Giant lock, possibly forcing other parts of 
the kernel under Giant aswell. Giant is bad, because it puts a single lock on 
the kernel. Moving some piece of code out of Giant is sometimes easy, but 
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 the 
user when a function that can sleep is called, depending on the context. This 
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?


--HPS