On April 18, 2019 4:09:07 AM PDT, Adhemerval Zanella <adhemerval.zanella@xxxxxxxxxx> 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.
