Re: [PATCH 16/16] fix struct termios in mips termios.h

[Rich Felker <dalias@libc.org>]

On Sun, Apr 10, 2016 at 02:16:24PM +0200, Szabolcs Nagy wrote:
> mips termios struct has no ispeed and ospeed members in glibc,
> mips64 is already consistent with glibc.
> 
> this is an abi change.
> ---
>  arch/mips/bits/termios.h | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/arch/mips/bits/termios.h b/arch/mips/bits/termios.h
> index 29b4b22..d97df8c 100644
> --- a/arch/mips/bits/termios.h
> +++ b/arch/mips/bits/termios.h
> @@ -1,13 +1,10 @@
> -struct termios
> -{
> +struct termios {
>  	tcflag_t c_iflag;
>  	tcflag_t c_oflag;
>  	tcflag_t c_cflag;
>  	tcflag_t c_lflag;
>  	cc_t c_line;
>  	cc_t c_cc[NCCS];
> -	speed_t __c_ispeed;
> -	speed_t __c_ospeed;
>  };

This patch (and the whole series) have been pending for a long time
because I did not remember all the motivations behind what musl is
doing now vs what glibc and the kernel do. I've finally gotten around
to digging it up, and here's what the situation seems to be:

While the kernel has lots of nasty legacy arch-specific termios
variants, glibc unifies them (mostly, with some minor exceptions like
omitting the speed fields on mips) and performs userspace
translations.

musl matches the glibc ABI on x86 and other "important ABI targets",
but does not perform any translation. Instead we allow cc_line to
move, and NCCS to vary (only if needed to make other members line up
with the ABI!), on a per-arch basis so that the kernel interfaces can
be used directly without translation. However, space for the unused
speed fields (and for most archs, the excessive NCCS value) were kept
around _in case_ we ever want to switch to doing some level of
translation to provide these facilities. The space for these things is
not to match existing kernel ABIs, but as safety room for
extensibility. So I do not want to be removing them or introducing new
archs that lack them.

What I'd like to do is go ahead and add them back to mips64/n32 (where
they were omitted) and drop this patch. Most of the rest of the
patches in this series are probably okay; I'll continue reviewing
them. The other mips64 ones need to be duplicated for n32, I think.

Rich