Aros/Developer/NICDriversDev

Sana II
The SANA2 specification (version 2 is available from Aminet, sana2_v2.lha from General FTP Germany FTP or UK html and read online 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 Numbers
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 driver
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

Wired
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,

Wireless
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 work
http://en.wikipedia.org/wiki/Device_driver and http://lwn.net/Kernel/LDD3/ and http://en.wikibooks.org/wiki/The_Linux_Kernel

ArosTCP
Does anyone know why our network stack has the following limitations:


 * each task needs to open its own library base
 * socket created by task A cannot be used by task B without doing some "sharing magic"

This limitation is a big 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.