[9fans] Xen/KVM preferences

[EBo]

I've come across references to plan9 running on KVM and Xen.  Is there any
consensus on which is the preferred/better way to go, or what is the preferred
development path?  

  EBo --

Re: [9fans] Plan9 ezine

[EBo]

Ethan Grammatikidis  said:

> With reference to both this and the Binary Format thread I would like  
> to say I don't think many people really grasp how different Plan 9's  
> approach is. Unix was made with the idea of getting away from the  
> overburdened, ridiculously bloated operating systems of the past.  
> (Lisp machines could take 15 minutes to start up.) Today the computing  
> world knows nothing else than trying to add back that bloat unix got  
> away from, except this time it's usually without the careful design of  
> the past.

Actually, explaining that in an ezine would make a wonderful article. 
Actually if I had time I think we could post a half dozen or more references
which basically explain this as why Plan 9 was designed and developed in the
first place.

  EBo --

Re: [9fans] Binary format

[EBo]

Nathaniel W Filardo  said:

> On Wed, Feb 17, 2010 at 03:06:57PM +0100, Gorka Guardiola wrote:
> > > * each module may have an entry point (main module w/o is allowed,
> > >  even if it wouldn't make much sense ;-o), these are called after
> > >  relocation, along the dependency tree, from leaf to root.
> > 
> > no modules.
> 
> That's not entirely true; there's (experimental ?) work for dynld(2), and
> the shipping compilers can already produce DLMs.  (That said, libdynld is
> not yet part of the base system.)  dynld(2) provides a system reminiscent of
> dlopen() and dlsym(), but no dynamic linkage is supported (only dynamic
> loading).  It is quite tastefully done and is useful to have for some
> applications (the python port springs to mind).

Is dynamic loading and linkage something that people want?  I have some old
experimental code written in Spirit++ (a C++ template library which
functionally replaces lex and yacc, and reads like EBNF).  The old code is for
a runtime polymorphic parser for RS274 (CNC g-code).  I was experimenting with
parsing historic CNC code, and play with different geometry engines.  This old
project is WAY down on my to-get-around-to list, but it might be an
interesting testbed for something later on.  This would be useful for stuff
like a motion controller for the RepRap and DIY 3D Fab machines.

For that matter, is there anything like Spirit++ <http://boost-spirit.com> in
Plan9/Limbo?  When I developed the code for my fist thesis I developed a
parser for some oddball finite difference equations produced by some modeling
software.  It was nice to have the code read like EBNF.

  EBo --

[9fans] int errno / errno.h patch

[EBo]

While working on gentoo ebuilds for plan9port, glendix, etc., I came across a
patch in Powerman's portage overlay for plan9port.

===
--- plan9/src/cmd/9660srv/main.c.orig   2009-12-11 19:18:18.0 +0200
+++ plan9/src/cmd/9660srv/main.c2009-12-11 19:18:43.0 +0200
@@ -38,7 +38,7 @@
 uchar mdata[Maxiosize];
 char fdata[Maxfdata];
 uchar statbuf[STATMAX];
-int errno;
+#include 
 
 
 extern Xfsub   *xsublist[];
===

should the base source include this patch?

  Best regards,

  EBo --

[9fans] compiler warnings for libavl/avl.c

[EBo]

The following two subroutines are defined and not used anywhere.  Should they
redefined as void or possibly removed?

  EBo --



static void
walkavl(Avl *t, void (*f)(Avl*, void*), void *v)
{
if(t == nil)
return;
walkavl(t->n[0], f, v);
f(t, v);
walkavl(t->n[1], f, v);
}

static void
checkparents(Avl *a, Avl *p)
{
if(a == nil)
return;
if(a->p != p)
print("bad parent\n");
checkparents(a->n[0], a);
checkparents(a->n[1], a);
}

Re: [9fans] compiler warnings for libavl/avl.c

[EBo]

> > The following two subroutines are defined and not used anywhere.  Should 
> > they
> > redefined as void or possibly removed?
>
> it's perfectly reasonable to leave code in for testing purposes
> that never gets called.

Agreed.  Should the declarations be changed then to void instead of static
void so that it does not give warnings?  I've worked on some projects where
the leads where very pedantic about cleaning up all warnings and was wondering
what the consensus amongst the plan 9 crowd.

> > -int errno;
> > +#include 
> >  
> > should the base source include this patch?
> 
> what's the advantage?  the current p9p system
> has worked for a long time.  including errno.h
> seems like it has the potential to break a lot of
> stuff.

I simply noticed the patch and was wondering if there would be any advantage
to including it, so I have no idea if there is any specific advantage.  I also
was not sure if this was simply a POSIX'ism or a 9'ism, and if this
could/should be cleaned up.

  EBo --

Re: [9fans] compiler warnings for libavl/avl.c

[EBo]

erik quanstrom  said:

> how about changing 9c so you don't get this warning?

At the moment the compiler is set to report all warnings (-Wall).  I would
rather ignore these two warnings then turn the warnings off.

Out of curiosity is there a reason why the subroutines should not be declared
void walkavl... instead of static void walkavl?  I understand that removing
the static declaration puts the two subroutines in question into global
namespace when linking to libavl.

I did a quick check and removing the static declaration removed the warnings,
and plan9port built without incident.

I hope I am not being annoying, I really am trying to get a sense of the
communities coding and process standards.

  Thanks and best regards,

  EBo --

Re: [9fans] int errno / errno.h patch

[EBo]

Russ Cox  said:

> It looks like deleting errno from that program
> would be an even better fix.

Hmmm... you are right.  All it does is set it to 0 and never uses it...

But for future reference should errno.h be used in Plan 9 programms or not?

  EBo --

[9fans] cleaning up gentoo plan9port ebuild

[EBo]

While working on merging and cleaning up the 3 or 4 different portage ebuild
trees for plan9 and plan9port I ran into a number of things which I need
clarified:

* Gentoo's plan9port report's the license as MIT, yet the LICENSE file says it
is Lucent-1.02. Which is correct?

* Gentoo's plan9port also sets DEPEND="x11-apps/xauth".  Is xauth a build or
runtime dependency?

* Am I correct in my understanding that the only two things that the install
configuration ("${PLAN9}/INSTALL -c") do is change the hardwired
/usr/local/plan9 paths, and build the documentation in $PLAN9/dist?

* I've built an updated live ebuild which works directly from the plan9port
mercurial tree.  Is there enough interest to request that this be added to
gentoo portage?

Thanks

  EBo --

[9fans] GSoC application template/examples

[EBo]

Is there an application template and/or copies of previously successful GSoC
applications available?

  EBo --

Re: [9fans] GSoC application template/examples

[EBo]

> Is there an application template and/or copies of previously successful GSoC
> applications available?

I should rephrase that -- are there any changes that should be made to the
2008 application template for current applications?

  EBo --

Re: [9fans] cleaning up gentoo plan9port ebuild

[EBo]

Andy Spencer  said:

> I think it would be a runtime dependency, xauth pulls in all the X11
> libraries so you can X forward the GUIs from a headless machine.  On the
> other hand, most of my binaries seem to be statically linked, so I'm not
> sure.

I had fixed it as:

DEPEND="x11-apps/xauth"
RDEPEND="${DEPEND}"

which appeased the reviewers, and seems to be the proper fix.

> I would like a live ebuild in portage, or at least an updated version of
> the tree. I have a live ebuild that I wrote a while back already, but it
> has a few bugs. There's a related gentoo bug:
> 
>   http://bugs.gentoo.org/show_bug.cgi?id=273890

Your ebuild is the one I started from.  Thanks!  While they had me tweak a
bunch of stuff to pass Sunrise review, the only real problem is that
plan9port.tgz is updated on a regular basis and the ebuild expects any source
to be static and pass a MD5 check (IIRC) unless it is specifically set up for
CVS, SVN, Mecurial, etc.  This caused the ebuild to fail its check the next
time plan9port.tgz was updated.  I've since rewritten it for mecurial.  There
is still an issue with the "mv * "${D}/${PLAN9}", but there are issues with
using "doins -r" as it strips the executable bit off all files installed, and
"dobin" sets everything to executable...

I'll post a reply to bugs.gentoo and make a point to sent it to you when I
finish the Sunrise review of my recent changes.

  EBo --

Re: [9fans] cleaning up gentoo plan9port ebuild

[EBo]

> > > * Gentoo's plan9port also sets DEPEND="x11-apps/xauth".  Is xauth a
> > > build or runtime dependency?
> > ...
> 
> i think it's neither.  xauth is an application.  and the x libraries are not
> staticly linked:
> ...

OK.  I dug a little deeper and found that rio uses x11-libs/libX11 and
x11-libs/libXext as build dependencies.  These I think are the correct ones to
use and not xauth.  This does raise the issue then if the gentoo ebuilds
should conditionally use X and not build rio if you do not want rio on a
non-gui system.  That will of course be an issue for a program specific ebuild
system and not for plan9port.

  EBo --

[9fans] build system: [was: (no subject)]

[EBo]

> Of course, one would then be tempted (as I have been) to look more
> seriously at porting the NetBSD package system to Plan 9.  That's not
> out of the question, in fact it's probably not too difficult, but the
> residual pain of autoconf for each individual package has already
> frightened people with a stronger stomach than mine away.  That is why
> I cannot suggest we catch up, but it may be nice to be ready when
> eventually the autoconf edifice falls down and something mildly
> intelligent takes its place!
> 
> Ironically, Plan 9 may be the platform on which a replacement for
> autoconf could be designed and implemented.  But that's too close to a
> pipedream to be given serious consideration.

Take a look at Boost's port of Perforce Software's build tool Jam
<http://www.boost.org/doc/tools/jam/index.html>.  What little I have used it
in the past it came across as a much more elegant tool-chain.  Now what I
would LOVE to see is a port of Joel de Gusman's Spirit++.  Well I can dream
cannt I ;-)

