Re: Closing a serial device takes one second

[Marc Balmer <marc%msys.ch@localhost>]

Am 06.02.14 21:05, schrieb Brian Buhrow:
>       hello.  The com(4) driver is pretty well vetted in the NetBSD
> sys/dev/ic tree.  In my opinion, the 1 second delay was put there for a
> reason when something didn't work and the Sparc driver would get it in a
> new york minute if it had been used in the same way as the MI version has
> been.  that said, I understand not wanting to wait for a second for the
> close call to return.  Therefore, I think the suggestion of forcing a
> subsequent open to wait if it happens  before a second has elapsed since
> the last close is a good one.  I don't think just removing the delay is a
> good idea.  Potential issues with this approach that I can think of are
> that the close() routines of a driver are only called when the last
> file descriptor open in the system to a given device closes that
> descriptor.  Therefore, it may be that making this change would require the
> com(4) driver to grow some sort of reference counter so that the open
> routines know whether or not the device is currently already open.  It may
> be that this infrastructure is already there and working, I haven't looked,
> but it is something to think about.

Actually the one second delay is wrong.  If you want to de-assert DTR
for a modem to hangup, then do it in the application.

Delaying all users of serial lines for one second on close is kind of
brutal and lead to user complaints in my case.

No other BSD I checked does this delay, and not even we do it consequently.

I think it will go away.