[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080623165826.GB8692@gerrit.erg.abdn.ac.uk>
Date: Mon, 23 Jun 2008 17:58:26 +0100
From: Gerrit Renker <gerrit@....abdn.ac.uk>
To: Tomasz Grobelny <tomasz@...belny.oswiecenia.net>
Cc: acme@...hat.com, dccp@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 1/1] [DCCP][QPOLICY]: Make information about qpolicies
available to userspace
| > We could still encode the parameters in the policy ID, by splitting the
| > bitmask, e.g. the low 24 bits to encode parameters, and the high 8 bits
| > to encode the policies using the same combination of parameters.
| >
| Yes, technically we could do it this way. Encoding accepted parameters in
| policy ID would provide applications with means to check whether certain
| parameters are supported. But should we mix two IMO distinct concepts (policy
| behaviour and accepted parameters) in one bitfield? I'd rather have them
| separated.
|
Yes having them separate gives a clearer semantics. But it comes at a price -
to retrieve the parameters, we need an extra function or lookup table.
Maybe there is an elegant solution which allows to encode the required
parameters while keeping the semantics clear?
| Keeping policy IDs as they are and using a bitfield for just parameters could
| be a nice idea. It would certainly simplify checking which parameters are
| supported - just a simple & and == would suffice.
| --
And it is fast, too.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists