apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: svn commit: r794485 - /apr/apr/trunk/configure.in
Date Thu, 16 Jul 2009 09:35:55 GMT
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

View raw message