On 5 Oct 1999, Chris G. Demetriou wrote:

> Bill Studenmund <wrstuden@nas.nasa.gov> 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
> something."
> 
> 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. :-)

Take care,

Bill