[9fans] risc-v memory layout

[9fans] risc-v memory layout

[ron minnich]

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

Something RIchard Miller said has got stuck in my head.

I am wondering about memory layout on riscv64.

The old tradition of "kernel at bottom of physical, top of virtual" is
something we've always done.

But do we have to? There are good riscv reasons to flip this. M mode, for
example, has no virtual addressing, and it would be useful (to say the
least) to have kernel and M mode have a common set of addresses.

Further, the PMP registers, which can be used to manage/limit physical
memory accesses, only gate addresses: they don't come with an offset. If we
had kernel addresses that were 0-based and identity mapped, then the
addresses would be the same for kernel, M mode, PMP, and IOMMU.

A convenience of the "kernel in high memory" was the fact that an immediate
32-bit number, e.g. 0x80000000, sign extends to 0xffffffff_80000000, such
that you can address a KVA with a 32-bit immediate, and a UVA with a 32-bit
immediate, as long as it is < 0x80000000.

But this comes with a headache: KVA breaks into a 2G region and "the rest",
so you end up with two kernel VA ranges. It's annoying at least. The sign
extend hack was convenient when 2G was a lot of memory, but after that,
it's a bit of a pain.

Finally, FWIW, loading a risc-v register with 0x4000_0000_0000_0000 is one
instruction, so having a big number for a base virtual address is not the
issue it is on amd64 (amd64 is, in many ways, a 32-bit architecture with a
64-bit RAX -- it is SO WEIRD, but it had to be to make the heroic move to
64 bits).

So, the proposal: on riscv64, kernel address are 0 to (1<<62)-1, and user
addresses are 1<<62 to (1<<62)-1. This means valid addresses are always
int64, but will never be negative; we can keep using u64int. 62 bits of
address space ought to be enough for everybody.

Again, this makes a lot of RISC-V things easier. It would make it much
easier to use kernel addresses for M mode code, because no translation
would be needed, and a bunch of other risc-v mechanisms would be similarly
simplified.

I'm not sure the toolchain can handle having user text start at
0x4000_0000_0000_0000, but maybe it's not so hard: for gvisor, back in
2014, Russ added the code to 6l to allow us to link text in very high
memory. So it has to be doable. The code's there in go1.4 :-)

Comments?

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf6e0b1b3f80df821-M67136852f364f333004b7db0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

Re: [9fans] risc-v memory layout

[Richard Miller]

<rminnich@gmail.com>:
> M mode, for
> example, has no virtual addressing, and it would be useful (to say the
> least) to have kernel and M mode have a common set of addresses.

Basic question: when would you use M mode? Doesn't the kernel normally
run entirely in Supervisor mode? Will the firmware on your platform even
allow Plan 9 to get into M mode?


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf6e0b1b3f80df821-M36da7668e117fb1f4a72f8f1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] risc-v memory layout

[ron minnich]

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

you can't avoid M mode on riscv, ever. There are several trap cases that
will drop you in to M mode.

And M mode does not have paging, so it will always be using what x86 would
call real memory addresses.

Given that, the more I look at this, the more I want Plan 9 KVA do be
0->1<<60 or so, and UVA to be above that.

I have not yet seen a reason this won't work. It's just not like an x86 :-)

thanks
Ron

P.S. Richard, this is all your fault, your comment a few days ago got me to
thinking. Always a bad idea :-)

On Wed, Jan 7, 2026 at 5:46 AM Richard Miller <9fans@hamnavoe.com> wrote:

> <rminnich@gmail.com>:
> > M mode, for
> > example, has no virtual addressing, and it would be useful (to say the
> > least) to have kernel and M mode have a common set of addresses.
> 
> Basic question: when would you use M mode? Doesn't the kernel normally
> run entirely in Supervisor mode? Will the firmware on your platform even
> allow Plan 9 to get into M mode?
> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf6e0b1b3f80df821-Maacb4cc0a8b566370c93ba31
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

Re: [9fans] risc-v memory layout

[Richard Miller]

rminnich@gmail.com:
> you can't avoid M mode on riscv, ever. There are several trap cases that
> will drop you in to M mode.

I thought avoiding M mode was forced on you by the SBI implementation
(firmware), which intercepts M mode traps and delegates them to S mode
(if it feels like it). That's my recollection from working with the
Polarfire Icicle, but it's a few years back. Or are you designing for
a bare metal platform with no SBI?

Are there any riscv implementations on the market which allow kernel
and user mode to run with different XLEN, and thus enable a 64-bit
kernel to host 32-bit processes? If so, I think that implies that
you would want user address space to start at (or near) zero.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf6e0b1b3f80df821-M5ca44f21c31403b6dd2a80b0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Fwd: [9fans] risc-v memory layout

