Todd Vierling <tv@pobox.com> said:

} On Tue, 1 Dec 1998, Ken Hornstein wrote:

} : >The major difficulty is that it means a bit of a flag day (fortunately
} : >not a serious one, not nearly as much so as the 16-partition changes),
} : >and breaks compatability with pre-change binaries.  Anyone have
} : >thoughts on when and how - and even whether, I suppose - such a thing
} : >should go in?

} : It seems the easiest thing to do would be to simply create new system
} : calls and version the old ones (statfs13, fstatfs13, and getfsstat13,
} : I think).  This would get rid of any binary compatibility problems.
} : What does everyone else think?

} If you're changing a structure, this is required action, not "a better way
} to do it".  Version them.

On a somewhat related flag day note, how much of a flag day would changing
major and minor sizes cause? As part of the startup for an LVM driver for
NetBSD, I'm trying to figure out how to get the driver to tell the device
files for each logical volume. On most OSes with LVMs, they use 8 bits
of the minor number to hold the logical volume number, and then 4 or more
bits to identify the LV's volume group.

>From what I've seen, NetBSD uses an 8 bit major and an 8 bit minor,
which means that I have to use something other than the minor number to
tell the difference between 255 logical volumes * X volume groups.

What kind of pain would be involved to a move to either 16 bit major numbers
and 16 bit minor numbers, or even 8 bit major/24 bit minors numbers like
HP and others use?

Thanks,
David

--
David W. Rankin, Jr.    Husband, Father, and UNIX System Administrator
  Email: rankind@iglou.com  Phone Number and Address Upon Request
    "Programming is like sex; one mistake and you support it for a
       lifetime." -- unknown (to me)