Re: [osv-dev] Booting Bare Metal

[Matthew Weekley]

My current grub.cfg:

menuentry “OSv”{
linux /boot/service/release.x64/vmlinuz.bin
boot
}

When I go to boot from within grub, I get a critical error :(

Any thoughts why?? 

> On Nov 26, 2019, at 10:06 AM, Matthew Weekley  wrote:
> 
> 
> Corrected that but that lead to a critical error when trying to boot it.
> 
> Do I need to specify any further files below the vmlinuz file?
> 
>>> On Nov 26, 2019, at 9:56 AM, Pekka Enberg  wrote:
>>> 
>> 
>>> On Tue, Nov 26, 2019 at 4:50 PM Matthew Weekley  
>>> wrote:
>> 
>>> My current grub is 
>>> 
>>> menuentry “OSv” {
>>> multiboot /boots/service/release.x64/vmlinuz.bin
>> 
>>^^^ this needs to "linux", instead of "multiboot".
>>  
>>> boot
>>> }
>>> 
>>> This returns “no multiboot header found. You need to load the kernel first”
>> 
>> Yes, because there's no Multiboot support in OSv anymore. The "vmlinuz" file 
>> follows the Linux boot protocol described here:
>> 
>> https://www.kernel.org/doc/Documentation/x86/boot.txt
>> 
>> - Pekka 

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/209F20AC-D16A-4BC3-9960-7BE14BA0CB03%40comcast.net.

Re: [osv-dev] Fedora 30/31 and Ubuntu 19.10

[Dor Laor]

I built OSv on Fedora 31, worked just fine I had to do this tiny thing:

dorlaor@dorpc osv]$ git diff
diff --git a/scripts/setup.py b/scripts/setup.py
index ce02b5d8..7412bb51 100755
--- a/scripts/setup.py
+++ b/scripts/setup.py
@@ -99,7 +99,15 @@ class Fedora(object):
 ec2_post_install = None
 version = '29'

-versions = [Fedora_25, Fedora_26, Fedora_27, Fedora_28, Fedora_29]
+class Fedora_31(object):
+packages = ['java-1.8.0-openjdk', 'python2-requests',
'openssl-devel', 'lua-5.3.*', 'lua-devel-5.3.*']
+ec2_packages = []
+test_packages = []
+ec2_post_install = None
+version = '31'
+
+
+versions = [Fedora_25, Fedora_26, Fedora_27, Fedora_28, Fedora_29,
Fedora_31]

 class RHELbased(Fedora):
 name = ['Scientific Linux', 'NauLinux', 'CentOS Linux', 'Red Hat
Enterprise Linux', 'Oracle Linux']

On Tue, Nov 26, 2019 at 5:52 AM Nadav Har'El  wrote:

> It seems fine on Fedora 30 (I seem to remember there were some specific
> modules that had problems because of the Boost mess, but not the tests). I
> didn't move to Fedora 31 yet. (I should).
>
>
> On Tue, Nov 26, 2019 at 3:39 PM Waldek Kozaczuk 
> wrote:
>
>> Has anybody tried to build and run OSv on any of those distributions? I
>> think per #1040 the code should build and all unit tests should pass on
>> Fedora 30 (I tested it on my other old laptop with that system).
>>
>> Regards,
>> Waldek
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "OSv Development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to osv-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/osv-dev/8432b433-4658-44ce-889c-3dceae3842c6%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/CANEVyjv%2BuF0kbV-htA7vDyzG7oiiMPHix4ZnJswYVmKGXZ3TWA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAKUaUn6oUH9fm6tDBwqur4U0r2Pd_fNh1j%3D9dcsMgf_3RKTxQw%40mail.gmail.com.

Re: [osv-dev] Unikernels as highly isolated processes and an idea to implement limited fork/execve in OSv

[zhiting zhu]

For example, there’re lots of program that uses subprocess in python or
exec.cmd in golang. Those programs have to be ported to rewrite with the
api bindings.

On Tue, Nov 26, 2019 at 9:06 AM Nadav Har'El  wrote:

>
> On Tue, Nov 26, 2019 at 12:44 AM Waldek Kozaczuk 
> wrote:
>
>> Sometimes it might be more useful to think of unikernels as highly
>> isolated processes instead of microVMs with a specialised guest OS. See
>> Nabla processes -
>> https://acmsocc.github.io/2018/slides/socc18-slides-williams.pdf.
>>
>> So given that I wonder if it would make sense/be feasible/applicable to
>> implement limited fork/execve in OSv. It could work like this:
>>
>>1. fork() starts new thread T2 - acts as "stub/proxy" to a new remote
>>microVM that would be lazily started when execve() is actually called
>>
>>
>>1. tid of the new thread T2 would be returned to the caller in the
>>thread T1; it would act as PID of the new process
>>2. New thread T2 would start with same code as calling thread T1 but
>>somehow (???) get 0 as the return value and continue from there (just like
>>on normal Posix OS)
>>3. T2 typically would call execve() right away
>>4.
>>   - execve() would somehow communicate with host (how?) to start new
>>   child VM with passed in command line, argv
>>   - execve() would never return and instead wait unit the child VM
>>   terminates
>>   - T2 would also somehow listen for some other calls like kill()
>>   and pass it to the host that would shutdown child VM
>>
>> Something like this is doable (and I vaguely remember someone from the
> Mikelangelo project once thought about doing this), but I wonder which kind
> of applications this would be useful for. I would start with finding such
> an application before spending too much effort on this.
>
>
>> There is obviously a plethora of various IPC mechanisms to communicate
>> between processes (shared filesystem, shared memory, named semaphores,
>> named semaphores, etc) so how much OSv would need to implement them to make
>> such fork/execve useful, I do not know. I am also not sure if that would be
>> applicable in any real-world scenarios. Maybe master-worker types of
>> workloads (kind of what nginx model is).'
>>
>> Do not be too harsh if you think this is really stupid idea ;-)
>>
>> Waldek
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "OSv Development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to osv-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/osv-dev/8f1e8b08-1028-4075-8298-fe72823da3cf%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/CANEVyjv%2BZxLquMMNPuvm7Miuv%2BYkA8h4q0G9C3eorr3vB%3Du4dg%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CA%2B3q14yTEZ9hoHvMsfP-k-mBPpZfDxTUf8sqDNwQ0SN-Yw5y8A%40mail.gmail.com.

