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 i
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
On 4/16/19 2:59 AM, Florian Weimer wrote:
> * hpa:
>
>> 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 w
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
On Tue, 9 Apr 2019, Florian Weimer wrote:
> diff --git a/sysdeps/unix/sysv/linux/Makefile
> b/sysdeps/unix/sysv/linux/Makefile
> index 52ac6ad484..4cb5e4f0d2 100644
> --- a/sysdeps/unix/sysv/linux/Makefile
> +++ b/sysdeps/unix/sysv/linux/Makefile
> @@ -156,6 +156,7 @@ endif
>
> ifeq ($(subdir)
On 16/04/2019 06:59, Florian Weimer wrote:
> * hpa:
>
>> 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 dea
* hpa:
> 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 necessar
On 15/04/2019 12:53, h...@zytor.com wrote:
> On April 12, 2019 12:50:41 AM PDT, Florian Weimer wrote:
>> * Adhemerval Zanella:
>>
>>> On 11/04/2019 08:07, Florian Weimer wrote:
* Adhemerval Zanella:
> This allows us to adjust the baud rates to non-standard values
>> using termios
On April 9, 2019 11:50:24 PM PDT, Florian Weimer wrote:
>* hpa:
>
>> PowerPC doesn't need it at all.
>
>Because the definition would be the same as struct termios?
>
>I think we should still define struct termios2 using the struct termios
>definition, and also define TCGETS2 and TCSETS2. This way
On April 12, 2019 12:50:41 AM PDT, Florian Weimer wrote:
>* Adhemerval Zanella:
>
>> On 11/04/2019 08:07, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
This allows us to adjust the baud rates to non-standard values
>using termios
interfaces without to resorting to add new headers
* Florian Weimer:
> My gut feeling is that it's safer to add new interfaces, based on the
> actual kernel/userspace interface, rather than trying to fix up existing
> interfaces with symbol versioning. The main reason is that code
> involving serial interfaces is difficult to test, so it will tak
* Adhemerval Zanella:
> On 11/04/2019 08:07, Florian Weimer wrote:
>> * Adhemerval Zanella:
>>
>>> This allows us to adjust the baud rates to non-standard values using termios
>>> interfaces without to resorting to add new headers and use a different API
>>> (ioctl).
>>
>> How much symbol versio
On 11/04/2019 08:07, Florian Weimer wrote:
> * Adhemerval Zanella:
>
>> This allows us to adjust the baud rates to non-standard values using termios
>> interfaces without to resorting to add new headers and use a different API
>> (ioctl).
>
> How much symbol versioning will be required for thi
* Adhemerval Zanella:
> This allows us to adjust the baud rates to non-standard values using termios
> interfaces without to resorting to add new headers and use a different API
> (ioctl).
How much symbol versioning will be required for this change?
> As Peter Anvin has indicated, he create a PO
On 09/04/2019 07:47, Florian Weimer wrote:
> struct termios2 is required for setting arbitrary baud rates on serial
> ports. and have conflicting
> definitions in the existing termios definitions, which means that it
> is currently very difficult to use TCGETS2/TCSETS2 and struct termios2
> w
* hpa:
> PowerPC doesn't need it at all.
Because the definition would be the same as struct termios?
I think we should still define struct termios2 using the struct termios
definition, and also define TCGETS2 and TCSETS2. This way, applications
can use the struct termios2 type without affecting
On April 9, 2019 4:47:30 AM MDT, Florian Weimer wrote:
>struct termios2 is required for setting arbitrary baud rates on serial
>ports. and have conflicting
>definitions in the existing termios definitions, which means that it
>is currently very difficult to use TCGETS2/TCSETS2 and struct termio
On April 9, 2019 4:47:30 AM MDT, Florian Weimer wrote:
>struct termios2 is required for setting arbitrary baud rates on serial
>ports. and have conflicting
>definitions in the existing termios definitions, which means that it
>is currently very difficult to use TCGETS2/TCSETS2 and struct termio
* hpa:
> Anything blocking the POC code I provided?
I don't recall that, sorry. Would you please provide a reference?
Thanks,
Florian
struct termios2 is required for setting arbitrary baud rates on serial
ports. and have conflicting
definitions in the existing termios definitions, which means that it
is currently very difficult to use TCGETS2/TCSETS2 and struct termios2
with glibc. Providing a definition within glibc resolves
20 matches
Mail list logo
