Resume: David Bulkow

>From owner-9fans Tue Jul 1 10:44:02 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id KAA08662 for 9fans-outgoing; Tue, 1 Jul 1997 10:44:01 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from whitsunday.net.au ([203.25.188.10]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id KAA08652 for <9fans@cse.psu.edu>; Tue, 1 Jul 1997 10:43:40 -0400 (EDT) Received: from whitsunday.net.au by whitsunday.net.au (SMI-8.6/SMI-SVR4) id AAA03187; Wed, 2 Jul 1997 00:19:57 +1000 From: OIL.PATCH.MARKETING@23792.com Received: from mailhost.worldbet.com{ak1.worldbet.com(207.7.99)} by worldbet.com (8.8.5/8.6.5) with SMTP id GAA03868 for ; Tue, 01 Jul 1997 07:53:01 -0600 (EST) Date: Tue, 01 Jul 97 07:53:01 EST To: succed@worldbet.com Subject: BULK EMAIL LIST GETS RESULTS QUICKLY TRY IT Message-ID: < 750362bmd45gaa02034@worldbet.com> Reply-To: succed@worldbet.com X-PMFLAGS: 128 0 X-UIDL: 948vn4822723968loiky1745gmts5428 Comments: Authenticated sender is Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans


                      Profitable Internet Marketing
                         
                              Using Bulk Email

               Best Bulk E-Mail Prices on the Internet!!!!!!

Bulk Email is the most cost effective form of advertising in the history of
                         the world !!!!!!!!!!!!!!!
             
---------------------------------------------------------------------------

Why is Bulk Email Successful ? - Bulk Email is successful because it works.
Advertising in any form is a numbers game. The more people exposed to your
message (an impression in advertising terminology), the more sales you will
make. Bulk Email gets your message in front of a vast amount of people for
a very modest investment. For the price of one black and white ad,
appearing one day only, in a daily newspaper in a medium to large city, you
can send your Bulk Email message out to 1,000,000 people !!! Most of these
large newspapers don't even have a circulation of 1,000,000. Sure not
everyone is going to read your Bulk Email message, but not everyone sees
your ad in the newspaper either. Bulk Snail Mail (regular junk mail) has
been very successful and not everyone reads it. If regular junk mail wasn't
profitable, you wouldn't be seeing so much of it. The reality is Bulk Email
works and that is why you are seeing it repeatedly.



    If Bulk Email didn't work you wouldn't see it being used !!!!!!!!!!

---------------------------------------------------------------------------

What is the Future of Bulk Email ? My advice is to get out there while you
still can and build up your business with Bulk E-mail.

---------------------------------------------------------------------------
What is Bulk E-mail ? - Bulk E-mail is the sending out of unsolicited Email
Messages. These Bulk E-mail messages can be sent to target list of Email
addresses or to just anyone. It is entirely possible to send out several
million pieces of Bulk Email in one day. These Bulk E-mail messages can
contain information, offers to sell goods or services, or simply promote a
web site.

---------------------------------------------------------------------------


                     General Bulk E-Mail Mailing Rates

  These prices include the creation of the Bulk E-Mail message, the use of
         the mailing list and the sending out of the Bulk E-mail.

Small Starter Size     25,000...............................$99

Try it Sampler Size   100,000..............................$199

Medium Size Run       250,000..............................$299

Large Run             500,000..............................$499

Serious Run         1,000,000..............................$899

Professional        2,000,000. ............................$1500

Business Builder    3,000,000..............................$2200

Mega Market Run     5,000,000..............................$3000


---------------------------------------------------------------------------

              Mailing Lists ( Does not include Bulk E-Mailing)

1,000,000 E-mail addresses........................................$99

2,0000,000 E-mail addresses......................................$149

5,000,000 E-mail addresses.......................................$299

10,000.000 E-mail addresses......................................$499

---------------------------------------------------------------------------

We have over 40,000,000 names in hand.  This list is updated every
few weeks. This gives our customers the NEWEST list available anywhere.
We can assure our customers that thier order will be processed A S A P.
If there is ever a doubt we send extra names.  We may not be the cheapest 
but we give our customer "TOP QUALITY SERVICE".

---------------------------------------------------------------------------
OIL PATCH MARKETING
RT 2 BOX 396A
JENKS, OK 74037

Call Bill Moore at 918-291-7546

Or fax your order to 918-291-7546

We accept Visa, MasterCard, Discover/Novus, American Ezpress
and checks by fax

If you're not interested in receiving this type of email, 
DO NOT HIT REPLY.  Send a blank e-mail message to







>From owner-9fans  Wed Jul  2 22:59:29 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id WAA18505 for 9fans-outgoing; Wed, 2 Jul 1997 22:59:29 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from finland.it.earthlink.net (finland-c.it.earthlink.net [204.250.46.29]) by cse.psu.edu (8.8.5/8.7.3) with ESMTP id WAA18501 for <9fans@cse.psu.edu>; Wed, 2 Jul 1997 22:59:22 -0400 (EDT)
Received: from solace.earthlink.net (1Cust28.Max3.San-Francisco.CA.MS.UU.NET [153.35.234.156])
	by finland.it.earthlink.net (8.8.5/8.8.5) with ESMTP id TAA06053
	for <9fans@cse.psu.edu>; Wed, 2 Jul 1997 19:59:14 -0700 (PDT)
Received: (from dbul@localhost) by solace.earthlink.net (8.7.5/8.7.3) id TAA01195; Wed, 2 Jul 1997 19:57:27 -0700
Date: Wed, 2 Jul 1997 19:57:27 -0700
Message-Id: <199707030257.TAA01195@solace.earthlink.net>
From: David Bulkow 
To: tadhunt@lucent.com
CC: 9fans@cse.psu.edu
In-reply-to: <199706302025.QAA17941@dante.mh.lucent.com> (message from Tad
	Hunt on Mon, 30 Jun 1997 16:25:54 -0400)
Subject: Re: Job Offer: Kernel Developers and System Engineers needed
Reply-to: dbul@earthlink.net
Mime-Version: 1.0
Content-Description: A MIME message created by mime-compose.el.
Content-Type: multipart/mixed; boundary=messageboundary
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

> THIS IS A MESSAGE IN 'MIME' FORMAT.
> If you are reading this, your mail reader may not support MIME.
> Some parts of this message will be readable as plain text.

--messageboundary
Content-Type: text/plain

Dear Mr. Hunt,

I have a supreme interest in working with Lucent Technologies.
Included below is my resume. 

My experience includes several years as a Systems Engineer consulting
customers in application design issues as well as developing kernel
enhancements and supplying defect repairs.

On the personal front, I have spent numerous hours studying the design
and internals of several systems including Plan9, VSTa, Amoeba, and
Choices.

Could you please send more information about the positions available,
including where they would be?

David Bulkow
dbul@earthlink.net


--messageboundary
Content-Type: text/plain; charset=US-ASCII; name="resume.txt"
Content-Description: /tmp/resume.txt
Content-Transfer-Encoding: quoted-printable

			     David Bulkow
			  1775 Milmont Drive
			    Apartment F204
			  Milpitas, CA 95035
			  dbul@earthlink.net
			    (408) 934-1394

Objective

     Software Engineering Development =


Individual Study

     Operating Systems Design and Implementation with an emphasis on
     new concepts and non-traditional methodologies. Personal research
     includes creating "from scratch" working models.

     Software Processes and Organizational Structure concentrating on
     the supporting culture as well as the generation of effective
     process frameworks.

Qualifications

     Working knowledge of kernel internals and utilities on both Unix
     SVR3 and SVR4 platforms including streams, scheduling, virtual
     memory, file systems, async, event tracing, and debuggers. Strong
     TCP/IP networking skills in both setup and diagnostics. Performed
     development, failure analysis and repair on many areas of system
     software. Emphasis on Stratus fault tolerant subsystems.

     Trained in the workings of Windows NT services, networking, and
     threads.  Attended courses on the WIN32 programming
     environment. Worked with contractor when developing device
     drivers. Developed multi-threaded services to support distributed
     application.

     Developed SEI CMM Level 2 capable processes for use in an
     Enhanced Services Engineering Group providing customer service
     and sustaining engineering services for telecom customers.

Work History

5/97 - present Lockheed Martin Missiles and Space

     5/97-present Senior Software Engineer - Mission Assurance & Training=


     Currently developing Web based solutions to replace existing
     management applications. Development environment includes HTML,
     JavaScript, Java, C and Perl.

10/91 - 5/97 Stratus Computer, Inc.

     6/96-5/97 Senior Software Engineer - UX Development Group

     Responsible for design, development, and testing of installation
     subsystem and utilities in a port of HP-UX to Stratus
     hardware. Created build and development environment automation
     utilities using scripting tools and Tcl/Tk. Documentation
     developed using html for company wide web access. Interfaced with
     customer service on a consultation basis. Involved in the design
     of the next generation remote service network.

     4/95-6/96 Technical Lead - Enhanced Services Engineering

     Technical Lead and Consultant to Enhanced Services Engineering
     Group focused on a telecom customer environment. Primary work
     responsibilities involved software sustaining for several
     revisions of the FTX 2 (Unix SVR4 port) operating
     environment. Customer interface duties involved management of
     critical situations, maintaining and coordinating the workflow of
     problem and status reports, assisting in development questions,
     and understanding customer needs and expectations on a daily
     basis. Designed workflow processes with a goal of attaining SEI
     CMM Level 2.

     12/94-4/95 Software Engineer - Isis Distributed Systems

     Participated with Windows NT development team in the Radio PC
     cluster project.  Worked on the design of a serviceability
     application to manage the cluster as a cohesive unit. Also
     provided input to the design of the remote service network
     capability of the cluster product. Partnered with owner of
     sub-contractor relationships and assisted in management of
     deliverables with the sub-contractors.

     4/94-12/94 Software Engineer - Software Sustaining Engineering

     Member of software sustaining kernel group supporting FTX 1 and
     FTX 2 (Unix SVR3 and SVR4 port). Diagnosed problems escalated by
     Customer Service, designed code changes where necessary. Managed
     application of source changes to multiple trees/releases. Worked
     with development group when necessary and integrated code changes
     into development trees as needed. Concentrated efforts in Stratus
     value added fault tolerance layers.

     10/91-4/94 Software Engineer - Customer Service

     Member of operating system support group. Performed analysis and
     debugging from kernel through application levels for both FTX 1
     and FTX 2 (Unix SVR3 and SVR4 port). Member of enhanced support
     for telecommunications customers.  Provided on-site support.

7/90-10/91 Systems Programmer, Cycare Systems, Inc.

     Implemented system administration facilities on Honeywell Bull
     DPX2 under BOS (Unix SVR3 port). Provided direction for
     application programmers in porting efforts between DOS and
     UNIX. Debugging of shared libraries, application and operating
     system interface.

Education

     Bachelor of Science, Computer Science
     University of Wisconsin - Madison, 1989 =


Languages

     C, C++, Java, Tcl/Tk, Bourne Shell, C-Shell, RCS, CVS, Pascal, FORTR=
AN,
     COBOL, awk, Intel x86 assembly, Intel i860 assembly, Motorola 68k as=
sembly =


Systems

     HP-UX, FTX1/SVR3, FTX2/SVR4, MS-DOS, Windows 3.1/95/NT, SunOS,
     Solaris, BSD, Linux, VMS, Xenix, Stratus VOS, Honeywell BOS, Plan9 -=
-messageboundary--

--messageboundary
Content-Type: text/html; charset=US-ASCII; name="resume.html"
Content-Description: ~/doc/personal/resume.html
Content-Transfer-Encoding: quoted-printable




Resume: David Bulkow



David Bulkow

1775 Milmont Drive

Apartment F204

Milpitas, CA 95035

dbul@earthlink.net

(408) 934-1394


Objective



Software Engineering Development


Individual Study



    Operating Systems Design and Implementation with an emphasis on
    new concepts and non-traditional methodologies.  Personal research
    includes creating "from scratch" working models.

    Software Processes and Organizational Structure concentrating on
    the supporting culture as well as the generation of effective
    process frameworks.


Qualifications



    Working knowledge of kernel internals and utilities on both Unix
    SVR3 and SVR4 platforms including streams, scheduling, virtual
    memory, file systems, async, event tracing, and debuggers.  Strong
    TCP/IP networking skills in both setup and diagnostics.  Performed
    development, failure analysis and repair on many areas of system
    software.  Emphasis on Stratus fault tolerant subsystems.


    Trained in the workings of Windows NT services, networking, and
    threads.  Attended courses on the WIN32 programming environment.
    Worked with contractor when developing device drivers.  Developed
    multi-threaded services to support distributed application.


    Developed SEI CMM Level 2 capable processes for use in an Enhanced
    Services Engineering Group providing customer service and
    sustaining engineering services for telecom customers.


Work History

5/97 - present Lockheed Martin Missiles and Space


5/97-present Senior Software Engineer - Mission Assurance & Training<=
/h4>


        Currently developing Web based solutions to replace existing
        management applications.  Development environment includes
        HTML, JavaScript, Java, C and Perl.


10/91 - 5/97 Stratus Computer, Inc.


6/96-5/97 Senior Software Engineer - UX Development Group


        Responsible for design, development, and testing of
        installation subsystem and utilities in a port of HP-UX to
        Stratus hardware.  Created build and development environment
        automation utilities using scripting tools and Tcl/Tk.
        Documentation developed using html for company wide web
        access.  Interfaced with customer service on a consultation
        basis.  Involved in the design of the next generation remote
        service network.

4/95-6/96    Technical Lead - Enhanced Services Engineering


        Technical Lead and Consultant to Enhanced Services Engineering
        Group focused on a telecom customer environment.  Primary work
        responsibilities involved software sustaining for several
        revisions of the FTX 2 (Unix SVR4 port) operating environment.
        Customer interface duties involved management of critical
        situations, maintaining and coordinating the workflow of
        problem and status reports, assisting in development
        questions, and understanding customer needs and expectations
        on a daily basis.  Designed workflow processes with a goal of
        attaining SEI CMM Level 2.

12/94-4/95   Software Engineer - Isis Distributed Systems


        Participated with Windows NT development team in the Radio PC
        cluster project.  Worked on the design of a serviceability
        application to manage the cluster as a cohesive unit.  Also
        provided input to the design of the remote service network
        capability of the cluster product.  Partnered with owner of
        sub-contractor relationships and assisted in management of
        deliverables with the sub-contractors.

4/94-12/94   Software Engineer - Software Sustaining Engineering=



        Member of software sustaining kernel group supporting FTX 1
        and FTX 2 (Unix SVR3 and SVR4 port).  Diagnosed problems
        escalated by Customer Service, designed code changes where
        necessary.  Managed application of source changes to multiple
        trees/releases.  Worked with development group when necessary
        and integrated code changes into development trees as needed.
        Concentrated efforts in Stratus value added fault tolerance
        layers.

10/91-4/94   Software Engineer - Customer Service


        Member of operating system support group.  Performed analysis
        and debugging from kernel through application levels for both
        FTX 1 and FTX 2 (Unix SVR3 and SVR4 port).  Member of enhanced
        support for telecommunications customers.  Provided on-site
        support.


7/90-10/91   Systems Programmer, Cycare Systems, Inc.


        Implemented system administration facilities on Honeywell Bull
        DPX2 under BOS (Unix SVR3 port).  Provided direction for
        application programmers in porting efforts between DOS and
        UNIX.  Debugging of shared libraries, application and
        operating system interface.


Education



Bachelor of Science, Computer Science

University of Wisconsin - Madison, 1989


Languages



    C, C++, Java, Tcl/Tk, Bourne Shell, C-Shell, RCS, CVS, Pascal,
    FORTRAN, COBOL, awk, Intel x86 assembly, Intel i860 assembly,
    Motorola 68k assembly


Systems


    HP-UX, FTX1/SVR3, FTX2/SVR4, MS-DOS, Windows 3.1/95/NT, SunOS,
    Solaris, BSD, Linux, VMS, Xenix, Stratus VOS, Honeywell BOS, Plan9






--messageboundary
Content-Type: text/plain



>From owner-9fans  Thu Jul  3 09:37:18 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id JAA22681 for 9fans-outgoing; Thu, 3 Jul 1997 09:37:18 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ns.dbSystems.com (root@[204.178.76.1]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id JAA22677 for <9fans@cse.psu.edu>; Thu, 3 Jul 1997 09:37:10 -0400 (EDT)
Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id IAA23050 for 9fans@cse.psu.edu; Thu, 3 Jul 1997 08:34:24 -0500
Date: Thu, 3 Jul 1997 08:34:24 -0500
From: "G. David Butler" 
Message-Id: <199707031334.IAA23050@ns.dbSystems.com>
To: 9fans@cse.psu.edu
Subject: multiple ethernet interfaces, naming
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

I am well on the way to supporting multiple ethernet interfaces
on the PC on Plan9 and I thought I would get some input.

Currently the ether device is #l and the card is called simply
ether.  I think the cards should be ether0, ether1, etc.  This
requires changes in a few programs and files to look for
/net/ether0 instead of /net/ether during the boot of the computer.
This also requires the lance device in other ports to call the card
ether0.  I have done all of these.

The next step is the interesting one.  In the kernel there are two
ways of doing multiple devices off one driver.  Examples are the
serial devices eia[0-?] on #t and the network protocols on #I.
The main difference can be seen by a ls '#t' and ls '#I'.  The
second one comes back with "ls: #I: network protocol not supported".
You must specify which protocol you want by ls '#Itcp', for example.
(This is different in Inferno, you don't have to add the tcp part,
if that makes a difference.)

My work so far is to make the ether devices behave like #I.  So one
must bind #lether0, #lether1, etc. separately.  In addition I also
am forcing the ethernet naming specified in plan9.ini instead of
the current driver's way of assiging to "ether" the first card that
probes successfully.  I think this is important since you don't want
to assign any old IP address to any old network card.  Ether0 is
connected to a specific network and a different address would not work.

This is where I want to start the discussion.  First I would like to
understand the thinking behind the #I semantics, especially since it
changed in Inferno.  Next, should #l behave like #I as I have it now
or like #t and why?  Should the semantics of #I change?  And lastly,
if #I changes, what is the use of strings after the initial character
in devices like #Itcp?

As always, thanks for any input.

David Butler
gdb@dbSystems.com

>From owner-9fans  Thu Jul  3 10:28:41 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id KAA23567 for 9fans-outgoing; Thu, 3 Jul 1997 10:28:40 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.bell-labs.com (achille.cs.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id KAA23563 for <9fans@cse.psu.edu>; Thu, 3 Jul 1997 10:28:37 -0400 (EDT)
From: presotto@plan9.bell-labs.com
Message-Id: <199707031428.KAA23563@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Thu, 3 Jul 1997 10:19:05 -0400
Subject: re: multiple ethernet interfaces, naming
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

For brazil, jmk got multiple ether interfaces working.
You might as well make things compatible since we
should eventually release this cruft.  They bind as
'#l0', '#l1', '#l2', ...  The directory names
are ether0, ether1, ether2, ...  After we do

bind -a '#l0' /net
bind -a '#l1' /net

an ls of /net yields

/net/arp
/net/cs
/net/dns
/net/ether0
/net/ether1
/net/gre
/net/icmp
/net/il
...

In plan9.ini we have

ether0=type=elnk3 port=0xE000
ether1=type=elnk3 port=0x0300

Our strangest machine has 4 ether cards on it.
This should be the same in inferno since it
shares most of this code with brazil.

>From owner-9fans  Thu Jul  3 12:33:59 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id MAA25680 for 9fans-outgoing; Thu, 3 Jul 1997 12:33:59 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ns.dbSystems.com (root@[204.178.76.1]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id MAA25672 for <9fans@cse.psu.edu>; Thu, 3 Jul 1997 12:33:51 -0400 (EDT)
Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id LAA23159 for 9fans@cse.psu.edu; Thu, 3 Jul 1997 11:32:43 -0500
Date: Thu, 3 Jul 1997 11:32:43 -0500
From: "G. David Butler" 
Message-Id: <199707031632.LAA23159@ns.dbSystems.com>
To: 9fans@cse.psu.edu
Subject: re: multiple ethernet interfaces, naming
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

>From: presotto@plan9.bell-labs.com
>
>For brazil, jmk got multiple ether interfaces working.
>You might as well make things compatible since we
>should eventually release this cruft.

I don't think that matters any more.  My Plan9 will be
sooo different by then that it won't do me any good.
I'm even changing 9P, but more on that later.  I'm
really tired of hearing about brazil.

>                                       They bind as
>'#l0', '#l1', '#l2', ...  The directory names
>are ether0, ether1, ether2, ...

That is consistent with #w[0-6] for sd[0-6]partition, etc.

Lets say you add FDDI.  Do you do #l3 and ether3 is
really fddi, or does #l3 get fddi0?  Would it not be
better to do #lfddi0?  Or would you do #F0 (whatever
letter you choose for fddi) for fddi0?  See below.

>an ls of /net yields
...
>/net/gre

What is this, another brazil thingy?

>In plan9.ini we have
>
>ether0=type=elnk3 port=0xE000
>ether1=type=elnk3 port=0x0300

So, if you have:

ether0=...
ether1=...
fddi0=...
atm0=...
atm1=...

Should each name have a different #.? scsi0=... does.  Or
do we do:

ether0=type=elnk3 ...
ether1=type=decfddi ...

Then #l[0-9] works.

Thanks.

David Butler
gdb@dbSystems.com

>From owner-9fans  Thu Jul  3 13:52:33 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id NAA27471 for 9fans-outgoing; Thu, 3 Jul 1997 13:52:32 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.cs.su.oz.au (lore.plan9.cs.su.oz.au [129.78.96.2]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id NAA27451 for <9fans@cse.psu.edu>; Thu, 3 Jul 1997 13:52:18 -0400 (EDT)
To: 9fans@cse.psu.edu
Subject: re: multiple ethernet interfaces, naming
From: David Hogan 
Date: Fri,  4 Jul 1997 03:39:34 +1000
In-Reply-To: <199707031632.LAA23159@ns.dbSystems.com>
Message-ID: <199707040339.31153.out.bakap@plan9.cs.su.oz.au>
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

> >From: presotto@plan9.bell-labs.com
> >For brazil, jmk got multiple ether interfaces working.
> >You might as well make things compatible since we
> >should eventually release this cruft.

	Brazil...
	Where hearts were entertaining June
	We stood beneath an amber moon
	And softly murmured someday soon.

> I don't think that matters any more.  My Plan9 will be
> sooo different by then that it won't do me any good.

Rule 1: don't split up the party!

> I'm even changing 9P, but more on that later.  I'm
> really tired of hearing about brazil.

Brazil, Brazil, Brazil, Brazil!!!

I'd just like to mention that I've "sort of" got Plug and Play
support working.  There's still a fair bit of work to be done
to get it working properly though, but when it is, I plan to
release it.  This requires some changes to the ethernet drivers...

	Tomorrow was another day
	The morning found me miles away 
	With still a million things to say...

>From owner-9fans  Thu Jul  3 16:35:15 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id QAA00283 for 9fans-outgoing; Thu, 3 Jul 1997 16:35:15 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.bell-labs.com (achille.cs.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id QAA00275 for <9fans@cse.psu.edu>; Thu, 3 Jul 1997 16:35:11 -0400 (EDT)
From: presotto@plan9.bell-labs.com
Message-Id: <199707032035.QAA00275@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Thu, 3 Jul 1997 16:32:20 -0400
Subject: re: multiple ethernet interfaces, naming
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

I'ld continue ingnoring fddi myself and hoping that it
goes away.  The 100baset ether is already easier to work
with.  The giga ether will make it just plain anchronistic.

Up to you if you want to treat it as an ether or something
else.

>From owner-9fans  Thu Jul  3 19:16:31 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id TAA02244 for 9fans-outgoing; Thu, 3 Jul 1997 19:16:31 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ncube.com (hundl.ncube.com [134.242.5.163]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id TAA02240 for <9fans@cse.psu.edu>; Thu, 3 Jul 1997 19:16:26 -0400 (EDT)
From: beto@ncube.com
Message-Id: <199707032316.TAA02240@cse.psu.edu>
Date: Thu, 3 Jul 97 16:05:13 PDT
To: 9fans@cse.psu.edu
Subject: Re: multiple ethernet interfaces, naming
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

I got another question about multiple ethernet interfaces.

If I do announce("/tcp/*/0",....) what would be the content of
/tcp/*/local if I have multiple ethernet/ip interfaces.

Normally It would return something like 

	My.ip.add.ress!nextport

but if we have multiple interfaces what should it return?

Some programs (bootp, arpd, ftpfs) use this trick to discover the
local ip address and to generate unique port numbers.

Maybe 0.0.0.0!nextport until there is a connection and it
knows which ip interface?

Any comments would be appreacited?



>From owner-9fans  Thu Jul  3 19:40:46 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id TAA02526 for 9fans-outgoing; Thu, 3 Jul 1997 19:40:46 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from postman.opengroup.org (postman.opengroup.org [130.105.1.152]) by cse.psu.edu (8.8.5/8.7.3) with ESMTP id TAA02522 for <9fans@cse.psu.edu>; Thu, 3 Jul 1997 19:40:42 -0400 (EDT)
Received: from sulphur.osf.org (sulphur.camb.opengroup.org [130.105.1.123])
	by postman.opengroup.org (8.8.6/8.8.6) with ESMTP id TAA19260
	for <9fans@cse.psu.edu>; Thu, 3 Jul 1997 19:40:13 -0400 (EDT)
Received: (from rsalz@localhost) by sulphur.osf.org (8.7.5/8.7.3) id TAA14651 for 9fans@cse.psu.edu; Thu, 3 Jul 1997 19:40:10 -0400 (EDT)
Date: Thu, 3 Jul 1997 19:40:10 -0400 (EDT)
From: Rich Salz 
Message-Id: <199707032340.TAA14651@sulphur.osf.org>
To: 9fans@cse.psu.edu
Subject: re: multiple ethernet interfaces, naming
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

>I'm even changing 9P,

Without knowing the details of your situation, I'll comment that this
is almost definitely a really bad thing to do.  Don't sacrifice
interoperability.

>From owner-9fans  Mon Jul  7 09:05:38 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id JAA27955 for 9fans-outgoing; Mon, 7 Jul 1997 09:05:38 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ns.dbSystems.com (root@[204.178.76.1]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id JAA27948 for <9fans@cse.psu.edu>; Mon, 7 Jul 1997 09:05:30 -0400 (EDT)
Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id IAA00294 for 9fans@cse.psu.edu; Mon, 7 Jul 1997 08:03:49 -0500
Date: Mon, 7 Jul 1997 08:03:49 -0500
From: "G. David Butler" 
Message-Id: <199707071303.IAA00294@ns.dbSystems.com>
To: 9fans@cse.psu.edu
Subject: re: multiple ethernet interfaces, naming
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

>From: presotto@plan9.bell-labs.com
>Date: Thu, 3 Jul 1997 16:32:20 -0400
>Subject: re: multiple ethernet interfaces, naming
>
>I'ld continue ingnoring fddi myself and hoping that it
>goes away.  The 100baset ether is already easier to work
>with.  The giga ether will make it just plain anchronistic.

I agree.  I just wanted to get the syntax down.

>Up to you if you want to treat it as an ether or something
>else.

I went with #l0, #l1, etc. with assumption that other types
of interfaces (non ethernet) will need different support
for IP (like arp).

Done.  I have multiple interfaces working!  Now to phase II.

>From: beto@ncube.com
>Date: Thu, 3 Jul 97 16:05:13 PDT
>Subject: Re: multiple ethernet interfaces, naming
>
>I got another question about multiple ethernet interfaces.
>
>If I do announce("/tcp/*/0",....) what would be the content of
>/tcp/*/local if I have multiple ethernet/ip interfaces.

At this point, since there is no connection, unknown.

>Normally It would return something like 
>
>	My.ip.add.ress!nextport
>
>but if we have multiple interfaces what should it return?

I think after the listen returns, then the local address should be
the address of the interface the packet came from.

>Some programs (bootp, arpd, ftpfs) use this trick to discover the
>local ip address and to generate unique port numbers.

Yeah, there will be changes here.

>Maybe 0.0.0.0!nextport until there is a connection and it
>knows which ip interface?

That may work.

>Any comments would be appreacited?

Lets ask presotto@plan9.bell-labs.com if he can give us the
syntax/semantics of the current implementation so we can
stay consistent.

Dave, can you help?

David Butler
gdb@dbSystems.com

>From owner-9fans  Mon Jul  7 11:15:12 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id LAA00522 for 9fans-outgoing; Mon, 7 Jul 1997 11:15:11 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.bell-labs.com (achille.cs.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id LAA00500 for <9fans@cse.psu.edu>; Mon, 7 Jul 1997 11:15:04 -0400 (EDT)
From: presotto@plan9.bell-labs.com
Message-Id: <199707071515.LAA00500@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Mon, 7 Jul 1997 10:53:20 -0400
Subject: re: multiple ethernet interfaces, naming
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

First of all, I've changed listen to listen specificly to
each port that's important to it in addition to '*'.  Otherwise
local users could hijack listening on important ports.  In
a friendly communittee it is more likely done as a mistake
than intentional malice.

I'll post that listen.

>>
>>If I do announce("/tcp/*/0",....) what would be the content of
>>/tcp/*/local if I have multiple ethernet/ip interfaces.
>
>I think after the listen returns, then the local address should be
>the address of the interface the packet came from.

I currently just make the listener 'local' the address of the first interface.
For the listener it doesn't matter much.  However when the new call
comes in, the local address should indeed be the address the call came to.
That's what we do.

>>Some programs (bootp, arpd, ftpfs) use this trick to discover the
>>local ip address and to generate unique port numbers.
>
>Yeah, there will be changes here.
>

For ftpfs, the above works fine since it is connection oriented and the
new call has the new local address.

Arpd doesn't matter since it is listening to a specific ethernet.
We actually gave up and moved it into the stack.  It made the
booting checken/egg stuff a lot easier.

However, I decided that the udp connection oriented stuff was
too much of a pain for things like bootp and added a 'headers'
control message for udp that causes every udp packets to/from
user programs to be preceeded by 12 bytes of info:

	uchar	raddr[IPaddrlen];	/* remote address */
	uchar	laddr[IPaddrlen];	/* local address */
	uchar	rport[2];
	uchar	lport[2];

That way, we can reply from the same address the message was sent to.

In case a message is sent to a broadcast address, we make 'laddr'
the local address on the interface the message came in
through.  That way, if it's a bootp from a directly connected
network and the system booting has ndb entries on multiple networks
to which the server is directly connected, it can decide which
'ciaddr' IP address to stick in the reply.

I'm currently rewriting bootp to be a dhcp server.  I'll put the
brazil (brazil, brazil, dee dah, dee dah, ...) version out there
for one of you to plan9 ize if you like.

>From owner-9fans  Mon Jul  7 11:15:48 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id LAA00596 for 9fans-outgoing; Mon, 7 Jul 1997 11:15:47 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.bell-labs.com (achille.cs.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id LAA00582 for <9fans@cse.psu.edu>; Mon, 7 Jul 1997 11:15:42 -0400 (EDT)
From: jmk@plan9.bell-labs.com
Message-Id: <199707071515.LAA00582@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Mon, 7 Jul 1997 11:14:53 -0400
Subject: re: multiple ethernet interfaces, naming
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

	>/net/gre

	What is this, another brazil thingy?

Generic Routing Encapsulation. RFC1701.

>From owner-9fans  Tue Jul  8 10:01:56 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id KAA14606 for 9fans-outgoing; Tue, 8 Jul 1997 10:01:56 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ns.dbSystems.com (root@[204.178.76.1]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id KAA14602 for <9fans@cse.psu.edu>; Tue, 8 Jul 1997 10:01:50 -0400 (EDT)
Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id IAA02149 for 9fans@cse.psu.edu; Tue, 8 Jul 1997 08:59:36 -0500
Date: Tue, 8 Jul 1997 08:59:36 -0500
From: "G. David Butler" 
Message-Id: <199707081359.IAA02149@ns.dbSystems.com>
To: 9fans@cse.psu.edu
Subject: re: multiple ethernet interfaces, naming
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

>From: presotto@plan9.bell-labs.com
>Date: Mon, 7 Jul 1997 10:53:20 -0400
>Subject: re: multiple ethernet interfaces, naming
>
>First of all, I've changed listen to listen specificly to
>each port that's important to it in addition to '*'.  Otherwise
>local users could hijack listening on important ports.  In
>a friendly communittee it is more likely done as a mistake
>than intentional malice.
>
>I'll post that listen.

Thanks

>I currently just make the listener 'local' the address of the first interface.
>For the listener it doesn't matter much.  However when the new call
>comes in, the local address should indeed be the address the call came to.
>That's what we do.

We?  Our source says local is *always* the address of the first
interface.  I assume you now use cp->src in iplocalfill()?

>For ftpfs, the above works fine since it is connection oriented and the
>new call has the new local address.

With the above change.

>Arpd doesn't matter since it is listening to a specific ethernet.
>We actually gave up and moved it into the stack.  It made the
>booting checken/egg stuff a lot easier.

Whoa!  That is a faily big change.  Isn't there another way to fix
arpd's problems?  (See below)

>However, I decided that the udp connection oriented stuff was
>too much of a pain for things like bootp and added a 'headers'
>control message for udp that causes every udp packets to/from
>user programs to be preceeded by 12 bytes of info:
>
>	uchar	raddr[IPaddrlen];	/* remote address */
>	uchar	laddr[IPaddrlen];	/* local address */
>	uchar	rport[2];
>	uchar	lport[2];
>
>That way, we can reply from the same address the message was sent to.

I see that code.  I also see the code in ipconfig that adds a secondary
address by pushing internet again.  So the headers allow you to
handle secondary addresses correctly, since c->src would be the first
address on an interface.  Of course, it would help if arpd worked
correctly. (See below)

>I'm currently rewriting bootp to be a dhcp server.  I'll put the
>brazil (brazil, brazil, dee dah, dee dah, ...) version out there
>for one of you to plan9 ize if you like.

Thanks again (for dhcp, not br*zil... :-)

So far the changes I'm planning look like:

    Change devip.c and make iplocalfill use c->src and deal with the
    consequences (i.e. the problems that crop up).

    Change ipconfig to use "look internet" to see if the interface has
    ever been configured instead of looking for a local address on the
    ip stack.

    Work on arpd (a lot) to use #P/ipifc data to do the right things.

Can anyone think of any other problems?

David Butler
gdb@dbSystems.com

>From owner-9fans  Tue Jul  8 10:12:52 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id KAA14914 for 9fans-outgoing; Tue, 8 Jul 1997 10:12:52 -0400 (EDT)
Received: from foible.proxima.alt.za (foible.proxima.alt.za [192.96.32.132]) by cse.psu.edu (8.8.5/8.7.3) with ESMTP id KAA14902 for <9fans@cse.psu.edu>; Tue, 8 Jul 1997 10:12:39 -0400 (EDT)
Received: from localhost.proxima.alt.za (localhost.proxima.alt.za [127.0.0.1]) by foible.proxima.alt.za (8.8.6/8.8.2) with SMTP id QAA01502 for 9fans@cse.psu.edu; Tue, 8 Jul 1997 16:15:40 +0200 (SAT)
Message-Id: <199707081415.QAA01502@foible.proxima.alt.za>
X-Authentication-Warning: foible.proxima.alt.za: localhost.proxima.alt.za [127.0.0.1] didn't use HELO protocol
X-Mailer: exmh version 2.0gamma 1/27/96
To: 9fans@cse.psu.edu
Subject: Re: multiple ethernet interfaces, naming 
In-reply-to: Message from "G. David Butler"  
 of "Tue, 08 Jul 1997 08:59:36 EST." <199707081359.IAA02149@ns.dbSystems.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 08 Jul 1997 16:15:40 +0200
From: Lucio de Re 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

> 
> >I'm currently rewriting bootp to be a dhcp server.  I'll put the
> >brazil (brazil, brazil, dee dah, dee dah, ...) version out there
> >for one of you to plan9 ize if you like.
> 
Score 1 for Microsoft, 0 for Lucent :-(

Surely you should be working on IPv6 or somesuch instead of pampering
to the Win'95 world (sigh!)?  Next thing, you'll all be developing
dynamic DNS too :-(
-- 
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.



>From owner-9fans  Tue Jul  8 10:32:56 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id KAA15409 for 9fans-outgoing; Tue, 8 Jul 1997 10:32:55 -0400 (EDT)
Received: from foible.proxima.alt.za (foible.proxima.alt.za [192.96.32.132]) by cse.psu.edu (8.8.5/8.7.3) with ESMTP id KAA15404 for <9fans@cse.psu.edu>; Tue, 8 Jul 1997 10:32:46 -0400 (EDT)
Received: from localhost.proxima.alt.za (localhost.proxima.alt.za [127.0.0.1]) by foible.proxima.alt.za (8.8.6/8.8.2) with SMTP id QAA01557 for 9fans@cse.psu.edu; Tue, 8 Jul 1997 16:36:02 +0200 (SAT)
Message-Id: <199707081436.QAA01557@foible.proxima.alt.za>
X-Authentication-Warning: foible.proxima.alt.za: localhost.proxima.alt.za [127.0.0.1] didn't use HELO protocol
X-Mailer: exmh version 2.0gamma 1/27/96
To: 9fans@cse.psu.edu
Subject: apologies
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 08 Jul 1997 16:36:01 +0200
From: Lucio de Re 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

Hm.  I guess I should be a touch more tactful.

Thing is, I think Plan 9 would knock the spots off any Microsoft
product if one could identify its rough edges and one smoothed
them out.

I don't think Win-anything will ever match Plan 9's creative, dare
I say genial, thinking, but it will swamp the market and I, amongst
many, will be the poorer for it.

I'm sorry if in venting my frustrations I offended anyone (other
than Bill Gates :-).
-- 
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.



>From owner-9fans  Tue Jul  8 14:37:20 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id OAA19871 for 9fans-outgoing; Tue, 8 Jul 1997 14:37:20 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ncube.com (hundl.ncube.com [134.242.5.163]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id OAA19867 for <9fans@cse.psu.edu>; Tue, 8 Jul 1997 14:37:15 -0400 (EDT)
From: beto@ncube.com
Message-Id: <199707081837.OAA19867@cse.psu.edu>
Date: Tue, 8 Jul 97 11:30:15 PDT
To: 9fans@cse.psu.edu
Subject: rc question
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

Hi, 

What should be the correct output for this rc fragment?

{
cat <From owner-9fans  Tue Jul  8 15:03:15 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id PAA20415 for 9fans-outgoing; Tue, 8 Jul 1997 15:03:15 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from finch.cse.psu.edu (qmailr@finch.cse.psu.edu [130.203.12.29]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id PAA20407 for <9fans@cse.psu.edu>; Tue, 8 Jul 1997 15:03:10 -0400 (EDT)
Received: (qmail 17191 invoked by uid 991); 8 Jul 1997 19:03:09 -0000
Message-ID: <19970708190309.17189.qmail@finch.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: rc question 
In-reply-to: Your message of "Tue, 08 Jul 1997 11:30:15 PDT."
             <199707081837.OAA19867@cse.psu.edu> 
Date: Tue, 08 Jul 1997 15:03:09 EDT
From: Scott Schwartz 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

beto@ncube.com writes:
| Is there a fix for this in the ftp site?

Byron's version prints the right thing.  We could port that to Plan 9. :-)


>From owner-9fans  Tue Jul  8 15:03:28 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id PAA20455 for 9fans-outgoing; Tue, 8 Jul 1997 15:03:28 -0400 (EDT)
Received: from foible.proxima.alt.za (foible.proxima.alt.za [192.96.32.132]) by cse.psu.edu (8.8.5/8.7.3) with ESMTP id PAA20425 for <9fans@cse.psu.edu>; Tue, 8 Jul 1997 15:03:16 -0400 (EDT)
Received: from localhost.proxima.alt.za (localhost.proxima.alt.za [127.0.0.1]) by foible.proxima.alt.za (8.8.6/8.8.2) with SMTP id VAA02183 for 9fans@cse.psu.edu; Tue, 8 Jul 1997 21:06:33 +0200 (SAT)
Message-Id: <199707081906.VAA02183@foible.proxima.alt.za>
X-Authentication-Warning: foible.proxima.alt.za: localhost.proxima.alt.za [127.0.0.1] didn't use HELO protocol
X-Mailer: exmh version 2.0gamma 1/27/96
To: 9fans@cse.psu.edu
Subject: Re: rc question 
In-reply-to: Message from beto@ncube.com 
 of "Tue, 08 Jul 1997 11:30:15 PDT." <199707081837.OAA19867@cse.psu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 08 Jul 1997 21:06:33 +0200
From: Lucio de Re 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

> Hi, 
> 
> What should be the correct output for this rc fragment?
> 
> {
> cat < hi there
> EOF
> }
> 
> I'm getting 
> 
> hi: file does not exist
> EOF: file does not exist
> 
> Is there a fix for this in the ftp site?

I have to enter a Ctrl-D after the closing brace before rc actually
registers.  Might be significant.
-- 
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.



>From owner-9fans  Tue Jul  8 15:08:02 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id PAA20793 for 9fans-outgoing; Tue, 8 Jul 1997 15:08:01 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from kissimmee.infomkt.ibm.com (kissimmee.infomkt.ibm.com [204.146.129.20]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id PAA20783 for <9fans@cse.psu.edu>; Tue, 8 Jul 1997 15:07:56 -0400 (EDT)
Received: from dingler.dev.infomkt.ibm.com (dingler.dev.infomkt.ibm.com [204.146.132.31]) by kissimmee.infomkt.ibm.com (8.6.10/8.6.10) with ESMTP id PAA12741; Tue, 8 Jul 1997 15:03:06 -0400
Received: (from quanstro@localhost) by dingler.dev.infomkt.ibm.com (8.7.5/8.7.3) id OAA46106; Tue, 8 Jul 1997 14:49:03 -0400
Date: Tue, 8 Jul 1997 14:49:03 -0400
Message-Id: <199707081849.OAA46106@dingler.dev.infomkt.ibm.com>
To: 9fans@cse.psu.edu, bento@ncube.com
From: erik quanstrom 
Subject: broken rc here documents.
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

>Hi, 
>
>What should be the correct output for this rc fragment?
>
>{
>cat <hi there
>EOF
>}
>
>I'm getting 
>
>hi: file does not exist
>EOF: file does not exist

the last time i tried writing a shell (1992) i decided that 
here documents were *way* too much work when you consider the 
simple quoting rules of rc (and other reasonable shells). all
you really need to do is replace each ' with '' and then put
the whole thing in 's. at one point i'd written a version of
shar that used exactly this trick but i seem to have lost it.

the point is: here documents are almost impossible to get
right so why not Just Use Quotes?

erik

>From owner-9fans  Tue Jul  8 15:10:31 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id PAA20967 for 9fans-outgoing; Tue, 8 Jul 1997 15:10:31 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.bell-labs.com (achille.cs.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id PAA20963 for <9fans@cse.psu.edu>; Tue, 8 Jul 1997 15:10:27 -0400 (EDT)
From: howard@plan9.bell-labs.com
Message-Id: <199707081910.PAA20963@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Tue, 8 Jul 1997 15:10:48 -0400
Subject: Re: rc question 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

'here' documents in nested rc constructs have to
come after the nest.

i.e., change

> {
> cat < hi there
> EOF
> }

to

{
cat <From owner-9fans  Tue Jul  8 15:53:37 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id PAA21791 for 9fans-outgoing; Tue, 8 Jul 1997 15:53:37 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from caldo.demon.co.uk (none@caldo.demon.co.uk [194.222.207.148]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id PAA21779 for <9fans@cse.psu.edu>; Tue, 8 Jul 1997 15:53:31 -0400 (EDT)
From: forsyth@caldo.demon.co.uk
Message-Id: <199707081953.PAA21779@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Tue, 8 Jul 1997 20:03:15 BST
Subject: Re: multiple ethernet interfaces, naming 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

DHCP is an Internet protocol, not exclusively Microsoft's,
nor was it exclusively designed by them
(although you'd hardly be blamed for thinking so, given the
way it is commonly described as a wonderful new Microsoft invention
by the PC press).  it's actually quite a useful thing to have in
the arsenal if you aim to take over the networking world.

>From owner-9fans  Tue Jul  8 17:13:10 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id RAA23081 for 9fans-outgoing; Tue, 8 Jul 1997 17:13:10 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from mail1.halcyon.com (mail1.halcyon.com [206.63.63.40]) by cse.psu.edu (8.8.5/8.7.3) with ESMTP id RAA23077 for <9fans@cse.psu.edu>; Tue, 8 Jul 1997 17:13:06 -0400 (EDT)
Received: from coho.halcyon.com (frankg@coho.halcyon.com [198.137.231.21])
	by mail1.halcyon.com (8.8.5/8.8.5) with SMTP id OAA06645
	for <9fans@cse.psu.edu>; Tue, 8 Jul 1997 14:14:19 -0700 (PDT)
Date: Tue, 8 Jul 1997 14:13:03 -0700 (PDT)
From: Frank Gleason 
To: 9fans@cse.psu.edu
Subject: Plan9 on sparc classic
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans


I am interested in getting a sparc classic for
use as a terminal. Has anyone run Plan9 on a 
classic?

The html archive of the 9fans mailing list
has been removed from the hosting system. Does
anyone have any information about the archive?

Thanks,
frankg@halcyon.com



>From owner-9fans  Tue Jul  8 17:52:03 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id RAA23655 for 9fans-outgoing; Tue, 8 Jul 1997 17:52:03 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from finch.cse.psu.edu (qmailr@finch.cse.psu.edu [130.203.12.29]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id RAA23651 for <9fans@cse.psu.edu>; Tue, 8 Jul 1997 17:51:59 -0400 (EDT)
Received: (qmail 18220 invoked by uid 991); 8 Jul 1997 21:51:59 -0000
Message-ID: <19970708215159.18218.qmail@finch.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: Plan9 on sparc classic 
In-reply-to: Your message of "Tue, 08 Jul 1997 14:13:03 PDT."
              
Date: Tue, 08 Jul 1997 17:51:59 EDT
From: Scott Schwartz 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

Frank Gleason  writes:
| The html archive of the 9fans mailing list
| has been removed from the hosting system. Does
| anyone have any information about the archive?

All the messages are archived by majoromo@cse.psu.edu.  Send it a help
message for instructions. (Access to this was broken for a while, but
it's fixed now.)

>From owner-9fans  Tue Jul  8 18:05:05 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id SAA23952 for 9fans-outgoing; Tue, 8 Jul 1997 18:05:05 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from finch.cse.psu.edu (qmailr@finch.cse.psu.edu [130.203.12.29]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id SAA23948 for <9fans@cse.psu.edu>; Tue, 8 Jul 1997 18:05:01 -0400 (EDT)
Received: (qmail 18802 invoked by uid 991); 8 Jul 1997 22:05:00 -0000
Message-ID: <19970708220500.18801.qmail@finch.cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Tue, 08 Jul 1997 18:05:00 EDT
From: Scott Schwartz 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

Here are some suggested changes to devvga to attempt to support screen
blanking, in the style of XFree86 3.3.  (Doing this completely right
requires chipset specific code, and more extensive changes.)  The
generic vga mechanisms could probably be used via aux/vga, but
/dev/vgactl is such a nice interface that I couldn't resist using it.
(Is that the wrong approach?)

-- Scott

diff devvga.c- devvga.c
292a293,329
> vga_blank(int mode)
> {
> 	uchar clocking_mode, mode_control;
> 
> 	if (mode == 0) {
> 		clocking_mode = 0;
> 		mode_control = Not_Hardware_Reset;
> 	}
> 	else if (mode == 1) {
> 		clocking_mode = Screen_Off;
> 		mode_control = Not_Hardware_Reset;
> 		/* Inspired by xfree86 3.3 vgaHW.c */
> 	}
> 	else if (mode == 2) {
> 		clocking_mode = 0;
> 		mode_control = 0;
> 		/* Wild guess.  Probably not useful. */
> 	}
> 	else if (mode == 3) {
> 		clocking_mode = Screen_Off;
> 		mode_control = 0;
> 	}
> 	else {
> 		SET(clocking_mode);
> 		SET(mode_control);
> 		error(Ebadarg);
> 	}
> 
> 	vgaxo(Seqx, Sync_Reset, Reset_Start);
> 	vgaxo(Seqx, Clocking_Mode,
> 		clocking_mode | (vgaxi(Seqx, Clocking_Mode) & ~Screen_Off));
> 	vgaxo(Crtx, Mode_Ctrl, 
> 		mode_control | (vgaxi(Crtx, Mode_Ctrl) & ~Not_Hardware_Reset));
> 	vgaxo(Seqx, Sync_Reset, Reset_End);
> }
> 
> static void
305c342,360
< 	if(strcmp(field[0], "hwgc") == 0){
- ---
> 	if(strcmp(field[0], "screen") == 0) {
> 		int mode = 0;
> 
> 		if (strcmp(field[1], "on") == 0)
> 			mode = 0;
> 		else if (strcmp(field[1], "standby") == 0)
> 			mode = 1;
> 		else if (strcmp(field[1], "suspend") == 0)
> 			mode = 2;
> 		else if (strcmp(field[1], "off") == 0)
> 			mode = 3;
> 		else
> 			error(Ebadarg);
> 
> 		/* if (vgac->blank) (vgac->blank)(mode); else */
> 		vga_blank(mode);
> 		return;
> 	}
> 	else if(strcmp(field[0], "hwgc") == 0){
1187a1243
> 

diff vga.h- vga.h
31a32,43
> enum {
> 	/* Seqx */
> 	Sync_Reset = 0x0,
> 		Reset_Start = 0x1,
> 		Reset_End = 0x3,
> 	Clocking_Mode = 0x1,
> 		Screen_Off = 0x20,
> 	/* Crtx */
> 	Mode_Ctrl = 0x17,
> 		Not_Hardware_Reset = 0x80,
> };
> 


>From owner-9fans  Tue Jul  8 19:06:57 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id TAA24831 for 9fans-outgoing; Tue, 8 Jul 1997 19:06:57 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.bell-labs.com (achille.cs.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id TAA24827 for <9fans@cse.psu.edu>; Tue, 8 Jul 1997 19:06:53 -0400 (EDT)
From: rob@plan9.bell-labs.com
Message-Id: <199707082306.TAA24827@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Tue, 8 Jul 1997 19:06:47 -0400
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

I put screen blanking portably into Brazil by just setting
the color map to all zeros after a quiet period.  Mouse action
restores it.

-rob

>From owner-9fans  Tue Jul  8 22:46:04 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id WAA27081 for 9fans-outgoing; Tue, 8 Jul 1997 22:46:04 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from finch.cse.psu.edu (qmailr@finch.cse.psu.edu [130.203.12.29]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id WAA27077 for <9fans@cse.psu.edu>; Tue, 8 Jul 1997 22:46:01 -0400 (EDT)
Received: (qmail 19032 invoked by uid 991); 9 Jul 1997 02:46:00 -0000
Message-ID: <19970709024600.19030.qmail@finch.cse.psu.edu>
To: 9fans@cse.psu.edu
In-reply-to: Your message of "Tue, 08 Jul 1997 19:06:47 EDT."
             <199707082306.TAA24827@cse.psu.edu> 
Date: Tue, 08 Jul 1997 22:46:00 EDT
From: Scott Schwartz 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

rob@plan9.bell-labs.com writes:
| I put screen blanking portably into Brazil by just setting
| the color map to all zeros after a quiet period.  Mouse action
| restores it.

That doesn't achieve the same effect, because it doesn't invoke
the VESA power saving mode.  Modern monitors watch the HSYNC and
VSYNC signals; if one stops they blank the screen in a moderate
power saving mode, and if both stop the monitor goes to very low
power mode.  

-- Scott

>From owner-9fans  Wed Jul  9 03:11:33 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id DAA29189 for 9fans-outgoing; Wed, 9 Jul 1997 03:11:33 -0400 (EDT)
Received: from foible.proxima.alt.za (foible.proxima.alt.za [192.96.32.132]) by cse.psu.edu (8.8.5/8.7.3) with ESMTP id DAA29184 for <9fans@cse.psu.edu>; Wed, 9 Jul 1997 03:11:18 -0400 (EDT)
Received: from localhost.proxima.alt.za (localhost.proxima.alt.za [127.0.0.1]) by foible.proxima.alt.za (8.8.6/8.8.2) with SMTP id JAA04916 for 9fans@cse.psu.edu; Wed, 9 Jul 1997 09:14:32 +0200 (SAT)
Message-Id: <199707090714.JAA04916@foible.proxima.alt.za>
X-Authentication-Warning: foible.proxima.alt.za: localhost.proxima.alt.za [127.0.0.1] didn't use HELO protocol
X-Mailer: exmh version 2.0gamma 1/27/96
To: 9fans@cse.psu.edu
Subject: VGA musings...
In-reply-to: Message from Scott Schwartz  
 of "Tue, 08 Jul 1997 18:05:00 EDT." <19970708220500.18801.qmail@finch.cse.psu.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 09 Jul 1997 09:14:32 +0200
From: Lucio de Re 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans


>From Scott Schwartz:
> Here are some suggested changes to devvga to attempt to support screen
> blanking, in the style of XFree86 3.3.  (Doing this completely right
> requires chipset specific code, and more extensive changes.)  The
> generic vga mechanisms could probably be used via aux/vga, but
> /dev/vgactl is such a nice interface that I couldn't resist using it.
> (Is that the wrong approach?)
> 
I would assume the contrary - device/chip specifics in the device driver,
generics in userland code.  Of course, that's also backwards, because
once off setting up of the VGA card should hardly be kernel resident.

I think this says something about different design criteria in hardware
and software.  

Maybe a new approach would be to have a "loader" operate as a pre-kernel
and arrange all devices into an architecture independent state?  Of
course, that's the BIOS approach, but not exactly.

I can see a problem with this tack, though, because there will always
be hardware features that can only be accessed if the adaptor is set up
appropriately, highest common denominator syndrome.

As far as VGA goes, I am reminded of the Ontel Amigo, which had a Z80 to
run CP/M and a 6502 with its own, dual-ported RAM (32 K, if memory serves)
for the graphic section.  The idea was to load in video RAM actual program
code, then communicate with this program as chosen by the user.  A graphic
language (X-protocol notwithstanding) has always appealed to me as an
architecture independent approach to communicating with graphic engines.

Of course, Plan 9's text-driven devices are very close to this, although
not quite in a position to interpret a full programming notation.  Adding
a programming layer (a shell?) might in fact suffice, as long as the
underlying commands set is sufficiently powerful.
-- 
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.



>From owner-9fans  Thu Jul 10 01:20:26 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id BAA13606 for 9fans-outgoing; Thu, 10 Jul 1997 01:20:26 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ns.dbSystems.com (root@[204.178.76.1]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id BAA13602 for <9fans@cse.psu.edu>; Thu, 10 Jul 1997 01:20:20 -0400 (EDT)
Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id AAA04450 for 9fans@cse.psu.edu; Thu, 10 Jul 1997 00:17:53 -0500
Date: Thu, 10 Jul 1997 00:17:53 -0500
From: "G. David Butler" 
Message-Id: <199707100517.AAA04450@ns.dbSystems.com>
To: 9fans@cse.psu.edu
Subject: re: multiple ethernet interfaces, naming
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

I hate replying to my own messages...

Multiple ethernet interfaces are now working.

>From: "G. David Butler" 
>Subject: re: multiple ethernet interfaces, naming
>
>>From: presotto@plan9.bell-labs.com
>>Date: Mon, 7 Jul 1997 10:53:20 -0400
>>Subject: re: multiple ethernet interfaces, naming
>>
>We?  Our source says local is *always* the address of the first
>interface.  I assume you now use cp->src in iplocalfill()?

This was needed.

>>Arpd doesn't matter since it is listening to a specific ethernet.
>>We actually gave up and moved it into the stack.  It made the
>>booting checken/egg stuff a lot easier.
>
>Whoa!  That is a faily big change.  Isn't there another way to fix
>arpd's problems?  (See below)

I had to take another tact with arpd, but I didn't have to put it
in the stack.

>>However, I decided that the udp connection oriented stuff was
>>too much of a pain for things like bootp and added a 'headers'

[snip]

>>That way, we can reply from the same address the message was sent to.
>
>I see that code.  I also see the code in ipconfig that adds a secondary
>address by pushing internet again.  So the headers allow you to
>handle secondary addresses correctly, since c->src would be the first
>address on an interface.  Of course, it would help if arpd worked
>correctly. (See below)

The secondary code is to handle multiple interfaces, not aliases;
even though it could do that.

>So far the changes I'm planning look like:
>
>    Change devip.c and make iplocalfill use c->src and deal with the
>    consequences (i.e. the problems that crop up).

Needed.  There were no consequences.

>    Change ipconfig to use "look internet" to see if the interface has
>    ever been configured instead of looking for a local address on the
>    ip stack.

Boy was that off base!  "look internet" doesn't help much on a chan
that you are trying to create.  Used #P/ipifc instead.

>    Work on arpd (a lot) to use #P/ipifc data to do the right things.

I didn't do this all the way yet.  Right now I use the digits at the
end of ether* to target the interface and ip number.  Works OK if there
is only one ip per interface.

>Can anyone think of any other problems?

How about the big one?  The kernel only will pass arp requests to one
arpd and an arpd will only sit on one interface.  Fixed that.

>David Butler
>gdb@dbSystems.com

dito.

>From owner-9fans  Thu Jul 10 17:17:33 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id RAA23218 for 9fans-outgoing; Thu, 10 Jul 1997 17:17:33 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ns.dbSystems.com (root@[204.178.76.1]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id RAA23212 for <9fans@cse.psu.edu>; Thu, 10 Jul 1997 17:17:27 -0400 (EDT)
Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id QAA06074 for 9fans@cse.psu.edu; Thu, 10 Jul 1997 16:15:00 -0500
Date: Thu, 10 Jul 1997 16:15:00 -0500
From: "G. David Butler" 
Message-Id: <199707102115.QAA06074@ns.dbSystems.com>
To: 9fans@cse.psu.edu
Subject: indexed directories and the File Server
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

On to the next project.

One of the big things I've always hated about *NIX was the exponential
search time directories.  I am going to do something about it in Plan9.
I have some Btree routines I wrote in '89 that would work very well here.
They are very simple and allow only search, insert and delete.  No
first, last, next and previous.  An update (rename) would be a delete
followed by an insert.

I see two ways to implement this.  First, change the allocation method
for directores from an "array" to a Btree.  The first direct block
points to the root block of the tree.  The directory blocks then
could have a structure like this:

struct IndexEntry {
  struct DirEntry
  long RightNodeBlockPointer
}

struct IndexBlock {
  struct IndexEntry[number that fills page]
  long LeftNodeBlockPointer
  int number of used entries
}


The other way would be to build an index on the directory entries and
leave the current directory structure alone.  A question is where to
store the blocks for the index?  We could use the first direct block
as above as a pointer to the root of the Btree and leave the other
5 direct, 1 indirect and 1 double-indirect for the directory as usual.
The index block could look like (dir blocks would not change):

struct IndexEntry {
  long DirSlotNumber 
  long RightNodeBlockPointer
}

struct IndexBlock {
  long number of used entries
  long LeftNodeBlockPointer
  struct IndexEntry[number that fills page]
}


I would also like to start a concurrent discussion about the File
Server.  When I first started with Plan9, I thought having two
different kernels was weird.  Now I think the idea is sound since
they have such different roles.  So the next question, do we put the
above functionality into kfs and make the cpu kernel and kfs able
to handle file services efficiently or do we keep the current
File Server?  (If we keep the File Server, we need to add an il
version of a port 23 server to provide access to the console.  In
fact, that is a good idea for the cpu server too.  TCP is missing
in the File Server, as it should.)

Any comments?  :-)

David Butler
gdb@dbSystems.com

>From owner-9fans  Thu Jul 10 18:43:41 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id SAA24196 for 9fans-outgoing; Thu, 10 Jul 1997 18:43:41 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ncube.com ([134.242.5.163]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id SAA24192 for <9fans@cse.psu.edu>; Thu, 10 Jul 1997 18:43:37 -0400 (EDT)
From: beto@ncube.com
Message-Id: <199707102243.SAA24192@cse.psu.edu>
Date: Thu, 10 Jul 97 15:16:39 PDT
To: 9fans@cse.psu.edu
Subject: Re: indexed directories and the File Server
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

In <199707102115.QAA06074@ns.dbSystems.com>
 "G. David Butler"  wrote:

> I would also like to start a concurrent discussion about the File
> Server.  When I first started with Plan9, I thought having two
> different kernels was weird.  Now I think the idea is sound since
> they have such different roles.  

I also like the idea of different kernels, there are so many oportunities
for optimizations. The main problem is how to keep drivers in 
both places in sync. It would be nice if the file server could reuse
drivers from the term/cpu kernel. For example,our bootstrap
program (9b.n3) reuses most of the drivers from 9. The same should be
possible with fs. 

>So the next question, do we put the
> above functionality into kfs and make the cpu kernel and kfs able
> to handle file services efficiently or do we keep the current
> File Server?  (If we keep the File Server, we need to add an il
> version of a port 23 server to provide access to the console.  In
> fact, that is a good idea for the cpu server too.  TCP is missing
> in the File Server, as it should.)
> 
I think the fact that the file system does not talk TCP/23 in on
purpose, you don't want people connection to it in that way.
Have a look to consolefs.

A better replacement for kfs as a local file system is to transform
it into a driver (devnvfs, this name is taken from inferno). I like this
idea because then the same process could copy the data directly
from the cache into user land. I've started doing something like this a 
couple of months ago, but haven't done much since.
  
I need longer lunch breaks :-).



>From owner-9fans  Thu Jul 10 20:03:36 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id UAA25001 for 9fans-outgoing; Thu, 10 Jul 1997 20:03:36 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.bell-labs.com (achille.cs.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id UAA24997 for <9fans@cse.psu.edu>; Thu, 10 Jul 1997 20:03:32 -0400 (EDT)
From: jmk@plan9.bell-labs.com
Message-Id: <199707110003.UAA24997@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Thu, 10 Jul 1997 19:56:05 -0400
Subject: Re: indexed directories and the File Server
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

	It would be nice if the file server could reuse
	drivers from the term/cpu kernel.

After the last filesytem go-round at the beginning of this
year the drivers became very similar to those of the main kernel.
I've actually worked out how to make them the same but it's not
implemented yet. The overall plan would be to make the bootstrap,
Brazil, Inferno and fileserver drivers all the same, currently
only the Brazil and our Inferno drivers are.

Of course, none of this helps you at the moment.

>From owner-9fans  Thu Jul 10 20:47:53 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id UAA25406 for 9fans-outgoing; Thu, 10 Jul 1997 20:47:52 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ncube.com (hundl.ncube.com [134.242.5.163]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id UAA25402 for <9fans@cse.psu.edu>; Thu, 10 Jul 1997 20:47:48 -0400 (EDT)
From: beto@ncube.com
Message-Id: <199707110047.UAA25402@cse.psu.edu>
Date: Thu, 10 Jul 97 17:44:01 PDT
To: 9fans@cse.psu.edu
Subject: Re: indexed directories and the File Server
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

In <199707110003.UAA24997@cse.psu.edu>
 jmk@plan9.bell-labs.com wrote:

> 	It would be nice if the file server could reuse
> 	drivers from the term/cpu kernel.
> 
> After the last filesytem go-round at the beginning of this
> year the drivers became very similar to those of the main kernel.
> I've actually worked out how to make them the same but it's not
> implemented yet. The overall plan would be to make the bootstrap,
> Brazil, Inferno and fileserver drivers all the same, currently
> only the Brazil and our Inferno drivers are.
> 
> Of course, none of this helps you at the moment.
> 
Well it's always cool to know that things are improving.
Who knows one day Brazil could be released.


>From owner-9fans  Fri Jul 11 03:14:08 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id DAA28361 for 9fans-outgoing; Fri, 11 Jul 1997 03:14:08 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from symbionics.co.uk (symsun3.symbionics.co.uk [194.32.100.60]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id DAA28355 for <9fans@cse.psu.edu>; Fri, 11 Jul 1997 03:14:01 -0400 (EDT)
Received: from symnt3.symbionics.co.uk by symbionics.co.uk (4.1/SMI-4.1)
	id AA23130; Fri, 11 Jul 97 08:14:14 BST
Received: by symnt3.symbionics.co.uk with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52)
	id <01BC8DD2.60DB88E0@symnt3.symbionics.co.uk>; Fri, 11 Jul 1997 08:13:56 +0100
Message-Id: 
From: Nigel Roles 
To: "'9fans@cse.psu.edu'" <9fans@cse.psu.edu>
Subject: RE: indexed directories and the File Server
Date: Fri, 11 Jul 1997 08:13:54 +0100
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

Further, making a driver FS/CPU dual compilable is not hard. I didn't do
a very tidy job on the NCR SCSI driver, but it didn't touch much. In
fact, it also compiles for the BeBox which needs to distinguish DMA
space, kernal space, and physical space.

>-----Original Message-----
>From:	jmk@plan9.bell-labs.com [SMTP:jmk@plan9.bell-labs.com]
>Sent:	Friday, July 11, 1997 12:56 AM
>To:	9fans@cse.psu.edu
>Subject:	Re: indexed directories and the File Server
>
>	It would be nice if the file server could reuse
>	drivers from the term/cpu kernel.
>
>After the last filesytem go-round at the beginning of this
>year the drivers became very similar to those of the main kernel.
>I've actually worked out how to make them the same but it's not
>implemented yet. The overall plan would be to make the bootstrap,
>Brazil, Inferno and fileserver drivers all the same, currently
>only the Brazil and our Inferno drivers are.
>
>Of course, none of this helps you at the moment.

>From owner-9fans  Fri Jul 11 09:06:57 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id JAA00253 for 9fans-outgoing; Fri, 11 Jul 1997 09:06:57 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ns.dbSystems.com (root@[204.178.76.1]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id JAA00248 for <9fans@cse.psu.edu>; Fri, 11 Jul 1997 09:06:52 -0400 (EDT)
Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id IAA07712 for 9fans@cse.psu.edu; Fri, 11 Jul 1997 08:04:22 -0500
Date: Fri, 11 Jul 1997 08:04:22 -0500
From: "G. David Butler" 
Message-Id: <199707111304.IAA07712@ns.dbSystems.com>
To: 9fans@cse.psu.edu
Subject: File Server extention for mirrored devices
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

I would like to propose the following extension to fsconfig(8):

{ device... }
  A pseudo-device formed by mirroring corresponding blocks of the
  devices in the list.  The size of the result is the number of
  blocks on the smallest device.

David Butler
gdb@dbSystems.com

>From owner-9fans  Fri Jul 11 22:12:10 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id WAA04349 for 9fans-outgoing; Fri, 11 Jul 1997 22:12:10 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ncube.com (wombat_pc1.ncube.com [134.242.5.64]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id WAA04345 for <9fans@cse.psu.edu>; Fri, 11 Jul 1997 22:12:06 -0400 (EDT)
From: beto@ncube.com
Message-Id: <199707120212.WAA04345@cse.psu.edu>
Date: Fri, 11 Jul 97 19:00:08 PDT
To: 9fans@cse.psu.edu
Subject: Re: File Server extention for mirrored devices
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

In <199707111304.IAA07712@ns.dbSystems.com>
 "G. David Butler"  wrote:

> I would like to propose the following extension to fsconfig(8):
> 
> { device... }
>   A pseudo-device formed by mirroring corresponding blocks of the
>   devices in the list.  The size of the result is the number of
>   blocks on the smallest device.
> 

Well if we are proposing new devices I'll like to have
stripping on the fs, or even raid.  

fs has interleave and concat disks but the
max. performance is limited by one disk. It does not
break a block in pieces and does the IO in parallel.

I don't think it's applicable to the juke box, 
a lot of noise in the machine room :-)





>From owner-9fans  Sat Jul 12 11:01:49 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id LAA07714 for 9fans-outgoing; Sat, 12 Jul 1997 11:01:49 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ns.dbSystems.com (root@[204.178.76.1]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id LAA07710 for <9fans@cse.psu.edu>; Sat, 12 Jul 1997 11:01:42 -0400 (EDT)
Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id JAA09592 for 9fans@cse.psu.edu; Sat, 12 Jul 1997 09:59:03 -0500
Date: Sat, 12 Jul 1997 09:59:03 -0500
From: "G. David Butler" 
Message-Id: <199707121459.JAA09592@ns.dbSystems.com>
To: 9fans@cse.psu.edu
Subject: Re: File Server extention for mirrored devices
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

>From: beto@ncube.com
>
>In <199707111304.IAA07712@ns.dbSystems.com>
> "G. David Butler"  wrote:
>
>> I would like to propose the following extension to fsconfig(8):
>> 
>> { device... }
>>   A pseudo-device formed by mirroring corresponding blocks of the
>>   devices in the list.  The size of the result is the number of
>>   blocks on the smallest device.
>> 

This is RAID 1, no?

>Well if we are proposing new devices I'll like to have
>stripping on the fs, or even raid.  
>
>fs has interleave and concat disks but the
>max. performance is limited by one disk. It does not

Huh?

>break a block in pieces and does the IO in parallel.

No, but it interleaves the blocks across drives thereby
doing the IO in "parallel".

>I don't think it's applicable to the juke box, 
>a lot of noise in the machine room :-)

Why not.  You have two (or more) jukes then you can
inteleave between either platters or entire boxes.

The configuration langauge Ken Thompson has created is an
elegant way of specifing file system layouts.  Since it
has recursive definitions you can have interleave concat
drives or vice versa.

So if you have scsi disks targets 0 and 1 and juke boxes on targets 2 and 3:
(the amount of scsi disk is dependent on how you plan to use the system.)

I wouldn't recommend this!!
	filesys main c[w0.<0-1>][(r0.2.<0-99>r0.3.<0-99>)]
This would be better.
	filesys main [cw0.0r0.2.<0-99>cw0.1r0.3.<0-99>]
More conventional.
	filesys main c[w0.<0-1>](r0.2.<0-99>r0.3.<0-99>)
If you have it, flaunt it!
	filesys main c[w0.<0-1>][r0.2.<0-99>r0.3.<0-99>]

With my proposal you can also have mirrored stripes, or concat mirrors.

filesys main {[w<0-1>][w<2-3>]} mirror of stripe of drives 0,1 and 2,3
filesys main [{w<0-1>}{w<2-3>}] stripe of mirror of drives 0,1 and 2,3

You get the idea.

As far as parity strips (like RAID 5 or 7), I would recommend buying an
external RAID and put it on the filesystem.  I don't like them much
since they can perform very poorly in failure modes.  Mirrors are more
expensive but do not destroy performance.  Also mirrors, as defined
above, can consist of 3 or more members and thus not fail on a two drive
failure.  RAID 5 or 7 can't do that.

Also, I am thinking of implementing the mirror so the reads are
round-robined (is that a word?) across the members for increased
performance.

David Butler
gdb@dbSystems.com

>From owner-9fans  Sat Jul 12 11:57:28 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id LAA08021 for 9fans-outgoing; Sat, 12 Jul 1997 11:57:28 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from mail1.halcyon.com (mail1.halcyon.com [206.63.63.40]) by cse.psu.edu (8.8.5/8.7.3) with ESMTP id LAA08017 for <9fans@cse.psu.edu>; Sat, 12 Jul 1997 11:57:23 -0400 (EDT)
Received: from adagio.halcyon.com (frankg@chinook.halcyon.com [198.137.231.20])
	by mail1.halcyon.com (8.8.5/8.8.5) with SMTP id IAA21606
	for <9fans@cse.psu.edu>; Sat, 12 Jul 1997 08:58:35 -0700 (PDT)
Received: by adagio.halcyon.com with Microsoft Mail
	id <01BC8F20.15C21E60@adagio.halcyon.com>; Sun, 13 Jul 1997 00:02:42 +-100
Message-ID: <01BC8F20.15C21E60@adagio.halcyon.com>
From: Frank Gleason 
To: "'9fans@cse.psu.edu'" <9fans@cse.psu.edu>
Subject: RE: File Server extention for mirrored devices
Date: Sun, 13 Jul 1997 00:02:26 +-100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BC8F20.15C9BF80"
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans


------ =_NextPart_000_01BC8F20.15C9BF80
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit


David, 

I like your idea, and it fits in well with the current syntax.

You may wish to consider closest head not round robin. 
I have measured closest head at 50% greater Kps read 
when compared to round robin.

Frank

----------
From: 	G. David Butler[SMTP:gdb@dbSystems.com]
Sent: 	Saturday, July 12, 1997 3:59 PM
To: 	9fans@cse.psu.edu
Subject: 	Re: File Server extention for mirrored devices

>From: beto@ncube.com
>
>In <199707111304.IAA07712@ns.dbSystems.com>
> "G. David Butler"  wrote:
>
>> I would like to propose the following extension to fsconfig(8):
>> 
>> { device... }
>>   A pseudo-device formed by mirroring corresponding blocks of the
>>   devices in the list.  The size of the result is the number of
>>   blocks on the smallest device.
>> 

This is RAID 1, no?

>Well if we are proposing new devices I'll like to have
>stripping on the fs, or even raid.  
>
>fs has interleave and concat disks but the
>max. performance is limited by one disk. It does not

Huh?

>break a block in pieces and does the IO in parallel.

No, but it interleaves the blocks across drives thereby
doing the IO in "parallel".

>I don't think it's applicable to the juke box, 
>a lot of noise in the machine room :-)

Why not.  You have two (or more) jukes then you can
inteleave between either platters or entire boxes.

The configuration langauge Ken Thompson has created is an
elegant way of specifing file system layouts.  Since it
has recursive definitions you can have interleave concat
drives or vice versa.

So if you have scsi disks targets 0 and 1 and juke boxes on targets 2 and 3:
(the amount of scsi disk is dependent on how you plan to use the system.)

I wouldn't recommend this!!
	filesys main c[w0.<0-1>][(r0.2.<0-99>r0.3.<0-99>)]
This would be better.
	filesys main [cw0.0r0.2.<0-99>cw0.1r0.3.<0-99>]
More conventional.
	filesys main c[w0.<0-1>](r0.2.<0-99>r0.3.<0-99>)
If you have it, flaunt it!
	filesys main c[w0.<0-1>][r0.2.<0-99>r0.3.<0-99>]

With my proposal you can also have mirrored stripes, or concat mirrors.

filesys main {[w<0-1>][w<2-3>]} mirror of stripe of drives 0,1 and 2,3
filesys main [{w<0-1>}{w<2-3>}] stripe of mirror of drives 0,1 and 2,3

You get the idea.

As far as parity strips (like RAID 5 or 7), I would recommend buying an
external RAID and put it on the filesystem.  I don't like them much
since they can perform very poorly in failure modes.  Mirrors are more
expensive but do not destroy performance.  Also mirrors, as defined
above, can consist of 3 or more members and thus not fail on a two drive
failure.  RAID 5 or 7 can't do that.

Also, I am thinking of implementing the mirror so the reads are
round-robined (is that a word?) across the members for increased
performance.

David Butler
gdb@dbSystems.com



------ =_NextPart_000_01BC8F20.15C9BF80
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IioXAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBJAG
ABABAAABAAAADAAAAAMAADADAAAACwAPDgAAAAACAf8PAQAAAEEAAAAAAAAAgSsfpL6jEBmdbgDd
AQ9UAgAAAAA5ZmFuc0Bjc2UucHN1LmVkdQBTTVRQADlmYW5zQGNzZS5wc3UuZWR1AAAAAB4AAjAB
AAAABQAAAFNNVFAAAAAAHgADMAEAAAASAAAAOWZhbnNAY3NlLnBzdS5lZHUAAAADABUMAQAAAAMA
/g8GAAAAHgABMAEAAAAUAAAAJzlmYW5zQGNzZS5wc3UuZWR1JwACAQswAQAAABcAAABTTVRQOjlG
QU5TQENTRS5QU1UuRURVAAADAAA5AAAAAAsAQDoBAAAAAgH2DwEAAAAEAAAAAAAAA8AtAQiABwAY
AAAASVBNLk1pY3Jvc29mdCBNYWlsLk5vdGUAMQgBBIABAC8AAABSRTogRmlsZSBTZXJ2ZXIgZXh0
ZW50aW9uIGZvciBtaXJyb3JlZCBkZXZpY2VzAPQQAQWAAwAOAAAAzQcHAA0AAAACABoAAAAEAQEg
gAMADgAAAM0HBwAMABcANAA6AAYAcgEBCYABACEAAAAyQ0I0MDk1QzExRkJEMDExQjE3NzQ0NDU1
MzU0MDAwMADPBgEDkAYAhAkAABIAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAEAA
OQDAkmaqF4+8AR4AcAABAAAALwAAAFJFOiBGaWxlIFNlcnZlciBleHRlbnRpb24gZm9yIG1pcnJv
cmVkIGRldmljZXMAAAIBcQABAAAAFgAAAAG8jxeqZlwJtC37ERHQsXdERVNUAAAAAB4AHgwBAAAA
BQAAAFNNVFAAAAAAHgAfDAEAAAATAAAAZnJhbmtnQGhhbGN5b24uY29tAAADAAYQ2nr+5wMABxBY
CAAAHgAIEAEAAABlAAAAREFWSUQsSUxJS0VZT1VSSURFQSxBTkRJVEZJVFNJTldFTExXSVRIVEhF
Q1VSUkVOVFNZTlRBWFlPVU1BWVdJU0hUT0NPTlNJREVSQ0xPU0VTVEhFQUROT1RST1VORFJPQklO
SQAAAAACAQkQAQAAAPQHAADwBwAARQ8AAExaRnUJ5zeC/wAKAQ8CFQKoBesCgwBQAvIJAgBjaArA
c2V0MjcGAAbDAoMyA8UCAHByQnER4nN0ZW0CgzN3AuQHEwKAfQqACM8J2TvxFg8yNTUCgAqBDbEL
YOBuZzEwMxRQCwoUURUL8mMAQCAKhURhdhhpZCwa5gqFSSBsoGlrZSB5CGEgG5BsZWEbsABwZB1g
BUBmhx4QBCALgCB3ZWwDILED8HRoIB8wHQBjCHAjFhACMCBzeQIwYXiqLhvcWQhgIADAeR8B+nMf
QW8fkAIgAJAEgR+QVxWgEbATwCAfcGEd8G62bwVAA2B1HeEDYGILgDYuHDgRgHYdAAeAYXMXCHAJ
gCL8YQVANTAlziAJwScgItFLcAQgJ6G7HfAKhXcfcAOgBaBtCrFPJiEiQSQaG9xGcgBwa0cb3Ar0
HNAxODAC0WnwLTE0NA3wDNAt8wtZXDE2CqADYBPQYwVALX8wFwqHLssMMC+WK8ADcDpnMR4vlgyC
IEckwBtjIBBCdXRsBJBbU02AVFA6Z2RiQDYw6ROkcy4pYV0wvzHNBmCvAjAy/zQLBhB0CHBkIcCR
G7BKdWwh0DEyG7AAMTk5NyAzOjUwOSBQTTdPMc1Ub5M5jzQLOWYAcUBjEbDSLiggdS4JgHU9Xzhe
OHViai/RP380C1JlfUTQRgMQHQAGYSWQBcBldngT0AIwaQIgHjAFsW2+aR/ABbAmIQ2wG4BjB5Bz
LB8tIzM2LpcaRS+WPsUytGIRwG9Abh+gTQCrNvIKhT5N5kkDoDw8kggwNzFPgDMwNC7YSUFBT2BP
cDJNQDbg0zZrTlcgIjTdIk8ANi91UgB3L6I6Te5SABywd70IYGwd8BzTIkEvkXAjIfcfUwIQHuBv
A/AZEEekAJAfSCEiQQThAiAeQGcoOE4pVNdSAFVoXHtJFS7fW8ADMBiCVZVcsEFW8BGw8HVkby1J
JEhCB4Ad8L5iIdBIlFgiBaEWEHNXMEcd4FgiAmBvY2sEIG/+Zh9SXCpJJR6CH2Ic0BPA7yTAP0Af
cQCQeh0AYHQoQZ0l8GwFQAQAH1NudQbQ3yLRYHBcKmAGYiRzAMAe4H8jQltlWf8KhWLwZGFkYVK4
QUlEPEAbsCPQPxvc/D5XHtIGkB6xHcAWEFb1zVgibgfRYZZJJx7hVobvJXJN5hPABRFwWCJmlQPQ
/xuwBbFJMCkxK9AbkGLBTe7/A9AlYR5yJ9E1kCWCHdIicdZjJyFfsHNgQWI1cGCa/wDAIHBW8ASQ
XeIAcF2xZGH/HNBIkBPQXjMCIB0AdJIkwDpJZ3FvB5Ej0RvcSHXqaGquYiehax3AX/Qegj9v0AWQ
B5Ed0nijH2JJT5d8AwrAZyJsII1Obxuw/3TyHhFzOGR0YAUA0ANgBBH+ZAUQgIUWEF5QCoVdQFgi
dX1IIn3mIiCNTtB4kW7OJ3USC4B78XQnfJFvwJ8c0HRQAmBWsx9ianUc8fUG4Hgbtz57kBWgBUBg
cX8j0AQAdtFiJADBhmFj0W8hA3AgOi0pG9xXaF8h0CPRYsEhciVzdFYgIPYoSGJI0SmIE2RzA6Ad
If8fkABwCoVzMnOETQEewCkx/mUfISLRC1ECQASQYFFHkf9H8WxhiHEHkCCNYvJZVAhwRycgSBIY
8mF1Zx0AS/cpMWLwKXFzSCFy8gUAJ7K/HfF8kgqFkFGVcB/xdyHB/2BxX3AFkAaQWCIeQEcRICDf
E8KVMR0hHmBiwVMLgHbC/3kWcvIWEB+hAJAlkQ2xC4D/HhBIEQQgj0UlZHM5dCSCxk+B9AWxXZNH
cXNhII1T/yJQa/GPQiVzBPAAkHSFAZD2cpWgHmEwHcMa0B3SiCZ/oDJY4aPVEeAd0jzgCoUo/R9i
YQRgJDCJg6MXZFINsP92MB3gH+KWclgAjzMLUVjj9nVXVZoELoudVgWGEpxBjwNwB4Ad4YZRcyEh
CoYfNJKZspoBIaEekWNbdxAwLjwwLeA+XVu0KHKwMDKwQjygPrDR+jOxFSk3NmmDViRNAEzyRyfR
IIau7yBbY7AhMNuw2bWyMbGJNzZNSNEiYv9xEUgCB0C0D69/sIGwz7HV/xxGomkeEBuwGOGn0h4Q
rm+/ul+wgruvt2uMFh8ibSHQ/1cEB0CdlwdAlmAlZUimb4P/B5Bws3QlSJSTLr/rWzCwEOOwVcoQ
Mi0zsJBcAEiFz5jTxpNgYoHlMCykpDxg/jPIr7VyWzDKFFwAzuLKsv1cAF3Lycs4zH/NhiEJo/H3
H1MdciCNQQQgQWAFwHMB3wqxHhAh0G+DBCAoHNNqA/I1cMI3KRuwVgateHTw/nlYIpeYR8EEoMSh
agMd0v5wf6RwJr/0q5JcsIXWVoTzH3CLUG11EXAKhWzhXbH/H2Eh0J3idjWg0sQhizBzcP8h0B6R
QWADECYBjiENsJrS/k3HxGxDjjLZ56kxnJN08u9dQCPD4fFvkG/EIXZIYsH+QcVix7UdsajymWEJ
gAqF/QGgbyWQG7Cd4iJzI1Fgcf4zcMKOMiWxZPJ8lB8wquD/I8PhUmaCe5CNsoHjzZbhZP9iwddZ
j3KGIeShHzAnINSO/8Vh2BKnoIZEb+NggAdwC1D/E+BH4oNlyzXFcWO0I6Dis9sKhSQTLSRzJiEo
ZGMnIfd7kFYgCyA/jnCBdYpj6nX/SFKbISehEbDn5uWaG9w1Cv8KhVNfG9xKD0sfL6UKhRUxAgAB
QAMAEBAAAAAAAwAREAAAAABAAAcwYC3aVxaPvAFAAAgwYC3aVxaPvAEeAD0AAQAAAAUAAABSRTog
AAAAADxb

------ =_NextPart_000_01BC8F20.15C9BF80--


>From owner-9fans  Sun Jul 13 01:39:43 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id BAA13042 for 9fans-outgoing; Sun, 13 Jul 1997 01:39:43 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from alpha.brainerd.net (alpha.brainerd.net [206.10.20.2]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id BAA13038 for <9fans@cse.psu.edu>; Sun, 13 Jul 1997 01:39:38 -0400 (EDT)
From: bonghits@thepres.com
Received: from ip161.providence.ri.pub-ip.psi.net by alpha.brainerd.net; (5.65v3.2/1.1.8.2/18Jan96-0309PM)
	id AA23493; Sun, 13 Jul 1997 00:31:30 -0500
Message-Id: <9707130531.AA23493@alpha.brainerd.net>
To: bonghits@thepres.com
Date: Sun, 13 Jul 97 01:30:49 EST
Subject: Presidential Joke, as seen on The Tonight Show with Jay Leno!
Reply-To: bonghits@thepres.com
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

You've seen or heard the commercial, "Hooked on Phonics, it 
worked for me, ABCDEFG" right?

Well, check out this Award-Winning Presidential T-Shirt, VOTED 
the Funniest Presidential T-Shirt of ALL TIME!

It has a Big Full-Color graphic on the back of The President 
in a Tux, playing his Saxaphone, with musical notes Flying 
out of it.  

But what's that I see?!?  No way!!!  There are big Smoke Rings 
Flying out of his Sax! ...and The President is saying,

                 HOOKED ON BONG HITS
                  IT WORKED FOR ME!

The exclamation point is actually a Burning Joint!

On the front of the T-Shirt is a small chest print with 
children's blocks colored in Every Color of the Rainbow, 
just like the ABCDEFG blocks in the commercial... only they 
say "THCYA", as in THC 'YA or SEE 'YA LATER!  

Underneath the blocks are the words "INHALE TO THE CHIEF" 
hovering atop another Joint! 

The Hooked On Bong Hits T-Shirt was hand silk-screened in the 
U.S.A. on the finest quality Fruit of the Loom(tm) 100% Cotton 
Heavy-Weight Tee and was previously available at Woodstock '94, 
Grateful Dead shows, Newbury Comics and numerous Smoke, Joke, 
and T-Shirt shops across the United States for $24.95 + local 
sales tax, but they sold ALL they had left!  

You can't find these One of a KIND T-Shirts in stores anymore.  
Now, for a limited time only, you can buy ONE Factory Direct 
for $15.95 or TWO for ONLY $24.95!  Sorry, but due to the HIGH 
demand for these T-Shirts, your order is limited to only TWO, 
so you MUST respond NOW, BEFORE supplies run out!  

Don't miss out on this FINAL Opportunity to own the hottest 
selling T-Shirt in history!  It's the perfect gift for mom or 
dad, brother or sister, a friend, your political enemy, your 
neighbor, your co-worker, your boyfriend or girlfriend (the 
XLarge makes a great Night Shirt).  Send one to your Mayor, 
Rush Limbaugh, Bob Dole or the President HIMSELF!  Take a 
picture of his facial expression when he sees it and send 
it to us or Jay Leno!  We'll put it up on the web for FREE!

Don't wait 'til it's TOO LATE!  Simply print the following 
order coupon, fill it out, and send it with your check or 
money order.  Please make Cashiers Check, Money Order, or 
Personal Check in US dollars payable to: 
E-Associates, Inc. and send to:


E-Associates, Inc.
306 Thayer St., Dept. 129
Providence, RI 02906
USA

--------------------------------------------------------------

E-mail Address_____________________________________________

Name_______________________________________________________

Address____________________________________________________

Address____________________________________________________

Phone #____________________(in case address is illegible, not required)

$_______  Please send ONE Hooked On Bong Hits T-Shirt for only  $15.95 ___
$_______  Please send TWO Hooked On Bong Hits T-Shirts for ONLY $24.95 ___
$_3.95__   Shipping & Handling (yes, it's the same for TWO!)
$_______  Subbtotal
$_______  Sales Tax (RI residents 7.00%)
$_______  Order total US$

T-Shirt Size Preference:

____S  ____M  ____L  ____XL
--------------------------------------------------------------

Please allow 1-2 weeks for delivery when paying by Cashiers Check or 
Money Order.  Please allow 2-3 weeks for delivery when paying by Personal 
Check.

The Tonight Show with Jay Leno is a Trademark of Jay Leno Productions.

>From owner-9fans  Sun Jul 13 10:51:30 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id KAA16242 for 9fans-outgoing; Sun, 13 Jul 1997 10:51:30 -0400 (EDT)
Received: from foible.proxima.alt.za (foible.proxima.alt.za [192.96.32.132]) by cse.psu.edu (8.8.5/8.7.3) with ESMTP id KAA16238 for <9fans@cse.psu.edu>; Sun, 13 Jul 1997 10:51:19 -0400 (EDT)
Received: from localhost.proxima.alt.za (localhost.proxima.alt.za [127.0.0.1]) by foible.proxima.alt.za (8.8.6/8.8.2) with SMTP id QAA00776 for 9fans@cse.psu.edu; Sun, 13 Jul 1997 16:55:25 +0200 (SAT)
Message-Id: <199707131455.QAA00776@foible.proxima.alt.za>
X-Authentication-Warning: foible.proxima.alt.za: localhost.proxima.alt.za [127.0.0.1] didn't use HELO protocol
X-Mailer: exmh version 2.0gamma 1/27/96
To: 9fans@cse.psu.edu
Subject: SCSI woes.
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 13 Jul 1997 16:55:24 +0200
From: Lucio de Re 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans


The Plug-and-Play (disabled) AHA1542CP adapter and Seagate ST12400N 
drive combination that I have allocated to my future Plan 9 file server 
causes PCFS to return zero heads and zero cylinders, the number of 
sectors and bytes per track (3145968 (0x3000f0) and 1610735616, 
respectively) also seem unreasonable:

hd0: 0 cylinders 0 heads 3145968 sectors/track 1610735616 bytes

This is then followed by, perhaps understandably:

adaptec0: invdcmd #01, len 5
scsiwait timed out
adaptec0: invdcmd #02, len 1

in various groupings; "can't read partition block" seems to be the 
eventual prognosis.  I do get some

scsi?: cap 1, sec 0

messages as well, where the question mark above has been 0, 1, 2, 3 and 
4 so far.

I'm going to rebuild PCFS with some additional debugging to see if I 
can remedy the situation and get the file server running.  As I know 
frightfully little about SCSI, any suggestions, recommendations and 
labour/headache saving advice will be greatly appreciated.

Ha!  PCFS gave up after "scsi6: cap 1, sec 0" although I'm not 
convinced that a register dump following "exception/interrupt 0" is 
going to simplify my efforts much :-)
-- 
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.



>From owner-9fans  Sun Jul 13 11:15:36 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id LAA16534 for 9fans-outgoing; Sun, 13 Jul 1997 11:15:36 -0400 (EDT)
Received: from foible.proxima.alt.za (foible.proxima.alt.za [192.96.32.132]) by cse.psu.edu (8.8.5/8.7.3) with ESMTP id LAA16530 for <9fans@cse.psu.edu>; Sun, 13 Jul 1997 11:15:27 -0400 (EDT)
Received: from localhost.proxima.alt.za (localhost.proxima.alt.za [127.0.0.1]) by foible.proxima.alt.za (8.8.6/8.8.2) with SMTP id RAA00815 for 9fans@cse.psu.edu; Sun, 13 Jul 1997 17:19:45 +0200 (SAT)
Message-Id: <199707131519.RAA00815@foible.proxima.alt.za>
X-Authentication-Warning: foible.proxima.alt.za: localhost.proxima.alt.za [127.0.0.1] didn't use HELO protocol
X-Mailer: exmh version 2.0gamma 1/27/96
To: 9fans@cse.psu.edu
Subject: SCSI woes - correction
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 13 Jul 1997 17:19:45 +0200
From: Lucio de Re 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

Hm, looking at the actual code, it seems that "b.com" is the one that 
does not cope with the AHA1542CP/ST12400 combination.  Presumably, 
though, whatever needs changing in b.com will also occur in other 
places.

Let me dig a little deeper, I also have to convince b.com to cope with 
the many C-Net NE2000 (almost) adaptors I adopted in a moment of 
exuberance.

-- 
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.



>From owner-9fans  Sun Jul 13 11:28:49 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id LAA16718 for 9fans-outgoing; Sun, 13 Jul 1997 11:28:47 -0400 (EDT)
Received: from foible.proxima.alt.za (foible.proxima.alt.za [192.96.32.132]) by cse.psu.edu (8.8.5/8.7.3) with ESMTP id LAA16714 for <9fans@cse.psu.edu>; Sun, 13 Jul 1997 11:28:28 -0400 (EDT)
Received: from localhost.proxima.alt.za (localhost.proxima.alt.za [127.0.0.1]) by foible.proxima.alt.za (8.8.6/8.8.2) with SMTP id RAA00841 for 9fans@cse.psu.edu; Sun, 13 Jul 1997 17:32:46 +0200 (SAT)
Message-Id: <199707131532.RAA00841@foible.proxima.alt.za>
X-Authentication-Warning: foible.proxima.alt.za: localhost.proxima.alt.za [127.0.0.1] didn't use HELO protocol
X-Mailer: exmh version 2.0gamma 1/27/96
To: 9fans@cse.psu.edu
Subject: SCSI woes - one more correction.
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 13 Jul 1997 17:32:45 +0200
From: Lucio de Re 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

The hd0 parameters seem to have belonged to the IDE disk I neglected to 
configure out of the way.  I still get adaptec invalid commands, but 
now there isn't an hd0 with no cylinders or heads.

Hm.  Better find out what we're asking the AHA to do...

-- 
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.



>From owner-9fans  Sun Jul 13 17:11:56 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id RAA18934 for 9fans-outgoing; Sun, 13 Jul 1997 17:11:56 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.bell-labs.com (achille.cs.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id RAA18930 for <9fans@cse.psu.edu>; Sun, 13 Jul 1997 17:11:52 -0400 (EDT)
From: geoff@plan9.bell-labs.com
Message-Id: <199707132111.RAA18930@cse.psu.edu>
Date: Sun, 13 Jul 1997 17:12:08 -0400
To: 9fans@cse.psu.edu
Subject: SCSI woes.
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

I have used the AHA1542CP in several machines; I think I've used it
with the Seagate ST12400N and on another occasion with bigger disks
and 9pcfs.  I don't think I've ever seen your symptoms.  You've got
the 1542 i/o port base set to 0x330, the drive's SCSI id set to 0, and
the bus is terminated correctly (if you've only a single SCSI device,
it should have termination enabled internally or have a SCSI
terminator attached)?  b.com will only look at 0x330 for a SCSI host
adapter.  Have you configured the adapter with Adaptec's `SCSISelect'
program, accessible at boot time with control-a?  SCSISelect should
also be able to probe the disk a little, as a sanity check.

Disabling plug-and-play also disables the 1542CP's BIOS (because it
then effectively becomes a 1542CF but the BIOS is for the 1542CP and
the versions don't match), which I don't believe is needed if you only
run Plan 9.

An unrelated potential problem is that the 1542 has a built-in floppy
controller that may need to be disabled (switch 5) if your system
already has one.

The SEE ALSO section of scuzz(8) is a good place to find out where to
learn more about SCSI; there's also a newer book called something like
`The SCSI and IDE Standards' that's quite good.  A quick introduction,
geared to FreeBSD, can be found through
`http://www.freebsd.org/handbook/handbook.html' (it's
`http://www.freebsd.org/handbook/handbook127.html' today, but they
keep renumbering it).

>From owner-9fans  Mon Jul 14 02:39:26 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id CAA22211 for 9fans-outgoing; Mon, 14 Jul 1997 02:39:26 -0400 (EDT)
Received: from foible.proxima.alt.za (foible.proxima.alt.za [192.96.32.132]) by cse.psu.edu (8.8.5/8.7.3) with ESMTP id CAA22207 for <9fans@cse.psu.edu>; Mon, 14 Jul 1997 02:39:18 -0400 (EDT)
Received: from localhost.proxima.alt.za (localhost.proxima.alt.za [127.0.0.1]) by foible.proxima.alt.za (8.8.6/8.8.2) with SMTP id IAA03937 for 9fans@cse.psu.edu; Mon, 14 Jul 1997 08:43:45 +0200 (SAT)
Message-Id: <199707140643.IAA03937@foible.proxima.alt.za>
X-Authentication-Warning: foible.proxima.alt.za: localhost.proxima.alt.za [127.0.0.1] didn't use HELO protocol
X-Mailer: exmh version 2.0gamma 1/27/96
To: 9fans@cse.psu.edu
Subject: Re: SCSI woes. 
In-reply-to: Message from geoff@plan9.bell-labs.com 
 of "Sun, 13 Jul 1997 17:12:08 -0400." <199707132111.RAA18930@cse.psu.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 14 Jul 1997 08:43:44 +0200
From: Lucio de Re 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

Geoff (does anyone at Bell Labs have names? I'm still racking my brain 
as to who jmk is, I'm sure I *ought* to know :-)

I'm using your mail as a checklist, please feel free to give me hell if 
this is annoying:

> I have used the AHA1542CP in several machines; I think I've used it
> with the Seagate ST12400N and on another occasion with bigger disks
> and 9pcfs.  I don't think I've ever seen your symptoms.  You've got
> the 1542 i/o port base set to 0x330, the drive's SCSI id set to 0, and
> the bus is terminated correctly (if you've only a single SCSI device,
> it should have termination enabled internally or have a SCSI
> terminator attached)?

I'm not sure about the termination.  The drive seems to operate 
correctly under (shudder) WinNT, and I've set the termination jumper(s) 
so that the drive provides termination power, has termination on and 
parity enabled.  I find the controller can be very forgiving, but not 
reliably so, alternative jumper configurations will be gratefully 
accepted.

> ... b.com will only look at 0x330 for a SCSI host
> adapter.  Have you configured the adapter with Adaptec's `SCSISelect'
> program, accessible at boot time with control-a?  SCSISelect should
> also be able to probe the disk a little, as a sanity check.
> 
The disk, as I mentioned, behaves fine.  PnP sets the adapter's IRQ to 
10 because of a PCI ethernet card (I'll hopefully get to the ethernet 
too, eventually), which is why I disable PnP.  This results in the 
default AHA configuration applying, although naturally I have reason to 
be concerned about PnP doing evil things with IRQ 11 itself.  I removed 
the Ether card to no noticeable improvement, perhaps reserving IRQ 11 
for an ISA legacy card will make a difference, I had not considered 
that possibility.  Nopes, still get "adaptec0: invdcmd #01, len 5", etc.

> Disabling plug-and-play also disables the 1542CP's BIOS (because it
> then effectively becomes a 1542CF but the BIOS is for the 1542CP and
> the versions don't match), which I don't believe is needed if you only
> run Plan 9.
> 
Ouch!  How, then, do I convince PnP to leave the AHA's default settings 
unchanged (I see it returns IRQ 10 and DMA 7, then again, b.com does 
ask the controller, whose I/O address certainly doesn't change :-(

> An unrelated potential problem is that the 1542 has a built-in floppy
> controller that may need to be disabled (switch 5) if your system
> already has one.
> 
Nopes, taken care of that.

> The SEE ALSO section of scuzz(8) is a good place to find out where to
> learn more about SCSI; there's also a newer book called something like
> `The SCSI and IDE Standards' that's quite good.  A quick introduction,
> geared to FreeBSD, can be found through
> `http://www.freebsd.org/handbook/handbook.html' (it's
> `http://www.freebsd.org/handbook/handbook127.html' today, but they
> keep renumbering it).

Seems to have lingered in the same spot long enough for me to catch it 
:-)
I'll now read through it and see if I can discover where I'm going 
wrong.

I can certainly not find any explanation for the invalid command 
report.  As I read it, what's happening is that the POLL command issuer 
is feeding dud data to the controller, or somesuch.  I'll make sure I 
have the most recent version of b.com on the boot floppy (I'm sure it 
currently has the CD-ROM version) and, additionally or alternatively, 
will hack at the sources to produce a copy that will help me diagnose 
the problem.

Thanks for your encouragement.
-- 
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.



>From owner-9fans  Mon Jul 14 09:23:07 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id JAA24573 for 9fans-outgoing; Mon, 14 Jul 1997 09:23:07 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.bell-labs.com (achille.cs.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id JAA24569 for <9fans@cse.psu.edu>; Mon, 14 Jul 1997 09:23:03 -0400 (EDT)
From: jmk@plan9.bell-labs.com
Message-Id: <199707141323.JAA24569@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Mon, 14 Jul 1997 09:17:33 -0400
Subject: Re: SCSI woes. 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

if you look in the driver (kernel or b.com) as to which command "adaptec0: invdcmd #01, len 5"
refers to (Cmbinit = 0x01), the following comment in the reset routine may give
a clue
	/*
	 * If the BIOS is enabled on the 1542C/CF and BIOS options for support of drives
	 * > 1Gb, dynamic scanning of the SCSI bus or more than 2 drives under DOS 5.0 are
	 * enabled, the BIOS disables accepting Cmbinit to protect against running with
	 * drivers which don't support those options. In order to unlock the interface
	 * it is necessary to read a lock-code using Cextbios and write it back using
	 * Cmbienable; the lock-code is non-zero.
	 */

i think this was an addition after the cd-rom was cut.

--jim

>From owner-9fans  Mon Jul 14 12:49:54 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id MAA03280 for 9fans-outgoing; Mon, 14 Jul 1997 12:49:53 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.bell-labs.com (achille.cs.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id MAA03275 for <9fans@cse.psu.edu>; Mon, 14 Jul 1997 12:49:50 -0400 (EDT)
From: presotto@plan9.bell-labs.com
Message-Id: <199707141649.MAA03275@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Mon, 14 Jul 1997 12:49:23 -0400
Subject: Re: SCSI woes. 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans


> Geoff (does anyone at Bell Labs have names? I'm still racking my brain 
> as to who jmk is, I'm sure I *ought* to know :-)

No, we are a society of nameless faceless individuals.
		#6

>From owner-9fans  Mon Jul 14 12:57:19 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id MAA03485 for 9fans-outgoing; Mon, 14 Jul 1997 12:57:19 -0400 (EDT)
Received: from foible.proxima.alt.za (foible.proxima.alt.za [192.96.32.132]) by cse.psu.edu (8.8.5/8.7.3) with ESMTP id MAA03480 for <9fans@cse.psu.edu>; Mon, 14 Jul 1997 12:57:13 -0400 (EDT)
Received: from localhost.proxima.alt.za (localhost.proxima.alt.za [127.0.0.1]) by foible.proxima.alt.za (8.8.6/8.8.2) with SMTP id TAA05457 for 9fans@cse.psu.edu; Mon, 14 Jul 1997 19:01:44 +0200 (SAT)
Message-Id: <199707141701.TAA05457@foible.proxima.alt.za>
X-Authentication-Warning: foible.proxima.alt.za: localhost.proxima.alt.za [127.0.0.1] didn't use HELO protocol
X-Mailer: exmh version 2.0gamma 1/27/96
To: 9fans@cse.psu.edu
Subject: Anonimity (Was: SCSI woes.)
In-reply-to: Message from presotto@plan9.bell-labs.com 
 of "Mon, 14 Jul 1997 12:49:23 -0400." <199707141649.MAA03275@cse.psu.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 14 Jul 1997 19:01:43 +0200
From: Lucio de Re 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

> 
> > Geoff (does anyone at Bell Labs have names? I'm still racking my brain 
> > as to who jmk is, I'm sure I *ought* to know :-)
> 
> No, we are a society of nameless faceless individuals.
> 		#6

Nopes, my Plan 9 CD-ROM claims to have pictures of you all.  Nary a name
in sight though :-)

-- 
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.



>From owner-9fans  Mon Jul 14 13:05:17 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id NAA03745 for 9fans-outgoing; Mon, 14 Jul 1997 13:05:17 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id NAA03738 for <9fans@cse.psu.edu>; Mon, 14 Jul 1997 13:05:11 -0400 (EDT)
Received: from reynaldo.parc.xerox.com ([13.2.116.96]) by alpha.xerox.com with SMTP id <52828(10)>; Mon, 14 Jul 1997 10:04:33 PDT
Received: from localhost by reynaldo.parc.xerox.com with SMTP id <304514>; Mon, 14 Jul 1997 10:04:18 PDT
X-Mailer: exmh version 2.0gamma 1/27/96
To: 9fans@cse.psu.edu
cc: kerch@parc.xerox.com
Subject: Re: SCSI woes. 
In-reply-to: Your message of "Mon, 14 Jul 97 09:49:23 PDT."
             <199707141649.MAA03275@cse.psu.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 14 Jul 1997 10:04:18 PDT
From: Berry Kercheval 
Message-Id: <97Jul14.100418pdt."304514"@reynaldo.parc.xerox.com>
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

>>>presotto@plan9.bell-labs.com said:
 > > Geoff (does anyone at Bell Labs have names? I'm still racking my brain 
 > > as to who jmk is, I'm sure I *ought* to know :-)
 > 
 > No, we are a society of nameless faceless individuals.
 > 		#6

I am not a number!  I am a free variable!

  --berry



>From owner-9fans  Mon Jul 14 13:16:31 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id NAA04079 for 9fans-outgoing; Mon, 14 Jul 1997 13:16:31 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.bell-labs.com (achille.cs.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id NAA04075 for <9fans@cse.psu.edu>; Mon, 14 Jul 1997 13:16:27 -0400 (EDT)
From: geoff@plan9.bell-labs.com
Message-Id: <199707141716.NAA04075@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Mon, 14 Jul 1997 13:16:45 -0400
Subject: Re: SCSI woes. 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

i saw the `If the BIOS is enabled' comment, but he said
he'd disabled p'n'p, which disables the bios in the 1542cp.

>From owner-9fans  Mon Jul 14 16:44:30 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id QAA03840 for 9fans-outgoing; Mon, 14 Jul 1997 16:44:30 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.cs.su.oz.au (lore.plan9.cs.su.oz.au [129.78.96.2]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id QAA03836 for <9fans@cse.psu.edu>; Mon, 14 Jul 1997 16:44:25 -0400 (EDT)
To: 9fans@cse.psu.edu
Subject: [9fans] Re: SCSI woes. 
From: David Hogan 
Date: Tue, 15 Jul 1997 06:42:09 +1000
In-Reply-To: <199707141649.MAA03275@cse.psu.edu>
Message-ID: <199707150642.49708.out.bakef@plan9.cs.su.oz.au>
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

> > Geoff (does anyone at Bell Labs have names? I'm still racking my brain 
> > as to who jmk is, I'm sure I *ought* to know :-)

> No, we are a society of nameless faceless individuals.
> 		#6

Who is #1?

>From owner-9fans  Mon Jul 14 22:24:45 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id WAA06994 for 9fans-outgoing; Mon, 14 Jul 1997 22:24:44 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from finch.cse.psu.edu (qmailr@finch.cse.psu.edu [130.203.12.29]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id WAA06990 for <9fans@cse.psu.edu>; Mon, 14 Jul 1997 22:24:41 -0400 (EDT)
Received: (qmail 9502 invoked by uid 991); 15 Jul 1997 02:24:40 -0000
Message-ID: <19970715022440.9500.qmail@finch.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: [9fans] Re: SCSI woes. 
In-reply-to: Your message of "Mon, 14 Jul 1997 10:04:18 PDT."
             <97Jul14.100418pdt."304514"@reynaldo.parc.xerox.com> 
Date: Mon, 14 Jul 1997 22:24:40 EDT
From: Scott Schwartz 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

Berry Kercheval  writes:
| >>>presotto@plan9.bell-labs.com said:
|  > > Geoff (does anyone at Bell Labs have names? I'm still racking my brain 
|  > > as to who jmk is, I'm sure I *ought* to know :-)
|  >  
|  > No, we are a society of nameless faceless individuals.
|  > 		#6
| 
| I am not a number!  I am a free variable!

"This is Information Retrieval, not Information Dissemination!"
  -- Michael Palin, in Brazil

>From owner-9fans  Mon Jul 14 23:34:52 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id XAA07834 for 9fans-outgoing; Mon, 14 Jul 1997 23:34:51 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ns.dbSystems.com (root@[204.178.76.1]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id XAA07830 for <9fans@cse.psu.edu>; Mon, 14 Jul 1997 23:34:46 -0400 (EDT)
Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id WAA13533 for 9fans@cse.psu.edu; Mon, 14 Jul 1997 22:31:46 -0500
Date: Mon, 14 Jul 1997 22:31:46 -0500
From: "G. David Butler" 
Message-Id: <199707150331.WAA13533@ns.dbSystems.com>
To: 9fans@cse.psu.edu
Subject: [9fans] Re: File Server extention for mirrored devices
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

>I would like to propose the following extension to fsconfig(8):
>
>{ device... }
>  A pseudo-device formed by mirroring corresponding blocks of the
>  devices in the list.  The size of the result is the number of
>  blocks on the smallest device.

This has been done.  Because of the available functionality, the
mirror is N-way.  The performance is the same as a single device
by itself (no round-robin on the reads nor sync-writes necessary
for a volume version number.)  If you need performance, use striping.
If you want both performance and safety, mirror a stripe.

Write errors take a member off line.  Read errors cause the read
from the good member to re-write the bad (for bit rot and block
remap.)  Version numbers are used to determine if partners of a
mirror are in sync at boot time.  If not, the out of sync members
are recovered from the good ones while the system is running.
If the system crashed, just reboot and run check like normal.  The
mirror system will do the right thing.

If a drive is replaced (after power-off) and the system is restarted,
the mirror system detects the new device, and after making sure it
is at least as large as the mirror, brings it into service and starts
recovery.

The device also handles the writing of the config block at any time.
This is good place to save the config block even if you don't use
mirroring for anything else.

This functioality is available in Plan9, not Brazil.  :->

David Butler
gdb@dbSystems.com

>From owner-9fans  Tue Jul 15 00:01:15 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id AAA08198 for 9fans-outgoing; Tue, 15 Jul 1997 00:01:15 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from tor.securecomputing.com (tor.securecomputing.com [199.71.190.98]) by cse.psu.edu (8.8.5/8.7.3) with ESMTP id AAA08194 for <9fans@cse.psu.edu>; Tue, 15 Jul 1997 00:01:11 -0400 (EDT)
Received: by janus.tor.securecomputing.com id <11649>; Mon, 14 Jul 1997 23:55:29 -0400
Date: Tue, 15 Jul 1997 00:01:03 -0400
From: steve@tor.securecomputing.com (Steve Kotsopoulos)
Message-Id: <97Jul14.235529edt.11649@janus.tor.securecomputing.com>
To: <9fans@cse.psu.edu>
Subject: [9fans] [reminder] pointer to Plan 9 FAQ
Content-Type: text
Apparently-To: 9fans@cse.psu.edu
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

The Plan 9 faq is posted to comp.os.plan9 at the beginning of each month.
It is also at news.answers archive sites, look for comp-os/plan9-faq

The hypertext version of the faq is always available at url
http://www.ecf.toronto.edu/plan9/plan9faq.html


>From owner-9fans  Tue Jul 15 11:52:17 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id LAA14971 for 9fans-outgoing; Tue, 15 Jul 1997 11:52:16 -0400 (EDT)
Received: from foible.proxima.alt.za (foible.proxima.alt.za [192.96.32.132]) by cse.psu.edu (8.8.5/8.7.3) with ESMTP id LAA14961 for <9fans@cse.psu.edu>; Tue, 15 Jul 1997 11:52:09 -0400 (EDT)
Received: from localhost.proxima.alt.za (localhost.proxima.alt.za [127.0.0.1]) by foible.proxima.alt.za (8.8.6/8.8.2) with SMTP id RAA09850 for 9fans@cse.psu.edu; Tue, 15 Jul 1997 17:56:40 +0200 (SAT)
Message-Id: <199707151556.RAA09850@foible.proxima.alt.za>
X-Authentication-Warning: foible.proxima.alt.za: localhost.proxima.alt.za [127.0.0.1] didn't use HELO protocol
X-Mailer: exmh version 2.0gamma 1/27/96
To: 9fans@cse.psu.edu
Subject: [9fans] SCSI update and NE2000 question
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 15 Jul 1997 17:56:39 +0200
From: Lucio de Re 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

The SCSI problem I had, failing to operate with the newer Adaptec 
eventually was resolved by using the most recent bootstrap code (B.COM 
from the PC distribution) and patching the PCFS code to include the 
read-only mailbox fixes, as pointed out to be by Jim McKie (and 
assisted by "forsyth" mailing me an updated kernel driver).

If anyone wants diffs for the FS driver, I'll happily mail them, they 
merely repeat what has been done for B.COM and the non-FS kernels.  It 
made me wonder whether the conciseness of the FS kernel makes up for 
the tedium of maintenance.  I don't have an answer :-)

Still on the SCSI side, I have a Sony Magneto-Optical drive and lots of 
small capacity (280MB x 2) platters and, not having thought much about 
it, I wonder how best to configure it; I'm hoping to attach it, 
intelligently, to the File Server.  If anyone else has in fact used, or 
is still using magneto-optical technology, I'll appreciate any 
suggestions on how best to deal with removable media.

I've had a problem with Ethernet adaptors for a while and eventually had to sit down and look into it.  This is what I discovered:

In the "write" function of the NE2000 driver there is some code that depends on the value of the "dummyrr" field of the adaptor data structure.  This causes the DMA destination address to be adjusted, downwards, by one plus the contents of the "card.bit16" value in the same data structure, while the transfer length is adjusted upwards accordingly.

This seems to me to be designed to cater for some extraordinary condition, seeing as there is no obvious way to turn "dummyrr" off (I may well be missing something, I'll get back to that shortly) and the nett effect with the adaptor I'm using is that the function loops endlessly waiting for some value to come up to expectations, which it never does.

Note that a quick browse of equivalent NetBSD driver code doesn't disclose anything along these lines while NetBSD is perfectly comfortable with the adaptors Plan 9 gets jammed on.

I'd like somebody to throw some light on how this peculiar fudge came into being.  I'm also curious as to whether it is at all possible to indicate with some options (the NE2000 driver code checks for the string "nodummyrr", but I can't find any other instance of the tested variable) that the dummyrr condition does not apply.

I have created a kernel with "dummyrr" forced to zero, and it looks more promising, what prompted this message is the necessity now to modify B.COM and the fear that in producing a new B.COM I may lose some functionality which, I seem to recall, is in the version released with the current PC Distribution, but for which sources are not available.

If anyone knows of a mechanism to pass the value "nodummyrr" to the appropriate portion of B.COM, I'd love to hear it.

Many thanks.
-- 
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.



>From owner-9fans  Tue Jul 15 13:10:06 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id NAA16303 for 9fans-outgoing; Tue, 15 Jul 1997 13:10:06 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.bell-labs.com (achille.cs.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id NAA16299 for <9fans@cse.psu.edu>; Tue, 15 Jul 1997 13:10:02 -0400 (EDT)
From: jmk@plan9.bell-labs.com
Message-Id: <199707151710.NAA16299@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Tue, 15 Jul 1997 12:04:30 -0400
Subject: re: [9fans] SCSI update and NE2000 question
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

there are some ne2000 clones which don't work as advertised and
should not do the dummy remote read, apparently you have such.
with dummyrr set the code is as described in the 8390 datsheet.

if you looked in ether2000.c you would see how to turn it off as
an option in plan9.ini

	ctlr->dummyrr = 1;
	for(i = 0; i < ether->nopt; i++){
		if(strcmp(ether->opt[i], "nodummyrr"))
			continue;
		ctlr->dummyrr = 0;
		break;
	}

>From owner-9fans  Tue Jul 15 16:52:14 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id QAA20078 for 9fans-outgoing; Tue, 15 Jul 1997 16:52:14 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from caldo.demon.co.uk (none@caldo.demon.co.uk [194.222.207.148]) by cse.psu.edu (8.8.5/8.7.3) with SMTP id QAA20074 for <9fans@cse.psu.edu>; Tue, 15 Jul 1997 16:52:08 -0400 (EDT)
From: forsyth@caldo.demon.co.uk
Message-Id: <199707152052.QAA20074@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Tue, 15 Jul 1997 21:10:48 BST
Subject: re: [9fans] SCSI update and NE2000 question
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

i think one of York's students might have been responsible for jmk adding
the nodummyrr option, since the student had such a card, which
gave the effects you describe.  the `dummy read' documented in the
data sheet looks like a fix for a chip bug that a clone manufacturer
didn't clone.  if you enable that option, you
should be able to get your card working.  even so, the 8390 cards are best avoided.
for 10m/bit operation, of those supported by plan 9, the 3com 3c509 cards
are a better choice, and now very reasonably priced.

>From owner-9fans  Wed Jul 16 08:52:36 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id IAA27064 for 9fans-outgoing; Wed, 16 Jul 1997 08:52:36 -0400 (EDT)
Received: from foible.proxima.alt.za (foible.proxima.alt.za [192.96.32.132]) by cse.psu.edu (8.8.5/8.7.3) with ESMTP id IAA27060 for <9fans@cse.psu.edu>; Wed, 16 Jul 1997 08:52:27 -0400 (EDT)
Received: from localhost.proxima.alt.za (localhost.proxima.alt.za [127.0.0.1]) by foible.proxima.alt.za (8.8.6/8.8.2) with SMTP id OAA14059 for 9fans@cse.psu.edu; Wed, 16 Jul 1997 14:57:24 +0200 (SAT)
Message-Id: <199707161257.OAA14059@foible.proxima.alt.za>
X-Authentication-Warning: foible.proxima.alt.za: localhost.proxima.alt.za [127.0.0.1] didn't use HELO protocol
X-Mailer: exmh version 2.0gamma 1/27/96
To: 9fans@cse.psu.edu
Subject: [9fans] Looking good...
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 16 Jul 1997 14:57:23 +0200
From: Lucio de Re 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

I now have a Plan 9 file server (don't laugh, it's a 386DX40 with 8Meg 
of RAM and the SONY Magneto-Optical drive - sadly, the 2Gig ST12400N I 
nearly got working fell off my desk and is now departed) that works.

I managed to test a combination of "mkfs | mkext" to copy part of the 
CDROM to the 280Meg MO disk, and I'd now like to be more selective 
about what I put on there while at the same time using the 
"_conform.map" file to rename files correctly.

Steve's script to do this needs "find" which is a utility Plan 9 lacks 
(I presume for good cause) and I'm at a loss on how to replace its 
functionality (I assume I'm not seeing the wood for the trees).  
Unfortunately, this puts me in a bit of a quandary: on the one hand I 
haven't enough space to use the installation diskette to upload the CD 
in its entirety (and get the names translated in the process) and I 
don't know how to get the names translated (other than by manually 
searching through the destination directory) if I generate the disk by 
hand.

I'll not be offended if someone rubs my nose into some obvious 
documentation I have not yet read, I thought I'd been through all the 
necessary information, but there's always something I overlooked or 
seem not to know about.
-- 
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.



>From owner-9fans  Wed Jul 16 09:39:41 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id JAA28052 for 9fans-outgoing; Wed, 16 Jul 1997 09:39:41 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from tor.securecomputing.com (tor.securecomputing.com [199.71.190.98]) by cse.psu.edu (8.8.5/8.7.3) with ESMTP id JAA28045 for <9fans@cse.psu.edu>; Wed, 16 Jul 1997 09:39:36 -0400 (EDT)
Received: by janus.tor.securecomputing.com id <11650>; Wed, 16 Jul 1997 09:33:41 -0400
Message-Id: <97Jul16.093341edt.11650@janus.tor.securecomputing.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Looking good... 
In-reply-to: Your message of "Wed, 16 Jul 1997 08:57:23 EDT."
             <199707161257.OAA14059@foible.proxima.alt.za> 
Date: Wed, 16 Jul 1997 09:39:16 -0400
From: Steve Kotsopoulos 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

Lucio de Re wrote:
> I managed to test a combination of "mkfs | mkext" to copy part of the 
> CDROM to the 280Meg MO disk, and I'd now like to be more selective 
> about what I put on there while at the same time using the 
> "_conform.map" file to rename files correctly.

What you want to do it boot a cdrom-capable kernel on a plan9 terminal (which
it appears you have already done), and then use mkfs|mkext with a custom
proto file that will copy only the stuff you want.
Look in /lib/proto for the prototype files, in particular /lib/proto/portproto, 
copy portproto to /tmp/myproto, edit it to suit your needs,
and use something like the following on your cdrom terminal: 

mount -c /srv/il!* /n/kremvax
mount /srv/boot /n/boot
disk/mkfs -a -s /n/boot /tmp/myproto | disk/mkext -u -d /n/kremvax

You don't need to think __conform.map if you mount the cdrom on a plan9
system. That "find" script is for unpacking things under Unix.

>From owner-9fans  Wed Jul 16 10:20:43 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.5/8.7.3) id KAA29600 for 9fans-outgoing; Wed, 16 Jul 1997 10:20:43 -0400 (EDT)
Received: from foible.proxima.alt.za (foible.proxima.alt.za [192.96.32.132]) by cse.psu.edu (8.8.5/8.7.3) with ESMTP id KAA29589 for <9fans@cse.psu.edu>; Wed, 16 Jul 1997 10:19:51 -0400 (EDT)
Received: from localhost.proxima.alt.za (localhost.proxima.alt.za [127.0.0.1]) by foible.proxima.alt.za (8.8.6/8.8.2) with SMTP id QAA14356 for 9fans@cse.psu.edu; Wed, 16 Jul 1997 16:24:42 +0200 (SAT)
Message-Id: <199707161424.QAA14356@foible.proxima.alt.za>
X-Authentication-Warning: foible.proxima.alt.za: localhost.proxima.alt.za [127.0.0.1] didn't use HELO protocol
X-Mailer: exmh version 2.0gamma 1/27/96
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Looking good... 
In-reply-to: Message from Steve Kotsopoulos  
 of "Wed, 16 Jul 1997 09:39:16 -0400." <97Jul16.093341edt.11650@janus.tor.securecomputing.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 16 Jul 1997 16:24:42 +0200
From: Lucio de Re 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

> 
> You don't need to think __conform.map if you mount the cdrom on a plan9
> system. That "find" script is for unpacking things under Unix.

I guess one needs to read between the lines.  The docs do say that the 
software knows how to translate names, I didn't realise that meant that 
the bits on the CDROM actually contained the filename in disguise and 
that "_conform.map" was just a red herring :-)

Good, now to squeeze the CDROM onto 280Meg...
-- 
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.



>From owner-9fans  Fri Jul 18 15:23:13 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id PAA21456 for 9fans-outgoing; Fri, 18 Jul 1997 15:23:12 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from nol.net (uucp@dazed.nol.net [206.126.32.101]) by cse.psu.edu (8.8.6/8.7.3) with ESMTP id PAA21447 for <9fans@cse.psu.edu>; Fri, 18 Jul 1997 15:23:06 -0400 (EDT)
Received: (from uucp@localhost) by nol.net (8.8.5/NOL - 8.*) id OAA25517 for <9fans@cse.psu.edu>; Fri, 18 Jul 1997 14:23:02 -0500 (CDT)
X-AUTH: NOLNET SENDMAIL AUTH
Received: from UNKNOWN(206.126.32.110), claiming to be "grassy.nol.net"
 via SMTP by dazed, id smtpdAAAa006ES; Fri Jul 18 14:23:00 1997
Date: Fri, 18 Jul 1997 14:23:00 -0500 (CDT)
From: Brandon Black 
To: 9fans@cse.psu.edu
Subject: [9fans] Re: multiple ethernet interfaces, naming 
In-Reply-To: <199707081415.QAA01502@foible.proxima.alt.za>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

On Tue, 8 Jul 1997, Lucio de Re wrote:

> > 
> > >I'm currently rewriting bootp to be a dhcp server.  I'll put the
> > >brazil (brazil, brazil, dee dah, dee dah, ...) version out there
> > >for one of you to plan9 ize if you like.
> > 
> Score 1 for Microsoft, 0 for Lucent :-(
> 
> Surely you should be working on IPv6 or somesuch instead of pampering
> to the Win'95 world (sigh!)?  Next thing, you'll all be developing
> dynamic DNS too :-(


DHCP is not pampering to the Win95 world.  DHCP is a good overall idea,
and I've seen a large company implement it for managing a UNIX network
before (several hundred Sun workstations, actually).  It makes IP
re-numbering much easier.  Don't knock DHCP.  And, If I remember
correctly, IPv6 will have a a much more Dynamic DNS than its predecessor.

Brandon




> -- 
> Lucio de Re (lucio@proxima.alt.za)
> Disclaimer: I'm working at getting my opinions to agree with me.
> 
> 


>From owner-9fans  Tue Jul 22 03:40:18 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id DAA06954 for 9fans-outgoing; Tue, 22 Jul 1997 03:40:18 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.cs.su.oz.au (lore.plan9.cs.su.oz.au [129.78.96.2]) by cse.psu.edu (8.8.6/8.7.3) with SMTP id DAA06949 for <9fans@cse.psu.edu>; Tue, 22 Jul 1997 03:39:48 -0400 (EDT)
To: 9fans@cse.psu.edu
Subject: [9fans] ne2000
From: David Hogan 
Date: Tue, 22 Jul 1997 17:11:46 +1000
Message-ID: <199707221711.63558.out.bakem@plan9.cs.su.oz.au>
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

Well, I have this PnP ethernet card which is supposedly
NE2000 compatible.  Naturally I want everything to
be "Plug and Play", ie once the kernel's recognized the
card (using my PnP support) and configured the irq and io
port, it should know all it needs to know, without any
special stuff in "plan9.ini".

There are two problems.  First, I need to know how much
memory the card has.  It's occured to me that I can
probably get this by using standard memory sizing
techniques.  However, I'd like to know a bit more about
the NE2000 "standard" (ha!), ie: is the RAM base always
at 0x4000?  Is the memory size always limitted to <= 16K?
Is it safe to poke any address, or are there areas
that must be avoided?

Second problem: I need some way to work out whether
dummyrr needs to be set.  Interestingly, leaving this
set for my card causes the machine to spin in dp8390write();
I am writing with "to" == 0x4000 and getting back "crda" == 0x3f00.
I have no idea what it all means, as I have no data sheet/
tech info for this dastardly contraption.

>From owner-9fans  Tue Jul 22 09:25:01 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id JAA09013 for 9fans-outgoing; Tue, 22 Jul 1997 09:25:01 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.bell-labs.com (achille.cs.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.6/8.7.3) with SMTP id JAA08997 for <9fans@cse.psu.edu>; Tue, 22 Jul 1997 09:24:55 -0400 (EDT)
From: jmk@plan9.bell-labs.com
Message-Id: <199707221324.JAA08997@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Tue, 22 Jul 1997 09:22:02 -0400
Subject: re: [9fans] ne2000
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

the datsheets and application notes for the dp8390 explain most of what you need
to know about the wrteched ne2000. they're available on-line at the national
semiconductor website.

no matter how cheap you say it is, it's not worth the money.

>From owner-9fans  Tue Jul 22 14:59:50 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id OAA14011 for 9fans-outgoing; Tue, 22 Jul 1997 14:59:50 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.cs.su.oz.au (lore.plan9.cs.su.oz.au [129.78.96.2]) by cse.psu.edu (8.8.6/8.7.3) with SMTP id OAA14007 for <9fans@cse.psu.edu>; Tue, 22 Jul 1997 14:59:44 -0400 (EDT)
To: 9fans@cse.psu.edu
Subject: re: [9fans] ne2000
From: David Hogan 
Date: Wed, 23 Jul 1997 04:48:37 +1000
In-Reply-To: <199707221324.JAA08997@cse.psu.edu>
Message-ID: <199707230448.64603.out.baker@plan9.cs.su.oz.au>
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

> the datsheets and application notes for the dp8390 explain most of what you need
> to know about the wrteched ne2000. they're available on-line at the national
> semiconductor website.

Thanks, I'll check it out.

> no matter how cheap you say it is, it's not worth the money.

After looking at the driver code, I have to agree.  Reading in
packets using INSx -- what is this, the stone age??

The target application is talking to an ISDN gateway, so
efficiency isn't crucial.  But if cable modem ever arrives,
I'll probably want a better ethernet card (or if I get
a second computer...).

So, which ethernet cards do PCI bus mastering?  :-)

>From owner-9fans  Tue Jul 22 15:35:27 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id PAA14894 for 9fans-outgoing; Tue, 22 Jul 1997 15:35:27 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.bell-labs.com (achille.cs.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.6/8.7.3) with SMTP id PAA14890 for <9fans@cse.psu.edu>; Tue, 22 Jul 1997 15:35:23 -0400 (EDT)
From: jmk@plan9.bell-labs.com
Message-Id: <199707221935.PAA14890@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Tue, 22 Jul 1997 15:32:35 -0400
Subject: re: [9fans] ne2000
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

	So, which ethernet cards do PCI bus mastering?  :-)

the three we currently use are
	3com		3c595 (half a busmaster), 3c905
	intel		ether express 10/100
	digital		de500x (21140 chip, other clones sometimes work)
all are 10/100 cards. the 3com and intel cards are sub $100US, don't
know about the cards based on the 21140 but i believe the clones are
very cheap too.

>From owner-9fans  Tue Jul 22 15:36:52 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id PAA14996 for 9fans-outgoing; Tue, 22 Jul 1997 15:36:52 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ncube.com (hundl.ncube.com [134.242.5.163]) by cse.psu.edu (8.8.6/8.7.3) with SMTP id PAA14989 for <9fans@cse.psu.edu>; Tue, 22 Jul 1997 15:36:46 -0400 (EDT)
From: beto@ncube.com
Message-Id: <199707221936.PAA14989@cse.psu.edu>
Date: Tue, 22 Jul 97 12:27:37 PDT
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ne2000
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

In <199707230448.64603.out.baker@plan9.cs.su.oz.au>
 David Hogan  wrote:

> > the datsheets and application notes for the dp8390 explain most of what you need
> > to know about the wrteched ne2000. they're available on-line at the national
> > semiconductor website.
> 
> Thanks, I'll check it out.
> 
> > no matter how cheap you say it is, it's not worth the money.
> 
> After looking at the driver code, I have to agree.  Reading in
> packets using INSx -- what is this, the stone age??
> 
> The target application is talking to an ISDN gateway, so
> efficiency isn't crucial.  But if cable modem ever arrives,
> I'll probably want a better ethernet card (or if I get
> a second computer...).
> 
> So, which ethernet cards do PCI bus mastering?  :-)

PCI Cogent Ethernet and Fast Ethernet adapters are very good.
We get 60% of a 100mbits link using UDP. These are not
supported on the release, but you could get the information to
write a driver from Digital Semiconductor 
(DECchip 21140A PCI Fast ethenet Lan Controller). 
The interface is very similar to a lance controller 
and it does scatther send (up to two).









>From owner-9fans  Tue Jul 22 16:27:03 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id QAA15974 for 9fans-outgoing; Tue, 22 Jul 1997 16:27:02 -0400 (EDT)
Received: from ducky.net (gate.ducky.net [198.145.101.253]) by cse.psu.edu (8.8.6/8.7.3) with SMTP id QAA15962 for <9fans@cse.psu.edu>; Tue, 22 Jul 1997 16:26:57 -0400 (EDT)
Received: from localhost.ducky.net (localhost.ducky.net [127.0.0.1]) by ducky.net (8.6.12/8.6.12) with SMTP id NAA03604 for <9fans@cse.psu.edu>; Tue, 22 Jul 1997 13:26:44 -0700
Message-Id: <199707222026.NAA03604@ducky.net>
X-Authentication-Warning: ducky.net: Host localhost.ducky.net didn't use HELO protocol
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ne2000 
Date: Tue, 22 Jul 1997 13:26:44 -0700
From: Mike Haertel 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

>So, which ethernet cards do PCI bus mastering?  :-)

Two that I know of, and use under FreeBSD:

* Intel EtherExpress Pro 100, based on the 82557 chip.

* Various cards based on the DEC 21040, 21041, and
  21140 chips.

>From owner-9fans  Tue Jul 22 16:30:22 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id QAA16123 for 9fans-outgoing; Tue, 22 Jul 1997 16:30:22 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.bell-labs.com (achille.cs.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.6/8.7.3) with SMTP id QAA16117 for <9fans@cse.psu.edu>; Tue, 22 Jul 1997 16:30:18 -0400 (EDT)
From: jmk@plan9.bell-labs.com
Message-Id: <199707222030.QAA16117@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Tue, 22 Jul 1997 16:29:59 -0400
Subject: Re: [9fans] ne2000
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

i can get 100% of a 100Mb/s link with UDP on a 21140 based card.
what are you doing wrong?

------ forwarded message follows ------

>From cse.psu.edu!owner-9fans Tue Jul 22 15:58:04 EDT 1997
Received: from cse.psu.edu ([130.203.3.50]) by plan9; Tue Jul 22 15:58:04 EDT 1997
Received: from localhost (majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) with SMTP id PAA15035; Tue, 22 Jul 1997 15:37:03 -0400 (EDT)
Received: by claven.cse.psu.edu (bulk_mailer v1.5); Tue, 22 Jul 1997 15:36:57 -0400
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id PAA14996 for 9fans-outgoing; Tue, 22 Jul 1997 15:36:52 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ncube.com (hundl.ncube.com [134.242.5.163]) by cse.psu.edu (8.8.6/8.7.3) with SMTP id PAA14989 for <9fans@cse.psu.edu>; Tue, 22 Jul 1997 15:36:46 -0400 (EDT)
From: ncube.com!beto
Message-Id: <199707221936.PAA14989@cse.psu.edu>
Date: Tue, 22 Jul 97 12:27:37 PDT
To: cse.psu.edu!9fans
Subject: Re: [9fans] ne2000
Sender: cse.psu.edu!owner-9fans
Reply-To: cse.psu.edu!9fans
Precedence: bulk

In <199707230448.64603.out.baker@plan9.cs.su.oz.au>
 David Hogan  wrote:

> > the datsheets and application notes for the dp8390 explain most of what you need
> > to know about the wrteched ne2000. they're available on-line at the national
> > semiconductor website.
> 
> Thanks, I'll check it out.
> 
> > no matter how cheap you say it is, it's not worth the money.
> 
> After looking at the driver code, I have to agree.  Reading in
> packets using INSx -- what is this, the stone age??
> 
> The target application is talking to an ISDN gateway, so
> efficiency isn't crucial.  But if cable modem ever arrives,
> I'll probably want a better ethernet card (or if I get
> a second computer...).
> 
> So, which ethernet cards do PCI bus mastering?  :-)

PCI Cogent Ethernet and Fast Ethernet adapters are very good.
We get 60% of a 100mbits link using UDP. These are not
supported on the release, but you could get the information to
write a driver from Digital Semiconductor 
(DECchip 21140A PCI Fast ethenet Lan Controller). 
The interface is very similar to a lance controller 
and it does scatther send (up to two).









>From owner-9fans  Tue Jul 22 16:50:28 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id QAA16638 for 9fans-outgoing; Tue, 22 Jul 1997 16:50:28 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from krystal.com (krystal.com [205.230.227.129]) by cse.psu.edu (8.8.6/8.7.3) with ESMTP id QAA16634 for <9fans@cse.psu.edu>; Tue, 22 Jul 1997 16:50:23 -0400 (EDT)
Received: (from prb@localhost)
	by krystal.com (8.8.5/8.8.5) id PAA13742;
	Tue, 22 Jul 1997 15:50:16 -0500 (CDT)
Date: Tue, 22 Jul 1997 15:50:16 -0500 (CDT)
Message-Id: <199707222050.PAA13742@krystal.com>
To: 9fans@cse.psu.edu
From: Paul Borman 
Subject: Re: [9fans] ne2000
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

It all depends on your packet size.  With 1500 byte packets I would
certainly hope you get 100% of a 100Mb/s link.  With 64 byte packets
I would say 60% is pretty darn good.

I am told the "internet" runs with an "average" packet size of around
300 bytes (remember all those acks).  I don't believe your standard
(fast) Intel box will do 100% of a 100Mb/s link with 300 byte packets.

				-Paul Borman
				 prb@bsdi.com

> From: jmk@plan9.bell-labs.com
> 
> i can get 100% of a 100Mb/s link with UDP on a 21140 based card.
> what are you doing wrong?

> From: ncube.com!beto
...k
> PCI Cogent Ethernet and Fast Ethernet adapters are very good.
> We get 60% of a 100mbits link using UDP. These are not

>From owner-9fans  Tue Jul 22 17:15:19 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id RAA17213 for 9fans-outgoing; Tue, 22 Jul 1997 17:15:19 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ncube.com (hundl.ncube.com [134.242.5.163]) by cse.psu.edu (8.8.6/8.7.3) with SMTP id RAA17209 for <9fans@cse.psu.edu>; Tue, 22 Jul 1997 17:15:15 -0400 (EDT)
From: beto@ncube.com
Message-Id: <199707222115.RAA17209@cse.psu.edu>
Date: Tue, 22 Jul 97 14:10:33 PDT
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ne2000
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

In <199707222030.QAA16117@cse.psu.edu>
 jmk@plan9.bell-labs.com wrote:

> i can get 100% of a 100Mb/s link with UDP on a 21140 based card.
> what are you doing wrong?
> 
Is this brazil or plan9? 


>From owner-9fans  Tue Jul 22 18:16:40 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id SAA00744 for 9fans-outgoing; Tue, 22 Jul 1997 18:16:40 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ncube.com (hundl.ncube.com [134.242.5.163]) by cse.psu.edu (8.8.6/8.7.3) with SMTP id SAA00740 for <9fans@cse.psu.edu>; Tue, 22 Jul 1997 18:16:34 -0400 (EDT)
From: beto@ncube.com
Message-Id: <199707222216.SAA00740@cse.psu.edu>
Date: Tue, 22 Jul 97 14:47:18 PDT
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ne2000
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

In <199707222030.QAA16117@cse.psu.edu>
 jmk@plan9.bell-labs.com wrote:

> i can get 100% of a 100Mb/s link with UDP on a 21140 based card.
> what are you doing wrong?
> 

Upss the 60% number is what they use here to configure
a video server because they need some other services
using the link (stream control, files and so on). 

We can saturate 1½ 100Mbits links with one cpu (ours cpu is
not extremelly fast)



>From owner-9fans  Tue Jul 22 18:20:44 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id SAA00893 for 9fans-outgoing; Tue, 22 Jul 1997 18:20:44 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.bell-labs.com (achille.cs.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.6/8.7.3) with SMTP id SAA00887 for <9fans@cse.psu.edu>; Tue, 22 Jul 1997 18:20:40 -0400 (EDT)
From: jmk@plan9.bell-labs.com
Message-Id: <199707222220.SAA00887@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Tue, 22 Jul 1997 18:18:24 -0400
Subject: Re: [9fans] ne2000
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

	From: ncube.com!beto

	In <199707222030.QAA16117@cse.psu.edu>
	 jmk@plan9.bell-labs.com wrote:

	> i can get 100% of a 100Mb/s link with UDP on a 21140 based card.
	> what are you doing wrong?
	> 
	Is this brazil or plan9? 

brazil. using ttcp -u. all the bytes get to the other end.

>From owner-9fans  Tue Jul 22 18:31:59 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id SAA01159 for 9fans-outgoing; Tue, 22 Jul 1997 18:31:59 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ncube.com (hundl.ncube.com [134.242.5.163]) by cse.psu.edu (8.8.6/8.7.3) with SMTP id SAA01154 for <9fans@cse.psu.edu>; Tue, 22 Jul 1997 18:31:55 -0400 (EDT)
From: beto@ncube.com
Message-Id: <199707222231.SAA01154@cse.psu.edu>
Date: Tue, 22 Jul 97 15:27:25 PDT
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ne2000
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

In <199707222220.SAA00887@cse.psu.edu>
 jmk@plan9.bell-labs.com wrote:

> 	From: ncube.com!beto
> 
> 	In <199707222030.QAA16117@cse.psu.edu>
> 	 jmk@plan9.bell-labs.com wrote:
> 
> 	> i can get 100% of a 100Mb/s link with UDP on a 21140 based card.
> 	> what are you doing wrong?
> 	> 
> 	Is this brazil or plan9? 
> 
> brazil. using ttcp -u. all the bytes get to the other end.
> 
What about TCP performance? 
We are only getting 35mbits using ttcp.




>From owner-9fans  Tue Jul 22 23:27:50 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id XAA03897 for 9fans-outgoing; Tue, 22 Jul 1997 23:27:50 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.bell-labs.com (achille.cs.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.6/8.7.3) with SMTP id XAA03893 for <9fans@cse.psu.edu>; Tue, 22 Jul 1997 23:27:46 -0400 (EDT)
From: jmk@plan9.bell-labs.com
Message-Id: <199707230327.XAA03893@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Tue, 22 Jul 1997 23:11:27 -0400
Subject: Re: [9fans] ne2000
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

	From: ncube.com!beto
	In <199707222220.SAA00887@cse.psu.edu>
	 jmk@plan9.bell-labs.com wrote:

	> 	From: ncube.com!beto
	> 
	> 	In <199707222030.QAA16117@cse.psu.edu>
	> 	 jmk@plan9.bell-labs.com wrote:
	> 
	> 	> i can get 100% of a 100Mb/s link with UDP on a 21140 based card.
	> 	> what are you doing wrong?
	> 	> 
	> 	Is this brazil or plan9? 
	> 
	> brazil. using ttcp -u. all the bytes get to the other end.
	> 
	What about TCP performance? 
	We are only getting 35mbits using ttcp.

the best i've seen on our unswitched 100base-tx hub was ~7.5MB/s, i think that's when
the acks collide with the data.

i'm hoping to get a switch in a few weeks and i can try some tests with mixes of
cards, there's certainly more tuning to be done.

i added a new card to the list today, the adaptec (cogent) ana-6910fx. it uses the
digital 21140 chip.

>From owner-9fans  Wed Jul 23 09:02:00 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id JAA07827 for 9fans-outgoing; Wed, 23 Jul 1997 09:02:00 -0400 (EDT)
Received: from foible.proxima.alt.za (foible.proxima.alt.za [192.96.32.132]) by cse.psu.edu (8.8.6/8.7.3) with ESMTP id JAA07816 for <9fans@cse.psu.edu>; Wed, 23 Jul 1997 09:01:39 -0400 (EDT)
Received: from localhost.proxima.alt.za (localhost.proxima.alt.za [127.0.0.1]) by foible.proxima.alt.za (8.8.6/8.8.2) with SMTP id PAA13279 for 9fans@cse.psu.edu; Wed, 23 Jul 1997 15:05:22 +0200 (SAT)
Message-Id: <199707231305.PAA13279@foible.proxima.alt.za>
X-Authentication-Warning: foible.proxima.alt.za: localhost.proxima.alt.za [127.0.0.1] didn't use HELO protocol
X-Mailer: exmh version 2.0gamma 1/27/96
To: 9fans@cse.psu.edu
Subject: [9fans] Plan 9 on PC - memory and swap
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 23 Jul 1997 15:05:21 +0200
From: Lucio de Re 
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

Loading a version of 9pccpudisk, I get the following message:

	2531 free pages, 10124K bytes, swap 55564K, highwater 504K, headroom 
628K

a "cat /dev/swap" yields:

	641/2531 memory 0/11360 swap

on an idle CPU/auth server.

I've not bothered with the details before, but now I'm curious.  
Evidently, the swap value in the kernel message is displayed 
incorrectly, specially in view of the fact that swap has not been 
enabled at the time the kernel loads.

Given that the CPU server has 16 meg of RAM, I'd also be curious as to 
why only 2531K remains available.  Pointers to reading material are 
welcome.
-- 
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.



>From owner-9fans  Wed Jul 23 14:07:33 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id OAA13351 for 9fans-outgoing; Wed, 23 Jul 1997 14:07:33 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.cs.su.oz.au (lore.plan9.cs.su.oz.au [129.78.96.2]) by cse.psu.edu (8.8.6/8.7.3) with SMTP id OAA13347 for <9fans@cse.psu.edu>; Wed, 23 Jul 1997 14:07:24 -0400 (EDT)
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Plan 9 on PC - memory and swap
From: David Hogan 
Date: Thu, 24 Jul 1997 03:43:55 +1000
In-Reply-To: <199707231305.PAA13279@foible.proxima.alt.za>
Message-ID: <199707240343.66706.out.bakes@plan9.cs.su.oz.au>
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

> Loading a version of 9pccpudisk, I get the following message:

> 	2531 free pages, 10124K bytes, swap 55564K, highwater 504K, headroom 
> 628K

> a "cat /dev/swap" yields:

> 	641/2531 memory 0/11360 swap

> on an idle CPU/auth server.

> I've not bothered with the details before, but now I'm curious.  
> Evidently, the swap value in the kernel message is displayed 
> incorrectly, specially in view of the fact that swap has not been 
> enabled at the time the kernel loads.

> Given that the CPU server has 16 meg of RAM, I'd also be curious as to 
> why only 2531K remains available.  Pointers to reading material are 
> welcome.

The numbers in /dev/swap are in units of pages, and on a PC
the page size is 4K.  [Aside: why is there no /dev/pagesize?]

So, 2531 * 4K = 10124K, ie of the 16M that you have, 10M is
available for user processes.  The other 6M is kept by
the kernel for its text and data space, in-kernel bitmap
storage, scsi and ethernet buffers, stream blocks, etc etc...

According to /dev/swap you have 11360*4K = 45440K available
for swap.  If you add 10124K, you get 55564K, the value printed
at startup.  This number represents the total amount of
virtual memory available when swapping is enabled (and
when the swap partition is >= BY2PG*conf.nswap).  See
pageinit() in /sys/src/9/port/page.c, where the message
is printed...

>From owner-9fans  Tue Jul 29 17:34:40 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id RAA07759 for 9fans-outgoing; Tue, 29 Jul 1997 17:34:40 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.bell-labs.com (achille.cs.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.6/8.7.3) with SMTP id RAA07755 for <9fans@cse.psu.edu>; Tue, 29 Jul 1997 17:34:35 -0400 (EDT)
From: seanq@plan9.bell-labs.com
Message-Id: <199707292134.RAA07755@cse.psu.edu>
Date: Tue, 29 Jul 1997 17:25:55 -0400
To: 9fans@cse.psu.edu, sam-fans@hawkwind.utcs.toronto.edu
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans


For those of you that use Sam on Windows 95/NT:
There is a new version which can be installed by running
the self extracting executable available thru netlib.

Go to
	http://netlib.bell-labs.com/netlib/research
and select the file sam.exe, or more directly,
	http://netlib.bell-labs.com/netlib/research/sam.exe

Major changes from the previous release include:
*) The commands that run external programs now work, i.e. '<', '>', '|', '!'.
   Included with the distribution are several command line programs
   that are useful with sam, such as: pwd, echo, fmt, and sort.
*) There is a 'B' command that enables sam to receive file open requests
   from other programs.

Let me know any problems you have.
seanq@research.bell-labs.com

>From owner-9fans  Tue Jul 29 18:00:03 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id SAA08124 for 9fans-outgoing; Tue, 29 Jul 1997 18:00:03 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from trantor.cse.psu.edu (root@trantor.cse.psu.edu [130.203.3.13]) by cse.psu.edu (8.8.6/8.7.3) with ESMTP id RAA08109 for <9fans@cse.psu.edu>; Tue, 29 Jul 1997 17:59:58 -0400 (EDT)
From: beto@ncube.com
Received: from ncube.com (hundl.ncube.com [134.242.5.163]) by trantor.cse.psu.edu (8.8.5/8.7.3) with SMTP id RAA04107 for <9fans@cse.psu.edu>; Tue, 29 Jul 1997 17:59:56 -0400 (EDT)
Message-Id: <199707292159.RAA04107@trantor.cse.psu.edu>
Date: Tue, 29 Jul 97 14:55:07 PDT
To: 9fans@cse.psu.edu
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

In <199707292134.RAA07755@cse.psu.edu>
 seanq@plan9.bell-labs.com wrote:

> 
> For those of you that use Sam on Windows 95/NT:
> There is a new version which can be installed by running
> the self extracting executable available thru netlib.

what about the plan9 terminal emulator for Windows 95/NT? is it
available in the web site? It would be a very good hit if
people could connect to plan9 cpus using
win/nt boxes.

I saw it working last year so I know it's out there.






>From owner-9fans  Wed Jul 30 11:49:51 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id LAA17303 for 9fans-outgoing; Wed, 30 Jul 1997 11:49:51 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ns.dbSystems.com (root@[204.178.76.1] (may be forged)) by cse.psu.edu (8.8.6/8.7.3) with SMTP id LAA17299 for <9fans@cse.psu.edu>; Wed, 30 Jul 1997 11:49:45 -0400 (EDT)
Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id KAA11790 for 9fans@cse.psu.edu; Wed, 30 Jul 1997 10:44:43 -0500
Date: Wed, 30 Jul 1997 10:44:43 -0500
From: "G. David Butler" 
Message-Id: <199707301544.KAA11790@ns.dbSystems.com>
To: 9fans@cse.psu.edu
Subject: [9fans] cfs type caching in the mnt driver
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

I was looking around the cfs code and thought that it
may be interesting to hook the #M mnt device to the
vm system and have it cache data in unused memory.

Memory used by the cache would considered free by the
vm system so processes have first dibs.

This seems the best place to put this kind of caching
since it is where calls get converted to messages and
multiplexing here will allow the cache to be shared
by all processes.

Comments?

David Butler
gdb@dbSystems.com

>From owner-9fans  Wed Jul 30 12:53:15 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id MAA18272 for 9fans-outgoing; Wed, 30 Jul 1997 12:53:14 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from punt-2.mail.demon.net (relay-15.mail.demon.net [194.217.242.9]) by cse.psu.edu (8.8.6/8.7.3) with SMTP id MAA18264 for <9fans@cse.psu.edu>; Wed, 30 Jul 1997 12:53:09 -0400 (EDT)
Received: from mftsun1.demon.co.uk ([158.152.19.44]) by punt-2.mail.demon.net
           id aa0528869; 30 Jul 97 17:47 BST
Received: by mft.co.uk (SMI-8.6/SMI-SVR4)
	id RAA14932; Wed, 30 Jul 1997 17:45:03 +0100
To: 9fans@cse.psu.edu, sam-fans@hawkwind.utcs.toronto.edu
Subject: [9fans] Re: Windows Sam
From: "Mark H. Wilkinson" 
Date: Wed, 30 Jul 1997 17:42:36 +0100
In-Reply-To: <199707292134.RAA07755@cse.psu.edu>
Message-ID: <199707301742.14916.out.babuj@mft.co.uk>
X-Face: Bsp[Ds(Y#/{==j:Cv'"IK4R^D0_z]{'OYtp2^EYqpG)88CsdBm&LJ{idLZWx}AKf}E4#|@4DT4cX3
 ?!>aIVcxmd#1
X-Url: http://Dcpu1.cs.york.ac.uk:6666/~mhw/
X-PGP-Fingerprint: 8E 43 1E D7 85 42 E0 C5  D3 8C B6 B1 EE 06 95 64
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

> *) There is a 'B' command that enables sam to receive file open requests
>    from other programs.

Yahoo! B.exe even works from the Send to... menu!

-Mark.

>From owner-9fans  Wed Jul 30 13:02:46 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id NAA18576 for 9fans-outgoing; Wed, 30 Jul 1997 13:02:45 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from plan9.bell-labs.com (achille.cs.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.6/8.7.3) with SMTP id NAA18572 for <9fans@cse.psu.edu>; Wed, 30 Jul 1997 13:02:42 -0400 (EDT)
From: philw@plan9.bell-labs.com
Message-Id: <199707301702.NAA18572@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Wed, 30 Jul 1997 13:02:03 -0400
Subject: re: [9fans] cfs type caching in the mnt driver
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans

>Memory used by the cache would considered free by the
>vm system so processes have first dibs.
I already did this.

>From owner-9fans  Wed Jul 30 17:19:26 1997
Received: (from majordom@localhost) by cse.psu.edu (8.8.6/8.7.3) id RAA23002 for 9fans-outgoing; Wed, 30 Jul 1997 17:19:25 -0400 (EDT)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from smtp2.nwnexus.com (smtp2.nwnexus.com [198.137.231.18]) by cse.psu.edu (8.8.6/8.7.3) with ESMTP id RAA22998 for <9fans@cse.psu.edu>; Wed, 30 Jul 1997 17:19:22 -0400 (EDT)
Received: from coho.halcyon.com (coho.halcyon.com [198.137.231.21])
	by smtp2.nwnexus.com (8.8.5/8.8.5) with SMTP id OAA13398
	for <9fans@cse.psu.edu>; Wed, 30 Jul 1997 14:19:15 -0700
Date: Wed, 30 Jul 1997 14:19:15 -0700 (PDT)
From: Frank Gleason 
To: 9fans@cse.psu.edu
Subject: re: [9fans] cfs type caching in the mnt driver
In-Reply-To: <199707301702.NAA18572@cse.psu.edu>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans



> >Memory used by the cache would considered free by the
> >vm system so processes have first dibs.
> I already did this.
And?
Objective

Individual Study

Qualifications

Work History

5/97 - present Lockheed Martin Missiles and Space

5/97-present Senior Software Engineer - Mission Assurance & Training<= /h4> Currently developing Web based solutions to replace existing management applications. Development environment includes HTML, JavaScript, Java, C and Perl.

10/91 - 5/97 Stratus Computer, Inc.

6/96-5/97 Senior Software Engineer - UX Development Group

4/95-6/96 Technical Lead - Enhanced Services Engineering

12/94-4/95 Software Engineer - Isis Distributed Systems

4/94-12/94 Software Engineer - Software Sustaining Engineering

10/91-4/94 Software Engineer - Customer Service

7/90-10/91 Systems Programmer, Cycare Systems, Inc.

Education

Languages

Systems

5/97-present Senior Software Engineer - Mission Assurance & Training<= /h4>
Currently developing Web based solutions to replace existing management applications. Development environment includes HTML, JavaScript, Java, C and Perl.
