Date:	Thu, 22 May 2008 02:35:41 +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 Wednesday 21 of May 2008, Gerrit Renker napisał:
> Hi Tomasz,
>
> | Since packets with invalid cmsg parameters can be rejected by kernel
> | there is a need to allow applications to access information on available
> | policies and their respective cmsg parameters at runtime. This patch
> | simplifies maintaining compatibility between userspace applications and
> | DCCP code.
>
> The difference to querying supported CCIDs is that
>  * CCIDs are all defined per RFC documents, and that
Yes, but does that change anything?

>  * different combinations of CCIDs are possible due to the Kconfig options.
>
Here we can have various kernel versions which is not much different. In both 
cases we need runtime feature detection.

> As far as I understand your patch, querying here has a different role -
> ensuring compatibilities between kernel versions.
>
Yes.

> I think it might be too early for that:
>  * it takes quite a long while until patches propagate through to
>    mainline (more than half a year), so that there is the time to
>    come up with a single, well-tested interface;
But when it gets into mainline people should be able to write applications 
that will be forward and backward compatible (as far as possible) with 
various kernel versions.

>  * at this stage it would be better to have documentation (man pages,
>    web pages, sample application code etc.) to allow people to use
>    the interface - few will want to discover the interface by grepping
>    through source code.
>
Sure it would be nice to have applications that use this interface. But in my 
opinion the basic interface is not yet ready to be included in mainline 
applications. It especially lacks features that will allow application 
developers to maintain compatibility.

> DCCP is full of half-finished things. 
That's why I'm trying to finish the qpolicy framework. Without providing 
runtime information it will turn out that application developers will be 
afraid to use new features just because the application won't be able to 
check if given parameter is supported or not.

> I would much prefer to keep this 
> as simple as at all possible, to have time/room to fix the missing parts
> (such as no ECN support) in DCCP.
>
I understand that there might be some missing features in DCCP that are more 
important than yet another informational getsockopt. But these features are 
IMO highly independent and can be developed in parallel.

> As a possible suggestion, I came up with a minimalistic variant of
> querying the interface - only 7 lines, including documentation.
>
> This is attached and it works by exploiting that
>  * policy IDs are just numbers;
>  * so that we could use the highest supported ID instead of an array;
I don't like the "highest supported ID" approach. But if you don't like arrays 
a simple "bool getsockopt" would do, we could just ask the kernel if it 
supports given qpolicy. Like (in pseudocode):
bool supports_prio=getsockopt(sk,DCCP_SOCKOPT_QPOLICY_AVAILABLE,QPOLICY_PRIO);
Would that be ok?

>  * parameters are tied to the individual policy, so that a second
>    query (about which parameters are supported) is not necessary.
>
Can you guarantee that nobody ever will add a parameter? In fact even today I 
can think of two parameters that could be added: the previously discussed 
timeout and my new concept - the identity or category parameter (which is a 
subject for a separate thread).

BTW, the somewhat big code was meant to act as a framework for other features. 
Like getting information about percent of dropped packets in prio qpolicy 
queue.
-- 
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

Powered by blists - more mailing lists