On Fri, Feb 19, 2021 at 08:07:04PM +0200, Lennert Buytenhek wrote:
> > > IORING_OP_GETDENTS may or may not update the specified directory's
> > > file offset, and the file offset should not be relied upon having
> > > any particular value during or after an IORING
On Fri, Feb 19, 2021 at 12:34:03PM +, Matthew Wilcox wrote:
> > IORING_OP_GETDENTS may or may not update the specified directory's
> > file offset, and the file offset should not be relied upon having
> > any particular value during or after an IORING_OP_GETDENTS call.
>
> This doesn't give m
, and the file offset should not be relied upon having
> > any particular value during or after an IORING_OP_GETDENTS call.
> >
> > Signed-off-by: Lennert Buytenhek
> > ---
> > fs/io_uring.c | 73 +++
> > include/uapi/lin
ible for either using fdget_pos() or
performing the equivalent serialization by hand.
Cc: Al Viro
Signed-off-by: Lennert Buytenhek
---
fs/readdir.c | 25 +
include/linux/fs.h | 4
2 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/fs/readdir.c b/fs/r
nts().
IORING_OP_GETDENTS may or may not update the specified directory's
file offset, and the file offset should not be relied upon having
any particular value during or after an IORING_OP_GETDENTS call.
Signed-off-by: Lennert Buytenhek
---
fs/io_uring.c
this can be set to zero,
and for subsequent calls, it can be set to the ->d_off field of
the last struct linux_dirent64 returned by the previous call.
Lennert Buytenhek (2):
readdir: split the core of getdents64(2) out into vfs_getdents()
io_uring: add support for IORING_OP_GETDENTS
On Fri, Jan 29, 2021 at 07:37:03AM +0200, Lennert Buytenhek wrote:
> > > > One open question is whether IORING_OP_GETDENTS64 should be more like
> > > > pread(2) and allow passing in a starting offset to read from the
> > > > directory from. (This would requi
On Fri, Jan 29, 2021 at 01:07:10AM +0200, Lennert Buytenhek wrote:
> > > One open question is whether IORING_OP_GETDENTS64 should be more like
> > > pread(2) and allow passing in a starting offset to read from the
> > > directory from. (This would require some m
On Sun, Jan 24, 2021 at 10:21:38PM +, David Laight wrote:
> > One open question is whether IORING_OP_GETDENTS64 should be more like
> > pread(2) and allow passing in a starting offset to read from the
> > directory from. (This would require some more surgery in fs/readdir.c.)
>
> Since direc
On Sat, Jan 23, 2021 at 04:33:34PM -0700, Jens Axboe wrote:
> >> IORING_OP_GETDENTS64 behaves like getdents64(2) and takes the same
> >
> > Could we drop the '64'? We don't, for example, have IOURING_OP_FADVISE64
> > even though that's the name of the syscall.
>
> Agreed, only case we do mimic
On Sat, Jan 23, 2021 at 10:37:25AM -0700, Jens Axboe wrote:
> > IORING_OP_GETDENTS64 behaves like getdents64(2) and takes the same
> > arguments.
> >
> > Signed-off-by: Lennert Buytenhek
> > ---
> > This seems to work OK, but I'd appreciate a review fro
IORING_OP_GETDENTS64 behaves like getdents64(2) and takes the same
arguments.
Signed-off-by: Lennert Buytenhek
---
This seems to work OK, but I'd appreciate a review from someone more
familiar with io_uring internals than I am, as I'm not entirely sure
I did everything quite right.
A
On Wed, Oct 09, 2013 at 09:27:14PM +0200, Sebastian Hesselbarth wrote:
> >This add a compatible for the Marvell Tauros3 cache controller which
> >is compatible with l2x0 cache controllers. While updating the binding
> >documentation, clean up the list of possible compatibles.
> >
>
On Fri, Mar 01, 2013 at 06:30:13PM +0100, Alexander Holler wrote:
> >>From: Lubomir Rintel
> >>
> >>=
> >>[ INFO: inconsistent lock state ]
> >>3.7.0-6.luboskovo.fc19.armv5tel.kirkwood #1 Tainted: GW
> >>-
> >>inconsistent {I
On Sun, Jan 06, 2013 at 10:02:14PM -0500, Nickolai Zeldovich wrote:
> > Good catch, but the patch would be better titled "mwl8k.c: avoid
> > having a working driver", as the station_id return code _is_ needed
> > by the caller in case of success.
>
> I'm not quite sure what you mean -- is there s
On Sun, Jan 06, 2013 at 08:27:22PM -0500, Nickolai Zeldovich wrote:
> Do not dereference p->station_id after kfree(cmd) because p
> points into the cmd data structure.
Good catch, but the patch would be better titled "mwl8k.c: avoid
having a working driver", as the station_id return code _is_ nee
On Fri, Jan 04, 2013 at 03:07:02PM +0100, Lubomir Rintel wrote:
> From: Lubomir Rintel
>
> =
> [ INFO: inconsistent lock state ]
> 3.7.0-6.luboskovo.fc19.armv5tel.kirkwood #1 Tainted: GW
> -
> inconsistent {IN-SOFTIRQ-W} ->
On Mon, Feb 11, 2008 at 02:59:34PM +0100, Thomas Gleixner wrote:
> Subject: futex: disable PI/robust on archs w/o valid implementation
> From: Thomas Gleixner <[EMAIL PROTECTED]>
>
> We have to disable the complete PI/robust functionality for those
> archs, which do not implement futex_atomic_cmp
oc/proc_misc.c:464:
> per_irq_sum = kzalloc(sizeof(unsigned int)*NR_IRQS, GFP_KERNEL);
>
> I am not sure whether this definition actually is used in any of these files.
> Am I being paranoya? anyway, adding parentheses should be safe.
> --
> Add parentheses to prevent operator preced
On Wed, Nov 28, 2007 at 11:23:57AM +0100, Jean Delvare wrote:
> > > 6a8e0e37019c0ffeb0071fae30210baf2c3bdd75
> > > diff --git a/Documentation/feature-removal-schedule.txt
> > > b/Documentation/feature-removal-schedule.txt
> > > index 2af3835..9114379 100644
> > > --- a/Documentation/feature-remo
On Mon, Nov 05, 2007 at 03:23:30PM +0100, Andre Haupt wrote:
> From: Andre Haupt <[EMAIL PROTECTED]>
> Signed-off-by: Andre Haupt <[EMAIL PROTECTED]>
Acked-by: Lennert Buytenhek <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
On Sat, Oct 27, 2007 at 09:02:32PM +0100, Al Viro wrote:
> diff --git a/include/linux/mv643xx_eth.h b/include/linux/mv643xx_eth.h
> index 3f27239..8df230a 100644
> --- a/include/linux/mv643xx_eth.h
> +++ b/include/linux/mv643xx_eth.h
> @@ -8,6 +8,9 @@
> #define MV643XX_ETH_NAME "mv643
On Fri, Oct 26, 2007 at 05:40:22AM -0400, Jeff Garzik wrote:
> arch/arm/mach-pxa/ssp.c|2 +-
> arch/arm/mach-s3c2410/usb-simtec.c |2 +-
> arch/arm/plat-omap/mailbox.c |2 +-
FWIW
Acked-by: Lennert Buytenhek <[EMAIL PROT
-omap/mcbsp.c:
> - remove pointless casts from void*
> - make longer lines more readable
>
> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
FWIW
Acked-by: Lennert Buytenhek <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-integrator/pci_v3.c |8 +-
The vendor_compatible and device_compatible fields in struct
pci_dev aren't used anywhere, and are somewhat pointless. Assuming
that these are historical artifacts, remove them.
Signed-off-by: Lennert Buytenhek <[EMAIL PROTECTED]>
diff --git a/include/linux/pci.h b/include/linux/
On Wed, Oct 24, 2007 at 10:35:33PM -0500, Bill Gatliff wrote:
> >Something broke CONFIG_CMDLINE of ARM (at least) between 2.6.22 and 2.6.23.
> >
> >I don't know whether it was an ARM patch one of those kernel-wide changes.
> >We have futzed with the command-line parsing a bit recently, but the 2.
On Wed, Aug 08, 2007 at 05:28:46PM -0700, Joe Perches wrote:
> Some uses of printk are missing KERN_ on the second
> and subsequent lines.
I'm not the ARM maintainer, but for what it's worth,
the arch/arm/kernel/ecard.c change looks fine to me.
Acked-by: Lennert Buytenhek &
On Wed, Aug 08, 2007 at 07:07:33PM -0400, Chris Snook wrote:
> From: Chris Snook <[EMAIL PROTECTED]>
>
> Some architectures currently do not declare the contents of an atomic_t to be
> volatile. This causes confusion since atomic_read() might not actually read
> anything if an optimizing compile
On Thu, Aug 02, 2007 at 02:06:27AM +0200, Mikael Pettersson wrote:
> > > @@ -52,7 +53,34 @@ futex_atomic_op_inuser (int encoded_op,
> > > static inline int
> > > futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
> > > {
> > > +#ifdef CONFIG_SMP
> > > return -ENOSYS;
>
On Thu, Aug 02, 2007 at 01:00:21AM +0200, Mikael Pettersson wrote:
> @@ -52,7 +53,34 @@ futex_atomic_op_inuser (int encoded_op,
> static inline int
> futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
> {
> +#ifdef CONFIG_SMP
> return -ENOSYS;
> +#else
Since the ca
On Fri, Jul 13, 2007 at 02:12:08AM +0200, Adrian Bunk wrote:
> From: John Donoghue <[EMAIL PROTECTED]>
>
> CONFIG_EP93XX_ETH=y, CONFIG_MII=n results in an obvious link error.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Lennert Buytenhek <[EMAI
- Forwarded message from Lennert Buytenhek <[EMAIL PROTECTED]> -
Date: Wed, 13 Jun 2007 20:40:40 +0200
From: Lennert Buytenhek <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: handle_futex_death() infinite loop
User-Agent: Mutt/1.4.1i
Hi,
If you're also running
On Sun, Jul 01, 2007 at 12:23:16PM +0200, Michael Buesch wrote:
> > More or less. You can't add the resistances like that, since the
> > bus isolation chip buffers the IDSEL signal, but it is correct that
> > if the host's IDSEL resistor is larger than a certain value, the
> > combination of the
On Thu, Jun 28, 2007 at 12:36:20PM +0200, Rodolfo Giometti wrote:
> attached you can find new version of my patch for PXA27x UDC driver
> support against kernel 2.6.22-rc3 (but it applies also ro rc6).
>
> I'd like to know what I have to do in order to prepare this patch for
> kernel inclusion. I
On Sun, Jul 01, 2007 at 12:24:40AM +0200, Michael Buesch wrote:
> > > Hm, I was going to measure the real power advantage with a
> > > PCI-extender card. But my B44B0 card doesn't seem to work in
> > > that extender card. It works perfectly fine sticked directly into
> > > the motherboard, though,
On Sat, Jun 30, 2007 at 11:53:25PM +0200, Michael Buesch wrote:
> > When the interface is down (or driver removed), the BroadCom 44xx card
> > remains
> > powered on, and both its MAC and PHY is using up power.
> > This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface
> > is h
On Sat, Jun 30, 2007 at 04:19:23PM +0100, Matthew Garrett wrote:
> I'd agree that there's a need for a state where we power down as much as
> possible (even at the cost of functionality), but where possible it
> would also be nice to offer a state where the mac is powered down and
> the phy lef
On Wed, May 16, 2007 at 09:05:18PM +0930, Rod Whitby wrote:
> >> So, if the author of these patches wishes to concentrate on big-endian
> >> support first, then we will not say (and have not said) anything which
> >> will block inclusion of a big-endian only version of this driver.
> >
> > The NS
On Wed, May 16, 2007 at 08:16:38PM +0930, Rod Whitby wrote:
> So, if the author of these patches wishes to concentrate on big-endian
> support first, then we will not say (and have not said) anything which
> will block inclusion of a big-endian only version of this driver.
The NSLU2 people are th
On Wed, May 16, 2007 at 08:13:01AM +0100, Christoph Hellwig wrote:
> > >>+#ifndef __ARMEB__
> > >>+#warning Little endian mode not supported
> > >>+#endif
> > >
> > >Personally I'm less fussed about WAN / LE support. Anyone with any
> > >sense will run ixp4xx boards doing such a specialised netw
On Wed, May 09, 2007 at 12:35:40PM +0200, Mikael Pettersson wrote:
> > > Does that mean that the Debian ARM people have their heads so far
> > > up their collective asses that they think that every form of change
> > > is bad and are unable to accept that some forms of change might be
> > > for th
On Wed, May 09, 2007 at 11:35:03AM +0200, Marcus Better wrote:
> > Does that mean that the Debian ARM people have their heads so far
> > up their collective asses that they think that every form of change
> > is bad and are unable to accept that some forms of change might be
> > for the better?
>
On Tue, May 08, 2007 at 06:59:36PM +0200, Krzysztof Halasa wrote:
> >> There may be up to 6 Ethernet ports (not sure about hardware
> >> status, not yet supported even by Intel) - 7 queues * 128 entries
> >> each = ~ 3.5 KB. Add 2 long queues (RX) for HSS and something
> >> for TX, and then crypto
On Wed, May 09, 2007 at 10:58:06AM +0200, Marcus Better wrote:
> >> There _is_ an ARM BE version of Debian.
> >>
> >> It's not an official port, but it's not maintained any worse than
> >> the 'official' LE ARM Debian port is.
>
> > Hmm... That changes a bit. Perhaps we should forget about
> > th
On Tue, May 08, 2007 at 05:28:21PM +0200, Krzysztof Halasa wrote:
> > I was always curious, why do people want to run ixp4xx in LE mode? What
> > are the benefits that overweight the obvious performance degradation?
>
> Debian is indeed a valid reason.
> I wonder if it would be much work to creat
On Tue, May 08, 2007 at 04:31:12PM +0200, Krzysztof Halasa wrote:
> >> +/* Built-in 10/100 Ethernet MAC interfaces */
> >> +static struct mac_plat_info ixdp425_plat_mac[] = {
> >> + {
> >> + .phy= 0,
> >> + .rxq= 3,
> >> + }, {
> >> + .phy
On Tue, May 08, 2007 at 04:12:17PM +0200, Krzysztof Halasa wrote:
> > The queue manager interrupts should probably be implemented as an
> > irqchip, in the same way that GPIO interrupts are implemented. (I.e.
> > allocate 'real' interrupt numbers for them, and use the interrupt
> > cascade mechan
On Tue, May 08, 2007 at 04:47:31PM +0400, Alexey Zaytsev wrote:
> > As with Christian's driver, I don't know whether an SRAM allocator
> > makes much sense. We can just set up a static allocation map for the
> > in-tree drivers and leave out the allocator altogether. I.e. I don't
> > think it's
On Mon, May 07, 2007 at 09:18:00PM +0100, Michael-Luke Jones wrote:
> >Well, I'm told that (compatible) NPEs are present on other IXP CPUs.
> >Not sure about details.
>
> If, by a combined effort, we ever manage to create a generic NPE
> driver for the NPEs found in IXP42x/43x/46x/2000/23xx the
On Mon, May 07, 2007 at 10:00:20PM +0200, Krzysztof Halasa wrote:
> > - the NPE can also be used as DMA engine and for crypto operations.
> > Both are not network related.
> > Additionally, the NPE is not only ixp4xx related, but is
> > also used in IXP23xx CPUs, so it could be placed in
> >
On Mon, May 07, 2007 at 02:07:16AM +0200, Krzysztof Halasa wrote:
> + * Ethernet port config (0x00 is not present on IXP42X):
> + *
> + * logical port 0x000x100x20
> + * NPE 0 (NPE-A) 1 (NPE-B) 2 (NPE-C)
> + * physical PortId
On Tue, May 08, 2007 at 03:19:22AM +0200, Krzysztof Halasa wrote:
> diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c
> b/arch/arm/mach-ixp4xx/ixdp425-setup.c
> index ec4f079..f20d39d 100644
> --- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
> +++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
> @@ -101,10 +10
I'm not sure what the latest versions are, so I'm not sure which
patches to review and which patches are obsolete.
On Tue, May 08, 2007 at 02:46:28AM +0200, Krzysztof Halasa wrote:
> +struct qmgr_regs __iomem *qmgr_regs;
> +static struct resource *mem_res;
> +static spinlock_t qmgr_lock;
> +stat
oving
> >of
> >the architecture dependant code (and explaining why) and one with the new
> >watchdog drivers? I will continue my review today.
>
> I am one of the maintainers of this architecture, (Lennert Buytenhek
> is the other).
Dan has done more work on iop13xx th
On Thu, Apr 26, 2007 at 09:41:22AM -0400, David Acker wrote:
> Here is a quote from Russell that describes what I believe is the main
> problem:
> http://www-gatago.com/linux/kernel/15457063.html
> "
> Has e100 actually been fixed to use the PCI DMA API correctly yet?
> Looking at it, it doesn't
On Mon, Mar 26, 2007 at 01:07:11PM -0700, Paul E. McKenney wrote:
> > > > Does everybody agree on these semantics, though? At least David
> > > > seems to think that mb/rmb/wmb aren't required to order normal
> > > > memory accesses against each other..
> > >
> > > Not on UP. On SMP, ordering i
On Sun, Mar 25, 2007 at 08:24:18PM -0700, Paul E. McKenney wrote:
> > > > > [ background: On ARM, SMP synchronisation does need barriers but
> > > > > device
> > > > > synchronisation does not. The question is that given this, whether
> > > > > mb() and friends can be NOPs on ARM or not (i.e
On Sun, Mar 25, 2007 at 02:15:42PM -0700, Paul E. McKenney wrote:
> > > [ background: On ARM, SMP synchronisation does need barriers but device
> > > synchronisation does not. The question is that given this, whether
> > > mb() and friends can be NOPs on ARM or not (i.e. whether mb() is
> > >
On Fri, Mar 23, 2007 at 01:43:53PM +, David Howells wrote:
> > [ background: On ARM, SMP synchronisation does need barriers but device
> > synchronisation does not. The question is that given this, whether
> > mb() and friends can be NOPs on ARM or not (i.e. whether mb() is
> > supposed
On Sun, Dec 17, 2006 at 11:02:10PM +0200, Riku Voipio wrote:
> > > bah. 2.6.20-git shows nothing (with or without Lennert's patch) after
> > > the following:
>
> > > Uncompressing
> > > Linux..done,
> > > b
On Sun, Dec 17, 2006 at 12:31:34AM +0100, Francois Romieu wrote:
> > Sounds good. How about something like the patch below plus the
> > corresponding r8169 diff?
>
> Go wild.
Martin/Riku, I'm pretty busy with other stuff at the moment, can you
give this (on top of 2.6.20-rc1) a spin?
Index:
On Fri, Dec 15, 2006 at 09:14:35PM +, Russell King wrote:
> > > > Is there a way we can have this done by default on the n2100? I guess
> > > > that since it's a PCI device, there isn't much hope for that..?
> > >
> > > Do you mean an automagically tuned default value based on CONFIG_ARM ?
>
On Sat, Dec 16, 2006 at 01:54:39AM +0100, Francois Romieu wrote:
> > No, that wouldn't make sense, that's like making a workaround depend on
> > arch == i386.
> >
> > I'm thinking that we should somehow enable this option on the n2100
> > built-in r8169 ports by default only. Since the n2100 als
On Fri, Dec 15, 2006 at 09:15:22PM +0100, Francois Romieu wrote:
> > Is there a way we can have this done by default on the n2100? I guess
> > that since it's a PCI device, there isn't much hope for that..?
>
> Do you mean an automagically tuned default value based on CONFIG_ARM ?
No, that woul
On Thu, Nov 23, 2006 at 12:16:56AM +0100, Francois Romieu wrote:
> You can apply the patch below and 'modprobe r8169 ignore_parity_err=1'.
Is there a way we can have this done by default on the n2100? I guess
that since it's a PCI device, there isn't much hope for that..?
-
To unsubscribe from t
On Wed, Dec 06, 2006 at 07:47:22PM +, David Howells wrote:
> > > Pre-v6 ARM doesn't support SMP according to ARM's atomic.h,
> >
> > That's not quite true, there exist ARMv5 processors that in theory
> > can support SMP.
>
> I meant that the Linux ARM arch doesn't support it:
Ah, yes, not c
On Wed, Dec 06, 2006 at 04:43:14PM +, David Howells wrote:
> Pre-v6 ARM doesn't support SMP according to ARM's atomic.h,
That's not quite true, there exist ARMv5 processors that in theory
can support SMP.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Wed, Dec 06, 2006 at 12:22:26AM +, Russell King wrote:
> Enabling EABI needs a compiler which supports EABI. That's where I
> get fuzzy but recent gcc 4 should be suitable. I have had it suggested
> to me that EABI support in the toolchain isn't all that stable at the
> moment.
I use a b
nsole UART driver from going into a mode where it reports
"ttyAM0: X input overrun(s)" every couple of keystrokes.
Signed-off-by: Lennert Buytenhek <[EMAIL PROTECTED]>
Index: linux-2.6.19-rc5/drivers/serial/amba-pl010.c
===
On Fri, Jul 08, 2005 at 02:34:56PM -0400, John W. Linville wrote:
> Some PCI devices lose all configuration (including BARs) when
> transitioning from D3hot->D0. This leaves such a device in an
> inaccessible state. The patch below causes the BARs to be restored
> when enabling such a device, so
(please CC, not on the list)
Hi all,
IXP2000 (ARM-based) platforms use a separate 'struct resource' for PCI
MEM space. Resource allocation for PCI BARs always fails because the
'root' resource (the IXP2000 PCI MEM resource) always has the entire
address space (-) free, and find_r
On Wed, Mar 23, 2005 at 06:03:30PM -0800, Ben Greear wrote:
> I have two 4-port e1000 NICs in the system, on a riser card.
How is the riser card wired? F.e. does it have a single edge
connector, and provides two PCI slots, or does it have a tiny
additional edge connector that routes REQ#/GNT#/IN
(please CC, not on the list.)
Hi all,
I have an embedded machine that needs a _tiny_ little bit more memory
for some of its tasks than it has. Unfortunately, it does not have
an IDE or USB controller, but it does have a 10/100 and three gigabit
ethernet interfaces.
There have been a number of e
On Thu, Feb 03, 2005 at 11:51:27AM -0800, Stephen Hemminger wrote:
> Recent 2.6 does a more advanced form of port randomization already
> using address hash at connect time. tcp_v4_get_port is only used for
> the case of applications that explicitly bind to port zero to find a
> free port.
Is an
On Fri, Jan 28, 2005 at 12:14:30AM +, Russell King wrote:
> The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
Hmmm, I recall e100 working fine on a Radisys ENP-2611, which has a
IXP2400 (xscale) in big-endian mode, running 2.6. This particular
board had its root fs NFS-
Intended behaviour. This is because of the access checks done in the
netlink code. Misleading, yes.
On Sun, 25 Mar 2001, James Stevenson wrote:
>
> Hi
>
> would somebody be able to explain to me
> when you try to open /dev/tap0 which is a
> character device file which has the permissions
>
> F
On 25 Feb 2001, Trond Myklebust wrote:
> > I was hopping to avoid unmounting, as I would have to shut
> > about everything down to do that.
>
> It looks as if you'll have to do that. 'mount -oremount' does not
> really cause the root filehandle to get updated. The only thing it
> does
On Wed, 13 Dec 2000, James Simmons wrote:
> > included a patch against 2.4.0-test9 (should apply against latest but
> > haven't checked) which adds the config option to have a bsd-style cursor
> > in VT's by default. I was hoping it might be considered for inclusion so
> > that I don't have to
Hi,
included a patch against 2.4.0-test9 (should apply against latest but
haven't checked) which adds the config option to have a bsd-style cursor
in VT's by default. I was hoping it might be considered for inclusion so
that I don't have to patch it in myself every time :-)
cheers,
Lennert
-
79 matches
Mail list logo
