Messages in this thread | | | From | Jason Vas Dias <> | Subject | Re: per-chroot clock module ? | Date | Mon, 29 Nov 2010 12:52:36 +0000 |
| |
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
| |