Re: [osv-dev] Unikernels as highly isolated processes and an idea to implement limited fork/execve in OSv

[Nadav Har'El]

On Tue, Nov 26, 2019 at 12:44 AM Waldek Kozaczuk 
wrote:

> Sometimes it might be more useful to think of unikernels as highly
> isolated processes instead of microVMs with a specialised guest OS. See
> Nabla processes -
> https://acmsocc.github.io/2018/slides/socc18-slides-williams.pdf.
>
> So given that I wonder if it would make sense/be feasible/applicable to
> implement limited fork/execve in OSv. It could work like this:
>
>1. fork() starts new thread T2 - acts as "stub/proxy" to a new remote
>microVM that would be lazily started when execve() is actually called
>
>
>1. tid of the new thread T2 would be returned to the caller in the
>thread T1; it would act as PID of the new process
>2. New thread T2 would start with same code as calling thread T1 but
>somehow (???) get 0 as the return value and continue from there (just like
>on normal Posix OS)
>3. T2 typically would call execve() right away
>4.
>   - execve() would somehow communicate with host (how?) to start new
>   child VM with passed in command line, argv
>   - execve() would never return and instead wait unit the child VM
>   terminates
>   - T2 would also somehow listen for some other calls like kill() and
>   pass it to the host that would shutdown child VM
>
> Something like this is doable (and I vaguely remember someone from the
Mikelangelo project once thought about doing this), but I wonder which kind
of applications this would be useful for. I would start with finding such
an application before spending too much effort on this.


> There is obviously a plethora of various IPC mechanisms to communicate
> between processes (shared filesystem, shared memory, named semaphores,
> named semaphores, etc) so how much OSv would need to implement them to make
> such fork/execve useful, I do not know. I am also not sure if that would be
> applicable in any real-world scenarios. Maybe master-worker types of
> workloads (kind of what nginx model is).'
>
> Do not be too harsh if you think this is really stupid idea ;-)
>
> Waldek
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/8f1e8b08-1028-4075-8298-fe72823da3cf%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CANEVyjv%2BZxLquMMNPuvm7Miuv%2BYkA8h4q0G9C3eorr3vB%3Du4dg%40mail.gmail.com.

Re: [osv-dev] Booting Bare Metal

[Matthew Weekley]

Corrected that but that lead to a critical error when trying to boot it.

Do I need to specify any further files below the vmlinuz file?

> On Nov 26, 2019, at 9:56 AM, Pekka Enberg  wrote:
> 
> 
>> On Tue, Nov 26, 2019 at 4:50 PM Matthew Weekley  
>> wrote:
> 
>> My current grub is 
>> 
>> menuentry “OSv” {
>> multiboot /boots/service/release.x64/vmlinuz.bin
> 
>^^^ this needs to "linux", instead of "multiboot".
>  
>> boot
>> }
>> 
>> This returns “no multiboot header found. You need to load the kernel first”
> 
> Yes, because there's no Multiboot support in OSv anymore. The "vmlinuz" file 
> follows the Linux boot protocol described here:
> 
> https://www.kernel.org/doc/Documentation/x86/boot.txt
> 
> - Pekka 

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/5E07C841-98DD-46D8-9349-7A6E6A1A6985%40comcast.net.

Re: [osv-dev] OSv boots in 3ms on QEMU microvm machine

[Waldek Kozaczuk]

Imagine the potential for serverless given OSv supports runscript boot option. 
If we can replace the runscript file for every reboot, OSv can execute 
different app with different parameters. Even better reboot and wait until the 
runscript file changes or some other touch mechanism. But for that we would 
need type of fs like 9p or new virtio-fs. 

Sent from my iPhone

