Hi Anatoly, I'm working on the implementation of bus/pci driver for Windows, pci_common.c uses the titled functions however they are relevant only for Linux OS. I'm wondering if the implementation of those functions should be moved to a Linux specific area since FreeBSD (and now Windows) are forced to implemented those in the current state. Would appreciate your feedback, Regards, Tal
On 22-Mar-20 5:20 PM, Tal Shnaiderman wrote:
> Hi Anatoly,
>
> I’m working on the implementation of bus/pci driver for Windows,
> pci_common.c uses the titled functions however they are relevant only
> for Linux OS.
>
> I’m wondering if the implementation of those functions should be moved
> to a Linux specific area since FreeBSD (and now Windows) are forced to
> implemented those in the current state.
>
> Would appreciate your feedback,
>
> Regards,
>
> Tal
>
Hi,
I believe those functions are marked as deprecated now. We probably
could remove them in 20.11?
--
Thanks,
Anatoly
On 17-Apr-20 3:05 PM, Burakov, Anatoly wrote:
> On 22-Mar-20 5:20 PM, Tal Shnaiderman wrote:
>> Hi Anatoly,
>>
>> I’m working on the implementation of bus/pci driver for Windows,
>> pci_common.c uses the titled functions however they are relevant only
>> for Linux OS.
>>
>> I’m wondering if the implementation of those functions should be moved
>> to a Linux specific area since FreeBSD (and now Windows) are forced to
>> implemented those in the current state.
>>
>> Would appreciate your feedback,
>>
>> Regards,
>>
>> Tal
>>
>
> Hi,
>
> I believe those functions are marked as deprecated now. We probably
> could remove them in 20.11?
>
Sorry, was thinking of different functions (not the container related ones).
Unfortunately, we don't have a generic API for these, but since we
export a single API on all platforms, either all platforms have to
implement these functions, or none of them do. There's simply no way to
avoid implementing stubs for these functions, short of coming up with a
generic API that would replace these. Given that this API is heavily
Linux specific, i don't see that happening.
--
Thanks,
Anatoly
17/04/2020 16:09, Burakov, Anatoly:
> On 17-Apr-20 3:05 PM, Burakov, Anatoly wrote:
> > On 22-Mar-20 5:20 PM, Tal Shnaiderman wrote:
> >> Hi Anatoly,
> >>
> >> I’m working on the implementation of bus/pci driver for Windows,
> >> pci_common.c uses the titled functions however they are relevant only
> >> for Linux OS.
> >>
> >> I’m wondering if the implementation of those functions should be moved
> >> to a Linux specific area since FreeBSD (and now Windows) are forced to
> >> implemented those in the current state.
>
> Unfortunately, we don't have a generic API for these, but since we
> export a single API on all platforms, either all platforms have to
> implement these functions, or none of them do. There's simply no way to
> avoid implementing stubs for these functions, short of coming up with a
> generic API that would replace these. Given that this API is heavily
> Linux specific, i don't see that happening.
Because it is Linux specific, we should not force FreeBSD and Windows
having stubs. Can we move VFIO calls in Linux-specific files?
I think rte_vfio.h should be moved in lib/librte_eal/linux/include.
19/04/2020 15:09, Thomas Monjalon:
> 17/04/2020 16:09, Burakov, Anatoly:
> > On 17-Apr-20 3:05 PM, Burakov, Anatoly wrote:
> > > On 22-Mar-20 5:20 PM, Tal Shnaiderman wrote:
> > >> Hi Anatoly,
> > >>
> > >> I’m working on the implementation of bus/pci driver for Windows,
> > >> pci_common.c uses the titled functions however they are relevant only
> > >> for Linux OS.
> > >>
> > >> I’m wondering if the implementation of those functions should be moved
> > >> to a Linux specific area since FreeBSD (and now Windows) are forced to
> > >> implemented those in the current state.
> >
> > Unfortunately, we don't have a generic API for these, but since we
> > export a single API on all platforms, either all platforms have to
> > implement these functions, or none of them do. There's simply no way to
> > avoid implementing stubs for these functions, short of coming up with a
> > generic API that would replace these. Given that this API is heavily
> > Linux specific, i don't see that happening.
>
> Because it is Linux specific, we should not force FreeBSD and Windows
> having stubs. Can we move VFIO calls in Linux-specific files?
>
> I think rte_vfio.h should be moved in lib/librte_eal/linux/include.
+Cc Bruce and David
On 19-Apr-20 2:10 PM, Thomas Monjalon wrote:
> 19/04/2020 15:09, Thomas Monjalon:
>> 17/04/2020 16:09, Burakov, Anatoly:
>>> On 17-Apr-20 3:05 PM, Burakov, Anatoly wrote:
>>>> On 22-Mar-20 5:20 PM, Tal Shnaiderman wrote:
>>>>> Hi Anatoly,
>>>>>
>>>>> I’m working on the implementation of bus/pci driver for Windows,
>>>>> pci_common.c uses the titled functions however they are relevant only
>>>>> for Linux OS.
>>>>>
>>>>> I’m wondering if the implementation of those functions should be moved
>>>>> to a Linux specific area since FreeBSD (and now Windows) are forced to
>>>>> implemented those in the current state.
>>>
>>> Unfortunately, we don't have a generic API for these, but since we
>>> export a single API on all platforms, either all platforms have to
>>> implement these functions, or none of them do. There's simply no way to
>>> avoid implementing stubs for these functions, short of coming up with a
>>> generic API that would replace these. Given that this API is heavily
>>> Linux specific, i don't see that happening.
>>
>> Because it is Linux specific, we should not force FreeBSD and Windows
>> having stubs. Can we move VFIO calls in Linux-specific files?
>>
>> I think rte_vfio.h should be moved in lib/librte_eal/linux/include.
>
> +Cc Bruce and David
>
>
...and have a Linux-specific ABI?
--
Thanks,
Anatoly
20/04/2020 16:07, Burakov, Anatoly:
> On 19-Apr-20 2:10 PM, Thomas Monjalon wrote:
> > 19/04/2020 15:09, Thomas Monjalon:
> >> 17/04/2020 16:09, Burakov, Anatoly:
> >>> On 17-Apr-20 3:05 PM, Burakov, Anatoly wrote:
> >>>> On 22-Mar-20 5:20 PM, Tal Shnaiderman wrote:
> >>>>> Hi Anatoly,
> >>>>>
> >>>>> I’m working on the implementation of bus/pci driver for Windows,
> >>>>> pci_common.c uses the titled functions however they are relevant only
> >>>>> for Linux OS.
> >>>>>
> >>>>> I’m wondering if the implementation of those functions should be moved
> >>>>> to a Linux specific area since FreeBSD (and now Windows) are forced to
> >>>>> implemented those in the current state.
> >>>
> >>> Unfortunately, we don't have a generic API for these, but since we
> >>> export a single API on all platforms, either all platforms have to
> >>> implement these functions, or none of them do. There's simply no way to
> >>> avoid implementing stubs for these functions, short of coming up with a
> >>> generic API that would replace these. Given that this API is heavily
> >>> Linux specific, i don't see that happening.
> >>
> >> Because it is Linux specific, we should not force FreeBSD and Windows
> >> having stubs. Can we move VFIO calls in Linux-specific files?
> >>
> >> I think rte_vfio.h should be moved in lib/librte_eal/linux/include.
> >
> > +Cc Bruce and David
>
> ...and have a Linux-specific ABI?
Yes, the ABI is different depending on arch and OS.
That's a fact, and I don't see any problem with it.
On 20-Apr-20 6:39 PM, Thomas Monjalon wrote:
> 20/04/2020 16:07, Burakov, Anatoly:
>> On 19-Apr-20 2:10 PM, Thomas Monjalon wrote:
>>> 19/04/2020 15:09, Thomas Monjalon:
>>>> 17/04/2020 16:09, Burakov, Anatoly:
>>>>> On 17-Apr-20 3:05 PM, Burakov, Anatoly wrote:
>>>>>> On 22-Mar-20 5:20 PM, Tal Shnaiderman wrote:
>>>>>>> Hi Anatoly,
>>>>>>>
>>>>>>> I’m working on the implementation of bus/pci driver for Windows,
>>>>>>> pci_common.c uses the titled functions however they are relevant only
>>>>>>> for Linux OS.
>>>>>>>
>>>>>>> I’m wondering if the implementation of those functions should be moved
>>>>>>> to a Linux specific area since FreeBSD (and now Windows) are forced to
>>>>>>> implemented those in the current state.
>>>>>
>>>>> Unfortunately, we don't have a generic API for these, but since we
>>>>> export a single API on all platforms, either all platforms have to
>>>>> implement these functions, or none of them do. There's simply no way to
>>>>> avoid implementing stubs for these functions, short of coming up with a
>>>>> generic API that would replace these. Given that this API is heavily
>>>>> Linux specific, i don't see that happening.
>>>>
>>>> Because it is Linux specific, we should not force FreeBSD and Windows
>>>> having stubs. Can we move VFIO calls in Linux-specific files?
>>>>
>>>> I think rte_vfio.h should be moved in lib/librte_eal/linux/include.
>>>
>>> +Cc Bruce and David
>>
>> ...and have a Linux-specific ABI?
>
> Yes, the ABI is different depending on arch and OS.
> That's a fact, and I don't see any problem with it.
>
OK, no objections then :)
--
Thanks,
Anatoly