Re: [RTnet-developers] Monitoring Link Beat

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

Jorge Almeida wrote:
> Em Quinta, 23 de Novembro de 2006 16:46, escreveu:
>> Jorge Almeida wrote:
>>> Em Quinta, 23 de Novembro de 2006 16:02, escreveu:
>>>> Jorge Almeida wrote:
>>>>> Hello Jan,
>>>>>
>>>>> I'm trying to implement an easy way of monitoring the link beat of =
one=20
>>> board.
>>>>> What i want is to pass the index of the board, and internaly call t=
he=20
>>>>> "do_ioctl" function that should be initialialized in the rtnet_devi=
ce=20
>>> struct=20
>>>>> for each device.
>>>>>
>>>>> My question is, How do i call the do_ioctl function using the file =

>>> descriptor=20
>>>>> of one socket that is open passing the number of the if_index (or t=
he=20
>>>>> interface name)? And how rtnet knows wath device to call?
>>>> IOCTLs on RTDM sockets come in over the related protocol handler, se=
e
>>>> e.g. this one for packet sockets:
>>>>
>>>>
> http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/packet/af_packet.=
c#L240
>>>> From there on you can easily go down the chain.
>>>>
>>>> As the IOCTLs are per-socket and not per-device, you have to provide=
 the
>>>> information about the address device within the request packet. Do y=
ou
>>>> have some Linux data structure you can reuse for it? Something like =
for
>>>> SIOCGIFINDEX?
>>> Yes, i have the struct ifreq used for the SIOCGIFINDEX ioctl.
>>>
>>> I was checking the code and the path is something like this:
>>>
>>> 1	Start at "rt_packet_ioctl" (af_packet.c) checking for  a new type o=
f=20
> ioctl=20
>>> "RTIOC_TYPE_MONITORING"
>> So you are about to define a new IOCTL? Is there no comparable interfa=
ce
>> existing in Linux? Will this interface be about polling for the curren=
t
>> link status? I'm not aware of an official Linux API for this, but this=

>> doesn't mean there isn't any.
>=20
> I don't know either if anything similar exists.
> I used to use the mii-diag tool to check if the has link bit or not.
>=20
> The IOCTL is only made when the user asks for it. Theres no polling mec=
hanism=20

Which is already what I meant with polling.

> working here. Thats another question that can be implemented in the fut=
ure.
>=20
>> Anyway, do this multiplexing here:
>>
>> http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/socket.c#L225
>>
>> i.e. in rt_socket_if_ioctl(). That way it will automatically work for
>> all kind of RTnet sockets.
>=20
> But it is driver dependent, and not a configuration stuff.

The driver dependent stuff comes with calling rtdev->do_ioctl. Here it
is about finding out which driver to to call.

> Isn't better to define already a new type of IOCTL??
> For future drivers and sockets it will be already available and the dev=
elopers=20
> are free to implement it.

If there is no IOCTL for Linux that tells you "link on device X is
up/down", then define one for RTnet.

>=20
>>> 2	send it to a new function in socket.c "rt_socket_monitoring_ioctl"
>>>
>>> 3	check the device that we are trying to check the link beat
>>>
>>> 4	send it to the driver (rt_8139too.c) with the do_ioctl pointer.
>>>
>>> In this i only have one doubt:
>>> 	Where do i return the result?
>> In the same data structure you used for the request? What does it look=

>> like so far?
>>
>>> Maybe the solution:
>>> 	Build a new struct in RTnet has support of the monitoring IOCTLS
>>> 	(just for now ) something like
>>>
>>> struct SDeviceMonit
>>> {
>>> 	int nDeviceIndex;
>>> 	int nLinkBeat;
>>> }
>>>
>>> This way i can identify the device (nDeviceIndex;) and get the result=
=20
>>> (nLinkBeat;).
>>>
>>> Any sugestion??!!
>> In any case, try to do it within struct ifreq. There is e.g. ifru_ival=
ue
>> used by multiple requests to pass an integer up and down.
>=20
> The ifreq structure is very limited:
> struct ifreq=20
> {
> #define IFHWADDRLEN	6
> 	union
> 	{
> 		char	ifrn_name[IFNAMSIZ];		/* if name, e.g. "en0" */
> 	} ifr_ifrn;
> =09
> 	union {
> 		struct	sockaddr ifru_addr;
> 		struct	sockaddr ifru_dstaddr;
> 		struct	sockaddr ifru_broadaddr;
> 		struct	sockaddr ifru_netmask;
> 		struct  sockaddr ifru_hwaddr;
> 		short	ifru_flags;
> 		int	ifru_ivalue;
> 		int	ifru_mtu;
> 		struct  ifmap ifru_map;
> 		char	ifru_slave[IFNAMSIZ];	/* Just fits the size */
> 		char	ifru_newname[IFNAMSIZ];
> 		void __user *	ifru_data;
> 		struct	if_settings ifru_settings;
> 	} ifr_ifru;
> };
>=20
> only has two fileds, i think the hardware monitoring need much more in =
the=20
> future. If a new structure is already available the next developers onl=
y has=20
> to fill it with the new parameters that they need, or even make a union=
=20
> similar to the struct ifreq.

OK, if you see the need for further fields that don't fit here, we can
extend the structure. But I would at least like to keep its head to
unify its usage - both in user-space and in the kernel.

What further information would you like to bundle one day
_with_this_particular_ service call?

Jan