Re: Linux 2.4.25-pre4

Re: Linux 2.4.25-pre4

[Andrzej Krzysztofowicz]

Andrzej Krzysztofowicz wrote:
>From ankry@sunrise.pg.gda.pl  Wed Jan  7 16:31:11 2004
Return-Path: <ankry@sunrise.pg.gda.pl>
Received: from sunrise.pg.gda.pl (root@sunrise.pg.gda.pl [153.19.40.230])
	by green.mif.pg.gda.pl (8.12.10/8.12.6) with ESMTP id i07FVBo0032429
	for <ankry@green.mif.pg.gda.pl>; Wed, 7 Jan 2004 16:31:11 +0100
Received: from sunrise.pg.gda.pl (localhost [127.0.0.1])
	by sunrise.pg.gda.pl (8.12.10/8.12.9) with ESMTP id i07FV6DJ005180
	for <ankry@green.mif.pg.gda.pl>; Wed, 7 Jan 2004 16:31:06 +0100 (CET)
Received: (from ankry@localhost)
	by sunrise.pg.gda.pl (8.12.10/8.12.9/Submit) id i07FV4VW005179
	for ankry@green.mif.pg.gda.pl; Wed, 7 Jan 2004 16:31:04 +0100 (CET)
From: Andrzej Krzysztofowicz <ankry@pg.gda.pl>
Message-Id: <200401071531.i07FV4VW005179@sunrise.pg.gda.pl>
Subject: Re: Linux 2.4.25-pre4 (fwd)
To: ankry@green.mif.pg.gda.pl
Date: Wed, 7 Jan 104 16:31:04 +0100 (CET)
Content-Type: text

"F wrote:"
>From linux-kernel-owner+ankry=40pg.gda.pl@vger.kernel.org  Tue Jan  6 18:34:02 2004
X-BrightmailFiltered: true
Date: Tue, 6 Jan 2004 18:30:17 +0100
From: Kronos <kronos@kronoz.cjb.net>
To: linux-kernel@vger.kernel.org
Cc: Matt Domsch <Matt_Domsch@dell.com>,
        Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Subject: Re: Linux 2.4.25-pre4
Message-ID: <20040106173017.GA10755@dreamland.darkstar.lan>
Reply-To: kronos@kronoz.cjb.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040106102819.A12626@lists.us.dell.com>
User-Agent: Mutt/1.4i
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
X-Spam-Checker-Version: SpamAssassin 2.70-cvs (1.218-2003-11-09-exp) on 
	mordred.oi.pg.gda.pl
X-Spam-Level: 
X-Spam-Status: No, hits=0.3 required=5.0 tests=UPPERCASE_25_50 autolearn=no 
	version=2.70-cvs

Matt Domsch <Matt_Domsch@dell.com> ha scritto:
>> Trying to compile $subj with following config (these options seem to
>> cause the problem, full config attached):
>> 
>> CONFIG_SCSI_MEGARAID=y
>> CONFIG_SCSI_MEGARAID2=y
>>
>> Is this a known issue and megaraids can't live together, or am I
>> supposed to be able to compile both drivers in and this is a bug?
> 
> yes, this is known and expected.  You can build both as modules, but
> they're not intended to both be loaded simultaneously (either built-in
> or as modules).  They're mutually exclusive.

Ok, what about this patch (against 2.4.25-pre4):

--- linux-2.4/drivers/scsi/Config.in.orig	Tue Jan  6 18:11:10 2004
+++ linux-2.4/drivers/scsi/Config.in	Tue Jan  6 18:23:29 2004
@@ -66,8 +66,13 @@
 dep_tristate 'AdvanSys SCSI support' CONFIG_SCSI_ADVANSYS $CONFIG_SCSI
 dep_tristate 'Always IN2000 SCSI support' CONFIG_SCSI_IN2000 $CONFIG_SCSI
 dep_tristate 'AM53/79C974 PCI SCSI support' CONFIG_SCSI_AM53C974 $CONFIG_SCSI $CONFIG_PCI
