lkml.org 
[lkml]   [2008]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 1/3] genclk: add generic framework for managing clocks.
Date
On Sunday 13 July 2008, Andrew Morton wrote:
> On Sun, 13 Jul 2008 14:12:32 -0700 David Brownell <david-b@pacbell.net> wrote:
>
> > On Saturday 12 July 2008, Andrew Morton wrote:
> > > > +EXPORT_SYMBOL(clk_get_parent);
> > >
> > > As this is a new kernel-wide utility library, it is appropriate that
> > > all of its public interfaces (at least) be documented. __An appropriate
> > > way of doing that is via kerneldoc annotation. __Please don't forget to
> > > document return values and call environment prerequisites (eg: requires
> > > foo_lock, may be called from interrupt context, etc, etc).
> >
> > That is, the stuff that's not already documented in <linux/clk.h>;
> > that's where clk_get_parent() is documented, for example.
>
> argh. That's why I missed it - please don't document stuff in header
> files. The usual approach is to document interfaces at the
> implementation site.

When it's a pure interface, I don't see a better option than having the
kerneldoc live in the header file ...

What Dmitry has provided is one implementation framework. It's not
clear it's general enough to become "the" implementation framework, or
that it should be. ISTR that it's not ready to handle OMAP clocks
yet ... those would be the acid test for any proposal that there be
a standard implementation framework.


> Except for structs where of course there is no choice. But then,
> the .h file _is_ the definition site.

That matches <linux/clk.h> to a tee: the header *is* the definition
of the interface.

- dave






\
 
 \ /
  Last update: 2008-07-13 23:57    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site