Subject: Re: should the shift & block size be seperate, was The demise of , DEV_BSIZE
To: Chuck Silvers <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 10/06/1999 11:59:46
On Wed, 6 Oct 1999, Bill Studenmund wrote:
> On Tue, 5 Oct 1999, Chuck Silvers wrote:
> > On Tue, Oct 05, 1999 at 05:20:09PM -0700, Bill Studenmund wrote:
> > well, after all the hoo-ha last time, I was convinced that it wasn't worth it,
> > but you seem keen on it so I'm not going to argue. if you could combine
> > the two values somehow (eg. having a negative shift represent a size or
> > vice-versa), that would mean only one extra argument everywhere instead of
> > two, which is the main thing I don't like about the way you've described.
I've looked at the code, and I kinda like having everything in one shift
value. So non-PO2 block sizes are negative #'s, and PO2 block sizes are
positive shift values.
The only place which will suffer is in the VBLK path of spec_read() and
spec_write(), as it will have to recalculate the block size from the shift
each call. AFAICT, they are only called when you read & write a block
device node (like you dd to /dev/sd0a). Filesystems won't care.
A bunch of the mount calls will also need the block size from the shift,
but they are called only once, so I'm not so worried about them.
The win would be we won't have to fetch mnt_bsize to feed the btodb() or
I'm going with one value, so spec_read() and spec_write() will loose a
little, but wanted thoughts.