nanogui: Thread: nanogui and pk


[<<] [<] Page 1 of 1 [>] [>>]
Subject: nanogui and pk
From: "Frank W. Miller" ####@####.####
Date: 28 Sep 1999 02:35:45 -0000
Message-Id: <199909280219.WAA25301@macalpine.cornfed.com>

Greetings,

I've been following this bare hardware thread with great interest.  I've
also thought about porting nanogui to pk, a protected memory, real-time
kernel I've been working on.  I've actually written a 640x480x16 driver
using bits from vgalib and Ferrarro that has pixel, horizontal line,
line and fill primitives in it as well as transparent fixed size fonts.
This environment might be ideal for nanogui to run on.  Whoever decides
to port the system to bare hardware, please document your porting process
as will make someone else's life (like me for example) easier ;)

More info on the just beta released pk kernel is available at
http://www.cornfed.com/pk


Later,
FM


--
Frank W. Miller
Cornfed Systems Inc
www.cornfed.com
Subject: Re: nanogui and pk
From: Michael Emmel ####@####.####
Date: 28 Sep 1999 14:16:32 -0000
Message-Id: <37F0CB46.B23EFBE3@tampabay.rr.com>

"Frank W. Miller" wrote:

> Greetings,
>
> I've been following this bare hardware thread with great interest.  I've
> also thought about porting nanogui to pk, a protected memory, real-time
> kernel I've been working on.  I've actually written a 640x480x16 driver
> using bits from vgalib and Ferrarro that has pixel, horizontal line,
> line and fill primitives in it as well as transparent fixed size fonts.
> This environment might be ideal for nanogui to run on.  Whoever decides
> to port the system to bare hardware, please document your porting process
> as will make someone else's life (like me for example) easier ;)
>
> More info on the just beta released pk kernel is available at
> http://www.cornfed.com/pk

Wow this looks like a very nice base for a java VM.


Mike

Subject: Re: nanogui and pk
From: "Frank W. Miller" ####@####.####
Date: 28 Sep 1999 18:33:15 -0000
Message-Id: <199909281817.OAA27732@macalpine.cornfed.com>

> BTW, what we REALLY need is a bare-hardware 640x480x256 color 

I started with x16 cuz its sposedly standard.  I was interested in something
going that was cross-hardware-platform for free, didnt feel like dealing
with all the different cards when you go beyond this.

That said, I forgot that the pk-0.9.0 release doesnt have the VGA driver in
it but I'll post it in the next release (which will be shortly to incorporate
some bug fixes).

Later,
FM

--
Frank W. Miller
Cornfed Systems Inc
www.cornfed.com
Subject: RE: nanogui and pk
From: Greg Haerr ####@####.####
Date: 28 Sep 1999 19:45:47 -0000
Message-Id: <01BF09B7.492EEB20.greg@censoft.com>

On Tuesday, September 28, 1999 12:17 PM, Frank W. Miller ####@####.#### wrote:
: > BTW, what we REALLY need is a bare-hardware 640x480x256 color 
: 
: I started with x16 cuz its sposedly standard.  I was interested in something
: going that was cross-hardware-platform for free, didnt feel like dealing
: with all the different cards when you go beyond this.

	I hear ya, but without 256 color, we can't compete with graphics displays...


: 
: That said, I forgot that the pk-0.9.0 release doesnt have the VGA driver in
: it but I'll post it in the next release (which will be shortly to incorporate
: some bug fixes).
: 
	Great - let me know and I'll pick it up.  BTW, does pk run executables?
Are they linked in, or does pk have a filesystem?

Greg
Subject: Re: nanogui and pk
From: "Frank W. Miller" ####@####.####
Date: 28 Sep 1999 20:34:08 -0000
Message-Id: <199909282017.QAA28038@macalpine.cornfed.com>

> 	Great - let me know and I'll pick it up.  BTW, does pk run executables?
> Are they linked in, or does pk have a filesystem?
> 

Well, since you asked...  =)

Here's a little history, with a little angst mixed in for good measure...

In the beginning there was Fairchild.  This was a simple 32-bit protected
mode real-time kernel with no memory protection.  This was in like about
1989.  I wrote this thing and discovered two things, first, that I really
liked doing it, and second, I could do it.  As the years passed, I brought
it up on a bare x86 machine and started adding a file system.  Then came
grad school.  Somehow I wanted to find some research that would allow me
to keep working on it.  Data streaming was the ticket, my advisor rechristened
the system as Roadrunner and let me continue working on the I/O system.
There was some talk at that time of adding support for virtual addressing
but hey, theres only so many hours in the day, and the I/O system looked
more interesting research-wise.  So its now the late 90's, Roadrunner has
a file system, TCP/IP, web server, runs a.outs, etc.  Its starting to look
like a real OS, and I'm thinking, "gee, wouldnt it be great if I could make
my living doing this?"  But there was this one big hole, memory protection
that potential customers kept asking about.  About this time, the research
funds dried up (aka I graduated) and rather than starve, I decided to get
a job.  Well, I made the mistake of going to work for a startup, you know,
the kind where you just basically move in.  The worst part was, they made
me sort of give working on  Roadrunner.  Well, after working on something
for that amount of time, you cant just walk away from it.  So I devised this
scheme to make everyone happy.  I decided to start writing a new kernel,
called pk, that would implement the memory protection I had been wanting for
a while.  This was good, I was living up to the letter of the law with my
job, I was still adding to Roadrunner, and I was adding memory protection
and a POSIX pthreads API.  Now, theres one more thing, part of my charade
to make "them" think I wasnt working on Roadrunner was that I released pk
under a BSD-style copyright.  So, now its late 1999 and pk is at its BETA
release stage.  I'm pretty happy with the design and have gotten to the point
where I am ready to port the upper layers of Roadrunner to pk.  There are a
couple of problems.  First, a port will mean I'm working on Roadrunner again
and my mgmt won't like that.  But they need me now to maintain the code I've
written so thats not as big a problem as it used to be.  Second, theres this
damn license thing.  pk is BSD'd and I'm not going to change that.
Roadrunner is commercial and I dont want to change that since I still have
these crazy dreams of being able to support myself and my family by doing
what I want to do, call me crazy.  Trouble is, there seems to be a lot of
interest in pk, which is quite gratifying and I want to continue supporting
it.  So, to sum up, the answer to your question is, yes and no.  There is
file system, and TCP/IP, and executable execution and a shell, and vi,
but they all belong to Roadrunner, not to pk.

Whew, sorry bout that...

Later,
FM


--
Frank W. Miller
Cornfed Systems Inc
www.cornfed.com
Subject: Re: nanogui and pk
From: Alex Holden ####@####.####
Date: 28 Sep 1999 20:43:04 -0000
Message-Id: <Pine.LNX.4.04.9909282054170.378-100000@hyperspace>

On Mon, 27 Sep 1999, Frank W. Miller wrote:
> More info on the just beta released pk kernel is available at
> http://www.cornfed.com/pk

Wow, that's actually pretty cool. How difficult would you say it would be
to port it to another architecture (in particular, ARM)? How does PK
support abstracted device access (eg. filesystems, networking)? Is there 
any easy way for a thread to load and execute a new thread, or is it
expected for the threads to all be statically compiled into the kernel
image?

You should definitely write something more impressive than mon to put on
the boot disk ;) I had to look at the source to figure out what it was
supposed to do... 

BTW. Line 85 of mon.c should probably be something like "printf("mon:
invalid command\n");" rather than "/* Not reached */", as it currently
assumes that the user would never do something so terrible as to type in 
an invalid command :)

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------


[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.