confused by char dev registration in a gpio driver

[Greg KH]

On Fri, May 13, 2011 at 11:05:08AM -0600, Jim Cromie wrote:
> On Tue, May 10, 2011 at 12:40 PM, Greg KH <greg at kroah.com> wrote:
> > On Tue, May 10, 2011 at 11:26:59AM -0600, Jim Cromie wrote:
> >> lets start with a list of grumbles about current api ?
> >>
> ...
> >> Are the insanities you alluded to of a different sort,
> >> ie internal suboptimalities ?
> >
> > No, those you have listed are all things I was talking about.
> >
> > And yes, there are also some internal issues as well (see the kobject
> > mapping stuff).
> 
> >> static struct char_device_struct {
> >> ...} *chrdevs[CHRDEV_MAJOR_HASH_SIZE];
> >> ie 255 elements.
> >>
> >> This is  == to legacy MAJOR number space,
> >> and is scanned 255..0 to find unused MAJOR number.
> >> It will need new const if MAJOR range increases,
> >> but doesnt waste much memory currently
> >>
> >> My 32bit laptop uses 48 devices, so ~200 major slots are
> >> empty/wasted (800 bytes) and ISTM like over-engineering
> >> to fix this preemptively if >255 is unneeded.
> >> OTOH, a hash or rb-tree could use only whats needed.
> >> is there a 'library' hash implementation in the kernel ?
> >
> > The kobject map stuff should handle most of this, but really, 800 bytes
> > isn't that much overhead for the speed you get, right?  Changing the
> > code to use something else would take more than 800 bytes from what I
> > can see.
> >
> 
> cool.  Im pleased that I agree with you :-) regarding the 800 byte cost.
> 
> but is speed even an issue ?
> registering char drivers isnt exactly a hot path.
> of course, simplicity is good too..

Speed is an issue on open() for some things, so yes, it can be
important (meaning, don't make it a linked list that you need to walk
all of them to find the last character device in the system if opening
just that one.)

> > Let's get the api fixed up first, that's the most important thing as
> > it's what people use all the time.
> >
> 
> Ive gone and done this.
> Im currently messing with coccinelle / spatch to try to automate
> the API - user conversion.
> will send when the spatch transforms are a bit more sane.

Ok, sounds good, looking forward to it.

> > I'm going to have some long-distance flights soon, so I'll try to work
> > on this then, thanks for the great summary above, I appreciate it.
> 
> Hope Ive beaten you to it,
> or hold off on actually doing the work

Well, my trip isn't for another week or so (depending on some changing
plans), so you might beat me to it, which is fine with me :)

thanks,

greg k-h