I've also started on updating an old per-application portage ebuild based on
Anant's work back in 2007.  If that is of any interest maybe I could get you
to either collaborate or just do a little testing.

  EBo --

Re: [9fans] build system: [was: (no subject)]

[EBo]

Sorry for disappearing since last Friday -- emergency house repairs.  Uggg
I feel like I've been beaten by mutant ninja dwarfs armed with...  something
only semi soft.  Uggg.

> here's the full list of dynamic libraries used on
> a random gentoo box i tried:
> ...
>   libX11.so.6 ...

updated the ebuild.  I did not know about ldd.  Thanks!

I'll send this for a final Gentoo-Sunrise review before submitting
both updated date specific versions and a live mercurial ebuild AFTER
Fridays GSoC deadline.

> > I've also started on updating an old per-application portage ebuild based on
> > Anant's work back in 2007.  If that is of any interest maybe I could get you
> > to either collaborate or just do a little testing.
> 
> p9p is ment to work as a unit.  i think it would
> be better if you didn't.

sorry for not being clear.  I am working on ebuilds for plan9port,
glendix, and (cross)compilation of an entire Plan9 system.
Per-application ebuilds are only appropriate for glendix kernel and
compilation of Plan9.  But if people think that it is a red herring
I'll drop the latter.

  EBo --

[9fans] glendix/plan9port/plan9 ebuilds [was: build system

[EBo]

> Is there any latest news on Glendix at this point?  Last I'd heard they had
> Plan 9's binaries supported at the kernel in at least some basic way.

I've only had a little interaction with the Glendix folks, and know little
more than it supposedly supports Plan 9's binaries at the kernel, as you say
at least some basic way.  I did get some feedback that my glendix-sources
ebuild (on the Gentoo-Sunrise overlay) worked out of the box.

What I do know is the main mover/shakers (at least as the GSoC is concerned)
cannot function as mentors, even though Gentoo has it listed on their ideas
page -- I need to contact Gentoo about that and make sure everyone is on the
same page.  That being said it is rather easy for me to support the glendix
kernel and plan9 ebuilds once polished up.  It was simply some of the
background/getting-ready work for applying to this years GSoC.

  EBo --

[9fans] testing please ignore...

[EBo]

I just updated my email SPAM filter to get non-digested emails and I do not
think I am getting any postings... testing...

sorry for the bandwidth.

  EBo --

Re: [9fans] plan9 on qemu and 9vx

[EBo]

> Unless there's some compelling reason to use qemu (I can't think of
> one) why not just use 9vx exclusively? I've made a transition over the
> years:
> qemu
> xen
> kvm
> lguest
> 9vx
> 
> And am stuck at 9vx ...

So, are you more interested in 9vx than lguest?  Or have I misinterpreted what
you ment by stuck ;-)

  EBo --

Re: [9fans] plan9 on qemu and 9vx

[EBo]

> > So, are you more interested in 9vx than lguest?  Or have I 
> > misinterpreted what you ment by stuck ;-)
> 
> Just going by performance and portability, 9vx is a way better way to
> go than lguest.

I have to take a look at it later then.

  EBo --

[9fans] partdisk fails in install

[EBo]

I'm having trouble installing on a clean disk with the latest iso (2010/3/12).

I first removed all the partition info (using fdisk on a gparted liveCD) so
that the disk was clear.  I then booted Plan9, and when it asked to install a
MBR, it returned an error that disk/fdisk failed.  This then caused parted to
restart in a loop...  Unfortunately it did not give me much additional info.

I'm hoping to get Plan9 and Inferno installed native and VM on all my
development machines so I can test both versions in various configurations. 
Unfortunately, it does not look like Plan9 will install native on any of my 3
machines so far.  One more to try...

  EBo --

Re: [9fans] partdisk fails in install

[EBo]

It will have to be later this afternoon/night.  I thwacked the disk with
gparted and gave it a couple of partitions, and am installing it on that
machine at the moment.  I at least want to see how far this install gets
before thwacking the disk again, and in a few I have to pick someone up at the
airport...

I will also go through the routine with all my machines and collate the info.

Thanks for the offer.  I look forward to sorting this out a little later.

  EBo --


erik quanstrom  said:

> > I'm having trouble installing on a clean disk with the latest iso 
> > (2010/3/12).
> > 
> > I first removed all the partition info (using fdisk on a gparted liveCD) so
> > that the disk was clear.  I then booted Plan9, and when it asked to install 
> > a
> > MBR, it returned an error that disk/fdisk failed.  This then caused parted 
> > to
> > restart in a loop...  Unfortunately it did not give me much additional info.
> 
> if you could send me some information (off list),
> i'll take a look at this.
> 1.  the exact error message that you see.
> 2.  at the installer prompt, after then fdisk error,
> the output of "!cat /dev/kmesg".
> 3.  the output of lspci -n (or similar) from linux
> (or whatever).
> 
> - erik
> 



-- 

[9fans] install filsystem hangs on bad block

[EBo]

Doing the initial native installation on an hpze1115, the installation hangs
when copying to disk.

Background:
  The old laptop has a disk which is known to have as many as 100 bad blocks,
but has continued to function fine.  While running copydist, the install ran
into the following errors then hung:

--
fossil: diskWriteRaw failed: /dev/sdC0/fossil: score 0x: date ...
  part=superblock 0: i/o error
fossil: diskWriteRaw failed: /dev/sdC0/fossil: score 0x0041: date ...
  part=label block 65: i/o error

and it hung at 65% installed.  I'll try a different partition.  

Gots to go...

  EBo --

Re: [9fans] install filsystem hangs on bad block

[EBo]

> > fossil: diskWriteRaw failed: /dev/sdC0/fossil: score 0x: date ...
> >   part=superblock 0: i/o error
> > fossil: diskWriteRaw failed: /dev/sdC0/fossil: score 0x0041: date ...
> >   part=label block 65: i/o error
> 
> those scores look funny.  so also to keep in mind, ...
> 
> fossil i/o can fail for lots of reasons that don't have
> anything to do with the disk.  for example, if its partitions
> are set up incorrectly.  (the installer is not infallable.)
> 
> it would be good to double-check that your partition
> sizes make sense.

I forget the disk portioning I first set up, but I think that it was 3
consecutive partitions with 20G each, then a forth (logical) with the rest of
the 120G drive.  I had not split up the logical partition yet.  Actually I
think it tried to use the logical one (p4).  I'll try this again again later.

Thanks for taking look at this!

  EBo --

Re: [9fans] install filsystem hangs on bad block

[EBo]

> > it would be good to double-check that your partition
> > sizes make sense.

I was finally able to replicate two related problems.  

The first concerns the logical partition that was not further broken into
partitions..  I was able to verify that the install would install directly
onto the logical partition and copying of the os would then cause write errors
later on.

The second problem arose when I repartitioned the disk with partdisk and it
did not appear to have been updated when I continued with the install.  I
wonder if the partition map had not been updated with plan9's partprobe
equivelent.

  EBo --

Re: [9fans] install filsystem hangs on bad block

[EBo]

Yes.

As a note, I kept having write errors pop up, so I ran a low level disk
format.   So far it is running better, but have not tried to replicate various
weird things I tripped over earlier.  I'll try that again later.

  EBo --

erik quanstrom  said:

> > The second problem arose when I repartitioned the disk with partdisk and it
> > did not appear to have been updated when I continued with the install.  I
> > wonder if the partition map had not been updated with plan9's partprobe
> > equivelent.
> 
> did you type 'w' then 'q' at the fdisk, the prep prompts, thus accepting
> and writing the defaults?
> 
> - erik
> 



-- 

Re: [9fans] install onto P5Q-Pro SATA drives

[EBo]

erik quanstrom  said:

> > (1) It looks like to be able to read SATA CDROM, such that we
> > can see directories, files at the top level of /n/cdrom.   
> > However, it fails to read the files under deeper levels,
> > say such as /n/cdrom/sys/src/9/pc/pc.  In short we cannot read
> > cdrom correctly.
> 
> if you want to try the new sata stuff, there's prebuilt kernels and
> source at ftp://ftp.quanstro.net/other.

There appears to be over 30 different downloads there.  Is there any metadata
(or README) detailing any of these?  The *atom* are most likely for the atom
processors, but I'm not sure about the others.

Of the 4 systems I have tried to install plan9 onto, the only one I was able
to get installed was a very old dual PIII-500, and even that is still not
completely functional.

  EBo --

Re: [9fans] recreational programming of an evening

[EBo]

> ...
> 
> Screen shot attached, this is pretty handy for me and if you want my
> patch to 9vx let me know. What's interesting to me about this is that
> I can not imagine even attempting this on any other os or windowing
> system. It was just too easy on Plan 9 however.

I for one would enjoy seeing it.  BTW, where should things like this normally
live?

  EBo --

