On Tuesday 28 April 2015 18:50:25 Baolin Wang wrote:
> On 28 April 2015 at 17:49, Arnd Bergmann <[email protected]> wrote:
> > > +void
> > > +jiffies_to_timespec(const unsigned long jiffies, struct timespec *value)
> > > +{
> > > + struct timespec64 *ts;
> > > +
> > > + *ts = timespec_to_timespec64(*value);
> > > + jiffies_to_timespec64(jiffies, ts);
> > > +}
> > > EXPORT_SYMBOL(jiffies_to_timespec);
> > >
> >
> > I would probably again put timespec_to_jiffies and jiffies_to_timespec
> > into the header file as static inline functions, which implies that you
> > then have to declare and export __timespec_to_jiffies.
> >
> > Arnd
> >
>
> But according to Thomas's suggestion, he would not like to add too much
> "EXPORT_SYMBOL".
> I also think here the "EXPORT_SYMBOL" is essential.
>
I think you just misunderstood his comments:
On Monday 20 April 2015 23:09:17 Thomas Gleixner wrote:
> So we have now two exports which are doing exactly the same
> thing. Copy and paste is wonderful, right?
>
> What about exporting __timespec_to_jiffies() and providing inlines for
> timespec_to_jiffies() and timespec64_to_jiffies() ?
>
> EXPORT_SYMBOL is not just a stupid annotation. Its impact on the
> resulting kernel size is larger than the actual function
> implementation.
The main takeaway here is that you should use specifically the
exports that are required, no more or less.
If a kernel-internal API has an 'extern' declaration in a header
file, it usually needs to be exported. What Thomas was suggesting
here was to reduce the number of exports that are required by
moving the two functions timespec_to_jiffies() and
timespec64_to_jiffies() into the header file as 'static inline'
functions that do not require the export.
If you get a review comment asking you to change something in your
patches, always make sure that you understand why that change is
a good idea. If you don't understand it, it's better to ask for
clarification than to blindly follow the advice and risk doing it
wrong again.
Arnd
_______________________________________________
Y2038 mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/y2038
