Re: [lng-odp] driver interface thinkings....

[Brian Brooks]

On 11/09 09:42:49, Francois Ozog wrote:
> To deal with drivers we need to have additional "standard" (helper or API?)
> objects to deal with MAC addresses.
> 
> ODP could be made to handle SDH, SDLC, FrameRelay or ATM packets. A
> packet_io is pretty generic...
> 
> But as soon as we talk with drivers and initialization, we need to deal
> with L1 initialization (link up/ synchronized...) and L2 initialization
> (DLCI, MAC (Ethernet, FDDI, TokenRing...)...).
> 
> Shall we add those L1 and L3 concepts ?

Thinking of L1 and L2 concepts. External PHYs and transceivers should
be brought out of reset and MDIO busses probed. Optional firmware loaded.
Line drivers configured with board-specific drive strength. Startup and
shutdown sequence across MAC, PHY, and optional transceiver. Loopback at
line-side or system-side. Autonegotiation. Link status according to MAC
and PHY. Link status info such as Link Fault Signaling. Timestamping.
IEEE DCB. Majority kept in driver, but what does interface look like?

> FF
> 
> On 9 November 2016 at 09:38, Francois Ozog  wrote:
> 
> >
> >
> > On 9 November 2016 at 09:09, Christophe Milard <
> > christophe.mil...@linaro.org> wrote:
> >
> >>
> >>
> >> On 8 November 2016 at 18:19, Francois Ozog 
> >> wrote:
> >>
> >>> Hi Christophe,
> >>>
> >>> We are focusing on network devices which have at least network ports.
> >>> Inventory of devices and ports are two distinct topics as there is no
> >>> guarantee that there is one device per port. (Intel and Mellanox have this
> >>> policy: one device per PCI port, but many others have one PCI device for
> >>> multiple ports (Chelsio...)
> >>>
> >>> 1) device discovery
> >>>
> >>> So let's focus first on device discovery.
> >>>
> >>> Devices can be found from:
> >>> - static "configuration" based on ODP implementation
> >>> - ACPI
> >>> - PCI
> >>> - DPAA2 NXP bus
> >>> - VMBus (VMs running on Microsoft Hyper-V hypervisor)
> >>> - others ?
> >>>
> >>> So bus are somewhat limited (ACPI is NOT a bus). I prefer to talk about
> >>> device enumerators.
> >>>
> >>
> >> OK.
> >>
> >>
> >>>
> >>> so we can loop through all devices using your proposed:
> >>> for each 
> >>> for each probed device
> >>>
> >>
> >> Not sure what a "probed device" is here, I what thinking:
> >>  for each 
> >> for each driver
> >> driver.probe(device)
> >>
> >> Is that what you meant?
> >>
> >>
> >>> [FF] no:
> >  for each 
> >
> >> for each enumerated device
> >>  for each registered driver
> >>
> >driver.probe(device)
> >
> >>
> >>> But that is only for static discovery at the program startup.
> >>>
> >>
> >> yes
> >>
> >>
> >>>
> >>> It would be way better to allow hotplugs (card insertion in a chassis,
> >>> addition of one virtual interfrace in aa VM because of a scale up
> >>> operation).
> >>>
> >>
> >> yes: we can probe new hotplugged devices (again registered drivers) when
> >> a new device is hot plugged and and probe registered (unassigned) device
> >> again any hot plugged driver.
> >>
> >>
> >>>
> >>> So in addition to initial synchronous probing we need asynchronous
> >>> events handling.
> >>>
> >>
> >> yes
> >>
> >>
> >>>
> >>> Once we have found the device, we need to check if we have a driver for
> >>> it and if the "user" has decided if he wants to use that device
> >>> (configuration aspects)
> >>>
> >>
> >> I guess the fact that a user loads a driver is an act of configuration...?
> >>  [FF] I guess not, load all drivers
> >>
> >>>
> >>> 2) driver assignment
> >>> From this device we may want to enumerate ports and other "things" (like
> >>> embeded switch) that are present on the device.
> >>>
> >>
> >> hmmm... so a device driver could act as a new enumerator? I am not fully
> >> following your proposal here... Let's say 2 PCI board contains (each) its
> >> switch (one switch per board). The PCI enumerator will detect 2 devices. So
> >> according to your proposal, we would also have switch enumerators? How many
> >> such switch enumerator do we have? Where is it located?
> >> [FF]: lets make a simpler example: 2 PCI devices, each with four 10Gbps
> >> ethernet ports. there are two enumerated PCI devices but there are 8
> >> packet_ios. packet ios should conserve a link to a device, the device
> >> should have a link back to the enumerator. no upperlayer metadata saved in
> >> each "object", just a link.

