Subject: RE: PCI device interface and interrupts
To: 'Manuel Bouyer' <bouyer@antioche.lip6.fr>
From: Marc Lanoue <mlanoue@hyperchip.com>
List: tech-kern
Date: 09/21/2000 08:55:21
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C023CB.3354E9B0
Content-Type: text/plain;
charset="iso-8859-1"
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
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?
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?
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? 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?
Thanks a lot.
Marc
-----Original Message-----
From: Manuel Bouyer [mailto:bouyer@antioche.lip6.fr]
Sent: Thursday, September 21, 2000 3:22 AM
To: Marc Lanoue
Cc: 'NetBSD Technical Kernel group (E-mail)'
Subject: Re: PCI device interface and interrupts
On Wed, Sep 20, 2000 at 04:41:17PM -0400, Marc Lanoue wrote:
> I don't want to port anything. As a matter of fact, I have the whole IP
> stack in hands (IP, UDP, sockets, etc.), so I don't want to use the
existing
> one from the NetBSD kernel. So at this point for me, it's a question of
> knowing what is the easiest solution to interface with an Ethernet card
that
> is plugged on the PCI bus. It's simply a question of being able to use
the
> PCI card as it is done through the device driver. Ultimately, there will
be
> no Ethernet card configured in the kernel once it will be reconfigured,
> compiled and started all over again. But, is that possible to do for what
I
> want to validate (i.e., interface my own IP stack with an Ethernet PCI
> card). In that case, how can I use the same Ethernet card? What is the
> simplest way to interface with it? Am I allowed to interface with the
DMA,
> I/O and PCI bus from what would probably be an application running my own
IP
> stack?
>
> Thanks a lot for your time and cooperation Manuel, it's appreciated. I'm
> really confused with NetBSD as it doesn't have (unless I'm wrong once
again)
> any "generic" interface to access the bus, interrupt control and PCI
> interface functions in general libraries. But since I'm a newbie with
> NetBSD maybe I'm wrong on that side too.
Ok, so you don't want to access the bus, interrupt control and PCI interface
(there are functions for this, but it's to write drivers, not to talk to
drivers).
You just need to ask the driver to send a packet for you, and get the
pakets received by the interface.
If you can do all this in userland then you can use the bpf(4) interface
for this (this is the kind of interface used by e.g. tcpdump). You'll also
have to disable the in-kernel IP stack to avoid interferences. Hum, if you
do
this you'll also have to implement arp (or permanent entries to the arp
tables
of other machines).
Another way of doing it is to remplace the in-kernel ip stack with yours,
but
this is IMHO more difficult: you'll also need to add a new soft inetrrupt,
and
interface with sockets. The entry points in the kernel to send/receive
packets
are ether_output() and ether_input()
--
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr
--
------_=_NextPart_001_01C023CB.3354E9B0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: PCI device interface and interrupts</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>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 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?</FONT></P>
<P><FONT SIZE=3D2>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?</FONT></P>
<P><FONT SIZE=3D2>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? 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?</FONT></P>
<P><FONT SIZE=3D2>Thanks a lot.</FONT>
<BR><FONT SIZE=3D2>Marc</FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Manuel Bouyer [<A =
HREF=3D"mailto:bouyer@antioche.lip6.fr">mailto:bouyer@antioche.lip6.fr</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, September 21, 2000 3:22 AM</FONT>
<BR><FONT SIZE=3D2>To: Marc Lanoue</FONT>
<BR><FONT SIZE=3D2>Cc: 'NetBSD Technical Kernel group (E-mail)'</FONT>
<BR><FONT SIZE=3D2>Subject: Re: PCI device interface and =
interrupts</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>On Wed, Sep 20, 2000 at 04:41:17PM -0400, Marc Lanoue =
wrote:</FONT>
<BR><FONT SIZE=3D2>> I don't want to port anything. As a =
matter of fact, I have the whole IP</FONT>
<BR><FONT SIZE=3D2>> stack in hands (IP, UDP, sockets, etc.), so I =
don't want to use the existing</FONT>
<BR><FONT SIZE=3D2>> one from the NetBSD kernel. So at this =
point for me, it's a question of</FONT>
<BR><FONT SIZE=3D2>> knowing what is the easiest solution to =
interface with an Ethernet card that</FONT>
<BR><FONT SIZE=3D2>> is plugged on the PCI bus. It's simply a =
question of being able to use the</FONT>
<BR><FONT SIZE=3D2>> PCI card as it is done through the device =
driver. Ultimately, there will be</FONT>
<BR><FONT SIZE=3D2>> no Ethernet card configured in the kernel once =
it will be reconfigured,</FONT>
<BR><FONT SIZE=3D2>> compiled and started all over again. But, =
is that possible to do for what I</FONT>
<BR><FONT SIZE=3D2>> want to validate (i.e., interface my own IP =
stack with an Ethernet PCI</FONT>
<BR><FONT SIZE=3D2>> card). In that case, how can I use the =
same Ethernet card? What is the</FONT>
<BR><FONT SIZE=3D2>> simplest way to interface with it? Am I =
allowed to interface with the DMA,</FONT>
<BR><FONT SIZE=3D2>> I/O and PCI bus from what would probably be an =
application running my own IP</FONT>
<BR><FONT SIZE=3D2>> stack?</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Thanks a lot for your time and cooperation =
Manuel, it's appreciated. I'm</FONT>
<BR><FONT SIZE=3D2>> really confused with NetBSD as it doesn't have =
(unless I'm wrong once again)</FONT>
<BR><FONT SIZE=3D2>> any "generic" interface to access the =
bus, interrupt control and PCI</FONT>
<BR><FONT SIZE=3D2>> interface functions in general libraries. =
But since I'm a newbie with</FONT>
<BR><FONT SIZE=3D2>> NetBSD maybe I'm wrong on that side too.</FONT>
</P>
<P><FONT SIZE=3D2>Ok, so you don't want to access the bus, interrupt =
control and PCI interface</FONT>
<BR><FONT SIZE=3D2>(there are functions for this, but it's to write =
drivers, not to talk to</FONT>
<BR><FONT SIZE=3D2>drivers).</FONT>
<BR><FONT SIZE=3D2>You just need to ask the driver to send a packet for =
you, and get the</FONT>
<BR><FONT SIZE=3D2>pakets received by the interface.</FONT>
<BR><FONT SIZE=3D2>If you can do all this in userland then you can use =
the bpf(4) interface</FONT>
<BR><FONT SIZE=3D2>for this (this is the kind of interface used by e.g. =
tcpdump). You'll also</FONT>
<BR><FONT SIZE=3D2>have to disable the in-kernel IP stack to avoid =
interferences. Hum, if you do</FONT>
<BR><FONT SIZE=3D2>this you'll also have to implement arp (or permanent =
entries to the arp tables</FONT>
<BR><FONT SIZE=3D2>of other machines).</FONT>
</P>
<P><FONT SIZE=3D2>Another way of doing it is to remplace the in-kernel =
ip stack with yours, but</FONT>
<BR><FONT SIZE=3D2>this is IMHO more difficult: you'll also need to add =
a new soft inetrrupt, and</FONT>
<BR><FONT SIZE=3D2>interface with sockets. The entry points in the =
kernel to send/receive packets</FONT>
<BR><FONT SIZE=3D2>are ether_output() and ether_input()</FONT>
</P>
<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>Manuel Bouyer, LIP6, Universite Paris =
VI. =
Manuel.Bouyer@lip6.fr</FONT>
<BR><FONT SIZE=3D2>--</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C023CB.3354E9B0--