[9fans] maintaining p9p
Hello, seems I really don't understand much presently. The p9p install(1) says: Once the system is built for the first time, it can be maintained and rebuilt using mk(1). To rebuild individual commands or libraries, run mk install and mk clean in the appropriate source directory (see src(1)). I use hg. So from time to time I do 'hg pull -u'. Now, it seems to be always safe to run ./INSTALL from the top directory. This, however, seems to build everything over again, probably unnecessarily. I thought I'd call sth like 'mk install' from the top directory to build only new/changed stuff. However there is no mkfile there. How should I understand the cited? Thanks! Ruda
Re: [9fans] maintaining p9p
2011/1/22 Rudolf Sykora : > Hello, > > seems I really don't understand much presently. > > The p9p install(1) says: > > Once the system is built for the first time, it can be maintained and > rebuilt using mk(1). To rebuild individual commands or libraries, run > mk install and mk clean in the appropriate source directory (see > src(1)). > > > I use hg. So from time to time I do 'hg pull -u'. Now, it seems to be > always safe to run ./INSTALL from the top directory. This, however, > seems to build everything over again, probably unnecessarily. I > thought I'd call sth like 'mk install' from the top directory to build > only new/changed stuff. However there is no mkfile there. How should I > understand the cited? I think the implication it is making is essentially that *you* need to know what you want to rebuild. (Also worth noting that a full rebuild is usually quite fast.) Hope that clarifies things, --dho > Thanks! > Ruda > >
Re: [9fans] maintaining p9p
On Sat, 22 Jan 2011 17:10:11 +0100 Rudolf Sykora wrote: > > I use hg. So from time to time I do 'hg pull -u'. Now, it seems to be > always safe to run ./INSTALL from the top directory. This, however, > seems to build everything over again, probably unnecessarily. I > thought I'd call sth like 'mk install' from the top directory to build > only new/changed stuff. However there is no mkfile there. How should I > understand the cited? cd $PLAN9/src 9 mk all && 9 mk install
[9fans] jtagfs(4) is done
For those of you who showed interest in the jtag, it is finished now (still beta, though). It fully supports acid (and some). You can stop a kernel (directly, via breakpoints or catching interrupts), look at its memory, change it, change its registers... Looking for testers, it is in contrib/paurea/jtag.tgz. G.
Re: [9fans] maintaining p9p
Setting NPROC to a reasonable number with cause mk to build n targets at once. I set NPROC to 8 (the number of threads my cpu has) and p9p rebuilds in less than 5 minutes.
Re: [9fans] maintaining p9p
> cd $PLAN9/src > 9 mk all && 9 mk install I'll try this. Thanks Ruda
Re: [9fans] plan9 go output faults on 9vx with rfork
This started to look like a 32/64 problem and I think it is. If you
trace the cmpswap, at some point we see 1 as a value, just
like somebody added 1 to , and it went to, not 0, as expected,
but a bigger value.
See this code:
long
syssemacquire(uint32 *arg)
{
int block;
long *addr;
Segment *s;
addr = uvalidaddr(arg[0], sizeof(long), 1);
evenaddr(arg[0]);
block = arg[1];
if((s = seg(up, arg[0], 0)) == nil)
error(Ebadarg);
if(*addr < 0)
error(Ebadarg);
return semacquire(s, addr, block);
}
And note how the u32int is actually converted to a pointer to a long,
which is 64 bits. I put a panic in there on sizeof(*addr) !=
sizeof(*arg) and bang! away we go.
So it's a 32/64 bit cleanliness problem. And it's not just for go,
it's for everything.
This is a huge problem as pentium is little-endian and you're going to
end up trashing data. Bad.
I will try to put a fix in now. We just need to be a little cleaner
about realizing that the syscall interface is always 32 bits, even
when 9vx is built as 64 bits. This is pretty much the TOS thing all
over again.
ron
Re: [9fans] plan9 go output faults on 9vx with rfork
> And note how the u32int is actually converted to a pointer to a long, > which is 64 bits. I put a panic in there on sizeof(*addr) != > sizeof(*arg) and bang! away we go. > > So it's a 32/64 bit cleanliness problem. And it's not just for go, > it's for everything. > > This is a huge problem as pentium is little-endian and you're going to > end up trashing data. Bad. > > I will try to put a fix in now. We just need to be a little cleaner > about realizing that the syscall interface is always 32 bits, even > when 9vx is built as 64 bits. This is pretty much the TOS thing all > over again. the plan 9 core needs to religiously use uintptr and not long. long is always wrong for these things. - erik
Re: [9fans] plan9 go output faults on 9vx with rfork
On Sat, Jan 22, 2011 at 6:48 PM, erik quanstrom wrote: > the plan 9 core needs to religiously use uintptr and not long. long > is always wrong for these things. It's a bit messier than that. When 9vx is built as 64-bit, it's a 64-bit kernel supporting 32-bit binaries. uintptr is still a 64-bit entity. There's no way to take a 32-bit reference parameter as used in semacquire and treat it as a pointer to a 64-bit item and have it end well ... What has to happen is the 9vx syscall interfaces need to be scrubbed just a bit more for these types of cases and corrected. Or,simpler, just keep building 32-bit 9vx; that may be the best bet. ron
Re: [9fans] plan9 go output faults on 9vx with rfork
> It's a bit messier than that. When 9vx is built as 64-bit, it's a > 64-bit kernel supporting 32-bit binaries. uintptr is still a 64-bit > entity. There's no way to take a 32-bit reference parameter as used in > semacquire and treat it as a pointer to a 64-bit item and have it end > well ... right. i think the situation confused me. but i don't feel too bad. the linux guys, with their 10s of thousands can't get this right. > What has to happen is the 9vx syscall interfaces need to be scrubbed > just a bit more for these types of cases and corrected. Or,simpler, > just keep building 32-bit 9vx; that may be the best bet. that makes more sense to me. - erik
