[Buildroot] [PATCH 1/1] package/linuxptp: remove hardcoded interface from config to args

[Vladimir Oltean]

On Thu, 18 Jun 2020 at 19:09, Michael Walle <michael at walle.cc> wrote:
>
> Am 2020-06-16 21:07, schrieb Vladimir Oltean:
> > Hi Heiko,
> >
> > 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?
> >>
> >> --
> >> Heiko
> >> _______________________________________________
> >> buildroot mailing list
> >> buildroot at busybox.net
> >> http://lists.busybox.net/mailman/listinfo/buildroot
> >
> > 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_ a customized config file which fits one board doesn't make
> sense either.

For that board, sure it makes sense. For the rest, not so much.

> So buildroot should really stick to the default ones
> provided by the upstream. Like every other distro does. Esp if it
> "just works".
>

And it does. To my knowledge, linuxptp.cfg from buildroot is
default.cfg from upstream, just with this extra [eth0] at the end.

> > 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):
> > https://github.com/richardcochran/linuxptp/tree/master/configs
> > 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?
>
> Having an empty [<interface>] section in linuxptp.cfg is strange.

Why is it strange to have no interfaces defined in linuxptp.cfg?
That's how upstream configurations are shipped.

> Why
> are there the "-i" options for the binary? Because you can then have
> one config which can be used for multiple instances on different
> interfaces.
>

Yes.

> > The default
> > configuration will remain just as useless for somebody who needs to
> > customize ptp4l for a particular set of ports and PTP profile.
>
> Right, but as a starting point it is sufficient.
>

And what do you gain if you move that "eth0" to just some other file?
Isn't the current starting point just as sufficient?

> -michael
>
> > 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?
> >
> > -Vladimir

Thanks,
-Vladimir