Re: Genode affinity, multi-core separation and service encapsulation (core inferences)

[Nobody III]

Right now, doesn't Genode just put everything on CPU 0 unless told
otherwise? It seems best for an available CPU to run the next thread that
has that CPU in its affinity space. How can that policy (or something
similarly efficient) be implemented?

On Wed, Mar 14, 2018 at 4:12 AM, Emery Hemingway  wrote:

> CPU balancing is pretty easy to manage at a higher level. For example,
> the Nim runtime balances additional Genode threads automatically,
> because the common high-level case is to create a thread pool for each
> CPU and push jobs to it. In other cases I assume that a thread will
> be blocked or block an external component, and running components on
> multiple CPUs only comes with the performance cost of communicating
> across multiple CPUs.
>
> https://github.com/nim-lang/Nim/blob/55a5dcf8a47a47028707c46491072c
> 438eb2f6ce/lib/system/threads.nim#L570
>
> On Tue, 13 Mar 2018 05:19:46 -0600
> Nobody III  wrote:
>
> > It seems like we ought to have a balancer component or at least basic
> > balancing built into init. A lack of balancing is a huge performance
> > issue on modern SMP CPUs. How could we go about this? Could a server
> > do the balancing through the CPU session interface?
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> genode-main mailing list
> genode-main@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: Library Isolation

[Nobody III]

Are you sure about retaining the separation? For 24-bit color, you can
either use 32 bits per pixel, or you can force the compiler to use 24 bit
per pixel, and likely run into alignment issues. If you are already using
32 bits per pixel, no extra memory is needed for embedding an alpha
channel. As far as I can tell, you have already opted for 32bpp in
Pixel_rgb888. If you use ARGB ordering, no conversion will be needed for
ARGB -> RGB.

For my use case, I'd be much better off just using either RGBA or ARGB.
RGB+A 5:6:5:(separate image for alpha channel) isn't well-supported by most
libraries. Even Qt doesn't support it. Using your suggestion would be
lossy, and would require two awkward, slow color format conversions, as
opposed to (at worst) a single fast, in-place RGBA/ARGB conversion for a
32-bit color image.

On Wed, Mar 14, 2018, 2:38 AM Norman Feske 
wrote:

> Hi Ben,
>
> On 13.03.2018 18:06, Nobody III wrote:
> > Will do. Thanks. The only problem I see now is the Framebuffer interface
> > using 16-bit color, which lacks transparency. With 32-bit color, this
> > should work perfectly, and can even be extended to text rendering.
>
> that's a good point. The color values are limited to 16 bit for the time
> being. But it is actually possible to supplement the framebuffer with
> alpha values, by following the convention used by nitpicker.
>
> Nitpicker hands out virtual framebuffers where the pixel buffer is
> followed by an equally-sized alpha buffer that uses one byte per value.
> (there is actually even another buffer following the alpha buffer that
> contains input-mask values)
>
> A client can detect the presence of the alpha buffer by comparing the
> size of the framebuffer dataspace with the bytes required for the mode
> plus alpha buffer. If an alpha buffer is present, its pointer can be
> computed from the start of the pixel buffer as follows:
>
>   Pixel_alpha8 *alpha_base = fb_ds.local_addr()
>+ mode.bytes_per_pixel()*size().count();
>
> Maybe you can follow the same convention for your image renderer?
>
> BTW, once when we will change Genode's color depth to 8 bits per pixel
> (presumably sometime later this year), I intend to retain the separation
> of the alpha buffer from the pixel values. So your code won't require
> big adaptations then.
>
> If you like to look at an example of using alpha values with the
> framebuffer, you may find [1] illustrative. It uses nitpicker as back
> end (not the framebuffer directly) but it shows the principle idea.
>
> [1]
> https://github.com/genodelabs/genode/blob/master/repos/gems/
> include/gems/nitpicker_buffer.h
>
> Cheers
> Norman
>
> --
> Dr.-Ing. Norman Feske
> Genode Labs
>
> https://www.genode-labs.com · https://genode.org
>
> Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
> Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> genode-main mailing list
> genode-main@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: base-linux IRQ session

[Martin Stein]

Hi Johannes,

