Re: [PATCH] Centralize the selection for debugging semaphores.

On Wed, 31 Jan 2007, Michal Piotrowski wrote:

On 31/01/07, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote:
On Wed, 31 Jan 2007, Michal Piotrowski wrote:

On 31/01/07, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote:

Centralize the kernel config option for debugging semaphores and
modify the macro for frv to use that config option instead.

Signed-off-by: Robert P. J. Day <rpjday@xxxxxxxxxxxxxx>
[..]
+config DEBUG_SEMAPHORE
+ bool "Semaphore debugging"
+ depends on DEBUG_KERNEL
+ default n
+ help
+ If you say Y here then semaphore processing will issue lots of
+ verbose debugging messages. If you suspect a semaphore
problem or
a
+ kernel hacker asks for this option then say Y. Otherwise say
N.
+
+ At the moment, this is implemented only by alpha and frv.

IMHO this option should stay in arch/{alpha,frv}/Kconfig.debug

any particular reason?

Only this
"At the moment, this is implemented only by alpha and frv."

It depends on architecture.

yes, i realize that, but surely there's a cleaner way to implement
something that's supported by only *some* of the architectures rather
than duplicating the code for every one of those architectures.

one possibility is to have the global config option look like this:

config DEBUG_SEMAPHORE
bool "Semaphore debugging"
depends on DEBUG_KERNEL && HAVE_SEMAPHORE_DEBUGGING
^^^^^^^^^^^^^^^^^^^^^^^^
default n
...

at that point, any architecture that implements semaphore debugging
and wants to advertise that simply needs to add this at the top of its
Kconfig.debug file:

config HAVE_SEMAPHORE_DEBUGGING
def_bool y

that was just off the top of my head, but it seems to work. more
generally, though, surely this sort of thing has come up before --
wanting to advertise an identical user-configurable option only for
certain architectures. how is that done *now* without rampant code
duplication? or is it?

rday

--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel
Pedantry Waterloo, Ontario, CANADA

http://www.fsdev.dreamhosters.com/wiki/index.php?title=Main_Page
========================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Linux 2.6.26-rc2
    ... The semaphore simplifcation in -rc1 caused a huge ... That config option was made the only one in January, ... -static inline int cond_resched ... static inline int cond_resched_bkl ...
    (Linux-Kernel)
  • Re: [RFC][PATCH 3/3] Kdump: Export crash notes section address through sysfs
    ... Please test kexec/kdump patches on all three architectures, ... kernel/ksysfs.c:38: error: (Each undeclared identifier is reported only once ... own config option, ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: limits / PIPE_BUF?
    ... the kernel implementation guarantees one page basically, ... architectures; it means apps don't suddenly break if you port it to ... config option on several architectures, so it'd have to be a define for ... do anything inside the kernel anymore? ...
    (Linux-Kernel)
  • Re: [PATCH 1/6] compacting file_ra_state
    ... On Fri, 20 Jul 2007, Fengguang Wu wrote: ... This would add a new limit to 64bit architectures. ... when/if we add a config option to turn pgoff_t into a 32-bit entry ...
    (Linux-Kernel)
  • Re: another kconfig target for building monolithic kernel (for security) ?
    ... /dev/kmem isn't used by much of anything except debugging, ... that a config option is reasonable. ... More majordomo info at http://vger.kernel.org/majordomo-info.html ... Please read the FAQ at http://www.tux.org/lkml/ ...
    (Linux-Kernel)