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

On Thu, May 25, 2006 at 09:34:45AM -0700, Bill Studenmund wrote:
> 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.
>=20
> 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 cde=
v=20
> and bdev tables.

Well, "obsolete", or "compat_something", it's about the same.

> > 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.
>=20
> 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.

It should always be "compat_something", but I'd rather avoid hard-coding
any knowledge of that in config(1) or MAKEDEV.awk.

> > 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.
>=20
> Hmmm...
>=20
> 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.

There are lots of parts that do that, yes, but I think most of them are
in control of the driver (e.g., either it has already done the
translation, or for instance when it is passed a bp, it knows what is
the canonical major and therefore can do the translation).

The rootdev/dumpdev stuff will use canonical numbers (as long as
config(1) manages to DTRT in that area).

I think we'd only really get into potential trouble when you find _both_
entries as device nodes, in which case I guess buffer cache and stuff
like that might be duplicated, but that will not happen unless the admin
has fucked up something.

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.

--LmUdgXdNLPkN/XLh
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iQEVAwUBRHXumdgoQloHrPnoAQK35Af/aagss6vq++xJJrrHWQfxW29ZKthJS1q4
Vb7Ayukl/Akz69LHsugODlx4qc2nUXyyBYIjSJeBHuu6nLiyFEOnrZZ/noL4xJxy
VS2jxPbmLqcY095hH/ZDN0qrJlDVBxk2ol4dDwyZJq4KoFzCI6aGM9WKX1lpIWT9
dB+EoQG/gcR0R0IKtrUbW/BzD/279313gZOH/OvPTpbEJMlkUBaJhZ9smEOSpSDw
Zs8+aHxSaIllL71poJkGzd7KQfxgLC/0d0Ngy2Ni43kJsgZIoPdXp3nFEY5Qrtsc
0dILTOPQPWqlERMwHiWidgAKW2RTlSgXf4IsLnN3MopUi8WOi5Xf7A==
=PnS1
-----END PGP SIGNATURE-----

--LmUdgXdNLPkN/XLh--