Messages in this thread | | | Date | Sun, 30 Jul 2006 12:51:15 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH 01/12] making the kernel -Wshadow clean - fix mconf |
| |
On Sun, 30 Jul 2006 21:17:18 +0200 "Jesper Juhl" <jesper.juhl@gmail.com> wrote:
> > (looks at > > lock_cpu_hotplug()) > > > Hmm, I'll take a look at lock_cpu_hotplug() - can you provide > additional details? >
eh. We put the recursive-sem thing in there as a temp fix to cpufreq to get 2.6.something out the door, expressing fine intentions to fix it for real later on. Then look what happened. Don't go there.
> > > 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?
Well actually when struct mutex went in we decided to remove all non-counting uses of semaphores kernel-wide, migrating them to mutexes. Then to remove all the arch-specific semaphore implementations and implement an arch-neutral version. After that has been done would be an appropriate time to rename things.
But it never happened. See "fine intentions", above ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |