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

Reply via email to