Just 1 enumeration and driver layer? On top-level (PCI, SoC bus) enumerator, say
2 devices probed and assigned driver. In driver on device init, a
representation of hw (pktio, classifier, scheduler, ..) returned to rest of
system. Ideally hotpluggable. Could device driver act as another enumerator if
there are further busses and devices which may be interchangeable across the 2
devices?

> >>>
> >>> Accessing devices is bus dependent, os dependent and processor
> >>> dependent.
> >>> A few problems to tackle:
> >>> - On Linux, a device can be accessed 

Re: [lng-odp] driver interface thinkings....

[Francois Ozog]

To deal with drivers we need to have additional "standard" (helper or API?)
objects to deal with MAC addresses.

ODP could be made to handle SDH, SDLC, FrameRelay or ATM packets. A
packet_io is pretty generic...

But as soon as we talk with drivers and initialization, we need to deal
with L1 initialization (link up/ synchronized...) and L2 initialization
(DLCI, MAC (Ethernet, FDDI, TokenRing...)...).

Shall we add those L1 and L3 concepts ?

FF

On 9 November 2016 at 09:38, Francois Ozog  wrote:

>
>
> On 9 November 2016 at 09:09, Christophe Milard <
> christophe.mil...@linaro.org> wrote:
>
>>
>>
>> On 8 November 2016 at 18:19, Francois Ozog 
>> wrote:
>>
>>> Hi Christophe,
>>>
>>> We are focusing on network devices which have at least network ports.
>>> Inventory of devices and ports are two distinct topics as there is no
>>> guarantee that there is one device per port. (Intel and Mellanox have this
>>> policy: one device per PCI port, but many others have one PCI device for
>>> multiple ports (Chelsio...)
>>>
>>> 1) device discovery
>>>
>>> So let's focus first on device discovery.
>>>
>>> Devices can be found from:
>>> - static "configuration" based on ODP implementation
>>> - ACPI
>>> - PCI
>>> - DPAA2 NXP bus
>>> - VMBus (VMs running on Microsoft Hyper-V hypervisor)
>>> - others ?
>>>
>>> So bus are somewhat limited (ACPI is NOT a bus). I prefer to talk about
>>> device enumerators.
>>>
>>
>> OK.
>>
>>
>>>
>>> so we can loop through all devices using your proposed:
>>> for each 
>>> for each probed device
>>>
>>
>> Not sure what a "probed device" is here, I what thinking:
>>  for each 
>> for each driver
>> driver.probe(device)
>>
>> Is that what you meant?
>>
>>
>>> [FF] no:
>  for each 
>
>> for each enumerated device
>>  for each registered driver
>>
>driver.probe(device)
>
>>
>>> But that is only for static discovery at the program startup.
>>>
>>
>> yes
>>
>>
>>>
>>> It would be way better to allow hotplugs (card insertion in a chassis,
>>> addition of one virtual interfrace in aa VM because of a scale up
>>> operation).
>>>
>>
>> yes: we can probe new hotplugged devices (again registered drivers) when
>> a new device is hot plugged and and probe registered (unassigned) device
>> again any hot plugged driver.
>>
>>
>>>
>>> So in addition to initial synchronous probing we need asynchronous
>>> events handling.
>>>
>>
>> yes
>>
>>
>>>
>>> Once we have found the device, we need to check if we have a driver for
>>> it and if the "user" has decided if he wants to use that device
>>> (configuration aspects)
>>>
>>
>> I guess the fact that a user loads a driver is an act of configuration...?
>>  [FF] I guess not, load all drivers
>>
>>>
>>> 2) driver assignment
>>> From this device we may want to enumerate ports and other "things" (like
>>> embeded switch) that are present on the device.
>>>
>>
>> hmmm... so a device driver could act as a new enumerator? I am not fully
>> following your proposal here... Let's say 2 PCI board contains (each) its
>> switch (one switch per board). The PCI enumerator will detect 2 devices. So
>> according to your proposal, we would also have switch enumerators? How many
>> such switch enumerator do we have? Where is it located?
>> [FF]: lets make a simpler example: 2 PCI devices, each with four 10Gbps
>> ethernet ports. there are two enumerated PCI devices but there are 8
>> packet_ios. packet ios should conserve a link to a device, the device
>> should have a link back to the enumerator. no upperlayer metadata saved in
>> each "object", just a link.
>>
>>>
>>> Accessing devices is bus dependent, os dependent and processor
>>> dependent.
>>> A few problems to tackle:
>>> - On Linux, a device can be accessed through uio, vfio or through a
>>> direct library (cf bifurcated drivers)
>>>
>>
>> yes. So  a device enumerator will give many interface to play with the
>> devices it enumerates. In my first example, I called BUS what you call
>> enumerator and DRIVER_TYPE was the key to select the device interface (like
>> PCI_VFIO wouild select the vfio interface).  If we keep with the enumerator
>> view (that I like), shall each enumerator give a choice of
>> "device-interface" for each of its device? I.E:
>> my BUS = your enumerator (OK)
>> my DRIVER_TYPE = device_interface?
>>  [FF] not sure I understand
>>
>
>
>> - if uio, it also depends on the processor architecture (Intel has a
>>> special way of exposing uio, PPC64 and ARM64 are different)
>>>
>>
>> Haven't digged into uio yet ...
>>
>>
>>
>>> - if bifurcated driver, the "odp/dpdk driver" SHOULD not deal directly
>>> with the PCI device but rather with the device specific library
>>>
>>
>> "odp/dpdk driver"...Are you planning for a new driver structure for dpdk
>> too, which we would share ?
>> Not sure I understand what you meant there. I though bifurcated drivers
>> where just drivers getting their data from userland 

