From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Post Subject: Re: [PATCH] 1/1 Better expose xenstore limits Date: Thu, 30 Apr 2009 02:18:12 +0800 Message-ID: <1241029092.5394.178.camel@localhost.localdomain> References: Reply-To: echo@echoreply.us Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Wed, 2009-04-29 at 19:01 +0100, Keir Fraser wrote: > On 29/04/2009 17:43, "Tim Post" wrote: > > > Since xs.h already includes xs_wire, this patch duplicates those limits > > as XS_PAYLOAD_MAX, XS_ABS_PATH_MAX and XS_REL_PATH_MAX. Moving these > > would be a pain, but they really need to be advertised. > > > > Such limits should be obvious in the headers that people actually use > > outside of the kernel, saving them from wondering what went wrong. > > > > Added comments direct people to xs_wire.h , in case those limits change. > > In terms of documentation, docs/misc/xenstore.txt already does a fine job. Provided such docs are actually packaged.. many install Xen (and associated DSO's and headers) via yum, apt-get, etc. > And I think a xen/public/... header is the right place for the limits, since > it is a general documented protocol-level constraint, rather than a > constraint of the particular client library (which is the scope of xs.h > itself). Yes, it is the right place for the limits, the patch does not suggest moving them, only echoing them in the header that user space apps will include. Someone using xs.h is going to be entirely unaware of said limits. Xenstore internals will relay an appropriate errno if the limits are exceeded, but I think many people will not know such limits exist. Xenwire is used when developing drivers.. not user space applications. Why not assert the limits in both at the cost of bothering the preprocessor three times? Cheers, --Tim