Date: Tue, 11 Jul 2000 17:52:46 -0600 From: Warner Losh <imp@village.org> To: Mike Smith <msmith@FreeBSD.ORG> Cc: FreeBSD Hackers <freebsd-hackers@FreeBSD.ORG> Subject: Re: Module parameters? Message-ID: <200007112352.RAA08554@harmony.village.org> In-Reply-To: Your message of "Tue, 11 Jul 2000 16:55:03 PDT." <200007112355.QAA00803@mass.osd.bsdi.com> References: <200007112355.QAA00803@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200007112355.QAA00803@mass.osd.bsdi.com> Mike Smith writes:
: > 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.
I like that idea, so long as it doesn't add yet another configuration
path. That is, so long as it builds on the hint and hint management
that is in the kernel now so that it can easily be added to userconfig
later.
In fact, that's where I'd like to take things in the future. It was
part of what I'd envisoned when I started. However, the config_keys
would have function pointers rather than raw offsets. The raw offsets
are OK, but you run into a lot of problems with them down the road.
You make simple functions that will do the storing, and that replaces
your TYPE_XXX parameter as well.
It would certainly be nicer than parsing it yourself.
I've been down this path twice before on large X toolkits (twice with
the OI toolkit), so I know the problems that you're going to hit. The
type parameter is weak at best because later you'll want to have a
filename (which is a string of a certain syntax and meaning) as well
as a node id (which is also a string of a certain, but different,
syntax and meaning). It will be much easier if we allow for function
pointers now to deal with that and to give the modules the maximum
flexibility in turning their strings into numbers.
Warner
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007112352.RAA08554>