[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