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.
-Brian
