Re: [9fans] [GSOC] plan9 which arch code to use?

Re: [9fans] [GSOC] plan9 which arch code to use?

[sl]

> Dan Brown

low blow

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

> But maybe, just maybe, if the community can get its act together to
> support a "codereview" type approach, we can ask Coraid to sponsor the
> minimum resources required by it.  I don't have a clue to the details,
> but I would be thrilled to contribute.

i think you're suggesting using some sort of corporate sponsorship as
an implicit endorsement.  endorsements are for polititians.  :-)

9front does have a lightly used review system.

all 9atom patches are submitted through apatch, and all apatches are
sent to sources klammeraffe 9atom punkt org.  apatch/note can be
used by anyone to post comments about a patch.  these comments are
sent to the list.

9atom is currently single committer, with the possibility of delegation
(like linux).  i'd love to delegate parts of the system.  if you want to
bend or replace apatch to your wishes, i'm all for it.  but i won't accept
dependencies on python or external web sites(see postscript)

> (1) Bell Labs are lagging behind 9atom and 9front in support for a lot
> of hardware (old and new), a situation that, by getting progressively
> worse may cause them to drop out of the race altogether and (2) The
> amount of effort and ego bashing required to bring the different
> releases in line is considerable and no one is likely to take such a
> mission on without knowing that, at minimum, the "owners" of the
> various distributions are willingly supportive of such efforts.

for what it's worth, i review all the changes made to plan 9 and 9front
and apply what makes sense.  david actually has a script that automaticly
packages any changes to sources and creates a 9atom patch.  many thanks
to him.

- erik

p.s. i am not using codereview for two reasons.  1.  codereview might be
neat, but for me it brings all the baggage of hg, but most of the good bits
are left out  2.  i don't want to depend on mercurial, hg, and google's
good graces.  (good grief.)  plan 9 is currently self-sufficient, and for me
this is a first-class goal.

Re: [9fans] [GSOC] plan9 which arch code to use?

[Kurt H Maier]

Quoting erik quanstrom <quanstro@quanstro.net>:

> for what it's worth, i review all the changes made to plan 9 and 9front
> and apply what makes sense.

Some subset of the 9front people also do this with various publicly-
available resources, like 9changes and 9atom.  I'm not sure of the
value of a javascript thing that is inaccessible from actual plan 9.
For a lot of us, plan 9 is a functioning operating system and less of
a research-paper generation mechanism.  Part of the reason 9front
originally even moved to google code was because hg worked on plan 9,
and since then cinap wrote hgfs to make things even easier in the field.
While I appreciate the desire for a dashboard-overview of this sort of
thing, javascript is not a thing that happens on this operating system.

khm

Re: [9fans] [GSOC] plan9 which arch code to use?

[Jeremy Jackins]

