All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: linux-ia64@vger.kernel.org
Subject: Re: 2.5.72 for ia64 released
Date: Fri, 20 Jun 2003 17:47:44 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105613167716254@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105605890319553@msgid-missing>

diff -Nru a/arch/ia64/lib/Makefile b/arch/ia64/lib/Makefile
--- a/arch/ia64/lib/Makefile    Thu Jun 19 14:19:14 2003
+++ b/arch/ia64/lib/Makefile    Thu Jun 19 14:19:14 2003
@@ -13,6 +13,12 @@
 lib-$(CONFIG_MCKINLEY) += copy_page_mck.o memcpy_mck.o
 lib-$(CONFIG_PERFMON)  += carta_random.o

+ifeq ($(CONFIG_MD_RAID5),m)
+       lib-y += xor.o
+else
+       lib-$(CONFIG_MD_RAID5)  += xor.o
+endif
+

No need for this ifeq ....
lib-m should work as well as lib-y.
If this is not the case then let me know - I will fix kbuild then.

lib-m is actually documented!



diff -Nru a/usr/Makefile b/usr/Makefile
....
+$(obj)/initramfs_data.S: $(obj)/initramfs_data.cpio.gz
+       echo '.section ".init.ramfs", "a"' > $@
+       od -v -An -t x1 -w8 $^ | cut -c2- | sed -e s"/ /,0x/g" -e s"/^/.byte 0x"/ >> $@

Will .incbin really replace the above magic?
I have the following patch ready - but not submitted:
[Deleted trivial changes that just removed LDFLAGS_BLOB]

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1414  -> 1.1415 
#	   arch/ppc/Makefile	1.39    -> 1.40   
#	 arch/ppc64/Makefile	1.26    -> 1.27   
#	 arch/sparc/Makefile	1.23    -> 1.24   
#	 arch/h8300/Makefile	1.1     -> 1.2    
#	  arch/s390/Makefile	1.25    -> 1.26   
#	usr/initramfs_data.scr	1.1     ->         (deleted)      
#	  arch/i386/Makefile	1.52    -> 1.53   
#	        usr/Makefile	1.6     -> 1.7    
#	 arch/alpha/Makefile	1.24    -> 1.25   
#	    arch/sh/Makefile	1.16    -> 1.17   
#	arch/m68knommu/Makefile	1.7     -> 1.8    
#	arch/x86_64/Makefile	1.27    -> 1.28   
#	arch/parisc/Makefile	1.20    -> 1.21   
#	  arch/m68k/Makefile	1.11    -> 1.12   
#	arch/sparc64/Makefile	1.26    -> 1.27   
#	  arch/v850/Makefile	1.6     -> 1.7    
#	               (new)	        -> 1.1     usr/initramfs_data.S
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/06/18	sam@mars.ravnborg.org	1.1415
# usr: Create objectfile for usr filesystem using .incbin
# 
# Patch originally by HJ Lu.
# 
# The filesystem was previously embedded in a .o file using ld.
# Embedding the filesystem using ld broke as a result ia64 and maybe more
# architectures.
# 
# The better way to do this is to use the .incbin feature, as already
# used for vsyscall for i386. .incbin has the advantage that ELH header
# is correct, as required by ia64 - and maybe other archs.
# This change will break architectures relying on binutils older than
# 2.11.90.0.23 released on 2001-07-14.
# Most notably arm will break in some configurations due to this.
# The rationale behing introducing .incbin is that ia64 needs this change
# and the .incbin feature has been present in binutils for a number
# of years now.
# arm will thus have to catch up with binutils - or patch usr/Makefile
# to stay compatible with the 2.5 kernel.
# 
# The definition of LDFLAGS_BLOB removed for all architectures - it was 
# obsoleted by this change.
# Except for arm - that may require it due to the tool compatibility issue.
# --------------------------------------------
#
diff -Nru a/usr/Makefile b/usr/Makefile
--- a/usr/Makefile	Fri Jun 20 19:45:26 2003
+++ b/usr/Makefile	Fri Jun 20 19:45:26 2003
@@ -5,11 +5,10 @@
 
 clean-files := initramfs_data.cpio.gz
 
