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: <200806172228.06801.tomasz@grobelny.oswiecenia.net>
Date:	Tue, 17 Jun 2008 22:28:05 +0200
From:	Tomasz Grobelny <tomasz@...belny.oswiecenia.net>
To:	Gerrit Renker <gerrit@....abdn.ac.uk>
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

Dnia Tuesday 17 of June 2008, Gerrit Renker napisał:
> | 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 agree that providing both parameters may be useful, but don't see this
> as a place of contradiction.
>
> In the kernel I think it is best to make it type-safe, i.e. no new
> parameters to already-defined policies. But I can't see how this would
> restrict the use.
> (...)
>
So we would need new policy for each new parameter, right? I somehow don't 
like it but it should work. You are right that this way runtime parameter 
discovery is not necessary. BTW, we will have a bit of a problem with naming 
qpolicies ;-)

> | > With a manpage I mean to document
> |
> | Is there any "man dccp"?
>
> Not yet. If you or someone else can find time to contribute towards a DCCP
> manpage, that would be just great. The best available information so far is
> on the OSDL pages for DCCP and Documentation/networking/dccp.txt.
>
But it's not in kernel sources? Then probably a new page would not be accepted 
as it would describe an experimental API. The above mentioned dccp.txt is 
probably the best place for now.

> I think there is a special maintainer for the kernel manpages, who could
> be emailed with a basic manpage. But ther ere is a similar problem - if the
> API changes frequently, then this requires to update the manpage
> accordingly.
>
I guess these would mostly be API additions, without any incompatible changes.

> As alternatives to documentation, there are for example providing
>  *running source code,
I will for sure be working on some apps to demonstrate how the new interface 
can be used. But first I need to create a simple server/client transmitting 
G.726 encoded voice over UDP/RTP (any hints on that?)...

>  * web pages or
Is there any official, publicly editable DCCP wiki? I'd rather not create yet 
another page...
-- 
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