El 13/03/18 a las 13:36, Johannes Kliemann escribió:
> Hi all,
> 
> I'm currently implementing the IRQ session on base-linux.
> If I understood the Foundations book correctly interrupts are waiting in
> a separate thread that locks when it is waiting and continues (and calls
> the handler) once an interrupt is triggered.
> 
> According to this I have implemented a kernel module [1] that triggers
> interrupts via reads on a device file. The interrupt can be registered
> via ioctl on the file descriptor and the a blocking read is called that
> returns once the registered interrupts has been triggered.
> 
> I have looked into the implementations of base-nova and base-hw but
> didn't completely understand it. As far as I understood the session
> component implements the session and only requires the interrupt number
> and a signal handler.
> The Irq_object implements the waiting thread but I didn't see where it
> is waiting for the interrupt.
> Also as far as I could see it the actual interrupt capability stays
> inside the session in core and only the signal handler capability is
> passed to the component.
> 
> Is my understanding of this correct? And is there any further
> documentation on this?

On base-hw, the IRQ session component of Core merely assigns the IRQ to
the client and forwards the clients signal capability and ack calls to
the kernel (allow the IRQ to trigger again). The Kernel IRQ-object is
created and bound to the clients signal context as soon as the client
calls Irq_session::sigh. From this moment on, the kernel directly
communicates the IRQ to the client through the signal context without
going over Core. So to the user, the IRQ session only comes into play
when requesting/releasing the interrupt and when acknowledging it. The
handling is achieved through the Signal_handler implementation. To be
more precise, the waiting is done by the component-local signal-handler
thread which dispatches the signals to RPCs on the your entrypoint
thread. All this happens behind the interface of the Genode Component
environment and shows up to you only as calls to the handler.

This simple IRQ-session-component implementation is based on the fact
that base-hw was explicitely designed to work together with the Genode
Core/Userland. Thus, I don't know how far you can get with it on a
third-party kernel.

Cheers,
Martin

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: std::stream::ignore ()

[Christian Helmuth]

Hi Stefan,

On Wed, Mar 14, 2018 at 03:18:52PM +0100, Stefan wrote:
> While trying to port OSG, I found out, that std::istream::ignore (long) seems 
> to be missing.
> 
> Is there an official workaround for this?

please try the attached patch for the stdcxx symbols file.

Greets
-- 
Christian Helmuth
Genode Labs

https://www.genode-labs.com/ · https://genode.org/
https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
diff --git a/repos/libports/lib/symbols/stdcxx b/repos/libports/lib/symbols/stdcxx
index 08db6b3..cf25efc 100644
--- a/repos/libports/lib/symbols/stdcxx
+++ b/repos/libports/lib/symbols/stdcxx
@@ -152,6 +152,8 @@ _ZNKSt9type_info10__do_catchEPKS_PPvj T
 _ZNKSt9type_info11__do_upcastEPKN10__cxxabiv117__class_type_infoEPPv T
 _ZNKSt9type_info14__is_pointer_pEv T
 _ZNKSt9type_info15__is_function_pEv T
+_ZNSi6ignoreEl T
+_ZNSi6ignoreEli T
 _ZNSt10__num_base11_S_atoms_inE D 8
 _ZNSt10__num_base12_S_atoms_outE D 8
 _ZNSt10__num_base15_S_format_floatERKSt8ios_basePcc T
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: Genode affinity, multi-core separation and service encapsulation (core inferences)

[Emery Hemingway]

CPU balancing is pretty easy to manage at a higher level. For example,
the Nim runtime balances additional Genode threads automatically,
because the common high-level case is to create a thread pool for each
CPU and push jobs to it. In other cases I assume that a thread will
be blocked or block an external component, and running components on
multiple CPUs only comes with the performance cost of communicating
across multiple CPUs.

https://github.com/nim-lang/Nim/blob/55a5dcf8a47a47028707c46491072c438eb2f6ce/lib/system/threads.nim#L570

On Tue, 13 Mar 2018 05:19:46 -0600
Nobody III  wrote:

> It seems like we ought to have a balancer component or at least basic
> balancing built into init. A lack of balancing is a huge performance
> issue on modern SMP CPUs. How could we go about this? Could a server
> do the balancing through the CPU session interface?


pgpnb_xondGjH.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: base-linux IRQ session

[Johannes Kliemann]

Hello Christian,

thanks for that hint, it was the missing piece. I can now happily
announce that Interrupts are working on Genode with base-linux!

Regards,
Johannes

