linux-kernel - Re: [PATCH] nozomi: constify driver

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:	Fri, 1 Feb 2008 08:28:15 +0100
From:	Sam Ravnborg <sam@...nborg.org>
To:	Frank Seidel <fseidel@...e.de>
Cc:	Jan Engelhardt <jengelh@...putergmbh.de>,
	Greg Kroah-Hartman <gregkh@...e.de>, jirislaby@...il.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] nozomi: constify driver

On Fri, Feb 01, 2008 at 07:25:05AM +0100, Frank Seidel wrote:
> On Thursday 31 January 2008 22:39, Jan Engelhardt wrote:
> > On Jan 31 2008 22:10, Frank Seidel wrote:
> > >(Re: [PATCH 012/196 ver2] nozomi driver) and is a rework
> > >of the nozomi constify patch from Jan Engelhardt.
> > 
> > It's hard to find what you actually reworked...
> 
> No, just use interdiff and its easy :-) .. and btw
> I didn't say i did a full rewrite ;-)
> 
> > >-static struct pci_device_id nozomi_pci_tbl[] = {
> > >+static const struct pci_device_id nozomi_pci_tbl[] __devinitdata = {
> > 
> > This is bogus.
> 
> In what way? First i tested this patch well (compiling and
> usage doesn't break a single thing) and second this (static
> const struct pci_device_id .. __devinitdata) can be found in many
> drivers.
> So, please explain why you think so.

__devinitdata is for non-const data.
__devinitconst is for const data.

You cannot mix const and non-const data in the same section,
if you do so gcc will complain.
It may build for you if all uses of __devinitdata in the
same source file is either const or non-const but when you
mix it then it breaks.

So please use the correct annotation.


> P.S.: btw this is the interdiff. Yes, its not big, but even
> then why not combine it with yours ;-)

We do small incremental steps whenever we can. The challenge is
often to split up patches and not to combine them.

Where we combine two patches this is when the second patch fix
a bug in the first patch.

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