[PATCH] score: Compact objects class indices

[Joel Sherrill]

On Wed, May 22, 2019 at 8:40 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 22/05/2019 15:23, Joel Sherrill wrote:
> > I'm OK with this.
> >
> > Is the statement that the API and class numbers are not
> > guaranteed to be held constant across releases something
> > that should be explicitly in a comment or requirement?
>
> The question is how can an application get one of the class numbers? I
> think the only legal way is to create an object and then use
> rtems_object_id_get_class(). The constants are only for internal use and
> not a part of the API?
>

Originally, they were not exposed at all and the encoding of the object
id was just an artifact of the implementation. The rtems_object* methods
were added to make it easier to decode an existing Id.

So yes. These constants have never been part of the public API because
applications were being supported in decoding Ids, not creating them.

Have you got a use case in mind to add them?

FWIW the original standard did not include what would now be called
object introspection APIs. I wouldn't be opposed to us defining a set of
APIs to examine and walk the object sets. There are already a pretty
good set in the monitor[1] which would make a great base to split off
and formally add to the API set.

So I would like to take a broad holistic view of introspection. There is
lots of useful information that could be reported without people poking
under the hood in ways we discourage.

[1] Credit to Chris for writing these many years ago. git blame still shows
many lines of monitor.h with 1995 and 1996 dates.

>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190522/43cda5fd/attachment-0002.html>