Re: [RTnet-developers] arcnet driver

[Jan K. <jan...@we...>]

Chris Lightcap wrote:
> Hi Jan,
>=20
> I've modified a simple arcnet communication program to support the=20
> new real-time driver.. but I'm having a problem opening the socket=20
> (the first step, i know!) where the function returns an integer=20
> value of -97? The original program called the socket function with=20
> the following socket type and protocol and I've modified it as=20
> shown below.
>=20
> int sockfd =3D socket(PF_PACKET, SOCK_PACKET, htons(ETH_P_ALL)); //=20
> the original
>=20
> int sockfd =3D rt_dev_socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));=20
> // the modified
>=20
> I know that SOCK_PACKET is an outdated socket type but the=20
> alternative SOCK_RAW will not work either. I found in the=20
> rt_pci32.c driver that the arguments AF_INET and SOCK_DGRAM work=20
> but I need to use header information in the arcnet packets.
>=20
> Any suggestions?
>=20

Depends on what you really need for your arcnet app: RTnet's rtpacket
currently provide PF_PACKET:SOCK_DGRAM, i.e. "cooked" access to some
networking device. And this access is limited to a per-protocol basis,
which means no ETH_P_ALL. Moreover, it's a bit Ethernet-specific, see
rt_packet_recvmsg().

Some generalisation of the rtpacket socket interface will therefore be
required. Whether you also have to add ETH_P_ALL support, depends on
your application design. Currently, the core would demux incoming arcnet
protocols for you and and distribute them to different sockets
(registered via socket(PF_PACKET, SOCK_DGRAM, <protocol>)). ETH_P_ALL
would require exclusive device access because RTnet has currently no
means to clone incoming packets for multiple receivers. SOCK_RAW might
be necessary if there is no clean way to get all required arcnet header
informations through the SOCK_DGRAM interface.

Re-check your situation and suggest what you think it's best for your
scenario. Then we can see how to generalise your usage scenario and
integrate it cleanly.

Jan