Dnia Thursday 12 of June 2008, Gerrit Renker napisał: > | But if the application wants information about implemented parameters > | there is currently no way to get it. It can try to send() packet and > | check return value (which is quite a hack to be honest). It will work if > | the parameter is not implemented at all. But what happens when you try to > | set priority for a packet and use "simple" qpolicy? AFAIR nothing - you > | get no information whatsoever that this parameter will not be used inside > | qpolicy. > | > | And that's why we need information about parameters in /proc or > | /proc/sys. > > Sorry I can't see here why we need information about parameters. When > introducing a new socket option there is a convention of how to use it. > > For sockopts, the type of the argument is listed for each option type. > You seem to assume that a given qpolicy is a fixed set of functionality at the time of submission to the mainline kernel. In that case you are right, the application developer knows which parameters he can attach to a packet to be sent (and (s)he knows it at the time of development), so no parameter detection is necessary. But I view it a bit differently. I think we have to go back to the discussion about how to add the "timeout" parameter (or any other). Basically there are two ways: 1. add a new "timeout" qpolicy (as you proposed), 2. extend an existing "prio" qpolicy adding DCCP_SCM_TIMEOUT parameter (as I propose). BTW, the "prio" name is a bit misleading, the qpolicy should probably be named "advanced" or something like that. In other words the basic question is: do we want to add new parameters to existing qpolicies (then we need parameter discovery) or we don't want new parameters (then we don't need information about parameters available at runtime). Having defined the alternatives it's time to decide which is better. I, of course, claim that mine (which is adding new parameters to existing qpolicies). That's simply because I think that providing both DCCP_SCM_TIMEOUT and DCCP_SCM_PRIORITY parameters may be useful. And I don't see an obvoius way of achieving that goal with "new policy for new parameter" approach. I hope this lengthy text is understandable. Either way, the question is simple: what is your concept of adding DCCP_SCM_TIMEOUT parameter? > | > If we agree on using unique strings to identify qpolicies then we can > | > keep the runtime discovery much simpler. I think a manpage would be > | > more helpful here, since the runtime discovery of parameters is not > | > immediately obvious. > | > | Manpage of what? Documentation is certainly needed but before writing one > | we need to have a basic implementation we agree upon. > | -- > > There is indeed a misunderstanding. > > We have already an implementation we agreed upon: > http://eden-feed.erg.abdn.ac.uk/cgi-bin/gitweb.cgi?p=dccp_exp.git;a=commitd >iff;h=87cf8b3ce96397f934775617ba24eb1ff404747a > Yes, but I would consider it not yet ready for application development. Why? See subject of this mail and previous paragraphs. > With a manpage I mean to document Is there any "man dccp"? > * how the two currently available qpolicies ("simple" and "prio") are > enabled; * which additional constraints they have (e.g. how they interpret > tx_qlen); * information specific to a policy (e.g. that higher priority > values in the "prio" policy mean a higher priority, comparable to > SO_PRIORITY in socket(7)); * which ancillary data the policies require (the > procfs parameters) - simple: no ancillary parameters > - prio: u32 priority value, passed as DCCP_SCM_PRIORITY via cmsg(3), > using a level of SOL_DCCP and a length of > CMSG_LEN(sizeof(uint32_t)); * ... probably I have missed something here > Fine. But where exactly should it be described? Which file? I downloaded latest man pages from [1] but dccp is not even mentioned there. Or should a new man page be created (which would involve explaining what is dccp in the first place)? [1] http://www.kernel.org/pub/linux/docs/manpages/man-pages-2.80.tar.bz2 > With that kind of documentation, I think, we would not need runtime > discovery of parameters. I still don't agree, see previous paragraphs. -- Regards, Tomasz Grobelny -- To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
