On Fri, Jan 19, 2018 at 04:18:07PM -0800, Jack Schwartz wrote: > Hi Anatol, Daniel and Kevin. > > On 01/19/18 10:36, Anatol Pomozov wrote: > > Hello Jack > > > > On Wed, Jan 17, 2018 at 12:06 PM, Jack Schwartz > > <jack.schwa...@oracle.com> wrote: > > > Hi Kevin and Anatol. > > > > > > Kevin, thanks for your review. > > > > > > More inline below... > > > > > > On 01/15/18 07:54, Kevin Wolf wrote: > > > > Am 21.12.2017 um 18:25 hat Jack Schwartz geschrieben: > > > > > Properly account for the possibility of multiboot kernels with a zero > > > > > bss_end_addr. The Multiboot Specification, section 3.1.3 allows for > > > > > kernels without a bss section, by allowing a zeroed bss_end_addr > > > > > multiboot > > > > > header field. > > > > > > > > > > Do some cleanup to multiboot.c as well: > > > > > - Remove some unused variables. > > > > > - Use more intuitive header names when displaying fields in messages. > > > > > - Change fprintf(stderr...) to error_report > > > > There are some conflicts with Anatol's (CCed) multiboot series: > > > > https://lists.nongnu.org/archive/html/qemu-devel/2017-10/msg03003.html > > > > > > > > None if these should be hard to resolve, but it would be good if you > > > > could agree with each other whose patch series should come first, and > > > > then the other one should be rebased on top of that. > > > Anatol, > > > > > > from my side, there are pros and cons to either patch set going in first, > > > but advantages to either are pretty negligible. Pro for you going first: > > > I > > > can use the constants you will define in header files. Pro for me going > > > first: your merge should be about the same as if you went first (since my > > > changes are small, more localized and affect only multiboot.c) and my > > > merge > > > will be easier. > > > > > > What are your thoughts? > > Please move ahead with your patches. I'll rebase my changes on top of yours. > OK. I'm consulting with my company's legal department and waiting for their > approvals for delivery of a test "kernel". I'll get in touch will everyone > once I have an answer about that. I anticipate about a week before taking > next steps to deliver. > > Kevin and Daniel, thanks for your inputs on this issue (different > subthread), which I have forwarded to our legal department for review.
FWIW, I don't think it needs to be your responsibility to decide this. I think the QEMU community / maintainer taking the patches needs to decide whether it is acceptable / desirable. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|