Re: [PATCH 1/3] genclk: add generic framework for managing clocks.

From: David Brownell
Date: Sun Jul 13 2008 - 17:54:19 EST


On Sunday 13 July 2008, Andrew Morton wrote:
> On Sun, 13 Jul 2008 14:12:32 -0700 David Brownell <david-b@xxxxxxxxxxx> 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




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/