Am 13.03.2018 um 16:25 schrieb Christian Helmuth:
> Hello Johannes,
> 
> On Tue, Mar 13, 2018 at 01:36:09PM +0100, Johannes Kliemann wrote:
>> I'm currently implementing the IRQ session on base-linux.
>> If I understood the Foundations book correctly interrupts are waiting in
>> a separate thread that locks when it is waiting and continues (and calls
>> the handler) once an interrupt is triggered.
> 
> The core-internal implementation depends on the base platform. On NOVA
> and FOC, the Irq_object (which is a thread) is never started, ie.,
> does not execute an entry function. Other platforms (e.g., OKL4) use
> the Irq_object thread to implement a interrupt-wait-and-signal loop.
> 
>> According to this I have implemented a kernel module [1] that triggers
>> interrupts via reads on a device file. The interrupt can be registered
>> via ioctl on the file descriptor and the a blocking read is called that
>> returns once the registered interrupts has been triggered.
>>
>> I have looked into the implementations of base-nova and base-hw but
>> didn't completely understand it. As far as I understood the session
>> component implements the session and only requires the interrupt number
>> and a signal handler.
>> The Irq_object implements the waiting thread but I didn't see where it
>> is waiting for the interrupt.
>> Also as far as I could see it the actual interrupt capability stays
>> inside the session in core and only the signal handler capability is
>> passed to the component.
> 
> I suggest you refer to OKL4
> 
>   base-okl4/src/core/irq_session_component.cc
> 
> and implement an Irq_object working similarly with a entry() function
> that uses Irq_object::_wait_for_irq() (which blocks in read(dev_fd))
> and signals IRQ occurence by Genode::Signal_transmitter(_sig_cap).submit(1)
> 
>> Is my understanding of this correct? And is there any further
>> documentation on this?
> 
> Unfortunately, there's only few documentation of the core internals.
> To get up-to-date information I suggest looking at the code and asking
> here or even on Freenode
> 
>   http://webchat.freenode.net/?randomnick=1=%23genode=d4
> 
> Regards
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: how to use genode on riscv

[Sebastian Sumpf]

Hello Dong Du,

On 12.03.2018 12:45, Dd Nirvana wrote:
> Hi guys,
>       
>        I am so glad to know that genode has supported RISCV from v16.02.
> I have already read the
> article(http://genode.org/documentation/articles/riscv) which introduce
> how genode port the RISCV.
>        However, I am still a little confused about how to build a
> runnable genode image and how to  run it on riscv platform like spike.
> Could you give me any advices to do it?

Genode's support for RISC-V is currently very limited. For example,
there is no libc or any peripheral devices. Currently, RISC-V can be
tested on Genode using the spike emulator and our custom kernel, which
implements support for the RISCV 1.9 privileged ISA. So, in order to
test RISC-V make sure to have spike installed. You can find the version
we are using here:

https://github.com/ssumpf/riscv-isa-sim
https://github.com/ssumpf/riscv-fesvr

Please check out the 17.05 branches of both repositories. The fesvr
(front-end server) is required by the instruction emulator and has to be
build first. Please check the README.md files for build instructions.

With spike installed you want to create a Genode directory next:

> /tool/create_builddir riscv_spike
> cd /build/risc_spike

Next you may execute the log run script:

> make KERNEL=hw run/log

(make sure to have the Genode tool chain installed -
http://genode.org/download/tool-chain)

This will build the log scenario and execute it within spike. The actual
boot image can be found under the /build/riscv-spike/bbl/bbl
(Berkeley Boot Loader). BBL implements the machine mode and also piggy
backs the Genode image.

Regards,

Sebastian


 --
Sebastian Sumpf
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: Library Isolation

[Norman Feske]

Hi Ben,

On 13.03.2018 18:06, Nobody III wrote:
> Will do. Thanks. The only problem I see now is the Framebuffer interface
> using 16-bit color, which lacks transparency. With 32-bit color, this
> should work perfectly, and can even be extended to text rendering.

that's a good point. The color values are limited to 16 bit for the time
being. But it is actually possible to supplement the framebuffer with
alpha values, by following the convention used by nitpicker.

Nitpicker hands out virtual framebuffers where the pixel buffer is
followed by an equally-sized alpha buffer that uses one byte per value.
(there is actually even another buffer following the alpha buffer that
contains input-mask values)

A client can detect the presence of the alpha buffer by comparing the
size of the framebuffer dataspace with the bytes required for the mode
plus alpha buffer. If an alpha buffer is present, its pointer can be
computed from the start of the pixel buffer as follows:

  Pixel_alpha8 *alpha_base = fb_ds.local_addr()
   + mode.bytes_per_pixel()*size().count();

Maybe you can follow the same convention for your image renderer?

BTW, once when we will change Genode's color depth to 8 bits per pixel
(presumably sometime later this year), I intend to retain the separation
of the alpha buffer from the pixel values. So your code won't require
big adaptations then.

If you like to look at an example of using alpha values with the
framebuffer, you may find [1] illustrative. It uses nitpicker as back
end (not the framebuffer directly) but it shows the principle idea.

[1]
https://github.com/genodelabs/genode/blob/master/repos/gems/include/gems/nitpicker_buffer.h

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main