> On Nov 26, 2019, at 09:47, Nadav Har'El  wrote:
> 
> 
> 
>> On Tue, Nov 26, 2019 at 3:35 PM Waldek Kozaczuk  wrote:
>> The review and discussion around proper poweroff/reboot sequence on 
>> microvm/firecracker with Nadav (see other email) inspired me to check 
>> another thing - remove '-no-reboot` from QEMU parameter list. This should 
>> then trigger reboot rather than poweroff, right? And then constantly 
>> re-execute the same OSv image over and over sequentially. And this is what I 
>> did and the results are astonishing.
>> 
>> cat test_micro.sh
>> 
>> time 
>> /home/wkozaczuk/projects/qemu/bin/release/native/x86_64-softmmu/qemu-system-x86_64
>>  \
>> -m 64M \
>> -smp 1 \
>> --nographic \
>> -kernel 
>> /home/wkozaczuk/projects/osv/scripts/../build/last/loader-stripped.elf \
>> -append "--nopci /hello" \
>> -M microvm,x-option-roms=off,pit=off,pic=off,rtc=off \
>> -nodefaults \
>> -no-user-config \
>> -global virtio-mmio.force-legacy=off \
>> -device virtio-blk-device,id=blk0,drive=hd0,scsi=off \
>> -drive 
>> file=/home/wkozaczuk/projects/osv/build/last/usr.img,if=none,id=hd0,cache=writeback,aio=threads
>>  \
>> -enable-kvm \
>> -cpu host,+x2apic \
>> -serial stdio
>> 
>> /test_micro.sh > /tmp/log
>> 
>> qemu-system-x86_64: terminating on signal 2
>> 
>> real 0m10.467s
>> user 0m6.366s
>> sys  0m3.328s
>> 
>> grep Hello /tmp/log | wc -l
>> 1772
>> 
>> As you can see OSv re-executed 1772 times in 10.467 seconds. Which gives you:
> 
> Too bad the Guiness Book of World Records doesn't keep records of which OS 
> can reboot the quickest :-)
>> 6ms - average execution time including boo time
>> 170 - number of executions per second 
>> So in this scenario, we pay for QEMU overhead once.
> 
> By the way, with such quick executions, the serial port code writing all the 
> output may prove to be a noticable slowdown. I wonder is we can shave another 
> millisecond by spewing less output :-)
> 
>> 
>> Waldek
>> 
>>> On Monday, November 25, 2019 at 5:20:29 PM UTC-5, Waldek Kozaczuk wrote:
>>> First please note that this and other old (5ms) firecracker boot times were 
>>> recorded when running on my old 2013 MacBook Pro with 4-way 2.3GHz i7 cpu 
>>> with Ubuntu 19.04 on it. I think it still a decent laptop and the cpus have 
>>> not gotten that much faster (Moore's law is dead now, right?), but it would 
>>> be interesting to measure boot times on something more modern and powerful.
>>> 
 On Sunday, November 24, 2019 at 6:46:30 AM UTC-5, Nadav Har'El wrote:
 
> On Fri, Nov 22, 2019 at 3:34 PM Waldek Kozaczuk  
> wrote:
> As you may have heard QEMU developers added new machine type: microvm - 
> https://github.com/qemu/qemu/blob/master/docs/microvm.rst. It has been 
> merged into master but not part of any official QEMU release. So if you 
> want to try you need to build QEMU from the source.
> 
> Recently I have played with it and eventually managed to boot OSv 
> successfully on it after some adjustments (see some of my recent virtio 
> code tweaks). And the same OSv ROFS image that would boot in ~5 ms on 
> firecracker, can boot in only ~3ms on QEMU microvm.
 
 Very nice!
 
> 
> OSv v0.54.0-34-gccb9cd12
> Booted up in 2.91 ms
> Cmdline: /hello 
> Hello from C code
> 
> real  0m0.057s
> user  0m0.037s
> sys   0m0.020s
> 
 
 Can you please remind me what this 2.91ms includes? When do we start 
 measuring and when do we stop measuring?
>>> The 'Booted up' message is what I added couple of months ago and simply 
>>> prints the total from bootchart. The boot time with full bootchart will 
>>> explain what is included:
>>> 
>>> OSv v0.54.0-40-g08466354
>>> disk read (real mode): 0.00ms, (+0.00ms)
>>> uncompress lzloader.elf: 0.00ms, (+0.00ms)
>>> TLS initialization: 0.51ms, (+0.51ms)
>>> .init functions: 1.22ms, (+0.71ms)
>>> SMP launched: 1.55ms, (+0.32ms)
>>> VFS initialized: 1.76ms, (+0.21ms)
>>> Network initialized: 2.01ms, (+0.25ms)
>>> pvpanic done: 2.08ms, (+0.07ms)
>>> drivers probe: 2.12ms, (+0.04ms)
>>> drivers loaded: 2.70ms, (+0.59ms)
>>> ROFS mounted: 2.93ms, (+0.22ms)
>>> Total time: 2.93ms, (+0.00ms)
>>> Cmdline: /hello 
>>> Hello from C code
>>> 
>>> Please note that OSv boots in PVH mode (direct kernel mode) so the 
>>> real-mode boot is bypassed and that is why disk read and uncompress are 0 
>>> (just like on firecracker).
>>> 
 
 The 57ms at the end, that is 20 slower - what does *that* include that the 
 2.91ms figure didn't? 
 
>>> 

Re: [osv-dev] Booting Bare Metal

[Pekka Enberg]

On Tue, Nov 26, 2019 at 4:50 PM Matthew Weekley 
wrote:

> My current grub is
>
> menuentry “OSv” {
> multiboot /boots/service/release.x64/vmlinuz.bin
>

   ^^^ this needs to "linux", instead of "multiboot".


> boot
> }
>
> This returns “no multiboot header found. You need to load the kernel first”
>

Yes, because there's no Multiboot support in OSv anymore. The "vmlinuz"
file follows the Linux boot protocol described here:

https://www.kernel.org/doc/Documentation/x86/boot.txt

- Pekka

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAGUyND-DNK5MTx%3D4BTErUqW7q-Nr6OjehQijKhzxCJjHqHXC-g%40mail.gmail.com.

Re: [osv-dev] Booting Bare Metal

[Matthew Weekley]

My current grub is 

menuentry “OSv” {
multiboot /boots/service/release.x64/vmlinuz.bin
boot
}

This returns “no multiboot header found. You need to load the kernel first”

Also, I don’t need any networking capabilities. Just trying to run a simple 
program and show it can boot bare metal :)

Think of it as me trying to run the “native-example” app that prints out “Hello”

Also, thanks for all the replies and help!!

