I don't really care about 64-bit.  Plan 9 is 32-bit.
Logos are a sensitive thing and they can hurt a project if not chosen very
carefully.
How do people feel about converting all the mkfiles to makefiles?
I'd like to remove as many dependencies on Plan 9 flavored tools as possible.
People just don't like them that much.
There are some changes we have to make that will require us to abandon Ken C for
good.
Can you remind me how to get mk to use rc, not /bin/sh?  I forget.
And wow, clang is so fast, at least as fast as ken c.
And, yes, we can remove acid, upas, and the ken toolchain, must as it hurts :-)
What's the next step folks?
Let's not be too hard on Rob.
It's gnu at front, and it becomes plan 9 where I stopped working.
This is really great.  We are getting close.
We'll get there.
weird.
This is getting *CLOSE*
Oh well.
I have done more of these plan 9 ports than I can remember.
We should make our binaries compatible with linux
It doesn't quite work.  But it almost works.
Don't worry, it's going to make sense soon.
we're dying
The question now is, what's going on?
where are we?  did everyone give up and go home?
There's something simple and stupid going on here.
The question is, do we want to support old plan 9 binaries?
That's about it for Ken C. It was great 20 years ago, but time moves on.
I love the build script.  No more weird mounts, mk and rc are out of my life, ah
joy.
Something's wrong.
You're going to need to use gdb.
This is great.
more people!!!!  wondeful!
I've talked to a former BL guy at Google, and he likes this work but would much
prefer to see us move to clang ASAP.  Just FYI.
whatever.
I'm lost.
how hard is it to NOT run SMP?
I think the best way to do config files from here on out is JSON.
Akaros can't boot from a disk on real hardware.
NIX never got disk drives.
I expect insults which is why I don't read 9fans.
Kenc won't ever work on harvey.
kenc is dead.
Change anything that uses factotum to use ssh-agent instead.
Factotum was interesting.  It failed.  Let's move on.
we're ready for the web site.  What do we do now?
Downside I suspect for some of you is that it does require an NDA for now.
we had several of the grand old Bell Labs guys at the BOF least night.  And, they
all offered their congratulations.
I am pretty certain it will work fine, which is why I like it so much.
Tty is a GREAT focus.
awesome.
OK, let's make it an action to get rid of embedded structs.
There's definitely some language barrier stuff getting in our way.
I was showing my family the Harvey logo.
I think factotum had its chance and was not accepted.
I would leave the project if autotools were ever brought in.
People never really accepted factotum outside Plan 9, and there are systems out
there that do the job it did as well or better.
I rebuilt the kernel from the ToT (tip of tree), built go from same, and when I
run the go command the system locks up.
Turns out the license is horrible.
Let's see what happens!
Even an rc script would be nice.
Make sure when you suggest build.go changes that you are certain you can't make
those changes in a .json file.
point taken.
not really.
I'm not sure what you mean.
So, folks, we need programmers ...
we can think a little about async io.
can somebody do a go test and see if it helps?
We were not supposed to break SMP for NIX.  Looks like we did at some point.
Damn.
I don't read 9 fans so if this bug fix is needed bring it over.
Let's us break with cruft.
does ahci fail in qemu?
it's a little complex.
here's the acid test: can we build openssh?
boy issue trackers are fun.
you are right, the problem is harvey.
The standard way in to Plan 9 is drawterm.
It's usually easier than that.
It's fine.
I don't even care that it's not really plan 9 style
My big mission with harvey is to use it as a coreboot payload.
We replaced all these different file formats with .json, and all the random
mkfiles, scripts, and tools with one script, build.go.
so where are we?
Can we close this issue now?
one thing coreboot does it put some nice pictures on the home page.
the other thing I forgot: drawterm is for cpu servers.
Wow, some of these bugs ....  they are from Plan 9 originally.
9p is a dog.
There is a real value of having build files using JSON that can be automatically
processed by a Go tool.
I want to get it working but I'm hoping someone else will also be interested.
If you want to improve 9p a good place to start is Floren's master's thesis.
Yep, looks like we screwed up.
Remember, this is plan 9.
I think a lot of things really need Go to be done well.
if we can define what we need done, it should be easy.
well, there's lots of ways to do this.
Then convince yourself this looks like a good idea.
I've learned the hard way, over that last 15 years, that we need vi and emacs.
That's heresy but it's also reality.
Maybe I'm pushing this too hard?
NICE
we ran on real hardware but I have not tested lately.
See the permission denied?  That's your problem.
NxM never had mice.
How do you run your 9p servers?  I'm lost!
We should remove strcpy from our libc because people should never use it.
What I'm trying to say is this is a good time to spend some time studying the
problem.
Um, anyone?
I think the web orientation is pretty sensible.
The term 'public domain' has no meaning here.
It would be really nice if we could have cooperation across all these projects.
This is a Plan 9 world and we should never do things because we don't understand
something else.
build.go is about 600 lines.  It's smaller than the awk, mkfile, and rc stuff it
replaces.  I think we need to make sure that the 100x growth in code size with a
new build tool is buying us a significant advantage.  At the same time, it might
really be great; the web interface is just terrific.  I think we have to give it a
look.
Works, I expected it to fail.
We've got enough things to fix
we can't yet exec programs from 9p-based file systems on akaros (long story).
It's a very slick design and worth understanding; just not worth keeping.
booting no longer works
As to why, it's a long story.
What's the API again?
Don't just start using different 9p servers because they "work".  It just wastes
lots of peoples time (like mine) when something fails for me and I think it's
working for you, when it's not.
thanks
It would be a shame, after all this work, to drop aux/tty.
It would be nice to move forwards, not back.
I +2'd myself.
I can boot again with this change.
yeah but ...
People often get confused by this -- I know I do.
I finally remembered how to do this.
We gotta fix this ...
I really want something better than 9p.
I am not a lawyer.
I think it's a good idea, it brings a program committee like feel to the process
These sorts of discussions can drag on forever on a mailing list.
so, everyone, please take a close look at what you've done.
great.
there is no mmap in plan 9.
I'm amazed as you are.
in this day and age, you need to have mmap.
It's a big task.
i think we need to slow down and this discussion is a great start.
I just about gave up but the reversion to the old code doesn't work for me.  So
let's move forward and not quit now.
It's what I used to do on the clusters.
But it's a great test setup.
Of course.
These are great comments.
why do we have to have a disk?
This is plan 9.
But here's the big point: this is Plan 9.
But there's not much point in the harvey project if we come in and start writing
unix programs.
If I sound like I changed my mind from earlier days, I have.
It's been a few years since I programmed in C in the Plan 9 style (I've been using
Go, for the same thing) and I had forgotten a lot.
so here's an option.
This is really great news.
Possibly you should target having cpu working.
Just look at what happened to us when we did the hellaphone.
What was that tar command I typed?
This isn't linux, it's Plan 9.
we have to make sure we don't break anything
Keith, I think before you do anything, it would be good to work out how we measure
improvements.
I think our go port works well enough that this might run
This code is from akaros, as the // INFERNO string clearly marks it as such.
really, it's arbitrary at this point.
Thanks for your patience ...
It's very important to be careful to keep the licenses and provenance of files
right.
adding one new predicate as a system call is not really a good direction.
I can't quite understand what you are saying.
let's slow down.
Could we take a pause and make sure we each have a bootable setup?
In my case, I'd like to see it work on my vmware fusion on osx.
harvey dies somewhere in smp startup.
Hey, that's really odd
one thing at a time.
hm..
I would recommend picking one path, not both :-)
are there any issues we can close?  I just added some.
I think we need to get factotum working.
I forget.
depressing.
WOW, this is weird.
It's no fun at all trying to deal with toxic contributors.
Just a thought.
Fossill was never very good, more of a proof of concept than a real file server.
I'd really personally prefer we write no new user mode code in C.
I am off to test fossil on the amd stack.
I'm wondering how to set up gerrithub for another project.
The code is correct as written.
If our code is different then I'm worried.
They are not bugs.
Let's get it to not suck first.
Let's fix it later, ok?
Ideally, there'd be one program (I prefer to say, written in Go) that would Just
Do It, rather than all this cobbled together crap we get from Plan 9.
We have to draw the line somewhere against bad software.
I think a lot of things got committed by accident.
Last time we tried, it built fine.
you should be able to compiler and build binaries on any mac/bsd and run in
harvey.  If not, we need to fix that.
I can't see what's wrong :-(
kencc does build python on 9front so it is really good.
Let's do it.
this is my long way of saying "I think we have to have gnu make".
I have no objections if you want to try it.
I don't think you can ship a disk until cpu works.
is this only an issue on qemu?
I think we need to test in more than just qemu.
I just remembered something ...
I realize this is not at all well documented.
Sorry.
There were several issues.
I don't know why home is needed ...  but it is.  With these changes drawterm and
rio work.
Can I ask you all once again to look in the source code so you can see where
things are done?
hang in there
You have to have a signed-off-by.
I am wondering if we should take this to a vote.
It's an oversight.
I think it's too soon for us to try for a native setup of a disk boot structure.
We need a vendoring tool.
I'm totally lost, so I'm going off to Yoga practice.  :-)
I really hate Plan 9 programs that know what's wrong and don't tell you.
Who wants to document all this on the wiki?
Is it what we want?  That's a great question.
you need to do some simpler things.
Do you really want to know?
Please not let's not do this hierarchy of tiny files and a file system that is a
direct map of the data structures.
Let's be a bit patient here, ok?
I would like to avoid rushing too much and doing things in a poor way.
Why would we ask golang-dev to fix a multi-hundred line program they don't even
have any familiarity with, that only works in the harvey tree?
Next step will be to create a big JSON string which can be used to read the tables
This seems a very easy thing to fix.
I'm done for the day.
This is just an annoyance we need to fix ...
it works fine for me.
yeah.
I'm not making these terms up.
travis broke.
I have a super simple shell in Go if you want it.
There was a reason recently I found it good to preserve read and write and I can't
remember what it was.
It is broken everywhere.
Things are broken, possibly, let's see what's going on.
if someone can remind me how to set up to drawterm into the harvey that's on a
local disk I'd appreciate it.
nvm.
I would never want to go back to the old plan 9.  We've moved beyond it.
- we can gdb the kernel
- we can gdb the kernel
- we can gdb the kernel
- we can gdb the kernel
do whatever it takes to make a gdb server easy.
I did this on Plan 9 on blue gene.
I actually did this on Blue Gene and NxM
It's really very hard to say.
I'm still not sure why I'm sure that might be an issue, but it came up in the
early harvey days.  I wish I could remember.
I've debugged harvey binaries on linux and I've also debugged harvey using linux
binaries.
Can you remind me if it ever worked?
I looked at it.
I think we need to work these things out before you ship.
!@#$!#@$.
Heres my opinion:
I'm not convinced it's not possible.
anyone?
This stuff is really hard.  It is depressing if you get too focused on what you
have not got done.
graphics is going to happen in 2016, I think.  Hang in there.
I'm just bitching.
This is plan 9.
I just talked to one of the Plan 9 authors
It's worth a shot.
It was painful.
BTW, harvey boots on the intel NUC.
I don't understand what you mean.
and lest I leave the wrong impression: all this is doing is getting us back to
where we were in july, with a non-working go test.
the go command builds.  If you run it you'll get a suicide.
Have fun!
Once you have drawterm, you can stop typing on the console of your machine.
I just built a go program on harvey and it worked fine.
So that's the thing to focus on.  Why are we SO SLOW?
And, now you get to see the ugly truths of Plan 9:file systems are really, really
slow.
That's step 1.
who knows.
It's not hard to come up with cases where your ideas won't work.
I think it's time to call a halt on system call redesign for about 6 months.
We've made lots of changes, and we've ported very little code.
The Go port is broken.  There is no gcc, clang, or glibc port.
how odd.
So I once again recommend we stop breaking system calls known to work until we can
test them better.
thanks
Let's slow down a little, OK?
I think you need to sleep more.  ;-)
Time to slow down.
I'm a bit more focused at this point on fixing broken stuff.
I like your ideas.
I've wasted 4 days on this.
I'm sorry if you find this upsetting.
why the heck is go build hello.go so damn slow?
And you can run it on harvey.
yep.
We need your help!
I'm wondering what your process is for fixing this kind of thing.
I'm confused.
My big goal with "anything but mk" was to try to break us out of the dead past.
I had to say CC=gcc, that's odd.
OK, I'm amazed ...
Wow, this is a shocker.
Thanks to cinap for releasing his emulator to us under bsd licensing.
good times.
I have no idea.
I'm not sure what you mean.
Yep, kernel builds just stopped working.
I hope we'll have the new build tool soon.
anyway, something broke.
But not in all cases.
it was my fault.
It's a rio problem.
I'll test on a real plan 9 system soon.
Things in harvey working better, day by day.  This is a great time to jump in and
contribute.
It would be nice to have Go.
I think our goal should be that by June 1 we have it working completely.
We need YOU to help harvey continue to grow.
This may be the wrong way to do this.
Now if I just had usb mouse, I'd be done.
PID 1 is taking a null pointer exception.
we need someone to help us work out the procedures to make installs easy.
For now, the builds are all done on linux, and it will be that way for a while.
I broke the tree
Do we want to go forward with it or try to get it working a little better?
Would any of you experts like to give it a try?
I just tried harvey on a falco chromebook and it did not go well.
Plan 9 file system performance will make you weep.
I don't know how well the old toolchain did with these things.
how close is native compilation at this point?
Back in 1998 when I did the first 9p port to linux, I was able to get performance
as good as nfs.
This might even free us from 9p.
I really feel that we can get very far with 9p.
Now I'm closing this laptop.
And, let's me more careful next time.
Why is all this stuff in there in addition to my commits?
Thanks for the offer of help.
It gets a little complex.
Just get it to build.
It's going to be a while before we know what we want.
Linking is going to be a huge task.
And so it begins.
symlinks suck.  But there is no option.  So we have to do them.
Sadly, the bug I was going to point you at just got fixed yesterday.
The old-school style initializations in the drivers in Plan 9 are prone to error
and confusion.
It's not working correctly and the hack to fix it is breaking other things.
If you can LGTM 128, we can then move on to 129, lgtm that, then debug the fact
that we can't boot.
I've been wanting to try this for a long time.
And this is it!  We're now free of the ken c legacy!
That is REALLY an outstanding job.  I'm just amazed.
I can not BELIEVE that worked.
we need a debugger, and acid might be a reasonable standin until somebody does
gdb.
The fix is to do what we did in Akaros:
Alvaro has to do it, I can't.
Acid still won't build but it is not built by default.  I think we could credibly
claim this is done.
I'll never tell Rob about you.
It's recommended in these projects that you not put names and dates.
I like // comments.
I suggest the coreboot style guide, which is the linux guide with // comments
added as being ok.
This is really terrific, if you could change the small number of things I suggest
it would be very nice.
I'll try again.
This is an easy one and a good intro.
It's easy.
Still not quite there but close.
Be sure when you're doing all this to not lose security.
I'm not saying this is right, only that it appears to do no harm.
You don't always get to pick the standard.
NIce job.  Huge effort.
It is proving to break some principles that we have to not break.
I removed it, I was not sure, but I think the function itself is fine.
If one other person can do a full build and test, and it works, then press merge.
Boots fine in qemu.
can you LGTM.
travis finally passed.
Another bunch of legacy junk bites the dust.
what's this for again?
neutralizing acpi is not really practical, we're stuck with it.
We just need to accept it.
LGTM
See where that mesage is printed and what it might mean.
This is wonderful.  I will -1 until we make sure we're all clear on the 9front
imports.
I detect confusion.
But it's not a harvey problem at this point I think.
so, that looks right to me, is it?
Anyway, I just compiled and ran a Go program.
I have not used Plan 9 go in years
let's make this system usable again.
That's what we did on NxM.
My point here is we don't need to limit our thinking.
A lot more is working.
The kernel no longer links but that's taken care of by sweat equity.
Harvey is once again multi-architecture, at least for libraries and userland.
anyone?
It wont remotely work, but Ive found it easiest to at least get something to build
 and then take it from there.
wow, the old code is just terrible.
We have devdraw and we have c++ ...
Just as a data point, Go does work fine on Harvey, which only has 2M pages.
The word profligate sticks in my mind.
Geez, is my memory that bad?
Harvey is Plan 9 with just enough changed to be C11 compliant.
Shall I start another thread?
IOW, if GOOS is harvey, then all the tests against the OS name, build tags, and
file names fails.
At the same time, I think some sort of GPL'ed kernel was inevitable for any number
of reasons.
well, you know, parity is for farmers.
yes and no.
note: doesn't built.
Plan 9 is a 32-bit kernel.
I thought about this some more.
I want to make a proposed change to harvey, and I don't even know where we meet
any more.