> would be nice to put all the hardware support together.
That would be wonderful. But it does require resources to deal with
incompatibilities as well as different perception of value. My angle
her is that I'm mostly working with obsolete equiopment and I am
extremely reluctant to watch Plan 9
Hi,
I was wondering what was the reasons for the name u.h? Is it because
it has lots of uxxx type in it?
Also what is the meaning of Qid. What the Q stands for?
I have every intention of making my efforts available to everyone,
should I have even just a remote chance of success. More importantly,
what I'm trying to do is to reduce differences, rather than increase
them.
Now, I note that by adding the amd64 stuff to an already modified
version of the Bell
Quoting Charles Forsyth :
they weren't "shot down", but saying use MY distribution over here,
or use MY distribution over here,
haha you said exactly the same thing
> (1) the amd64 compiler suite, (2) the source for the amd64-specific bits of
> the library,
> (3) the modifications to make the whole source compile and run in 64 bits
> (and not just amd64 but any one), (4) the source for the prototype amd64
> kernel,
> (5) the source for the several versions of
> Why is this stuff always so difficult?
because on the internet nobody does "relax".
> It's worth remembering that the only reason there was ANY
> available code for the amd64, and initial kernel code to
> boot, was because
Thank you Charles, and everyone else involved. Because of your
contributions I'm able to run cinap's pc64 kernel on my x86_64
machines.
I'll say this again ju
> No, it wasn't. There was some confusion over the point that
> Plan 9, unlike some other systems, selects the arch based
> entirely on the running kernel (no 386 binaries running on
> amd64 machines).
Do you recall the reason this guy is even trying to install
Plan 9?
Kernel hacking.
Once he bu
On 7 May 2014 22:38, wrote:
> Maybe the
> code is not really secret, but is instead held up somewhere
> in the coordination process.
>
> For years, and years, and years at a time.
>
It's worth remembering that the only reason there was ANY available
code for the amd64, and initial kernel code to
sl said:
> The original post (in its way) was asking for advice about
> an amd64 kernel that is not publicly available.
No, it wasn't. There was some confusion over the point that
Plan 9, unlike some other systems, selects the arch based
entirely on the running kernel (no 386 binaries running on
> (come to mention it, i did Dan Brown a favour last year, unwittingly.)
There you go again. More secrets :-)
> Dan Brown
low blow
On 7 May 2014 22:38, wrote:
> . Some people
> (not knowing the full situation) offered advice about publicly
> available amd64 kernels and were shot down.
>
they weren't "shot down", but saying use MY distribution over here,
or use MY distribution over here, didn't directly help with the problem
>> Why is this controversial?
>
> Because you're missing the point, and arguing against a
> position nobody holds.
The original post (in its way) was asking for advice about
an amd64 kernel that is not publicly available. Some people
(not knowing the full situation) offered advice about publicly
On May 7, 2014, at 2:17 PM, Anthony Sorace wrote:
> What some folks are suggesting is that some coordination would yield better
> results; that we can do better than the "everyone going off and doing their
> own thing" part of the above scenarios.
>
> I believe Erik's point about "falling int
> Why is this controversial?
Because you're missing the point, and arguing against a position nobody holds.
Absolutely nobody here is suggesting that everyone going off and doing their
own thing and keeping the results to themselves is better than everyone going
off and doing their own thing a
[Without picking on or singling out anyone ...]
> Who would you like to volunteer to do all of this work, that's what it seems
> like you're trying to do.
It is this ongoing level of petty pissiness that has led to the fragmentation
of the community.
It's also the reason the folks at the Labs
>> What I know is that I turn on my Thinkpad x230 and everything
>> works. After the boot process finishes I just carry on with my
>> work.
>
> sure that's fine. but if everyone does that, plan 9 will fall into disrepair,
> because nobody's willing to do the work.
What are you talking about? If
Who would you like to volunteer to do all of this work, that's what it
seems like you're trying to do.
On May 7, 2014 4:09 PM, "erik quanstrom" wrote:
> On Wed May 7 16:00:21 EDT 2014, s...@9front.org wrote:
> > > you're missing my point. it's not particularly useful as a tinker-toy
> > > set.
On Wed May 7 16:00:21 EDT 2014, s...@9front.org wrote:
> > you're missing my point. it's not particularly useful as a tinker-toy
> > set. especially when there are 10 wheels and 1 stick.
>
> What I know is that I turn on my Thinkpad x230 and everything
> works. After the boot process finishes I
> you're missing my point. it's not particularly useful as a tinker-toy
> set. especially when there are 10 wheels and 1 stick.
What I know is that I turn on my Thinkpad x230 and everything
works. After the boot process finishes I just carry on with my
work.
sl
> > would be nice to put all the hardware support together.
>
> It's all available for anyone to take from the public
> repositories. I don't think any of the forks have placed
> additional restrictions on what can be done with their
> changes.
>
> Enjoy.
you're missing my point. it's not parti
>> The forks of Plan 9 exist mainly because people want to
>> run Plan 9 on their computers.
>
> would be nice to put all the hardware support together.
It's all available for anyone to take from the public
repositories. I don't think any of the forks have placed
additional restrictions on what c
On Wed May 7 14:33:08 EDT 2014, s...@9front.org wrote:
> > if everybody does their own thing, perhaps we spend all our collective
> > time doing the same thing, and no progress is made?
>
> Most of the duplicated effort never seems to make it out
> to the public, so for users, the point is often
> if everybody does their own thing, perhaps we spend all our collective
> time doing the same thing, and no progress is made?
Most of the duplicated effort never seems to make it out
to the public, so for users, the point is often moot.
The forks of Plan 9 exist mainly because people want to
run
> Mostly just a mixture of arrogance and ineptitude that says I want to
> do this my way?
>
> For real, I can't resist a convergence challenge. The image I had in
> my mind was of an amd64 environment within the Bell Labs release
> (i386) that would allow me to build either 9atom or 9front releas
> could explain why these patches made sense for you rather
> than the atom stuff?
Mostly just a mixture of arrogance and ineptitude that says I want to
do this my way?
For real, I can't resist a convergence challenge. The image I had in
my mind was of an amd64 environment within the Bell Labs r
On Wed May 7 09:37:51 EDT 2014, charles.fors...@gmail.com wrote:
> On 7 May 2014 13:59, Kurt H Maier wrote:
>
> > Sorry, wasn't aware this is an SP9SSS affair.
>
>
> nothing secret; just what happened.
so, asking myself as well as the list, what steps can we
take to prevent working so much a
On Wed May 7 07:15:46 EDT 2014, lu...@proxima.alt.za wrote:
> > I should have commented further. The first patch is a copy from the
> > original Nix files written by jmk. The second is an attempt to synchronize
> > with the changes made in Plan 9 on September 2013.
>
> Based entirely on these pat
On 7 May 2014 13:59, Kurt H Maier wrote:
> Sorry, wasn't aware this is an SP9SSS affair.
nothing secret; just what happened.
Quoting Charles Forsyth :
I see that I had better explain. I am yan cui's mentor for GSoC on a
particular project that is starting with some
code that I wrote, and it will greatly assist me initially if he and I are
using the same basic source code for
the system and the kernel. Sources provides
On 7 May 2014 12:13, wrote:
> I haven't yet checked Charles' posting.
that won't have anything to do with wider APE support.
> I should have commented further. The first patch is a copy from the
> original Nix files written by jmk. The second is an attempt to synchronize
> with the changes made in Plan 9 on September 2013.
Based entirely on these patches, plus a little tweaking because I've
updated APE to be closer to N
!/bin/upas/marshal -s 'Re: [9fans] [GSOC] plan9 which arch code to use?' -R
/mail/fs/mbox/1815 9fans@9fans.net
> > On 7 May 2014 10:05, erik quanstrom wrote:
> >
> > > the comment is wrong. it's "int ainc(int*)"
> >
> >
> > h% grep ainc /sys/include/libc.h
> > long ainc(long*);
> >
> > h% gr
> You just have to apply the following patches (from Nix):
>
> hget http://www.9legacy.org/9legacy/patch/amd64.diff | ape/patch -p0
> hget http://www.9legacy.org/9legacy/patch/amd64-fix.diff | ape/patch -p0
I should have commented further. The first patch is a copy from the
original Nix files writ
On Wed May 7 05:24:00 EDT 2014, 0in...@gmail.com wrote:
> > also why have atom.s in ape?
>
> This is what was done on 386.
>
> /n/sources/plan9/sys/src/ape/lib/ap/386/atom.s
that begs the question. why put the atom functions in ape
for any architecture?
- erik
> also why have atom.s in ape?
This is what was done on 386.
/n/sources/plan9/sys/src/ape/lib/ap/386/atom.s
--
David du Colombier
On Wed May 7 05:21:03 EDT 2014, charles.fors...@gmail.com wrote:
> I see that I had better explain. I am yan cui's mentor for GSoC on a
> particular project that is starting with some
> code that I wrote, and it will greatly assist me initially if he and I are
> using the same basic source code f
I see that I had better explain. I am yan cui's mentor for GSoC on a
particular project that is starting with some
code that I wrote, and it will greatly assist me initially if he and I are
using the same basic source code for
the system and the kernel. Sources provides a conservative base for the
> On 7 May 2014 10:05, erik quanstrom wrote:
>
> > the comment is wrong. it's "int ainc(int*)"
>
>
> h% grep ainc /sys/include/libc.h
> long ainc(long*);
>
> h% grep ainc /n/sources/plan9/sys/include/libc.h
> long ainc(long*);
shouldn't that be aincl? these definitions were added to
libc.h
On Wed May 7 04:47:05 EDT 2014, charles.fors...@gmail.com wrote:
> On 7 May 2014 06:14, wrote:
>
> > The Bell Labs distribution does not seem to have a libc/amd64. It's a
> > bit of a show stopper. I could also be mistaken and a different amd64
> > is being looked for.
> >
>
> I did not know
On 7 May 2014 10:05, erik quanstrom wrote:
> the comment is wrong. it's "int ainc(int*)"
h% grep ainc /sys/include/libc.h
long ainc(long*);
h% grep ainc /n/sources/plan9/sys/include/libc.h
long ainc(long*);
+++ /sys/src/ape/lib/ap/amd64/atom.s
@@ -0,0 +1,75 @@
+TEXT ainc(SB), $0 /* long ainc(long *); */
+ MOVLaddr+0(FP), BX
the comment is wrong. it's "int ainc(int*)"
further down the definition of casp, cas64 is really wrong.
(it only considers the low 32-bits)
also why have atom.s i
On 7 May 2014 09:38, Riddler wrote:
> Out of curiosity is there a reason that the patches for a 64bit install
> never ended up in the main plan9 codebase?
The full story is much more complicated, but briefly, the switch to 64 bits
offered a chance to revisit the kernel implementation,
but the v
On 7 May 2014 06:14, wrote:
> The Bell Labs distribution does not seem to have a libc/amd64. It's a
> bit of a show stopper. I could also be mistaken and a different amd64
> is being looked for.
>
I did not know that. I've attached a tar file, of what I'm using.
I'll compare it to the patches
Out of curiosity is there a reason that the patches for a 64bit install
never ended up in the main plan9 codebase?
> You just have to apply the following patches (from Nix):
Thank you, that worked well (so far, the build is still running),
although I have a spim (0) object type in my mkfile.proto that threw a
(small) spanner in the works.
++L
47 matches
Mail list logo
