Re: [9fans] Plan9 Sources Repository

[dante]

done

On 20.07.2014 00:30, erik quanstrom wrote:

The Wiki seems to be frozen (i.e., not editable anymore):
- no "Edit" button on
http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/
- no permissions for /mnt/wiki/software_for_plan9/current (wiki.wiki
444)


edit from plan 9.

- erik

Re: [9fans] Plan9 Sources Repository

[dante]

thanks.

On 20.07.2014 02:12, Brian L. Stuart wrote:

My whole argument goes about the following hypotheses:
1. increasing the amount of contributions may not scale in
the current model.
2. submitting trivial contributions is not trivial for the 
contributor.


Both of these points seem to come from a mental model
that just doesn't apply to Plan 9.  In earlier messages, you
used the word team to describe the set of people contributing
to Plan 9.  However, in reality, there isn't a Plan 9 team, per
se.  Essentially, Plan 9 is a research system.  It's a platform
and a vehicle for doing systems research.  It is true that it
has been very useful as the basis of products, as infrastructure,
and as a daily-use OS.  However, rather than being its raison
d'etre, Plan 9's utility is a tribute to and the acid test of the
research work done on it.  After all, I'm hardly going to suggest
that a file system I develop is worthy of study or use if I'm
not willing to put my own data on it.  (So yes, my main file
server is running on thetafs, and has been for months.)

Given that the primary function of Plan 9 is to be a research
system, neither increasing numbers of contributions nor
trivial contributions are to be expected.  In fact, it's not
clear they would be particularly desirable.

The flip side of all this is that because it has been very useful,
many of us use it heavily enough that we'd be loathe to
return to a world where we'd have to do without it.  So there
is valid motivation to expand the set of supported hardware,
fix bugs, make it easier to install and use, etc.  While, I'm
not in a position to speak for the principals involved, from
my perspective, both 9atom and 9front are laregely so
motivated.  I don't think I'm speaking out of turn when I say
that the maintainers of both of those systems would be more
than happy to accept contributions to them.  If, in the course
of making such contributions, you reach a point where the
contribution channel could be improved, then contributing
an improved contribution mechanism would be just as welcome,
I suspect.

In other words, welcome to the Plan 9 community.  We'll
be glad to help you however we can.  We encourage and
look forward to seeing any contributions you make that
emerge from what captures your interest.

BLS

Re: [9fans] extern register

[Aram Hăvărneanu]

On Sun, Jul 20, 2014 at 3:42 AM,   wrote:
> removed the saving and restoring
> of DS/ES/FS/GS segment registers... they have no effect in long mode

Actually FS and GS do work in long mode. Since we don't need them for
TLS, maybe we can do something useful with them.

-- 
Aram Hăvărneanu

Re: [9fans] Pull and compile latest kernel (sys call 53 error)

[Patryk Laurent]

> you need to reboot using one of the kernels you pulled first.
> 

How do I find the kernels that I pulled?  They don't appear to be in 
/sys/src/9/pc

After I have found the kernel, do I with it by copying it into /n/9fat as 
specified here?: http://plan9.bell-labs.com/wiki/plan9/compiling_kernels/

Thank you,
Patryk

Re: [9fans] extern register

[cinap_lenrek]

it doenst matter to runtime what data segment selectors have been
loaded in the segment registers in long mode. we initially load
them with null seletors and then never touch them again.

but the processor *does* check the selectors index when you load
a selector into a segment register!

the reason i removed the saving and restoring is that i can stop
worrying about bad data selectors when devproc or noted sets the ureg
of a process. 

we had todo this on 386 because otherwise the process would #GP when 
trying to restore the bad selectors. now without restoring the segment
registers, it cant #GP and nothing needs to be checked.

for GS/FS theres new GS_BASE and FS_BASE msr register that the kernel
can set to change GS and FS segment offsets affetcing the offset used
by GS and FS segment prefixes. but the kernel would need to switch
these msrs in and out for each process and provide a interface
for userspace to set ther base. you will need this for something
like linuxemu.

--
cinap

Re: [9fans] Pull and compile latest kernel (sys call 53 error)

[cam]

> How do I find the kernels that I pulled?  They don't appear to be in 
> /sys/src/9/pc

they are in /386 (ie - /386/9pcf).  a pull copies binaries as well 
as source.

> After I have found the kernel, do I with it by copying it into /n/9fat as 
> specified here?: http://plan9.bell-labs.com/wiki/plan9/compiling_kernels/

that should do it.

Re: [9fans] Pull and compile latest kernel (sys call 53 error)

[Patryk Laurent]

> they are in /386 (ie - /386/9pcf).  a pull copies binaries as well 
> as source.

Thank you, it's working perfectly.

Patryk

[9fans] ANTS and Atoms

[Shane Morris]

Hello 9fans,

If I were to follow these commands:

DNSSERVER=8.8.8.8
ip/ipconfig
ndb/cs
ndb/dns -r
mkdir ants
9fs ants.9gridchan.org
dircp /n/ants.9gridchan.org/rootlessnext ants
cd ants
build isoinstall
build worker
cd cfg
stockmod
fshalt


