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

[Dave Scott <Dave.Scott@xxxxxxxxxxxxx>]

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 
space.

> - 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
reason.

> - 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.

Cheers,
Dave

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api