lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 25 Feb 2007 05:58:28 +0000
From:	Christoph Hellwig <hch@...radead.org>
To:	Artem Bityutskiy <dedekind@...radead.org>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Frank Haverkamp <haver@...t.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	David Woodhouse <dwmw2@...radead.org>,
	Josh Boyer <jwboyer@...ux.vnet.ibm.com>, rusty@...tcorp.com.au
Subject: Re: [PATCH 06/44 take 2] [UBI] startup code

On Tue, Feb 20, 2007 at 03:00:56PM +0200, Artem Bityutskiy wrote:
> > > +module_param_call(mtd, ubi_mtd_param_parse, NULL, NULL, 000);
> > > +MODULE_PARM_DESC(mtd, "MTD devices to attach. Parameter format: "
> > > +		      "mtd=<name|num>[,<vid_hdr_offs>,<data_offs>]. "
> > > +		      "Multiple \"mtd\" parameters may be specified.\n"
> > > +		      "MTD devices may be specified by their number or name. "
> > > +		      "Optional \"vid_hdr_offs\" and \"data_offs\" parameters "
> > > +		      "specify UBI VID header position and data starting "
> > > +		      "position to be used by UBI.\n"
> > > +		      "Example: mtd=content,1984,2048 mtd=4 - attach MTD device"
> > > +		      "with name content using VID header offset 1984 and data "
> > > +		      "start 2048, and MTD device number 4 using default "
> > > +		      "offsets");
> > 
> > This is a very odd paramater interface.  We really don't want drivers to use
> > module_param_call directly.  You probably want various module_param_array calls
> > instead.
> 
> Why not? We tried to avoid this but found out that this is the most
> decent interface. Specific advises are welcome.

because this type of compount interface is really painful for the user.
the module.param=foo syntax makes sure paramaters can be used without
endless documentation for each and every single of them, and makes
sure module writers don't introduce bugs in their own parser reimplementations.

Rusty, was it intentional that drivers can use __module_param_call?
Do you think the ubi use here is okay?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