[9fans] /sys/src/9/port/devsd.c

[9fans] /sys/src/9/port/devsd.c

[Lucio De Re]

Last changed 12 December, reports

	8c -FVw -I. ../port/devsd.c
	../port/devsd.c:1007 not a function
	../port/devsd.c:1007 syntax error, last name: Devport

when trying to

	mk 'CONF=pcdisk' 9pcdisk.gz

or

	mk 'CONF=pc' 9pc.gz

Hm, I also get

	8c -FVw -I. ../port/proc.c
	../port/proc.c:156 not a member of struct/union: readied
	../port/proc.c:157 not a member of struct/union: schedticks
	../port/proc.c:190 not a member of struct/union: schedticks
	../port/proc.c:191 not a member of struct/union: readied
	../port/proc.c:208 not a member of struct/union: readied
	../port/proc.c:411 not a member of struct/union: readied
	../port/proc.c:495 not a member of struct/union: readied

which makes me suspicious that I may have a dated ../port.

Replica/pull does not have a "check" mode that would report if any
file is out of date, has it?  Mind you, it's as fast just to reload
everything, isn't it?

++L

Re: [9fans] /sys/src/9/port/devsd.c

[andrey mirtchovski]

On Fri, 2 Jan 2004, Lucio De Re wrote:

> Replica/pull does not have a "check" mode that would report if any
> file is out of date, has it?  Mind you, it's as fast just to reload
> everything, isn't it?

try 'replica/pull -vn'

andrey

Re: [9fans] /sys/src/9/port/devsd.c

[Russ Cox]

> which makes me suspicious that I may have a dated ../port.
>
> Replica/pull does not have a "check" mode that would report if any
> file is out of date, has it?  Mind you, it's as fast just to reload
> everything, isn't it?

9fs sources
d=/n/sources/plan9
diff /sys/src/9/port $d/sys/src/9/port

Re: [9fans] /sys/src/9/port/devsd.c

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 52 bytes --]

They're in pc/dat.h on sources.  You're out of date.

[-- Attachment #2: Type: message/rfc822, Size: 3093 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans mailing list <9fans@cse.psu.edu>
Subject: [9fans] /sys/src/9/port/devsd.c
Date: Fri, 2 Jan 2004 18:50:42 +0200
Message-ID: <20040102185042.B25949@cackle.proxima.alt.za>

Last changed 12 December, reports

	8c -FVw -I. ../port/devsd.c
	../port/devsd.c:1007 not a function
	../port/devsd.c:1007 syntax error, last name: Devport

when trying to

	mk 'CONF=pcdisk' 9pcdisk.gz

or

	mk 'CONF=pc' 9pc.gz

Hm, I also get

	8c -FVw -I. ../port/proc.c
	../port/proc.c:156 not a member of struct/union: readied
	../port/proc.c:157 not a member of struct/union: schedticks
	../port/proc.c:190 not a member of struct/union: schedticks
	../port/proc.c:191 not a member of struct/union: readied
	../port/proc.c:208 not a member of struct/union: readied
	../port/proc.c:411 not a member of struct/union: readied
	../port/proc.c:495 not a member of struct/union: readied

which makes me suspicious that I may have a dated ../port.

Replica/pull does not have a "check" mode that would report if any
file is out of date, has it?  Mind you, it's as fast just to reload
everything, isn't it?

++L

Re: [9fans] /sys/src/9/port/devsd.c

[Lucio De Re]

On Fri, Jan 02, 2004 at 04:35:44PM -0500, David Presotto wrote:
>
> They're in pc/dat.h on sources.  You're out of date.

Yep, I have what I hope is a well-maintained copy of sources and
I was quite successful in compiling the kernel with that set.  Of
course, it is now no longer pristine, is it?

It concerns me that there is no auditing mechanism, where one really
needs one.  My problem is compounded by the line speed, which is
9600bps out of my office (it gets better further along, but I can't
always exploit the remote proxy services).  You an imagine that a
200Meg check of consistency could take a long time.

I'm thinking along the lines of setting up a log/db (I haven't
found the need to figure out which does what, I guess I need to do
that now) of locally modified files so they can be tucked away
during a full (-s) update, then restored with a separate replica/pull.
This would enable me (notwithstanding my speed restrictions, I
could use a CD image, say) to perform a clean re-install (how will
that affect the dump, Fossil/Venti or traditional?) in a live
environment.

The other option I have thought a little about is not only to have
a pristine copy of sources as I do presently, but also to rebuild
a parallel copy from the CD and run consistency checks and audits
across these.

I mention these so anyone who's had similar thinking can make
suggestions, I'm still trying to figure out what replication should
really be capable of.  Hm, I wonder how much one can learn from
comparing log/db files with sourcesdump (my CVS roots are showing,
I guess)?  Could one not add a release file to each update so that
it is easier to establish which dump date to consult?  Annotating
each update may be asking too much, that I concede.

++L