[lkml]   [2010]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: per-chroot clock module ?
On Sunday 28 November 2010 11:15:13 you wrote:
> Jason Vas Dias <> wrote:
> > This would allow one to very easily support websites for totally different
> > timezones
> Timezones can be set using environment variables.
> man 8 tzselect
> example:
> $ date
> Sun Nov 28 12:11:39 CET 2010
> $ TZ="America/New_York" date
> Sun Nov 28 06:11:46 EST 2010
Yes, but that's not what I'm trying to do - as I said in previous mail:
"support websites for totally different timezones , where offsets need not be
restricted to legal timezone offsets but could encompass years
I'm not talking about legal locale timezones but of "enabling groups of processes
running in zones of completely different date / time values" without adverse filesystem
"modification time in the future" side-effects - no false modification times would be
stored on disk nor any non-zero offset added to times seen by processses running
outside of a chroot.

More precisely , the new "per_chroot_clock" module will provide :
A built-in module function:
o A very high performance "per_chroot_clock_for_root_inode()" kernel / builtin function will return any associated
real-time clock offset for the root inode of the current process or 0 if not found or the
per_chroot_clock module is not installed. There would also be an 'per_chroot_any_clocks()'
function to return >=1 if the module is installed and there are any successfully chroot-ed into root inodes with
clocks defined, 0 otherwise.
When the "per_chroot_clock" module is installed and there are any per_chroot clocks defined :
o After a successful chroot, all processes running with a root inode of that chroot directory
that issue the "clock_settime" system call will affect only the per-chroot clock offset for their root inode directory.
o A "modify file stat" / "write inode" hook is added that will remove the offset from any inode modification times
written by a process with a root device inode in the set of inodes for which "clock_for_root_inode()"
returns a non-zero value.
o A "read inode" hook is added that will add any non-zero offset returned by "clock_for_root_inode()" when
any stat() returns for a call from a process with such a root inode. Processes which issue stat() from outside
the chroot will not see any offsets in file modification times when they look at files under the chroot .
o time(), gettimofday(), clock_gettime () all get similar hooks so that if the module is installed, the root inode
number of the current process is used to lookup a clock offset to be added to the value returned , and processes
that invoke these calls from within a chroot have that value added, while those outside the chroot see no difference
to the real-time clock time.
o possibly clock_settime() and clock_gettime() could accept one single new "illegal clock" clock_t value that means
"ROOT_INODE_CLOCK" ; all processes could then inspect their per-root inode clock, regardless of whether
they have a chroot-ed root inode or not, and if there is none, the real-time clock is used.
o a /proc filesystem interface ( eg /proc/$pid/per_chroot_clock ) will read / write the per_chroot root inode clock for
the process - setting to 0 removes the offset.

I would find the above useful , and have already begun investigation & development on it -
I still don't know if anyone else would or if there is anything that does something like it out there .

All the best,

 \ /
  Last update: 2010-11-29 13:55    [W:0.034 / U:1.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site