Date: Fri, 13 Oct 1995 13:06:43 +0000 From: Matt Thomas <matt@lkg.dec.com> To: hackers@freebsd.org Subject: Re: IPX now available Message-ID: <199510131306.NAA22947@whydos.lkg.dec.com> In-Reply-To: Your message of "Thu, 12 Oct 1995 10:39:00 MST." <199510121739.KAA15401@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In <199510121739.KAA15401@phaeton.artisoft.com>, Terry Lambert wrote:
> > > What would you need as far as a registration interface in the protocol
> > > code to allow you to make it an LKM?
> >
> > Well I haven't looked at how LKMs work. The problems I see is in
> > net/if_ethersubr.c, net/if_loop.c and the device drivers that have to change.
> > Maybe we can make those things more generic???
>
> This would be my preference.
>
> We want a registration mechanism for LLC's, another for protocol
> families, etc..
It's actaully much more complex than this.
You need at least the following:
int domain_add(struct domain *);
int domain_remove(struct domain *);
int netisr_add(int *isrnum, struct ifqueue *ifq, struct domain *dom,
void (*isr)(void), int flags);
int netisr_remove(int isrnum);
int netisr_input(int isrnum, struct mbuf *,
const char *hdr, int hdrlen);
Those are nicely generic and are really independent of the interface type.
Not surpisingly these are very similar to the functions provided by Digital
UNIX (aka DEC OSF/1) for their LKMs.
Now you need some media-specific routines and this is where it gets messy.
enum ether_sap_type { ETHER_PTYPE, ETHER_LLC };
ether_add(struct ifnet *, void **cookie_p, int isrnum,
enum ether_sap_type, ...);
ether_remove(struct ifnet *, void *cookie);
If the sap_type is PTYPE, then the next argument is the ether type
(e.g. ETHERTYPE_IP). If the sap_type is ETHER_LLC, then the next two
arguments are pointers to int32_t [2] arrays. These are used in the
following manner: (llcdata & array1-data) == array2-data. This is a
sufficently simple yet flexible mechanism to deal with normal LLC SAPs
as well as SNAP SAPs and even braindead (aka RAW 802) Netware. (FDDI
and Token Ring could use the same routines if they were written in a
generic manner).
You'll need corresponding routines for ppp and other multi-protocol
datalinks.
---
As for the related issue of how Ethernet drivers know they are dealing
with LLC or Ethernet packets, it's actually very simple. When the
ether_output is called with a sockaddr with AF_UNSPEC, if the ether_type
in the ether_header in the sockaddr data is non-zero, it's Ethernet format
(or encapsulated Ethernet for FDDI or Token Ring) otherwise it's LLC and
it's assumed that the mbuf already has the LLC data. If the media is
Ethernet and the data is LLC, ether_output will set the protocol type of
the Ethernet header to the length of the packet.
This gives consistent behavour for Ethernet and FDDI (or other 802 media).
---
The above completely changes the way netisr processing works and it would
probably be best to migrate that out of locore.s into a .c in sys/net.
The most important thing to recognize is that there are nolonger any
assigned netisr numbers, they are all dynamically assigned (and deassigned).
Anyways, most of the netisr changes are needed to properly support SMP.
Matt Thomas Internet: matt@lkg.dec.com
3am Software Foundry WWW URL: <currently homeless>
Westford, MA Disclaimer: Digital disavows all knowledge
of this message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510131306.NAA22947>