[9fans] recreational programming of an evening

[9fans] recreational programming of an evening

[ron minnich]

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

I'm an admirer of acid but never found that I like the truss functions
all that much. I've used acid on just enough semi-working platforms,
where breakpoints don't do what is expected, that truss is not
frequently operational and hence not that useful. Also, it's not that
great for fork. And, I'm not that happy about the need to change the
process' memory image just to do tracing. truss() just feels
unfinished.

I pretty much prefer strace on Unix to what acid can do on Plan 9. It
follows forks nicely, and it shows what's going on. And, it works even
if debugging doesn't. And, and on a lightweight node, I don't have to
drag all the acid bits along.

Now, on Linux, strace is a beast: 256KB binary, needs shared
libraries, and so on. (come to think of it that's small for a GNU
program nowadays ...)

What I want is something that works like this:
echo stop > proc/75/ctl
while (echo startsyscall>/proc/75/ctl) {
		cat /proc/75/truss
		}

(note the undocumented startsyscall verb). You need to see the source,
not the man page :-)

Well, turns out to be trivial to do in Plan 9. I did the work against
9vx, since it's so easy to prototype this stuff. The diff is so small
I just attached it. Russ already had nice pretty-print examples for
tracing system calls so I cribbed them.

Here's the output:

75 [cat] Pread 0x13d7 00000000 0fffdf30 00002000 00002000h= 0x9
75 [cat] Pwrite 0x12ed 00000001 0fffdf30 00000009 00000009h= 0x9
75 [cat] Pread 0x13d7 00000000 0fffdf30 00002000 00002000h= 0xc
75 [cat] Pwrite 0x12ed 00000001 0fffdf30 0000000c 0000000ch= 0xc
75 [cat] Pread 0x13d7 00000000 0fffdf30 00002000 00002000h= 0
75 [cat] Open 0x1410 00006990 00000000 00000014 00000014h= 0x3
75 [cat] Pread 0x13d7 00000003 0fffff00 00000014 00000014h= 0xc
75 [cat] Close 0x143e 00000003 0fffff00 00000014 00000014h= 0
75 [cat] Exits 0x128b 00000000 00000000 00000000 00000000hecho: write
error: process exited

So, voila, we have truss, it took 15 minutes to add this in, in fact
almost as long to write this message as to add it in. And a day to
look at the code and ruminate in the odd free moment how to do it. But
that's why I still like this kernel: I can image how much fun this
would have been in just about any Unix, since I've been through a
similar exercise of this sort frequently on Linux.

I may extend it just a bit to dump stuff like file names, read and
write data, and so on. Not that hard in my view.

Anyway, I'll be doing the same thing in the 9k kernel, but the patch I
just attached should give you a hint if you need this. I think it
would help people trying to find problems in 9vx. And, I bet somebody
out there can do a better job than I did.

Obviously, you need to do a bit more work to catch fork but that's
left to the student.

ron

[-- Attachment #2: x --]
[-- Type: application/octet-stream, Size: 3354 bytes --]

diff -r c7e9b5edb8d4 src/9vx/Makefrag
--- a/src/9vx/Makefrag	Sun Dec 27 09:49:22 2009 -0800
+++ b/src/9vx/Makefrag	Tue Mar 16 21:29:23 2010 -0700
@@ -74,6 +74,7 @@
 		devmnt.o \
 		devproc.o \
 		devpipe.o \
+		devram.o \
 		devroot.o \
 		devsd.o \
 		devsrv.o \
diff -r c7e9b5edb8d4 src/9vx/a/AUTOGEN
--- a/src/9vx/a/AUTOGEN	Sun Dec 27 09:49:22 2009 -0800
+++ b/src/9vx/a/AUTOGEN	Tue Mar 16 21:29:23 2010 -0700
@@ -38,6 +38,7 @@
 /sys/src/9/port/devmnt.c
 /sys/src/9/port/devpipe.c
 /sys/src/9/port/devproc.c
+/sys/src/9/port/devram.c
 /sys/src/9/port/devroot.c
 /sys/src/9/port/devsrv.c
 /sys/src/9/port/devtls.c
diff -r c7e9b5edb8d4 src/9vx/a/devproc.c
--- a/src/9vx/a/devproc.c	Sun Dec 27 09:49:22 2009 -0800
+++ b/src/9vx/a/devproc.c	Tue Mar 16 21:29:23 2010 -0700
@@ -31,6 +31,7 @@
 	Qtext,
 	Qwait,
 	Qprofile,
+	Qtruss,
 };
 
 enum
