Re: svn commit: r355430 - head/sys/cam/scsi
At some point, we used to replace bad chars with spaces, but that may have
been two ata stacks ago..
Warner
On Wed, Dec 11, 2019, 9:35 AM Alan Somers wrote:
> No, and there's no possibility of connecting a Windows host to this
> particular device. We have some Oracle Solaris servers hooked up to these
> expanders, but it looks like Solaris completely ignores the offending
> element type.
> -Alan
>
> On Wed, Dec 11, 2019 at 10:19 AM Scott Long wrote:
>
>> U+FFFD doesn’t make sense for an ASCII string, but 0x3F might. Any idea
>> what Windows shows for this device?
>>
>> Scott
>>
>> > On Dec 11, 2019, at 8:42 AM, Alan Somers wrote:
>> >
>> > In this case the offending descriptor is solid 0xFF, so replacing
>> individual characters wouldn't accomplish anything. I can imagine a
>> different buggy expander that has just one or two bad characters. In that
>> case, it would make sense to replace them. But replace them with what?
>> The UTF replacement character 0xFFFD isn't an option, because the result is
>> supposed to be ASCII. There's no other obvious choice, which is why I
>> chose to replace the whole thing.
>> > -Alan
>> >
>> > On Fri, Dec 6, 2019 at 2:40 AM Steven Hartland <
>> steven.hartl...@multiplay.co.uk> wrote:
>> > If the illegal chars where removed or replaced would the result be
>> useful, if so might that be a better approach?
>> >
>> > On Fri, 6 Dec 2019 at 00:06, Alan Somers wrote:
>> > Author: asomers
>> > Date: Fri Dec 6 00:06:05 2019
>> > New Revision: 355430
>> > URL: https://svnweb.freebsd.org/changeset/base/355430
>> >
>> > Log:
>> > ses: sanitize illegal strings in SES element descriptors
>> >
>> > The SES4r3 standard requires that element descriptors may only
>> contain ASCII
>> > characters in the range 0x20 to 0x7e. Some SuperMicro expanders
>> violate
>> > that rule. This patch adds a sanity check to ses(4). Descriptors in
>> > violation will be replaced by "".
>> >
>> > This patch fixes "sesutil --libxo xml" on such systems. Previously
>> it would
>> > generate non-well-formed XML output.
>> >
>> > PR: 241929
>> > Reviewed by: allanjude
>> > MFC after:2 weeks
>> > Sponsored by: Axcient
>> >
>> > Modified:
>> > head/sys/cam/scsi/scsi_enc_ses.c
>> >
>> > Modified: head/sys/cam/scsi/scsi_enc_ses.c
>> >
>> ==
>> > --- head/sys/cam/scsi/scsi_enc_ses.cThu Dec 5 19:39:51 2019
>> (r355429)
>> > +++ head/sys/cam/scsi/scsi_enc_ses.cFri Dec 6 00:06:05 2019
>> (r355430)
>> > @@ -110,7 +110,7 @@ typedef struct ses_addl_status {
>> > typedef struct ses_element {
>> > uint8_t eip;/* eip bit is set */
>> > uint16_t descr_len; /* length of the descriptor */
>> > - char *descr;/* descriptor for this object */
>> > + const char *descr; /* descriptor for this object */
>> > struct ses_addl_status addl;/* additional status info */
>> > } ses_element_t;
>> >
>> > @@ -1977,6 +1977,35 @@ ses_publish_cache(enc_softc_t *enc, struct
>> enc_fsm_sta
>> > return (0);
>> > }
>> >
>> > +/*
>> > + * \brief Sanitize an element descriptor
>> > + *
>> > + * The SES4r3 standard, sections 3.1.2 and 6.1.10, specifies that
>> element
>> > + * descriptors may only contain ASCII characters in the range 0x20 to
>> 0x7e.
>> > + * But some vendors violate that rule. Ensure that we only expose
>> compliant
>> > + * descriptors to userland.
>> > + *
>> > + * \param desc SES element descriptor as reported by the
>> hardware
>> > + * \param len Length of desc in bytes, not necessarily
>> including
>> > + * trailing NUL. It will be modified if desc is
>> invalid.
>> > + */
>> > +static const char*
>> > +ses_sanitize_elm_desc(const char *desc, uint16_t *len)
>> > +{
>> > + const char *invalid = "";
>> > + int i;
>> > +
>> > + for (i = 0; i < *len; i++) {
>> > + if (desc[i] < 0x20 || desc[i] > 0x7e) {
>> > + *len = strlen(invalid);
>> > + return (invalid);
>> > + } else if (desc[i] == 0) {
>> > + break;
>> > + }
>> > + }
>> > + return (desc);
>> > +}
>> > +
>> > /**
>> > * \brief Parse the descriptors for each object.
>> > *
>> > @@ -2061,7 +2090,8 @@ ses_process_elm_descs(enc_softc_t *enc, struct
>> enc_fsm
>> > if (length > 0) {
>> > elmpriv = element->elm_private;
>> > elmpriv->descr_len = length;
>> > - elmpriv->descr = [offset];
>> > + elmpriv->descr =
>> ses_sanitize_elm_desc([offset],
>> > + >descr_len);
>> > }
>> >
>> > /* skip over the descriptor itself */
>>
>>
___
Re: svn commit: r355430 - head/sys/cam/scsi
No, and there's no possibility of connecting a Windows host to this
particular device. We have some Oracle Solaris servers hooked up to these
expanders, but it looks like Solaris completely ignores the offending
element type.
-Alan
On Wed, Dec 11, 2019 at 10:19 AM Scott Long wrote:
> U+FFFD doesn’t make sense for an ASCII string, but 0x3F might. Any idea
> what Windows shows for this device?
>
> Scott
>
> > On Dec 11, 2019, at 8:42 AM, Alan Somers wrote:
> >
> > In this case the offending descriptor is solid 0xFF, so replacing
> individual characters wouldn't accomplish anything. I can imagine a
> different buggy expander that has just one or two bad characters. In that
> case, it would make sense to replace them. But replace them with what?
> The UTF replacement character 0xFFFD isn't an option, because the result is
> supposed to be ASCII. There's no other obvious choice, which is why I
> chose to replace the whole thing.
> > -Alan
> >
> > On Fri, Dec 6, 2019 at 2:40 AM Steven Hartland <
> steven.hartl...@multiplay.co.uk> wrote:
> > If the illegal chars where removed or replaced would the result be
> useful, if so might that be a better approach?
> >
> > On Fri, 6 Dec 2019 at 00:06, Alan Somers wrote:
> > Author: asomers
> > Date: Fri Dec 6 00:06:05 2019
> > New Revision: 355430
> > URL: https://svnweb.freebsd.org/changeset/base/355430
> >
> > Log:
> > ses: sanitize illegal strings in SES element descriptors
> >
> > The SES4r3 standard requires that element descriptors may only contain
> ASCII
> > characters in the range 0x20 to 0x7e. Some SuperMicro expanders
> violate
> > that rule. This patch adds a sanity check to ses(4). Descriptors in
> > violation will be replaced by "".
> >
> > This patch fixes "sesutil --libxo xml" on such systems. Previously it
> would
> > generate non-well-formed XML output.
> >
> > PR: 241929
> > Reviewed by: allanjude
> > MFC after:2 weeks
> > Sponsored by: Axcient
> >
> > Modified:
> > head/sys/cam/scsi/scsi_enc_ses.c
> >
> > Modified: head/sys/cam/scsi/scsi_enc_ses.c
> >
> ==
> > --- head/sys/cam/scsi/scsi_enc_ses.cThu Dec 5 19:39:51 2019
> (r355429)
> > +++ head/sys/cam/scsi/scsi_enc_ses.cFri Dec 6 00:06:05 2019
> (r355430)
> > @@ -110,7 +110,7 @@ typedef struct ses_addl_status {
> > typedef struct ses_element {
> > uint8_t eip;/* eip bit is set */
> > uint16_t descr_len; /* length of the descriptor */
> > - char *descr;/* descriptor for this object */
> > + const char *descr; /* descriptor for this object */
> > struct ses_addl_status addl;/* additional status info */
> > } ses_element_t;
> >
> > @@ -1977,6 +1977,35 @@ ses_publish_cache(enc_softc_t *enc, struct
> enc_fsm_sta
> > return (0);
> > }
> >
> > +/*
> > + * \brief Sanitize an element descriptor
> > + *
> > + * The SES4r3 standard, sections 3.1.2 and 6.1.10, specifies that
> element
> > + * descriptors may only contain ASCII characters in the range 0x20 to
> 0x7e.
> > + * But some vendors violate that rule. Ensure that we only expose
> compliant
> > + * descriptors to userland.
> > + *
> > + * \param desc SES element descriptor as reported by the
> hardware
> > + * \param len Length of desc in bytes, not necessarily
> including
> > + * trailing NUL. It will be modified if desc is
> invalid.
> > + */
> > +static const char*
> > +ses_sanitize_elm_desc(const char *desc, uint16_t *len)
> > +{
> > + const char *invalid = "";
> > + int i;
> > +
> > + for (i = 0; i < *len; i++) {
> > + if (desc[i] < 0x20 || desc[i] > 0x7e) {
> > + *len = strlen(invalid);
> > + return (invalid);
> > + } else if (desc[i] == 0) {
> > + break;
> > + }
> > + }
> > + return (desc);
> > +}
> > +
> > /**
> > * \brief Parse the descriptors for each object.
> > *
> > @@ -2061,7 +2090,8 @@ ses_process_elm_descs(enc_softc_t *enc, struct
> enc_fsm
> > if (length > 0) {
> > elmpriv = element->elm_private;
> > elmpriv->descr_len = length;
> > - elmpriv->descr = [offset];
> > + elmpriv->descr =
> ses_sanitize_elm_desc([offset],
> > + >descr_len);
> > }
> >
> > /* skip over the descriptor itself */
>
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r355430 - head/sys/cam/scsi
U+FFFD doesn’t make sense for an ASCII string, but 0x3F might. Any idea what
Windows shows for this device?
Scott
> On Dec 11, 2019, at 8:42 AM, Alan Somers wrote:
>
> In this case the offending descriptor is solid 0xFF, so replacing individual
> characters wouldn't accomplish anything. I can imagine a different buggy
> expander that has just one or two bad characters. In that case, it would
> make sense to replace them. But replace them with what? The UTF replacement
> character 0xFFFD isn't an option, because the result is supposed to be ASCII.
> There's no other obvious choice, which is why I chose to replace the whole
> thing.
> -Alan
>
> On Fri, Dec 6, 2019 at 2:40 AM Steven Hartland
> wrote:
> If the illegal chars where removed or replaced would the result be useful, if
> so might that be a better approach?
>
> On Fri, 6 Dec 2019 at 00:06, Alan Somers wrote:
> Author: asomers
> Date: Fri Dec 6 00:06:05 2019
> New Revision: 355430
> URL: https://svnweb.freebsd.org/changeset/base/355430
>
> Log:
> ses: sanitize illegal strings in SES element descriptors
>
> The SES4r3 standard requires that element descriptors may only contain ASCII
> characters in the range 0x20 to 0x7e. Some SuperMicro expanders violate
> that rule. This patch adds a sanity check to ses(4). Descriptors in
> violation will be replaced by "".
>
> This patch fixes "sesutil --libxo xml" on such systems. Previously it would
> generate non-well-formed XML output.
>
> PR: 241929
> Reviewed by: allanjude
> MFC after:2 weeks
> Sponsored by: Axcient
>
> Modified:
> head/sys/cam/scsi/scsi_enc_ses.c
>
> Modified: head/sys/cam/scsi/scsi_enc_ses.c
> ==
> --- head/sys/cam/scsi/scsi_enc_ses.cThu Dec 5 19:39:51 2019
> (r355429)
> +++ head/sys/cam/scsi/scsi_enc_ses.cFri Dec 6 00:06:05 2019
> (r355430)
> @@ -110,7 +110,7 @@ typedef struct ses_addl_status {
> typedef struct ses_element {
> uint8_t eip;/* eip bit is set */
> uint16_t descr_len; /* length of the descriptor */
> - char *descr;/* descriptor for this object */
> + const char *descr; /* descriptor for this object */
> struct ses_addl_status addl;/* additional status info */
> } ses_element_t;
>
> @@ -1977,6 +1977,35 @@ ses_publish_cache(enc_softc_t *enc, struct enc_fsm_sta
> return (0);
> }
>
> +/*
> + * \brief Sanitize an element descriptor
> + *
> + * The SES4r3 standard, sections 3.1.2 and 6.1.10, specifies that element
> + * descriptors may only contain ASCII characters in the range 0x20 to 0x7e.
> + * But some vendors violate that rule. Ensure that we only expose compliant
> + * descriptors to userland.
> + *
> + * \param desc SES element descriptor as reported by the hardware
> + * \param len Length of desc in bytes, not necessarily including
> + * trailing NUL. It will be modified if desc is invalid.
> + */
> +static const char*
> +ses_sanitize_elm_desc(const char *desc, uint16_t *len)
> +{
> + const char *invalid = "";
> + int i;
> +
> + for (i = 0; i < *len; i++) {
> + if (desc[i] < 0x20 || desc[i] > 0x7e) {
> + *len = strlen(invalid);
> + return (invalid);
> + } else if (desc[i] == 0) {
> + break;
> + }
> + }
> + return (desc);
> +}
> +
> /**
> * \brief Parse the descriptors for each object.
> *
> @@ -2061,7 +2090,8 @@ ses_process_elm_descs(enc_softc_t *enc, struct enc_fsm
> if (length > 0) {
> elmpriv = element->elm_private;
> elmpriv->descr_len = length;
> - elmpriv->descr = [offset];
> + elmpriv->descr = ses_sanitize_elm_desc([offset],
> + >descr_len);
> }
>
> /* skip over the descriptor itself */
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r355430 - head/sys/cam/scsi
In this case the offending descriptor is solid 0xFF, so replacing
individual characters wouldn't accomplish anything. I can imagine a
different buggy expander that has just one or two bad characters. In that
case, it would make sense to replace them. But replace them with what?
The UTF replacement character 0xFFFD isn't an option, because the result is
supposed to be ASCII. There's no other obvious choice, which is why I
chose to replace the whole thing.
-Alan
On Fri, Dec 6, 2019 at 2:40 AM Steven Hartland <
steven.hartl...@multiplay.co.uk> wrote:
> If the illegal chars where removed or replaced would the result be useful,
> if so might that be a better approach?
>
> On Fri, 6 Dec 2019 at 00:06, Alan Somers wrote:
>
>> Author: asomers
>> Date: Fri Dec 6 00:06:05 2019
>> New Revision: 355430
>> URL: https://svnweb.freebsd.org/changeset/base/355430
>>
>> Log:
>> ses: sanitize illegal strings in SES element descriptors
>>
>> The SES4r3 standard requires that element descriptors may only contain
>> ASCII
>> characters in the range 0x20 to 0x7e. Some SuperMicro expanders violate
>> that rule. This patch adds a sanity check to ses(4). Descriptors in
>> violation will be replaced by "".
>>
>> This patch fixes "sesutil --libxo xml" on such systems. Previously it
>> would
>> generate non-well-formed XML output.
>>
>> PR: 241929
>> Reviewed by: allanjude
>> MFC after:2 weeks
>> Sponsored by: Axcient
>>
>> Modified:
>> head/sys/cam/scsi/scsi_enc_ses.c
>>
>> Modified: head/sys/cam/scsi/scsi_enc_ses.c
>>
>> ==
>> --- head/sys/cam/scsi/scsi_enc_ses.cThu Dec 5 19:39:51 2019
>> (r355429)
>> +++ head/sys/cam/scsi/scsi_enc_ses.cFri Dec 6 00:06:05 2019
>> (r355430)
>> @@ -110,7 +110,7 @@ typedef struct ses_addl_status {
>> typedef struct ses_element {
>> uint8_t eip;/* eip bit is set */
>> uint16_t descr_len; /* length of the descriptor */
>> - char *descr;/* descriptor for this object */
>> + const char *descr; /* descriptor for this object */
>> struct ses_addl_status addl;/* additional status info */
>> } ses_element_t;
>>
>> @@ -1977,6 +1977,35 @@ ses_publish_cache(enc_softc_t *enc, struct
>> enc_fsm_sta
>> return (0);
>> }
>>
>> +/*
>> + * \brief Sanitize an element descriptor
>> + *
>> + * The SES4r3 standard, sections 3.1.2 and 6.1.10, specifies that element
>> + * descriptors may only contain ASCII characters in the range 0x20 to
>> 0x7e.
>> + * But some vendors violate that rule. Ensure that we only expose
>> compliant
>> + * descriptors to userland.
>> + *
>> + * \param desc SES element descriptor as reported by the hardware
>> + * \param len Length of desc in bytes, not necessarily including
>> + * trailing NUL. It will be modified if desc is
>> invalid.
>> + */
>> +static const char*
>> +ses_sanitize_elm_desc(const char *desc, uint16_t *len)
>> +{
>> + const char *invalid = "";
>> + int i;
>> +
>> + for (i = 0; i < *len; i++) {
>> + if (desc[i] < 0x20 || desc[i] > 0x7e) {
>> + *len = strlen(invalid);
>> + return (invalid);
>> + } else if (desc[i] == 0) {
>> + break;
>> + }
>> + }
>> + return (desc);
>> +}
>> +
>> /**
>> * \brief Parse the descriptors for each object.
>> *
>> @@ -2061,7 +2090,8 @@ ses_process_elm_descs(enc_softc_t *enc, struct
>> enc_fsm
>> if (length > 0) {
>> elmpriv = element->elm_private;
>> elmpriv->descr_len = length;
>> - elmpriv->descr = [offset];
>> + elmpriv->descr =
>> ses_sanitize_elm_desc([offset],
>> + >descr_len);
>> }
>>
>> /* skip over the descriptor itself */
>>
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r355430 - head/sys/cam/scsi
If the illegal chars where removed or replaced would the result be useful,
if so might that be a better approach?
On Fri, 6 Dec 2019 at 00:06, Alan Somers wrote:
> Author: asomers
> Date: Fri Dec 6 00:06:05 2019
> New Revision: 355430
> URL: https://svnweb.freebsd.org/changeset/base/355430
>
> Log:
> ses: sanitize illegal strings in SES element descriptors
>
> The SES4r3 standard requires that element descriptors may only contain
> ASCII
> characters in the range 0x20 to 0x7e. Some SuperMicro expanders violate
> that rule. This patch adds a sanity check to ses(4). Descriptors in
> violation will be replaced by "".
>
> This patch fixes "sesutil --libxo xml" on such systems. Previously it
> would
> generate non-well-formed XML output.
>
> PR: 241929
> Reviewed by: allanjude
> MFC after:2 weeks
> Sponsored by: Axcient
>
> Modified:
> head/sys/cam/scsi/scsi_enc_ses.c
>
> Modified: head/sys/cam/scsi/scsi_enc_ses.c
>
> ==
> --- head/sys/cam/scsi/scsi_enc_ses.cThu Dec 5 19:39:51 2019
> (r355429)
> +++ head/sys/cam/scsi/scsi_enc_ses.cFri Dec 6 00:06:05 2019
> (r355430)
> @@ -110,7 +110,7 @@ typedef struct ses_addl_status {
> typedef struct ses_element {
> uint8_t eip;/* eip bit is set */
> uint16_t descr_len; /* length of the descriptor */
> - char *descr;/* descriptor for this object */
> + const char *descr; /* descriptor for this object */
> struct ses_addl_status addl;/* additional status info */
> } ses_element_t;
>
> @@ -1977,6 +1977,35 @@ ses_publish_cache(enc_softc_t *enc, struct
> enc_fsm_sta
> return (0);
> }
>
> +/*
> + * \brief Sanitize an element descriptor
> + *
> + * The SES4r3 standard, sections 3.1.2 and 6.1.10, specifies that element
> + * descriptors may only contain ASCII characters in the range 0x20 to
> 0x7e.
> + * But some vendors violate that rule. Ensure that we only expose
> compliant
> + * descriptors to userland.
> + *
> + * \param desc SES element descriptor as reported by the hardware
> + * \param len Length of desc in bytes, not necessarily including
> + * trailing NUL. It will be modified if desc is
> invalid.
> + */
> +static const char*
> +ses_sanitize_elm_desc(const char *desc, uint16_t *len)
> +{
> + const char *invalid = "";
> + int i;
> +
> + for (i = 0; i < *len; i++) {
> + if (desc[i] < 0x20 || desc[i] > 0x7e) {
> + *len = strlen(invalid);
> + return (invalid);
> + } else if (desc[i] == 0) {
> + break;
> + }
> + }
> + return (desc);
> +}
> +
> /**
> * \brief Parse the descriptors for each object.
> *
> @@ -2061,7 +2090,8 @@ ses_process_elm_descs(enc_softc_t *enc, struct
> enc_fsm
> if (length > 0) {
> elmpriv = element->elm_private;
> elmpriv->descr_len = length;
> - elmpriv->descr = [offset];
> + elmpriv->descr =
> ses_sanitize_elm_desc([offset],
> + >descr_len);
> }
>
> /* skip over the descriptor itself */
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r355430 - head/sys/cam/scsi
Author: asomers
Date: Fri Dec 6 00:06:05 2019
New Revision: 355430
URL: https://svnweb.freebsd.org/changeset/base/355430
Log:
ses: sanitize illegal strings in SES element descriptors
The SES4r3 standard requires that element descriptors may only contain ASCII
characters in the range 0x20 to 0x7e. Some SuperMicro expanders violate
that rule. This patch adds a sanity check to ses(4). Descriptors in
violation will be replaced by "".
This patch fixes "sesutil --libxo xml" on such systems. Previously it would
generate non-well-formed XML output.
PR: 241929
Reviewed by: allanjude
MFC after:2 weeks
Sponsored by: Axcient
Modified:
head/sys/cam/scsi/scsi_enc_ses.c
Modified: head/sys/cam/scsi/scsi_enc_ses.c
==
--- head/sys/cam/scsi/scsi_enc_ses.cThu Dec 5 19:39:51 2019
(r355429)
+++ head/sys/cam/scsi/scsi_enc_ses.cFri Dec 6 00:06:05 2019
(r355430)
@@ -110,7 +110,7 @@ typedef struct ses_addl_status {
typedef struct ses_element {
uint8_t eip;/* eip bit is set */
uint16_t descr_len; /* length of the descriptor */
- char *descr;/* descriptor for this object */
+ const char *descr; /* descriptor for this object */
struct ses_addl_status addl;/* additional status info */
} ses_element_t;
@@ -1977,6 +1977,35 @@ ses_publish_cache(enc_softc_t *enc, struct enc_fsm_sta
return (0);
}
+/*
+ * \brief Sanitize an element descriptor
+ *
+ * The SES4r3 standard, sections 3.1.2 and 6.1.10, specifies that element
+ * descriptors may only contain ASCII characters in the range 0x20 to 0x7e.
+ * But some vendors violate that rule. Ensure that we only expose compliant
+ * descriptors to userland.
+ *
+ * \param desc SES element descriptor as reported by the hardware
+ * \param len Length of desc in bytes, not necessarily including
+ * trailing NUL. It will be modified if desc is invalid.
+ */
+static const char*
+ses_sanitize_elm_desc(const char *desc, uint16_t *len)
+{
+ const char *invalid = "";
+ int i;
+
+ for (i = 0; i < *len; i++) {
+ if (desc[i] < 0x20 || desc[i] > 0x7e) {
+ *len = strlen(invalid);
+ return (invalid);
+ } else if (desc[i] == 0) {
+ break;
+ }
+ }
+ return (desc);
+}
+
/**
* \brief Parse the descriptors for each object.
*
@@ -2061,7 +2090,8 @@ ses_process_elm_descs(enc_softc_t *enc, struct enc_fsm
if (length > 0) {
elmpriv = element->elm_private;
elmpriv->descr_len = length;
- elmpriv->descr = [offset];
+ elmpriv->descr = ses_sanitize_elm_desc([offset],
+ >descr_len);
}
/* skip over the descriptor itself */
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
