20-Apr-2024 02:20 GMT.		 UNDER CONSTRUCTION
Anonymous, there are 13 items in your selection
[News] Proposal for SANA-IIR5 extensions publishedANN.lu
Posted on 06-May-2004 18:43 GMT by Olaf Barthel13 comments
View flat
View list
An article detailing enhancements to the Amiga networking driver standard has appeared on 'www.amigadev.net'. The proposed extensions are intended to improve core driver functionality by replacing 68000 ABI dependencies with architecture-neutral call-back hooks. You can find the article in the documents section, where it is tagged as 'new'. Comments and criticism are welcome!
Proposal for SANA-IIR5 extensions published : Comment 1 of 13ANN.lu
Posted by brotheris on 06-May-2004 22:14 GMT
Is it only useful under OS4 ?
Proposal for SANA-IIR5 extensions published : Comment 2 of 13ANN.lu
Posted by Anonymous on 06-May-2004 23:44 GMT
In reply to Comment 1 (brotheris):
Any other official AmigaOS that runs on anything else than PPC and therefore needs to abstract a specification a tad above from 20 year old hardware? In that case, yes.
Proposal for SANA-IIR5 extensions published : Comment 3 of 13ANN.lu
Posted by Olaf Barthel on 07-May-2004 04:24 GMT
In reply to Comment 1 (brotheris):
> Is it only useful under OS4 ?

I don't think so. The 68k call-back functions may have been introduced to
keep the overhead of the data transfers as low as possible. But the fact
remains that for call-back functions, there is an operating system API
which should be used instead. The utility.library/CallHookPkt functionality
solves problems which are not as easily addressed by the generic 68k
call-back functions, such as where the IOSana2Req address should be stored
and how context information should be handed to the function.
Proposal for SANA-IIR5 extensions published : Comment 4 of 13ANN.lu
Posted by Olaf Barthel on 07-May-2004 04:24 GMT
In reply to Comment 2 (Anonymous):
> Any other official AmigaOS that runs on anything else than PPC
> and therefore needs to abstract a specification a tad above from
> 20 year old hardware? In that case, yes.

