Date: Fri, 13 Oct 1995 17:03:00 +0000 From: Matt Thomas <matt@lkg.dec.com> Cc: hackers@freebsd.org Subject: Re: IPX now available Message-ID: <199510131703.RAA23906@whydos.lkg.dec.com> In-Reply-To: Your message of "Fri, 13 Oct 1995 13:06:43 GMT." <199510131306.NAA22947@whydos.lkg.dec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In <199510131306.NAA22947@whydos.lkg.dec.com>, I wrote:
> 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.
Actually I forgot about something. ether_output (and friends) do a switch
based on the address family passed in. The code in the switch needs to be
separated from if_ethersubr.c. So the ether_add and ether_remove should
become ether_input_add and ether_input_remove and two additional routines
added:
int ether_output_add(struct ifnet *, int af,
struct mbuf *(*)(struct ifnet *,
struct mbuf *,
struct sockaddr *,
struct rtentry *));
int ether_output_remove(struct ifnet *, int af);
So the only address families ether_output will deal with are
AF_UNSPEC and AF_IMPLINK (AF_IMPLINK is used for BPF to transmit a
packet "as-is" with little or no post-processing.
Though if the rt_output routinem pointer in the rtentry structure is
used in preference to the if_output (such that only rt_output routine(s)
(e.g. link-type specific code) call if_output and the protocol
code *never* calls if_output directly) then the above routines
would not be needed since ether_output would reduce to the just
the act of sending the packet (as it should be IMO).
Yet another problem is "knowledge" of various address families in
the lan drivers. This should be solved in two steps. The first
is for a generic ether_ifioctl to be added to do most of the common
processing that is in each drivers ifioctl routine. The second is
that yet another registration mechanism is required for SIOCSIFADDR
handler.
Instead of adding YARM, I would instead add a dom_ifaction to the
domain structure. This would be called by any if or link routines
that needed an action performed by the protocol.
error = (*dom->dom_ifhandle)(ifp, ETHER_SIFADDR, (void *) ifa);
For IP, this would simply do what arp_ifinit does today.
The routine would need to switch off the interface type to figure
what action it is being asked to perform. Other actions for LAN
interfaces would include things like ETHER_XLATEMCAST (for ether_addmulti
and ether_delmulti).
Loadable network drivers is one of the harder problems because of how
tightly inter-dependent all the various components currently are. Even
though Digital UNIX has solved a great many of the problem of LKMs,
they still don't support loadable network drivers.
One adavantage of the current blurred layers is efficency and it would
be a shame to lose that when going to loadable future.
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?199510131703.RAA23906>