subject:"Re\: Library Isolation"

Re: Library Isolation

2018-03-16 Thread Nobody III

You're probably right. I probably overestimated the overhead of the RGBA ->
RGB+A -> RGBA/ARGB conversion. And yes, I invented the RGB+A notation.

On Fri, Mar 16, 2018 at 2:25 AM, Norman Feske 
wrote:

> Hi Ben,
>
> I am afraid that we are getting off-topic but I nevertheless don't want
> to leave your question unanswered.
>
> On 14.03.2018 19:40, Nobody III wrote:
> > 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.
>
> with using 24 bits per pixel being no option, the obvious downside of
> using 32-bit color values combined with a separate alpha buffer is the
> waste of the forth byte of each 32-bit pixel value.
>
> For this reason, I shared your intuition before I practically explored
> both alternatives. In particular with my work on the menu view - which
> uses 32-bit color depth internally - I first went for the RGBA
> representation where the alpha values are interleaved with the color
> values. However, the complexity of the result made me uncomfortable,
> which prompted me to split the alpha channel from the color values. This
> change had the desired effect of vastly simplifying the
> software-rendering code while making it more flexible.
>
> In hindsight, it is obvious why: Alpha values and color values are
> different things. Pretending that an alpha value is a forth color
> channel is a leaky abstraction at best. It turns two simple but
> different (!) objects (color and alpha) into a more complicated object.
> All operations on those objects are then bothered with the semantics of
> both parts. E.g., in practice, one wants to have the freedom to apply an
> operation only on the alpha channel. With RGBA, one needs to craft a
> special operation for that. Worse, since this policy is part of the
> inner loop of drawing operations (similar to a pixel shader), the logic
> around it needs to consider both color and alpha - even if only one part
> is used by the operation. In short, by keeping things separate, software
> rendering becomes much more simple.
>
> Another indicator that supports my confidence is the need to supplement
> input-mask information per pixel. With 32-bit RGBA, there is no space
> for this information. So we need to append a dedicated input-mask buffer
> to the pixel buffer anyway. By keeping the alpha values in a dedicated
> buffer, we are consistent with the handling of the input-mask values.
>
> > 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.
> BTW, I like the notation RGB+A. Is this your invention?
>
> The framebuffer's representation does not need to be supported by the Qt
> API and remains invisible to Qt applications. It is only relevant to the
> QPA (platform abstraction).
>
> > 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.
>
> I don't share this concern. Genode's graphics performance is already
> quite acceptable despite the use of software rendering. Today,
> components like VirtualBox or menu view employ in-band color-space
> conversion and dithering. Compared to that, the conversion from RGBA to
> RGB+A is trivial and certainly faster.
>
> Second, the output of any non-trivial application is buffered anyway -
> simply to avoid artifacts from blitting intermediate drawing states to
> the screen.
>
> As the bottom line, I consider the framebuffer organization as a
> technicality and doubt that it is worth arguing about it. Should we find
> the RGB+A approach limiting sometime down the road, we can learn from
> our mistakes and change it.
>
> 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,

Re: Library Isolation

2018-03-16 Thread Norman Feske

Hi Ben,

I am afraid that we are getting off-topic but I nevertheless don't want
to leave your question unanswered.

On 14.03.2018 19:40, Nobody III wrote:
> 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.

with using 24 bits per pixel being no option, the obvious downside of
using 32-bit color values combined with a separate alpha buffer is the
waste of the forth byte of each 32-bit pixel value.

For this reason, I shared your intuition before I practically explored
both alternatives. In particular with my work on the menu view - which
uses 32-bit color depth internally - I first went for the RGBA
representation where the alpha values are interleaved with the color
values. However, the complexity of the result made me uncomfortable,
which prompted me to split the alpha channel from the color values. This
change had the desired effect of vastly simplifying the
software-rendering code while making it more flexible.

In hindsight, it is obvious why: Alpha values and color values are
different things. Pretending that an alpha value is a forth color
channel is a leaky abstraction at best. It turns two simple but
different (!) objects (color and alpha) into a more complicated object.
All operations on those objects are then bothered with the semantics of
both parts. E.g., in practice, one wants to have the freedom to apply an
operation only on the alpha channel. With RGBA, one needs to craft a
special operation for that. Worse, since this policy is part of the
inner loop of drawing operations (similar to a pixel shader), the logic
around it needs to consider both color and alpha - even if only one part
is used by the operation. In short, by keeping things separate, software
rendering becomes much more simple.

Another indicator that supports my confidence is the need to supplement
input-mask information per pixel. With 32-bit RGBA, there is no space
for this information. So we need to append a dedicated input-mask buffer
to the pixel buffer anyway. By keeping the alpha values in a dedicated
buffer, we are consistent with the handling of the input-mask values.

> 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.
BTW, I like the notation RGB+A. Is this your invention?

