Subject: Re: Cabletron "etherd" program for NetBSD
To: None <budd@cs.bu.edu>
From: Ian Dall <Ian.Dall@dsto.defence.gov.au>
List: port-pc532
Date: 08/26/1996 13:17:09
Phil Budne <budd@cs.bu.edu> writes:

  >> I got "no route to host" message... I couldn't get it to work until
  >> I did something like "route add -net 10.0.0.0 10.0.0.1 -interface".

  > Hmmm....  My code should issues an equvalent command (via a routing
  > socket) for the dest net (as determined from the tunnel interface addr
  > and mask), and no manual route commands should be needed.

  >> One thing, I had a ppp running which set up a default route ...

  > I don't think that should have mattered...

I also had a ppp between the sun3 and the pc532. I killed that of course.
I'll see next time I reboot it may have fixed its self.

  >> I assume block IO and paging/swapping is not done in a process context.

  > They're done by process zero!

The same mechanism might be possible. Either have another "in kernel"
process or just use process 0 as the context somehow.

  > It's since occured to me that the natural way to allocate memory for
  > packets in a SCSI ethernet driver is to use mbufs.

Certainly. Any ethernet driver must have a way of allocating space for
packets (presumably the mbuf mechanism) and it makes sense to do the same
thing.

  > You just have to
  > make sure that when they get wrapped in a block I/O "struct buf" to
  > hand to the SCSI I/O system that the buffers will never get freed (by
  > normal block I/O routines).

Perhaps a custom scsi_done()?

Ian