[PATCH v2 3/4] ipq40xx: fix compatibility with linux-atm tools

Sergey Ryazanov ryazanov.s.a at gmail.com
Sun Jan 12 04:19:16 PST 2025


+CC John as the Lantiq patch author

On 12.01.2025 11:20, Andre Heider wrote:
> Hi,
> 
> On 12/01/2025 2:02 am, Sergey Ryazanov wrote:
>> atm_qos struct should be the same both for user and kernel spaces. Via
>> the __SO_ENCODE() macro it is used to define the SO_ATMQOS socket IOC.
>>
>> During the VRX518 support introduction, the atm_trafprm sturct nested
>> into the atm_qos stucture was update with newer fields that are
>> referenced by the ATM TC layer of the VRX518 TC driver. These new fields
>> are intended to communicate information for extra traffic classes
>> supported by the driver. But we are still using vanila kernel headers
>> to build the toolchain. Due to the atm.h header incoherency br2684ctl
>> from linux-atm tools is incapable to configure an ATM bridge netdev:
> 
> if vrx518_tc is the only instance using those new fields, wouldn't it be 
> nicer and neater if you remove the usage of the added ATM_* fields from 
> dcdp/atm_tc.c and then just drop 998-lantiq-atm-hacks.patch completely?

Make sense. I also was thinking about this and decided that it would be 
too radical solution. Removing extra struct fields, but keeping these 
ATM_VBR_NRT/ATM_VBR_RT/etc definitions leaves atm.h aligned with the 
Lantiq target.

On another hand, we really do not have any users and extra kernel patch 
is extra maintenance work. You are right.

> That'll get rid of patching the atm uapi header altogether, which isn't 
> nice to begin with and it's one less spot to maintain.

I could not say removing these extra definitions will remove burden of 
maintenance entirely. We still need to maintain the patch that is 
removing extra traffic classes functionality in the vrx518_tc. But it 
still makes sense since we need to maintain only one patch and we are 
going to update kernel more often than the driver.

If there no other points or objections then I am going to send V3 
removing these extra traffic classes and the kernel patch.

--
Sergey



More information about the openwrt-devel mailing list