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?
