tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Closing a serial device takes one second



On Fri, Feb 07, 2014 at 09:23:18AM +0100, Marc Balmer wrote:
> Am 06.02.14 17:18, schrieb Marc Balmer:
> > Closing a serial port (e.g. /dev/dtyXX) takes almost exactly one second.
> >  Why is that so?  Why does the call not return immediately?
> > 
> > int fd;
> > 
> > fd = open("/dev/dty03", O_RDWR);  /* returns immediately */
> > close(fd); /* returns after one second */
> > 
> 
> So it is clear now that the delay is there for a specific application
> case:  A modem on a tty line that hangs up when DTR is gone for one
> second.  For probably all other use cases the delay is not necessary.
> 
> Removing the delay in the driver probably means that init will reopen
> the tty more or less immediately after it closes the line.  And _if_
> there is such a modem on that line, it will probably not hang up.
> 
> So the question is whether we want to add a 1 sec. delay to init?
> 
> The other proposed "solution", namely to add a delay to open in case the
> device is reopened, does not help either in the use cases where we run
> into trouble:
> 
> When talking to serial printers, we open a tty, send the data to the
> printer and then close the tty again.  This is done several times in a
> sequence, each time causing a one second delay.
> 
> Now adding softcar to the respective line /etc/ttys can fix the issue,
> if the hardware does not rely on it (which we are currently testing).
> 
> In conclusion, the delay probably comes from times long gone when people
> used dial-in modems.  For "modern" serial applications they are more a
> nuisance.  Is it time to switch the default to no delay?

If I understood it properly there is a standard and documented way to
avoid the delay, which is to clear the HUPCL flag.
Blindly removing the delay is probably not the right thing to do as there
would be no way to have it for applications that need it.

I see no reason to change the driver to suit *your* application, especially
as there is already a way to make it behaves as you need.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--


Home | Main Index | Thread Index | Old Index