On Sunday 10 February 2008, Tilman Schmidt wrote: > Am 10.02.2008 10:38 schrieb Mike Frysinger: > > On Saturday 09 February 2008, Tilman Schmidt wrote: > >> Am 08.02.2008 05:01 schrieb Mike Frysinger: > >>>> while i havent actually tested this, it should be fine. termios2 was > >>>> created because not all arches integrated the speed fields into the > >>>> termios structure. for those that did, there was no need for > >>>> termios2. > >>>> > >>>> until these details get pushed into the libc, the code in ldattach > >>>> prob needs to look something like: > >>>> > >>>> #ifndef TCGETS2 > >>>> #define termios2 termios > >>>> #define TCGETS2 TCGETS > >>>> #define TCSETS2 TCSETS > >>>> #endif > >>>> ... > >>>> #ifdef BOTHER > >>>> < do BOTHER / CBAUD stuff > > >>>> if (ioctl( TCGETS ) works) > >>>> return; > >>>> #endif > >>>> < normal speed functions > > >>>> > >>>> this way you can build a binary against newer headers but have it work > >>>> OK on older kernels where TCGETS2 isnt implemented > >> > >> I'm afraid this isn't going to work on platforms which *did* integrate > >> the speed fields into the termios structure, as there is no way to > >> determine whether the retrieved termios structure does or doesn't > >> contain the speed fields. > > > > i dont really follow. if an arch defines TCGETS2, you can assume the > > termios2 struct exists (regardless of the speed status in the termios > > struct). if an arch does not define TCGETS2, you cn assume the termios > > struct includes the speed members. > > Can I really? Imagine building the above against recent headers on > arch=powerpc. BOTHER is defined, TCGETS2 isn't. The resulting > executable will therefore call ioctl(TCGETS) with a termios structure > including the c_ispeed and c_ospeed fields, and expect them to be set > on return. Now run that executable on a pre-BOTHER kernel, which > doesn't know about c_ispeed and c_ospeed. The ioctl(TCGETS) will > succeed, but c_ispeed and c_ospeed will not have been filled. > How is the executable to detect that situation? that's why it's an ABI. on say ppc, the termios struct has always had the speed members and the kernel has always filled them in. so that takes care of the GET path. the SET path cannot make any assumptions. if BOTHER is defined, you'll have to try to use it and then do a GET and compare the speeds. if they differ, you're running on an old kernel which does not support BOTHER so you'll have to fall back to using the libc termios functions. > >> I therefore solved it the other way around, > >> by using the old speed setting via Bnnn for those speeds supported by > >> it, and resorting to the BOTHER mechanism only for speed values which > >> don't have a Bnnn value. > > > > the Bnnn list beyond 115200 is not consistent across arches :/ > > In fact, the divergence starts after 38400, the last value defined > by POSIX. (Though the difference for 57600, 115200, 230400 and 460800 > is really only because of a different CBAUDEX value.) That's the > reason for the ifdeffery around B57600, B115200 and B230400 in my v2 > submission. For higher values I didn't even bother, reckoning that > those needing them should run a BOTHER-capable kernel anyway. while true, i was referring to the existence of the Bnnn values, not the actual values. every Linux arch is guaranteed to support up to 115200. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
