Subject: Re: The demise of DEV_BSIZE
To: None <email@example.com, firstname.lastname@example.org>
From: Chris Torek <torek@BSDI.COM>
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).