9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Russ Cox" <rsc@swtch.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: patch/list sorry/proc-mtime
Date: Thu, 30 Mar 2006 12:19:14 -0500	[thread overview]
Message-ID: <22bde5614000d885106987413c69bb88@swtch.com> (raw)
In-Reply-To: <442C0C65.1060607@proweb.co.uk>

>  > It's not useless, and it's the same as essentially every other
>  > device file in the system.
>
> Then perhaps they convey the wrong information.
> Note the "essentially every other". Not "every other".
>
> That means you can't take a devices mtime to be kerndate, which means
> making *some* of them have kerndate presents duplicate data that is also
> untrustworthy and therefore meaningless and arbitrary.

I hedged because I wasn't 100% sure and didn't want to
look through all the drivers.  But now I have.  It's really
"every other".  There are no kernel-provided devices that
fiddle with mtime.  Not one.

> If we are assigning arbitrary pieces of data as the mtime then why not
> the start time of when the process was created and therefore the
> creation date of /proc/pid
>
> IMHO the creation time of /proc should be the boot time of the kernel.
> Kerndate should be somewhere but it is it really relevant to the current
> running state of the system ?

Maybe in someone else's humble opinion the modification time
(there is no creation time in Plan 9) of /proc should be the time of
the last call to fork or exits, i.e. the last time the directory actually
changed.  There isn't an obvious value here.

There are lots of good arguments that various information relevant
to the system should be available (when did the system boot?
when was the kernel built?  what kernel is running?  where did it
get loaded from?  etc.).  Overloading mtime for all these purposes
is misguided, as none of them are actually modification times.

An arbitrary value got chosen for the mtime on kernel devices.
It's reasonable enough and I don't see an argument to change it.
If the value was something else, I'd feel the same way: I wouldn't go
changing it to kerndate.  Same reason I didn't change NBROKEN.
If it were 8 already, I wouldn't be arguing that it should be 4.
But given that it there isn't one right answer and that the current
definitions have sufficed for the last 15+ years, I don't see why
we should change it today.

Enough already.
Russ



  reply	other threads:[~2006-03-30 17:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <dfb566242e58a31d6d4f97b379b4f487@plan9.bell-labs.com>
2006-03-29 23:07 ` uriel
2006-03-29 23:34   ` Russ Cox
2006-03-30  0:13   ` quanstro
2006-03-29 23:34     ` Federico G. Benavento
2006-03-30  8:31   ` Charles Forsyth
2006-03-30 10:09     ` lucio
2006-03-30 11:33     ` Gabriel Diaz
2006-03-30 13:42       ` Anthony Sorace
2006-03-30 14:17         ` Russ Cox
2006-03-30 14:52           ` Gorka guardiola
2006-03-30 16:22             ` uriel
2006-03-30 16:50               ` matt
2006-03-30 17:19                 ` Russ Cox [this message]
2006-03-31 10:52                   ` matt
2006-03-30 17:24         ` rog
2006-03-30 17:32           ` uriel
2006-03-30 16:37 Fco. J. Ballesteros

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=22bde5614000d885106987413c69bb88@swtch.com \
    --to=rsc@swtch.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).