On 17/04/2019 19:04, H. Peter Anvin wrote:
> On 4/15/19 10:22 AM, Adhemerval Zanella wrote:
>>>
>>> New interfaces are only necessary for the handful of architectures that
>>> don't have the speed fields *and* to space to put them in.
>>
>> Based on your WIP, it seems that both sparc and mips could be adapted.
>> Do we still have glibc supported architecture that would require compat
>> symbols?
>>
>>>
>>> Using symbol versioning doesn't really help much since the real problem is
>>> that struct termios can be passed around in userspace, and the interfaces
>>> between user space libraries don't have any versioning. However, my POC
>>> code deals with that too by only seeing BOTHER when necessary, so if the
>>> structure is extended garbage in the extra fields will be ignored unless
>>> new baud rates are in use.
>>
>> Yeah, we discussed this earlier and if recall correctly it was not settled
>> that all architectures would allow the use to extra space for the new
>> fields. It seems the case, which makes the adaptation for termios2 even
>> easier.
>>
>> The question I have for kernel side is whether termios2 is fully compatible
>> with termios, meaning that if there is conner cases we need to handle in
>> userland.
>>
>
> It depends on what you mean with "fully compatible."
>
> Functionality-wise, the termios2 interfaces are a strict superset. There
> is not, however, any guarantee that struct kernel_termios2 *contains* a
> contiguous binary equivalent to struct kernel_termios (in fact, on most
> architectures, it doesn't.)
I mean that we can fully implement termios1 using termios2 by adjusting
the termios struct in syscall wrappers. If it is a superset I think it
is fine.
>
>>>
>>> My POC code deals with Alpha as well by falling back to the old interfaces
>>> if necessary and possible, otherwise return error.
>>>
>>> Exporting termios2 to user space feels a bit odd at this stage as it would
>>> only be usable as a fallback on old glibc. Call it kernel_termios2 at
>>> least. ioctls using struct termios *must* be changed to kernel_termios
>>> anyway!
>>>
>>
>> I still prefer to avoid export it to userland and make it usable through
>> default termios, as your wip does. My understanding is new interfaces
>> should be semantic equal to current one with the only deviation that
>> non-standard baudrates will handled as its values. The only issue I
>> can foresee is if POSIX starts to export new bauds value.
>>
>
> ... which will be easy to handle: just define a Bxxxx constant with the
> value equal to the baud rate.
>
> -hhpa
Right.