Re: [lng-odp] driver interface thinkings....

[Francois Ozog]

On 9 November 2016 at 09:09, Christophe Milard  wrote:

>
>
> On 8 November 2016 at 18:19, Francois Ozog 
> wrote:
>
>> Hi Christophe,
>>
>> We are focusing on network devices which have at least network ports.
>> Inventory of devices and ports are two distinct topics as there is no
>> guarantee that there is one device per port. (Intel and Mellanox have this
>> policy: one device per PCI port, but many others have one PCI device for
>> multiple ports (Chelsio...)
>>
>> 1) device discovery
>>
>> So let's focus first on device discovery.
>>
>> Devices can be found from:
>> - static "configuration" based on ODP implementation
>> - ACPI
>> - PCI
>> - DPAA2 NXP bus
>> - VMBus (VMs running on Microsoft Hyper-V hypervisor)
>> - others ?
>>
>> So bus are somewhat limited (ACPI is NOT a bus). I prefer to talk about
>> device enumerators.
>>
>
> OK.
>
>
>>
>> so we can loop through all devices using your proposed:
>> for each 
>> for each probed device
>>
>
> Not sure what a "probed device" is here, I what thinking:
>  for each 
> for each driver
> driver.probe(device)
>
> Is that what you meant?
>
>
>> [FF] no:
 for each 

> for each enumerated device
>  for each registered driver
>
   driver.probe(device)

>
>> But that is only for static discovery at the program startup.
>>
>
> yes
>
>
>>
>> It would be way better to allow hotplugs (card insertion in a chassis,
>> addition of one virtual interfrace in aa VM because of a scale up
>> operation).
>>
>
> yes: we can probe new hotplugged devices (again registered drivers) when a
> new device is hot plugged and and probe registered (unassigned) device
> again any hot plugged driver.
>
>
>>
>> So in addition to initial synchronous probing we need asynchronous events
>> handling.
>>
>
> yes
>
>
>>
>> Once we have found the device, we need to check if we have a driver for
>> it and if the "user" has decided if he wants to use that device
>> (configuration aspects)
>>
>
> I guess the fact that a user loads a driver is an act of configuration...?
>  [FF] I guess not, load all drivers
>
>>
>> 2) driver assignment
>> From this device we may want to enumerate ports and other "things" (like
>> embeded switch) that are present on the device.
>>
>
> hmmm... so a device driver could act as a new enumerator? I am not fully
> following your proposal here... Let's say 2 PCI board contains (each) its
> switch (one switch per board). The PCI enumerator will detect 2 devices. So
> according to your proposal, we would also have switch enumerators? How many
> such switch enumerator do we have? Where is it located?
> [FF]: lets make a simpler example: 2 PCI devices, each with four 10Gbps
> ethernet ports. there are two enumerated PCI devices but there are 8
> packet_ios. packet ios should conserve a link to a device, the device
> should have a link back to the enumerator. no upperlayer metadata saved in
> each "object", just a link.
>
>>
>> Accessing devices is bus dependent, os dependent and processor dependent.
>> A few problems to tackle:
>> - On Linux, a device can be accessed through uio, vfio or through a
>> direct library (cf bifurcated drivers)
>>
>
> yes. So  a device enumerator will give many interface to play with the
> devices it enumerates. In my first example, I called BUS what you call
> enumerator and DRIVER_TYPE was the key to select the device interface (like
> PCI_VFIO wouild select the vfio interface).  If we keep with the enumerator
> view (that I like), shall each enumerator give a choice of
> "device-interface" for each of its device? I.E:
> my BUS = your enumerator (OK)
> my DRIVER_TYPE = device_interface?
>  [FF] not sure I understand
>


