From owner-freebsd-hackers Tue Jul 11 16:52:59 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id F341E37B981; Tue, 11 Jul 2000 16:52:53 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id RAA50177; Tue, 11 Jul 2000 17:52:51 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id RAA08554; Tue, 11 Jul 2000 17:52:46 -0600 (MDT) Message-Id: <200007112352.RAA08554@harmony.village.org> To: Mike Smith Subject: Re: Module parameters? Cc: FreeBSD Hackers 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> Date: Tue, 11 Jul 2000 17:52:46 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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