Qemu on Haiku

Qemu on Haiku

[Richard Zak]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

Hello there! I noticed the message which appears when building qemu on
Haiku. I'd hate for Haiku to lose qemu, so I would like to help!

What is needed in terms of a build system for continuous integration? I'm
not familiar with CI systems, other than simply knowing what they do.

-- 
Regards,

Richard J. Zak
Professional Genius
PGP Key: https://keybase.io/rjzak/key.asc

[-- Attachment #2: Type: text/html, Size: 716 bytes --]

Re: Qemu on Haiku

[Thomas Huth]

On 25/06/2021 06.12, Richard Zak wrote:
> Hello there! I noticed the message which appears when building qemu on 
> Haiku. I'd hate for Haiku to lose qemu, so I would like to help!
> 
> What is needed in terms of a build system for continuous integration? I'm 
> not familiar with CI systems, other than simply knowing what they do.

  Hi,

since a couple of month, we already have a Haiku VM in our VM tests, so the 
basics are already there - it's possible to run a Haiku build test on a 
Linux host by typing:

  make vm-build-haiku.x86_64

However, it's still in a quite bad shape, the disk image that is used in 
that VM is not big enough for compiling the whole QEMU sources. So somebody 
needs to add some additional logic there to either increase the disk image 
on the fly or to add a second free disk image to the VM that could be used 
for compilation instead. If you want to have a try, have a look at: 
tests/vm/haiku.x86_64

Also, I'm not sure whether Peter is using this VM already in his gating CI 
tests? I guess not, due to those size limitations...

Finally, we'd also need somebody who's proficient with the Haiku APIs and 
who could help with problems in a timely manner, i.e. we'd need an entry in 
the "Hosts" section in the maintainers file. It should be someone who's 
basically familiar with the QEMU development process, so if you're 
interested, I'd suggest that you try to contribute some patches to QEMU 
first to get a basic understanding of the process (see e.g. 
https://wiki.qemu.org/Contribute/BiteSizedTasks for some easier tasks), and 
once you feel confident, you could add a Haiku entry to the MAINTAINERS file.

  Thomas

Re: Qemu on Haiku

[Richard Zak]

[-- Attachment #1: Type: text/plain, Size: 2950 bytes --]

Hello and thanks for the detailed response! I wasn't aware that a Linux
host could compile for Haiku as a target, that's interesting.

Seems like the big tasks are:
1) Haiku VM for continuous integration. Is this hosted in Amazon or other
cloud infrastructure?
2) Supporting aspects of the qemu code relevant to Haiku.

I'll take a look at that Wiki page to get a feel for things, and I've
started with the compilation of the latest code from the repo on Haiku,
addressing some issues as they come up.

I am a huge fan of both projects, but also am doing this in my own time.
I'm a developer professionally, but working on Haiku & qemu during off
hours (though timely shouldn't be a problem). How are things communicated
for this project (in regard to your request for someone who can help in a
timely manner)? It seems that the vast majority of the mailing list is
patch information. What's the primary way for code to be contributed, a
merging code though Gitlab or via emailed patches?

În vin., 25 iun. 2021 la 03:09, Thomas Huth <thuth@redhat.com> a scris:

> On 25/06/2021 06.12, Richard Zak wrote:
> > Hello there! I noticed the message which appears when building qemu on
> > Haiku. I'd hate for Haiku to lose qemu, so I would like to help!
> >
> > What is needed in terms of a build system for continuous integration?
> I'm
> > not familiar with CI systems, other than simply knowing what they do.
>
>   Hi,
>
> since a couple of month, we already have a Haiku VM in our VM tests, so
> the
> basics are already there - it's possible to run a Haiku build test on a
> Linux host by typing:
>
>   make vm-build-haiku.x86_64
>
> However, it's still in a quite bad shape, the disk image that is used in
> that VM is not big enough for compiling the whole QEMU sources. So
> somebody
> needs to add some additional logic there to either increase the disk image
> on the fly or to add a second free disk image to the VM that could be used
> for compilation instead. If you want to have a try, have a look at:
> tests/vm/haiku.x86_64
>
> Also, I'm not sure whether Peter is using this VM already in his gating CI
> tests? I guess not, due to those size limitations...
>
> Finally, we'd also need somebody who's proficient with the Haiku APIs and
> who could help with problems in a timely manner, i.e. we'd need an entry
> in
> the "Hosts" section in the maintainers file. It should be someone who's
> basically familiar with the QEMU development process, so if you're
> interested, I'd suggest that you try to contribute some patches to QEMU
> first to get a basic understanding of the process (see e.g.
> https://wiki.qemu.org/Contribute/BiteSizedTasks for some easier tasks),
> and
> once you feel confident, you could add a Haiku entry to the MAINTAINERS
> file.
>
>   Thomas
>
>

-- 
Regards,

Richard J. Zak
Professional Genius
PGP Key: https://keybase.io/rjzak/key.asc

[-- Attachment #2: Type: text/html, Size: 3833 bytes --]

Re: Qemu on Haiku

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 4212 bytes --]

On Fri, Jun 25, 2021 at 8:45 PM Richard Zak <richard.j.zak@gmail.com> wrote:

> Hello and thanks for the detailed response! I wasn't aware that a Linux
> host could compile for Haiku as a target, that's interesting.
>
> Seems like the big tasks are:
> 1) Haiku VM for continuous integration. Is this hosted in Amazon or other
> cloud infrastructure?
>

Take a look at, for example, the make vm-build-freebsd target (see
tests/vm/Makefile.include). It downloads
the latest FreeBSD images, boots it with a serial console, walks through
the install of the base OS, then
installs the packages needed for qemu to build and kicks off a build and
runs some acceptance tests
afterwards. OpenBSD, NetBSD and several Linux distributions have similar
setups. I think it would be
useful for there to be one for Haiku as well, so any developer could run
these tests either in response to
a bug report in their code, or to make sure things work on/with Haiku. All
of this is done locally.

There's a separate issue for creating a Haiku runner for gitlab, but I know
little even about the FreeBSD
runner.


> 2) Supporting aspects of the qemu code relevant to Haiku.
>
> I'll take a look at that Wiki page to get a feel for things, and I've
> started with the compilation of the latest code from the repo on Haiku,
> addressing some issues as they come up.
>
> I am a huge fan of both projects, but also am doing this in my own time.
> I'm a developer professionally, but working on Haiku & qemu during off
> hours (though timely shouldn't be a problem). How are things communicated
> for this project (in regard to your request for someone who can help in a
> timely manner)? It seems that the vast majority of the mailing list is
> patch information. What's the primary way for code to be contributed, a
> merging code though Gitlab or via emailed
>
patches?
>

Emailed patches. https://wiki.qemu.org/Contribute/SubmitAPatch has all the
details, though the volume of patches means that you really want to make
sure that you CC the maintainers of the code listed in the MAINTAINERS file
when submitting patches to help ensure they do not get list.

Warner


>
> În vin., 25 iun. 2021 la 03:09, Thomas Huth <thuth@redhat.com> a scris:
>
>> On 25/06/2021 06.12, Richard Zak wrote:
>> > Hello there! I noticed the message which appears when building qemu on
>> > Haiku. I'd hate for Haiku to lose qemu, so I would like to help!
>> >
>> > What is needed in terms of a build system for continuous integration?
>> I'm
>> > not familiar with CI systems, other than simply knowing what they do.
>>
>>   Hi,
>>
>> since a couple of month, we already have a Haiku VM in our VM tests, so
>> the
>> basics are already there - it's possible to run a Haiku build test on a
>> Linux host by typing:
>>
>>   make vm-build-haiku.x86_64
>>
>> However, it's still in a quite bad shape, the disk image that is used in
>> that VM is not big enough for compiling the whole QEMU sources. So
>> somebody
>> needs to add some additional logic there to either increase the disk
>> image
>> on the fly or to add a second free disk image to the VM that could be
>> used
>> for compilation instead. If you want to have a try, have a look at:
>> tests/vm/haiku.x86_64
>>
>> Also, I'm not sure whether Peter is using this VM already in his gating
>> CI
>> tests? I guess not, due to those size limitations...
>>
>> Finally, we'd also need somebody who's proficient with the Haiku APIs and
>> who could help with problems in a timely manner, i.e. we'd need an entry
>> in
>> the "Hosts" section in the maintainers file. It should be someone who's
>> basically familiar with the QEMU development process, so if you're
>> interested, I'd suggest that you try to contribute some patches to QEMU
>> first to get a basic understanding of the process (see e.g.
>> https://wiki.qemu.org/Contribute/BiteSizedTasks for some easier tasks),
>> and
>> once you feel confident, you could add a Haiku entry to the MAINTAINERS
>> file.
>>
>>   Thomas
>>
>>
>
> --
> Regards,
>
> Richard J. Zak
> Professional Genius
> PGP Key: https://keybase.io/rjzak/key.asc
>

[-- Attachment #2: Type: text/html, Size: 5999 bytes --]

Re: Qemu on Haiku

[Richard Zak]

[-- Attachment #1: Type: text/plain, Size: 5453 bytes --]

Hopefully last questions:

1) What's the format for the subject line for patches? I'm seeing things
like "[PATCH 2/4]" or "[PATCH v2 00/10]" what do those numbers mean in this
context? I didn't see anything about this mentioned in the SubmitAPatch
wiki.
2) Is it acceptable to have a patch for the configure script, or is that
generated? I found some Haiku-related issues there
3) Is there a way to specify that the patch is for a submodule, or is there
a separate place for that?

Regarding prior email:
Seems like the big tasks are:
1) Haiku VM for continuous integration. Is this hosted in Amazon or other
cloud infrastructure?
2) Resolving issues with Haiku pertaining to testing, bringing it inline
with other OSes (and I see how the disk space error)
3) Supporting aspects of the qemu code relevant to Haiku (found an issue in
slirp & configure script)

