On Wed, 2008-08-06 at 18:33 +0200, Tosoni wrote: > > > -----Original Message----- > > From: Christopher Gibson > > --- 8< --- > > S. (Maybe an ill > > conceived UART is just an ART;) Also if this is to also be useful for > > radio communications then it may be necessary to provide a mechanism > > where lead in and lead out times can be specified for the control. > > > > As far as IOCTL names go I dislike the CRTSTOGGLE, toggling > > the RTS line > > is an incorrect description of function. > > It is incorrect only if you introduce the timings. Please note that Windows > has RTS_TOGGLE, no extra timings, and nobody seems to complain. > Wait wait... I am not saying that you are wrong. Last year I had to write a > (non unix) driver to handle these kinks of timings. But the case is not > usual. > Sorry was being pedantic about naming. When I said that CRTSTOGGLE was an incorrect description of function, I was meaning toggle normally means (in both electronic and mechanical systems) that something switches between two stable states on application of a signal or force. (Like the mechanism on the top of a pen to make the nib poke out or retract.) For this reason it seems wrong to me call the RTS direction control a toggle function. > > I prefer CARTS as it is not an > > incorrect description of function. CARTS - auto request to send is > > rather ambiguous though. If I was to suggest a name it would > > be RTSADC > > - request to send auto direction control (maybe with a > > preceding C if it > > went into termios cflags). --- 8< --- On reflection I think I was getting carried away when I suggested adding timings to the "lead in" and "lead out". Will discuss this in greater detail in reply to another email on this thread. -- Christopher Gibson <chris@xxxxxxxxxxxxxxxx> -- 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
