linux-kernel - Re: [PATCH 06/44 take 2] [UBI] startup code

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:	Mon, 05 Mar 2007 14:28:04 +0100
From:	Frank Haverkamp <haver@...t.ibm.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Artem Bityutskiy <dedekind@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	David Woodhouse <dwmw2@...radead.org>,
	Josh Boyer <jwboyer@...ux.vnet.ibm.com>,
	Frank Haverkamp <haver@...t.ibm.com>
Subject: Re: [PATCH 06/44 take 2] [UBI] startup code

Hi Rusty,

On Mon, 2007-02-26 at 09:03 +1100, Rusty Russell wrote:
> On Sun, 2007-02-25 at 05:58 +0000, Christoph Hellwig wrote:
> > 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");
> > > > 

> The reason drivers can use __module_param_call is that they can
> implement their own "types" for module parameters, which will end up
> requiring this.
> 
> Using it directly is only really for backwards compatibility (which is
> important!), but for new parameters, this multi-part self-parsing is
> nasty.  Standard (but admittedly suboptimal) way to do this is having
> three parameters module_param_array(name, ...),
> module_param_array(header_offset, ...),
> module_param_array(data_start, ...).

we wanted to be able to ommit some of the parameters and let UBI use
resonable defaults if needed.

Example where we wanted to explicitly overwrite the offset parameters:
  mtd=content,1984,2048

Example where we did not want it but let instead UBI figure out
resonable parameters:
  mtd=4

With the three arrays we did not see a nice way of achieving this.

  ubimtds=content,4,7
  hdroffs=1984,?,1984
  dataoff=s2048,?,2048

The ? look odd, don't they?

We also looked at the slram parameters which are like this:

  slram=name0,addr0,+size0,name1,addr1,+size1

and found that if we wanted to add one more parameter e.g. width it
cause likely an interface change:

  slram=name0,addr0,+size0,width0,name1,addr1,+size1,width1

Finally we found that we liked the phram parameter parsing (which is
essentially the same) and did it similar to that.

Frank


-
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/