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