Skip to contentSkip to conversation

asm-generic magic

PATCH In review george anzinger 4 participants 12 messages May 6, 2003 – May 7, 2003 Kbuild

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 asm-generic magic

The attached patch changes topdir/Makefile to make the asm-generic stuff to work the way I assumed it was supposed to work. :)

That is, if the file exists in .../include/asm/ use that one, if not and it exist in .../include/asm-generic/ use the generic one. This is compatable with current conventions but also allows asm files that do nothing but include the asm-generic file with the same name to go away. The "magic" is to supply both include and include/asm-generic to CPP. This causes it, when looking for <asm/foo.h> to look first in ...include/asm/ and then in .../include/asm-generic/asm. To make the ladder work we put a link (called asm) in asm-generic to point to ".".

Commits?

Signature · 3 lines
George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
Makefile renamed from Makefile~ +6 -2
@@ -181,7 +181,7 @@
 
 NOSTDINC_FLAGS  = -nostdinc -iwithprefix include
 
-CPPFLAGS	:= -D__KERNEL__ -Iinclude
+CPPFLAGS	:= -D__KERNEL__ -Iinclude -Iinclude/generic-asm
 CFLAGS 		:= $(CPPFLAGS) -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \
 	  	   -fno-strict-aliasing -fno-common
 AFLAGS		:= -D__ASSEMBLY__ $(CPPFLAGS)
@@ -403,7 +403,7 @@
 #	module versions are listed in "prepare"
 
 .PHONY: prepare
-prepare: include/linux/version.h include/asm include/config/MARKER
+prepare: include/linux/version.h include/asm include/config/MARKER include/asm-generic/asm
 ifdef KBUILD_MODULES
 ifeq ($(origin SUBDIRS),file)
 	$(Q)rm -rf $(MODVERDIR)
@@ -453,6 +453,10 @@
 	@echo '  Making asm->asm-$(ARCH) symlink'
 	@ln -s asm-$(ARCH) $@
 
+include/asm-generic/asm:
+	@echo '  Making asm-generic/asm->. symlink'
+	@ln -s . $@
+
 # 	Split autoconf.h into include/linux/config/*
 
 include/config/MARKER: scripts/split-include include/linux/autoconf.h

child process exited abnormally

#1 lore raw
Quoted 2 lines · george anzinger

That is, if the file exists in .../include/asm/ use that one, if not and it exist in .../include/asm-generic/ use the generic one.

This is not at all how this stuff is supposed to work.

You must include them from the asm-${ARCH}/foo.h file.

Please, don't create this setup.

Signature · 1 line
David S. Miller <[email protected]>
#2 lore raw
Quoted 6 lines · David S. Miller
Quoted 1 line · george anzinger

That is, if the file exists in .../include/asm/ use that one, if not and it exist in .../include/asm-generic/ use the generic one.

This is not at all how this stuff is supposed to work.

Um, where might one learn how it is _supposed_ to work?

Quoted 2 lines

You must include them from the asm-${ARCH}/foo.h file.

That still works with this patch, same as with out it.

Quoted 3 lines

Please, don't create this setup.

Signature · 3 lines
George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
#3 lore raw

From: george anzinger <[email protected]>
Date: Tue, 06 May 2003 13:15:05 -0700

Quoted 1 line · David S. Miller

This is not at all how this stuff is supposed to work.

Um, where might one learn how it is _supposed_ to work?

By looking at existing uses.

Some files provide partial APIs, other files are "configured' by the asm-ARCH/foo.h header before being included.

#4 lore raw
Quoted 4 lines · David S. Miller

From: george anzinger <[email protected]>
Date: Tue, 06 May 2003 13:15:05 -0700

David S. Miller wrote:

Quoted 9 lines
Quoted 1 line

This is not at all how this stuff is supposed to work.

Um, where might one learn how it is _supposed_ to work?

By looking at existing uses.

Some files provide partial APIs, other files are "configured' by the asm-ARCH/foo.h header before being included.

Yes, I am aware of existing use. Sometimes the asm file just includes the generic with no additional content. It is these that go away.
This also means that an arch need not supply the asm version UNTIL it has one that does it better. This might be useful if one wanted to supply a u64 = u64 * u32 mpy, for example. This can be done in C, but is rather costly. An arch could supply the asm version at a later time, but for the short haul, the generic gets them on the air.

If the arch wanted to supply only some of the content, the configure option as is used with some today, is still available. CURRENT USAGE IS NOT AFFECTED.

As to "_supposed_ to work", I rather though we were making this up as we went along, as long as we don't change existing usage, and even, sometimes, that rule is not honored :)

Quoted 1 line
Signature · 3 lines
George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
#5 lore raw
Quoted 3 lines · george anzinger

If the arch wanted to supply only some of the content, the configure option as is used with some today, is still available. CURRENT USAGE IS NOT AFFECTED.

The usage of magic symlinks shall be kept minimal.
The asm -> $(ARCH)-asm symlink already has caused me troubles when doing cross compilation. Also the separate obj tree patch treats the symlink with special care.

the gain should be high introducing one more symlink. For what I understood the gain is only to avoid a couple of one line files that inculde another file. Not enough to justify a second symlink IMHO.

Sam

