Subject: Re: The demise of DEV_BSIZE
To: Chris G. Demetriou <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 10/05/1999 17:47:46
On 5 Oct 1999, Chris G. Demetriou wrote:
> Bill Studenmund <email@example.com> writes:
> > 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. bshift == -1
> > indicates that the device isn't configured.
> If you must add such a function, it would seem to me at least that
> returning an error (i.e. having a return value, and using it) if the
> device wasn't configured would be better than what you propose
> above... 8-)
My first version had an error value. :-) Then I realized that this routine
isn't, "tell me the block size for this device," a routine for which an
error make sense, but more, "what should I put in my struct specinfo for
this device." The latter defenition makes sense without an error code.
This routine gets called almost exclusivly in checkalias() (well
checkalias() calls get[bc]devsize() which calls this) when we are filling
in the struct specinfo for a vnode. checkalias() can't return an error.
And even if it could, ls -l should still work on non-configured devices.
If there's a consensus, we could have it return an error code. But since
we still have to put SOMETHING into the struct specinfo, I thought this
would be the most direct approach.
> > disklabel writing needs work in that we shouldn't accept a disklabel which
> > we know is not the device's block size. i.e. for sd & cd drives, we can
> > querry the device to see what it's block size is. We shouldn't let you set
> > a disklabel with a different block size.
> I'm not sure i believe this.
> It's _nice_ to be able to e.g. take a CD-ROM image and dd it on to a
> disk, and try it out.
Yeah, that would be nice. I hadn't thought of it.
> I think there might be some argument that "disklabel block size must
> be pow2 multiple of real block size, and disklabel block size is used
> to convert partition offsets into units of 'real' blocks or
> But just breaking this is probably the wrong thing to do.
Well, it doesn't work now, so we're not "breaking" it. :-)
I think this would be fine, now that you mention it. We'd have to be
careful about when we use disklabel blocks and when we use device blocks,
but I think we can do it. :-)