linux-kernel - Re: [PATCH 01/12] making the kernel -Wshadow clean

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]

Message-ID: <9a8748490607301217g1edad85dre8a45457c57bee35@mail.gmail.com>
Date:	Sun, 30 Jul 2006 21:17:18 +0200
From:	"Jesper Juhl" <jesper.juhl@...il.com>
To:	"Andrew Morton" <akpm@...l.org>
Cc:	pj@....com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/12] making the kernel -Wshadow clean - fix mconf

On 30/07/06, Andrew Morton <akpm@...l.org> wrote:
> On Sun, 30 Jul 2006 20:48:23 +0200
> "Jesper Juhl" <jesper.juhl@...il.com> wrote:
>
> > > Perhaps I am misreading this patch set?
> > >
> > i don't think you are. It's just that I want to take the least
> > intrusive route *now*, make us -Wshadow clean, get -Wshadow to be an
> > accepted part of the Makefile, *then* deal with the more
> > intrusive/controversial renamings, where I guess you'd have done
> > things in the opposite order - right?
>
> yup.  Experience tells us that it's better to get things right first time,
> because we don't get around to doing the intended second pass

I believe my (modest) track record would show that I do follow up on
these things...
But anyway, I believe the renames I've done are not bad one way or the
other and should be acceptable (and some of the long names for local
symbols are chosen based on maintainer feedback even)... but I'll
await more feedback and change the patches if needed.

> (looks at
> lock_cpu_hotplug())
>
Hmm, I'll take a look at lock_cpu_hotplug() - can you provide
additional details?

> That being said, no, we can't go and rename up().  Let us go through the
> patches one-at-a-time..
>
i figured as much. *But* won't you agree that up_sem() (or considering
the other locking function names, sem_up() would probably be better)
would be a much better name for a global like this one?

How about a plan like this:
We introduce sem_up() and sem_down() wrapper functions now. They could
go into 2.6.19 for example - and also add a note to
feature-removal-schedule.txt that the old function names will be
removed in 1 year. Then in a few kernel versions - say 2.6.21 - we
deprecate the old names and add a big fac comment in the source as
well.
Wouldn't that be doable?   Or do we have to live with up()/down() forever?

-- 
Jesper Juhl <jesper.juhl@...il.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html
-
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/