> What is the status of netiso and
>netccitt? Is anybody using them? Do they actually work?

The problem is finding whether they work is finding someone else silly
enough to be running them, to talk to.  The code in Reno worked. I
don't even *know* anymore what to use as an OSI address (the New
Zealand OSI profile effectively used telephone numbers, in BCD, to
which an Ethernet address was appended. Bletch.  A suitably-configured
Cisco could answer a `ping' equivalent.)

I heard rumours that ISODE 8.0(?) was going to include
application-level code that ran over the BSD netiso stack.  I don't
know if that ever happened.


>The biggest question is what to do with the protocol switch; unfortunately
>there is no way to fully prototype in input and output functions...
>Here's the current prototype that I am using. Does anybody have any
>nbetter ideas? It looks to me like the protocol switch was an afterthought,
>and there are lots of places where it is violated.

I said all along the struct protosw would be the sticking point :).

Whatever you do, please don't use variadic prototypes. To be
conformant, the definitions of the variadic functions __have__ to use
stdargs.  Using ordinary function definitions ``usually works'', since
compiler writers typically try and support pre-ANSI code that makes
calls to variadic functions that may *still* be defined using varargs
--like, oh, printf(), on some systems.  (This affects the calling
sequence that a compiler like GCC uses on a given target, even *if*
NetBSD's user-level code is already fully prototyped.)

At some point, with some compiler, on some RISC machine (or perhaps
even a CISC configured to pass arguments in registers) having a
variadic prototype and a non-variadic definition will break horribly
on some port.

Also, supporting variadic calls while maintaining support for old
compilers that don't support prototypes (and thus are unlikely to
support stdargs) is likely, IMHO, to be even worse than loose
typechecking on the protocol switch.


Surely it's possible to have one `protocol switch' that's strongly
typed, for each stack? Declare a variant of a struct protosw for each
protocol stack, that *does* match the actual calling conventions for
that protocol stack;  make the protocol switch definition for each
protocol to be of the type appropriate for that protocol switch, and
then declare (or cast) all the pointers *to* protocol switches,
as being of the appropriate type?

I don't see why that couldn't be made to work for the input level
(i.e., driver-level demultiplexing), since
that code dispatches based on frame-level type information anyway.
Above there, upward calls  are in protocol-specific code, and can
use the protcol's own switch variant.

Calls *downward* from the socket layer might be harder; but they
*should* all be do-able.

(If socket-level code makes generic calls into a protosw function
 without knowing the underlying protocol, the interface *has*
 to be the same across protocols, or things'd break.  That's one
 reason why downard calls from the socket layer go through
 pr_usrreq().  If a call *is* made from code aware of the underlying
 protocol, and using a protocol-specific set of arguments, then the
 call via a protocol switch can be cast to something appropriate for
 the given protocol at the point of the call.)

Am I missing anything there?

And if a specialized, strongly-type-checked protosw-for-each-protocol
doesn't really work -- the protocol switch really *is* polymorphic.
Why not leave it un-typechecked (until, if ever, the kernel is
converted to C++, and the protosw becomes virtual funciton calls
anyway)?