Daniel P. Berrange wrote:
On Fri, Jan 16, 2009 at 04:52:30PM +0100, Hans de Goede wrote:
- The API for auth credentials is hardcoded to the 4 credentials
needed for CHAP auth. Might be desirable to have a more generic
interface to pass arbitrary credentials to avoid the API being
tied to CHAP.
I'll think a bit about this, I might be able to come up with something.
Note that currently only CHAP is supported by open-iscsi AFAIK.
I've updated the API to make adding other authentication types without breaking
the ABI possible in the future:
http://people.atrpms.net/~hdegoede/html/libiscsi_8h.html
- No API for enumerating the LUNs in a target once you're logged in ?
open-iscsi / iscsiadm does not do this, it merely creates a virtual scsi
adapter and then the generic kernel scsi code does this (AFAIK).
iscsiadm has a command to at least list the LUNs from an active target
though not providing the corresponding device names. Getting this info
is one of the more tedious things, because poking around in sysfs to
find the devices matching the LUNs is very troubleprone due to changing
structure of sysfs, and changing output of iscsiadm. Having an API for
listing LUNS and their device paths would be very valuable.
I can see how something like this coukld be useful. However currently I would
like to concentrate on the functionality which is present in the API *now*, and
getting the API for that right (so that we can freeze it) as that is the
minimum which we need in anaconda, which is the main reason why I'm working on
this. I'm certainly willing to take patches (assuming upstream will accept this
lib and let me maintain it) :)
- What are the thread safety rules for the API ? Is it safe for mutliple
threads to use the API concurrently ?
No, maybe one day it will be safe for multiple threads to use it, as long
as they use a separate context per thread. But the open-iscsi code this
library uses is full of globals. The main purpose of the context purpose is
to allow this in the future, but it is not possible right now.
Hmm, this is rather a show stopper for libvirt, since we have to be
fully threadsafe - not only in terms of the public APIs, but also in
terms of the POSIX calls used internally. eg making sure libiscsiadm
does not call getmntent(), but instead uses getmntent_r() (likewise
for something like 50 other POSIX calls which aren't reentrant safe.
This is certainly something which can be done in the future, the used
open-iscsi code is not that large. Which leaves the question how threadsafe do
you want this to be? Is the need to have one context per thread acceptable or
do you want it to be safe to call functions on the same context from different
threads at potentially the same time?
Again I'm mainly trying to get the API right here, the whole context concept
was added to allow to make it threadsafe in the future without requiring API
changes.
Regards,
Hans
p.s.
You might want to subscribe to the opne-iscsi mailinglist (low trafic) as right
after this mail I'll send a mail there announcing my libiscsi initiative and
asking for feedback (and pushing for inclusion into open-iscsi itself eventually).
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
