Ar Iau, 2006-08-24 am 20:51 +0200, ysgrifennodd Krzysztof Halasa: > Hmm... I'm not sure if I understand this correctly. Can't we just > create the 3 new ioctls in the kernel and teach glibc to use it? We could implement an entirely new TCSETS/TCGETS/TCSETSA/SAW which used different B* values so B9600 was 9600 etc and the data was stored in c_ospeed/c_ispeed type separate fields and we'd support arbitary speeds for input and output once and for all, shoot all the multiplier hacks etc. As it happens the kernel code for this is easy owing to some fortuitous good design long ago in the tty layer. We could also implement a Linux "improved" TCSET* new set of ioctls that had sensible speed fields, utf-8 characters for the _cc[] array and new flags for all the utf-8 handling and the like. That would be less compatible though. Or we could just add a standardised extra set of speed ioctls, but then we need to decide what occurs if I set the speed and then issue a termios call - does it override or not. > The old ioctls would be optional in the kernel (and perhaps in glibc, > sometime). The kernel side translation is thankfully really trivial. > Not sure if we want int, uint, or long long for speed values :-) You want speed_t according to POSIX. I've no idea what the glibc impact of this kind of thing would be (consider new glibc, old kernel etc). I've cc'd the libc folks but I am not sure it is practical to do. Alan - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html