Em Sexta, 24 de Novembro de 2006 17:58, escreveu:
> 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.
Ok lets implements this.
It's standard.
>
> >
> >>>
> >>> /* 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).
Lets use the rt_socket_if_ioctl, the ethtool use the ifreq struct and we do
the same thing.
>
> 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
>
For now i need only the link beat functionality and don't have time anymore
for more configuration especific things.
Maybe in the future i can continue the work.
>
--
Jorge Almeida
[EMAIL PROTECTED]
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.
-------------------------------------------------------------------------
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