> - if uio, it also depends on the processor architecture (Intel has a
>> special way of exposing uio, PPC64 and ARM64 are different)
>>
>
> Haven't digged into uio yet ...
>
>
>
>> - if bifurcated driver, the "odp/dpdk driver" SHOULD not deal directly
>> with the PCI device but rather with the device specific library
>>
>
> "odp/dpdk driver"...Are you planning for a new driver structure for dpdk
> too, which we would share ?
> Not sure I understand what you meant there. I though bifurcated drivers
> where just drivers getting their data from userland application but
> controled by kernel tools. I guess my view is not complete here.
> [FF] when you bind a driver to uio, the netdev disappears. When using
> bifurcated drivers it does not.
>
>>
>> 3) created objects in ODP
>> odp_pktio_t is somewhat corresponding to a port "driver". it does
>> properly adapts to a device with multiple ports.
>>
>
> Not sure of the match when you started talking about the embeded
> switches...
>
[FF] I keep hw discovery/inventory/representation (hierarchy of connected
elements) separate from the functional aspects (drivers, ports,
controllable hw blocks such as classifier, scheduler...).  .I guess we can
represent the switch as if it was a 

Re: [lng-odp] driver interface thinkings....

[Christophe Milard]

On 8 November 2016 at 18:19, Francois Ozog  wrote:

> Hi Christophe,
>
> We are focusing on network devices which have at least network ports.
> Inventory of devices and ports are two distinct topics as there is no
> guarantee that there is one device per port. (Intel and Mellanox have this
> policy: one device per PCI port, but many others have one PCI device for
> multiple ports (Chelsio...)
>
> 1) device discovery
>
> So let's focus first on device discovery.
>
> Devices can be found from:
> - static "configuration" based on ODP implementation
> - ACPI
> - PCI
> - DPAA2 NXP bus
> - VMBus (VMs running on Microsoft Hyper-V hypervisor)
> - others ?
>
> So bus are somewhat limited (ACPI is NOT a bus). I prefer to talk about
> device enumerators.
>

OK.


>
> so we can loop through all devices using your proposed:
> for each 
> for each probed device
>

Not sure what a "probed device" is here, I what thinking:
 for each 
for each driver
driver.probe(device)

Is that what you meant?


>
> But that is only for static discovery at the program startup.
>

yes


>
> It would be way better to allow hotplugs (card insertion in a chassis,
> addition of one virtual interfrace in aa VM because of a scale up
> operation).
>

yes: we can probe new hotplugged devices (again registered drivers) when a
new device is hot plugged and and probe registered (unassigned) device
again any hot plugged driver.


>
> So in addition to initial synchronous probing we need asynchronous events
> handling.
>

yes


>
> Once we have found the device, we need to check if we have a driver for it
> and if the "user" has decided if he wants to use that device (configuration
> aspects)
>

I guess the fact that a user loads a driver is an act of configuration...?


>
> 2) driver assignment
> From this device we may want to enumerate ports and other "things" (like
> embeded switch) that are present on the device.
>

hmmm... so a device driver could act as a new enumerator? I am not fully
following your proposal here... Let's say 2 PCI board contains (each) its
switch (one switch per board). The PCI enumerator will detect 2 devices. So
according to your proposal, we would also have switch enumerators? How many
such switch enumerator do we have? Where is it located?


> Accessing devices is bus dependent, os dependent and processor dependent.
> A few problems to tackle:
> - On Linux, a device can be accessed through uio, vfio or through a direct
> library (cf bifurcated drivers)
>

yes. So  a device enumerator will give many interface to play with the
devices it enumerates. In my first example, I called BUS what you call
enumerator and DRIVER_TYPE was the key to select the device interface (like
PCI_VFIO wouild select the vfio interface).  If we keep with the enumerator
view (that I like), shall each enumerator give a choice of
"device-interface" for each of its device? I.E:
my BUS = your enumerator (OK)
my DRIVER_TYPE = device_interface?


