- 1 Sana2
- 2 Overview of a simple NIC driver
- 3 How does a GPL-linux driver work
- 3.1 Detecting the device, enabling the device and understanding the network device
- 3.2 Bus-independent device access
- 3.3 Understanding the PCI configuration space
- 3.4 Initializing net_device
- 3.5 Understanding transmission mechanism and receiving mechanism
- 3.6 Making the device ready to transmit packets and to receive packets
- 4 How to convert GPL-linux driver to SANA2 AROS driver
- 5 ArosTCP
- 6 Reference
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}.
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:
- 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)
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
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(),
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
Detecting the device, enabling the device and understanding the network deviceEdit
Bus-independent device accessEdit
Understanding the PCI configuration spaceEdit
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
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.
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