From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <599f06db0603300652t25cf9075i817ea6b2a337710a@mail.gmail.com> Date: Thu, 30 Mar 2006 16:52:31 +0200 From: "Gorka guardiola" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Re: patch/list sorry/proc-mtime In-Reply-To: <71765ba5c9538e6b52296854a71ea405@swtch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <509071940603300542v4d79c76pa797c8d73a3cfd5d@mail.gmail.com> <71765ba5c9538e6b52296854a71ea405@swtch.com> Topicbox-Message-UUID: 267cd508-ead1-11e9-9d60-3106f5b1d025 On 3/30/06, Russ Cox 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