Re: [RFC] Defining a home/maintenance model for non-NIC PHC devices using the /dev/ptpX API

[Sven Schnelle <svens@linux.ibm.com>]

Hi Wen,

Wen Gu <guwen@linux.alibaba.com> writes:

> 1. Reorganize drivers/ptp/ to make the interface/implementation split
>    explicit,
>
>    * drivers/ptp/core      : PTP core infrastructure and API.
>                              (e.g. ptp_chardev.c, ptp_clock.c,
>                               ptp_sysfs.c, etc.)
>
>    * drivers/ptp/pure      : Non-network ("pure clock") implementation,
>                              they are typically platform/architecture/
>                              virtualization-provided time sources.
>                              (e.g. ptp_kvm, ptp_vmw, ptp_vmclock,
>                               ptp_s390, etc.)
>
>    * drivers/ptp/*         : Network timestamping oriented implementation,
>                              they primarily used together with IEEE1588
>                              over the network.
>                              (e.g. ptp_qoriq, ptp_pch, ptp_dp83640,
>                               ptp_idt82p33 etc.)

I'm fine with splitting paths - but I would propose a different naming
scheme as 'pure' is not really a common term in the driver world (at
least in my perception, which might be wrong. How about the following
instead:

drivers/ptp/core    - API as written above
drivers/ptp/virtual - all PtP drivers somehow emulating a PtP clock
                      (like the ptp_s390 driver)
drivers/ptp/net     - all NIC related drivers.