Dnia Wednesday 30 of April 2008, Gerrit Renker napisał: > | c) allow qpolicy to use each cmsg header as different parameter. So that > (...) > I think (c) is best, here is what I'd support. > (...) Seems we are getting closer in our views, see the just sent patch. > Ok, but this is a separate question and it is about a yet non-existing > policy. > Hopefully someone, someday will implement it. So it is good to have a basic idea how it might work. > So far there is a "priority" policy, for which I think we agree that 32 > bits are enough. > For storing just priority - yes. I'd even say that it is too much... > And both associated parameters can be parsed differently, in particular > there is no requirement to restrict DCCP_SCM_TIMEOUT to use 32 bits - it > could even pass a struct timeval or struct timespec. > Yes, that's nice. > Then there is a yet non-existing "timeout" policy, which has no associated > field yet. If we can assume that e.g. the skb->tstamp field can be used > to store timeouts, then there are separate fields associated with separate > policies. > > Thirdly, there is the aggregate policy "priority+timeout", which can > then use both skb->priority and skb->tstamp. > > I.e. to answer the question, I think it is best to implement "timeout" > first, solve the problems it brings up; when that is done, > "priority+timeout" will be easy to do - it could be constructed just out of > the existing functions defined for "priority" and "timeout". > > In that manner, other policies can be modularly constructed - for instance > by combining "timeout" with a different form of the "priority" policy. > I'm not entirely sure if such modular constructions would be possible. I prefer to think of "timeout policy" and "prio policy" as a special cases of "timeout+prio policy" with respectively DCCP_SCM_PRIORITY and DCCP_SCM_TIMEOUT not supplied (and thus set to their default values: 0 and INFINITY). -- 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