@@ -84,6 +85,7 @@
 	"text",		{Qtext},	0,			0000,
 	"wait",		{Qwait},	0,			0400,
 	"profile",	{Qprofile},	0,			0400,
+	"truss",	{Qtruss},	0,			0400,
 };
 
 static
@@ -397,6 +399,7 @@
 	case Qwait:
 	case Qregs:
 	case Qfpregs:
+	case Qtruss:
 		nonone(p);
 		break;
 
@@ -706,6 +709,12 @@
 		memmove(a, &up->genbuf[offset], n);
 		return n;
 
+	case Qtruss:
+		if (! p->syscalltrace)
+			return 0;
+		n = readstr(offset, a, n, p->syscalltrace);
+		return n;
+
 	case Qmem:
 		if(offset < USTKTOP)
 			return procctlmemio(p, offset, n, va, 1);
diff -r c7e9b5edb8d4 src/9vx/a/portdat.h
--- a/src/9vx/a/portdat.h	Sun Dec 27 09:49:22 2009 -0800
+++ b/src/9vx/a/portdat.h	Tue Mar 16 21:29:23 2010 -0700
@@ -752,6 +752,9 @@
 	 *  machine specific MMU
 	 */
 	PMMU pmmu;
+	/* syscall trace */
+	char *syscalltrace;
+	
 };
 
 enum
diff -r c7e9b5edb8d4 src/9vx/devtab.c
--- a/src/9vx/devtab.c	Sun Dec 27 09:49:22 2009 -0800
+++ b/src/9vx/devtab.c	Tue Mar 16 21:29:23 2010 -0700
@@ -8,6 +8,7 @@
 extern Dev consdevtab;
 extern Dev rootdevtab;
 extern Dev pipedevtab;
+extern Dev ramdevtab;
 extern Dev ssldevtab;
 extern Dev tlsdevtab;
 extern Dev mousedevtab;
@@ -38,6 +39,7 @@
 	&mousedevtab,
 	&pipedevtab,
 	&procdevtab,
+	&ramdevtab,
 	&srvdevtab,
 	&ssldevtab,
 	&tlsdevtab,
diff -r c7e9b5edb8d4 src/9vx/trap.c
--- a/src/9vx/trap.c	Sun Dec 27 09:49:22 2009 -0800
+++ b/src/9vx/trap.c	Tue Mar 16 21:29:23 2010 -0700
@@ -198,8 +198,18 @@
 	up->dbgreg = ureg;
 
 	if(up->procctl == Proc_tracesyscall){
+		uint32 *sp = (uint32*)(up->pmmu.uzero + ureg->usp);
 		up->procctl = Proc_stopme;
+		if (up->syscalltrace)
+			free(up->syscalltrace);
+		up->syscalltrace = smprint("%d [%s] %s %#ux %08ux %08ux %08ux %08uxh",
+				up->pid, up->text,
+				sysctab[ureg->ax], sp[0], sp[1], sp[2], sp[3]);
 		procctl(up);
+		/* you must have read the string by now. The free above is really not needed */
+		if (up->syscalltrace)
+			free(up->syscalltrace);
+		up->syscalltrace = NULL;
 	}
 
 	scallnr = ureg->ax;
@@ -260,9 +270,19 @@
 
 	if(up->procctl == Proc_tracesyscall){
 		up->procctl = Proc_stopme;
+		if (up->syscalltrace)
+			free(up->syscalltrace);
+		if(ureg->ax == -1)
+			up->syscalltrace = smprint("= %s\n", up->syserrstr);
+		else
+			up->syscalltrace = smprint("= %#ux\n", ureg->ax);
 		s = splhi();
 		procctl(up);
 		splx(s);
+		/* you must have read the string by now. The free above is really not needed */
+		if (up->syscalltrace)
+			free(up->syscalltrace);
+		up->syscalltrace = NULL;
 	}
 
 	up->insyscall = 0;

Re: [9fans] recreational programming of an evening

[Noah Evans]

Doing shell debugging I wrote a fork tracer that would setproc() the
return value of every fork call if non-zero. That worked fine if only
the parent did the forking but it was a pain if different processes
forked at different times it was even more useless when the forked
process immediately exec'ed because acid assumes all of the processes
it is debugging have the same symbols and address space.

