Autor: Maciej W. Rozycki (macro_at_ds2.pg.gda.pl)
Data: Wed 22 Oct 2003 - 18:12:22 MET DST
On Wed, 22 Oct 2003, Radoslaw Sokol wrote:
> > Gdzie sie przyjelo? Stosowanie niskiego ID (typowo 0) dla dysku twardego
> > ma uzasadnienie jedynie w przypadku wybrakowanych implementacji
>
> Choćby taką zasadę przyjęli sami producenci -- o ile dobrze
> pamiętam skanery są często dostarczane z ID 3, zaś nagrywarki
> i napędy CD-ROM z ID 6.
Moze to byc po prostu sposob na dostarczenie zworek -- zwykle urzadzenia
SCSI nie maja dedykowanych pinow do przechowywania zapasowych zworek. Co
ciekawe: odnosze wrazenie, ze zworki dostarczane w inny sposob (typowo w
dolaczonym woreczku) maja zwyczaj znikac na drodze producent ->
uzytkownik.
> > Kontrolery SCSI jak najbardziej istnieja -- nie wszystkie urzadzenia
> > laczace magistrale systemowa z magistrala SCSI to proste sterowniki
> > magistrali sterowane przez glowny procesor systemu. Istnieja rozwiazania
> > posiadajace oprocz host-adaptera SCSI, wlasny procesor, pamiec lokalna i
> > firmware, z ktorym system komunikuje sie przy uzyciu protokolu
> > programowego i te jak najbardziej odpowiadaja definicji kontrolera.
>
> Nie jestem przekonany. Kontroler to przede wszystkim urządze-
> nie nadzorujące pracę innych urządzeń lub magistrali, bez
> którego działanie tych urządzeń lub magistrali jest całkowicie
> niemożliwe. Urządzenia SCSI zaś całkiem dobrze mogą sobie
> radzić bez obecności jakiegoś specjalnego urządzenia dodatko-
> wego -- to magistrala w stylu peer-to-peer.
Nie twierdze, ze kontroler SCSI jest kontrolerem magistrali. Ale kazde
urzadzenie dokonujace sterowania innymi urzadzeniami mozna okreslic takim
mianem. Jest to szczegolnie wyraznie widoczne w urzadzeniach sterowanych
programowo -- wyposazonych we wlasny procesor, czesto wbudowana wersje
procesora ogolnego przeznaczenia (m68k, i960, etc.) i firmware. I taki
kontroler SCSI steruje host-adapterem SCSI i adapterem magistrali systemu
(dla ustalenia uwagi, zalozmy, ze jest to magistrala PCI) programujac oba
odpowiednio, w zaleznosci od odebranych polecen z jednej badz drugiej
strony (urzadzenie SCSI moze przesylac komendy do host-adaptera
pracujacego w trybie "target").
Np. polecenie odczytu (o danych parametrach: adres urzadzenia, numer
bloku i liczba blokow) dostarczone kontrolerowi przez magistrale systemowa
jest interpretowane przez firmware kontrolera i w zaleznosci od
implementacji nastepujace kroki moga byc wykonywane przez firmware (w
uproszczeniu):
1. Ustawienie adresu i licznika slow dla transmisji DMA w adapterze PCI.
2. Ustawienie adresu transmisji DMA odpowiadajacego adapterowi PCI w
adapterze SCSI.
3. Opracowanie i wyslanie komendy READ(10) do wskazanego urzadzenia przez
adapter SCSI.
4. Oczekiwanie na zgloszenie przez adapter SCSI zakonczenia transmisji
przychodzacej.
5. W przypadku powodzenia operacji, opracowanie pomyslnego rezultatu i
zgloszenie zadania obslugi (przerwania) poprzez magistrale systemowa.
6. W przypadku porazki, ustawienie adresu transmisji DMA odpowiadajacego
lokalnej pamieci kontrolera w adapterze SCSI.
7. Opracowanie i wyslanie komendy REQUEST SENSE do wskazanego urzadzenia
przez adapter SCSI.
8. Oczekiwanie na zgloszenie przez adapter SCSI zakonczenia transmisji
przychodzacej.
9. Opracowanie niepomyslnego rezultatu na podstawie otrzymanego wyniku i
zgloszenie zadania obslugi (przerwania) poprzez magistrale systemowa.
Podobnie sprawa wyglada w przypadku innych urzadzen, np. wiekszosc kart
sieciowych to proste adaptery, ale istnieja tez implementacje bedace
kontrolerami -- zawierajace wlasny procesor i firmware, zdolne do
samodzielnego generowania i wysylania oraz odbioru i interpretacji ramek z
danymi.
Chcialbym jeszcze nadmienic, ze urzadzenia typu adapter SCSI w rzeczy
samej nie sa w stanie dzialac samodzielnie -- wymagaja one odpowiedniego
zaprogramowania i w przypadku braku dedykowanego kontrolera role te zwykle
przejmuje procesor systemowy.
-- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro_at_ds2.pg.gda.pl, PGP key available +
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 11:29:14 MET DST