On Sun, Jun 2, 2013 at 2:43 AM, Michael S. Tsirkin wrote:
> On Fri, May 31, 2013 at 01:45:55PM +0200, Laszlo Ersek wrote:
>> On 05/31/13 09:09, Jordan Justen wrote:
>>
>> > Why is updating the ACPI tables in seabios viewed as such a burden?
>> > Either qemu does it, or seabios... (And, OVMF too, b
On Thu, May 30, 2013 at 10:34:26PM -0400, Kevin O'Connor wrote:
> On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
> > There were discussions on potentially introducing a middle component
> > to generate the tables. Coreboot was raised as a possibility, and
> > David thought it woul
On Fri, May 31, 2013 at 01:45:55PM +0200, Laszlo Ersek wrote:
> On 05/31/13 09:09, Jordan Justen wrote:
>
> > Why is updating the ACPI tables in seabios viewed as such a burden?
> > Either qemu does it, or seabios... (And, OVMF too, but I don't think
> > you guys are concerned with that. :)
>
> I
On Fri, May 31, 2013 at 5:01 PM, Laszlo Ersek wrote:
> On 05/31/13 23:03, Jordan Justen wrote:
>
>> Of course, the fact that the current FAT driver is exclusionary for
>> free software projects is a point that is not lost on me. I just don't
>> agree that the best response to this is a GPL'd FAT d
On Fri, May 31, 2013 at 07:58:36AM -0500, Anthony Liguori wrote:
> Kevin O'Connor writes:
> > Given the objections to implementing ACPI directly in QEMU, one
> > possible way forward would be to split the current SeaBIOS rom into
> > two roms: "qvmloader" and "seabios". The "qvmloader" would do t
On 05/31/13 23:03, Jordan Justen wrote:
> Of course, the fact that the current FAT driver is exclusionary for
> free software projects is a point that is not lost on me. I just don't
> agree that the best response to this is a GPL'd FAT driver.
What would you suggest?
Thank you,
Laszlo
On Fri, May 31, 2013 at 1:27 PM, Anthony Liguori wrote:
> Jordan Justen writes:
>
>> On Fri, May 31, 2013 at 7:38 AM, Anthony Liguori
>> wrote:
>>> In terms of creating a FAT module, the most likely source would seem to
>>> be the kernel code and since that's GPL, I don't think it's terribly
>>
Jordan Justen writes:
> On Fri, May 31, 2013 at 11:35 AM, Anthony Liguori
> wrote:
>> As I think more about it, I think forking edk2 is inevitable. We need a
>> clean repo that doesn't include the proprietary binaries. I doubt
>> upstream edk2 is willing to remove the binaries.
>
> No, probab
Jordan Justen writes:
> On Fri, May 31, 2013 at 7:38 AM, Anthony Liguori
> wrote:
>> In terms of creating a FAT module, the most likely source would seem to
>> be the kernel code and since that's GPL, I don't think it's terribly
>> avoidable to end up with a GPL'd uefi implementation.
>
> Why w
On Fri, May 31, 2013 at 11:35 AM, Anthony Liguori wrote:
> As I think more about it, I think forking edk2 is inevitable. We need a
> clean repo that doesn't include the proprietary binaries. I doubt
> upstream edk2 is willing to remove the binaries.
No, probably not unless a BSD licensed altern
On Fri, May 31, 2013 at 7:38 AM, Anthony Liguori wrote:
> In terms of creating a FAT module, the most likely source would seem to
> be the kernel code and since that's GPL, I don't think it's terribly
> avoidable to end up with a GPL'd uefi implementation.
Why would OpenBSD not be a potential sou
Paolo Bonzini writes:
> Il 31/05/2013 19:06, Anthony Liguori ha scritto:
>> David Woodhouse writes:
>>
>>> On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
It's even more fundamental. OVMF as a whole (at least in it's usable
form) is not Open Source.
>>>
>>> The FAT module
Il 31/05/2013 19:06, Anthony Liguori ha scritto:
> David Woodhouse writes:
>
>> On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
>>> It's even more fundamental. OVMF as a whole (at least in it's usable
>>> form) is not Open Source.
>>
>> The FAT module is required to make EDK2 usable,
Laszlo Ersek writes:
> On 05/31/13 16:38, Anthony Liguori wrote:
>
>> It's either Open Source or it's not. It's currently not.
>
> I disagree with this binary representation of Open Source or Not. If it
> weren't (mostly) Open Source, how could we fork (most of) it as you're
> suggesting (from t
David Woodhouse writes:
> On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
>> It's even more fundamental. OVMF as a whole (at least in it's usable
>> form) is not Open Source.
>
> The FAT module is required to make EDK2 usable, and yes, that's not Open
> Source. So in a sense you're ri
On 05/31/13 18:33, David Woodhouse wrote:
> On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
>> It's even more fundamental. OVMF as a whole (at least in it's usable
>> form) is not Open Source.
>
> The FAT module is required to make EDK2 usable, and yes, that's not Open
> Source. So in
On 05/31/13 16:38, Anthony Liguori wrote:
> It's either Open Source or it's not. It's currently not.
I disagree with this binary representation of Open Source or Not. If it
weren't (mostly) Open Source, how could we fork (most of) it as you're
suggesting (from the soapbox :))?
> I have a hard
>
On 05/31/13 17:43, Anthony Liguori wrote:
> David Woodhouse writes:
>
>> On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
>>>
>>>
>>>
>>> Fork OVMF, drop the fat module, and just add GPL code. It's an easily
>>> solvable problem.
>>
>> Heh. Actually it doesn't need to be a fork. It's m
On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
> It's even more fundamental. OVMF as a whole (at least in it's usable
> form) is not Open Source.
The FAT module is required to make EDK2 usable, and yes, that's not Open
Source. So in a sense you're right.
But we're talking here about
David Woodhouse writes:
> On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
>>
>>
>>
>> Fork OVMF, drop the fat module, and just add GPL code. It's an easily
>> solvable problem.
>
> Heh. Actually it doesn't need to be a fork. It's modular, and the FAT
> driver is just a single module
Laszlo Ersek writes:
> On 05/31/13 15:04, Anthony Liguori wrote:
>> Laszlo Ersek writes:
>>
>>> On 05/31/13 09:09, Jordan Justen wrote:
>>>
>>> Due to licensing differences I can't just port code from SeaBIOS to
>>> OVMF
>>
>>
>
> :)
>
>> Fork OVMF, drop the fat module, and just add GPL code.
On 05/31/13 16:08, David Woodhouse wrote:
> On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
>>
>>
>>
>> Fork OVMF, drop the fat module, and just add GPL code. It's an easily
>> solvable problem.
>
> Heh. Actually it doesn't need to be a fork. It's modular, and the FAT
> driver is just
On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
>
>
>
> Fork OVMF, drop the fat module, and just add GPL code. It's an easily
> solvable problem.
Heh. Actually it doesn't need to be a fork. It's modular, and the FAT
driver is just a single module. Which is actually included in *binar
Laszlo Ersek writes:
> On 05/31/13 09:09, Jordan Justen wrote:
>
> Due to licensing differences I can't just port code from SeaBIOS to
> OVMF
Fork OVMF, drop the fat module, and just add GPL code. It's an easily
solvable problem.
Rewriting BSD implementations of everything is silly. Every o
On Fri, 2013-05-31 at 07:58 -0500, Anthony Liguori wrote:
> What about a small change to the SeaBIOS build system to allow ACPI
> table generation to be done via a "plugin".
SeaBIOS already accepts ACPI tables from Coreboot or UEFI, and queries
them to find things that it needs.
> This could be a
Kevin O'Connor writes:
> On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
>> There were discussions on potentially introducing a middle component
>> to generate the tables. Coreboot was raised as a possibility, and
>> David thought it would be okay to use coreboot for both OVMF an
On 05/31/13 09:09, Jordan Justen wrote:
> Why is updating the ACPI tables in seabios viewed as such a burden?
> Either qemu does it, or seabios... (And, OVMF too, but I don't think
> you guys are concerned with that. :)
I am :)
> On the flip side, why is moving the ACPI tables to QEMU such an is
On Thu, May 30, 2013 at 7:34 PM, Kevin O'Connor wrote:
> On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
>> There were discussions on potentially introducing a middle component
>> to generate the tables. Coreboot was raised as a possibility, and
>> David thought it would be okay t
On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
> There were discussions on potentially introducing a middle component
> to generate the tables. Coreboot was raised as a possibility, and
> David thought it would be okay to use coreboot for both OVMF and
> SeaBIOS. The possibility
Hi,
> Why should this be true? Shouldn't we be allowed to increase the amount
> of memory the guest has across reboots? That's equivalent to adding
> another DIMM after power off.
poweroff is equivalent to exiting qemu, not to guest reset.
> Not generating tables on reset does limit what we
On Wed, May 29, 2013 at 11:12:06AM -0500, Anthony Liguori wrote:
> "Michael S. Tsirkin" writes:
>
> > On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
> >> On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
> >> > Juan is not available now, and Anthony asked for
>
"Michael S. Tsirkin" writes:
> On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
>> On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
>> > Juan is not available now, and Anthony asked for
>> > agenda to be sent early.
>> > So here comes:
>> >
>> > Agenda for the m
On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
> On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
> > Juan is not available now, and Anthony asked for
> > agenda to be sent early.
> > So here comes:
> >
> > Agenda for the meeting Tue, May 28:
> >
> > - Generati
On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
> On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
> > Juan is not available now, and Anthony asked for
> > agenda to be sent early.
> > So here comes:
> >
> > Agenda for the meeting Tue, May 28:
> >
> > - Generati
On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
> Juan is not available now, and Anthony asked for
> agenda to be sent early.
> So here comes:
>
> Agenda for the meeting Tue, May 28:
>
> - Generating acpi tables
I didn't see any meeting notes, but I thought it would be worthw
Juan is not available now, and Anthony asked for
agenda to be sent early.
So here comes:
Agenda for the meeting Tue, May 28:
- Generating acpi tables
- Switching the call to a bi-weekly schedule
Please, send any topic that you are interested in covering.
Thanks, MST
--
MST
36 matches
Mail list logo
