Hi, I like the idea of alphanumeric identifiers. How about using `#define` or a `enum` that map a alphanumeric token to the RIOT internal numeric identifier? That way the strings come for free in terms of ROM usage. (But as a downside, those strings would be hard to e.g. reuse from within the shell. However, the name of enum constants are visible to GDB.)
E.g. let's say a board configures only one I2C bus which is labeled I2C3 in the
datasheet of the MCU. How about using the following:
#define I2C_ID_3 I2C_DEV(0)
or
typdef enum {
I2C_ID_3 = I2C_DEV(0),
} i2c_dev_stable_id_t;
Kind regards,
Marian
On Thu, 01 Oct 2020 06:18:01 -0400
Michael Richardson <m...@sandelman.ca> wrote:
> chrysn <chr...@fsfe.org> wrote:
> > Do we have any existing text on these kinds of stability? Do we want to?
> > If so, is that RDM material or really just a note to the board porting
> > documentation?
>
> Perhaps not everyone is aware of, has lived through with great frustration,
> the multiple times the "indices" for ethernet devices have changed on Linux
> (and BSD and Solaris).
>
> From order of linking in the kernel for ISA devices, to cmdline= order, to
> PCI reverse index order (a goof), to PCI index order, to moving from ethX to
> ensXXX order due to PCI vs USB ordering, to udev for consistent ordering
> despite hotplug, to...
>
> Fortunately, most devices in the SoC which we typically run on are not
> hotpluggable. Integer indices are really very convenient, but not stable.
> But, that doesn't mean we should use names at runtime, but perhaps it means
> that we should have a name->indice resolution step that is part of the
> linking step.
>
> > # Long-term stability
>
> > Board identities are generally stable: While they may be renamed if it
> turns
> > out that the old name was misleading, a physical board that worked with
> a given
> > name in one release can be expected to work with the next release.
>
> Yes, but refactoring.
> We tend to start with some specific vendorSOC-CPU-devel-board name, and then
> refactor out CPU or SOC, for other devel-board.
>
> --
> ] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works | IoT architect [
> ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails
> [
>
pgpKxtIr4Kk3P.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
