Re: [9fans] Init hangs
On Mon, 2008-09-22 at 13:46 +0200, Rodolfo kix García wrote: Try to disconect the CD-Rom in vmware, and boot plan9 That was my thought too. While on the subject, anybody tried to install on a Free ESXi server? My attempts fall apart as early as 9load. The IDE line is printed, then nothing happens. -- Lucio De Re (Off site) Ph: +27 83 251 5824 Fx: +27 58 653 1435
Re: [9fans] sdiahci.c on sources broken?
On Thu, 2008-09-25 at 21:58 +0200, [EMAIL PROTECTED] wrote: so it seems the version on sources is wrong, and eriks version does the right thing. (calculating the time the operation takes (current time - time of request start)) can somebody confirm this? I can vouch for the fact that Erik knows what he's doing, specially as regards disk operations: he's demonstrated that to me on more than one occasion. I can also raise the issue that he has trouble getting changes approved through the patch system, probably because his fixes are hard to validate and/or bring in line with the P9 philosophy. Bottom line, trust him! And when it all works, let the community know. -- Lucio De Re (Off site) Ph: +27 83 251 5824 Fx: +27 58 653 1435
Re: [9fans] request for testers of next beta release of tvx
On Tue, Jun 08, 2010 at 09:10:33PM -0700, ron minnich wrote: On Tue, Jun 8, 2010 at 9:39 AM, Lucio De Re lu...@proxima.alt.za wrote: Different namespaces. I think we'll live... That's the point of private name spaces right? I doubt a linux distro is that much concerned with anything related to windows. And I especially doubt that Windows will concern itself with a Linux distro. My point exactly. ++L
Re: [9fans] portability question
On Wed, Jun 16, 2010 at 11:11:09AM +0200, hugo rivera wrote: printf(%lX\n, l); Would you try %luX? It may work better? ++L
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
On Tue, Jun 29, 2010 at 04:00:09PM -0700, Russ Cox wrote: i think people get too hung up on trying to make the port back perfect. just make it work. then make it better. But it's the toolchain I'm after. I like Go a lot, but I feel that a viable toolchain that produces ELF files for Linux is also a worthy objective. And getting the toolchain to produce Plan 9 executable code has already been done, albeit unchecked and about to be lost or forgotten on a server a long way from here. Still, I'd be thrilled to be able to cut my teeth on Go on Plan 9 rather than UBUNTU, so don't let me discourage anyone. I just want 9fans to know that I'm willing to do the slog work to keep the toolchains in sync and they shouldn't go out of their way to make my life unnecessarily difficult :-) ++L
Re: [9fans] sharing the ndb(6) database
On Mon, Sep 06, 2010 at 11:45:01PM -0700, Akshat Kumar wrote: I'm using Google mail servers to send mail - this shouldn't be in the RBL. Damn right. The criterion for dumping IP addresses into my private RBL is that an attempt was made to send mail to a local, unregistered address. In this case, I have: /var/tmp/iptrash.err:Registered: o2IFSlFZ009429: - 209.85.160.48 for from=saxxonenterprisegr...@gmail.com, - cars...@myrtle.proxima.alt.za... which is certainly unsolicited as Carsten hasn't been around for years, and Myrtle has been decommissioned almost equally long ago. Of course, I have corrected the problem, but I wonder if google should be alerted. Can I prevail upon you to confirm that the problem is cleared? Lucio.
Re: [9fans] sharing the ndb(6) database
On Tue, Sep 07, 2010 at 09:09:11AM +0200, Lucio De Re wrote: On Mon, Sep 06, 2010 at 11:45:01PM -0700, Akshat Kumar wrote: I'm using Google mail servers to send mail - this shouldn't be in the RBL. Damn right. The criterion for dumping IP addresses into my private RBL is that an attempt was made to send mail to a local, unregistered address. Oops. I ought to have redirected this to private correspondence. Apologies. ++L
[9fans] 9VX failure
Not much more than init: starting /bin/rc Segmentation fault from a freshly compiled 9vx or the 9vx.Linux contained in the HG repository on bitbucket.org. I was hoping to try 9vx.tgz from swtch.com which is not 9vx*.bz2, but that does not behave any differently. The platform Linux fangle 2.6.32-24-generic #42-Ubuntu SMP Fri Aug 20 14:24:04 UTC 2010 i686 GNU/Linux Ubuntu Lucid Lynx on an HP Laptop. ++L
Re: [9fans] 9VX failure
On Sat, Sep 11, 2010 at 09:02:36AM +0200, Lucio De Re wrote: I was hoping to try 9vx.tgz from swtch.com which is not 9vx*.bz2, but that does not behave any differently. s/not 9/now 9/ ++L
Re: [9fans] 9VX failure
On Sat, Sep 11, 2010 at 09:34:20AM -0700, ron minnich wrote: I am pretty sure Charle's patch will fix this problem Is that included in rminnich/vx32, where default compilation fails with a missing pcap.h? What should I be looking for? ++L
Re: [9fans] 9VX failure
On Sat, Sep 11, 2010 at 10:24:05AM -0700, ron minnich wrote: Is that included in rminnich/vx32, where default compilation fails with a missing pcap.h? the pcap.h thing is unrelated and I think I'm going to change it so that it builds default with no pcap support, since I'm not the only person seeing this build error. no, I have to get his patch included. I had a question in to his customer support people about the patch first before i went with the patch :-) That means that there are two patches required here: Charles' adjustment (why have I not seen it, I wonder) and the pcap.h thing. Can you post them here in the interim? I'm not sure I want to know why pcap.h is being included and not found... ++L
[9fans] 9vx/vx32 - Out of ignorance
Besides the issue of (not) understanding TAP and so having no access to networking, what struck me while experimenting with a very remarkable 9vx installation (9vx is impressive, not my installation thereof :-) was that if you start it as root, you retain root credentials within the sandbox, irrespective of user selection at start up of 9vx. Given that 9vx seems pretty comfortable as an arbitrary user, would it make sense for me to find a location where a switch to the specified user can take place? Admittedly, that does not correspond to the Plan 9 model where Eve has unrestricted access to devices, but in a hosted environment that can be excused (and documented). My thinking is that 9vx could start up as root to install the TAP device (nothing else so far has alerted me to a need for root permissions), then switch user to the selected one (if it exists, nobody may be needed if there is no equivalent in the host repertoire) once setting up is complete. Back to the question, then: is there any reason why I should not be looking into doing this? Another thought that struck me, in passing, is whether the TAP device should be set up in vx32 rather than in 9vx. I am not familiar with the boundary between these, so the question may seem silly to others, to me the logic seems a bit strained right now. And if anybody can arrange a short lesson on using networking under 9vx, that would also be greatly appreciated. ++L
Re: [9fans] 9vx/vx32 - Out of ignorance
On Sun, Sep 12, 2010 at 07:30:05PM +0200, yy wrote: 2010/9/12 Lucio De Re lu...@proxima.alt.za: My thinking is that 9vx could start up as root [ ... ] The advantage of the tap device is precisely that it does not need root permissions. You need those permissions to manage the devices, but that will be normally done by tunctl or openvpn. Those are the programs that have to worry about being run as root, not 9vx. In other words: you need to be root to create the tap device, but not to use it. I eventually got that far :-) I do appreciate confirmation of my understanding and I now understand the underlying processes considerably better. And if anybody can arrange a short lesson on using networking under 9vx, that would also be greatly appreciated. Inside 9vx, networking with tap devices is not different to using physical devices. At the host system level, it works as it does in qemu (there could be more bugs though). There are many qemu tutorials with sample scripts and better explanations than what I could give. I'll check on qemu, I haven't tried it with any success (or real effort, for that matter) in the past, but then I also had even less understanding than I have now. The particular configuration I'm using is documented at: http://wiki.archlinux.org/index.php/QEMU#Tap_Networking_with_QEMU Based on the qemu-ifup/down scripts described there I wrote a 9vx-tap script you can find at: http://bitbucket.org/yiyus/vx32/src/tip/src/9vx/9vx-tap Probably disecting that script is the best way to understand how the bridge, the tap devices and 9vx play together. It's very, very helpful. I would, and almost certainly will, have split the tunnel and openvpn portions into two scripts (a selector of some type might be good enough, but isn't easily justified), because I'm sure that they don't overlap quite the way the present shape of the script suggests. I found it after posting my request, I still haven't got everything working to my satisfaction, but I think the reference to qemu will help. There are still questions unanswered: (1) would switching userid be useful and practical, irrespective of the actual need for it? and (2) would it make sense to migrate the virtual network devices to vx32? I'm quite happy to entertain opinions, that's all I have to work with right now, it takes me a long time to read and understand source code :-( I know that Ron has already replied to the first of these questions, I'm hoping that those who made the original decisions will contribute their rationales as well. ++L PS: and thanks to all those who have contributed to such a superb toolkit.
Re: [9fans] 9vx/vx32 - Out of ignorance
On Sun, Sep 12, 2010 at 12:27:07PM -0700, Bakul Shah wrote: On a mac you don't need root perms to open a tap device. This is sorted out to my satisfaction, thank you. Here you have two choices: I think I lack some of the terminology to get my mind around all this, but some experimenting will definitely help me figure it out. And 9vx is very helpful in being robust and quick. Just to explain my problem, I can run 9vx as a terminal to each of two cpu/everything servers, but I can't (yet) attach the other fileserver when attached to either of them (they are configured very similarly). Somehow, in all the information provided so far I'm sure there is enough detail for me to make the final step, I just have to study what I have a little longer. So, thanks everyone. ++L
[9fans] DYNDNS - re-invent the wheel?
I don't remember anybody mentioning it, is there a Plan 9 tool to submit a dynamic DNS request to a DNS server like BIND? I use the feature in a very limited fashion, but I don't want to re-invent something that has already been done. ++L
Re: [9fans] Fifth Edition
On Tue, Oct 19, 2010 at 10:02:22AM +, Mark Tuson wrote: Steve, would you be willing to share copies of the demo discs? Which architecture do they use? I just want to play with something ancient as well as modern, then I'll feel like I have a better feel for the system. I can't imagine any logical reason why this should be submitted as a public message. ++L
Re: [9fans] sheevaplug port available
You might want to look at /tmp, you may not have a writable one from the login. Executing ramfs normally takes care of that issue. I saw the ratrace.c error this early morning, but it seems to have been transient. I guess you ought to try a second time, by then somebody more savvy than me might be awake to guide you. ++L
[9fans] lock diagnostics on Fossil server
I keep getting errors in this fashion (I'm afraid I have no serial console, so this is manually copied stuff): lock 0xf045c390 loop key 0xdeaddead pc 0xf017728a held by pc 0xf017728a proc 100 117: timesync pc f01ef88c dbgpc 916f Open (Running) ut 22 st 173 bss 1b000 qpc f01c733d nl 0 nd 0 lpc f0100f6e pri 19 100: listen pc f0100583 dbgpc 4a6a Open (Ready) ut 165 st 1094 bss 29000 qpc f01e6bac nl 1 nd 0 lpc f01e2cb4 pri 10 The report is much less frequent now, it occurred very frequently when I had a couple of CPU sessions running on it. The most obvious trigger seems to have been exportfs, I eventually turned off the stats report I had running from the workstation and since then I have had a single report. While stats was running, reports seemed to coincide with full load as reported by stats. I've seen #I0tcpack appear in earlier reports and etherread4 beside the more frequent exportfs. Any idea what IO ought to be looking out for? I have recompiled the 9pccpuf kernel from up to date sources (as up to date as replica can make them, I was tempted to make local copies of /sys/src/9, but then I thought I'd have to make sure the libaries are up to date too, and that was going to be a bit of a mission. I checked the libraries, though, and the sizes and dates all seem to correspond with sources so I can only presume there's a gremlin somewhere. ++L PS: There's a marginal chance that dns is involved. My Internet connectivity isn't very robust and I note that dns gets pretty overwhelmed when things aren't good. It's hard to pinpoint the exact circumstances: I don't have an active console that I can observe all the time for unexpected reports.
Re: [9fans] lock diagnostics on Fossil server
On Mon, Oct 25, 2010 at 09:20:51AM -0400, erik quanstrom wrote: sounds familiar. this patch needs to be applied to the kernel: /n/sources/plan9//sys/src/9/port/chan.c:1012,1018 - chan.c:1012,1020 /* * mh-mount-to == c, so start at mh-mount-next */ + f = nil; rlock(mh-lock); + if(mh-mount) for(f = mh-mount-next; f; f = f-next) if((wq = ewalk(f-to, nil, names+nhave, ntry)) != nil) break; please apply. if the problem persists after the fix, use acid to print the source of the pcs and qpcs of the procs involved and send that offline. Will do. I was looking for that patch, you have posted it to 9fans before. Somehow, a quick search did not reveal what I was hoping to find. I'll come back with some results soon. ++L
Re: [9fans] lock diagnostics on Fossil server
On Tue, Oct 26, 2010 at 08:44:37AM -0400, erik quanstrom wrote: On Mon Oct 25 22:03:53 EDT 2010, cinap_len...@gmx.de wrote: hm... wouldnt it just crash if mh-mount is nil? perhaps you are reading the diff backwards? it used to crash when mh-mount was nil. leading to a lock loop. i added the test to see that mh-mount != nil after the rlock on mh-lock is acquired. otherwise, there is a race with unmount which can make mh-mount nil while we're running. I was hoping you'd follow up on that, I needed a seed message and my mailbox has recently overflowed :-( I'm curious what you call crash in this case and I think Cinap is too. Basically, exactly what happens in the situation when a nil pointer is dereferenced in the kernel? How does the kernel survive and slip into a locked situation? Yes, yes, I know I could read the sources, but that's a skill I'm a little short on. our newer faster processors with more cores were making this event likely enough that a few receipies would crash the machine within 5 minutes. I really appreciate the fix, it certainly had the desired effect. ++L
Re: [9fans] lock diagnostics on Fossil server
On Tue, Oct 26, 2010 at 07:28:57AM -0700, Russ Cox wrote: Like Lucio and Cinap, I am skeptical that this is the fix. It's a real bug and a correct fix, as we've discussed before, but if the kernel loses this race I believe it will crash dereferencing nil. Lucio showed a kernel that was very much still running. And a very busy one, at that, because while I had stats(1) running, it showed load at max. I may not remember correctly, but I think there lots of context switches as well, but load was saturating. I can re-create the problem if anybody wants me to help diagnose it. ++L
Re: [9fans] kw audio -- /dev/audio and friends
On Wed, Oct 27, 2010 at 08:30:29AM -0400, Tristan Plumb wrote: i am not offering to change the interface, but to implement a simpler third interface (as usbaudio implements volume). poor diction on my part. No one is going to reject your efforts, although it may be harder to get them accepted into the distribution. But if you can make the results backwards compatible, one assumes there will be others who will make good use of them. But if the encouragement you seek is, as is often the case around here, more a request for approval, _that_ is seldom granted here. Also, actual contributions from the audience are rare, specially positive ones. Don't look for such and go ahead and code, that is what gets you noddy points :-) If you have a specific question, this is a great place to get an answer, not a great place to give shape to vague ideas. I sincerely hope the above can be construed as encouragement, it is certainly intended as such. ++L
Re: [9fans] crashing 9vx
On Thu, Oct 28, 2010 at 04:00:32PM +0200, yy wrote: So, if you are using the 9vx version at http://bitbucket.org/yiyus/vx32/ (or ron's version, which is almost the same) and you have a reproducible way to crash it, could you please fill an issue in bitbucket or send me an email? Thanks. I only use 9vx as proof of concept and I have only two reportable issues: I can't get cpu to work where drawterm seems to succeed and on one occasion I used DEL to terminate a task and the whole of 9vx shut down. The latter is a little scary, but I have been very reluctant to test it :-) The cpu doesn't succeed seems to mean that I can't persuade it to use the target host as auth server. I could just be showing my ignorance and/or stupidity. ++L
Re: [9fans] A little more ado about async Tclunk
On Fri, Oct 29, 2010 at 02:12:11PM +0100, roger peppe wrote: so this trick is unsafe in general, but might be ok sometimes. So is the answer to add semantics to Topen or add a Treopen that obviates the Tclunk? ++L
Re: [9fans] Plan9 development
On Thu, Nov 04, 2010 at 09:36:11AM +, Admiral Fukov wrote: I'm looking at http://plan9.bell-labs.com/sources/plan9/sys/src/ and I noticed that most of the distribution hasn't been updated in years. Is the development of plan 9 abandoned? Why fix what's perfect? ;-) ++L
Re: [9fans] Plan9 development
On Fri, Nov 05, 2010 at 02:50:22PM +1100, Bruce Ellis wrote: mash has a make builtin. very brief, as all the shell type stuff in mk goes away.. I seem to remember that the mash source was lost? ++L
Re: [9fans] Passing a file descriptor between processes
On Fri, Nov 05, 2010 at 12:29:46PM +0200, Kirill A. Shutemov wrote: One of the ugliest interface in Unix is passing a file descriptor between processes [1]. Does Plan9 provide any mechanism for it? You can pass fds in channels between threads, but for processes you should look at #s for guidance. ++L
Re: [9fans] Plan9 development
Dan makes a good point and I agree entirely with his sentiments. But I do have a qualm: the Plan 9 designers managed to simplify cross-compilation to a single underlying (OS) platform, but failed (in a suprisingly ugly way) to cater for different target object formats, even though there were efforts to do so. In my opinion - and this is all I hold against Plan 9 - by shoehorning various target object formats in the linker/loader as options, they spoiled the consistency of the system. I have no doubt at all that this was an afterthought or at any rate an attempt to make the most of a situation they could not have control over, but I think that the problem ought to have been given more attention and a better solution sought. Of course, I can plead ignorance and stupidity and admit that I have no idea how I would address the same problem, but I'd like to raise it, because I think in a forum like this it may well stimulate the type of productive discussion that leads to a better mouse trap. To put the problem into perspective, think of Go: the developers have added more shoehorning to target ELF and possibly other object models; I'm sure that, had they had space to do it, they would have found it more fruitful to distil that portion of the development system into a separate or at least better structure. Having investigated this and painted myself into a corner, I'm curious to hear what others think of the issue. Specially those, like Russ, who were involved in the initial decisions regarding Go. Looking at the outcome, I can't help but think that the Plan 9 toolchain is infinitely superior to its current competitors. And I'd also like to point out that any shortcomings it may have regarding implementation of C99 can almost certainly be addressed within the ability of a single, no doubt gifted, but not infinitely so, individual. ++L
Re: [9fans] That deadlock, again
On Tue, Nov 16, 2010 at 06:28:07AM +0100, cinap_len...@gmx.de wrote: if your kernel image is uncompressed and is unstriped, you can just load it with acid: acid /386/9pc if you build it yourself, then there should be such a kernel in /sys/src/9/pc OK, will try this evening, I specifically left the machines on to do so, I'm very keen to help put this issue to rest. And to get to know the kernel more initmately. Pity Nemo isn't updating his commentary. ++L
Re: [9fans] That deadlock, again
Well, here is an acid dump, I'll inspect it in detail, but I'm hoping
someone will beat me to it (not hard at all, I have to confess):
rumble# acid /sys/src/9/pc/9pccpuf
/sys/src/9/pc/9pccpuf:386 plan 9 boot image
/sys/lib/acid/port
/sys/lib/acid/386
[ ... ]
This bit looks suspicious to me, but I'm really not an authority and I
may easily be missing something:
acid: src(0xf0148c8a)
/sys/src/9/ip/tcp.c:2096
2091 if(waserror()){
2092 qunlock(s);
2093 nexterror();
2094 }
2095 qlock(s);
2096 qunlock(tcp);
2097
2098 /* fix up window */
2099 seg.wnd = tcb-rcv.scale;
2100
2101 /* every input packet in puts off the keep alive time out */
The source actually says (to be pedantic):
/* The rest of the input state machine is run with the control block
* locked and implements the state machine directly out of the RFC.
* Out-of-band data is ignored - it was always a bad idea.
*/
tcb = (Tcpctl*)s-ptcl;
if(waserror()){
qunlock(s);
nexterror();
}
qlock(s);
qunlock(tcp);
Now, the qunlock(s) should not precede the qlock(s), this is the first
case in this procedure:
/sys/src/9/ip/tcp.c:1941,2424
void
tcpiput(Proto *tcp, Ipifc*, Block *bp)
{
...
}
and unlocking an unlocked item should not be permitted, right? If s
(the conversation) is returned locked by either of
/sys/src/9/ip/tcp.c:2048
s = iphtlook(tpriv-ht, source, seg.source, dest, seg.dest);
or
/sys/src/9/ip/tcp.c:2081
s = tcpincoming(s, seg, source, dest, version);
then the qlock(s) is an issue, but I'm sure that is not the case here.
Finally, locking an item ahead of unlocking another is often cause for
a deadlock, although I understand the possible necessity.
qlock(s);
qunlock(tcp);
Even though acid points to a different location, I'd be curious to
have the details above expanded on by somebody familiar with the code.
++L
Re: [9fans] That deadlock, again
Now, the qunlock(s) should not precede the qlock(s), this is the first
case in this procedure:
it doesn't. waserror() can't be executed before the code
following it. perhpas it could be more carefully written
as
2095 qlock(s);
2091 if(waserror()){
2092 qunlock(s);
2093 nexterror();
2094 }
2096 qunlock(tcp);
Hm, I thought I understood waserror(), but now I'm sure I don't. What
condition is waserror() attempting to handle here?
++L
Re: [9fans] That deadlock, again
On Wed, Nov 17, 2010 at 06:22:33AM +0100, cinap_len...@gmx.de wrote: qpc is the just the caller of the last successfull *acquired* qlock. what we know is that the exportfs proc spins in the q-use taslock called by qlock() right? this already seems wired... q-use is held just long enougth to test q-locked and manipulate the queue. also sched() will avoid switching to another proc while we are holding tas locks. I think I'm with you, probably not quite to the same depth of understanding. i would like to know which qlock is the kernel is trying to acquire on behalf of exportfs that is also reachable from the etherread4 code. ... and from whatever the other proc is that also contributes to this jam. I don't have the name right in front of me, but I will post it separately. As far as I know it's always those two that interfere with exportfs and usually together, only a short time apart. one could move: up-qpc = getcallerpc(q); from qlock() before the lock(q-use); so we can see from where that qlock gets called that hangs the exportfs call, or add another magic debug pointer (qpctry) to the proc stucture and print it in dumpaproc(). I think I'll do the latter; even though it's more complex, it can be a useful debugging tool in future. I wouldn't leave in the kernel code, but it would be worth being able to refer to it when the occasion arises. How do you expect this qpctry to be initialised/set? ++L
Re: [9fans] That deadlock, again
On Wed, Nov 17, 2010 at 06:33:13AM +0100, cinap_len...@gmx.de wrote: sorry for not being clear. what i ment was that qpc is for the last qlock we succeeded to acquire. its *not* the one we are spinning on. also, qpc is not set to nil on unlock. Ok, so we set qpctry (qpcdbg?) to qpc before changing qpc? Irrespective of whether qpc is set or nil? And should qunlock() clear qpc for safety, or would this just make debugging more difficult? ++L
Re: [9fans] That deadlock, again
On Wed, Nov 17, 2010 at 08:45:00AM +0200, Lucio De Re wrote: ... and from whatever the other proc is that also contributes to this jam. I don't have the name right in front of me, but I will post it separately. As far as I know it's always those two that interfere with exportfs and usually together, only a short time apart. #I0tcpack pc f01ff12a dbgpc ... That's the other common factor. ++L
Re: [9fans] Plan9 development
On Wed, Nov 17, 2010 at 09:38:46AM +0200, Pavel Zholkover wrote: I did a Go runtime port for x86, it is in already in the main hg repository. Right now it is cross-compile from Linux for example (GOOS=plan9 8l -s when linking. notice the -s, it is required). I have Plan 9 versions of the toolchain that ought to make it possible to do the same under Plan 9. I'll have a look around the repository, see if I can add any value. There were a few changes made to the upstream so the following patch is needed until the fix is committed: http://codereview.appspot.com/2674041/ Right now I'm working on syscall package. Thanks for letting us know. ++L
Re: [9fans] That deadlock, again
one could move:
up-qpc = getcallerpc(q);
from qlock() before the lock(q-use); so we can see from where that
qlock gets called that hangs the exportfs call, or add another magic
debug pointer (qpctry) to the proc stucture and print it in dumpaproc().
Cinap, I tried your debugging code and got an odd panic at boot time.
Consistently:
panic: kernel fault: no user process pc=0xf01e739e addr=0x09e8
Having a look with acid, this seems to be caused by an attempt at
setting the debug PC (your up-qpctry) at a time when up has no
value yet.
Strangely, later in the qlock() code up is checked and a panic
issued if zero. I'm missing something here: it is possible to execute
this code
/sys/src/9/port/qlock.c:29,37 (more or less)
lock(q-use);
rwstats.qlock++;
if(!q-locked) {
q-locked = 1;
unlock(q-use);
return;
}
which is immediately followed by
if(up == 0)
panic(qlock);
If up is nil, but it looks like a bit of a one-way operation.
Anyway, I have moved the assignment to qpctry to after up is
tested. Let's see what happens. I'll have to get back to you once
the system is back up.
++L
Re: [9fans] That deadlock, again
Anyway, I have moved the assignment to qpctry to after up is tested. Let's see what happens. I'll have to get back to you once the system is back up. The system is working now. I have to wait for a problem to arise, next. ++L
Re: [9fans] That deadlock, again
On Thu, Nov 18, 2010 at 12:53:52AM -0500, erik quanstrom wrote: you must be in process context to qlock, because only processes can sleep. There's obviously at least one exception, because otherwise I would not have got a panic at startup. Or, for that matter there would not be active code ahead of the /sys/src/9/port/qlock.c:35,36 if(up == 0) panic(qlock); in qlock(). Or maybe that's where things are going wrong, but I doubt that the code is mistaken, I know my understanding is inadequate :-) ++L
Re: [9fans] That deadlock, again
On Thu, Nov 18, 2010 at 10:20:33AM +0100, cinap_len...@gmx.de wrote: hm... thinking about it... does the kernel assume (maybe in early initialization) that calling qlock() without a proc is ok as long as it can make sure it will not be held by another proc? That's a question for Bell Labs, I suppose, but that's precisely what I believe. There is no other explanation for the panic. Moving the up == 0 test earlier will invalidate this assumption and cause the panic we have already seen. The issue here is whether there is a situation where qlock() is intentionally invoked where up == 0 (suggested by the positioning of the up == 0 test _after_ setting the locked condition). This is improbable, though, and needs sorting out: whereas setting the lock can be done with up == 0 - and we can also clear the lock - we cannot _fail_ to set the lock, because then the absence of up will trigger a panic. Now, we know that qlock() is called with up == 0, we have seen a panic being generated by such a call. Will it suffice to locate the invocation and somehow deal with it, or should we make qlock() more robust and cause it to reject a request from a space where up == 0? Definitely, if qlock() no longer allows invocations with up == 0 there will be simplifications in its implementation. For example, the line if(up != nil up-nlocks.ref) print(qlock: %#p: nlocks %lud\n, getcallerpc(q), up-nlocks.ref); will no longer need the up != nil test. But I'm convinced there's more here than meets the eye. Unfortunately, while I have a Plan 9 distribution at my fingertips, I'm not going to try to fix this problem in a 9vx environment, I'll wait until I get home to deal with the native stuff. But one can speculate... ++L
Re: [9fans] That deadlock, again
and i'm just wrong. intentionally or not, devsd does qlock things with no up from sdreset(). ether82598 does too (my fault). I suggest you fix ether82598: it is OK to call qlock() and qunlock() without up, but only if sure that the qlock() will succeed. If it has to wait, it will panic. Given that, why do the locking at all? ++L
Re: [9fans] That deadlock, again
but i have a feeling that there is a mistake in your modification to qlock. you didn't have this panic before you modified qlock. qlock() is broken, or at the very least ambivalent. Someone ought to put it out of its misery: is it legal or is it not to call qlock() in a up == 0 context? ++L
Re: [9fans] That deadlock, again
it's to allow the use during reset of a given driver's standard functions that normally must qlock, to avoid requiring two copies of them, with and without the qlock. after reset, it's illegal to call qlock without a process (notably in an interrupt function), as it previously was. I'm willing to credit the validity of this, but I believe then that it ought to be more explicit. It seems to me that having a situation where a panic can ensue if a lock is already taken is too risky. Is it possible to count the instances of such qlock() invocations in the present kernel code and find out how common the problem really is? Or should one simply treat such invocations as innocuous and just omit connecting a user process to the queue when no user process is specified, if the lock is taken? That sounds positively explosive! ++L
Re: [9fans] That deadlock, again
after reset, it's illegal to call qlock without a process (notably in an interrupt function), as it previously was. That suggests that the (hopefully) few instances of qlock() invocations that may occur in this space should be burdened with the need to check for the value of up and altogether skip the call if it's nil. Mind you, this is not the problem we set out to fix anymore, although no doubt there is a relationship, however tenuous. ++L
Re: [9fans] That deadlock, again
/n/dump/2010/1118/sys/src/9/port/qlock.c:18,23 - port/qlock.c:18,25
{
Proc *p;
+ if(up == nil conf.postdawn)
+ panic(qlock: %#p: postdawn up nil\n, getcallerpc(q));
if(m-ilockdepth != 0)
print(qlock: %#p: ilockdepth %d\n, getcallerpc(q),
m-ilockdepth);
if(up != nil up-nlocks.ref)
Yes, this is the type of explicit-ness I was thinking of. Note that
you can now drop further tests for up == 0 later in the qlock() text.
++L
Re: [9fans] That deadlock, again
Yes, this is the type of explicit-ness I was thinking of. Note that you can now drop further tests for up == 0 later in the qlock() text. Hm, spoke too quickly. The tests on up have to remain, sadly. Sorry about the misleading noise. ++L
Re: [9fans] Video mode problem after installation on QEMU
On Thu, Nov 25, 2010 at 09:46:15AM +, Artem Novikov wrote: Date: Thu, 25 Nov 2010 09:46:15 GMT From: Artem Novikov noviko...@gmail.com To: 9fans@9fans.net Subject: Re: [9fans] Video mode problem after installation on QEMU On 24 ноя, 20:52, quans...@quanstro.net (erik quanstrom) wrote: 1. I compared the files plan9.ini.cd and plan9.ini, and no significant differences are found *nomp=1 This one has far-reaching effects. I presume it is not set in the installed system? Erik actually pointed that out in his message. *nobiosload=1 *nodumpstack=1 2. After installing the monitor = ask and vgasize = ask, was loaded into the default mode 640x480x8 (xga) 3. vga, vesa does not work 4. Maybe there is some difference in the kernels? plan9.ini.cd bootfile=sdD0!cdboot!9pcflop.gz plan9.ini bootfile=sdC0!9fat!9pcf Not likely, they are derived from the same code base. If differences can be identified, they should probably be eliminated. But it's hard to look. The real difference is the inclusion of a RAMdisk in pcflop, if memory serves. ++L
Re: [9fans] Video mode problem after installation on QEMU
On Thu, Nov 25, 2010 at 01:32:25PM +, Artem Novikov wrote: 1. *nomp=1 set by default after installation 2. --- plan9.ini.cd Hm. My approach would be to try to build 9pcf from sources as at the same date as 9pcflop.gz, probably build both and see how closely they match what gets installed. After that, it's binary division to find where things went wrong, I suppose. I'd offer to do it, but I know I'd never keep my promise :-( ++L
Re: [9fans] latest minicluster: ARM fun
The good news from Ron's photos is it seems they do make 'em like they used to, abet a little smaller. And the biblical number seven is also back, although not in the seventy times seven form yet :-) ++L
Re: [9fans] Trap in 5c compiling rc?
On Mon, Dec 06, 2010 at 09:57:50PM -0800, Paul Lalonde wrote: Getting closer. I still seem to be lacking syscallfmt.c which is called out explicitly in the mkfile but isn't in sysfromiso. The version in sys/pc clearly won't work. You can't just grab it off sources? 9fs sources fcp /n/sources/plan9/sys/src/9/kw/syscallfmt.c /sys/src/9/kw/ I rebuilt 9plug on a fresh native plan 9n distribution in the last hour, without a hitch. I even tested it on my sheevaplug and other that I haven't yet figured out how to get flash going, it worked without any intervention. Any suggestions on getting rid of the need for a console by supplying #F/flash/flash0 and putting intelligent settings in there? I'd love to get to the point where the sheeva just starts up without human intervention when there are file and auth services for it to use. I'm a little concerned about guessing my way around flash, I'd rather have instructions that are known to work. But the sheer simplicity of the whole system is mind boggling. ++L
Re: [9fans] Trap in 5c compiling rc?
Now, how do I tell it to use the USB stick as a root filesystem? I'm guessing I'll want to have two partitions, one to hold the image and another as a native P4 fs of some sort (if only to get case-sensitive filenames). How do I specify the later to the root is from prompt? Time for that consolidation of fsfs, disksim and other such disk tools into one. In your case, I think fsfs is what you need, but I'd hate to be the one to figure it all out. ++L
Re: [9fans] Trap in 5c compiling rc?
Oh dear, I spend too much time with Perforce (P4) these days. I mean an Plan9 fs, of course. Well, I don't, so I did not see the 4 at all. Anyway, you should be more careful not to contaminate this list with lower numbered members of the species :-) ++L
Re: [9fans] gumstix displays
if you want to go for a cheap atom, i think you can beat that price. Yes, but two weeks later you can't get the same device anymore, even though the successor, incompatible in fifteen different ways, is 2 USD cheaper. And all of it is buggy in some fashion or other. And VGA is its own reward. Ron has a point. ++L
Re: [9fans] tls[srv,client] confusion
After running something like the following on the server: : root; auth/rsagen -b 2048 -t 'service=tls owner=*' /tmp/keykey : root; auth/rsa2x509 'C=US CN=9srv.net' /tmp/key | auth/pemencode CERTIFICATE /tmp/cert : root; cat /tmp/key /mnt/factotum/ctl : root; aux/listen1 -tv 'tcp!*!21234' /bin/tlssrv -c /tmp/cert -Dl /tmp/out /bin/date I'd expect tlsclient tcp!9srv.net!21234 elsewhere on the network to print the date. It's not; instead, it exits with no output (and with $status unset). The connection's getting to listen1 and some sort of binary data is returned (tested with con), but tlsclient seems not to like it. Are my expectations right? Have you tried echo debug /mnt/factotum/ctl? The /tmp/keykey vs /tmp/key above is a bit worrying, but you would have picked it up interactively. Lucio.
Re: [9fans] How would you go about implementing this in Plan9?
On Fri, Dec 10, 2010 at 11:34:41AM +0200, Eugene Gorodinsky wrote: Date: Fri, 10 Dec 2010 11:34:41 +0200 From: Eugene Gorodinsky e.gorodin...@gmail.com To: 9fans@9fans.net Subject: [9fans] How would you go about implementing this in Plan9? Suppose you're writing an app such as a multiprotocol instant messenger or a mediaplayer that supports multiple container formats and codecs. It's a good You build them all into the synthetic files server, but only activate the needed ones as commanded through a control channel or file. In such case, you can define the communication mechanism and may do better than with loadable modules, where you can never be certain that they'll be available. ++L
Re: [9fans] How would you go about implementing this in Plan9?
On Fri, Dec 10, 2010 at 10:46:43AM +0100, hiro wrote: How much overhead are we talking about? In a real-time environment, it's easiest to think of all overheads as being bad, even though often they don't have any noticeable impact. ++L
Re: [9fans] UDP echo server sample code
On Mon, Jan 31, 2011 at 09:45:44AM +, ish wrote:
afd = announce(udp!*!1234, adir);
and??
...
while (read (afd, ...) 0) {
write (afd, ...);
}
... sort of thing?
++L
Re: [9fans] RESOLVED: recoving important header file rudely
On Tue, Feb 01, 2011 at 07:07:30AM +, smi...@zenzebra.mv.com wrote: Lucio De Re lu...@proxima.alt.za writes: Also, you have managed to stomp all over a couple of this mailing list's most sacred cows with your suggestion that the Plan 9 kernel code is less than perfect Ooh! No intent to offend. I actually haven't even looked at the kernel code, yet. I was referring to the bits under /sys/src/cmd/. No offense taken, sacred cows are usually very thin because they are sacred :-) _my_ suggestion to you is that you port the code to GCC and do what you like with it there. You mean port the userspace to GCC? Or the kernel? Wouldn't that kind of defeat the intent behind Plan 9's redesigned toolchain? Is gcc even supported enough on Plan 9 for serious work? The docs I've read seem to suggest that gcc is kind of glued onto the side of Plan 9 proper. The kernel code, so you can have your paradigms where I assumed you would miss them the most. No one cares about user space applications: they work, why change them? That way lies a proliferation of incompatible versions. And plan9port provides most of the Plan 9 userspace under a plethora of platforms, so that job is already done. As for GCC, it's like Linux, you know where to get it. It doesn't fit very well within Plan 9 (I have a sort-of-working version I keep as a monument), so my idea was to encourage you to turn the Plan 9 platform into something that ought to match your religious beliefs more closely. There is merit to having Plan 9 supported as a GCC application, but no one here has the necessary faith in GCC to invest in doing it. Chances are that the the changes you want to introduce are going to be incompatible in some or other manner; Some, yes. But most not. At least not yet. :) I expect I might run into trouble figuring out how to pass around strings containing NUL bytes, though. As long as you don't try to treat them as text strings, I don't see why you should encounter any problems. And I fail to see how you would do any better on any other platform, without resorting to a completely new string type. And in that vein, do you want to compare Plan 9's support for UTF-8 to other platforms' support for internationalisation? ++L
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Tue, Feb 01, 2011 at 11:06:33PM -0800, ron minnich wrote: Missionaries, at least according to the cartoons, sometimes are invited to dinner, and other times are invited to BE dinner. :-) And they often are fatter than sacred cows :-) ++L
Re: [9fans] RESOLVED: recoving important header file rudely
On Thu, Feb 03, 2011 at 03:35:04AM +, smi...@zenzebra.mv.com wrote: The finished version will support strings backed by file storage and should actually be able to handle that. But that's still far in the future, at this point. I haven't even finished coding the basic string operations for data in memory, yet. And you propose finishing this by when? And re-inventing mmap by when? ++L
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, Feb 03, 2011 at 03:47:17AM -0600, EBo wrote: Ah. Thanks for the info. I asked because some of the physicists and atmospheric scientists I work with are likely to insist on having FORTRAN. I still have not figured how I will deal with that if at all. If the cost can be met, porting GCC 3.0 (the Hogan efforts) and the Fortran front end may be feasible. You may even be able to rope me into helping, but that is hardly a recommendation :-) ++L
Re: [9fans] HELP: recoving important header file rudely clobbered
On Thu, Feb 03, 2011 at 10:37:39AM +, roger peppe wrote: you're not supposed to have a metarule with a target that matches command line arguments! What would break if mk had an empty rule matching command line arguments itself? ++L
Re: [9fans] files vs. directories
did i hear cloud-backed directory entries? I'll bite: If the cloud were to be a mere repository of (encrypted) Venti blocks, wouldn't it be a very useful tool? In fact, how do we know that Al Qaeda are not already storing and distributing all their plans for nuking New York on line as steganographically encrypted Venti blocks on porno sites? Oh, I forgot, Al Qaeda is not allowed to download from sites under the control of the U.S. Department of Commerce (right department? hard to remember). ++L
Re: [9fans] files vs. directories
did i hear cloud-backed directory entries? I'll bite: If the cloud were to be a mere repository of (encrypted) Venti blocks, wouldn't it be a very useful tool? In fact, how do we know that Al Qaeda are not already storing and distributing all their plans for nuking New York on line as steganographically encrypted Venti blocks on porno sites? Oh, I forgot, Al Qaeda is not allowed to download from sites under the control of the U.S. Department of Commerce (right department? hard to remember). ++L
Re: [9fans] files vs. directories
did i hear cloud-backed directory entries? I'll bite: If the cloud were to be a mere repository of (encrypted) Venti blocks, wouldn't it be a very useful tool? In fact, how do we know that Al Qaeda are not already storing and distributing all their plans for nuking New York on line as steganographically encrypted Venti blocks on porno sites? Oh, I forgot, Al Qaeda is not allowed to download from sites under the control of the U.S. Department of Commerce (right department? hard to remember). ++L
Re: [9fans] files vs. directories
did i hear cloud-backed directory entries? I'll bite: If the cloud were to be a mere repository of (encrypted) Venti blocks, wouldn't it be a very useful tool? In fact, how do we know that Al Qaeda are not already storing and distributing all their plans for nuking New York on line as steganographically encrypted Venti blocks on porno sites? Oh, I forgot, Al Qaeda is not allowed to download from sites under the control of the U.S. Department of Commerce (right department? hard to remember). ++L
Re: [9fans] files vs. directories
My humble apologies for the multiple copies, my fingers slipped. ++L ---BeginMessage--- did i hear cloud-backed directory entries? I'll bite: If the cloud were to be a mere repository of (encrypted) Venti blocks, wouldn't it be a very useful tool? In fact, how do we know that Al Qaeda are not already storing and distributing all their plans for nuking New York on line as steganographically encrypted Venti blocks on porno sites? Oh, I forgot, Al Qaeda is not allowed to download from sites under the control of the U.S. Department of Commerce (right department? hard to remember). ++L ---End Message---
Re: [9fans] realemu update
for everyone running realemu, please try with the new version to see if i broke something. Why TARG=qi in the mkfile (I would have guessed 8i, but I could be wrong)? and I think the error: term% mk install cp 8.out $BIN/qi rc: null list in concatenation mk: cp 8.out $BIN/qi : exit status=rc 9367: error comes from not defining BIN? Also, there's usgae: ./8.out [-Dpt] [-s srvname] [-m mountpoint] ;-) but I'll gladly submit a man page if you throw a couple of guidelines in my direction. That said, I haven't tried it yet. I'm a little concerned about aux/vga being altered to expect the emulation in /dev/realmode* and what it may do if it's not there, which probably merely shows how limited my understanding is. I would like to see this type of change find its way into the distribution permanently, I'll certainly help if I can. ++L
Re: [9fans] realemu update
mkfile is fixed now. will install itself into /$objtype/bin/aux/realemu and install realemu (8) manpage. impovement on the manpage is welcome as my english is not so good :) Again, I'm delaying testing because I need to install a different video card in the available hardware, but I'm looking forward to doing that. I have installed the pertinent bits in preparation, we'll see what happens. Thanks for tidying up. On my side what I'm still missing is a description of #P/realmode and #P/realmodemem; realemu's manpage suggests that these can be found in arch(3) but my copy of that man page has nothing to say about it (not your problem, of course). The realemu(8) man page is pretty adequate now, thank you for that, too. Would it make sense, in your opinion, to backport these changes to 8i and have that added to the distribution as well? ++L
Re: [9fans] realemu update
On Mon, Mar 07, 2011 at 11:39:10AM +0100, cinap_len...@gmx.de wrote: the /dev/realmode intraface was not documented, but it is very simple. Thank you for explaining this. /dev/realmodemem is just an image of the first megabyte of physical memory that is addressable from 16 bit realmode. That being where the machine's BIOS resides, if memory serves. Plus whatever can fit in there if one chooses to use the space. I'll understand things better with the fesh background, thank you. plan9 reserves a 4k page at 0x9000 (defined as RMBUF) that can be refered to in the bios call as data buffer. previously, this was the only offset range that could be written with /dev/realmodemem. I think I get it, but I'll experiment with it to make sure. in /dev/realmode, you write a struct Ureg (from /386/include/ureg.h) (in x86 machine byte order?) containing the register contents and the interrupt number of the bios call you want to make. the write returns when the BIOS call returns and the machine state can be read back from /dev/realmode. That is a neat idea. realemu did a little extension to the interface: it allows reading and writing the whole address space and in case the trap is zero in the Ureg, it will copy ss, sp, cs, and pc in the virtual cpu state too and not make a BIOS interrupt. this is used by loadcom.c to run dos .com files in the emulator. This bit is harder to get my mind around, but I'll explore the source code to make better sense of it. It all sounds very sensible. 8i was never in a working or finished state... That suggests that you see no value in a working 8i implementation, it's tempting to take your word for it :-) All in all, there are only so many brain cycles available. ++L
Re: [9fans] realemu update
On Mon, Mar 07, 2011 at 07:23:36AM -0500, erik quanstrom wrote: in /dev/realmode, you write a struct Ureg (from /386/include/ureg.h) (in x86 machine byte order?) containing the register contents and the interrupt number of the bios call you want to make. yes. you should use libmach to do this dirty work. Erik, what have you got in mind? Philosophically, you are perfectly correct, but the implementation would seem like overkill to me. Maybe a libmach function to build the registers from user-mode values, but surely not additional complexities in /dev/realmode to set registers, shall we say, from user-mode text values? ++L
Re: [9fans] realemu update
On Mon, Mar 07, 2011 at 09:19:58AM -0500, Russ Cox wrote: huh? what does libmach (which takes apart executables) have to do with any of this? Did I get the wrong impression when I perceived libmach, as released with GoLang - cause that's where I looked - seemingly quite capable of synthesising as well as analysing binary images? ++L
Re: [9fans] self modifying code in intel vga bios?
On Tue, Mar 08, 2011 at 10:24:48AM +0100, cinap_len...@gmx.de wrote: Fish- has catched this on a Intel(r)915GM/910ML/915MS Graphics Controller with realemu: bad mem write c0c11 bad memory access 1d17b0 4a008800 0002 a002 9000 5108 ac007bda 7bc0 c000 csZoPdI 61ed c6 MOV CS:[c11], $01 You know it's a crappy architecture when even the manufacturer needs to use self-modifying code. I thought self-modifying code (and all its dangers) had gone out of fashion a few decades ago and more advanced architectures provided safer ways to provide equivalent functionality. Heavens, with variable length instructions, the types of bugs this can give rise to are positively frightening. A case of clever but stoopid. ++L
Re: [9fans] self modifying code in intel vga bios?
On Tue, Mar 08, 2011 at 07:21:50AM -0800, Paul Lalonde wrote: The last time I poked at one of these self-modifying bits they were really just jitting a blit loop, in place. Drops register pressure a little bit, which has always been a bit of an issue in x86 land. A bankrupt CPU architecture. I guess the day they all do it, it will be decreed the right way. In the meantime, I guess we can still shop around. ++L
Re: [9fans] self modifying code in intel vga bios?
it may be that instruction sets aren't very important any longer. I wish I had the persistence to respond to this gem in detail. What is important, in my opinion, is progress in some undefinable, but recognisable sense. Faster and faster isn't it and it does seem to set higher and higher entry barriers for alternatives. Basically, that way lies a monopoly that throttles diversification. Put Nokia in bed with Microsoft in bed with Intel and you're leaving little room for somebody with a great idea to get any attention. A brave new world, indeed. ++L
Re: [9fans] 8c puzzling behavior
so it seems clear that constants are treated as if unsigned, regardless, but variables are not? the really wierd bit is that the 1 in 1i suddenly becomes signed, even though other constants are treated as if unsigned, and i is unsigned. I would not hesitate to call that a bug. I would also strongly advise you to leave well enough alone and not rely on what the standard calls implementation choices for any code you would like to be portable. If it doesn't have to be portable, check the compiler behaviour; then, as R.A. Heinlein would have it, revel in it. ++L
Re: [9fans] a little frustrated
On Wed, Mar 09, 2011 at 08:31:09AM -0500, Jacob Todd wrote: What's your point? Trolling? ++L
Re: [9fans] native library: linking err
On Mon, Mar 14, 2011 at 11:42:13AM +0100, Peter A. Cejchan wrote: sorry, type is void *fn() or void *fn(void) ? You may, if I'm guessing right, have to tighten up. It's more complicated than I can get my mind around... Lucio.
Re: [9fans] New venti install won't boot after 05:00 crash
does anything think that it's a mistake to default dma on? I have a lot of old kit around and can't for the hell of me figure out which drives do need and which ones don't want DMA, occasionally losing if nothing else a lot of time and effort in repairing a bad assumption. Having a kernel instruction can only be very useful; setting an arbitrary initial condition isn't really that helpful either way. The default, of course, would have to be ON if most hardware is to be taken into account. I'm not sure, given that old drives had unlimited lifespans and new drives only last a year or so, who wins that competition :-) Probably the motherboards: the old ones just can't compete. ++L
Re: [9fans] how can I set path
On Fri, Mar 25, 2011 at 07:57:36AM -0400, erik quanstrom wrote: for the record, you can set the path. e.g. path=($path /some/other/directory) the default path is (. /bin). Probably because one doesn't want to bind . to /bin for every . visited, not because it's a good idea. jaketodd and john correctly point out that this isn't the way it's done; bind(1) is the preferred method. rc (the shell) is the only program that respects $path. in fact that would be a sneeky way to run programs from the shell that can't be exec(2)'d. I read that as allowing the shell to run programs that the kernel would reject. I eventually understood it to mean that you can hide programs where only the shell will find them. Is the current directory one of those places, I wonder? I'm reluctant to figure it out for myself - long day. ++L
Re: [9fans] troff macros for typesetting books/longer texts
On Fri, Mar 25, 2011 at 08:25:27AM -0400, erik quanstrom wrote: i never could get past the fact that texbook reeks of hubris and nih, nor forgive gnu for using info as an excuse for not having man pages. that, and the fact that it's at least 100x slower than troff, and the reader requires cursor addressing. And info is in a league of counter-intuitiveness all of its own. ++L
Re: [9fans] Go Plan 9
On Sat, Apr 02, 2011 at 07:48:14PM -0700, Rob Pike wrote: We'll get the Plan 9 implementation up to scratch. It's not there yet, though. Once things look solid we'll need a volunteer to set up a builder so we can automatically make sure the Plan 9 port stays current. That's code for we'll have a build under Linux for the Plan 9 cross-development system or we'll have a Plan 9 port of Go? I've been thinking, besides my now very dated efforts to port the Go toolchain to Plan 9 native, that there may be merit in an intermediate port of the C and Go toolchains to p9p. But combining the build environments looked pretty complicated. I did try, but I got lost trying to keep the three build environments (Linux, Plan 9 and p9p) in my head at the same time. Still, there may be somebody out there who can get this done better than I would. ++L
Re: [9fans] Go Plan 9
On Sun, Apr 03, 2011 at 06:34:28AM -0400, erik quanstrom wrote: but there definately are some difficult bits. this hacked inclusion of stdio.h is a problem on plan 9. http://code.google.com/p/go-plan9/source/diff?spec=svnd6ec95bd4f9b2e9af2d10f08d9869aa2ca49d851r=d6ec95bd4f9b2e9af2d10f08d9869aa2ca49d851format=sidepath=/src/cmd/8a/a.y As GNU says, GNU is not Unix (or Plan 9). There is no #ifdef-free way to satisfy both toolchains unless one wants to pervert the Plan 9 toolchain. One trivial change to GCC, namely Plan 9's use of empty names to represent unused arguments, would improve GCC greatly, but is unlikely to be accepted by the developers. The alternative is a pain in the butt. But I agree with Erik, the changes to port the Go toolchain to Plan 9 are quite extensive and would require a great deal of care, I have done a similar job a year ago. Actually, I think it was two years agon and I failed to resurrect my efforts a year later. I'm not sure whether the compiler, assembler and linker that seemed to work after my first attempts could be used to bootstrap a fresh source tree. I put no effort in place on the Go package side, so that remains to be tried. In passing, Erik, you made some changes to Yacc to accept //-comments, do you still have those at hand? Do you have some idea why they were not applied to P9 Yacc? ++L
Re: [9fans] Go Plan 9
On Sun, Apr 03, 2011 at 06:34:28AM -0400, erik quanstrom wrote: a real solution would be one of 0 copy u.h; hack to taste 1 add the hacks to the real u.h 2 come to a concensus with go about what the defined-bit-width types should be called. change both plan 9 and go to conform. i'd vote for 2. it's harder that way, but i'd hate for go to feel like it was pasted on. but i'd like to know what everyone else thinks. I don't think anything comes near to 2 as a solution. And it really isn't all that invasive either. Add my vote to yours. ++L
Re: [9fans] Go Plan 9
On Sun, Apr 03, 2011 at 07:49:06PM +0300, Pavel Zholkover wrote: What about the old gcc3 port? Is it enough for bootstrapping the compilers? On Apr 3, 2011 7:28 PM, Skip Tavakkolian skip.tavakkol...@gmail.com wrote: You'd perpetuate an alien binary format, which sounds like a bad idea to me. But I'm so muddled up with all the options, I can't really find my way out of that paperbag. So perhaps somebody can pick up where Erik and I independently left off and make something out of it. I keep trying, but it keeps getting more and more complicated, at least to me. I'm happy to donate all the mkfiles I strung together, but even those may need major surgery. ++L
Re: [9fans] Go Plan 9
On Sun, Apr 03, 2011 at 01:43:53PM -0400, Devon H. O'Dell wrote: Does -fplan9-extensions not do that? Its in the latest gcc for gccgo... That would be great. I don't even pretend to keep track of what the GCC group does, I guess I owe you thanks for correcting me. If that's how one goes about finding these things out, well, it's not pretty, but it works. And in passing that grants me the option to drop unwanted argument names in the Go sources, but will the Go developers follow suit? Have they already done so? I think I have enough evidence to track down most if not all instances. ++L
Re: [9fans] Go Plan 9
On Sun, Apr 03, 2011 at 11:20:25AM -0700, Rob Pike wrote: I'm not sure I follow. The 6c and 6g compilers in the Go distribution are compiled with the local compiler, such as gcc on Linux and OS X. I don't believe it's possible they have Plan 9-specific features in their source. I can believe they would have problems compiling on Plan 9, but that's the inverse problem. On the contrary (if that makes sense), they have that nasty #include stdio.h that Erik referred to and Plan 9 is allergic to, as well as a number of nested #includes that trigger rebellion in the Plan 9 toolchain. And I don't have a 64-bit host to test them on. But do not forget that I have a Plan 9 native toolchain that compiles a runnable copy of hello.c, including printf() invocation. It's just too old to be useful. Once 6c is built, it is used to build the Go runtime, so the source and compiler should match perfectly. Plan 9 compiler issues should not be relevant. I haven't even considered using the toolchain for Plan 9 native because I can't track releases given the many changes required to silence the Plan 9 toolchain. And maybe some warnings can be overlooked, but I don't want to be the judge of that. Basically, I can't find an approach to submitting changes to the Go toolchain so it can run under Plan 9 that does not involve major surgery, nor can I separate the changes out in small parcels because testing is impractical. I'm hoping that things will eventually settle down and there will be resources to review extensive, if documentable changes. Not being able to back-port the Go toolchain to Plan 9 native seems defeatist. Now that a runtime is available and will hopefully receive extensive testing, it makes the exercise even more worthwhile. And if issues such as compatibility in function argument definitions can be resolved amicably between the GCC compiler and the Plan 9 toolchain, then things are really looking up. But, as I stated earlier, it requires the will on the Go side to retrofit changes for the sake of Plan 9, and that may be a problem. My failed efforts (possibly thoroughly misguided) to get l.h accepted with changes acceptable to the Plan 9 built-in pre-processor suggest that the Go developers have different objectives in mind. If this does not address Rob's concerns, then I'd like to ask for the question(s) to be phrased more clearly. And again, I think one ought to look at all the Plan 9 favours out there: 9vx deserves effort, Plan9port could support Go better than the native environment, linuxemu would provide a useful testbench. Only GCC 3.0 in Plan 9 is almost certainly a dead end. ++L
Re: [9fans] Go Plan 9
On Sun, Apr 03, 2011 at 07:50:20PM +0100, Steve Simon wrote: A month or so ago I got the go compiler chain to build on plan9, port is too grand a term, it was just fixing a few nits. That makes a third version. I seem to remember Erik's version compiled clean and I have to ask Steve now whether his version actually generates Plna 9 executables. And, for that matter, how far the Go portion reached. The version I have restricts itself to C, but has libraries generated using the Go toolchain and has produced one non-trivial object code that ran successfully. Regarding the Go compiler and runtime, I seem to remember that gc.a was created, but nothing else. I wrote mkfiles and fixed a few minor bugs. The bigest problem was my knowledge of yacc was not sufficent to rework the error generation magic go uses from the bison based code to plan9 yacc code. perhaps there is a yacc expert out there who would be interested in helping? When I looked at the Go sources, no such magic stood out, but it's a long time ago and I may have ignored the problem intentionally. I am happy to push back my changes, but without either getting yacc to work, or, abandoning yacc and porting bison, I didn't feel it was ready. Maybe Erik, Steve and I should consolidate our changes into a single batch and submit it as a unit, knowing that it will have received at least some competent code review. Anybody else who may want to contribute would, in my view, be welcome. Reviewing code intended for Plan 9 cannot be terribly high within the Google framework at this point in time. ++L
Re: [9fans] Go Plan 9
On Mon, Apr 04, 2011 at 10:37:30AM +0300, Pavel Zholkover wrote: Thanks for the detailed explanation, I've added your patch to if that is alright with you https://bitbucket.org/paulzhol/golang-plan9- runtime-patches/ May I suggest that we identify Go executables, because they may not run under 9vx, as different from Plan 9 executables and adjust the Plan 9 kernel to identify these and avoid running them under 9vx? There will be changes to Plan 9 to match the Go toolchain, this one is really small and could be seen as acceptance of Go as part of Plan 9's future. Ideally, when the Go runtime no longer needs special treatment we can re-categorise Go executables as normal Plan 9 executables. That option moves into the hands of the Go developers, which to me seems like the right place. The other one I would like to submit as a patch affects /386/include/u.h (and other architectures), involving the addition of integer types of various length. Equally small and benign. Opinions? ++L PS: Would anybody like to summarise for us plebs whether there is any convergence looming between Go and Plan 9 on the x64 front? It seems sad to miss a chance to add a peer-reviewed and thoroughly tested 64-bit toolchain to Plan 9.
Re: [9fans] Go Plan 9
On Mon, Apr 04, 2011 at 10:18:12PM +0300, Pavel Zholkover wrote: On Mon, Apr 4, 2011 at 8:27 PM, Lucio De Re lu...@proxima.alt.za wrote: PS: Would anybody like to summarise for us plebs whether there is any convergence looming between Go and Plan 9 on the x64 front? It seems sad to miss a chance to add a peer-reviewed and thoroughly tested 64-bit toolchain to Plan 9. the basic runtime support (not the current syscall and os changes) involved changes to 8l and some C and 386 specific assembly in pkg/runtime. I guess this could be re-done for 6l + x64 code in runtime. The question is whether it is a useful application of developers time at this stage (it would be still cross-compiled) and the 386 runtime has not been properly tested. I agree that focussing on x64 when there isn't a working target would be pointless, if intriguing. I guess the question then belongs in the Plan 9 camp: are we going to see an x64 Plan 9 development soon? and is the availability of the 6? chain in the Go sources helpful in arriving there? ++L
Re: [9fans] Go Plan 9
On Mon, Apr 04, 2011 at 07:27:28PM +0200, Lucio De Re wrote: On Mon, Apr 04, 2011 at 10:37:30AM +0300, Pavel Zholkover wrote: Thanks for the detailed explanation, I've added your patch to if that is alright with you https://bitbucket.org/paulzhol/golang-plan9- runtime-patches/ [ ... ] The other one I would like to submit as a patch affects /386/include/u.h (and other architectures), involving the addition of integer types of various length. Equally small and benign. Opinions? Here is how I changed u.h for the 386 architecture: term% diff /n/dump/2011/0130/386/include/u.h /n/dump/2011/0404/386/include/u.h 21a22,34 /* for the GO toolchain */ /* (with some effort this could go into /go/386/include, but there's really no reason to keep it from the native toolchain) */ typedef char int8; typedef short int16; typedef long int32; typedef long long int64; typedef unsigned char uint8; typedef unsigned short uint16; typedef unsigned long uint32; typedef unsigned long long uint64; Seems harmless enough. I'm sure I've actually rebuilt the Plan 9 binaries in their entirety with these changes and no ill effect. ++L
Re: [9fans] Go Plan 9
On Mon, Apr 04, 2011 at 04:10:15PM -0700, ron minnich wrote: On Mon, Apr 4, 2011 at 10:27 AM, Lucio De Re lu...@proxima.alt.za wrote: May I suggest that we identify Go executables, because they may not run under 9vx, as different from Plan 9 executables and adjust the Plan 9 kernel to identify these and avoid running them under 9vx? um, yuck :-) anyway, all you're saying is don't run go on 9vx. That's a solved problem :-) No, and no yuck, either: Go executables are different animals and they are allowed to be identified as such. Until they are not, when they are allowed to become the same animal. As for not running Go on 9vx, that's a pain, I have such a nice 9vx installation on my Ubuntu 32-bit laptop that it almost fools me into believing it's Plan 9. I don't always have a convenient CPU server at hand to run Go on it. And maybe it's just me being uninformed, but I have this suspicion that you need a Go toolchain with Plan 9 targets to produce Plan 9 executables. Maybe I should phrase this as a question: does the default Go toolchain produce Plan 9 executables or is a separate toolchain required for it? I'm pretty certain there's a need for two toolchains, but I'll be very happy to be proven wrong (and Ron right, of course). The proof would be in the pudding: I tried to compile hell-o.go (I guess that will become a benchmark :-) under an unadulterated Go toolchain, then under a Go toolchain built for the Plan 9 target (GOOS=plan9) and the object code produced showed distincly different sizes. I don't have the details at my fingertips now, this is from memory. And for Cinap, a challenge I wish I had the time and skills to take on myself: can linuxemu be added as a much thinner shim to 9vx to run Linux executables? I can think of one very interesting door that would open, there may be others. ++L
Re: [9fans] Go Plan 9
On Tue, Apr 05, 2011 at 12:22:18AM -0400, Russ Cox wrote: The number of people who want to run Go on Plan 9 is already small. The number of people who want to run Go on Plan 9 on 9vx is smaller yet. At that point why not just run Go directly? All that Microsoft thinking (99.9%-thinking, if you find the other label offensive) to avoid adding a minute, one-off change to the Go runtime? Sure, as Ron suggested it, it may need some additional thought, but we are talking about the Plan 9 team thinking about it, surely it would not take long to solve? 9vx is a nice hack but still a hack. So is VMware, but it may be a breath of life for Plan 9 and adding features to it seems inexpensive enough. The same applies to p9p, which is another toolkit that could benefit from providing a development environment for Go. That said, I'd like to make it very clear that I am extremely grateful to all those who have contributed to making Go available on the Plan 9 platform and that I hope to be part of a growing community. The current solution to the 9vx problem seems adequate, one is merely concerned that it may come back to bite an unsuspecting third party if it is forgotten. ++L
Re: [9fans] Go Plan 9
On Mon, Apr 04, 2011 at 04:33:29PM -0400, erik quanstrom wrote: [ ... ] then you can get rid of the old definitions in /*/include/u.h and declare a flag day. having both seems wrong to me. you might as well just do a local hack for the go stuff at that point. the hard part is convincing everyone that this large patch is worth the pain. i think it is, but maybe there's something i'm not thinking of, or a different point of view. Personally, I like the suggestion, but I think flag days in Plan 9 are best reserved for larger issues than the name of a handful of type definitions. The old type names might have been a bad choice (or a good choice, but contrary to popular opinion), but they do not need to go away, perhaps they can just be deprecated. I'm sure the label wrong is too strong. ++L
Re: [9fans] Go Plan 9
On Tue, Apr 05, 2011 at 01:11:35AM -0400, Russ Cox wrote: All that Microsoft thinking (99.9%-thinking, if you find the other label offensive) to avoid adding a minute, one-off change to the Go runtime? It is not a minute, one-off change. I stand corrected. I don't know how to fix it to cope with tiny virtual address spaces like those in 9vx. It's not something I anticipated when I wrote the allocator, and it's not something I really want to spend time on for such a tiny fraction of use cases. We have limited time. We don't even support OS X 10.5 anymore. That is as good an answer as I could possibly ask for. There will be other eyes to look at it and hopefully supplement the lack of time. A quick, uneducated question: should 9vx be investigated instead? The best answer might be to make USTKTOP 1GB. Where? Thanks for replying. ++L
[9fans] Plan 9 port of the Go toolchain
.../src/cmd/8a/asm.c, around line #900: /* This null SHdr must appear before all others */ sh = newElfShdr(elfstr[ElfStrEmpty]); My guess is that this needs to be followed by an instruction to write out the header, which in fact does not take place. I will not be able to test this until a number of other inconsistencies have been addressed, so if anyone knows whether this code could in fact be dropped, I'd appreciate not having to figure it out myself. The full diffs to asm.c look like this: 308c308 archreloc(Reloc *r, Sym *s, vlong *val) --- archreloc(Reloc *r, Sym *, vlong *val) 647c647 uint32 va, fo, w, symo, startva, machlink; --- uint32 symo, startva, machlink; 779d778 lputl(0); /* x */ 895d893 fo = HEADR; 897,901d894 va = startva + fo; w = segtext.filelen; /* This null SHdr must appear before all others */ sh = newElfShdr(elfstr[ElfStrEmpty]); 1217c1210 Bprint(bso, symsize = %ud\n, symsize); --- Bprint(bso, symsize = %uld\n, symsize); Comments are welcome. And, no, I don't plan to publish each set of changes, I just would like anyone who cares to know that I'm embarking on this and to make as many suggestions as they deem necessary. ++L
Re: [9fans] Go Plan 9
The new build incantation is: cd $GOROOT/src/pkg make clean mkdir -p $GROOT/bin/plan9 GOOS=plan9 GOBIN=$GOROOT/bin/plan9 make -k install I won't try this until the mmap problem you refer to is resolved, so a question is in order: are the plan 9 tools essential to the operation of 8l with GOOS=plan9 and will they be found by default or will one need to make sure that the PATH is set to find them ahead of the Linux ones? Wait. You are talking about a.out executables, these are specifically for the Plan 9 environment, aren't they? I guess I need to look for myself :-) Alternatively, is it sufficient to specify a different GOBIN or does the PATH need to be changed? I think I know the answer to this question is that the PATH needs changing, but I am normally wrong in these matters. ++L
Re: [9fans] Go Plan 9
The following executables are installed into $GOROOT/bin as Plan 9 a.out binaries when you run make -k install inside src/pkg: cgo, ebnflint, gofix, gofmt, gotest, gotype, govet, goyacc, hgpatch. They should be directed somewhere else by setting GOBIN, there is no need to include them in your PATH, the host's native executables are already in place after you build Go. OK, I think I got it. These belong on the Plan 9 platform where it is easy to bind -a .../bin/plan9 /bin to access them. Thanks for clarifying this for me: as I have nentioned more than once, getting my mind around all the permutations of toolchains, tools, platforms, architectures and targets isn't easy. ++L PS: So far I have had no joy building any of them, but that will get fixed :-)
Re: [9fans] Additional compilers under 9vx.OSX
the way to do this is
cd /sys/src; objtype=arm mk mk clean
Just getting to play with this... had to do some copying of some of
the files first among other setbacks... ok, plain mk asks what to make,
and so I tried 'mk all' which is saying 5c does not exist, but
that's one of the things I want it to build.
There's a post by Geoff Collyer a while back, when the SheevaPlug was
first introduced to Plan 9 that explains how to build the arm
toolchain before trying to build the entire system. Along these
lines:
cd /sys/src/cmd
for (d in 5?) @{cd $d mk install}
I'm not going to try that now...
++L
[9fans] Plan 9 port of the Go toolchain
I have tweaked the Plan 9 native ar.h to allow for manual adjustment around the different needs of Go and native Plan 9 toolchains, so now: #ifndef SARNAME #define SARNAME 16 #endif SARNAME can be predefined to the 64 that Go prefers. Unfortunately, it's a short term solution, I'm hoping for suggestions on the way forward from here. ++L PS: I still can't link an executable with the version of 8l from the Go toolchain that I built under Plan 9, but I'm hoping to get there soon.
Re: [9fans] Plan 9 port of the Go toolchain
PS: I still can't link an executable with the version of 8l from the Go toolchain that I built under Plan 9, but I'm hoping to get there soon. It's of some consolation to me that I see exactly the same results under Ubuntu, so that particular problem isn't in the 8l executable created for Plan 9. I may have something exciting to report on this issue within the day. ++L
