I finally took time out to review the case materials (I know very little
about Python, although you could argue that I have a fair bit of
experience with DLPI), and they look pretty good with the exception
mechanism you indicate below. I guess it should be obvious to most
folks that code which uses any of this will require sys_net_rawaccess or
some similar privilege to do much. You might want to indicate that
somewhere in the man pages for the library.
(Hmm... now that I see it, libdlpi(3DLPI) has no such note in it... I
think that the man page would also be improved by a note indicating that
sys_net_rawaccess or similar privilege is likely to be required.)
-- Garrett
Max Zhen wrote:
>
>>>
>>> But this isn't true. libdlpi has an entire error space separate from
>>> errno... There are dozens of error codes unrelated to errno, and it is
>>> defined as the union of DL_* errors in <sys/dlpi.h> and DLPI_*
>>> errors in
>>> <libdlpi.h>. ?Only if the error returned from a libdlpi function is
>>> DL_SYSERR is errno set to something meaningful.
>>>
>> OK. I can see that it makes sense to add a new exception for libdlpi
>> specific error.
>> So, two exceptions can be raised from this dlpi module:
>> + OSError - for errors set in errno
>> + dlpi.error - for dlpi specific error other than DL_SYSERR
> After some off-line discussion w/ Danek, we agree that it makes sense
> to only raise one specific dlpi exception. So, only one exception will
> be raise in this module: dlpi.error
> The accompanying value is:
> (dlpi_error_number, string), when it is caused by a dlpi specific
> error, or,
> (DL_SYSERR, errno, s
> mactype(mactype) -> string
>
> Returns a string that describes the specified mactype.
> Valid mac types are defined in <sys/dlpi.h>.
> See dlpi_mactype(3DLPI)
>
> tring) when the error is coming from a system call.
> The dlpi_error_number is the error return value, other than DL_SYSERR,
> from dlpi_*.
> The string is used to describe what went wrong during the call.
>
> Max
>>
>> Max
>>> -Seb
>>>
>>>
>>>
