On 11/05/2014 05:01 PM, Shreyas Bethur wrote: >> From: Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> >> On 10/31/2014 04:33 PM, Shreyas Bethur wrote: >>> When tty port is opened, we will raise the DTR and RTS lines. But for >>> second and subsequent opens, we should not modify these lines because the >>> first session might be actively using these lines. We don't want a second >>> open to interfere with the first session. >>> >>> Signed-off-by: Shreyas Bethur <shreyas.bethur@xxxxxx> >>> --- >>> To give some background for this patch, we have a product that uses the >>> DTR line on the serial port for synchronization with other devices. While >>> the synchronization application is using the DTR line, if another process >>> opens the same port, then DTR line is raised, and thus interferes with the >>> synchronization application. So, if a port is open, subsequent opens >>> should not modify any modem lines. >> >> Would you please expand on your use-case? > > We have many devices in a real-time test & measurement system, and the > clocks on all these devices needs to be synchronized for our applications. > So we connect all the devices to a central hub via serial ports. We open > a tty session (in exclusive mode and non-admin user) and toggle the DTR > lines from all the devices, every time cycle. The hub measures the time > difference between these signals and correct the clock on the devices. > We also have a service that the user can use to enumerate all the serial > ports and check whether they are in use. When this service opens the port > that is used for synchronization, it gets EBUSY error, which is good; But > the tty driver raises the DTR line before returning EBUSY. > > I would expect that if a tty session is opened in exclusive mode, any > subsequent opens to not change anything on the port including DTR and RTS > lines. Please let me know if I'm missing something or if my understanding > is incorrect. Your understanding is exactly right, and I think your application's use and expectation of TTY_EXCLUSIVE is correct as well. But I think the appropriate fix for this is elsewhere; I need to do some testing but I think I can get you a test patch in the next couple of days. What kernel version are you using to test (so I can make sure the test patch applies)? Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