-dep_tristate 'AMI MegaRAID support' CONFIG_SCSI_MEGARAID $CONFIG_SCSI
-dep_tristate 'AMI MegaRAID2 support' CONFIG_SCSI_MEGARAID2 $CONFIG_SCSI
+
+if [ "$CONFIG_SCSI_MEGARAID2" == "n" -o "$CONFIG_SCSI_MEGARAID2" == "" ]; then
+  dep_tristate 'AMI MegaRAID support' CONFIG_SCSI_MEGARAID $CONFIG_SCSI
+fi
+if [ "$CONFIG_SCSI_MEGARAID" == "n" -o "$CONFIG_SCSI_MEGARAID" == "" ]; then
+  dep_tristate 'AMI MegaRAID2 support' CONFIG_SCSI_MEGARAID2 $CONFIG_SCSI
+fi
 
 dep_tristate 'BusLogic SCSI support' CONFIG_SCSI_BUSLOGIC $CONFIG_SCSI
 if [ "$CONFIG_SCSI_BUSLOGIC" != "n" ]; then


I'm not very familiar with 2.4 config language, maybe there's a better
way to do it.

Luca
-- 
Reply-To: kronos@kronoz.cjb.net
Home: http://kronoz.cjb.net
Carpe diem, quam minimum credula postero. (Q. Horatius Flaccus)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry@mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Gdansk University of Technology

about ipmr

[Joilnen Leite]

excuse me for my english bad :) !

alloc_netdev func can return NULL and I think that is
not right to use dev pointer in this case without a
test.
so maybe it is better ? !

---------------------------------------------

--- knl_src/net/ipv4/ipmr.c	2003-11-25
16:02:59.000000000 -0300
+++ ipmr_patch.c	2004-01-08 10:21:22.000000000 -0300
@@ -205,7 +205,7 @@
 	dev = alloc_netdev(sizeof(struct net_device_stats),
"pimreg",
 			   reg_vif_setup);
 
-	if (register_netdevice(dev)) {
+	if (dev&&register_netdevice(dev)) {
 		kfree(dev);
 		return NULL;
 	}

----------------------------------------------

sorry if is a dumb question and thanks for atention

pub  1024D/5139533E Joilnen Batista Leite 
F565 BD0B 1A39 390D 827E  03E5 0CD4 0F20 5139 533E


__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

Re: about ipmr

[Raj]

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

I would prefer this way of checking the NULL

That would be more consistent with ip_gre.c and ipip.c

any suggestions ?

/Raj


[-- Attachment #2: ipmr.patch --]
[-- Type: text/plain, Size: 349 bytes --]

--- ipmr.c.org	2004-01-09 12:07:45.271713432 +0530
+++ ipmr.c	2004-01-09 12:09:39.389364912 +0530
@@ -205,6 +205,9 @@ static struct net_device *ipmr_reg_vif(v
 	dev = alloc_netdev(sizeof(struct net_device_stats), "pimreg",
 			   reg_vif_setup);
 
+	if( dev == NULL)
+		return NULL;
+
 	if (register_netdevice(dev)) {
 		kfree(dev);
 		return NULL;

Re: about ipmr

[James Morris]

On Fri, 9 Jan 2004, Raj wrote:

> I would prefer this way of checking the NULL
> 
> That would be more consistent with ip_gre.c and ipip.c
> 
> any suggestions ?

Yes, this is much better form.


- James
-- 
James Morris
<jmorris@redhat.com>

Re: about ipmr

[David S. Miller]

On Fri, 09 Jan 2004 12:11:39 +0530
Raj <obelix123@toughguy.net> wrote:

> I would prefer this way of checking the NULL
> 
> That would be more consistent with ip_gre.c and ipip.c

Patch applied, thank you.