Re: /dev/cuad0: Device busy
On Mon, Feb 04, 2008 at 02:08:32PM +0700, Eugene Grosbein wrote: Personally, I never understood the concept of dial-in and call-out devices on FreeBSD. I ran BBS software for years on both Apple II hardware and PC hardware; there was no distinction between such devices. A serial port is a serial port. Chances are I'm not understanding why there's a distinction, but there doesn't appear to be any explanation of why there's a distinction within manpages or the handbook... The distinction exists to allow an application to wait on the dial-in port for incoming calls and another application to make outgoing call mean time using the same port as call-out while the port is idle. This is intruiging to me, because now I'm left wondering how that actually works behind the scenes! :-) What happens when program X has /dev/ttyd0 open (for incoming calls), receives a call, and then during which program Y attempts to open /dev/cuad0? Does program Y indefinitely block/wait somewhere within the kernel until program X releases the fd? If so, then I'm left wondering why Ganbold's cu -l cuad0 attempt returned an immediate EBUSY, rather than blocking indefinitely. Also, the above mechanism must be fairly old, because I imagine it would be more effective to utilise kqueue/kevent to inform said programs of when the serial port is available for use. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
On Mon, Feb 04, 2008 at 02:08:32PM +0700, Eugene Grosbein wrote: Personally, I never understood the concept of dial-in and call-out devices on FreeBSD. I ran BBS software for years on both Apple II hardware and PC hardware; there was no distinction between such devices. A serial port is a serial port. Chances are I'm not understanding why there's a distinction, but there doesn't appear to be any explanation of why there's a distinction within manpages or the handbook... The distinction exists to allow an application to wait on the dial-in port for incoming calls and another application to make outgoing call mean time using the same port as call-out while the port is idle. This is intruiging to me, because now I'm left wondering how that actually works behind the scenes! :-) What happens when program X has /dev/ttyd0 open (for incoming calls), receives a call, and then during which program Y attempts to open /dev/cuad0? Does program Y indefinitely block/wait somewhere within the kernel until program X releases the fd? open blocks until CD is asserted when /dev/cuad0 is not open. If so, then I'm left wondering why Ganbold's cu -l cuad0 attempt returned an immediate EBUSY, rather than blocking indefinitely. EBUSY indicates that the open on /dev/ttyd0 completed. Also, the above mechanism must be fairly old, because I imagine it would be more effective to utilise kqueue/kevent to inform said programs of when the serial port is available for use. Only about 20 years old. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
On Mon, Feb 04, 2008 at 05:10:20AM -0800, Jeremy Chadwick wrote: Also, the above mechanism must be fairly old, because I imagine it would be more effective to utilise kqueue/kevent to inform said programs of when the serial port is available for use. The kqueue/kevent had appeared only in 4.x version of FreeBSD and serial ports were used long time before. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
Personally, I never understood the concept of dial-in and call-out devices on FreeBSD. I ran BBS software for years on both Apple II hardware and PC hardware; there was no distinction between such devices. A serial port is a serial port. Chances are I'm not understanding why there's a distinction, but there doesn't appear to be any explanation of why there's a distinction within manpages or the handbook... The distinction exists to allow an application to wait on the dial-in port for incoming calls and another application to make outgoing call mean time using the same port as call-out while the port is idle. And once there is a incoming call block out going calls until the incoming call completes. And for now one must forget existance of such devices and use /dev/ttyd* for both incoming and outgoing calls. Long history is the following: terminal devices under UNIX have changed its semantics quite a long time ago. Historically, there are a pair of devices, one was for dial-in, and another -- for dial-out. This absurd was created because of absence of non-blocking open()'s -- O_NONBLOCK simply doesn't work for open()'s of devices. As such, historical getty implementation opens port in blocking mode and blocks until carrier is detected on terminal line. Kernel doesn't allow multiple simultaneous opens of /dev/tty* in blocking mode to prevent multiple applications from accessing serial port simultaneously -- as such, if we want to make outgoing call, we ought to have 'some another' device physically attached to the same serial port, so, /dev/cua* exist. For now, there are virtually no software that relates on this behaviour -- POSIX tty locking semantics mandate us to check lock files in well-known system-wide directory -- /var/spool/lock in FreeBSD. Kernel allows opens of /dev/tty* in non-blocking mode many times, as such, no special 'dial-out' device needs to make outgoing call. It is clear that _all_ applications communicating with serial port use one semantics -- historical UNIX or POSIX. One can not use system /usr/libexec/getty with POSIX-compatible software because it opens /dev/tty* in blocking mode. Use comms/mgetty+sendfax mgetty instead -- to be precise, mgetty also can be used with UNIX tty semantics (see description of configuration keyword blocking), but just don't do it. ;) -- Andrew Kolchoogin. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
Personally, I never understood the concept of dial-in and call-out devices on FreeBSD. I ran BBS software for years on both Apple II hardware and PC hardware; there was no distinction between such devices. A serial port is a serial port. Chances are I'm not understanding why there's a distinction, but there doesn't appear to be any explanation of why there's a distinction within manpages or the handbook... The distinction exists to allow an application to wait on the dial-in port for incoming calls and another application to make outgoing call mean time using the same port as call-out while the port is idle. And once there is a incoming call block out going calls until the incoming call completes. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
On Mon, 4 Feb 2008, Ganbold wrote: I'm trying to use serial port but the system says device busy. daemon# cu -l /dev/cuad0 -s 9600 /dev/cuad0: Device busy link down What does fstat /dev/cuad0 say? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
/dev/cuad0: Device busy
Hi, I'm trying to use serial port but the system says device busy. daemon# cu -l /dev/cuad0 -s 9600 /dev/cuad0: Device busy link down daemon# uname -an FreeBSD daemon.micom.mng.net 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #0: Mon Jan 14 16:49:57 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GDAEMON i386 It seems like no other program is using serial port. How to check whether something is using serial port? Any idea? thanks, Ganbold -- If you think the problem is bad now, just wait until we've solved it. -- Arthur Kasspe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
Daniel O'Connor wrote: On Mon, 4 Feb 2008, Ganbold wrote: I'm trying to use serial port but the system says device busy. daemon# cu -l /dev/cuad0 -s 9600 /dev/cuad0: Device busy link down What does fstat /dev/cuad0 say? It says: daemon# fstat /dev/cuad0 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME daemon# Ganbold -- We'll have solar energy when the power companies develop a sunbeam meter. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
On Mon, Feb 04, 2008 at 12:53:58PM +0800, Ganbold wrote: Hi, I'm trying to use serial port but the system says device busy. daemon# cu -l /dev/cuad0 -s 9600 /dev/cuad0: Device busy link down Does the same happen if you do `cu -l ttyd0 -s 9600`? How to check whether something is using serial port? Any idea? fstat should help here. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
Jeremy Chadwick wrote: On Mon, Feb 04, 2008 at 12:53:58PM +0800, Ganbold wrote: Hi, I'm trying to use serial port but the system says device busy. daemon# cu -l /dev/cuad0 -s 9600 /dev/cuad0: Device busy link down Does the same happen if you do `cu -l ttyd0 -s 9600`? It works and fstat shows: daemon# fstat /dev/cuad0 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME daemon# fstat /dev/ttyd0 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME root cu 55743 /dev 41 crw--- ttyd0 rw /dev/ttyd0 root cu 55733 /dev 41 crw--- ttyd0 rw /dev/ttyd0 daemon# Is it expected behaviour? thanks, Ganbold How to check whether something is using serial port? Any idea? fstat should help here. -- Success is in the minds of Fools. -- William Wrenshaw, 1578 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
On Mon, Feb 04, 2008 at 02:37:31PM +0800, Ganbold wrote: Jeremy Chadwick wrote: On Mon, Feb 04, 2008 at 12:53:58PM +0800, Ganbold wrote: Hi, I'm trying to use serial port but the system says device busy. daemon# cu -l /dev/cuad0 -s 9600 /dev/cuad0: Device busy link down Does the same happen if you do `cu -l ttyd0 -s 9600`? It works and fstat shows: daemon# fstat /dev/cuad0 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME daemon# fstat /dev/ttyd0 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME root cu 55743 /dev 41 crw--- ttyd0 rw /dev/ttyd0 root cu 55733 /dev 41 crw--- ttyd0 rw /dev/ttyd0 daemon# Is it expected behaviour? As far as I know, yes. On all of our machines which utilise getty(8) on ttyd0 (as listed in /etc/ttys): $ grep ttyd0 /etc/ttys ttyd0 /usr/libexec/getty std.115200 xterm on secure $ fstat /dev/ttyd0 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME root getty 373760 /dev 36 crw--- ttyd0 rw /dev/ttyd0 root getty 373761 /dev 36 crw--- ttyd0 rw /dev/ttyd0 root getty 373762 /dev 36 crw--- ttyd0 rw /dev/ttyd0 Additionally, see Section 23.2.5 of the below document: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serial.html Personally, I never understood the concept of dial-in and call-out devices on FreeBSD. I ran BBS software for years on both Apple II hardware and PC hardware; there was no distinction between such devices. A serial port is a serial port. Chances are I'm not understanding why there's a distinction, but there doesn't appear to be any explanation of why there's a distinction within manpages or the handbook... -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
Personally, I never understood the concept of dial-in and call-out devices on FreeBSD. I ran BBS software for years on both Apple II hardware and PC hardware; there was no distinction between such devices. A serial port is a serial port. Chances are I'm not understanding why there's a distinction, but there doesn't appear to be any explanation of why there's a distinction within manpages or the handbook... The distinction exists to allow an application to wait on the dial-in port for incoming calls and another application to make outgoing call mean time using the same port as call-out while the port is idle. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
