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