ARCH_HAS / HAVE_ARCH

["Randy.Dunlap" <rdunlap@xenotime.net>]

On Mon, 3 Jul 2006 10:13:12 -0700 (PDT) Linus Torvalds wrote:

> On Sun, 2 Jul 2006, Andrew Morton wrote:
> > 
> > The requirement "if you implement this then you must do so as a macro" is a
> > bit regrettable.  The ARCH_HAS_HANDLE_DYNAMIC_TICK approach would eliminate
> > that requirement.
> 
> Btw, this is WRONG.
> 
> The whole "ARCH_HAS_XYZZY" is nothing but crap. It's totally unreadable, 

I agree that ARCH_HAS_* (and HAVE_ARCH_*) are unreadable.  However, the
#define xyzzy	xyzzy

solution isn't much better IMO and it will be confuzing
to people in a few years.


> compared to the _much_ simpler
> 
> 	#ifndef xyzzy
> 	#define zyzzy() /* empty */
> 	#endif
> 
> which is a hell of a lot more obvious to everybody involved, not to 
> mention being a lot easier to "grep" for (try it - "grep xyzzy" ends up 
> showing _exactly_ what is going on for cases like this, unlike the 
> ARCH_HAS_XYZZY crap).
> 
> And no, it does not require implementing xyzzy as a macro AT ALL. 
> 
> You can very easily just do
> 
> 	/*
> 	 * We have a very complex xyzzy, we don't even want to
> 	 * inline it!
> 	 */
> 	extern void xyxxy(...);
> 
> 	/* Tell the rest of the world that we do it! */
> 	#define xyzzy xyzzy
> 
> and you're now all set. No need for a new stupid name like ARCH_HAS_XYZZY, 
> which adds _nothing_ but unnecessary complexity ("What was the condition 
> for using that symbol again?" and ungreppability).
> 
> WE SHOULD GET RID OF ARCH_HAS_XYZZY. It's a disease.

I have about 10 patches ready, but I'm not terribly happy with them.
Using Kconfig symbols for some of them seems more appropriate to me,
i.e., moving the symbol definitions from "random" header files to
Kconfig files.  After all, these are just hidden config settings.

Would that be acceptable?

---
~Randy
-
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/