I didn't know this until after I started, but it is irrelevant. Use
Andrew's if you want. However, I have incorporated some useful bits
from your patch and such that I think are superior.
> Second, as i've repeatedly said it, it's a failure to do this over /proc.
> What if /proc is not mounted? What if the process is in a chroot()
> environment, should it not be able to set its own affinity? This is a
> fundamental limitation of your approach, and *if* we want to export the
> cpus_allowed affinity to user-space (which is up to discussion), then the
> right way (TM) to do it is via a syscall.
OK OK OK ... we can argue all day over syscall vs. proc. Personally, I
don't find any of the arguments fruitful -- we make all sorts of
restrictions and "Don't do thats" in the kernel. Requiring procfs isn't
the end of the world.
When you posted your initial patch, I commented I liked it but was
interested in a proc variant. Some people were interested. Even you
said it wasn't a huge deal.
It doesn't matter to me, let's just expose _some_ interface to
userspace. Personally, I prefer procfs, but both implementations are
nicely done. I respect you too much to argue religion like this. I'll
push for either variant.
Robert Love
-
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/