here is the code snippet I promised:
/* = */
/* Code snipets */
/* --- */
/* enumerator stuf */
/* PCI enumerator module */
pci_enumerator_class_init
{
enumclass_register("pci"...);
Browse /sys/bus/pci to create pci_enumerators for each
On Fri, Oct 27, 2017 at 4:54 PM, Francois Ozog
wrote:
>
> Le ven. 27 oct. 2017 à 23:51, Bill Fischofer
> a écrit :
>
>> On Fri, Oct 27, 2017 at 4:24 PM, Francois Ozog
>> wrote:
>>
>>>
>>> Le ven. 27 oct. 2017 à 23:05, Honnappa Nagarahalli <
>>> honnappa.nagaraha...@linaro.org> a écrit :
>>>
>>>
Le ven. 27 oct. 2017 à 23:54, Francois Ozog a
écrit :
> Le ven. 27 oct. 2017 à 23:51, Bill Fischofer
> a écrit :
>
>> On Fri, Oct 27, 2017 at 4:24 PM, Francois Ozog
>> wrote:
>>
>>>
>>> Le ven. 27 oct. 2017 à 23:05, Honnappa Nagarahalli <
>>> honnappa.nagaraha...@linaro.org> a écrit :
>>>
On Fri, Oct 27, 2017 at 3:43 PM, Francois Ozog
wrote:
>
> Le ven. 27 oct. 2017 à 20:35, Bill Fischofer
> a écrit :
>
>> On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog > > wrote:
>>
>>>
>>> Le ven. 27 oct. 2017 à 17:17, Bill Fischofer
>>> a écrit :
>>>
The problem with scanning, especially
Le ven. 27 oct. 2017 à 23:51, Bill Fischofer a
écrit :
> On Fri, Oct 27, 2017 at 4:24 PM, Francois Ozog
> wrote:
>
>>
>> Le ven. 27 oct. 2017 à 23:05, Honnappa Nagarahalli <
>> honnappa.nagaraha...@linaro.org> a écrit :
>>
>>> On 27 October 2017 at 13:35, Bill Fischofer
>>> wrote:
>>>
On Fri, Oct 27, 2017 at 4:24 PM, Francois Ozog
wrote:
>
> Le ven. 27 oct. 2017 à 23:05, Honnappa Nagarahalli <
> honnappa.nagaraha...@linaro.org> a écrit :
>
>> On 27 October 2017 at 13:35, Bill Fischofer
>> wrote:
>>
>>>
>>>
>>> On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog <
>>> francois.o..
Le ven. 27 oct. 2017 à 23:05, Honnappa Nagarahalli <
honnappa.nagaraha...@linaro.org> a écrit :
> On 27 October 2017 at 13:35, Bill Fischofer
> wrote:
>
>>
>>
>> On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog > > wrote:
>>
>>>
>>> Le ven. 27 oct. 2017 à 17:17, Bill Fischofer
>>> a écrit :
>>>
>
On 27 October 2017 at 13:35, Bill Fischofer
wrote:
>
>
> On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog
> wrote:
>
>>
>> Le ven. 27 oct. 2017 à 17:17, Bill Fischofer
>> a écrit :
>>
>>> The problem with scanning, especially in a VNF environment, is that (a)
>>> the application probably isn't a
Le ven. 27 oct. 2017 à 20:35, Bill Fischofer a
écrit :
> On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog
> wrote:
>
>>
>> Le ven. 27 oct. 2017 à 17:17, Bill Fischofer
>> a écrit :
>>
>>> The problem with scanning, especially in a VNF environment, is that (a)
>>> the application probably isn't a
On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog
wrote:
>
> Le ven. 27 oct. 2017 à 17:17, Bill Fischofer
> a écrit :
>
>> The problem with scanning, especially in a VNF environment, is that (a)
>> the application probably isn't authorized to to that
>>
>
> nothing prevents scanning what is availa
Le ven. 27 oct. 2017 à 17:31, Honnappa Nagarahalli <
honnappa.nagaraha...@linaro.org> a écrit :
> On 27 October 2017 at 02:36, Francois Ozog
> wrote:
>
>> Well, we do not need to scan all the platform because the pktio_open
>> contains enough information to target the right device.
>> This is alm
Le ven. 27 oct. 2017 à 17:17, Bill Fischofer a
écrit :
> The problem with scanning, especially in a VNF environment, is that (a)
> the application probably isn't authorized to to that
>
nothing prevents scanning what is available for n the vm. "Scale up" Events
are triggered when increasing reso
On 27 October 2017 at 02:36, Francois Ozog wrote:
> Well, we do not need to scan all the platform because the pktio_open
> contains enough information to target the right device.
> This is almost true as we need to have an additional "selector" for the
> port on multiport NICs that are controlled
The problem with scanning, especially in a VNF environment, is that (a) the
application probably isn't authorized to to that and (b) the application
certainly doesn't have real visibility into what the actual device topology
is. It only knows what it "needs to know" (as determined by higher-level
f
On 27 October 2017 at 09:50, Bill Fischofer
wrote:
> ODP 2.0 assumes Linux system services are available so the question of how
> to operate in bare metal environments is a separate one and up to those ODP
> implementations. Again the application will provide a
> sufficiently-qualified device nam
ODP 2.0 assumes Linux system services are available so the question of how
to operate in bare metal environments is a separate one and up to those ODP
implementations. Again the application will provide a
sufficiently-qualified device name string to identify which device it wants
to open in an unam
Well, we do not need to scan all the platform because the pktio_open
contains enough information to target the right device.
This is almost true as we need to have an additional "selector" for the
port on multiport NICs that are controlled by a single pci ID.
:: or something like that.
All ports m
On 26 October 2017 at 16:34, Bill Fischofer wrote:
> I agree with Maxim. Best to get one or two working drivers and see what else
> is needed. The intent here is not for ODP to become another OS, so I'm not
> sure why we need to concern ourselves with bus walking and similar arcana.
> Linux has al
Hi Bill/Maxim,
These are the exact decisions I wanted us to make coming out of
this discussion. I have taken some what of a longer route, i.e.
examine the DDF design and understand the idea/thinking on why
somethings were created.
We are almost there, we do not have many more slides to cover,
I agree with Maxim. Best to get one or two working drivers and see what
else is needed. The intent here is not for ODP to become another OS, so I'm
not sure why we need to concern ourselves with bus walking and similar
arcana. Linux has already long solved this problem. We should leverage
what's th
Hello Honnappa,
I think we also need to take a look from bottom. I.e. from exact drivers to
implement. That it will be more clear which interface is needed to be
created.
Do you have some list of drivers which needed to be implemented? I.e. with
pci drivers I think we in a good way, but non pci dr
Hi,
Agree, we have taken 2 hours and the progress has been slow. But
the discussions have been good and helpful to us at Arm. The goal is
to identify the gaps and work items. I am not sure if it has been
helpful to others, please let me know.
To speed this up, I propose few options below, let m
22 matches
Mail list logo