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

On Thu, May 25, 2006 at 11:17:51AM +0200, Quentin Garnier wrote:
> Hi folks,
>=20
> On Thu, May 11, 2006 at 03:21:31PM +0200, Quentin Garnier wrote:
> > For the first scheme, MAKEDEV should only contain the entries that are
> > not there for compatibility;  for the second, I don't know right now
> > how to teach MAKEDEV what is the relevant entry...  I need to think of
> > that some more.
>=20
> I've thought of that a bit more. "Same number, different names" is not
> really an issue for now, what we want is to produce a "name -> number"
> table, we don't really care about the reverse.
>=20
> "Same name, different numbers" is more problematic.  We have two
> choices, here:  either we forbid using the same name twice (and e.g.,
> when we allocate a MI number for sd(4), have the previous entries
> renamed "sdcompat"), or we use a specially crafted config file that
> config(1) will parse to select the necessary options to output a
> MAKEDEV.

Actually, I think a better thing would be that if we have the same name=20
repeated, all but one occurrence must be flagged "obsolete" or something=20
to that effect. If an entry is "obsolete" (however we choose to express=20
that in the config syntax), then it doesn't go into MAKEDEV, only the cdev=
=20
and bdev tables.

> I actually think of it more as "unselecting" options, having them all
> implied by default.  For instance, the "config.majors" file for i386
> would be something like that:
>=20
> include "arch/i386/conf/std.i386"
> no options COMPAT_30
>=20
> While in other areas we'd have:
>=20
> (conf/majors)
> device-major	sd		char XXX block XXX	sd
>=20
> (arch/i386/conf/majors.i386)
> device-major	sdcompat	char 13  block 4	sd & compat_30
>=20
> So that no output would be produced for the "sdcompat" entry.

Hmmm... I haven't thought about the kernel option issues. To be honest,=20
I'm not sure if we really need a way to drop old entries from the table,=20
but maybe you're right, we do.

> Adding a flag to config(1) to output a relevant table to be parsed by
> a changed MAKEDEV.awk is a SMOP, but I'd like to have some input on the
> proposal before.
>=20
> Note that the "config.majors" thing would offer a way to solve the
> "Same number, different names" issue too, because if the conflicting
> names are left out, they won't get entries in the final MAKEDEV script.
>=20
> The reason why I'd like to avoid forbidding the use of a single name for
> several major numbers is because I'd rather avoid extra _{c,b}devsw
> structures when they're not needed.
>=20
> For instance, take the case that is the actual reason I do all this:
> amd64 vs. i386 on sd.  The MI sd(4) would have a "flat" minor number
> allocation scheme, just like amd64 already has.
>=20
> Therefore, there would be a "sdcompat" entry for i386, with a different
> _{c,b}devsw structure.  It would only contain wrappers to change the
> minor and major numbers to the new values.

Hmmm...

I think the problem I see with that is that the driver isn't the right=20
place for this AFAICT, as lots of parts of the kernel go looking at the=20
minor numbers and units & such. So that while we will need some sort of=20
compat driver, we will need to play major/unit/partition games elsewhere.

Take care,

Bill

--NMuMz9nt05w80d4+
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFEddylWz+3JHUci9cRAmo4AJ9GiCgM9lFHAOL+PGfAFnYNB2rH8gCdGfuY
xjs/lb7J5ZCD72HdwsjQ1X4=
=IVdN
-----END PGP SIGNATURE-----

--NMuMz9nt05w80d4+--