Anybody with more experience than me with this kind of debugging have
any experience they'd like to share?

Noah

On Wed, Mar 17, 2010 at 5:37 AM, ron minnich <rminnich@gmail.com> wrote:
> I'm an admirer of acid but never found that I like the truss functions
> all that much. I've used acid on just enough semi-working platforms,
> where breakpoints don't do what is expected, that truss is not
> frequently operational and hence not that useful. Also, it's not that
> great for fork. And, I'm not that happy about the need to change the
> process' memory image just to do tracing. truss() just feels
> unfinished.
>
> I pretty much prefer strace on Unix to what acid can do on Plan 9. It
> follows forks nicely, and it shows what's going on. And, it works even
> if debugging doesn't. And, and on a lightweight node, I don't have to
> drag all the acid bits along.
>
> Now, on Linux, strace is a beast: 256KB binary, needs shared
> libraries, and so on. (come to think of it that's small for a GNU
> program nowadays ...)
>
> What I want is something that works like this:
> echo stop > proc/75/ctl
> while (echo startsyscall>/proc/75/ctl) {
>                cat /proc/75/truss
>                }
>
> (note the undocumented startsyscall verb). You need to see the source,
> not the man page :-)
>
> Well, turns out to be trivial to do in Plan 9. I did the work against
> 9vx, since it's so easy to prototype this stuff. The diff is so small
> I just attached it. Russ already had nice pretty-print examples for
> tracing system calls so I cribbed them.
>
> Here's the output:
>
> 75 [cat] Pread 0x13d7 00000000 0fffdf30 00002000 00002000h= 0x9
> 75 [cat] Pwrite 0x12ed 00000001 0fffdf30 00000009 00000009h= 0x9
> 75 [cat] Pread 0x13d7 00000000 0fffdf30 00002000 00002000h= 0xc
> 75 [cat] Pwrite 0x12ed 00000001 0fffdf30 0000000c 0000000ch= 0xc
> 75 [cat] Pread 0x13d7 00000000 0fffdf30 00002000 00002000h= 0
> 75 [cat] Open 0x1410 00006990 00000000 00000014 00000014h= 0x3
> 75 [cat] Pread 0x13d7 00000003 0fffff00 00000014 00000014h= 0xc
> 75 [cat] Close 0x143e 00000003 0fffff00 00000014 00000014h= 0
> 75 [cat] Exits 0x128b 00000000 00000000 00000000 00000000hecho: write
> error: process exited
>
> So, voila, we have truss, it took 15 minutes to add this in, in fact
> almost as long to write this message as to add it in. And a day to
> look at the code and ruminate in the odd free moment how to do it. But
> that's why I still like this kernel: I can image how much fun this
> would have been in just about any Unix, since I've been through a
> similar exercise of this sort frequently on Linux.
>
> I may extend it just a bit to dump stuff like file names, read and
> write data, and so on. Not that hard in my view.
>
> Anyway, I'll be doing the same thing in the 9k kernel, but the patch I
> just attached should give you a hint if you need this. I think it
> would help people trying to find problems in 9vx. And, I bet somebody
> out there can do a better job than I did.
>
> Obviously, you need to do a bit more work to catch fork but that's
> left to the student.
>
> ron
>

Re: [9fans] recreational programming of an evening

[ron minnich]

On Wed, Mar 17, 2010 at 1:15 AM, Noah Evans <noah.evans@gmail.com> wrote:

> Anybody with more experience than me with this kind of debugging have
> any experience they'd like to share?

Yes. Take this thing I've done and make it more complete, then write
strace() for Plan 9, done. I may do it before you because I really
need it. I'm going to modify my output to produce (what else?)
S-expressions because it is a sensible format and there is a very a
handy library to parse them and do reasonable things.

I realize acid has many wonderful properties, but it's not a
substitute for many handy tools, strace being one of them.

thanks

ron

[9fans] recreational programming of an evening

[ron minnich]

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

I wanted /proc/<pid>/truss to be more infomative ... and I wanted to
trace things that fork/exec. I can now see things like file names, IO
data, and so on. This is only in 9vx at present.

For RFORK, the output from /proc/<pid>/truss is just Rfork unless it
is creating new proc, in which case it is ProcRfork. That's how the rc
script knows to start a new truss.

