svn commit: r368056 - in head: .github/workflows tools/build

2020-11-26 Thread Ulrich Spörlein
Author: uqs
Date: Thu Nov 26 14:42:16 2020
New Revision: 368056
URL: https://svnweb.freebsd.org/changeset/base/368056

Log:
  GH Actions: Use pre-installed clang packages
  
  Also fix the run by setting up the environment in non-deprecated way.
  
  Always run with --debug to understand better what sort of stuff is happening 
in
  the background. Also split out the bmake bootstrap stage (takes about 31s on
  ubuntu, but 1m14 on macOS?)
  
  Drops the dependency on coreutils (realpath, nproc) and thus (?) fixes macOS 
to
  be just as fast (4 logical cores vs 2 physical cores before, go figure.)
  
  Reviewed by:  arichardson

Modified:
  head/.github/workflows/cross-bootstrap-tools.yml
  head/tools/build/make.py

Modified: head/.github/workflows/cross-bootstrap-tools.yml
==
--- head/.github/workflows/cross-bootstrap-tools.ymlThu Nov 26 13:31:57 
2020(r368055)
+++ head/.github/workflows/cross-bootstrap-tools.ymlThu Nov 26 14:42:16 
2020(r368056)
@@ -1,4 +1,4 @@
-name: Cross-build CI
+name: Cross-build Kernel
 
 on:
   push:
@@ -8,28 +8,51 @@ on:
 
 jobs:
   build:
-name: ${{ matrix.os }}
+name: ${{ matrix.os }} (${{ matrix.compiler }})
 runs-on: ${{ matrix.os }}
 strategy:
+  fail-fast: false
   matrix:
-os: [ubuntu-18.04, ubuntu-20.04, macOS-latest]
+include:
+  # TODO: both Ubuntu and macOS have bmake packages, we should try 
them instead of bootstrapping our own copy.
+  - os: ubuntu-20.04
+compiler: clang-9
+cross-bindir: /usr/lib/llvm-9/bin
+pkgs: bmake libarchive-dev
+  - os: ubuntu-20.04
+compiler: clang-10
+cross-bindir: /usr/lib/llvm-10/bin
+pkgs: bmake libarchive-dev
+  - os: macOS-latest
+compiler: clang-11
+#cross-bindir: /usr/local/Cellar/llvm/11.0.0/bin  # script figures 
this out automatically
+pkgs: bmake libarchive llvm@11
 
 steps:
   - uses: actions/checkout@v2
-  - name: install LLVM+libarchive (Ubuntu)
+  - name: install packages (Ubuntu)
+if: runner.os == 'Linux'
 run: |