[ron minnich]

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

M mode is forced by the architecture, and SBI is essential to making that
work. SBI has grown like cancer, to the point that SMP startup now requires
SBI, replacing the old lottery system. We discussed M-mode-free SoC in
2014, but in 2025, I can see that's never going to happen.

So you have to have SBI. And the kernel and SBI share data, so it would be
nice to give them a compatible address range.

Consider kmapaddr. With the address space at the  top, here is today's
version:
static void*
kmapaddr(uintptr pa)
{
if(pa < (uintptr)-KZERO)
return (void*)(pa + KZERO);
if(pa < (VDRAM - KZERO) || pa >= (VDRAM - KZERO) + (KMAPEND - KMAP))
panic("kmapaddr: pa=%#p pc=%#p", pa, getcallerpc(&pa));
return (void*)(pa + KMAP - (VDRAM - KZERO));
}
// Note: this panics. I don't know why just yet.

0-based KVA version:

static void*
kmapaddr(uintptr pa)
{
if (pa < 1<<62) return (void *)pa;
panic("kmapaddr: pa=%#p pc=%#p", pa, getcallerpc(&pa));
return nil;
}

That second version I can understand; that first version makes my head
hurt. Further, what is KZERO? Well, the answer is, it depends on whether
your RISC-V is sv39, sv48, or sv57. It's painful.

Looking at things a bit more, UVA already starts at 2M. As a test, I'm
going to build the kernel with KZERO = 0, start UVA at 1<<31 and see if I
get any distance,

I'm tired of all this math. (uintptr)-KZERO? bah.

ron

On Wed, Jan 7, 2026 at 12:12 PM Richard Miller <9fans@hamnavoe.com> wrote:

> rminnich@gmail.com:
> > you can't avoid M mode on riscv, ever. There are several trap cases that
> > will drop you in to M mode.
> 
> I thought avoiding M mode was forced on you by the SBI implementation
> (firmware), which intercepts M mode traps and delegates them to S mode
> (if it feels like it). That's my recollection from working with the
> Polarfire Icicle, but it's a few years back. Or are you designing for
> a bare metal platform with no SBI?
> 
> Are there any riscv implementations on the market which allow kernel
> and user mode to run with different XLEN, and thus enable a 64-bit
> kernel to host 32-bit processes? If so, I think that implies that
> you would want user address space to start at (or near) zero.
> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf6e0b1b3f80df821-Ma7e1202fce4910d209f48b65
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

Re: [9fans] risc-v memory layout

[tlaronde]

Concerning IOMMU, what is the general position regarding it? I had
tested an AMD64 8 physical cores (for Nix eventually) but run into
problems regarding USB because IOMMU is not handled and apparently
recent firmware unable it by default so one has to put it out the
way---in my case, this is USB that was put out of the way, but it is
a PITA (keyboard...). So how does it usage fit regarding Plan9, Nix?

On Tue, Jan 06, 2026 at 03:13:45PM -0800, ron minnich wrote:
> Something RIchard Miller said has got stuck in my head.
> 
> I am wondering about memory layout on riscv64.
> 
> The old tradition of "kernel at bottom of physical, top of virtual" is
> something we've always done.
> 
> But do we have to? There are good riscv reasons to flip this. M mode, for
> example, has no virtual addressing, and it would be useful (to say the
> least) to have kernel and M mode have a common set of addresses.
> 
> Further, the PMP registers, which can be used to manage/limit physical
> memory accesses, only gate addresses: they don't come with an offset. If we
> had kernel addresses that were 0-based and identity mapped, then the
> addresses would be the same for kernel, M mode, PMP, and IOMMU.
> 
> A convenience of the "kernel in high memory" was the fact that an immediate
> 32-bit number, e.g. 0x80000000, sign extends to 0xffffffff_80000000, such
> that you can address a KVA with a 32-bit immediate, and a UVA with a 32-bit
> immediate, as long as it is < 0x80000000.
> 
> But this comes with a headache: KVA breaks into a 2G region and "the rest",
> so you end up with two kernel VA ranges. It's annoying at least. The sign
> extend hack was convenient when 2G was a lot of memory, but after that,
> it's a bit of a pain.
> 
> Finally, FWIW, loading a risc-v register with 0x4000_0000_0000_0000 is one
> instruction, so having a big number for a base virtual address is not the
> issue it is on amd64 (amd64 is, in many ways, a 32-bit architecture with a
> 64-bit RAX -- it is SO WEIRD, but it had to be to make the heroic move to
> 64 bits).
> 
> So, the proposal: on riscv64, kernel address are 0 to (1<<62)-1, and user
> addresses are 1<<62 to (1<<62)-1. This means valid addresses are always
> int64, but will never be negative; we can keep using u64int. 62 bits of
> address space ought to be enough for everybody.
> 
> Again, this makes a lot of RISC-V things easier. It would make it much
> easier to use kernel addresses for M mode code, because no translation
> would be needed, and a bunch of other risc-v mechanisms would be similarly
> simplified.
> 
> I'm not sure the toolchain can handle having user text start at
> 0x4000_0000_0000_0000, but maybe it's not so hard: for gvisor, back in
> 2014, Russ added the code to 6l to allow us to link text in very high
> memory. So it has to be doable. The code's there in go1.4 :-)
> 
> Comments?

