Re: [9fans] fs kernel: eagle

Re: [9fans] fs kernel: eagle

[jmk]

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


it's worse than you know, some drivers are used in 5 different
operating systems, all requiring them to be mangled to fit, it's
a maintenance headache i'm well aware of.

after saying so for years, i have actually started on merging the
kernels. but don't hold your breath, there are lots of things to
get in the way.

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

From: Jakub Jermar <jj@comberg.cz>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] fs kernel: eagle
Date: Wed, 8 Nov 2000 09:22:57 GMT
Message-ID: <8u9s02$gtf$1@news.vol.cz>

> I suppose I could remove them, I remove the dregs of other dead hardware
> when I find them. Hands up, who knows what this typedef in
fs/port/portdat.h
> was for:
> typedef struct Bit Bit;
> If you know, I pity you.

I don't know what purpose was 'typedef struct Bit Bit' for -- I guess
I was only ten or so when Plan 9 used to be proud of
the SGI Power multiprocessor servers...

But now I see that things like the Bit typedef, Eagle and Jaguar drivers
merely ARE
and their one and only task is silent being in the kernel. No doubts they
should
go.

Besides these fossils, there is another thing that I would like to point
out. Both fs and CPUterm kernels suffer mutual duplication of code.
I've done a private survey on this issue in both kernels and found the
following simillarities/duplicities:

all kinds of locks
pieces of scheduler including sleep() and wakeup()
clock and time planning
interrupt dispatching
PCI, CGA, keyboard, floppy
ethernets (etherlnk3, 82557, 2114x), ethernet generic interface
scsi (NCR53c8xx), scsi generic interface
IP protocols...

...and possibly many more.

The result of my survey brought me to thoughts like: "let's have only one
Plan 9 kernel".
For there are only kernel processes in the fs kernel and all of them
cooperate in the algorithm described in the File Server paper written by
Ken Thompson, it should be no problem to transfer the functionality of it
to the CPUterm kernel -- CPUterm kernel supports kernel processes,
and all the hardware that fs kernel needs + more.

With some #ifdefined'ing and a little (more or less) coding, we could
achieve the fully functional fileserver kernel from the CPUterm source.

One would be able to build different images from one source, depending on
whether he wanted to build a file server or a CPUterm server kernel . (I
also
believe that there could be a slight distinction between kernels intended
for
CPU servers and kernels meant for terminals. While enterprise CPU servers
are probably not going to need devices like VGA and sound, they should
be given the opportunity to be free of them, terminals, on the other hand,
might need some of the multimedia drivers.
The scheduler could also be optimised for compute-bound processes on CPU
kernels and for transput-bound processes on term kernels.)

Well, what do you think?

Jakub Jermar

Re: [9fans] fs kernel: eagle

[Christopher Nielsen]

On Thu, 9 Nov 2000 jmk@plan9.bell-labs.com wrote:

> after saying so for years, i have actually started on
> merging the kernels. but don't hold your breath, there
> are lots of things to get in the way.

You've mentioned this to me privately. Knowing my own skills
and familiarity with plan9, I'll assume you're going to be
better at unifying the kernels than I, but if there is
anything I can do to help, let me know. I can at least act
as a alpha/beta tester.

-- 
Christopher Nielsen
(enkhyl|cnielsen)@pobox.com
"Not only is UNIX dead, it's starting to smell really bad." --rob pike

Re: [9fans] fs kernel: eagle

[Christopher Nielsen]

oops... *sheepish grin*

That was meant to be private, but hey... :-)

On Thu, 9 Nov 2000, Christopher Nielsen wrote:

> Date: Thu, 9 Nov 2000 00:17:07 -0800 (PST)
> From: Christopher Nielsen <cnielsen@pobox.com>
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] fs kernel: eagle
> 
> On Thu, 9 Nov 2000 jmk@plan9.bell-labs.com wrote:
> 
> > after saying so for years, i have actually started on
> > merging the kernels. but don't hold your breath, there
> > are lots of things to get in the way.
> 
> You've mentioned this to me privately. Knowing my own skills
> and familiarity with plan9, I'll assume you're going to be
> better at unifying the kernels than I, but if there is
> anything I can do to help, let me know. I can at least act
> as a alpha/beta tester.