-LDFLAGS_initramfs_data.o := $(LDFLAGS_BLOB) -r -T
-
-$(obj)/initramfs_data.o: $(src)/initramfs_data.scr \
-			 $(obj)/initramfs_data.cpio.gz FORCE
-	$(call if_changed,ld)
+# initramfs_data.o contains the initramfs_data.cpio.gz image.
+# The image is included using .incbin, a dependency which is not
+# tracked automatically.
+$(obj)/initramfs_data.o: $(obj)/initramfs_data.cpio.gz FORCE
 
 # initramfs-y are the programs which will be copied into the CPIO
 # archive. Currently, the filenames are hardcoded in gen_init_cpio,
diff -Nru a/usr/initramfs_data.S b/usr/initramfs_data.S
--- /dev/null	Wed Dec 31 16:00:00 1969
+++ b/usr/initramfs_data.S	Fri Jun 20 19:45:26 2003
@@ -0,0 +1,30 @@
+/*
+  initramfs_data includes the compressed binary that is the
+  filesystem used for early user space.
+  Note: Older versions of "as" (prior to binutils 2.11.90.0.23
+  released on 2001-07-14) dit not support .incbin.
+  If you are forced to use older binutils than that then the
+  following trick can be applied to create the resulting binary:
+
+
+  ld -m elf_i386  --format binary --oformat elf32-i386 -r \
+  -T initramfs_data.scr initramfs_data.cpio.gz -o initramfs_data.o
+   ld -m elf_i386  -r -o built-in.o initramfs_data.o
+
+  initramfs_data.scr looks like this:
+SECTIONS
+{
+       .init.ramfs : { *(.data) }
+}
+
+  The above example is for i386 - the parameters vary from architectures.
+  Eventually look up LDFLAGS_BLOB in an older version of the
+  arch/$(ARCH)/Makefile to see the flags used before .incbin was introduced.
+
+  Using .incbin has the advantage over ld that the correct flags are set
+  in the ELF header, as required by certain architectures.
+*/
+
+.section .init.ramfs,"a"
+.incbin "usr/initramfs_data.cpio.gz"
+
diff -Nru a/usr/initramfs_data.scr b/usr/initramfs_data.scr
--- a/usr/initramfs_data.scr	Fri Jun 20 19:45:26 2003
+++ /dev/null	Wed Dec 31 16:00:00 1969
@@ -1,4 +0,0 @@
-SECTIONS
-{
-	.init.ramfs : { *(.data) }
-}

  parent reply	other threads:[~2003-06-20 17:47 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-19 21:39 2.5.72 for ia64 released David Mosberger
2003-06-20 11:38 ` Andreas Schwab
2003-06-20 17:11 ` Jesse Barnes
2003-06-20 17:47 ` Sam Ravnborg [this message]
2003-06-20 18:01 ` David Mosberger
2003-06-20 18:35 ` Jesse Barnes
2003-06-20 18:41 ` David Mosberger
2003-06-20 18:45 ` Jesse Barnes
2003-06-20 18:49 ` David Mosberger
2003-06-20 18:50 ` Jesse Barnes
2003-06-20 18:53 ` Jesse Barnes
2003-06-20 19:02 ` David Mosberger
2003-06-20 19:07 ` Jesse Barnes
2003-06-20 19:44 ` Andreas Schwab
2003-06-20 19:49 ` Jesse Barnes
2003-06-20 19:51 ` Andreas Schwab
2003-06-20 19:56 ` Jesse Barnes
2003-06-20 20:03 ` Alex Tsariounov
2003-06-20 20:06 ` David Mosberger
2003-06-20 20:25 ` Andreas Schwab
2003-06-20 20:28 ` Jesse Barnes
2003-06-20 20:34 ` David Mosberger
2003-06-20 20:39 ` Jesse Barnes
2003-06-20 20:40 ` Andreas Schwab
2003-06-20 20:50 ` David Mosberger
2003-06-20 20:51 ` Sam Ravnborg
2003-06-20 21:04 ` Jack Steiner
2003-06-20 21:06 ` David Mosberger
2003-06-20 21:21 ` Jesse Barnes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-ia64-105613167716254@msgid-missing \
    --to=sam@ravnborg.org \
    --cc=linux-ia64@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.