Date: Tue, 11 Jul 2000 20:58:45 -0400 From: "Gary T. Corcoran" <gcorcoran@lucent.com> To: Warner Losh <imp@village.org> Cc: Mike Smith <msmith@FreeBSD.ORG>, FreeBSD Hackers <freebsd-hackers@FreeBSD.ORG> Subject: Re: Module parameters? Message-ID: <396BC2C5.E89AD827@lucent.com> References: <200007112355.QAA00803@mass.osd.bsdi.com> <200007112352.RAA08554@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote:
>
> 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.
You're right, Mike. I hadn't thought about it (since one usually won't
have more than one DSL card in a PC :), but to be generally useful, we really
should have per-instance arguments for modules that support multiple
instances of the same device. I'm not sure what you mean though, by
"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.
It sounds pretty good to me, too. And yes, even though my initial
example concerned just an int, you also need to be able to set strings
for tunable parameters (e.g. the Service Name for PPPoE).
Forgive my ignorance (since I'm unfamiliar with this hint stuff), but
I presume the above hints.foo... stuff just goes in some config file
somewhere? And this config file would be consulted whenever a module
is loaded? Just curious, what would "userconfig" be for?
> 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.
Umm, I'm a little bit confused by the above. First you say that you'd
make simple functions to do the storing, but that you don't do the
parsing yourself. If you don't know how to do the storing (because of
a special type), how do you know how to do the parsing in a general
routine? :) But then you go on to suggest that you would like the
function pointers to give modules the maximum flexibility. This means
that the module itself would have the functions for parsing the parameters,
right? I'm not trying to give you a hard time, I'm just trying to
understand what you really meant to say... :)
And I do agree that it would be nice to have the flexibility for the
module to parse its own parameters, if desired. For example, it would
be much clearer, and less prone to error, if the user could specify
TransmissionMode=LLC/SNAP/Bridged, rather than having to look up that
LLC/SNAP/Bridged mode is value 4 and then put TransmissionMode=4 in
a config file. The Windows "Advanced Properties" GUI allows this -
that is, it presents a drop-down list of strings, and when the user
chooses one, the corresponding enum'ed value is stored in the registry.
But of course using the string to specify the desired
mode takes more work on the part of the module writer, so it'd be
nice to not require that in all cases, i.e. allow "=4" auto-parsed.
I suppose we could have kernel-supplied functions to do the parsing
for the typical simple cases, e.g. int's, strings, and allow the
modules themselves to supply parsing routines for "special" parameters?
Maybe that's what you meant by the above? ;-)
Gary
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?396BC2C5.E89AD827>