From owner-freebsd-hackers  Wed Jun  7 02:32:30 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id CAA11207
          for hackers-outgoing; Wed, 7 Jun 1995 02:32:30 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA11199
          ; Wed, 7 Jun 1995 02:32:21 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA10819; Wed, 7 Jun 1995 19:25:40 +1000
Date: Wed, 7 Jun 1995 19:25:40 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199506070925.TAA10819@godzilla.zeta.org.au>
To: jkh@freefall.cdrom.com, taob@gate.sinica.edu.tw
Subject: Re: Install bug for big minor numbers
Cc: dufault@hda.com, freebsd-hackers@freebsd.org
Sender: hackers-owner@freebsd.org
Precedence: bulk

>    I would rather see the /dev entries completely removed from the
>tarball and have MAKEDEV run unconditionally (I don't find it takes
>*that* long, compared to tarball extraction).  Or fix tar so that it
>handles large minor numbers.  Poking around in port.h (of the tar
>sources), I see:

Tar can't handle large minor numbers.  The format has only 6 octal
digits so it can only handle 18 bits (what a waste of 6 bytes).
The default cpio format can only handle 8 bits.

>#define minor(dev)  ((dev) & 0xff)

>   ... where in <sys/types.h> they are declared as:

>#define minor(x)    ((int)((x)&0xffff00ff))     /* minor number */

>    The define is bracketed by an #ifndef HAVE_MAJOR, so it may not
>be called at all, but I haven't tried it.  It just looked like an
>obvious candidate, with the conflicting bitmasks.

tar uses the right define.  For total brokenness, see the pax sources.

Bruce