netdev - Re: [net-next 02/11] igb: Use node specific allocations for the q

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] [day] [month] [year] [list]

Date:	Mon, 10 Oct 2011 13:50:28 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	alexander.h.duyck@...el.com
Cc:	jeffrey.t.kirsher@...el.com, netdev@...r.kernel.org,
	gospo@...hat.com, sassmann@...hat.com
Subject: Re: [net-next 02/11] igb: Use node specific allocations for the
 q_vectors and rings

From: Alexander Duyck <alexander.h.duyck@...el.com>
Date: Mon, 10 Oct 2011 09:15:02 -0700

> Actually the main reason for having adapter->node is because in our
> out-of-tree driver we end up using it as a module parameter in the event
> that someone is running in single queue mode and wants to split up the
> ports between nodes.  As such I would prefer to keep the parameter
> around and just default it to -1 as I am currently doing.  However if it
> must go I guess I can work around that sync-up issue.

Please stop adding such hacks to your out-of-tree driver and add
appropriate, generic, configure mechanisms to the upstream tree.

It absolutely is not appropriate to add something which is completely
useless to the upstream tree for the sake of something being done
only externally.

You guys are the best at upstream net driver maintainence, so it
really surprises me that you continue to do completely unacceptable
crap like this.  Write the necessary generic non-module-option
mechanisms to facilitate the features you need and kill your out of
tree driver _now_.
--
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