> - if uio, it also depends on the processor architecture (Intel has a
> special way of exposing uio, PPC64 and ARM64 are different)
>

Haven't digged into uio yet ...



> - if bifurcated driver, the "odp/dpdk driver" SHOULD not deal directly
> with the PCI device but rather with the device specific library
>

"odp/dpdk driver"...Are you planning for a new driver structure for dpdk
too, which we would share ?
Not sure I understand what you meant there. I though bifurcated drivers
where just drivers getting their data from userland application but
controled by kernel tools. I guess my view is not complete here.


> 3) created objects in ODP
> odp_pktio_t is somewhat corresponding to a port "driver". it does properly
> adapts to a device with multiple ports.
>

Not sure of the match when you started talking about the embeded switches...

Christophe.

>
> FF
>
>
>
>
>
> On 7 November 2016 at 17:49, Christophe Milard <
> christophe.mil...@linaro.org> wrote:
>
>> Bonsoir Francois,
>>
>> I'll take that in English thereafter so that other can read (copy to the
>> list).
>>
>> I have looked at that:
>>
>> https://dpdksummit.com/Archive/pdf/2016Userspace/Day02-
>> Session03-ShreyanshJain-Userspace2016.pdf
>>
>> I guess that is what you referred to, Francois, when talking at the
>> SYNC meeting earlier today. I missed a lot of was you said, though, my
>> BJ being extremely uncooperative today.
>>
>> I have not seen the presentation, but my understanding is that PCI
>> drivers would "require" PCI bus drivers. As SocX driver could require
>> Soc bus scan.
>> I have to admit that I did not follow 100%  the DPDK proposal, but
>> this approach to have a "BUS driver" is not very clear to me, when it
>> comes to ODP:
>>
>> 1)Because SoC constructors will probably accelerate more than the
>> interface. If those constructors have, for instance, different
>> odp-packet implementation (matching their HW), they will likely have
>> their own ODP implementation anyway, so making the bus 

Re: [lng-odp] driver interface thinkings....

[Francois Ozog]

Hi Christophe,

We are focusing on network devices which have at least network ports.
Inventory of devices and ports are two distinct topics as there is no
guarantee that there is one device per port. (Intel and Mellanox have this
policy: one device per PCI port, but many others have one PCI device for
multiple ports (Chelsio...)

1) device discovery

So let's focus first on device discovery.

Devices can be found from:
- static "configuration" based on ODP implementation
- ACPI
- PCI
- DPAA2 NXP bus
- VMBus (VMs running on Microsoft Hyper-V hypervisor)
- others ?

So bus are somewhat limited (ACPI is NOT a bus). I prefer to talk about
device enumerators.

so we can loop through all devices using your proposed:
for each 
for each probed device

But that is only for static discovery at the program startup.

It would be way better to allow hotplugs (card insertion in a chassis,
addition of one virtual interfrace in aa VM because of a scale up
operation).

So in addition to initial synchronous probing we need asynchronous events
handling.

Once we have found the device, we need to check if we have a driver for it
and if the "user" has decided if he wants to use that device (configuration
aspects)

2) driver assignment
>From this device we may want to enumerate ports and other "things" (like
embeded switch) that are present on the device.

Accessing devices is bus dependent, os dependent and processor dependent.
A few problems to tackle:
- On Linux, a device can be accessed through uio, vfio or through a direct
library (cf bifurcated drivers)
- if uio, it also depends on the processor architecture (Intel has a
special way of exposing uio, PPC64 and ARM64 are different)
- if bifurcated driver, the "odp/dpdk driver" SHOULD not deal directly with
the PCI device but rather with the device specific library

3) created objects in ODP
odp_pktio_t is somewhat corresponding to a port "driver". it does properly
adapts to a device with multiple ports.

FF





On 7 November 2016 at 17:49, Christophe Milard  wrote:

