On Wed, Jun 15, 2016 at 10:45:28PM +0200, Marcus Glocker wrote: > On Wed, Jun 15, 2016 at 08:26:01PM +0200, Marcus Glocker wrote: > > > On Wed, Jun 15, 2016 at 10:11:19AM -0700, Philip Guenther wrote: > > > > > On Wed, Jun 15, 2016 at 7:22 AM, Martin Pieuchot <[email protected]> wrote: > > > > On 11/06/16(Sat) 16:44, Marcus Glocker wrote: > > > >> Currently one can open multiple instances of /dev/ttyU* since ucom(4) > > > >> just checks 'TS_ISOPEN' against /dev/cuaU* access. There are quiet a > > > >> lot of flags in ucom.c so it's a bit difficult to understand what the > > > >> initial idea was. But moving the 'TS_ISOPEN' check before the UCOMCUA > > > >> branch makes /dev/ttyU* access also return EBUSY if already opened. > > > >> > > > >> Ok? Or better ideas to fix this? > > > > > > > > No idea how this is supposed to work but com(4) contains the exact same > > > > code, so if this is a bug it should probably fixed there too. > > > > > > If I'm logged in on /dev/ttyU0, shouldn't I be able to open my tty, > > > such as with "stty < /dev/ttyU0". Wouldn't this change break that? > > > > Right, that wouldn't work anymore. > > > > > What's the problem with multiple opens of the incoming call device? > > > > The "problem" I faced is that by mistake I did open two cu(1) sessions > > to /dev/ttyU0. If you try this you will notice that afterwards both > > cu(1) sessions are broken. The output and input gets garbled. First I > > thought something is broken with my cable until I've noticed that I've > > opened two cu(1) sessions by mistake. > > > > Therefore I thought similar as when one is opening an usb audio or > > video device, the device node should be busy for others since this would > > also lead to interferences. > > > > The inconsitent part here is that /dev/cuaU* _will_ spit EBUSY when > > already opened. Is this how it should be? > > I have checked behaviour of ttyU on NetBSD and FreeBSD; Both return > EBUSY when the device is already open. But stty(1) still works for both > also when ttyU is open. I try to find how they managed that, for a > bit.
The issue lies within our cu(1) rewrite. While the original cu(1) code checks for ports beeing busy with a function called hunt() we don't do it anymore. I'm not feeling like adding this back again, so lets be careful in future with multiple cu(1) sessions :-)
