Re: [9fans] Re: patch/list sorry/proc-mtime

[uriel@cat-v.org]

> I am not sure about this. Static devices having all the
> same mtime (kerndate) makes sense to me. Dynamic
> devices in which files and directories appear and disappear
> as draw or proc not having the mtime set as normal
> dir/files doesnt.

In all fairness at least the semantics for files inside each proc
directory would not match directly what one would expect from
static file systems (eg., content can change, but mtime would always
be the creation time of the proc.) Maybe setting only the mtime of the
dirs would removes any ambiguity.

Certainly having dirs with a mtime that clearly predates their creation
is far from ideal.

> It may be done for simplicity,
> but it breaks what one would expect. The information
> is not duplicated as far as I understand. The info on the
> mtime would be when the process started, but the
> info inside status is how much time it has consumed
> isnt it?.

The information in status also includes real elapsed time in ms, that
can be used to calculate when the process started as russ pointed out.
Still this is tedious and akward and the mtime of the proc dirs seems
like a natural place to present this often useful information.

Adding the calculation to ps is another possibility, but IMHO it would
unnecessarily clutter the output, probably add an extra option and
require more code while ls -lt /proc works just fine with the mtime
approach.

In the end everything is matter of convenience and taste, but this
criticism comming from the person that instigated the tar -z
abomination is harder to take seriously.

> All this said, I am not coding any of this, so I have voice but not vote...

FYI here is the change to set the mtime, a single line of code:
+  dp->mtime = seconds() - TK2MS(MACHP(0)->ticks - p->time[TReal]) / 1000;

uriel