-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf6e0b1b3f80df821-M1cd5f0159acc2ad51e61db64
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] risc-v memory layout

[ron minnich]

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

I don't much like IOMMU on x86, they are just awful to program, and come
with a performance hit. They're also here to stay. If you can disable
x2apic on your amd, then you should be able to turn off iommu I believe?

On Wed, Jan 7, 2026 at 9:58 AM <tlaronde@kergis.com> wrote:

> Concerning IOMMU, what is the general position regarding it? I had
> tested an AMD64 8 physical cores (for Nix eventually) but run into
> problems regarding USB because IOMMU is not handled and apparently
> recent firmware unable it by default so one has to put it out the
> way---in my case, this is USB that was put out of the way, but it is
> a PITA (keyboard...). So how does it usage fit regarding Plan9, Nix?
>
> On Tue, Jan 06, 2026 at 03:13:45PM -0800, ron minnich wrote:
> > Something RIchard Miller said has got stuck in my head.
> >
> > I am wondering about memory layout on riscv64.
> >
> > The old tradition of "kernel at bottom of physical, top of virtual" is
> > something we've always done.
> >
> > But do we have to? There are good riscv reasons to flip this. M mode, for
> > example, has no virtual addressing, and it would be useful (to say the
> > least) to have kernel and M mode have a common set of addresses.
> >
> > Further, the PMP registers, which can be used to manage/limit physical
> > memory accesses, only gate addresses: they don't come with an offset. If
> we
> > had kernel addresses that were 0-based and identity mapped, then the
> > addresses would be the same for kernel, M mode, PMP, and IOMMU.
> >
> > A convenience of the "kernel in high memory" was the fact that an
> immediate
> > 32-bit number, e.g. 0x80000000, sign extends to 0xffffffff_80000000, such
> > that you can address a KVA with a 32-bit immediate, and a UVA with a
> 32-bit
> > immediate, as long as it is < 0x80000000.
> >
> > But this comes with a headache: KVA breaks into a 2G region and "the
> rest",
> > so you end up with two kernel VA ranges. It's annoying at least. The sign
> > extend hack was convenient when 2G was a lot of memory, but after that,
> > it's a bit of a pain.
> >
> > Finally, FWIW, loading a risc-v register with 0x4000_0000_0000_0000 is
> one
> > instruction, so having a big number for a base virtual address is not the
> > issue it is on amd64 (amd64 is, in many ways, a 32-bit architecture with
> a
> > 64-bit RAX -- it is SO WEIRD, but it had to be to make the heroic move to
> > 64 bits).
> >
> > So, the proposal: on riscv64, kernel address are 0 to (1<<62)-1, and user
> > addresses are 1<<62 to (1<<62)-1. This means valid addresses are always
> > int64, but will never be negative; we can keep using u64int. 62 bits of
> > address space ought to be enough for everybody.
> >
> > Again, this makes a lot of RISC-V things easier. It would make it much
> > easier to use kernel addresses for M mode code, because no translation
> > would be needed, and a bunch of other risc-v mechanisms would be
> similarly
> > simplified.
> >
> > I'm not sure the toolchain can handle having user text start at
> > 0x4000_0000_0000_0000, but maybe it's not so hard: for gvisor, back in
> > 2014, Russ added the code to 6l to allow us to link text in very high
> > memory. So it has to be doable. The code's there in go1.4 :-)
> >
> > Comments?
> 
> --
> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>              http://www.kergis.com/
>             http://kertex.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf6e0b1b3f80df821-M6008b32e0a8d08c8d0eba83c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

Re: [9fans] risc-v memory layout

[Dan Cross]

