From owner-freebsd-hackers Mon Aug 19 20:53:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA13138 for hackers-outgoing; Mon, 19 Aug 1996 20:53:18 -0700 (PDT) Received: from precipice.shockwave.com (ppp-206-170-5-26.rdcy01.pacbell.net [206.170.5.26]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA13118; Mon, 19 Aug 1996 20:52:56 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id UAA17960; Mon, 19 Aug 1996 20:51:55 -0700 (PDT) Message-Id: <199608200351.UAA17960@precipice.shockwave.com> To: Bruce Evans cc: julian@freefall.freebsd.org, committers@freebsd.org, hackers@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_conf.c uipc_socket2.c In-reply-to: Your message of "Tue, 20 Aug 1996 11:02:21 +1000." <199608200102.LAA01327@godzilla.zeta.org.au> Date: Mon, 19 Aug 1996 20:51:54 -0700 From: Paul Traina Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From: Bruce Evans Subject: Re: cvs commit: src/sys/kern kern_conf.c uipc_socket2.c >It would be a good thing(tm) if the #define CDEV_MAJOR and >#define BDEV_MAJOR definitions were completely removed from all .c files. They should go away (when device numbers in inodes go away), so don't spend much time fixing them. >Instead, configure should read in the files config/majors and >i386/config/majors.i386 and produce a bunch of "major_xxx.h" files, >each with a #define XXX_CDEV_MAJOR values. There should be at most one majors.h file. Drivers don't need to know their own numbers, but kern_conf.c needs to know until the numbers go Yes they do! That's the rub. Lots of things in drivers call makedev(). :-( away. This can be implemented using table lookup. E.g., cdevsw_add_devsw(dev_t *dev, int bdev, struct cdevsw *dp) could have been simply cdevsw_add_devsw(struct cdevsw *dp). dp->d_name gives the name of the device, which can be looked up in a table in majors.h. It's probably not worth implementing this now, since the whole interface will have to change (all device info should be in one struct managed by devfs and this struct will be passed around instead of dev_t's or devswitch pointers. >Why am I suggesting this? Majors.XXX is not being kept up to date for thing >>s >that require fixed major numbers. I know, DEVFS and fully dynmic major >numbers fixes this. I'm not holding my breath. Neither is devices.i386 (it's missing at least ccd) :-(. Bruce