Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of jorton@redhat.com designates
 66.187.237.31 as permitted sender)
Date: Thu, 16 Jul 2009 10:35:55 +0100
From: Joe Orton <jorton@redhat.com>
To: dev@apr.apache.org
Subject: Re: svn commit: r794485 - /apr/apr/trunk/configure.in
Message-ID: <20090716093555.GA4093@redhat.com>
Mail-Followup-To: dev@apr.apache.org
References: <20090716013932.D629923888BB@eris.apache.org>
 <1247708572.2811.385.camel@shrek.rexursive.com>
 <20090716082739.GA5017@redhat.com>
 <1247735147.2811.422.camel@shrek.rexursive.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <1247735147.2811.422.camel@shrek.rexursive.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor,
 Berkshire, SL4 1TE, United Kingdom.
  Registered in UK and Wales under Company Registration No. 03798903
  Directors: Michael Cunningham (USA), Brendan Lane (Ireland),
 Matt Parson (USA), Charlie Peters (USA)

On Thu, Jul 16, 2009 at 07:05:46PM +1000, Bojan Smojver wrote:
> On Thu, 2009-07-16 at 09:27 +0100, Joe Orton wrote:
> > In the past I have argued we should never do runtime platform feature 
> > detection, i.e., if accept4() works at build-time, we can presume it 
> > works at run-time.  I think I need to soften that position now; use of
> > a modern userspace on an older kernel seems to be very widespread in
> > Xen hosting sites.  I shipped socket(,SOCK_CLOEXEC) support in neon
> > and got lots of complaints, from users across the spectrum of
> > distributions.
> 
> Shouldn't these people build their runtime using the older kernel then?

The problem is that these Xen hosting sites use a specific guest kernel 
which they have tuned/customised/whatever.  Then they let people run an 
otherwise vanilla Linux distribution on top of that.

> It is bad enough that we need to do "will it really work" gymnastics at
> build time. If we go down the road of runtime checks, we'll soon be
> testing for all kinds of stuff, wasting lots of CPU cycles.

I know, I totally agree.  The only mitigation is that those who waste 
CPU cycles are those who run with mismatched kernel/userspace.  It's the 
added complexity which scares me the most.

Maybe let's just do a release with this code as-is, and see how many 
people complain, and then revisit the decision if necessary.

> PS. This is obviously some kind of Xen bug (i.e. inability to run the
> latest kernel). Shouldn't they be fixing it?

I think this situation arose because of the historical lack of a stable 
hypervisor/guest interface for running paravirt. guests, which did get 
fixed more recently ("VMI"?), but, I'm not really an expert here, to say 
the least.

Regards, Joe