Thank you for your help & patience!

În vin., 25 iun. 2021 la 23:03, Warner Losh <imp@bsdimp.com> a scris:

>
>
> On Fri, Jun 25, 2021 at 8:45 PM Richard Zak <richard.j.zak@gmail.com>
> wrote:
>
>> Hello and thanks for the detailed response! I wasn't aware that a Linux
>> host could compile for Haiku as a target, that's interesting.
>>
>> Seems like the big tasks are:
>> 1) Haiku VM for continuous integration. Is this hosted in Amazon or other
>> cloud infrastructure?
>>
>
> Take a look at, for example, the make vm-build-freebsd target (see
> tests/vm/Makefile.include). It downloads
> the latest FreeBSD images, boots it with a serial console, walks through
> the install of the base OS, then
> installs the packages needed for qemu to build and kicks off a build and
> runs some acceptance tests
> afterwards. OpenBSD, NetBSD and several Linux distributions have similar
> setups. I think it would be
> useful for there to be one for Haiku as well, so any developer could run
> these tests either in response to
> a bug report in their code, or to make sure things work on/with Haiku. All
> of this is done locally.
>
> There's a separate issue for creating a Haiku runner for gitlab, but I
> know little even about the FreeBSD
> runner.
>
>
>> 2) Supporting aspects of the qemu code relevant to Haiku.
>>
>> I'll take a look at that Wiki page to get a feel for things, and I've
>> started with the compilation of the latest code from the repo on Haiku,
>> addressing some issues as they come up.
>>
>> I am a huge fan of both projects, but also am doing this in my own time.
>> I'm a developer professionally, but working on Haiku & qemu during off
>> hours (though timely shouldn't be a problem). How are things communicated
>> for this project (in regard to your request for someone who can help in a
>> timely manner)? It seems that the vast majority of the mailing list is
>> patch information. What's the primary way for code to be contributed, a
>> merging code though Gitlab or via emailed
>>
> patches?
>>
>
> Emailed patches. https://wiki.qemu.org/Contribute/SubmitAPatch has all
> the details, though the volume of patches means that you really want to
> make sure that you CC the maintainers of the code listed in the MAINTAINERS
> file when submitting patches to help ensure they do not get list.
>
> Warner
>
>
>>
>> În vin., 25 iun. 2021 la 03:09, Thomas Huth <thuth@redhat.com> a scris:
>>
>>> On 25/06/2021 06.12, Richard Zak wrote:
>>> > Hello there! I noticed the message which appears when building qemu on
>>> > Haiku. I'd hate for Haiku to lose qemu, so I would like to help!
>>> >
>>> > What is needed in terms of a build system for continuous integration?
>>> I'm
>>> > not familiar with CI systems, other than simply knowing what they do.
>>>
>>>   Hi,
>>>
>>> since a couple of month, we already have a Haiku VM in our VM tests, so
>>> the
>>> basics are already there - it's possible to run a Haiku build test on a
>>> Linux host by typing:
>>>
>>>   make vm-build-haiku.x86_64
>>>
>>> However, it's still in a quite bad shape, the disk image that is used in
>>> that VM is not big enough for compiling the whole QEMU sources. So
>>> somebody
>>> needs to add some additional logic there to either increase the disk
>>> image
>>> on the fly or to add a second free disk image to the VM that could be
>>> used
>>> for compilation instead. If you want to have a try, have a look at:
>>> tests/vm/haiku.x86_64
>>>
>>> Also, I'm not sure whether Peter is using this VM already in his gating
>>> CI
>>> tests? I guess not, due to those size limitations...
>>>
>>> Finally, we'd also need somebody who's proficient with the Haiku APIs
>>> and
>>> who could help with problems in a timely manner, i.e. we'd need an entry
>>> in
>>> the "Hosts" section in the maintainers file. It should be someone who's
>>> basically familiar with the QEMU development process, so if you're
>>> interested, I'd suggest that you try to contribute some patches to QEMU
>>> first to get a basic understanding of the process (see e.g.
>>> https://wiki.qemu.org/Contribute/BiteSizedTasks for some easier tasks),
>>> and
>>> once you feel confident, you could add a Haiku entry to the MAINTAINERS
>>> file.
>>>
>>>   Thomas
>>>
>>>
>>
>> --
>> Regards,
>>
>> Richard J. Zak
>> Professional Genius
>> PGP Key: https://keybase.io/rjzak/key.asc
>>
>

-- 
Regards,

Richard J. Zak
Professional Genius
PGP Key: https://keybase.io/rjzak/key.asc

[-- Attachment #2: Type: text/html, Size: 7818 bytes --]

Re: Qemu on Haiku

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 6343 bytes --]

On Sun, 27 Jun 2021, Richard Zak wrote:
> Hopefully last questions:
>
> 1) What's the format for the subject line for patches? I'm seeing things
> like "[PATCH 2/4]" or "[PATCH v2 00/10]" what do those numbers mean in this
> context? I didn't see anything about this mentioned in the SubmitAPatch
> wiki.

These are added by git format-patch so check out the docs for that (git 
format-patch --help). The numbers are number of patch/total number in 
series, related patches are submitted in one series. The v2 is second 
revision of a patch. The first submission doesn't have a version, then 
when review asks for changes you make those and do git format-patch -v 2 
and so on. For changing commits you might want to learn about git rebase 
-i and git commit --amend. When making commits you don't have to add these 
[PATCH ...] headers just the subject line, then git will add these when 
formatting/sending patches.

> 2) Is it acceptable to have a patch for the configure script, or is that
> generated? I found some Haiku-related issues there

