9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: G. David Butler gdb@dbSystems.com
Subject: multiple ethernet interfaces, naming
Date: Thu,  3 Jul 1997 08:34:24 -0500	[thread overview]
Message-ID: <19970703133424.9Km43kjKOzlXiKNy5ESkWZMWNoTD5TDsYSRlMvsDNGk@z> (raw)

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




             reply	other threads:[~1997-07-03 13:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-07-03 13:34 G.David [this message]
1997-07-03 14:19 presotto
1997-07-03 16:32 G.David
1997-07-03 17:39 David
1997-07-03 20:32 presotto
1997-07-03 23:05 beto
1997-07-03 23:40 Rich
1997-07-07 13:03 G.David
1997-07-07 14:53 presotto
1997-07-07 15:14 jmk
1997-07-08 13:59 G.David
1997-07-08 14:15 Lucio
1997-07-08 19:03 forsyth
1997-07-10  5:17 G.David

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19970703133424.9Km43kjKOzlXiKNy5ESkWZMWNoTD5TDsYSRlMvsDNGk@z \
    --to=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).