Jorge Almeida wrote: > 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.
The above information make sense. I agree that at least the link speed should come not as some bits in a single integer but as a real value to remain independent of the medium. > change the speed manualy. That's stuff for another service call. > > And some more that i dont remember now. There more we know, the better we can design the interface on first attempt. > > I will send you a patch todoy or tomorow morning with something implemented. OK, looking forward. 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