-  wget -O /tmp/llvm.sh https://apt.llvm.org/llvm.sh
-  chmod +x /tmp/llvm.sh
-  sudo /tmp/llvm.sh 11
-  sudo apt install -y libarchive-dev
-  echo "::set-env 
name=EXTRA_MAKE_ARGS::--cross-bindir=/usr/lib/llvm-11/bin"
-if: ${{ startsWith(matrix.os, 'ubuntu') }}
-  - name: install LLVM+libarchive (macOS)
-run: brew install llvm coreutils libarchive xz
-if: ${{ startsWith(matrix.os, 'macOS') }}
-  - name: create build dir
-run: rm -rf ../build && mkdir -p ../build
+  sudo apt-get update --quiet || true
+  sudo apt-get -yq --no-install-suggests --no-install-recommends 
install ${{ matrix.pkgs }}
+  - name: install packages (macOS)
+if: runner.os == 'macOS'
+run: |
+  brew update --quiet || true
+  brew install ${{ matrix.pkgs }}
+  - name: create environment
+run: |
+  echo "GITHUB_WORKSPACE = $GITHUB_WORKSPACE"
+  if [ -n "${{ matrix.cross-bindir }}" ]; then
+echo "EXTRA_BUILD_ARGS=--cross-bindir=${{ matrix.cross-bindir }}" 
>> $GITHUB_ENV
+  fi
+  mkdir -p ../build
+  echo "MAKEOBJDIRPREFIX=${PWD%/*}/build" >> $GITHUB_ENV
+  # heh, works on Linux/BSD/macOS ...
+  echo "NPROC=`getconf _NPROCESSORS_ONLN 2>/dev/null || getconf 
NPROCESSORS_ONLN 2>/dev/null || echo 1`" >> $GITHUB_ENV
+  - name: bootstrap bmake
+run: ./tools/build/make.py --debug $EXTRA_BUILD_ARGS TARGET=amd64 
TARGET_ARCH=amd64 -n
   - name: make kernel-toolchain
-run: env MAKEOBJDIRPREFIX=`realpath ../build` ./tools/build/make.py 
$EXTRA_MAKE_ARGS TARGET=amd64 TARGET_ARCH=amd64 kernel-toolchain -s -j$(nproc)
+run: ./tools/build/make.py --debug $EXTRA_BUILD_ARGS TARGET=amd64 
TARGET_ARCH=amd64 kernel-toolchain -s -j$NPROC
   - name: make buildkernel
-run: env MAKEOBJDIRPREFIX=`realpath ../build` ./tools/build/make.py 
$EXTRA_MAKE_ARGS TARGET=amd64 TARGET_ARCH=amd64 KERNCONF=GENERIC NO_MODULES=yes 
buildkernel -s -j$(nproc)
+run: ./tools/build/make.py --debug $EXTRA_BUILD_ARGS TARGET=amd64 
TARGET_ARCH=amd64 KERNCONF=GENERIC NO_MODULES=yes buildkernel -s -j$NPROC 
$EXTRA_MAKE_ARGS

Modified: head/tools/build/make.py
==
--- head/tools/build/make.pyThu Nov 26 13:31:57 2020(r368055)
+++ head/tools/build/make.pyThu Nov 26 14:42:16 2020(r368056)
@@ -115,6 +115,9 @@ def check_required_make_env_var(varname, binary_name, 
  " does not exist")
 new_env_vars[varname] = guess
 debug("Inferred", varname, "as", guess)
+global parsed_args
+if parsed_args.debug:
+  

Re: svn commit: r298585 - in head: sys/kern usr.sbin/jail

2016-04-26 Thread Ulrich Spörlein
On Apr 26, 2016 11:44 AM, "Conrad Meyer"  wrote:
>
> Right.  False positive.  Coverity doesn't grok sbuf memory management
fully.
>

If someone can explain it to me in very simple words, I can update the
model to make these go away ... maybe.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r298585 - in head: sys/kern usr.sbin/jail

2016-04-26 Thread Ulrich Spörlein
2016-04-25 10:06 GMT-07:00 Jamie Gritton :
> Author: jamie
> Date: Mon Apr 25 17:06:50 2016
> New Revision: 298585
> URL: https://svnweb.freebsd.org/changeset/base/298585
>
> Log:
>   Encapsulate SYSV IPC objects in jails.  Define per-module parameters
>   sysvmsg, sysvsem, and sysvshm, with the following bahavior:
>
>   inherit: allow full access to the IPC primitives.  This is the same as
>   the current setup with allow.sysvipc is on.  Jails and the base system
>   can see (and moduly) each other's objects, which is generally considered
>   a bad thing (though may be useful in some circumstances).
>
>   disable: all no access, same as the current setup with allow.sysvipc off.
>
>   new: A jail may see use the IPC objects that it has created.  It also
>   gets its own IPC key namespace, so different jails may have their own
>   objects using the same key value.  The parent jail (or base system) can
>   see the jail's IPC objects, but not its keys.
>
>   PR:   48471
>   Submitted by: based on work by kikucha...@gmail.com
>   MFC after:5 days
>
> Modified:
>   head/sys/kern/sysv_msg.c
>   head/sys/kern/sysv_sem.c
>   head/sys/kern/sysv_shm.c
>   head/usr.sbin/jail/jail.8

Looks like some bad sbuf_deletes, see the recent Coverity report (are
you folks getting these emails?)

*** CID 1354974:  Memory - corruptions  (BAD_FREE)
/sys/kern/sysv_shm.c: 1043 in sysctl_shmsegs()
1037shmseg->u.shm_perm.key = IPC_PRIVATE;
1038}
1039
1040sbuf_bcat(, shmseg, sizeof(*shmseg));
1041}
1042error = sbuf_finish();
>>> CID 1354974:  Memory - corruptions  (BAD_FREE)
>>> "sbuf_delete" frees address of "sb".
1043sbuf_delete();
1044
1045 done:
1046SYSVSHM_UNLOCK();
1047return (error);
1048 }

** CID 1354975:  Memory - corruptions  (BAD_FREE)

and one in sysv_msg.c
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r276071 - in head/contrib/ntp: ntpd util

2014-12-23 Thread Ulrich Spörlein
On Mon, 2014-12-22 at 18:54:56 +, Xin LI wrote:
 Author: delphij
 Date: Mon Dec 22 18:54:55 2014
 New Revision: 276071
 URL: https://svnweb.freebsd.org/changeset/base/276071
 
 Log:
   Fix multiple ntp vulnerabilities.
   
   Reviewed by:roberto (earlier revision), philip
   Security:   CVE-2014-9293, CVE-2014-9294
   Security:   CVE-2014-9295, CVE-2014-9296
   Security:   FreeBSD-SA-14:31.ntp
   
   Differential Revision: https://reviews.freebsd.org/D1343
 

Hi

the latest Coverity run (which should include these patches, I think)
still flags two DEADCODEs in ntp_proto.c:



*** CID 1260388:  Logically dead code  (DEADCODE)
/contrib/ntp/ntpd/ntp_proto.c: 702 in receive()
696 if (!(rbufp-dstadr-flags  INT_MCASTOPEN)) {
697 if (AUTH(restrict_mask  RES_DONTTRUST,
698is_authentic))
699 fast_xmit(rbufp, MODE_SERVER, skeyid,
700 restrict_mask);
701 else if (is_authentic == AUTH_ERROR)
 CID 1260388:  Logically dead code  (DEADCODE)
 Execution cannot reach this statement fast_xmit(rbufp, 4, 0U, res
702 fast_xmit(rbufp, MODE_SERVER, 0,
703 restrict_mask);
704 return; /* hooray */
705 }
706
707 /*
/contrib/ntp/ntpd/ntp_proto.c: 869 in receive()
863  * symmetric active response is sent. If authentication
864  * fails, send a crypto-NAK packet.
865  */
866 if (!AUTH(restrict_mask  RES_DONTTRUST, is_authentic))
867 {
868 if (is_authentic == AUTH_ERROR)
 CID 1260388:  Logically dead code  (DEADCODE)
 Execution cannot reach this statement fast_xmit(rbufp, 1, 0U, res
869 fast_xmit(rbufp, MODE_ACTIVE, 0,
870 restrict_mask);
871 return; /* bad auth */
872 }
873 if (!AUTH(sys_authenticate | (restrict_mask 
874 RES_NOPEER), is_authentic)) {

___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r254138 - in head: share/man/man9 sys/amd64/amd64 sys/arm/arm sys/cddl/contrib/opensolaris/uts/common/fs/zfs sys/dev/agp sys/dev/drm2/i915 sys/dev/drm2/ttm sys/dev/md sys/fs/fuse sys/f

2013-08-13 Thread Ulrich Spörlein
On Fri, 2013-08-09 at 11:11:12 +, Attilio Rao wrote:
 Author: attilio
 Date: Fri Aug  9 11:11:11 2013
 New Revision: 254138
 URL: http://svnweb.freebsd.org/changeset/base/254138
 
 Log:
   The soft and hard busy mechanism rely on the vm object lock to work.
   Unify the 2 concept into a real, minimal, sxlock where the shared
   acquisition represent the soft busy and the exclusive acquisition
   represent the hard busy.
   The old VPO_WANTED mechanism becames the hard-path for this new lock
   and it becomes per-page rather than per-object.
   The vm_object lock becames an interlock for this functionality:
   it can be held in both read or write mode.
   However, if the vm_object lock is held in read mode while acquiring
   or releasing the busy state, the thread owner cannot make any
   assumption on the busy state unless it is also busying it.
   
   Also:
   - Add a new flag to directly shared busy pages while vm_page_alloc
 and vm_page_grab are being executed.  This will be very helpful
 once these functions happen under a read object lock.
   - Move the swapping sleep into its own per-object flag
   
   The KPI is heavilly changed this is why the version is bumped.
   It is very likely that some VM ports users will need to change
   their own code.
   
   Sponsored by:   EMC / Isilon storage division
   Discussed with: alc
   Reviewed by:jeff, kib
   Tested by:  gavin, bapt (older version)
   Tested by:  pho, scottl

The changes to sys/vm/vm_fault.c introduce a call to
vm_page_sleep_if_busy() where the return code is not checked. The other
5 places in the tree check the return code, please fix this here too.
It's CID 1062398, and I would encourage folks to get an account with
scan.coverity.com and have an eye on newly found defects.

Thanks!
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r254138 - in head: share/man/man9 sys/amd64/amd64 sys/arm/arm sys/cddl/contrib/opensolaris/uts/common/fs/zfs sys/dev/agp sys/dev/drm2/i915 sys/dev/drm2/ttm sys/dev/md sys/fs/fuse sys/f

2013-08-13 Thread Ulrich Spörlein
2013/8/13 Attilio Rao atti...@freebsd.org:
 On Tue, Aug 13, 2013 at 4:22 PM, Ulrich Spörlein u...@freebsd.org wrote:
 On Fri, 2013-08-09 at 11:11:12 +, Attilio Rao wrote:
 Author: attilio
 Date: Fri Aug  9 11:11:11 2013
 New Revision: 254138
 URL: http://svnweb.freebsd.org/changeset/base/254138

 Log:
   The soft and hard busy mechanism rely on the vm object lock to work.
   Unify the 2 concept into a real, minimal, sxlock where the shared
   acquisition represent the soft busy and the exclusive acquisition
   represent the hard busy.
   The old VPO_WANTED mechanism becames the hard-path for this new lock
   and it becomes per-page rather than per-object.
   The vm_object lock becames an interlock for this functionality:
   it can be held in both read or write mode.
   However, if the vm_object lock is held in read mode while acquiring
   or releasing the busy state, the thread owner cannot make any
   assumption on the busy state unless it is also busying it.

   Also:
   - Add a new flag to directly shared busy pages while vm_page_alloc
 and vm_page_grab are being executed.  This will be very helpful
 once these functions happen under a read object lock.
   - Move the swapping sleep into its own per-object flag

   The KPI is heavilly changed this is why the version is bumped.
   It is very likely that some VM ports users will need to change
   their own code.

   Sponsored by:   EMC / Isilon storage division
   Discussed with: alc
   Reviewed by:jeff, kib
   Tested by:  gavin, bapt (older version)
   Tested by:  pho, scottl

 The changes to sys/vm/vm_fault.c introduce a call to
 vm_page_sleep_if_busy() where the return code is not checked. The other
 5 places in the tree check the return code, please fix this here too.
 It's CID 1062398, and I would encourage folks to get an account with
 scan.coverity.com and have an eye on newly found defects.

 Not true.
 The same call existed also before with exactly the same semantic.
 The trick there is that it is not important to check for the return
 value because we are going to retry the operation anyway.
 The code looks ok to me.

Thanks for the explanation. The code shuffling meant that Coverity saw
it as new code, that's what prompted me to email you.

Cheers,
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r253680 - in head: lib/libfetch usr.bin/fetch

2013-08-08 Thread Ulrich Spörlein
On Fri, 2013-07-26 at 15:53:43 +, Dag-Erling SmÞrgrav wrote:
 Modified: head/lib/libfetch/common.c
 ==
 --- head/lib/libfetch/common.cFri Jul 26 14:43:38 2013
 (r253679)
 +++ head/lib/libfetch/common.cFri Jul 26 15:53:43 2013
 (r253680)
 +static struct addrinfo *
 +fetch_ssl_get_numeric_addrinfo(const char *hostname, size_t len)
 +{
 + struct addrinfo hints, *res;
 + char *host;
 +
 + host = (char *)malloc(len + 1);
 + memcpy(host, hostname, len);
 + host[len] = '\0';
 + memset(hints, 0, sizeof(hints));
 + hints.ai_family = PF_UNSPEC;
 + hints.ai_socktype = SOCK_STREAM;
 + hints.ai_protocol = 0;
 + hints.ai_flags = AI_NUMERICHOST;
 + /* port is not relevant for this purpose */
 + getaddrinfo(host, 443, hints, res);

We check the return value for getaddrinfo() 210 out of 217 times in our
tree, please check it here too. Thanks! CID 1061016

 +static int
 +fetch_ssl_setup_peer_verification(SSL_CTX *ctx, int verbose)
 +{
 + X509_LOOKUP *crl_lookup;
 + X509_STORE *crl_store;
 + const char *ca_cert_file, *ca_cert_path, *crl_file;
 +
 + if (getenv(SSL_NO_VERIFY_PEER) == NULL) {
 + ca_cert_file = getenv(SSL_CA_CERT_FILE) != NULL ?
 + getenv(SSL_CA_CERT_FILE) : /etc/ssl/cert.pem;
 + ca_cert_path = getenv(SSL_CA_CERT_PATH);
 + if (verbose) {
 + fetch_info(Peer verification enabled);
 + if (ca_cert_file != NULL)
 + fetch_info(Using CA cert file: %s,
 + ca_cert_file);
 + if (ca_cert_path != NULL)
 + fetch_info(Using CA cert path: %s,
 + ca_cert_path);
 + }
 + SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER,
 + fetch_ssl_cb_verify_crt);

The return value is unchecked here. Coverity claims we check it 4 out of
5 times in our tree, please fix this one too. CID 1061015


Cheers,
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r253719 - in head: sys/conf sys/dev/watchdog sys/libkern sys/sys usr.sbin/watchdogd

2013-07-30 Thread Ulrich Spörlein
On Sat, 2013-07-27 at 20:47:02 +, Alfred Perlstein wrote:
 Author: alfred
 Date: Sat Jul 27 20:47:01 2013
 New Revision: 253719
 URL: http://svnweb.freebsd.org/changeset/base/253719
 
 Log:
   Fix watchdog pretimeout.

Alfred,

this broken the build and hasn't been fixed for almost three days now.
What's up with that? How was this change tested before commit?

=== usr.sbin/watchdogd (all)
cc  -O2 -pipe  -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers 
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings 
-Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline 
-Wnested-externs -Wredundant-decls -Wold-style-definition 
-Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body 
-Wno-string-plus-int -c /data/src/freebsd-head/usr.sbin/watchdogd/watchdogd.c
/data/src/freebsd-head/usr.sbin/watchdogd/watchdogd.c:777:18: error: comparison 
of integers of different signs: 'u_int' (aka 'unsigned int') and 'time_t' (aka 
'int') [-Werror,-Wsign-compare]
if (pretimeout = ts.tv_sec) {
~~ ^  ~
1 error generated.
*** Error code 1
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r253210 - in head/sys: conf netinet

2013-07-15 Thread Ulrich Spörlein
Hey Andre,

I don't see why this commit triggers it, but Coverity Scan found a new
resource leak in this file. syncache_expand() will leak *s when line
1071 is reached. The failed: case below correctly frees the resources.

1068/* how do we find the inp for the new socket? */
22. Condition sc != scs, taking true branch
1069if (sc != scs)
1070syncache_free(sc);

CID null (#1 of 1): Resource leak (RESOURCE_LEAK)
23. leaked_storage: Variable s going out of scope leaks the storage it points 
to.
1071return (1);
1072failed:
1073if (sc != NULL  sc != scs)
1074syncache_free(sc);
1075if (s != NULL)
1076free(s, M_TCPLOG);
1077*lsop = NULL;
1078return (0);
1079}

This has no CID yet ...

Cheers,
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r253322 - in head/sys/cam: . scsi

2013-07-15 Thread Ulrich Spörlein
On Sat, 2013-07-13 at 13:35:10 +, Alexander Motin wrote:
 Author: mav
 Date: Sat Jul 13 13:35:09 2013
 New Revision: 253322
 URL: http://svnweb.freebsd.org/changeset/base/253322
 
 Log:
   Improve handling of 0x3F/0x0E Reported LUNs data has changed and 0x25/0x00
   Logical unit not supported errors.  First initiates specific target 
 rescan,
   second -- destroys specific LUN.  That allows to automatically detect 
 changes
   in list of device LUNs.  This mechanism doesn't work when target is 
 completely
   idle, but probably that is all what can be done without active polling.
   
   Reviewed by:ken
   Sponsored by:   iXsystems, Inc.
 
 Modified:
   head/sys/cam/cam_periph.c
   head/sys/cam/scsi/scsi_all.c
   head/sys/cam/scsi/scsi_all.h
 
 Modified: head/sys/cam/cam_periph.c
 ==
 @@ -1761,12 +1759,25 @@ cam_periph_error(union ccb *ccb, cam_fla
   xpt_async(AC_LOST_DEVICE, newpath, NULL);
   xpt_free_path(newpath);
   }
 + }
  
   /* Broadcast UNIT ATTENTIONs to all periphs. */
 - } else if (scsi_extract_sense_ccb(ccb,
 - error_code, sense_key, asc, ascq) 
 - sense_key == SSD_KEY_UNIT_ATTENTION) {
 + if ((action  SSQ_UA) != 0)
   xpt_async(AC_UNIT_ATTENTION, orig_ccb-ccb_h.path, orig_ccb);
 +
 + /* Rescan target on Reported LUNs data has changed */
 + if ((action  SSQ_RESCAN) != 0) {
 + if (xpt_create_path(newpath, NULL,
 + xpt_path_path_id(ccb-ccb_h.path),
 + xpt_path_target_id(ccb-ccb_h.path),
 + -1) == CAM_REQ_CMP) {
 +
 + scan_ccb = xpt_alloc_ccb_nowait();
 + scan_ccb-ccb_h.path = newpath;
 + scan_ccb-ccb_h.func_CODe = XPT_SCAN_BUS;
 + scan_ccb-crcn.flags = 0;
 + xpt_rescan(scan_ccb);
 + }
   }
  
   /* Attempt a retry */
 

This introduces a possible NULL dereference. xpt_alloc_ccb_nowait() may
return NULL. Coverity reports that this is checked for NULL returns 31
out of 36 times. Please grep over the tree and fix this plus the other 4
locations where this is not being null-checked. Thanks!

This has no CID yet (they run a background check that merges and
assigns CIDs, and this is a fresh run ...)
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r253274 - head/sys/cam/scsi

2013-07-15 Thread Ulrich Spörlein
On Fri, 2013-07-12 at 17:09:50 +, Kenneth D. Merry wrote:
 Author: ken
 Date: Fri Jul 12 17:09:50 2013
 New Revision: 253274
 URL: http://svnweb.freebsd.org/changeset/base/253274
 
 Log:
   Fix a problem with READ ELEMENT STATUS that occurs on some
   changers that don't support the DVCID and CURDATA bits that were
   introduced in the SMC spec.
   
   These changers will return an Illegal Request type error if the
   bits are set.  This causes chio status to fail.
   
   The fix is two-fold.  First, for changers that claim to be SCSI-2
   or older, don't set the DVCID and CURDATA bits for READ ELEMENT
   STATUS.  For newer changers (SCSI-3 and newer), we default to
   setting the new bits, but back off and try the READ ELEMENT STATUS
   without the bits if we get an Illegal Request type error.
   
   This has been tested on a Qualstar TLS-8211, which is a SCSI-2
   changer that does not support the new bits, and a Spectra T-380,
   which is a SCSI-3 changer that does support the new bits.  In the
   absence of a SCSI-3 changer that does not support the bits, I
   tested that with some error injection code.  (The SMC spec says
   that support for CURDATA is mandatory, and DVCID is optional.)
   
   scsi_ch.c:  Add a new quirk, CH_Q_NO_DVCID that gets set for
   SCSI-2 and older libraries, or newer libraries that
   report errors when the DVCID/CURDATA bits are set.
   
   In chgetelemstatus(), use the new quirk to
   determine whether or not to set DVCID and CURDATA.
   If we get an error with the bits set, back off and
   try without the bits.  Set the quirk flag if the
   read element status succeeds without the bits set.
   
   Increase the READ ELEMENT STATUS timeout to 60
   seconds after testing with a Spectra T-380.  The
   previous value was 10 seconds, and too short for
   the T-380.  This may be decreased later after
   some additional testing and investigation.
   
   Tested by:  Andre Albsmeier andre.albsme...@siemens.com
   Sponsored by:   Spectra Logic
   MFC after:  3 days
 
 Modified:
   head/sys/cam/scsi/scsi_ch.c
 
 Modified: head/sys/cam/scsi/scsi_ch.c
 ==
 --- head/sys/cam/scsi/scsi_ch.c   Fri Jul 12 16:41:58 2013
 (r253273)
 +++ head/sys/cam/scsi/scsi_ch.c   Fri Jul 12 17:09:50 2013
 (r253274)
 @@ -1284,8 +1342,8 @@ chgetelemstatus(struct cam_periph *perip
/* voltag */ want_voltags,
/* sea */ softc-sc_firsts[chet]
+ cesr-cesr_element_base,
 -  /* dvcid */ 1,
 -  /* curdata */ 1,
 +  /* dvcid */ dvcid,
 +  /* curdata */ curdata,
/* count */ cesr-cesr_element_count,
/* data_ptr */ data,
/* dxfer_len */ size,

Are you sure? Coverity flags this as being in the wrong argument order
(there's no CID for this yet).

CID null (#2 of 2): Arguments in wrong order (SWAPPED_ARGUMENTS)
swapped_arguments: The positions of arguments curdata and dvcid are 
inconsistent with the positions of the corresponding parameters for 
scsi_read_element_status(struct ccb_scsiio *, u_int32_t, void (*)(struct 
cam_periph *, union ccb *), u_int8_t, int, u_int32_t, int, int, u_int32_t, 
u_int8_t *, u_int32_t, u_int8_t, u_int32_t). [show details]
1338scsi_read_element_status(ccb-csio,
1339 /* retries */ 1,
1340 /* cbfcnp */ chdone,
1341 /* tag_action */ MSG_SIMPLE_Q_TAG,
1342 /* voltag */ want_voltags,
1343 /* sea */ softc-sc_firsts[chet]
1344 + cesr-cesr_element_base,
1345 /* dvcid */ dvcid,
1346 /* curdata */ curdata,
1347 /* count */ cesr-cesr_element_count,
1348 /* data_ptr */ data,
1349 /* dxfer_len */ size,
1350 /* sense_len */ SSD_FULL_SIZE,
1351 /* timeout */ 
CH_TIMEOUT_READ_ELEMENT_STATUS);

And this is the definition:

1860void
1861scsi_read_element_status(struct ccb_scsiio *csio, u_int32_t retries,
1862 void (*cbfcnp)(struct cam_periph *, union ccb *),
1863 u_int8_t tag_action, int voltag, u_int32_t sea,
1864 int curdata, int dvcid,
1865 u_int32_t count, u_int8_t *data_ptr,
1866 u_int32_t dxfer_len, u_int8_t sense_len,
1867 

Re: svn commit: r253274 - head/sys/cam/scsi

2013-07-15 Thread Ulrich Spörlein
2013/7/15 Kenneth D. Merry k...@freebsd.org:
 Oops, you're right!  Thanks for pointing it out!  I just committed a fix.

 How does Coverity detect something like that?  Using the comment, or the
 variable name?

I would guess the variable name, maybe with a fuzzy match. At least
that's how I would do it, I don't know the internal workings of their
software and I'm sure they won't tell anyone :)

Cheers,
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r252408 - head/sbin/ifconfig

2013-07-03 Thread Ulrich Spörlein
On Sun, 2013-06-30 at 07:37:32 +, Hiroki Sato wrote:
 Author: hrs
 Date: Sun Jun 30 07:37:31 2013
 New Revision: 252408
 URL: http://svnweb.freebsd.org/changeset/base/252408
 
 Log:
   Do not display a warning message in a jail without AF_INET6 support.
   
   MFC after:  3 days
 
 Modified:
   head/sbin/ifconfig/af_nd6.c
 
 Modified: head/sbin/ifconfig/af_nd6.c
 ==
 --- head/sbin/ifconfig/af_nd6.c   Sun Jun 30 06:44:31 2013
 (r252407)
 +++ head/sbin/ifconfig/af_nd6.c   Sun Jun 30 07:37:31 2013
 (r252408)
 @@ -148,7 +148,7 @@ nd6_status(int s)
   memset(nd, 0, sizeof(nd));
   strncpy(nd.ifname, ifr.ifr_name, sizeof(nd.ifname));
   if ((s6 = socket(AF_INET6, SOCK_DGRAM, 0))  0) {
 - if (errno != EAFNOSUPPORT)
 + if (errno != EAFNOSUPPORT  error != EPROTONOSUPPORT)
   warn(socket(AF_INET6, SOCK_DGRAM));
   return;
   }

This gives undefined behavior, error is uninitialized at this point.

Found by: Coverity Scan, CID 1042128

Cheers,
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r252356 - in head: contrib/smbfs/mount_smbfs etc/defaults etc/mtree include lib lib/libprocstat rescue/rescue sbin/mount share/examples share/examples/etc share/mk sys/conf sys/kern sy

2013-07-03 Thread Ulrich Spörlein
On Fri, 2013-06-28 at 21:00:08 +, Davide Italiano wrote:
 Author: davide
 Date: Fri Jun 28 21:00:08 2013
 New Revision: 252356
 URL: http://svnweb.freebsd.org/changeset/base/252356
 
 Log:
   - Trim an unused and bogus Makefile for mount_smbfs.
   - Reconnect with some minor modifications, in particular now selsocket()
   internals are adapted to use sbintime units after recent'ish calloutng
   switch.

yay, for reconnecting this to the build. Now Coverity Scan is seeing
this code and there are dozens of double frees in the form:

smb_rq_done(rqp);
free(rqp, M_SMBFSDATA);

But smb_rq_done() is already calling free(rqp). This seems easy to audit
and fix.
(sometimes the order is swapped, so it's a USE_AFTER_FREE instead)

This is CIDs 1042109 -- 1042126, all in smbfs_smb.c.

Thanks for looking into this
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r247960 - head/cddl/contrib/opensolaris/tools/ctf/cvt

2013-04-19 Thread Ulrich Spörlein
On Thu, 2013-03-07 at 20:45:20 -0500, Eitan Adler wrote:
 On 7 March 2013 18:00, Dimitry Andric d...@freebsd.org wrote:
  On 2013-03-07 23:29, Andriy Gapon wrote:
  ...
 
  I was not really kidding when I said that this change, as is, is a nop:
 
  ...
 
  +   bname = strrchr(match.iim_name, '/');
  +   bname = bname == NULL ? match.iim_name : bname +
  1;
 
 
  It would probably make sense to make use of bname after going to through
  all the
  trouble of calculating it:
 
  match.iim_file = match.iim_name;
 
 
  Should be match.iim_file = bname ?
 
 
  Yes, I actually had this in my test code, and committed the wrong diff
  by accident. :(  Fixed in r247962, in any case.
 
 
 
  Surprised that clang hasn't warned you about this one :-)
 
 
  Clang currently does not have the -Wunused-but-set-variable warning; it
  is apparently available in the static analyzer.  On the other hand, that
  warning is one of the most annoying ones that newer gcc's have. :-)
 
 I have found real bugs in FreeBSD's code base as a result of this
 warning, but the vast majority were more annoying than useful.
 

That's why I've disabled them on
http://scan.freebsd.your.org/freebsd-head/

:)
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r246362 - head/games/fortune/datfiles

2013-02-18 Thread Ulrich Spörlein
On Wed, 2013-02-06 at 08:42:01 +0100, Joel Dahl wrote:
 On 06-02-2013 11:18, Gleb Smirnoff wrote:
  On Tue, Feb 05, 2013 at 04:17:25PM -0500, John Baldwin wrote:
  J On Tuesday, February 05, 2013 3:55:47 pm Gleb Smirnoff wrote:
  J  On Tue, Feb 05, 2013 at 11:58:54AM -0500, John Baldwin wrote:
  J  J   On Tuesday, February 05, 2013 9:39:38 am Dag-Erling SmXXrgrav 
  wrote:
  J  JAuthor: des
  J  JDate: Tue Feb  5 14:39:37 2013
  J  JNew Revision: 246362
  J  JURL: http://svnweb.freebsd.org/changeset/base/246362
  J  J   
  J  JLog:
  J  J  Remove political propaganda
  J  J   
  J  JModified:
  J  J  head/games/fortune/datfiles/fortunes-o.real
  J  J  
  J  J   *sigh*
  J  J  
  J  J   I'm sure there are other quotes that people who do not share 
  your political
  J  J   persuasion might find propaganda or offensive, etc.  Censorship 
  and freedom
  J  J   of speech is quite a sticky widget, and I think the only truly 
  sane policy
  J  J   is that fortune files are append-only (unless we outright 
  remove them and
  J  J   that seems excessive).  And new things should have a very high 
  bar to be
  J  J   added to fortune.  Perhaps we should move fortunes-o to ports 
  entirely?
  J  J  
  J  J  
  J  J  I am more concerned about the insta-MFC than the removal per se.
  J  J  Only security or legal issues are cause to go under 3 days, was my
  J  J  impression.
  J  J 
  J  J Yes, the insta-MFC is also not appropriate, esp. for something that 
  you know
  J  J is going to raise eyebrows when it is committed.  Having to debate 
  this sort
  J  J of thing in public on mailing lists is also distinctly unhelpful 
  and very
  J  J distracting from productive work.  Also, I'd like to preemptively 
  ask
  J  J developers to refrain from any further commits to the fortunes 
  datfiles for
  J  J the time being as the last thing we need is a commit war over this 
  sort of
  J  J thing.
  J  
  J  What about just moving the entire games subdirectory to ports repo?
  J 
  J We've already moved most of it many years ago.
  
  The yesterday bikeshed proves that most isn't enough. :( The entire games 
  subdir
  needs to be moved.
 
 +1
 
 This is a worthless discussion that seems to pop up from time to time. Move it
 to ports.

No. There are people that use morse(6) in production code and stuff like
random(6) can also be very useful. This is *BSD legacy and if it was for
me, the whole games stuff would be brought *back* into the tree from
ports.

So can we move on to something else now and let this one die?

kthxbai
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r245700 - head/usr.sbin/bsdinstall/partedit

2013-01-23 Thread Ulrich Spörlein
On Sun, 2013-01-20 at 22:25:59 +, Nathan Whitehorn wrote:
 Author: nwhitehorn
 Date: Sun Jan 20 22:25:58 2013
 New Revision: 245700
 URL: http://svnweb.freebsd.org/changeset/base/245700
 
 Log:
   Add a simple scripted partitioner. Documentation and more scripting support
   will come soon. This lets the install process have a line like:
   
   bsdinstall scriptedpart 'ada0 GPT {1.5G freebsd-ufs /, 10G freebsd-swap,
   auto freebsd-ufs /usr}'
   
   to set up a system with a 1.5GB /, some swap space, and a /usr using the
   rest of ada0.

What will be the alignment/offset for these? (and also for the fully
automated case?)

We should make sure the first partition starts at 1MB all the time,
unless the user points the gun at his feet ...

Thanks
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r242767 - in head/tools/regression/bin/sh: builtins parser

2012-11-18 Thread Ulrich Spörlein
On Thu, 2012-11-08 at 13:36:19 +, Jilles Tjoelker wrote:
 Author: jilles
 Date: Thu Nov  8 13:36:19 2012
 New Revision: 242767
 URL: http://svnweb.freebsd.org/changeset/base/242767
 
 Log:
   sh: Add tests for modifying an alias (r242766).
   
   Note: parser/alias10.0 will eat a lot of memory/cpu time when it fails (with
   the old sh).

Can't you run it with reduced ulimits to have it fail fast?

Cheers,
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r243130 - head/etc/root

2012-11-18 Thread Ulrich Spörlein
On Fri, 2012-11-16 at 04:25:35 +, Eitan Adler wrote:
 Author: eadler
 Date: Fri Nov 16 04:25:35 2012
 New Revision: 243130
 URL: http://svnweb.freebsd.org/changeset/base/243130
 
 Log:
   dot.login is supposed to be for bourne shell, not csh
   
   Pointyhat to: me
   Approved by: cperciva (implicit)
 
 Modified:
   head/etc/root/dot.login
 
 Modified: head/etc/root/dot.login
 ==
 --- head/etc/root/dot.login   Fri Nov 16 03:33:34 2012(r243129)
 +++ head/etc/root/dot.login   Fri Nov 16 04:25:35 2012(r243130)
 @@ -6,4 +6,4 @@
  #
  
  # Uncomment to display a random cookie each login:
 -# if ( -x /usr/games/fortune ) /usr/games/fortune -s
 +# [ -x /usr/games/fortune ]  /usr/games/fortune -s

Please add || true to that line, so that when it is enabled and
/usr/games/fortune doesn't exist or is not executable, the shell startup
doesn't return with $? set to something non-zero.

This is especially annoying if you have $? somewhere in your prompt.

Thanks
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r241916 - in head/sys: netinet netinet6

2012-10-28 Thread Ulrich Spörlein
On Tue, 2012-10-23 at 20:43:33 +0200, Michael Tuexen wrote:
 On Oct 23, 2012, at 8:28 PM, Bruce Evans wrote:
 
  On Tue, 23 Oct 2012, Michael Tuexen wrote:
  
  On Oct 23, 2012, at 6:23 AM, Bruce Evans wrote:
  
  On Mon, 22 Oct 2012, Xin LI wrote:
  
  Log:
  Remove __P.
  
  This was a chance to remove style bugs in the prototypes.  At least it
  didn't create so many new ones, unlike the original __P axing.  It
  still enlarged about a hundred by changing from Gnu style continuation
  to Gnu style continuation indentation with an off-by-5 error.
  
  please note that the SCTP code in the FreeBSD sources is generated
  via an export script from a codebase which runs on multiple platforms.
  The script tries to follow FreeBSDs guidelines, but is far from being
  perfect.
  
  The export script might not like manual editing of its output.
  
  Portability might require __P(()), and then removing it cleaning requires
  a complicated script.
 Maybe I wasn't clear...
 
 * The removal of __P() needs also be done upstream. I'll handle this, not 
 problem.
   I don't think we need __P on any platform.
 * My comment was regarding your list of formatting issues of the code. 
 Changing
   the formatting would require changing the export script.
   If someone just changes the FreeBSD sources and these changes are not 
 included
   upstream, they are lost by the next commit of rrs@ or mine.
 
 My point was: Getting rid of __P is fine and we can handle that upstream (as
 any other non whitespace/formatting changes needed), but changing the 
 formatting
 is NOT that easy. I'm sorry about that and just wanted to let you know that
 there is a reason why the style 9 stuff is not followed exactly within the
 SCTP code.
 
 I hope this makes the situation clearer.

Maybe running it through uncrustify[1] as part of the export for FreeBSD
could help here?

hth
Uli

[1] http://uncrustify.sourceforge.net/ and textproc/uncrustify
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r232249 - head

2012-06-15 Thread Ulrich Spörlein
On Tue, 2012-02-28 at 11:06:52 +, Sergey Kandaurov wrote:
 Author: pluknet
 Date: Tue Feb 28 11:06:52 2012
 New Revision: 232249
 URL: http://svn.freebsd.org/changeset/base/232249
 
 Log:
   Add lib32 part after libarchive 3.0.3 update.
 
 Modified:
   head/ObsoleteFiles.inc
 
 Modified: head/ObsoleteFiles.inc
 ==
 --- head/ObsoleteFiles.incTue Feb 28 08:36:38 2012(r232248)
 +++ head/ObsoleteFiles.incTue Feb 28 11:06:52 2012(r232249)
 @@ -56,6 +56,9 @@ OLD_FILES+=man/man3/archive_read_data_in
   man/man3/archive_write_set_compression_none.3.gz \
   man/man3/archive_write_set_compression_program.3.gz
  OLD_LIBS+=usr/lib/libarchive.so.5
 +.if ${TARGET_ARCH} == amd64 || ${TARGET_ARCH} == powerpc64
 +OLD_LIBS+=usr/lib32/libarchive.so.5
 +.endif
  # 20120113: removal of wtmpcvt(1)
  OLD_FILES+=usr/bin/wtmpcvt
  OLD_FILES+=usr/share/man/man1/wtmpcvt.1.gz

Please don't add TARGET_ARCH checks unless they are really necessary.
Here they aren't, they very rarely are.

Thanks
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r228953 - in head/tools: regression/pthread/mutex_isowned_np tools/ansify tools/genericize tools/hcomp tools/mtxstat tools/prstats tools/whereintheworld

2011-12-29 Thread Ulrich Spörlein

I know :)

Making my way through them one subdir at a time...

Cheers
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r228896 - head/contrib/netcat

2011-12-28 Thread Ulrich Spörlein
On Mon, 2011-12-26 at 01:14:28 -0800, Doug Barton wrote:
 On 12/26/2011 01:07, Xin LI wrote:
  Author: delphij
  Date: Mon Dec 26 09:07:08 2011
  New Revision: 228896
  URL: http://svn.freebsd.org/changeset/base/228896
  
  Log:
Merge from OpenBSD 5.0 (this is a dummy change, the vendor change does not
apply to us).
 
 When I'm importing stat(1) stuff from Net/OpenBSD I don't do this. I
 will however comment in the commit log for the next substantive change,
 Skipped update N.NN because the change was not relevant to us, or
 words to that effect.
 
 I'm not suggesting that my way of doing this is perfect, or cannot be
 improved. I would suggest however that this change was needless churn.

I think it was the right thing to do. It's better to have one person
(Xin LI) figure out if the change is needed or a no-op and do the
upgrade to match our version to upstream's version, than to have a
discrepancy between the two and cause half a dozen developers that
stumble upon that difference to scratch their heads and spend time in
figuring out if we should import the change.

Cheers,
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r228909 - head/games/fortune/datfiles

2011-12-28 Thread Ulrich Spörlein
On Tue, 2011-12-27 at 10:21:57 +, Doug Barton wrote:
 Author: dougb
 Date: Tue Dec 27 10:21:57 2011
 New Revision: 228909
 URL: http://svn.freebsd.org/changeset/base/228909
 
 Log:
   1. Remove a bunch of duplicates. Usually this means removing them from
  fortunes, but occasionally remove them from the other 2 files when
  they are not offensive, or not murphy'ish enough.
   
  Where the version in fortunes had better attribution and/or formatting,
  copy it over.
   
   2. Fix a few typos
   
   3. Use the full name of François De La Rochefoucauld, fix one of his
  quotes, and remove the duplicate of it.

Sigh,

except for a stupid Unicode version of an apostrophe (’ vs ') this file
was ASCII. And I made it so for a reason. We don't currently have a way
to iconv fortune(6)'s output to the users LC_CTYPE. ASCII is the common
denominator so that's what we have to choose to be bug free.

My plan was to teach fortune to use bsdiconv once that is ready and in
the tree to convert from Unicode to the users' locale. But until that is
ready, we have to stick to ASCII.

This is not a backout request, merely an explanation for why things were
the way they were. I wish we'd mandated UTF-8 as the one true encoding a
looong time ago. If Plan9 could do it, why not us?

Cheers,
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r228909 - head/games/fortune/datfiles

2011-12-28 Thread Ulrich Spörlein
On Wed, 2011-12-28 at 09:59:13 -0800, Doug Barton wrote:
 On 12/28/2011 07:53, Ulrich Spörlein wrote:
  On Tue, 2011-12-27 at 10:21:57 +, Doug Barton wrote:
  Author: dougb
  Date: Tue Dec 27 10:21:57 2011
  New Revision: 228909
  URL: http://svn.freebsd.org/changeset/base/228909
 
  Log:
1. Remove a bunch of duplicates. Usually this means removing them from
   fortunes, but occasionally remove them from the other 2 files when
   they are not offensive, or not murphy'ish enough.

   Where the version in fortunes had better attribution and/or 
  formatting,
   copy it over.

2. Fix a few typos

3. Use the full name of François De La Rochefoucauld, fix one of his
   quotes, and remove the duplicate of it.
  
  Sigh,
  
  except for a stupid Unicode version of an apostrophe (’ vs ')
 
 That seems like an easy thing to fix?

Sure, somebody must have snuk that in while I was not watching ;]
However, the real solution would be some sort of pre-submit check or
even breaking the build when the datfile is not 7bit clean.

The state is that all datfiles were ASCII clean some time in the past,
except for gerrold.limerick which has a unicode (C) in a comment, so it
doesn't actually affect operation of fortune so I left it in.

  this file
  was ASCII. And I made it so for a reason. We don't currently have a way
  to iconv fortune(6)'s output to the users LC_CTYPE. ASCII is the common
  denominator so that's what we have to choose to be bug free.
 
 What breaks for non-ASCII text?

If your terminal is ISO8859-1 (aka latin1) or an other non-UTF-8 groking
terminal, you'll get garbage instead of François. Not a biggie but ugly
anyhow.

  My plan was to teach fortune to use bsdiconv once that is ready and in
  the tree to convert from Unicode to the users' locale. But until that is
  ready, we have to stick to ASCII.
 
 I'm not opposed to doing that, but I want to make sure that a) it's for
 a good reason, and b) that we have some way to know what needs to be
 added back when it's safe.
 
 Meanwhile, I did actually test this change and it worked for me, so I
 thought it was safe to proceed.

Your terminal understands UTF-8, so you don't see a difference between
ASCII and Unicode chars. Try setting LANG to, e.g. en_US.ISO8859-1 and
run xterm +u8 with it (just to make sure). Then, when displaying a quote
you get:

% fortune -m Rochefoucauld
%% (fortunes)
Absence diminishes mediocre passions and increases
great ones, as the wind blows out candles and fans fires.
-- François De La Rochefoucauld

(I hope this makes it through the way I see it). It all boils down to
that fact that fortune(6) is not locale aware and thus only ASCII chars
are safe to display (no EBCDIC does not count).

  This is not a backout request, 
 
 I've no objection to making a change. Apparently the De should be de
 anyway, so what do you suggest?

I cannot speak to that with any authority.

Uli

PS: I'd love for us to drop supporting anything but Unicode, but then
again I'd also would like to have a pony ...
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r228896 - head/contrib/netcat

2011-12-28 Thread Ulrich Spörlein
On Wed, 2011-12-28 at 15:11:33 -0600, Mark Linimon wrote:
 On Wed, Dec 28, 2011 at 04:40:49PM +0100, Ulrich Spörlein wrote:
  It's better to have one person
  (Xin LI) figure out if the change is needed or a no-op and do the
  upgrade to match our version to upstream's version, than to have a
  discrepancy between the two and cause half a dozen developers that
  stumble upon that difference to scratch their heads and spend time in
  figuring out if we should import the change.
 
 We already have the following wiki page:
 
   http://wiki.freebsd.org/PortsNotUpgraded
 
 Perhaps an analagous page for src would be helpful?
 
 mcl

We have

http://wiki.freebsd.org/ContribSoftware

that tries to track the state of anything upstream in src. Maintainers
are encouraged to add notes to their entries if there are reasons the
software is kept at a lower version or whatever.

See also the section for GPLv3'ed software on that page.

Cheers,
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r228896 - head/contrib/netcat

2011-12-28 Thread Ulrich Spörlein
On Wed, 2011-12-28 at 15:00:07 -0800, Doug Barton wrote:
 On 12/28/2011 14:52, Ulrich Spörlein wrote:
 
  We have
  
  http://wiki.freebsd.org/ContribSoftware
  
  that tries to track the state of anything upstream in src. 
 
 I've been maintaining BIND in the base for 9 1/2 years, and never knew
 about that page ... the wiki is a good tool for some things, but IMO
 this kind of information needs to be in the src tree where it is easily
 available, archived for the future, etc.

Agreed. It would make branching that information a whole lot easier!

Any good ideas on how to implement this? It could be as simple as having
all that information in /CONTRIB or something, similar to UPDATING or
MAINTAINERS.

Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r225951 - head

2011-10-07 Thread Ulrich Spörlein
On Mon, 2011-10-03 at 20:46:36 +, Nathan Whitehorn wrote:
 Author: nwhitehorn
 Date: Mon Oct  3 20:46:36 2011
 New Revision: 225951
 URL: http://svn.freebsd.org/changeset/base/225951
 
 Log:
   Fix a number of platform problems in this file (mostly assuming that only
   amd64 has lib32).
 
 Modified:
   head/ObsoleteFiles.inc
 
 Modified: head/ObsoleteFiles.inc
 ==
 --- head/ObsoleteFiles.incMon Oct  3 20:32:55 2011(r225950)
 +++ head/ObsoleteFiles.incMon Oct  3 20:46:36 2011(r225951)
 @@ -56,7 +56,7 @@ OLD_LIBS+=usr/lib/libdwarf.so.2
  OLD_LIBS+=usr/lib/libopie.so.6
  OLD_LIBS+=usr/lib/librtld_db.so.1
  OLD_LIBS+=usr/lib/libtacplus.so.4
 -.if ${TARGET_ARCH} == amd64
 +.if ${TARGET_ARCH} == amd64 || ${TARGET_ARCH} == powerpc64
  OLD_LIBS+=usr/lib32/libcam.so.5
  OLD_LIBS+=usr/lib32/libpcap.so.7
  OLD_LIBS+=usr/lib32/libufs.so.5

These conditionals should all be removed. 99% of them are not needed.
The rm(1) should only be conditional on TARGET != arch1 iff arch1 is
still using the file in question. It doesn't matter that arch2 never
ever had that file. It's just one more rm(1) to a non-existing file.

Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r222980 - in head/sys: amd64/conf i386/conf

2011-07-02 Thread Ulrich Spörlein
On Sat, 11.06.2011 at 13:55:15 -0700, Doug Barton wrote:
 On 6/11/2011 1:02 PM, Warner Losh wrote:
 
  On Jun 11, 2011, at 12:17 PM, Doug Barton wrote:
 
  On 6/11/2011 6:07 AM, Robert Watson wrote:
  To me, this seems like the wrong direction.  Over the last decade, we've
  been trying to move away from conditional compilation of features to
  having them be loadable as modules.
 
  FWIW, I agree. I'm wondering though, is there still a performance penalty 
  for modules? My understanding in the past was that there is, although for 
  most use cases it's in the statistical noise. Is that still true?
 
  At run time, I believe that's true.  At load time, lots of modules can take 
  a few seconds longer.
 
 I have 3 or 4 modules loaded via loader.conf at boot time. They take at 
 least 2 seconds each. IMO loading everything via loader.conf would slow 
 the boot so much as to be a non-starter.
 
 OTOH, I could imagine an rc.d script that depends on mountcritlocal that 
 could load a list of modules. Unless I'm missing something that would be 
 several times faster.

I suspect this is your BIOS' fault. I load 22 modules via loader.conf
and the loader takes 2, at most 3, seconds to load them all (next to the
kernel). This is true for all machines that I own/owned.

As you can guess, I'm very much in favour of moving modules from GENERIC
to loader.conf ...

Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r222273 - in head: gnu/usr.bin gnu/usr.bin/grep tools/build/options usr.bin usr.bin/grep

2011-06-02 Thread Ulrich Spörlein
On Wed, 25.05.2011 at 01:04:13 +, David E. O'Brien wrote:
 Author: obrien
 Date: Wed May 25 01:04:12 2011
 New Revision: 73
 URL: http://svn.freebsd.org/changeset/base/73
 
 Log:
   Build and install a BSD licensed grep.
   If WITH_BSD_GREP is not set, it will be 'bsdgrep' and GNUgrep will be
   '[ef]grep'.  Otherwise, BSD-grep will be the grep family, and GNUgrep
   will be 'gnugrep'.
   
   Discussed with: brooks
 
 Modified:
   head/gnu/usr.bin/Makefile
   head/gnu/usr.bin/grep/Makefile
   head/tools/build/options/WITH_BSD_GREP
   head/usr.bin/Makefile
   head/usr.bin/grep/Makefile
 
 Modified: head/gnu/usr.bin/Makefile
 ==
 --- head/gnu/usr.bin/Makefile Wed May 25 00:34:25 2011(r72)
 +++ head/gnu/usr.bin/Makefile Wed May 25 01:04:12 2011(r73)
 @@ -27,9 +27,7 @@ _groff= groff
  .endif
  .endif
  
 -.if ${MK_BSD_GREP} != yes
  _grep=  grep
 -.endif
  

You should have done the same here as in usr.bin/Makefile, i.e. get rid
of the ${_grep} variable completely. Just saying ...

Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r222094 - head/share/misc

2011-05-23 Thread Ulrich Spörlein
On Sun, 22.05.2011 at 20:16:47 +1000, Edwin Groothuis wrote:
 
 On 22/05/2011, at 7:29 PM, Ulrich Spörlein wrote:
 
  On Thu, 19.05.2011 at 13:09:39 +, Edwin Groothuis wrote:
  Author: edwin
  Date: Thu May 19 13:09:39 2011
  New Revision: 222094
  URL: http://svn.freebsd.org/changeset/base/222094
  
  Log:
   Put AN back after finding out that tzsetup(1) will complain that
   it doesn't exist. It will be removed again once the tzdata distribution
   files have been updated with the replacements for AN.
  
  Wouldn't it be better to have tzsetup use iso3166.tab from the tzdata
  distribution, which is mostly guaranteed to be in sync with zone.tab?
 
 
 Which opens a different can of worms.
 Duplicate file, with semi-similar contents.
 
 Whenever there are changes in the distribution of the tzdata iso3166.tab 
 equivalent file, I check if they are in the /usr/share/misc equivalent file.
 A warning to that file should be added that tzsetup uses it and that they 
 always should check tzsetup functionality before commiting it.

This seems way too brittle, as can be seen by random people going in and
updating our iso3166 file. I'd rather take a tiny duplication of files
than manual fixups needed to unbreak installing.

AFAICS only tzsetup and sysinstall depend on /usr/share/misc/iso3166,
if we change tzsetup to use the iso list from tzdata and since
sysinstall is on the chopping block we could then simply remove our
iso3166 list.

And as for duplicated files, have you looked at regdomain.xml and
ieee80211_regdomain.h? Just saying ...

Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r222094 - head/share/misc

2011-05-22 Thread Ulrich Spörlein
On Thu, 19.05.2011 at 13:09:39 +, Edwin Groothuis wrote:
 Author: edwin
 Date: Thu May 19 13:09:39 2011
 New Revision: 222094
 URL: http://svn.freebsd.org/changeset/base/222094
 
 Log:
   Put AN back after finding out that tzsetup(1) will complain that
   it doesn't exist. It will be removed again once the tzdata distribution
   files have been updated with the replacements for AN.

Wouldn't it be better to have tzsetup use iso3166.tab from the tzdata
distribution, which is mostly guaranteed to be in sync with zone.tab?

Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r221348 - head/sys/boot/i386/boot2

2011-05-12 Thread Ulrich Spörlein
On Tue, 03.05.2011 at 18:51:19 +0200, Roman Divacky wrote:
 On Tue, May 03, 2011 at 04:27:57AM -0500, Brooks Davis wrote:
  On Tue, May 03, 2011 at 03:39:27PM +0200, Roman Divacky wrote:
   With the recent libobjc removal this means that we can compile
   all (no exceptions) of FreeBSD/{i386,amd64} with clang.
   
   Quite a milestone in my opinion :)
  
  
  Great news!  Thanks for all the work to make this happen!
  
  Has boot2 been submitted to LLVM as a clang regression test?
 
 No, but we are setting up a testing environment to track the code
 size changes in boot2.
 
 Pawel, can you comment on this?

Bonus points for doing this retro-actively. That is, use the current
clang we have in the tree and track the size changes to boot2 over the
years. Just for the lulz ...

Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r219084 - in head: bin/test tools/regression/bin/test

2011-03-09 Thread Ulrich Spörlein
On Sun, 27.02.2011 at 12:28:06 +, Xin LI wrote:
 Author: delphij
 Date: Sun Feb 27 12:28:06 2011
 New Revision: 219084
 URL: http://svn.freebsd.org/changeset/base/219084
 
 Log:
   Accept == as an alias of = which is a popular GNU extension.
   
   This is intentionally undocumented for now since it's not part
   of any standard.
   
   MFC after:  1 month

So we are giving up the fight?

Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r218421 - head/usr.bin/gzip

2011-02-14 Thread Ulrich Spörlein
On Sun, 13.02.2011 at 18:05:46 -0500, Glen Barber wrote:
 On 2/13/11 5:58 PM, Glen Barber wrote:
  Hi,
  
  On 2/13/11 5:27 PM, Ulrich Spörlein wrote:
  Log:
Update manpage to remove CRT reference.
 
  Would you mind tackling these as well?
 
 
  share/man/man4/acpi_panasonic.4
 
 Hmm.. acpi_panasonic(4) appears to have a mode which differentiates
 between LCD and CRT modes.  Do you think this manual should be left as-is?

I think this is bogus. Sure, the internal display is of type LCD, but
what the manpage really tries to say is, that the button switches
between the laptop display (can you call that internal?) and the
external VGA port. Not sure how to best phrase this.

LCD brightness should be replaced with display brightness, although
it only pertains to the internal display, not any externally attached
ones ...)

Cheers,
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r218421 - head/usr.bin/gzip

2011-02-13 Thread Ulrich Spörlein
On Mon, 07.02.2011 at 22:33:39 +, Glen Barber wrote:
 Author: gjb (doc committer)
 Date: Mon Feb  7 22:33:39 2011
 New Revision: 218421
 URL: http://svn.freebsd.org/changeset/base/218421
 
 Log:
   Update manpage to remove CRT reference.

Would you mind tackling these as well?

bin/stty/stty.1
share/man/man4/acpi_panasonic.4
usr.bin/colcrt/colcrt.1  (I think this tool should be removed)
usr.bin/ul/ul.1

Cheers
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r217073 - head/etc/rc.d

2011-01-09 Thread Ulrich Spörlein
On Thu, 06.01.2011 at 21:09:22 +, Warner Losh wrote:
 Author: imp
 Date: Thu Jan  6 21:09:22 2011
 New Revision: 217073
 URL: http://svn.freebsd.org/changeset/base/217073
 
 Log:
   Don't require /usr/lib/aout to be on the system.  Test for its
   existance since we don't generally need it.
   
   MFC after:  1 week
 
 Modified:
   head/etc/rc.d/ldconfig

Umm,

Would someone object if the aout stuff get's ripped out with prejudice?

Regards,
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r216694 - head/libexec/rtld-elf

2010-12-28 Thread Ulrich Spörlein
On Sat, 25.12.2010 at 08:42:38 +, Konstantin Belousov wrote:
 Author: kib
 Date: Sat Dec 25 08:42:38 2010
 New Revision: 216694
 URL: http://svn.freebsd.org/changeset/base/216694
 
 Log:
   Add a hook to pass debug flags to the build of rtld when doing make in
   the rtld directory.
   
   Reviewed by:kan

Please revert this, $(VAR) is against style, and passing DEBUG_FLAGS is
the canonical way to achieve what you wanted, eg. make DEBUG_FLAGS=-g is
working just fine for me.

 Modified:
   head/libexec/rtld-elf/Makefile
 
 Modified: head/libexec/rtld-elf/Makefile
 ==
 --- head/libexec/rtld-elf/MakefileFri Dec 24 21:31:18 2010
 (r216693)
 +++ head/libexec/rtld-elf/MakefileSat Dec 25 08:42:38 2010
 (r216694)
 @@ -34,7 +34,7 @@ CFLAGS+=-fPIC
  .else
  CFLAGS+= -fpic
  .endif
 -CFLAGS+= -DPIC
 +CFLAGS+= -DPIC $(DEBUG)
  LDFLAGS+=-shared -Wl,-Bsymbolic
  DPADD=   ${LIBC_PIC}
  LDADD=   -lc_pic -lssp_nonshared
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r216473 - head/sbin/geom/class/eli

2010-12-18 Thread Ulrich Spörlein
On Thu, 16.12.2010 at 16:43:48 -0800, David O'Brien wrote:
 On Thu, Dec 16, 2010 at 12:27:04PM -0800, Xin LI wrote:
  On 12/16/10 12:23, Ulrich Spörlein wrote:
   Shamless plug: the attached, crude expect(1) script allows you to do
   $ cd /usr/src  universe-build sbin/geom WARNS=6
   
   with the minimal amount of compilation (you have to build the toolchain
   once, though). I found it invaluable.
  
  I think we could probably put that in src/tools/somewhere...
 
 Ulrich,
 Yes, please.

I'd love to, but some tcl/expect expert should get in contact with me
first, as the script has some serious deficiencies that need fixing
before a public release.

Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r216147 - head/sbin/geom/class/eli

2010-12-03 Thread Ulrich Spörlein
On Fri, 03.12.2010 at 10:06:19 +, Xin LI wrote:
 Author: delphij
 Date: Fri Dec  3 10:06:19 2010
 New Revision: 216147
 URL: http://svn.freebsd.org/changeset/base/216147
 
 Log:
* Recommend a overwrite of whole geli provider before use.
* Correct a typo while I'm there.
   
   Reviewed by:pjd
   MFC after:  2 weeks
 
 Modified:
   head/sbin/geom/class/eli/geli.8
 
 Modified: head/sbin/geom/class/eli/geli.8
 ==
 --- head/sbin/geom/class/eli/geli.8   Fri Dec  3 09:26:56 2010
 (r216146)
 +++ head/sbin/geom/class/eli/geli.8   Fri Dec  3 10:06:19 2010
 (r216147)
 @@ -24,7 +24,7 @@
  .\
  .\ $FreeBSD$
  .\
 -.Dd October 20, 2010
 +.Dd December 3, 2010
  .Dt GELI 8
  .Os
  .Sh NAME
 @@ -842,7 +842,7 @@ Enter passphrase:
  .Nm
  supports two encryption modes:
  .Nm XTS ,
 -which was standarized as
 +which was standardized as
  .Nm IEE P1619
  and
  .Nm CBC
 @@ -873,6 +873,10 @@ changes with the data he owns without no
  In other words
  .Nm
  will not protect your data against replay attacks.
 +.Pp
 +It is recommended to write the whole provider before the first use,
 +in order to make sure that all sectors and their corresponding
 +checksums are properly initialized into a consistent state.
  .Sh SEE ALSO
  .Xr crypto 4 ,
  .Xr gbde 4 ,

I'm not sure this wording is very helpful. Why should there be a
consistent state? In fact, if you write all zeros to the partition
before creating the geom, then an attacker pretty much knows how much
data you have written to the provider. I'm not saying this weakens any
security, but I think the current phrasing will confuse the reader. What
needs to be consistent? What does writing to the provider mean?

Or am I mixing up provider and consumer here?

Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r215271 - head

2010-11-14 Thread Ulrich Spörlein
On Sat, 13.11.2010 at 22:38:33 +, Warner Losh wrote:
 Author: imp
 Date: Sat Nov 13 22:38:33 2010
 New Revision: 215271
 URL: http://svn.freebsd.org/changeset/base/215271
 
 Log:
   Add mips back to universe
 
 Modified:
   head/Makefile
 
 Modified: head/Makefile
 ==
 --- head/Makefile Sat Nov 13 22:34:12 2010(r215270)
 +++ head/Makefile Sat Nov 13 22:38:33 2010(r215271)
 @@ -281,7 +281,7 @@ tinderbox:
  # existing system is.
  #
  .if make(universe) || make(universe_kernels) || make(tinderbox)
 -TARGETS?=amd64 i386 ia64 pc98 powerpc sparc64 sun4v
 +TARGETS?=amd64 i386 ia64 pc98 powerpc sparc64 sun4v mips

Can we have that sorted, please? I'm sure it was sorted before ...

-TARGETS?=amd64 i386 ia64 pc98 powerpc sparc64 sun4v mips
+TARGETS?=amd64 i386 ia64 mips pc98 powerpc sparc64 sun4v

Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r215041 - head/contrib/bzip2

2010-11-09 Thread Ulrich Spörlein
On Tue, 09.11.2010 at 18:32:57 +, David E. O'Brien wrote:
 Author: obrien
 Date: Tue Nov  9 18:32:57 2010
 New Revision: 215041
 URL: http://svn.freebsd.org/changeset/base/215041
 
 Log:
   Upgrade to Bzip2 version 1.0.6.
   
   Reviewed by: SO (cperciva)
 
 Modified:
   head/contrib/bzip2/CHANGES
   head/contrib/bzip2/LICENSE
   head/contrib/bzip2/Makefile
   head/contrib/bzip2/Makefile-libbz2_so
   head/contrib/bzip2/README
   head/contrib/bzip2/README.COMPILATION.PROBLEMS
   head/contrib/bzip2/blocksort.c
   head/contrib/bzip2/bzip2.1
   head/contrib/bzip2/bzip2.c
   head/contrib/bzip2/bzip2recover.c
   head/contrib/bzip2/bzlib.c
   head/contrib/bzip2/bzlib.h
   head/contrib/bzip2/bzlib_private.h
   head/contrib/bzip2/compress.c
   head/contrib/bzip2/crctable.c
   head/contrib/bzip2/decompress.c
   head/contrib/bzip2/huffman.c
   head/contrib/bzip2/randtable.c
   head/contrib/bzip2/spewG.c
   head/contrib/bzip2/unzcrash.c
 Directory Properties:
   head/contrib/bzip2/   (props changed)

Perhaps I'm reading this wrong, but shouldn't those files have been
copied/merged from vendor/bzip2/dist?

Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r215041 - head/contrib/bzip2

2010-11-09 Thread Ulrich Spörlein
On Tue, 09.11.2010 at 17:04:27 -0500, John Baldwin wrote:
 On Tuesday, November 09, 2010 4:23:56 pm Ulrich Spörlein wrote:
  On Tue, 09.11.2010 at 18:32:57 +, David E. O'Brien wrote:
   Author: obrien
   Date: Tue Nov  9 18:32:57 2010
   New Revision: 215041
   URL: http://svn.freebsd.org/changeset/base/215041
   
   Log:
 Upgrade to Bzip2 version 1.0.6.
 
 Reviewed by: SO (cperciva)
   
   Modified:
 head/contrib/bzip2/CHANGES
 head/contrib/bzip2/LICENSE
 head/contrib/bzip2/Makefile
 head/contrib/bzip2/Makefile-libbz2_so
 head/contrib/bzip2/README
 head/contrib/bzip2/README.COMPILATION.PROBLEMS
 head/contrib/bzip2/blocksort.c
 head/contrib/bzip2/bzip2.1
 head/contrib/bzip2/bzip2.c
 head/contrib/bzip2/bzip2recover.c
 head/contrib/bzip2/bzlib.c
 head/contrib/bzip2/bzlib.h
 head/contrib/bzip2/bzlib_private.h
 head/contrib/bzip2/compress.c
 head/contrib/bzip2/crctable.c
 head/contrib/bzip2/decompress.c
 head/contrib/bzip2/huffman.c
 head/contrib/bzip2/randtable.c
 head/contrib/bzip2/spewG.c
 head/contrib/bzip2/unzcrash.c
   Directory Properties:
 head/contrib/bzip2/   (props changed)
  
  Perhaps I'm reading this wrong, but shouldn't those files have been
  copied/merged from vendor/bzip2/dist?
 
 I think they were.  Notice the prop change on the directory.  Also, 1.0.6 was 
 imported into the vendor area a while ago.  I think David was just now able 
 to 
 get review completed and commit the merge.

Subversion is weird. I was expecting lines like these to appear:
   (from /vendor/bzip2/dist/foo:12345)
but this seems to be only done for (A)dded files.

Sorry for the noise.
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r211397 - in head: lib/libbluetooth lib/libc/gen lib/libc/net lib/libc/stdlib lib/libc/sys lib/libedit lib/libelf lib/libgeom lib/libgpib lib/libgssapi lib/libpmc lib/libradius lib/lib

2010-08-17 Thread Ulrich Spörlein
On Mon, 16.08.2010 at 15:18:30 +, Joel Dahl wrote:
 Author: joel (doc committer)
 Date: Mon Aug 16 15:18:30 2010
 New Revision: 211397
 URL: http://svn.freebsd.org/changeset/base/211397
 
 Log:
   Fix typos, spelling, formatting and mdoc mistakes found by Nobuyuki while
   translating these manual pages.  Minor corrections by me.
   
   Submitted by:   Nobuyuki Koganemaru n-kog...@syd.odn.ne.jp

Awesome!

Cheers,
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r209153 - head/lib/clang

2010-06-14 Thread Ulrich Spörlein
On Mon, 14.06.2010 at 06:23:47 +, Ed Schouten wrote:
 Author: ed
 Date: Mon Jun 14 06:23:47 2010
 New Revision: 209153
 URL: http://svn.freebsd.org/changeset/base/209153
 
 Log:
   Unbreak Clang on PowerPC.
   
   It seems GCC 4.2.1 on PowerPC miscompiles Clang, causing it to crash
   when building even simple Hello World applications. Switch back to -O1
   for this architecture.

What about clang compiled using clang -O2? Ie., does clang bootstrap
correctly on PPC and this is a genuine gcc 4.2.1 bug?

Regards,
Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r206497 - in head: sbin/geom/class sbin/geom/class/sched sys/geom/sched sys/modules/geom sys/modules/geom/geom_sched sys/modules/geom/geom_sched/gs_sched sys/modules/geom/geom_sched/gs

2010-04-15 Thread Ulrich Spörlein
On Thu, 15.04.2010 at 17:15:57 +0200, Luigi Rizzo wrote:
 On Thu, Apr 15, 2010 at 04:38:23PM +0200, Attila Nagy wrote:
  On 04/12/2010 06:37 PM, Luigi Rizzo wrote:
 Bring in geom_sched, support for scheduling disk I/O requests
 in a device independent manner. Also include an example anticipatory
 scheduler, gsched_rr, which gives very nice performance improvements
 in presence of competing random access patterns.
  
 This is joint work with Fabio Checconi, developed last year
 and presented at BSDCan 2009. You can find details in the
 README file or at
 
  Are there any plans to bring in something like Linux's ionice (or even 
  better solutions)? Is it possible to do it easily at all (the user and 
  GEOM are seemingly very far from each other)?
 
 I can easily[*] modify the I/O priority/weight of process or threads,
 but you have to keep in mind that once a request is intercepted by
 the filesystem code (e.g. for delayed writes, or avoid duplication
 of pending reads), by the time it hits the disk it is not trivial
 to tell who should be charged for it.
 
 This is an area where we still need to experiment a bit
 (especially to find on which process issues which request,
 say for metadata, delayed writes, shared reads).
 
 [*] the 'easy' way is put the information in an external hash table
 and look it up using as a search key either of uid, gid, pid/struct
 thread *.  I think we did something like this in the GSOC2005
 project on disk scheduling.  A more intrusive way involves extending
 the struct thread with an extra field to store the io priority.

What would already be helpful, is an I/O time measurement of the overall
system and have that displayed in, eg., vmstat like Linux and Solaris
do. It gives a better measure of if a system is CPU bound or I/O bound
or neither.

Can the scheduler help here?

Uli
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org