netdev - Re: [PATCH 1/14 v2] nes: module and device initialization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <adatzodxxxw.fsf@cisco.com>
Date:	Fri, 26 Oct 2007 16:23:23 -0700
From:	Roland Dreier <rdreier@...co.com>
To:	ggrundstrom@...effect.com
Cc:	ewg@...ts.openfabrics.org, general@...ts.openfabrics.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH 1/14 v2] nes: module and device initialization

OK, a couple quick review comments and a process comment too:

 - First step in the driver is to kill off a lot of the #ifdefs:

 > +#ifdef IRQF_SHARED

The upstream driver really shouldn't have compatibility gunk for older
kernels... just make it build against the kernel it's in.

 > +#ifdef OFED_1_2

Same... kernel code shouldn't worry about OFED.

 > +#ifdef CONFIG_PCI_MSI
 > +	if (nesdev->msi_enabled) {
 > +		pci_disable_msi(pcidev);
 > +	}
 > +#endif

This can be much simpler, because pci_disable_msi() is always
available and is a NOP if the config option is off or MSI is not
enabled.  So you can just unconditionally do

	pci_disable_msi(pcidev);

 > +#ifdef NES_NAPI

I don't see anything that defines NES_NAPI.  I think for the final
merge we want a NAPI-only driver (ie no ifdef at all)... is there any
performance or other reason to ever build a non-NAPI driver (for a
modern kernel)?

OK, on a process level, my plan is to pull the current driver into a
"neteffect" branch in my git tree with the intention of merging it for
2.6.25.  I'll let you know when that's ready (probably early next
week).  I'll probably do some cleanups there, and you can send me
cleanup/fix patches against that branch any time too.  We should try
to keep the cycle time short: the interval between the first posting
of this driver and the current one was pretty long, and there's a lot
of cleanup to do to get ready for the next merge window.  Does that
plan make sense?

 - R.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html