9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Gorka guardiola" <paurea@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] Re: patch/list sorry/proc-mtime
Date: Thu, 30 Mar 2006 16:52:31 +0200	[thread overview]
Message-ID: <599f06db0603300652t25cf9075i817ea6b2a337710a@mail.gmail.com> (raw)
In-Reply-To: <71765ba5c9538e6b52296854a71ea405@swtch.com>

On 3/30/06, Russ Cox <rsc@swtch.com> wrote:
>
> it duplicates information already in the status file,
> and it would be the *only* kernel device file in the system

The metadata of each device is not giving any
information if they all have the same mtime.

> that didn't use kerndate as the mtime.  when did the
> plan 9 approach become "there's more than one way to do it"?
>
> ls -t /proc is of course indistinguishable from ls | sort -n.
>
> ls -lt /proc just gives you some dates in sorted order.
> it's useless unless you somehow have the pid->process info
> mapping stored in your head.
>
> if you want to change ps(1) to *display* the start time
> of a process, i think that could be genuinely useful.
> putting an extra copy on the directory mtime is not.
>
> russ

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. 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?.

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

- curiosity sKilled the cat


  reply	other threads:[~2006-03-30 14:52 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 [this message]
2006-03-30 16:22             ` uriel
2006-03-30 16:50               ` matt
2006-03-30 17:19                 ` Russ Cox
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=599f06db0603300652t25cf9075i817ea6b2a337710a@mail.gmail.com \
    --to=paurea@gmail.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).