Subject: Re: PR 4094 (really about FreeBSD's approach to one aspect of the DDI/DKI)
To: NetBSD-current Discussion List <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
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)
> email@example.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
> > 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
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 <firstname.lastname@example.org> <robohack!woods>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>