HAVE or ARCH_HAS or ARCH_SUPPORTS and use of select

HAVE or ARCH_HAS or ARCH_SUPPORTS and use of select

[Sam Ravnborg]

I just asked Mathieu to use ARCH_HAS_<config-symbol>
when an architecture should say that it uses the
generic KPROBSE functionality.

ARCH_HAS was selected from a pure "what is most popular today"
grep of the kernel source.

It is used roughly like this:

*Generic Kconfig file:*
config KPROBES
	depends on ARCH_HAS_KPROBES
	bool "bla bla"

# let arch that support KPROBES select the below symbol.
# Note: no dependencies allowed on ARCH_HAS_ symbols!
config ARCH_HAS_KPROBES
	def_bool n

*Arch specific Kconfig file:*
config X86
	select ARCH_HAS_KPROBES


But I felt a bit uneasy with the wording "ARCH_HAS" because
in reality it is "ARCH_USES" or "ARCH_SUPPORTS" because
in this case X86 uses the generic KPROBES functionality
or maybe it just supports it.
On the config level do we really want to ditingush between "HAS",
"SUPPORTS", "USE" and whatever the next person come up with?

automake and friends uses HAVE_ and I dunno about other tools.

Could we come up with a naming that fits the current usages we
could standardize on this.
When we have it defined I will update kconfig-language.txt
and try to chase people that fail to use the naming scheme.
(Or I will ask Randy to do it so it is readable for humans..)

For x86 for instance there is potential for some cleaning and likewise
in other archs.

	Sam

Re: HAVE or ARCH_HAS or ARCH_SUPPORTS and use of select

[Russell King]

On Thu, Nov 15, 2007 at 10:02:15AM +0100, Sam Ravnborg wrote:
> automake and friends uses HAVE_ and I dunno about other tools.

For the sake of conciseness, HAVE_ is the obvious winner.  Though
I'm not sure that we particularly go for conciseness:

config ARCH_MAY_HAVE_PC_FDC

I've no particular preference for any particular prefix above
conciseness.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: HAVE or ARCH_HAS or ARCH_SUPPORTS and use of select

[Mathieu Desnoyers]

* Sam Ravnborg (sam@ravnborg.org) wrote:
> I just asked Mathieu to use ARCH_HAS_<config-symbol>
> when an architecture should say that it uses the
> generic KPROBSE functionality.
> 
> ARCH_HAS was selected from a pure "what is most popular today"
> grep of the kernel source.
> 
> It is used roughly like this:
> 
> *Generic Kconfig file:*
> config KPROBES
> 	depends on ARCH_HAS_KPROBES
> 	bool "bla bla"
> 
> # let arch that support KPROBES select the below symbol.
> # Note: no dependencies allowed on ARCH_HAS_ symbols!
> config ARCH_HAS_KPROBES
> 	def_bool n
> 
> *Arch specific Kconfig file:*
> config X86
> 	select ARCH_HAS_KPROBES
> 
> 
> But I felt a bit uneasy with the wording "ARCH_HAS" because
> in reality it is "ARCH_USES" or "ARCH_SUPPORTS" because
> in this case X86 uses the generic KPROBES functionality
> or maybe it just supports it.
> On the config level do we really want to ditingush between "HAS",
> "SUPPORTS", "USE" and whatever the next person come up with?
> 
> automake and friends uses HAVE_ and I dunno about other tools.
> 

FWIW, I've used "NEED_*" in my LTTng patchset to specify when an
architecture needs support from an architecture independent module. (it
could be an alternative to USE_*).

Mathieu

> Could we come up with a naming that fits the current usages we
> could standardize on this.
> When we have it defined I will update kconfig-language.txt
> and try to chase people that fail to use the naming scheme.
> (Or I will ask Randy to do it so it is readable for humans..)
> 
> For x86 for instance there is potential for some cleaning and likewise
> in other archs.
> 
> 	Sam
> 

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: HAVE or ARCH_HAS or ARCH_SUPPORTS and use of select

[Sam Ravnborg]

On Thu, Nov 15, 2007 at 07:21:51AM -0500, Mathieu Desnoyers wrote:
> 
> FWIW, I've used "NEED_*" in my LTTng patchset to specify when an
> architecture needs support from an architecture independent module. (it
> could be an alternative to USE_*).

The situations we need to cover are:

1) An architecture uses or support a generic implementation
   Examples: KPROBES, GENERIC_TIME

2) An architecture uses a specific functionality
   Examples: MMU

3) Architecture provide a specific functionality
   Examples: ARCH_HAS_ILOG2_U32, ARCH_HAS_ILOG2_U64

4) A driver is supported by a subset of the architectures
   Example: config EDAC
                   depends on X86 || PPC


I'm very tempted to go with the suggestion of Russell and
say that the naming is the very generic:
HAVE_<config-symbol>

We know it from the auto-tools (albeit that could be a reason to avoid it)
And we can hardly put wrong interpretations in the HAVE_ thing.

	Sam

Re: HAVE or ARCH_HAS or ARCH_SUPPORTS and use of select

[Geert Uytterhoeven]

On Thu, 15 Nov 2007, Sam Ravnborg wrote:
> On Thu, Nov 15, 2007 at 07:21:51AM -0500, Mathieu Desnoyers wrote:
> > 
> > FWIW, I've used "NEED_*" in my LTTng patchset to specify when an
> > architecture needs support from an architecture independent module. (it
> > could be an alternative to USE_*).
> 
> The situations we need to cover are:

> 2) An architecture uses a specific functionality
>    Examples: MMU

That's always been just CONFIG_MMU.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: HAVE or ARCH_HAS or ARCH_SUPPORTS and use of select

[David Howells]

Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> > 2) An architecture uses a specific functionality
> >    Examples: MMU
> 
> That's always been just CONFIG_MMU.

And can be variable within an arch.

David