> . > > In addition the cases I can think of allowed_affinity is the wrong > name. suggested_affinity sounds like what you are trying to implement > and when it is merely a suggestion and not a hard limit it doesn't > make sense to export like this. it really IS a hard limit. - 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/
- Follow-Ups:
- Re: [patch] Add allowed_affinity to the irq_desc to make it possible to have restricted irqs
- From: ebiederm@xmission.com (Eric W. Biederman)
- Re: [patch] Add allowed_affinity to the irq_desc to make it possible to have restricted irqs
- References:
- [patch] Add allowed_affinity to the irq_desc to make it possible to have restricted irqs
- From: Arjan van de Ven <arjan@linux.intel.com>
- Re: [patch] Add allowed_affinity to the irq_desc to make it possible to have restricted irqs
- From: ebiederm@xmission.com (Eric W. Biederman)
- [patch] Add allowed_affinity to the irq_desc to make it possible to have restricted irqs
- Prev by Date: [PATCH] Conditionally check expected_preempt_count in __resched_legal()
- Next by Date: Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
- Previous by thread: Re: [patch] Add allowed_affinity to the irq_desc to make it possible to have restricted irqs
- Next by thread: Re: [patch] Add allowed_affinity to the irq_desc to make it possible to have restricted irqs
- Index(es):
![]() |