[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-API] stdext compilation on macos x

  • To: 'Anil Madhavapeddy' <anil@xxxxxxxxxx>, "xen-api@xxxxxxxxxxxxxxxxxxx" <xen-api@xxxxxxxxxxxxxxxxxxx>
  • From: Dave Scott <Dave.Scott@xxxxxxxxxxxxx>
  • Date: Wed, 4 Nov 2009 20:44:50 +0000
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc:
  • Delivery-date: Wed, 04 Nov 2009 12:44:52 -0800
  • List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
  • Thread-index: AcpdhRWHbI3YyLWvRuq8Sb/LeO/BigACHX8g
  • Thread-topic: [Xen-API] stdext compilation on macos x

Hi Anil,

> - statfs(3) is quite different on Darwin and has different interfaces 
> depending on whether 64-bit inodes are defined or not.  It would easier 
> to skip it entirely.  I noticed that there are no consumers of the 
> Unixext.statfs binding in xen-api.hg; do other repos use it or can it be GCed?

I think it can be GCed. I bet it was originally added back when storage
backends were built-in to xapi and we wanted to say something about free/used 

> - What's the story with the signal state dumping to a /tmp file in  
> sigutil_stub.c ; was that from "historical" XAPI crashes in XenRT?   
> That's also importable due to different siginfo_t and it would be easier if 
> removed if the debugging is no longer needed.

I had to go dig around in our issue tracker to figure this one out. Here's what
I found:

Richard Sharp wrote in Jul/2007:
> Believed fix by passing syslog a single "%s" + argument. (SegFaults were 
> being 
> caused by a python traceback containing "%s"s which we passed to syslog via 
> our syslog bindings. Syslog interpreted this as a fmt string and then started 
> dereferencing beyond the end of its stack... causing xapi to die with 
> segfault)

Given that (i) this is the last segfault I can remember; (ii) it was debugged
by catching the crash in gdb anyway (syslog complete with dodgy fmt string was
on the stack); and (iii) this stuff is switched off by default anyway I think
we can GC this too. We can always put it back if we think we need it for some

> - I notice a comment in uuid/ which uses /dev/urandom instead of /dev/ random 
> since its too slow.  Is there anything wrong with replacing this with the 
> Random module (with a Random.self_init it should be random and fast enough).

Hm, before doing that I'd like to check that we're not using a bunch of UUIDs
somewhere where we really need a random source (rather than a pseudorandom one).
In principle I think this is fine.


xen-api mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.