In article <199507310828.BAA02195@Kowhai.Stanford.EDU> jonathan@dsg.stanford.edu (Jonathan Stone) writes:
>
>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.)

This means that testing will be really difficult...

>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.

I am using stdargs in the function definitions too. [Yes my fingers
are hurting from too much typing of the same word sequences!]

>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.

I thought it was required to accept at least varargs style
declarations?!? I have never used a compiler that did not have
varargs.h or stdarg.h...  The only problem I can see with the
variadic approach is the extra code and a possible performance
penalty.

>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?

That is not a bad idea. I'll try to convert to that in the second
pass. I am running out of steam converting all the networking code
to KNF and adding prototypes to them. I'd like to finish everything
before I leave for vacation because otherwise the code will diverge
too much from -current.

>(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)?

Because I really would like eventually to have -Wstrict-prototypes
in the kernel CFLAGS so that we don't end up with missing prototypes
in a couple of months.