Re: static functions are your friends (Was GPIO revisited)

[Adam Hoka <adam.hoka%gmail.com@localhost>]

On Sun, 9 Aug 2009 19:12:56 +0200
Marc Balmer <marc%msys.ch@localhost> wrote:

> 
> Am 09.08.2009 um 19:11 schrieb Adam Hoka:
> 
> > On Sun, 9 Aug 2009 19:03:26 +0200
> > Marc Balmer <marc%msys.ch@localhost> wrote:
> >
> >>>>>> One more comment...
> >>>>>>
> >>>>>>> +int    gpio_pinbyname(struct gpio_softc *, char *gp_name);
> >>>>>>> +
> >>>>>>> +/* Old API version */
> >>>>>>> +int    gpio_ioctl_oapi(struct gpio_softc *, u_long cmd, void
> >>>>>>> *data, int flag,
> >>>>>>> +    int pinset);
> >>>>>>>
> >>>>>>> KNF: no variables names in the declaration.
> >>>>>>> Also, any reason why these are not static?
> >>>>>>
> >>>>>> While it certainly can make sense to declare functions static in
> >>>>>> some userland programs for the sole reason to include a command
> >>>>>> in a crunched binary, it does not make sense in kernel code; much
> >>>>>> to the contrary, it makes debugging harder.
> >>>>>
> >>>>> static functions make great sense in kernel code.  In fact, we
> >>>>> have too many public functions as is and even more of the kernel
> >>>>> should be using static.
> >>>>>
> >>>>> When a component only has a relatively small on entry points, it
> >>>>> allows the compiler to treat the component as one single unit to
> >>>>> compiled.  This allows it to inline, follow the scope of
> >>>>> variables, and lots of other thing to generate better code.
> >>>>>
> >>>>> The other reason to use static it prevents code from calling your
> >>>>> function that should never have never called it in the first  
> >>>>> place.
> >>>>
> >>>> I want to quickly come back to this and explain my reasoning for
> >>>> not making all functions static in the kernel, although I am
> >>>> totally aware of all the positive effects of static in general.
> >>>>
> >>>> I do mostly low-level driver development, something where you see
> >>>> the ddb prompt more often than you like...  Now with the functions
> >>>> not being declared static, the trace command is my friend, I see
> >>>> immediately in which function my driver crashed, this is an immense
> >>>> debugging aid.
> >>>>
> >>>> I took the time to write a function that crahses the kernel on
> >>>> purpose.  Compiled as non static function, ddb showed me the
> >>>> function name and function call trace with proper function names.
> >>>> Quite easy to locate the faulty spot.  To complete my test, I
> >>>> compiled the very same code with all functions declared static.
> >>>> Now the ddb trace does not show me the function names, making it a
> >>>> lot harder to locate the faulty spot.
> >>>
> >>>
> >>> Can you show code which worked and not worked with static function
> >>> declarations. I'm pretty sure that this works
> >>> for me for a long time.
> >>
> >> We can consider this issue solved.  I can declare my functions as
> >> "__noinline static ...." and have both the benefits of a static
> >> declaration and the function name show up in ddb's 'trace' command.
> >>
> >> I will slowly convert my code to this idiom, if no one objects.
> >
> > And later on we could unify this as a macro maybe.
> >
> 
> why a macro? well, I know we like macros here, but still?
> 
> 

Maybe other compilers dont grok __noinline or someone wants to make them
inline anyway, who knows. :-)

-- 
Adam Hoka <Adam.Hoka%Gmail.com@localhost>
Adam Hoka <ahoka%NetBSD.org@localhost>
Adam Hoka <ahoka%MirBSD.de@localhost>