From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Sun, 23 Mar 2014 20:32:07 EDT." References: <40707a306f2cb1caf97b21f639f8a9f5@brasstown.quanstro.net> <590d4ca16a9d61afc0bdc6b4d16862af@brasstown.quanstro.net> <20140323213208.A38E8B827@mail.bitblocks.com> <9838602a5db28f523fec74b5e8a9c2ab@brasstown.quanstro.net> <20140323220205.1AE20B827@mail.bitblocks.com> Date: Sun, 23 Mar 2014 17:41:34 -0700 From: Bakul Shah Message-Id: <20140324004134.673DBB827@mail.bitblocks.com> Subject: Re: [9fans] usb/serial control open Topicbox-Message-UUID: cedd5a68-ead8-11e9-9d60-3106f5b1d025 On Sun, 23 Mar 2014 20:32:07 EDT erik quanstrom wrote: > > > i think it is even easier to set the state up properly with cpurc or > > > consolefs' configuration file, and have the various programs not even > > > care that they're talking to a serial port. > > > > Not my experience. Occasionally programs do have to care about > > some serial port parameters and if such a program crashes you > > have a partially working interface. Think CTS/RTS state etc. > > doesn't sound like the common case. in any event, seems like a > program fiddling with CTS/RTS should do the whole setup, especially > if it plans on crashing. :-) The issue is program A can leave things in non-working order and program B running after A has to deal with this. This is no different from bringing up a system in a known good state.