On 22/05/2019 15:55, Joel Sherrill wrote:
On Wed, May 22, 2019 at 8:40 AM Sebastian Huber <sebastian.hu...@embedded-brains.de <mailto: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?
No, I think it is good that they are somewhat hidden. -- 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