[-- Attachment #1.1: Type: text/plain, Size: 261 bytes --]

On Thu, May 8, 2014 at 7:55 AM, Kurt H Maier <khm@sciops.net> wrote:

> thing, javascript is not a thing that happens on this operating system.
>

Here is a screenshot of a javascript interpreter running on plan 9.

https://github.com/robertkrimen/otto

[-- Attachment #1.2: Type: text/html, Size: 751 bytes --]

[-- Attachment #2: 2014-05-08-103427_708x409_scrot.png --]
[-- Type: image/png, Size: 11696 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[Kurt H Maier]

Quoting Jeremy Jackins <jeremyjackins@gmail.com>:

> On Thu, May 8, 2014 at 7:55 AM, Kurt H Maier <khm@sciops.net> wrote:
>
>> thing, javascript is not a thing that happens on this operating system.
>>
>
> Here is a screenshot of a javascript interpreter running on plan 9.
>
> https://github.com/robertkrimen/

Are you being deliberately disingenuous, or are you legitimately unable
to interpret context?

khm

Re: [9fans] [GSOC] plan9 which arch code to use?

[Jeremy Jackins]

[-- Attachment #1: Type: text/plain, Size: 267 bytes --]

I'm not trying to weigh in on the discussion. I posted the link in case
someone in the community is interested. This software has only been working
on plan 9 since fairly recently, thanks to a lot of hard work on the Go
port from a few members of this community.

[-- Attachment #2: Type: text/html, Size: 326 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[sl]

> 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 just because it seems to keep getting missed:
That work was only available to us because you made it available.

sl

Re: [9fans] [GSOC] plan9 which arch code to use?

[sl]

> 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 builds the amd64 userland, what does he do with
it? What would be the next step in making use of that userland?
Obviously, not booting a 386 kernel. My comments followed
the context of the conversation from its inception and were
relevant to the replies therein. The back-and-forth with Erik
(and later, you, Charles, etc.) branched out into other territory,
but this whole thread is based on a new guy being given weirdly
cryptic responses in reply to very basic confusion that is easy
to clear up if we just put together words in an obvious manner
and speak clearly. If it's silly to suggest one of the forks,
then it's equally silly to pretend an amd64 kernel is on the
table at all.

The chain was this:

prospective kernel hacker asks about amd64 ->
receives accurate answer ->
someone says no, no ->
explanation of building amd64 userland (with non-Labs code) ->
last minute revelation of relevant facts ->
someone points out that secrets, by definition, are not generally known ->
someone denies the obvious, casts aspersions on the forks ->
weird accusations ->
denials ->
arguing ->
complaints ->
this message

When did anyone plan on telling this guy that an amd64 kernel
is not even on the table?

Remember: The argument against investigating one of the forks
was that he should stick close to the Labs distribution, right?

When I said that people weren't aware of the full situation,
I was referring to the fact that nobody seemed to be aware
this guy had made prior arrangements to do work on Charles'
non-Labs code. He asked a common question about amd64
(ignoring for a moment the confusion about the difference
between VM host and guest CPU as seen by the guest OS) so
people gave him relevant answers. Then we stepped
on the apparent land mine. Now it's the fault of forks
for existing. All because nobody could just say: "Hack
on the 386 kernel because nothing else is in the official
distribution yet."

Why is this stuff always so difficult?

sl

Re: [9fans] [GSOC] plan9 which arch code to use?

[andrey mirtchovski]

> Why is this stuff always so difficult?

because on the internet nobody does "relax".

Re: [9fans] [GSOC] plan9 which arch code to use?

[sl]

>>  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
available amd64 kernels and were shot down.

Everything else follows from that. I agree, it's a bit
muddled at this point, but I've been responding directly
to things people have said. The mailing lists for each fork
are open to the public. E-mail addresses of principles are
all known. The only people who aren't at the party are the
ones who haven't bothered to show up. Again, where is the
problem? Are we supposed to hire professional coordinators
to make the process seem more official? It seems to me the
sort-of-articulated complaint is that all of this work is
not being conducted under the watchful eye of a centralized
authority.

Do you mean something like patch(1)? With work being
coordinated by staff at Bell Labs?


> 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.

People working on the forks are in constant contact. How could
the situation be improved?

My observation was that secret code helps no one. 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.

sl

Re: [9fans] [GSOC] plan9 which arch code to use?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

On 7 May 2014 22:38, <sl@9front.org> 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
of starting from sources (which was actually closer to the original
question).
normally, it wouldn't really matter, and i'd have kept out of it,
but in this case it did. i'm fairly sure nothing warranted the subsequent
comments that owe more to dan brown than reality.
(come to mention it, i did Dan Brown a favour last year, unwittingly.)

[-- Attachment #2: Type: text/html, Size: 1220 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[Bakul Shah]

> (come to mention it, i did Dan Brown a favour last year, unwittingly.)

There you go again.  More secrets....  :-)

Re: [9fans] [GSOC] plan9 which arch code to use?

[Kurt H Maier]

Quoting Charles Forsyth <charles.forsyth@gmail.com>:

> 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

Re: [9fans] [GSOC] plan9 which arch code to use?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 179 bytes --]

On 8 May 2014 02:38, Kurt H Maier <khm@sciops.net> wrote:

> haha you said exactly the same thing


I confined myself to instructions relating to sources, which isn't mine.

[-- Attachment #2: Type: text/html, Size: 464 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

On Wed May  7 21:40:05 EDT 2014, khm@sciops.net wrote:
> Quoting Charles Forsyth <charles.forsyth@gmail.com>:
>
> > they weren't "shot down", but saying use MY distribution over here,
> > or use MY distribution over here,

what i said was that both 9front and 9atom have the relevant bits in
an easily accessible location.  i mentioned this in an attempt to be
helpful, and i'm sorry it was not.

- erik

Re: [9fans] [GSOC] plan9 which arch code to use?

[balaji]

When Charles brought up that 64bit binaries can be built from Labs
distribution, it would have been so much simple if either 9atom or
9front owners took a quick look at what was there and confirmed what
he meant by "binaries".
To a lot of lurkers it's still not clear what the labs amd64 binaries
are. bootable kernel? commands?

On Thu, May 8, 2014 at 9:06 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Wed May  7 21:40:05 EDT 2014, khm@sciops.net wrote:
>> Quoting Charles Forsyth <charles.forsyth@gmail.com>:
>>
>> > they weren't "shot down", but saying use MY distribution over here,
>> > or use MY distribution over here,
>
> what i said was that both 9front and 9atom have the relevant bits in
> an easily accessible location.  i mentioned this in an attempt to be
> helpful, and i'm sorry it was not.
>
> - erik
>

Re: [9fans] [GSOC] plan9 which arch code to use?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 302 bytes --]

On 8 May 2014 15:14, balaji <balaji.srinivasa+plan9@gmail.com> wrote:

> To a lot of lurkers it's still not clear what the labs amd64 binaries
> are. bootable kernel? commands?
>

it turned out that it didn't include any of it, except the compilers. i am
attempting to address
this oversight.

[-- Attachment #2: Type: text/html, Size: 697 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[Anthony Sorace]

[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

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
amd64 machines).

> Some people (not knowing the full situation) offered advice
> about publicly available amd64 kernels and were shot down.

Again, that's not what happened. Erik and cinap pointed out
one can use 9atom or 9front; Charles gave instructions for
building the amd64 userland. He then, later, pointed out that
there are things other than just the 64-bit kernels in 9atom
and 9front. It's at that point some folks seem to have felt
compelled to dredge up the old mess of the original amd64
kernel, which was not what Charles was talking about and was
not otherwise at issue here.

I'm not sure who in this conversation you think is "not knowing
the full situation"; I'm fairly confident that all the salient points
on this topic have been discussed on 9fans ad nauseam.

> Everything else follows from that.

From two faulty premises. Got it.

You should re-read the thread. You may think you've been
responding to what people are actually saying, but the
bunker-mentality defensiveness you repeatedly exhibit has
caused you to misinterpret much.

As for how the situation could be improved: well, there's lots of
potential answers to that question. This has nothing to do with
hiring professional project managers or whatever you seem to
think is required for actual coordination, but taking some care
for your upstream sources is a really effective first step common
among open source projects. Try starting there.

Anthony

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]

On 7 May 2014 22:38, <sl@9front.org> 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 boot, was because
(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 the experimental development nix,
and a lot more besides was published. in the 6a/6c/6l/libc case, i did the
initial
initial compiler suite and libraries, and a chunk of the 64-bit clean-up,
andthat was indeed available years and years and years ago
(about 2005/6, i think). others contributed the other things on the list.
i can't help think that availability helped the other projects along a bit.

[-- Attachment #2: Type: text/html, Size: 1696 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

> (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 the experimental development nix,
> and a lot more besides was published. in the 6a/6c/6l/libc case, i did the
> initial
> initial compiler suite and libraries, and a chunk of the 64-bit clean-up,
> andthat was indeed available years and years and years ago
> (about 2005/6, i think). others contributed the other things on the list.
> i can't help think that availability helped the other projects along a bit.

yes, and it was very good work.  thank you.
i'm glad it was baked in so long ago.  it's always
been a pleasant surprise to find a uintptr in some
code that hasn't been touched for years.

- erik

Re: [9fans] [GSOC] plan9 which arch code to use?

[sl]

>> 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 everyone fixes Plan 9 to
work on their computers then Plan 9 will fall into disrepair?

What has changed is this: Code is being made available
because some people decided to make their code available.
Notice the key phrase: "make their code available." Anyone can
take that code and do with it whatever they want. The major result
is that now Plan 9 now runs on more computers. Some bugs got fixed.
Some new (useful) programs got written. These things only happened
because those people made their changes available. Otherwise, we
wouldn't even know it had been done. I have trouble seeing this
as a net loss.

On the other hand, innuendo about code that may or may not ever
be released doesn't help anyone, and at this point serves as
little more than the traditional way to end a conversation.
By now this tradition is decades old. Feels great! I agree with
you that over 9,000 private projects that don't communicate with
each other and keep their results secret don't result in progress.
You can tell because the definition says that the results are kept
secret. The difference between that and what is happening with the
forks is that the changes made by the forks (including your own)
are available for anyone to read, use, adopt -- or not -- at their
own discretion. The important morsel to digest here is that the
code is out there for people to evaluate. It's not just a legend.
Not just a rumor. You can read it, compile it, run it; then decide
what to do with it. Again, I have trouble seeing why this is a
problem, or how it makes the situation worse than what we have
already lived with since long before the forks came into
existence.

I hope everyone gets good use out of whatever Plan 9 code
they manage to load onto their computers. I enjoy using Plan 9
and I enjoy talking to people who are still working on Plan 9.

If you want to keep secrets, keep them. But nothing done by
any of the forks is secret. Just take the code and do with it
what you will. Why is this controversial?

sl

Re: [9fans] [GSOC] plan9 which arch code to use?

[Anthony Sorace]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

>  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 and releasing the results.

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 into disrepair" is that if everyone is spending time fixing the same issues, each on their own without any coordination, is that the resulting system will increasingly fail to keep up with the evolution of the surrounding world. Even if the code for all the parts I need to drive exist, that's not the same as having a running system.

Anthony


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[Lyndon Nerenberg]

[-- Attachment #1: Type: text/plain, Size: 1626 bytes --]


On May 7, 2014, at 2:17 PM, Anthony Sorace <a@9srv.net> 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 into disrepair" is that if everyone is spending time fixing the same issues, each on their own without any coordination, is that the resulting system will increasingly fail to keep up with the evolution of the surrounding world. Even if the code for all the parts I need to drive exist, that's not the same as having a running system.

I do think there is an analogy to be made with the 4.x BSD releases.  They were few and far between, but they were also the prescriptive reference points for that UNIX fork.  There was a lot of development that branched off from the UCB code base.  But much of what was of benefit to all (device drivers, VM enhancements, apps) was folded back into the core.  The CSRG encouraged that.  And with the CSRG releases as a reference, it wasn't that difficult to share local modifications between sites.

But the Labs are not the CSRG.  There is no longer a central focus point for the code base.  Not in the community sense – the Labs are no longer interested.  We are losing the 'reference implementation' from which the branches can be compared.  Without an anchor we will drift off in many incompatible directions, to the point where code sharing will become so annoying it just won't happen (in the kernel at least, and in the /dev/* user space as a side effect).

--lyndon


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 817 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[lucio]

> We are losing the 'reference implementation' from which the branches can be compared.

But is this a necessary consequemce of Bell Labs' distance, or merely
the way the community operates?  A reference point need not itself be
in use by all involved, it just needs to move slowly enough for a few
responsible parties to ensure that it remains a reference point.  Give
9atom x 2 and 9front (in whichever guise), together with the ARM
implementations (which I believe are much closer to the Bell Labs
release), it is not that onerous to make sure that there is a base
point for everyone out there.

I can see the weak points of such an approach, but is it any worse
than the current situation?

++L

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

On Thu May  8 07:59:12 EDT 2014, lucio@proxima.alt.za wrote:
> > We are losing the 'reference implementation' from which the branches can be compared.
>
> But is this a necessary consequemce of Bell Labs' distance, or merely
> the way the community operates?  A reference point need not itself be
> in use by all involved, it just needs to move slowly enough for a few
> responsible parties to ensure that it remains a reference point.  Give
> 9atom x 2 and 9front (in whichever guise), together with the ARM
> implementations (which I believe are much closer to the Bell Labs
> release), it is not that onerous to make sure that there is a base
> point for everyone out there.

since it's not clear to me from reading this (forgive my reading comprehension),
i run 9atom on rb, kw, and rpi in addition to amd64.  i run the pc and pcpae
kernels when there are changes.  i know others also run 9atom on the rb.
sadly i don't have a teg2 or original beagle.

- erik

Re: [9fans] [GSOC] plan9 which arch code to use?

[lucio]

> since it's not clear to me from reading this (forgive my reading comprehension),
> i run 9atom on rb, kw, and rpi in addition to amd64.  i run the pc and pcpae
> kernels when there are changes.  i know others also run 9atom on the rb.
> sadly i don't have a teg2 or original beagle.

One can interpret this as advocacy for 9atom or confrontation against
the Bell Labs release.  It's OK, I am more of a bigot for sticking to
the BLR than you are for promoting your valuable efforts, but I don't
want to disclose all the reasons for me being such a bigot, it would
be boring without being "relaxing".

However, the issue remains that there could be one true Plan 9 if the
community kept their bigotry under control and contributed useful
effort in its stead.  Now, there are two major hurdles in my opinion,
and everything pales against them.  Feel free to argue with that, I'm
not adequately informed and much prepared to learn:

(1) Bell Labs are lagging behind 9atom and 9front in support for a lot
of hardware (old and new), a situation that, by getting progressively
worse may cause them to drop out of the race altogether and (2) The
amount of effort and ego bashing required to bring the different
releases in line is considerable and no one is likely to take such a
mission on without knowing that, at minimum, the "owners" of the
various distributions are willingly supportive of such efforts.

Now, point (1) can be addressed by treating the Bell Labs distribution
as one more "fork" and proceeding towards a new distribution which
will eventually be accepted by Bell Labs as well, while (2) needs the
Plan 9 community to rally behind a single communication channel, open
to all willing contributors and lurkers, where amendments to each fork
are submitted for discussion.  In particular, it is essential that CLs
be shaped in a way that each fork can accept them, especially the
convergence fork.

Now, I'm not in a position to suggest how each of these objectives can
be attained and if I go off and do something like I proposed earlier,
there will be little chance that my efforts will stay ahead of
environmental changes.  Thus, I think the floor should be opened to
all interested parties to discuss how we can combine our efforts with
minimal cost in resources.

We have no deadlines, we just need to have clear objectives and
willing contributors.  Doing without detractors would be great, but I
wouldn't count on that much.

++L

Re: [9fans] [GSOC] plan9 which arch code to use?

[sl]

> 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

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

On Wed May  7 16:00:21 EDT 2014, sl@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 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.

- erik

Re: [9fans] [GSOC] plan9 which arch code to use?

[Jacob Todd]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

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" <quanstro@quanstro.net> wrote:

> On Wed May  7 16:00:21 EDT 2014, sl@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 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.
>
> - erik
>
>

[-- Attachment #2: Type: text/html, Size: 1033 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[Lyndon Nerenberg]

[-- Attachment #1: Type: text/plain, Size: 349 bytes --]

[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 quit following the mailing list.

--lyndon


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 817 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[lucio]

> It is this ongoing level of petty pissiness that has led to the fragmentation of the community.

It's poorly phrased and even offensive, but the answer is not out
there in the public domain.  Nor is the list of tasks to be undertaken
in the shape for a GSOC project.

But maybe, just maybe, if the community can get its act together to
support a "codereview" type approach, we can ask Coraid to sponsor the
minimum resources required by it.  I don't have a clue to the details,
but I would be thrilled to contribute.

And I would start with one of 9front ot 9atom and submit CLs to
improve the Bell Labs foundation.  Participation by JMK or Geoff would
be optional and extremely welcome.

And maybe there are others out there who could step up to the plate if
Coraid cannot provide some financial support?

++L

Re: [9fans] [GSOC] plan9 which arch code to use?

[sl]

>> 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 can be done with their
changes.

Enjoy.

sl

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

> > 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 particularly useful as a tinker-toy
set.  especially when there are 10 wheels and 1 stick.

- erik

Re: [9fans] [GSOC] plan9 which arch code to use?

[sl]

> 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 Plan 9 on their computers.

sl

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

On Wed May  7 14:33:08 EDT 2014, sl@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 moot.

right, perhaps because it is duplicated and there is no one version.

> 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.

- erik

Re: [9fans] [GSOC] plan9 which arch code to use?

[lucio]

> 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 drop support for the hardware I
have in favour of hardware I cannot afford.

I can see how one would approach this problem in a fair manner, but I
appreciate that the cost would be higher.  For example, I'm using AC97
audio on this workstation, after putting some trouble into fitting it
into the Bell Labs distribution (nothing much, in fact, still...).
Now, this is incompatible with the original Soundblaster stuff and no
one seems to care to deal with the incompatibilities.  That's where
the community needs to be encouraged to take on low-benefit projects.

++L

Re: [9fans] [GSOC] plan9 which arch code to use?

[cinap_lenrek]

> Now, this is incompatible with the original Soundblaster stuff and no
> one seems to care to deal with the incompatibilities.
wrong. it has been dealed with.

--
cinap

Re: [9fans] [GSOC] plan9 which arch code to use?

[lucio]

>> Now, this is incompatible with the original Soundblaster stuff and no
>> one seems to care to deal with the incompatibilities.
> wrong. it has been dealed with.

Not in the Bell Labs distribution, it hasn't.  At least, not that I noticed.

And that was just a convenient example.

++L

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

On Thu May  8 07:22:41 EDT 2014, lucio@proxima.alt.za wrote:
> >> Now, this is incompatible with the original Soundblaster stuff and no
> >> one seems to care to deal with the incompatibilities.
> > wrong. it has been dealed with.
>
> Not in the Bell Labs distribution, it hasn't.  At least, not that I noticed.
>
> And that was just a convenient example.

i'm quoting from your original post:

	Now, this [ac97] is incompatible with the original Soundblaster stuff and no
	one seems to care to deal with the incompatibilities.  That's where

so, someone (cinap) does care about the incompatabilities and has addressed them.
i think what you're saying is nobody has gotten this in to the distribution.
fair point.  why don't you submit a patch?

- erik

Re: [9fans] [GSOC] plan9 which arch code to use?

[lucio]

> so, someone (cinap) does care about the incompatabilities and has addressed them.
> i think what you're saying is nobody has gotten this in to the distribution.
> fair point.  why don't you submit a patch?

I ought to, I'm not sure how soon I'll get to it (I'm just a normal
Joe, I also fix problems once and hope they don't come back, instead
of fixing them at source).  I do get your drift and I specifically
decline to get drawn into criticising Bell Labs for being slow in
accepting patches as an excuse for _my_ inertia, even though I think
such criticism is warranted, but not constructive (that also
contributed to JMK dropping off 9fans).

I also don't yet have a working version of 9front and (feeble excuse)
not enough Internet credits to sustain efforts to stay with 9front and
9atom (although I'm sure I could make the additional effort at least
once).

Feeble, indeed, but let's look beyond that at what would be
possible and maybe we can find a way to make it inevitable.

++L

Re: [9fans] [GSOC] plan9 which arch code to use?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

On 8 May 2014 13:46, <lucio@proxima.alt.za> wrote:
>
> not enough Internet credits to sustain efforts ...
>

Or a working e-mail supplier (they've blocked Google):

Delivery to the following recipient failed permanently:

     lucio@proxima.alt.za

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the server for
the recipient domain proxima.alt.za by mumble.proxima.alt.za.
[192.96.32.140].

The error that the other server returned was:
550 5.7.1 Rejected: 209.85.212.169 listed at rbl.proxima.alt.za

[-- Attachment #2: Type: text/html, Size: 2732 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[Kurt H Maier]

Quoting Charles Forsyth <charles.forsyth@gmail.com>:

> On 8 May 2014 13:46, <lucio@proxima.alt.za> wrote:
>>
>> not enough Internet credits to sustain efforts ...
>>
>
> Or a working e-mail supplier (they've blocked Google):
>

This is what happens when people vote for Julius Malema.

khm

Re: [9fans] [GSOC] plan9 which arch code to use?

[lucio]

> This is what happens when people vote for Julius Malema.

How do you know this?

++L

Re: [9fans] [GSOC] plan9 which arch code to use?

[lucio]

> Delivery to the following recipient failed permanently:

My fault, my spam rules reject and ban IP addresses if mail is sent to
a non-existent recipient in the "proxima.alt.za" domain.  I have
whitelisted a block of gmail IPs, but that's a moving target.

Should be fixed now.

++L

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

On Thu May  8 10:06:35 EDT 2014, lucio@proxima.alt.za wrote:
> > Delivery to the following recipient failed permanently:
>
> My fault, my spam rules reject and ban IP addresses if mail is sent to
> a non-existent recipient in the "proxima.alt.za" domain.  I have
> whitelisted a block of gmail IPs, but that's a moving target.
>
> Should be fixed now.

i hate to suggest something that i've done on this list, but nupas
(upas in 9atom) has full support for spamhaus, so you can delegate
this problem.

- erik

Re: [9fans] [GSOC] plan9 which arch code to use?

[lucio]

> i hate to suggest something that i've done on this list, but nupas
> (upas in 9atom) has full support for spamhaus, so you can delegate
> this problem.

This list doesn't hate you :-)

I use my Gmail address for nearly everything these days, so I have
little reason to mess with a complicated procmail setting that impacts
only a few messages a year.  I'm sorry that occasionally it hits
perfectly innocent bystanders.  That's the result of bad thinking by
the Internet's fathers and isn't going to stop any time soon.

++L

Re: [9fans] [GSOC] plan9 which arch code to use?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 149 bytes --]

On 8 May 2014 15:51, <lucio@proxima.alt.za> wrote:

> That's the result of bad thinking by
> the Internet's fathers
>

you blame the parents?

[-- Attachment #2: Type: text/html, Size: 504 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[lucio]

> you blame the parents?

I've been known to.  In this case, I do think the stage was set,
rather than grabbed.  Of course, opinions are allowed to differ.

++L

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

On Thu May  8 01:57:57 EDT 2014, lucio@proxima.alt.za wrote:
> > 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 drop support for the hardware I
> have in favour of hardware I cannot afford.
>
> I can see how one would approach this problem in a fair manner, but I
> appreciate that the cost would be higher.  For example, I'm using AC97
> audio on this workstation, after putting some trouble into fitting it
> into the Bell Labs distribution (nothing much, in fact, still...).
> Now, this is incompatible with the original Soundblaster stuff and no
> one seems to care to deal with the incompatibilities.  That's where
> the community needs to be encouraged to take on low-benefit projects.
>

; lc /sys/src/9/pc/audio*
audioac97.c	audioac97m.c	audiohda.c	audiosb16.c

- erik

Re: [9fans] [GSOC] plan9 which arch code to use?

[sl]

>> your options are 9atom or 9front.
>
>
> well no, no they aren't.

What are the other options?

sl

[9fans] [GSOC] plan9 which arch code to use?

[yan cui]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

Dear all,

     I was confused by one experiment which is done today.
My machine is x86_64 and I run Plan9 inside KVM. According to my
understanding, operating system should detect which hardware platform it is
running (x86, sparc, etc) and automatically invoke
corresponding arch-dependent codes. But, when I echo $cputypes,
it is 386! I also browse some kernel config file in /sys/src/9/pc, it seems
that plan9 forces to use 386 for Intel cpus (right?). Please tolerate if I
made stupid mistakes, I just wonder how to make a amd64 kernel? (My
hardware already supports that.)



Thanks, Yan


--
Think big; Dream impossible; Make it happen.

[-- Attachment #2: Type: text/html, Size: 935 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[cinap_lenrek]

official plan9 has no amd64 kernel in the distribution.
use 9atom or 9front.

--
cinap

Re: [9fans] [GSOC] plan9 which arch code to use?

[yan cui]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

Got it, Thanks Cinap!


2014-05-06 17:33 GMT-04:00 <cinap_lenrek@felloff.net>:

> official plan9 has no amd64 kernel in the distribution.
> use 9atom or 9front.
>
> --
> cinap
>
>


--
Think big; Dream impossible; Make it happen.

[-- Attachment #2: Type: text/html, Size: 595 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

On 6 May 2014 22:00, yan cui <ccuiyyan@gmail.com> wrote:

> But, when I echo $cputypes,
> it is 386!


where the hardware can do either, the kernel you boot chooses the cputype
to suit itself.
/sys/src/9/pc is only 386 (ie, 32-bit x86). another directory is used for
amd64 (ie, 64-bit x86).
you can use the 386 kernel to compile and install the /amd64 environment
though,
which you'll need to do before running an amd64 kernel.

[-- Attachment #2: Type: text/html, Size: 828 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[yan cui]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

OK, I will try to do that.


2014-05-06 17:47 GMT-04:00 Charles Forsyth <charles.forsyth@gmail.com>:

>
> On 6 May 2014 22:00, yan cui <ccuiyyan@gmail.com> wrote:
>
>> But, when I echo $cputypes,
>> it is 386!
>
>
> where the hardware can do either, the kernel you boot chooses the cputype
> to suit itself.
> /sys/src/9/pc is only 386 (ie, 32-bit x86). another directory is used for
> amd64 (ie, 64-bit x86).
> you can use the 386 kernel to compile and install the /amd64 environment
> though,
> which you'll need to do before running an amd64 kernel.
>



--
Think big; Dream impossible; Make it happen.

[-- Attachment #2: Type: text/html, Size: 1351 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

On 6 May 2014 22:47, Charles Forsyth <charles.forsyth@gmail.com> wrote:

> you can use the 386 kernel to compile and install the /amd64 environment
> though,
> which you'll need to do before running an amd64 kernel.
>

more precisely, do

cd /sys/src
objtype=amd64 mk install

[-- Attachment #2: Type: text/html, Size: 767 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 274 bytes --]

On 6 May 2014 22:56, Charles Forsyth <charles.forsyth@gmail.com> wrote:

> more precisely, do
>
> cd /sys/src
> objtype=amd64 mk install
>

actually, i use

cd /sys/src; objtype=amd64 mk -k install
so that if something's broken, it will build as much as it can.

[-- Attachment #2: Type: text/html, Size: 816 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[cinap_lenrek]

nobody expects the spanish inquisition :)

--
cinap

Re: [9fans] [GSOC] plan9 which arch code to use?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

On 6 May 2014 22:59, Charles Forsyth <charles.forsyth@gmail.com> wrote:

> actually, i use
>
> cd /sys/src; objtype=amd64 mk -k install
> so that if something's broken, it will build as much as it can.
>

and just before THAT, in case /amd64/bin itself is only partially there:

mkdir -p /amd64/bin/^(ape auth aux bitsy dial disk fossil fs games ip ndb
oventi pub replica upas usb venti aux/jot aux/style ip/httpd) /amd64/lib/ape

[-- Attachment #2: Type: text/html, Size: 1028 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[lucio]

> mkdir -p /amd64/bin/^(ape auth aux bitsy dial disk fossil fs games ip ndb
> oventi pub replica upas usb venti aux/jot aux/style ip/httpd) /amd64/lib/ape

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.

++L

Re: [9fans] [GSOC] plan9 which arch code to use?

[David du Colombier]

> The Bell Labs distribution does not seem to have a libc/amd64.

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

--
David du Colombier

Re: [9fans] [GSOC] plan9 which arch code to use?

[lucio]

> 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

[9fans] [GSOC] plan9 which arch code to use?

[Riddler]

[-- Attachment #1: Type: text/plain, Size: 117 bytes --]

Out of curiosity is there a reason that the patches for a 64bit install
never ended up in the main plan9 codebase?

[-- Attachment #2: Type: text/html, Size: 133 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]

On 7 May 2014 09:38, Riddler <riddler876@gmail.com> 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 version that was closest to plan 9 was incomplete on amd64, and
never released except for powerpc where most of the work was done,
and the other forks that were released for amd64 were more experimental
(eg, Nix). A year or two back a further attempt was made
to retrace and set out again, because so much old crud had got added back
in,
but that stalled when several of us ran out of time or got too busy. At the
time, none of us was interested in adding yet more unfinished
or unpolished software to the big cloudy bitbuckets.
I'm sure at least one of those will be back soon.

There was, however, a parallel effort to allow a more conventional licence,
which did finally prosper.

[-- Attachment #2: Type: text/html, Size: 1615 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

+++ /sys/src/ape/lib/ap/amd64/atom.s
@@ -0,0 +1,75 @@
+TEXT ainc(SB), $0	/* long ainc(long *); */
+	MOVL	addr+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 in ape?

- erik

Re: [9fans] [GSOC] plan9 which arch code to use?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

On 7 May 2014 10:05, erik quanstrom <quanstro@quanstro.net> 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*);

[-- Attachment #2: Type: text/html, Size: 872 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

> On 7 May 2014 10:05, erik quanstrom <quanstro@quanstro.net> 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 very late in the game (2013), and iirc, the only
place ainc was actually used was the 64-bit kernel, and
its definition was int ainc(int*).

- erik

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

!/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 <quanstro@quanstro.net> 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 very late in the game (2013), and iirc, the only
> place ainc was actually used was the 64-bit kernel, and
> its definition was int ainc(int*).

sent too soon.  so this allows a reference count to be just
an int.  i also felt int ainc(int*) fit better with the other
atom(2) functions, which have a suffix of 32, 64, l or p added
when the argument is not an int.

so what i did assumes that there could be an aincl, aincp,
ainc32, ainc64, but there just isn't.

the definition "long ainc(long*)" seems to assume there is
only one ainc.  and i can't see why the argument should be
a long.  that would make it 64-bits in an lp64 model, which
may not be what was intended.

- erik

Re: [9fans] [GSOC] plan9 which arch code to use?

[David du Colombier]

> 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

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

On Wed May  7 05:24:00 EDT 2014, 0intro@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

Re: [9fans] [GSOC] plan9 which arch code to use?

[David du Colombier]

> 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 written by jmk. The second is an attempt to synchronize
with the changes made in Plan 9 on September 2013.

--
David du Colombier

Re: [9fans] [GSOC] plan9 which arch code to use?

[lucio]

> 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 NetBSD for sys/socket.h, lib/bsd/connect.c,
lib/bsd/getpeername.c and lib/bds/getsockname.c, I get pretty far
along, failing on:

	inittraps: undefined: sigemptyset in inittraps

while building pdksh.

I'm sure I can track this down, but perhaps somebody has already taken
care of this issue?  I haven't yet checked Charles' posting.

++L

Re: [9fans] [GSOC] plan9 which arch code to use?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 158 bytes --]

On 7 May 2014 12:13, <lucio@proxima.alt.za> wrote:

>  I haven't yet checked Charles' posting.


that won't have anything to do with wider APE support.

[-- Attachment #2: Type: text/html, Size: 459 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

On Wed May  7 07:15:46 EDT 2014, lucio@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 patches, plus a little tweaking because I've
> updated APE to be closer to NetBSD for sys/socket.h, lib/bsd/connect.c,
> lib/bsd/getpeername.c and lib/bds/getsockname.c, I get pretty far
> along, failing on:
>
> 	inittraps: undefined: sigemptyset in inittraps
>
> while building pdksh.
>
> I'm sure I can track this down, but perhaps somebody has already taken
> care of this issue?  I haven't yet checked Charles' posting.

from my perspective, it's hard to see this patch issue.
9atom is my attempt at bringing the system
together with a amd64 port. it's not perfect, but that's
why i've always encouraged patches.  i don't want it to be
a solo effort; it should be a community project.

(9atom is actually incorporated as a non profit in the US.)

could explain why these patches made sense for you rather
than the atom stuff?

- erik

Re: [9fans] [GSOC] plan9 which arch code to use?

[lucio]

> 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 release
(i386) that would allow me to build either 9atom or 9front releases
with minimal adjustments.

It probably needs one additional layer above the conventional Bell
Labs /sys/src, but it seems feasible.  I confess I did not think very
hard about it, but the instructions just look so temptingly simple...

++L

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

> 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 releases
> with minimal adjustments.

if everybody does their own thing, perhaps we spend all our collective
time doing the same thing, and no progress is made?

just an observation.  and obviously there are tradeoffs.  i'll give you that
i love to do things my self.  let me know if you see anything in atom that causes
issues.  certainly a goal is to keep these to a minimum.

the atom stuff of course came about for three reasons that were not
solved elsewhere at the time: working with certain hardware, 21-bit
runes, and production amd64 support.

i think all of these are at least to some extent still valid.  there are gaps
in the distribution's 21-bit rune support, and the hardware support gap
may have increased.

- erik

Re: [9fans] [GSOC] plan9 which arch code to use?

[lucio]

[-- Attachment #1: Type: text/plain, Size: 3055 bytes --]

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 Labs distribution, I'm complicating thing rather
than simplify them, but that is the only approach that has caught my
attention.  And I am listening to the limited discussion on this forum
and, no, I am not paying attention to other discussions that may be
taking place elsewhere and to which I either have not been invited or
from which I have been explicitly been expelled.

Now, bear with me for a minute.

David has some good stuff lying around that, like much other stuff,
needs to be reviewed before it is incorporated with the Bell Labs
distribution.  Like me, I believe that David's preferrence is to
remain with the Bell Labs stuff, whatever his motives.  Mine, in
passing, are to secure portability for Plan 9 across architectures,
idiotic as that may be (I despise the Intel 8088 and all its progeny).

Then there is 9atom and 9front that I am aware of, neither of which I
am really familiar with, but both of which I respect, greatly, the
genesis of.  Now, I am human and not a particularly clever specimen of
my species, therefore I am picking familiarity over features as my
foundations: I know that - bar DNS glitches - the Bell Labs
distribution is robust and also the most conservative of the options
out there, or maybe just the slowest moving, so it makes a good rock
to build a castle on.

What's missing in this picture is the tool chest to add walls to this
rock, as 9atom (you, Erik, with few assistants) and 9front (cinap and
what seems like a superb, youthful team) have already done in their
own way.  So we have plenty of bricks, some master masons and a
community that, at least in small ways, is no doubt willing to
contribute.

But there is no code review facility (unless you call "patch" a code
review tool - I'm afraid the real thing has spoiled me rotten, despite
some shortcomings) and no trusted code review board to push along
deserving fixes.  Perhaps we can also have a team that takes on ideas
that either have no corresponding code or where implementation does
not pass review and makes the necessary adjustments, subject to review
as well as cooperation from the original submitter(s).

I know I can make the time to participate in such an effort, I'm not
sure who else might be willing.  I also know that there are
personality problems as well as ideology problems, but I always
believed that these can be overcome in a technological environment
where financial incentives are not dominating.

Anyway, the elections in South Africa are distracting me, so I'm not
going to take this further now, but I'd be delighted to hear from
like-thinking developers as well as from those who may want to
approach this problem from a very different perspective.

++L

[-- Attachment #2: Type: message/rfc822, Size: 3937 bytes --]

From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: Re: [9fans] [GSOC] plan9 which arch code to use?
Date: Wed, 7 May 2014 14:22:42 -0400
Message-ID: <b3a9f25efdffc75e75b05f92e972a14d@ladd.quanstro.net>

> 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 releases
> with minimal adjustments.

if everybody does their own thing, perhaps we spend all our collective
time doing the same thing, and no progress is made?

just an observation.  and obviously there are tradeoffs.  i'll give you that
i love to do things my self.  let me know if you see anything in atom that causes
issues.  certainly a goal is to keep these to a minimum.

the atom stuff of course came about for three reasons that were not
solved elsewhere at the time: working with certain hardware, 21-bit
runes, and production amd64 support.

i think all of these are at least to some extent still valid.  there are gaps
in the distribution's 21-bit rune support, and the hardware support gap
may have increased.

- erik

Re: [9fans] [GSOC] plan9 which arch code to use?

[Charles Forsyth]

[-- Attachment #1.1: Type: text/plain, Size: 404 bytes --]

On 7 May 2014 06:14, <lucio@proxima.alt.za> 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 that David posted. Clearly it would help to
push the files into sources.

[-- Attachment #1.2: Type: text/html, Size: 800 bytes --]

[-- Attachment #2: amd64.tgz --]
[-- Type: application/x-gzip, Size: 19860 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

On Wed May  7 04:47:05 EDT 2014, charles.forsyth@gmail.com wrote:

> On 7 May 2014 06:14, <lucio@proxima.alt.za> 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 that David posted. Clearly it would help to
> push the files into sources.

alternately, the source is available on sources.9atom.org. /n/atom/plan9/...

is there a reason for "/amd64/include/gnu/*"?

- erik

Re: [9fans] [GSOC] plan9 which arch code to use?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

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
former, and I am providing the latter, which will end up
on googlecode as a working environment, but one step at a time.

[-- Attachment #2: Type: text/html, Size: 606 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

On Wed May  7 05:21:03 EDT 2014, charles.forsyth@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 for
> the system and the kernel. Sources provides a conservative base for the
> former, and I am providing the latter, which will end up
> on googlecode as a working environment, but one step at a time.

that makes sense.  and good luck.  it's an interesting project.

- erik

Re: [9fans] [GSOC] plan9 which arch code to use?

[Kurt H Maier]

Quoting Charles Forsyth <charles.forsyth@gmail.com>:

> 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
> former, and I am providing the latter, which will end up
> on googlecode as a working environment, but one step at a time.

Sorry, wasn't aware this is an SP9SSS affair.  Might be useful to mention
that fact when you're telling your junior initiates things that mere
mortals aren't allowed to fathom.

khm

Re: [9fans] [GSOC] plan9 which arch code to use?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 151 bytes --]

On 7 May 2014 13:59, Kurt H Maier <khm@sciops.net> wrote:

> Sorry, wasn't aware this is an SP9SSS affair.


nothing secret; just what happened.

[-- Attachment #2: Type: text/html, Size: 437 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

On Wed May  7 09:37:51 EDT 2014, charles.forsyth@gmail.com wrote:

> On 7 May 2014 13:59, Kurt H Maier <khm@sciops.net> 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 at cross purpose in the future?

i'm not interested in whatever water went under the bridge.
it is assuredly wet.

- erik

Re: [9fans] [GSOC] plan9 which arch code to use?

[Kurt H Maier]

Quoting yan cui <ccuiyyan@gmail.com>:

> My machine is x86_64 and I run Plan9 inside KVM.

The architecture of the hypervisor has little bearing on the architecture
of the KVM guest environment.   Check your kvm configuration (or the options
passed to the qemu process) to see which cpu has been specified for the guest.

khm

Re: [9fans] [GSOC] plan9 which arch code to use?

[erik quanstrom]

On Tue May  6 18:26:58 EDT 2014, ccuiyyan@gmail.com wrote:

> Dear all,
>
>      I was confused by one experiment which is done today.
> My machine is x86_64 and I run Plan9 inside KVM. According to my
> understanding, operating system should detect which hardware platform it is
> running (x86, sparc, etc) and automatically invoke
> corresponding arch-dependent codes. But, when I echo $cputypes,
> it is 386! I also browse some kernel config file in /sys/src/9/pc, it seems
> that plan9 forces to use 386 for Intel cpus (right?). Please tolerate if I
> made stupid mistakes, I just wonder how to make a amd64 kernel? (My
> hardware already supports that.)

good question.  /sys/src/9/pc is a 386 kernel.  it runs 386 code on anything
that at least supports a 386 regardless of the hardware support.  if you
think about it, supporting more than one instruction set with a single
kernel has some added difficulties.

as cinap mentions, for a 64-bit kernel, your options are 9atom or 9front.
since i work with 9atom, i'll speak to it.  you can just install 64-bit with
no muss or fuss, if the hardware is supported.  let me know if there are
issues.  if you already have something working, then nevermind.  :-)

- erik

Re: [9fans] [GSOC] plan9 which arch code to use?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 137 bytes --]

On 7 May 2014 01:40, erik quanstrom <quanstro@quanstro.net> wrote:

> your options are 9atom or 9front.


well no, no they aren't.

[-- Attachment #2: Type: text/html, Size: 430 bytes --]

Re: [9fans] [GSOC] plan9 which arch code to use?

[Kurt H Maier]

Quoting Charles Forsyth <charles.forsyth@gmail.com>:

> On 7 May 2014 01:40, erik quanstrom <quanstro@quanstro.net> wrote:
>
>> your options are 9atom or 9front.
>
>
> well no, no they aren't.

exactly what value is that comment supposed to add to anyone's day

Re: [9fans] [GSOC] plan9 which arch code to use?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 231 bytes --]

On 7 May 2014 02:12, Kurt H Maier <khm@sciops.net> wrote:

> well no, no they aren't.
>>
>
> exactly what value is that comment supposed to add to anyone's day


sorry, i meant that isn't the full set of relevant choices.

[-- Attachment #2: Type: text/html, Size: 692 bytes --]