Konrad Rzeszutek wrote:
On Mon, Jan 19, 2009 at 02:07:23PM +0100, Hans de Goede wrote:
Hi All,
Short intro: I'm a long time Linux an and developer. Since Sept 1st I work for
RedHat on the installer team (anaconda the installer for Fedora and RHEL).
We currently make all kind of calls to iscsiadm in the installer and then parse
the output for our iscsi functionality. This is a bit of a kludge and somewhat
error prone.
Therefore we would like to export (some) of the functionality of iscsiadm as a
C-library. I've discussed this a bit with Mike Christie and we arived add doing
a library which hides all open-iscsi's internals (no existing headers used in
the libraries public headers) so that changes to open-iscsi can still be done
easily without breaking the library's API.
I've got documentation of the proposed API here:
http://people.atrpms.net/~hdegoede/html/libiscsi_8h.html
And the attached patch implements this, as you see only very minimal changes to
the existing code are needed, the library code is all in its own dir, and wraps
various files under the usr dir.
The API currently offers pretty minimal functionality (just what we need in
anaconda) I'm fine with extending this (patches welcome). But currently I would
like to focus on the set of functionality as the current API offers and try to
get that right. Most important here is to have a clean, clear and usable API
which is also future proof, as I want to freeze the ABI of the available
I would recommend that you provide as the first variable in all of the structs
an unsigned int called 'version'. This way if the structs are extended they
would be backwards compatible and there is an easy way to identify which
version of structs they are.
Erm, given the amount of programs which will probably end up using this (not
all that much) a distro should be able to easily rebuild all those in case of
an ABI change and thus a soname bump. I understand what you are trying to say
here, but IMHO the added complexity and ugliness is not worth it.
Regards,
Hans
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
