[Buildroot] [PATCH 1/1] package/linuxptp: remove hardcoded interface from config to args
olteanv at gmail.com
Tue Jun 16 19:07:36 UTC 2020
On Mon, 15 Jun 2020 at 14:36, Heiko Thiery <heiko.thiery at gmail.com> wrote:
> Hi Thomas, Hi Michael,
> Am Mi., 27. Mai 2020 um 08:51 Uhr schrieb Heiko Thiery <heiko.thiery at gmail.com>:
> > Hi Petr,
> > Am Do., 21. Mai 2020 um 23:22 Uhr schrieb Michael Walle <michael at walle.cc>:
> > >
> > > Hi all,
> > >
> > > Am 2020-05-21 15:36, schrieb Thomas Petazzoni:
> > > > Hello Heiko,
> > > >
> > > > On Wed, 20 May 2020 07:16:48 +0200
> > > > Heiko Thiery <heiko.thiery at gmail.com> wrote:
> > > >
> > > >> Interface configuration is hard coded in the config file. This will
> > > >> throw an error when this interace (eth0) is not present.
> > > >>
> > > >> This patch removes the interface to be used from the config and
> > > >> appends it
> > > >> to the PTP4L_ARGS. With this the custom arguments can be set via
> > > >> /etc/defaults/ptp4l.
> > > >
> > > > Well, you can also just as well provide your custom linuxptp.cfg in a
> > > > rootfs overlay, no?
> > >
> > > You can, but then you'd have to copy the configuration on each and every
> > > board which has another interface name than "eth0". That being said, I'd
> > > also prefer it to have the normal default config, shipped with linuxptp.
> > > Like at least debian does too.
> > What do you think? Can we change the default configuration to the one
> > coming from the package? As Michael mentioned this is also the case
> > e.g. for debian.
> Since no reply from the package maintainer about changing the default
> configuration what do you think? Should we change the used config to
> the one provided by the upstream linuxptp?
> buildroot mailing list
> buildroot at busybox.net
I've thought many times about changing the default ptp4l config file
shipped by buildroot (due to that inconvenient eth0), but at the end
of the day, buildroot is meant to be customized for each and every
embedded target (which makes the comparison to debian not so
relevant). So providing a default config doesn't make a lot of sense
in the first place, except for those users who have never used it
before, and have no idea where to start. But apart from that, as you
said, interface names are going to differ, and let me add another one:
PTP profiles are going to differ (automotive, AVB, telecom, etc):
So what do you do, ship them all? That's a little bit _not_ in the
spirit of buildroot where you are only supposed to install what the
end appliance will use.
So I guess I'm back to Thomas's question: what do you win if you move
"eth0" from /etc/linuxptp.cfg to /etc/defaults/ptp4l? The default
configuration will remain just as useless for somebody who needs to
customize ptp4l for a particular set of ports and PTP profile.
The furthest I got was to have some advanced Kconfig-based system
where you could specify in the defconfig which profile you want, and
on which ports, and the build system would automatically make things
happen. Sadly it was so complicated that I just tossed it away. Note
that some hardware also needs hardware-specific settings (such as
increasing the tx_timestamp_timeout), which makes Thomas's suggestion
of providing rootfs overlays the only viable path in the general case.
What do you think?
More information about the buildroot