On Wed, May 22, 2019 at 8:40 AM Sebastian Huber < sebastian.hu...@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.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
