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 implementedI'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?
I therefore solved it the other way around, by using the old speed setting via Bnnn for those speeds supported byit, 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. -- Tilman Schmidt E-Mail: tilman@xxxxxxx Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
Attachment:
signature.asc
Description: OpenPGP digital signature