Re: [9fans] recreational programming of an evening

[EBo]

> no, it's just badly designed. Working with a bad design gives me a
> splitting headache. I make my living doing linux but that doesn't mean
> I have to worship at the altar, right?

To bad plan 9 was publicly released just after Linus started working on Linux.
 Oh well.  It's all about timing.

  EBo --

Re: [9fans] recreational programming of an evening

[EBo]

> > I've wanted to do something like this for a while, but it's hard to
> > find a publisher for such a thing.
> 
> Self-publish it. You'll probably end up pocketing more money, anyway,  
> vs. having someone else do it.

That is not the worst of it.  You usually have to sign first rights of refusal
for everything you ever do .  So, if you ever want to write a second edition,
or a different book, it might cost you more money than you ever made just to
get out of that contract.  That is happening to a friend of mine whose book
was published by a small academic press that was later bought out by Wiley...

Look at Lulu.com.  They will publish ebooks as well as paper.  The costs are
very reasonable.

  EBo --

Re: [9fans] recreational programming of an evening

[EBo]

> It took nearly 10 years for Plan 9 to be released open-source, but I  
> think the bigger issue would have been people not "getting" the Plan 9  
> way then, just as they don't "get" it now.

Most people do not "get" Linux or UNIX internals for that matter.  Maybe 1 in
100 users have a clue.  The difference would be to have started from an
elegant and consistent design.

  EBo --

Re: [9fans] recreational programming of an evening

[EBo]

No!  I'm glad that it is open source.  I would not have even given it a second
glance if it was not.  If Linus had access to Plan 9 as a base I think things
could have looked very different now, and possibly for the better.


> I don't get your reasoning. Do you want to say we would be better off
> if they had not released it?!
> 
> On 3/21/10, EBo  wrote:
> >
> >> no, it's just badly designed. Working with a bad design gives me a
> >> splitting headache. I make my living doing linux but that doesn't mean
> >> I have to worship at the altar, right?
> >
> > To bad plan 9 was publicly released just after Linus started working on
> > Linux.
> >  Oh well.  It's all about timing.

Re: [9fans] Install CD hanging on "probing floppy"

[EBo]

I've been having similar trouble trying to install native on 3 of my 4
machines.  Using an old PIII-500 box I was finally able to get it running once
I reconfigured some of the hardware.  Once I got that running I started
hammering on my my new Gateway.  The issue I appear to be having on my other 3
machines is that they all, if I'm not mistaken, is they all have SATA drives.
 When I plugged an IDE DVD into the gateway it booted.  Unfortunately it is
not seeing *ANY* of my 3 SATA devices.  I've had similar problems with my Acer
laptop.  I'm currently doing a backup of one of my old IDE backup hard drives
so I can plug that in and see if that will work.

Can you give us a link to your ISO's for us to try?

  Thanks and best regards,

  EBo --


cinap_len...@gmx.de said:

> 9load will be gone soon.  muzgo and i are working on 9pcload wich will
> use /dev/reboot to start the final kernel and use the native plan9
> drivers.  9pcload will itself be loaded by some simple bootblocks.  we
> have iso (el torito in non emulation mode - no floppy emulation) and
> pxe working already.  for harddisk here are lba and chs bootblocks
> available that load 9pcload from a patchable lba offset and a multi
> staged loader that will detect lba/chs automatically and is more
> flexible on finding 9pcload is in the works.
> 
> this terminal and my thinkpad are already network booted without any
> 9load involvement!
> 
> :)
> 
> --
> cinap
> 



-- 

Re: [9fans] Install CD hanging on "probing floppy"

[EBo]

> ...
> > PBS1...Plan 9 from Bell Labs
> > ELCR: 0E20
> > pcirouting: 8086/24DB at pin 1 irq 5
> > cpu0: 2793 MHz Pentium IV/Xeon loop 53571
> > apm ax=f000 cx=f000 dx=fdf9 di=0 ebx=100469 esi=0
> > found 5 e820 entries
> > 
> > ...and then freezes.
> 
> i've experienced this too.  but not on a pentium iii machine.

I think his is a pentium iv and the p-iii runs, but the new gateway (AMD
Phenom(tm) II X4 805 Processor) is the one that hangs.  Also, that is *with* a
sata cdrom.  Actually, poking around I've found a possible bios bug.  turning
off the ide support in the bios helps the cdrom to work, -- it runs, but not
installs -- because it cannot see any of the sata disks.  When I swap out the
sata dvdrom for an ide-dvdrom, enable both ide and sata (ahci) it installs,
but then has trouble booting...

One bright bit of sucess: I was able to install 9atom on my Acer 5720z laptop
-- but the thernet is not recognized.  That is why I am hammering some more on
the gateway dx4300 -- at least it is open archecture and I can install an old
3com 100bT connection...

> the root of the problem is that ich5 (8086/24db) is one of
> intel's first attempts at a sata/ide controller, and it doesn't
> work very well.  there are ways for the sata controller to
> wedge the ide side of things, and vice versa.
>
> 9atom has a number of defenses against this.  you may
> be able to boot with it, but mixing sata and ide on ich5
> basically doesn't work.  the easy and cheep solution is
> to get a sata cdrom.

Maybe it is some weird compatibility issue with the specific DVD...  It was
the one that came from the manufacturer...

I'll keep banging on this and post any updates I find.

Oh, before I forget.  Eric, thanks a LOT for providing the 9aton ISO!


  EBo --

[9fans] limited success [was: Install CD hanging on "probing floppy"]

[EBo]

Well it looks like I *finially* got my Gateway DX4300 to install and
run Plan9 (using 9atom version 3/19/2010).  I've decided to post the
following notes for the poor saps using the DX4300 for just about
anything, because I've read various posts with people having trouble
with these MB's.  Also, I hope that this might be useful as an
overview for those having weird SATA problems installing and running
Plan9.

