Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
From: Hans Petter Selasky (hselasky_at_c2i.net)
Date: 10/28/05
- Previous message: John-Mark Gurney: "Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x"
- Maybe in reply to: Hans Petter Selasky: "FreeBSD 5/6/7 kernel emulator for NetBSD 2.x"
- Next in thread: Bill Studenmund: "Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: tech-kern@netbsd.org, freebsd-hackers@freebsd.org Date: Fri, 28 Oct 2005 01:27:49 +0200
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
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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
- Previous message: John-Mark Gurney: "Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x"
- Maybe in reply to: Hans Petter Selasky: "FreeBSD 5/6/7 kernel emulator for NetBSD 2.x"
- Next in thread: Bill Studenmund: "Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