On Wed, Jan 7, 2026 at 3:12 PM ron minnich <rminnich@gmail.com> wrote:
> I don't much like IOMMU on x86, they are just awful to program, and come with a performance hit. They're also here to stay. If you can disable x2apic on your amd, then you should be able to turn off iommu I believe?

Two independent things, really.  You can put the LAPIC into x2 mode as
long as it's supported; you only need the IOMMU if you have more than
255 CPU threads and want to serve external interrupts on the high
numbered ones (or if the APIC ID space is sparse, which it often is if
you have >255 CPUs or a two socket system that supports large
core-counts).

And even then, you're really only using the IOMMU's interrupt
remapping functionality; you don't _have_ to do the page-level
translation stuff for IO devices if you don't want to.

        - Dan C.

> On Wed, Jan 7, 2026 at 9:58 AM <tlaronde@kergis.com> wrote:
>>
>> Concerning IOMMU, what is the general position regarding it? I had
>> tested an AMD64 8 physical cores (for Nix eventually) but run into
>> problems regarding USB because IOMMU is not handled and apparently
>> recent firmware unable it by default so one has to put it out the
>> way---in my case, this is USB that was put out of the way, but it is
>> a PITA (keyboard...). So how does it usage fit regarding Plan9, Nix?
>>
>> On Tue, Jan 06, 2026 at 03:13:45PM -0800, ron minnich wrote:
>> > Something RIchard Miller said has got stuck in my head.
>> >
>> > I am wondering about memory layout on riscv64.
>> >
>> > The old tradition of "kernel at bottom of physical, top of virtual" is
>> > something we've always done.
>> >
>> > But do we have to? There are good riscv reasons to flip this. M mode, for
>> > example, has no virtual addressing, and it would be useful (to say the
>> > least) to have kernel and M mode have a common set of addresses.
>> >
>> > Further, the PMP registers, which can be used to manage/limit physical
>> > memory accesses, only gate addresses: they don't come with an offset. If we
>> > had kernel addresses that were 0-based and identity mapped, then the
>> > addresses would be the same for kernel, M mode, PMP, and IOMMU.
>> >
>> > A convenience of the "kernel in high memory" was the fact that an immediate
>> > 32-bit number, e.g. 0x80000000, sign extends to 0xffffffff_80000000, such
>> > that you can address a KVA with a 32-bit immediate, and a UVA with a 32-bit
>> > immediate, as long as it is < 0x80000000.
>> >
>> > But this comes with a headache: KVA breaks into a 2G region and "the rest",
>> > so you end up with two kernel VA ranges. It's annoying at least. The sign
>> > extend hack was convenient when 2G was a lot of memory, but after that,
>> > it's a bit of a pain.
>> >
>> > Finally, FWIW, loading a risc-v register with 0x4000_0000_0000_0000 is one
>> > instruction, so having a big number for a base virtual address is not the
>> > issue it is on amd64 (amd64 is, in many ways, a 32-bit architecture with a
>> > 64-bit RAX -- it is SO WEIRD, but it had to be to make the heroic move to
>> > 64 bits).
>> >
>> > So, the proposal: on riscv64, kernel address are 0 to (1<<62)-1, and user
>> > addresses are 1<<62 to (1<<62)-1. This means valid addresses are always
>> > int64, but will never be negative; we can keep using u64int. 62 bits of
>> > address space ought to be enough for everybody.
>> >
>> > Again, this makes a lot of RISC-V things easier. It would make it much
>> > easier to use kernel addresses for M mode code, because no translation
>> > would be needed, and a bunch of other risc-v mechanisms would be similarly
>> > simplified.
>> >
>> > I'm not sure the toolchain can handle having user text start at
>> > 0x4000_0000_0000_0000, but maybe it's not so hard: for gvisor, back in
>> > 2014, Russ added the code to 6l to allow us to link text in very high
>> > memory. So it has to be doable. The code's there in go1.4 :-)
>> >
>> > Comments?
>> 
>> --
>> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>>              http://www.kergis.com/
>>             http://kertex.kergis.com/
>> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf6e0b1b3f80df821-M70a96a5b429a1398032b87dd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] risc-v memory layout

[tlaronde]

On Wed, Jan 07, 2026 at 09:50:07PM -0500, Dan Cross wrote:
> On Wed, Jan 7, 2026 at 3:12?PM ron minnich <rminnich@gmail.com> wrote:
> > I don't much like IOMMU on x86, they are just awful to program, and come with a performance hit. They're also here to stay. If you can disable x2apic on your amd, then you should be able to turn off iommu I believe?
> 
> Two independent things, really.  You can put the LAPIC into x2 mode as
> long as it's supported; you only need the IOMMU if you have more than
> 255 CPU threads and want to serve external interrupts on the high
> numbered ones (or if the APIC ID space is sparse, which it often is if
> you have >255 CPUs or a two socket system that supports large
> core-counts).
> 
> And even then, you're really only using the IOMMU's interrupt
> remapping functionality; you don't _have_ to do the page-level
> translation stuff for IO devices if you don't want to.

