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? Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ RTnet-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-developers