Overview:

  As Erik Quanstrom pointed out, some of the EIDE/SATA interface
  chips are buggy, and one should not mix/match devices.  The problem
  on my machine is installing plan9 on any SATA hard drive on a
  DX4300 causes weird problems. (Maybe we can sort it out later, for
  for now a mixed IDE/SATA setup works.

  The DX4300 appears to have two SATA controllers.  The first
  controls SATA 1-4, they can be disabled, and have their mode set.
  The second, SATA 5-6, is always on and you have no control over the
  mode, etc.  My first success with plan9 on this machine was
  achieved by unplugging *all* SATA devices and booting off an EIDE
  CDROM and disk.  Once this worked I reconfigured one device at a
  time, reinstalled, tested, etc., until I ended up with what seems
  the most stable configuration.

  An interesting aside, on this MB, if you use SATA5/6, then the
  devices show up as hd*, and if you use SATA1-4 they show up as
  sd*.  This solves some anoying problems on this MB for Linux users
  who find that their drive letters float around alot...


Notes on Interesting Configurations...

=

SATA(6) - CDROM
SATA(5) - 1TB Disk
EIDE(M) - 250G Disk (DMA-0 must be set)

EIDE - Enabled
SATA - Enabled
  mode - Native IDE

This appears to be the most stable configuration.  It will boot Plan
9 from the CD, Linux from the SATA HD, and Plan9 from the IDE HD.
Booting plan9 from the SATA HD gives the following errors:

Plan9 on SATA(5):

  PBS2...
Plan 9 From Bell Labs
ELCR: 0C80
pcirouting: South bridge 1002, 439D not found
dev A0 port 1F0 config 427A capabilities 2F00 mwdma 0007 udma 047FLLBA
sectors 1953525168
dev B0 port 1F0 config 85C0 capabilities 0F00 mwdma 0007 udma 013F
dev A0 port 170 config 427A capabilities 2F00 mwdma 0007 udma 013FLLBA
sectors 488397168
.
1. 1
2. 1
3. none of the above
*nobiosload: 

Booting from the EIDE MBR and using sdC0!9fat!9pcf (which is the SATA
drive, gives the following errors:

ELCR: 0C80
pcirouting: ignoring south bridge PCI.0.20.3 1002/439D
..
ohci interupt: unhandled sts 0x0040
ohci interupt: unhandled sts 0x0040

   and here is where it hangs.

In order to get this to work please note that I had to boot Plan 9
with nodma, and actually set the EIDE disk DMA to 0 in the BIOS.  I
have since then added extra SATA drives to 1+2, and they appear to
function properly.

=

SATA(6) - CDROM
SATA(5) - 1TB Disk
EIDE(M) - 250G Disk

EIDE - Enabled
SATA - Enabled
  mode - Native IDE and ACHI

This configuration will boot from the CD, Linux from the SATA HD.
Grub and Plan9 cannot see the IDE HD.  Attempting to boot plan9 from
the SATA HD gives the same *nobiosload error as above.

=

SATA(6) - CDROM
SATA(5) - 1TB Disk
EIDE(M) - 250G Disk

EIDE - Enabled
SATA - Disable

This configuration will boot from the CD, Linux from the SATA HD,
plan9 from the IDE HD, but plan9 from the SATA HD gives the same:

  ohci interupt: unhandled sts 0x0040

errors from above.

=

[9fans] VIA Rhine II support?

[EBo]

Searching the net reveled that Stephan got his VIA Rhine II ethernet working a
couple of years ago.  Where can I find the patch or drivers?

  EBo --

[9fans] native install

[EBo]

I just wanted to take a moment to thank Iru and Erik for their help with
getting Plan 9 installed natively on my 4 machines.  While I'm still having
some difficulties with SATA/IDE issues, and non-supported ethernet devices, at
least now I can test native support as well as hosted inferno, plan9port, and 
9xv.

  Thanks!

  EBo --

Re: [9fans] native install

[EBo]

> from 1 to 3. . .vmware or qemu (all of them).. . .i'm thinking
> in buying a modern PC in which i can run it natively...suggestions?

While I have not bought one yet (money's a little tight at the moment), take a
look at http://open-pc.com/.  At least since everything is open, even if the
device drivers are not available there is still a chance 

Re: [9fans] 9atom update

[EBo]

erik quanstrom  said:

> it appears that the problem EBo's been having has to do
> with an inproperly set ccrp with amd sb7xx (and possibly
> sb8xx southbridges).  since the ccrp was not set properly,
> sdiahci didn't recognize the ahci controller. this has been fixed.
> 
> many thanks to EBo for doing the hard work.

and much gratitude to you Erik for working through this with me.

Re: [9fans] VIA Rhine II support?

[EBo]

> As with other things Via, I'd recommend avoiding Rhine chips like the plague.

this is not a new buy, but an 8 year old laptop I'm playing with.  At least
the Rhine chip has better support than Broadcom as far as I can tell.  Now
*THAT* is company I avoid like a plague...

Re: [9fans] Man pages for add-ons

[EBo]

> i vote for putting the binaries in /$objtype/bin or /$objtype/bin/tex.
> in the latter case, it would be tex/tex or tex/mf.

I'm a total plan9 newbie, but I hate polluting / with every single
application.  I do prefer to have all apps in a single package directory 
/$some_dir/$objtype/bin  where $some_dir is /opt, /pkg, /contrib, etc.  I do
not know if this would fit in well with the plan9 way though...

Re: [9fans] Man pages for add-ons

[EBo]

erik quanstrom  said:

> > I'm inclined to this kind of stuff too, since it's easy to "rm -fr" if
> > everything is simply in the same place.
> 
> replica should make such concerns moot.

I've taken a quick look at the docs, but it is intended to be a per-package
management tool?  Typically my concerns are setting up canonical
versions/'dates which are known to be stable so testing can be done on
multiple known code revisions.  How does one do that with replica?


  EBo --

Re: [9fans] Man pages for add-ons

[EBo]

> > I'm a total plan9 newbie, but I hate polluting / with every single
> > application.  I do prefer to have all apps in a single package directory 
> > /$some_dir/$objtype/bin  where $some_dir is /opt, /pkg, /contrib, etc.  I do
> > not know if this would fit in well with the plan9 way though...
> > 
> You wouldn't be `polluting' / with every single application. Binaries would
> either go in $user/bin and would be then be bind-ed to /bin, or binaries would
> just go in /$objtype/bin. No `pollution' here.

Following on what Ron said earlier, I prefer to leave / untouched.  If
programs are installed into /$app_name/..., you end up with variants of
/acme/*, /rc/*, /tex/*, /troff/*, /tex/*, /my_fav_pub_app/...  That is what I
meant by pollution.  Do you consider this desirable?  Maybe we are talking
apples and oranges here.  I'm also talking about system wide apps on a
multiuser system.  So, for example, your /$objtype/bin would look something
like /sys_apps/$objtype/bin, and /sys_aps would contain all system wide,
non-OS distributed, applications.

Hope I have not offended here.

  EBo --

Re: [9fans] Man pages for add-ons

[EBo]

Anthony Sorace  said:

>   Unix has two camps for approaching this problem /usr/local and /opt.  
> While they're almost never followed well on modern unix systems, the  
> idea is basically a global local overlay vs. a per-package overlay.
> 
>   The /usr/local approach takes all packages not part of the base  
> system and creates a "local root", a global mirror of (roughly) the  
> root file system. Those poor souls don't have bind to work with, so  
> everything ends up "knowing" to look in /bin and /usr/local/bin, /etc  
> and /usr/local/etc, and so on. Packages from multiple sources are all  
> intermixed in one /usr/local, so you've basically got the base system  
> vs. everything else. EBo's /sys_aps is basically a recreation of /usr/ 
> local.
>
> ...

Actually no.  I am advocating for the /opt (per-package) model.  Sorry that
was not clear.  I simply called it sys_apps in an attempt to make it clear
that I was talking about installed system wide apps.  Sorry for not being 
clearer.

  EBo --

Re: [9fans] Man pages for add-ons

[EBo]

"Federico G. Benavento"  said:

> other thing that deserves noticing is that there are 2 kind of needs
> for packages, some people want to develop or like knowing what's
> going on, so replica works for us as we get to see what files were
> modified and when.
> 
> contrib(1) was written with this kind of user in mind, try to convince
> erik to drop replica and you'll hear the justifications :)

;-) I'm learning more about these things all the time.

> on the other hand you people that don't care about the source and
> just want to run their apps, for those a package system that with
> only runtime stuff makes more sense.

I see this as a little more complicated for two reasons.  1) administrating
distributed systems with group supplied applications that are widely used but
not part of the OS, and 2) maintenance and development cycles.  How do you
propose managing the source/executables for ver 1.* (stable) 2.* (stable), 2.*
(experimental), and maybe even 1.* (backport)?  Even for my personal stuff I
have had lack of versioning bite me -- I was working on a spatially-explicit
modeling project, and had made some updates.  One of the ecologists came in
and asked me for some data which was not generated in the original modeling
runs, so I added it... only to find that the new version of could not read the
old input...  Took days to reconstruct everything.  To make matters worse,
this was in response to a review in a good journal, so time was of the
essence.  So, in this case I had maybe 20 users at 6 universities in 3
countries running at least two incompatible versions.  When I talk to these
people I needed to know which they were using, and fix any bugs for the
appropriate version.  I cannot expect them to stop what they are doing and
simply upgrade at my whim.  I should also note that it often takes 1.5 to 5
years from the start of an ecological field project to when it is published. 
So, users might be using a given version of software for years before they
complete their projects.

As a note, I do not care how these things are accomplished, only that I can. 
It may be that there are ways (replica & contrib) which allow for this level
of control, but I have yet to figure it out.

> on lunixes you have binary packages and then you use svn/hg/whatever
> to get the source and get synced.
> 
> to me this is the real question, not where do we put the binaries,
> the latter is just a convention and taste related, while the first
> is an actual problem for some.

I see this as another very important, but separate, issue.

  EBo --

Re: [9fans] ken-cc, 64 bits machine, and 32 bits integers

[EBo]

> with kenc, long === 32 bits even on 64 bit machines; there is no
> difference in storage size between long and int.

out of curiosity, does kenc implement long long's?

Re: [9fans] using usb

[EBo]

> plug it, run usbfat:
> and go to /n...
> 
> see its man page.

usbfat: does not work consistently on my machines, but I was not going to
mention that until I spent enough time to try to figure out why.  So, try it,
it might work for you.  If it does not also try running usb/disk /dev/sdU*
(where * is the usb device) and then try running usbfat:  For some reason that
seems to work for me most of the time.

As a note, the problem with the USB is probably more systemic -- I even lost
my USB mouse for awhile after I rebooted into Linux.  I had to unplug the
machine a couple of times before it came back.  Not sure what's up with that.

  EBo --

Re: [9fans] using usb

[EBo]

Francisco J Ballesteros  said:

> If you have some problems I could reproduce, I'd like to know.

certainly!

Figuring this out is much lower on my priority list than finishing my GSoC
applications and moving forward on some technical stuff for my thesis, but is
annoying enough that I'll probably get back at it sooner than later.  If I do
not write you with some info within the next two weeks, give me a ping and
that will probably be a good window of opportunity.  I may have simply forgot. 

One thing that I have noticed though is that if I boot the machine with the
thumb drive in, then it often comes right up.  I do not know enough about Plan
9 devices and drivers yet to say much about that...

As a note, the BIOS on my primary machine is really buggy, and there are
actual configurations which cause the machine to reboot in the middle of
posting and it never even gets to the point of reading any MBR or boot device
(just starting up, and up, and up...)  It may be that the current
configuration is not quite stable enough and is screwing with the usbdevices.
 I actually need to post a couple of bug reports to Gateway (now I am begging
to remember why I swore off buying their products 20 years ago...)

  Thanks and best regards,

  EBo --



> thanks
> 
> On Wed, Mar 31, 2010 at 1:49 PM, EBo  wrote:
> >
> >> plug it, run usbfat:
> >> and go to /n...
> >>
> >> see its man page.
> >
> > usbfat: does not work consistently on my machines, but I was not going to
> > mention that until I spent enough time to try to figure out why.  So, try 
> > it,
> > it might work for you.  If it does not also try running usb/disk /dev/sdU*
> > (where * is the usb device) and then try running usbfat:  For some reason
that
> > seems to work for me most of the time.
> >
> > As a note, the problem with the USB is probably more systemic -- I even lost
> > my USB mouse for awhile after I rebooted into Linux.  I had to unplug the
> > machine a couple of times before it came back.  Not sure what's up with 
> > that.
> >
> >  EBo --
> >
> >
> >
> 



-- 

Re: [9fans] MPI

[EBo]

> I'm about to start a course that goes by the title of "Computational
> Physics", and as I was having a look at the items that we are going to
> cover, and saw that there's an "Introduction to parallel computing and
> parallel programming with Message Passing Interface (MPI)". Some of
> you 9fans may be familiar with this protocol, any comments on it? can
> you recommend a book on this topic (not MPI, but concurrent stuff in
> general)? how plan9 solves this problem, if at all? Any feedback is
> welcome ☺

the open source implementations of MPI (mpich1, mpich2, openmpi) all have
little examples to play with and get started -- and also test the
installation.  I would recommend to start by playing with those.  

It has been years since I had taken the initial intros to MPI/PVM, but at the
time the supercomputer center had some nice tutorials and online
documentation.  So, I would search a number of these installations.

Other than that, you might want to download some of the models which use MPI
and possibly play with them.  Depending on the size of the codebase this might
scare you off a bit, but I actually find playing with the GCM WRF and RegCM3
rather enlightening once I got past the initial frustrations...  On second
thought I never got over my frustrations, but this brings me to a pet peve --
if you are looking into modeling and are not a computer scientist by training,
PLEASE, PLEASE, PLEASE at LEAST sit in a course on algorithms and data
structures, and possibly another one in software engineering.  For all the
theoretical physicists, ecologists, biologists, sociologists, and economists I
have worked with, I have yet to meet one which have had more than a practicum
in FORTRAN and/or C/C++.  If you already have a CS background, you come to
understand why some of the code still makes me twitch...

Re: [9fans] MPI

[EBo]

> > wrong list
>
> Wrong answer... He was also asking about any libraries or technologies that
> Plan 9 might have, no one has answered that part of the question yet as far
> as I know.

ahhh... I missed that.  I do not have all my lit integrated into bibtex yet,
so here are some URL's and citations that might be of interest:

  http://www.usenix.org/events/usenix07/posters/vanhensbergen.pdf 

  "Experiences porting the Plan 9 research operating system to the IBM Blue
Gene supercomputers" (Minnich and Mckie, 2009)

  "Grid Computing with Plan 9: an Alternative Solution for Grid Computing"
(Mirtchovski, 2005)

  "System Support for Many Task Computing" (van Hensbergen and Minnich, 2008)

Actually replacing MPI/Globus with Plan9 is something that I am interested in
myself.  I personally would love to find some exemplar programs for plan9 and
Inferno which I could study.  They are probably around, but I have not made
time to dig them up yet.

  EBo --

Re: [9fans] MPI

[EBo]

> I must admit that, in general, physicist, astrophysicists and
> astronomers are very bad programmers. I've worked with all those
> breeds and we really suck. 

referring to we, I take it you are one of them.  

> Maybe the fact that I've read, and solved
> almost all the exercises from "the practice of programming"
>  and K&R's "the c programming language" will make you feel better.
> Currently I'm going through Aho et al. "the awk programming language",
> and then I'm planning to move to "The Unix Programming Environment".

from this I realize that you are well on your way, and I stand duly
chastised...  In other words I think I have finally met one.  Thank you sir,
may I have another!  ;-)

> Coming back to the subject, I'll start with your recommendations and
> Andrew's. Probably this is just a newbie talking, but it seemed to me
> a kind of problem easily solved with file servers and 9p; but again,
> this was only my first impression.

Some of the people here are the authorities on those subjects, and wish you
the best in your endeavors.

  Best regards,

  EBo --

Re: [9fans] using usb

[EBo]

> when I run usbfat: I got this:
> bind: #u: unknown device in # filename
> no #u/usb
> 
> and there is not any lights from the pendrive, I think that the
> pendrive is not detected.

I know this sounds weird, but unplug the power to the machine for a half
minute and power it back up and boot off the same kernel.  See if it happens
again.

I had had my USB ports disappear a couple of times after playing with plan9,
and it even persisted after rebooting into Linux.  I have no idea what would
have caused that, and have not had time to try to reproduce.

Re: [9fans] MPI

[EBo]

> > These new flint arrowheads are state of the art! I always use them for
> > HPC with my MPI code!
> 
> With some ancient Fortran sprinkled in?  :-)

Now were were those Jacquard loom plates I had sitting around?  Are we done
with out multi-tread processing testing?  You know that was a real warped
setup... :-)

Re: [9fans] tinycore 9vx .tce on sources

[EBo]

> --rw-r--r-- M 26 rminnich sys8805 Apr  3 17:41
> /n/sources/contrib/rminnich/9vx.tce

Thanks, I've downloaded this and will play with it later...

> Questions? Let me know.

will do.

> Thanks

Thank you!

  Laters,

  EBo --

Re: [9fans] native install

[EBo]

Actually I would like to see this too.  Maybe if you could post the specs to
the list it would generally be helpful.

> I'm going to be buying something soon. I'd like to follow your lead.
> > I recently built a machine using a dualcore atom card from supermicro
> > its quick, draws very little power and is rock solid.
> >
> > email me for the details if you like.

[9fans] 9vx patch to read environment var PLAN9

[EBo]

The following is a little patch to 9vx which uses getenv to read the
environmental variable PLAN9 to set "plan 9 root" on startup if it has not
been overloaded on the command line or in the CWD.  I would enjoy any feedback.

Best regards,

  EBo --

=

diff -r 8184025094f4 src/9vx/main.c
--- a/src/9vx/main.cMon Oct 05 02:53:41 2009 -0400
+++ b/src/9vx/main.cSun Apr 11 11:59:03 2010 -0500
@@ -10,6 +10,8 @@

 #include   "u.h"
 #include   "libvx32/vx32.h"
+#include   
+#include   
 #include   
 #include   
 #include   
@@ -224,12 +226,13 @@
 findroot(void)
 {
static char cwd[1024];
+   static char plan9[1024];
int i;
char buf[1024];
char *dir[] = {
cwd,
-   "/Users/rsc/9vx",
-   "/home/rsc/plan9/4e"
+   plan9,
+   "/usr/local/plan9"
};

if(getcwd(cwd, sizeof cwd) == nil){
@@ -237,6 +240,9 @@
panic("getcwd: %r");
}

+   if(getenv("PLAN9") != nil)
+   strncpy(plan9, getenv("PLAN9"), sizeof plan9);
+
for(i=0; i= 0)

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

I thought p9p uses it for the root of the Plan 9 tree?  At least that is what
the ebuilds imply.  Maybe I am using the wrong term for what PLAN9 points to.

  EBo --


erik quanstrom  said:

> recommend using a different environment variable
> other than PLAN9, since that is taken by p9p to mean
> something else.
> 
> - erik
> 



-- 

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

Got it!  Changed.  I'll also change it along the lines of Erik's suggestion.

As a note, I thought that 9vx ran on top of the p9p stuff.

  Thanks again,

  EBo --


"Devon H. O'Dell"  said:

> 2010/4/11 EBo :
> > I thought p9p uses it for the root of the Plan 9 tree?  At least that is 
> > what
> > the ebuilds imply.  Maybe I am using the wrong term for what PLAN9 points 
> > to.
> 
> That's true, but in the case of 9vx, the tree it points to contains
> actual plan 9 binaries, whereas p9p binaries are compiled for the host
> system. Since it is very feasible that someone may run p9p and 9vx on
> the same machine (I do, for instance), it would be a good idea to not
> overload the env var.
> 
> --dho
> 
> >  EBo --
> >
> >
> > erik quanstrom  said:
> >
> >> recommend using a different environment variable
> >> other than PLAN9, since that is taken by p9p to mean
> >> something else.
> >>
> >> - erik
> >>
> >
> >
> >
> > --
> >
> >
> >
> >
> >
> 



-- 

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> I was going to suggest that, but you can't start env. var. names with
> numbers in many shells.

That's why I named it vx9root (not to screem).  ;-)

> > and there's no reason to shout.  :-)

[9fans] /sys/lib/newuser patch

[EBo]

I'm playing around with 9vx and have split up (re)building 9vx from the the
9vx root file system provided in the tarball 9vx-0.12.tar.gz

When I first start 9vx from a clean build and run /sys/lib/newuser it builds
the user directory in /$user instead of /usr/$user.  The problem appears to
arize from the following:


user=`{cat /dev/user}
home=/usr/$user
if(test -f $home/lib/profile){
echo user directories already made
exit no
}
cd $home


When we try to cd to $home, it does not exist (as checked by the previous if),
and $cwd is set to / by default...  The following patch simply makes $home
before cd'ing to it.

Is this supposed to be the expected nehaviour?

  EBo --

=
--- a/sys/lib/newuser   2008-06-30 08:44:02.0 -0500
+++ b/sys/lib/newuser   2010-04-11 15:36:41.865384817 -0500
@@ -6,6 +6,7 @@
echo user directories already made
exit no
 }
+mkdir $home
 cd $home
 x='$'
 mkdir bin bin/rc bin/mips bin/386

Re: [9fans] /sys/lib/newuser patch

[EBo]

> newuser assumes that your home directory exists, and on a
> normal plan 9 install, it's likely not possible to create anything
> in /usr without doing it on the fs console.

Maybe I am missing something here, but this is not a normal plan9 install, but
9vx.  There I can create a user's directory in $9vx_root/usr provided that the
permissions are open.

in the base system that came with 9vx I get an error that /src/fscons does not
exist when running "con -l /srv/fscons".

So, how is the initial setup supposed to be done on 9vx which defaults to a
$user instead of glenda

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> Why isn't 9vx -r yourdir good enough?

it is if you want to force all users to specify the root directory every
single time they run 9vx, or if you want to use an alternative root.  If I use
a standard install locations then we can either change "/Users/rsc/9vx" and
"/home/rsc/plan9/4e" or I can simply run a sed script during the build phase.
 Setting up a $root9vx (what I have changed it to) seemed the cleanest approach.

  EBo --

Re: [9fans] /sys/lib/newuser patch

[EBo]

Anthony Sorace  said:

> On a "real" plan 9 system, you create the user at the file server  
> console, then log in as that user and run newuser. That first step  
> creates /usr/$user. The analogue in 9vx is at least 'mkdir /usr/ 
> $user', and (less likely) possibly creating the actual user in the  
> unix world, depending on your intended setup.
> 
> Rather than see newuser create the dir if it doesn't exist, I'd rather  
> see it exit with an error in that case.

and have the 9vx tutorial explain that the user needs to create the directory
by hand if the file serve console is not working.  OK, this works for me, and
concurs with what Erik was saying.

  EBo --

Re: [9fans] /sys/lib/newuser patch

[EBo]

> create the user dir on the host machine. run 9vx -u $user and then run
> /sys/lib/newuser.
> 
> you seem to be following the wiki instructions on how to add a new
> user. they are not valid for 9vx, since it usually uses the hosts
> filesystem.

is there already a 9vx specific tutorial?

  EBo --

Re: [9fans] /sys/lib/newuser patch

[EBo]

Anthony Sorace  said:

> On a "real" plan 9 system, you create the user at the file server  
> console, then log in as that user and run newuser. That first step  
> creates /usr/$user. The analogue in 9vx is at least 'mkdir /usr/ 
> $user', and (less likely) possibly creating the actual user in the  
> unix world, depending on your intended setup.
> 
> Rather than see newuser create the dir if it doesn't exist, I'd rather  
> see it exit with an error in that case.

Following on several peoples advice and a suggested code snippet from Erik
I've added the following before the check for profile:

if(! test -d $home){
echo no home directory $home
exit homeless
}
if(! ls -ld $home >[2=] | grep -s '^d-rwx.* '$user){
echo bad permissions
exit homeless
}

I could add the 'mkdir /usr/ $user' to newuser, but then as Erik points out it
would be a special case for 9vx and not work for native plan9.  This way it
works if the file server console was never run, so possibly a general solution.

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

Francisco J Ballesteros  said:

> you could also use a script to call 9vx as you please.

That is what I did for the first prototype.  I thought this would be a beeter
solution.

Out of curiosity, have I hit a nerve or something.  Have I somehow offended? 
I'm just a bit confused by some of the responses.

I could easily understand the reluctance if there are some standardization
issues with getenv on the targeted platforms I do not know about.  I could
also understand if I was proposing to put it in some weird location, but both
of the hard-coded paths in 9vx main.c are obviously in RSC's home directories
and not more generic locations like /home/9vx, $home/9vx, /usr/local/9vx, 
/opt...

  EBo --


> On Mon, Apr 12, 2010 at 5:22 AM, EBo  wrote:
> >
> >> Why isn't 9vx -r yourdir good enough?
> >
> > it is if you want to force all users to specify the root directory every
> > single time they run 9vx, or if you want to use an alternative root.  If
I use
> > a standard install locations then we can either change "/Users/rsc/9vx" and
> > "/home/rsc/plan9/4e" or I can simply run a sed script during the build 
> > phase.
> >  Setting up a $root9vx (what I have changed it to) seemed the cleanest
approach.
> >
> >  EBo --

Re: [9fans] /sys/lib/newuser patch

[EBo]

erik quanstrom  said:

> > Following on several peoples advice and a suggested code snippet from Erik
> > I've added the following before the check for profile:
> > 
> > if(! test -d $home){
> > echo no home directory $home
> > exit homeless
> > }
> > if(! ls -ld $home >[2=] | grep -s '^d-rwx.* '$user){
> > echo bad permissions
> > exit homeless
> > }
> 
> you must also exit if ~ $user none.  i'd also recommend
> aborting if ~ $home /.  you don't want none making
> files in /.  on a regular plan 9 system, that's no worry, but
> 9vx, ...

The reason I did not include ~ $home / is that the first two lines of code in
newuser are:

user=`{cat /dev/user}
home=/usr/$user

so home can never be just / (unless I am missing something here), but the ~
$user none is a very good point.  Thanks!

  EBo --

Re: [9fans] /sys/lib/newuser patch

[EBo]

> you must also exit if ~ $user none.  i'd also recommend
> aborting if ~ $home /.  you don't want none making
> files in /.  on a regular plan 9 system, that's no worry, but
> 9vx, ...

I also tried to add test -z $user for the null string.  It turns out that
user=`{cat /dev/user} dies with the error "rc (newuser): null list in
concatenation".  Is this an appropriate failure mode, or is there some
workaround to do a null username? or is this getting to complicated?

  EBo --

Re: [9fans] /sys/lib/newuser patch

[EBo]

> On Apr 12, 2010, at 11:23, hiro wrote:
> 
> > and what is src/9vx/a/devcap.c ?
> 
> As far as my system and (as far as I can tell) the
> Mercurial repository: fictional. Something you'd
> like to share with the class?

Hunting on the we it looks like Ron Cox is the goto person for that
(http://bitbucket.org/rsc/vx32/changesets/ dated 2009-12-27):

"To make it possible to log into 9vx using drawterm a device #¤ (devcap) is
needed, otherwise auth_chuid() will fail, because it cannot open #¤/capuse."

"This patch adds `9/port/devcap.c' from Plan 9 to 9vx/a, with only a few
adaptions (see a/devcap.ed)."

So if I am reading this correctly, it is in a vx32 repository but not in the
9vx one.  I could be totally off base with that one, but thought the info
might be useful for tracking down.


  EBo --

Re: [9fans] /sys/lib/newuser patch

[EBo]

> > Hunting on the we it looks like Ron Cox is the goto person for that
> > (http://bitbucket.org/rsc/vx32/changesets/ dated 2009-12-27):
> 
> Ah, my bad. I was looking at the old, pre-bitbucket repository (in my
> defense, still linked from swtch.com/9vx). I take it back.

hmmm... the sources I am building 9vx from are:

  http://hg.pdos.csail.mit.edu/hg/vx32/http://code.swtch.com/9vx.

Should I be building them from http://bitbucket.org/rsc/vx32?

  EBo --

Re: [9fans] /sys/lib/newuser patch

[EBo]

EBo  said:

> 
> > > Hunting on the we it looks like Ron Cox is the goto person for that
> > > (http://bitbucket.org/rsc/vx32/changesets/ dated 2009-12-27):
> > 
> > Ah, my bad. I was looking at the old, pre-bitbucket repository (in my
> > defense, still linked from swtch.com/9vx). I take it back.
> 
> hmmm... the sources I am building 9vx from are:
> 
>   http://hg.pdos.csail.mit.edu/hg/vx32/http://code.swtch.com/9vx.
> 
> Should I be building them from http://bitbucket.org/rsc/vx32?

yep.  Just verified it.  The bitbucket sources are a superset and seem to be
moved sometime after 2009/10/05.

Thanks Anthony for bringing that to my attention!

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

Skip Tavakkolian <9...@9netics.com> said:

> > but both
> > of the hard-coded paths in 9vx main.c are obviously in RSC's home 
> > directories
> 
> it's not hardcoded; 

What?  The findroot code reads:

static char*
findroot(void)
{
static char cwd[1024];
int i;
char buf[1024];
char *dir[] = {
cwd,
"/Users/rsc/9vx",
"/home/rsc/plan9/4e"
};

if(getcwd(cwd, sizeof cwd) == nil){
oserrstr();
panic("getcwd: %r");
}

for(i=0; i= 0)
return dir[i];
}
return nil;
}

"/Users/rsc/9vx","/home/rsc/plan9/4e" are most certainly hard coded locations,
and will likely only be default on rsc's machines.  

> you can use -r as Russ said.  the difference is:
> "use default unless -r is given" vs.  "use default unless
> getenv(NINEROOT) is given".  -r makes it very obvious what the root is
> and probably will work better for un-unix-like environments.

Put another way, what are the default locations? 

Also, it would probably be "use default unless getenv(NINEROOT) or -r is
given".  Also, getenv works on Windoz.  What un-unix-like environments are you
referring to?

> but at any rate, you have the sources and are free to change things
> locally to suit your taste.

true, but will these patches be accepted upstream?  If I was looking to just
build this for myself I would not be bothering any of you, I'm trying to
figure out what would be useful to include upstream.  I guess I should not
have posted this to the list, but simply taken it up with Russ off-list since
it is his code.

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

Skip Tavakkolian <9...@9netics.com> said:

> > What?  The findroot code reads:
> 
> read the code again; findroot doesn't come into play.

it most certainly does!

in main...

if(!bootboot){
if(localroot == nil && (localroot = findroot()) == nil)
panic("cannot find plan 9 root; use -r");

So, if you do not specify localroot (via -r) then it uses findroot.  Findroot
first checks the cwd, and then two hardcoded paths.  This means that unless
the program is run from the 9vx's associated Plan 9 root, or the programs were
installed in "/Users/rsc/9vx" or "/home/rsc/plan9/4e", then you are requiring
all users on a system to run 9vx with -r and know where that root is always.  

Is it unreasonable to expect that an invocation of "9vx" to actually run?

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> >> > What?  The findroot code reads:
> >> 
> >> read the code again; findroot doesn't come into play.
> > 
> > it most certainly does!
> 
> the whole point was that given -r, findroot doesn't come into play.
> 
> if NINEROOT is not set, what does your version of 9vx do (without -r)? 

In short it fails with the error "cannot find plan 9 root; use -r"

Here is the specific sequence:

  If the 9vx invocation is in the root directory use `cwd`

-> here is where I checked for NINEROOT

  try "/Users/rsc/9vx" 

  try "/home/rsc/plan9/4e"

  fail with error "cannot find plan 9 root; use -r"


  EBo --

Re: [9fans] /sys/lib/newuser patch

[EBo]

 
> surely : echo bad permissions >[1=2]

I think you may be right.

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> I don't usually like to say "why bother", but given 9vx could be  
> launched with the appropriate parameter from a 2 line shell script  
> (including the #!), why are you even debating this?

wow...  I can understand people not liking checking the environmental
variables as it does increase the complexity, but I would have thought that
changing the default lookup from /home/rcs... would not have been a problem. 
I guess I was wrong about that.  

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> hardcode your own path and let the next sucker repeat the story

fair enough, and now for the heart of the question that I have been dancing
around all along (actually I thought it was obvious) -- what is the best way
to fix this section of code so that we can be done with it once and for all? 
Remove all hard coded paths and require -r and startup from root dir?  ok. 
add the env variable?  ok.  do whatever I am going to do and never post my
patches to start another flame drizzle (as compared to an all out flame war)?
 So, what's to be done?

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> relax.  it is unfortunte that there's too much resistance
> to improving on the initial cut.

Don't worry I'm relaxed, just seriously amazed and trying to figure this out.

The issue that will eventually stress me out however is the fact that these
discussions have hamstrung my productivity to probably less than 10% my
normal.  Learning the plan9 way is so far more than worth it, and I hope it
will continue to be.

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> the point is that any default is bound to be wrong.  my guess is that
> '/home/rsc/...' default was introduced early in the development and
> before '-r' was added.  it might be more useful to lobby for a default
> location like '/usr/lib/9vx'.
> 
> secondly writing
> 
> $ NINEROOT=/usr/ebo/9vxroot 9vx
> 
> is less pleasant than:
> 
> $ 9vx -r /usr/ebo/9vxroot
> 
> it's true that NINEROOT can be set and forgotten about, but the same
> argument could be made for writing a shell function that aliases 9vx
> to '9vx -r ...' etc -- and probably in the same place, e.g. .profile.

excellent, some constructive feedback, and thank all of you who have done so.

We already have -r so that we can either alias 9vx, or write a two line
wrapper as also previously suggested.

Now lets debate if there should be any hard coded paths in the program.  Where
are the most appropraite locations?  We could of course open up the /opt
/usr/local debate again, but there is also putting it into /usr/share/9vx and
/usr/lib/9vx as suggested. We could hash out what is suggested with the Linux
Standard Base, or throw the whole thing out the window.

What I have decided to do for my current work is to put it in /usr/local. 
Why?  I am working on Tvx, and their standard install is in 
/usr/local/${package}

I'll take consensus on the NINEROOT and ${home}/ if people do not mind that
complexity.

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> I don't mind adding more directories to the list in findroot,
> and something like /usr/local/9vx is certainly a better entry
> in that list than /home/rsc/plan9/4e (sorry).

no apologies necessary.  I actually liked Ethan Grammatikidis' last comments
regarding adding standard the standard locations.

> What I didn't understand was the rationale behind putting
> in a new environment variable when there is already a
> command-line option.  The argument about being right
> for the users is bogus: the amount of work required to
> make all users have the right environment variable setting
> is about the same as the amount of work required to
> make all users pass the right -r flag.

what I had meant is simply that when a user tries to run a program which has
been installed system wide it should simply work.  If writing a shell script
around the exe is considered a better way to go about it then I'm good with it.

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> Define reasonable. For me, that’s just 1 single spot. But it seems 
> the Linux people are very insistent on Freedom meaning do what you 
> want, even if it's against the build suggestions.
> I say stick to one hardcoded path, and make everyone else stop doing 
> it their own way, and stick to one simple, consistent solution.

Two possible guides are:

Linux Standard Base  

and

Filesystem Hierarchy Standard 

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> > Just to add more complications ;)
> 
> Did you choose the word "complications" because in watchmaking it  
> denotes extra (and often near-pointless) features? :D

Those watches are amazing!

Speaking for simplicity, the first time I saw the Salisbury cathedral clock
<http://en.wikipedia.org/wiki/Salisbury_cathedral_clock> I wanted to go out
and build one.  So, if you know anyone with dimensional drawings I should soon
have my forge up and running again ;-)

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> But the world isn't Linux.
> http://www.freebsd.org/cgi/man.cgi?query=hier&sektion=7

I never said it was, but if you look at FeeBSD's /usr/local you will also see
they are in agreement.

  EBo --

Re: [9fans] Spook/Glenda image use restrictions?

[EBo]

Steve Arons  said:

> For Glenda: http://plan9.bell-labs.com/plan9/glenda.html

unfortunately neither that page no the documentation explicitly state what
copyright and/or use restrictions for the images are.

Maybe it was presumptuous of me, but I emailed Renee for clarification.  It
really should be documented.

  EBo --

[9fans] C++ support [was: TeX: hurrah!]

[EBo]

> The lack of C++ is going to hinder efforts to port these projects to
> Plan 9 as-is; and these are significant efforts, not likely to be
> duplicated by 9fans.  (Perhaps the C++ library for PDF handling can be
> rewritten in C, and then XeTeX & LuaTeX can be ported.  But don't
> expect the projects to use the rewrite in favor of the original
> libraries.)

In the spirit of offering possible useful information while not being in the
slightest bit interested in either porting a compiler or writing a converter
at this time, I had the thought "why not write a C++ to C converter" like the
old f2c I used back before g77/g95 came out.  In anticipation of another flame
drizzle, I am not reading these threads thinking that everyone is asking me to
write these things for them, nor are my contributions necessarily asking
others to develop such projects for me.  When I have written my own posts it
was intended to ask if anyone has done this, something similar, or even tried
it.  I like orienting myself a little before spending hundreds of hours --
only to find that I have reinvented the wheel.

I poked around a little and found the following info:

http://www.programmersheaven.com/mb/CandCPP/82212/82212/c++-to-c-converter/
http://cboard.cprogramming.com/c-programming/106880-there-any-up-date-cplusplus-c-converter.html

apparently LLVM can be used to convert C++ to C; I had not know that:
  http://llvm.org/docs/FAQ.html#translatecxx

I remember seeing someone interested in porting LLVM to Plan 9.  Maybe that
would help get you going.

  EBo --

Re: [9fans] plan9port awk problem

[EBo]

> this is a bug that bwk fixed.  it is fixed in the 
> new port of awk to plan 9, but not in the distribution
> the new port is contrib quanstro/awk.

sorry, I'm confused here.  Does that mean that we should use contrib
quanstro/awk? Or not?

Re: [9fans] SATA boot failure

[EBo]

> > no PATA drives, just SATA-II, it worked before, but stopped to, I
> > thought it was damaged but surface scan was OK, I reinstalled, but the
> > problem persists. it well may be also caused by the fact that I,
> > in the meantime, used that box with linux IDE discs, so I fiddled with
> > BIOS, sory...

This sounds exactly like the trouble I initially had on my AMD machine.  It
turned out there is a bios bug and it is highly sensitive to how the SATA is
configured, and whether in ACHI or native IDE mode.  I also found it necessary
to remove power to clear nvram or memory or something which seemed to maintain
state unless power was removed.

[9fans] 9vx crashing

[EBo]

Just an FYI.  I've been working on getting 9vx running on a TinyCoreLinux USB
stick, and I have been having 9vx crash in odd ways and wanted to post a note
about it.

For starters, I am building 9vx from hg source and using the root from 9vx's
2008/7/1 release 9vx-0.12.  There are three points of possible interest:

1) the base root does not have libc.a which means that I can compile program,
but not link them.

2) I installed Erik's find utility and running it gave the error:

 find 2062: suicide: sys: trap: invalid opcode pc=0x5001

   from inside 9vx, and:

 invalid opcode ff ff ba at eip 5001

   in the linux terminal that spawned it.

3) I was able to resolve both problems by replace the Plan 9 root with one
copied from a recent 9atom.iso, however I am not finished testing that though.

  EBo --

Re: [9fans] 9vx crashing

[EBo]

> that pc is in the floating point code.  clearly bogus.
> as find doesn't do any floating point.

I have no idea why this is happening, only that it is and it is failing
consistently.  

While I could spend time trying to tracing through the code to figure out what
is going on, I have opted for the moment to update the base root I am using as
the old one is just shy of two years old, and the newer one seem to run
correctly so far.  If this problem creeps up again I'll start debugging it in
earnest.

  EBo --

[9fans] updating 9vx root

[EBo]

what is the procedure for either updating the entire 9vx root, or setting up
and building all the special customizations to build an up to date system?

For background, I am running the newest 9vx/vx32 sources and have tried
various combinations of 9vx-0.12 (which is missing libc.a), the full tree that
was based on (a "pull -s /" overloads some customized program and renders the
root unbootable), root extracted from 9aton.iso (which gives me error messages
about not having kfs setup).

Thanks and best regards,

  EBo --

Re: [9fans] updating 9vx root

[EBo]

Fernan Bolando  said:

> On Wed, Apr 21, 2010 at 12:49 PM, EBo  wrote:
> >
> > what is the procedure for either updating the entire 9vx root, or setting up
> > and building all the special customizations to build an up to date system?
> >
> > For background, I am running the newest 9vx/vx32 sources and have tried
> > various combinations of 9vx-0.12 (which is missing libc.a), the full tree 
> > that
> > was based on (a "pull -s /" overloads some customized program and renders 
> > the
> > root unbootable), root extracted from 9aton.iso (which gives me error 
> > messages
> > about not having kfs setup).
> >
> > Thanks and best regards,
> >
> have you tried replica/pull?
> I have not used 9vx for sometime since I got my atom motherboard
> working natively, But I remember doing a replica/pull to update my 9vx
> installation. I did get a bunch of permission problem, if you do a
> search in 9fans archive you should see an advice from andrey on how to
> fix it.

sorry I was not clear with the above.  Yes, but I used glenda's pull script.

I'm looking up andrey's comments now...

Re: [9fans] updating 9vx root

[EBo]

> > what is the procedure for either updating the entire 9vx root, or setting up
> > and building all the special customizations to build an up to date system?
> 
> See: http://9fans.net/archive/2008/07/118
> 
> I always start from the tree posted in that message, but you can also
> follow the instructions to start from a cd.

Sorry I was not clear.  http://pdos.csail.mit.edu/~rsc/plan9.tar.bz2 was the
one I was referring to by the full tree.

I have not however overloaded /dist/replica/client and /dist/replica/network
yet from a stock CD.  That is my next step.

  EBo --

Re: [9fans] updating 9vx root

[EBo]

> > See: http://9fans.net/archive/2008/07/118
> > 
> > I always start from the tree posted in that message, but you can also
> > follow the instructions to start from a cd.
> 
> Sorry I was not clear.  http://pdos.csail.mit.edu/~rsc/plan9.tar.bz2 was the
> one I was referring to by the full tree.
> 
> I have not however overloaded /dist/replica/client and /dist/replica/network
> yet from a stock CD.  That is my next step.

update: I got the exact same coredump when I followed the above and replaced
/dist/replica/client and /dist/replica/network as suggested in that email. 
The one interesting thing that did happen however, is that the kfs error I was
getting before went away.

Re: [9fans] 9vx crashing

[EBo]

> Sorry, forget to mention that I also spend a lot of time on figuring out
> why newly build 9vx from hg was crashing both on FreeBSD and Linux, but
> all in a vain (currently don't have access to an OS/X machine).
> 
> I'm not sure, if it was a correct fix, but removing -melf_i386 option
> did the trick; 

Without the -melf_i386 option I get the the following error:

ld  -o vxa/zlib/ezlib -Llibvxc -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/32/ -g
-L.  libvxc/vx32/crt0.o vxa/zlib/ezlib.vo vxa/zlib/compress.vo
vxa/zlib/deflate.vo vxa/zlib/trees.vo vxa/zlib/adler32.vo vxa/zlib/crc32.vo
vxa/zlib/zutil.vo -lc -lgcc
ld: skipping incompatible libvxc/libc.a when searching for -lc
ld: errno: TLS definition in /lib64/libc.so.6 section .tbss mismatches non-TLS
reference in vxa/zlib/ezlib.vo

Removing both the -melf_i386 and -mfp-ret-in-387 resulted in the same.

I'm using GCC 4.3.4 and ld 2.18 on Gentoo updated/synchronized daily.

I should also note that my hardware is an AMD x86_64

  EBo --

Re: [9fans] 9vx crashing

[EBo]

ron minnich  said:

> randomly changing build options is one approach to debugging but not
> always effective :-)

true, true ;-)  I'm still waking up! : Gentlemen, Start your tea-pot/coffee-makers! 