With the hardware I bought for testing, whatever the use or not of
IOMMU, the firmware doesn't offer the possibility to put aside the
IOMMU (and if I'm not mistaken, even the UEFI EDK doesn't provide a
mean to do so) and it is enable by default, so even for not using any
part of the IOMMU functionnalities, code has to be added to the kernel
to reinitialize the IOMMU mapping to a no-op.

Thus the question about IOMMU vs Plan9/Nix because, for recent x86
like hardware for example, the IOMMU will have to be dealt with, if
only to neutralize it.

> > On Wed, Jan 7, 2026 at 9:58?AM <tlaronde@kergis.com> wrote:
> >>
> >> Concerning IOMMU, what is the general position regarding it? I had
> >> tested an AMD64 8 physical cores (for Nix eventually) but run into
> >> problems regarding USB because IOMMU is not handled and apparently
> >> recent firmware unable it by default so one has to put it out the
> >> way---in my case, this is USB that was put out of the way, but it is
> >> a PITA (keyboard...). So how does it usage fit regarding Plan9, Nix?
> >>
> >> On Tue, Jan 06, 2026 at 03:13:45PM -0800, ron minnich wrote:
> >> > Something RIchard Miller said has got stuck in my head.
> >> >
> >> > I am wondering about memory layout on riscv64.
> >> >
> >> > The old tradition of "kernel at bottom of physical, top of virtual" is
> >> > something we've always done.
> >> >
> >> > But do we have to? There are good riscv reasons to flip this. M mode, for
> >> > example, has no virtual addressing, and it would be useful (to say the
> >> > least) to have kernel and M mode have a common set of addresses.
> >> >
> >> > Further, the PMP registers, which can be used to manage/limit physical
> >> > memory accesses, only gate addresses: they don't come with an offset. If we
> >> > had kernel addresses that were 0-based and identity mapped, then the
> >> > addresses would be the same for kernel, M mode, PMP, and IOMMU.
> >> >
> >> > A convenience of the "kernel in high memory" was the fact that an immediate
> >> > 32-bit number, e.g. 0x80000000, sign extends to 0xffffffff_80000000, such
> >> > that you can address a KVA with a 32-bit immediate, and a UVA with a 32-bit
> >> > immediate, as long as it is < 0x80000000.
> >> >
> >> > But this comes with a headache: KVA breaks into a 2G region and "the rest",
> >> > so you end up with two kernel VA ranges. It's annoying at least. The sign
> >> > extend hack was convenient when 2G was a lot of memory, but after that,
> >> > it's a bit of a pain.
> >> >
> >> > Finally, FWIW, loading a risc-v register with 0x4000_0000_0000_0000 is one
> >> > instruction, so having a big number for a base virtual address is not the
> >> > issue it is on amd64 (amd64 is, in many ways, a 32-bit architecture with a
> >> > 64-bit RAX -- it is SO WEIRD, but it had to be to make the heroic move to
> >> > 64 bits).
> >> >
> >> > So, the proposal: on riscv64, kernel address are 0 to (1<<62)-1, and user
> >> > addresses are 1<<62 to (1<<62)-1. This means valid addresses are always
> >> > int64, but will never be negative; we can keep using u64int. 62 bits of
> >> > address space ought to be enough for everybody.
> >> >
> >> > Again, this makes a lot of RISC-V things easier. It would make it much
> >> > easier to use kernel addresses for M mode code, because no translation
> >> > would be needed, and a bunch of other risc-v mechanisms would be similarly
> >> > simplified.
> >> >
> >> > I'm not sure the toolchain can handle having user text start at
> >> > 0x4000_0000_0000_0000, but maybe it's not so hard: for gvisor, back in
> >> > 2014, Russ added the code to 6l to allow us to link text in very high
> >> > memory. So it has to be doable. The code's there in go1.4 :-)
> >> >
> >> > Comments?
> >> 
> >> --
> >> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> >>              http://www.kergis.com/
> >>             http://kertex.kergis.com/
> >> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
> >
> > 9fans / 9fans / see discussions + participants + delivery options Permalink

-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf6e0b1b3f80df821-M89246f7bae7e5344376fca4f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription