On 30/07/06, Andrew Morton <[email protected]> wrote:
On Sun, 30 Jul 2006 21:17:18 +0200
"Jesper Juhl" <[email protected]> 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.
Ok, that's probably way over my head, but I'll dig in none the less
and see what I can do to help. It'll probably land me in a world of
hurt, but I've taken flames before and I'm still here ;-)
Don't expect much, but I'll see if there's anything I can do at least.
>
> > 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.
Makes sense.
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.
Ok, that is (again) probably beyond me, but I'll still take a look at
it just for the hell of it.
If nothing else I can at least keep an eye out for when we reach the
point we want to be at and then submit renaming patches... let's
see..
But it never happened. See "fine intentions", above ;)
Heh, The road to hell is paved with fine intentions ;-)
--
Jesper Juhl <[email protected]>
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
