netdev - Re: [PATCH 1/1] [DCCP][QPOLICY]: Make information about qpolicies available to userspace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200806202303.37924.tomasz@grobelny.oswiecenia.net>
Date:	Fri, 20 Jun 2008 23:03:37 +0200
From:	Tomasz Grobelny <tomasz@...belny.oswiecenia.net>
To:	Gerrit Renker <gerrit@....abdn.ac.uk>, acme@...hat.com
Cc:	dccp@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 1/1] [DCCP][QPOLICY]: Make information about qpolicies available to userspace

Dnia Thursday 19 of June 2008, Gerrit Renker napisał:
> But such a bottom-up approach would not necessarily make sense, since
> likely the policy will do a bit more work than just reacting to the
> parameters it uses, which leads to the next point.
>
Agreed.

> | Could be nice, but what happens if we have two policies with the same set
> | of supported parameters? How do we differentiate them? In the above: how
> | do we diffrentiate between simple policy (which doesn't have any
> | parameters ever) and prio policy with no parameters (just because we
> | don't need to provide any for one particular case)?
>
> 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.

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.
-- 
Regards,
Tomasz Grobelny
--
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