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