So here is the result: very minor extension to the kernel code, shell
script a bit longer (25 lines!) but what happens is e.g. you trace an
rc, and for each fork/exec that happens, a new truss display pops up
in a new window and you can now watch the kid. And yes it does work
fine if the thing you start is an rc.

Watching ssh is fun. I hope to use this to try to find out what hg is up to.

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

ron

[-- Attachment #2: trussf.png --]
[-- Type: image/png, Size: 55126 bytes --]

Re: [9fans] recreational programming of an evening

[EBo]

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

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

  EBo --

Re: [9fans] recreational programming of an evening

[Stuart Morrow]

On 3/21/10, ron minnich <rminnich@gmail.com> wrote:
> What's  interesting to me about this is that
> I can not imagine even attempting this on any other os or windowing
> system. It was just too easy on Plan 9 however.
>
> ron

so, are you basically saying that linux is a complex operating system,
and it just takes a genius to understand its complexity?

stu

Re: [9fans] recreational programming of an evening

[erik quanstrom]

> On 3/21/10, ron minnich <rminnich@gmail.com> wrote:
> > What's  interesting to me about this is that
> > I can not imagine even attempting this on any other os or windowing
> > system. It was just too easy on Plan 9 however.
> >
> > ron
>
> so, are you basically saying that linux is a complex operating system,
> and it just takes a genius to understand its complexity?

troll fail:  too transparent.

- erik

Re: [9fans] recreational programming of an evening

[ron minnich]

On Sun, Mar 21, 2010 at 10:36 AM, Stuart Morrow
<morrow.stuart@googlemail.com> wrote:

> so, are you basically saying that linux is a complex operating system,
> and it just takes a genius to understand its complexity?


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

ron

Re: [9fans] recreational programming of an evening

[EBo]

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

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

  EBo --

Re: [9fans] recreational programming of an evening

[hiro]

I don't get your reasoning. Do you want to say we would be better off
if they had not released it?!

On 3/21/10, EBo <ebo@sandien.com> wrote:
>
>> no, it's just badly designed. Working with a bad design gives me a
>> splitting headache. I make my living doing linux but that doesn't mean
>> I have to worship at the altar, right?
>
> To bad plan 9 was publicly released just after Linus started working on
> Linux.
>  Oh well.  It's all about timing.
>
>   EBo --
>
>

Re: [9fans] recreational programming of an evening

[EBo]

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


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

Re: [9fans] recreational programming of an evening

[David Leimbach]

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

On Sun, Mar 21, 2010 at 5:02 PM, EBo <ebo@sandien.com> wrote:

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

I don't think that's true... he's been on this list, and he's had his say
about how he thinks about the way things work in Plan 9.

http://9fans.net/archive/2004/02/1233

http://9fans.net/archive/2004/02/1229

http://9fans.net/archive/2004/02/1227

http://9fans.net/archive/2004/02/1225

http://9fans.net/archive/2004/02/1224

Dave


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

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

Re: [9fans] recreational programming of an evening

[andrey mirtchovski]

Linus in 2004 is not the same one from 1995. not to say anything about
the man, but humility is generally inversely proportional to success.
you can say the same thing about Plan 9's designers and you'd be more
or less on the point. butting egos aside, linus has won and we're just
sulking :)

Re: [9fans] recreational programming of an evening

[David Leimbach]

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

It's fun to look back and see what people thought was going to be the
programming model we're being faced with though.  Things seem more NUMA than
ever, or at least heading that way, even on the desktop.

Intel's 48 core demo CPU doodad has a mesh network behind the scenes for
reasons of scalability rather than a huge shared cache blob.

Also shared state is the devil in the details (some might say its just the
invariants really) of highly concurrent applications.

One actually has to wonder if the desktop/workstation is on its last legs
now.  Grandma doesn't want a computer, she wants an iPad with a camera!

Dave

On Mon, Mar 22, 2010 at 8:57 AM, andrey mirtchovski
<mirtchovski@gmail.com>wrote:

> Linus in 2004 is not the same one from 1995. not to say anything about
> the man, but humility is generally inversely proportional to success.
> you can say the same thing about Plan 9's designers and you'd be more
> or less on the point. butting egos aside, linus has won and we're just
> sulking :)
>
>

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

Re: [9fans] recreational programming of an evening

