> 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). > - 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. -- meem _______________________________________________ networking-discuss mailing list [email protected]
