Bart Van Assche wrote:
On Mon, Jan 19, 2009 at 2:07 PM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
Therefore we would like to export (some) of the functionality of iscsiadm as a
C-library.
Great !
I've got documentation of the proposed API here:
http://people.atrpms.net/~hdegoede/html/libiscsi_8h.html
Not so great:
libiscsi_get_error_string()
This function can be called to get a human readable error string when
a libiscsi function has returned an error. This function uses a static
buffer thus the result is only valid as long as no other libiscsi
calls are made after the failing function call.
That should read: "This function uses a single buffer per context, thus the
result is only valid as long as no other libiscsi calls are made on the same
context after the failing function call."
Actually this reminds me this function currently isn't even implemented. I'm
planning on changing usr/log.c to make this possible. The idea is that dolog
becomes a function pointer which can be pointer to either a function
doing the current log_daemon behavior, or to one doing the current print to
stderr behavior. Then the log_daemon variable can be removed, and libiscsi can
supply its own logging function which can store the last error message.
But before making these changes I first wanted to discuss this on this list, so
are there any objections against this change?
This makes it impossible to use libiscsi_get_error_string() in a safe
way in multithreaded software.
Well, as long as you use one context per thread, it should be safe, atleast API
wise, unfortunately the used existing open-iscsi code is full of global
variables. So thread safety will come as a future enhancement. Actually the
only reason for the whole "context" paradigm in the current API is to allow a
move over to thread safety in the future without breaking ABI.
Furthermore, there are some minor spelling issues, e.g. "cleanups".
Shouldn't this be "cleans up" ?
patches welcome :)
Regards,
Hans
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
