Very much looking forward for working newlib alternatives!

I am not quite sure I understand the idea behind the uart_stdio module, though. I see it cleans up the syscalls.c code a bit, but it does not really bring any architectural improvements. How about a slightly changed approach (which to this point is just a matter of some renaming):

Rename the header from uart_stdio.h to stdio.h and strip it to these three functions:

void stdio_init(void);
int stdio_read(char* buffer, int len);
int stdio_write(const char* buffer, int len);

This interface can now be implemented in different ways (one of them of course being uart) and we can chose during compile time which of the implementation we would like to use. For simplicity it surely makes sense to set the stdio_uart module as default, but this way it can be overwritten in the Makefile with something like USEMODULE += stdio_sockets or so...

Does this make sense?

Does this make sense?

Well, if you'd want to implement a generic stdio_ module, and at some point you want to use uart for a file descriptor, you can use exactly this module. So, this module is a wrapper from uart0 or periph/uart + interrupt handling to posix read/write.

At some point we might have x86_console_stdio, ..., and this module, and in newlibs syscalls, we can have a (either static or dynamic) file descriptor table, mapping e.g. _file_descriptors[0].write to uart_write.

But does musl libc work on systems without an MMU?

edit Yes.

Does this make sense?

Well, if you'd want to implement a generic stdio_ module, and at some point you want to use uart for a file descriptor, you can use exactly this module. So, this module is a wrapper from uart0 or periph/uart + interrupt handling to posix read/write.

At some point we might have x86_console_stdio, ..., and this module, and in newlibs syscalls, we can have a (either static or dynamic) file descriptor table, mapping e.g. _file_descriptors[0].write to uart_write.

@kaspar030 See also the (now removed) device map/device IO stuff in the mulle port in https://github.com/RIOT-OS/RIOT/tree/bdc12b05cda97b7d9f11a079bd9dac9d59e1a8a8/cpu/k60/devio and https://github.com/RIOT-OS/RIOT/blob/bdc12b05cda97b7d9f11a079bd9dac9d59e1a8a8/boards/mulle/devicemap.c

It was deleted when migrating all the Kinetis platforms to the common Cortex-M framework in #3099 (6e12503), but feel free to reuse any parts of it that you find useful.

@haukepetersen I would suggest that the name of the new header be something other than stdio.h because the C library (be it newlib, musl, glibc) will have its printf functions etc. declared in a header with the same name which will cause problems.

;)

I dont care about the name, my idea was just to rename the header into something more generic instead of having uart in it...

rename the header into something more generic instead of having uart in it

Are you happy with uart_stdio being the implementation of an stdio interface for uart devices?

yes.

I look at it the following way: Take e.g. the _read_r() function in the syscalls. Currently it calls uart_stdio_read(). Say there is now another stdio implementation with the function socket_stdio_read(). When you want to switch to this, you would have another _read_r() function that calls socket_stdio_read(), or have some #ifdef inside _read_r() to decide which of the two above to call.

When now renaming the interace functions to something without the reference to its implementation (e.g. stdio_read() or similar), then you can just compile in one of the implementing modules and there is no need in code changes (or #ifedfs) in syscalls.c.

Well, I look at it this way:
The system calls, e.g., _read_r, take a "file descriptor" as argument. Right know, they only support one file descriptor: 0 (STDIO). Right now, that file descriptor is hard-coded to uart.

In the feature, we will have files, and maybe different simultaneous UARTs, and maybe sockets. They all can use read, write, flush, close.

So we need an interface, e.g.,

struct stdio_fd_interface { fd_read_func_t *read; fd_write_func_t *write; [...] }stdio_fd_interface_t;

An uart implementation:

const stdio_fd_interface_t uart_fd_interface = { .read = uart_stdio_read; .write = uart_stdio_write; }

and in syscalls.c an array with one stdio_interface_t pointer per file descriptor.

I see, makes sense. Though I am not a 100% content with the file descriptor idea, though I have no hard arguments against it. But this is another discussion, so for this PR I am fine for now.

• accidently already squashed fix

• fixed license header
• rebased

Apart from the documentation this seems to be fine.

• fixed doxygen

ACK. Please squash!

• squashed again

• addressed @gebart's comment
• rebased
• squashed again

• fixed typo
• squashed

Needs a rebase, too.

Travis is happy...

ACK holds - and go!

perfect. thanks for reviewing!