[9fans] Motherboard recommendations?
The motherboard in my main server went belly-up yesterday. No POST, no nothing. Well, the fans spin. Joy. That particular motherboard isn't carried anywhere any more, despite being a whopping one year old. I'm looking for a replacement, but having a hard time finding one with both a supported SATA controller and supported gigabit ethernet with an AMD CPU and DDR2 RAM (so I don't have to replace that, too). Anyone have any recommendations? Bonus points for one that I can get shipped overnight.
Re: [9fans] Motherboard recommendations?
perhaps more particularly, anyone know of or working on support for the RealTek RTL8111/8168B ethernet controller? I've found two boards with match except for having an 8111 controller, which we don't list as supported. i have no idea how close realtek's parts are to each other.
Re: [9fans] Motherboard recommendations?
On Wed Dec 17 13:10:41 EST 2008, ano...@gmail.com wrote: > perhaps more particularly, anyone know of or working on support for > the RealTek RTL8111/8168B ethernet controller? I've found two boards > with match except for having an 8111 controller, which we don't list > as supported. i have no idea how close realtek's parts are to each > other. i haven't had a problem with any of these working. you can get a $34 intel pro/pt 1000 if you want something a little nicer. - erik
Re: [9fans] Motherboard recommendations?
On Wed Dec 17 13:00:49 EST 2008, ano...@gmail.com wrote: > The motherboard in my main server went belly-up yesterday. No POST, no > nothing. Well, the fans spin. Joy. > > That particular motherboard isn't carried anywhere any more, despite > being a whopping one year old. I'm looking for a replacement, but > having a hard time finding one with both a supported SATA controller > and supported gigabit ethernet with an AMD CPU and DDR2 RAM (so I > don't have to replace that, too). get a sb600 or greater-based machine. they all have ahci which is supported by the intel ahci driver. - erik
Re: [9fans] Motherboard recommendations?
does "sb600 or greater" really mean just by number? sb700 and sb750 seem common, but i'd assumed (probably foolishly) that 6xx was different (enough) from 7xx.
Re: [9fans] Motherboard recommendations?
On Wed Dec 17 14:23:23 EST 2008, ano...@gmail.com wrote: > does "sb600 or greater" really mean just by number? sb700 and sb750 > seem common, but i'd assumed (probably foolishly) that 6xx was > different (enough) from 7xx. yes. i don't know of many significant changes between sb600 and sb750. amd really did release them in order. shocking, i know. you may have to grab the ahci driver from my contrib area (/n/sources/contrib/quanstro/src/9/pc/^(sdiahci.c ahci.h)) to recognize the sb7xx parts. i run a sb600 at home. - erik
Re: [9fans] 9vx on x86-64
> > That's scary. Can you send the output of "gcc -v"? > Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/ configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/ 4.3.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include -- datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2 --mandir=/usr/ share/gcc-data/x86_64-pc-linux-gnu/4.3.2/man --infodir=/usr/share/gcc- data/x86_64-pc-linux-gnu/4.3.2/info --with-gxx-include-dir=/usr/lib/ gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4 --host=x86_64-pc-linux- gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed- point --enable-nls --without-included-gettext --with-system-zlib -- disable-checking --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld -- enable-objc-gc --enable-languages=c,c++,java,objc,obj-c+ +,treelang,fortran --enable-shared --enable-threads=posix --enable- __cxa_atexit --enable-clocale=gnu --with-bugurl=http:// bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.2 p1.1' Thread model: posix gcc version 4.3.2 (Gentoo 4.3.2 p1.1)
[9fans] devtrace release time
Devtrace is ready for your consumption, hot out of the oven and juicy fresh. The source is at /n/sources/contrib/john/devtrace-backport.tgz which includes all the necessary source files, the man page (troff), and instructions for putting it in the kernel and compiling. Remember, this isn't mine alone, Ron and Aki came up with the idea and did the real hard implementation; I just finished up and did some porting. Therefore, make sure to blame Ron if it doesn't work. John Floren
Re: [9fans] devtrace release time
Does it work now with non-amd64 kernels? Peace uriel On Wed, Dec 17, 2008 at 8:36 PM, wrote: > Devtrace is ready for your consumption, hot out of the > oven and juicy fresh. The source is at > /n/sources/contrib/john/devtrace-backport.tgz > which includes all the necessary source files, the man > page (troff), and instructions for putting it in the > kernel and compiling. > > Remember, this isn't mine alone, Ron and Aki came up > with the idea and did the real hard implementation; > I just finished up and did some porting. Therefore, > make sure to blame Ron if it doesn't work. > > John Floren > >
Re: [9fans] devtrace release time
This source is backported to the PC kernel in /sys/src/9/pc. The instructions make this abundantly clear, what with all the stuff being done in /sys/src/9/pc. John > Does it work now with non-amd64 kernels? > > Peace > > uriel > > On Wed, Dec 17, 2008 at 8:36 PM, wrote: >> Devtrace is ready for your consumption, hot out of the >> oven and juicy fresh. The source is at >> /n/sources/contrib/john/devtrace-backport.tgz >> which includes all the necessary source files, the man >> page (troff), and instructions for putting it in the >> kernel and compiling. >> >> Remember, this isn't mine alone, Ron and Aki came up >> with the idea and did the real hard implementation; >> I just finished up and did some porting. Therefore, >> make sure to blame Ron if it doesn't work. >> >> John Floren >> >>
Re: [9fans] devtrace release time
Didn't know the amd64 kernel doesn't live in /sys/src/9/pc/. Sorry, I should have guessed that /sys/src/9/not-for-the-unworthy-unwashed-masses/ was much more likely location. Peace uriel On Wed, Dec 17, 2008 at 8:55 PM, wrote: > This source is backported to the PC kernel in /sys/src/9/pc. > The instructions make this abundantly clear, what with all > the stuff being done in /sys/src/9/pc. > > John > >> Does it work now with non-amd64 kernels? >> >> Peace >> >> uriel >> >> On Wed, Dec 17, 2008 at 8:36 PM, wrote: >>> Devtrace is ready for your consumption, hot out of the >>> oven and juicy fresh. The source is at >>> /n/sources/contrib/john/devtrace-backport.tgz >>> which includes all the necessary source files, the man >>> page (troff), and instructions for putting it in the >>> kernel and compiling. >>> >>> Remember, this isn't mine alone, Ron and Aki came up >>> with the idea and did the real hard implementation; >>> I just finished up and did some porting. Therefore, >>> make sure to blame Ron if it doesn't work. >>> >>> John Floren >>> >>> > > >
[9fans] ape pwd.h not in sync ?
Hi All,
the ape/pwd.h has the following
(in short pw_passwd missing, is this something unwanted ?)
struct passwd {
char*pw_name;
uid_t pw_uid;
gid_t pw_gid;
char*pw_dir;
char*pw_shell;
};
Linux has:
struct passwd
{
char *pw_name;/* Username. */
char *pw_passwd; /* Password. */
__uid_t pw_uid; /* User ID. */
__gid_t pw_gid; /* Group ID. */
char *pw_gecos; /* Real name. */
char *pw_dir; /* Home directory. */
char *pw_shell; /* Shell program. */
};
BSD:
struct passwd {
char*pw_name; /* user name */
char*pw_passwd; /* encrypted password */
uid_t pw_uid; /* user uid */
gid_t pw_gid; /* user gid */
time_t pw_change; /* password change time */
char*pw_class; /* user access class */
char*pw_gecos; /* Honeywell login info */
char*pw_dir;/* home directory */
char*pw_shell; /* default shell */
time_t pw_expire; /* account expiration */
};
Cheers,
/Prem
Re: [9fans] devtrace release time
On Wed, Dec 17, 2008 at 12:08 PM, Uriel wrote: > Didn't know the amd64 kernel doesn't live in /sys/src/9/pc/. OK, I am only responding to this because of the incorrect impressions being left by these kinds of comments. The backport John did is to the standard kernel that you all can get on your machine. It should in fact even work on 9vx. You are welcome to use it. In fact, one could actually look at what John released *before* posting to this list and making oneself look silly. It's an idea. great unwashed masses? I am reminded of a liberation sign somebody spotted in some foreign land once: "The Masses are Revolting!" :-) ron
Re: [9fans] 9P in C++
Pietro Gagliardi escribió:
Given
extern "C"{
#include <9p.h> // or whatever you do
}
you can link 9p into a C++ program easily.
Yes!
If I use the extern "C" it compiles :'-)
Using "extern function" is not valid for linking C and C++
Sorry Pietro, sqweek. Thanks a lot.
Re: [9fans] devtrace release time
On Wed, Dec 17, 2008 at 4:07 PM, ron minnich wrote: > > "The Masses are Revolting!" > "You said it! They stink on ice!" -History of the World, Part I.
Re: [9fans] Getting qlock errors when trying to install
Excerpts from Sebastian Arvidsson Liem's message of Fri Dec 05 12:40:49 -0800 2008: > Hi, > > I've got my hands on a Intel Atom D945GCLF [1] board and I'm trying > to install Plan 9 on it. It's my first time so please be gentle. ;D > > I'm using the Dec 5 2008 iso and it hangs on the following: > > [...] > 1014M memory: 256M kernel data, 758M user, 1383M swap > kfs...version...time... > qlock: 0xf018bb64: ilockdepth 1 > qlock: 0xf01a1591: ilockdepth 1 > qlock: 0xf01a1591: ilockdepth 1 I recently put together a similar system but using the 945GCLF2 motherboard [1]. I also got similar qlock errors. I noticed that the kernel detected the ethernet card twice and so I decided to try disabling the ethernet interface in the BIOS. The system booted fine after that. I did have to put the SATA controller in legacy mode for it to be recognized as well. I think once I build a newer kernel I'll be able to use it in native mode. I'm using the last ISO I had lying around which is from 24 Sept 2008. I've since popped a 3c905 card in the machine and it's on the net. Hopefully tonight I'll have some time to update the installation. Once I've got that I can try renabling the onboard ethernet interface and see if it fares better with a newer kernel. If not I'll post the kernel I'm using somewhere so that Erik or whomever else can take a peek. Barring that I suppose I can just buy a supported GigE NIC. I might also try putting a Linux partition on here so I can try the lguest port, but I'd really rather run on bare hardware. This box is shaping up to be my home cpu/file server. It's definitely not a monster, but I think it will be more than adequate for my needs. Cheers, Jon [1]: For less than $225 shipped I got the following complete system: http://www.newegg.com/Product/Product.aspx?Item=N82E16813121359 http://www.newegg.com/Product/Product.aspx?Item=N82E16820134192 http://www.newegg.com/Product/Product.aspx?Item=N82E16811154084 http://www.newegg.com/Product/Product.aspx?Item=N82E16822148262
[9fans] Fwd: Re: devtrace release time
--- Begin Message --- On Wed, Dec 17, 2008 at 4:07 PM, ron minnich wrote: > > "The Masses are Revolting!" > "You said it! They stink on ice!" -History of the World, Part I. --- End Message ---
[9fans] This is classic.
For no reason that I can see I am now getting this message via a dialogue box: Packagekit Error Failed to reset get-updates Then a little box I can tick for more data. Here's where it really gets good: A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface "org.freedesktop.PackageKit.Transaction" member "Cancel" error name "(unset)" destination "org.freedesktop.PackageKit") Neat. Lots of this. So. just WTF could this all mean? It means dbus hell. It's amazing to think of the amount of labor that could produce something like this. And people claim Plan 9 is obscure? ron
Re: [9fans] This is classic.
D-bus, a disgrace that should never have even been invented, if 9P on linux had not been dead-on-arrival. uriel On Wed, Dec 17, 2008 at 11:28 PM, ron minnich wrote: > For no reason that I can see I am now getting this message via a dialogue box: > Packagekit Error > Failed to reset get-updates > > Then a little box I can tick for more data. > > Here's where it really gets good: > A security policy in place prevents this sender from sending this > message to this recipient, see message bus configuration file > (rejected message had interface > "org.freedesktop.PackageKit.Transaction" member "Cancel" error name > "(unset)" destination "org.freedesktop.PackageKit") > > Neat. Lots of this. So. just WTF could this all mean? It means dbus hell. > > It's amazing to think of the amount of labor that could produce > something like this. And people claim Plan 9 is obscure? > > ron > >
Re: [9fans] This is classic.
> D-bus, a disgrace that should never have even been invented, if 9P on > linux had not been dead-on-arrival. "if you want Plan 9 you know where to find it" I heard them say.
[9fans] spamhaus alternative
Hello, I've started to get spam this week, seems that, or this has been applied to 9grid.es "Caution: If your usage should exceed the free use criteria your access to Spamhaus's public DNSBL servers is very likely to be cut off without warning." or they are missing some "well-known" sources of spam. I've registered 9grid.es in http://www.barracudacentral.org/rbl/ and they are already blocking the spam emails i've got. slds. gabi
Re: [9fans] This is classic.
On Wed, Dec 17, 2008 at 11:39 PM, andrey mirtchovski wrote: >> D-bus, a disgrace that should never have even been invented, if 9P on >> linux had not been dead-on-arrival. > > "if you want Plan 9 you know where to find it" I heard them say. If that is what they said, that displays their usual ignorance of Plan 9 and how its development 'works'. uriel
Re: [9fans] This is classic.
Ron, probably is something like this: http://www.linuxquestions.org/questions/fedora-35/fedora-core-9-update-dbus.exception-and-dbus.proxies-and-dbus.error.accessdenied-errors-689207/ Saludos. ron minnich escribió: For no reason that I can see I am now getting this message via a dialogue box: Packagekit Error Failed to reset get-updates Then a little box I can tick for more data. Here's where it really gets good: A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface "org.freedesktop.PackageKit.Transaction" member "Cancel" error name "(unset)" destination "org.freedesktop.PackageKit") Neat. Lots of this. So. just WTF could this all mean? It means dbus hell. It's amazing to think of the amount of labor that could produce something like this. And people claim Plan 9 is obscure? ron
Re: [9fans] devtrace release time
2008/12/17 ron minnich : > On Wed, Dec 17, 2008 at 12:08 PM, Uriel wrote: >> Didn't know the amd64 kernel doesn't live in /sys/src/9/pc/. > > OK, I am only responding to this because of the incorrect impressions > being left by these kinds of comments. > > The backport John did is to the standard kernel that you all can get > on your machine. It should in fact even work on 9vx. You are welcome > to use it. In fact, one could actually look at what John released > *before* posting to this list and making oneself look silly. It's an > idea. It doesn't (yet) work on 9vx. I'm working on that right now, though. More on that in a later message. --dho > great unwashed masses? I am reminded of a liberation sign somebody > spotted in some foreign land once: > > "The Masses are Revolting!" > > :-) > > ron > >
[9fans] 9vx Patches
Hey guys, Back in my ``let's have fun with Plan 9'' yearly phase. Here I come back and I see some really cool work. 9vx definitely is the coolest thing I've seen so far, and devtrace looks pretty nifty too. What's really cool to me about them is that they're available and there is open work to be done with them. So I've started hacking away. My 9vx has a couple changes that I found useful / thought would be fun to implement / thought others might find useful. A brief synopsis: * Memory bounds -- gives 9vx an upper bound on resident memory usage as it limits the size of the pagefile. Set by running 9vx with -m [MB] * CPU bounds -- only works on FreeBSD so far. I've got a Linux port of that management code, but it doesn't seem to actually do the right thing (and it hasn't been a priority to fix since I rarely run Linux). I do plan on fixing it, but if someone else wants to fix it first, that'd be fine by me, too. Darwin support looks unlikely because, although the libkvm stuff is there and likely would work after just changing some of the member names of where things look, it has neither a clone(2) or rfork(2) implementation. If anybody has an idea about how to spawn and disassociate a child process in Darwin so it doesn't receive its parents' signals, let me know. Set by running 9vx with -l [% CPU]. * Set window width/height on the console. Set with -w [width] and -h [height], respectively. * Lock tracing. I needed this when debugging some of the netstack stuff because I screwed up a qunlock which deadlocked the system. Set by toggling -L. Things in the works: * Native Plan 9 netstack. It's ported, it compiles, but my virtual ethernet device doesn't seem to be transmitting anything (though I haven't done any extensive tests). See also: http://testbed.dh0.us/~dho/fuxyes.png * Porting devtrace. Needs some changes to compile with gas; the #pragmas are useless, but I think should work after a little more tweaking. * FreeBSD/amd64 support. I don't think it works yet, but it compiles. I don't rightly understand what all the LDT modification does on Linux x86_64 in relation to what I'm actually doing with %gs (hints from people with knowledge welcome). Other stuff * Automatic provisioning via a web browser. Yeah, Plan 9 in the web browser (if you have Java, I guess -- otherwise it's just VNC). http://testbed.dh0.us/ -- this code isn't version controlled, but I could probably put it in hg with little effort. The code for the rest of the stuff is at http://testbed.dh0.us:8000/ --dho
Re: [9fans] 9vx Patches
so here's a potentially interesting idea. Since you are running plan 9 under Linux with 9vx, consider using the TAU toolkit to measure it. http://www.cs.uoregon.edu/research/tau/home.php we've used these tools to optmize an MPI library and they are quite powerful. See what you think. ron
Re: [9fans] 9vx Patches
On Wed, Dec 17, 2008 at 4:10 PM, Devon H. O'Dell wrote: > * Porting devtrace. Needs some changes to compile with gas; the > #pragmas are useless, but I think should work after a little more > tweaking. note that those pragmas are the tip of the iceberg. gcc inserts the profiling code; on Plan 9, the linker does it. There will be a few things to fix here. neat stuff you are doing. ron
Re: [9fans] 9vx Patches
On Dec 17, 2008, at 4:33 PM, ron minnich wrote: so here's a potentially interesting idea. Since you are running plan 9 under Linux with 9vx, consider using the TAU toolkit to measure it. http://www.cs.uoregon.edu/research/tau/home.php we've used these tools to optmize an MPI library and they are quite powerful. TAU is good. There's also a Sun Studio Performance Analyzer that, to my taste, is a bit more tightly integrated than TAU and seems to be more scalable: http://developers.sun.com/sunstudio/overview/topics/analyzer_index.html In fact, Ron, now that you've mentioned it -- I'm going to try the PerfAn on 9vx myself ;-) And here's the question for you: how representative the behavior of 9vx is supposed to be of the regular Plan9 kernel? Thanks, Roman.
Re: [9fans] 9vx Patches
On Wed, Dec 17, 2008 at 4:43 PM, Roman Shaposhnik wrote: > In fact, Ron, now that you've mentioned it -- I'm going to try the PerfAn > on 9vx myself ;-) And here's the question for you: how representative > the behavior of 9vx is supposed to be of the regular Plan9 kernel? I don't know but the code sure looked like a plan 9 kernel to me. ron
Re: [9fans] 9vx Patches
On Dec 17, 2008, at 4:10 PM, Devon H. O'Dell wrote: * Automatic provisioning via a web browser. Yeah, Plan 9 in the web browser (if you have Java, I guess -- otherwise it's just VNC). http://testbed.dh0.us/ -- this code isn't version controlled, but I could probably put it in hg with little effort. Really nice bunch of things! I'm looking forward to seeing the implementations. As for the above service -- is it currently off-line? I can log-in and create an instance, but when I try to connect to it here's what I get: snazvx: dashboard control id namestate activateview 10 rvs-testrunning stopview (or vncviewer testbed.dh0.us:5810) vncviewer: ConnectToTcpAddr: connect: Connection refused Unable to connect to VNC server Thanks, Roman. P.S. Has anybody experimented with running 9vx on Amazon's EC2 yet?
[9fans] How can I boot plan9 on my Compaq AlphaServer DS10L?
Well apparently plan9 runs on alpha, but I can not get plan9 to run on my DS10L. Can anyone help?
Re: [9fans] How can I boot plan9 on my Compaq AlphaServer DS10L?
On Wed, Dec 17, 2008 at 5:10 PM, Nolan Hamilton wrote: > Well apparently plan9 runs on alpha, but I can not get plan9 to run on my > DS10L. Can anyone help? > I can help the DS10L. 1. open window 2. look out, make sure no one is in the areas 3. slide DS10L out window now that was easy! Of course, there are also experiments involving sledgehammers and large rocks if you want to get more creative. I do love the DS10L. ron
Re: [9fans] Getting qlock errors when trying to install
> I recently put together a similar system but using the 945GCLF2 motherboard > [1]. I also got similar qlock errors. I noticed that the kernel detected the > ethernet card twice and so I decided to try disabling the ethernet interface > in the BIOS. The system booted fine after that. I did have to put the SATA > controller in legacy mode for it to be recognized as well. I think once I > build a newer kernel I'll be able to use it in native mode. I'm using the > last ISO I had lying around which is from 24 Sept 2008. that motherboard uses the realtek gbe chipset. the "8169" driver doesn't appear to get along with the recent changes to the Block code. my machine rebooted too fast to get much useful information (ya, ya, i need to get another serial card. tell me about it. :-)) i backed those changes out and things work fine. if the kernel /n/sources/contrib/quanstro/9pccd.gz works for you, i'd think this is very likely your problem. as to recognizing your drives in "native" mode. supposing it is supported, the driver at /n/sources/contrib/quanstro/src/9/pc/^(ahci.h sdiahci.c) will do the trick, if your chipset supports ahci. you will also need to modify 9load to recognize your vid/did. i'll do that when i get a chance. - erik
Re: [9fans] 9vx Patches
2008/12/17 Roman Shaposhnik : > On Dec 17, 2008, at 4:10 PM, Devon H. O'Dell wrote: >> >> * Automatic provisioning via a web browser. Yeah, Plan 9 in the web >> browser (if you have Java, I guess -- otherwise it's just VNC). >> http://testbed.dh0.us/ -- this code isn't version controlled, but I >> could probably put it in hg with little effort. > > Really nice bunch of things! I'm looking forward to seeing the > implementations. As for the above service -- is it currently > off-line? I can log-in and create an instance, but when I > try to connect to it here's what I get: Thanks! The 9vx that is installed by this though is the one from Russ's tip... mine's still not perfect and currently doesn't do any networking. > snazvx: dashboard > control > id namestate activateview > 10 rvs-testrunning stopview (or vncviewer > testbed.dh0.us:5810) The vncviewer text is wrong; it's just vncviewer testbed.dh0.us:10 -- I haven't fixed this yet :( > vncviewer: ConnectToTcpAddr: connect: Connection refused > Unable to connect to VNC server > > Thanks, > Roman. --dho > P.S. Has anybody experimented with running 9vx on Amazon's EC2 yet? I would if it was free and I didn't have a server :\ --dho
Re: [9fans] 9vx Patches
> I would if it was free and I didn't have a server :\ and more reliable than street power. - erik
[9fans] of historical interest (old Unix filesystems using FUSE)
This is from the TUHS list. I thought it might be of interest here, too. > Date: Thu, 18 Dec 2008 09:05:30 +1000 > From: Warren Toomey > To: t...@tuhs.org > Subject: [TUHS] Old UNIX Filesystems with FUSE > > http://osxbook.com/software/ancientfs/ > > Amit Singh has added support for a whole bunch of early UNIX filesystem and > archive formats to FUSE. > > Cheers, > Warren > ___ > TUHS mailing list > t...@minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs A subsequent mail says that it doesn't work immediately on Linux but apparently it shouldn't be that hard. Didn't Plan 9 have a way to mount 6th and 7th edition disk images also? Was that ever released? Arnold
Re: [9fans] devtrace release time
> In fact, one could actually look at what John released > *before* posting to this list and making oneself look silly. It's an > idea. Uriel is renowned for demanding tools to be released on principle, without him having any practical need for them. He lands up sounding like a peevish, ungrateful child who just wants more sweets even though his hands are already full. Far from him to actually do some checking first. What could he possibly need with devtrace anyway? That said, is there any reason why devtrace is not part of the distribution and are there plans to incorporate it? ++L
Re: [9fans] How can I boot plan9 on my Compaq AlphaServer DS10L?
> I can help the DS10L. > > 1. open window > 2. look out, make sure no one is in the areas > 3. slide DS10L out window Sure, but how do you "keep Plan 9 honest" if no one checks portability? In fact, it's already very hard to find porting opportunities for Plan 9, regretfully. An example I raised at IWP9 in Volos was the Linux emulation and the possibility that it could be ported to the PowerPC. Forsyth pointed out that there are no mere mortal accessible platforms for experimentation in this direction. Now, what's preferable: no experimentation or being able to test on an old RS6000 or power-MAC? ++L PS: This is a bit of a call for interest in architectures other than the 386, no matter how much Ron tries to discourage it. Hey, why should I not be able to test the BG code at home?! :-)
Re: [9fans] How can I boot plan9 on my Compaq AlphaServer DS10L?
On Thu, Dec 18, 2008 at 5:12 AM, wrote: >> I can help the DS10L. >> >> 1. open window >> 2. look out, make sure no one is in the areas >> 3. slide DS10L out window > > Sure, but how do you "keep Plan 9 honest" if no one checks > portability? Don't worry. The holy keepers of the amd64 kernel do that for us. There is nothing to fear, go back to sleep. > In fact, it's already very hard to find porting opportunities for Plan > 9, regretfully. An example I raised at IWP9 in Volos was the Linux > emulation and the possibility that it could be ported to the PowerPC. > Forsyth pointed out that there are no mere mortal accessible platforms > for experimentation in this direction. > > Now, what's preferable: no experimentation or being able to test on an > old RS6000 or power-MAC? There is supposedly a partial port to the iMac (or some other ancient jobsian hardware) by some university somewhere, last I heard the code was only available under some bizarre access restrictions that I never quite understood nor do I remember, npe was even able to procure himself access to the server in question after jumping through some hoops, supposedly to finish the port, no idea what came of that... this was years ago. > ++L > > PS: This is a bit of a call for interest in architectures other than > the 386, no matter how much Ron tries to discourage it. Hey, why > should I not be able to test the BG code at home?! :-) Because we unworthy dirty masses should not bother with what we are not supposed to be interested in. uriel
Re: [9fans] devtrace release time
Yea, stupid retarded moron I am to give a fuck about the welfare of Plan 9 and its future. After all, I have only invested I don't know how many hundreds of hours of my life in it... uriel On Thu, Dec 18, 2008 at 4:52 AM, wrote: >> In fact, one could actually look at what John released >> *before* posting to this list and making oneself look silly. It's an >> idea. > > Uriel is renowned for demanding tools to be released on principle, > without him having any practical need for them. He lands up sounding > like a peevish, ungrateful child who just wants more sweets even > though his hands are already full. > > Far from him to actually do some checking first. What could he > possibly need with devtrace anyway? > > That said, is there any reason why devtrace is not part of the > distribution and are there plans to incorporate it? > > ++L > > >
Re: [9fans] devtrace release time
>> In fact, one could actually look at what John released >> *before* posting to this list and making oneself look silly. It's an >> idea. > > Uriel is renowned for demanding tools to be released on principle, > without him having any practical need for them. He lands up sounding > like a peevish, ungrateful child who just wants more sweets even > though his hands are already full. > > Far from him to actually do some checking first. What could he > possibly need with devtrace anyway? > > That said, is there any reason why devtrace is not part of the > distribution and are there plans to incorporate it? > > ++L Answering the last question: devtrace has only been compatible with the current kernel for a few weeks, which I've spent testing and cleaning up the code a bit. Right now, I'd object to including devtrace in the distribution because of all the #pragma's it tosses around in 9/pc, 9/port, and even libc. Also, it currently replaces the *old* profiling system--that's why the assembly functions are called _profin and _profout even though they call tracein and traceout in devtrace.c (and everything else in the code is called "trace" rather than "profile"). I hacked the linker so it could take a -t flag and insert _tracein and _traceout; if we were to put it in the distribution, we could replace all my "#pragma profile 0" lines with "#pragma trace 0", which would allow you to still use the old profiling system without interference. It would be a bit of work but definitely feasible if there's interest. John
Re: [9fans] devtrace release time
On Wed, Dec 17, 2008 at 11:55:50PM -0500, j...@csplan9.rit.edu wrote: > It would be a bit of work but definitely feasible if there's interest. +1 pgpTOmxdMaiBS.pgp Description: PGP signature
Re: [9fans] devtrace release time
> On Wed, Dec 17, 2008 at 11:55:50PM -0500, j...@csplan9.rit.edu wrote: >> It would be a bit of work but definitely feasible if there's interest. > > +1 I presume by this that you were able to get devtrace working? Did you find the documentation sufficiently clear? Any problems? John
Re: [9fans] devtrace release time
No, '+1' means that he agrees and supports the quoted statement. uriel On Thu, Dec 18, 2008 at 6:04 AM, wrote: >> On Wed, Dec 17, 2008 at 11:55:50PM -0500, j...@csplan9.rit.edu wrote: >>> It would be a bit of work but definitely feasible if there's interest. >> >> +1 > > I presume by this that you were able to get devtrace working? Did you > find the documentation sufficiently clear? Any problems? > > John > > >
Re: [9fans] of historical interest (old Unix filesystems using FUSE)
> Didn't Plan 9 have a way to mount 6th and 7th edition disk images also? > Was that ever released? tapefs(4)
[9fans] Help with device and clone?
I really am getting to the deep guts of dev.c and chan.c here in debugging why when ip/ipconfig tries to open /net/ether0/clone, it's getting Enotfound. From my latest commit: Fix some stuff with the ether controller attaching. It attaches now, but for some reason clone screws up. I have no idea why; domount is failing to work in 9vx/a/chan.c when we are doing the walk over the path which in turn causes us to try to find the file in rootgen instead of going to the other side of the mount and looking for it in /ether0/clone. Help? It's entirely possible (and almost entirely clear) that I'm missing something obvious, but I'm not sure what it is. The virtual device is at http://testbed.dh0.us:8000/file/dfc493421329/src/9vx/etherve.c for the current revision -- feel free to browse around or clone my repo. I'm going to sleep now, but any help would be appreciated. --dho
Re: [9fans] How can I boot plan9 on my Compaq AlphaServer DS10L?
> Because we unworthy dirty masses should not bother with what we are > not supposed to be interested in. This is getting tedious. Have you considered psychotherapy for your paranoia? And what exactly is it that is being denied to you and you deem to be your undeniable right? ++L
Re: [9fans] devtrace release time
> On Wed, Dec 17, 2008 at 11:55:50PM -0500, j...@csplan9.rit.edu wrote: >> It would be a bit of work but definitely feasible if there's interest. > > +1 Out of scope in my case, but the logistics interest me greatly. Please keep me in the loop. ++L
Re: [9fans] 9P in C++
On Thu, Dec 18, 2008 at 7:14 AM, Rodolfo kix Garcia wrote:
> Pietro Gagliardi escribió:
>> extern "C"{
>> #include <9p.h> // or whatever you do
>> }
>>
>> you can link 9p into a C++ program easily.
>
> If I use the extern "C" it compiles :'-)
>
> Using "extern function" is not valid for linking C and C++
extern works fine between C and C++, but maybe it doesn't do what you
think it does. extern assures the compiler that there is a symbol with
a certain type defined in some other object than the one currently
being compiled.
What you're running into is a name mangling issue. C++ supports
overloaded functions, ie. functions with the same name but different
prototypes. This doesn't fly with the linker, because as far as it is
concerned each symbol has a unique type[1]. So, C++ mangles[2] the
function name by appending a string representation of the prototype.
int main(int, char**) maps to a symbol like main_i_i_ppc. The mangled
notation is compiler specific of course.
This presents a problem for interoperation with C code. Any existing
library compiled by a C compiler has regular non-mangled names. But, a
C++ compiler will grab the prototypes from the library's header file,
and then tell the linker to look for mangled versions of the symbols.
Obviously it is not going to find them.
So, as a workaround, C++ overloads the extern keyword to allow the form:
extern "C" {
...
}
Which tells the compiler "the functions defined in this block were
compiled with a C compiler, don't mangle the symbols".
[1] Does the linker actually know about types or just sizes?
[2] "mangles" is official terminology, so at least they're honest about it. ;)
-sqweek
