Re: [MirageOS-devel] Timestamp representation and CLOCK

[Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx>]

Le vendredi, 10 juillet 2015 Ã 10:50, Richard Mortier a Ãcrit :
> Not sure why it would necessarily lead to disaster

Well that seems quite evident to me:

1) We already saw enough â some still waiting to happen â clock rollovers in 
the short history of computing. Time bugs can be really disastrous, you don't 
want these expired certificates to no longer be.

2) Programs have to be able to represent point in times before and after they 
were started from anyways. For this you want to give them ample range and very 
well defined boundaries (which is what ptime does). It's better if the OS gives 
you a single representation you don't have to fiddle with in order to be able 
to actually work with it. Bug occurence minimization.

3) Letting each program have their time representation is a code reader 
nightmare and what is likely to happen is that those timestamps will anyway end 
up in a library that supports them in a generic fashion using a representation 
that needs to accommodate them all. At this point you gained absolutely nothing 
and this idea of letting the unikernel choose the range and precision of its 
timestamps only introduced noise, confusion and new potential sources of bugs 
in the system.

For these reasons it's better to actually make a single decision about how this 
should be represented to err on the safe side by *design*. It's interesting to 
find out whether we can find a good compact encoding, but focusing to much on 
the actual memory footprint of the the representation focuses on the wrong 
problem in my opinion.

Best,

Daniel

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel