Subject: Re: PR 4094 (really about FreeBSD's approach to one aspect of the DDI/DKI)
To: NetBSD-current Discussion List <current-users@netbsd.org>
From: Greg A. Woods <woods@most.weird.com>
List: current-users
Date: 12/10/1998 22:22:58
[ On , December 10, 1998 at 17:39:45 (-0800), Chris G. Demetriou wrote: ]
> Subject: Re: PR 4094 (really about FreeBSD's approach to one aspect of the DDI/DKI)
>
> woods@most.weird.com (Greg A. Woods) writes:
> > somewhere near the top of sys/i386/isa/fd.c:
> > 
> > 	#define CDEV_MAJOR 9
> > 	#define BDEV_MAJOR 2
> 
> of course, this ... doesn't work so well when you've got a driver
> being shared by multiple architectures, each of which (for
> compatiblity reasons) has a different device switch ordering...
> 
> you then devolve into, basically, another conf.c mess, but possibly
> distributed across all files.

Oh, I fully agree, which is why I say you need that last bit of "glue"
in the build process so that these numbers are pulled out of a canonical
table and are *not* supplied by the driver author.

All schemes I've ever seen to date that require keeping multiple lists
of what goes into cdevsw/bdevsw in sync have always bugged the heck out
of me, especially when the solution has always seemed so obvious to me....

I think of all the kernels I've ever developed device drivers on, only
AT&T SysVr3.x got most of the way past this hurdle, though I don't
remember the details on how their scheme worked and my AT&T DDI/DKI
manuals are still packed away in the garage....

> Furthermore, in a scheme like that, where can you go, in the kernel
> source, to find out what the complete list of device major/minor
> numbers is?

Why not just go to that same canonical table listing all major/minor
numbers?

> > I don't remember exactly how it all fits together under the hood though,
> > and it would seem they are changing some of this again since the 3.0
> > release, perhaps to add that missing bit of glue which would ensure
> > there's only one place where device numbers are defined.
> 
> ... even if you do this, unless you renumber all device tables (an
> option which Charles may have effectively killed, by expanding the
> device number macros before all issues were considered) and force all
> ports to have the same one, you still end up needing multiple "one
> place"s.

Not at all.  Each port would have its own sys/arch/conf/majors file.

In fact I think FreeBSD does this already, though it's not entirely
obvious since their current sources are missing that one last bit of
"glue" in the build process that I keep talking about.

Of course with the table of device numbers one could teach config(8) to
build conf.c, but I like the idea of dynamic registrations, not only
becuase it makes implementing DEVFS easier, but because it makes a whole
lot of things cleaner and more elegant, esp. if you want to support LKMs
that install drivers, and such.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>