Re: [PATCH RFC: linux-next 1/2] irq: Add CPU mask affinity hintcallback framework

From: Peter P Waskiewicz Jr
Date: Tue Apr 27 2010 - 12:04:33 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/