Aros/Developer/NICDriversDev

Navbar for the Aros wikibook
Aros User Docs
Aros User Docs
Aros User FAQs
Aros User Applications
Aros User DOS Shell
Aros/User/AmigaLegacy
Aros Dev Docs
Aros Developer Docs
Porting Software from AmigaOS/SDL
For Zune Beginners
Zune .MUI Classes
For SDL Beginners
Aros Developer BuildSystem
Specific platforms
68k Support
PPC Power Architecture Support
Arm Raspberry Pi Support
Android support
Linux and FreeBSD Support
Windows Mingw and MacOSX Support
Aros x86 Installing
Aros x86 Audio/Video Support
Aros x86 Network Support
Aros x86 Complete System HCL
Aros Storage Support IDE SATA etc
Aros Poseidon USB Support
x86-64 Support
misc
Aros Public License


Sana2Edit

The SANA2 specification (version 2 is available from Aminet, sana2_v2.lha from General FTP Germany FTP or UK html and read online [http://wiki.amigaos.net/index.php/Revision_2_%2B_3 here}.

Aminet comm/tcp and Aminet comm/net and search Search Aminet


Being SANA II compatible means it will support all the major network protocols available for AROS.



Multicast: (least-significant bit of the first byte - low-order bits in a byte transmitted first) Broadcast:


Sana2IOReq

  • 6 bytes of destination address (Ethernet addresses consist of 47 bits of address information and a 1 bit multicast flag)
  • 6 bytes of source address
  • 2 bytes of type,
  • 64 to 1500 bytes of data (packet)
  • (followed by 4 byte CRC value covering all of the above which is hardware generated and checked, hence not included in even raw packets)



Xerox(TM) Packet Type NumbersEdit

decimal   Hex           Description
-------   ---           -----------
  000     0000-05DC     IEEE 802.3 Length Field
 2048     0800          TCP/IP -- IP
 2054     0806          TCP/IP -- ARP
32821     8035          TCP/IP -- RARP
32923     809B          Appletalk
33011     80F3          AppleTalk AARP (Kinetics)
33100     814C          SNMP
33079     8137-8138     Novell, Inc. 



Overview of a simple NIC driverEdit

setup tx (transfer/driver) & rx (receive) descriptors and data buffers
    set packet size, split data into packets and queue serially (one after the other) 
    handshaking/data integrity check per packet
    poll until all rx packets received 



WiredEdit

A typical ethernet driver has these files associated with it in workbench/devs/networks/

device.c      - (APTR)DevOpen, (APTR)DevClose, (APTR)DevExpunge, (APTR)DevReserved, (APTR)DevBeginIO, (APTR)DevAbortIO, 
aros-device.c - AROSDevInit, AROSDevOpen, AROSDevClose, AROSDevExpunge, AROSDevReserved, AROSDevBeginIO, AROSDevAbortIO, 
                RXFunction, TXFunction, *DMATXFunction, AROSInt, 
expansion.c   - GetExpansionCount(), *AllocExpansionCard(), FreeExpansionCard(), 
                AddExpansionIntServer(), RemExpansionIntServer(), 
pci.c         - GetPCICount(), *GetPCIUnit(), *FindPCIUnit(), *CreatePCIUnit(), DeletePCIUnit(), *AllocCard(), FreeCard(), 
                AddPCIIntServer(), RemPCIIntServer(), IsCardCompatible(), Product_Codes, 
unit.c        - *CreateUnit(), DeleteUnit(), InitialiseAdapter(), ConfigureAdapter(), FillConfigData(), 
                 GoOnline(), GoOffline(), AddMulticastRange(), RemMulticastRange(), *FindMulticastRange(), SetMulticast(), 
                *FindTypeStats(), FlushUnit(), StatusInt(), RXInt(), CopyPacket(), AddressFilter(), TXInt(), TXEndInt(), 
                UpdateStats(), ReportEvents(), UnitTask(), ReadMII(), WriteMII(), BusyMicroDelay(), 
                GetEEPROMAddressSize(), ReadEEPROM(), ReadEEPROMBits(), WriteEEPROMBits(), ReadEEPROMBit(), WriteEEPROMBit, 
request.c     - ServiceRequest(), CmdInvalid(), CmdRead(), CmdWrite(), CmdFlush(), CmdS2DeviceQuery(), PutRequest(), 
                CmdGetStationAddress(), CmdConfigInterface(), CmdBroadcast(), CmdTrackType(), CmdUntrackType(), 
                CmdGetTypeStats(), CmdGetSpecialStats(), CmdGetGlobalStats(), CmdOnEvent(), CmdReadOrphan(), 
                CmdOnline(), CmdOffline(), CmdDeviceQuery(), CmdAddMulticastAddresses(), CmdDelMulticastAddresses(), 



WirelessEdit

A typical wireless driver has these files associated with it in workbench/devs/networks/

aros-device.c
device.c
encryption.c
request.c
startup.c
unit.c



How does a GPL-linux driver workEdit

http://en.wikipedia.org/wiki/Device_driver and http://lwn.net/Kernel/LDD3/ and http://en.wikibooks.org/wiki/The_Linux_Kernel


Detecting the device, enabling the device and understanding the network deviceEdit

Bus-independent device accessEdit

Understanding the PCI configuration spaceEdit

Initializing net_deviceEdit

Understanding transmission mechanism and receiving mechanismEdit

Making the device ready to transmit packets and to receive packetsEdit

How to convert GPL-linux driver to SANA2 AROS driverEdit

ArosTCPEdit

Does anyone know why our network stack have the following limitations:

  • each task needs to open it's own library base
  • socket created by task A cannot be used by task B without doing some "sharing magic"

This limitation is a bug hurdle when porting multi threaded networking software from linux world as there, there is not such limitation.

Because some things are based on signals, and signals belong to some task. Also, there's no other way to have thread-safe errno and DNS lookups. This comes from original AmiTCP design, Miami is the same. Only Roadshow (OS4 stack) provides shared SocketBase. This can be queried by querying a SocketBaseTag, i don't remember details. In AROSTCP the same can be implemented by separating task context from SocketBase and using AVL tree for associating context with the task. This is true about the Exec Signalling setup - All Tasks Allocate their own signals (this is true from original exec). Or wait till the relbase patches are commited and use that mechanism. It will then be done for you.

Does AROS need the TCP stack re-written to have a single common library with a shared library base and per-caller specialist data provided as well? with the *option* of setting per-task private data? per-task data would still need to have an associative lookup mechanism.

This is a holdover from the AmiTCP network stack and Miami Classic Amiga Network stack implementations of creating the bsdsocket.library itself when the network Application (AmiTCP or Miami or MiamiDX) was launched.

There is also the holdover from the task/process model of Classic Exec allowing each opener of a library to have a custom library base.

"It is a common knowledge that each process that uses bsdsocket.library has to open the library only for its very own purposes - database of the library is connected with the process and can not be shared between other processes." (source: http://aminet.net/package/comm/tcp/networksnooper)

Most major UAE versions have memory-only bsdsocket.library (including all other "virtual" devices like uaehf.device, uaescsi.device etc..) I think some port does (did have?) "real" library but it most likely only contained m68k<>host C-routine jump table magic.

AmiTCP/IP documentation to Aminet.


I am dreaming of a full TCP/IP based on the amiga message passing system. Thus with for example ip.device, tcp.device, udp.device etc.



ReferenceEdit

Each sana2 device has

AbortIO 
CloseDevice 
CMD_CLEAR 
CMD_FLUSH 
CMD_INVALID 
CMD_READ 
CMD_RESET 
CMD_START 
CMD_STOP 
CMD_UPDATE 
CMD_WRITE 
OpenDevice 
S2_ADDMULTICASTADDRESS 
S2_BROADCAST 
S2_CONFIGINTERFACE 
S2_DELMULTICASTADDRESS 
S2_DEVICEQUERY 
S2_GETGLOBALSTATS 
S2_GETSPECIALSTATS 
S2_GETSTATIONADDRESS 
S2_GETTYPESTATS 
S2_MULTICAST 
S2_OFFLINE 
S2_ONEVENT 
S2_ONLINE 
S2_READORPHAN 
S2_TRACKTYPE 
S2_UNTRACKTYPE
Last modified on 3 November 2012, at 10:10