<div dir="ltr"><div>I'm not disagreeing with you at all Peter. This is definitely history and a "grep -r _routine | grep typedef" will show a few other cases where this pattern still exists. In at least one, it is internal and deprecated. </div><div><br></div><div>You are right. This is from the earliest days of RTEMS. I looked in the scanned RTEID and ORKID documents and can't fine the IO manager. I swear it came from there but I did find a pSOS+ manual online and their interface was so bare, it did not use any typedef at all. It even mentioned CPU architecture specific differences. <shudder></div><div><br></div><div>If we want to deprecate it, I'm ok with that. But we should put all of these kind of typedefs. on the way to the dustbin.</div><div><br></div><div>It is definitely used enough where eliminating it will take scripting.<br><br> grep -r "rtems_device_driver " . 2>/dev/null | wc -l<br>710<br></div><div><br></div><div>That doesn't count timer_service_routine, the one for signals, etc.</div><div><br></div><div>I'm not opposed and now is the time if there is consensus. I have reached the point where I acknowledge the long history and mostly am concerned about how changes impact user code more than the idea of change itself.</div><div><br></div><div>--joel</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 29, 2020 at 1:01 PM Peter Dufault <<a href="mailto:dufault@hda.com">dufault@hda.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Sep 29, 2020, at 10:13 , Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
> <br>
> <br>
> <br>
> On Tue, Sep 29, 2020 at 8:54 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
> On 29/09/2020 15:47, Sebastian Huber wrote:<br>
> <br>
> > On 29/09/2020 15:42, Joel Sherrill wrote:<br>
> ><br>
> >><br>
> >><br>
> >> On Tue, Sep 29, 2020 at 8:37 AM Sebastian Huber<br>
> >> <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
> >> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>>> wrote:<br>
> >><br>
> >>     Hello,<br>
> >><br>
> >>     I work currently on the documentation of the IO Manager. What is the<br>
> >>     purpose of<br>
> >><br>
> >>     typedef rtems_status_code rtems_device_driver;<br>
> >><br>
> >>     ?<br>
> >><br>
> >>     For me this looks a bit like camouflage.<br>
> >><br>
> >><br>
> >> No. It is a use of typedef to make the purpose of the method clear.<br>
> >><br>
> >> You have nibbled at these for years. There were at least types for<br>
> >> Classic Tasks, ASRs, and TSRs at one point.<br>
> > Yes, the typedefs to void.<br>
> >><br>
> >> If this is the last one, I'm not going to fight it. This isn't the<br>
> >> hill I am<br>
> >> going to die on.<br>
> > I am not suggesting to remove them although I find these typedefs<br>
> > pretty odd. I just look for some documentation text.<br>
> <br>
> What about this:<br>
> <br>
> /**<br>
>   * @ingroup RTEMSAPIClassicIO<br>
>   *<br>
>   * @brief This type shall be used in device driver entry declarations and<br>
>   *   definitions.<br>
>   *<br>
>   * Device driver entries return an #rtems_status_code status code. This<br>
> type<br>
>   * definition helps to document device driver entries in the source code.<br>
>   */<br>
> typedef rtems_status_code rtems_device_driver;<br>
> <br>
> That's more than sufficient.<br>
> <br>
> Thanks.<br>
<br>
This typedef is odd.  Unless I'm missing a fine-point.<br>
<br>
If the typedef is, and always will remain, "rtems_status_code" I would not use a typedef.<br>
<br>
The RTEMS API documentation is moving to Doxygen (and more formally than that given Sebastian's ESA work). Using a typedef to indicate a function is part of a device driver as "documentation" is not a good idea.<br>
<br>
When I've thought I needed a special return code in the past I've made the return code a "struct" so that it can't be used interchangeably with other return codes, even with casting, and so that you need to be *sure* you really want such a special return type. This probably pre-dates enabling aggressive warnings.<br>
<br>
I haven't done this recently.  Recently I've assumed that:<br>
- Status codes are an integral type;<br>
- Status codes of 0 always mean success.<br>
<br>
Trying to pretend you need to compare a return to a special "success" #define that is 0 is pointless and error prone now-a-days IMHO.<br>
<br>
If I really wanted a return code that was special I'd do something like:<br>
<br>
typedef struct {<br>
  rtems_status_code status; /* Error return. */<br>
  int unused;               /* Unused */<br>
} rtems_device_driver;<br>
<br>
Peter<br>
-----------------<br>
Peter Dufault<br>
HD Associates, Inc.      Software and System Engineering<br>
<br>
This email is delivered through the public internet using protocols subject to interception and tampering.<br>
<br>
</blockquote></div></div>