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

Hi folks,

On Thu, May 11, 2006 at 03:21:31PM +0200, Quentin Garnier wrote:
> On Thu, May 11, 2006 at 07:55:16PM +0900, Izumi Tsutsui wrote:
> > rjs@fdy2.demon.co.uk wrote:
> >=20
> > > YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp> wrote:
> >=20
> > > >> Modified Files:
> > > >> 	src/sys/arch/hpcarm/conf: files.hpcarm
> > > >>=20
> > > >> Log Message:
> > > >> Remove majors.arm32.
> > >=20
> > > >what's the purpose of recent changes here?
> > >=20
> > > To fix this:
> > >=20
> > > http://mail-index.netbsd.org/port-hpcarm/2006/05/07/0000.html
> >=20
> > Then you should fix src/etc/MAKEDEV.awk, not files for config(9).
>=20
> Actually, I think config(1) should help building the list.  I find
> awkward that several things has to parse files used by config(1).
>=20
> Another thing I wonder is what to make of duplicate device-major
> entries, as I intend to make use of that in the future.  Both "same
> name with different number" and "same number, different name" have a
> valid use:  the first one because it allows compatibility while changing
> the way a device allocates its minor numbers (I plan to use that to
> make disk devices behave the same way on all archs), the second one
> because it allows generic declaration that might be overriden by
> subarchs (because the kernel configuration will only select the
> relevant one).
>=20
> 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.

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.

"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.

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:

include "arch/i386/conf/std.i386"
no options COMPAT_30

While in other areas we'd have:

(conf/majors)
device-major	sd		char XXX block XXX	sd

(arch/i386/conf/majors.i386)
device-major	sdcompat	char 13  block 4	sd & compat_30

So that no output would be produced for the "sdcompat" entry.

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.

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.

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.

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.

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.

OTOH, on amd64, the same structure should be used, as no translation
would be needed.

Yes, yes, I know, devfs.  If you have a devfs implementation to submit,
then please do, otherwise any mention of it is outside the scope of
this thread.

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

--FmdPcZLZZW6lDAYm
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iQEVAwUBRHV2P9goQloHrPnoAQIJ+QgArDttI4oIUpjHaQkZntmvg/Uv0/5I8VCr
dN8t6TMInV9lcG26hT5J1hNt4GNUvmiQ1QlzvzuhRqygaS6rwl4O08Hcr9/VOArI
BwJyEwFrRJJ8VTgx1hRv4/KGVryhaNTq9JfCVm4RHJf2QFlzQG91bD9oCxHVBsmr
PGX0E1H5W3Hze1/FACv2B05/TSQMiS4/YHkl2jmjkpP6b1rfafLzW9DPOtUzT7zE
D1CEotUvuJRJD8SDXzDT0IYBMCh7d109pMdVxnbTHweJUgi7v8YBhA3equDB/Mv2
gO3p0Wur4b18ExmYPt7FT1iRhdREcoPKzeXX34BpKNlgchIJ89Ivkg==
=joUd
-----END PGP SIGNATURE-----

--FmdPcZLZZW6lDAYm--