Re: [9fans] 9vx crashing

[EBo]

> randomly changing build options is one approach to debugging but not
> always effective :-)

I also forgot to mention that the reason I tried that is that I noticed both
of those switches were missing from one of the Makefrag files I was reading
recently, so it was not completely random ;-)

[9fans] corrupted update on 9vx

[EBo]

OK.  I've been trying to track down the odd 9vx crash and discovered some
other oddities and request some guidance in what might be causing the pull to
become corrupted and installing entire blocks of nil's in updated files.

Following details outlined in
http://fixunix.com/plan9/501128-9fans-pull-9vx.html, I first tried to update
the original plan9 distro, then moved to a new 9atom.iso.  To get the pull to
work I had to update the network and client db:

# cp -a plan9/dist/replica/client/plan9.* root9atom/dist/replica/client/
# cp -a plan9/dist/replica/network root9atom/dist/replica/network

Then I ran /usr/glenda/bin/rc/pull.  At one point it seemed to work until I
decided to recompile a couple of the commands in /sys/src/cmd and discovered
that several of the source files had blocks of nil's in them.  I wanted to see
if the problem was systematic or more random, so I saved that root tree and
reran the test.  What I found is that the corruption happens very often and at
seemingly random files and locations.  I also wanted to check to see if these
differences were consistent (like 4K blocks, etc).  I found that the number of
corrupted blocks, and their respective lengths, vary.  I also found that they
are not guaranteed to be multiples of 512.

