Re: [RTnet-developers] Monitoring Link Beat

[Jorge A. <j-a...@cr...>]

Em Quinta, 23 de Novembro de 2006 17:27, o Jan Kiszka escreveu:
> 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 
> >>> board.
> >>>>> What i want is to pass the index of the board, and internaly call the 
> >>>>> "do_ioctl" function that should be initialialized in the rtnet_device 
> >>> struct 
> >>>>> for each device.
> >>>>>
> >>>>> My question is, How do i call the do_ioctl function using the file 
> >>> descriptor 
> >>>>> of one socket that is open passing the number of the if_index (or the 
> >>>>> interface name)? And how rtnet knows wath device to call?
> >>>> IOCTLs on RTDM sockets come in over the related protocol handler, see
> >>>> 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 you
> >>>> 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 of 
> > ioctl 
> >>> "RTIOC_TYPE_MONITORING"
> >> So you are about to define a new IOCTL? Is there no comparable interface
> >> existing in Linux? Will this interface be about polling for the current
> >> link status? I'm not aware of an official Linux API for this, but this
> >> doesn't mean there isn't any.
> > 
> > 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.
> > 
> > The IOCTL is only made when the user asks for it. Theres no polling 
mechanism 
> 
> Which is already what I meant with polling.
> 
> > working here. Thats another question that can be implemented in the 
future.
> > 
> >> 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.
> > 
> > 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 
developers 
> > 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.
> 
> > 
> >>> 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 
> >>> (nLinkBeat;).
> >>>
> >>> Any sugestion??!!
> >> In any case, try to do it within struct ifreq. There is e.g. ifru_ivalue
> >> used by multiple requests to pass an integer up and down.
> > 
> > The ifreq structure is very limited:
> > struct ifreq 
> > {
> > #define IFHWADDRLEN	6
> > 	union
> > 	{
> > 		char	ifrn_name[IFNAMSIZ];		/* if name, e.g. "en0" */
> > 	} ifr_ifrn;
> > 	
> > 	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;
> > };
> > 
> > only has two fileds, i think the hardware monitoring need much more in the 
> > future. If a new structure is already available the next developers only 
has 
> > to fill it with the new parameters that they need, or even make a union 
> > 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?

For example:

check if Auto-negotiation is enabled or not.
check the link speed.
check if is Half or Full duplex.
change the speed manualy.

And some more that i dont remember now.

I will send you a patch todoy or tomorow morning with something implemented.

Jorge

> 
> Jan
> 
> 

-- 
Jorge Almeida
j-a...@cr...
DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or without errors as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software, SA.