[LinuxPPS] task force was I'm still here! :)

[Heiko Gerstung]

Udo van den Heuvel schrieb:
> Heiko Gerstung wrote:
>> thanks a lot. Maybe we should form some sort of a task force for 
>> LinuxPPS, Hal already did a great job breaking this whole thing into 
>> several pieces:
>
> Task force sounds OK to me.
>
>> 1. Rewrite the in-line documentation to the kernel standards.  Make 
>> sure these are not flagged in anyway by checkpatch.pl.  Doc change - 
>> possible non-programmer task.
>
> Current status:
>
> # /usr/src/linux-2.6.28/scripts/checkpatch.pl ntp-pps-2.6.28-rc6
> WARNING: do not add new typedefs
> #603: FILE: Documentation/pps/timepps.h:61:
> +typedef int pps_handle_t;        /* represents a PPS source */
>
> WARNING: do not add new typedefs
> #604: FILE: Documentation/pps/timepps.h:62:
> +typedef unsigned long pps_seq_t;    /* sequence number */
>
> WARNING: do not add new typedefs
> #605: FILE: Documentation/pps/timepps.h:63:
> +typedef struct ntp_fp ntp_fp_t;        /* NTP-compatible time stamp */
>
> WARNING: do not add new typedefs
> #606: FILE: Documentation/pps/timepps.h:64:
> +typedef union pps_timeu pps_timeu_t;    /* generic data type for time 
> stamps */
>
> WARNING: do not add new typedefs
> #607: FILE: Documentation/pps/timepps.h:65:
> +typedef struct pps_info pps_info_t;
>
> WARNING: do not add new typedefs
> #608: FILE: Documentation/pps/timepps.h:66:
> +typedef struct pps_params pps_params_t;
>
> WARNING: plain inline is preferred over __inline
> #626: FILE: Documentation/pps/timepps.h:84:
> +static __inline int time_pps_create(int source, pps_handle_t *handle)
>
> WARNING: plain inline is preferred over __inline
> #651: FILE: Documentation/pps/timepps.h:109:
> +static __inline int time_pps_destroy(pps_handle_t handle)
>
> WARNING: plain inline is preferred over __inline
> #656: FILE: Documentation/pps/timepps.h:114:
> +static __inline int time_pps_getparams(pps_handle_t handle,
>
> WARNING: plain inline is preferred over __inline
> #674: FILE: Documentation/pps/timepps.h:132:
> +static __inline int time_pps_setparams(pps_handle_t handle,
>
> WARNING: plain inline is preferred over __inline
> #690: FILE: Documentation/pps/timepps.h:148:
> +static __inline int time_pps_getcap(pps_handle_t handle, int *mode)
>
> WARNING: plain inline is preferred over __inline
> #695: FILE: Documentation/pps/timepps.h:153:
> +static __inline int time_pps_fetch(pps_handle_t handle, const int 
> tsformat,
>
> WARNING: plain inline is preferred over __inline
> #728: FILE: Documentation/pps/timepps.h:186:
> +static __inline int time_pps_kcbind(pps_handle_t handle,
>
> ERROR: Missing Signed-off-by: line(s)
>
> total: 1 errors, 13 warnings, 2549 lines checked
>
> ntp-pps-2.6.28-rc6 has style problems, please review.  If any of these 
> errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
>
> I see no complaints about the inline (in the source I assume) 
> documentation, just coding issues.
> Is there an example to get the idea of what needs to be done for this 
> particular job? Then I could have a look over the code and 
> documentation in there.
>
>> 2. Clean up ioctl code to not use depreciated constructs and 
>> eliminate redundant code.
>>
>> 3. Divide pps.h into two header files. One for userspace ABI and one 
>> for kernel only  interfaces.
>
> Could be done based on ____KERNEL___ #ifdef ?
>
>> 4. Remove conditional includes from the pps.h derivatives.
>>
>>
>> So, you would be willing to work on 1. if I understood you correctly. 
>
> Indeed, but I need some basic info to get started with some idea about 
> the stuff that needs changing to what shape.
>
> Udo

Here is what Hal posted from Alans comments:

> linuxpps-core-support.patch

> 
> looks generally good, but the comments should get a little loving.


> Please remove the stupid filenames that always get out of sync in
> the top of file comments, and make the documentation of exported
> symbols kernel-doc instead of it's weird own format.

I guess he means that there should be a little bit more comments and the 
ones that are there should be expanded a little bit.

Regards,
  Heiko