On 08/18/2009 04:16 PM, Gregory Haskins wrote:
The issue here is that vbus is designed to be a generic solution to in-kernel virtual-IO. It will support (via abstraction of key subsystems) a variety of environments that may or may not be similar in facilities to KVM, and therefore it represents the least-common-denominator as far as what external dependencies it requires.
Maybe it will be easier to evaluate it in the context of these other environments. It's difficult to assess this without an example.
The bottom line is this: despite the tendency for people to jump at "don't put much in the kernel!", the fact is that a "bus" designed for software to software (such as vbus) is almost laughably trivial. Its essentially a list of objects that have an int (dev-id) and char* (dev-type) attribute. All the extra goo that you see me setting up in something like the kvm-connector needs to be done for fast-path _anyway_, so transporting the verbs to query this simple list is not really a big deal.
It's not laughably trivial when you try to support the full feature set of kvm (for example, live migration will require dirty memory tracking, and exporting all state stored in the kernel to userspace).
Note that I didn't really want to go that route. As you know, I tried pushing this straight through kvm first since earlier this year, but I was met with reluctance to even bother truly understanding what I was proposing, comments like "tell me your ideas so I can steal them", and
Oh come on, I wrote "steal" as a convenient shorthand for "cross-pollinate your ideas into our code according to the letter and spirit of the GNU General Public License". Since we're all trying to improve Linux we may as well cooperate.
"sorry, we are going to reinvent our own instead".
No. Adopting venet/vbus would mean reinventing something that already existed. Continuing to support virtio/pci is not reinventing anything.
This isn't exactly going to motivate someone to continue pushing these ideas within that community. I was made to feel (purposely?) unwelcome at times. So I can either roll over and die, or start my own project.
You haven't convinced me that your ideas are worth the effort of abandoning virtio/pci or maintaining both venet/vbus and virtio/pci. I'm sorry if that made you feel unwelcome. There's no reason to interpret disagreement as malice though.
-- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
