From owner-freebsd-hackers  Mon Aug 19 16:37:03 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id QAA27371
          for hackers-outgoing; Mon, 19 Aug 1996 16:37:03 -0700 (PDT)
Received: from red.jnx.com (ppp-206-170-2-24.sntc01.pacbell.net [206.170.2.24])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA27351;
          Mon, 19 Aug 1996 16:36:51 -0700 (PDT)
Received: (from pst@localhost) by red.jnx.com (8.7.5/8.7.3) id QAA23376; Mon, 19 Aug 1996 16:36:45 -0700 (PDT)
To: julian@freefall.freebsd.org (Julian Elischer)
cc: hackers@freebsd.org, committers@freebsd.org
Subject: Re: cvs commit:  src/sys/kern kern_conf.c uipc_socket2.c
References: <199608191922.MAA03012@freefall.freebsd.org>
From: Paul Traina <pst@jnx.com>
Date: 19 Aug 1996 16:36:44 -0700
In-Reply-To: julian@freefall.freebsd.org's message of 19 Aug 96 19:22:28 GMT
Message-ID: <7yvief6j5f.fsf@red.jnx.com>
Lines: 36
X-Mailer: Gnus v5.2.25/XEmacs 19.14
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

julian@freefall.freebsd.org (Julian Elischer) writes:

> 
> julian      96/08/19 12:22:27
> 
>   Modified:    sys/kern  kern_conf.c uipc_socket2.c
>   Log:
>   for kern_conf.c, start allocating dynamic major numbers
>   half way through the range rather than possibly colliding with
>   fixed elements. Increase the size of the arrays to take this into account..
>   remember that each element in the array is now only 1 ponter  so this
>   isn't that much..
>   
>   also note a possible bug in debugging code in uipc_socket2.c (add XXX)

Two suggestions relating to the same thing --

It would be a good thing(tm) if the #define CDEV_MAJOR and
#define BDEV_MAJOR definitions were completely removed from all .c files.

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 <n> values.

In addition, an optional hack (I don't love it, but WTF) is that config could
also generate a "major_used.h" file that contains a structure containing a
list of fixed major numbers not eligble for dynamic allocation.  (I like
the idea of starting dynamic major numbers at 32768 or some high number
better.)

Why am I suggesting this?  Majors.XXX is not being kept up to date for things
that require fixed major numbers.  I know, DEVFS and fully dynmic major
numbers fixes this.  I'm not holding my breath.

Paul