> Bonsoir Francois,
>
> I'll take that in English thereafter so that other can read (copy to the
> list).
>
> I have looked at that:
>
> https://dpdksummit.com/Archive/pdf/2016Userspace/
> Day02-Session03-ShreyanshJain-Userspace2016.pdf
>
> I guess that is what you referred to, Francois, when talking at the
> SYNC meeting earlier today. I missed a lot of was you said, though, my
> BJ being extremely uncooperative today.
>
> I have not seen the presentation, but my understanding is that PCI
> drivers would "require" PCI bus drivers. As SocX driver could require
> Soc bus scan.
> I have to admit that I did not follow 100%  the DPDK proposal, but
> this approach to have a "BUS driver" is not very clear to me, when it
> comes to ODP:
>
> 1)Because SoC constructors will probably accelerate more than the
> interface. If those constructors have, for instance, different
> odp-packet implementation (matching their HW), they will likely have
> their own ODP implementation anyway, so making the bus enumerator a
> driver will not help them.
>
> 2)Bus enumeration and ressource mapping would likely require quite a
> lot of assumptions regarding the OS/platform the BUS driver runs on
> (such as the persence of the /sys fs on linux).
> That would make the driver OS/Platform dependent: not a big deal for
> DPDK (which is mainly targetting linux/X86),  but maybe more a problem
> for ODP...
>
> I have to admit that having driver dependencies (a bit like package
> systems like apt-get/rpm have) would have benefits as well, but not
> sure that it would be best for us. Isn't the goal of ODP being mostly
> an API to enable completely different  implementations? Is there a
> point trying to go for more than standart busses in the linux generic
> implementation then?
>
> By the way: How does the NXP board interface the machine? Not sure I
> understand their case...
>
>
> My intension was to do Bus enumeration in ODP, and provide driver
> registration in ODP as well. So eventually, ODP would build a list of
> devices for each bus and a list of registered drivers.
>
>  Then ODP would do something like:
> for each bus
> for each device of this bus
> for each driver
> if driver.bus == bus, then call driver.probe(device),
> if probe() returns true (the driver can handle the
> device), then break;
>
> Basically saying that the first driver whose probe() fnct returns true
> is good to go.
>
> This is a simpler model (and It would be limited to PCI busses to
> start with), but it hopefully would enable drivers to be OS/platform
> agnostic: If, PCI for instance, is handled differentely on different
> ODP implementation, the board driver would not have to care as long as
> the ODPDRV-pci interface remains the same.
>
> Any other voices?
>
> Those who want to TALK to me are VERY welcomed to HO me! :-)
>
> Thks for reading :-)
>
> Christophe.
>



-- 
[image: Linaro] 

[lng-odp] driver interface thinkings....

[Christophe Milard]

Bonsoir Francois,

I'll take that in English thereafter so that other can read (copy to the list).

I have looked at that:

https://dpdksummit.com/Archive/pdf/2016Userspace/Day02-Session03-ShreyanshJain-Userspace2016.pdf

I guess that is what you referred to, Francois, when talking at the
SYNC meeting earlier today. I missed a lot of was you said, though, my
BJ being extremely uncooperative today.

I have not seen the presentation, but my understanding is that PCI
drivers would "require" PCI bus drivers. As SocX driver could require
Soc bus scan.
I have to admit that I did not follow 100%  the DPDK proposal, but
this approach to have a "BUS driver" is not very clear to me, when it
comes to ODP:

1)Because SoC constructors will probably accelerate more than the
interface. If those constructors have, for instance, different
odp-packet implementation (matching their HW), they will likely have
their own ODP implementation anyway, so making the bus enumerator a
driver will not help them.

2)Bus enumeration and ressource mapping would likely require quite a
lot of assumptions regarding the OS/platform the BUS driver runs on
(such as the persence of the /sys fs on linux).
That would make the driver OS/Platform dependent: not a big deal for
DPDK (which is mainly targetting linux/X86),  but maybe more a problem
for ODP...

I have to admit that having driver dependencies (a bit like package
systems like apt-get/rpm have) would have benefits as well, but not
sure that it would be best for us. Isn't the goal of ODP being mostly
an API to enable completely different  implementations? Is there a
point trying to go for more than standart busses in the linux generic
implementation then?

By the way: How does the NXP board interface the machine? Not sure I
understand their case...


My intension was to do Bus enumeration in ODP, and provide driver
registration in ODP as well. So eventually, ODP would build a list of
devices for each bus and a list of registered drivers.

 Then ODP would do something like:
for each bus
for each device of this bus
for each driver
if driver.bus == bus, then call driver.probe(device),
if probe() returns true (the driver can handle the
device), then break;

Basically saying that the first driver whose probe() fnct returns true
is good to go.

This is a simpler model (and It would be limited to PCI busses to
start with), but it hopefully would enable drivers to be OS/platform
agnostic: If, PCI for instance, is handled differentely on different
ODP implementation, the board driver would not have to care as long as
the ODPDRV-pci interface remains the same.

Any other voices?

Those who want to TALK to me are VERY welcomed to HO me! :-)

Thks for reading :-)

Christophe.