Subject: Re: major device number assignment
To: Jaromir Dolecek <jdolecek@NetBSD.org>
From: Quentin Garnier <cube@cubidou.net>
List: tech-kern
Date: 10/16/2005 23:11:54
--Vhqu5qQ3bjg0ZI9i
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Oct 16, 2005 at 10:57:23PM +0200, Jaromir Dolecek wrote:
> On Fri, Oct 14, 2005 at 07:56:25AM +0200, Quentin Garnier wrote:
> > On Fri, Oct 14, 2005 at 03:33:15PM +1000, Simon Burge wrote:
> > > john heasley wrote:
> > >=20
> > > > I'd like to add twe to the alpha port.  Do I attempt to keep the ma=
jor number
> > > > the same as other ports, or just allocate the next available number=
?  sparc*
> > > > & arm unnecessarily use different majors for twe.
> > >=20
> > > I'm pretty sure that entries in sys/conf/majors can be overriden by
> > > arch-specific entries, so just add it to the end of the former file
> > > and it should effect any existing archs that use twe.
> >=20
> > They're not overriden;  they just co-exist.  Both major numbers will be
> > valid on archs that already provide a major number for that device.
>=20
> Is that really the case? I thought a device can have at most one
> major number assigned, and that it's not possible to assign different
> major in sys/conf/majors and sys/arch/*/conf/majors.*. For example,
> cdevsw_lookup_major() et.al. works with exactly one major.

No.  cdevsw_lookup_major() returns the relevant entry from a switch
table.  Several entries (i.e., several major numbers) can point to the
same cdevsw structure.

My point was, there is nothing currently in the tree preventing multiple
major definitions in files.*, and preventing such a setup to work.

devsw_attach might complain in some case (actually, it will get
confused a bit by the _conv table, but not to the point of failing in
any way I think), but it is not used with config(1)-generated data.

Whether or not this situation is a good thing or not is another issue.

> Effectively once a device has a major assigned within arch-specific
> for some arch, it must have arch-specific major also for any new
> architecture, AFAIK.

That's the political aspect of the issue.

I can add code in config(1) preventing that.  Just ask.  But maybe we
want the fact that they can co-exist, though that would require more
checks in MAKEDEV.awk to make sure it takes the generic values always,
so that the arch-dependent value stays there for compatibility.

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

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

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

iQEVAwUBQ1LCGtgoQloHrPnoAQI/nwgAvqpD5LGINclro49TX4fUGNIc5zvkMoKm
u86OBMX2Y6I1ZkAxP2PBbKvhyPd689rhgsElq+QBbJVU8Mro3GDpa8fDB5ey5nBe
ewuVX0ZgQtzSskqp7MXk9hQwrk2LsGe7jg2XUoTuVzKhj6r5GQQCG0s4abZ+x8qv
IgAx9UaWrnqkmu6IpT4K1QW9QBBtcEV9WQQwEpxHJlAMdmojYeg5UA4OHrgMFLi7
0yDAysXZmFjHYuvSzOQePnfNJ6ohxs3KgpPyl2+6fy41xlWAN9MxGC1YVDpSnn2j
D4ON7SvbXa+gdWnDfUGF1HzrUp3YDlOlcg/4njMraZIp3v+AGi1dMA==
=cET0
-----END PGP SIGNATURE-----

--Vhqu5qQ3bjg0ZI9i--