On Thu, Sep 21, 2000 at 08:55:21AM -0400, Marc Lanoue wrote:
> OK thanks a lot for the precise answer.  I've already taken a look at the
> code for the tcpdump application and the interface is still not clear at
> this point, but I'll try to figure out.  Also, I'll probably try to disable

see also the bpf and pcap manual pages.

> in that case the whole in-kernel IP stack since I do have my own version
> that contains the ARP tables, IP, UDP, TCP, sockets, filtering, etc.  Are
> there a lot of different configuration fields that I need to change in order
> to disable the in-kernel IP stack?

I think a kernel compiled without "options NETINET" should be enouth.
Also, if you ifconfig up the interface without giving a ip addr, the ip stack
should't be used, but you should still be able to use bpf/pcap

> 
> And just to understand the whole architecture, would it still be possible to
> use the various "bus_space_* and "bus_dma_* functions to access the bus at
> the level of my application?  Same thing with the "pci_intr_*" functions,
> would it still be possible to use a library to build my application?  Are
> there any kind of "rings" (like in OS/2) that make doesn't allow an
> application to talk to the different buses and I/O ports?

Hum  you'll have to put something in the kernel for this.
But if you want to talk to the ethernet board this way you'll have to touch
the driver as well. I still don't understand why you want to do this if you
don't want to change/write a driver :)

> 
> On the other side, if you can still answer some questions, let's say that
> this whole application will be ported to an embedded platform, and still
> running NetBSD.  In that case, if I follow the steps that you're suggesting,
> then I would only need to write device drivers to talk to the embedded
> device interface, is that it?

yes.

>  But, on the other side, wouldn't it be
> simpler to use some generic functions and ultimately modify the very
> low-level interface functions, meaning by that, to use the suggested
> "pci_intr_*" functions and the like to keep my whole application minimal?

pci_intr_*, bus_space & bus_dma are to be used by drivers, not protocol
stacks ! You'll have to use them to write a driver. To simplify, you can use
a different interface between your driver and protocol stack, but I'm not sure
you'll really win much by changing this.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--