This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Linux: Define struct termios2 in <termios.h> under _GNU_SOURCE [BZ #10339]

On April 18, 2019 4:09:07 AM PDT, Adhemerval Zanella <> wrote:
>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
>>> Do we still have glibc supported architecture that would require
>>> 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
>>> that all architectures would allow the use to extra space for the
>>> 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
>>> 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.
>> is not, however, any guarantee that struct kernel_termios2 *contains*
>> contiguous binary equivalent to struct kernel_termios (in fact, on
>> 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
>>> default termios, as your wip does.  My understanding is new
>>> 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
>> value equal to the baud rate.
>> 	-hhpa

termio, termios1 and termios2 are kernel ioctl interfaces ... there are no wrappers; it is an ioctl.

The glibc termios is different from all of these, and already is a wrapper around the kernel-provided ioctls.
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]