On Tue, 16 Jul 2002, Cliff Woolley wrote:
Uhh... What Sander said. How is my commit exporting a symbol? It's
*UN*exporting the symbol. :-)
Ahh, I see you already responded to this under a different subject line.
Looks like both of us need our coffee. :)
On Tue, 16 Jul 2002, Brad Nicholes wrote:
The problem with the MOD_CGI case is that it *doesn't* call
pipe_bucket_read() with APR_BLOCK_READ. In fact it calls it with
APR_NONBLOCK_READ which is what prompted the modification in the first
place. If your analysis as to the definitions of
On Tue, 16 Jul 2002, Brad Nicholes wrote:
protocol.c is compared against the macro APR_STATUS_IS_EAGAIN(). The
problem for both NetWare and Win32 is that this macros is defined to
test the rv against WSAEWOULDBLOCK rather than EWOULDBLOCK. Since the
call to select() in apr_poll() actually
On Mon, 15 Jul 2002, Brian Pane wrote:
(seconds 20) + microseconds
Yeah, but addition and subtraction of the resulting scalars would require
just as many carry/underflow checks as a structure would...
I mean, that's all that really is: a bitfield.
--Cliff
On Mon, 15 Jul 2002, Bill Stoddard wrote:
Cliff demonstrates that there is significant loss of accuracy using just a
shift. I believe (faith? :-) that there is a simple solution to this. Don't
know what it is just now though...
More numerical musings:
Without compensation:
1-21 seconds come
On Mon, 15 Jul 2002, Brian Pane wrote:
seconds = (t 20) + (t 24)
That probably isn't accurate enough, but you get the basic idea:
sum a couple of t/(2^n) terms to approximate t/100.
What do you think?
Sounds like the right idea. But I'm still not sure this isn't too
complicated.
On Sun, 14 Jul 2002, William A. Rowe, Jr. wrote:
Drop _t since this is a scalar type and not a structure/opaque?
Let's plze not do that. We've managed to be beautifully consistent in
APR on that front, let's not backtrack now.
With apr_time... our functions can stay as is.
I think I
On 12 Jul 2002 [EMAIL PROTECTED] wrote:
+ [fielding; Cliff says he has a sample app. I still don't know how
+ he uses them without making implementation assumptions about
+ apr_time_t everywhere (there is no print routine for microsecond
+ resolution), but I'll
On Thu, 11 Jul 2002, Justin Erenkrantz wrote:
Regarding this apr_time_t 'debate,' are we going to be operating
under majority voting or consensus voting?
Questions about the code are always resolved by consensus or lazy
consensus (which clearly does not apply here :). Majority is only ever
On Thu, 11 Jul 2002, Roy T. Fielding wrote:
As near as I can tell from looking at the code and cvs logs, the only
reason we have apr_size_t and apr_ssize_t is because win32 wants to
define apr_ssize_t. Is that because win32 doesn't have ssize_t?
Is there a reason why we don't simply define
On 12 Jul 2002 [EMAIL PROTECTED] wrote:
-apr_file_pipe_timeout_set(p, 0);
+// Only mess with the timeout if we are in a blocking state
+// otherwise we are already nonblocking so don't worry about it.
+if (timeout 0) {
+
On Thu, 11 Jul 2002, Greg Marr wrote:
I keep thinking that APR_USEC_PER_SEC should be (1 20), or now
(1 APR_USEC_BITS) instead of the magical constant. I have no way
of verifying with a quick glance that 1048576 is really 2^20.
You don't know your powers of 2? Memorize, Greg, Memorize.
On 11 Jul 2002 [EMAIL PROTECTED] wrote:
+ -1: aaron [veto for reusing the apr_time_t identifier for a new
use.
+I'm ok with apr_timeval_t.]
If we're avoiding apr_time_t because of confusion with the POSIX time_t,
it makes no sense whatsoever to use
On Wed, 10 Jul 2002, Thom May wrote:
Hrm, think I prefer apr_(u|g)id_
Likewise.
--Cliff
On Mon, 8 Jul 2002, Tony Finch wrote:
I note that apr_time_t is a bad name in the first place, because POSIX
reserves all names ending in _t for the implementation. Feel free to
ignore this exceedingly irritating naming rule :-)
I think we uniformly ignore this rule already. Everything in
On Mon, 8 Jul 2002, William A. Rowe, Jr. wrote:
Can we please use apr_memchr and apr_strncasecmp? I don't mind
if we #define to the platform fn's, and blow up when downgrading the
clib or moving to an older machine without those functions.
+1
--Cliff
On 2 Jul 2002 [EMAIL PROTECTED] wrote:
wrowe 2002/07/02 11:18:52
Modified:test testatomic.c
Log:
We shouldn't presume any specific int sizes here, no?
+apr_atomic_t oldval;
+apr_atomic_t casval = 0;
This will fix some things and break others.
On Tue, 2 Jul 2002, Aaron Bannert wrote:
I'm not really comfortable doing a change like this without changing
the name for apr_time_t. If we are going to change the semantics
we need to create a new identifier.
AFAIK, changing the name has been part of the plan all along. I was under
the
On 2 Jul 2002 [EMAIL PROTECTED] wrote:
wrowe 2002/07/02 11:20:57
Modified:buckets apr_brigade.c
Log:
New emit on win32. Since this is a heap bucket, we are always dealing
in start offsets that fit in apr_size_t. This doesn't need the file
sized apr_off_t
On Tue, 2 Jul 2002, Aaron Bannert wrote:
Adding another apr_status_t code would be ok. Maybe APR_FAILURE to
complement APR_SUCCESS, or we could go all out and add APR_TRUE
and APR_FALSE...
I was thinking about that. But then APR_FALSE == APR_SUCCESS for the
normal semantics to work out.
On Tue, 2 Jul 2002, Aaron Bannert wrote:
Non-APR functions that want to use APR's apr_status_t codes don't have
the luxury of being able to add another code, so given the performance
tradeoff maybe this is the way to go...
Well, they *can*, but APR doesn't know what to do with them. That's
On Tue, 2 Jul 2002, Ryan Bloom wrote:
P.S. I am getting a say in the child's name, just not as big a say as
Kelly. :-)
As long as you don't name him/her void or apr_bloom_child or
something, you'll be fine. ;-)
--Cliff
On Sat, 29 Jun 2002, Brian Pane wrote:
This patch adds an apr_file_setaside() function that moves
an apr_file_t from one pool to another without doing any
dup(2) or mmap(2) operations.
Why not keep the dup() and add in a transfer ownership feature like the
mmap dup uses? After all, the whole
On Sat, 29 Jun 2002, Brian Pane wrote:
Which dup() do you mean: the dup(2) or the naming convention of
using _dup*() for this family of apr_file_t functions?
Sorry, I should have been more precise. apr_file_dup() was what I was
referring to.
On second thought though, I suppose I wouldn't
On Sat, 29 Jun 2002, Brian Pane wrote:
#define apr_mmap_setaside(new, old, pool) apr_mmap_dup(new, old, pool, 1);
/* the '1' at the end is the transfer ownership flag
+1, sounds good.
--Cliff
On Fri, 28 Jun 2002, Ian Holsman wrote:
do you think that it is worthwhile having a APR function to determine
system load ?
That could be nice.
On Fri, 28 Jun 2002, Brian Pane wrote:
I remembered why memcpy won't help here: we don't know the
length in advance. But I managed to speed up apr_brigade_puts()
by about 30% in my tests by optimizing its main loop. Does this
patch reduce the apr_brigade_puts() overhead in your test
On Sat, 29 Jun 2002, Brian Pane wrote:
I tried this, and it didn't unroll the loop. That's probably
because some of information needed to unroll the loop effectively
is unknown to the compiler.
Hm. Okay, well, if we're going to do this, can we split it out into a
separate macro (my_strncpy
On Sat, 29 Jun 2002, Cliff Woolley wrote:
Also, isn't it true that your patch now causes the buffer bucket to always
have 0-7 unused bytes at the end?
Oh duh, nevermind on this point, my fault. I misread the loop condition.
--Cliff
On Sat, 29 Jun 2002, Cliff Woolley wrote:
some way that would allow us to coalesce the writes.
Alignment issues would kill us here, aren't they? That sucks. G.
On 28 Jun 2002, Jeff Trawick wrote:
The first fun comes during buildconf processing:
$ ./buildconf
buildconf: checking installation...
buildconf: autoconf version 2.53 (ok)
buildconf: libtool version 1.3.4 (ok)
Copying libtool helper files ...
Creating include/arch/unix/apr_private.h.in
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
I have one bit that must be broken before 1.0, and cannot be remedied easily.
I'd like to simply break these things before Apache 2.0.40 is tagged.
+1 on all counts. 2.0.40 will already require a full recompile anyway.
Other users of APR must
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
IMHO, the implementation is what people have tested, not the documented
behavior. Use the source, luke :-)
But what I'm saying is that I don't think anybody *has* tested it. I
couldn't find a single use case in Apache where the called function
On Fri, 28 Jun 2002, Justin Erenkrantz wrote:
Sounds like SMS. We could never overcome speed limitations and we
always seemed to place blame on the function pointers as the reason
why the SMS performance wasn't as good as pools.
We had function pointers *and* wrapper functions. We never
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
If it is used by -anybody- they trust the existing implementation.
That said, it should behave sensibly. The fact that you've asked three
times says you want to change it.
Hehehehe You noticed? :) Sorry to be a pest, I'm just getting sick of
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
What I'd like to propose is that we document that, for any given status
code, _more_ than one APR_STATUS_IS* macro can match, and it's the
programmer's responsibility to decide in what order to make the tests.
+1
--Cliff
On Fri, 28 Jun 2002, Justin Erenkrantz wrote:
p-alloc
and
#define apr_palloc(...) p-alloc
None, but that's not what we were doing with SMS.
to the fact that we used to have a function like this:
apr_palloc()
{
return p-alloc();
}
Yeah, but it did even more. It was more like:
On 27 Jun 2002, Jeff Trawick wrote:
So I guess sizeof(long) is 8 bytes on 64-bit HP-UX? sizeof(long) is
still 4 on 64-bit AIX.
$ uname -a
HP-UX nova126 B.11.00 U 9000/785 2010844465 unlimited-user license
$ cat test.c
#include stdio.h
int main()
{
Huh, that's odd. I swear I tested this. I'll look into it tomorrow and
place this in patches/apply_to_2.0.39/ if need be.
Thanks,
Cliff
On Wed, 19 Jun 2002 itojun@iijlab.net wrote:
regarding to random number device in apr - thanks for
--with-randomdev=foo configure option in
On Tue, 18 Jun 2002, it was written:
the attached patch may not be correct. sorry.
Well, just keep me posted.
Thx,
Cliff
On Sun, 16 Jun 2002 itojun@iijlab.net wrote:
on unix platforms, apr shipped with httpd 2.0.36 asks for truely-
random number (/dev/random) instead of so-so random number
(/dev/urandom). question: is it really necessary to require
/dev/random instead of /dev/urandom?
On Mon, 17 Jun 2002, hiroyuki hanai wrote:
Ben Laurie wrote:
you can specify with a ./configure argument which one you want. It will
be part of 2.0.38.
I still say it should be runtime configurable.
I strongly agree with Ben.
Well, so do I. But somebody's got to sit down and code
On Tue, 11 Jun 2002, William A. Rowe, Jr. wrote:
However, we aught to define convenience macros;
#define APR_BUSEC_PER_SEC 1048576
I was thinking the same thing. +1.
--Cliff
On Wed, 12 Jun 2002, Miguel Camargo wrote:
I am trying to modify the APR library just to add some specific features
in it and use it in Apache.
What kinds of things, just out of curiosity?
But i have some doubts about the meaning and the differences among the
macro definitions of:
The
On Wed, 12 Jun 2002, Cliff Woolley wrote:
There are a *few* cases where we use HAVE where we should be using HAS,
and those ought to be cleaned up. But we're mostly consistent. :)
Responding to this message caused me to take a second and actually go look
at how consistently we're using
On 12 Jun 2002 [EMAIL PROTECTED] wrote:
+#define APR_TIME_USEC(time) ((apr_int32_t)(time) % APR_USEC_PER_SEC)
+
+#define APR_TIME_SEC(time) ((apr_int64_t)(time) / APR_USEC_PER_SEC)
+
+#define APR_TIME_FROM_SEC(sec) ((apr_time_t)(sec) * APR_USEC_PER_SEC)
+
+#define
On Wed, 12 Jun 2002, Miguel Camargo wrote:
First of all,thank you Cliff and Ryan for your answers!
No problem. :)
../apr/include/arch/unix/fileio.h:
at the begining:
#if APR_HAVE_NEWFEATURE_H
#include newfeature.h
#endif
Right.
APR code...
#if APR_HAS_NEWFEATURE ? /* or also
On Wed, 12 Jun 2002, William A. Rowe, Jr. wrote:
It seems that we've decided sometime back that all macro-fns should be
declared in ucase. Now, we can debate that issue again, but if someone
could pull up a reference to that thread in the archives it would be
most cool.
Somewhere in [EMAIL
On Wed, 12 Jun 2002, William A. Rowe, Jr. wrote:
time [(apr_time_t]] Enter
APR_USEC_PER_SEC [(apr_time_t)100] Enter
Ah. I missed the fact that APR_USEC_PER_SEC has a built-in cast.
Nevermind.
--Cliff
On Mon, 10 Jun 2002, Pier Fumagalli wrote:
Now, the question is _why_ that thing is called and why libsvn_ra_local.so
does not exist (if shared is disabled, it should be compiled in, right?)...
I was under the impression that it was one of those things of SVN
attempting to load all extensions
On Mon, 10 Jun 2002, Roy T. Fielding wrote:
I know of one existing bug in httpd that I would consider a
showstopper, if I were RM, due to the way APR handles time.
Are you going to tell me what it is? :)
[Moved here from [EMAIL PROTECTED]
On Thu, 6 Jun 2002, Justin Erenkrantz wrote:
On Thu, Jun 06, 2002 at 04:51:10PM -0700, Aaron Bannert wrote:
I'd *love* to see progress on something like this, but whenver I start
thinking about this kind of a MPM I run into the problem where brigades
On Mon, 3 Jun 2002, William A. Rowe, Jr. wrote:
Would it make sense to introduce APR_FILE_PIPECHECK to ask
apr_os_file_put() to first check an apr_file_info_get() of the handle, and
set the flags correctly if this is a pipe device (e.g. pass this flag for
apr_file_open_stdin/out/err when
On Sun, 2 Jun 2002, Ryan Bloom wrote:
+enum {
+/** This bucket type represents actual data to send to the
client. */
+APR_BUCKET_DATA = 0,
+/** This bucket type represents metadata. */
+APR_BUCKET_METADATA = 1
+} is_metadata;
By
On Mon, 3 Jun 2002, Paul Marculescu wrote:
I made a little patch for apr-util's apr_uri.c to handle win32 absolute
paths under file:// schema.
I'll admit it strikes me as a bit odd to be supporting platform-specific
forms of _uniform_ resource identifiers. :-) Is this a
standards-recognized
On Mon, 3 Jun 2002, Paul Marculescu wrote:
PS: Please be sure to follow our styleguide when submitting patches...
namely, no tabs. :)
There were some tabs in the apr_uri.c as I cvs co it a few minutes ago
(again, to make sure).
so I got a little confused. Anyway, I'll keep that in mind.
On 31 May 2002 [EMAIL PROTECTED] wrote:
rbb 2002/05/31 13:51:20
Modified:buckets apr_buckets_eos.c apr_buckets_file.c
apr_buckets_flush.c apr_buckets_heap.c
apr_buckets_mmap.c apr_buckets_pipe.c
On Fri, 31 May 2002, Ryan Bloom wrote:
I considered that, but I am actually thinking of the future, where there
are different types of data. For example, when we want to send the
headers down the filter stack as a part of the brigade, that is metadata
and should be marked as such. However,
On Fri, 31 May 2002, Ryan Bloom wrote:
Length does always mean data, but length has nothing to do with this
discussion.
Just to update everybody else, we just had a big smackdown discussion
about this on IRC. We had to cut it short for various reasons, though.
We'll pick it back up later
On 28 May 2002 [EMAIL PROTECTED] wrote:
jwoolley02/05/28 16:15:10
Modified:.CHANGES configure.in
Log:
Added --with-devrandom=[DEV] configure flag which allows a particular
/dev/random-compatible device to be specified, overriding the
default search path
Oops, I missed one thing:
On Tue, 28 May 2002, Cliff Woolley wrote:
1) If --with-egd=path is specified, --without-devrandom is assumed
and the EGD socket is used as the source of entropy.
2) Otherwise, if --with-devrandom=DEV is specified with a particular
device, that device
On Mon, 27 May 2002, Ben Laurie wrote:
Hmmm. Well, IMO it should be configurable at runtime, especially since
some other OSes have yet more sources of entropy (/dev/arandom for
example).
Oh good, that matches the patch I've been working on. I'll post it in a
little while. PS: is
On Sun, 26 May 2002, Ben Laurie wrote:
3) open /dev/random in non-blocking mode and defer EAGAIN reads
until later (read it at startup; if it would block, try again when
the entropy is actually needed, failing if it isn't ready by then
-- no idea if this would even work).
Grr. We
On Sun, 26 May 2002, Ben Laurie wrote:
What about a --with-devrandom=path option for people who do want to go
the /dev/urandom route?
I'm starting to prefer this option I think.
Surely its configurable anyway? Changing the default strikes me as
something that will bite you if you aren't
= 0x8111ce0 Mozilla/2
p_end = 0x8111ce8 2
I'll look into this a bit more and report back in a while.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Thu, 23 May 2002, Cliff Woolley wrote:
#0 match_boyer_moore_horspool (this_pattern=0x8111cf0,
s=0x8161dc4 Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; ),
slen=58) at apr_strmatch.c:133
(Note that -71 is a non-printable superscript 1 or something.)
PS: It's not evident from
On 24 May 2002, Jeff Trawick wrote:
Unfortunately we can't just pstrdup because we have no pool to dup into.
+1
The API needs to be changed to use const char * if at all possible.
This isn't the first time this has come up.
Already did that along with my commit yesterday. :)
--Cliff
(/dev/random)
rand=1
else
case $host in
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
be done
without impacting the performance of the other, more heavily-used formats
in a horrendous way.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
the macros out, I can... it's only three lines per if-block.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
), and that it was
in the Win32-specific time code.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Tue, 21 May 2002, Cliff Woolley wrote:
Didn't someone post a patch for this months ago? I remember it was an
extraneous timezone add (or subtract, one of the two), and that it was
in the Win32-specific time code.
Was this it, perhaps?
Index: time.c
On Tue, 21 May 2002, Cliff Woolley wrote:
Index: time.c
===
RCS file: /home/cvs/apr/time/win32/time.c,v
retrieving revision 1.32
diff -u -d -r1.32 time.c
--- time.c 15 Apr 2002 00:01:09 - 1.32
+++ time.c 21
On Fri, 17 May 2002, Justin Erenkrantz wrote:
No, there isn't any OS-specific code in the LDAP section, so the code we
have is inherently portable. It's only related to how we deal with the
different LDAP libraries that are available. For rationale, I see the
DBMs as the proper predecent.
On Fri, 17 May 2002 [EMAIL PROTECTED] wrote:
There is a:
#define APR_WANT_MEMFUNC
This seems to interact with the above; i.e. when you do not get apr_pools
in early enough. Is this avoidable; can we warn for this ?
I'm not sure I understand what the problem is. Is there a
bumped the MMN for Apache 2.0.37... can we just call that
good enough and note this as a change that must be made? It's a simple
search and replace.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
to the codebase every time we
want another 1% improvement. We'll end up with an unmaintainable codebase;
it'll run wicked fast, but we won't be able to fix or improve it.
A point... and the reason I said +0 and not +1.
--Cliff
--
Cliff Woolley
was never generated. Now at least it would get
built by the Makefile if it *did* exist, which is more than used to
happen.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
the real question is this: is it ever possible for strlen()+memcpy() to
be faster than the while loop used here? I believe the answer is no.
+0 on the optimization.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On 11 May 2002 [EMAIL PROTECTED] wrote:
+f-can_mmap = 1;
Great, thanks!
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
for getting rid of the macro. Somebody on Win32
will probably come up with a good reason though. But if that's the case,
why don't we use the thing?
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
(1);
}
Cut-and-pastos on the if conditionals, I assume?
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Ouch... the API docs on apr.apache.org are way out of date. How do I
update them?
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Why do the apr_dbm_*_ex() calls use strings instead of symbolic constants
to select a dbm type?
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
!
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
for me).
That's my guess as well.
Or, you still haven't resolved the conflict created when I added
the config.{guess|sub} to the repository. -- justin
Nope, did it.
Thanks,
Cliff
--
Cliff Woolley
[EMAIL PROTECTED
On Fri, 19 Apr 2002, Justin Erenkrantz wrote:
I also tweaked expat's buildconf.sh to match APR's invocation of
libtoolize so that it shouldn't update with local copies. -- justin
Thanks!
--
Cliff Woolley
[EMAIL PROTECTED
want to hang onto that return
code, though, like this:
while ((rc = apr_file_read(file, buffer, len)) != APR_SUCCESS)
{
...
}
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED
On Thu, 18 Apr 2002, Joe Orton wrote:
Sure - I'd just hope the change could be made for the time being, until
someone gets round to that, since currently APR won't build on
combinations of modern glibc/kernel.
Which combinations? It works fine for me on glibc 2.2.5 / linux 2.4.18.
Granted, I
On Thu, 18 Apr 2002, Justin Erenkrantz wrote:
I committed this second part as with that testatomic passes here
on my Linux/SMP box.
It passed for me beforehand on my non-SMP linux box, but it still passes
afterward, so +1 on that commit.
--Cliff
On Wed, 17 Apr 2002, Dave Hill wrote:
My first inclination was to think what a bonehead thing to do, my
second inclination was that maybe apr should protect me from myself a
bit more
...
-or-
Wouldn't it make sense for me just to check my arguments be for calling
apr :-)
APR typically
to the cleanup function itself, but it's static
to apr/mmap/*/mmap.c.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
any of this?
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
pool cleanups
work internally, but especially with the changes proposed for
apr_allocator_* to have a freelist size limit and so forth, we could get
ourselves into trouble easily with a feature like this.
--Cliff
--
Cliff Woolley
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
= mmap_cleanup(mm)) == APR_SUCCESS)) {
apr_pool_cleanup_kill(mm-cntxt, mm, mmap_cleanup);
return APR_SUCCESS;
}
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
201 - 300 of 538 matches
Mail list logo
