Hi all...
Long time ago noticed this, but did not remember to report till this night:
x86 seems to build altivec source files for md checksums:
CC drivers/md/raid6recov.o
CC fs/partitions/ldm.o
CC fs/proc/task_mmu.o
HOSTCC drivers/md/mktables
CC net/core/dev_mcast.o
UNROLL drivers/md/raid6int1.c
UNROLL drivers/md/raid6int2.c
UNROLL drivers/md/raid6int4.c
UNROLL drivers/md/raid6int8.c
UNROLL drivers/md/raid6int16.c
CC fs/proc/inode.o
UNROLL drivers/md/raid6int32.c
UNROLL drivers/md/raid6altivec1.c
UNROLL drivers/md/raid6altivec2.c
UNROLL drivers/md/raid6altivec4.c
UNROLL drivers/md/raid6altivec8.c
CC fs/partitions/msdos.o
CC drivers/md/raid6mmx.o
CC fs/proc/root.o
CC net/core/dst.o
LD fs/partitions/built-in.o
CC net/core/neighbour.o
CC drivers/md/raid6sse1.o
(buld lines are out of order due to a make -j4)
Kernel is 2.6.14-mm2.
This is an x86 box, why does it compile raid6altivec*.c ? I suppose it
does not generate any code, because of some #ifdef magic, but why does
it build them anyways ? Looks a bit strange.
Thanks.
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.14-jam2 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))
On Sunday November 13, [email protected] wrote:
>
> Kernel is 2.6.14-mm2.
> This is an x86 box, why does it compile raid6altivec*.c ? I suppose it
> does not generate any code, because of some #ifdef magic, but why does
> it build them anyways ? Looks a bit strange.
It's probably just easier that way.
I guess you could do the following, but I'm not sure that it is really
worth it.
NeilBrown
Signed-off-by: Neil Brown <[email protected]>
diff ./drivers/md/Makefile~current~ ./drivers/md/Makefile
--- ./drivers/md/Makefile~current~ 2005-11-14 08:13:43.000000000 +1100
+++ ./drivers/md/Makefile 2005-11-14 08:23:29.000000000 +1100
@@ -8,12 +8,15 @@ dm-multipath-objs := dm-hw-handler.o dm-
dm-snapshot-objs := dm-snap.o dm-exception-store.o
dm-mirror-objs := dm-log.o dm-raid1.o
md-mod-objs := md.o bitmap.o
+raid6-$(CONFIG_ALTIVEC) := \
+ raid6altivec1.o raid6altivec2.o raid6altivec4.o \
+ raid6altivec8.o
+raid6-$(CONFIG_X86) := raid6mmx.o raid6sse1.o
+raid6-$(CONFIG_X86_64) := raid6sse2.o
raid6-objs := raid6main.o raid6algos.o raid6recov.o raid6tables.o \
raid6int1.o raid6int2.o raid6int4.o \
raid6int8.o raid6int16.o raid6int32.o \
- raid6altivec1.o raid6altivec2.o raid6altivec4.o \
- raid6altivec8.o \
- raid6mmx.o raid6sse1.o raid6sse2.o
+ $(raid6-y)
hostprogs-y := mktables
# Note: link order is important. All raid personalities
Neil Brown wrote:
> On Sunday November 13, [email protected] wrote:
>
>>Kernel is 2.6.14-mm2.
>>This is an x86 box, why does it compile raid6altivec*.c ? I suppose it
>>does not generate any code, because of some #ifdef magic, but why does
>>it build them anyways ? Looks a bit strange.
>
> It's probably just easier that way.
> I guess you could do the following, but I'm not sure that it is really
> worth it.
>
Yes, it's really just simpler. It ends up being an empty .o file on
non-altivec machines.
I don't object to changing it, but it doesn't seem worth it to change it.
-hpa
On Mon, 14 Nov 2005 08:26:45 +1100, Neil Brown <[email protected]> wrote:
> On Sunday November 13, [email protected] wrote:
> >
> > Kernel is 2.6.14-mm2.
> > This is an x86 box, why does it compile raid6altivec*.c ? I suppose it
> > does not generate any code, because of some #ifdef magic, but why does
> > it build them anyways ? Looks a bit strange.
>
> It's probably just easier that way.
> I guess you could do the following, but I'm not sure that it is really
> worth it.
>
> +raid6-$(CONFIG_X86) := raid6mmx.o raid6sse1.o
> +raid6-$(CONFIG_X86_64) := raid6sse2.o
plain x86 can also do some sse2 ;) (x2, not x4)
As X86_64 also defines plain X86, this could be just
> +raid6-$(CONFIG_X86) := raid6mmx.o raid6sse1.o raid6sse2.o
And perhaps IA64 will need this also ?
Thanks, anyways.
I will send it to Andrew, to see if it goes in.
by
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.14-jam2 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))
>
> diff ./drivers/md/Makefile~current~ ./drivers/md/Makefile
> --- ./drivers/md/Makefile~current~ 2005-11-14 08:13:43.000000000 +1100
> +++ ./drivers/md/Makefile 2005-11-14 08:23:29.000000000 +1100
> @@ -8,12 +8,15 @@ dm-multipath-objs := dm-hw-handler.o dm-
> dm-snapshot-objs := dm-snap.o dm-exception-store.o
> dm-mirror-objs := dm-log.o dm-raid1.o
> md-mod-objs := md.o bitmap.o
> +raid6-$(CONFIG_ALTIVEC) := \
> + raid6altivec1.o raid6altivec2.o raid6altivec4.o \
> + raid6altivec8.o
> +raid6-$(CONFIG_X86) := raid6mmx.o raid6sse1.o
> +raid6-$(CONFIG_X86_64) := raid6sse2.o
> raid6-objs := raid6main.o raid6algos.o raid6recov.o raid6tables.o \
Change the above line to:
> raid6-y += raid6main.o raid6algos.o raid6recov.o raid6tables.o \
> raid6int1.o raid6int2.o raid6int4.o \
> raid6int8.o raid6int16.o raid6int32.o \
> - raid6altivec1.o raid6altivec2.o raid6altivec4.o \
> - raid6altivec8.o \
> - raid6mmx.o raid6sse1.o raid6sse2.o
> + $(raid6-y)
And then you do not need to add the above line.
The Makefile deserve a small comment why you overwrite
the first assigned vaule of raid6-y - otherwise it may confuse when
reading through the file.
Sam
On Mon, 14 Nov 2005 08:26:45 +1100, Neil Brown <[email protected]> wrote:
> On Sunday November 13, [email protected] wrote:
> >
> > Kernel is 2.6.14-mm2.
> > This is an x86 box, why does it compile raid6altivec*.c ? I suppose it
> > does not generate any code, because of some #ifdef magic, but why does
> > it build them anyways ? Looks a bit strange.
>
> It's probably just easier that way.
> I guess you could do the following, but I'm not sure that it is really
> worth it.
>
> NeilBrown
>
> Signed-off-by: Neil Brown <[email protected]>
>
> diff ./drivers/md/Makefile~current~ ./drivers/md/Makefile
> --- ./drivers/md/Makefile~current~ 2005-11-14 08:13:43.000000000 +1100
> +++ ./drivers/md/Makefile 2005-11-14 08:23:29.000000000 +1100
> @@ -8,12 +8,15 @@ dm-multipath-objs := dm-hw-handler.o dm-
> dm-snapshot-objs := dm-snap.o dm-exception-store.o
> dm-mirror-objs := dm-log.o dm-raid1.o
> md-mod-objs := md.o bitmap.o
> +raid6-$(CONFIG_ALTIVEC) := \
> + raid6altivec1.o raid6altivec2.o raid6altivec4.o \
> + raid6altivec8.o
> +raid6-$(CONFIG_X86) := raid6mmx.o raid6sse1.o
> +raid6-$(CONFIG_X86_64) := raid6sse2.o
> raid6-objs := raid6main.o raid6algos.o raid6recov.o raid6tables.o \
> raid6int1.o raid6int2.o raid6int4.o \
> raid6int8.o raid6int16.o raid6int32.o \
> - raid6altivec1.o raid6altivec2.o raid6altivec4.o \
> - raid6altivec8.o \
> - raid6mmx.o raid6sse1.o raid6sse2.o
> + $(raid6-y)
Err, if I did not misundertood it, raid6-y would mean 'objects for building
raid6 in kernel', versus 'raid6-m', for objects for build as a module ?
Would not this be better:
--- Makefile.orig 2005-11-13 23:14:48.000000000 +0100
+++ Makefile 2005-11-13 23:28:05.000000000 +0100
@@ -8,12 +8,21 @@
dm-snapshot-objs := dm-snap.o dm-exception-store.o
dm-mirror-objs := dm-log.o dm-raid1.o
md-mod-objs := md.o bitmap.o
+
+
+ifeq ($(CONFIG_ALTIVEC),y)
+raid6-vec-objs := \
+ raid6altivec1.o raid6altivec2.o \
+ raid6altivec4.o raid6altivec8.o
+endif
+ifeq ($(CONFIG_X86),y)
+raid6-vec-objs := \
+ raid6mmx.o raid6sse1.o raid6sse2.o
+endif
raid6-objs := raid6main.o raid6algos.o raid6recov.o raid6tables.o \
raid6int1.o raid6int2.o raid6int4.o \
raid6int8.o raid6int16.o raid6int32.o \
- raid6altivec1.o raid6altivec2.o raid6altivec4.o \
- raid6altivec8.o \
- raid6mmx.o raid6sse1.o raid6sse2.o
+ $(raid6-vec-objs)
hostprogs-y := mktables
# Note: link order is important. All raid personalities
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.14-jam2 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))