Garry wrote: > > In reading through the setserial man page, it looks > like it can handle just about any configuration you > can dream up. It would seem that you can under-specify > the UART, but it's not safe to over-specify it.
Even in the old BBS days we had problems with users putting fast external modems on slow UARTS. It's rare to see that problem nowadays, although users of old PCs need to keep it in mind. > Being unfamiliar with the layers of Linux, could you > perhaps give me a feel for where the breaks are? > I presume that once setserial has done its job, The Linux kernel boots using default parameters for the comports. Here is what my kernel says when it boots: -------------------------------------- ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A ttyS02 at 0x03e8 (irq = 4) is a 16550A -------------------------------------- If necessary, setserial can then be used to change these parameters. This is not a permanent change. The next time the kernel boots it will be back to the default parameters. > the next thing is for a dialer/driver to load up pppd runs the show. It starts the dialer, takes back control when the dialer is finished, authenticates (if necessary) and establishes the connection with the remote host. In order to do this, it needs several bits of information: (1) which serial device (/dev/ttyS?) to use (2) what speed to use on that device (3) whether it should be locked to the serial device (4) whether to use hardware flow control (5) whether to authenticate the remote host (6) what username/password to use for authentication (7) what local address to use (8) whether to add a default route (9) the pathname of the dialer The dialer needs to know: (1) any special init strings the modem needs (2) the phone number of the ISP (3) the prompts/responses for login (if necessary) > Is this correct, or does PPP talk direct to the port hardware? pppd works through /dev/ttySx > I had the impression that it was the kernel's job to talk > to the port hardware Yes the kernel manages the link between /dev/ttySx and the port hardware. There is a serial driver in the kernel to do this. >... so that (if it's true) would mean that setserial > simply calls the API and tells it "do these things" > to the serial port, I'm not an expert on low level stuff, but I am under the impression that setsetserial simply alters the parameters that the kernel uses to address the hardware. It does not do anything itself to the serial port. When you run "setserial /dev/ttySx" without parameter, it reports the current settings used by the kernel. When you run "setserial /dev/ttySx" with parameter, it alters the current settings. > and that the application will simply assume you've already > done that part and talk the the API using that assumption. The applications work through /dev/ttySx. They don't care what is going on behind the scenes to make /dev/ttySx function. Cheers, Steven To unsubscribe from SURVPC send a message to [EMAIL PROTECTED] with unsubscribe SURVPC in the body of the message. Also, trim this footer from any quoted replies. More info can be found at; http://www.softcon.com/archives/SURVPC.html
