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.
On Tue, Mar 13, 2018 at 10:38 AM, Norman Feske wrote:
Hi Ben,
On 13.03.2018 17:25, Nobody III wrote:
> Thanks! That should work, and should help a lot for reducing the TCB of
> graphical programs.
please note however, that it is up to the server to consider the
client-specified mode or not. In any case, the client should request the
actual mode by
Thanks! That should work, and should help a lot for reducing the TCB of
graphical programs.
On Tue, Mar 13, 2018, 10:21 AM Norman Feske
wrote:
> Hi Ben,
>
> On 13.03.2018 16:54, Nobody III wrote:
> > That's what I was thinking originally, but that only works when
Hi Ben,
On 13.03.2018 16:54, Nobody III wrote:
> That's what I was thinking originally, but that only works when the
> image size is known beforehand.
the 'Framebuffer::Connection' allows a client to specify the preferred
mode as session argument. So the image-renderer component could first
That's what I was thinking originally, but that only works when the image
size is known beforehand.
On Tue, Mar 13, 2018 at 9:08 AM, Norman Feske
wrote:
> Hi Ben,
>
> On 13.03.2018 12:14, Nobody III wrote:
> > Okay, I suppose you're probably right. How do you
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
>
Hi Ben,
On 13.03.2018 12:14, Nobody III wrote:
> Okay, I suppose you're probably right. How do you recommend that I
> isolate image rendering? My inclination is to create a custom RPC
> interface, but if you have a better suggestion, I'd like to hear it.
the most straight-forward way would the
Hello Johannes,
On Tue, Mar 13, 2018 at 11:01:02AM +0100, Johannes Kliemann wrote:
> I have sent this mail before but it was timed unfortunately and got lost
> in the 18.02 release.
Sorry for leaving you in the lurch! I read your last posting but was
distracted in the middle of my investigation.
Thanks. If nobody else gets to it first, I'll probably implement dynamic
cap quota adjustment in init. As for determining starting quotas, I'm
wondering mostly for porting QProcess, so I won't be working with packages.
On Tue, Mar 13, 2018 at 3:55 AM, Norman Feske
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
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?
On Tue, Mar 13, 2018 at 3:40 AM,
Okay, I suppose you're probably right. How do you recommend that I isolate
image rendering? My inclination is to create a custom RPC interface, but if
you have a better suggestion, I'd like to hear it.
On Tue, Mar 13, 2018 at 3:33 AM, Norman Feske
wrote:
> Hi Ben,
Hi Ben,
On 11.03.2018 04:06, Nobody III wrote:
> Thanks. How about CAP quotas? What happens when a component runs out of
> CAPs? And init doesn't seem to indicate the number or CAPs each child is
> using. Shouldn't CAPs be added to the report?
you can add this information to init's state report
Hello Ben,
On 08.03.2018 20:23, Nobody III wrote:
> On Genode, how do we ensure that CPU cores are being used efficiently?
it is not ensured.
> What mechanisms are in place for thread balancing?
None. (well, except on base-linux where Linux performs the balancing)
The general idea is that the
14 matches
Mail list logo