> It's a little radical to go placing userspace daemons into the kernel tree,
> but I think it is appropriate - this thing is very tightly coupled to the
> kernel.
>
> The proposal has these advantages:
>
> - No version skew problems: if the format of /proc/interrupts changes, we
> patch the irq balance daemon at the same time.
>
> - Can build irqbalanced into the intial initramfs image as part of kernel
> build. (lacking klibc, we would need to statically link against glibc)
Why, please? Unless you postulate that (a) the default kernel balance
would be so bad the machine wouldn't boot, or (b) that the interface would
be done only once at boot time, there's no reason for the user program to
be in initramfs, is there? Let the distribution put it where other system
things like ifconfig live.
Feel free to explain what I'm missing.
> - Doing it in userspace means that we can do more things.
>
> - The balancer can "know about" the differences between NICs, disk
> controllers, etc.
>
> - The balancer can be controlled by config files: "I am a router"
>
> - The balancer can support non-x86 architectures
>
>
> Anyway, that's the theory. None of it has been done yet.
I do agree that the program would have to match the /proc if done as you
propose, but wouldn't it be better to design an interface once and then
NOT have it change? And does it belong in /proc at all, given that other
things are being moved out?
I like the idea of being able to tune the int processing with a user
program. I don't think I share your vision of making a user program part
of the kernel to allow diddling an interface which might be better getting
right the first time, and protecting against "features" being added.
Hopefully it will be minimalist, and may well benefit from a totally
different user program for various machine types.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.- 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/