On Mon, 16 Sep 2019 14:44:57 +, Petr Machata wrote:
> So you want to change the current TLV? I guess that's reasonable, since
> it is essentially an internal API.
Whatever, just have a way to extend this in the future, while allowing
the tools compiled today to still work after the extension.
> -Original Message-
> From: Petr Machata [mailto:pe...@mellanox.com]
> Sent: Monday, September 16, 2019 2:56 AM
> To: Keller, Jacob E
> Cc: Jiri Benc ; linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] [PATCH 2/2] pmc: Support querying
> T
Jiri Benc writes:
> On Mon, 16 Sep 2019 09:56:29 +, Petr Machata wrote:
>> Inside the namespace you can do "ip netns id" to get the namespace that
>> you are in.
>
> Beware that this netnsid is only valid in the net name space that the
> 'ip' command ran in. It is not a global identifier
Jiri Benc writes:
> On Mon, 16 Sep 2019 14:04:00 +, Petr Machata wrote:
>> I was actually thinking about /var/run/netns being mounted elsewhere or
>> some such, which would prevent "ip netns id" from working. The symbolic
>> names seem to be accessible from other namespaces just fine --"ip
On Mon, 16 Sep 2019 14:04:00 +, Petr Machata wrote:
> I was actually thinking about /var/run/netns being mounted elsewhere or
> some such, which would prevent "ip netns id" from working. The symbolic
> names seem to be accessible from other namespaces just fine --"ip netns
> exec foo ip netns
On Mon, 16 Sep 2019 09:56:29 +, Petr Machata wrote:
> Inside the namespace you can do "ip netns id" to get the namespace that
> you are in.
Beware that this netnsid is only valid in the net name space that the
'ip' command ran in. It is not a global identifier and it is not valid
in another
Keller, Jacob E writes:
>> From: Petr Machata [mailto:pe...@mellanox.com]
>> Sent: Friday, September 13, 2019 7:58 AM
>> To: Jiri Benc
>> Cc: linuxptp-devel@lists.sourceforge.net
>> Subject: Re: [Linuxptp-devel] [PATCH 2/2] pmc: Support querying
>> TL
> -Original Message-
> From: Petr Machata [mailto:pe...@mellanox.com]
> Sent: Friday, September 13, 2019 7:58 AM
> To: Jiri Benc
> Cc: linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] [PATCH 2/2] pmc: Support querying
> TLV_PORT_PROPERTIES_NP
>
Jiri Benc writes:
> pmc is different. It's not tied to the service start time, it's used by
> administrators and by various scripts from varying environment. While
> you can reasonably expect that ptp4l and phc2sys will be run in the
> same name space, it's not necessarily the case for pmc.
On Fri, 13 Sep 2019 09:32:37 +, Petr Machata wrote:
> I would guess the same problem applies when phc2sys uses the interface.
> Why is it not an issue there?
It is an issue, too, of course, but it's mostly theoretical. It won't
happen in practice - usually, phc2sys will be started together
Jiri Benc writes:
> On Thu, 12 Sep 2019 11:06:30 +, Petr Machata wrote:
>> +text2str(>interface));
>
> How does this work when net name spaces are in use? There's no guarantee
> that pmc is run in the same net name space where ptp4l is running. The
> returned interface
On Thu, 12 Sep 2019 11:06:30 +, Petr Machata wrote:
> + text2str(>interface));
How does this work when net name spaces are in use? There's no guarantee
that pmc is run in the same net name space where ptp4l is running. The
returned interface name may correspond to a
TLV_PORT_PROPERTIES_NP messages serve for querying of port properties, such
as timestamp type and, prominently, netdevice name associated with the
port. pmc however does not support this query, which makes it difficult to
access this information e.g. from scripts. Add this support to pmc.
13 matches
Mail list logo