#6 lore raw
Quoted 5 lines · Sam Ravnborg
Quoted 1 line · george anzinger

If the arch wanted to supply only some of the content, the configure option as is used with some today, is still available. CURRENT USAGE IS NOT AFFECTED.

Quoted 7 lines

The usage of magic symlinks shall be kept minimal. The asm -> $(ARCH)-asm symlink already has caused me troubles when doing cross compilation. Also the separate obj tree patch treats
the symlink with special care.

the gain should be high introducing one more symlink.
For what I understood the gain is only to avoid a couple of
one line files that include another file. Not enough to justify a second symlink IMHO.

That is a good point. To the other side, the symlink is arch independent and is just "asm->." Also, if you are introducing a file with asm code, you either cause all "other" archs to fail (till they catch up) or you must introduce the simple one line file in each arch.

Signature · 3 lines
George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
#7 lore raw

From: george anzinger <[email protected]>
Date: Wed, 07 May 2003 08:08:38 -0700

Also, if you are introducing a file with asm code, you either cause all "other" archs to fail (till they catch up) or you must introduce the simple one line file in each arch.

This is desirable behavior, then the arch maintainer sees the breakage and if the asm-generic solution is appropriate he makes that decision.

I don't think you want to play expert for port maintainers.

I sense that you want to be able to do "instant ports" to some architecture. This isn't the way to do it. Instead tar up a template set of asm-foo/ header files, and dump that into the directory for your new port.

I see absolutely no value whatsoever to what you are proposing. In fact, I frankly think it sucks. :(

#8 lore raw
Quoted 11 lines · David S. Miller

From: george anzinger <[email protected]>
Date: Wed, 07 May 2003 08:08:38 -0700

Also, if you are introducing a file with asm code, you either cause all "other" archs to fail (till they catch up) or you must introduce the simple one line file in each arch.

This is desirable behavior, then the arch maintainer sees the breakage and if the asm-generic solution is appropriate he makes that decision.

Quoted 6 lines

I don't think you want to play expert for port maintainers.

I sense that you want to be able to do "instant ports" to some architecture. This isn't the way to do it. Instead tar up a template set of asm-foo/ header files, and dump that into the directory for your new port.

For the record, I don't and have not done ports.

Rather I was interested in introducing a scaled math header. It would contain routines to allow access to the 64 bit mpy and div instructions, which ,of course, can be done in C but, if you don't want the 64-bit lib, must be done with a rather large bit of code to do simple s32=s64/s32 and s32=s64%s32 calculations. And, on 64-bit archs the whole problem goes away.

Quoted 3 lines

I see absolutely no value whatsoever to what you are proposing. In fact, I frankly think it sucks. :(

I understand what you think, but don't understand why you think that :(

Quoted 2 lines
Signature · 3 lines
George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
#9 lore raw

From: george anzinger <[email protected]>
Date: Wed, 07 May 2003 08:33:27 -0700

Rather I was interested in introducing a scaled math header. It would contain routines to allow access to the 64 bit mpy and div instructions, which ,of course, can be done in C but, if you don't want the 64-bit lib, must be done with a rather large bit of code to do simple s32=s64/s32 and s32=s64%s32 calculations. And, on 64-bit archs the whole problem goes away.

I think you want to do something more like what the byteorder swabbing interfaces do. Let the arch override whatever it'd like to optimize, but provide default 32-bit/64-bit centric "implementations" under linux/scaled_math/

#10 lore raw

Kbuild newbie/promotional docs needed

In reply to Sam Ravnborg

Hi all,

I have an organization called the Linux Society, and I am helping the Devil-Linux.org group (of sourceforge) develop their second generation firewall CD boot linux.

We have been kicking around a custom ISO build kit using Webmin, and, kernal compile configuration will have to be part of the equation. I am wildly guessing that I am in the right place for getting the modules !!

Quoting the sourceforge site:

" Last updated 2001-Apr-15 by mec.
I suck at html ... that's why the page loads so fast! "

As I have not had time to play with the kit yet, I am hoping for some generalized information which I can provide to my membership.

Do any of you have any rough notes or embryonic pages ??

I should mention that Devil-Linux is X phobic, requiring text applications ultimately wrapped in www perl cgi scripts.

BTW, I should mention that my own embryonic support service will soon become my degree project.

Thanks in advance,

John

http://groups.yahoo.com/group/linux-society/join

=====
CXN, Inc. Contact: [email protected]
President, The Linux Society
http://groups.yahoo.com/group/linux-society
linux society distro -> http://www.thinman.com/eLSD/readme
ThinMan is a registered trademark of CXN, Inc

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

#11 lore raw

Re: Kbuild newbie/promotional docs needed

On Wed, May 07, 2003 at 08:24:46AM -0700, John van V. wrote:
[cc: list trimmed]

Quoted 8 lines

We have been kicking around a custom ISO build kit using Webmin, and, kernal compile configuration will have to be part of the equation. I am wildly guessing that I am in the right place for getting the modules !!

Quoting the sourceforge site:

" Last updated 2001-Apr-15 by mec.
I suck at html ... that's why the page loads so fast! "

Could you try to rephrase your question a bit - I do not understand what you are asking about, neither what sourceforge site you refer to.

Sam