[PATCH] asm-generic magic

[PATCH] asm-generic magic

[george anzinger]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]



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?

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml


[-- Attachment #2: asm-generic.patch --]
[-- Type: text/plain, Size: 1096 bytes --]

--- linux-2.5.69-wq/Makefile~	2003-05-05 15:33:30.000000000 -0700
+++ linux/Makefile	2003-05-05 18:00:42.000000000 -0700
@@ -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

Re: [PATCH] asm-generic magic

[David S. Miller]

On Mon, 2003-05-05 at 23:41, george anzinger wrote:
> 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.

-- 
David S. Miller <davem@redhat.com>

Re: [PATCH] asm-generic magic

[george anzinger]

David S. Miller wrote:
> On Mon, 2003-05-05 at 23:41, george anzinger wrote:
> 
>>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?
> 
> You must include them from the asm-${ARCH}/foo.h file.

That still works with this patch, same as with out it.
> 
> Please, don't create this setup.
> 

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

Re: [PATCH] asm-generic magic

[David S. Miller]

   From: george anzinger <george@mvista.com>
   Date: Tue, 06 May 2003 13:15:05 -0700

   David S. Miller wrote:
   > 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.

Re: [PATCH] asm-generic magic

[george anzinger]

David S. Miller wrote:
>    From: george anzinger <george@mvista.com>
>    Date: Tue, 06 May 2003 13:15:05 -0700
> 
>    David S. Miller wrote:
>    > 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 :)
> 

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

Re: [PATCH] asm-generic magic

[Sam Ravnborg]

On Wed, May 07, 2003 at 02:35:42AM -0700, george anzinger wrote:
> 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

Re: [PATCH] asm-generic magic

[george anzinger]

Sam Ravnborg wrote:
> On Wed, May 07, 2003 at 02:35:42AM -0700, george anzinger wrote:
> 
>>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 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.

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

Re: [PATCH] asm-generic magic

[David S. Miller]

   From: george anzinger <george@mvista.com>
   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. :(

Re: [PATCH] asm-generic magic

[george anzinger]

David S. Miller wrote:
>    From: george anzinger <george@mvista.com>
>    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.

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.
> 
> 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 :(
> 
> 

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

Re: [PATCH] asm-generic magic

[David S. Miller]

   From: george anzinger <george@mvista.com>
   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/

Kbuild newbie/promotional docs needed

[John van V.]

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: john@thinman.com
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

Re: Kbuild newbie/promotional docs needed

[Sam Ravnborg]

On Wed, May 07, 2003 at 08:24:46AM -0700, John van V. wrote:
[cc: list trimmed]
> 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