Re: Documentation of device spec list does not agree with parser code



On Mon, 2016-01-18 at 15:48 +0000, Roger James wrote:
On 18/01/16 11:21, Thomas Haller wrote:
On Mon, 2016-01-18 at 10:54 +0000, Roger James wrote:

Hi Roger,




Sorry about the confusion. The ? instead of the ~ in the first
message 
was a typo.

Produce the following statement in the man page entry:

Correct.

This implies that that interface-name:?on* should match for example
mon0.

Yes, this should indeed match.



However the code fro the nm_match_spec_interface_name function in 
NetworkManagerUtils.c, only sets the match_pattern flag if it sees a
~ 
character as the first character of the interface name. This is at
or 
around line 1322 of the source file.

»···»···»···spec_str += STRLEN (INTERFACE_NAME_TAG);
»···»···»···if (spec_str[0] == '=')
»···»···»···»···spec_str += 1;
»···»···»···else {
»···»···»···»···if (spec_str[0] == '~')
»···»···»···»···»···spec_str += 1;
»···»···»···»···use_pattern=TRUE;
»···»···»···}

it sets use_pattern=TRUE if the first character is not '='.

Seems correct to me.




I think that.

         <varlistentry>
           <term>interface-name:IFNAME</term>
           <listitem><para>Case sensitive match of interface name of
the device. Ranges and escaping is not supported.</para></listitem>
         </varlistentry>

That would be conceivable, but that would be a different behavior.
AFAIS, currently it works as documented and as intended.



However I am not very familiar with this code. So I might be
completely 
mistaken. I came across this whilst trying work out why my config
was 
not working on Ubuntu 15.10. However the NM version there appears to
be 
very old and  I suspect that interface-names in the conf  for
exclusion 
do not work for a number of other reasons :-)

A quick check reveals that 15.10 comes with 1.0.4-0ubuntu5 version
which has this feature too. So, it should work there.

If something is not working, it might be a bug. But I still don't see
anything wrong.
It'd be best to show the configuration you were using and explain the
observed behavior (contrary to your expectation).



ciao,
Thomas

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]