Re: iSCSI initiator

On Fri, Jun 20, 2003 at 01:13:47PM +1000, Peter Ross wrote:
> Hi Bernd,
>
> On Fri, 20 Jun 2003, Bernd Walter wrote:
>
> > Es gibt einen Kernel Developer Guide, den du in den benötigten
> > Abschnitten lesen solltest.
> > Gerade CAM ist gut Dokumentiert.
>
> Das stimmt. Danach ist mir so ein SIM fuer einen Adapter schon klar.
>
> (Rein theoretisch, das Implementieren ist ja trotzdem noch Arbeit und wird
> sicher auch noch mal ein paar Fragezeichen erzeugen, ich denke zum
> Beispiel Bemerkungen zu alpha-Byteorder etc)

alpha-byteorder ist identisch mit Intel.
sparc64 und ppc haben eine andere.
Behandeln mußt du das sowieso, da

> Nun ist dieser iSCSI-SIM allerdings ein Zwitter.. einmal SCSI-SIM und dann
> TCP (statt irgendwo dem SCSI-Adapter Bytes zuzuschieben).

So ein SIM hat Prinzipiel immer zwei Seiten.
Eine zum CAM und eine anderartige zu den Geräten gerichtet.
Schau dir mal den umass Treiber an, der implementiert einen SIM und
schickt die Befehle nach Umwandlung in logische USB Kanäle.
Genausogut muß jeder Treiber der einen echten Host Controller ansteuert
das ganze mehr oder weniger Wandeln, da alle modernen SCSI Adapter
Microcontroller benutzen - zum großen Teil bekommen die sogar ihr
Programm vom FreeBSD Treiber.

> Wie man einen TCP-Daemon schreibt, weiss ich so ziemlich..

Im Kernel ist das auch kein Vodoo.
Wenn du bereits mit einer select loop gearbeitet hast, dann wird dir
das sehr bekannt vor kommen.

> > Es hat Vorteile das komplett im Kernel zu machen, damit kannst du z.B.
> > auch die / Platte auf einem iSCSI Laufwerk haben.
> > Außerdem hast du bei einem Userland Programm einiges mehr zu beachten,
> > um low Memory Deadloks zu verhindern.
> > Die Konfiguration kannst du am besten mittels eines /dev/iscsi.ctl
> > und ein paar selbst definierten ioctl machen.
>
> Du schlaegst vor, den TCP-Kram auch in den Kernel zu legen.. Kommt mir
> irgendwie "unsauber" vor.

NFS macht das auch.
Unsauber wäre es, wenn der Kernel Massenspeicher erst über ein Userland
Programm ereichen könnte.

> Wenn die Verbindung erst einmal steht, ist es relativ simpel - es gibt
> TCP-Verbindungen, ueber den die SCSI-Messages raus- und reingehen.

Das ist wohl auch weniger dein Problem.
Die Arbeit wird das Handling von Disconnects und Authentifizierung,
sowie Konfiguration sein.
Ebenso ist das Fehlerhändling arbeit, da die Gegenstelle ja einen
Softwarebug haben kann.
Je nach dem, ob das Packethandling in TCP abgewickelt wird, oder du das
selber machen muß wirst du mit Syncronsierung oder Packetverlusten zu
tun haben.
Der normale Datenpfad im Kernel ist 0-8-15 - zumindest für jemanden,
der sowas schon mal gemacht hat.
Von daher ist das sicherlich ein guter Einstieg.

> Klar, auch das ist nicht ganz ohne: Wenn z.B. die Verbindung abgebrochen
> ist, muss evt. eine anderere initialisiert werden (wenn z.B. das Target an
> mehreren Interfaces ueber unterschiedliche Netze erreichbar ist), Resets
> etc.

Eben.

> Aber erst einmal die Initialisierung: Lookup, welche Targets da sind,
> Verbindungsaufbau, Authorisierung (in den Bereichen ist iSCSI auch noch
> von der Standardisierung her Work In Progress..)
>
> Das alles im Kernel?

Sicher - Userland ist absolut nicht einfacher.
Du kannst dir für einige Authorisierungsverfahren ja immer noch
Userland Hilfe dazuholen.

> Ich sehe leichte Analogien zu NFS, wenn es auch andere "Lagen" sind, aber
> auch hier erzeugt ein eigentlich "lokales" Kommando Netzpakete.

Nein - Packete können auch vom Kernel erzeugt werden.
Man denke z.B. an den Pager oder an restransmits.

> Hier wird meines Wissens nfssvc verwendet, um den Server in den Kernel
> einzubinden, wobei mir das "Kleingedruckte", die Teils der
> Implementierung, nicht klar ist.

Das ist Vergangenheit.
Man hat das gemacht, um einen Thread im Kernel zu haben.
Das Programm hat eine Kernelfunction aufgerufen und ist nie mehr
zurückgekehrt.
Inzwischen ist das ein kernelinterner Thread.
Auf der Clientseite war das eh Optional.
Die Tatsache, daß das ein Thread sein mußte hängt mit NFS
Besonderheiten zusammen.
 
> Z.B. spielt hier auch Authorisierung eine Rolle, die Zusammenarbeit mit
> Kerberos ist erwaehnt..

Authorisierung hat ja nichts mit dem Datenpfad zu tun.
Beim NFS Server passiert das z.B. über den mountd, der auch mit den
Nutzdaten überhaupt nichts zu tun hat sondern nur Tickets verteilt.
IIRC kann man auch NFS über Kerberos authentifizieren, aber ich habe
keine Ahnung, ob FreeBSD das Implementiert hat.

> Lohnt es sich, das genauer anzuschauen, nfsiod ebenfalls und
> sinngemaess auf iSCSI zu uebertragen?

Zum lehrnen von Kernel Socketprogrammierung ist das ein gutes Beispiel.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message