The framebuffer's representation does not need to be supported by the Qt
API and remains invisible to Qt applications. It is only relevant to the
QPA (platform abstraction).

> 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.

I don't share this concern. Genode's graphics performance is already
quite acceptable despite the use of software rendering. Today,
components like VirtualBox or menu view employ in-band color-space
conversion and dithering. Compared to that, the conversion from RGBA to
RGB+A is trivial and certainly faster.

Second, the output of any non-trivial application is buffered anyway -
simply to avoid artifacts from blitting intermediate drawing states to
the screen.

As the bottom line, I consider the framebuffer organization as a
technicality and doubt that it is worth arguing about it. Should we find
the RGB+A approach limiting sometime down the road, we can learn from
our mistakes and change it.

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

Re: Library Isolation

2018-03-14 Thread 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

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

Re: Library Isolation

2018-03-13 Thread Nobody III

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 calling 'Framebuffer::Session::mode'. For your custom
> server, this mode might always be equal to the client-specified one, but
> when testing your component with one of the existing framebuffer
> drivers, please keep in mind that the client-provided mode is just a
> suggestion.
>
> Happy hacking!
> 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: Library Isolation

2018-03-13 Thread Norman Feske

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 calling 'Framebuffer::Session::mode'. For your custom
server, this mode might always be equal to the client-specified one, but
when testing your component with one of the existing framebuffer
drivers, please keep in mind that the client-provided mode is just a
suggestion.

Happy hacking!
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

Re: Library Isolation

2018-03-13 Thread Nobody III

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 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
> decode the image size, then create a framebuffer session with the image
> size as mode, render the image onto the framebuffer, and finally invoke
> the 'Framebuffer::Session::refresh' function. The latter tells the
> server that the image is ready to be consumed.
>
> Regards
> 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: Library Isolation

2018-03-13 Thread Norman Feske

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
decode the image size, then create a framebuffer session with the image
size as mode, render the image onto the framebuffer, and finally invoke
the 'Framebuffer::Session::refresh' function. The latter tells the
server that the image is ready to be consumed.

Regards
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

Re: Library Isolation

2018-03-13 Thread Nobody III

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 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 rendering of the image into a
> 'Framebuffer' session.
>
> 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: Library Isolation

2018-03-13 Thread Norman Feske

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 rendering of the image into a
'Framebuffer' session.

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

Re: Library Isolation

2018-03-13 Thread Nobody III

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,
>
> On 11.03.2018 05:00, Nobody III wrote:
> > For method calls, one option would be to generate an RPC interface for
> > each library. This seems doable, but methods involving pointers to large
> > amounts of data may be an issue. I could wrap pointers in buffers, but
> > dynamic argument sizes and limits on RPC argument sizes could be an
> issue.
> > ...
>
> whereas I definitely see the appeal of sandboxing libraries, I think
> that the attempt to achieve it transparently is futile. There are many
> arguments against it. Just from the top of my head:
>
> * Since inter-component communication is expensive, RPC interfaces are
>   designed to decouple client and server as far as possible. This is
>   not the case for the design of library interfaces. A good library
>   interfaces does not make a good RPC interface.
>
> * When using a library, the control flow can go back-and-forth between
>   the library and the caller. Think about callback functions. This is
>   not (easily) possible with RPC.
>
> * Genode's RPC mechanism does only support POD types as arguments.
>   That means, a passed argument must not contain any pointer to another
>   object. Most libraries use opaque pointers to library-internal objects
>   as API arguments. This common pattern directly contradicts with
>   Genode's RPC mechanism.
>
> * The memory touched by a library is not disjoint from the memory used
>   by the library-using code. E.g., an inline function defined in a
>   library header becomes part of the calling program when compiled but
>   may operate on library data structures. Therefore, the line between
>   library-owned memory and caller-owned memory cannot be drawn in a
>   general way.
>
> * The magic needed to overcome these complicated problems is complex.
>   Even if succeeding, this complexity inflates the trusted computing
>   base of the library-using program.
>
> * We try to avoid the proliferation of RPC interfaces to foster the
>   composability of components. Your idea goes into the opposite
>   direction.
>
> In summary, I feel that this idea creates more problems than it solves.
> From my perspective it is more practical to manually wrap libraries into
> components - just as I did with libarchive (extract component) or GnuPG
> (verify) component.
>
> Btw, if you are interested in the isolation of libraries from an
> academic perspective, you may find it worthwhile to study tagged-memory
> CPU architecture like CHERI.
>
> 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: Library Isolation

Re: Library Isolation

Re: Library Isolation

Re: Library Isolation

Re: Library Isolation

Re: Library Isolation

Re: Library Isolation

Re: Library Isolation

Re: Library Isolation

Re: Library Isolation

Re: Library Isolation

11 matches

Site Navigation

Mail list logo

Footer information