[Chad Brown]

On Mar 22, 2010, at 9:09 AM, David Leimbach wrote:

> It's fun to look back and see what people thought was going to be the programming model we're being faced with though.  

When linux was first released, I remember people being surprised that GNU (which was still claiming to be working on at least two kernels) had *competition*.  I also remember when the core linux hackers thought that 386BSD was going to `win' (in the end-days of ``all the world's a VAX'', that must have seemed comforting), and that they really only needed to survive long enough for that to happen.  Computing history is a funny place.

*Chad

Re: [9fans] recreational programming of an evening

[Chad Brown]

> When linux was first released, I remember people being surprised that GNU (which was still claiming to be working on at least two kernels) had *competition*.  I also remember when the core linux hackers thought that 386BSD was going to `win' (in the end-days of ``all the world's a VAX'', that must have seemed comforting), and that they really only needed to survive long enough for that to happen.  Computing history is a funny place.

That should have been ``some of the core linux hackers'', of course.  Mea culpa.

*Chad

Re: [9fans] recreational programming of an evening

[erik quanstrom]

On Mon Mar 22 11:59:21 EDT 2010, mirtchovski@gmail.com wrote:
> linus has won and we're just
> sulking :)

this all depends on your definition of "winning".
it appears your measure is user base.  if this is
the definition, then windows has won.

but what i see is that there is increasing resistance
to the complexity of linux;  we're not the only
ones who complain about it anymore.

- erik

Re: [9fans] recreational programming of an evening

[Ethan Grammatikidis]

On 21 Mar 2010, at 22:02, EBo wrote:

>
>> no, it's just badly designed. Working with a bad design gives me a
>> splitting headache. I make my living doing linux but that doesn't
>> mean
>> I have to worship at the altar, right?
>
> To bad plan 9 was publicly released just after Linus started working
> on Linux.
> Oh well.  It's all about timing.

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


--
Simplicity does not precede complexity, but follows it.
  -- Alan Perlis

Re: [9fans] recreational programming of an evening

[EBo]

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

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

  EBo --

Re: [9fans] recreational programming of an evening

[Skip Tavakkolian]

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

most are only now experiencing the problems that Plan 9 set out to
solve.  sometimes you just got to let gravity do its thing.

Re: [9fans] recreational programming of an evening

[David Leimbach]

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

On Sun, Mar 21, 2010 at 2:47 PM, ron minnich <rminnich@gmail.com> wrote:

> On Sun, Mar 21, 2010 at 10:36 AM, Stuart Morrow
> <morrow.stuart@googlemail.com> wrote:
>
> > so, are you basically saying that linux is a complex operating system,
> > and it just takes a genius to understand its complexity?
>
>
> no, it's just badly designed. Working with a bad design gives me a
> splitting headache. I make my living doing linux but that doesn't mean
> I have to worship at the altar, right?
>
> ron
>
>
I got the hunch it wasn't designed at all, but more "hacked on" or evolved.
 Different subsystems appear to have designs, but there doesn't seem to be
anything stopping people from stomping all over the structures and glue that
make it possible for a driver to last very long without updates needed.  At
least that's been my experience.

In fact the evolutionary nature appears to have been backed as an advantage
by Linus himself.

Dave

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

Re: [9fans] recreational programming of an evening

[ron minnich]

On Mon, Mar 22, 2010 at 8:47 AM, David Leimbach <leimy2k@gmail.com> wrote:

> I got the hunch it wasn't designed at all, but more "hacked on" or evolved.

I shouldn't be so down on Linux, as it is arguably the most successful
OS out there. It runs on my e-reader, will be running on my next
phone, probably runs on things you own which you don't know about --
it's everywhere. It made a lot of what I do in HPC possible.

Linux's runaway success is part of the problem! It is almost
inevitable that when you run on *anything* and you open the gates to
lots of contributors your work will lose a certain intellectual
coherence, and that's what has happened with Linux. Add to the fact
that he started with a pretty old-fashioned design (classical Unix,
with it's "major and minor nodes" and so on) and it's not surprising
that it's not that pretty.

And there are parts of it that are quite elegant, such as lguest.

But it still gives me a splitting headache every time I have to
deep-dive to do anything :-)

ron

Re: [9fans] recreational programming of an evening

[Bakul Shah]

