[patch] 2.6.9-rc1-mm1: megaraid_mbox.c compile error with gcc 3.4

[patch] 2.6.9-rc1-mm1: megaraid_mbox.c compile error with gcc 3.4

[Adrian Bunk]

On Thu, Aug 26, 2004 at 01:47:45AM -0700, Andrew Morton wrote:
>...
> All patches:
>...
> bk-scsi.patch
>...

This results in many compile errors when using gcc 3.4 starting with the 
following:

<--  snip  -->

...
  CC      drivers/scsi/megaraid/megaraid_mbox.o
drivers/scsi/megaraid/megaraid_mbox.c: In function `megaraid_queue_command':
drivers/scsi/megaraid/megaraid_mbox.c:114: sorry, unimplemented: inlining failed
 in call to 'megaraid_mbox_build_cmd': function body not available
drivers/scsi/megaraid/megaraid_mbox.c:1410: sorry, unimplemented: called from here
drivers/scsi/megaraid/megaraid_mbox.c:123: sorry, unimplemented: inlining failed
 in call to 'megaraid_mbox_runpendq': function body not available
drivers/scsi/megaraid/megaraid_mbox.c:1413: sorry, unimplemented: called from here
make[3]: *** [drivers/scsi/megaraid/megaraid_mbox.o] Error 1

<--  snip  -->


The patch fixes this by removing the inline's from all functions where 
the inline function was called before it was defined.

An alterenate approach would be to reorder the file to move all inline'd 
functions above their first callers.


diffstat output:
 drivers/scsi/megaraid/megaraid_mbox.c |   44 +++++++++++++-------------
 1 files changed, 22 insertions(+), 22 deletions(-)



Signed-off-by: Adrian Bunk <bunk@fs.tum.de>

--- linux-2.6.9-rc1-mm1-full-3.4/drivers/scsi/megaraid/megaraid_mbox.c.old	2004-08-28 10:21:20.000000000 +0200
+++ linux-2.6.9-rc1-mm1-full-3.4/drivers/scsi/megaraid/megaraid_mbox.c	2004-08-28 10:31:23.000000000 +0200
@@ -110,26 +110,26 @@
 static int megaraid_queue_command(struct scsi_cmnd *,
 		void (*)(struct scsi_cmnd *));
 
-static inline scb_t *megaraid_mbox_build_cmd(adapter_t *, struct scsi_cmnd *,
+static scb_t *megaraid_mbox_build_cmd(adapter_t *, struct scsi_cmnd *,
 		int *);
-static inline scb_t *megaraid_alloc_scb(adapter_t *, struct scsi_cmnd *);
-static inline void megaraid_dealloc_scb(adapter_t *, scb_t *);
-static inline void megaraid_mbox_prepare_pthru(adapter_t *, scb_t *,
+static scb_t *megaraid_alloc_scb(adapter_t *, struct scsi_cmnd *);
+static void megaraid_dealloc_scb(adapter_t *, scb_t *);
+static void megaraid_mbox_prepare_pthru(adapter_t *, scb_t *,
 		struct scsi_cmnd *);
-static inline void megaraid_mbox_prepare_epthru(adapter_t *, scb_t *,
+static void megaraid_mbox_prepare_epthru(adapter_t *, scb_t *,
 		struct scsi_cmnd *);
-static inline int megaraid_mbox_mksgl(adapter_t *, scb_t *);
+static int megaraid_mbox_mksgl(adapter_t *, scb_t *);
 
-static inline void megaraid_mbox_runpendq(adapter_t *, scb_t *);
-static inline int mbox_post_cmd(adapter_t *, scb_t *);
+static void megaraid_mbox_runpendq(adapter_t *, scb_t *);
+static int mbox_post_cmd(adapter_t *, scb_t *);
 
 static void megaraid_mbox_dpc(unsigned long);
-static inline void megaraid_mbox_sync_scb(adapter_t *, scb_t *);
+static void megaraid_mbox_sync_scb(adapter_t *, scb_t *);
 
 static irqreturn_t megaraid_isr(int, void *, struct pt_regs *);
-static inline int megaraid_ack_sequence(adapter_t *);
+static int megaraid_ack_sequence(adapter_t *);
 
-static inline int megaraid_busywait_mbox(mraid_device_t *);
+static int megaraid_busywait_mbox(mraid_device_t *);
 
 static int megaraid_cmm_register(adapter_t *);
 static int megaraid_cmm_unregister(adapter_t *);
@@ -1434,7 +1434,7 @@
  * convert the command issued by mid-layer to format understood by megaraid
  * firmware. We also complete certain command without sending them to firmware
  */
-static inline scb_t *
+static scb_t *
 megaraid_mbox_build_cmd(adapter_t *adapter, struct scsi_cmnd *scp, int *busy)
 {
 	mraid_device_t		*rdev = ADAP2RAIDDEV(adapter);
@@ -1809,7 +1809,7 @@
  * return the scb from the head of the free list. NULL if there are none
  * available
  **/
-static inline scb_t *
+static scb_t *
 megaraid_alloc_scb(adapter_t *adapter, struct scsi_cmnd *scp)
 {
 	struct list_head	*head = &adapter->kscb_pool;
@@ -1847,7 +1847,7 @@
  * NOTE NOTE: Make sure the scb is not on any list before calling this
  * routine.
  **/
-static inline void
+static void
 megaraid_dealloc_scb(adapter_t *adapter, scb_t *scb)
 {
 	unsigned long		flags;
@@ -1873,7 +1873,7 @@
  *
  * prepare a command for the scsi physical devices
  */
-static inline void
+static void
 megaraid_mbox_prepare_pthru(adapter_t *adapter, scb_t *scb,
 		struct scsi_cmnd *scp)
 {
@@ -1921,7 +1921,7 @@
  * prepare a command for the scsi physical devices. This rountine prepares
  * commands for devices which can take extended CDBs (>10 bytes)
  */
-static inline void
+static void
 megaraid_mbox_prepare_epthru(adapter_t *adapter, scb_t *scb,
 		struct scsi_cmnd *scp)
 {
@@ -1967,7 +1967,7 @@
  *
  * prepare the scatter-gather list
  */
-static inline int
+static int
 megaraid_mbox_mksgl(adapter_t *adapter, scb_t *scb)
 {
 	struct scatterlist	*sgl;
@@ -2046,7 +2046,7 @@
  * out from the head of the pending list. If it is successfully issued, the
  * next SCB is at the head now.
  */
-static inline void
+static void
 megaraid_mbox_runpendq(adapter_t *adapter, scb_t *scb_q)
 {
 	scb_t			*scb;
@@ -2116,7 +2116,7 @@
  *
  * post the command to the controller if mailbox is availble.
  */
-static inline int
+static int
 mbox_post_cmd(adapter_t *adapter, scb_t *scb)
 {
 	mraid_device_t	*raid_dev = ADAP2RAIDDEV(adapter);
@@ -2218,7 +2218,7 @@
  *
  * Returns:	1 if the interrupt is valid, 0 otherwise
  */
-static inline int
+static int
 megaraid_ack_sequence(adapter_t *adapter)
 {
 	mraid_device_t		*raid_dev = ADAP2RAIDDEV(adapter);
@@ -2556,7 +2556,7 @@
  *
  * DMA sync if required.
  */
-static inline void
+static void
 megaraid_mbox_sync_scb(adapter_t *adapter, scb_t *scb)
 {
 	mbox_ccb_t	*ccb;
@@ -3069,7 +3069,7 @@
  * wait until the controller's mailbox is available to accept more commands.
  * wait for at most 1 second
  */
-static inline int
+static int
 megaraid_busywait_mbox(mraid_device_t *raid_dev)
 {
 	mbox_t	*mbox = raid_dev->mbox;

RE: [patch] 2.6.9-rc1-mm1: megaraid_mbox.c compile error with gcc 3.4

[Mukker, Atul]

The driver and the patches with the re-ordered functions is available at
ftp://ftp.lsil.com/pub/linux-megaraid/drivers/version-2.20.3.1/

Please merge to the lk 2.6.8.1 using
ftp://ftp.lsil.com/pub/linux-megaraid/drivers/version-2.20.3.1/megaraid2.20.
3.1-lk2.6.8.1.patch.gz or upgrade the existing 2.20.3.0 driver in
2.6.9-rc1-mm1 to 2.20.3.1 using
ftp://ftp.lsil.com/pub/linux-megaraid/drivers/version-2.20.3.1/megaraid2.20.
3.0-2.20.3.1.patch.gz

Thanks
-Atul Mukker

> -----Original Message-----
> From: Adrian Bunk [mailto:bunk@fs.tum.de]
> Sent: Saturday, August 28, 2004 5:07 AM
> To: Andrew Morton; Atul.Mukker@lsil.com; Sreenivas.Bagalkote@lsil.com;
> Manoj.Jose@lsil.com
> Cc: linux-kernel@vger.kernel.org; James.Bottomley@SteelEye.com;
> linux-scsi@vger.kernel.org
> Subject: [patch] 2.6.9-rc1-mm1: megaraid_mbox.c compile error with gcc
> 3.4
> 
> 
> On Thu, Aug 26, 2004 at 01:47:45AM -0700, Andrew Morton wrote:
> >...
> > All patches:
> >...
> > bk-scsi.patch
> >...
> 
> This results in many compile errors when using gcc 3.4 
> starting with the 
> following:
> 
> <--  snip  -->
> 
> ...
>   CC      drivers/scsi/megaraid/megaraid_mbox.o
> drivers/scsi/megaraid/megaraid_mbox.c: In function 
> `megaraid_queue_command':
> drivers/scsi/megaraid/megaraid_mbox.c:114: sorry, 
> unimplemented: inlining failed
>  in call to 'megaraid_mbox_build_cmd': function body not available
> drivers/scsi/megaraid/megaraid_mbox.c:1410: sorry, 
> unimplemented: called from here
> drivers/scsi/megaraid/megaraid_mbox.c:123: sorry, 
> unimplemented: inlining failed
>  in call to 'megaraid_mbox_runpendq': function body not available
> drivers/scsi/megaraid/megaraid_mbox.c:1413: sorry, 
> unimplemented: called from here
> make[3]: *** [drivers/scsi/megaraid/megaraid_mbox.o] Error 1
> 
> <--  snip  -->
> 
> 
> The patch fixes this by removing the inline's from all 
> functions where 
> the inline function was called before it was defined.
> 
> An alterenate approach would be to reorder the file to move 
> all inline'd 
> functions above their first callers.
> 
> 
> diffstat output:
>  drivers/scsi/megaraid/megaraid_mbox.c |   44 
> +++++++++++++-------------
>  1 files changed, 22 insertions(+), 22 deletions(-)
> 
> 
> 
> Signed-off-by: Adrian Bunk <bunk@fs.tum.de>
> 
> --- 
> linux-2.6.9-rc1-mm1-full-3.4/drivers/scsi/megaraid/megaraid_mb
> ox.c.old	2004-08-28 10:21:20.000000000 +0200
> +++ 
> linux-2.6.9-rc1-mm1-full-3.4/drivers/scsi/megaraid/megaraid
> _mbox.c	2004-08-28 10:31:23.000000000 +0200
> @@ -110,26 +110,26 @@
>  static int megaraid_queue_command(struct scsi_cmnd *,
>  		void (*)(struct scsi_cmnd *));
>  
> -static inline scb_t *megaraid_mbox_build_cmd(adapter_t *, 
> struct scsi_cmnd *,
> +static scb_t *megaraid_mbox_build_cmd(adapter_t *, struct 
> scsi_cmnd *,
>  		int *);
> -static inline scb_t *megaraid_alloc_scb(adapter_t *, struct 
> scsi_cmnd *);
> -static inline void megaraid_dealloc_scb(adapter_t *, scb_t *);
> -static inline void megaraid_mbox_prepare_pthru(adapter_t *, scb_t *,
> +static scb_t *megaraid_alloc_scb(adapter_t *, struct scsi_cmnd *);
> +static void megaraid_dealloc_scb(adapter_t *, scb_t *);
> +static void megaraid_mbox_prepare_pthru(adapter_t *, scb_t *,
>  		struct scsi_cmnd *);
> -static inline void megaraid_mbox_prepare_epthru(adapter_t *, scb_t *,
> +static void megaraid_mbox_prepare_epthru(adapter_t *, scb_t *,
>  		struct scsi_cmnd *);
> -static inline int megaraid_mbox_mksgl(adapter_t *, scb_t *);
> +static int megaraid_mbox_mksgl(adapter_t *, scb_t *);
>  
> -static inline void megaraid_mbox_runpendq(adapter_t *, scb_t *);
> -static inline int mbox_post_cmd(adapter_t *, scb_t *);
> +static void megaraid_mbox_runpendq(adapter_t *, scb_t *);
> +static int mbox_post_cmd(adapter_t *, scb_t *);
>  
>  static void megaraid_mbox_dpc(unsigned long);
> -static inline void megaraid_mbox_sync_scb(adapter_t *, scb_t *);
> +static void megaraid_mbox_sync_scb(adapter_t *, scb_t *);
>  
>  static irqreturn_t megaraid_isr(int, void *, struct pt_regs *);
> -static inline int megaraid_ack_sequence(adapter_t *);
> +static int megaraid_ack_sequence(adapter_t *);
>  
> -static inline int megaraid_busywait_mbox(mraid_device_t *);
> +static int megaraid_busywait_mbox(mraid_device_t *);
>  
>  static int megaraid_cmm_register(adapter_t *);
>  static int megaraid_cmm_unregister(adapter_t *);
> @@ -1434,7 +1434,7 @@
>   * convert the command issued by mid-layer to format 
> understood by megaraid
>   * firmware. We also complete certain command without 
> sending them to firmware
>   */
> -static inline scb_t *
> +static scb_t *
>  megaraid_mbox_build_cmd(adapter_t *adapter, struct scsi_cmnd 
> *scp, int *busy)
>  {
>  	mraid_device_t		*rdev = ADAP2RAIDDEV(adapter);
> @@ -1809,7 +1809,7 @@
>   * return the scb from the head of the free list. NULL if 
> there are none
>   * available
>   **/
> -static inline scb_t *
> +static scb_t *
>  megaraid_alloc_scb(adapter_t *adapter, struct scsi_cmnd *scp)
>  {
>  	struct list_head	*head = &adapter->kscb_pool;
> @@ -1847,7 +1847,7 @@
>   * NOTE NOTE: Make sure the scb is not on any list before 
> calling this
>   * routine.
>   **/
> -static inline void
> +static void
>  megaraid_dealloc_scb(adapter_t *adapter, scb_t *scb)
>  {
>  	unsigned long		flags;
> @@ -1873,7 +1873,7 @@
>   *
>   * prepare a command for the scsi physical devices
>   */
> -static inline void
> +static void
>  megaraid_mbox_prepare_pthru(adapter_t *adapter, scb_t *scb,
>  		struct scsi_cmnd *scp)
>  {
> @@ -1921,7 +1921,7 @@
>   * prepare a command for the scsi physical devices. This 
> rountine prepares
>   * commands for devices which can take extended CDBs (>10 bytes)
>   */
> -static inline void
> +static void
>  megaraid_mbox_prepare_epthru(adapter_t *adapter, scb_t *scb,
>  		struct scsi_cmnd *scp)
>  {
> @@ -1967,7 +1967,7 @@
>   *
>   * prepare the scatter-gather list
>   */
> -static inline int
> +static int
>  megaraid_mbox_mksgl(adapter_t *adapter, scb_t *scb)
>  {
>  	struct scatterlist	*sgl;
> @@ -2046,7 +2046,7 @@
>   * out from the head of the pending list. If it is 
> successfully issued, the
>   * next SCB is at the head now.
>   */
> -static inline void
> +static void
>  megaraid_mbox_runpendq(adapter_t *adapter, scb_t *scb_q)
>  {
>  	scb_t			*scb;
> @@ -2116,7 +2116,7 @@
>   *
>   * post the command to the controller if mailbox is availble.
>   */
> -static inline int
> +static int
>  mbox_post_cmd(adapter_t *adapter, scb_t *scb)
>  {
>  	mraid_device_t	*raid_dev = ADAP2RAIDDEV(adapter);
> @@ -2218,7 +2218,7 @@
>   *
>   * Returns:	1 if the interrupt is valid, 0 otherwise
>   */
> -static inline int
> +static int
>  megaraid_ack_sequence(adapter_t *adapter)
>  {
>  	mraid_device_t		*raid_dev = ADAP2RAIDDEV(adapter);
> @@ -2556,7 +2556,7 @@
>   *
>   * DMA sync if required.
>   */
> -static inline void
> +static void
>  megaraid_mbox_sync_scb(adapter_t *adapter, scb_t *scb)
>  {
>  	mbox_ccb_t	*ccb;
> @@ -3069,7 +3069,7 @@
>   * wait until the controller's mailbox is available to 
> accept more commands.
>   * wait for at most 1 second
>   */
> -static inline int
> +static int
>  megaraid_busywait_mbox(mraid_device_t *raid_dev)
>  {
>  	mbox_t	*mbox = raid_dev->mbox;
> 

Re: [patch] 2.6.9-rc1-mm1: megaraid_mbox.c compile error with gcc 3.4

[Andrew Morton]

"Mukker, Atul" <Atulm@lsil.com> wrote:
>
> The driver and the patches with the re-ordered functions is available at
>  ftp://ftp.lsil.com/pub/linux-megaraid/drivers/version-2.20.3.1/

I dunno about James, but I *really* dislike receiving patches by going and
getting them from internet servers.  It breaks our commonly-used tools.  It
loses authorship info.  It loses Signed-off-by: info.  There is no
changelog.  All this means that your patch is more likely to be ignored by
busy people.  Please, just email the diffs.

I wrote a little guide this week:



The perfect patch.  akpm@osdl.org

The latest version of this document may be found at
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt

Delivery
========

- Patches are delivered via email only.  Downloading them from internet
  servers is a pain.

- One patch per email, with the changelog in the body of the email.

Subject:
========

- The email's Subject: should consisely describe the patch which that email
  contains.  The Subject: should not be a filename.  Do not use the same
  Subject: for every patch in a whole patch series.

  Bear in mind that the Subject: of your email becomes a globally-unique
  identifier for that patch.  It propagates all the way into BitKeeper.  The
  Subject: may later be used in developer discussions which refer to the
  patch.  People will want to google for the patch's Subject: to read
  discussion regarding that patch.

- When sending a series of patches, the patches should be sequence-numbered
  in the Subject:

- It is nice if the Subject: includes mention of the subsystem which it
  affects.  See example below.

- Example Subject:

	[patch 2/5] ext2: improve scalability of bitmap searching

- Note that various people's patch receiving scripts will strip away
  Subject: text which is inside brackets [].  So you should place information
  which has no long-term relevance to the patch inside brackets.  This
  includes the word "patch" and any sequence numbering.  The subsystem
  identifier ("ext2:") should hence be outside brackets.


Changelog
=========

- Bear in mind that the Subject: and changelog which you provide will
  propagate all the way into the permanent kernel record.  Other developers
  will want to read and understand your patch and changelog years in the
  future.

  So the changelog should describe the patch fully:

  - why the kernel needed patching

  - the overall design approach in the patch

  - implementation details

  - testing results

- Don't bother mentioning what version of the kernel the patch applies to
  ("applies to 2.6.8-rc1").  This is not interesting information - once the
  patch is in bitkeeper, of _course_ it applied, and it'll probably be merged
  into a later kernel than the one which you wrote it for.

- Do not refer to earlier patches when changelogging a new version of a
  patch.  It's not very useful to have a bitkeeper changelog which says "OK,
  this fixes the things you mentioned yesterday".  Each iteration of the patch
  should contain a standalone changelog.  This implies that you need a patch
  management system which maintains changelogs.  See below.

- Add a Signed-off-by: line.

- Most people's patch receiving scripts will treat a ^--- string as the
  separator between the changelog and the patch itself.  You can use this to
  ensure that any diffstat information is discarded when the patch is applied:



	Another few #if/#ifdef cleanups, this time for the PPC architecture.

	Signed-off-by: <valdis.kletnieks@vt.edu>
	Signed-off-by: Andrew Morton <akpm@osdl.org>
	---

	 25-akpm/arch/ppc/kernel/process.c                    |    2 +-
	 25-akpm/arch/ppc/platforms/85xx/mpc85xx_cds_common.c |    2 +-
	 25-akpm/arch/ppc/syslib/ppc85xx_setup.c              |    4 ++--
	 3 files changed, 4 insertions(+), 4 deletions(-)

	--- 25/arch/ppc/kernel/process.c
	+++ 25/arch/ppc/kernel/process.c
	@@ -667,7 +667,7 @@ void show_stack(struct task_struct *tsk,


The diff
========

- Patches should be in `patch -p1' form:

  --- a/kernel/sched.c
  +++ b/kernel/sched.c

- Make sure that your patches apply to the latest version of the kernel
  tree.  Either straight from bitkeeper or from
  ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/

- When raising patches for -mm it's generally best to base them on the
  latest Linus tree.  I'll work out any rejects/incompatibilities.  There are
  of course exceptions to this.

- Ensure that your patch does not add new trailing whitespace.  The below
  script will fix up your patch by stripping off such whitespace.

	#!/bin/sh

	strip1()
	{
		TMP=$(mktemp /tmp/XXXXXX)
		cp $1 $TMP
		sed -e '/^+/s/[ 	]*$//' < $TMP > $1
		rm $TMP
	}

	for i in $*
	do
		strip1 $i
	done


Overall
=======

- Avoid MIME and attachements if possible.  Make sure that your email client
  does not wordwrap your patch.  Make sure that your email client does not
  replace tabs with spaces.

  Mail yourself a decent-sized patch and check that it still applies.



The patch management scripts at http://www.zip.com.au/~akpm/linux/patches/
implement all of the above.

The patch management tools at https://savannah.nongnu.org/projects/quilt/ also
implement all of the above.

Re: [patch] 2.6.9-rc1-mm1: megaraid_mbox.c compile error with gcc 3.4

[Lee Revell]

On Sat, 2004-08-28 at 16:04, Andrew Morton wrote:
> "Mukker, Atul" <Atulm@lsil.com> wrote:
> >
> > The driver and the patches with the re-ordered functions is available at
> >  ftp://ftp.lsil.com/pub/linux-megaraid/drivers/version-2.20.3.1/
> 
> I dunno about James, but I *really* dislike receiving patches by going and
> getting them from internet servers.  It breaks our commonly-used tools.  It
> loses authorship info.  It loses Signed-off-by: info.  There is no
> changelog.  All this means that your patch is more likely to be ignored by
> busy people.  Please, just email the diffs.
> 

The FAQ should be updated, as it recommends posting a link to large
patches, rather than splitting them up and posting that way.

Of course, there is a lot in the FAQ that needs updating...

Lee

Re: [patch] 2.6.9-rc1-mm1: megaraid_mbox.c compile error with gcc 3.4

[James Bottomley]

On Sat, 2004-08-28 at 16:04, Andrew Morton wrote:
> I dunno about James, but I *really* dislike receiving patches by going and
> getting them from internet servers.  It breaks our commonly-used tools.  It
> loses authorship info.  It loses Signed-off-by: info.  There is no
> changelog.  All this means that your patch is more likely to be ignored by
> busy people.  Please, just email the diffs.

Yes, I dislike it, but I've learned to live with downloading...

The Megaraid patch set, by the way, annoys me even more by not actually
applying to the kernel tree.  it doesn't reflect the fact that the
Changelog.megaraid is under Documentation/scsi not drivers/scsi.

However, it's all merged into the vanilla kernel now but in future, if
you could follow Andrew's guide, I'd be very grateful.

James

RE: [patch] 2.6.9-rc1-mm1: megaraid_mbox.c compile error with gcc 3.4

[Mukker, Atul]

Andrew,

Thanks for the insight into the patch release process. We will make sure we
adhere to this process in future. I do have some concerns though:

1.	The initial announcement (see my mail on 8/24) did inline the
changelog and the patch against the previous version of the driver was sent
as attachment. I did mistakenly not add linux-scsi though.

2.	The guideline on the size of patches. Because of the new driver, the
size of the patches for megaraid are relatively big (the small patches are
always inlined). Should it be discretionary for submitter to either inline,
attach, or (deprecated) send a link, based on size of the package.

Thanks
-Atul Mukker

> -----Original Message-----
> From: Andrew Morton [mailto:akpm@osdl.org]
> Sent: Saturday, August 28, 2004 4:04 PM
> To: Mukker, Atul
> Cc: bunk@fs.tum.de; Atulm@lsil.com; sreenib@lsil.com; Manojj@lsil.com;
> linux-kernel@vger.kernel.org; James.Bottomley@SteelEye.com;
> linux-scsi@vger.kernel.org
> Subject: Re: [patch] 2.6.9-rc1-mm1: megaraid_mbox.c compile error with
> gcc 3.4
> 
> 
> "Mukker, Atul" <Atulm@lsil.com> wrote:
> >
> > The driver and the patches with the re-ordered functions is 
> available at
> >  ftp://ftp.lsil.com/pub/linux-megaraid/drivers/version-2.20.3.1/
> 
> I dunno about James, but I *really* dislike receiving patches 
> by going and
> getting them from internet servers.  It breaks our 
> commonly-used tools.  It
> loses authorship info.  It loses Signed-off-by: info.  There is no
> changelog.  All this means that your patch is more likely to 
> be ignored by
> busy people.  Please, just email the diffs.
> 
> I wrote a little guide this week:
> 
> 
> 
> The perfect patch.  akpm@osdl.org
> 
> The latest version of this document may be found at
> http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
> 
> Delivery
> ========
> 
> - Patches are delivered via email only.  Downloading them 
> from internet
>   servers is a pain.
> 
> - One patch per email, with the changelog in the body of the email.
> 
> Subject:
> ========
> 
> - The email's Subject: should consisely describe the patch 
> which that email
>   contains.  The Subject: should not be a filename.  Do not 
> use the same
>   Subject: for every patch in a whole patch series.
> 
>   Bear in mind that the Subject: of your email becomes a 
> globally-unique
>   identifier for that patch.  It propagates all the way into 
> BitKeeper.  The
>   Subject: may later be used in developer discussions which 
> refer to the
>   patch.  People will want to google for the patch's Subject: to read
>   discussion regarding that patch.
> 
> - When sending a series of patches, the patches should be 
> sequence-numbered
>   in the Subject:
> 
> - It is nice if the Subject: includes mention of the 
> subsystem which it
>   affects.  See example below.
> 
> - Example Subject:
> 
> 	[patch 2/5] ext2: improve scalability of bitmap searching
> 
> - Note that various people's patch receiving scripts will strip away
>   Subject: text which is inside brackets [].  So you should 
> place information
>   which has no long-term relevance to the patch inside brackets.  This
>   includes the word "patch" and any sequence numbering.  The subsystem
>   identifier ("ext2:") should hence be outside brackets.
> 
> 
> Changelog
> =========
> 
> - Bear in mind that the Subject: and changelog which you provide will
>   propagate all the way into the permanent kernel record.  
> Other developers
>   will want to read and understand your patch and changelog 
> years in the
>   future.
> 
>   So the changelog should describe the patch fully:
> 
>   - why the kernel needed patching
> 
>   - the overall design approach in the patch
> 
>   - implementation details
> 
>   - testing results
> 
> - Don't bother mentioning what version of the kernel the 
> patch applies to
>   ("applies to 2.6.8-rc1").  This is not interesting 
> information - once the
>   patch is in bitkeeper, of _course_ it applied, and it'll 
> probably be merged
>   into a later kernel than the one which you wrote it for.
> 
> - Do not refer to earlier patches when changelogging a new 
> version of a
>   patch.  It's not very useful to have a bitkeeper changelog 
> which says "OK,
>   this fixes the things you mentioned yesterday".  Each 
> iteration of the patch
>   should contain a standalone changelog.  This implies that 
> you need a patch
>   management system which maintains changelogs.  See below.
> 
> - Add a Signed-off-by: line.
> 
> - Most people's patch receiving scripts will treat a ^--- 
> string as the
>   separator between the changelog and the patch itself.  You 
> can use this to
>   ensure that any diffstat information is discarded when the 
> patch is applied:
> 
> 
> 
> 	Another few #if/#ifdef cleanups, this time for the PPC 
> architecture.
> 
> 	Signed-off-by: <valdis.kletnieks@vt.edu>
> 	Signed-off-by: Andrew Morton <akpm@osdl.org>
> 	---
> 
> 	 25-akpm/arch/ppc/kernel/process.c                    |    2 +-
> 	 25-akpm/arch/ppc/platforms/85xx/mpc85xx_cds_common.c |    2 +-
> 	 25-akpm/arch/ppc/syslib/ppc85xx_setup.c              | 
>    4 ++--
> 	 3 files changed, 4 insertions(+), 4 deletions(-)
> 
> 	--- 25/arch/ppc/kernel/process.c
> 	+++ 25/arch/ppc/kernel/process.c
> 	@@ -667,7 +667,7 @@ void show_stack(struct task_struct *tsk,
> 
> 
> The diff
> ========
> 
> - Patches should be in `patch -p1' form:
> 
>   --- a/kernel/sched.c
>   +++ b/kernel/sched.c
> 
> - Make sure that your patches apply to the latest version of 
> the kernel
>   tree.  Either straight from bitkeeper or from
>   ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/
> 
> - When raising patches for -mm it's generally best to base them on the
>   latest Linus tree.  I'll work out any 
> rejects/incompatibilities.  There are
>   of course exceptions to this.
> 
> - Ensure that your patch does not add new trailing 
> whitespace.  The below
>   script will fix up your patch by stripping off such whitespace.
> 
> 	#!/bin/sh
> 
> 	strip1()
> 	{
> 		TMP=$(mktemp /tmp/XXXXXX)
> 		cp $1 $TMP
> 		sed -e '/^+/s/[ 	]*$//' < $TMP > $1
> 		rm $TMP
> 	}
> 
> 	for i in $*
> 	do
> 		strip1 $i
> 	done
> 
> 
> Overall
> =======
> 
> - Avoid MIME and attachements if possible.  Make sure that 
> your email client
>   does not wordwrap your patch.  Make sure that your email 
> client does not
>   replace tabs with spaces.
> 
>   Mail yourself a decent-sized patch and check that it still applies.
> 
> 
> 
> The patch management scripts at 
> http://www.zip.com.au/~akpm/linux/patches/
> implement all of the above.
> 
> The patch management tools at 
> https://savannah.nongnu.org/projects/quilt/ also
> implement all of the above.
> 

Re: [patch] 2.6.9-rc1-mm1: megaraid_mbox.c compile error with gcc 3.4

[Andrew Morton]

"Mukker, Atul" <Atulm@lsil.com> wrote:
>
> 2.	The guideline on the size of patches. Because of the new driver, the
>  size of the patches for megaraid are relatively big (the small patches are
>  always inlined). Should it be discretionary for submitter to either inline,
>  attach, or (deprecated) send a link, based on size of the package.

Sending a URL to a big patch is a necessary evil for mailing lists, so the
best approach would be to also mail the patches directly to the guy(s) who
you wish to apply them.

An even better approach is to split the patches up so they are not so big ;)

Following the "once concept per patch rule" works well.

Re: [patch] 2.6.9-rc1-mm1: megaraid_mbox.c compile error with gcc 3.4

[Daniel Phillips]

Hi Andrew,

On Saturday 28 August 2004 16:04, Andrew Morton wrote:
> - Example Subject:
>
> 	[patch 2/5] ext2: improve scalability of bitmap searching
>
> - Note that various people's patch receiving scripts will strip away
>   Subject: text which is inside brackets [].  So you should place
>   information which has no long-term relevance to the patch inside brackets. 
>   This includes the word "patch" and any sequence numbering.  The subsystem
>   identifier ("ext2:") should hence be outside brackets.

One nit: if you do it this way then when people sort their mail by subject 
they end up with tossed subject salad, with your 2/5 sitting next to a whole 
bunch of other people's 2/5's.  So:

    [patch] ext2: improve scalability of bitmap searching [2/5]

Regards,

Daniel