On Fri, Jan 09, 2009 at 08:06:01PM +0200, Avi Kivity wrote: > Sheng Yang wrote: >> I just use it as #ifdef in userspace now, for no user other than >> MSI/MSI-X now. And if we keep maintaining it in kernel, we would return >> free size instead of maximum size.. >> > > We need to allow userspace to change pic/ioapic routing for the HPET. > > There are two styles of maintaining the table: > > 1. add/remove ioctls > > The advantage is that very little work needs to be done when something > changes, but the code size (and bug count) doubles. > > 2. replace everything ioctl > > Smaller code size, but slower if there are high frequency changes > > I don't think we'll see high frequency interrupt routing changes; we'll > probably have one on setup (for HPET), another when switching from ACPI > PIC mode to ACPI APIC mode, and one for every msi initialized.
Hi, Avi After reconsidering, I must say I prefer add/remove ioctls. About the code size, I don't think it would increase much. I've rewritten the code twice, I think I know the difference is little. For the option 2 route table ioctl, we got a array from userspace, and would convert it to linked list and keep it in kernel. That's a kind of must(I don't think you would prefer use a array in kernel), and it's very direct. So, we have to insert/delete route entry for both. What's the real difference we do it one by one or do it all at once. I don't think it is much different on the code size. And it's indeed very clear and direct. Beside this, option 2 seems strange. Why should we handle this table in this way when it won't result in significant code reduce. Insert/delete entry it there, look up entry is also there, not many things changed. And it's not that direct as option 1, which also can be a source of bugs. How do you think? -- regards Yang, Sheng |Intel Opensource Technology Center -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
