In message <[EMAIL PROTECTED]> "Gary T. Corcoran" writes:
: 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?
Yes. hints are loaded in the environment at boot time. userconfig
will edit hints.
: 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.
No. I'd provide the usual functions to parse integers, simple
strings, booleans, etc and store them properly. Driver writers would
be free to provide their own string -> binary mappings if they
desired.
: 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? :)
That's implicit. All the strings in the enviornment are of the form:
hint.foo.4.key=value\0
so the function listed in the table would be called with value and it
would be responsible for storing the binary represenation of the
string.
: 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... :)
No. See above.
: 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.
Yes. You'd say
hint.dslmodem.-1.TransmissionMode=LLC
and your entry would look like:
"TransmissionMode", offsetof(struct softc, tm), MyParseTM, NULL,
in the table. And it would be responsible for parsing. MyParseTM
would look like:
int
MyParseTM(const char *src, void *dst, void *argp)
{
int *valp = (int *) dst;
if (strcmp("LLC", src) == 0) {
*valp = 1;
return 1;
}
if (strcmp("Next", src) == 0) {
*valp = 2;
return 1;
}
// etc
return 0;
}
It would be called
ep points to the entry
vp points to "LLC"
sc points to softc.
ep->fnp(vp, (void *) ((caddr_t) sc) + ep->off, ep->argp);
But writing this, I thin that normal enums would want a specialized
routine for doing this that would could pass a table to.
Hmmm, maybe I should just write something now that I've designed it to
this level :-)
: 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? ;-)
Something like that.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
