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
Il 02/06/2013 17:05, Gleb Natapov ha scritto:
>>> Anthony requested that patches be made that generate the ACPI tables
>>> in QEMU for the upcoming hotplug work, so that they could be evaluated
>>> to see if they truly do need to live in QEMU or if the code could live
>>> in the firmware. There we
On 06/01/13 01:01, Jordan Justen wrote:
> On Fri, May 31, 2013 at 2:32 AM, Gerd Hoffmann wrote:
>> Hi,
>>
>>> I guess -bios would load coreboot. Coreboot would siphon the data
>>> necessary for ACPI table building through the current (same) fw_cfg
>>> bottleneck, build the tables,
>>
>> Yes.
>
On Sun, Jun 02, 2013 at 06:40:43PM +0300, Gleb Natapov wrote:
> On Sun, Jun 02, 2013 at 06:09:50PM +0300, Michael S. Tsirkin wrote:
> > On Sun, Jun 02, 2013 at 06:05:42PM +0300, Gleb Natapov wrote:
> > > On Wed, May 29, 2013 at 11:45:44AM +0300, Michael S. Tsirkin wrote:
> > > > On Tue, May 28, 201
On Sun, Jun 02, 2013 at 06:09:50PM +0300, Michael S. Tsirkin wrote:
> On Sun, Jun 02, 2013 at 06:05:42PM +0300, Gleb Natapov wrote:
> > On Wed, May 29, 2013 at 11:45:44AM +0300, Michael S. Tsirkin wrote:
> > > On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
> > > > On Thu, May 23, 2
On Sun, Jun 02, 2013 at 06:05:42PM +0300, Gleb Natapov wrote:
> On Wed, May 29, 2013 at 11:45:44AM +0300, Michael S. Tsirkin wrote:
> > 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 avail
On Wed, May 29, 2013 at 11:45:44AM +0300, Michael S. Tsirkin wrote:
> 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.
> > > S
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 10:13:34AM +0200, Peter Stuge wrote:
> Kevin O'Connor wrote:
> > one possible way forward would be to split the current SeaBIOS rom
> > into two roms: "qvmloader" and "seabios". The "qvmloader" would do
> > the qemu specific platform init (pci init, smm init, mtrr init, bio
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
--
To un
On Fri, May 31, 2013 at 2:32 AM, Gerd Hoffmann wrote:
> Hi,
>
>> I guess -bios would load coreboot. Coreboot would siphon the data
>> necessary for ACPI table building through the current (same) fw_cfg
>> bottleneck, build the tables,
>
> Yes.
So, this is really about making coreboot+seabios th
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
Am 31.05.2013 14:09, schrieb David Woodhouse:
> On Thu, 2013-05-30 at 09:20 -0700, Jordan Justen wrote:
>> On Thu, May 30, 2013 at 5:19 AM, David Woodhouse
>> wrote:
>>> https://github.com/pgeorgi/edk2/tree/coreboot-pkg
>> Is the license on this actually BSD as the License.txt indicates?
Yes. All
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 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 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 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
On 05/31/13 10:13, Peter Stuge wrote:
> ACPI bytes are obviously a function of QEMU configuration.
Precisely!
When we evaluate that (mathematical-sense) function in boot firmware, we
need to retrieve the function's arguments. Those arguments are bits of
QEMU configuration, as you say, and fw_cfg
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 Wed, 2013-05-29 at 21:12 -0400, Kevin O'Connor wrote:
>
> I remain doubtful that QOM has all the info needed to generate the
> BIOS tables. Does QOM describe how the 5th pci device uses global
> interrupt 11 when using global interrupts, legacy interrupt 5 when not
> using global interrupts, a
On Thu, 2013-05-30 at 09:20 -0700, Jordan Justen wrote:
> On Thu, May 30, 2013 at 5:19 AM, David Woodhouse
> wrote:
> > On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote:
> >> Where is CorebootPkg available from?
> >
> > https://github.com/pgeorgi/edk2/tree/coreboot-pkg
>
> Is the license on
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 05/31/13 10:13, Peter Stuge wrote:
> Kevin O'Connor wrote:
>> one possible way forward would be to split the current SeaBIOS rom
>> into two roms: "qvmloader" and "seabios". The "qvmloader" would do
>> the qemu specific platform init (pci init, smm init, mtrr init, bios
>> tables) and then load
Gerd Hoffmann wrote:
> > and pass down the
> > tables to the firmware (through a now unspecified interface -- perhaps
> > the tables could even be installed at this point).
>
> As far I know coreboot can add more stuff such as acpi tables to cbfs at
> runtime and seabios able to access cbfs too an
Hi,
> I guess -bios would load coreboot. Coreboot would siphon the data
> necessary for ACPI table building through the current (same) fw_cfg
> bottleneck, build the tables,
Yes.
> load the boot firmware (SeaBIOS or OVMF or
> something else -- not sure how to configure that),
The coreboot rom
Kevin O'Connor wrote:
> one possible way forward would be to split the current SeaBIOS rom
> into two roms: "qvmloader" and "seabios". The "qvmloader" would do
> the qemu specific platform init (pci init, smm init, mtrr init, bios
> tables) and then load and run the regular seabios rom.
qvmloader
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
On Thu, May 30, 2013 at 09:57:10AM -0700, Jordan Justen wrote:
> On Thu, May 30, 2013 at 9:41 AM, Laszlo Ersek wrote:
> > On 05/30/13 18:20, Jordan Justen wrote:
> >> I think ACPI table generation lives in firmware on real products,
> >> because on real products the firmware is the point that best
On Thu, May 30, 2013 at 09:20:42AM -0700, Jordan Justen wrote:
> On Thu, May 30, 2013 at 5:19 AM, David Woodhouse wrote:
> > On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote:
> >> Where is CorebootPkg available from?
> >
> > https://github.com/pgeorgi/edk2/tree/coreboot-pkg
>
> Is the licens
On 05/30/13 18:57, Jordan Justen wrote:
> On Thu, May 30, 2013 at 9:41 AM, Laszlo Ersek wrote:
>> On 05/30/13 18:20, Jordan Justen wrote:
>>> I think ACPI table generation lives in firmware on real products,
>>> because on real products the firmware is the point that best
>>> understands the actua
On Thu, May 30, 2013 at 9:41 AM, Laszlo Ersek wrote:
> On 05/30/13 18:20, Jordan Justen wrote:
>> I think ACPI table generation lives in firmware on real products,
>> because on real products the firmware is the point that best
>> understands the actual hardware layout for the machine. In qemu, I
On 05/30/13 18:20, Jordan Justen wrote:
> I think ACPI table generation lives in firmware on real products,
> because on real products the firmware is the point that best
> understands the actual hardware layout for the machine. In qemu, I
> would say that qemu best knows the hardware layout, give
On Thu, May 30, 2013 at 5:19 AM, David Woodhouse wrote:
> On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote:
>> Where is CorebootPkg available from?
>
> https://github.com/pgeorgi/edk2/tree/coreboot-pkg
Is the license on this actually BSD as the License.txt indicates?
Is this planned to be u
On 05/30/13 14:19, David Woodhouse wrote:
> Yeah, but if we're shoving a lot of hardware-specific ACPI table
> generation into the guest's firmware, instead of just doing it on the
> qemu side where a number of us seem to think it belongs, then there *is*
> a benefit to using Coreboot. When stuff
On Thu, May 30, 2013 at 01:19:18PM +0100, David Woodhouse wrote:
> Yeah, but if we're shoving a lot of hardware-specific ACPI table
> generation into the guest's firmware, instead of just doing it on the
> qemu side where a number of us seem to think it belongs,
Hopefully this is not yet set in st
On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote:
> Where is CorebootPkg available from?
https://github.com/pgeorgi/edk2/tree/coreboot-pkg
> > And it helps to dispel the stupid misconception in some quarters that
> > Coreboot *competes* with UEFI and thus cannot possibly be supported
> > bec
On 05/30/13 11:23, David Woodhouse wrote:
> On Wed, 2013-05-29 at 11:18 -0500, Anthony Liguori wrote:
>>
>>> Certainly an option, but that is a long-term project.
>>
>> Out of curiousity, are there other benefits to using coreboot as a core
>> firmware in QEMU?
>>
>> Is there a payload we would eve
On Wed, 2013-05-29 at 11:18 -0500, Anthony Liguori wrote:
>
> > Certainly an option, but that is a long-term project.
>
> Out of curiousity, are there other benefits to using coreboot as a core
> firmware in QEMU?
>
> Is there a payload we would ever plausibly use besides OVMF and SeaBIOS?
I li
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
Hi,
>>> Raised
>>> that QOM interface should be sufficient.
>>
>> Agree on this one. Ideally the acpi table generation code should be
>> able to gather all information it needs from the qom tree, so it can be
>> a standalone C file instead of being scattered over all qemu.
>
> Ack. So my basi
On Wed, May 29, 2013 at 11:18:03AM -0500, Anthony Liguori wrote:
> Gerd Hoffmann writes:
> > On 05/29/13 01:53, Kevin O'Connor wrote:
> >> Raised
> >> that QOM interface should be sufficient.
> >
> > Agree on this one. Ideally the acpi table generation code should be
> > able to gather all inform
On Wed, May 29, 2013 at 07:28:05PM +0300, Michael S. Tsirkin wrote:
> Because that's just insanely rick interface
s/rick/rich/. Sorry about the typo.
--
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
Anthony Liguori writes:
> Gerd Hoffmann writes:
>
>> On 05/29/13 01:53, 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 Wed, May 29, 2013 at 11:18:03AM -0500, Anthony Liguori wrote:
> Gerd Hoffmann writes:
>
> > On 05/29/13 01:53, 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.
>
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
>
Gerd Hoffmann writes:
> On 05/29/13 01:53, 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:
>>>
>>> - Genera
"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 Wed, May 29, 2013 at 11:42:34AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >>> possible complexity of having to regenerate
> >>> tables on a vm reboot,
> >>
> >> Why tables should be regenerated at reboot? I remember hotplug being
> >> mentioned in the call. Hmm? Which hotplugged component need
Hi,
>>> possible complexity of having to regenerate
>>> tables on a vm reboot,
>>
>> Why tables should be regenerated at reboot? I remember hotplug being
>> mentioned in the call. Hmm? Which hotplugged component needs acpi
>> table updates to work properly? And what is the point of hotpluggi
On Wed, May 29, 2013 at 10:49:27AM +0200, Gerd Hoffmann wrote:
> On 05/29/13 01:53, 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
On 05/29/13 01:53, 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:
>>
>> - Generating acpi tables
>
> I didn't see
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
在 2013-05-23四的 15:41 +0300，Michael S. Tsirkin写道：
> 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 y
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
--
To unsubscribe
74 matches
Mail list logo
