On 28 April 2015 at 19:04, Arnd Bergmann <[email protected]> wrote: > 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 >
Thanks for your explanation, and i'll do that follow your suggestion. -- Baolin.wang Best Regards _______________________________________________ Y2038 mailing list [email protected] https://lists.linaro.org/mailman/listinfo/y2038
