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

Michael Walle michael at walle.cc
Thu Jun 18 16:09:47 UTC 2020


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. So buildroot should really stick to the default ones
provided by the upstream. Like every other distro does. Esp if it
"just works".

> 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
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.

> 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.

-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


More information about the buildroot mailing list