Zachary Amsden wrote: >> Hi Chris, >> >> Would you have less trouble if the "ROM" were actually more like a >> module? Specifically, if it had a proper elf header and symbol >> table, used symbols as entry points, and was a GPL interface (so that >> ROM's had to be GPL)? Then it's just a kernel module that's hidden >> in the option ROM space and has a C interface. >> >> I know you end up losing the ability to do crazy inlining of the ROM >> code but I think it becomes a much less hairy interface that way. > > Actually, I think you still can get the ability to do crazy inlining > of the ROM code. You have three exports from the ELF module: > > vmi_init - enter paravirtual mode > vmi_annotate - apply inline transformations based on inlining > vmi_exit - exit paravirtual mode (required for module unloading). Hrm, I was actually thinking that each of the VMI calls would be an export (vmi_init, vmi_set_pxe, etc.). I know that you want the hypervisor to drive the inlining but I that's sufficiently hairy (not to mention, there's not AFAIK performance data yet to justify it) that I think it ought to be left for VMI 2.0. > But you can't require the ROM to be GPL'd. It has to be > multi-licensed for compatibility with other open source or, even > proprietary operating systems. If the ROM is licensed for use only > under the GPL, then by including it in your kernel and allowing it to > patch your kernel code, you leave your non-GPL kernel in a > questionable license state. If the ROM is licensed under an open > license, with a clause allowing its inclusion into GPL'd software, > then I don't think you have a problem. Course I could be wrong. This > is sort of a unique situation, and finding an identical comparison is > tricky. Multi-licensing is fine as long as one is GPL :-) Regards, Anthony Liguori > Zach
