Well, we need to formalize the scope and it looks like this is part of the Device and Driver Framework (DDF) that Christophe works on.
I have asked Christophe to create a document complementing the patches it pushed so that we have a human readable reference on what the DDF does and the general mechanics of it. For instance the DDF can build a "physical" view of things through the various device enumerators (from DT to DPAA2 including ACPi, PCI, virtual, static...). But applications should not care about that. They may care of a "functional representation" derived from that hardware aspect. For instance controlling SFP aspects of a port may require controlling a specific PCI device ID while the port itself is under the control of another PCI device ID. Additional information can be found here: https://docs.google.com/a/linaro.org/presentation/d/1Ecb9-jA_7jbXtgMVImiTePzpOJsa6IldZMeFdjG8ypQ/edit?usp=sharing So until we know how (or even if) the proposed API fits in a functional framework (how it is used by what - application, odp internal, drivers only...) this is premature to introduce it. FF On 7 December 2016 at 12:13, Savolainen, Petri (Nokia - FI/Espoo) < petri.savolai...@nokia-bell-labs.com> wrote: > I know device trees and how ugly those can be …. values are not > documented but you (your driver) just have to know what some list of four > integers (reg = <4, 78865, 6, 565>) may actually mean… > > > > Anyway, the idea here is that > > · an implementation has a way to enumerate resources to the user > as names > > o a name may come from a standard or system specific tool (ifconfig), a > configuration file (even device trees), etc. API does not dictate how user > gets a resource name, or which kind of string that name is. > > · User passes the name to the application (through command line, > config file, env variable). API don’t dictate how that happens. > > · Application passes the name to the implementation and gets a > device ID (odp_dev_t), which it uses as a parameter on other calls > > > > Resource discovery/enumeration/management/etc is left to upper layer. API > is only needed for passing resource identifier information down to the > implementation. And this is how it should be: ODP is a passive library > which does what it’s told to do, the active role is on upper layers (user, > scripts, resource management SW, etc entity). > > > > So, no need to defer the API since it’s flexible enough (to pass any kind > of string down to implementation). Driver, cloud, etc frameworks may then > specify the dev name string format, etc later on, but it would not change > the API if a timer is called “timer0” or “timer0:2” or > “/proc/soc/0/timer/1” or something else. > > > > -Petri > > > > > > > > *From:* Francois Ozog [mailto:francois.o...@linaro.org] > *Sent:* Tuesday, December 06, 2016 5:10 PM > *To:* Bill Fischofer <bill.fischo...@linaro.org> > *Cc:* lng-odp-forward <lng-odp@lists.linaro.org>; Savolainen, Petri > (Nokia - FI/Espoo) <petri.savolai...@nokia-bell-labs.com>; Christophe > Milard <christophe.mil...@linaro.org> > *Subject:* Re: [lng-odp] [API-NEXT PATCHv3 1/3] api: dev: add device apis > for numa support > > > > For the link, I think it ate the .... following it. > > Here it is without decoration: > > http://free-electrons.com/pub/conferences/2013/elce/ > petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf > > > > > > > > On 6 December 2016 at 16:05, Francois Ozog <francois.o...@linaro.org> > wrote: > > OK. So let's defer the API but not the discussion. > > I think we need a "strategic architecture" call. > > > > FF > > > > > > > > On 6 December 2016 at 15:59, Bill Fischofer <bill.fischo...@linaro.org> > wrote: > > I have no problem deferring this if we want to have one of the SoC vendors > drive a more comprehensive approach based on their capabilities which can > then be generalized. BTW, your link doesn't resolve. Typo somewhere? > > > > On Tue, Dec 6, 2016 at 8:47 AM, Francois Ozog <francois.o...@linaro.org> > wrote: > > Devicetree has been formed by and for SoC vendors to represent what they > have on their platforms (CPUs, Memory, interconnects, IOMMUs, ports, IRQ > lines, firmware - http://free-electrons.com/pub/conferences/2013/elce/ > petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf)..... so > it looks like very similar to what Petri is talking about. > > > > ACPI has also a concept of a proximity domains and the relative cost to > use a resource from another domain. > > > > Handling NUMA requires a well thought through approach because it has > implications at many levels in particular for device and driver framework. > > > > Bottom line, regardless if it's value, the introduction of the API seem > too early as I haven't seen the use case that it supports and in particular > the device and drivers framework. > > > > FF > > > > > > > > > > > > > > On 6 December 2016 at 14:23, Bill Fischofer <bill.fischo...@linaro.org> > wrote: > > > > > > On Tue, Dec 6, 2016 at 5:03 AM, Francois Ozog <francois.o...@linaro.org> > wrote: > > Hi Bill, > > > > could you clarify if this "device" is related to devicetree as defined by > Linaro (https://github.com/devicetree-org/devicetree-specification) or > the devices that are in the scope of Christophe Millard, or some other > device concept ? > > > > This is the Device ID proposal that Petri suggested at BKK16. It is not > related to devtree or any other specific taxonomy as the idea was to > establish an abstract "device" framework that would support both individual > sockets or multi-SoC environments. In odp-linux these are basically > placeholder functions as we don't have any cross-platform concept of NUMA. > The idea is that each individual platform that does support NUMA should be > able to map their native concepts into this framework to permit > applications to associate an internal odp_dev_t handle with named devices. > > > > > > FF > > > > > > > > On 6 December 2016 at 04:43, Bill Fischofer <bill.fischo...@linaro.org> > wrote: > > Ping. v3 of this patch is still awaiting review. > > > On Mon, Oct 24, 2016 at 4:29 PM, Bill Fischofer > <bill.fischo...@linaro.org> wrote: > > Add the odp_dev_id() API used for NUMA support > > > > Signed-off-by: Bill Fischofer <bill.fischo...@linaro.org> > > --- > > Changes for v3: > > - Correct ODP_DEV_ANY to ODP_DEV_DEFAULT > > > > Changes for v2: > > - Incorporate changes suggested by Petri > > > > include/odp/api/spec/dev.h | 89 ++++++++++++++++++++++++++++++ > ++++++++++++++++ > > 1 file changed, 89 insertions(+) > > create mode 100644 include/odp/api/spec/dev.h > > > > diff --git a/include/odp/api/spec/dev.h b/include/odp/api/spec/dev.h > > new file mode 100644 > > index 0000000..76d861a > > --- /dev/null > > +++ b/include/odp/api/spec/dev.h > > @@ -0,0 +1,89 @@ > > +/* Copyright (c) 2016, Linaro Limited > > + * All rights reserved. > > + * > > + * SPDX-License-Identifier: BSD-3-Clause > > + */ > > + > > +/** > > + * @file > > + * > > + * ODP device > > + */ > > + > > +#ifndef ODP_API_DEV_H_ > > +#define ODP_API_DEV_H_ > > +#include <odp/visibility_begin.h> > > + > > +#ifdef __cplusplus > > +extern "C" { > > +#endif > > + > > +#include <odp/api/std_types.h> > > + > > +/** @defgroup odp_dev ODP DEVICE > > + * Operations on devices > > + * @{ > > + */ > > + > > +/** > > + * @typedef odp_dev_t > > + * ODP Device > > + */ > > + > > +/** > > + * @def ODP_DEV_NAME_LEN > > + * Maximum device name length in chars > > + */ > > + > > +/** > > + * @def ODP_DEV_DEFAULT > > + * Default device > > + */ > > + > > +/** > > + * @def ODP_DEV_INVALID > > + * Invalid device > > + */ > > + > > +/** > > + * Get Device ID by Name > > + * > > + * Get an implementation-defined device identifier from a device name. > Device > > + * names are supplied as parameter info (command line, file, etc.) to > the > > + * application. This routine translates this symbolic name into an > internal > > + * identifier that can be used to define a device connection hierarchy > for > > + * NUMA or other purposes. > > + * > > + * The reserved id ODP_DEV_DEFAULT may be used as a "don't care" > placeholder > > + * wherever a device id is required. > > + * > > + * @param name Name of the device > > + * > > + * @return Device ID > > + * @retval ODP_DEV_INVALID Device is unknown > > + */ > > +odp_dev_t odp_dev_id(const char *name); > > + > > +/** > > + * Get printable value for an odp_dev_t > > + * > > + * @param hdl odp_dev_t handle to be printed > > + * @return uint64_t value that can be used to print/display this > > + * handle > > + * > > + * @note This routine is intended to be used for diagnostic purposes > > + * to enable applications to generate a printable value that represents > > + * an odp_dev_t handle. > > + */ > > +uint64_t odp_dev_to_u64(odp_dev_t hdl); > > + > > +/** > > + * @} > > + */ > > + > > +#ifdef __cplusplus > > +} > > +#endif > > + > > +#include <odp/visibility_end.h> > > +#endif > > -- > > 2.7.4 > > > > > > > > -- > > [image: Image removed by sender. Linaro] <http://www.linaro.org/> > > *François-Frédéric Ozog* | *Director Linaro Networking Group* > > T: +33.67221.6485 > francois.o...@linaro.org | Skype: ffozog > > > > > > > > > > -- > > [image: Image removed by sender. Linaro] <http://www.linaro.org/> > > *François-Frédéric Ozog* | *Director Linaro Networking Group* > > T: +33.67221.6485 > francois.o...@linaro.org | Skype: ffozog > > > > > > > > > > -- > > [image: Image removed by sender. Linaro] <http://www.linaro.org/> > > *François-Frédéric Ozog* | *Director Linaro Networking Group* > > T: +33.67221.6485 > francois.o...@linaro.org | Skype: ffozog > > > > > > > > -- > > [image: Image removed by sender. Linaro] <http://www.linaro.org/> > > *François-Frédéric Ozog* | *Director Linaro Networking Group* > > T: +33.67221.6485 > francois.o...@linaro.org | Skype: ffozog > > > -- [image: Linaro] <http://www.linaro.org/> François-Frédéric Ozog | *Director Linaro Networking Group* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
