Subject: Re: The demise of DEV_BSIZE
To: None <,>
From: Chris Torek <torek@BSDI.COM>
List: tech-kern
Date: 10/06/1999 01:14:56
I am sure all this was argued before (I missed it all, which is
probably just as well :-) ) but I happen to like "byte offsets"
for struct-buf-values.  But, never mind that :-) , I just have
one or two real comments on this.

>Both character and block devices have gained a new function call, d_bsize:
>void    (*d_bsize)      __P((dev_t dev, int * bshift, int * bsize));
>which fills in the bshift and bsize values for a device.

You do not need both (and as cgd noted, "unconfigured device" seems
like it should be an error-return).  The reason you only need one
is that all you need is the number of blocks.  The caller can
translate that into a shift if appropriate, e.g.:

	ispow2 = (size & (size - 1)) == 0;
	shift = ispow2 ? ffs(size) - 1 : 0;

>We can't totally get rid of DEF_BSIZE. In addition to a few cases where we
>really need a DEF_BSIZE (md and memory disks come to mind - there's no
>underlying block size from which to determine values),

Why not have these report whatever size they like?  A memory-disk
could even have a programmable block size, if only for testing the code.

>For instance, UFS keeps track of "blocks" allocated to a file in
>units of DEV_BSIZE. I've changed this to UFS_BSIZE & UFS_BSHIFT.
>ufs quotas are in the same unit.

This seems right.  POSIX probably requires 512 (if it says anything
at all about this).