These tests were so far run on my AMD x86_64.  I'll try rerunning these tests
on an Intel based laptop to see if this is some weird x86_64'ism.  I will also
try the Tvx code compiled for i486 on both machines

Does anyone have an idea what could be causing replica to behave so?  Has
anyone ever seen this behavior before?

  Thanks and best regards,


  EBo --

Re: [9fans] corrupted update on 9vx

[EBo]

Sorry for the delay

> On Thu Apr 22 14:45:38 EDT 2010, st...@quintile.net wrote:
> > replica uses fcp which works multithreaded for speed. 
> > 
> > Perhaps the implementation of fswrite() #Z in 9vx uses a seek()
> > followed by a write() rather than pwrite() which is not thread safe.
> 
> replica actually uses replica/applylog.c:^/worker internally, not
> fcp.  but essentially, it's the same thing.  it copies NBUF=8192
> bytes at a time with 16 parallel processes.  #Z uses pwrite on non-sockets.
> 
> in theory, since NBUF < SSIZE_MAX, pwrite should be atomic
> to normal files.

Thanks for the pointer.  I'll try playing around with NBUF and also see if I
can play with the number of processes (thwack it to 1 for testing and see if
that helps).

> you're not using a fuse-based fs, are you?

no.  I did have fuse installed, but it was only used by usermode-utilities,
and I have since removed both that and fuse.

