[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
> The SCSI Driver does not prevent you from using any other access method,
> it just provides more (low level) functionality and direct device
> access.
But the problem is that you might have a regular file on the host attached =
to e.g. the emulators SCSI interface. It does not make sense (if at all pos=
sible) to use the hosts sg-interface to access that file, if the atari side=
decides to send SCSI command to access it. Instead the natfeat would have =
to look at every command and try to translate it to something meaningful. I=
n that case it might make more sense to tell the SCSI driver that this "dev=
ice" should not be accessed by SCSI, so the driver (or EmuTOS or whoever) c=
an fallback to use the XHDI method. It might make sense though to access re=
al devices like cdroms or anything else.
> I would appreciate if my code could be added as an experimental feature
> after the release of Hatari 1.9.0. The changes are minimal, basically
> it's just a new C source file with its header file.
If your patch gets accepted, you might also consider to implement it in Ara=
nym, too. If you need any help with this, let me know.
=20
Uwe Seimet <Uwe.Seimet@xxxxxxxxx> schrieb am 18:31 Dienstag, 18.August=
2015:
=20
Hi,
Well, I simply like to point out that it usually makes more sense to
implement a SCSI Driver than XHDI. If there was a SCSI Driver for the
Firebee, for instance, users would not complain about the lack of decent
software for partitioning, formatting etc. Alan Hourihane did the right
thing for his Unicorn: Because he implemented a SCSI Driver users can
simply use existing software for maintaining their devices.
The SCSI Driver does not prevent you from using any other access method,
it just provides more (low level) functionality and direct device
access. One should not use this driver for devices that are at the same
used by another access method provided by the emulation. Otherwise you
may end up with accessing the same device with more than one driver,
which is usually dangerous.
Take care
Uwe
> > XHDI is much more limited than the SCSI Driver
> Well, i didn't want to explain to the HDDRIVER guru what XHDI is ;)I just=
wanted to point out that there already is an existing XHDI Natfeats implem=
entation in Aranym.
> Of course direct SCSI is more powerful. But you also have to take into ac=
count the special requirements for an emulator. Eg. the devices that are ma=
naged by ACSI, SCSI and IDE are most likely not real devices, but just plai=
n files on the host.There are also configurations (like mine ;) where you d=
on't have an disk driver at all, because all access=C2=A0 to block devices =
is done through the HOSTFS Natfeat. Will the SCSI Interface be still access=
ible in this case?
>=C2=A0=20
>=20
>=20
>=C2=A0 =C2=A0 =C2=A0 Uwe Seimet <Uwe.Seimet@xxxxxxxxx> schrieb am 7:19 Die=
nstag, 18.August 2015:
>=C2=A0 =C2=A0=20
>=20
>=C2=A0 Hi,
>=20
> XHDI is much more limited than the SCSI Driver, which is the more modern
> approach. XHDI can only be used for accessing block devices, and even
> then it is limited to 32 bit sector numbers. With the SCSI Driver you can
> send SCSI commands to any device, not just SCSI. It's basically the
> equivalent of the sg interface.
> XHDI is typically implemented on top of a SCSI Driver, like it is done
> by HDDRIVER and (most likely) also by CBHD. And these drivers also run
> on top of existing SCSI Drivers, in which case they automatically
> provide XHDI for block devices managed by the SCSI Driver.
> The most recent implementation of a SCSI driver is the one Alan Hourihane
> provides for his Unicorn USB adapter. Another implementation is the one f=
or
> Milan PCI SCSI. And of course those for MagiCMac and MagiCPC.
>=20
> See http://hddriver.seimet.de/en/downloads.html for links to all these
> specifications.
>=20
> Take care
>=20
> Uwe
>=20
> >=20
> > >I'm currently experimenting with a (Linux-only) SCSI Driver implementa=
tion
> > >that gives seamless, direct access to devices. It maps SCSI Driver cal=
ls
> > >to the Linux sg interface. 8 or 9 calls have to be mapped.
> > There is already an existing XHDI driver interface that basically provi=
des the same functionality as the native atari interface. It is in use by E=
muTOS, and also by recent linux-68k kernels. Sounds like this is very simil=
ar to what you are experimenting with.
> > In Aranym there is also some low-level SCSI support through the IDE int=
erface. This is not based on Natfeats, but on direct hardware emulation. I =
cannot tell though how good it is working, and some low-level commands migh=
t not be implemented.
> >=C2=A0=20
> >=20
> >=20
> >=C2=A0 =C2=A0 =C2=A0 Uwe Seimet <Uwe.Seimet@xxxxxxxxx> schrieb am 22:56 =
Montag, 17.August 2015:
> >=C2=A0 =C2=A0=20
> >=20
> >=C2=A0 Hi,
> >=20
> > > > Looks to me as if the existing features are mainly related to the d=
ebugger.
> > > Thats maybe because Hatari does not need anything else yet. There are=
quite some more features implemented in eg. Aranym.
> > > > is there a preferred way of doing that, some kind of extension poin=
t, some guideline?
> > > I dont't think that there is a general guideline. There are is bit of=
documentation on Native Features Intro [ARAnyM Wiki] that covers the basic=
features.=C2=A0Most features use sub-id 0 to identify their interface vers=
ion, and i would recommend to do this for any new feature. Anything else la=
rgely depends on what your feature implements.
> >=20
> > I'm currently experimenting with a (Linux-only) SCSI Driver implementat=
ion
> > that gives seamless, direct access to devices. It maps SCSI Driver call=
s
> > to the Linux sg interface. 8 or 9 calls have to be mapped.
> >=20
> > The basics are working already, see attached screenshot. I have not
> > dared yet to write something to a drive, though ;-).
> >=20
> > Take care
> >=20
> > Uwe
> >=20
> >=20
> >=C2=A0=20
>=20
>=20
>=20
>=20
>=C2=A0=20
------=_Part_251315_2018327544.1439986513360
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><body><div style=3D"color:#000; background-color:#fff; font-family:He=
lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;fo=
nt-size:13px"><div dir=3D"ltr" id=3D"yui_3_16_0_1_1439967925530_19558">>=
Well, I simply like to point out that it usually makes more sense to<br cl=
ass=3D"" clear=3D"none">> implement a SCSI Driver than XHDI.</div><div i=
d=3D"yui_3_16_0_1_1439967925530_19565" dir=3D"ltr"><br></div><div id=3D"yui=
_3_16_0_1_1439967925530_25751" dir=3D"ltr">From the users point of view, i =
think the XHDI interface is much easier to use than a low-level SCSI interf=
ace. And it is already in use by at least EmuTOS and linux-68k, i don't thi=
nk that they would switch over to SCSI.</div><div id=3D"yui_3_16_0_1_143996=
7925530_25759" dir=3D"ltr"><br></div><div id=3D"yui_3_16_0_1_1439967925530_=
32255" dir=3D"ltr">> If there was a SCSI Driver for the Firebee, for ins=
tance,</div><div id=3D"yui_3_16_0_1_1439967925530_32256" dir=3D"ltr"><br></=
div><div id=3D"yui_3_16_0_1_1439967925530_34721" dir=3D"ltr">But we are tal=
king about emulators here, not about real hardware. There is no emulator fo=
r the FireBee. FireBee users will probaly use HDDRIVER, were SCSI support i=
s already available.<br></div><div id=3D"yui_3_16_0_1_1439967925530_34722" =
dir=3D"ltr"><br></div><div id=3D"yui_3_16_0_1_1439967925530_34723" dir=3D"l=
tr">> The SCSI Driver does not prevent you from using any other access m=
ethod,<br class=3D"" clear=3D"none">> it just provides more (low level) =
functionality and direct device<br class=3D"" clear=3D"none">> access.</=
div><div id=3D"yui_3_16_0_1_1439967925530_36270" dir=3D"ltr"><br></div><div=
id=3D"yui_3_16_0_1_1439967925530_67624" dir=3D"ltr">But the problem is tha=
t you might have a regular file on the host attached to e.g. the emulators =
SCSI interface. It does not make sense (if at all possible) to use the host=
s sg-interface to access that file, if the atari side decides to send SCSI =
command to access it. Instead the natfeat would have to look at every comma=
nd and try to translate it to something meaningful. In that case it might m=
ake more sense to tell the SCSI driver that this "device" should not be acc=
essed by SCSI, so the driver (or EmuTOS or whoever) can fallback to use the=
XHDI method. It might make sense though to access real devices like cdroms=
or anything else.<br></div><div id=3D"yui_3_16_0_1_1439967925530_25752" di=
r=3D"ltr"><br></div><div id=3D"yui_3_16_0_1_1439967925530_25753" dir=3D"ltr=
">> I would appreciate if my code could be added as an experimental feat=
ure<br class=3D"" clear=3D"none">> after the release of Hatari 1.9.0. Th=
e changes are minimal, basically<br class=3D"" clear=3D"none">> it's jus=
t a new C source file with its header file.</div><div id=3D"yui_3_16_0_1_14=
39967925530_67629" dir=3D"ltr"><br></div><div id=3D"yui_3_16_0_1_1439967925=
530_69210" dir=3D"ltr">If your patch gets accepted, you might also consider=
to implement it in Aranym, too. If you need any help with this, let me kno=
w.<br></div> <br><div class=3D"qtdSeparateBR"><br><br></div><div style=3D"=
display: block;" class=3D"yahoo_quoted"> <div style=3D"font-family: Helveti=
caNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-s=
ize: 13px;"> <div style=3D"font-family: HelveticaNeue, Helvetica Neue, Helv=
etica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir=3D"ltr=
"> <font face=3D"Arial" size=3D"2"> Uwe Seimet <Uwe.Seimet@xxxxxxxxx>=
schrieb am 18:31 Dienstag, 18.August 2015:<br> </font> </div> <br><br> <d=
iv class=3D"y_msg_container">Hi,<br clear=3D"none"><br clear=3D"none">Well,=
I simply like to point out that it usually makes more sense to<br clear=3D=
"none">implement a SCSI Driver than XHDI. If there was a SCSI Driver for th=
e<br clear=3D"none">Firebee, for instance, users would not complain about t=
he lack of decent<br clear=3D"none">software for partitioning, formatting e=
tc. Alan Hourihane did the right<br clear=3D"none">thing for his Unicorn: B=
ecause he implemented a SCSI Driver users can<br clear=3D"none">simply use =
existing software for maintaining their devices.<br clear=3D"none"><br clea=
r=3D"none">The SCSI Driver does not prevent you from using any other access=
method,<br clear=3D"none">it just provides more (low level) functionality =
and direct device<br clear=3D"none">access. One should not use this driver =
for devices that are at the same<br clear=3D"none">used by another access m=
ethod provided by the emulation. Otherwise you<br clear=3D"none">may end up=
with accessing the same device with more than one driver,<br clear=3D"none=
">which is usually dangerous.<br clear=3D"none"><br clear=3D"none">Take car=
e<br clear=3D"none"><br clear=3D"none">Uwe<div class=3D"yqt9989652148" id=
=3D"yqtfd32457"><br clear=3D"none"><br clear=3D"none">> > XHDI is muc=
h more limited than the SCSI Driver<br clear=3D"none">> Well, i didn't w=
ant to explain to the HDDRIVER guru what XHDI is ;)I just wanted to point o=
ut that there already is an existing XHDI Natfeats implementation in Aranym=
..<br clear=3D"none">> Of course direct SCSI is more powerful. But you al=
so have to take into account the special requirements for an emulator. Eg. =
the devices that are managed by ACSI, SCSI and IDE are most likely not real=
devices, but just plain files on the host.There are also configurations (l=
ike mine ;) where you don't have an disk driver at all, because all access&=
nbsp; to block devices is done through the HOSTFS Natfeat. Will the SCSI In=
terface be still accessible in this case?<br clear=3D"none">> <br =
clear=3D"none">> <br clear=3D"none">> <br clear=3D"none">> &=
nbsp; Uwe Seimet <<a shape=3D"rect" ymailto=3D"mailto:Uwe.Seimet@=
seimet.de" href=3D"mailto:Uwe.Seimet@xxxxxxxxx";>Uwe.Seimet@xxxxxxxxx</a>>=
; schrieb am 7:19 Dienstag, 18.August 2015:<br clear=3D"none">> &n=
bsp; <br clear=3D"none">> <br clear=3D"none">> Hi,<br clear=3D"=
none">> <br clear=3D"none">> XHDI is much more limited than the SCSI =
Driver, which is the more modern<br clear=3D"none">> approach. XHDI can =
only be used for accessing block devices, and even<br clear=3D"none">> t=
hen it is limited to 32 bit sector numbers. With the SCSI Driver you can<br=
clear=3D"none">> send SCSI commands to any device, not just SCSI. It's =
basically the<br clear=3D"none">> equivalent of the sg interface.<br cle=
ar=3D"none">> XHDI is typically implemented on top of a SCSI Driver, lik=
e it is done<br clear=3D"none">> by HDDRIVER and (most likely) also by C=
BHD. And these drivers also run<br clear=3D"none">> on top of existing S=
CSI Drivers, in which case they automatically<br clear=3D"none">> provid=
e XHDI for block devices managed by the SCSI Driver.<br clear=3D"none">>=
The most recent implementation of a SCSI driver is the one Alan Hourihane<=
br clear=3D"none">> provides for his Unicorn USB adapter. Another implem=
entation is the one for<br clear=3D"none">> Milan PCI SCSI. And of cours=
e those for MagiCMac and MagiCPC.<br clear=3D"none">> <br clear=3D"none"=
>> See <a shape=3D"rect" href=3D"http://hddriver.seimet.de/en/downloads.=
html" target=3D"_blank">http://hddriver.seimet.de/en/downloads.html </a>for=
links to all these<br clear=3D"none">> specifications.<br clear=3D"none=
">> <br clear=3D"none">> Take care<br clear=3D"none">> <br clear=
=3D"none">> Uwe<br clear=3D"none">> <br clear=3D"none">> > <br =
clear=3D"none">> > >I'm currently experimenting with a (Linux-only=
) SCSI Driver implementation<br clear=3D"none">> > >that gives sea=
mless, direct access to devices. It maps SCSI Driver calls<br clear=3D"none=
">> > >to the Linux sg interface. 8 or 9 calls have to be mapped.<=
br clear=3D"none">> > There is already an existing XHDI driver interf=
ace that basically provides the same functionality as the native atari inte=
rface. It is in use by EmuTOS, and also by recent linux-68k kernels. Sounds=
like this is very similar to what you are experimenting with.<br clear=3D"=
none">> > In Aranym there is also some low-level SCSI support through=
the IDE interface. This is not based on Natfeats, but on direct hardware e=
mulation. I cannot tell though how good it is working, and some low-level c=
ommands might not be implemented.<br clear=3D"none">> > <br cle=
ar=3D"none">> > <br clear=3D"none">> > <br clear=3D"none">> =
> Uwe Seimet <<a shape=3D"rect" ymailto=3D"mailto=
:Uwe.Seimet@xxxxxxxxx" href=3D"mailto:Uwe.Seimet@xxxxxxxxx";>Uwe.Seimet@seim=
et.de</a>> schrieb am 22:56 Montag, 17.August 2015:<br clear=3D"none">&g=
t; > <br clear=3D"none">> > <br clear=3D"none">> &=
gt; Hi,<br clear=3D"none">> > <br clear=3D"none">> > >=
> Looks to me as if the existing features are mainly related to the deb=
ugger.<br clear=3D"none">> > > Thats maybe because Hatari does not=
need anything else yet. There are quite some more features implemented in =
eg. Aranym.<br clear=3D"none">> > > > is there a preferred way =
of doing that, some kind of extension point, some guideline?<br clear=3D"no=
ne">> > > I dont't think that there is a general guideline. There =
are is bit of documentation on Native Features Intro [ARAnyM Wiki] that cov=
ers the basic features. Most features use sub-id 0 to identify their i=
nterface version, and i would recommend to do this for any new feature. Any=
thing else largely depends on what your feature implements.<br clear=3D"non=
e">> > <br clear=3D"none">> > I'm currently experimenting with =
a (Linux-only) SCSI Driver implementation<br clear=3D"none">> > that =
gives seamless, direct access to devices. It maps SCSI Driver calls<br clea=
r=3D"none">> > to the Linux sg interface. 8 or 9 calls have to be map=
ped.<br clear=3D"none">> > <br clear=3D"none">> > The basics ar=
e working already, see attached screenshot. I have not<br clear=3D"none">&g=
t; > dared yet to write something to a drive, though ;-).<br clear=3D"no=
ne">> > <br clear=3D"none">> > Take care<br clear=3D"none">>=
> <br clear=3D"none">> > Uwe<br clear=3D"none">> > <br clea=
r=3D"none">> > <br clear=3D"none">> > <br clear=3D"none">=
> <br clear=3D"none">> <br clear=3D"none">> <br clear=3D"none">>=
; <br clear=3D"none">> <br clear=3D"none"><br clear=3D"none"><br =
clear=3D"none"></div><br><br></div> </div> </div> </div></div></body></ht=
ml>
------=_Part_251315_2018327544.1439986513360--