confused by char dev registration in a gpio driver

[Jim Cromie]

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..

> 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.

> 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

>
> thanks,
>
> greg k-h
>