Re: [dpdk-dev] [EXT] Re: [PATCH v2 2/6] eal/interrupts: avoid direct access to interrupt handle

[Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>]

2021-10-14 17:31 (UTC+0000), Harman Kalra:
> > -----Original Message-----
> > From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
> > Sent: Thursday, October 14, 2021 6:29 AM
> > To: Harman Kalra <hkalra@marvell.com>
> > Cc: dev@dpdk.org; Bruce Richardson <bruce.richardson@intel.com>;
> > david.marchand@redhat.com; mdr@ashroe.eu
> > Subject: [EXT] Re: [PATCH v2 2/6] eal/interrupts: avoid direct access to
> > interrupt handle
> > 
> > External Email
> > 
> > ----------------------------------------------------------------------
> > 2021-10-05 17:44 (UTC+0530), Harman Kalra:  
> > > Making changes to the interrupt framework to use interrupt handle APIs
> > > to get/set any field. Direct access to any of the fields should be
> > > avoided to avoid any ABI breakage in future.  
> > 
> > How is ABI breakage applicable to internal consumers?
> > 
> > This protects against fields renaming for sure, but convenience is arguable.
> > If EAL needs to add a EAL-private field to struct rte_intr_handle, it must add
> > an accessor even though the field is likely OS-specific.
> > It would be simpler if the definition was in some private EAL header and
> > could be accessed directly by EAL code.  
> 
> Initially we thought to implement this way only i.e. defining rte_intr_handle inside internal headers
> but supporting out of tree drivers was one of the reason to go via this get/set approach. All drivers
> internal and external should follow the same way, that was the intention. 
> 
> Thanks
> Harman

True for drivers, I understand this, but the question is about EAL itself.
I shouldn't say "internal consumers", I only meant EAL, not inbox drivers.