> possible ways to debug:
> 1.  reduce NBUF to PIPE_BUF=4096.  guard against someone treating
> the fd as a pipe.
> 2.  put a qlock in the UnixFd structure in devfs-posix.c.  lock for all io.

If I recall correctly, qlock has not been ported to 9vx.  Ahhh... I see that
it has.  This saves me the hassles of porting it myself ;-)

Laters,

  EBo --

Re: [9fans] /sys/include/ape/u.h

[EBo]

erik quanstrom  said:

> i'm not sure i understand the rationale behind this file.
> shouldn't these defines be in /$objtype/include/u.h?
> seems a mistake to make a u.h machine independent.
> what am i missing?

I have no idea what you are referring to -- I did not create any files I
mentioned...

so, for whatever you are missing I am clueless!

  EBo --

Re: [9fans] 9vx crashing

[EBo]

lu...@proxima.alt.za said:

> > Try http://werc.homelinux.net/hacks/nano9/
> > 
> > Hope that helps,
> 
> How does one install the stuff in that directory?  Specifically, what
> handles *.xz files?

I tripped over that one too...  This might help with the *.xz files:
http://en.wikipedia.org/wiki/Xz

I forget what all else I did when trying nano.  I ended up focusing back on
9atom, and Erik had just patched the source so that a "mk all" would compile
everything.  See ftp://ftp.quanstro.net/other/9atom.iso.bz2 if interested. 
That is one of the source trees I'm playing with for setting up 9vx on
TinyCoreLinux and Gentoo.

hope that helps.

  EBo --

Re: [9fans] 9vx crashing

[EBo]

> > I forget what all else I did when trying nano.  I ended up focusing back on
> > 9atom, and Erik had just patched the source so that a "mk all" would compile
> > everything.  See ftp://ftp.quanstro.net/other/9atom.iso.bz2 if interested. 
> > That is one of the source trees I'm playing with for setting up 9vx on
> > TinyCoreLinux and Gentoo.
> 
> Sounds like something that ought to be on the wiki (where I seldom
> look, I have to confess).  Do you think you could add an entry when
> you're done?  And maybe let us or just me know?

sure.  what specifically would you like to see?  

This is some of the background work for my GSoC and thesis work, so if any of
my proposals are accepted for GSoC then I'll be working on various aspects of
this.  If some reason that none of the proposals get excepted, then my thesis
research will need this for rudimentary toolchain.

  EBo --