On Tue, 5 Oct 1999, Chuck Silvers wrote:

> cool.  I had a start on this in the UBC branch, but I'm glad someone else
> is doing the rest of it.  I have a few comments:
> 
> 1.  do we really want to pretend to support non-power-of-two devices at all
>     in the device interface?  we kinda went thru this when this whole subject
>     came up before, and I thought the consensus was that it wasn't worthwhile.

Ick. That wasn't the consensus I took away from the previous thread. I
thought the idea was that if supporting non-power-of-two devices meant we
had to divide all the time in dbtob() and btodb(), THAT would be bad.
whenever possible we want to avoid those divides.

But if we could have the non-PO2 support without loosing the bit shifting
ability, we'd be fine.

By using a shift value, and rolling over to multiply and divide when its
0, I thought we could have the best of both. :-)

> 2.  do we really need a (*d_bsize)() ?  I recall that there was already a
>     device ioctl that returns this info... or maybe I was just thinking
>     that that's how I'd do it eventually.

I don't remember seeing such an ioctl. The advantage of this routine is
that the setup for the caller is simple - get[bc]devsize take a dev_t &
look this routine up in the [bc]devsw tables. So checkalias gains:

                } else if (nvp->v_type == VBLK) {
                        getbdevsize(nvp_rdev, &nvp->v_specbshift,
                                                &nvp->v_specbsize);
                } else {
                        getcdevsize(nvp_rdev, &nvp->v_specbshift,
                                                &nvp->v_specbsize);
                }

and the meaty part of these routines is just:

		(*bdevsw[major].d_bsize)(dev, bshift, bsize);

If we did an ioctl, the meaty setup would be more. We could do it, but
this is the way the info is going to be used anyway. :-)

> 3.  I'm not sure what "swap blocks" are, but I would guess they should
>     be in pagesize units, since that's how swap space is managed.
> 
> 4.  I'd think the goal should be to get rid of DEF_BSIZE eventually too.
>     purely software devices like md can define their own constants.
> 
> 5.  perhaps the sector size info in the on-disk disklabel should be
>     ignored and replaced with the info from the device itself?
>     there are probably further disklabel implications to all this.

Not sure. See Chris's reply about this too.

Take care,

Bill