> On Nov 26, 2019, at 9:40 AM, Nadav Har'El  wrote:
> 
> 
> 
>> On Tue, Nov 26, 2019 at 2:51 AM Matthew Weekley  
>> wrote:
>> I am looking to boot the kernel I generated from the build script. 
>> 
>> How would one recommend doing so using grub? I have noticed that OSv doesn't 
>> support multiboot, or so it seems to me. I am not a grub expert by any means 
>> so that's why I am asking for some help. I am doing a school research 
>> project on Unikernels and am looking to show performance increase running 
>> that running a unikernel as a standalone provides.
> 
> Besides the kernel format issues which I see that you're discussing with 
> Pekka  and Waldek, there may be a more serious problem - 
> You're mentioning running OSv in grub, and "running a unikernel as a 
> standalone". Does this mean you want to run OSv on an actual physical 
> machine, not a VM inside a hypervisor?
> 
> If this is the case the bigger problem you'll encounter is that OSv will not 
> have a driver for your network card, and probably also not for your disk 
> drive. One of the things which simplified OSv's development is that we didn't 
> need to implement a hundred drivers for different hardware. Doing this is not 
> impossible, but will not be trivial either.
> 
>  
>> 
>> Thanks for any help provided!
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "OSv Development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to osv-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/osv-dev/531F2E6E-8EA3-48C8-9E4E-5DF9AAF4A023%40comcast.net.

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CF90073E-9E5C-40A3-80F2-535D202C6D09%40comcast.net.

Re: [osv-dev] OSv boots in 3ms on QEMU microvm machine

[Nadav Har'El]

On Tue, Nov 26, 2019 at 3:35 PM Waldek Kozaczuk 
wrote:

> The review and discussion around proper poweroff/reboot sequence on
> microvm/firecracker with Nadav (see other email) inspired me to check
> another thing - remove '-no-reboot` from QEMU parameter list. This should
> then trigger reboot rather than poweroff, right? And then constantly
> re-execute the same OSv image over and over sequentially. And this is what
> I did and the results are astonishing.
>
> cat test_micro.sh
>
> time
> /home/wkozaczuk/projects/qemu/bin/release/native/x86_64-softmmu/qemu-system-x86_64
> \
> -m 64M \
> -smp 1 \
> --nographic \
> -kernel
> /home/wkozaczuk/projects/osv/scripts/../build/last/loader-stripped.elf \
> -append "--nopci /hello" \
> -M microvm,x-option-roms=off,pit=off,pic=off,rtc=off \
> -nodefaults \
> -no-user-config \
> -global virtio-mmio.force-legacy=off \
> -device virtio-blk-device,id=blk0,drive=hd0,scsi=off \
> -drive
> file=/home/wkozaczuk/projects/osv/build/last/usr.img,if=none,id=hd0,cache=writeback,aio=threads
> \
> -enable-kvm \
> -cpu host,+x2apic \
> -serial stdio
>
> /test_micro.sh > /tmp/log
>
> qemu-system-x86_64: terminating on signal 2
>
> real 0m10.467s
> user 0m6.366s
> sys 0m3.328s
>
> grep Hello /tmp/log | wc -l
> 1772
>
> As you can see OSv re-executed 1772 times in 10.467 seconds. Which gives
> you:
>

Too bad the Guiness Book of World Records doesn't keep records of which OS
can reboot the quickest :-)

>
>- *6ms - average execution time including boo time*
>- *170 - number of executions per second *
>
> So in this scenario, we pay for QEMU overhead once.
>

By the way, with such quick executions, the serial port code writing all
the output may prove to be a noticable slowdown. I wonder is we can shave
another millisecond by spewing less output :-)


