--i0/AhcQY5QxfSsSZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 03, 2006 at 09:06:42AM +0100, Quentin Garnier wrote:
> On Mon, Jan 02, 2006 at 06:55:30PM -0800, Bill Studenmund wrote:
> > On Sun, Jan 01, 2006 at 02:32:00AM +0100, Quentin Garnier wrote:
> [...]
> > We already effectively do this; we resolve the major & minor at open.
>=20
> No.  Calls to {c,b}devsw_lookup are done at each call (for a good reason
> anyway;  a LKM can disappear).

You're right we do the lookup many times. It's not because an lkm can=20
disappear though. Historically lookup was a walk of a static table, so=20
fast, so it didn't matter if we did it a lot. Now we do the lookup, which=
=20
was an easy code conversion.

> > > Of course, there's still the solution of changing the way minor numbe=
rs
> > > are allocated in either arch.  But it would get us a lot of angry
> > > users...
> >=20
> > Unfortunately it's too late.
>=20
> That's not a positive way of considering the issue.

Well what do you expect? :-)

The problem is that we have to make a decision based on information we=20
don't really have, which is what architecture the /dev was for.

> > The problem with what you propose is that you're assuming that amd64=20
> > binaries will only see amd64 /dev, and i386 binaries will only see=20
> > i386 /dev. Thus we can convert based on emulation. However if we only h=
ave=20
> > one /dev, which is what we would need to do to boot an amd64 kernel ove=
r=20
> > an i386 partition, we lose. The problem is that we need to know what ki=
nd=20
> > of /dev we have, not what kind of binary is opening it. :-(
>=20
> There are two main cases to consider:
>=20
> 1.  User wants to boot an i386 system with an amd64 kernel (and please
>     note that with the VM_TOPDOWN patch I sent on the port-amd64 list
>     yesterday, we gain 1 GB of virtual space by using COMPAT_NETBSD32
>     instead of NetBSD/i386, so it can matter in some situations).
>=20
> 2.  User wants to use a limited number of i386 binaries in an amd64
>     environment.
>=20
> Case 1 means we have to make the assumption COMPAT_NETBSD32 binaries
> will only see an i386 /dev (which will be the only one in the system).
>=20
> That means that in order for case 2 to still work, we'll require that
> one step of the COMPAT_NETBSD32 setup is to populate /emul/netbsd32/dev
> with i386's MAKEDEV.  Through the compat rewrite of path, i386 binaries
> will get the correct path and access the correct device.

I really think /emul/netbsd32/dev is a bad idea. It's one thing if we=20
really really have to have a different node or set of nodes either for a=20
chroot or for another OS that does something VERY weird, but I do not=20
think the use you describe warrants it for our own nodes.

I think a far better solution is add an option to the amd64 (and i386)=20
sysinst so that it can optionally set up the /dev is magic symlink trick,=
=20
and have sysinst figure out what /dev was made for (look at {r,}wd1* and=20
you can tell real quick), move that dev out to /dev.whatever, and make a=20
new /dev.other.

I really think that if we do anything other than require that the device=20
entries in /dev exactly match the running kernel, we will end up with a=20
mess later on.

We're cleaning up after one hack, let's not do it by adding another.

Take care,

Bill

--i0/AhcQY5QxfSsSZ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFDutO3Wz+3JHUci9cRAgvdAJ9Hzl6ggvFw3MS/O4UhaoAyxoMYBwCeJopZ
rd/0cC3B+VuumxaVnQ+Ic1w=
=1q1m
-----END PGP SIGNATURE-----

--i0/AhcQY5QxfSsSZ--