Re: [avr32-libc-devel] read and write system calls

[Boyapati, A. <Ani...@at...>]

> From: praveen kaushik [mailto:pra...@gm...] 
	....

> In NewLib _read syscall's code is:
>
> #define T2H_SYSCALL(syscall_code)                 \
>  asm ("mov   r8, %0\n"                           \
>       "breakpoint\n"                             \
>       "mov   r12, -1\n"                          \
>       "mov   r11, %1\n"                          \
>       :: "i" (syscall_code), "i" (ENOSYS) );
>
> with syscall_code 3.
> but now I dont know what is the logic behind these statements, 
> how it implements _read command?


This appears as a broad area to me (assuming the real question is how to carry out stdin initialization). 3 relevant suggestions though :

1. The above format is called extended assembly. It says that syscall_node (input operand numbered as %0) be moved to r8 and the rest of the code is debugger related stuff which can be followed from comments documented just above T2H_SYCALL(incase you missed it). Further info on extended assembly,  http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html

2. The design of interface between libc functions and syscalls  (as in the case stdio) is not trivial. It requires a good understanding of software framework of a system (for e.g.,with/without OS)and system interfaces. For a posix-like system, the design runs similar to glibc, uclibc and newlib. Essentially, a function like fread(...) ends up calling read syscall to read from a file. For systems without OS support, minimal/trivial interfaces are necessary as suggested by newlib documentation http://www.sourceware.org/newlib/libc.html#Syscalls

3. A certain distinction is necessary between library functions and systemcalls. C standard recommends support for functions fread(...), fwrite, fputc, fgetc...etc. However it leaves the implementation details to a libc developer. A better way of developing libc on a posix-like system is to have them work over the corresponding syscalls. The former has no target-dependent information while the latter has. This means that theoretically porting an existing libc to a new target requires that all syscalls be written for that target while minimal changes to no changes are required for former high-level functions.

In short, I think, a much-indepth knowledge of existing libc is a pre-requisite before embarking onto support (or for deciding to not support) such routines. 

Anitha