On Thu 26 Apr 2007 at 12:43PM, Rayson Ho wrote:
> On 4/24/07, Dan Price <[EMAIL PROTECTED]> wrote:
> >No, it's not possible to do so.  However, the time zone can be set
> >independently between zones.
> Having a different date/time settings for non-global zones seems to be
> a commonly requested feature...

We've heard it a few times, but not nearly as many times as some other
feature requests-- such as:

        - Zones rooted on NFS servers
        - Patch/Upgrade on Attach
        - GUI/Management API for zones
        - Improved kstats inside of zones
        - Improved monitoring/accounting for zones

And so on.  I realize that there's a fairly interesting use case here--
the "what will happen in a month, or in 2038?" test.  It might be the
case that you could write a shared library interposer that would be
"good enough" for most apps.

We'd be supportive of someone wanting to go investigate this-- it'd
probably make a great project; see below for some thoughts on how
this could be investigated.

> IMO, it should be possible to allow a "time offset" in each non-global
> zone, but gettimeofday() & time() in those zones will need to be
> modified to add the offset into the return value.

And other subsystems like stat(2), utimes(2), timer_settime(3RT)
(maybe), /proc, DTrace, AIO (maybe), exacct, NFS (maybe),
and so on.  To me that's the issue.  That's not to say it is impossible.
One approach might be to prototype this as a brand so as to figure out
where all of the issues are; a Brand would also allow one to trade a
little performance for keeping this out of the the rest of the kernel.
On the other hand, you'd probably have to build a layered filesystem for
/proc unless you wanted to do fairly fancy interposition.

At a minimum I think you'd want to do a walk of:

And most uses of timestruc_t.


Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
zones-discuss mailing list

Reply via email to