Subject: Parameter passing in the kernel
To: None <>
From: Lloyd Parkes <>
List: tech-kern
Date: 06/19/2001 10:32:44
One thing that I thought of a while back, and have been reminded of it
now that I am delving into device driver code again.

With the layered device driver structure that is used extensively in
NetBSD to provide machine, bus and in some cases chip independence we
often find the following paradigm:

	static void
	xx_bus_attach (struct device *self, _ATTACH_ARGS_)
		struct xx_softc *xx = (struct xx_softc *xx)self;


		xx->xx_DATA1 = _DATA1_;
		xx->xx_DATA2 = _DATA2_;
		xx->xx_DATA3 = _DATA3_;
		xxattach (xx, _ATTACH_ARGS_);

It is important to note that I am only interested in the case where the
xx_DATA* fields are being used by the upper layer driver. They could be
anything from data needed to configure chip for the type of bus it is
on, to pointers to funtions that handle special operations.

In this case the data in xx_DATA* are effectively parameters to xxattach
describing how the device is attached to the bus in question. We have
bypassed C's parameter passing mechanism and built our own. My problem
with this is that we have not replaced C's parameter checking mechanism.
We have an implicit type check being dome, but the number of parameters
being passed isn't checked. We could forget to fill in a field and we
would only find out by getting a DIAGNOSTIC message at runtime (in the
best case).

The C parameter passing mechanism is well defined and C compilers are
designed to warn us when we make many types of dumb mistakes with it. 
I object to discarding this support. As far as I am concerned I want all
the help I can get from the compiler. The more work it does, the less
work I do.

The following is my preferred paradigm:

	static void
	xx_bus_attach (struct device *self, _ATTACH_ARGS_)
		struct xx_softc *xx = (struct xx_softc *xx)self;


		xxattach (xx, _ATTACH_ARGS_, _DATA1_, _DATA2_, _DATA2_);

I realise that this doesn't suit all of the NetBSD drivers, but it does
work for a good number of them.