Jorge Almeida wrote:
>>> ------------------------------------------------------------------------
>>>
>>> Index: stack/include/rtnet.h
>>> ===================================================================
>>> --- stack/include/rtnet.h (revision 1087)
>>> +++ stack/include/rtnet.h (working copy)
>>> @@ -52,6 +52,14 @@
>>> void *arg;
>>> };
>>>
>>> +/*
>>> + * Monitoring Device structure
>>> + */
>>> +struct rtnet_device_monitoring
>>> +{
>>> + int ifindex;
>>> + int link_beat;
>>> +};
>> So, is this the final structure for the request or do you plan to attach
>> more information already? The question is what primary purpose it should
>> be optimised for. If performance doesn't matter that much, we could
>> bundle as much information as make sense for an enhanced device status
>> (as you suggested yesterday).
>>
>> But then I would really prefer to keep the structure close to ifreq,
>> i.e. identification via name, embedded information in the existing space
>> (there is room, just takes some overloading of types). This would allow
>> to reuse existing code to pass the information up/down. We do not
>> perform user-safe argument passing yet, but once we do, I would like to
>> concentrate on as few different spots as possible.
>
> i dont understand very well why you want to keep the ifreq structure (its
> limited, only two fields)
> I think the best thing is to define already a new structure for monitoring,
> like do in the patch.
ifreq can carry at least 4 words as payload, that should be enough for
this purpose. One could overload the structure like this
struct rtnet_ifstatus {
char ifr_name[IFNAMSIZ]; /* Interface name */
int link; /* better: explicit widths like __u32 etc. */
int speed;
...
}
and still share common entry/exit code with other ifreq IOCTLs.
OK, I dug a bit deeper and found the corresponding Linux interface:
ethtool. Never looked at all details of that API so far, but it actually
seems to define what is required here, namely ETHTOOL_GLINK and
ETHTOOL_GSET. The rest is not so interesting for RTnet.
The invocation works via SIOCETHTOOL and ifreq. The ethtool-specific
data is linked via the pointer field in ifreq. That's not elegant, but
it's standard. Please have a look.
>
>>>
>>> /* sub-classes: RTDM_CLASS_NETWORK */
>>> #define RTDM_SUBCLASS_RTNET 0
>>> @@ -70,6 +78,13 @@
>>> #define RTNET_RTIOC_EXTPOOL _IOW(RTIOC_TYPE_NETWORK, 0x14, unsigned
> int)
>>> #define RTNET_RTIOC_SHRPOOL _IOW(RTIOC_TYPE_NETWORK, 0x15, unsigned
> int)
>>>
>>> +
>>> +/* RTnet Monitoring Ioctls */
>>> +// this must be different from RTIOC_TYPE_NETWORK
>>> +#define RTIOC_TYPE_NETWORK_MONITORING 152
>> I would prefer to not define a new RTIOC class for this, rather keep it
>> under RTIOC_TYPE_NETWORK.
>
> Just one question:
> If do not want to define a new IOC type, it couldn't be also in the
> RTIOC_TYPE_NETWORK type because the entry you have in the af_packet.c
>
> /* fast path for common socket IOCTLs */
> if (_IOC_TYPE(request) == RTIOC_TYPE_NETWORK)
> return rt_socket_common_ioctl(sockctx, user_info, request, arg);
>
> it goes to rt_socket_common_ioctl and not rt_socket_if_ioctl.
>
> Please decide where you want to call the RTNET_RTIOC_MONITORING_LINK_BEAT if
> in rt_socket_common_ioctl or rt_socket_if_ioctl ?!!
Agreed, that is contradictory. What way to choose now depends on ethtool
interface (=> rt_socket_if_ioctl) vs. RTnet-specific one (=>
rt_socket_common_ioctl).
So, please comment on what you need and what you could live with. Can we
go for a (subset of a) standard API here or do we need something
special, and why? Well, this is probably stuff for Monday... ;)
Have a nice WE,
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