Please read the SANA-II specifications before you snipe at the
proposal. Thank you.
Proposal for SANA-IIR5 extensions published : Comment 5 of 13ANN.lu
Posted by Elwood on 07-May-2004 06:10 GMT
Strange, I always thought www.amigadev.net was for AmigaDE developments only... Even ths first page of the website doesn't mention AmigaOS...
Proposal for SANA-IIR5 extensions published : Comment 6 of 13ANN.lu
Posted by lolly on 07-May-2004 06:38 GMT
In reply to Comment 5 (Elwood):
Whats to say AmigaDE couldn't use SANA-II? ;-)
Proposal for SANA-IIR5 extensions published : Comment 7 of 13ANN.lu
Posted by Anonymous on 07-May-2004 06:53 GMT
Interresting read (note I've never made any SANA2 driver yet).

But I was thinking: maybe SANA2 should implement some kind of "this, this and this is done by the NIC". Because modern network card can do:

IP Checksum (receive and transmit)
TCP/UDP Checksum (receive and transmit)
FlowControl (802.3x) see Linux "Forwarding between high speed internface"

Linux also supports some kinds of forward without mem copy (by just telling to the sender card that the receiver has put the packet somewhere ...).

Bye
Proposal for SANA-IIR5 extensions published : Comment 8 of 13ANN.lu
Posted by itix on 07-May-2004 10:47 GMT
Never programmed SANA-II driver, so here is my dumb question: why not use System V calling convention?

Is it because 68k SANA-II driver programmers could start using Hooks in their 68k drivers, allowing max performance in OS4? Otherwise, I would not use Hooks at all but PPC function pointers or library vectors?
Proposal for SANA-IIR5 extensions published : Comment 9 of 13ANN.lu
Posted by Ray A. Akey on 07-May-2004 12:35 GMT
In reply to Comment 5 (Elwood):
Elwood,

This is true. Amigadev.net appeared to be targeted toward AmigaDE because that's where Amiga's focus was at the time. In reality, we started to internally look towards changing amigadev.net to host information and resources for both AmigaOS and AmigaDE/Anywhere.

Alas, today, Amiga Inc. doesn't own AmigaOS so those plans have likely changed.

However.. Olaf asked me to place the document online and, considering his previous SANA-IIR4 proposal was published there, amigadev.net was again the chosen location. This is the most likely place that it could/should have been published, until our friends at KMOS are ready to host documents and information relating to AmigaOS.
Proposal for SANA-IIR5 extensions published : Comment 10 of 13ANN.lu
Posted by Elwood on 07-May-2004 14:48 GMT
In reply to Comment 9 (Ray A. Akey):
Ok, that explains... Thanks.
Proposal for SANA-IIR5 extensions published : Comment 11 of 13ANN.lu
Posted by Kid X on 07-May-2004 15:36 GMT
A job well done! For those of you not familiar with the name Olaf "Olsen" Barthel, he is - in my opinion - one of the most experienced AmigaOS developers currently active. His commitment to the Amiga computing platform is simply put amazing.

Please keep up the good work, Olaf! (and consider porting AmigaDesk to OS 4 :)
Proposal for SANA-IIR5 extensions published : Comment 12 of 13ANN.lu
Posted by Olaf Barthel on 07-May-2004 18:53 GMT
In reply to Comment 7 (Anonymous):
> Interresting read (note I've never made any SANA2 driver yet).
>
> But I was thinking: maybe SANA2 should implement some kind of "this, this
> and this is done by the NIC". Because modern network card can do:
>
> IP Checksum (receive and transmit)
> TCP/UDP Checksum (receive and transmit)
> FlowControl (802.3x) see Linux "Forwarding between high speed internface"
>
> Linux also supports some kinds of forward without mem copy (by just
> telling to the sender card that the receiver has put the packet somewhere ...).

We are bound to see further enhancements to the driver standard. The methods
chosen for the SANA-II drivers to transfer data between the NIC and the networking
software is positively primitive. And the enhancements, such as for DMA transfer,
were tailor-made for a system design which allowed DMA to access any memory.
Today's NICs don't support this approach. This might call for a tighter integration
of drivers and networking software. I guess we'll have to wait for the hardware
demands to provide more input as to how SANA-II should grow.
Proposal for SANA-IIR5 extensions published : Comment 13 of 13ANN.lu
Posted by Olaf Barthel on 07-May-2004 19:01 GMT
In reply to Comment 8 (itix):
> Never programmed SANA-II driver, so here is my dumb question: why not use
> System V calling convention?

One reason is that the Hook interface was created exactly for the purpose
of allowing for call-back functions. Another reason might be in that
replacing one ABI with another ABI is not really solving a fundamental
design problem. What if the next OS release ends up picking a different
ABI? It would not be advisable to enforce another SANA-II driver update :)

> Is it because 68k SANA-II driver programmers could start using Hooks in their 68k
> drivers, allowing max performance in OS4? Otherwise, I would not use Hooks at
> all but PPC function pointers or library vectors?

It's part of a cleanup operation, you might say. When Heinz and me worked on
the proposal, he suggested to go so far as to drop all TagItem parameters
from the OpenDevice() call and leverage all the functionality through the
SANA2Hook. This would have been a cleaner, more orthogonal solution. But in
terms of backwards compatibility it would have created problems. For example,
there's no telling how existing driver software will react to changes in the
API. Even benign changes, such as the extension of the Sana2DeviceQuery data
structure in the SANA-IIR4 proposal broke drivers such as the a2065.device
driver (which did not even validate its input). Now you might ask, why care
about these dinosaurs? In my opinion, you should never put the stability of
the system in danger if you can avoid it.
Anonymous, there are 13 items in your selection
Back to Top