From: hpa@zytor.com
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>,
Florian Weimer <fweimer@redhat.com>
Cc: linux-api@vger.kernel.org, libc-alpha@sourceware.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] Linux: Define struct termios2 in <termios.h> under _GNU_SOURCE [BZ #10339]
Date: Thu, 18 Apr 2019 07:46:39 -0700 [thread overview]
Message-ID: <50A91072-AEEB-4A05-BF7C-41086B17A4F9@zytor.com> (raw)
In-Reply-To: <4ae23f8e-c5e5-2d11-8508-82e5dd4c1e2b@linaro.org>
On April 18, 2019 4:09:07 AM PDT, Adhemerval Zanella <adhemerval.zanella@linaro.org> 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
>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.
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.
next prev parent reply other threads:[~2019-04-18 14:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-09 10:47 [PATCH] Linux: Define struct termios2 in <termios.h> under _GNU_SOURCE [BZ #10339] Florian Weimer
2019-04-09 15:02 ` hpa
2019-04-10 6:50 ` Florian Weimer
2019-04-15 15:54 ` hpa
2019-04-09 15:07 ` hpa
2019-04-09 16:04 ` Florian Weimer
2019-04-10 20:24 ` Adhemerval Zanella
2019-04-11 11:07 ` Florian Weimer
2019-04-11 12:53 ` Adhemerval Zanella
2019-04-12 7:50 ` Florian Weimer
2019-04-15 12:28 ` Florian Weimer
2019-04-15 15:53 ` hpa
2019-04-15 17:22 ` Adhemerval Zanella
2019-04-17 22:04 ` H. Peter Anvin
2019-04-18 11:09 ` Adhemerval Zanella
2019-04-18 14:46 ` hpa [this message]
2019-04-16 9:59 ` Florian Weimer
2019-04-16 12:11 ` Adhemerval Zanella
2019-04-17 22:06 ` H. Peter Anvin
2019-04-17 21:22 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50A91072-AEEB-4A05-BF7C-41086B17A4F9@zytor.com \
--to=hpa@zytor.com \
--cc=adhemerval.zanella@linaro.org \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).