Kurt Garloff wrote:
>
> On Tue, Aug 31, 1999 at 04:15:29AM -0400, Doug Ledford wrote:
> > > options aic7xxx aic7xxx=verbose,extended
> >
> > The second line above is broken. As is documented in the file
> > /usr/src/linux/drivers/scsi/README.aic7xxx, the aic7xxx= portion of an insmod
> > command can not have any commas (,) present. The program insmod doesn't
> > handle the comma correctly and the options don't get passed to the driver.
>
> Sorry?
> I got lots of modules working with comma separated options. I can't find any
> insmod bug.
> Ah, you probably expect your commas to not separate your string, right?
> May you should not use "s", but "1-16s" in MODULE_PARM and use aic7xxx[] for
> storing the options.
Documentation on the MODULE_PARM() stuff would be nice, but regardless of
that, I don't believe what you are suggesting will give what I'm looking for
(although I could be wrong). What I actually consider to be a bug in insmod
is that regarless of quoting convention, the commas still split the string
into chunks such that at insmod time, the following two lines operate
identically:
insmod aic7xxx aic7xxx=verbose,extended
insmod aic7xxx aic7xxx='verbose,extended'
So, although there is an argument that can be made that the first line should
result in two string allocations and the variable aic7xxx[0] being a pointer
to the first and aic7xxx[1] being a pointer to the second, I can find no such
justification for the second to also operate in that fashion. (side note, I
also don't think the first should be split into two strings,
I think a string option should be passed in verbatim so that it can be
interpreted by the same code that parses strings to built in kernel drivers,
such as in my case the aic7xxx_setup() routine. I find the argument that
there should be any difference between passing options to a module and passing
options to a built in kernel driver more compelling than the argument for
splitting strings up at commas)
Secondly, in the interest of not duplicating code, I use the exact same parser
on this string as is used when the driver is compiled into the kernel and a
setup string is passed to us. What you are suggesting would require some
modifications to the parser and in general a difference between compiled in
driver parsers versus module parses. Personally, I find the whole distinction
stupid. I can see an argument for the treatment commas get on integer
variables and the like, but I think it's totally wrong to be interpreting them
at all in the middle of a string variable and an order of maginitude more
wrong that they can't be quoted around or escaped in any way to my knowledge.
Let me demonstrate, by means of an actuall aic7xxx setup line I have put into
my lilo.conf in the past, why interpreting commas in a string variable is
wrong and how the suggestion you made would break my parser:
append="aic7xxx=verbose:0x9939,tag_info:{,{32,32,32,32,32,32,32,32},{,,,,32,32,32,32,32,32},{0,0}},panic_on_abort"
Now, if insmod wants to put those into individual strings then I have to turn
around and cat them all back together and re-insert the commas in order to
make my parser work. In general, the format my parser uses allows a person to
do set a lot of variables with a minumum of effort. Far less effort than the
typical insmod way of doing things which would translate the above line to:
insmod aic7xxx aic7xxx_verbose=0x9939 aic7xxx_panic_on_abort=1
aic7xxx_tag_info=255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,32,32,32,32,32,32,32,32,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,32,32,32,32,32,32,255,255,255,255,255,255,0,0
So, how do I get around this brokenness in the insmod utility? I make my
parser interpret a comma and a period as the same thing. That way, you can
use a comma on the lilo append line when passing options in, which makes sense
and has been done since the very early days of the kernel. And when using a
module instead, the only thing you have to change is that you replace your
commas with periods so that insmod doesn't ruin your option string for you.
Unfortunately, even though I've documented that fact, not everyone catches it
and so I still have to field questions about broken module option strings....
--
Doug Ledford <[EMAIL PROTECTED]>
Opinions expressed are my own, but
they should be everybody's.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
