Subject: Re: The demise of DEV_BSIZE
To: Chuck Silvers <chuq@chuq.com>
From: Bill Studenmund <wrstuden@nas.nasa.gov>
List: tech-kern
Date: 10/06/1999 09:57:04
On Tue, 5 Oct 1999, Chuck Silvers wrote:
> On Tue, Oct 05, 1999 at 05:20:09PM -0700, Bill Studenmund wrote:
>
> well, after all the hoo-ha last time, I was convinced that it wasn't worth it,
> but you seem keen on it so I'm not going to argue. if you could combine
> the two values somehow (eg. having a negative shift represent a size or
> vice-versa), that would mean only one extra argument everywhere instead of
> two, which is the main thing I don't like about the way you've described.
My only concern with that is that block sizes being represented as
negative numbers. :-) But you're right that something like that would get
us down to one argument, and the btodb and dbtob macros would deal
correctly.
> > 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. :-)
>
> slightly more setup goo in exactly two places, at the cost of adding
> another devops interface that doesn't apply to all devices when there's
> an existing interface that will work perfectly well.
I don't understand the reluctance about adding a devops interface. :-) We
already have a number of them which only apply to a subset of devices (for
instance, how many times have you mmap'd a tty, or gotten a struct tty *
for a raw disk device :-) ). And this goo will be hit every time we create
a new device node, since it's called from checkalias. While it's not a
super-high traffic code path, I'd rather not make things slow..
Also, this call struck me as being a lot like the d_psize call. :-) I also
modified all of the [bc]dev_foo_init macros so that everything other than
disks set this field to 0, which the get[bc]devsize routines know means
use -1.
> actually you could just pass in the function pointer to getdevsize() and
> then there would be only one copy of the setup goo.
>
> the naming daemon in me insists I suggest [bc]dev_getsize()
> (or dev_getsize() if you combine the functions). :-)
That sounds fine. :-)
Take care,
Bill