This patch fixes the following compile error with CONFIG_MD_RAID456
on avr32:
<-- snip -->
...
CC [M] crypto/xor.o
/home/bunk/linux/kernel-2.6/git/linux-2.6/crypto/xor.c:23:21: error: asm/xor.h: No such file or directory
/home/bunk/linux/kernel-2.6/git/linux-2.6/crypto/xor.c: In function 'calibrate_xor_blocks':
/home/bunk/linux/kernel-2.6/git/linux-2.6/crypto/xor.c:131: error: 'XOR_TRY_TEMPLATES' undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/git/linux-2.6/crypto/xor.c:131: error: (Each undeclared identifier is reported only once
/home/bunk/linux/kernel-2.6/git/linux-2.6/crypto/xor.c:131: error: for each function it appears in.)
make[2]: *** [crypto/xor.o] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <[email protected]>
---
601f75e99c076c16e2648f4860cac4fc6ce187ea diff --git a/include/asm-avr32/xor.h b/include/asm-avr32/xor.h
new file mode 100644
index 0000000..99c87aa
--- /dev/null
+++ b/include/asm-avr32/xor.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XOR_H
+#define _ASM_XOR_H
+
+#include <asm-generic/xor.h>
+
+#endif
* Adrian Bunk | 2008-04-14 17:16:32 [+0300]:
>This patch fixes the following compile error with CONFIG_MD_RAID456
>on avr32:
>
><-- snip -->
>
>...
> CC [M] crypto/xor.o
>/home/bunk/linux/kernel-2.6/git/linux-2.6/crypto/xor.c:23:21: error: asm/xor.h: No such file or directory
>/home/bunk/linux/kernel-2.6/git/linux-2.6/crypto/xor.c: In function 'calibrate_xor_blocks':
>/home/bunk/linux/kernel-2.6/git/linux-2.6/crypto/xor.c:131: error: 'XOR_TRY_TEMPLATES' undeclared (first use in this function)
>/home/bunk/linux/kernel-2.6/git/linux-2.6/crypto/xor.c:131: error: (Each undeclared identifier is reported only once
>/home/bunk/linux/kernel-2.6/git/linux-2.6/crypto/xor.c:131: error: for each function it appears in.)
>make[2]: *** [crypto/xor.o] Error 1
>
><-- snip -->
>
>Signed-off-by: Adrian Bunk <[email protected]>
>
>---
>601f75e99c076c16e2648f4860cac4fc6ce187ea diff --git a/include/asm-avr32/xor.h b/include/asm-avr32/xor.h
>new file mode 100644
>index 0000000..99c87aa
>--- /dev/null
>+++ b/include/asm-avr32/xor.h
>@@ -0,0 +1,6 @@
>+#ifndef _ASM_XOR_H
>+#define _ASM_XOR_H
>+
>+#include <asm-generic/xor.h>
>+
>+#endif
What about providing <linux/xor.h> which includes the right file from
asm/ or asm-generic/ depending on HAVE_.* ?
Sebastian
On Mon, Apr 14, 2008 at 08:11:40PM +0200, Sebastian Siewior wrote:
> * Adrian Bunk | 2008-04-14 17:16:32 [+0300]:
>
> >This patch fixes the following compile error with CONFIG_MD_RAID456
> >on avr32:
> >
> ><-- snip -->
> >
> >...
> > CC [M] crypto/xor.o
> >/home/bunk/linux/kernel-2.6/git/linux-2.6/crypto/xor.c:23:21: error: asm/xor.h: No such file or directory
> >/home/bunk/linux/kernel-2.6/git/linux-2.6/crypto/xor.c: In function 'calibrate_xor_blocks':
> >/home/bunk/linux/kernel-2.6/git/linux-2.6/crypto/xor.c:131: error: 'XOR_TRY_TEMPLATES' undeclared (first use in this function)
> >/home/bunk/linux/kernel-2.6/git/linux-2.6/crypto/xor.c:131: error: (Each undeclared identifier is reported only once
> >/home/bunk/linux/kernel-2.6/git/linux-2.6/crypto/xor.c:131: error: for each function it appears in.)
> >make[2]: *** [crypto/xor.o] Error 1
> >
> ><-- snip -->
> >
> >Signed-off-by: Adrian Bunk <[email protected]>
> >
> >---
> >601f75e99c076c16e2648f4860cac4fc6ce187ea diff --git a/include/asm-avr32/xor.h b/include/asm-avr32/xor.h
> >new file mode 100644
> >index 0000000..99c87aa
> >--- /dev/null
> >+++ b/include/asm-avr32/xor.h
> >@@ -0,0 +1,6 @@
> >+#ifndef _ASM_XOR_H
> >+#define _ASM_XOR_H
> >+
> >+#include <asm-generic/xor.h>
> >+
> >+#endif
>
> What about providing <linux/xor.h> which includes the right file from
> asm/ or asm-generic/ depending on HAVE_.* ?
Where's the advantage?
> Sebastian
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
* Adrian Bunk | 2008-04-14 21:15:36 [+0300]:
>> >601f75e99c076c16e2648f4860cac4fc6ce187ea diff --git a/include/asm-avr32/xor.h b/include/asm-avr32/xor.h
>> >new file mode 100644
>> >index 0000000..99c87aa
>> >--- /dev/null
>> >+++ b/include/asm-avr32/xor.h
>> >@@ -0,0 +1,6 @@
>> >+#ifndef _ASM_XOR_H
>> >+#define _ASM_XOR_H
>> >+
>> >+#include <asm-generic/xor.h>
>> >+
>> >+#endif
>>
>> What about providing <linux/xor.h> which includes the right file from
>> asm/ or asm-generic/ depending on HAVE_.* ?
>
>Where's the advantage?
This week you are going through avr32. The same fixup is required for
blackfin or cris if my ls isn't lying. So either you fix every arch
with this missing include or you provide a generic include and every
arch that provides a private xor.h includes it. From what I can see
almost every arch includes the generic except for x86 & sparc so most
xor.h files are identical copies and this is probably as bad as a
trailing white space :)
>
>cu
>Adrian
Sebastian
On Mon, Apr 14, 2008 at 5:46 PM, Sebastian Siewior
<[email protected]> wrote:
> * Adrian Bunk | 2008-04-14 21:15:36 [+0300]:
> >> >601f75e99c076c16e2648f4860cac4fc6ce187ea diff --git a/include/asm-avr32/xor.h b/include/asm-avr32/xor.h
> >> >new file mode 100644
> >> >index 0000000..99c87aa
> >> >--- /dev/null
> >> >+++ b/include/asm-avr32/xor.h
> >> >@@ -0,0 +1,6 @@
> >> >+#ifndef _ASM_XOR_H
> >> >+#define _ASM_XOR_H
> >> >+
> >> >+#include <asm-generic/xor.h>
> >> >+
> >> >+#endif
> >>
> >> What about providing <linux/xor.h> which includes the right file from
> >> asm/ or asm-generic/ depending on HAVE_.* ?
> >
> >Where's the advantage?
>
> This week you are going through avr32. The same fixup is required for
> blackfin or cris if my ls isn't lying. So either you fix every arch
> with this missing include or you provide a generic include and every
> arch that provides a private xor.h includes it. From what I can see
> almost every arch includes the generic except for x86 & sparc so most
> xor.h files are identical copies and this is probably as bad as a
> trailing white space :)
indeed. the less work for arches the better :).
-mike
On Mon, Apr 14, 2008 at 11:46:40PM +0200, Sebastian Siewior wrote:
> * Adrian Bunk | 2008-04-14 21:15:36 [+0300]:
>
> >> >601f75e99c076c16e2648f4860cac4fc6ce187ea diff --git a/include/asm-avr32/xor.h b/include/asm-avr32/xor.h
> >> >new file mode 100644
> >> >index 0000000..99c87aa
> >> >--- /dev/null
> >> >+++ b/include/asm-avr32/xor.h
> >> >@@ -0,0 +1,6 @@
> >> >+#ifndef _ASM_XOR_H
> >> >+#define _ASM_XOR_H
> >> >+
> >> >+#include <asm-generic/xor.h>
> >> >+
> >> >+#endif
> >>
> >> What about providing <linux/xor.h> which includes the right file from
> >> asm/ or asm-generic/ depending on HAVE_.* ?
> >
> >Where's the advantage?
>
> This week you are going through avr32. The same fixup is required for
> blackfin or cris if my ls isn't lying.
Could be, these arre the two archs I did for different reasons not
include when I tried allmodconfig on all archs.
> So either you fix every arch
> with this missing include or you provide a generic include and every
> arch that provides a private xor.h includes it. From what I can see
> almost every arch includes the generic except for x86 & sparc
You didn't see that the following architectures also have their own
versions:
- alpha
- arm
- ia64
- sparc64
> so most
> xor.h files are identical copies and this is probably as bad as a
> trailing white space :)
I'm not sure whether it's worth spending my time discussing whether
adding a config variable to 6 architectures is really better than
adding trivial headers to 3 architectures...
> Sebastian
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, Apr 14, 2008 at 6:01 PM, Adrian Bunk <[email protected]> wrote:
> On Mon, Apr 14, 2008 at 11:46:40PM +0200, Sebastian Siewior wrote:
> > so most
> > xor.h files are identical copies and this is probably as bad as a
> > trailing white space :)
>
> I'm not sure whether it's worth spending my time discussing whether
> adding a config variable to 6 architectures is really better than
> adding trivial headers to 3 architectures...
long term robustness for new ports/codedrops indicates that having a
common header in linux/ and making arches opt-in via Kconfig/whatever
makes life a lot easier for everyone
everything builds by default with the generic C versions and arches
dont have to go through and figure out all the fun little stub files
they need to straight copy from other architectures ... they only have
to care if they want to implement an optimized version
-mike
On Mon, Apr 14, 2008 at 3:11 PM, Mike Frysinger <[email protected]> wrote:
> On Mon, Apr 14, 2008 at 6:01 PM, Adrian Bunk <[email protected]> wrote:
> > On Mon, Apr 14, 2008 at 11:46:40PM +0200, Sebastian Siewior wrote:
>
> > > so most
> > > xor.h files are identical copies and this is probably as bad as a
> > > trailing white space :)
> >
> > I'm not sure whether it's worth spending my time discussing whether
> > adding a config variable to 6 architectures is really better than
> > adding trivial headers to 3 architectures...
>
> long term robustness for new ports/codedrops indicates that having a
> common header in linux/ and making arches opt-in via Kconfig/whatever
> makes life a lot easier for everyone
>
> everything builds by default with the generic C versions and arches
> dont have to go through and figure out all the fun little stub files
> they need to straight copy from other architectures ... they only have
> to care if they want to implement an optimized version
"arches" did not have to go through and figure out the fun little stub
file for xor.h. Adrian already made your "life easier".
--
Dan
On Mon, Apr 14, 2008 at 6:27 PM, Dan Williams <[email protected]> wrote:
> On Mon, Apr 14, 2008 at 3:11 PM, Mike Frysinger <[email protected]> wrote:
> > On Mon, Apr 14, 2008 at 6:01 PM, Adrian Bunk <[email protected]> wrote:
> > > On Mon, Apr 14, 2008 at 11:46:40PM +0200, Sebastian Siewior wrote:
> > > > so most
> > > > xor.h files are identical copies and this is probably as bad as a
> > > > trailing white space :)
> > >
> > > I'm not sure whether it's worth spending my time discussing whether
> > > adding a config variable to 6 architectures is really better than
> > > adding trivial headers to 3 architectures...
> >
> > long term robustness for new ports/codedrops indicates that having a
> > common header in linux/ and making arches opt-in via Kconfig/whatever
> > makes life a lot easier for everyone
> >
> > everything builds by default with the generic C versions and arches
> > dont have to go through and figure out all the fun little stub files
> > they need to straight copy from other architectures ... they only have
> > to care if they want to implement an optimized version
>
> "arches" did not have to go through and figure out the fun little stub
> file for xor.h. Adrian already made your "life easier".
actually he didnt. he posted a fix for avr32. i dont care about
avr32, i'm a blackfin guy. he also wouldnt have had to do anything at
all if everything was handled with indirection in linux/xor.h.
your point also is irrelevant in the case of new architectures. poor
microblaze for example.
-mike
On Mon, Apr 14, 2008 at 3:30 PM, Mike Frysinger <[email protected]> wrote:
> On Mon, Apr 14, 2008 at 6:27 PM, Dan Williams <[email protected]> wrote:
> > "arches" did not have to go through and figure out the fun little stub
> > file for xor.h. Adrian already made your "life easier".
>
> actually he didnt. he posted a fix for avr32. i dont care about
> avr32, i'm a blackfin guy. he also wouldnt have had to do anything at
> all if everything was handled with indirection in linux/xor.h.
>
> your point also is irrelevant in the case of new architectures. poor
> microblaze for example.
>
Don't get me wrong I see the pain-reducing-value in codifying all the
features that have architecture specific aspects with HAVE_* config
variables. But in this case I think a 6 line patch per new arch gets
the immediate job done.
Regards,
Dan
On Mon, Apr 14, 2008 at 7:45 PM, Dan Williams <[email protected]> wrote:
> On Mon, Apr 14, 2008 at 3:30 PM, Mike Frysinger <[email protected]> wrote:
> > On Mon, Apr 14, 2008 at 6:27 PM, Dan Williams <[email protected]> wrote:
> > > "arches" did not have to go through and figure out the fun little stub
> > > file for xor.h. Adrian already made your "life easier".
> >
> > actually he didnt. he posted a fix for avr32. i dont care about
> > avr32, i'm a blackfin guy. he also wouldnt have had to do anything at
> > all if everything was handled with indirection in linux/xor.h.
> >
> > your point also is irrelevant in the case of new architectures. poor
> > microblaze for example.
>
> Don't get me wrong I see the pain-reducing-value in codifying all the
> features that have architecture specific aspects with HAVE_* config
> variables. But in this case I think a 6 line patch per new arch gets
> the immediate job done.
sure ... i see the original patch as OK to get things working now
(especially as that is how the xor stuff is currently architected).
bigger picture is to go the common route proposed by Sebastian. now
just need to sucker someone into doing the footwork :).
-mike