Hi Andrew, I agree with you, we should revert the comparison back to ~0 and set the default to ~0. The larger issue is setting a false narrative in the commit message to relax the review process. "This is a temporary measure, ". It may not have been false at the time it was authored, but the expectation made by the author is false after two years. Is it not incumbent on the author of a temporary measure to address it before the next release? A manager at one of my clients always says "explain that to me: You don't have the time to do it right, but you have the time to do it again?"
The larger issue is whether high level languages are going to be considered first class citizens with VPP. You want to mentor someone to do rust bindings. Florin reached out for someone to do Go bindings. I have a change [0] that was submitted before the crc process. You -1 it "to test the crc process" and it took Ole to remove your -1 months later after the crc check was put in place. It too, is a bug-fix, because Jakub updated the .api with the wrong typedef, needed by the high-level language bindings to be correct. Paul [0] https://gerrit.fd.io/r/c/vpp/+/26832 On Mon, May 3, 2021 at 5:40 AM Andrew Yourtchenko <ayour...@gmail.com> wrote: > I would argue that this case can be classified as "bugfix" - there was > no good reason to use the 0 as a wildcard value in the first place, > since it is a valid sw_if_index, and there is a perfectly good > "wildcard value" of ~0 that already works, right ? > > So I would say this discussion should serve as the announcement (Or > there can be another separate thread with the explicit subject of it), > and post-branch of stable/2106, we can apply the fix to consider the 0 > to be a valid interface ID. > > And of course bump the semver for those who look at it. > > It's always useful to keep in mind "why" the process is in place, when > evaluating how to apply it: > > the reason for it is minimize the amount of forced work downstream, > caused by the API changes, and minimize the element of surprise. > > In this case, having the "buggy" clients use ~0 in place of 0 (if they > ever used that) is strictly less work than having *all* clients to > switch to using a new message name even if they used the ~0 to begin > with. > > We can take care of minimizing the "element of surprise" by this > discussion, or maybe a separate mail - and giving the folks a few > weeks (namely, until after RC1), to adapt. > > This way the spirit of why the process there in the first place will > be fulfilled, without incurring the unnecessary effort for everyone. > > Does this make sense ? > > --a > > On 5/3/21, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) > via lists.fd.io <vrpolak=cisco....@lists.fd.io> wrote: > >> Is there any plan for support selecting only index==0 ? > > > > Good news first. > > I added the TODO here [0], but since then > > CSIT stopped using the VAT command in [1], > > and other uses based on PAPI should be ready since [2]. > > > > The bad news is VPP now has more strict process [3] > > regarding changes to API. > > This particular case is debatable, as the change > > will not affect the message CRC value, > > only the behavior for a particular argument value. > > But I think it would be an API change overall, > > so not directly allowed (as sw_interface_dump is a production API). > > > > The indirect fix is to add a new API message > > (sw_interface_dump_v2) and mark the old one as deprecated. > > > > Vratko. > > > > [0] https://gerrit.fd.io/r/c/vpp/+/19106 > > [1] https://gerrit.fd.io/r/c/csit/+/21149 > > [2] https://gerrit.fd.io/r/c/vpp/+/23530 > > [3] https://wiki.fd.io/view/VPP/ApiChangeProcess > > > > From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of > > jiangxiaom...@outlook.com > > Sent: Thursday, 2021-April-29 13:41 > > To: vpp-dev@lists.fd.io > > Subject: [vpp-dev] sw_interface_dump currently cann't dump interface > which > > sw_if_index == 0 #vapi > > > > Hi Vratko Polak, > > > > currently sw_interface_dump will dump all interfaces if sw_if_index == > 0. In > > my case, i need get interface information by id without by dumping all, > but > > there is no way for this. > > I notice there is a TODO comment for sw_interface_dump in interface.api > > file. > > /** \brief Request all or filtered subset of sw_interface_details > > @param client_index - opaque cookie to identify the sender > > @param context - sender context, to match reply w/ request > > @param sw_if_index - index of the interface to dump info on, 0 or ~0 > if > > on all > > TODO: Support selecting only index==0 when CSIT is ready. > > @param name_filter_valid - 1 if requesting a filtered subset of > records > > else 0 > > if name filter is set as valid, sw_if_index value is ignored and > all > > interfaces are examined > > @param name_filter - interface name substring filter. Eg. loop1 > returns > > [loop1, loop10] > > */ > > define sw_interface_dump > > Is there any plan for support selecting only index==0 ? > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19318): https://lists.fd.io/g/vpp-dev/message/19318 Mute This Topic: https://lists.fd.io/mt/82453036/21656 Mute #vapi:https://lists.fd.io/g/vpp-dev/mutehashtag/vapi Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
