Date: Thu, 14 Oct 2004 19:20:15 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Randy Bush <randy@psg.com> Cc: Peter Edwards <peadar.edwards@gmail.com> Subject: Re: NOTICE: /dev/cuaa%d -> /dev/cuad%d renaming Message-ID: <69103.1097774415@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 14 Oct 2004 10:16:43 PDT." <16750.46203.217249.805105@ran.psg.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <16750.46203.217249.805105@ran.psg.com>, Randy Bush writes: >> Think of DCD as indicating that a "connection is established" with the >> other side. The ttyd device is _supposed_ to block until a remote >> connection is established. If you can't provide a DCD signal, then >> just use "cuad" instead of "ttyd": >> >> The intention is that's for making outgoing calls you use cuad, so a >> getty waiting to open ttyd won't stop the open on cuad. In your case, >> it's probably ok for the getty to just hog the modem itself, so using >> /dev/cuad0 sounds like the right thing to do. > >it's the getty that is the problem. this is out of band access to >the console, i.e. getty. It is a rather hairy issue. It is true that /dev/cua* should be used when DCD should be ignored, but in addition to that we also lock CLOCAL on consoleports in order to make /dev/tty* for them act essentially the same way. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?69103.1097774415>