The configure script is not generated, it's just a shell script so you can 
send patches for it I think.

> 3) Is there a way to specify that the patch is for a submodule, or is there
> a separate place for that?

Submodules are separate projects so you'd have to get in patches to them 
separately then QEMU would pick it up from upstream. Each of these may 
have different process to send patches.

Regards,
BALATON Zoltan

> Regarding prior email:
> Seems like the big tasks are:
> 1) Haiku VM for continuous integration. Is this hosted in Amazon or other
> cloud infrastructure?
> 2) Resolving issues with Haiku pertaining to testing, bringing it inline
> with other OSes (and I see how the disk space error)
> 3) Supporting aspects of the qemu code relevant to Haiku (found an issue in
> slirp & configure script)
>
> Thank you for your help & patience!
>
> În vin., 25 iun. 2021 la 23:03, Warner Losh <imp@bsdimp.com> a scris:
>
>>
>>
>> On Fri, Jun 25, 2021 at 8:45 PM Richard Zak <richard.j.zak@gmail.com>
>> wrote:
>>
>>> Hello and thanks for the detailed response! I wasn't aware that a Linux
>>> host could compile for Haiku as a target, that's interesting.
>>>
>>> Seems like the big tasks are:
>>> 1) Haiku VM for continuous integration. Is this hosted in Amazon or other
>>> cloud infrastructure?
>>>
>>
>> Take a look at, for example, the make vm-build-freebsd target (see
>> tests/vm/Makefile.include). It downloads
>> the latest FreeBSD images, boots it with a serial console, walks through
>> the install of the base OS, then
>> installs the packages needed for qemu to build and kicks off a build and
>> runs some acceptance tests
>> afterwards. OpenBSD, NetBSD and several Linux distributions have similar
>> setups. I think it would be
>> useful for there to be one for Haiku as well, so any developer could run
>> these tests either in response to
>> a bug report in their code, or to make sure things work on/with Haiku. All
>> of this is done locally.
>>
>> There's a separate issue for creating a Haiku runner for gitlab, but I
>> know little even about the FreeBSD
>> runner.
>>
>>
>>> 2) Supporting aspects of the qemu code relevant to Haiku.
>>>
>>> I'll take a look at that Wiki page to get a feel for things, and I've
>>> started with the compilation of the latest code from the repo on Haiku,
>>> addressing some issues as they come up.
>>>
>>> I am a huge fan of both projects, but also am doing this in my own time.
>>> I'm a developer professionally, but working on Haiku & qemu during off
>>> hours (though timely shouldn't be a problem). How are things communicated
>>> for this project (in regard to your request for someone who can help in a
>>> timely manner)? It seems that the vast majority of the mailing list is
>>> patch information. What's the primary way for code to be contributed, a
>>> merging code though Gitlab or via emailed
>>>
>> patches?
>>>
>>
>> Emailed patches. https://wiki.qemu.org/Contribute/SubmitAPatch has all
>> the details, though the volume of patches means that you really want to
>> make sure that you CC the maintainers of the code listed in the MAINTAINERS
>> file when submitting patches to help ensure they do not get list.
>>
>> Warner
>>
>>
>>>
>>> În vin., 25 iun. 2021 la 03:09, Thomas Huth <thuth@redhat.com> a scris:
>>>
>>>> On 25/06/2021 06.12, Richard Zak wrote:
>>>>> Hello there! I noticed the message which appears when building qemu on
>>>>> Haiku. I'd hate for Haiku to lose qemu, so I would like to help!
>>>>>
>>>>> What is needed in terms of a build system for continuous integration?
>>>> I'm
>>>>> not familiar with CI systems, other than simply knowing what they do.
>>>>
>>>>   Hi,
>>>>
>>>> since a couple of month, we already have a Haiku VM in our VM tests, so
>>>> the
>>>> basics are already there - it's possible to run a Haiku build test on a
>>>> Linux host by typing:
>>>>
>>>>   make vm-build-haiku.x86_64
>>>>
>>>> However, it's still in a quite bad shape, the disk image that is used in
>>>> that VM is not big enough for compiling the whole QEMU sources. So
>>>> somebody
>>>> needs to add some additional logic there to either increase the disk
>>>> image
>>>> on the fly or to add a second free disk image to the VM that could be
>>>> used
>>>> for compilation instead. If you want to have a try, have a look at:
>>>> tests/vm/haiku.x86_64
>>>>
>>>> Also, I'm not sure whether Peter is using this VM already in his gating
>>>> CI
>>>> tests? I guess not, due to those size limitations...
>>>>
>>>> Finally, we'd also need somebody who's proficient with the Haiku APIs
>>>> and
>>>> who could help with problems in a timely manner, i.e. we'd need an entry
>>>> in
>>>> the "Hosts" section in the maintainers file. It should be someone who's
>>>> basically familiar with the QEMU development process, so if you're
>>>> interested, I'd suggest that you try to contribute some patches to QEMU
>>>> first to get a basic understanding of the process (see e.g.
>>>> https://wiki.qemu.org/Contribute/BiteSizedTasks for some easier tasks),
>>>> and
>>>> once you feel confident, you could add a Haiku entry to the MAINTAINERS
>>>> file.
>>>>
>>>>   Thomas
>>>>
>>>>
>>>
>>> --
>>> Regards,
>>>
>>> Richard J. Zak
>>> Professional Genius
>>> PGP Key: https://keybase.io/rjzak/key.asc
>>>
>>
>
>

Re: Qemu on Haiku

[Thomas Huth]

On 28/06/2021 02.38, BALATON Zoltan wrote:
> On Sun, 27 Jun 2021, Richard Zak wrote:
>> Hopefully last questions:
[...]
>> 2) Is it acceptable to have a patch for the configure script, or is that
>> generated? I found some Haiku-related issues there
> 
> The configure script is not generated, it's just a shell script so you can 
> send patches for it I think.

Right, QEMU's "configure" script is handmade.

>> Regarding prior email:
>> Seems like the big tasks are:
>> 1) Haiku VM for continuous integration. Is this hosted in Amazon or other
>> cloud infrastructure?

The QEMU project is using gitlab-CI, Travis-CI and Cirrus-CI, as CI systems 
that could be used by everybody. However, most of these are based on 
Containers, so it's not possible to run an OS there that is completely 
different from the ones that are offered by default.
Now that's where the tests in the tests/vm/ directory come in very handy. 
These are based on KVM, so they can run on all Linux hosts that have 
virtualization enabled. Thus if the tests/vm/haiku.x86_64 test would work 
more properly, it could get run on KVM-enabled machines, too.

>> 3) Supporting aspects of the qemu code relevant to Haiku (found an issue in
>> slirp & configure script)

slirp is a separate project now, if you want to fix something in there, 
please report it here:

  https://gitlab.freedesktop.org/slirp/libslirp

  Thomas