On a vanilla 9atom VM install, would it erase the /bin directory of the
9atom installation? I'd like to play with the ANTS Toolkit, but I'd also
like to have all of the /bin folder there locally, rather than populated by
"addsources." I've also installed the contrib GUI into 9atom thus far.

Many thanks!

Shane.

[9fans] Compiler Message

[Shane Morris]

Hello again 9fans,

I'm also trying to compile hosted Inferno for OS X 10.9, all seems to go
well until the "mk install" giving this error message:

shanes-air-2:inferno-os boris$ PATH=`pwd`/MacOSX/386/bin:$PATH mk install
(cd lib9; mk  install)
cc -c -arch i386 -mmacosx-version-min=10.4 -Wno-deprecated-declarations
-Wuninitialized -Wunused -Wreturn-type -Wimplicit -Wno-four-char-constants
-Wno-unknown-pragmas -pipe -fno-strict-aliasing -no-cpp-precomp
-mno-fused-madd -I/Users/boris/Documents/inferno-os/MacOSX/386/include
-I/Users/boris/Documents/inferno-os/include -Os convD2M.c
clang: error: unknown argument: '-mno-fused-madd'
[-Wunused-command-line-argument-hard-error-in-future]
clang: note: this will be a hard error (cannot be downgraded to a warning)
in the future
mk: cc -c -arch ...  : exit status=exit(1)
mk: for j in ...  : exit status=exit(1)
shanes-air-2:inferno-os boris$

Does anyone have any insight?

Many thanks!

Shane.

Re: [9fans] Compiler Message

[tlaronde]

On Mon, Jul 21, 2014 at 12:55:44PM +1000, Shane Morris wrote:
>
> clang: error: unknown argument: '-mno-fused-madd'
> [-Wunused-command-line-argument-hard-error-in-future]
> clang: note: this will be a hard error (cannot be downgraded to a warning)
> in the future

Apparently the "future hard error" is treated as an error.

It looks like clang does not understand the gcc argument
'-mno-fused-madd'. Only the developers of Inferno would know if
multiply-add for float caveat is really a requisite for Inferno.
So look if there is the equivalent in clang, and convert the
argument; or suppress it where it is defined in the mkfiles (perhaps
it is necessary for gcc, doing "things", and not necessary with
another compiler, so the compiled program will not exhibit any
problem).

HTH
-- 
Thierry Laronde 
  http://www.kergis.com/
  http://www.renaissance-francaise.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Compiler Message

[Ramakrishnan Muthukrishnan]

On Mon, Jul 21, 2014 at 8:25 AM, Shane Morris  wrote:
> Hello again 9fans,
>
> I'm also trying to compile hosted Inferno for OS X 10.9, all seems to go
> well until the "mk install" giving this error message:
>
> shanes-air-2:inferno-os boris$ PATH=`pwd`/MacOSX/386/bin:$PATH mk install
> (cd lib9; mk  install)
> cc -c -arch i386 -mmacosx-version-min=10.4 -Wno-deprecated-declarations
> -Wuninitialized -Wunused -Wreturn-type -Wimplicit -Wno-four-char-constants
> -Wno-unknown-pragmas -pipe -fno-strict-aliasing -no-cpp-precomp
> -mno-fused-madd -I/Users/boris/Documents/inferno-os/MacOSX/386/include
> -I/Users/boris/Documents/inferno-os/include -Os convD2M.c
> clang: error: unknown argument: '-mno-fused-madd'
> [-Wunused-command-line-argument-hard-error-in-future]
> clang: note: this will be a hard error (cannot be downgraded to a warning)
> in the future
> mk: cc -c -arch ...  : exit status=exit(1)
> mk: for j in ...  : exit status=exit(1)
> shanes-air-2:inferno-os boris$
>
> Does anyone have any insight?

Hi,

On OS X 10.9.x, gcc points to clang. I installed gcc-4.9.0 from source
(follow instructions on this page, for example:
 to
get a working gcc. I don't use a package manager on OSX these days, I
compile/install what I need, from source.)

I then edited mkfiles/mkfile-MacOSX-386 to point to the newly built
gcc (I called the gcc binary gcc-4.9.0). Here is the complete file.

TARGMODEL=  Posix
TARGSHTYPE= sh
CPUS=   386

O=  o
OS= o

AR= ar
ARFLAGS=ruvs
A=  a

AS= gcc-4.9.0 -c -arch i386 -m32
ASFLAGS=

ISYSROOT=   -isysroot /Developer/SDKs/MacOSX10.6.sdk

CC= gcc-4.9.0 -c -m32
COPTFLAGS=  -Os
CDEBUGFLAGS=
CTHREADFLAGS=
CFLAGS= -arch i386 -m32\
-mmacosx-version-min=10.6\
-Wno-deprecated-declarations -Wuninitialized -Wunused
-Wreturn-type -Wimplicit -Wno-four-char-constants
-Wno-unknown-pragmas\
-pipe\
-fno-strict-aliasing\
-mno-fused-madd\
-I$ROOT/MacOSX/386/include\
-I$ROOT/include\
$COPTFLAGS $CDEBUGFLAGS\

LD= gcc -arch i386 -m32
LDFLAGS=\
-mmacosx-version-min=10.4\
-multiply_defined suppress

SYSLIBS=

YACC=   iyacc
YFLAGS= -d


-- 
  Ramakrishnan