lkml.org 
[lkml]   [2010]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: per-chroot clock module ?
Date
On Sunday 28 November 2010 11:15:13 you wrote:
> Jason Vas Dias <jason.vas.dias@gmail.com> 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,
Jason









\
 
 \ /
  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