On Sat, 20 Mar 2010 22:48:53 PDT ron minnich <rminnich@gmail.com>  wrote:
  	...
> So here is the result: very minor extension to the kernel code, shell
> script a bit longer (25 lines!) but what happens is e.g. you trace an
> rc, and for each fork/exec that happens, a new truss display pops up
> in a new window and you can now watch the kid. And yes it does work
> fine if the thing you start is an rc.
	...
>                           What's interesting to me about this is that
> I can not imagine even attempting this on any other os or windowing
> system. It was just too easy on Plan 9 however.
>
> ron

Very nice!

Users of other OSes won't even believe it is this easy!  Have
you considered writing this up for a publication or blogging
about it?  This sort of "joy of programming with plan9"
stories need to be known more widely.

What's really missing is a whole book on hands on OS hacking
along the lines of the Art of Electronics or SICP (Structure
and Interpretation of Computer Programs).  And with a kit of
h/w & i/o devices so that you can build some widgets and
give'em a real OS!

Re: [9fans] recreational programming of an evening

[Devon H. O'Dell]

2010/3/21 Bakul Shah <bakul+plan9@bitblocks.com>:
[snip]
> What's really missing is a whole book on hands on OS hacking
> along the lines of the Art of Electronics or SICP (Structure
> and Interpretation of Computer Programs).  And with a kit of
> h/w & i/o devices so that you can build some widgets and
> give'em a real OS!
>
>

I've wanted to do something like this for a while, but it's hard to
find a publisher for such a thing.

Re: [9fans] recreational programming of an evening

[Lyndon Nerenberg]

>>
>>
> I've wanted to do something like this for a while, but it's hard to
> find a publisher for such a thing.

Self-publish it. You'll probably end up pocketing more money, anyway,
vs. having someone else do it.

Re: [9fans] recreational programming of an evening

[EBo]

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

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

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

  EBo --

Re: [9fans] recreational programming of an evening

[Steve Simon]

> What's really missing is a whole book on hands on OS hacking
> along the lines of the Art of Electronics or SICP (Structure
> and Interpretation of Computer Programs).

John Lyons book taught me a heck of a lot.

http://www.peerllc.com/

Perhaps its publishers might be interested in such a thing?

-Steve

Re: [9fans] recreational programming of an evening

[Bakul Shah]

On Sun, 21 Mar 2010 14:03:14 EDT "Devon H. O'Dell" <devon.odell@gmail.com>  wrote:
> 2010/3/21 Bakul Shah <bakul+plan9@bitblocks.com>:
> [snip]
> > What's really missing is a whole book on hands on OS hacking
> > along the lines of the Art of Electronics or SICP (Structure
> > and Interpretation of Computer Programs).  And with a kit of
> > h/w & i/o devices so that you can build some widgets and
> > give'em a real OS!
>
> I've wanted to do something like this for a while, but it's hard to
> find a publisher for such a thing.

Go for it!

These days you can self publish or put it on the web.  Or
post your tentative Table of Contents here and may be it can
turn into a cooperative effort.

A web based "book" can be pretty interactive and flexible.
For example, it can start assuming the readers have a plan9
virtual machine with your teaching package so they can
experiment right away.  Then they can explore plan9 in any
direction they want (to learn OS concepts by experimenting,
or "move up" to build apps or interface with other apps, or
"move down" to add device drivers or replace some kernel
parts, or "further down" to bare metal, to move to real h/w
and add some h/w devices).

One project I have been interested in (but lack time for) is
to build a h/w building block that speaks P9 (instead of just
a low level USB interface).  Given that one can add h/w for a
specific purpose, add a bit of glue logic and can make the
new h/w functionality easily available from plan9.  Such a
thing can be a great boon to hobbyists and scientists alike,
as they can stop worrying about low level computer interface
details and spend time on things *they* want to spend time
on.  And make them want to learn plan9, which is where your
book can come in!

Re: [9fans] recreational programming of an evening

[ron minnich]

On Sun, Mar 21, 2010 at 10:57 AM, Bakul Shah <bakul+plan9@bitblocks.com> wrote:

> Users of other OSes won't even believe it is this easy!  Have
> you considered writing this up for a publication or blogging
> about it?  This sort of "joy of programming with plan9"
> stories need to be known more widely.

Yeah, I'm going to do a short paper on "what I learned from writing
strace in 4 lines". It's in the queue.

ron