From owner-freebsd-hackers  Tue Jul 11 16:46:56 2000
Delivered-To: freebsd-hackers@freebsd.org
Received: from mass.osd.bsdi.com (mass.osd.bsdi.com [204.216.28.234])
	by hub.freebsd.org (Postfix) with ESMTP id 943EE37B967
	for <freebsd-hackers@FreeBSD.ORG>; Tue, 11 Jul 2000 16:46:49 -0700 (PDT)
	(envelope-from msmith@mass.osd.bsdi.com)
Received: from mass.osd.bsdi.com (localhost [127.0.0.1])
	by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id QAA00803;
	Tue, 11 Jul 2000 16:55:03 -0700 (PDT)
	(envelope-from msmith@mass.osd.bsdi.com)
Message-Id: <200007112355.QAA00803@mass.osd.bsdi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Warner Losh <imp@village.org>
Cc: FreeBSD Hackers <freebsd-hackers@FreeBSD.ORG>
Subject: Re: Module parameters? 
In-reply-to: Your message of "Tue, 11 Jul 2000 17:31:39 MDT."
             <200007112331.RAA08374@harmony.village.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 11 Jul 2000 16:55:03 -0700
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> In message <396B8BBB.4AA1867D@lucent.com> "Gary T. Corcoran" writes:
> : No, I know it's not that easy.  We need to be able to do things
> : like have "TransmissionMode=4" on the kldload command line, and
> : have that parse the decimal value 4, and then go into the module
> : and set the value of the TransmissionMode variable to actually be
> : 4 immediately after loading the module into memory, before any of
> : its subroutines are called.  This is what the Linux module loader
> : allows, and it's extremely useful...
> 
> Understood.  What I'm suggesting is that you get those values from the
> kernel like so:
> 
> 	int transmission_mode;
> 
> 	transmission_mode = 4;	/* 4 is the default */
> 	if (resource_int_value(name, unit, "TransmissionMode",
> 	    &transmission_mode) != 0)
> 		resource-int_value(name, -1, "TransmissionMode", 
> 		    &transmission_mode);
> 
> You can then put
> 	hint.dslmodem.-1.TransmissionMode=4
> in your hints file for the kernel.
> 
> Right now the draw back of this is that hints cannot be added after
> boot.  We're working on fixing that.  So if you use this model, you'll
> get the dynamic setting of this information essensially for free.

What Gary and Archie are talking about is actually quite smarfy, and I'm 
somewhat torn.  Imagine an API like this:

struct foodev_tunables {
	int	colour;
	char	name[32];
};

struct config_keys[] {
	{"colour", offsetof(struct foodev_tunables, colour), TYPE_INT, 0},
	{"name",   offsetof(struct foodev_tunables, name), TYPE_CHAR, 32}
};
...
	hints_get_config(dev, &config_keys, &foodev_tunables);

The Linux approach is bad insofar as the arguments are per-module rather 
than per-instance.  In our case we need per-module and per-instance even 
though the arguments are supplied per-file.  So the above would, for 
example, as the foo0 device pick up:

hints.foo.*.colour=4
hints.foo.0.name="foo the zeroeth"

and pack them into the structure.  You could easily use this to tweak 
tunables in your softc, etc. with a lot less code overhead than one call 
per tunable.
-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message