Date: Tue, 29 Apr 1997 20:46:02 +1000 (EST) From: Stephen McKay <syssgm@dtir.qld.gov.au> To: freebsd-hackers@freebsd.org Cc: syssgm@dtir.qld.gov.au Subject: Re: disklabel -- owner? Message-ID: <199704291046.UAA28580@ogre.dtir.qld.gov.au>
next in thread | raw e-mail | index | archive | help
Jason Thorpe <thorpej@nas.nasa.gov> wrote: >On Thu, 24 Apr 1997 20:25:18 +1000 > Bruce Evans <bde@zeta.org.au> wrote: > > > Strangely enough, NetBSD supports up to 22 partitions. > >...well, that's MAXMAXPARTITIONS ... i.e. any more, and you don't fit >in a DEV_BSIZE block. Most NetBSD platforms set MAXPARTITIONS at 8. > >There's actually a good reason to NOT change this on existing platforms.. >You screw minor number compatibility with existing installed base. That's >annoying, at least. I'd classify it as stupid, personally :-) I don't feel an overwhelming desire to preserve my device numbers. Though if people must keep backward compatibility, discontiguous bits can be manipulated by dkpart() and friends. If 8 or less partitions are allocated, the disk should be physically and logically portable to other machines and/or BSD operating systems. As Bruce pointed out, the format should already support up to 22 partitions if we had enough bits allocated in the minor device number. On a related topic, the disk device numbers are arrange in an ugly way, presumably for backward compatibilty reasons. Are these reasons still valid? The current "type / unit2 / slice / major / unit1 / part" could be rearranged to "major / unit / slice / part" (I don't know what "type" is here. Grep didn't help me either.). Oh, and the existing dkmakeminor() doesn't handle unit > 31, though dkunit() does. I presume nobody has 32 or more disks. I haven't! Stephen.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704291046.UAA28580>