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.
