On Tue, May 24, 2016 at 1:13 AM, Chris Johns <chr...@rtems.org> wrote: > On 23/05/2016 22:37, Gedare Bloom wrote: >> >> How does this affect user applications? > > > It should not but if a user has an application that is using the plugin > interface there is a struct name change. The previous struct ended in '_t' > and that is reserved for POSIX plus the name included _printk_ and it is a > plugin interface for printf, printk, fprintf and fiprintf (I think). The > change for a user is simple and should be stable from here on. > That's what I thought.
> The rtems_printf interface can become a documented interface and we can > maintain it. The previous interface was functionally fine and is pretty much > as it was but it's user interface needed some rework, which is what I have > done. For example there was no easy way to test if a plugin was present and > if not present dropped all output. > OK, it makes sense. > Going forward there is a benefit for small memory devices and there is a > case for printf possibly mapping to rtems_vprintf for those BSPs. I am not > yet sure how this would be managed but it could be via SYSINT and > confdefs.h. Defining a stable way to manage this sort of things removes the > need for users to handle it in their applications. > > Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
