10:34 p.m.
Hi all
Last week at the ASWG conference call I took the action of defining some
ground rules for _DSD submissions. I have drafted some up here. I¹d be
grateful to know your thoughts.
Cheers
Charles
Introduction
============
The following provides rules for the process of submitting _DSD
properties. This process must be followed by vendors wishing to see their
drivers supported by OS vendors that support ACPI.
What properties can be described by _DSD
========================================
_DSD stands for device specific data, it is an object in ACPI that may be
associated with a device to describe specific device properties that are
not covered by other mechanisms in the ACPI specification. An example may
be a mac address, or phy for an networking device.
What properties must not be described by _DSD
=============================================
_DSD must only be used to describe properties that are specific to a
device, rather than properties of the system as whole. i.e. Generic
properties that are required by generic kernel frameworks must not be
described with _DSD.
_DSD must not be used to describe properties that are already covered in
the ACPI specification.
For a system described with ACPI, it must not a requirement that any of
the following areas need and OS to evaluate _DSD in order to work:
- Support dynamic device configurations (hot add/removal)
- Support hardware abstraction through control methods
- power management
- thermal management
- RAS interfaces
_DSD must not be used to describe properties that are specific to an
operating system. For example properties with OS names in the key
would not allowed.
Submitting a binding
====================
<Insert previous mails from Al Stone on the dsd too and dsd(a)acpica.org>
Becoming a reviewer
===================
Anybody who is member of the dsd(a)acpica.org can be a reviewer.
Becoming a maintainer
=====================
_DSD maintainership is a meritocracy. The process is:
1. You submit a request dsd(a)acpica.org to become maintainer
2. Existing maintainers take a view on teh merit of the request based
on the track record of the person making the request in:
2.1 OS verndors. Eg FreeBSD, RH, or Windows may propose a maintainer
2.2 Existing FW representation technologies: ie person is a known
ACPI contributor or Device Tree contributor or maintainer
<< Other stuff to eventually include >>
========================================
Dsd tool stuff from Al, Rules on what properties look like from Rafael
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and
may also be privileged. If you are not the intended recipient, please notify the sender
immediately and do not disclose the contents to any other person, use it for any purpose,
or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England
& Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in
England & Wales, Company No: 2548782
7:21 a.m.
Thanks for doing this, Charles...
On 09/17/2015 06:34 AM, Charles Garcia-Tobin wrote:
Hi all
Last week at the ASWG conference call I took the action of defining some
ground rules for _DSD submissions. I have drafted some up here. I¹d be
grateful to know your thoughts.
Cheers
Charles
Introduction
============
The following provides rules for the process of submitting _DSD
s/_DSD/_DSD
device/
properties. This process must be followed by vendors wishing to see
their
drivers supported by OS vendors that support ACPI.
What properties can be described by _DSD
========================================
_DSD stands for device specific data, it is an object in ACPI that may be
_DSD
stands for Device Specific Data. It is an object in ACPI that may be
associated with a device to describe specific device properties that
are
not covered by other mechanisms in the ACPI specification. An example may
be a mac address, or phy for an networking device.
s/mac/MAC/; s/phy/a PHY/
What properties must not be described by _DSD
=============================================
_DSD must only be used to describe properties that are specific to a
device, rather than properties of the system as whole. i.e. Generic
s/i.e.
Generic/I.e., generic/
properties that are required by generic kernel frameworks must not
be
described with _DSD.
_DSD must not be used to describe properties that are already covered in
the ACPI specification.
More specificity here would be good. Examples showing what is and is not
allowed would be very useful.
Using _DSD for things like clocks should be explicitly mentioned as not
at all allowed -- perhaps some cut'n'paste from the Linux kernel docs?
For a system described with ACPI, it must not a requirement that any
of
s/not/not be/
the following areas need and OS to evaluate _DSD in order to work:
s/and OS/an OS/
- Support dynamic device configurations (hot add/removal)
- Support hardware abstraction through control methods
- power management
- thermal management
- RAS interfaces
Stating a "why?" would be good here. I _think_ the implication is that
we're trying to avoid executing the ACPI interpreter at these times, but
stating that explicitly would be best.
_DSD must not be used to describe properties that are specific to an
operating system. For example properties with OS names in the key
would not allowed.
Submitting a binding
====================
<Insert previous mails from Al Stone on the dsd too and dsd(a)acpica.org>
I've started collecting some of this documentation in a branch on github:
https://github.com/ahs3/dsd/tree/v-next. There's a design-principles.txt
with Rafael's suggestions and our other commentary, and I'll put a draft
of this in there, too.
I think this section should be a separate document, as well as the bits below
on review/maintenance.
Becoming a reviewer
===================
Anybody who is member of the dsd(a)acpica.org can be a reviewer.
Becoming a maintainer
=====================
_DSD maintainership is a meritocracy. The process is:
1. You submit a request dsd(a)acpica.org to become maintainer
2. Existing maintainers take a view on teh merit of the request based
s/teh/the/
on the track record of the person making the request in:
2.1 OS verndors. Eg FreeBSD, RH, or Windows may propose a maintainer
2.1 OS
vendors; e.g., FreeBSD, Red Hat or Microsoft may propose a maintainer
2.2 Existing FW representation technologies: ie person is a known
I think this should be s/ie/e.g.,/ -- correct?
ACPI contributor or Device Tree contributor or maintainer
IMHO, there needs to be a single final arbiter. Suppose there are some
number of maintainers, and they disagree on a submission. Someone will
need to make the final decision. If there is no final arbiter, there is
the risk of getting things stuck at some point, with no way to unstick
them.
<< Other stuff to eventually include >>
========================================
Dsd tool stuff from Al, Rules on what properties look like from Rafael
Yup. See above.
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and
may also be privileged. If you are not the intended recipient, please notify the sender
immediately and do not disclose the contents to any other person, use it for any purpose,
or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in
England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in
England & Wales, Company No: 2548782
_______________________________________________
DSD mailing list
DSD(a)acpica.org
https://lists.acpica.org/mailman/listinfo/dsd
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Linaro Enterprise Group
al.stone(a)linaro.org
-----------------------------------
8:41 a.m.
Hi Al
On 17/09/2015 22:21, "DSD on behalf of Al Stone" <dsd-bounces(a)acpica.org
on behalf of al.stone(a)linaro.org> wrote:
Thanks for doing this, Charles...
On 09/17/2015 06:34 AM, Charles Garcia-Tobin wrote:
> Hi all
>
> Last week at the ASWG conference call I took the action of defining some
> ground rules for _DSD submissions. I have drafted some up here. I¹d be
> grateful to know your thoughts.
>
> Cheers
>
> Charles
>
>
> Introduction
> ============
> The following provides rules for the process of submitting _DSD
s/_DSD/_DSD device/
Ta'
> properties. This process must be followed by vendors wishing to see
>their
> drivers supported by OS vendors that support ACPI.
>
>
> What properties can be described by _DSD
> ========================================
>
> _DSD stands for device specific data, it is an object in ACPI that may
>be
_DSD stands for Device Specific Data. It is an object in ACPI that may be
Ta'
> associated with a device to describe specific device properties that are
> not covered by other mechanisms in the ACPI specification. An example
>may
> be a mac address, or phy for an networking device.
s/mac/MAC/; s/phy/a PHY/
Yup, see thread with Rafael, will probably change this, his suggestion had
much better spelling than mine :-P
>
> What properties must not be described by _DSD
> =============================================
>
> _DSD must only be used to describe properties that are specific to a
> device, rather than properties of the system as whole. i.e. Generic
s/i.e. Generic/I.e., generic/
> properties that are required by generic kernel frameworks must not be
> described with _DSD.
>
> _DSD must not be used to describe properties that are already covered in
> the ACPI specification.
More specificity here would be good. Examples showing what is and is not
allowed would be very useful.
Using _DSD for things like clocks should be explicitly mentioned as not
at all allowed -- perhaps some cut'n'paste from the Linux kernel docs?
Sounds good. I try to tackle some examples below, but will redo this bit.
> For a system described with ACPI, it must not a requirement that any of
s/not/not be/
Ta’
> the following areas need and OS to evaluate _DSD in order to work:
s/and OS/an OS/
Ta’
> - Support dynamic device configurations (hot add/removal)
> - Support hardware abstraction through control methods
> - power management
> - thermal management
> - RAS interfaces
Stating a "why?" would be good here. I _think_ the implication is that
we're trying to avoid executing the ACPI interpreter at these times, but
stating that explicitly would be best.
Yeah this bit needs a rewrite, but the “why” is to preserve a platform
interface that an OS can use.
> _DSD must not be used to describe properties that are specific to an
> operating system. For example properties with OS names in the key
> would not allowed.
>
> Submitting a binding
> ====================
>
> <Insert previous mails from Al Stone on the dsd too and dsd(a)acpica.org>
I've started collecting some of this documentation in a branch on github:
https://github.com/ahs3/dsd/tree/v-next. There's a design-principles.txt
with Rafael's suggestions and our other commentary, and I'll put a draft
of this in there, too.
I think this section should be a separate document, as well as the bits
below
on review/maintenance.
Sounds good.
> Becoming a reviewer
> ===================
>
> Anybody who is member of the dsd(a)acpica.org can be a reviewer.
>
> Becoming a maintainer
> =====================
>
> _DSD maintainership is a meritocracy. The process is:
> 1. You submit a request dsd(a)acpica.org to become maintainer
> 2. Existing maintainers take a view on teh merit of the request based
s/teh/the/
Ta’
> on the track record of the person making the request in:
> 2.1 OS verndors. Eg FreeBSD, RH, or Windows may propose a maintainer
2.1 OS vendors; e.g., FreeBSD, Red Hat or Microsoft may propose a
maintainer
> 2.2 Existing FW representation technologies: ie person is a known
I think this should be s/ie/e.g.,/ -- correct?
> ACPI contributor or Device Tree contributor or maintainer
IMHO, there needs to be a single final arbiter. Suppose there are some
number of maintainers, and they disagree on a submission. Someone will
need to make the final decision. If there is no final arbiter, there is
the risk of getting things stuck at some point, with no way to unstick
them.
Yeah this is interesting. Lets chat at the FW summit about this. Choosing
who the arbiter is, surely brings up the same question on conflict. What
if we can’t agree who that is. Especially considering that this is a
pan-OS initiative.
Cheers
Charles
> << Other stuff to eventually include >>
> ========================================
> Dsd tool stuff from Al, Rules on what properties look like from Rafael
Yup. See above.
>
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
>confidential and may also be privileged. If you are not the intended
>recipient, please notify the sender immediately and do not disclose the
>contents to any other person, use it for any purpose, or store or copy
>the information in any medium. Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>Registered in England & Wales, Company No: 2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
>9NJ, Registered in England & Wales, Company No: 2548782
>
> _______________________________________________
> DSD mailing list
> DSD(a)acpica.org
> https://lists.acpica.org/mailman/listinfo/dsd
>
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Linaro Enterprise Group
al.stone(a)linaro.org
-----------------------------------
_______________________________________________
DSD mailing list
DSD(a)acpica.org
https://lists.acpica.org/mailman/listinfo/dsd
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and
may also be privileged. If you are not the intended recipient, please notify the sender
immediately and do not disclose the contents to any other person, use it for any purpose,
or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England
& Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in
England & Wales, Company No: 2548782
1:30 a.m.
On Thu, Sep 17, 2015 at 01:34:37PM +0100, Charles Garcia-Tobin wrote:
Introduction
============
The following provides rules for the process of submitting _DSD
properties. This process must be followed by vendors wishing to see their
drivers supported by OS vendors that support ACPI.
Realistically how are OS vendors going to do that (especially those that
actively encourage device vendors and system integrators to ship things
separately to the OS)? If these are really best practices rather than
standards which will be enforced we should probably be realistic in
saying that.
There's also the situation where we want to document bindings found in
the wild which may not have been submitted for review. Obviously the
review standards aren't going to apply here, it's just going to be a
case of documenting reality no matter how unfortunate the bindings are
and adopting any good practices or ideas which can be seen.
Becoming a maintainer
=====================
I'm missing a description of what a maintainer is and/or the process by
which maintainers work together? I think this also goes to the issues
Al was raising about conflict resolution processes.
_DSD maintainership is a meritocracy. The process is:
Please don't use the term meritocracy here, it has a number of
problematic aspects and is regarded as actively toxic in some
communities due to the difficulties in assessing merit as a measurable
thing with clear and unambiguous standards. It sets off alarm bells for
people familiar with broader project governance discussions - I'd say
it's better to just describe a procedure.
1. You submit a request dsd(a)acpica.org to become maintainer
2. Existing maintainers take a view on teh merit of the request based
on the track record of the person making the request in:
2.1 OS verndors. Eg FreeBSD, RH, or Windows may propose a maintainer
2.2 Existing FW representation technologies: ie person is a known
ACPI contributor or Device Tree contributor or maintainer
Realistically the situation you describe here is that the maintainers
will add other people they trust, essentially a commit bit model.
8:41 a.m.
Hi
On 19/09/2015 16:30, "Mark Brown" <broonie(a)kernel.org> wrote:
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and
may also be privileged. If you are not the intended recipient, please notify the sender
immediately and do not disclose the contents to any other person, use it for any purpose,
or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England
& Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in
England & Wales, Company No: 2548782
On Thu, Sep 17, 2015 at 01:34:37PM +0100, Charles Garcia-Tobin wrote:
> Introduction
> ============
> The following provides rules for the process of submitting _DSD
> properties. This process must be followed by vendors wishing to see
>their
> drivers supported by OS vendors that support ACPI.
Realistically how are OS vendors going to do that (especially those that
actively encourage device vendors and system integrators to ship things
separately to the OS)? If these are really best practices rather than
standards which will be enforced we should probably be realistic in
saying that.
Mark I am not quite sure what you are trying to say. Do you want me to
change the title from ³rules" to "best practices"? Whilst there is an
element of realism vs ambition, I¹d worry about watering it down. Not sure
I get what you mean so probably best if you suggest some text and we take
it from there.
Incidentally the aim is to get reviewers in from all key OSs, and this
discussion is also happening in ASWG.
There's also the situation where we want to document bindings found in
the wild which may not have been submitted for review. Obviously the
review standards aren't going to apply here, it's just going to be a
case of documenting reality no matter how unfortunate the bindings are
and adopting any good practices or ideas which can be seen.
The idea of this tool is obviously to avoid the above as much as possible.
Sure this may happen but counter is not having this tool at all, which
would make it happen all the time. Again I am not sure how you want me to
amend the text.
> Becoming a maintainer
> =====================
I'm missing a description of what a maintainer is and/or the process by
which maintainers work together? I think this also goes to the issues
Al was raising about conflict resolution processes.
We have refine this at the FW summit at Connect. I could do with more input
> _DSD maintainership is a meritocracy. The process is:
Please don't use the term meritocracy here, it has a number of
problematic aspects and is regarded as actively toxic in some
communities due to the difficulties in assessing merit as a measurable
thing with clear and unambiguous standards. It sets off alarm bells for
people familiar with broader project governance discussions - I'd say
it's better to just describe a procedure.
Fair enough
> 1. You submit a request dsd(a)acpica.org to become maintainer
> 2. Existing maintainers take a view on teh merit of the request based
> on the track record of the person making the request in:
> 2.1 OS verndors. Eg FreeBSD, RH, or Windows may propose a maintainer
> 2.2 Existing FW representation technologies: ie person is a known
> ACPI contributor or Device Tree contributor or maintainer
Realistically the situation you describe here is that the maintainers
will add other people they trust, essentially a commit bit model.
Can¹t ascertain from what you are saying whether you think this is good or
bad :-)
That was my first thought, as I say we can chat about it at the FW summit,
or some other time during Connect.
Thanks!
Charles
2:14 a.m.
On Sun, Sep 20, 2015 at 11:41:07PM +0100, Charles Garcia-Tobin wrote:
Hi
On 19/09/2015 16:30, "Mark Brown" <broonie(a)kernel.org> wrote:
>On Thu, Sep 17, 2015 at 01:34:37PM +0100, Charles Garcia-Tobin wrote:
>> Introduction
>> ============
>> The following provides rules for the process of submitting _DSD
>> properties. This process must be followed by vendors wishing to see their
>> drivers supported by OS vendors that support ACPI.
>Realistically how are OS vendors going to do that (especially
those that
>actively encourage device vendors and system integrators to ship things
>separately to the OS)? If these are really best practices rather than
>standards which will be enforced we should probably be realistic in
>saying that.
Mark I am not quite sure what you are trying to say. Do you want me
to
change the title from ³rules" to "best practices"? Whilst there is an
element of realism vs ambition, I¹d worry about watering it down. Not sure
I get what you mean so probably best if you suggest some text and we take
it from there.
I think if the start of the document is an obviously false claim about
the impact and scope then that's going to encourage people to think of
it as meaningless and pay less attention to it, it communicates a lack
of engagement with reality. If there's realistic teeth behind it fair
enough but I'm not sure that's there.
Incidentally the aim is to get reviewers in from all key OSs, and
this
discussion is also happening in ASWG.
>There's also the situation where we want to document bindings
found in
>the wild which may not have been submitted for review. Obviously the
>review standards aren't going to apply here, it's just going to be a
>case of documenting reality no matter how unfortunate the bindings are
>and adopting any good practices or ideas which can be seen.
The idea of this tool is obviously to avoid the above as much as
possible.
Sure this may happen but counter is not having this tool at all, which
would make it happen all the time. Again I am not sure how you want me to
amend the text.
I think we should rephrase as best practices unless we've actually got
realistic buy in from all OS vendors that they're genuinely going to
enforce requirements on this (and bearing in mind that in general Linux
has no effective mechanism for doing that).
>> 1. You submit a request dsd(a)acpica.org to become maintainer
>> 2. Existing maintainers take a view on teh merit of the request based
>> on the track record of the person making the request in:
>> 2.1 OS verndors. Eg FreeBSD, RH, or Windows may propose a maintainer
>> 2.2 Existing FW representation technologies: ie person is a known
>> ACPI contributor or Device Tree contributor or maintainer
>Realistically the situation you describe here is that the
maintainers
>will add other people they trust, essentially a commit bit model.
Can¹t ascertain from what you are saying whether you think this is
good or
bad :-)
That was my first thought, as I say we can chat about it at the FW summit,
or some other time during Connect.
It's obviously not an ideal governance model but it's probably realistic
and practical for something that is essentially always going to be a
semi-closed club anyway.
10:04 p.m.
On Thu, 2015-09-17 at 13:34 +0100, Charles Garcia-Tobin wrote:
Submitting a binding
====================
<Insert previous mails from Al Stone on the dsd too and
dsd(a)acpica.org>
When designing a property set for a device, best practice is to look
for any previous mechanism which may have existed to describe that same
device.
For example, a built-in wifi chip may previously have shipped with an
external EEPROM containing calibration data, regulatory settings and
hardware addresses. DSD can allow that additional cost to be dropped,
and the same information to be provided by firmware instead.
It is obviously useful if the DSD property set contains the *same*
data, in broadly the same form. The same units should be used for
numeric values unless there's a good reason to be different, etc.
Likewise if an existing method of describing a device already used
key/value pairs in any form, such as ePAPR bindings, we'd want to see a
good *reason* for using *different* names for the same information.
By ensuring that DSD properties are analogous to existing descriptions
we can avoid needless churn, and less-tested code paths, in device
drivers.
Even with newly-written ACPI-only device drivers, it will improve the
quality of the property sets which are being devised — because the
examples will help to show future-proof ways of describing the hardware
which will allow forward- and backward-compatibility in drivers. Or in
rare cases, a *bad* previous example will still help to highlight
pitfalls and help us avoid them.
Note that the best practice is to *look*, and to have a *reason* for
being different. Not just to blindly use without thinking, of course.
Obviously, this is just restating basic engineering discipline, but it
would actually be good to have a reminder *in* the submission process.
To get to my specific proposal:
When submitting a property set, a submitter should need to *explicitly*
state whether any previous hardware description exists, and provide
reasons for any divergence. It should be part of the form, or email
template, or whatever we use for the actual process of submission.
Reviewers would obviously be looking for this *anyway*, and pushing
back if they find problems in this area — but let's make sure the
expectations are clearly set in the first place and the reviewers don't
have to go searching for themselves every time.
(Note that some consideration should also be given to compatibility in
the other direction — for example if we are thinking about adding some
additional properties to PCIe extended config space, we could think
about how a proposed property set might work when the same device
appears as a PCIe device instead of as an ACPI device. But I don't
think we'd *write* anything in the requirements about that. It might
be a bullet point on an "internal" review checklist, at most.)
--
dwmw2
9:35 p.m.
On 29/01/2016 11:04, "David Woodhouse" <dwmw2(a)infradead.org> wrote:
On Thu, 2015-09-17 at 13:34 +0100, Charles Garcia-Tobin wrote:
>
>
> Submitting a binding
> ====================
>
> <Insert previous mails from Al Stone on the dsd too and
> dsd(a)acpica.org>
When designing a property set for a device, best practice is to look
for any previous mechanism which may have existed to describe that same
device.
For example, a built-in wifi chip may previously have shipped with an
external EEPROM containing calibration data, regulatory settings and
hardware addresses. DSD can allow that additional cost to be dropped,
and the same information to be provided by firmware instead.
It is obviously useful if the DSD property set contains the *same*
data, in broadly the same form. The same units should be used for
numeric values unless there's a good reason to be different, etc.
Likewise if an existing method of describing a device already used
key/value pairs in any form, such as ePAPR bindings, we'd want to see a
good *reason* for using *different* names for the same information.
By ensuring that DSD properties are analogous to existing descriptions
we can avoid needless churn, and less-tested code paths, in device
drivers.
Even with newly-written ACPI-only device drivers, it will improve the
quality of the property sets which are being devised < because the
examples will help to show future-proof ways of describing the hardware
which will allow forward- and backward-compatibility in drivers. Or in
rare cases, a *bad* previous example will still help to highlight
pitfalls and help us avoid them.
Note that the best practice is to *look*, and to have a *reason* for
being different. Not just to blindly use without thinking, of course.
Obviously, this is just restating basic engineering discipline, but it
would actually be good to have a reminder *in* the submission process.
To get to my specific proposal:
When submitting a property set, a submitter should need to *explicitly*
state whether any previous hardware description exists, and provide
reasons for any divergence. It should be part of the form, or email
template, or whatever we use for the actual process of submission.
Completely agree, we should take those words into the rules doc.
Cheers
Charles
Reviewers would obviously be looking for this *anyway*, and pushing
back if they find problems in this area < but let's make sure the
expectations are clearly set in the first place and the reviewers don't
have to go searching for themselves every time.
(Note that some consideration should also be given to compatibility in
the other direction < for example if we are thinking about adding some
additional properties to PCIe extended config space, we could think
about how a proposed property set might work when the same device
appears as a PCIe device instead of as an ACPI device. But I don't
think we'd *write* anything in the requirements about that. It might
be a bullet point on an "internal" review checklist, at most.)
--
dwmw2
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may
also be privileged. If you are not the intended recipient, please notify the sender
immediately and do not disclose the contents to any other person, use it for any purpose,
or store or copy the information in any medium. Thank you.
2421
days inactive
2558
days old
7 comments
5 participants
participants (5)
-
Al Stone -
Charles Garcia-Tobin -
Charles Garcia-Tobin
-
David Woodhouse -
Mark Brown