Date: Wed, 7 Jun 1995 11:42:55 +0800 (CST) From: Brian Tao <taob@gate.sinica.edu.tw> To: "Jordan K. Hubbard" <jkh@freefall.cdrom.com> Cc: Peter Dufault <dufault@hda.com>, freebsd-hackers@freebsd.org Subject: Re: Install bug for big minor numbers Message-ID: <Pine.BSI.3.91.950607112026.3207V-100000@leo> In-Reply-To: <21702.802483914@freefall.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 6 Jun 1995, Jordan K. Hubbard wrote:
>
> Since the pre-BETA tarballs would only run the MAKEDEV the _first_
> time the bindist was extracted (which is fixed), did you perhaps
> install the bin installation multiple times before rebooting? That
> would solve this mystery!
Yes, that's possible... I do recall going through the bindist
extract several (dozen?) times to test out various parts of the
installer. I'm fairly sure I went through the whole disk slicing and
dicing and newfs'ing procedure with each iteration though. Shouldn't
that force MAKEDEV to be run?
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:
#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.
--
Brian ("Though this be madness, yet there is method in't") Tao
taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.91.950607112026.3207V-100000>