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