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/petazzon >> i-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: 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 >> >> > -- [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
