Thank you Paul and Meem for your comments.
Peter Memishian wrote:
> Man pages:
>
> dlpi_open and dlpi_set_timeout:
>
> - Could we allow 0 timeout to really mean 0. I.e. could we provide a
> define of some other value to indicate "appropriate default", e.g. -2?
>
> (0 timeout will need further interfaces added to work properly, but
> initial users can just use the FOO_DPLI_DEFAULT_TIMEOUT define..)
I agree we might use "0" to mean "non-blocking" in the future, and that
we'd be more future-proof with a DLPI_DEFAULT_TIMEOUT constant with some
out-of-range value. However, since the vast majority of the callers will
want the default timeout, I'd vote to remove the timeout argument entirely
from dlpi_open(), and require use of dlpi_set_timeout() to change it (or
restore it to DLPI_DEFAULT_TIMEOUT).
Yes, it certainly makes sense to keep the timeout mechanism with the
dlpi_set_timeout().
> - libdpli is using poll behind the scenes, could we perhaps make the
> timeout be millisec (noting that libdpli is allowed to round-up to 1s
> precision if it wishes)
I'm not sure I see the benefit in that. DLPI control operations sometimes
lead to hardware initialization/reset or other slow operations; providing
a millisecond timeout encourages people to write code that may ultimately
prove unreliable across the set of network device drivers supported by
Solaris. Instead of attempting to maintain the illusion that DLPI is
synchronous in small-timeout contexts, I would rather provide alternatives
that either remove the need for a small timeout, such as providing a
non-blocking mode.
dlpi_set_timeout() can be modified to handle '0' to truly mean non-blocking.
-Sagun
_______________________________________________
networking-discuss mailing list
[email protected]
