On Thursday 07 February 2008, Mike Frysinger wrote: > On Thursday 07 February 2008, Tilman Schmidt wrote: > > Am 06.02.2008 23:23 schrieb Mike Frysinger: > > >>> hmm, this doesnt seem right ... this does not allow for arbitrary > > >>> baud rates which newer versions of linux now supports. > > > > [...] > > > > > ive documented the current way of doing it here: > > > http://docs.blackfin.uclinux.org/doku.php?id=faq > > > (see the question at the bottom about custom/high speeds) > > > > Great! Thanks. > > > > > since this is relatively new, you may have to wrap the code in > > > something like: #ifdef BOTHER > > > < new way > > > > #else > > > < old cfsetspeed way > > > > #endif > > > > Ok. Now, being curious I poked around in the current kernel for > > that termios2 structure, and I couldn't help noticing that some > > architectures (including the very first one, alpha) do not have > > it, but instead integrate the c_ispeed and c_ospeed fields in > > struct termios. Do I have to handle that case? Would something > > like > > > > #ifndef TCGETS2 > > #define termios2 termios > > #define TCGETS2 TCGETS > > #define TCSETS2 TCSETS > > #endif > > 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 actually, it'd probably be best if this were a lib func in like lib/tty_speed.c or something ... -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
