Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755635Ab0D0QEa (ORCPT ); Tue, 27 Apr 2010 12:04:30 -0400 Received: from mga11.intel.com ([192.55.52.93]:7401 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755433Ab0D0QE1 (ORCPT ); Tue, 27 Apr 2010 12:04:27 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.52,280,1270450800"; d="scan'208";a="561967134" Date: Tue, 27 Apr 2010 09:04:25 -0700 (Pacific Daylight Time) From: Peter P Waskiewicz Jr To: Thomas Gleixner cc: "davem@davemloft.net" , "arjan@linux.jf.intel.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH RFC: linux-next 1/2] irq: Add CPU mask affinity hint callback framework In-Reply-To: Message-ID: References: <20100419045741.30276.23233.stgit@ppwaskie-hc2.jf.intel.com> X-X-Sender: ppwaskie@imapmail.glb.intel.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2151 Lines: 58 On Tue, 27 Apr 2010, Thomas Gleixner wrote: > On Sun, 18 Apr 2010, Peter P Waskiewicz Jr wrote: >> +/** >> + * struct irqaffinityhint - per interrupt affinity helper >> + * @callback: device driver callback function >> + * @dev: reference for the affected device >> + * @irq: interrupt number >> + */ >> +struct irqaffinityhint { >> + irq_affinity_hint_t callback; >> + void *dev; >> + int irq; >> +}; > > Why do you need that extra data structure ? The device and the irq > number are known, so all you need is the callback itself. So no need > for allocating memory .... When I register the function callback with the interrupt layer, I need to know what device structures to reference back in the driver. In other words, if I call into an underlying driver with just an interrupt number, then I have no way at getting at the dev structures (netdevice for me, plus my private adapter structures), unless I declare them globally (yuck). I had a different approach before this one where I assumed the device from the irq handler callback was safe to use for the device in this new callback. I didn't feel really great about that, since it's an implicit assumption that could cause things to go sideways really quickly. Let me know what you think either way. I'm certainly willing to make a change, I just don't know at this point what's the safest approach from what I currently have. > >> +static ssize_t irq_affinity_hint_proc_write(struct file *file, >> + const char __user *buffer, size_t count, loff_t *pos) >> +{ >> + /* affinity_hint is read-only from proc */ >> + return -EOPNOTSUPP; >> +} >> + > > Why do you want a write function when the file is read only ? It's leftover paranoia. I put it in early on, then changed the mode later. I can remove this function. I'll re-send something once we agree on how the code in your first comment should look. Thanks Thomas! -PJ -- 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/