> Waldek
>
> On Monday, November 25, 2019 at 5:20:29 PM UTC-5, Waldek Kozaczuk wrote:
>>
>> First please note that this and other old (5ms) firecracker boot times
>> were recorded when running on my old 2013 MacBook Pro with 4-way 2.3GHz i7
>> cpu with Ubuntu 19.04 on it. I think it still a decent laptop and the cpus
>> have not gotten that much faster (Moore's law is dead now, right?), but it
>> would be interesting to measure boot times on something more modern and
>> powerful.
>>
>> On Sunday, November 24, 2019 at 6:46:30 AM UTC-5, Nadav Har'El wrote:
>>>
>>>
>>> On Fri, Nov 22, 2019 at 3:34 PM Waldek Kozaczuk 
>>> wrote:
>>>
 As you may have heard QEMU developers added new machine type: microvm -
 https://github.com/qemu/qemu/blob/master/docs/microvm.rst. It has been
 merged into master but not part of any official QEMU release. So if you
 want to try you need to build QEMU from the source.

 Recently I have played with it and eventually managed to boot OSv
 successfully on it after some adjustments (see some of my recent virtio
 code tweaks). And the same OSv ROFS image that would boot in ~5 ms on
 firecracker, can boot in only *~3ms* on QEMU microvm.

>>>
>>> Very nice!
>>>
>>>
 OSv v0.54.0-34-gccb9cd12
 Booted up in 2.91 ms
 Cmdline: /hello
 Hello from C code

 real 0m0.057s
 user 0m0.037s
 sys 0m0.020s


>>> Can you please remind me what this 2.91ms includes? When do we start
>>> measuring and when do we stop measuring?
>>>
>> The 'Booted up' message is what I added couple of months ago and simply
>> prints the total from bootchart. The boot time with full bootchart will
>> explain what is included:
>>
>> OSv v0.54.0-40-g08466354
>> disk read (real mode): 0.00ms, (+0.00ms)
>> uncompress lzloader.elf: 0.00ms, (+0.00ms)
>> TLS initialization: 0.51ms, (+0.51ms)
>> .init functions: 1.22ms, (+0.71ms)
>> SMP launched: 1.55ms, (+0.32ms)
>> VFS initialized: 1.76ms, (+0.21ms)
>> Network initialized: 2.01ms, (+0.25ms)
>> pvpanic done: 2.08ms, (+0.07ms)
>> drivers probe: 2.12ms, (+0.04ms)
>> drivers loaded: 2.70ms, (+0.59ms)
>> ROFS mounted: 2.93ms, (+0.22ms)
>> Total time: 2.93ms, (+0.00ms)
>> Cmdline: /hello
>> Hello from C code
>>
>> Please note that OSv boots in PVH mode (direct kernel mode) so the
>> real-mode boot is bypassed and that is why disk read and uncompress are 0
>> (just like on firecracker).
>>
>>
>>> The 57ms at the end, that is 20 slower - what does *that* include that
>>> the 2.91ms figure didn't?
>>>
>>> Some of that will the execution of the application and poweroff. But
>> most of it will be the overhead of the QEMU itself. Even though OSv boots
>> very fast, QEMU process with microvm is still relatively slow to start.
>>
>> Here is the gist with the same thing with timed strace around it -
>> https://gist.github.com/wkozaczuk/0806809f4003f1c3761ce4ba8c2f634f.
>> Please note that running with strace slows everything down twice.
>>
>> My sense is that most of the overall 50-60ms are spent in QEMU startup.
>>
>> Now if you compare it with firecracker, firecracker starts much faster
>> (based on the printouts I added to firecracker) 

Re: [osv-dev] Booting Bare Metal

[Nadav Har'El]

On Tue, Nov 26, 2019 at 2:51 AM Matthew Weekley 
wrote:

> I am looking to boot the kernel I generated from the build script.
>
> How would one recommend doing so using grub? I have noticed that OSv
> doesn't support multiboot, or so it seems to me. I am not a grub expert by
> any means so that's why I am asking for some help. I am doing a school
> research project on Unikernels and am looking to show performance increase
> running that running a unikernel as a standalone provides.
>

Besides the kernel format issues which I see that you're discussing with
Pekka  and Waldek, there may be a more serious problem -
You're mentioning running OSv in grub, and "running a unikernel as a
standalone". Does this mean you want to run OSv on an actual physical
machine, not a VM inside a hypervisor?

If this is the case the bigger problem you'll encounter is that OSv will
not have a driver for your network card, and probably also not for your
disk drive. One of the things which simplified OSv's development is that we
didn't need to implement a hundred drivers for different hardware. Doing
this is not impossible, but will not be trivial either.



>
> Thanks for any help provided!
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/531F2E6E-8EA3-48C8-9E4E-5DF9AAF4A023%40comcast.net
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CANEVyjsRtb4J%2Bz5ww%2BsQ2TuKeUZnkHT-h%3DUzgX5VWaVsMuEC%2BA%40mail.gmail.com.

Re: [osv-dev] Booting Bare Metal

[Pekka Enberg]

On Tue, Nov 26, 2019 at 4:14 PM  wrote:

> I've never used vmlinuz to boot, but I see files that pertain to vmlinuz.
> Any suggestions for how to boot bare metal using vmlinuz? Currently looking
> for solutions now. Thanks!
>

Use GRUB, for example. See the previous links to "grub-mkrescue" how to
generate an bootable ISO image. The only difference to Multiboot is that
you need to remember to tell GRUB that the kernel follows the vmlinuz
format, and that's it.

- Pekka

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAGUyND9wZFAt79M0BgMeoziiQYaKktVG7mdJ-t8YUJKgFrnoqA%40mail.gmail.com.

Re: [osv-dev] Booting Bare Metal

[Matthew Weekley]

I’ve never used vmlinuz to boot. Any suggestions?? Currently looking but maybe 
you can provide a faster solution than I’ll be able to research. Thanks!

> On Nov 26, 2019, at 8:51 AM, Waldek Kozaczuk  wrote:
> 
> Pekka,
> 
> Thanks for finding this. From what I remember I found multiboot not that 
> widely supported comparing to vmlinuz. 
> 
> Please note that OSv vmlinuz is not compressed so we simply wrap loader.elf
> 
> I really need to revise the boot wikis 
> 
> Sent from my iPhone
> 
>>> On Nov 26, 2019, at 08:46, Pekka Enberg  wrote:
>>> 
>> 
>> 
>> 
>>> On Tue, Nov 26, 2019 at 3:30 PM  wrote:
>>> I just looked and I do not have any of those files anywhere on my system 
>>> (did the find command).
>> 
>> Aah, my tree was not up-to-date. Looks like Waldek removed Multiboot support:
>> 
>> commit 2a34f9f2acb582b8351c3ca7cac0ac2ad18dfe2a
>> Author: Waldemar Kozaczuk 
>> Date:   Wed Jul 24 17:54:56 2019 -0400
>> 
>> Remove obsolete loader.bin build artifact and related source files
>> 
>> At some point long time ago the loader.bin artifact was added
>> as a way to boot OSv on multiboot bootloaders. Unfortunately it got 
>> abandoned with time,
>> then resurrected with the commit 
>> e44133273ebdbb305b045b6a74c347a96cab9943 to allow
>> OSv boot on hyperkit in multiboot mode which never became fully 
>> functional.
>> 
>> Given that now we have Linux-compatible vmlinuz.bin artifact generated
>> than can be used to boot OSv on hyperkit, there is no need to keep this 
>> arifact
>> around - the boot process and all kinds of its variation are complex 
>> enough.
>> 
>> Signed-off-by: Waldemar Kozaczuk 
>> 
>> But, GRUB should be able to boot to "vmlinuz.bin" if it's really compatible 
>> with Linux kernel.
>> 
>> - Pekka 

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/9FF78D8E-B323-4845-AE50-1D415661F308%40comcast.net.

Re: [osv-dev] Booting Bare Metal

[tweekley5]

I've never used vmlinuz to boot, but I see files that pertain to vmlinuz. 
Any suggestions for how to boot bare metal using vmlinuz? Currently looking 
for solutions now. Thanks!

On Tuesday, November 26, 2019 at 8:50:59 AM UTC-5, Waldek Kozaczuk wrote:
>
> Pekka,
>
> Thanks for finding this. From what I remember I found multiboot not that 
> widely supported comparing to vmlinuz. 
>
> Please note that OSv vmlinuz is not compressed so we simply wrap loader.elf
>
> I really need to revise the boot wikis 
>
> Sent from my iPhone
>
> On Nov 26, 2019, at 08:46, Pekka Enberg > 
> wrote:
>
> 
>
>
> On Tue, Nov 26, 2019 at 3:30 PM > wrote:
>
>> I just looked and I do not have any of those files anywhere on my system 
>> (did the find command).
>>
>
> Aah, my tree was not up-to-date. Looks like Waldek removed Multiboot 
> support:
>
> commit 2a34f9f2acb582b8351c3ca7cac0ac2ad18dfe2a
> Author: Waldemar Kozaczuk >
> Date:   Wed Jul 24 17:54:56 2019 -0400
>
> Remove obsolete loader.bin build artifact and related source files
>
> At some point long time ago the loader.bin artifact was added
> as a way to boot OSv on multiboot bootloaders. Unfortunately it got 
> abandoned with time,
> then resurrected with the commit 
> e44133273ebdbb305b045b6a74c347a96cab9943 to allow
> OSv boot on hyperkit in multiboot mode which never became fully 
> functional.
>
> Given that now we have Linux-compatible vmlinuz.bin artifact generated
> than can be used to boot OSv on hyperkit, there is no need to keep 
> this arifact
> around - the boot process and all kinds of its variation are complex 
> enough.
>
> Signed-off-by: Waldemar Kozaczuk >
>
> But, GRUB should be able to boot to "vmlinuz.bin" if it's really 
> compatible with Linux kernel.
>
> - Pekka 
>
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/c630c9c6-0009-4c56-80e9-7e6c7ac3f228%40googlegroups.com.

Re: [osv-dev] Fedora 30/31 and Ubuntu 19.10

[Nadav Har'El]

It seems fine on Fedora 30 (I seem to remember there were some specific
modules that had problems because of the Boost mess, but not the tests). I
didn't move to Fedora 31 yet. (I should).


On Tue, Nov 26, 2019 at 3:39 PM Waldek Kozaczuk 
wrote:

> Has anybody tried to build and run OSv on any of those distributions? I
> think per #1040 the code should build and all unit tests should pass on
> Fedora 30 (I tested it on my other old laptop with that system).
>
> Regards,
> Waldek
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/8432b433-4658-44ce-889c-3dceae3842c6%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CANEVyjv%2BuF0kbV-htA7vDyzG7oiiMPHix4ZnJswYVmKGXZ3TWA%40mail.gmail.com.

Re: [osv-dev] Booting Bare Metal

[Waldek Kozaczuk]

Pekka,

Thanks for finding this. From what I remember I found multiboot not that widely 
supported comparing to vmlinuz. 

Please note that OSv vmlinuz is not compressed so we simply wrap loader.elf

I really need to revise the boot wikis 

Sent from my iPhone

> On Nov 26, 2019, at 08:46, Pekka Enberg  wrote:
> 
> 
> 
> 
>> On Tue, Nov 26, 2019 at 3:30 PM  wrote:
>> I just looked and I do not have any of those files anywhere on my system 
>> (did the find command).
> 
> Aah, my tree was not up-to-date. Looks like Waldek removed Multiboot support:
> 
> commit 2a34f9f2acb582b8351c3ca7cac0ac2ad18dfe2a
> Author: Waldemar Kozaczuk 
> Date:   Wed Jul 24 17:54:56 2019 -0400
> 
> Remove obsolete loader.bin build artifact and related source files
> 
> At some point long time ago the loader.bin artifact was added
> as a way to boot OSv on multiboot bootloaders. Unfortunately it got 
> abandoned with time,
> then resurrected with the commit e44133273ebdbb305b045b6a74c347a96cab9943 
> to allow
> OSv boot on hyperkit in multiboot mode which never became fully 
> functional.
> 
> Given that now we have Linux-compatible vmlinuz.bin artifact generated
> than can be used to boot OSv on hyperkit, there is no need to keep this 
> arifact
> around - the boot process and all kinds of its variation are complex 
> enough.
> 
> Signed-off-by: Waldemar Kozaczuk 
> 
> But, GRUB should be able to boot to "vmlinuz.bin" if it's really compatible 
> with Linux kernel.
> 
> - Pekka 

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/3C4E24E9-76B4-47A2-BEBE-61B0285B0F2F%40gmail.com.

Re: [osv-dev] Booting Bare Metal

[Pekka Enberg]

On Tue, Nov 26, 2019 at 3:30 PM  wrote:

> I just looked and I do not have any of those files anywhere on my system
> (did the find command).
>

Aah, my tree was not up-to-date. Looks like Waldek removed Multiboot
support:

commit 2a34f9f2acb582b8351c3ca7cac0ac2ad18dfe2a
Author: Waldemar Kozaczuk 
Date:   Wed Jul 24 17:54:56 2019 -0400

Remove obsolete loader.bin build artifact and related source files

At some point long time ago the loader.bin artifact was added
as a way to boot OSv on multiboot bootloaders. Unfortunately it got
abandoned with time,
then resurrected with the commit
e44133273ebdbb305b045b6a74c347a96cab9943 to allow
OSv boot on hyperkit in multiboot mode which never became fully
functional.

Given that now we have Linux-compatible vmlinuz.bin artifact generated
than can be used to boot OSv on hyperkit, there is no need to keep this
arifact
around - the boot process and all kinds of its variation are complex
enough.

Signed-off-by: Waldemar Kozaczuk 

But, GRUB should be able to boot to "vmlinuz.bin" if it's really compatible
with Linux kernel.

- Pekka

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAGUyND-1%2BJ0WjwV_Vv0zVVKET0Eu%3Da57_vYkg%3DuH-%3D0S1Zctvw%40mail.gmail.com.

[osv-dev] Fedora 30/31 and Ubuntu 19.10

[Waldek Kozaczuk]

Has anybody tried to build and run OSv on any of those distributions? I 
think per #1040 the code should build and all unit tests should pass on 
Fedora 30 (I tested it on my other old laptop with that system).

Regards,
Waldek

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/8432b433-4658-44ce-889c-3dceae3842c6%40googlegroups.com.

Re: [osv-dev] OSv boots in 3ms on QEMU microvm machine

[Waldek Kozaczuk]

The review and discussion around proper poweroff/reboot sequence on 
microvm/firecracker with Nadav (see other email) inspired me to check 
another thing - remove '-no-reboot` from QEMU parameter list. This should 
then trigger reboot rather than poweroff, right? And then constantly 
re-execute the same OSv image over and over sequentially. And this is what 
I did and the results are astonishing.

cat test_micro.sh

time 
/home/wkozaczuk/projects/qemu/bin/release/native/x86_64-softmmu/qemu-system-x86_64
 
\
-m 64M \
-smp 1 \
--nographic \
-kernel 
/home/wkozaczuk/projects/osv/scripts/../build/last/loader-stripped.elf \
-append "--nopci /hello" \
-M microvm,x-option-roms=off,pit=off,pic=off,rtc=off \
-nodefaults \
-no-user-config \
-global virtio-mmio.force-legacy=off \
-device virtio-blk-device,id=blk0,drive=hd0,scsi=off \
-drive 
file=/home/wkozaczuk/projects/osv/build/last/usr.img,if=none,id=hd0,cache=writeback,aio=threads
 
\
-enable-kvm \
-cpu host,+x2apic \
-serial stdio

/test_micro.sh > /tmp/log

qemu-system-x86_64: terminating on signal 2

real 0m10.467s
user 0m6.366s
sys 0m3.328s

grep Hello /tmp/log | wc -l
1772

As you can see OSv re-executed 1772 times in 10.467 seconds. Which gives 
you:

   - *6ms - average execution time including boo time*
   - *170 - number of executions per second *

So in this scenario, we pay for QEMU overhead once.

Waldek

On Monday, November 25, 2019 at 5:20:29 PM UTC-5, Waldek Kozaczuk wrote:
>
> First please note that this and other old (5ms) firecracker boot times 
> were recorded when running on my old 2013 MacBook Pro with 4-way 2.3GHz i7 
> cpu with Ubuntu 19.04 on it. I think it still a decent laptop and the cpus 
> have not gotten that much faster (Moore's law is dead now, right?), but it 
> would be interesting to measure boot times on something more modern and 
> powerful.
>
> On Sunday, November 24, 2019 at 6:46:30 AM UTC-5, Nadav Har'El wrote:
>>
>>
>> On Fri, Nov 22, 2019 at 3:34 PM Waldek Kozaczuk  
>> wrote:
>>
>>> As you may have heard QEMU developers added new machine type: microvm - 
>>> https://github.com/qemu/qemu/blob/master/docs/microvm.rst. It has been 
>>> merged into master but not part of any official QEMU release. So if you 
>>> want to try you need to build QEMU from the source.
>>>
>>> Recently I have played with it and eventually managed to boot OSv 
>>> successfully on it after some adjustments (see some of my recent virtio 
>>> code tweaks). And the same OSv ROFS image that would boot in ~5 ms on 
>>> firecracker, can boot in only *~3ms* on QEMU microvm.
>>>
>>
>> Very nice!
>>
>>
>>> OSv v0.54.0-34-gccb9cd12
>>> Booted up in 2.91 ms
>>> Cmdline: /hello 
>>> Hello from C code
>>>
>>> real 0m0.057s
>>> user 0m0.037s
>>> sys 0m0.020s
>>>
>>>
>> Can you please remind me what this 2.91ms includes? When do we start 
>> measuring and when do we stop measuring?
>>
> The 'Booted up' message is what I added couple of months ago and simply 
> prints the total from bootchart. The boot time with full bootchart will 
> explain what is included:
>
> OSv v0.54.0-40-g08466354
> disk read (real mode): 0.00ms, (+0.00ms)
> uncompress lzloader.elf: 0.00ms, (+0.00ms)
> TLS initialization: 0.51ms, (+0.51ms)
> .init functions: 1.22ms, (+0.71ms)
> SMP launched: 1.55ms, (+0.32ms)
> VFS initialized: 1.76ms, (+0.21ms)
> Network initialized: 2.01ms, (+0.25ms)
> pvpanic done: 2.08ms, (+0.07ms)
> drivers probe: 2.12ms, (+0.04ms)
> drivers loaded: 2.70ms, (+0.59ms)
> ROFS mounted: 2.93ms, (+0.22ms)
> Total time: 2.93ms, (+0.00ms)
> Cmdline: /hello 
> Hello from C code
>
> Please note that OSv boots in PVH mode (direct kernel mode) so the 
> real-mode boot is bypassed and that is why disk read and uncompress are 0 
> (just like on firecracker).
>
>
>> The 57ms at the end, that is 20 slower - what does *that* include that 
>> the 2.91ms figure didn't? 
>>
>> Some of that will the execution of the application and poweroff. But most 
> of it will be the overhead of the QEMU itself. Even though OSv boots very 
> fast, QEMU process with microvm is still relatively slow to start.
>
> Here is the gist with the same thing with timed strace around it - 
> https://gist.github.com/wkozaczuk/0806809f4003f1c3761ce4ba8c2f634f. 
> Please note that running with strace slows everything down twice.
>
> My sense is that most of the overall 50-60ms are spent in QEMU startup. 
>
> Now if you compare it with firecracker, firecracker starts much faster 
> (based on the printouts I added to firecracker) and only adds 5 ms when it 
> gives control to the guest. But then wastes 30-40 ms shutting down - see 
> this from my firecracker issue comments - 
> https://github.com/firecracker-microvm/firecracker/issues/1164 and 
> https://github.com/firecracker-microvm/firecracker/issues/923#issuecomment-497336403.
>  
> Somehow from the moment exit_group() is called until the process officially 
> dies it takes 30-45 ms. Weird.
>
>

-- 
You received this message because you are subscribed to the 

Re: [osv-dev] Booting Bare Metal

[tweekley5]

I just looked and I do not have any of those files anywhere on my system 
(did the find command).

On Tuesday, November 26, 2019 at 1:30:26 AM UTC-5, Pekka Enberg wrote:
>
> Hi Matthew,
>
> On Tue, Nov 26, 2019 at 2:51 AM Matthew Weekley  > wrote:
>
>> How would one recommend doing so using grub? I have noticed that OSv 
>> doesn't support multiboot, or so it seems to me. I am not a grub expert by 
>> any means so that's why I am asking for some help. I am doing a school 
>> research project on Unikernels and am looking to show performance increase 
>> running that running a unikernel as a standalone provides.
>>
>
> Look arch/x64/boot32.S and you will see Multiboot 1 compatible boot 
> header. My assumption is that "loader.bin" should be bootable under GRUB. 
> You could look into "grub-mkrescue", for example, to generate a bootable 
> ISO image:
>
> https://wiki.osdev.org/GRUB
>
> Please also note that most OSes have moved over to Multiboot 2, which is 
> not backward compatible with Multiboot 1. I think GRUB 2 supports the older 
> variant, but if you hit unexpected problems, make sure it's not related to 
> Multiboot 1/2 differences.
>
> - Pekka 
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/165ec4a3-ae23-4699-b414-ccf76649c39d%40googlegroups.com.

Re: [osv-dev] Unikernels as highly isolated processes and an idea to implement limited fork/execve in OSv

[Pekka Enberg]

Hi Waldek,

On Tue, Nov 26, 2019 at 12:44 AM Waldek Kozaczuk 
wrote:

> Sometimes it might be more useful to think of unikernels as highly
> isolated processes instead of microVMs with a specialised guest OS. See
> Nabla processes -
> https://acmsocc.github.io/2018/slides/socc18-slides-williams.pdf.
>
> So given that I wonder if it would make sense/be feasible/applicable to
> implement limited fork/execve in OSv. It could work like this:
>
>1. fork() starts new thread T2 - acts as "stub/proxy" to a new remote
>microVM that would be lazily started when execve() is actually called
>2. tid of the new thread T2 would be returned to the caller in the
>thread T1; it would act as PID of the new process
>3. New thread T2 would start with same code as calling thread T1 but
>somehow (???) get 0 as the return value and continue from there (just like
>on normal Posix OS)
>4. T2 typically would call execve() right away
>5.
>   - execve() would somehow communicate with host (how?) to start new
>   child VM with passed in command line, argv
>   - execve() would never return and instead wait unit the child VM
>   terminates
>   - T2 would also somehow listen for some other calls like kill() and
>   pass it to the host that would shutdown child VM
>
> There is obviously a plethora of various IPC mechanisms to communicate
> between processes (shared filesystem, shared memory, named semaphores,
> named semaphores, etc) so how much OSv would need to implement them to make
> such fork/execve useful, I do not know. I am also not sure if that would be
> applicable in any real-world scenarios. Maybe master-worker types of
> workloads (kind of what nginx model is).'
>

You can certainly implement fork()/exec() for an unikernel, and it has been
done before. See, for example, the following paper on Graphene:

  Tsai et al. Cooperation and Security Isolation of Library OSes for
Multi-Process Applications. EuroSys 2014.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.589.1837=rep1=pdf

However, please keep in mind that fork() is used for different kinds of
things, which are not going to be easy to support efficiently using this
kind of model. The way Redis uses fork() for snapshotting comes to mind,
for example.

There is a way to support multi-process environment, though, and that's by
implementing the posix_spawn() system call. I recommend reading the
following paper for a case against fork() and why posix_spawn() makes more
sense in the general case:

  Baumann et al. A fork() in the road. HotOS 2019.
https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf

- Pekka

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAGUyND_q5cm093bHuKkPTWPS56ENNh1EcAckH%3DDzGLzUfXamgw%40mail.gmail.com.

Re: [osv-dev] Re: Capstan Build Fail and Fix

[Pekka Enberg]

Hi,

On Mon, Nov 25, 2019 at 6:59 PM Waldek Kozaczuk 
wrote:

> I am not golang expert either. Maybe others, original authors of capstan
> on the list can chime in. I will look into myself. If there is a lot of
> work we might just explicitly stick with v1. Either way, it would be good
> to express the explict dependency on the specific version rather than
> always use master. What is the right way to do in golang?
>

Vendoring (IOW, keeping full copies of the dependencies) used to be the
thing to do, but not sure what Gophers do these days.

But, you probably should anyway just update capstan.git to use the new
APIs, because at some point the older versions will stop working for one
reason or another.

- Pekka

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAGUyND_S%3DXaG3uJTtYCbyMF10SrYPRwb8JNAS0ifHbPxNqP5mg%40mail.gmail.com.