From owner-freebsd-hackers Fri Oct 13 10:17:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA06293 for hackers-outgoing; Fri, 13 Oct 1995 10:17:51 -0700 Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id KAA06288 for ; Fri, 13 Oct 1995 10:17:49 -0700 Received: from muggsy.lkg.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA04491; Fri, 13 Oct 1995 09:58:13 -0700 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA03389; Fri, 13 Oct 1995 12:58:05 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id NAA22947 for ; Fri, 13 Oct 1995 13:06:44 GMT Message-Id: <199510131306.NAA22947@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: hackers@freebsd.org Subject: Re: IPX now available In-Reply-To: Your message of "Thu, 12 Oct 1995 10:39:00 MST." <199510121739.KAA15401@phaeton.artisoft.com> X-Mailer: exmh version 1.5omega 10/6/94 Date: Fri, 13 Oct 1995 13:06:43 +0000 From: Matt Thomas Sender: owner-hackers@freebsd.org Precedence: bulk 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: Westford, MA Disclaimer: Digital disavows all knowledge of this message