Hallo Denys! >>> getty -i -h -n -I 'ATE0Q1&D2&C1S0=1\015' -l /usr/bin/startppp 115200 >>> /dev/ttyS1 >>> >>> Is there any reason that getty would not wait? I don't have the '-L' >>> so it seems it should wait for carrier detect. > It doesn't wait because we open tty with O_NONBLOCK. > I don't know why we do that. > > agetty also does this. So it seems it's not a busybox deviation.
Outch ... looks to me O_NONBLOCK is wrong in getty ... except you do an open (w/o blocking), emit some codes, close the device and reopen with blocking ... or you have to wait for the raise of carrier on modem lines in a different way. >> -I INITSTR Send INITSTR before anything else >> >> As a suggestion -- could be better to cange this to read: >> >> -I INITSTR Send terminal INITSTR before anything else >> >> or >> >> -I INITSTR Send terminal (NOT modem) INITSTR before anything else >> >> or >> >> -I INITSTR Send terminal INITSTR before anything else (NOT for modem) > > I do not understand what are you trying to say in that text. > We can't know where INITSTR goes (to modem or to whatever is connected > to that modem) - we merely send these bytes to the tty. INITSTR was never designed to be used for modem initialization tasks. It's indention always was for tty init (like switching tty emulation, tty reset etc.). So help text shell give the info not to misuse for modem init purposes as there are so many users expecting normal getty's to work the same way as mgetty (which allows to initialize the modem that way). > One related gray area is whether we should use open(O_NONBLOCK) > or not, and if not, what to do with INITSTR then: it will no longer be sent > to tty immediately, but only after open() succeeds (which on !CLOCAL > lines means "after Carrier Detect appears") - meaning that INITSTR > can no longer be used to initialize modems. INITSTR shall be send to the line after connection to tty has been established and shall be used to initialize the tty (may be connected via a modem line) to understand the expected control codes. INITSTR shall never be send before the connection to the tty has been established. As this INITSTR ist NOT for modem initialization. That was the long standing behavior of getty processes on many systems I had been working with. Modem initialization is normally done ahead before getty is activated and shall leave the modem in a state where it initializes to a working state by just activating the DTR handshake signal. After that modem shall be ready to accept incoming calls (auto answer). If you want to have functionality to initialize a modem you need a different function which opens the tty device in local mode, send the init sequence, wait for the response then close the tty and reopen in none local mode. ... or do it the mgetty way, open device and watch/control all modem lines on your own (required by modern modems to use extended functionalities). This design may be considered awesome but think of the fact, the design has been made at a time where modems where very thumb devices and multi purpose/multi function "computers" for it's own. This is why mgetty is so much different from other gettys. mgetty is designed to control/use complex multi purpose modem devices. Busybox getty is assembled close to the behavior of a standard getty so it shall clearly inform users not to misuse INITSTR for modem initialization purposes. IMHO (else BB getty needs heavy redesign!). -- Harald _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
