From owner-freebsd-current  Fri May 10 07:45:05 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id HAA23051
          for current-outgoing; Fri, 10 May 1996 07:45:05 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA22901
          for <current@freebsd.org>; Fri, 10 May 1996 07:43:03 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id AAA17773; Sat, 11 May 1996 00:30:45 +1000
Date: Sat, 11 May 1996 00:30:45 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199605101430.AAA17773@godzilla.zeta.org.au>
To: asami@cs.berkeley.edu, jgreco@brasil.moneng.mei.com
Subject: Re: more than 32 scsi disks on a single machine ?
Cc: bde@zeta.org.au, current@freebsd.org, nisha@cs.berkeley.edu
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> * What if we don't give a damn about existing device nodes?  :-)  "Take the
> * plunge".

>Well we may try that too I guess, but I didn't want to spend hours
>trying to figure out the right mix in the /dev directory (oh devfs,
>wasn't you supposed to get rid of the major/minor numbers?), so I went 
>in with the quick and dirty hack.

You mostly preserved compatibility with the existing device nodes, provided
everything uses the dk macros and functions.

>Index: sys/sys/disklabel.h
>===================================================================
>RCS file: /usr/cvs/src/sys/sys/disklabel.h,v
>retrieving revision 1.21
>diff -u -r1.21 disklabel.h
>--- 1.21	1996/05/03 05:38:34
>+++ disklabel.h	1996/05/10 00:12:30
>@@ -374,17 +374,19 @@
>     -----------------------------------------------------------------
>     |      TYPE     |PART2| SLICE   |  MAJOR?       |  UNIT   |PART | <-soon

`soon' should have been `RSN', i.e., not soon :-).

>     -----------------------------------------------------------------
>+    |  TYPE | UNIT2 |PART2| SLICE   |  MAJOR?       |  UNIT   |PART | <-new
>+    -----------------------------------------------------------------
> 
> 	I want 3 more part bits (taken from 'TYPE' (useless as it is) (JRE)
> */

I use 6 TYPE bits in the floppy driver.  Committing this has been
waiting about 1.5 years because I don't want to rearrange everyone's fd
minors.  Please bits from the top of the original TYPE.  PART2 should be
taking from the top too.  Watch out for the scsictl bit in MAKEDEV.

> #define	dkmakeminor(unit, slice, part) \
>-				(((slice) << 16) | ((unit) << 3) | (part))
>+				(((slice) << 16) | (((unit) & 0x1f) << 3) | (((unit) & 0x1e0) << 19) | (part))

`unit' is now evaluated multiply and there are too many columns.

>...
> #define	dktype(dev)       	((minor(dev) >> 21) & 0x7ff)

This is now out of date.

>-#define	dkunit(dev)		((minor(dev) >> 3) & 0x1f)
>+#define	dkunit(dev)		(((minor(dev) >> 3) & 0x1f) | ((minor(dev) >> 19) & 0x1e0))

`dev' is now evaluated multiply and there are too many columns.

>Index: sys/etc/etc.i386/MAKEDEV
>===================================================================
>RCS file: /usr/cvs/src/etc/etc.i386/MAKEDEV,v
>retrieving revision 1.118
>diff -u -r1.118 MAKEDEV
>--- 1.118	1996/05/03 05:37:34
>+++ MAKEDEV	1996/05/10 04:47:22
>@@ -131,7 +131,7 @@
> # Convert disk (type, unit, slice, partition) to minor number
> dkminor()
> {
>-	echo $((32 * 65536 * $1 + 8 * $2 + 65536 * $3 + $4))
>+	echo $((32 * 65536 * $1 + 8 * ($2 % 32) + 256 * 65536 * ($2 / 32) + 65536 * $3 + $4))
> }

The type bits now overlap ...

>...
>+		nunit=$((($unit / 32) * 32 * 65536 + ($unit % 32)))
>...
>-			mknod r${name}${unit}.ctl c $chr `expr $unit '*' 8 + $scsictl `
>+			mknod r${name}${unit}.ctl c $chr `expr $nunit '*' 8 + $scsictl `

scsictl should have been a `type' bit.  Maybe it is :-).

>...

>What do people think?  I'm sure people will agree with Joe that
>limiting power users to 32 disks (or even less if not contiguous) will 
>seriously damage FreeBSD's reputation as a "server" OS.

>With Julian and Peter's impending modified driver coming up some time
>in the future (how long til that?  one year?), maybe we shouldn't try
>to move around things too much.

devfs should be finished so that minor numbers become irrelevant.

Bruce