-- 
Christopher Nielsen
(enkhyl|cnielsen)@pobox.com
"Not only is UNIX dead, it's starting to smell really bad." --rob pike

Re: [9fans] fs kernel: eagle

[presotto]

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

We're already redoing the fs to run off of the same kernel.  The reason
for the current dichotomy is that ken was doing the file server while
the rest of us were doing the normal kernel.  We started from some common
code but that didn't last very long.  We've lived with the situation
because Ken was willing to do all the work on the fs side and didn't
feel comfortable with the rate of change in our kernels, i.e., the
file server had to be solid, our lives depended on it, while the
other kernels just had to be up long enough to edit and compile
the next kernel.

Now that ken is leaving, we're going to have one kernel.  It also
means that we can use the same IP stack on both sides, which will
be a big win.

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

[-- Attachment #2.1.1: Type: text/plain, Size: 327 bytes --]


it's worse than you know, some drivers are used in 5 different
operating systems, all requiring them to be mangled to fit, it's
a maintenance headache i'm well aware of.

after saying so for years, i have actually started on merging the
kernels. but don't hold your breath, there are lots of things to
get in the way.

[-- Attachment #2.1.2: Type: message/rfc822, Size: 3753 bytes --]

From: Jakub Jermar <jj@comberg.cz>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] fs kernel: eagle
Date: Wed, 8 Nov 2000 09:22:57 GMT
Message-ID: <8u9s02$gtf$1@news.vol.cz>

> I suppose I could remove them, I remove the dregs of other dead hardware
> when I find them. Hands up, who knows what this typedef in
fs/port/portdat.h
> was for:
> typedef struct Bit Bit;
> If you know, I pity you.

I don't know what purpose was 'typedef struct Bit Bit' for -- I guess
I was only ten or so when Plan 9 used to be proud of
the SGI Power multiprocessor servers...

But now I see that things like the Bit typedef, Eagle and Jaguar drivers
merely ARE
and their one and only task is silent being in the kernel. No doubts they
should
go.

Besides these fossils, there is another thing that I would like to point
out. Both fs and CPUterm kernels suffer mutual duplication of code.
I've done a private survey on this issue in both kernels and found the
following simillarities/duplicities:

all kinds of locks
pieces of scheduler including sleep() and wakeup()
clock and time planning
interrupt dispatching
PCI, CGA, keyboard, floppy
ethernets (etherlnk3, 82557, 2114x), ethernet generic interface
scsi (NCR53c8xx), scsi generic interface
IP protocols...

...and possibly many more.

The result of my survey brought me to thoughts like: "let's have only one
Plan 9 kernel".
For there are only kernel processes in the fs kernel and all of them
cooperate in the algorithm described in the File Server paper written by
Ken Thompson, it should be no problem to transfer the functionality of it
to the CPUterm kernel -- CPUterm kernel supports kernel processes,
and all the hardware that fs kernel needs + more.

With some #ifdefined'ing and a little (more or less) coding, we could
achieve the fully functional fileserver kernel from the CPUterm source.

One would be able to build different images from one source, depending on
whether he wanted to build a file server or a CPUterm server kernel . (I
also
believe that there could be a slight distinction between kernels intended
for
CPU servers and kernels meant for terminals. While enterprise CPU servers
are probably not going to need devices like VGA and sound, they should
be given the opportunity to be free of them, terminals, on the other hand,
might need some of the multimedia drivers.
The scheduler could also be optimised for compute-bound processes on CPU
kernels and for transput-bound processes on term kernels.)

Well, what do you think?

Jakub Jermar

Re: [9fans] fs kernel: eagle

[Russ Cox]

  (I also believe that there could be a slight distinction between kernels intended
  for CPU servers and kernels meant for terminals. While enterprise CPU servers
  are probably not going to need devices like VGA and sound, they should
  be given the opportunity to be free of them, terminals, on the other hand,
  might need some of the multimedia drivers.

Although, as Jim points out, you are quite right overall,
this part we already do: see the differences between 
/sys/src/9/pc/pcdisk and /sys/src/9/pc/pccpu.

Russ

Re: [9fans] fs kernel: eagle

[Boyd Roberts]

IIRC an eagle was a fujitsu? winchester drive.  i forget
its size [500Mb?], but it did have a massbus interface [vax].

Re: [9fans] fs kernel: eagle

[Jakub Jermar]

> I suppose I could remove them, I remove the dregs of other dead hardware
> when I find them. Hands up, who knows what this typedef in
fs/port/portdat.h
> was for:
> typedef struct Bit Bit;
> If you know, I pity you.

I don't know what purpose was 'typedef struct Bit Bit' for -- I guess
I was only ten or so when Plan 9 used to be proud of
the SGI Power multiprocessor servers...

But now I see that things like the Bit typedef, Eagle and Jaguar drivers
merely ARE
and their one and only task is silent being in the kernel. No doubts they
should
go.

Besides these fossils, there is another thing that I would like to point
out. Both fs and CPUterm kernels suffer mutual duplication of code.
I've done a private survey on this issue in both kernels and found the
following simillarities/duplicities:

all kinds of locks
pieces of scheduler including sleep() and wakeup()
clock and time planning
interrupt dispatching
PCI, CGA, keyboard, floppy
ethernets (etherlnk3, 82557, 2114x), ethernet generic interface
scsi (NCR53c8xx), scsi generic interface
IP protocols...

...and possibly many more.

The result of my survey brought me to thoughts like: "let's have only one
Plan 9 kernel".
For there are only kernel processes in the fs kernel and all of them
cooperate in the algorithm described in the File Server paper written by
Ken Thompson, it should be no problem to transfer the functionality of it
to the CPUterm kernel -- CPUterm kernel supports kernel processes,
and all the hardware that fs kernel needs + more.

With some #ifdefined'ing and a little (more or less) coding, we could
achieve the fully functional fileserver kernel from the CPUterm source.

One would be able to build different images from one source, depending on
whether he wanted to build a file server or a CPUterm server kernel . (I
also
believe that there could be a slight distinction between kernels intended
for
CPU servers and kernels meant for terminals. While enterprise CPU servers
are probably not going to need devices like VGA and sound, they should
be given the opportunity to be free of them, terminals, on the other hand,
might need some of the multimedia drivers.
The scheduler could also be optimised for compute-bound processes on CPU
kernels and for transput-bound processes on term kernels.)

Well, what do you think?

Jakub Jermar

Re: [9fans] fs kernel: eagle

[jmk]

Jakub Jermar <jj@comberg.cz>:
	There are two kernel processes called "egi" and "ego" in the fs kernel
	source. They do similar job as "etheri" and "ethero" processes.

	i) what kind of network device is Eagle
	ii) they seem to be unused today - I can't find any call to the routine that
	spawns them

	Jakub Jermar

Two drivers (eagle and jaguar) are included in the distribution source
although the machines which used them are long gone (SGI Power series and
MIPS 6280). These are VME cards, the Eagle was ethernet, Jaguar was SCSI,
both made by Interphase.

I suppose I could remove them, I remove the dregs of other dead hardware
when I find them. Hands up, who knows what this typedef in fs/port/portdat.h
was for:
	typedef	struct	Bit	Bit;
If you know, I pity you.

--jim

[9fans] fs kernel: eagle

[Jakub Jermar]

There are two kernel processes called "egi" and "ego" in the fs kernel
source. They do similar job as "etheri" and "ethero" processes.

i) what kind of network device is Eagle
ii) they seem to be unused today - I can't find any call to the routine that
spawns them

Jakub Jermar