[dpdk-dev] [EXT] Re: [PATCH v2 2/6] eal/interrupts: avoid direct access to interrupt handle
Dmitry Kozlyuk
dmitry.kozliuk at gmail.com
Thu Oct 14 19:53:30 CEST 2021
2021-10-14 17:31 (UTC+0000), Harman Kalra:
> > -----Original Message-----
> > From: Dmitry Kozlyuk <dmitry.kozliuk at gmail.com>
> > Sent: Thursday, October 14, 2021 6:29 AM
> > To: Harman Kalra <hkalra at marvell.com>
> > Cc: dev at dpdk.org; Bruce Richardson <bruce.richardson at intel.com>;
> > david.marchand at redhat.com; mdr at 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.
More information about the dev
mailing list