From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 9 22:26:07 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D0BA106566C; Sat, 9 Oct 2010 22:26:07 +0000 (UTC) (envelope-from mlobo@digiart.art.br) Received: from sv4.hmnoc.net (sv4.hmnoc.net [63.247.76.174]) by mx1.freebsd.org (Postfix) with ESMTP id 1C9BF8FC22; Sat, 9 Oct 2010 22:26:06 +0000 (UTC) Received: from [189.70.152.114] (port=61792 helo=papi.localnet) by sv4.hmnoc.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P4h3e-0006rH-AC; Sat, 09 Oct 2010 18:34:23 -0300 From: Mario Lobo To: freebsd-hackers@freebsd.org Date: Sat, 9 Oct 2010 18:32:28 -0300 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <1286397912.27308.40.camel@localhost.localdomain> <51B4504F-5AA4-47C5-BF23-FA51DE5BC8C8@vicor.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010091832.28759.mlobo@digiart.art.br> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sv4.hmnoc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - digiart.art.br X-Mailman-Approved-At: Sun, 10 Oct 2010 00:28:30 +0000 Cc: Brandon Gooch , Devin Teske , Garrett Cooper Subject: Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 22:26:07 -0000 Forgive me for this top posting but I don't want to risk ruining the perfect flow of Garret's analysis. I read through it as if I was in a classroom lecture. I have a special folder in kmail called "FreeBSD Tops" where I put mail that makes me discover something unknown to me about FBSD, and this one is marked as important. Thank you both, Devin and Garret!. -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winfoes FREE) On Saturday 09 October 2010 17:25:55 Garrett Cooper wrote: > On Wed, Oct 6, 2010 at 8:29 PM, Devin Teske wrote: > > On Oct 6, 2010, at 4:09 PM, Brandon Gooch wrote: > >> On Wed, Oct 6, 2010 at 3:45 PM, Devin Teske wrote: > >>> Hello fellow freebsd-hackers, > >>> > >>> Long-time hacker, first-time poster. > >>> > >>> I'd like to share a shell script that I wrote for FreeBSD system > >>> administration. > >> > >> It seems the list ate the attachment :( > > > > Here she is ^_^ Comments welcome. > > Hah. More nuclear reactor than bikeshed :D! > > > #!/bin/sh > > # -*- tab-width: 4 -*- ;; Emacs > > # vi: set tabstop=4 :: Vi/ViM > > > > # > > # Default setting whether to dump a list of internal dependencies upon > > exit # > > > > : ${SYSRC_SHOW_DEPS:=0} > > > > ############################################################ GLOBALS > > > > # Global exit status variables > > > > : ${SUCCESS:=0} > > : ${FAILURE:=1} > > Should this really be set to something other than 0 or 1 by the > end-user's environment? This would simplify a lot of return/exit > calls... > > > # > > # Program name > > # > > progname="${0##*/}" > > > > # > > # Options > > # > > SHOW_EQUALS= > > SHOW_NAME=1 > > > > # Reserved for internal use > > _depend= > > When documenting arguments passed to functions, I usually do something > like: > > # 1 - a var > # 2 - another var > # > # ... etc > > because it's easier to follow for me at least. > > Various spots in the codebase have differing styles though (and it > would be better to follow the style in /etc/rc.subr, et all for > consistency, because this tool is a consumer of those APIs). > > > ############################################################ FUNCTION > > > > # fprintf $fd $fmt [ $opts ... ] > > # > > # Like printf, except allows you to print to a specific file-descriptor. > > Useful # for printing to stderr (fd=2) or some other known > > file-descriptor. # > > > > : dependency checks performed after depend-function declaration > > : function ; fprintf ( ) # $fd $fmt [ $opts ... ] > > Dumb question. Does declaring `: dependency checks performed after > depend-function declaration' and `: function' buy you anything other > than readability via comments with syntax checking? > > > { > > local fd=$1 > > [ $# -gt 1 ] || return ${FAILURE-1} > > While working at IronPort, Doug (my tech lead) has convinced me that > constructs like: > > if [ $# -le 1 ] > then > return ${FAILURE-1} > fi > > Are a little more consistent and easier to follow than: > > [ $# -gt 1 ] || return ${FAILURE-1} > > Because some folks have a tendency to chain shell expressions, i.e. > > expr1 || expr2 && expr3 > > Instead of: > > if expr1 || expr2 > then > expr3 > fi > > or... > > if ! expr1 > then > expr2 > fi > if [ $? -eq 0 ] > then > expr3 > fi > > I've caught myself chaining 3 expressions together, and I broke that > down into a simpler (but more longhand format), but I've caught people > chaining 4+ expressions together, which just becomes unmanageable to > follow (and sometimes bugs creep in because of operator ordering and > expression evaluation and subshells, etc, but that's another topic for > another time :)..). > > > shift 1 > > printf "$@" >&$fd > > } > > > > # eprintf $fmt [ $opts ... ] > > # > > # Print a message to stderr (fd=2). > > # > > > > : dependency checks performed after depend-function declaration > > : function ; eprintf ( ) # $fmt [ $opts ... ] > > > > { > > fprintf 2 "$@" > > } > > > > # show_deps > > # > > # Print the current list of dependencies. > > # > > > > : dependency checks performed after depend-function declaration > > : function ; show_deps ( ) # > > > > { > > if [ "$SYSRC_SHOW_DEPS" = "1" ]; then > > eprintf "Running internal dependency list:\n" > > > > local d > > for d in $_depend; do > > eprintf "\t%-15ss%s\n" "$d" "$( type "$d" )" > > The command(1) -v builtin is more portable than the type(1) builtin > for command existence lookups (it just doesn't tell you what the > particular item is that you're dealing with like type(1) does). > > I just learned that it also handles other builtin lexicon like if, > for, while, then, do, done, etc on FreeBSD at least; POSIX also > declares that it needs to support that though, so I think it's a safe > assumption to state that command -v will provide you with what you > need. > > > done > > fi > > } > > > > # die [ $err_msg ... ] > > # > > # Optionally print a message to stderr before exiting with failure > > status. # > > > > : dependency checks performed after depend-function declaration > > : function ; die ( ) # [ $err_msg ... ] > > > > { > > local fmt="$1" > > [ $# -gt 0 ] && shift 1 > > [ "$fmt" ] && eprintf "$fmt\n" "$@" > > "x$fmt" != x ? It seems like it could be simplified to: > > if [ $# -gt 0 ] > then > local fmt=$1 > shift 1 > eprintf "$fmt\n" "$@" > fi > > > show_deps > > exit ${FAILURE-1} > > } > > > > # have $anything > > # > > # Used for dependency calculations. Arguments are passed to the `type' > > built-in # to determine if a given command is available (either as a > > shell built-in or # as an external binary). The return status is true if > > the given argument is # for an existing built-in or executable, > > otherwise false. > > # > > # This is a convenient method for building dependency lists and it aids > > in the # readability of a script. For example, > > # > > # Example 1: have sed || die "sed is missing" > > # Example 2: if have awk; then > > # # We have awk... > > # else > > # # We DON'T have awk... > > # fi > > # Example 3: have reboot && reboot > > # > > > > : dependency checks performed after depend-function declaration > > : function ; have ( ) # $anything > > > > { > > type "$@" > /dev/null 2>&1 > > } > > > > # depend $name [ $dependency ... ] > > # > > # Add a dependency. Die with error if dependency is not met. > > # > > > > : dependency checks performed after depend-function declaration > > : function ; depend ( ) # $name [ $dependency ... ] > > > > { > > local by="$1" arg > > shift 1 > > > > for arg in "$@"; do > > local d > > Wouldn't it be better to declare this outside of the loop (I'm not > sure how optimal it is to place it inside the loop)? > > > for d in $_depend ""; do > > [ "$d" = "$arg" ] && break > > done > > if [ ! "$d" ]; then > > Could you make this ` "x$d" = x ' instead? > > > have "$arg" || die \ > > "%s: Missing dependency '%s' required by > > %s" \ "${progname:-$0}" "$arg" "$by" > > The $0 substitution is unnecessary based on how you set progname above: > > $ foo=yadda > $ echo ${foo##*/} > yadda > $ foo=yadda/badda/bing/bang > $ echo ${foo##*/} > bang > > > _depend="$_depend${_depend:+ }$arg" > > fi > > done > > } > > > > # > > # Perform dependency calculations for above rudimentary functions. > > # NOTE: Beyond this point, use the depend-function BEFORE dependency-use > > # > > depend fprintf 'local' '[' 'return' 'shift' 'printf' > > depend eprintf 'fprintf' > > depend show_deps 'if' '[' 'then' 'eprintf' 'local' 'for' 'do' 'done' 'fi' > > depend die 'local' '[' 'shift' 'eprintf' 'show_deps' 'exit' > > depend have 'local' 'type' 'return' > > depend depend 'local' 'shift' 'for' 'do' '[' 'break' 'done' 'if' > > 'then' \ 'have' 'die' 'fi' > > I'd say that you have bigger fish to try if your shell lacks the > needed lexicon to parse built-ins like for, do, local, etc :)... > > > # usage > > # > > # Prints a short syntax statement and exits. > > # > > depend usage 'local' 'eprintf' 'die' > > > > : function ; usage ( ) # > > > > { > > local optfmt="\t%-12s%s\n" > > local envfmt="\t%-22s%s\n" > > > > eprintf "Usage: %s [OPTIONS] name[=value] ...\n" "${progname:-$0}" > > > > eprintf "OPTIONS:\n" > > eprintf "$optfmt" "-h --help" \ > > "Print this message to stderr and exit." > > eprintf "$optfmt" "-d" \ > > "Print list of internal dependencies before exit." > > eprintf "$optfmt" "-e" \ > > "Print query results as \`var=value' (useful for > > producing" eprintf "$optfmt" "" \ > > "output to be fed back in). Ignored if -n is specified." > > eprintf "$optfmt" "-n" \ > > "Show only variable values, not their names." > > eprintf "\n" > > > > eprintf "ENVIRONMENT:\n" > > eprintf "$envfmt" "SYSRC_SHOW_DEPS" \ > > "Dump list of dependencies. Must be zero or one" > > eprintf "$envfmt" "" \ > > "(default: \`0')" > > eprintf "$envfmt" "RC_DEFAULTS" \ > > "Location of \`/etc/defaults/rc.conf' file." > > > > die > > } > > > > # sysrc $setting > > # > > # Get a system configuration setting from the collection of system- > > # configuration files (in order: /etc/defaults/rc.conf /etc/rc.conf > > # and /etc/rc.conf). > > # > > # Examples: > > # > > # sysrc sshd_enable > > # returns YES or NO > > # sysrc defaultrouter > > # returns IP address of default router (if configured) > > # sysrc 'hostname%%.*' > > # returns $hostname up to (but not including) first `.' > > # sysrc 'network_interfaces%%[$IFS]*' > > # returns first word of $network_interfaces > > # sysrc 'ntpdate_flags##*[$IFS]' > > # returns last word of $ntpdate_flags (time server address) > > # sysrc usbd_flags-"default" > > # returns $usbd_flags or "default" if unset > > # sysrc usbd_flags:-"default" > > # returns $usbd_flags or "default" if unset or NULL > > # sysrc cloned_interfaces+"alternate" > > # returns "alternate" if $cloned_interfaces is set > > # sysrc cloned_interfaces:+"alternate" > > # returns "alternate" if $cloned_interfaces is set and > > non-NULL # sysrc '#kern_securelevel' > > # returns length in characters of $kern_securelevel > > # sysrc 'hostname?' > > # returns NULL and error status 2 if $hostname is unset (or > > if # set, returns the value of $hostname with no error > > status) # sysrc 'hostname:?' > > # returns NULL and error status 2 if $hostname is unset or > > NULL # (or if set and non-NULL, returns value without > > error status) # > > I would probably just point someone to a shell manual, as available > options and behavior may change, and behavior shouldn't (but > potentially could) vary between versions of FreeBSD. > > > depend sysrc 'local' '[' 'return' '.' 'have' 'eval' 'echo' > > > > : function ; sysrc ( ) # $varname > > > > { > > : ${RC_DEFAULTS:="/etc/defaults/rc.conf"} > > > > local defaults="$RC_DEFAULTS" > > local varname="$1" > > > > # Check arguments > > [ -r "$defaults" ] || return > > [ "$varname" ] || return > > > > ( # Execute within sub-shell to protect parent environment > > [ -f "$defaults" -a -r "$defaults" ] && . "$defaults" > > have source_rc_confs && source_rc_confs > > eval echo '"${'"$varname"'}"' 2> /dev/null > > ) > > } > > > > # ... | lrev > > # lrev $file ... > > # > > # Reverse lines of input. Unlike rev(1) which reverses the ordering of > > # characters on a single line, this function instead reverses the line > > # sequencing. > > # > > # For example, the following input: > > # > > # Line 1 > > # Line 2 > > # Line 3 > > # > > # Becomes reversed in the following manner: > > # > > # Line 3 > > # Line 2 > > # Line 1 > > # > > depend lrev 'local' 'if' '[' 'then' 'while' 'do' 'shift' 'done' 'else' > > 'read' \ 'fi' 'echo' > > > > : function ; lrev ( ) # $file ... > > > > { > > local stdin_rev= > > if [ $# -gt 0 ]; then > > # > > # Reverse lines from files passed as positional arguments. > > # > > while [ $# -gt 0 ]; do > > local file="$1" > > [ -f "$file" ] && lrev < "$file" > > shift 1 > > done > > else > > # > > # Reverse lines from standard input > > # > > while read -r LINE; do > > stdin_rev="$LINE > > $stdin_rev" > > done > > fi > > > > echo -n "$stdin_rev" > > } > > > > # sysrc_set $setting $new_value > > # > > # Change a setting in the system configuration files (edits the files > > in-place # to change the value in the last assignment to the variable). > > If the variable # does not appear in the source file, it is appended to > > the end of the primary # system configuration file `/etc/rc.conf'. > > # > > depend sysrc_set 'local' 'sysrc' '[' 'return' 'for' 'do' 'done' 'if' > > 'have' \ 'then' 'else' 'while' 'read' 'case' 'esac' 'fi' 'break' \ > > 'eprintf' 'echo' 'lrev' > > > > : function ; sysrc_set ( ) # $varname $new_value > > > > { > > local rc_conf_files="$( sysrc rc_conf_files )" > > local varname="$1" new_value="$2" > > IIRC I've run into issues doing something similar to this in the past, > so I broke up the local declarations on 2+ lines. > > > local file conf_files= > > > > # Check arguments > > [ "$rc_conf_files" ] || return ${FAILURE-1} > > [ "$varname" ] || return ${FAILURE-1} > > Why not just do... > > if [ "x$rc_conf_files" = x -o "x$varname" = x ] > then > return ${FAILURE-1} > fi > > ...? > > > # Reverse the order of files in rc_conf_files > > for file in $rc_conf_files; do > > conf_files="$file${conf_files:+ }$conf_files" > > done > > > > # > > # Determine which file we are to operate on. If no files match, > > we'll # simply append to the last file in the list (`/etc/rc.conf'). # > > local found= > > local regex="^[[:space:]]*$varname=" > > for file in $conf_files; do > > #if have grep; then > > if false; then > > grep -q "$regex" $file && found=1 > > Probably want to redirect stderr for the grep output to /dev/null, or > test for the file's existence first, because rc_conf_files doesn't > check for whether or not the file exists which would result in noise > from your script: > > $ . /etc/defaults/rc.conf > $ echo $rc_conf_files > /etc/rc.conf /etc/rc.conf.local > $ grep -q foo /etc/rc.local > grep: /etc/rc.local: No such file or directory > > > else > > while read LINE; do \ > > case "$LINE" in \ > > $varname=*) found=1;; \ > > esac; \ > > done < $file > > fi > > [ "$found" ] && break > > done > > > > # > > # Perform sanity checks. > > # > > if [ ! -w $file ]; then > > eprintf "\n%s: cannot create %s: permission denied\n" \ > > Being pedantic, I would capitalize the P in permission to match > EACCES's output string. > > > "${progname:-$0}" "$file" > > return ${FAILURE-1} > > fi > > > > # > > # If not found, append new value to last file and return. > > # > > if [ ! "$found" ]; then > > echo "$varname=\"$new_value\"" >> $file > > return ${SUCCESS-0} > > fi > > > > # > > # Operate on the matching file, replacing only the last > > occurrence. # > > local new_contents="`lrev $file 2> /dev/null | \ > > ( found= > > while read -r LINE; do > > if [ ! "$found" ]; then > > #if have grep; then > > if false; then > > match="$( echo "$LINE" | grep "$regex" )" > > else > > case "$LINE" in > > $varname=*) match=1;; > > *) match=;; > > esac > > fi > > if [ "$match" ]; then > > LINE="$varname"'="'"$new_value"'"' > > found=1 > > fi > > fi > > echo "$LINE" > > done > > ) | lrev`" > > > > [ "$new_contents" ] \ > > && echo "$new_contents" > $file > > What if this write fails, or worse, 2+ people were modifying the file > using different means at the same time? You could potentially > lose/corrupt your data and your system is potentially hosed, is it > not? Why not write the contents out to a [sort of?] temporary file > (even $progname.$$ would suffice probably, but that would have > potential security implications so mktemp(1) might be the way to go), > then move the temporary file to $file? You might also want to use > lockf to lock the file. > > > } > > > > ############################################################ MAIN SOURCE > > > > # > > # Perform sanity checks > > # > > depend main '[' 'usage' > > [ $# -gt 0 ] || usage > > > > # > > # Process command-line options > > # > > depend main 'while' '[' 'do' 'case' 'usage' 'eprintf' \ > > 'break' 'esac' 'shift' 'done' > > while [ $# -gt 0 ]; do > > Why not just use the getopts shell built-in and shift $(( $OPTIND - 1 > )) at the end? > > > case "$1" in > > -h|--help) usage;; > > -d) SYSRC_SHOW_DEPS=1;; > > -e) SHOW_EQUALS=1;; > > -n) SHOW_NAME=;; > > -*) eprintf "%s: unrecognized option \`$1'\n" "${progname:-$0}" > > usage;; > > *) # Since it is impossible (in many shells, including bourne, c, > > # tennex-c, and bourne-again) to name a variable beginning > > with a # dash/hyphen [-], we will terminate the option-list at the first > > # item that doesn't begin with a dash. > > break;; > > esac > > shift 1 > > done > > [ "$SHOW_NAME" ] || SHOW_EQUALS= > > > > # > > # Process command-line arguments > > # > > depend main '[' 'while' 'do' 'case' 'echo' 'sysrc' 'if' 'sysrc_set' > > 'then' \ 'fi' 'esac' 'shift' 'done' > > SEP=': ' > > [ "$SHOW_EQUALS" ] && SEP='="' > > while [ $# -gt 0 ]; do > > NAME="${1%%=*}" > > case "$1" in > > *=*) > > echo -n "${SHOW_NAME:+$NAME$SEP}$( > > sysrc "$1" )${SHOW_EQUALS:+\"}" > > if sysrc_set "$NAME" "${1#*=}"; then > > echo " -> $( sysrc "$NAME" )" > > fi > > What happens if this set fails :)? It would be confusing to end users > if you print out the value (and they expected it to be set), but it > failed for some particular reason. > > > ;; > > *) > > if ! IGNORED="$( sysrc "$NAME?" )"; then > > echo "${progname:-$0}: unknown variable '$NAME'" > > else > > echo "${SHOW_NAME:+$NAME$SEP}$( > > sysrc "$1" )${SHOW_EQUALS:+\"}" > > Not sure if it's a gmail screwup or not, but is there supposed to > be a newline between `$(' and `sysrc' ? > And now some more important questions: > > 1. What if I do: sysrc PS1 :) (hint: variables inherited from the > shell really shouldn't end up in the output / be queried)? > 2. Could you add an analog for sysctl -a and sysctl -n ? > 3. There are some more complicated scenarios that unfortunately > this might not pass when setting variables (concerns that come to mind > deal with user-set $rc_conf_files where values could be spread out > amongst different rc.conf's, and where more complicated shell syntax > would become a slippery slope for this utility, because one of the > lesser used features within rc.conf is that it's nothing more than > sourceable bourne shell script :)...). I would definitely test the > following scenarios: > > #/etc/rc.conf-1: > foo=baz > > #/etc/rc.conf-2: > foo=bar > > #/etc/rc.conf-3: > foo="$foo zanzibar" > > Scenario A: > > #/etc/rc.conf: > rc_conf_files="/etc/rc.conf-1 /etc/rc.conf-2" > > The value of foo should be set to bar; ideally the value of foo in > /etc/rc.conf-2 should be set to a new value by the end user. > > Scenario B: > > #/etc/rc.conf: > rc_conf_files="/etc/rc.conf-2 /etc/rc.conf-1" > > The value of foo should be set to baz; ideally the value of foo in > /etc/rc.conf-1 should be set to a new value by the end user. > > Scenario C: > > #/etc/rc.conf: > rc_conf_files="/etc/rc.conf-1 /etc/rc.conf-2 /etc/rc.conf-3" > > The value of foo should be set to `bar zanzibar'; ideally the > value of foo in /etc/rc.conf-3 should be set to a new value by the end > user (but that will affect the expected output potentially). > > Scenario D: > > #/etc/rc.conf: > rc_conf_files="/etc/rc.conf-2 /etc/rc.conf-1 /etc/rc.conf-3" > > The value of foo should be set to `baz zanzibar'; ideally the > value of foo in /etc/rc.conf-3 should be set to a new value by the end > user (but that will affect the expected output potentially). > > I'll probably think up some more scenarios later that should be > tested... the easy way out is to state that the tool does a best > effort at overwriting the last evaluated value. > Overall, awesome looking tool and I'll be happy to test it > Thanks! > -Garrett > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 10 02:30:46 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CCE8106566C for ; Sun, 10 Oct 2010 02:30:46 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BFD298FC13 for ; Sun, 10 Oct 2010 02:30:45 +0000 (UTC) Received: by iwn8 with SMTP id 8so2968255iwn.13 for ; Sat, 09 Oct 2010 19:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=APRc6dKIOehS8Gfd5IeVZOI+qxoaQeHQhCBUUuVVSww=; b=oeTjE5sYgYX0BFcyWDlTaou+VYr++KCWDqY2KhOv7p86pUkM5KR8+RfsWNzHF+/c/y OpksnHx1VxRnGz5x7nMg+vhhbYYq/u0nT1Xy9mJoYLD/9i1/MMiYRUyO9dWMEHqfqMz3 ZFkKFPCSmnMR2ZnmFkTMiVNzgY2iGpDmDttRI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=TQtHleF/5eTi+Fx5Ud31CUYfFJpHRvTQW3GRt0HIYJJCXWNbyA4ovKcSQGwn3qsn7H 9/b6jjiEPorkBH49kurLtujo/xcvzp15dDtDYrpYUl+2LrSXoNPsi85PJmBboywIHp7K ZTJj3bISPhpaaGvjthRyeaoSV6BxocerUtGXc= MIME-Version: 1.0 Received: by 10.42.6.135 with SMTP id a7mr1168331ica.53.1286677844932; Sat, 09 Oct 2010 19:30:44 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Sat, 9 Oct 2010 19:30:44 -0700 (PDT) In-Reply-To: <238E0B24-AA12-4684-9651-84DA665BE893@vicor.com> References: <1286397912.27308.40.camel@localhost.localdomain> <51B4504F-5AA4-47C5-BF23-FA51DE5BC8C8@vicor.com> <238E0B24-AA12-4684-9651-84DA665BE893@vicor.com> Date: Sat, 9 Oct 2010 19:30:44 -0700 X-Google-Sender-Auth: ueBHPcnNwBPb0JOojDbrFCQsRWA Message-ID: From: Garrett Cooper To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Brandon Gooch , freebsd-hackers@freebsd.org Subject: Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2010 02:30:46 -0000 Trimming out some context... On Sat, Oct 9, 2010 at 3:39 PM, Devin Teske wrote: > ... > Should this really be set to something other than 0 or 1 by the > end-user's environment? This would simplify a lot of return/exit > calls... > > A scenario that I envision that almost never arises, but... > Say someone wanted to call my script but wanted to mask it to always retu= rn > with success (why? I dunno... it's conceivable though). > Example:=A0(this should be considered ugly -- because it is) > FAILURE=3D0 &&=A0sysrc foo && reboot But then someone could do sysrc foo || : && reboot, or more simply sysrc foo; reboot Perhaps you meant env FAILURE=3D0 sysrc foo && reboot ? $ cat failure.sh #!/bin/sh echo "FAILURE: $FAILURE" $ FAILURE=3D0 && sh failure.sh FAILURE: $ env FAILURE=3D0 sh failure.sh FAILURE: 0 > Efficacy: > The `reboot' rvalue of '&&' will always execute because FAILURE. > I don't really know why I got into the practice of writing scripts this > way... most likely a foregone conclusion that seemed like a good idea at = one > time but never really amounted to anything substantive (in fact, it shoul= d > perhaps be considered heinous). > I agree... a productionized version in the base distribution should lack > such oddities. The script should do: > SUCCESS=3D0 > FAILURE=3D1 > and be done with it. > Though, I've been sometimes known to follow the habits of C-programming a= nd > instead do: > EXIT_SUCCESS=3D0 > EXIT_FAILURE=3D1 > (real macros defined by system includes; though in C-land they aren't 0/1 > but rather 0/-1 IIRC) > I just found it redundant to say: > exit $EXIT_SUCCESS > and shorter/more-succinct to say: > exit $SUCCESS Understood :). I try to avoid sysexits just because bde@ wasn't too happy in a review that I posted some C code in a review. ... > I borrow my argument-documentation style from 15+ years of perl programmi= ng. > I think it's all just personal preference. Personally, I like to jam it a= ll > one line specifically so that I can do a quick mark, then "?function.*nam= e" > to jump up to the definition-line, "yy" (for yank-yank; copies current li= ne > into buffer), then jump back to my mark, "p" for paste, then replace the > variables with what I intend to pass in for the particular call. > Using vi for years teaches interesting styles -- packing a list of keywor= ds > onto a single line to grab/paste elsewhere are just one of those little > things you learn. Understood. There really isn't any degree of shell style in FreeBSD, but it would be nice if there was.. ... > The first ": dependency checks ..." is just a note to myself. I used ":" > syntax to make it stand-out differently than the "#" syntax. Not to menti= on > that when I go through my scripts (well, the ones that are intended for > functioning within an embedded environment at least) I expect to see a ca= ll > to "depend()" before a) each/every function and b) each/every large > contiguous block of code (or at least the blocks that look like they are > good candidates for re-use in other scripts). > The second usage (": function") aids in finding the function declaration > among the usages. See, in Perl, I can simply search for "sub" preceding t= he > function name. In C, I tend to split the return type from the function na= me > and ensure that the function name always starts in column-1 so I can sear= ch > for "^funcname" to go to the declaration opposed to the usages/references= . > In BASH, `function' is a valid keyword and you can say "function funcname= ( > ) BLOCK" but unfortunately in good ol' bourne shell, "function" is not an > understood keyword, ... but really liking this keyword, I decided to make > use of it in bourne shell by-way-of simply making it a > non-executed-expression (preceded it with ":" and terminated it with ";")= . Yeah, that's one of the nicer readability points that would be helpful in POSIX. Unfortunately none of the other shell code in FreeBSD [that I've seen] is written that way, so it would look kind of out of place. But I understand your reasoning... > > { > > =A0 =A0 =A0 =A0local fd=3D$1 > > =A0 =A0 =A0 =A0[ $# -gt 1 ] || return ${FAILURE-1} > > While working at IronPort, Doug (my tech lead) has convinced me that > constructs like: > > if [ $# -le 1 ] > then > =A0=A0=A0return ${FAILURE-1} > fi > > Never did understand why folks insisted on splitting the if/then syntax (= or > while/do or for/do etc.) into multiple lines. I've always found that putt= ing > the semi-colon in there made it easier to read. Well, I [personally] prefer the semi-colon, but I can see merits with the other format because spacing between the expressions, the semi-colon, etc is variable, so code gets inconsistent over time (looking back I've noticed that even my code has become inconsistent in that manner). Either way can easily be searched and extracted via sed or awk. > Are a little more consistent and easier to follow than: > > [ $# -gt 1 ] || return ${FAILURE-1} > > Because some folks have a tendency to chain shell expressions, i.e. > > I agree with you that any-more than one is excessive. > I've often tried to emulate the C-expression "bool ? if-true : else" usin= g: > ( bool && if-true ) || else > but it's just not clean-looking. > I still like the simple-elegance of "expr || if-false" and "expr && if-tr= ue" > ... but-again, only perhaps since my first-love is Perl (of which I've > programmed 15+ years), and statements like that are rampant in Perl perha= ps > because the ol' Perl cookbooks of historical right advocate their usage i= n > such a manner. I know. Perl was my first language after C, but that was only 4 years ago, and I only used it extensively for a year or so. > Ah, coolness. command(1) is new to me just now ^_^ Yeah.. I was looking for something 100% portable after I ran into issues with writing scripts for Solaris :). ... > I originally had been programming in tests for '!' and 'in', but in POSIX > bourne-shell, they aren't defined (though understood) in the keyword tabl= e > (so type(1) balks in bourne-shell while csh and bash do respond to '!' an= d > 'in' queries). > Since you've pointed out command(1)... I now have a way of checking '!'. > Though unfortunately, "command -v", like type(1), also does not like "in" > (in bourne-shell at least). Hmmm... interesting. > I never understood why people don't trust the tools they are using... > `[' is very very similar (if not identical) to test(1) $ md5 /bin/\[ /bin/test MD5 (/bin/[) =3D b4199bea7980ecac7af225af14ae555f MD5 (/bin/test) =3D b4199bea7980ecac7af225af14ae555f Looks the same to me :). On FreeBSD and Linux (and I'm sure other OSes), if done properly test(1) and [(1) should be hardlinks to the same file. > [ "..." ] is the same thing as [ -n "..." ] or test -n "..." > [ ! "..." ] is the same things as [ -z "..." ] or test -z "..." > I'll never understand why people have to throw an extra letter in there a= nd > then compare it to that letter. I ran into issues using ! on Solaris ksh recently (not using test), and I agree that your example below is more straightforward and readable than the other examples I've dealt with in the past. > If the variable expands to nothing, go ahead and let it. I've traced ever= y > possible expansion of variables when used in the following manner: > [ "$VAR" ] ... > and it never fails. If $VAR is anything but null, the entire expression w= ill > evaluate to true. > Again... coming from 15+ years of perl has made my eyes read the followin= g > block of code: > if [ "$the_network_is_enabled" ]; then > aloud in my head as "if the network is enabled, then ..." (not too far of= a > stretch)... which has a sort of quintessential humanized logic to it, don= 't > you think? > Now, contrast that with this block: > if [ "x$the_network_is_enabled" =3D x ]; then > (one might verbalize that in their head as "if x plus `the network is > enabled' is equal to x, then" ... which is more clear?) Yet, it's more complicated than that. I use the x because some versions are test(1) are more braindead than others and interpret the string as an option, not as an argument. I suppose the other way to ameliorate that though is to swap the static string and the value which needs to be expanded. But that's also counterintuitive if you read it out loud, and that's also against the recommendation of my college professor (when dealing with assignment and tests... but that's more of an artifact of beginning C than anything else). > Yet, if I don't leave out the implied "-n" or "-z", is it more acceptable= ? > For instance... > if [ -n "$the_network_is_enabled" ]; then > But that would require the reader (performing intonation in their heads a= s > they read the code) to innately _know_ that "-n" is "this is non-null" > (where "this" is the rvalue to the keyword). I wouldn't sweat it so much though. I just tested out the string with dashes and it passed all of the cases mentioned above (our version of test seems a bit less error prone than some of the others I've run across). ... > Wouldn't it be better to declare this outside of the loop (I'm not > sure how optimal it is to place it inside the loop)? > > I'm assuming you mean the "local d" statement. There's no restriction tha= t > says you have to put your variable declarations at the beginning of a blo= ck > (like in C -- even if only within a superficial block { in the middle of > nowhere } ... like that). Correct. My issue was just how a shell interpreter would act on the local declaration. I need to do more digging in that area to determine how our's works vs bash vs whatever. > Meanwhile, in Perl, it's quite a difference to scope it to the loop rathe= r > than the block. So, it all depends on whichever _looks_ nicer to you ^_^ Sure, and perl has the my keyword too :). > =3D( > I made the switch to using [ "..." ] (implied "-n") and [ ! "..." ] (impl= ied > "-z") long ago because they intonate in my head so-darned well ("!" becom= ing > "NOT" of course). No worries. We established above that this isn't an issue. > Ah, another oddity of my programming style. > I often experienced people ripping whole blocks or whole functions out of= my > scripts and re-using them in their own scripts... > So I adopted this coding practice where... whenever I anticipated people > doing this (usually I only anticipate people ripping whole functions), I > wanted the blocks of code to still be semi-functional. > So what you're seeing is that everytime I rely on the global "progname" > within a re-usable code construct (a function for example), I would use > special parameter-expansion syntaxes that allow a fall-back default value > that was sensible ($0 in this case). > So outside of functions within the script, you'll see: > $progname > -- the global is used explicitly without fallback (because people ripping > out a block in the main source should be smart enough to know to check th= e > globals section at the top) > meanwhile, in a function: > ${progname:-$0} > So that if they ripped said-function into their own code and neglected to > define progname, the fallback default would be $0 which is expanded by th= e > shell always to be the first word (words being separated by any character= of > $IFS) of the invocation line. Well, right... but if someone's taking the value out of context and you acted on the value in a different way, then really shouldn't be copy-pasting your code without understanding your intent :). > Too true... > I was being ULTRA pedantic in my embedded-environment testing. ^_^ > Taking measures to test with different shells even... sh, bash, csh, pdks= h, > zsh, etc. etc. etc. (glad to report that the script is ultra portable) Fair enough :). ... > I would probably just point someone to a shell manual, as available > options and behavior may change, and behavior shouldn't (but > potentially could) vary between versions of FreeBSD. > > I just checked "man 1 sh" on FreeBSD-8.1, and it did have copious > documentation on special expansion syntaxes. (beautiful!)... so you're > right, we could just point them at a sh(1) man-page. > I somehow had it ingrained in my mind that the sh(1) man-page was lacking > while the bash(1) info-tex pages were the only places to find documentati= on > on the special expansion syntaxes. I'm glad to see they are fully documen= ted > in FreeBSD these days (even back to 4.11 which I checked just now). Yeah. GNU likes infopages, but even those sometimes lack critical data (and that's one of the positive points for using FreeBSD). ... > IIRC I've run into issues doing something similar to this in the past, > so I broke up the local declarations on 2+ lines. > > I find that the issue is only when you do something funky where you need = to > know the return status after the assignment. `local' will always return w= ith > success, so if you need to test the error status after an assignment with > local, you'll never get it. In those cases, it's best to use local just t= o > define the variable and then assign in another step to which you can get = the > return error status of the command executed within. > For example: > local foo=3D"$( some command )" > if [ $? -ne 0 ]; then > ... > will never fire because local always returns true. > Meanwhile,... > local foo > foo=3D"$( some command )" > if [ $? -ne 0 ]; then > ... > will work as expected (if "some command" returns error status, then the > if-block will fire). I understand, along with this case: $ cat test_scoping #!/bin/sh foo() { for i in a b c d; do echo $i done } i=3D2 foo echo $i [gcooper@bayonetta /scratch/ltp/testcases/open_posix_testsuite/conformance/interfaces/aio_retu= rn]$ sh test_scoping a b c d d If someone didn't understand scoping in Bourne shell they would think that i is local to foo. My consideration was more over: local i=3D local j=3D $ sh test_local.sh $ cat test_local.sh #!/bin/sh foo() { local i=3Da # <- here local j=3Db # <- and there } foo echo $i $j But if it works with all cases you have tested, then by all means please us= e it. ... > I think you'll find (quite pleasantly) that if you intonate the lines... > "rc_conf_files [is non-null] OR return failure" > "varname [is non-null] OR return failure" > Sounds a lot better/cleaner than the intonation of the suggested > replacement: > "if x plus rc_conf_files expands to something that is not equal to x OR x > plus the expansion of varname is not x then return failure" > Not to mention that if the checking of additional arguments is required, = a > single new line of similar appearance is added... whereas if you wanted t= o > expand the suggested replacement to handle another argument, you'd have t= o > add another "-o" case to the "[ ... ]" block which causes the line to be > pushed further to the right, requiring something like one of the two > following solutions: > if [ "x$rc_conf_files" =3D x -o "x$varname" =3D x -o "x$third" =3D x ] > then > ... > or (slightly better) > if [ "x$rc_conf_files" =3D x -o \ > =A0=A0 =A0 "x$varname" =3D x -o \ > =A0=A0 =A0 "x$third" =3D x ] > then > ... > But then again... you're lacking something very importantant in both of > those that you don't get with the original syntax ([ "$blah" ] || return > ...)... clean diff outputs! and clean CVS differentials... and clean RCS.= .. > Let's say that the sanity checks need to be expanded to test yet-another > variable. In the original syntax, the diff would be one line: > + [ "$third" ] || return ${FAILURE-1} > Otherwise, the diff is uglier (in my humble opinion): > - if [ "x$rc_conf_files" =3D x -o "x$varname" =3D x ] > + if [ "x$rc_conf_files" =3D x -o "x$varname" =3D x -o "x$third" =3D x ] > Make sense? > I think looking at CVS diffs where only a single line is added to check a > new variable is much cleaner than a code-block which must be erased and > rewritten everytime the test is expanded. Yeah... perforce does a worse job in this department when it comes to merges and deletions :/. Got what you mean... > $ . /etc/defaults/rc.conf > $ echo $rc_conf_files > /etc/rc.conf /etc/rc.conf.local > $ grep -q foo /etc/rc.local > grep: /etc/rc.local: No such file or directory > > Good catch! I missed that ^_^ Np :). > Being pedantic, I would capitalize the P in permission to match > EACCES's output string. > > But, I actually copied the error verbatim from what the shell produces if > you actually try the command. > So... if you remove the check (if [ ! -w $file ] ... ... ...) and try the > script as non-root, you'll get exactly that error message (with lower-cas= e > 'p' on 'permission denied'). > It wouldn't make sense for my script to use upper-case 'P' unless the > bourne-shell is patched to do the same. > I'm simply fundamentally producing the same error message as the shell sa= fe > for one difference... I try to detect the error before running into it > simply so I can throw a spurious newline before the error... causing the > output to more accurately mimick what sysctl(8) produces in the same exac= t > case (the case where a non-root user with insufficient privileges tries t= o > modify an MIB). Give it a shot... > $ sysctl security.jail.set_hostname_allowed=3D1 > security.jail.set_hostname_allowed: 1 > sysctl: security.jail.set_hostname_allowed: Operation not permitted > If I don't test for lack of write permissions first, and throw the error = out > with a preceding new-line, the result would be: > $ sysrc foo=3Dbar > foo: barsysrc: cannot create /etc/rc.conf: permission denied > Rather than: > $sysrc foo=3Dbar > foo: bar > sysrc: cannot create /etc/rc.conf: permission denied I'm not sure which version you're using, but it looks like mine uses strerror(3): $ touch /etc/rc.conf touch: /etc/rc.conf: Permission denied $ > /etc/rc.conf cannot create /etc/rc.conf: Permission denied $ echo $SHELL /bin/sh $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: Thu Aug 19 22:50:36 PDT 2010 root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 *shrugs* ... > I'll investigate lockf, however I think it's one of those things that you > just live with (for example... what happens if two people issue a sysctl(= 8) > call at the exact same time ... whoever gets there last sets the effectiv= e > value). There's a difference though. Most of sysctl(9) is locked with mutexes of various flavors; this method however is lock-free. > You'll notice that I do all my work in memory... > If the buffer is empty, I don't write out the buffer. > Much in the way that if an in-line sed (with -i for example) will also ch= eck > the memory contents before writing out the changes. > Since error-checking is performed, there's no difference between doing th= is > on a temporary file (essentially the memory buffer is the temporary file = -- > safe for wierd scenarios where memory fails you -- but then you have bigg= er > problems than possibly wiping out your rc.conf file -- like perhaps > scribbling on the disk in new and wonderful ways during memory corruption= ). > Also, since the calculations are done in memory and the read-in is decide= dly > different than the write-out (read: not performed as a single command), i= f > two scripts operated simultaneously, here's what would happen: > script A reads rc.conf(5) > script B does the same > script A operates on in-memory buffer > script B does the same > script A writes out new rc.conf from modified memory buffer > script B does the same > whomever does the last write will have their contents preserved. The unlu= cky > first-writer will have his contents overwritten. > I do not believe the kernel will allow the two writes to intertwine even = if > firing at the exact same precise moment. I do believe that one will block > until the other finishes (we could verify this by looking at perhaps the > bourne-shell's '>' redirect operator to see if it flock's the file during > the redirect, which it may, or perhaps such things are at lower levels). Even then, my concern was more about the atomicity of the operation than anything else. If person A modifies the file, then person B modifies it simultaneously, and for whatever reason person B finishes before person A, and person A's changes are written out to disk, there's not much that can be done (otherwise we'd need a database, but then that's smelling a lot like Windows registries, and those are a bi^%& to recover, if at all possible). I care more about the corruption case because that's a problem if the contents written out to disk get partially written (script killed, process interrupted, out of disk space, etc), or worse, the results get interleaved from process A and process B :/. There are some tricks that can be employed with test(1) (-nt, -ot), but it's probably just easier to use lockf when writing out the file because you're in a critical section of the script. ... > ^_^ > Well, I see getopt is an external dependency (bad) while getopts appears = to > be a builtin. The only plus-side to getopt is that it allows for double-dashed arguments from what I've read (at least that was the Linux version), but I avoid it because its implementation varies. > I'll have a looksie and see, but I find the case statement to be very > readable as it is. But getopts does the shifting and junk for you and that's why I suggested it *shrug*... just like getopt vs optparse in python, but that's a different ball of wax. > No more confusing than sysctl(8) which does the same thing as I did (I wa= s > in-fact mimicking sysctl(8) in this behavior). ... well, the output is different depending on the context; example: $ sysctl dev.uhid.0.%parent=3Dblah sysctl: oid 'dev.uhid.0.%parent' is read only $ sysctl debug.minidump=3D0 debug.minidump: 1 sysctl: debug.minidump: Operation not permitted $ sudo sysctl debug.minidump=3D0 debug.minidump: 1 -> 0 So the messages vary, but it looks like I missed the newline with the eprintf call you made above in sysrc_set in my first pass, so I wouldn't worry about this comment. > Not a screw-up.... > Since what appears between $( ... ) (back-ticks too `...`) is read using > readline(3), any leading whitespace is ignored. > I'm using this technique to split the line because it was too long to be > accommodated-fully within an 80-character wide terminal window with > tab-width set to 8 (what nearly everybody defaults to these days). Ok, sounds good -- just a bit harder to scan with the eye initially. > =A0=A0=A0And now some more important questions: > > =A0=A0=A01. What if I do: sysrc PS1 :) (hint: variables inherited from th= e > shell really shouldn't end up in the output / be queried)? > > Great question... hadn't thought of that. > I could perhaps use a set(1) flag to clear the environment variables prio= r > to calling source_rc_confs. That seems to be a prudent thing to do (or if > not via set(1) built-in, via preening the list of current variables and > using unset built-in to kill them off in a for/in/do loop). Ok -- sounds good! ... > The `-n' is already covered (see usage). > I do agree `-a' is both warranted and highly useful (provides system > administrator a snapshot of what /etc/rc sees at boot after performing a > source_rc_confs -- great for either trouble-shooting boot problems or > taint-checking everything before a reboot). Oooh -- cool (I'll have to look closer next time for `-n' :)..)! -a is helpful, but could become a bit tricky, esp. when some rc.d scripts live in /usr/local/etc/rc.d (can they live elsewhere? I don't remember OTOH..) and don't necessarily have the same constraints as rc.conf does... maybe some markup would need to be added to the scripts or external metadata, to deal with configuration information. One thing that would be nice is mapping variables to humanized descriptions for the less understood values, but at that point it might be wise to point someone to a manpage for the service they're tweaking. > Well now.... > If you really want to support ALL those possibilities... I _did_ have a m= ore > complex routine which caught them all (each and every one), but it wasn't > quite as clean ^_^ > If you really want me to break out the nuclear reactor, I'll work it back= in > from one of the predecessors of this script which was 1,000+ lines of cod= e. > However, I found that the need to catch such esoteric conditions was > far-out-weighed by the need to simplify the script and make a cleaner > approach. > Yes, the rc.conf(5) scripts (whether we're talking about /etc/rc.conf, > /etc/rc.conf.local, or ones that are appended by the end-user) can be qui= te > complex beasts... > And we could see things like this... > foo=3Dbar; bar=3Dbaz; baz=3D123 > And the script would not be able to find the correct instance that needs = to > be replaced to get "bar" to be some new value. > My nuclear-physics-type script could handle those instances (using sed to > reach into the line and replace only the baz portion and retain the exist= ing > foo and baz declarations. > What would you prefer though? Something that is cleaner, more readable, > easier to digest, more efficient, and has fewer dependencies, or one that= is > more robust but may require a degree to digest? Fair enough :P; I would clearly advertise the limitations of the tool with so it doesn't turn into a kitchen sink utility like pkg_install and sysinstall have become :/.. otherwise people love to add features into pieces of code that shouldn't really have those features. Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 10 05:24:17 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9942E1065673 for ; Sun, 10 Oct 2010 05:24:17 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outp.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id E0C1E8FC08 for ; Sun, 10 Oct 2010 05:24:16 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o9A5OGlS014653 for ; Sat, 9 Oct 2010 22:24:16 -0700 X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 7A8812D601C for ; Sat, 9 Oct 2010 22:24:15 -0700 (PDT) Message-ID: <4CB14E2D.3070806@freebsd.org> Date: Sat, 09 Oct 2010 22:25:01 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <1286397912.27308.40.camel@localhost.localdomain> <51B4504F-5AA4-47C5-BF23-FA51DE5BC8C8@vicor.com> <238E0B24-AA12-4684-9651-84DA665BE893@vicor.com> In-Reply-To: <238E0B24-AA12-4684-9651-84DA665BE893@vicor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Subject: Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2010 05:24:17 -0000 Ah grasshoppers... /me wonders if anyone will get the full significance of that.. On 10/9/10 3:39 PM, Devin Teske wrote: > On Oct 9, 2010, at 1:25 PM, Garrett Cooper wrote: > > >> Why not just do... >> >> if [ "x$rc_conf_files" = x -o "x$varname" = x ] >> then >> return ${FAILURE-1} >> fi > I think you'll find (quite pleasantly) that if you intonate the lines... > > "rc_conf_files [is non-null] OR return failure" > "varname [is non-null] OR return failure" > > Sounds a lot better/cleaner than the intonation of the suggested replacement: > > "if x plus rc_conf_files expands to something that is not equal to x OR x plus the expansion of varname is not x then return failure" > For what it matters, I'v enever found the [ "x$foo" = "x" ] construct to be useful. the quoting seems to work for everything I've ever worked on. so "officially" I'd express it as: if [ -n "$rc_conf_files" -o -n "$varname" ] but if I were hacking I'd probably express it as if [ "$rc_conf_files" != "" ] || [ "$varname" != "" ] then ..... I also sometimes find the use of the (()) operator to be useful. Now One thing that should be bourne in mind (heh) is that as there is a 'usual' form of format for perl there is one for sh as well so it's not "polite" to make one's sh code look like perl. :-) From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 10 05:31:21 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 804491065673 for ; Sun, 10 Oct 2010 05:31:21 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outp.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id 5C5E68FC18 for ; Sun, 10 Oct 2010 05:31:21 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o9A5VKlJ014740; Sat, 9 Oct 2010 22:31:20 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 804CA2D6015; Sat, 9 Oct 2010 22:31:19 -0700 (PDT) Message-ID: <4CB14FD5.9090505@freebsd.org> Date: Sat, 09 Oct 2010 22:32:05 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Garrett Cooper References: <1286397912.27308.40.camel@localhost.localdomain> <51B4504F-5AA4-47C5-BF23-FA51DE5BC8C8@vicor.com> <238E0B24-AA12-4684-9651-84DA665BE893@vicor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Brandon Gooch , freebsd-hackers@freebsd.org, Devin Teske Subject: Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2010 05:31:21 -0000 On 10/9/10 7:30 PM, Garrett Cooper wrote: > >> [ "..." ] is the same thing as [ -n "..." ] or test -n "..." >> [ ! "..." ] is the same things as [ -z "..." ] or test -z "..." >> I'll never understand why people have to throw an extra letter in there and >> then compare it to that letter. > I ran into issues using ! on Solaris ksh recently (not using test), > and I agree that your example below is more straightforward and > readable than the other examples I've dealt with in the past. Ah that reminds me for the reason for "X$foo" = "X" it's in case $foo evaluates to "-n" or similar... It's been a long time... but these days a data misevaluation leads to such things ad SQL injection attacks and I see no reason that a shell injection attack shouldn't be possible. From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 10 07:13:26 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CA211065670; Sun, 10 Oct 2010 07:13:26 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id F15188FC15; Sun, 10 Oct 2010 07:13:25 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1P4pq3-000CSR-QS; Sun, 10 Oct 2010 08:56:55 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Julian Elischer In-reply-to: <4CB14FD5.9090505@freebsd.org> References: <1286397912.27308.40.camel@localhost.localdomain> <51B4504F-5AA4-47C5-BF23-FA51DE5BC8C8@vicor.com> <238E0B24-AA12-4684-9651-84DA665BE893@vicor.com> <4CB14FD5.9090505@freebsd.org> Comments: In-reply-to Julian Elischer message dated "Sat, 09 Oct 2010 22:32:05 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Oct 2010 08:56:55 +0200 From: Daniel Braniss Message-ID: Cc: Brandon Gooch , freebsd-hackers@freebsd.org, Devin Teske , Garrett Cooper Subject: Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2010 07:13:26 -0000 > On 10/9/10 7:30 PM, Garrett Cooper wrote: > > > >> [ "..." ] is the same thing as [ -n "..." ] or test -n "..." > >> [ ! "..." ] is the same things as [ -z "..." ] or test -z "..." > >> I'll never understand why people have to throw an extra letter in there and > >> then compare it to that letter. > > I ran into issues using ! on Solaris ksh recently (not using test), > > and I agree that your example below is more straightforward and > > readable than the other examples I've dealt with in the past. > > > Ah that reminds me for the reason for "X$foo" = "X" but grasshopper, in Version 6 there was no test(1), hence the x$1 = x > > it's in case $foo evaluates to "-n" or similar... > > It's been a long time... but these days a data misevaluation leads to > such things ad SQL injection attacks > and I see no reason that a shell injection attack shouldn't be possible. From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 10 18:38:40 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D31921065670 for ; Sun, 10 Oct 2010 18:38:40 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp1.one.com (csmtp1.one.com [195.47.247.21]) by mx1.freebsd.org (Postfix) with ESMTP id 575108FC14 for ; Sun, 10 Oct 2010 18:38:40 +0000 (UTC) Received: from [192.168.10.202] (0x573b9942.cpe.ge-1-2-0-1101.ronqu1.customer.tele.dk [87.59.153.66]) by csmtp1.one.com (Postfix) with ESMTP id B5CB91BC00EE5 for ; Sun, 10 Oct 2010 18:38:38 +0000 (UTC) From: Erik Cederstrand Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-2077--808926872; protocol="application/pkcs7-signature"; micalg=sha1 Date: Sun, 10 Oct 2010 20:38:38 +0200 In-Reply-To: References: <52C32EA5-A380-4237-A27C-9E2DF2D4E022@cederstrand.dk> <20101005135906.GA3430@owl.midgard.homeip.net> <140AD250-ECD1-4BCF-806B-F5901B3BFD87@kientzle.com> Message-Id: <72C0D832-283B-4D81-89E8-7614B49DB8E7@cederstrand.dk> X-Mailer: Apple Mail (2.1081) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Hackers Subject: Re: Timestamps in static libraries X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2010 18:38:40 -0000 --Apple-Mail-2077--808926872 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Den 06/10/2010 kl. 14.35 skrev Erik Cederstrand: > Den 06/10/2010 kl. 13.07 skrev Erik Cederstrand: >=20 >> Is something like the following acceptable? Without risking changes = to buildworld/distribution just now, this would allow me to dump = contents of an archive and re-insert them with '0' for mtime, uid and = gid before checking checksums, without affecting normal ar behaviour. >=20 > Great, I didn't even see the discussion on this list recently: = http://lists.freebsd.org/pipermail/freebsd-hackers/2010-September/033005.h= tml >=20 > Anyway, I added file mode to the patch. Apparently recent binutils = also added this feature. I haven't looked at their patch, but chance has = it I used the same option '-D'. >=20 > I'm sure the file mode I'm setting in line 175 of write.c is wrong = (obj->md =3D 100644), but I couldn't quite figure out how to set the = value to rw-r--r--. Here's the new patch: >=20 > Index: ar.1 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- ar.1 (revision 213478) > +++ ar.1 (working copy) > @@ -62,6 +62,7 @@ > .Op Fl a Ar position-after > .Op Fl b Ar position-before > .Op Fl c > +.Op Fl D > .Op Fl i Ar position-before > .Op Fl j > .Op Fl s > @@ -179,6 +180,14 @@ > .Ar archive . > The archive's symbol table, if present, is updated to reflect > the new contents of the archive. > +.It Fl D > +When used in combination with the=20 > +.Fl r > +option, insterts 0's instead of the real mtime, uid and gid values=20 > +and 644 instead of file mode from the members named by arguments > +.Ar files ... . > +This ensures that checksums on the resulting archives are = reproducible > +when member contents are identical. > .It Fl f > Synonymous with option > .Fl T . > Index: ar.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- ar.c (revision 213478) > +++ ar.c (working copy) > @@ -154,7 +154,7 @@ > } > } >=20 > - while ((opt =3D getopt_long(argc, argv, = "abCcdfijlMmopqrSsTtuVvxz", > + while ((opt =3D getopt_long(argc, argv, = "abCcdDfijlMmopqrSsTtuVvxz", > longopts, NULL)) !=3D -1) { > switch(opt) { > case 'a': > @@ -173,6 +173,9 @@ > case 'd': > set_mode(bsdar, opt); > break; > + case 'D': > + bsdar->options |=3D AR_D; > + break; > case 'f': > case 'T': > bsdar->options |=3D AR_TR; > @@ -357,8 +360,8 @@ > (void)fprintf(stderr, "\tar -m [-Tabijsvz] position archive file = ...\n"); > (void)fprintf(stderr, "\tar -p [-Tv] archive [file ...]\n"); > (void)fprintf(stderr, "\tar -q [-Tcjsvz] archive file ...\n"); > - (void)fprintf(stderr, "\tar -r [-Tcjsuvz] archive file ...\n"); > - (void)fprintf(stderr, "\tar -r [-Tabcijsuvz] position archive = file ...\n"); > + (void)fprintf(stderr, "\tar -r [-TcDjsuvz] archive file ...\n"); > + (void)fprintf(stderr, "\tar -r [-TabcDijsuvz] position archive = file ...\n"); > (void)fprintf(stderr, "\tar -s [-jz] archive\n"); > (void)fprintf(stderr, "\tar -t [-Tv] archive [file ...]\n"); > (void)fprintf(stderr, "\tar -x [-CTouv] archive [file ...]\n"); > Index: ar.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- ar.h (revision 213478) > +++ ar.h (working copy) > @@ -43,6 +43,7 @@ > #define AR_U 0x0200 /* only extract or update newer = members.*/ > #define AR_V 0x0400 /* verbose mode */ > #define AR_Z 0x0800 /* gzip compression */ > +#define AR_D 0x1000 /* insert members with dummy mode, = mtime, uid and gid */ >=20 > #define DEF_BLKSZ 10240 /* default block size */ >=20 > Index: write.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- write.c (revision 213478) > +++ write.c (working copy) > @@ -163,11 +163,23 @@ > if (mtime !=3D 0 && bsdar->options & AR_U && sb.st_mtime <=3D = mtime) > goto giveup; >=20 > - obj->uid =3D sb.st_uid; > - obj->gid =3D sb.st_gid; > - obj->md =3D sb.st_mode; > + /* > + * When option '-D' is specified, mtime and UID / GID from the = file > + * will be replaced with 0, and file mode with 644. This ensures = that=20 > + * checksums will match for two archives containing the exact = same files. > + */ > + if (bsdar->options & AR_D) { > + obj->uid =3D 0; > + obj->gid =3D 0; > + obj->mtime =3D 0; > + obj->md =3D 100644; > + } else { > + obj->uid =3D sb.st_uid; > + obj->gid =3D sb.st_gid; > + obj->mtime =3D sb.st_mtime; > + obj->md =3D sb.st_mode; > + } > obj->size =3D sb.st_size; > - obj->mtime =3D sb.st_mtime; > obj->dev =3D sb.st_dev; > obj->ino =3D sb.st_ino; >=20 > @@ -621,7 +633,10 @@ > bsdar->options & AR_S) { > entry =3D archive_entry_new(); > archive_entry_copy_pathname(entry, "/"); > - archive_entry_set_mtime(entry, time(NULL), 0); > + if (bsdar->options & AR_O) > + archive_entry_set_mtime(entry, 0, 0); > + else > + archive_entry_set_mtime(entry, time(NULL), 0); > archive_entry_set_size(entry, (bsdar->s_cnt + 1) * > sizeof(uint32_t) + bsdar->s_sn_sz); > AC(archive_write_header(a, entry)); For the record, a correct version of this patch was applied in r213643. Erik= --Apple-Mail-2077--808926872-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 10 20:51:23 2010 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DBAE10656A9 for ; Sun, 10 Oct 2010 20:51:23 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp1.one.com (csmtp1.one.com [195.47.247.21]) by mx1.freebsd.org (Postfix) with ESMTP id 9409B8FC12 for ; Sun, 10 Oct 2010 20:51:22 +0000 (UTC) Received: from [192.168.10.202] (0x573b9942.cpe.ge-1-2-0-1101.ronqu1.customer.tele.dk [87.59.153.66]) by csmtp1.one.com (Postfix) with ESMTP id C9FA21BC00AF3 for ; Sun, 10 Oct 2010 20:51:20 +0000 (UTC) From: Erik Cederstrand Content-Type: multipart/signed; boundary=Apple-Mail-2086--800964699; protocol="application/pkcs7-signature"; micalg=sha1 Date: Sun, 10 Oct 2010 22:51:20 +0200 Message-Id: <718D8E86-EA2E-4D07-BAFF-5D8D093FD296@cederstrand.dk> To: FreeBSD Hackers Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Deterministic builds? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2010 20:51:23 -0000 --Apple-Mail-2086--800964699 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi hackers As a followup to the "Timestamps in static libraries" thread which = resulted in a '-D' option to ar(1), I'd like to discuss if it is a = worthy goal of the Project to create deterministic builds. By that I = mean for two make build+install world+kernel+distribution runs, every = contained file is bitwise identical between the two runs. Deterministic builds would be useful for me, since I'm creating binary = diffs against lots of FreeBSD builds, and smaller diffs are good. Also, = I'd like to detect which files have changed between two commits. I = imagine it would also be useful for things like IDS and freebsd-update. Currently, this does not hold for static libraries (*.a), kernel modules = (*.ko / *.ko.symbols) and the following: bthidd cc1 cc1obj cc1plus clang clang++ ctfconvert freebsd.cf freebsd.submit.cf kernel kernel.symbols libcrypto.so.6 libufs.so.5 loader pxeboot sendmail.cf submit.cf tblgen zfsloader Most of the libraries can be brought to be identical by using ar -D. = Some record the absolute OBJDIR path to header files, though (libc.a for = example). I tried adding 'D' to ARFLAGS in share/mk/sys.mk, but that's only part = of the solution. ARFLAGS are overridden hundreds of places in the source = code, and in some places ARFLAGS isn't even used (or AR for that = matter). Is it worthwhile to go through the whole tree, fixing up these = calls to ar? A lot of this is in contrib/ code. Another option is to add a WITH_DETERMINISTIC_AR knob to the build to = compile ar with D as default behaviour. This would make the above = changes unnecessary, but is more intrusive. A third option is that this is not a priority for the community, or = directly unwanted, and that I just post-process my builds myself. I don't know what causes the checksum difference in .ko files - there is = no size difference, and no difference according to strings(1). A bsdiff = on the two is typically around 160B. .ko.symbols have some unique identifiers or addresses internally. kernel, loader, zfsloader and pxeboot have a build date recorded, kernel = also has absolute path to GENERIC. OK for the kernel, I think, although = it would be easier for me if this was just stored in a separate file = since binary diffs on large files are expensive. clang, clang++ and tblgen store some absolute paths to .cpp files in the = src repo internally, plus unique identifiers. freebsd.cf, freebsd.submit.cf, sendmail.cf and submit.cf record the = absolute OBJDIR path to sendmail What do you think? Thanks, Erik= --Apple-Mail-2086--800964699-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 10 21:45:02 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ECC8106564A for ; Sun, 10 Oct 2010 21:45:02 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-5.mx.aerioconnect.net [216.240.47.65]) by mx1.freebsd.org (Postfix) with ESMTP id 841BD8FC16 for ; Sun, 10 Oct 2010 21:45:02 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o9ALLF5i001157 for ; Sun, 10 Oct 2010 14:21:15 -0700 X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id B58EC2D6014 for ; Sun, 10 Oct 2010 14:21:14 -0700 (PDT) Message-ID: <4CB22E79.2010202@freebsd.org> Date: Sun, 10 Oct 2010 14:22:01 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "hackers@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Subject: anyone got advice on sendmail and TLS on 8.1? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2010 21:45:02 -0000 When I last did sendmail there wasn't any TLS/SSL stuff. has anyone got an exact howto as to how to enable a simple sendmail server? all I want is: TLS and authenticated email submission by me and my family able to forward the email anywhere (maybe just to my ISP but who knows) (outgoing) non TLS submission from outside to reject all mail not to elischer.{org,com} and deliver our mail to mailboxes or gmail (or where-ever /etc/aliases says.). This is probably ALMOST a default configuration but I can't be sure what is needed.. there are several howtos on hte net but they are generally old and differ in details. Julian It's a simple enough request that he default sendmail install should probably do it.. probably no need to move to postfix or anything. From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 10 22:50:03 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D4C4106564A; Sun, 10 Oct 2010 22:50:03 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id 4C6188FC1A; Sun, 10 Oct 2010 22:50:03 +0000 (UTC) Received: from [173.241.24.124] (port=63388 helo=[10.0.0.109]) by postoffice.vicor.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71) (envelope-from ) id 1P54i3-0001a0-V8; Sun, 10 Oct 2010 15:49:48 -0700 Mime-Version: 1.0 (Apple Message framework v1081) From: Devin Teske In-Reply-To: Date: Sun, 10 Oct 2010 15:49:39 -0700 Message-Id: <9BBDE5CB-F755-44DB-915A-1C90B9DE3482@vicor.com> References: <1286397912.27308.40.camel@localhost.localdomain> <51B4504F-5AA4-47C5-BF23-FA51DE5BC8C8@vicor.com> <238E0B24-AA12-4684-9651-84DA665BE893@vicor.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 237e7bf4ea8c74147048c29aed8d68a1 X-Scan-Host: postoffice.vicor.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Brandon Gooch , freebsd-hackers@freebsd.org, Devin Teske Subject: Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2010 22:50:03 -0000 Trimming further context... On Oct 9, 2010, at 7:30 PM, Garrett Cooper wrote: > Trimming out some context... >=20 > On Sat, Oct 9, 2010 at 3:39 PM, Devin Teske wrote: >>=20 >=20 > ... >=20 > Perhaps you meant env FAILURE=3D0 sysrc foo && reboot ? >=20 > $ cat failure.sh > #!/bin/sh > echo "FAILURE: $FAILURE" > $ FAILURE=3D0 && sh failure.sh > FAILURE: > $ env FAILURE=3D0 sh failure.sh > FAILURE: 0 Ah, beautiful. I'd been searching for a way to set an environment = variable prior to running a command in one-swift blow. I see env(1) is = handy for that. Though honestly, the reason it's not working for you is because FAILURE = has not been exported... $ while read LINE; do echo "$LINE" >> failure.sh; done =20 #!/bin/sh echo "FAILURE: $FAILURE" ^D ### nifty way to create a file ^_^ $ cat failure.sh #!/bin/sh echo "FAILURE: $FAILURE" ### Yup, that's what we wrote to it. $ unset FAILURE ### Let's start clean $ FAILURE=3D0 && sh failure.sh FAILURE:=20 ### No effect... (cause it's not exported yet) $ export FAILURE ### Should have an effect now, let's try $ FAILURE=3D0 && sh failure.sh FAILURE: 0 ### Success ... once it has been exported by name (with a value or not) = it is always exported $ FAILURE=3D1 && sh failure.sh FAILURE: 1 ### no need to re-export, once exported by-name, new assignments are = exported $ unset FAILURE ### Only way to get it to be unexported once exported $ FAILURE=3D0 && sh failure.sh FAILURE:=20 ### Assignment no longer exported to sub-shells So, I guess an alternative to the usage of env(1) would be: export FAILURE=3D0 && sh failure.sh Works as expected... $ unset FAILURE $ export FAILURE=3D0 && sh failure.sh FAILURE: 0 Hence why when adding environment-variable based tunables in ~/.bashrc, = it's best to use export (either after initial assignment or with = assignment specified on export line in-one-go) else the assignment won't = survive the script... Safe for four exceptions... 1. When the script itself executes the set(1) built-in with either `-a' = flag or `-o allexport' arguments 2. The parent shell does the above and does not execute the child as a = sub-shell but rather sources the child using the `.' built-in 3. The script itself has an invocation line resembling any of the = following: #!/bin/sh -a #!/bin/sh -o allexport #!/usr/bin/env sh -a #!/usr/bin/env sh -o allexport 4. The parent shell does the above and does not execute the child as a = sub-shell but rather sources the child using the `.' built-in. Which, in any of the above cases, simple assignment to a variable name = will cause it to be exported to all children/sub-shell environments. Works for example in a live-shell too... $ unset FAILURE # start from a clean slate $ FAILURE=3D0 && sh failure.sh=20 FAILURE:=20 # Success, we're not exporting on bare assignment $ set -a # Turn on allexport in the interactive shell $ FAILURE=3D0 && sh failure.sh=20 FAILURE: 0 # Success, we're exporting on bare-assignment due to allexport $ set +a # Turn off allexport in the interactive shell $ FAILURE=3D0 && sh failure.sh=20 FAILURE: 0 # It was still exported $ unset FAILURE # Let's unexport it $ FAILURE=3D0 && sh failure.sh=20 FAILURE:=20 # success, no longer exported automatically via allexport feature > Understood. There really isn't any degree of shell style in FreeBSD, > but it would be nice if there was.. I find that to be the case quite often when dealing with shell = scripting. I've been trying to bring a little style to the shell = scripting world these days ^_^ >> Ah, coolness. command(1) is new to me just now ^_^ >=20 > Yeah.. I was looking for something 100% portable after I ran into > issues with writing scripts for Solaris :). I went back to our legacy systems just now (FreeBSD-4.11) and tried = this... $ uname -spr FreeBSD 4.11-STABLE i386 $ /bin/sh -c "command -v '['" command: unknown option: -v Meanwhile: $ uname -spr FreeBSD 8.1-RELEASE-p1 amd64 $ /bin/sh -c "command -v '['" [ So it would appear that on FreeBSD at least, type(1) built-in is more = portable (this perhaps traces back to it's 4.4BSDLite roots). I was thinking ... perhaps another flag. But alas, -p was the only valid = option back then, which only causes a default PATH to be used rather = than an inherited one. > ... >=20 >> If the variable expands to nothing, go ahead and let it. I've traced = every >> possible expansion of variables when used in the following manner: >> [ "$VAR" ] ... >> and it never fails. If $VAR is anything but null, the entire = expression will >> evaluate to true. >> Again... coming from 15+ years of perl has made my eyes read the = following >> block of code: >> if [ "$the_network_is_enabled" ]; then >> aloud in my head as "if the network is enabled, then ..." (not too = far of a >> stretch)... which has a sort of quintessential humanized logic to it, = don't >> you think? >> Now, contrast that with this block: >> if [ "x$the_network_is_enabled" =3D x ]; then >> (one might verbalize that in their head as "if x plus `the network is >> enabled' is equal to x, then" ... which is more clear?) >=20 > Yet, it's more complicated than that. I use the x because some > versions are test(1) are more braindead than others and interpret the > string as an option, not as an argument. On legacy system: $ uname -spr FreeBSD 4.11-STABLE i386 $ /bin/sh -c '[ "-n" ] && echo true' true $ /bin/sh -c '[ "-e" ] && echo true' true $ /bin/sh -c '[ "-z" ] && echo true' true $ /bin/sh -c '[ "-r" ] && echo true' true $ /bin/sh -c '[ "-f" ] && echo true' true $ /bin/sh -c '[ "-s" ] && echo true' true Up-to-date is the same: $ uname -spr FreeBSD 8.1-RELEASE-p1 amd64 $ /bin/sh -c '[ "-n" ] && echo true' true $ /bin/sh -c '[ "-e" ] && echo true' true $ /bin/sh -c '[ "-z" ] && echo true' true $ /bin/sh -c '[ "-r" ] && echo true' true $ /bin/sh -c '[ "-f" ] && echo true' true $ /bin/sh -c '[ "-s" ] && echo true' true >> Meanwhile, in Perl, it's quite a difference to scope it to the loop = rather >> than the block. So, it all depends on whichever _looks_ nicer to you = ^_^ >=20 > Sure, and perl has the my keyword too :). and the `our' keyword too ^_^ > Well, right... but if someone's taking the value out of context and > you acted on the value in a different way, then really shouldn't be > copy-pasting your code without understanding your intent :). Indeed. Is it weird to have "code that is itself considerate and/or = kind" in that respect? lol >> Being pedantic, I would capitalize the P in permission to match >> EACCES's output string. >>=20 >> But, I actually copied the error verbatim from what the shell = produces if >> you actually try the command. >> So... if you remove the check (if [ ! -w $file ] ... ... ...) and try = the >> script as non-root, you'll get exactly that error message (with = lower-case >> 'p' on 'permission denied'). >> It wouldn't make sense for my script to use upper-case 'P' unless the >> bourne-shell is patched to do the same. >> I'm simply fundamentally producing the same error message as the = shell safe >> for one difference... I try to detect the error before running into = it >> simply so I can throw a spurious newline before the error... causing = the >> output to more accurately mimick what sysctl(8) produces in the same = exact >> case (the case where a non-root user with insufficient privileges = tries to >> modify an MIB). Give it a shot... >> $ sysctl security.jail.set_hostname_allowed=3D1 >> security.jail.set_hostname_allowed: 1 >> sysctl: security.jail.set_hostname_allowed: Operation not permitted >> If I don't test for lack of write permissions first, and throw the = error out >> with a preceding new-line, the result would be: >> $ sysrc foo=3Dbar >> foo: barsysrc: cannot create /etc/rc.conf: permission denied >> Rather than: >> $sysrc foo=3Dbar >> foo: bar >> sysrc: cannot create /etc/rc.conf: permission denied >=20 > I'm not sure which version you're using, but it looks like mine uses > strerror(3): >=20 > $ touch /etc/rc.conf > touch: /etc/rc.conf: Permission denied > $ > /etc/rc.conf > cannot create /etc/rc.conf: Permission denied > $ echo $SHELL > /bin/sh > $ uname -a > FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: > Thu Aug 19 22:50:36 PDT 2010 > root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 >=20 > *shrugs* >=20 > ... Oops! I intended to copy the message verbatim, but typo'd in the = translation from one terminal to the next -- one of the cases where = copy/paste could have been my friend. (realized this as I tried the same = commands over again and got capital 'P' -- thanks) >> I'll investigate lockf, however I think it's one of those things that = you >> just live with (for example... what happens if two people issue a = sysctl(8) >> call at the exact same time ... whoever gets there last sets the = effective >> value). >=20 > There's a difference though. Most of sysctl(9) is locked with mutexes > of various flavors; this method however is lock-free. >=20 >> You'll notice that I do all my work in memory... >> If the buffer is empty, I don't write out the buffer. >> Much in the way that if an in-line sed (with -i for example) will = also check >> the memory contents before writing out the changes. >> Since error-checking is performed, there's no difference between = doing this >> on a temporary file (essentially the memory buffer is the temporary = file -- >> safe for wierd scenarios where memory fails you -- but then you have = bigger >> problems than possibly wiping out your rc.conf file -- like perhaps >> scribbling on the disk in new and wonderful ways during memory = corruption). >> Also, since the calculations are done in memory and the read-in is = decidedly >> different than the write-out (read: not performed as a single = command), if >> two scripts operated simultaneously, here's what would happen: >> script A reads rc.conf(5) >> script B does the same >> script A operates on in-memory buffer >> script B does the same >> script A writes out new rc.conf from modified memory buffer >> script B does the same >> whomever does the last write will have their contents preserved. The = unlucky >> first-writer will have his contents overwritten. >> I do not believe the kernel will allow the two writes to intertwine = even if >> firing at the exact same precise moment. I do believe that one will = block >> until the other finishes (we could verify this by looking at perhaps = the >> bourne-shell's '>' redirect operator to see if it flock's the file = during >> the redirect, which it may, or perhaps such things are at lower = levels). >=20 > Even then, my concern was more about the atomicity of the operation > than anything else. If person A modifies the file, then person B > modifies it simultaneously, and for whatever reason person B finishes > before person A, and person A's changes are written out to disk, > there's not much that can be done (otherwise we'd need a database, but > then that's smelling a lot like Windows registries, and those are a > bi^%& to recover, if at all possible). >=20 > I care more about the corruption case because that's a problem if the > contents written out to disk get partially written (script killed, > process interrupted, out of disk space, etc), or worse, the results > get interleaved from process A and process B :/. >=20 > There are some tricks that can be employed with test(1) (-nt, -ot), > but it's probably just easier to use lockf when writing out the file > because you're in a critical section of the script. >=20 Hmmm, sysctl(9) is lock-free, which might imply that both sysctl(8) and = sysctl(3) are also lock-free, and proposed sysrc(8) is lock-free, so = might that imply that the atomicity tests would fare the same for all of = the above? Here's what I'm thinking we should do to solve this... Since the atomicity of the write operation is anything-but singular = (meaning, it takes incrementally larger blocks of time to write larger = amounts of data, increasing the risk-curve for failure to occur by two = operations coinciding at the same time -- I'm truly sorry, my wife has = me helping her with her business statistics II course, forgive me, I'll = clarify). We make all our writes to a single temporary file (say, /etc/rc.conf.$$) = and then rely on the much more atomic action of replacing the existing = file with a move operation. For example: Instead of this: [ "$new_contents" ] && echo "$new_contents" > $file Do this: if [ "$new_contents" ]; then echo "$new_contents" > $file.$$ mv -f $file.$$ $file fi The effective difference is that if two different instances of the same = script, firing at the same precise moment, will avert writing to the = same file at the same time, and the only point of common interest would = be the final mv(1) command -- which I theorize the kernel would protect = the filesystem inode structure when two programs try to move two = different files into the same space). Testing this in realtime would be an educational challenge/exercise. = Though just at a glance (doing the steps slowly)... watch the inodes... # First, make our sandbox to play in $ sudo mkdir -p /sandbox/etc $ sudo touch /sandbox/etc/rc.conf # Next, show a reliable way to simulate the script's usage of $$ $ sudo /bin/sh -c 'echo "$$"' 87221 $ !! sudo /bin/sh -c 'echo "$$"' 87222 $ !! sudo /bin/sh -c 'echo "$$"' 87223 # The above works, "!!" re-runs the entire last-command entered and each # instance gets a different value for the pid-expansion of "$$" as we = expect # Next, simulate the script writing out to the temporary file chosen $ sudo /bin/sh -c 'echo 123 > /sandbox/etc/rc.conf.$$ && ls -li = /sandbox/etc/rc.conf.$$' 23602 -rw-r--r-- 1 root wheel 4 Oct 10 08:24 = /sandbox/etc/rc.conf.87236 # Do it again, same exact code $ !! sudo /bin/sh -c 'echo 123 > /sandbox/etc/rc.conf.$$ && ls -li = /sandbox/etc/rc.conf.$$' 23603 -rw-r--r-- 1 root wheel 4 Oct 10 08:24 = /sandbox/etc/rc.conf.87237 # What do we have at this snapshot-in-time? $ ls -li /sandbox/etc/* 23601 -rw-r--r-- 1 root wheel 0 Oct 10 08:20 /sandbox/etc/rc.conf 23602 -rw-r--r-- 1 root wheel 4 Oct 10 08:24 = /sandbox/etc/rc.conf.87236 23603 -rw-r--r-- 1 root wheel 4 Oct 10 08:24 = /sandbox/etc/rc.conf.87237 # An untouched rc.conf, and two temporary files # This snapshot is right before the mv command of each script # Let's see what a mv(1) does... $ sudo /bin/sh -c 'mv -f /sandbox/etc/rc.conf.87237 = /sandbox/etc/rc.conf' $ ls -li /sandbox/etc/* 23603 -rw-r--r-- 1 root wheel 4 Oct 10 08:24 /sandbox/etc/rc.conf 23602 -rw-r--r-- 1 root wheel 4 Oct 10 08:24 = /sandbox/etc/rc.conf.87236 # the 23601 inode ceases to exist and in its place # is the same filename pointing to the data at inode 23603. # Let's now do the same with the other hypothetical instance $ sudo /bin/sh -c 'mv -f /sandbox/etc/rc.conf.87236 = /sandbox/etc/rc.conf' $ ls -li /sandbox/etc/* 23602 -rw-r--r-- 1 root wheel 4 Oct 10 08:24 /sandbox/etc/rc.conf # again the original inode ceases and the directory entry is # updated with the newly desired inode So, the question really comes to be... What happens when mv(1) is called concurrently in the same exact moment? According to `/usr/src/bin/mv/mv.c', the do_move(const char *from, const = char *to) function ultimately relies on rename(2) (line 211, version = 1.51.2.2.2.1 RELENG_8). And according to rename(2): The rename() system call causes the link named `from' to be renamed as = `to'. [snip] The rename() system call guarantees that if `to' already = exists, an instance to `to' will always exist, even if the system should = crash in the middle of the operation. I think that sounds like our final solution... Recap: if [ "$new_contents" ]; then echo "$new_contents" > $file.$$ mv -f $file.$$ $file fi > ... >=20 >> The `-n' is already covered (see usage). >> I do agree `-a' is both warranted and highly useful (provides system >> administrator a snapshot of what /etc/rc sees at boot after = performing a >> source_rc_confs -- great for either trouble-shooting boot problems or >> taint-checking everything before a reboot). >=20 > Oooh -- cool (I'll have to look closer next time for `-n' :)..)! >=20 > -a is helpful, but could become a bit tricky, esp. Shouldn't be that hard. Here's how we can systematically clear the environment: for var in $( set | awk -F=3D '/^[[:alpha:]_][[:alnum:]_]*=3D/ {print $1}' ); do [ "$var" =3D "OPTIND" ] && continue unset $var done unset var For example: $ uname -spr FreeBSD 8.1-RELEASE i386 $ : start copy after semi-colon ;/bin/sh -c "# we're trailing; it's = ok... till we hit closing quote set | wc -l # approx. how many vars? for var in \$( set | awk -F=3D '/[[:alpha:]_][[:alnum:]_]*=3D/ {print \$1}' ); do [ \"\$var\" =3D "OPTIND" ] && continue echo unset \$var unset \$var done unset var set | /usr/bin/wc -l # how many things set now? notice PATH was unset set # show what's currently set"(end copy at quote to the left; paste = into shell) 24 unset BLOCKSIZE unset FOOBAR unset FTP_PASSIVE_MODE unset HOME unset IFS unset LOGNAME unset MAIL unset PATH unset PPID unset PS1 unset PS2 unset PS4 unset PWD unset SHELL unset SHLVL unset SSH_CLIENT unset SSH_CONNECTION unset SSH_TTY unset TERM unset USER unset _ 1 OPTIND=3D1 Note: The reason the first-result of "set | wc -l" produces 24 and we = only unset 22 variables is because IFS and FOOBAR evaluate to strings = with newlines in them. We prune-out variables that contain newlines because the awk is = instructed to only execute the "{print $1}" block when the line matches = the following: a. The line must be at least 2 characters long b. The first character must be an alphabetic character ([a-zA-Z]) or = underscore (_) c. After an indeterminate number of characters, which must be = alphanumeric ([a-zA-Z0-9]) or underscore (_), there must be an = equals-sign (=3D). That is all expressed in the awk regular expression = "/^[[:alpha:]_][[:alnum:]_]*=3D/". And, since awk is passed in a value of "=3D" to the `-F' operator, awk = splits the fields on "=3D", so when the "{print $1}" block is executed = (given only matching lines to the above regex), we get back a list of = variable names that can be passed to the `unset' built-in. Further, even if a variable had string contents that contained a newline = and then a line that matched the awk pattern, it wouldn't matter, = because: a. the intent is to clear the entire environment (within a subshell) = prior to calling source_rc_confs b. the awk pattern ensures that we're only going to pass valid = identifiers to `unset' c. it doesn't matter if you try to unset something that is already unset = (e.g., executing "unset nosuchvar" has no stderr output and returns with = success) I've crafted the regex pattern for awk based on what I think is the = complete valid structure of a variable in POSIX bourne shell ... and = tested it: $ /bin/sh -c 'export x=3D' # success (one-character, begins with letter) $ /bin/sh -c 'export _x=3D' # success (can begin with underscore) $ /bin/sh -c 'export 3x=3D' export: 3x: bad variable name # can't begin with number $ /bin/sh -c 'export _3x=3D' # success (but can contain number) $ /bin/sh -c 'export _3x-=3D' export: _3x-: bad variable name $ /bin/sh -c 'export -_3x=3D' export: unknown option: -_ $ /bin/sh -c 'export -- -_3x=3D' export: -_3x: bad variable name # the dash should not be valid anywhere/anyway $ uname -spr FreeBSD 8.1-RELEASE i386 NOTE: "FreeBSD 4.11-STABLE i386" gave exact same results. Last, but not least... Not sure why, but... $ uname -spr FreeBSD 4.11-STABLE i386 $ /bin/sh -c 'echo OPTIND: $OPTIND; unset OPTIND; echo failed' OPTIND: 1 unset: Illegal number:=20 $ uname -spr FreeBSD 8.1-RELEASE-p1 amd64 $ /bin/sh -c 'echo OPTIND: $OPTIND; unset OPTIND; echo failed' =20 OPTIND: 1 unset: Illegal number:=20 > when some rc.d > scripts live in /usr/local/etc/rc.d (can they live elsewhere? I don't > remember OTOH..) and don't necessarily have the same constraints as > rc.conf does... maybe some markup would need to be added to the > scripts or external metadata, to deal with configuration information. Nah... the purpose of sysrc(8) would be to print, munge, check, verify, = etc. what source_rc_confs sees at boot time -- so in-turn being a tool = to administer how those very rc.d scripts you speak of act at = boot-time...=20 Because most all of the rc.d scripts I've seen (in `/etc/rc.d', = `/usr/local/etc/rc.d', and any other directories that are configured in = the `local_startup' option within rc.conf(5)). Generally speaking though, things in these rc.d directories have two = formats: They either end in `.sh' or they don't. The ones that end in `.sh' are old-style and tend to ignore = `/etc/rc.subr'. The old-style scripts are passed in `start' at boot-time = and they often use case/esac to switch on the first positional argument = ($1). The ones that don't end in `.sh' are new-style and tend to source = `/etc/rc.subr'. New-style scripts are expected to adhere to rcorder(8) = markups placed in the script as strategic comments (preceded with `#') = (see rc(8) for even more info). The new-style functions are not passed a parameter at startup, rather = the ${start_cmd}() function is called by /etc/rc at boot-time when [ = "${name}_enable" =3D YES ] in rc.conf(5). These scripts are more sophisticated and more modular in that they rely = on shared-code in /etc/rc.subr But, in the end-run, the new-style scripts tend to all run = load_rc_config from /etc/rc.subr which ends up calling source_rc_confs = anyway (among other things -- such as sourcing = /etc/rc.conf.d/service_name, but we talked about sysrc(8) not having = context of the service_name that load_rc_conf() does, though we could = add some flag to cause sysrc(8) to emulate the startup of an rc.d script = by-name which would follow the same actions performed by load_rc_conf, = allowing the user of sysrc(8) to see additional values configured in = /etc/rc.conf.d/service_name given the additional context). >=20 > One thing that would be nice is mapping variables to humanized > descriptions for the less understood values, but at that point it > might be wise to point someone to a manpage for the service they're > tweaking. I think in a previous e-mail we talked about re-mapping `-d' from = dependency to be more like sysctl(8)'s `-d' which is akin to "describe". All we'd have to do is find the line in /etc/defaults/rc.conf and return = "cat /etc/defaults/rc.conf | grep "[[:space:]]*$var=3D" | tail -1 | sed = -e 's/.*#[[:space:]]\{1,\}//'" ... (finds last line that matches a = bare-assignment of the variable by-name, trimming up-to first '#' = including all additional white-space following first '#', retaining = what's left up to the end of the line). Admittedly, that's a poor-excuse of a parser, since it will miss = multi-line comments. A full-on sub-shell would be much better (but I'll = leave that for the final script which will hit the e-mail in another = thread). >=20 >> Well now.... >> If you really want to support ALL those possibilities... I _did_ have = a more >> complex routine which caught them all (each and every one), but it = wasn't >> quite as clean ^_^ >> If you really want me to break out the nuclear reactor, I'll work it = back in >> from one of the predecessors of this script which was 1,000+ lines of = code. >> However, I found that the need to catch such esoteric conditions was >> far-out-weighed by the need to simplify the script and make a cleaner >> approach. >> Yes, the rc.conf(5) scripts (whether we're talking about = /etc/rc.conf, >> /etc/rc.conf.local, or ones that are appended by the end-user) can be = quite >> complex beasts... >> And we could see things like this... >> foo=3Dbar; bar=3Dbaz; baz=3D123 >> And the script would not be able to find the correct instance that = needs to >> be replaced to get "bar" to be some new value. >> My nuclear-physics-type script could handle those instances (using = sed to >> reach into the line and replace only the baz portion and retain the = existing >> foo and baz declarations. >> What would you prefer though? Something that is cleaner, more = readable, >> easier to digest, more efficient, and has fewer dependencies, or one = that is >> more robust but may require a degree to digest? >=20 > Fair enough :P; I would clearly advertise the limitations of the > tool with so it doesn't turn into a kitchen sink utility like > pkg_install and sysinstall have become :/.. otherwise people love to > add features into pieces of code that shouldn't really have those > features. Right-on. In the man-page would definitely be the place to advertise the = limitations, such as: Warning! If you have variables in rc.conf(5) which rely on the shell's = interpretation of BLOCKs, then the modification of these variables will = fail (currently with version 1.0 of sysrc(8) posted to this list). This = includes BLOCKs of the form: "...", '...', {...}, (...), etc. where = newlines are traversed innately without the need for a preceding = back-slash before the EOL character. This is because the function that = finds the line to replace when performing modification uses readline(3) = (with the `-r' option), only the first line of the multi-line assignment = will be replaced. Ultimately because readline(3) has no understanding of = BLOCKs in the shell context and will stop reading at the EOL (note: = back-slash not an option because `-r' is used). For example, $ echo 'abc=3D123 > 456 > xyz' | ( read LINE; echo "$LINE" ) abc=3D123 The above shows that `read LINE' invoked only once, read only up to the = EOL (NOTE: we were able to embed the newline EOL character into the echo = argument by enabling the shell's usage of BLOCKs, in this case a '...' = block, which when we hit ENTER, the shell throws up a '> ' prompt asking = for more data, until the block is ended with an ending apostrophe ('). This is supposed to simulate something like this in rc.conf(5): multiline_var=3D"line 1 line 2 line 3" Where, currently, sysrc(8) will turn the above into the following (when, = for example, invoked as `sysrc multiline_var=3Dfoo'): multiline_var=3D"foo" line 2 line 3" The remnants remain (which is not what we want, we wanted to replace the = whole value, and the whole value includes lines 2 and 3, not to mention = the bad-syntax arising from the prematurely terminated quote). I could write a version that accounts for this, but it may be tricky (so = the warning in a man-page could suffice until then). Essentially, to solve this, we'll have to run tests on the line that was = read-in. Unfortunately, it gets hairy even with egrep! What you really = need is to fire-off a perl using the expert regex options like advanced = look-ahead "(?=3D>>regex)" craziness (if that's even a valid "advanced = look-ahead" regex, can't recall), to accurately detect a broken BLOCK, = because you get into REAL craziness with compound strings... = compound_str_var=3D"strexp"_'lit-strexp'_"'strexp-surrby-sgl-quot'"_'"lit-= strexp-w-dbl-quot"' That's four valid blocks, "...", '...', "...", '...' (note the last-two = are not special, they are the same as the first two, they just contain = characters to make you think they are special... the shell treats the = last two just as normal "..." and '...' blocks respectively). The expansion of that compound string turns out to be a single string = when expanded: strexp_lit-strexp_'strexp-surrby-sql-quot'_"lit-strexp-w-dbl-qot" If you did an `echo "$compound_str_var"' you'd actually get the above = output (single quotes in the third block and double-quotes in the fourth = block). And... for our script to know whether one of the blocks was broken = (which would cause the shell to keep reading to the next line without a = back-slash preceding the EOL) we'd need the awesome power of perl's = advanced look-ahead and look-behind regex in combination with variable = quantifiers. It's possible, but the solution, ... which indeed would be all-inclusive = and catch all possible logic (by-way of understanding the POSIX shell = line-interpreter at an awe-inspiring fundamental level)... would then be dependent upon something that is no-longer installed as = part of the base distribution ... Perl! So... alas... the answer is... We live with this fact and instead of trying to cow-tow to multi-line = variable-assignment syntax in rc.conf(5), we simplify the script to = handle all-but those cases which would require perl regex to handle ... = have that warning in the man-page about such beasts, ... and move on ^_^ = am I wrong? :D > Thanks! > -Garrett -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 10 23:09:58 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 206BC1065670; Sun, 10 Oct 2010 23:09:58 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id 0359F8FC25; Sun, 10 Oct 2010 23:09:57 +0000 (UTC) Received: from [173.241.24.124] (port=63437 helo=[10.0.0.109]) by postoffice.vicor.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71) (envelope-from ) id 1P551e-0001js-Qu; Sun, 10 Oct 2010 16:09:57 -0700 Mime-Version: 1.0 (Apple Message framework v1081) From: Devin Teske In-Reply-To: <4CB14E2D.3070806@freebsd.org> Date: Sun, 10 Oct 2010 16:09:54 -0700 Message-Id: <663E0B47-9318-4C75-BAEB-5C4F9EAFFDD1@vicor.com> References: <1286397912.27308.40.camel@localhost.localdomain> <51B4504F-5AA4-47C5-BF23-FA51DE5BC8C8@vicor.com> <238E0B24-AA12-4684-9651-84DA665BE893@vicor.com> <4CB14E2D.3070806@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 66bbd96c97311663deb3688a834fe54f X-Scan-Host: postoffice.vicor.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2010 23:09:58 -0000 On Oct 9, 2010, at 10:25 PM, Julian Elischer wrote: > Ah grasshoppers... >=20 > /me wonders if anyone will get the full significance of that.. >=20 >=20 > On 10/9/10 3:39 PM, Devin Teske wrote: >> On Oct 9, 2010, at 1:25 PM, Garrett Cooper wrote: >>=20 >>=20 >>> Why not just do... >>>=20 >>> if [ "x$rc_conf_files" =3D x -o "x$varname" =3D x ] >>> then >>> return ${FAILURE-1} >>> fi >> I think you'll find (quite pleasantly) that if you intonate the = lines... >>=20 >> "rc_conf_files [is non-null] OR return failure" >> "varname [is non-null] OR return failure" >>=20 >> Sounds a lot better/cleaner than the intonation of the suggested = replacement: >>=20 >> "if x plus rc_conf_files expands to something that is not equal = to x OR x plus the expansion of varname is not x then return failure" >>=20 >=20 >=20 > For what it matters, I'v enever found the [ "x$foo" =3D "x" ] = construct to be useful. > the quoting seems to work for everything I've ever worked on. I agree... I think that the "x" syntax came around for when people were = using non-quoted syntax... for example... [ x$foo =3D x ] is still very useful in that it prevents the error when $foo expands to = "-e". However, enclosing the argument (as the 'x$foo' portion is really just = the first argument to the '[' built-in) in quotes: [ "$foo" =3D x ] makes it so that the expansion is taken as: [ "-n" =3D x ] rather than: [ -n =3D x ] The former not causing an error, while the latter does. Quite functionally, at a C-level, if you have your array, ... argv[0] =3D "[\0"; argv[1] =3D "\"-n\"\0"; /* quoted syntax */ argv[2] =3D "=3D\0"; argv[3] =3D "x\0"; and argv[0] =3D "[\0"; argv[1] =3D "-n\0"; /* non-quoted syntax */ argv[2] =3D "=3D\0"; argv[3] =3D "x\0"; The C-code that switch'es on the argv element can tell the difference = between a leading quote and a leading dash and does indeed do the right = thing for all expansions of the variable within a double-quote block = ("..."). Though, the non-quoted syntax should be avoided at all costs, imho = unless you know for a fact that the expansion of the variable will never = include a character from $IFS (defaults to space, tab, newline). If it does, then it'll evaluate to a new positional argument for the = C-code. Take the following example: $ foo=3D"abc =3D abc" $ [ $foo ] && echo true true $ foo=3D"abc =3D 123" $ [ $foo ] && echo true # no output (not true) Whereas the quoted syntax: $ [ "$foo" ] will always evaluate to true because there is an implied "-n" operator = for the case where the first-and-last positional argument is a = double-quoted string, and... $ [ -n "$foo" ] always evaluates to true in the above cases for foo ("abc =3D abc" then = later "abc =3D 123"). > ... >=20 > Now One thing that should be bourne in mind (heh) is that > as there is a 'usual' form of format for perl there is one for sh as = well so it's not "polite" > to make one's sh code look like perl. :-) Perusing sh(1) today... found examples of the lazy operators: [ expr ] || expr [ expr ] && expr Search under "Short-Circuit List Operators" I'd say that the description therein is a green-light to treat sh like = perl ^_^ > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> FUN STUFF <- -----BEGIN GEEK CODE BLOCK----- Version 3.1 GAT/CS d(+) s: a- C++(++++) UB++++$ P++(++++) L++(++++) !E--- W++ N? o? = K- w O M+ V- PS+ PE Y+ PGP- t(+) 5? X+(++) R>++ tv(+) b+(++) DI+(++) D(+) G+>++ = e>+ h r>++ y+=20 ------END GEEK CODE BLOCK------ http://www.geekcode.com/ -> END TRANSMISSION <- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 00:15:56 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95FC6106564A for ; Mon, 11 Oct 2010 00:15:56 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 55EEF8FC15 for ; Mon, 11 Oct 2010 00:15:56 +0000 (UTC) Received: by iwn8 with SMTP id 8so3864465iwn.13 for ; Sun, 10 Oct 2010 17:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=U0m5Ix3vKGjH8ozf8/+QWT+2Grc8Ima+ifjBcm0wExA=; b=ZpGaY+zvfDM0ypez4tBPijXBJfWy0LL7Cw/IHstQQomurqS8Y6b0tQaKYp5p8sXgJS /V7vyjLWgWFgeKdpE930CGF9m4NKxJTemCrypZIP++GlfEK0g8am/K+pnZhCnSTSJFrK clQq5fE5sOA8nqMmIKiWMKf1C1RM4QqE0tUBA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Rit7OcbnDP7mt7Goa2X8cmWj9Gu45r3qyD9ivJSJFch1NGBrRp7E8ZfDijaMSk9vz2 lPpy8CU9p/d5cW7+YvO6ta66JGugQ0IcZJcr4gEP0VTcr45ulOARfNfeh0LEKkm4SAwu peL2Nc2zWcFgXS1dE/g3LS75AHCQMs32Tjq0w= MIME-Version: 1.0 Received: by 10.42.169.66 with SMTP id a2mr1617911icz.86.1286756155587; Sun, 10 Oct 2010 17:15:55 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Sun, 10 Oct 2010 17:15:55 -0700 (PDT) In-Reply-To: <9BBDE5CB-F755-44DB-915A-1C90B9DE3482@vicor.com> References: <1286397912.27308.40.camel@localhost.localdomain> <51B4504F-5AA4-47C5-BF23-FA51DE5BC8C8@vicor.com> <238E0B24-AA12-4684-9651-84DA665BE893@vicor.com> <9BBDE5CB-F755-44DB-915A-1C90B9DE3482@vicor.com> Date: Sun, 10 Oct 2010 17:15:55 -0700 X-Google-Sender-Auth: dQ-wDL1thuYgYPH4QX4Av0WSj7I Message-ID: From: Garrett Cooper To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 00:15:56 -0000 On Sun, Oct 10, 2010 at 3:49 PM, Devin Teske wrote: > Trimming further context... > On Oct 9, 2010, at 7:30 PM, Garrett Cooper wrote: ... > Perhaps you meant env FAILURE=0 sysrc foo && reboot ? > > $ cat failure.sh > #!/bin/sh > echo "FAILURE: $FAILURE" > $ FAILURE=0 && sh failure.sh > FAILURE: > $ env FAILURE=0 sh failure.sh > FAILURE: 0 > > Ah, beautiful. I'd been searching for a way to set an environment variable > prior to running a command in one-swift blow. I see env(1) is handy for > that. And the cool thing is that it works from other shells: $ export FOO=0; csh -c "env FOO=1 csh -c 'env | grep FOO'" FOO=1 That's why I prefer it in command line examples (it's deterministic). > Though honestly, the reason it's not working for you is because FAILURE has > not been exported... I didn't state it explicitly that way, but yes... that's what I was implying. ... > Hence why when adding environment-variable based tunables in ~/.bashrc, it's > best to use export (either after initial assignment or with assignment > specified on export line in-one-go) else the assignment won't survive the > script... Which makes sense because you're the developer, but does it make sense for production quality code, especially when users are better than developers at finding code flaws, i.e. doing the following: $ export FAILURE=a $ exit $FAILURE exit: Illegal number: a $ echo $? 2 Implementation in the shell may vary (again, this was /bin/sh). > Safe for four exceptions... > 1. When the script itself executes the set(1) built-in with either `-a' flag > or `-o allexport' arguments > 2. The parent shell does the above and does not execute the child as a > sub-shell but rather sources the child using the `.' built-in > 3. The script itself has an invocation line resembling any of the following: > #!/bin/sh -a > #!/bin/sh -o allexport > #!/usr/bin/env sh -a > #!/usr/bin/env sh -o allexport Hmm... forgot about that :D. > 4. The parent shell does the above and does not execute the child as a > sub-shell but rather sources the child using the `.' built-in. > Which, in any of the above cases, simple assignment to a variable name will > cause it to be exported to all children/sub-shell environments. > Works for example in a live-shell too... > $ unset FAILURE > # start from a clean slate > $ FAILURE=0 && sh failure.sh > FAILURE: > # Success, we're not exporting on bare assignment > $ set -a > # Turn on allexport in the interactive shell > $ FAILURE=0 && sh failure.sh > FAILURE: 0 > # Success, we're exporting on bare-assignment due to allexport > $ set +a > # Turn off allexport in the interactive shell > $ FAILURE=0 && sh failure.sh > FAILURE: 0 > # It was still exported > $ unset FAILURE > # Let's unexport it > $ FAILURE=0 && sh failure.sh > FAILURE: > # success, no longer exported automatically via allexport feature Part of the reason why I follow the set global once with empty values or defaults and declare locals given the chance and if I care. Otherwise there's too much wiggle room for surprises from the user's environment :). > Understood. There really isn't any degree of shell style in FreeBSD, > but it would be nice if there was.. > > I find that to be the case quite often when dealing with shell scripting. > I've been trying to bring a little style to the shell scripting world these > days ^_^ > > > Ah, coolness. command(1) is new to me just now ^_^ > > Yeah.. I was looking for something 100% portable after I ran into > issues with writing scripts for Solaris :). > > I went back to our legacy systems just now (FreeBSD-4.11) and tried this... > $ uname -spr > FreeBSD 4.11-STABLE i386 > $ /bin/sh -c "command -v '['" > command: unknown option: -v > Meanwhile: > $ uname -spr > FreeBSD 8.1-RELEASE-p1 amd64 > $ /bin/sh -c "command -v '['" > [ > So it would appear that on FreeBSD at least, type(1) built-in is more > portable (this perhaps traces back to it's 4.4BSDLite roots). > I was thinking ... perhaps another flag. But alas, -p was the only valid > option back then, which only causes a default PATH to be used rather than an > inherited one. Potentially. command(1) is just POSIX compatible, whereas type may be BSD compatible *shrugs*. ... > On legacy system: > $ uname -spr > FreeBSD 4.11-STABLE i386 > $ /bin/sh -c '[ "-n" ] && echo true' > true > $ /bin/sh -c '[ "-e" ] && echo true' > true > $ /bin/sh -c '[ "-z" ] && echo true' > true > $ /bin/sh -c '[ "-r" ] && echo true' > true > $ /bin/sh -c '[ "-f" ] && echo true' > true > $ /bin/sh -c '[ "-s" ] && echo true' > true > Up-to-date is the same: > $ uname -spr > FreeBSD 8.1-RELEASE-p1 amd64 > $ /bin/sh -c '[ "-n" ] && echo true' > true > $ /bin/sh -c '[ "-e" ] && echo true' > true > $ /bin/sh -c '[ "-z" ] && echo true' > true > $ /bin/sh -c '[ "-r" ] && echo true' > true > $ /bin/sh -c '[ "-f" ] && echo true' > true > $ /bin/sh -c '[ "-s" ] && echo true' > true Fair enough. My supposed knowledge and/or memory mislead me here :/. ... > and the `our' keyword too ^_^ Yeah, each with their own nuances... but my is closer to local than our is closer to local IIRC. > Indeed. Is it weird to have "code that is itself considerate and/or kind" in > that respect? lol Well... code is code. The developer should understand what's going on in the code before they copy-paste things at will, because they might omit certain bits and introduce bugs into their code if they have no clue what they're doing or don't understand the context that is required to use your code. ... > Oops! I intended to copy the message verbatim, but typo'd in the translation > from one terminal to the next -- one of the cases where copy/paste could > have been my friend. (realized this as I tried the same commands over again > and got capital 'P' -- thanks) NP. ... > Hmmm, sysctl(9) is lock-free, which might imply that both sysctl(8) and > sysctl(3) are also lock-free, and proposed sysrc(8) is lock-free, so might > that imply that the atomicity tests would fare the same for all of the > above? .../sys/kern/kern_sysctl.c says otherwise (look for the comment above the sysctllock declaration). The locking is just hidden from the developer/end-user. > Here's what I'm thinking we should do to solve this... > Since the atomicity of the write operation is anything-but singular > (meaning, it takes incrementally larger blocks of time to write larger > amounts of data, increasing the risk-curve for failure to occur by two > operations coinciding at the same time -- I'm truly sorry, my wife has me > helping her with her business statistics II course, forgive me, I'll > clarify). ... I think I said it before, but yes.. I completely agree with the atomicity approach. I prefer `mktemp /tmp/XXXXXX' because it would do nothing more than potentially clutter up /tmp if the operation fails for whatever reason (instead of /etc), and it's less of a security concern. I suppose that's less of a problem though, because if someone has the ability to write to /etc, then all bets are off, but the clutter part is a bit annoying.. ... > Shouldn't be that hard. Your approach seems reasonable. ... > Last, but not least... > Not sure why, but... > $ uname -spr > FreeBSD 4.11-STABLE i386 > $ /bin/sh -c 'echo OPTIND: $OPTIND; unset OPTIND; echo failed' > OPTIND: 1 > unset: Illegal number: > $ uname -spr > FreeBSD 8.1-RELEASE-p1 amd64 > $ /bin/sh -c 'echo OPTIND: $OPTIND; unset OPTIND; echo failed' > OPTIND: 1 > unset: Illegal number: Hmmm... that seems like a shell bug to me, in particular that it would always declare that value (esp when POSIX makes no mention of the variable being that way, and the manpage for sh doesn't mention that either). I'd have to ask jilles@ about that. $ sh -c 'echo OPTIND: $OPTIND; unset OPTIND' OPTIND: 1 unset: Illegal number: $ sh -c 'echo "OPTIND: $OPTIND"; unset OPTIND' OPTIND: 1 unset: Illegal number: $ bash -c 'echo "OPTIND: $OPTIND"; unset OPTIND' OPTIND: 1 $ env optind=1 bash -c 'echo "optind: $optind"; unset optind' optind: 1 ... > Nah... the purpose of sysrc(8) would be to print, munge, check, verify, etc. > what source_rc_confs sees at boot time -- so in-turn being a tool to > administer how those very rc.d scripts you speak of act at boot-time... > Because most all of the rc.d scripts I've seen (in `/etc/rc.d', > `/usr/local/etc/rc.d', and any other directories that are configured in the > `local_startup' option within rc.conf(5)). > Generally speaking though, things in these rc.d directories have two > formats: > They either end in `.sh' or they don't. > The ones that end in `.sh' are old-style and tend to ignore `/etc/rc.subr'. > The old-style scripts are passed in `start' at boot-time and they often use > case/esac to switch on the first positional argument ($1). > The ones that don't end in `.sh' are new-style and tend to source > `/etc/rc.subr'. New-style scripts are expected to adhere to rcorder(8) > markups placed in the script as strategic comments (preceded with `#') (see > rc(8) for even more info). > The new-style functions are not passed a parameter at startup, rather the > ${start_cmd}() function is called by /etc/rc at boot-time when [ > "${name}_enable" = YES ] in rc.conf(5). > These scripts are more sophisticated and more modular in that they rely on > shared-code in /etc/rc.subr > But, in the end-run, the new-style scripts tend to all run load_rc_config > from /etc/rc.subr which ends up calling source_rc_confs anyway (among other > things -- such as sourcing /etc/rc.conf.d/service_name, but we talked about > sysrc(8) not having context of the service_name that load_rc_conf() does, > though we could add some flag to cause sysrc(8) to emulate the startup of an > rc.d script by-name which would follow the same actions performed by > load_rc_conf, allowing the user of sysrc(8) to see additional values > configured in /etc/rc.conf.d/service_name given the additional context). Part of the reason why I brought it up was to serve an additional purpose as a means to configure a system for newbies (something randi@ asked me to look into a while back that kind of fizzled out due to lack of interest). > I think in a previous e-mail we talked about re-mapping `-d' from dependency > to be more like sysctl(8)'s `-d' which is akin to "describe". > All we'd have to do is find the line in /etc/defaults/rc.conf and return > "cat /etc/defaults/rc.conf | grep "[[:space:]]*$var=" | tail -1 | sed -e > 's/.*#[[:space:]]\{1,\}//'" ... (finds last line that matches a > bare-assignment of the variable by-name, trimming up-to first '#' including > all additional white-space following first '#', retaining what's left up to > the end of the line). > Admittedly, that's a poor-excuse of a parser, since it will miss multi-line > comments. A full-on sub-shell would be much better (but I'll leave that for > the final script which will hit the e-mail in another thread). Sounds reasonable (and I didn't realize that sysctl's -d option did that -- thanks!). ... I would just hold to this statement in /etc/defaults/rc.conf: # All arguments must be in double or single quotes. and also state: "this tool functions based on the idea that the rc.conf files are simply written, and can be evaluated as standalone configuration data. Anything that doesn't conform to these requirements isn't guaranteed to work with the tool in all cases" Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 00:23:07 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEF7B106564A; Mon, 11 Oct 2010 00:23:07 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id AF6A18FC13; Mon, 11 Oct 2010 00:23:07 +0000 (UTC) Received: from [173.241.24.124] (port=63474 helo=[10.0.0.109]) by postoffice.vicor.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71) (envelope-from ) id 1P56AS-0002Jn-Ml; Sun, 10 Oct 2010 17:23:07 -0700 Mime-Version: 1.0 (Apple Message framework v1081) From: Devin Teske In-Reply-To: <4CB25198.4020209@rpi.edu> Date: Sun, 10 Oct 2010 17:23:03 -0700 Message-Id: <4A1D95C2-10BB-43D1-99E0-A0D68D8836DC@vicor.com> References: <1286397912.27308.40.camel@localhost.localdomain> <51B4504F-5AA4-47C5-BF23-FA51DE5BC8C8@vicor.com> <238E0B24-AA12-4684-9651-84DA665BE893@vicor.com> <4CB14E2D.3070806@freebsd.org> <663E0B47-9318-4C75-BAEB-5C4F9EAFFDD1@vicor.com> <4CB25198.4020209@rpi.edu> To: Garance A Drosihn X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 5bc890c53f1cf23d4fe0f4a0c187a6c0 X-Scan-Host: postoffice.vicor.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 00:23:07 -0000 On Oct 10, 2010, at 4:51 PM, Garance A Drosihn wrote: > On 10/10/10 7:09 PM, Devin Teske wrote:=20 >> However, enclosing the argument (as the 'x$foo' portion is really = just the first argument to the '[' built-in) in quotes: >>=20 >> [ "$foo" =3D x ] >>=20 >> makes it so that the expansion is taken as: >>=20 >> [ "-n" =3D x ] >>=20 >> rather than: >>=20 >> [ -n =3D x ] >>=20 >> The former not causing an error, while the latter does. >> =20 > The latter does not cause an error. Try it: >=20 > # [ "-n" =3D x ] ; echo $? > 1 >=20 > # [ -e =3D "no" ] ; echo $? > 1 >=20 > # [ -e =3D -n ] ; echo $? > 1 Logical error, not functional error. >> Quite functionally, at a C-level, if you have your array, ... >>=20 >> argv[0] =3D "[\0"; >> argv[1] =3D "\"-n\"\0"; /* quoted syntax */ >> argv[2] =3D "=3D\0"; >> argv[3] =3D "x\0"; >>=20 >> and >>=20 >> argv[0] =3D "[\0"; >> argv[1] =3D "-n\0"; /* non-quoted syntax */ >> argv[2] =3D "=3D\0"; >> argv[3] =3D "x\0"; >>=20 >> =20 > You won't see the double-quotes in the C program. Correct, an external C programming will get the arguments just like a = shell script. > The shell processes single and double quotes, and passes the result = to the C program which is running. It might be different for built-in = functions, Indeed it is. > but /bin/test would never see the double-quotes if they were used. = And since the built-in function has to work the same as standalone = function There is no distinction between "built-in function" and "standalone = function". I think you mean "built-in" versus "external binary". The way that parameters are passed off to the internal parser is = different than the way arguments are passed to external executables. > , I doubt the built-in would be any different. >=20 > # list_args "-n" =20 >=20 > list_args at 19:36:15 Oct 10: $# =3D 1 > ARG[000] l=3D002: '-n' > # list_args -n >=20 > list_args at 19:36:22 Oct 10: $# =3D 1 > ARG[000] l=3D002: '-n' >=20 > (note that the single-quotes you see there are printed by the = list_args script itself for display purposes). >=20 > disclaimer: I think this is the first post that I've made with the new = "open-source edition" of Eudora, and I have no idea if this will be = formatted the way I'm expecting it be! >=20 > --=20 > Garance Alistair Drosehn =3D drosih@rpi.edu > Senior Systems Programmer or gad@FreeBSD.org > Rensselaer Polytechnic Institute; Troy, NY; USA >=20 -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> FUN STUFF <- -----BEGIN GEEK CODE BLOCK----- Version 3.1 GAT/CS d(+) s: a- C++(++++) UB++++$ P++(++++) L++(++++) !E--- W++ N? o? = K- w O M+ V- PS+ PE Y+ PGP- t(+) 5? X+(++) R>++ tv(+) b+(++) DI+(++) D(+) G+>++ = e>+ h r>++ y+=20 ------END GEEK CODE BLOCK------ http://www.geekcode.com/ -> END TRANSMISSION <- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 00:47:38 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC68B106566C; Mon, 11 Oct 2010 00:47:38 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id BE7F88FC08; Mon, 11 Oct 2010 00:47:38 +0000 (UTC) Received: from [166.205.138.131] (port=27426 helo=[10.83.175.23]) by postoffice.vicor.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71) (envelope-from ) id 1P56Xx-0002VV-58; Sun, 10 Oct 2010 17:47:24 -0700 References: <1286397912.27308.40.camel@localhost.localdomain> <51B4504F-5AA4-47C5-BF23-FA51DE5BC8C8@vicor.com> <238E0B24-AA12-4684-9651-84DA665BE893@vicor.com> <4CB14E2D.3070806@freebsd.org> <663E0B47-9318-4C75-BAEB-5C4F9EAFFDD1@vicor.com> <4CB25198.4020209@rpi.edu> In-Reply-To: <4CB25198.4020209@rpi.edu> Mime-Version: 1.0 (iPhone Mail 8B117) Message-Id: <12CA8898-95C0-465E-9560-F7184D126903@vicor.com> X-Mailer: iPhone Mail (8B117) From: Devin Teske Date: Sun, 10 Oct 2010 17:46:56 -0700 To: Garance A Drosihn X-Scan-Signature: b49d86c8d857f08b40b5e975f460ec84 X-Scan-Host: postoffice.vicor.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-hackers@freebsd.org" Subject: Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 00:47:38 -0000 On Oct 10, 2010, at 4:51 PM, Garance A Drosihn wrote: > The latter does not cause an error. Try it: > > # [ "-n" = x ] ; echo $? > 1 > > # [ -e = "no" ] ; echo $? > 1 > > # [ -e = -n ] ; echo $? > 1 1 is error. 0 is success. -- Devin From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 00:59:57 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B2141065673; Mon, 11 Oct 2010 00:59:57 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp5.server.rpi.edu (smtp5.server.rpi.edu [128.113.2.225]) by mx1.freebsd.org (Postfix) with ESMTP id 4D7118FC14; Mon, 11 Oct 2010 00:59:57 +0000 (UTC) Received: from gilead.netel.rpi.edu (gilead.netel.rpi.edu [128.113.124.121]) by smtp5.server.rpi.edu (8.13.1/8.13.1) with ESMTP id o9ANpqwI001556; Sun, 10 Oct 2010 19:51:53 -0400 Message-ID: <4CB25198.4020209@rpi.edu> Date: Sun, 10 Oct 2010 19:51:52 -0400 From: Garance A Drosihn User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Devin Teske References: <1286397912.27308.40.camel@localhost.localdomain> <51B4504F-5AA4-47C5-BF23-FA51DE5BC8C8@vicor.com> <238E0B24-AA12-4684-9651-84DA665BE893@vicor.com> <4CB14E2D.3070806@freebsd.org> <663E0B47-9318-4C75-BAEB-5C4F9EAFFDD1@vicor.com> In-Reply-To: <663E0B47-9318-4C75-BAEB-5C4F9EAFFDD1@vicor.com> X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 2.60 (**) [Hold at 15.00] HTML_MESSAGE, J_CHICKENPOX_13, J_CHICKENPOX_14, RATWARE_GECKO_BUILD, 22490(-25) X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.225 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 00:59:57 -0000 On 10/10/10 7:09 PM, Devin Teske wrote: > On Oct 9, 2010, at 10:25 PM, Julian Elischer wrote: > >> >> For what it matters, I'v enever found the [ "x$foo" = "x" ] construct to be useful. >> the quoting seems to work for everything I've ever worked on. >> There have been times where I had scripts which could get errors unless "x$foo" was used, but it's been more than 10 years since I last hit that situation. Of course, ever since I did hit it, I tend to write my 'test' parameters in ways which avoid the problem. It might have only been when checking if the variable was set to anything. Eg, using: if [ "$foo" ] ; then .... instead of: if [ -n "$foo" ] ; then ... Or it might have been when combining multiple checks in a single 'test' (using -a's, etc). However, I'm not going to try to dream up a pathological example of that right now. > I agree... I think that the "x" syntax came around for when people were using non-quoted syntax... for example... > > [ x$foo = x ] > > is still very useful in that it prevents the error when $foo expands to "-e". > The non-quoted example is dangerous in the case where $foo has multiple words in it. The "x" does not save you from that problem. I have a 'list_args' script which just lists out the parameters it is called with: # Test="this is a multi-word test" # list_args x$Test list_args at 19:22:27 Oct 10: $# = 5 ARG[000] l=005: 'xthis' ARG[001] l=002: 'is' ARG[002] l=001: 'a' ARG[003] l=010: 'multi-word' ARG[004] l=004: 'test' > However, enclosing the argument (as the 'x$foo' portion is really just the first argument to the '[' built-in) in quotes: > > [ "$foo" = x ] > > makes it so that the expansion is taken as: > > [ "-n" = x ] > > rather than: > > [ -n = x ] > > The former not causing an error, while the latter does. > The latter does not cause an error. Try it: # [ "-n" = x ] ; echo $? 1 # [ -e = "no" ] ; echo $? 1 # [ -e = -n ] ; echo $? 1 > Quite functionally, at a C-level, if you have your array, ... > > argv[0] = "[\0"; > argv[1] = "\"-n\"\0"; /* quoted syntax */ > argv[2] = "=\0"; > argv[3] = "x\0"; > > and > > argv[0] = "[\0"; > argv[1] = "-n\0"; /* non-quoted syntax */ > argv[2] = "=\0"; > argv[3] = "x\0"; > > You won't see the double-quotes in the C program. The shell processes single and double quotes, and passes the result to the C program which is running. It might be different for built-in functions, but /bin/test would never see the double-quotes if they were used. And since the built-in function has to work the same as standalone function, I doubt the built-in would be any different. # list_args "-n" list_args at 19:36:15 Oct 10: $# = 1 ARG[000] l=002: '-n' # list_args -n list_args at 19:36:22 Oct 10: $# = 1 ARG[000] l=002: '-n' (note that the single-quotes you see there are printed by the list_args script itself for display purposes). /disclaimer: I think this is the first post that I've made with the new "open-source edition" of Eudora, and I have no idea if this will be formatted the way I'm expecting it be!/ -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 01:03:10 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41AFC106564A for ; Mon, 11 Oct 2010 01:03:10 +0000 (UTC) (envelope-from eknath.iyer@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id CD1F48FC13 for ; Mon, 11 Oct 2010 01:03:09 +0000 (UTC) Received: by fxm12 with SMTP id 12so519606fxm.13 for ; Sun, 10 Oct 2010 18:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=77hwWAFJEzdHVdZUaxW6Qd3NdVqGarBVb7Mq/wPy19Q=; b=seRkx7irGRI7VRZ/0LOH1FVuYsq2n2tl6Q+P11NRV2IMaNzhndcL3nRSTvK6yPMz55 WRRALIStCTzecaYdIvczYZKFkIdXRw/aYMB5YI8aQm+dL3fbsRtjNtgGFXCVQkcIsMLI LHuboDh8VMIEyMWyoRum6C2Y/KjH88DujBXq4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=rhU2G1DhXDuh9aippNtOW3bJ5IZzL4cf2ryJf7Jxlzuz29dskErNHlhnBChEXkMSXd vXEob2g1apmoZVAy8tEzmHLrW06wSFPaMrXOZEFie7x0clmcWGL2+HLRYPfTkpBuGKqz PQPVAulR81HVlhkY9DfeofGmJokN2/JfSXvwU= MIME-Version: 1.0 Received: by 10.239.161.203 with SMTP id i11mr353242hbd.116.1286758988525; Sun, 10 Oct 2010 18:03:08 -0700 (PDT) Received: by 10.239.155.133 with HTTP; Sun, 10 Oct 2010 18:03:08 -0700 (PDT) Date: Sun, 10 Oct 2010 21:03:08 -0400 Message-ID: From: Eknath Venkataramani To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Run queue questions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 01:03:10 -0000 How would the scheduling overhead and the system performance be affected when the total number of run queues is reduced from 64 to 32? -- Eknath Venkataramani From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 03:36:36 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D77AB1065670 for ; Mon, 11 Oct 2010 03:36:36 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp8.server.rpi.edu (smtp8.server.rpi.edu [128.113.2.228]) by mx1.freebsd.org (Postfix) with ESMTP id 971048FC12 for ; Mon, 11 Oct 2010 03:36:36 +0000 (UTC) Received: from gilead.netel.rpi.edu (gilead.netel.rpi.edu [128.113.124.121]) by smtp8.server.rpi.edu (8.13.1/8.13.1) with ESMTP id o9B3aAHZ005844; Sun, 10 Oct 2010 23:36:10 -0400 Message-ID: <4CB2862A.1070207@rpi.edu> Date: Sun, 10 Oct 2010 23:36:10 -0400 From: Garance A Drosihn User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Devin Teske References: <1286397912.27308.40.camel@localhost.localdomain> <51B4504F-5AA4-47C5-BF23-FA51DE5BC8C8@vicor.com> <238E0B24-AA12-4684-9651-84DA665BE893@vicor.com> <4CB14E2D.3070806@freebsd.org> <663E0B47-9318-4C75-BAEB-5C4F9EAFFDD1@vicor.com> <4CB25198.4020209@rpi.edu> <12CA8898-95C0-465E-9560-F7184D126903@vicor.com> In-Reply-To: <12CA8898-95C0-465E-9560-F7184D126903@vicor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 1.40 (*) [Hold at 15.00] RATWARE_GECKO_BUILD,22490(-25) X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.228 Cc: "freebsd-hackers@freebsd.org" Subject: Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 03:36:36 -0000 On 10/10/10 8:46 PM, Devin Teske wrote: > On Oct 10, 2010, at 4:51 PM, Garance A Drosihn > wrote: > >> The latter does not cause an error. Try it: >> >> # [ "-n" = x ] ; echo $? >> 1 >> >> # [ -e = "no" ] ; echo $? >> 1 >> >> # [ -e = -n ] ; echo $? >> 1 > > 1 is error. 0 is success. > -- Um, yes, true. I know that. What I'm saying is that the command works as you'd want it to work. It does not hit a parsing error. The double-quotes did not change how the command behaved. You deleted the context of what I was replying to when I said the above. Looking at the examples I gave there, it probably would have been clearer if I had typed the exact same command with and without the double-quotes. Eg: On 10/10/10 7:09 PM, Devin Teske wrote: > However, enclosing the argument (as the 'x$foo' > portion is really just the first argument to the > '[' built-in) in quotes: > > [ "$foo" = x ] > > makes it so that the expansion is taken as: > > [ "-n" = x ] > > rather than: > > [ -n = x ] > > The former not causing an error, while the latter does. Your second example does not cause an error. Try it: # [ "-n" = "-n" ] ; echo $? 0 # [ "-n" = x ] ; echo $? 1 Compared to the double-quote-less: # [ -n = "-n" ] ; echo $? 0 # [ -n = x ] ; echo $? 1 -- Garance From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 04:17:29 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 621A1106564A; Mon, 11 Oct 2010 04:17:29 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id B8EF48FC19; Mon, 11 Oct 2010 04:17:28 +0000 (UTC) Received: by fxm12 with SMTP id 12so566611fxm.13 for ; Sun, 10 Oct 2010 21:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject :in-reply-to:references:user-agent:date:message-id:mime-version :content-type; bh=r0aLOjS0UXVx4+4EoXaAGGExTm1F3SHco3V1/jCosH0=; b=VH7BsFazsIPNagF0ESZauvOmqS1CG6E9vDjYFIXyvqp9Zz9SisseU2ytoLKb/PhYl/ NSijwmRCuOFW0Iq6U2f0PMxnE1wtyMFcA7A8vLjGQoIRg3lp0qaCb0XTWNI+s/BfLsov NGsmZlsGGRA9qF2kJNMDgw7LNG0DBuxgJn/ns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; b=YhNWFgyk+fL8jTBrgoR77PxKIbNDZRYab6C+EI9XAIyFgOJLWukOIRjs5l99SNDFmo /Qug3hstiMvQZzmPAeBrn0+CY40MK9UtbL5yzsOoEpxTvd5cWti8pqoCWaIl2Rajzw6W KvjG8Ocz8SPx25OH9MImSToJAWic96vrmgK+8= Received: by 10.223.114.19 with SMTP id c19mr1511889faq.29.1286768905027; Sun, 10 Oct 2010 20:48:25 -0700 (PDT) Received: from localhost ([85.17.254.135]) by mx.google.com with ESMTPS id d17sm1631789fav.29.2010.10.10.20.48.22 (version=SSLv3 cipher=RC4-MD5); Sun, 10 Oct 2010 20:48:23 -0700 (PDT) From: Anonymous To: Devin Teske In-Reply-To: <238E0B24-AA12-4684-9651-84DA665BE893@vicor.com> (Devin Teske's message of "Sat, 9 Oct 2010 15:39:44 -0700") References: <1286397912.27308.40.camel@localhost.localdomain> <51B4504F-5AA4-47C5-BF23-FA51DE5BC8C8@vicor.com> <238E0B24-AA12-4684-9651-84DA665BE893@vicor.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) Date: Mon, 11 Oct 2010 07:48:19 +0400 Message-ID: <86lj65ie4c.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Brandon Gooch , freebsd-hackers@freebsd.org, Garrett Cooper Subject: Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 04:17:29 -0000 Devin Teske writes: >>> ############################################################ GLOBALS >>> >>> # Global exit status variables >>> : ${SUCCESS:=0} >>> : ${FAILURE:=1} >> >> Should this really be set to something other than 0 or 1 by the >> end-user's environment? This would simplify a lot of return/exit >> calls... > > A scenario that I envision that almost never arises, but... > > Say someone wanted to call my script but wanted to mask it to always return with success (why? I dunno... it's conceivable though). > > Example: (this should be considered ugly -- because it is) > > FAILURE=0 && sysrc foo && reboot Wouldn't this bork functions used inside a conditional? : ${FAILURE:=1} foo() { return ${FAILURE-1}; } if ! foo; then echo good else echo error fi $ test.sh good $ FAILURE=0 test.sh error I think only sysrc_set() is affected, though. if sysrc_set "$NAME" "${1#*=}"; then echo " -> $( sysrc "$NAME" )" fi $ sysrc hostname=blah hostname: raphael.local sysrc: cannot create /etc/rc.conf: permission denied $ FAILURE=0 sh sysrc hostname=blah hostname: raphael.local sysrc: cannot create /etc/rc.conf: permission denied -> raphael.local From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 05:53:55 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEAB8106564A; Mon, 11 Oct 2010 05:53:55 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4D7178FC0A; Mon, 11 Oct 2010 05:53:54 +0000 (UTC) Received: by ywh2 with SMTP id 2so645085ywh.13 for ; Sun, 10 Oct 2010 22:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=IUyrSUBhhuwHNTvElWfvNuavSGrNc3E9PICqFb5MM5U=; b=Tss0xK6GB/V1bUXMDZfwCCclLMRItRI+51ulbstWqSg8NZq3jdkurE1NlDoCBaf4Xn Xmu3vXYhVphHqNAyiDDTmOriZYVDiRzJ2toD+8iYMyWCZgqE6rQvN43IJpY9rALdw1wN CN4ZJRBclfnO0TrBWym+/bAhlYL48xl7ebHIE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=GDPBrDyJ2Z4YMc3z7GnBAV6hTwYbwqpGq2193rTMxAj4eK1eFMP6Jdzdws1303/Ufq AsSgiIoEJqJ+hVuMViZ5315VeFlfgFsRXbYdDrw9gsM7RZzekuFX9671HoCB3H8ZCT1F c4t9Tx/qJqhb2T3ED+TJqBYYkNC85z+/cBMZs= MIME-Version: 1.0 Received: by 10.90.31.14 with SMTP id e14mr2819693age.21.1286776432357; Sun, 10 Oct 2010 22:53:52 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.91.78.6 with HTTP; Sun, 10 Oct 2010 22:53:51 -0700 (PDT) In-Reply-To: <20101007103601.GA17089@freebsd.org> References: <20101005235054.GA45827@freebsd.org> <20101006173522.GA92402@freebsd.org> <20101006193827.GA13528@freebsd.org> <20101007103601.GA17089@freebsd.org> Date: Sun, 10 Oct 2010 22:53:51 -0700 X-Google-Sender-Auth: W7bm_QN2yOH7nGsra0xnuGsj4nY Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Sergey Kandaurov Subject: Re: issue with unsetting 'arch' flag X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 05:53:55 -0000 On Thu, Oct 7, 2010 at 3:36 AM, Alexander Best wrote: > On Wed Oct =A06 10, Garrett Cooper wrote: >> On Wed, Oct 6, 2010 at 4:03 PM, Garrett Cooper wro= te: >> > On Wed, Oct 6, 2010 at 3:01 PM, Sergey Kandaurov w= rote: >> >> On 6 October 2010 23:38, Alexander Best wrote: >> >>> On Wed Oct =A06 10, Garrett Cooper wrote: >> >>>> On Wed, Oct 6, 2010 at 10:35 AM, Alexander Best wrote: >> >>>> > On Wed Oct =A06 10, Garrett Cooper wrote: >> >>>> >> On Tue, Oct 5, 2010 at 4:50 PM, Alexander Best wrote: >> >>>> >> > hi there, >> >>>> >> > >> >>>> >> > i think the following example shows the problem better than a = long explanation: >> >>>> >> > >> >>>> >> > `touch ftest && chflags arch ftest && chflags -vv 0 ftest`. >> >>>> >> > =A0^^non-root =A0 =A0 ^^root =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^= non-root >> >>>> >> > >> >>>> >> > chflags claims to have cleared the 'arch' flag (which should b= e impossible as >> >>>> >> > non-root user), but indeed has done nothing. >> >>>> >> > >> >>>> >> > i've tried the same with 'sappnd' and that works as can be exp= ected. >> >>>> >> > >> >>>> >> > The issue was confirmed to exist in HEAD (me), stable/8 (pgoll= ucc1, jpaetzel) >> >>>> >> > and stable/7 (nox). >> >>>> >> > On stable/6 it does NOT exist (jpaetzel). chflags properly fai= ls with EPERM. >> >>>> >> >> >>>> >> =A0 =A0 Fails for me when I call the syscall directly, as I woul= d expect, >> >>>> >> and passes when I'm superuser: >> >>>> >> >> >>>> >> $ ./test_chflags >> >>>> >> (uid, euid) =3D (1000, 1000) >> >>>> >> test_chflags: chflags: Operation not permitted >> >>>> >> test_chflags: lchflags: Operation not permitted >> >>>> >> $ sudo ./test_chflags >> >>>> >> (uid, euid) =3D (0, 0) >> >>>> >> >> >>>> >> =A0 =A0 According to my basic inspection in strtofflags >> >>>> >> (.../lib/libc/gen/strtofflags.c), it works as well. >> >>>> >> =A0 =A0 And last but not least, executing the commands directly = on the CLI work: >> >>>> >> >> >>>> >> $ tmpfile=3D`mktemp /tmp/chflags.XXXXXX` >> >>>> >> $ chflags arch $tmpfile >> >>>> >> chflags: /tmp/chflags.nQm1IL: Operation not permitted >> >>>> >> $ rm $tmpfile >> >>>> >> $ tmpfile=3D`mktemp /tmp/chflags.XXXXXX` >> >>>> >> $ sudo chflags arch $tmpfile >> >>>> >> $ sudo chflags noarch $tmpfile >> >>>> >> $ rm $tmpfile >> >>>> > >> >>>> > thanks for your test app and helping out with this problem. i'm n= ot sure >> >>>> > however you understood the problem. probably i didn't explain it = right: >> >>>> > >> >>>> > $ sudo rm -d /tmp/chflags.XXXXXX >> >>>> > $ tmpfile=3D`mktemp /tmp/chflags.XXXXXX` >> >>>> > $ sudo chflags arch $tmpfile >> >>>> > $ chflags noarch $tmpfile >> >>>> > >> >>>> > is what's causing the problem. the last chflags call should fail,= but it >> >>>> > doesn't. >> >>>> >> >>>> Sorry... my CLI based example was stupid. I meant: >> >>>> >> >>>> $ tmpfile=3D`mktemp /tmp/chflags.XXXXXX` >> >>>> $ chflags arch $tmpfile >> >>>> chflags: /tmp/chflags.V2NpXR: Operation not permitted >> >>>> $ chflags noarch $tmpfile >> >>>> $ rm $tmpfile >> >>>> >> >>>> Currently chflags(2) states: >> >>>> >> >>>> =A0 =A0 =A0The SF_IMMUTABLE, SF_APPEND, SF_NOUNLINK, and SF_ARCHIVE= D flags may only >> >>>> =A0 =A0 =A0be set or unset by the super-user. =A0Attempts to set th= ese flags by non- >> >>>> =A0 =A0 =A0super-users are rejected, >>> attempts by non-superusers= to clear >> >>>> flags that >> >>>> =A0 =A0 =A0are already unset are silently ignored. <<< =A0These fla= gs may be set at any >> >>>> =A0 =A0 =A0time, but normally may only be unset when the system is = in single-user >> >>>> =A0 =A0 =A0mode. =A0(See init(8) for details.) >> >>>> >> >>>> So this behavior is already well documented :). The EPERM section >> >>>> should really note SF_ARCHIVED though (whoever added the flag forgo= t >> >>>> to add that particular item to the ERRORS section). >> >>> >> >>> that's perfectly alright. clearing an unset flag shouldn't cause any= error to >> >>> be returned. however in my example arch *does* get set and still try= ing to >> >>> unset it as normal user doesn't return an error. >> >>> >> >> >> >> It's even more interesting. >> >> >> >> As far as I could parse the code: >> >> - UFS has no special handling for SF_ARCHIVED (I found only it for ms= dosfs) >> > >> > =A0 =A0_very_ interesting: >> > >> > [/sys]$ grep -r SF_ARCHIVED kern/ fs/ ufs/ | grep -v svn >> > fs/msdosfs/msdosfs_vnops.c: =A0 =A0 =A0 =A0 =A0 =A0 vap->va_flags |=3D= SF_ARCHIVED; >> > fs/msdosfs/msdosfs_vnops.c: =A0 =A0 =A0 =A0 =A0 =A0 if (vap->va_flags = & ~SF_ARCHIVED) >> > fs/msdosfs/msdosfs_vnops.c: =A0 =A0 =A0 =A0 =A0 =A0 if (vap->va_flags = & SF_ARCHIVED) >> > >> > =A0 =A0The commit that introduced this change probably wasn't doing th= e >> > right thing: http://svn.freebsd.org/viewvc/base/head/sys/fs/msdosfs/ms= dosfs_vnops.c?revision=3D5241&view=3Dmarkup >> > ; cp(1) probably should have been fixed in lieu of `fixing' msdosfs. >> > >> >> - ufs_setattr() does not handle unsetting SF_ARCHIVED, >> >> =A0so all what it does is simply return zero. >> > >> > =A0 =A0 [EOPNOTSUPP] =A0 =A0 =A0 The underlying file system does not s= upport file >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0flags. >> > >> > =A0 =A0So I would expect for invalid flags to return EOPNOTSUPP. >> > >> > ... >> > >> > $ ~/test_chflags_negative >> > test_chflags_negative: should not get here >> > $ sudo ~/test_chflags_negative >> > test_chflags_negative: should not get here >> > >> > *facepalm* >> > >> > =A0 =A0I think the problem in part is here (sys/stat.h): >> > >> > =A0* >> > =A0* Super-user and owner changeable flags. >> > =A0*/ >> > #define UF_SETTABLE =A0 =A0 0x0000ffff =A0 =A0 =A0/* mask of owner cha= ngeable flags */ >> > #define UF_NODUMP =A0 =A0 =A0 0x00000001 =A0 =A0 =A0/* do not dump fil= e */ >> > #define UF_IMMUTABLE =A0 =A00x00000002 =A0 =A0 =A0/* file may not be c= hanged */ >> > #define UF_APPEND =A0 =A0 =A0 0x00000004 =A0 =A0 =A0/* writes to file = may only append */ >> > #define UF_OPAQUE =A0 =A0 =A0 0x00000008 =A0 =A0 =A0/* directory is op= aque wrt. union */ >> > #define UF_NOUNLINK =A0 =A0 0x00000010 =A0 =A0 =A0/* file may not be r= emoved or renamed */ >> > /* >> > =A0* Super-user changeable flags. >> > =A0*/ >> > #define SF_SETTABLE =A0 =A0 0xffff0000 =A0 =A0 =A0/* mask of superuser= changeable flags */ >> > #define SF_ARCHIVED =A0 =A0 0x00010000 =A0 =A0 =A0/* file is archived = */ >> > #define SF_IMMUTABLE =A0 =A00x00020000 =A0 =A0 =A0/* file may not be c= hanged */ >> > #define SF_APPEND =A0 =A0 =A0 0x00040000 =A0 =A0 =A0/* writes to file = may only append */ >> > #define SF_NOUNLINK =A0 =A0 0x00100000 =A0 =A0 =A0/* file may not be r= emoved or renamed */ >> > #define SF_SNAPSHOT =A0 =A0 0x00200000 =A0 =A0 =A0/* snapshot inode */ >> > >> > =A0 =A0Note the *_SETTABLE macros, and the fact that they allow for mo= re >> > functionality than what's currently slotted with the one-hot encoded >> > flags currently available. >> > =A0 =A0SF_ARCHIVED is not present in the other BSDs or Mac OSX either = (I >> > did some hunting for a python bug related to chflags a few weeks >> > ago)... and I'm not even sure what this functionality really buys us >> > because it's not well described (but I'd be happy to get an >> > explanation/history lesson). >> > >> >> - /bin/chflags doesn't check the actual flags value from inode after >> >> calling chflags() syscall, and blindly assumes all is well, if chflag= s() >> >> returns with zero, >> > >> > =A0 =A0Yeah... but ideally tests should be written for this stuff and >> > exercised on all filesystems and exercised whenever code in this >> > particular path is changed, because that would potentially turn into a >> > noticeable performance hit [depending on how it's implemented in >> > chflags(1)]. And lo and behold it already does exist under >> > .../tools/regression/fstest/tests/chflags . I'll audit this once I get >> > back home... >> >> =A0 =A0 For starters, the tests were moved to .../tools/regression/pjdfs= test . >> =A0 =A0 This fixes the manpage and the negative flags testcase at least.= I >> ran the pjdfstest on a UFS2 partition on my test machine and tmpfs, >> and it passed chflags with flying colors. msdosfs unfortunately isn't >> supported yet, but I did some manual testing and everything seemed ok. >> I also need to check and see whether or not pjdfstest is doing the >> right job with negative testcases. >> =A0 =A0 I didn't have a ext2/3 or zfs pool to test with, so if someone >> could poke around with those filesystems it would be much appreciated >> :). >> =A0 =A0 And finally, here are all of the references in the sourcebase to >> SF_ARCHIVED: >> >> # /usr/local/bin/svnversion >> 213377M >> # grep -r SF_ARCHIVED /usr/src/ | grep -v svn >> grep: /usr/src/tools/regression/pjdfstest/pjdfstest_5aaec5b222b60945b16d= aa0e8d61313d/pjdfstest_b4353ca81458e0bfc9ec5be8ff741eb2/usr/src/tools/regre= ssion/priv/priv_vfs_chflags.c: =A0 =A0 flags >> |=3D SF_ARCHIVED; >> /usr/src/tools/regression/priv/priv_vfs_chflags.c: =A0 =A0flags |=3D SF_= ARCHIVED; >> /usr/src/tools/regression/priv/priv_vfs_chflags.c: =A0 =A0flags |=3D SF_= ARCHIVED; >> /usr/src/tools/regression/pjdfstest/tests/chflags/00.t: =A0 =A0 =A0 allf= lags=3D"UF_NODUMP,UF_IMMUTABLE,UF_APPEND,UF_NOUNLINK,UF_OPAQUE,SF_ARCHIVED,= SF_IMMUTABLE,SF_APPEND,SF_NOUNLINK" >> /usr/src/tools/regression/pjdfstest/tests/chflags/00.t: =A0 =A0 =A0 syst= emflags=3D"SF_ARCHIVED,SF_IMMUTABLE,SF_APPEND,SF_NOUNLINK" >> Binary file /usr/src/tools/regression/pjdfstest/pjdfstest matches >> /usr/src/tools/regression/pjdfstest/pjdfstest.c:#ifdef SF_ARCHIVED >> /usr/src/tools/regression/pjdfstest/pjdfstest.c: =A0 =A0 =A0{ SF_ARCHIVE= D, "SF_ARCHIVED" }, >> : Operation not supported >> grep: warning: /usr/src/sys/modules/tmpfs/@: recursive directory loop >> /usr/src/lib/libc/gen/strtofflags.c: =A0{ "noarch", =A0 =A0 =A0 =A0 =A0 = =A0 SF_ARCHIVED, =A0 =A00 }, >> /usr/src/lib/libc/gen/strtofflags.c: =A0{ "noarchived", =A0 =A0 =A0 =A0 = SF_ARCHIVED, =A0 =A00 }, >> /usr/src/lib/libc/sys/chflags.2:.It Dv SF_ARCHIVED >> /usr/src/lib/libc/sys/chflags.2:.Dv SF_ARCHIVED >> /usr/src/lib/libc/sys/chflags.2:.Dv SF_ARCHIVED , SF_IMMUTABLE , SF_APPE= ND , >> /usr/src/lib/libc/sys/chflags.2:.Dv SF_ARCHIVED , SF_IMMUTABLE , SF_APPE= ND , >> /usr/src/lib/libarchive/archive_entry.c:#ifdef SF_ARCHIVED >> /usr/src/lib/libarchive/archive_entry.c: =A0 =A0 =A0{ >> "noarch", =A0 =A0 L"noarch", =A0 =A0 =A0SF_ARCHIVED, =A0 =A00 }, >> /usr/src/lib/libarchive/archive_entry.c: =A0 =A0 =A0{ >> "noarchived", L"noarchived", =A0 =A0 =A0 =A0 =A0SF_ARCHIVED, =A0 =A00 }, >> /usr/src/sys/fs/msdosfs/msdosfs_vnops.c: =A0 =A0 =A0 =A0 =A0 =A0 =A0vap-= >va_flags |=3D SF_ARCHIVED; >> /usr/src/sys/fs/msdosfs/msdosfs_vnops.c: =A0 =A0 =A0 =A0 =A0 =A0 =A0if (= vap->va_flags & ~SF_ARCHIVED) >> /usr/src/sys/fs/msdosfs/msdosfs_vnops.c: =A0 =A0 =A0 =A0 =A0 =A0 =A0if (= vap->va_flags & SF_ARCHIVED) >> /usr/src/sys/sys/stat.h:#define =A0 =A0 =A0 SF_ARCHIVED =A0 =A0 0x000100= 00 =A0 =A0 =A0/* file is archived */ >> /usr/src/sys/sys/stat.h:#define =A0 =A0 =A0 SF_SETTABLE =A0 =A0 (SF_ARCH= IVED | >> SF_IMMUTABLE | SF_APPEND | \ >> >> =A0 =A0 So it doesn't look like anything's utilizing the functionality, >> other than msdosfs, and all that really does is tweak the following >> attribute: >> >> #define ATTR_ARCHIVE =A0 =A00x20 =A0 =A0 =A0 =A0 =A0 =A0/* file is new o= r modified */ >> >> =A0 =A0 and vice versa. I vaguely remember archive file types in FAT32 >> from the Win95 days, but my memory is a bit hazy as to what the >> attribute actually does. > > occasionally i get errors during file copies from msdosfs to ufs2. window= s > seems to use the arch flag quite extensively actually. i think formating = a new > drive automatically markes it as 'archivable' and all new files get their= flag > set. According to sbruno@: "It gets set when a file is written to. That's it. A backup program can backup files then clear the bit; later backups can use the state of the bit to determine if the file needs backing up again. And it dates from MS-DOS 2.x, and possibly even 1.x. During those times you couldn't exactly trust timestamps on files meant anything for backup purposes, as PCs didn't have a battery backed RTC as standard. http://en.wikipedia.org/wiki/Archive_bit" So it exists purely for msdosfs for that historic reason. > so when copying files from fat32 to ufs i very often get an EPERM error, > because as a non-root user that flag cannot be preserved. doesn't matter > however since the copying suceeds. good thing the chflags operation takes= place > after copying the file and not beforehand (i.e. touch, chflags, copy). Yeah... > also: what about sorting the flags (in the manual page e.g.). should they= be > sorted alphabetically or by bitfields? They're currently sorted by value (including the patch I attached earlier). > also: is SF_SNAPSHOT really changeable by the super user? chflags(2) says= it's > not. >From what I've seen, not directly. It's used widely in querying filesystems though. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 05:57:43 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9873106566B; Mon, 11 Oct 2010 05:57:43 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id 996288FC0A; Mon, 11 Oct 2010 05:57:43 +0000 (UTC) Received: from [173.241.24.124] (port=63526 helo=[10.0.0.109]) by postoffice.vicor.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71) (envelope-from ) id 1P5BOF-00057S-OI; Sun, 10 Oct 2010 22:57:42 -0700 Mime-Version: 1.0 (Apple Message framework v1081) From: Devin Teske In-Reply-To: Date: Sun, 10 Oct 2010 22:57:39 -0700 Message-Id: <6BB51EB3-E1F5-46FB-8C24-4351FAC320DA@vicor.com> References: <1286397912.27308.40.camel@localhost.localdomain> <51B4504F-5AA4-47C5-BF23-FA51DE5BC8C8@vicor.com> <238E0B24-AA12-4684-9651-84DA665BE893@vicor.com> <9BBDE5CB-F755-44DB-915A-1C90B9DE3482@vicor.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 3d0a3550f3d8caf302954fca505b0856 X-Scan-Host: postoffice.vicor.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 05:57:43 -0000 On Oct 10, 2010, at 5:15 PM, Garrett Cooper wrote: > On Sun, Oct 10, 2010 at 3:49 PM, Devin Teske wrote: >=20 >> Hmmm, sysctl(9) is lock-free, which might imply that both sysctl(8) = and >> sysctl(3) are also lock-free, and proposed sysrc(8) is lock-free, so = might >> that imply that the atomicity tests would fare the same for all of = the >> above? >=20 > .../sys/kern/kern_sysctl.c says otherwise (look for the comment above > the sysctllock declaration). The locking is just hidden from the > developer/end-user. >=20 >> Here's what I'm thinking we should do to solve this... >> Since the atomicity of the write operation is anything-but singular >> (meaning, it takes incrementally larger blocks of time to write = larger >> amounts of data, increasing the risk-curve for failure to occur by = two >> operations coinciding at the same time -- I'm truly sorry, my wife = has me >> helping her with her business statistics II course, forgive me, I'll >> clarify). >=20 > ... >=20 > I think I said it before, but yes.. I completely agree with the > atomicity approach. I prefer `mktemp /tmp/XXXXXX' because it would do > nothing more than potentially clutter up /tmp if the operation fails > for whatever reason (instead of /etc), and it's less of a security > concern. I suppose that's less of a problem though, because if someone > has the ability to write to /etc, then all bets are off, but the > clutter part is a bit annoying.. I checked out mktemp(1)... just what the doctor ordered for preventing = race-conditions. And it's in the base FreeBSD distribution even back as = far as FreeBSD-4.11 (likely much further; but that's what I checked). > ... >=20 > I would just hold to this statement in /etc/defaults/rc.conf: >=20 > # All arguments must be in double or single quotes. >=20 > and also state: >=20 > "this tool functions based on the idea that the rc.conf files are > simply written, and can be evaluated as standalone configuration data. > Anything that doesn't conform to these requirements isn't guaranteed > to work with the tool in all cases" Simpler is indeed better ^_^ >=20 > Thanks! > -Garrett > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> FUN STUFF <- -----BEGIN GEEK CODE BLOCK----- Version 3.1 GAT/CS d(+) s: a- C++(++++) UB++++$ P++(++++) L++(++++) !E--- W++ N? o? = K- w O M+ V- PS+ PE Y+ PGP- t(+) 5? X+(++) R>++ tv(+) b+(++) DI+(++) D(+) G+>++ = e>+ h r>++ y+=20 ------END GEEK CODE BLOCK------ http://www.geekcode.com/ -> END TRANSMISSION <- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 09:03:20 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D655106566B for ; Mon, 11 Oct 2010 09:03:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A61338FC12 for ; Mon, 11 Oct 2010 09:03:19 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o9B8lXc4016996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Oct 2010 11:47:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o9B8lXGb065261; Mon, 11 Oct 2010 11:47:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9B8lXrs065260; Mon, 11 Oct 2010 11:47:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 11 Oct 2010 11:47:33 +0300 From: Kostik Belousov To: Erik Cederstrand Message-ID: <20101011084733.GM2392@deviant.kiev.zoral.com.ua> References: <718D8E86-EA2E-4D07-BAFF-5D8D093FD296@cederstrand.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9CGWabQ8wCOOTGwI" Content-Disposition: inline In-Reply-To: <718D8E86-EA2E-4D07-BAFF-5D8D093FD296@cederstrand.dk> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Hackers Subject: Re: Deterministic builds? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 09:03:20 -0000 --9CGWabQ8wCOOTGwI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 10, 2010 at 10:51:20PM +0200, Erik Cederstrand wrote: > Hi hackers >=20 > As a followup to the "Timestamps in static libraries" thread which result= ed in a '-D' option to ar(1), I'd like to discuss if it is a worthy goal of= the Project to create deterministic builds. By that I mean for two make bu= ild+install world+kernel+distribution runs, every contained file is bitwise= identical between the two runs. >=20 > Deterministic builds would be useful for me, since I'm creating binary di= ffs against lots of FreeBSD builds, and smaller diffs are good. Also, I'd l= ike to detect which files have changed between two commits. I imagine it wo= uld also be useful for things like IDS and freebsd-update. >=20 > Currently, this does not hold for static libraries (*.a), kernel modules = (*.ko / *.ko.symbols) and the following: >=20 > bthidd > cc1 > cc1obj > cc1plus > clang > clang++ > ctfconvert > freebsd.cf > freebsd.submit.cf > kernel > kernel.symbols > libcrypto.so.6 > libufs.so.5 > loader > pxeboot > sendmail.cf > submit.cf > tblgen > zfsloader >=20 > Most of the libraries can be brought to be identical by using ar -D. Some= record the absolute OBJDIR path to header files, though (libc.a for exampl= e). >=20 > I tried adding 'D' to ARFLAGS in share/mk/sys.mk, but that's only part of= the solution. ARFLAGS are overridden hundreds of places in the source code= , and in some places ARFLAGS isn't even used (or AR for that matter). Is it= worthwhile to go through the whole tree, fixing up these calls to ar? A lo= t of this is in contrib/ code. >=20 > Another option is to add a WITH_DETERMINISTIC_AR knob to the build to com= pile ar with D as default behaviour. This would make the above changes unne= cessary, but is more intrusive. >=20 > A third option is that this is not a priority for the community, or direc= tly unwanted, and that I just post-process my builds myself. >=20 > I don't know what causes the checksum difference in .ko files - there is = no size difference, and no difference according to strings(1). A bsdiff on = the two is typically around 160B. >=20 > .ko.symbols have some unique identifiers or addresses internally. >=20 > kernel, loader, zfsloader and pxeboot have a build date recorded, kernel = also has absolute path to GENERIC. OK for the kernel, I think, although it = would be easier for me if this was just stored in a separate file since bin= ary diffs on large files are expensive. >=20 > clang, clang++ and tblgen store some absolute paths to .cpp files in the = src repo internally, plus unique identifiers. >=20 > freebsd.cf, freebsd.submit.cf, sendmail.cf and submit.cf record the absol= ute OBJDIR path to sendmail >=20 > What do you think? My personal opinion that the feature is nice to have. Unless the changes to get this working are too large, and, more importantly, unless the maintenan= ce cost of having this in good shape is too high, sure we would better have deterministic build results. Also, the deterministic builds require somebody who would monitor the feature, either manually, or by setting some bot that automatically checks it. Otherwise, I suspect, it will degrade. --9CGWabQ8wCOOTGwI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkyyzyQACgkQC3+MBN1Mb4hUwgCcD7slcBfrCl9lb+L3nt9QE0YI NVAAnipFNyVhp8YmQ+C3M1bsK5Ds9C5e =310U -----END PGP SIGNATURE----- --9CGWabQ8wCOOTGwI-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 09:35:45 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E56681065670 for ; Mon, 11 Oct 2010 09:35:44 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) by mx1.freebsd.org (Postfix) with ESMTP id 86C2E8FC17 for ; Mon, 11 Oct 2010 09:35:44 +0000 (UTC) Received: from [10.0.1.25] (unknown [217.157.7.211]) by csmtp2.one.com (Postfix) with ESMTPA id C8022C4660503; Mon, 11 Oct 2010 09:35:42 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-2128--755102632; protocol="application/pkcs7-signature"; micalg=sha1 From: Erik Cederstrand In-Reply-To: <20101011084733.GM2392@deviant.kiev.zoral.com.ua> Date: Mon, 11 Oct 2010 11:35:42 +0200 Message-Id: <95F3B27C-42E6-4267-9965-AC3219310C35@cederstrand.dk> References: <718D8E86-EA2E-4D07-BAFF-5D8D093FD296@cederstrand.dk> <20101011084733.GM2392@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1081) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Hackers Subject: Re: Deterministic builds? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 09:35:45 -0000 --Apple-Mail-2128--755102632 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Den 11/10/2010 kl. 10.47 skrev Kostik Belousov: > > My personal opinion that the feature is nice to have. Unless the = changes to > get this working are too large, and, more importantly, unless the = maintenance > cost of having this in good shape is too high, sure we would better = have > deterministic build results. >=20 > Also, the deterministic builds require somebody who would monitor the > feature, either manually, or by setting some bot that automatically > checks it. Otherwise, I suspect, it will degrade. I might want to adopt the task of monitoring the feature. I'm beginning to think that it should at least be optional. Removing = e.g. build times, mtimes and path to OBJDIR or SRCDIR might not make = everyone happy. Any hints to why kernel module checksums don't match? Thanks, Erik= --Apple-Mail-2128--755102632-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 13:57:56 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A6EF106566C; Mon, 11 Oct 2010 13:57:56 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id 455158FC08; Mon, 11 Oct 2010 13:57:56 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id 6FA894D771; Mon, 11 Oct 2010 15:57:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id qWenzp4tdYIi; Mon, 11 Oct 2010 15:57:52 +0200 (CEST) Received: from danger-mbp.local (adsl-dyn172.78-99-31.t-com.sk [78.99.31.172]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.syscare.sk (Postfix) with ESMTPSA id 544E24D756; Mon, 11 Oct 2010 15:57:52 +0200 (CEST) Message-ID: <4CB317DF.5040501@FreeBSD.org> Date: Mon, 11 Oct 2010 15:57:51 +0200 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12pre) Gecko/20101010 Lanikai/3.1.6pre MIME-Version: 1.0 To: current@freebsd.org, hackers@freebsd.org, questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Fwd: HEADSUP: Call for FreeBSD Status Reports - 3Q/2010 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 13:57:56 -0000 Hello, this is a reminder to anyone who's planning on sending a status report to us. The submission deadline is 15th Sept 2010. I know that many of you guys have spent last few days in Karlsruhe (and I hope to receive some additional reports covering the EuroBSDCon/DevSummit events), so that I understand that the reports might still be on their way. I just wanted to note, that to this date we have received only 5 entries. Please, if you are planning to send your entry, let us know so we can at least count with you and poke you if we don't receive it soon :) -------- Original Message -------- Subject: HEADSUP: Call for FreeBSD Status Reports - 3Q/2010 Date: Thu, 30 Sep 2010 08:29:48 +0200 From: Daniel Gerzo Organization: The FreeBSD Project To: current@freebsd.org, hackers@freebsd.org, questions@freebsd.org Dear all, I would like to remind you that the next round of status reports covering the third quarter of 2010 is due on October 15th, 2010. This initiative is very welcome in our community. Therefore, I would like to ask you to submit your status reports soon, so that we can compile the report on time. Do not hesitate and write us a few lines - a short description about what you are working on, what are your plans and goals, so we can inform our community about your great work! Check out the reports from the past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome too. Note that the submissions are accepted from anyone involved with the FreeBSD community, you do not have to be a FreeBSD committer. Submissions about anything related to FreeBSD are very welcome! Please email us the filled-in XML template which can be found at http://www.freebsd.org/news/status/report-sample.xml to monthly@FreeBSD.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 17:39:55 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B94B7106566C for ; Mon, 11 Oct 2010 17:39:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 61E628FC12 for ; Mon, 11 Oct 2010 17:39:55 +0000 (UTC) Received: (qmail 30880 invoked by uid 399); 11 Oct 2010 17:39:54 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 11 Oct 2010 17:39:54 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CB34BF9.4050504@FreeBSD.org> Date: Mon, 11 Oct 2010 10:40:09 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Devin Teske References: <1286397912.27308.40.camel@localhost.localdomain> In-Reply-To: <1286397912.27308.40.camel@localhost.localdomain> X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: sysconf -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 17:39:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Unfortunately $LIFE is preventing me from an in-depth review of this script at this time, but I wanted to lodge a comment or two. Please forgive me for the brevity. 1. I applaud any effort in the realm of making things easier for users. 2. I like the general concept of having a programmatic interface to the "settings" that live in "rc.conf and friends". 3. I have read the thread, and so I have a pretty good idea of the environment that the author is working in, and that the complexity of this script is (at least in part) a result of that environment. 4. That said, I think that in its current form the script is: a) far too complex b) not even in the neighborhood of "FreeBSD rc.d style" c) misses some knowledge of FreeBSD resources (e.g., mktemp) 5. For those reasons I am not supportive of adding this to the base at this time 6. I would not object to this being added to ports, however 7. I agree with the author's statement that in an ideal world the internals of the script would be added to rc.subr so that they could be available to the whole rc.d system. In fact, one of the features that has been requested to add to the service(8) script is the idea of taking "enable" and "disable" as arguments. I'm supportive of that, but haven't found time to code it yet, in part because (as has been illuminated in this thread) the problem of determining how to conclusively toggle the setting is not as cut and dry as it appears. The model that I had more or less settled on for that is to be certain that /etc/rc.d/servicename is the last file sourced for any given invocation of source_rc_confs() and focus on that, but even that mechanism has complications that I don't have time to go into right now. So to summarize, the general idea is a good one and needed, and an area that I'd like to see more work in. Perhaps it might be a good idea to move the discussion about that to freebsd-rc@? hth, Doug PS, have a look at, for example, 'service named rcvar' - -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBCAAGBQJMs0v4AAoJEFzGhvEaGryEF5oH/iVMaqFwytSIJSucka/4PkfY 2hUzw+OjvxqSCPZmxch+zU6hfFkWh8H0ZjbNULoA8y6FLrV1ogJuWqEb3g9K4vKt 3rx5reubsyS/bIWd5J0cXSM97hD2bq0DZlyFQKPiDY+xSEPiLvOcFKyzTq4MOu58 Z78LTBt3sAHc7Yc/lpiJD8lKQDNDzhtUsB13y+7AwmKh7RkYoub0QvlGwFF5D3xu a7oNiRUlZJdrhfRQPq65r7h7W0fLJGxQCcOJMaUFvGvdXUREZrsuplV1ABlXZ+tL B95dmu7oaOdwE5vkSP+v10Wbl4oMCuLoDhAgrfwhbOF1i2bXbH5UJd+vfyljcss= =wz2I -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 17:46:43 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE2FE106566C for ; Mon, 11 Oct 2010 17:46:43 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 5AD318FC0C for ; Mon, 11 Oct 2010 17:46:43 +0000 (UTC) Received: (qmail 1072 invoked by uid 399); 11 Oct 2010 17:20:01 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 11 Oct 2010 17:20:01 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CB34750.2030303@FreeBSD.org> Date: Mon, 11 Oct 2010 10:20:16 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <1286397912.27308.40.camel@localhost.localdomain> <51B4504F-5AA4-47C5-BF23-FA51DE5BC8C8@vicor.com> <4CAD513F.3010903@DataIX.net> <4CAD7563.1070706@DataIX.net> <87fwwici02.wl%rand@meridian-enviro.com> <4CAF26DB.3060706@FreeBSD.org> In-Reply-To: <4CAF26DB.3060706@FreeBSD.org> X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 17:46:43 -0000 On 10/8/2010 7:12 AM, Daniel Gerzo wrote: > On 7.10.2010 15:42, Warren Block wrote: >> Consider also the docs that tell the user to >> echo 'something_enable="YES"' >> /etc/rc.conf >> >> which can produce duplicate and possibly differing entries. Or >> non-working entries if there was no ending \n present, or even a broken > > like forgetting to add two '>' and not having a backup :) > >> rc.conf that breaks startup. You cannot program around stupidity. :) -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 18:13:44 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D768E106589B; Mon, 11 Oct 2010 18:13:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A75438FC15; Mon, 11 Oct 2010 18:13:44 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4EA8E46B35; Mon, 11 Oct 2010 14:13:44 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 400D08A01D; Mon, 11 Oct 2010 14:13:43 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 11 Oct 2010 12:11:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CAE092A.60905@freebsd.org> In-Reply-To: <4CAE092A.60905@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201010111211.37993.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 11 Oct 2010 14:13:43 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Matthew Fleming , Andriy Gapon Subject: Re: generic_stop_cpus: prevent parallel execution X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 18:13:44 -0000 On Thursday, October 07, 2010 1:53:46 pm Andriy Gapon wrote: > > Here is patch that applies the technique from panic() to generic_stop_cpus() to > prevent its parallel execution on multiple CPUs: > http://people.freebsd.org/~avg/generic_stop_cpus.diff > > In theory this could lead to two CPUs stopping each other and everyone else, and > thus a total system halt. > > Also, in theory, we should have some smarter locking here, because two (or more > CPUs) could be stopping unrelated sets of CPUs. But in practice, it seems, this > function is only used to stop "all other" CPUs. Unless I overlooked other usages, > that is. > > Additionally, I took this opportunity to make amd64-specific suspend_cpus() > function use generic_stop_cpus() instead of rolling out essentially duplicate > code. I couldn't see any reason no to consolidate, but perhaps I missed something. > > Big thanks to Matthew and his employer for the idea and example. One note. Use 'cpu_spinwait()' in the inner loop waiting for 'stopping_cpu' to change. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 18:13:46 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D4C01065912; Mon, 11 Oct 2010 18:13:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0C7438FC14; Mon, 11 Oct 2010 18:13:46 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A851646B5C; Mon, 11 Oct 2010 14:13:45 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CD0558A027; Mon, 11 Oct 2010 14:13:44 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 11 Oct 2010 12:14:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CB22E79.2010202@freebsd.org> In-Reply-To: <4CB22E79.2010202@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010111214.11698.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 11 Oct 2010 14:13:44 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Subject: Re: anyone got advice on sendmail and TLS on 8.1? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 18:13:46 -0000 On Sunday, October 10, 2010 5:22:01 pm Julian Elischer wrote: > When I last did sendmail there wasn't any TLS/SSL stuff. > > has anyone got an exact howto as to how to enable a simple sendmail > server? > > all I want is: > > TLS and authenticated email submission by me and my family > able to forward the email anywhere (maybe just to my ISP but who > knows) (outgoing) > non TLS submission from outside to reject all mail not to > elischer.{org,com} > and deliver our mail to mailboxes or gmail (or where-ever /etc/aliases > says.). > > This is probably ALMOST a default configuration > but I can't be sure what is needed.. there are several > howtos on hte net but they are generally old and differ in details. Your best bet is probably to look at the docs on sendmail.org. You need to recompile the sendmail in base against SASL and need to install cyrus-sasl2 from ports to manage your authentication database. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 18:45:27 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 139B81065672; Mon, 11 Oct 2010 18:45:27 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-hackers@freebsd.org Date: Mon, 11 Oct 2010 14:45:03 -0400 User-Agent: KMail/1.6.2 References: <4CAE092A.60905@freebsd.org> <201010111211.37993.jhb@freebsd.org> In-Reply-To: <201010111211.37993.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010111445.14920.jkim@FreeBSD.org> Cc: Matthew Fleming , Andriy Gapon Subject: Re: generic_stop_cpus: prevent parallel execution X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 18:45:27 -0000 On Monday 11 October 2010 12:11 pm, John Baldwin wrote: > On Thursday, October 07, 2010 1:53:46 pm Andriy Gapon wrote: > > Here is patch that applies the technique from panic() to > > generic_stop_cpus() to prevent its parallel execution on multiple > > CPUs: > > http://people.freebsd.org/~avg/generic_stop_cpus.diff > > > > In theory this could lead to two CPUs stopping each other and > > everyone else, and thus a total system halt. > > > > Also, in theory, we should have some smarter locking here, > > because two (or more CPUs) could be stopping unrelated sets of > > CPUs. But in practice, it seems, this function is only used to > > stop "all other" CPUs. Unless I overlooked other usages, that > > is. > > > > Additionally, I took this opportunity to make amd64-specific > > suspend_cpus() function use generic_stop_cpus() instead of > > rolling out essentially duplicate code. I couldn't see any > > reason no to consolidate, but perhaps I missed something. When I wrote the code, generic_stop_cpus() didn't exist. Now it makes sense, though. > > Big thanks to Matthew and his employer for the idea and example. > > One note. Use 'cpu_spinwait()' in the inner loop waiting for > 'stopping_cpu' to change. +1. Jung-uk Kim From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 19:22:51 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D82291065674 for ; Mon, 11 Oct 2010 19:22:51 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id C23E88FC0C for ; Mon, 11 Oct 2010 19:22:51 +0000 (UTC) Received: from [208.206.78.30] (port=49633 helo=dt.vicor.com) by postoffice.vicor.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.71) (envelope-from ) id 1P5NxQ-0004o5-7o; Mon, 11 Oct 2010 12:22:51 -0700 From: Devin Teske To: Doug Barton In-Reply-To: <4CB34BF9.4050504@FreeBSD.org> References: <1286397912.27308.40.camel@localhost.localdomain> <4CB34BF9.4050504@FreeBSD.org> Content-Type: text/plain Organization: Vicor, Inc Date: Mon, 11 Oct 2010 12:22:48 -0700 Message-Id: <1286824968.30494.46.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-41.el4) Content-Transfer-Encoding: 7bit X-Scan-Signature: 489a3d1789d9ed6a493067fc3624beb4 X-Scan-Host: postoffice.vicor.com Cc: freebsd-hackers@freebsd.org Subject: Re: sysconf -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 19:22:52 -0000 On Mon, 2010-10-11 at 10:40 -0700, Doug Barton wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Unfortunately $LIFE is preventing me from an in-depth review of this > script at this time, but I wanted to lodge a comment or two. Please > forgive me for the brevity. > > 1. I applaud any effort in the realm of making things easier for users. Thanks! > 2. I like the general concept of having a programmatic interface to the > "settings" that live in "rc.conf and friends". Yay! Glad to find people generally support the idea of this script (and enhancements are on the way, according to what has been discussed in this thread). > 3. I have read the thread, and so I have a pretty good idea of the > environment that the author is working in, and that the complexity of > this script is (at least in part) a result of that environment. > 4. That said, I think that in its current form the script is: > a) far too complex I've already started dramatically reducing the complexity. Script has dropped nearly 300 lines of code already. > b) not even in the neighborhood of "FreeBSD rc.d style" ^_^ In the same state at least? Next version should be in the same neighborhood. > c) misses some knowledge of FreeBSD resources (e.g., mktemp) I'm adding that in now. > 5. For those reasons I am not supportive of adding this to the base at > this time I agree. The 1.0 revision posted is not a candidate for base- distribution. However, the thread has helped me design the second revision around that desire. > 6. I would not object to this being added to ports, however Let's see if we can't develop something that does meet the stringent guidelines of base-distribution (failing that I'd love it in ports). > 7. I agree with the author's statement that in an ideal world the > internals of the script would be added to rc.subr so that they could be > available to the whole rc.d system. And then the script could be programmed to source /etc/rc.subr and therefore get even closer to the neighborhood-style of rc.d scripts (which do the same). > > In fact, one of the features that has been requested to add to the > service(8) script is the idea of taking "enable" and "disable" as > arguments. I'm supportive of that, but haven't found time to code it > yet, in part because (as has been illuminated in this thread) the > problem of determining how to conclusively toggle the setting is not as > cut and dry as it appears. The model that I had more or less settled on > for that is to be certain that /etc/rc.d/servicename is the last file > sourced for any given invocation of source_rc_confs() Might you have meant "/etc/rc.conf.d/servicename is the last file sourced for any given invocation of source_rc_confs()"?? And slight correction... source_rc_confs() from /etc/defaults/rc.conf doesn't source anything in /etc/rc.conf.d (it doesn't have the `servicename' context), but rather load_rc_confs() from /etc/rc.subr does indeed source /etc/rc.conf.d/servicename as the last file (because it has `servicename' as a context in the first positional argument). My feelings are that since the load_rc_conf() does the following: 1. Sources /etc/defaults/rc.conf 2. calls source_rc_confs() which: 3. Sources files from $rc_conf_files in order of appearance 4. Sources /etc/rc.conf.d/servicename if it exists So, if someone wants to disable a given service... say, named, it seems logical that the _minimum_ that the service(8) script must do is: Either A: Cheat and plop the new value in the last file sourced (in this case, appending `named_enable="NO"' to /etc/rc.conf.d/named). or B: 1. Find the last place that it was defined (search in reverse-order) 2. Replace the last instance in the last place it was defined Of course, no modification should ever be made to /etc/defaults/rc.conf, so it also stands to reason that if the directive is not found, then throw it into the first (aka "primary") file (in this case, the first file in $rc_conf_files -- usually /etc/rc.conf). This tends to work very well. If there are multiple instances of definition, only the last such definition will be replaced. The end result is that the operation is not sloppy, and doesn't result in growing files (that simply appending would result in). Also, I wouldn't go much further than the minimum... say in searching out all uses and consolidating all occurrences down to one definition in a single file. There are times when you do want the duplicate definition hanging around. For example, if you've got /etc/rc.conf shared among a bevy of machines yet you rely on /etc/rc.conf.local to override values specific to the local machine. > and focus on that, > but even that mechanism has complications that I don't have time to go > into right now. Understandable. $LIFE and $WIFE eat up a lot of CPU cycles. God help you if you have $PROGENY ^_^ > > So to summarize, the general idea is a good one and needed, and an area > that I'd like to see more work in. Perhaps it might be a good idea to > move the discussion about that to freebsd-rc@? I'll look into signing up for the rc mailing list (didn't see that when I checked last -- I'll have to look again). Maybe I'll post v2.0 to there (but will cc back hackers cause I know folks may not be part of both). > > > hth, > > Doug > > PS, have a look at, for example, 'service named rcvar' > > - -- > > Breadth of IT experience, and | Nothin' ever doesn't change, > depth of knowledge in the DNS. | but nothin' changes much. > Yours for the right price. :) | -- OK Go > http://SupersetSolutions.com/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (MingW32) > > iQEcBAEBCAAGBQJMs0v4AAoJEFzGhvEaGryEF5oH/iVMaqFwytSIJSucka/4PkfY > 2hUzw+OjvxqSCPZmxch+zU6hfFkWh8H0ZjbNULoA8y6FLrV1ogJuWqEb3g9K4vKt > 3rx5reubsyS/bIWd5J0cXSM97hD2bq0DZlyFQKPiDY+xSEPiLvOcFKyzTq4MOu58 > Z78LTBt3sAHc7Yc/lpiJD8lKQDNDzhtUsB13y+7AwmKh7RkYoub0QvlGwFF5D3xu > a7oNiRUlZJdrhfRQPq65r7h7W0fLJGxQCcOJMaUFvGvdXUREZrsuplV1ABlXZ+tL > B95dmu7oaOdwE5vkSP+v10Wbl4oMCuLoDhAgrfwhbOF1i2bXbH5UJd+vfyljcss= > =wz2I > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> FUN STUFF <- -----BEGIN GEEK CODE BLOCK----- Version 3.1 GAT/CS d(+) s: a- C++(++++) UB++++$ P++(++++) L++(++++) !E--- W++ N? o? K- w O M+ V- PS+ PE Y+ PGP- t(+) 5? X+(++) R>++ tv(+) b+(++) DI+(++) D(+) G+>++ e>+ h r>++ y+ ------END GEEK CODE BLOCK------ http://www.geekcode.com/ -> END TRANSMISSION <- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 20:36:32 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E411B1065670 for ; Mon, 11 Oct 2010 20:36:32 +0000 (UTC) (envelope-from raj@csub.edu) Received: from mh0.csub.edu (mh0.csub.edu [136.168.1.94]) by mx1.freebsd.org (Postfix) with ESMTP id C10CB8FC12 for ; Mon, 11 Oct 2010 20:36:32 +0000 (UTC) Received: from [136.168.65.65] (strider.csub.edu [136.168.65.65]) (authenticated bits=0) by mh0.csub.edu (8.14.3/8.14.3) with ESMTP id o9BKaVbN096500 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 11 Oct 2010 13:36:32 -0700 (PDT) (envelope-from raj@csub.edu) X-DKIM: Sendmail DKIM Filter v2.8.3 mh0.csub.edu o9BKaVbN096500 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=csub.edu; s=mailhub.csub.edu; t=1286829392; bh=r8JvE4SGlnHgG4DvQUGBOu2YNB4=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Rd5pOrl0XNwiszNT3sKON1sUNtsXsoDjbMu7dtNcsKWrBMZOBKOcqQNs5UYoCEJPN rOdLoP8cROlDKcT0uAjc13dcQkRp6xB/+pP1YQx2DH7Pkpf+tsizpuos3/3+Gy7E6B LyVcSSNSVrf/QfCtL7qq1fkRZEUXzF9jArOOrXiU= Message-ID: <4CB3749C.1040000@csub.edu> Date: Mon, 11 Oct 2010 13:33:32 -0700 From: Russell Jackson Organization: California State University Bakersfield User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.11) Gecko/20101007 Thunderbird/3.1.5 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <1286397912.27308.40.camel@localhost.localdomain> In-Reply-To: <1286397912.27308.40.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: sysconf -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 20:36:33 -0000 On 10/06/2010 01:45 PM, Devin Teske wrote: > Hello fellow freebsd-hackers, > > Long-time hacker, first-time poster. > > I'd like to share a shell script that I wrote for FreeBSD system > administration. > > The attached shell script works similar to sysctl(8), but rather than > querying or working on sysctl MIBs, it instead works on the /etc/rc.conf > (and /etc/rc.conf.local) files. > Have you looked at textproc/augeas? It's a more generic and extensible way to edit plain text configuration files programmatically using an xpath like syntax. Example # augtool get /files/etc/rc.conf/sshd_enable /files/etc/rc.conf/sshd_enable = YES # printf 'set /files/etc/rc.conf/sshd_enable NO\nsave\n' | augtool # augtool get /files/etc/rc.conf/sshd_enable /files/etc/rc.conf/sshd_enable = NO The tool itself is written in C and has no external dependencies. It is taught file grammar via "lenses" which are like formal language specs written in BNF. http://augeas.net/ -- Russell A Jackson Network Analyst California State University, Bakersfield From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 20:42:45 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE2401065670 for ; Mon, 11 Oct 2010 20:42:45 +0000 (UTC) (envelope-from raj@csub.edu) Received: from mh1.csub.edu (mh1.csub.edu [136.168.1.95]) by mx1.freebsd.org (Postfix) with ESMTP id C74868FC12 for ; Mon, 11 Oct 2010 20:42:45 +0000 (UTC) Received: from [136.168.65.65] (strider.csub.edu [136.168.65.65]) (authenticated bits=0) by mh1.csub.edu (8.14.3/8.14.3) with ESMTP id o9BKEEW5054986 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 11 Oct 2010 13:14:15 -0700 (PDT) (envelope-from raj@csub.edu) X-DKIM: Sendmail DKIM Filter v2.8.3 mh1.csub.edu o9BKEEW5054986 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=csub.edu; s=mailhub.csub.edu; t=1286828055; bh=W/I2PmPTKGJDQlV9Aq05zvStvl0=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=CJoYwYqAXCsYYJcoArfKdMltjc0Jcmtcln1a99SYPZpHY23cuDvdTM9PKDeB+wiO+ pNVFK5m4cuoMwCotNUHXM2/NGjOYWjHnnXILbgheQ8gNF3sRJNz4LPfrEHlV46bsiL dZtp7FKL6sBg7L1AcrCKwlezu66DSypxTp6aoLfc= Message-ID: <4CB36F64.3040601@csub.edu> Date: Mon, 11 Oct 2010 13:11:16 -0700 From: Russell Jackson Organization: California State University Bakersfield User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.11) Gecko/20101007 Thunderbird/3.1.5 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <1286397912.27308.40.camel@localhost.localdomain> <51B4504F-5AA4-47C5-BF23-FA51DE5BC8C8@vicor.com> <4CAD513F.3010903@DataIX.net> <4CAD7563.1070706@DataIX.net> <87fwwici02.wl%rand@meridian-enviro.com> In-Reply-To: <87fwwici02.wl%rand@meridian-enviro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 20:42:46 -0000 On 10/07/2010 05:19 AM, Douglas K. Rand wrote: > I think that this script might also fill a void with using Puppet as a > configuration tool. Currently Puppet, as its default behaviour, uses > files in /etc/rc.conf.d to set variables. This is no longer the case. Current versions edit /etc/rc.conf. -- Russell A Jackson Network Analyst California State University, Bakersfield From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 00:38:40 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FA301065674 for ; Tue, 12 Oct 2010 00:38:40 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id 087238FC12 for ; Tue, 12 Oct 2010 00:38:39 +0000 (UTC) Received: from [208.206.78.30] (port=50238 helo=dt.vicor.com) by postoffice.vicor.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.71) (envelope-from ) id 1P5St0-0000An-Uk; Mon, 11 Oct 2010 17:38:37 -0700 From: Devin Teske To: Russell Jackson In-Reply-To: <4CB3749C.1040000@csub.edu> References: <1286397912.27308.40.camel@localhost.localdomain> <4CB3749C.1040000@csub.edu> Content-Type: text/plain Organization: Vicor, Inc Date: Mon, 11 Oct 2010 17:38:34 -0700 Message-Id: <1286843914.30494.55.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-41.el4) Content-Transfer-Encoding: 7bit X-Scan-Signature: 7cae7f85fe1875c3bbf6d4261624bd4e X-Scan-Host: postoffice.vicor.com Cc: freebsd-hackers@freebsd.org Subject: Re: sysconf -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 00:38:40 -0000 On Mon, 2010-10-11 at 13:33 -0700, Russell Jackson wrote: > On 10/06/2010 01:45 PM, Devin Teske wrote: > > Hello fellow freebsd-hackers, > > > > Long-time hacker, first-time poster. > > > > I'd like to share a shell script that I wrote for FreeBSD system > > administration. > > > > The attached shell script works similar to sysctl(8), but rather than > > querying or working on sysctl MIBs, it instead works on the /etc/rc.conf > > (and /etc/rc.conf.local) files. > > > > Have you looked at textproc/augeas? It's a more generic and extensible > way to edit plain text configuration files programmatically using an > xpath like syntax. > > Example > > # augtool get /files/etc/rc.conf/sshd_enable > /files/etc/rc.conf/sshd_enable = YES > # printf 'set /files/etc/rc.conf/sshd_enable NO\nsave\n' | augtool > # augtool get /files/etc/rc.conf/sshd_enable > /files/etc/rc.conf/sshd_enable = NO > > > The tool itself is written in C and has no external dependencies. It is > taught file grammar via "lenses" which are like formal language specs > written in BNF. > > http://augeas.net/ > Very cool. However... $ uname -spr FreeBSD 8.1-RELEASE-p1 amd64 $ which augtool $ type augtool -bash: type: augtool: not found Not like I'm running bare... $ pkg_info -Ia | wc -l 399 Unfortunately, augtool doesn't even appear to be packaged for FreeBSD: $ pwd /repos/FreeBSD-8.1/8.1-RELEASE/packages $ ls | head -4 All INDEX MOVED UPDATING $ awk -F'|' '/augtool/ {print $1}' < INDEX $ awk -F'|' '/lexx/ {print $1}' < INDEX lexxia-0.901 $ awk -F'|' '/yacc/ {print $1}' < INDEX afay-041111 byaccj-1.14 ebnf2yacc-0.1.1 lemon-1.69 ruby18-byaccr-0.1 showgrammar-1.1 cocor-1.7_1 Not as a binary package nor could I find it in the ports tree. At this point, we're developing a script that is to be a candidate for inclusion into the base-distribution of FreeBSD, so any/all use of augtool is out unless it gets included in the base OS. Thanks for the heads-up though... looks really powerful. -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 00:50:23 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD758106564A for ; Tue, 12 Oct 2010 00:50:23 +0000 (UTC) (envelope-from raj@csub.edu) Received: from mh1.csub.edu (mh1.csub.edu [136.168.1.95]) by mx1.freebsd.org (Postfix) with ESMTP id A7B9D8FC08 for ; Tue, 12 Oct 2010 00:50:23 +0000 (UTC) Received: from [136.168.65.65] (strider.csub.edu [136.168.65.65]) (authenticated bits=0) by mh1.csub.edu (8.14.3/8.14.3) with ESMTP id o9C0oMIt057171 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 11 Oct 2010 17:50:22 -0700 (PDT) (envelope-from raj@csub.edu) X-DKIM: Sendmail DKIM Filter v2.8.3 mh1.csub.edu o9C0oMIt057171 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=csub.edu; s=mailhub.csub.edu; t=1286844622; bh=PWvltfKDCf8XV7tlgx0ZSW8cvLs=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=RJP4w0e1ypRNCUfGTP6Oj9KTE/pg4eW0eQurNDaHb7GGUOEWZlTxv2Me5w6uHm3fa VUbfLlaa4VXcBXJCqBPjXMVpZc1UGFag6gObzTYhSTqzDMmJj4h5gjJEp3fHZkoYxE NLSBjzGxtK+MccsmY15K+SOF+UVahjrLQQ/4fEYQ= Message-ID: <4CB3B019.3030807@csub.edu> Date: Mon, 11 Oct 2010 17:47:21 -0700 From: Russell Jackson Organization: California State University Bakersfield User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.11) Gecko/20101007 Thunderbird/3.1.5 MIME-Version: 1.0 To: Devin Teske References: <1286397912.27308.40.camel@localhost.localdomain> <4CB3749C.1040000@csub.edu> <1286843914.30494.55.camel@localhost.localdomain> In-Reply-To: <1286843914.30494.55.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: sysconf -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 00:50:23 -0000 On 10/11/2010 05:38 PM, Devin Teske wrote: > > $ uname -spr > FreeBSD 8.1-RELEASE-p1 amd64 > $ which augtool > $ type augtool > -bash: type: augtool: not found > > Not like I'm running bare... > > $ pkg_info -Ia | wc -l > 399 > > Unfortunately, augtool doesn't even appear to be packaged for FreeBSD: > Try pkg_add -r augeas. The port is textproc/augeas. Augtool is just the cli frontend to libaugeas. There's also language bindings for python and ruby. -- Russell A Jackson Network Analyst California State University, Bakersfield From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 10:47:50 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2FFE1065672 for ; Tue, 12 Oct 2010 10:47:50 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3D1798FC0A for ; Tue, 12 Oct 2010 10:47:50 +0000 (UTC) Received: by iwn8 with SMTP id 8so6030935iwn.13 for ; Tue, 12 Oct 2010 03:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=y2265HVJHY9TbDIxeNy9JGL2eHaGJfVHQadPgquEWwE=; b=fTgShgjfV+fg8EdDqaZkAggBAwnbcyBus+T3xuSuW6m+ufFA8F3VvyddHJx6CCmPzz ywpWXw0Lx0FjCANgHeP/gxOWnn3fJFUQo/x5VnkYEElooEm4f1cKVgNI8r6wCrvSTeXW bPHIlAr8ahOVT+OiSmaRMn0fcbqjJ8sPYGrhs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=EZlwsseTi6clHIW6lbez6MYh9t3ke9bxbgzhP3n0EUbx31ngNGo0bRaZknYPbwQeCb uUpu9sQpGEdYcpI99VGSzrFV9aoN+pE0b92sV3ZdlszIPX3Jx7/eGntelnMMkZ/JnWmg hOzF5Zna+Rj1uYmVTH7IAMjZgrSQJ9kPUhMF4= MIME-Version: 1.0 Received: by 10.231.19.74 with SMTP id z10mr5464626iba.120.1286880469594; Tue, 12 Oct 2010 03:47:49 -0700 (PDT) Received: by 10.231.184.3 with HTTP; Tue, 12 Oct 2010 03:47:49 -0700 (PDT) Date: Tue, 12 Oct 2010 03:47:49 -0700 Message-ID: From: Garrett Cooper To: Jilles Tjoelker Content-Type: multipart/mixed; boundary=00221532cd104234de049269356f Cc: freebsd-hackers@freebsd.org Subject: [PATCH] Fix /bin/sh compilation with CFLAGS += -DDEBUG > 1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 10:47:50 -0000 --00221532cd104234de049269356f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, It looks like the format strings are broken on 64-bit archs in /bin/sh's TRACE functionality (can be enabled by uncommenting -DDEBUG > 1 in bin/sh/Makefile). The attached patch fixes this functionality again so one can trace sh's calls with TRACE, which may or may be helpful to those debugging /bin/sh. Tested build and execution on amd64; tested build on i386. Thanks! -Garrett PS If someone can help review, and potentially commit this patch, it would be much appreciated. Tracing started. Shell args: "./sh" "-x" cmdloop(1) called showjobs(1) called token word sleep pipeline: entered reread token word sleep reread token word sleep reread token word sleep reread token word sleep reread token word sleep token word 100 token "&" reread token "&" reread token "&" reread token "&" token newline evaltree(0x800d4b658: 1) called evalcommand(0x800d4b658, 0) called evalcommand arg: sleep evalcommand arg: 100 searchexec "sleep" returns "/bin/sleep" makejob(0x800d4b658, 1) returns %1 forkshell(%0, 0x800d4b658, 1) called dowait(0) called wait returns -1, status=3D8 Child shell 16632 normal command: "sleep" "100" In parent shell: child =3D 16632 showjobs(1) called dowait(0) called wait returns 0, status=3D-256 token word echo pipeline: entered reread token word echo reread token word echo reread token word echo reread token word echo reread token word echo token word hallo token end of file reread token end of file reread token end of file reread token end of file token word foo=3D=84 pipeline: entered reread token word foo=3D=84 reread token word foo=3D=84 reread token word foo=3D=84 reread token word foo=3D=84 reread token word foo=3D=84 token newline reread token newline reread token newline reread token newline evaltree(0x800d4b6a8: 1) called evalcommand(0x800d4b6a8, 0) called evalcommand(0x800d4b668, 4) called evalcommand arg: echo evalcommand arg: hallo builtin command: "echo" "hallo" evalbackcmd done: fd=3D-1 buf=3D0x800c570c0 nleft=3D6 jp=3D0x0 expbackq: size=3D5: "hallo" builtin command: showjobs(1) called dowait(0) called wait returns 0, status=3D-256 token word jobs pipeline: entered reread token word jobs reread token word jobs reread token word jobs reread token word jobs reread token word jobs token newline reread token newline reread token newline reread token newline evaltree(0x800d4b630: 1) called evalcommand(0x800d4b630, 0) called evalcommand arg: jobs builtin command: "jobs" showjobs(0) called dowait(0) called wait returns 0, status=3D-256 showjobs(1) called dowait(0) called wait returns 0, status=3D-256 token word fg pipeline: entered reread token word fg reread token word fg reread token word fg reread token word fg reread token word fg token newline reread token newline reread token newline reread token newline evaltree(0x800d4b630: 1) called evalcommand(0x800d4b630, 0) called evalcommand arg: fg builtin command: "fg" waitforjob(%1) called dowait(1) called wait returns 16632, status=3D0 Changing status of proc 16632 from 0xffffffff to 0x0 Job 1: changing state from 0 to 2 showjobs(1) called dowait(0) called wait returns -1, status=3D0 token word exit pipeline: entered reread token word exit reread token word exit reread token word exit reread token word exit reread token word exit token newline reread token newline reread token newline reread token newline evaltree(0x800d4b630: 1) called evalcommand(0x800d4b630, 0) called evalcommand arg: exit builtin command: "exit" exitshell(0) pid=3D16619 --00221532cd104234de049269356f Content-Type: application/octet-stream; name="fix-bin-sh-DEBUG-functionality.diff" Content-Disposition: attachment; filename="fix-bin-sh-DEBUG-functionality.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gf6m6huv0 SW5kZXg6IGJpbi9zaC9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBiaW4vc2gvTWFrZWZpbGUJKHJl dmlzaW9uIDIxMzY4MCkKKysrIGJpbi9zaC9NYWtlZmlsZQkod29ya2luZyBjb3B5KQpAQCAtMjEs NyArMjEsOSBAQAogTEZMQUdTPSAtOAkjIDgtYml0IGxleCBzY2FubmVyIGZvciBhcml0aG1ldGlj CiBDRkxBR1MrPS1EU0hFTEwgLUkuIC1JJHsuQ1VSRElSfQogIyBmb3IgZGVidWc6Ci0jIENGTEFH Uys9IC1nIC1EREVCVUc9MgorLmlmIGRlZmluZWQoREVCVUcpCitDRkxBR1MrPQktZyAtRERFQlVH PSR7REVCVUd9CisuZW5kaWYKIFdBUk5TPz0JMgogV0ZPUk1BVD0wCiAKSW5kZXg6IGJpbi9zaC9l eHBhbmQuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSBiaW4vc2gvZXhwYW5kLmMJKHJldmlzaW9uIDIxMzY4MCkK KysrIGJpbi9zaC9leHBhbmQuYwkod29ya2luZyBjb3B5KQpAQCAtNDMsMTQgKzQzLDE1IEBACiAj aW5jbHVkZSA8c3lzL3R5cGVzLmg+CiAjaW5jbHVkZSA8c3lzL3RpbWUuaD4KICNpbmNsdWRlIDxz eXMvc3RhdC5oPgorI2luY2x1ZGUgPGRpcmVudC5oPgogI2luY2x1ZGUgPGVycm5vLmg+Ci0jaW5j bHVkZSA8ZGlyZW50Lmg+Ci0jaW5jbHVkZSA8dW5pc3RkLmg+CisjaW5jbHVkZSA8aW50dHlwZXMu aD4KKyNpbmNsdWRlIDxsaW1pdHMuaD4KICNpbmNsdWRlIDxwd2QuaD4KKyNpbmNsdWRlIDxzdGRp by5oPgogI2luY2x1ZGUgPHN0ZGxpYi5oPgotI2luY2x1ZGUgPGxpbWl0cy5oPgotI2luY2x1ZGUg PHN0ZGlvLmg+CiAjaW5jbHVkZSA8c3RyaW5nLmg+CisjaW5jbHVkZSA8dW5pc3RkLmg+CiAKIC8q CiAgKiBSb3V0aW5lcyB0byBleHBhbmQgYXJndW1lbnRzIHRvIGNvbW1hbmRzLiAgV2UgaGF2ZSB0 byBkZWFsIHdpdGgKQEAgLTQ5Nyw5ICs0OTgsOSBAQAogCQlleGl0c3RhdHVzID0gd2FpdGZvcmpv Yihpbi5qcCwgKGludCAqKU5VTEwpOwogCWlmIChxdW90ZWQgPT0gMCkKIAkJcmVjb3JkcmVnaW9u KHN0YXJ0bG9jLCBkZXN0IC0gc3RhY2tibG9jaygpLCAwKTsKLQlUUkFDRSgoImV2YWxiYWNrcTog c2l6ZT0lZDogXCIlLipzXCJcbiIsCi0JCShkZXN0IC0gc3RhY2tibG9jaygpKSAtIHN0YXJ0bG9j LAotCQkoZGVzdCAtIHN0YWNrYmxvY2soKSkgLSBzdGFydGxvYywKKwlUUkFDRSgoImV4cGJhY2tx OiBzaXplPSUiUFJJb01BWCI6IFwiJS4qc1wiXG4iLAorCQkoc2l6ZV90KSAoKGRlc3QgLSBzdGFj a2Jsb2NrKCkpIC0gc3RhcnRsb2MpLAorCQkoaW50KSAoKGRlc3QgLSBzdGFja2Jsb2NrKCkpIC0g c3RhcnRsb2MpLAogCQlzdGFja2Jsb2NrKCkgKyBzdGFydGxvYykpOwogCWV4cGRlc3QgPSBkZXN0 OwogCUlOVE9OOwpJbmRleDogYmluL3NoL2pvYnMuYwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBiaW4vc2gvam9i cy5jCShyZXZpc2lvbiAyMTM2ODApCisrKyBiaW4vc2gvam9icy5jCSh3b3JraW5nIGNvcHkpCkBA IC02ODEsNyArNjgxLDcgQEAKIAl9CiAJSU5UT047CiAJVFJBQ0UoKCJtYWtlam9iKCVwLCAlZCkg cmV0dXJucyAlJSVkXG4iLCAodm9pZCAqKW5vZGUsIG5wcm9jcywKLQkgICAganAgLSBqb2J0YWIg KyAxKSk7CisJICAgIChpbnQpIChqcCAtIGpvYnRhYiArIDEpKSk7CiAJcmV0dXJuIGpwOwogfQog CkBAIC03NjYsNyArNzY2LDcgQEAKIAlwaWRfdCBwaWQ7CiAJcGlkX3QgcGdycDsKIAotCVRSQUNF KCgiZm9ya3NoZWxsKCUlJWQsICVwLCAlZCkgY2FsbGVkXG4iLCBqcCAtIGpvYnRhYiwgKHZvaWQg KiluLAorCVRSQUNFKCgiZm9ya3NoZWxsKCUlJWQsICVwLCAlZCkgY2FsbGVkXG4iLCAoaW50KSAo anAgLSBqb2J0YWIpLCAodm9pZCAqKW4sCiAJICAgIG1vZGUpKTsKIAlJTlRPRkY7CiAJaWYgKG1v ZGUgPT0gRk9SS19CRykKQEAgLTkwMyw3ICs5MDMsNyBAQAogCWludCBzdDsKIAogCUlOVE9GRjsK LQlUUkFDRSgoIndhaXRmb3Jqb2IoJSUlZCkgY2FsbGVkXG4iLCBqcCAtIGpvYnRhYiArIDEpKTsK KwlUUkFDRSgoIndhaXRmb3Jqb2IoJSUlZCkgY2FsbGVkXG4iLCAoaW50KShqcCAtIGpvYnRhYiAr IDEpKSk7CiAJd2hpbGUgKGpwLT5zdGF0ZSA9PSAwKQogCQlpZiAoZG93YWl0KDEsIGpwKSA9PSAt MSkKIAkJCWRvdHJhcCgpOwpAQCAtMTAwNCw3ICsxMDA0LDcgQEAKIAkJCWlmIChzdG9wcGVkKSB7 CQkvKiBzdG9wcGVkIG9yIGRvbmUgKi8KIAkJCQlpbnQgc3RhdGUgPSBkb25lPyBKT0JET05FIDog Sk9CU1RPUFBFRDsKIAkJCQlpZiAoanAtPnN0YXRlICE9IHN0YXRlKSB7Ci0JCQkJCVRSQUNFKCgi Sm9iICVkOiBjaGFuZ2luZyBzdGF0ZSBmcm9tICVkIHRvICVkXG4iLCBqcCAtIGpvYnRhYiArIDEs IGpwLT5zdGF0ZSwgc3RhdGUpKTsKKwkJCQkJVFJBQ0UoKCJKb2IgJWQ6IGNoYW5naW5nIHN0YXRl IGZyb20gJWQgdG8gJWRcbiIsIChpbnQpKGpwIC0gam9idGFiICsgMSksIGpwLT5zdGF0ZSwgc3Rh dGUpKTsKIAkJCQkJanAtPnN0YXRlID0gc3RhdGU7CiAJCQkJCWlmIChqcCAhPSBqb2IpIHsKIAkJ CQkJCWlmIChkb25lICYmICFqcC0+cmVtZW1iZXJlZCAmJgo= --00221532cd104234de049269356f-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 13:14:46 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4235B106566C for ; Tue, 12 Oct 2010 13:14:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 126DA8FC1C for ; Tue, 12 Oct 2010 13:14:46 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id BC8B546B51; Tue, 12 Oct 2010 09:14:45 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 977278A01D; Tue, 12 Oct 2010 09:14:44 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 12 Oct 2010 08:30:19 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201010120830.19872.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 12 Oct 2010 09:14:44 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Garrett Cooper , Jilles Tjoelker Subject: Re: [PATCH] Fix /bin/sh compilation with CFLAGS += -DDEBUG > 1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 13:14:46 -0000 On Tuesday, October 12, 2010 6:47:49 am Garrett Cooper wrote: > Hi, > It looks like the format strings are broken on 64-bit archs in > /bin/sh's TRACE functionality (can be enabled by uncommenting -DDEBUG > > 1 in bin/sh/Makefile). The attached patch fixes this functionality > again so one can trace sh's calls with TRACE, which may or may be > helpful to those debugging /bin/sh. > Tested build and execution on amd64; tested build on i386. > Thanks! > -Garrett I don't think the Makefile bits are needed, you can just use 'make DEBUG_FLAGS="-g -DDEBUG=2"' instead. Also, if you plan on using -g you should generally set DEBUG_FLAGS anyway so binaries are not stripped. The use of things like PRIoMAX is not done in FreeBSD as it is ugly. You can use things like '%t' to print ptrdiff_t types instead. So for example, for the first hunk, I would change the type of 'startloc' to ptrdiff_t and use this: TRACE(("evalbackq: size=%td: \"%.*s\"\n", (dest - stackblock()) - startloc, (int)((dest - stackblock()) - startloc), stackblock() + startloc)); Also, in your change here, you used %j to print a size_t. That will break on i386. You should use %z to print size_t's, but even better is to just use %t to print a ptrdiff_t (which is the type that holds the difference of two pointers). The various changes in jobs.c should use '%td' as well rather than (int) casts. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 18:31:41 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AC5A106566B; Tue, 12 Oct 2010 18:31:41 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id A149E8FC14; Tue, 12 Oct 2010 18:31:40 +0000 (UTC) Received: by gwb15 with SMTP id 15so1839528gwb.13 for ; Tue, 12 Oct 2010 11:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=SMg9sBY6YvQXGPMiQkxRRqLbaurKKPg+quDSUQWG0ks=; b=iZiSZlCc2lbxqhrc0N0pHkFeKZvr/8M7wJjFgbFvRTqBbkHGaOIZC3YcQD+zmgTOk6 QCZDnFyI67rVL9VAzUwKJbhfYtxk+1vE7TmsOKkZNdNnOPXaRH8FQMrVJnSC4bjez8dT r7emDQCgZ3X4u7NJhe7rsGLd4R1hrUbLh8svc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RmAXh8n+blXarJ5y4LZ/2QyiZzGJjP2TwY8Vae2X4HJEgo8xiUKqolDmIQS6uNcF+J 8/ucup22O/1a9zvyRqJ3yP2zp8wWR0oheevxvYEOkUZjJyehMpNU9AnNwmn6ZgJfHVUZ 5PVSE0CtUdrS8hKT2xNZV9GLCUP1jVotmYCfs= MIME-Version: 1.0 Received: by 10.42.148.9 with SMTP id p9mr500566icv.440.1286908298004; Tue, 12 Oct 2010 11:31:38 -0700 (PDT) Received: by 10.231.184.3 with HTTP; Tue, 12 Oct 2010 11:31:36 -0700 (PDT) In-Reply-To: <201010120830.19872.jhb@freebsd.org> References: <201010120830.19872.jhb@freebsd.org> Date: Tue, 12 Oct 2010 11:31:36 -0700 Message-ID: From: Garrett Cooper To: John Baldwin Content-Type: multipart/mixed; boundary=90e6ba212165f607a504926faffc Cc: freebsd-hackers@freebsd.org, Jilles Tjoelker Subject: Re: [PATCH] Fix /bin/sh compilation with CFLAGS += -DDEBUG > 1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 18:31:41 -0000 --90e6ba212165f607a504926faffc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Oct 12, 2010 at 5:30 AM, John Baldwin wrote: > On Tuesday, October 12, 2010 6:47:49 am Garrett Cooper wrote: >> Hi, >> =A0 =A0 It looks like the format strings are broken on 64-bit archs in >> /bin/sh's TRACE functionality (can be enabled by uncommenting -DDEBUG >> > 1 in bin/sh/Makefile). The attached patch fixes this functionality >> again so one can trace sh's calls with TRACE, which may or may be >> helpful to those debugging /bin/sh. >> =A0 =A0 Tested build and execution on amd64; tested build on i386. > > I don't think the Makefile bits are needed, you can just use > 'make DEBUG_FLAGS=3D"-g -DDEBUG=3D2"' instead. Ok... I was just trying to make it tunable, but sure :)! > Also, if you plan on using -g you should generally set DEBUG_FLAGS anyway= so > binaries are not stripped. Ok, something new to note... > The use of things like PRIoMAX is not done in FreeBSD as it is ugly. =A0Y= ou can > use things like '%t' to print ptrdiff_t types instead. =A0So for example,= for > the first hunk, I would change the type of 'startloc' to ptrdiff_t and us= e > this: > > =A0 =A0 =A0 =A0TRACE(("evalbackq: size=3D%td: \"%.*s\"\n", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(dest - stackblock()) - startloc, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(int)((dest - stackblock()) - startloc), > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0stackblock() + startloc)); > > Also, in your change here, you used %j to print a size_t. =A0That will br= eak on > i386. It didn't actually break the build, but it's fine because I didn't test runtime (and I might have broken that)... I'll go with defacto standard as per printf(3). > You should use %z to print size_t's, but even better is to just use %t > to print a ptrdiff_t (which is the type that holds the difference of two > pointers). Ok. The overall temperature of using PRI* from POSIX seems like it's undesirable; is it just POSIX cruft that FreeBSD conforms to in theory only and doesn't really use in practice, or is there an example of real practical application where it's used in the sourcebase? > The various changes in jobs.c should use '%td' as well rather than (int) > casts. Ok. Tested build and runtime on amd64 and tested build-only with i386. Thanks! -Garrett --90e6ba212165f607a504926faffc Content-Type: application/octet-stream; name="fix-bin-sh-DEBUG-functionality.diff" Content-Disposition: attachment; filename="fix-bin-sh-DEBUG-functionality.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gf73rqou0 SW5kZXg6IGJpbi9zaC9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBiaW4vc2gvTWFrZWZpbGUJKHJl dmlzaW9uIDIxMzY4MCkKKysrIGJpbi9zaC9NYWtlZmlsZQkod29ya2luZyBjb3B5KQpAQCAtMjEs NyArMjEsNyBAQAogTEZMQUdTPSAtOAkjIDgtYml0IGxleCBzY2FubmVyIGZvciBhcml0aG1ldGlj CiBDRkxBR1MrPS1EU0hFTEwgLUkuIC1JJHsuQ1VSRElSfQogIyBmb3IgZGVidWc6Ci0jIENGTEFH Uys9IC1nIC1EREVCVUc9MgorI0RFQlVHX0ZMQUdTKz0JLWcgLURERUJVRz0yCiBXQVJOUz89CTIK IFdGT1JNQVQ9MAogCkluZGV4OiBiaW4vc2gvZXhwYW5kLmMKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gYmluL3No L2V4cGFuZC5jCShyZXZpc2lvbiAyMTM2ODApCisrKyBiaW4vc2gvZXhwYW5kLmMJKHdvcmtpbmcg Y29weSkKQEAgLTQzLDE0ICs0MywxNSBAQAogI2luY2x1ZGUgPHN5cy90eXBlcy5oPgogI2luY2x1 ZGUgPHN5cy90aW1lLmg+CiAjaW5jbHVkZSA8c3lzL3N0YXQuaD4KKyNpbmNsdWRlIDxkaXJlbnQu aD4KICNpbmNsdWRlIDxlcnJuby5oPgotI2luY2x1ZGUgPGRpcmVudC5oPgotI2luY2x1ZGUgPHVu aXN0ZC5oPgorI2luY2x1ZGUgPGludHR5cGVzLmg+CisjaW5jbHVkZSA8bGltaXRzLmg+CiAjaW5j bHVkZSA8cHdkLmg+CisjaW5jbHVkZSA8c3RkaW8uaD4KICNpbmNsdWRlIDxzdGRsaWIuaD4KLSNp bmNsdWRlIDxsaW1pdHMuaD4KLSNpbmNsdWRlIDxzdGRpby5oPgogI2luY2x1ZGUgPHN0cmluZy5o PgorI2luY2x1ZGUgPHVuaXN0ZC5oPgogCiAvKgogICogUm91dGluZXMgdG8gZXhwYW5kIGFyZ3Vt ZW50cyB0byBjb21tYW5kcy4gIFdlIGhhdmUgdG8gZGVhbCB3aXRoCkBAIC00OTcsOSArNDk4LDkg QEAKIAkJZXhpdHN0YXR1cyA9IHdhaXRmb3Jqb2IoaW4uanAsIChpbnQgKilOVUxMKTsKIAlpZiAo cXVvdGVkID09IDApCiAJCXJlY29yZHJlZ2lvbihzdGFydGxvYywgZGVzdCAtIHN0YWNrYmxvY2so KSwgMCk7Ci0JVFJBQ0UoKCJldmFsYmFja3E6IHNpemU9JWQ6IFwiJS4qc1wiXG4iLAotCQkoZGVz dCAtIHN0YWNrYmxvY2soKSkgLSBzdGFydGxvYywKLQkJKGRlc3QgLSBzdGFja2Jsb2NrKCkpIC0g c3RhcnRsb2MsCisJVFJBQ0UoKCJleHBiYWNrcTogc2l6ZT0ldGQ6IFwiJS4qc1wiXG4iLAorCQko KGRlc3QgLSBzdGFja2Jsb2NrKCkpIC0gc3RhcnRsb2MpLAorCQkoaW50KSAoKGRlc3QgLSBzdGFj a2Jsb2NrKCkpIC0gc3RhcnRsb2MpLAogCQlzdGFja2Jsb2NrKCkgKyBzdGFydGxvYykpOwogCWV4 cGRlc3QgPSBkZXN0OwogCUlOVE9OOwpJbmRleDogYmluL3NoL2pvYnMuYwo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBiaW4vc2gvam9icy5jCShyZXZpc2lvbiAyMTM2ODApCisrKyBiaW4vc2gvam9icy5jCSh3b3Jr aW5nIGNvcHkpCkBAIC0zOCwxOCArMzgsMTggQEAKICNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KIF9f RkJTRElEKCIkRnJlZUJTRCQiKTsKIAorI2luY2x1ZGUgPHN5cy9pb2N0bC5oPgorI2luY2x1ZGUg PHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9yZXNvdXJjZS5oPgorI2luY2x1ZGUgPHN5cy9z dGRkZWYuaD4KKyNpbmNsdWRlIDxzeXMvdGltZS5oPgorI2luY2x1ZGUgPHN5cy93YWl0Lmg+Cisj aW5jbHVkZSA8ZXJybm8uaD4KICNpbmNsdWRlIDxmY250bC5oPgorI2luY2x1ZGUgPHBhdGhzLmg+ CiAjaW5jbHVkZSA8c2lnbmFsLmg+Ci0jaW5jbHVkZSA8ZXJybm8uaD4KLSNpbmNsdWRlIDxwYXRo cy5oPgorI2luY2x1ZGUgPHN0ZGxpYi5oPgogI2luY2x1ZGUgPHVuaXN0ZC5oPgotI2luY2x1ZGUg PHN0ZGxpYi5oPgotI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgotI2luY2x1ZGUgPHN5cy93YWl0Lmg+ Ci0jaW5jbHVkZSA8c3lzL3RpbWUuaD4KLSNpbmNsdWRlIDxzeXMvcmVzb3VyY2UuaD4KLSNpbmNs dWRlIDxwYXRocy5oPgotI2luY2x1ZGUgPHN5cy9pb2N0bC5oPgogCiAjaW5jbHVkZSAic2hlbGwu aCIKICNpZiBKT0JTCkBAIC02ODAsOCArNjgwLDggQEAKIAkJanAtPnBzID0gJmpwLT5wczA7CiAJ fQogCUlOVE9OOwotCVRSQUNFKCgibWFrZWpvYiglcCwgJWQpIHJldHVybnMgJSUlZFxuIiwgKHZv aWQgKilub2RlLCBucHJvY3MsCi0JICAgIGpwIC0gam9idGFiICsgMSkpOworCVRSQUNFKCgibWFr ZWpvYiglcCwgJWQpIHJldHVybnMgJSUldGRcbiIsICh2b2lkICopbm9kZSwgbnByb2NzLAorCSAg ICAocHRyZGlmZl90KSAoanAgLSBqb2J0YWIgKyAxKSkpOwogCXJldHVybiBqcDsKIH0KIApAQCAt NzY2LDcgKzc2Niw3IEBACiAJcGlkX3QgcGlkOwogCXBpZF90IHBncnA7CiAKLQlUUkFDRSgoImZv cmtzaGVsbCglJSVkLCAlcCwgJWQpIGNhbGxlZFxuIiwganAgLSBqb2J0YWIsICh2b2lkICopbiwK KwlUUkFDRSgoImZvcmtzaGVsbCglJSV0ZCwgJXAsICVkKSBjYWxsZWRcbiIsIChwdHJkaWZmX3Qp IChqcCAtIGpvYnRhYiksICh2b2lkICopbiwKIAkgICAgbW9kZSkpOwogCUlOVE9GRjsKIAlpZiAo bW9kZSA9PSBGT1JLX0JHKQpAQCAtOTAzLDcgKzkwMyw3IEBACiAJaW50IHN0OwogCiAJSU5UT0ZG OwotCVRSQUNFKCgid2FpdGZvcmpvYiglJSVkKSBjYWxsZWRcbiIsIGpwIC0gam9idGFiICsgMSkp OworCVRSQUNFKCgid2FpdGZvcmpvYiglJSV0ZCkgY2FsbGVkXG4iLCAocHRyZGlmZl90KShqcCAt IGpvYnRhYiArIDEpKSk7CiAJd2hpbGUgKGpwLT5zdGF0ZSA9PSAwKQogCQlpZiAoZG93YWl0KDEs IGpwKSA9PSAtMSkKIAkJCWRvdHJhcCgpOwpAQCAtMTAwNCw3ICsxMDA0LDcgQEAKIAkJCWlmIChz dG9wcGVkKSB7CQkvKiBzdG9wcGVkIG9yIGRvbmUgKi8KIAkJCQlpbnQgc3RhdGUgPSBkb25lPyBK T0JET05FIDogSk9CU1RPUFBFRDsKIAkJCQlpZiAoanAtPnN0YXRlICE9IHN0YXRlKSB7Ci0JCQkJ CVRSQUNFKCgiSm9iICVkOiBjaGFuZ2luZyBzdGF0ZSBmcm9tICVkIHRvICVkXG4iLCBqcCAtIGpv YnRhYiArIDEsIGpwLT5zdGF0ZSwgc3RhdGUpKTsKKwkJCQkJVFJBQ0UoKCJKb2IgJXRkOiBjaGFu Z2luZyBzdGF0ZSBmcm9tICVkIHRvICVkXG4iLCAocHRyZGlmZl90KShqcCAtIGpvYnRhYiArIDEp LCBqcC0+c3RhdGUsIHN0YXRlKSk7CiAJCQkJCWpwLT5zdGF0ZSA9IHN0YXRlOwogCQkJCQlpZiAo anAgIT0gam9iKSB7CiAJCQkJCQlpZiAoZG9uZSAmJiAhanAtPnJlbWVtYmVyZWQgJiYK --90e6ba212165f607a504926faffc-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 18:56:36 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29AE51065670 for ; Tue, 12 Oct 2010 18:56:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EE0C98FC16 for ; Tue, 12 Oct 2010 18:56:35 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A8DFB46B09; Tue, 12 Oct 2010 14:56:35 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A85838A01D; Tue, 12 Oct 2010 14:56:34 -0400 (EDT) From: John Baldwin To: Garrett Cooper Date: Tue, 12 Oct 2010 14:56:32 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010120830.19872.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201010121456.32819.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 12 Oct 2010 14:56:34 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org, Jilles Tjoelker Subject: Re: [PATCH] Fix /bin/sh compilation with CFLAGS += -DDEBUG > 1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 18:56:36 -0000 On Tuesday, October 12, 2010 2:31:36 pm Garrett Cooper wrote: > On Tue, Oct 12, 2010 at 5:30 AM, John Baldwin wrote: > > You should use %z to print size_t's, but even better is to just use %t > > to print a ptrdiff_t (which is the type that holds the difference of two > > pointers). > > Ok. The overall temperature of using PRI* from POSIX seems like > it's undesirable; is it just POSIX cruft that FreeBSD conforms to in > theory only and doesn't really use in practice, or is there an example > of real practical application where it's used in the sourcebase? PRI* are ugly. FreeBSD provides it so that we are compliant and so that portable code can use it, but we do not use it in our source tree because it is unreadable. > > The various changes in jobs.c should use '%td' as well rather than (int) > > casts. > > Ok. Tested build and runtime on amd64 and tested build-only with i386. Hmm, jobs.c shouldn't need any of the (ptrdiff_t) casts as the expression being printed is already a ptrdiff_t. See this non-debug code in jobs.c for example: int bgcmd(int argc, char **argv) { char s[64]; struct job *jp; ... do { ... fmtstr(s, 64, "[%td] ", jp - jobtab + 1); -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 19:09:56 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 303CE106564A for ; Tue, 12 Oct 2010 19:09:56 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id CBFE38FC0C for ; Tue, 12 Oct 2010 19:09:55 +0000 (UTC) Received: (qmail 25704 invoked by uid 399); 12 Oct 2010 19:09:54 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 12 Oct 2010 19:09:54 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CB4B293.1050505@FreeBSD.org> Date: Tue, 12 Oct 2010 12:10:11 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <1286397912.27308.40.camel@localhost.localdomain> <4CB34BF9.4050504@FreeBSD.org> <1286824968.30494.46.camel@localhost.localdomain> In-Reply-To: <1286824968.30494.46.camel@localhost.localdomain> X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: sysconf -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 19:09:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 [ Snipping the areas in which there is no disagreement ] On 10/11/2010 12:22 PM, Devin Teske wrote: | On Mon, 2010-10-11 at 10:40 -0700, Doug Barton wrote: | | c) misses some knowledge of FreeBSD resources (e.g., mktemp) | |> I'm adding that in now. Good to know. The more you can boil down the critical elements of the tool the easier it will be to review, FYI. If you haven't already, you might review /etc/rc.subr and some of the scripts in /etc/rc.d for an idea of what I mean by "rc.d style." | 5. For those reasons I am not supportive of adding this to the base at | this time | |> I agree. The 1.0 revision posted is not a candidate for base- |> distribution. However, the thread has helped me design the second |> revision around that desire. Please don't focus on "getting something into the base." Focus on producing a good tool. | 7. I agree with the author's statement that in an ideal world the | internals of the script would be added to rc.subr so that they could be | available to the whole rc.d system. | |> And then the script could be programmed to source /etc/rc.subr and |> therefore get even closer to the neighborhood-style of rc.d scripts |> (which do the same). Once again, I'm not sure that having this as a standalone script in the base is the right way to approach this problem. Obviously there is interest in the functionality your script currently provides, and I agree that it's an area worth pursuing. But let's not focus on what the final form _should_ be, since that could prevent us from seeing what it _could_ be. |> Might you have meant "/etc/rc.conf.d/servicename is the last file |> sourced for any given invocation of source_rc_confs()"?? I was going by memory, and may have had some of the details wrong. I think you get the gist of what I am suggesting however. |> So, if someone wants to disable a given service... say, named, it seems |> logical that the _minimum_ that the service(8) script must do is: | |> Either A: | |> Cheat and plop the new value in the last file sourced (in this case, |> appending `named_enable="NO"' to /etc/rc.conf.d/named). | |> or B: | |> 1. Find the last place that it was defined (search in reverse-order) |> 2. Replace the last instance in the last place it was defined | |> Of course, no modification should ever be made to /etc/defaults/rc.conf, |> so it also stands to reason that if the directive is not found, then |> throw it into the first (aka "primary") file (in this case, the first |> file in $rc_conf_files -- usually /etc/rc.conf). I think your analysis is correct, but your conclusion is wrong. There are a lot of reasons why you might not want to modify /etc/rc.conf, the biggest one being what was already discussed in this thread. In large server farms /etc/rc.conf is often under centralized control (using cfengine, or similar) and modifications to it may not be possible, desirable, or persistent. |> If there are multiple instances of definition, only the last such |> definition will be replaced. The end result is that the operation is not |> sloppy, and doesn't result in growing files (that simply appending would |> result in). This argument I'm sort of sympathetic to, but that's also one of the reasons I'm proposing that /etc/rc.conf.d/servicename is the right thing for us to twiddle since it's largely unused atm. |> Also, I wouldn't go much further than the minimum... say in searching |> out all uses and consolidating all occurrences down to one definition in |> a single file. There are times when you do want the duplicate definition |> hanging around. For example, if you've got /etc/rc.conf shared among a |> bevy of machines yet you rely on /etc/rc.conf.local to override values |> specific to the local machine. Yes. | So to summarize, the general idea is a good one and needed, and an area | that I'd like to see more work in. Perhaps it might be a good idea to | move the discussion about that to freebsd-rc@? | |> I'll look into signing up for the rc mailing list (didn't see that when |> I checked last -- I'll have to look again). Maybe I'll post v2.0 to |> there (but will cc back hackers cause I know folks may not be part of |> both). The canonical way to deal with that is to post the message to the proper list (-rc@), then post a brief note to the other list (-hackers@) saying where the discussion is being continued. We discourage people from cc'ing multiple FreeBSD lists. hth, Doug - -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBCAAGBQJMtLKTAAoJEFzGhvEaGryE13IH/3E2rT0CRrO/hm0Ssp/ttgSp dVdYRpWbXLM8ELz6B5jzL9/maJK6mUpqkO6n+89KWFVvNkUnlBE7e4F/OI8q63vA 5273cwJDI1OlIHE2dNYylWbETs9NjdmCthNn6emRtMf++3+1yikSfDt+KaJ9AiNk 7/rus6/3Q7DawBeUlx4RnMTV3bFC/yfwJfvYzve14t0UN//SXw+0EzErbWFWheqD IqEsu9eCZM2tyFNZKORW0IFxvJ/5QT4HqVwnzzSD4NUw5M+pp7u3W06USVV/vl3G +soFPcBANLBlqTN/rTjJ8cJrUpcz1+nXbJ6nVjxVSqKRiCLKId3gkQFLePzwtO8= =6RwN -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 20:30:34 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FD3D1065674; Tue, 12 Oct 2010 20:30:34 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id F3FDE8FC16; Tue, 12 Oct 2010 20:30:33 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 072E1359960; Tue, 12 Oct 2010 22:30:33 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id E7D7A172CD; Tue, 12 Oct 2010 22:30:32 +0200 (CEST) Date: Tue, 12 Oct 2010 22:30:32 +0200 From: Jilles Tjoelker To: Devin Teske Message-ID: <20101012203032.GA22040@stack.nl> References: <1286397912.27308.40.camel@localhost.localdomain> <51B4504F-5AA4-47C5-BF23-FA51DE5BC8C8@vicor.com> <238E0B24-AA12-4684-9651-84DA665BE893@vicor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <238E0B24-AA12-4684-9651-84DA665BE893@vicor.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org, Garrett Cooper Subject: Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 20:30:34 -0000 On Sat, Oct 09, 2010 at 03:39:44PM -0700, Devin Teske wrote: > On Oct 9, 2010, at 1:25 PM, Garrett Cooper wrote: [...] > The second usage (": function") aids in finding the function > declaration among the usages. See, in Perl, I can simply search for > "sub" preceding the function name. In C, I tend to split the return > type from the function name and ensure that the function name always > starts in column-1 so I can search for "^funcname" to go to the > declaration opposed to the usages/references. In BASH, `function' is a > valid keyword and you can say "function funcname ( ) BLOCK" but > unfortunately in good ol' bourne shell, "function" is not an > understood keyword, ... but really liking this keyword, I decided to > make use of it in bourne shell by-way-of simply making it a > non-executed-expression (preceded it with ":" and terminated it with > ";"). I think function f() { ... } is a despicable bashism. In POSIX, an empty pair of parentheses is an unambiguous indication of a function definition; although FreeBSD sh also accepts () as a subshell containing an empty command, there is no reason to use that. In ksh, function f { ... } is different from f() { ... }, so there is a reason to use it, and function f() { ... } does not exist. > I originally had been programming in tests for '!' and 'in', but in > POSIX bourne-shell, they aren't defined (though understood) in the > keyword table (so type(1) balks in bourne-shell while csh and bash do > respond to '!' and 'in' queries). > Since you've pointed out command(1)... I now have a way of checking > '!'. Though unfortunately, "command -v", like type(1), also does not > like "in" (in bourne-shell at least). The type builtin in the original Bourne shell does not know keywords. The type builtin in FreeBSD sh knows them, but unlike most shells "in" is not a keyword -- it is only recognized at the appropriate places in a case or for command (this is probably a POSIX violation and may change in the future). > > "x$fmt" != x ? It seems like it could be simplified to: > > if [ $# -gt 0 ] > > then > > local fmt=$1 > > shift 1 > > eprintf "$fmt\n" "$@" > > fi > > I never understood why people don't trust the tools they are using... > > `[' is very very similar (if not identical) to test(1) > > [ "..." ] is the same thing as [ -n "..." ] or test -n "..." > [ ! "..." ] is the same things as [ -z "..." ] or test -z "..." > > I'll never understand why people have to throw an extra letter in there and then compare it to that letter. > > If the variable expands to nothing, go ahead and let it. I've traced > every possible expansion of variables when used in the following > manner: > [ "$VAR" ] ... > and it never fails. If $VAR is anything but null, the entire > expression will evaluate to true. Right, except in very old implementations if VAR is -t, but those should be extinct and are not worth coding for. However, in some fairly recent implementations [ "$A" = "$B" ] does not work as expected for all values of A and B. For example, FreeBSD 7.0 returns true for A='(' and B=')' because it applies the POSIX rules in the wrong order (certainly, [ '(' "$X" ')' ] is true for most non-empty values of X, but this does not apply if X is an operator). > >> # depend $name [ $dependency ... ] > >> # > >> # Add a dependency. Die with error if dependency is not met. > >> # > >> : dependency checks performed after depend-function declaration > >> : function ; depend ( ) # $name [ $dependency ... ] > >> { > >> local by="$1" arg > >> shift 1 > >> > >> for arg in "$@"; do > >> local d > > Wouldn't it be better to declare this outside of the loop (I'm not > > sure how optimal it is to place it inside the loop)? > I'm assuming you mean the "local d" statement. There's no restriction > that says you have to put your variable declarations at the beginning > of a block (like in C -- even if only within a superficial block { in > the middle of nowhere } ... like that). > Meanwhile, in Perl, it's quite a difference to scope it to the loop > rather than the block. So, it all depends on whichever _looks_ nicer > to you ^_^ Although this works, I do not recommend it. It makes the impression that the variable is scoped to the do block, which is not the case as there is only function scope. Also, FreeBSD sh will register another local variable record if you make the same variable local again (but it will reset the variable to the correct value later). > > I'd say that you have bigger fish to try if your shell lacks the > > needed lexicon to parse built-ins like for, do, local, etc :)... local might be worth checking for as the original Bourne shell and ksh93 don't know it. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 20:34:04 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54E3910656B1 for ; Tue, 12 Oct 2010 20:34:04 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 09B1D8FC1C for ; Tue, 12 Oct 2010 20:34:03 +0000 (UTC) Received: by gyf3 with SMTP id 3so1344591gyf.13 for ; Tue, 12 Oct 2010 13:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=dis/EaE0O4DF+W2WxQ9x7Jeoy2PyIi89Aed9mOVVccI=; b=smx1siD0PBsZTHwgivIsdHzOKQYHBdY163os6LA460r0zDvdH6njjtmrRnyy0CChTh z9+VtwZtVT757e3wr27gHYACp/UJRmzCdxlN7EEb2tWR0kC2MoTbMk/5LZzc5cUktAez EebxjCOPkr29VtDZkiAiCsWC53U5fBOYcyJJc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=MUWAaurxCnFsbrVfMPShGQT0ZU+Rc7c4XgQQlebV534U8yEC1Pd6Zb/LW2G/aoLQzU KmfmSf8YtaC+2w4XSyyKOnrKexNl+uX4KE7QJdCd9iH2CW0SQBfaXw8IAJtsQ6yCpkVa IdfaLmYgDxkh3M4kUCLHCrcIMP5cm/Vhv8/0U= MIME-Version: 1.0 Received: by 10.90.73.9 with SMTP id v9mr3860194aga.89.1286915642947; Tue, 12 Oct 2010 13:34:02 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.90.109.16 with HTTP; Tue, 12 Oct 2010 13:34:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Oct 2010 13:34:02 -0700 X-Google-Sender-Auth: vjs5CFvIeavL0Rxu86fNWV5fVNI Message-ID: From: Garrett Cooper To: Eknath Venkataramani Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: Scheduler Question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 20:34:04 -0000 On Sat, Oct 9, 2010 at 4:46 PM, Eknath Venkataramani wrote: > D&I of the FreeBSD Operating System says it's gonna refer to the BSD default > scheduler, the 'time share scheduler' does this mean sched_4BSD.c(In the > introduction section of Chapter 4) handles only time-share process? > If so, then how (or where) are the kernel processes/real time process > scheduled? The Design and Implementation of the FreeBSD Operating System is unfortunately extremely out of date (my edition which I think is the latest one refers to FreeBSD 5.2). The FreeBSD scheduler was switched over to sched_ule.c as the default scheduler in 7.1. So I'd invest more time in determining how SCHED_ULE works rather than SCHED_4BSD going forward (even though learning about SCHED_4BSD is a good lesson in history of design of FreeBSD). FWIW the algorithm of prioritization, quantization of time slices, etc for SCHED_4BSD are discussed more in depth in the chapter. Cheers, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 23:07:48 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 661DF106566C; Tue, 12 Oct 2010 23:07:48 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mailoutltc.fnis.com (mailoutltc.fnis.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 2D8078FC16; Tue, 12 Oct 2010 23:07:47 +0000 (UTC) Received: from sbhfislrext02.fnfis.com ([192.168.249.140]) by SCSFISLTC01 (8.14.3/8.14.3) with ESMTP id o9CN7X9h002942; Tue, 12 Oct 2010 18:07:33 -0500 Received: from sbhfisltcgw01.FNFIS.COM (Not Verified[10.132.248.121]) by sbhfislrext02.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Tue, 12 Oct 2010 18:07:28 -0500 Received: from SBHFISLTCGW04.FNFIS.COM ([10.132.248.123]) by sbhfisltcgw01.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Oct 2010 18:06:28 -0500 Received: from dt.vicor.com ([10.14.152.1]) by SBHFISLTCGW04.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Oct 2010 18:06:27 -0500 From: Devin Teske To: Doug Barton In-Reply-To: <4CB4B293.1050505@FreeBSD.org> References: <1286397912.27308.40.camel@localhost.localdomain> <4CB34BF9.4050504@FreeBSD.org> <1286824968.30494.46.camel@localhost.localdomain> <4CB4B293.1050505@FreeBSD.org> Content-Type: text/plain Date: Tue, 12 Oct 2010 16:06:25 -0700 Message-Id: <1286924785.32724.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-41.el4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2010 23:06:27.0603 (UTC) FILETIME=[196BDE30:01CB6A62] Cc: freebsd-hackers@freebsd.org, Devin Teske Subject: Re: sysconf -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 23:07:48 -0000 On Tue, 2010-10-12 at 12:10 -0700, Doug Barton wrote: > On 2010-10-11 at 10:40 -0700, Doug Barton wrote: > | So to summarize, the general idea is a good one and needed, and an area > | that I'd like to see more work in. Perhaps it might be a good idea to > | move the discussion about that to freebsd-rc@? > | > |On 2010-10-11 at 12:22 -0700, Devin Teske wrote: > |> I'll look into signing up for the rc mailing list (didn't see that when > |> I checked last -- I'll have to look again). Maybe I'll post v2.0 to > |> there (but will cc back hackers cause I know folks may not be part of > |> both). > > The canonical way to deal with that is to post the message to the proper > list (-rc@), then post a brief note to the other list (-hackers@) saying > where the discussion is being continued. We discourage people from > cc'ing multiple FreeBSD lists. This thread is moving over to the -rc@ list. New thread: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) The first post to the -rc@ list will be version 2.0 of the script which attempts to address the following (which were discussed in this thread here on -hackers@): 1. Style -- remove some personal styles in favor of standardized styles. (the FreeBSD environment doesn't need all the extra things that are required to run in an embedded environment -- which the first version was coded for) 2. Remove a disgusting-amount of comments (the first release of the script had a hurdle to climb in that it had to establish rapport with the targeted audience -- y'all). 3. Remove shell inheritance of SUCCESS/FAILURE (this was silly for a finished product). 4. Remove unnecessary code-sense (some things just don't need to be tested for in a known environment -- such as FreeBSD vs. embedded). 5. Remove dependency checks (have(), depend(), and show_deps() are gone). 6. Remove fake "function" keywords (public objections win) 7. Rename sysrc() function to sysrc_get() to: a. prevent confusion between the script and the internal function b. to coincide with the remainder of related functions (sysrc_get, sysrc_set, sysrc_find, and sysrc_desc). 8. Fix sysrc_get() function to mask positional parameters (don't expand "1", "2", etc.) 9. Fix sysrc_get() function to clean the environment prior to sourcing rc.conf(5) files (preventing expansion of normals such as PS1, TERM, etc.) 10. New function: `sysrc_find $varname' Find which file holds the effective last-assignment to a given variable within the rc.conf(5) file(s). If the variable is found in any of the rc.conf(5) files, the function prints the filename it was found in and then returns success. Otherwise output is NULL and the function returns with error status. 11. Fix sysrc_set() function to use mktemp(1) (prevent race-conditions where sysrc(8) could be executing in concurrence, possibly whacking the output-file in an unexpected manner). 12. New function: `sysrc_desc $varname' Attempts to return the comments associated with varname from the rc.conf (5) defaults file `/etc/defaults/rc.conf' (or whatever RC_DEFAULTS points to). Multi-line comments are joined together. Results are NULL if no description could be found. 13. Use getopts(1) to parse command-line options rather than manually parsing (now we can support grouping of flags -- i.e. "-avN"). 14. Remove `--help' option (using getopts(1) now ... that was the only long-option we had, and we don't need it). 15. Remove `-d' as we know it. No longer dump internal dependency list, but mimick `-d' from sysctl(8) -- Print a description of the given variable. 16. Remove `SYSRC_SHOW_DEPS' environment variable. 17. Add `SYSRC_VERBOSE' environment variable (inheritable from the shell, so that folks whom don't want to always pass `-v' can plop `SYSRC_VERBOSE=1' into their shell startup scripts, `~/.bash_profile' and `~/.profile' for example). 18. Add `-f file' option. Operate on the specified file(s) instead of rc_conf_files. 19. Add `-a' option. Dump a list of non-default configuration variables. 20. Add `-A' option. Dump a list of all configuration variables (incl. defaults). 21. Add `-v' option. Verbose. Print the pathname of the specific rc.conf(5) file where the directive was found. 22. Add `-i' option. Ignore unknown variables. 23. Add `-N' option. Show only variable names, not their values. And, here's the new usage: Usage: sysrc [OPTIONS] name[=value] ... OPTIONS: -h Print this message to stderr and exit. -f file Operate on the specified file(s) instead of rc_conf_files. -a Dump a list of non-default configuration variables. -A Dump a list of all configuration variables (incl. defaults). -d Print a description of the given variable. -e Print query results as `var=value' (useful for producing output to be fed back in). Ignored if -n is specified. -v Verbose. Print the pathname of the specific rc.conf(5) file where the directive was found. -i Ignore unknown variables. -n Show only variable values, not their names. -N Show only variable names, not their values. ENVIRONMENT: RC_DEFAULTS Location of `/etc/defaults/rc.conf' file. SYSRC_VERBOSE Default verbosity. Set to non-NULL to enable. See you all on the -rc@ list. -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> FUN STUFF <- -----BEGIN GEEK CODE BLOCK----- Version 3.1 GAT/CS d(+) s: a- C++(++++) UB++++$ P++(++++) L++(++++) !E--- W++ N? o? K- w O M+ V- PS+ PE Y+ PGP- t(+) 5? X+(++) R>++ tv(+) b+(++) DI+(++) D(+) G+>++ e>+ h r>++ y+ ------END GEEK CODE BLOCK------ http://www.geekcode.com/ -> END TRANSMISSION <- _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________ From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 13 08:11:11 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D0D910656C9; Wed, 13 Oct 2010 08:11:11 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0121F8FC1E; Wed, 13 Oct 2010 08:11:10 +0000 (UTC) Received: by iwn8 with SMTP id 8so7472299iwn.13 for ; Wed, 13 Oct 2010 01:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=OwBzSnGK/+zbgOR2mc/hw0XQhn5aZyN8KpNDtF5oHOI=; b=uBxoAUyQo6RxWm5XXestKLcQcbONov3qP7Pb2qYsaQxBiB+hn3mRTVFIVQhBfNrTDt JPu1SaQvUPX5gvgXxm3yQPrHvPWG5CUzrRj103t6xr5CIfKmFn9Jf494JkMAhqlo7wkt KiZ8//8cVv3eCy4E7SeOiNbJ39vKhUKqQ8KMQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aAdL9A/ZLBOXz44WA2jCQGbU1QUaiu91zlHIB4zgWBP7jrN63z+91h53wWtDkz/U3T X51CbT7vrgCfZ9yQCAJ7sUOiPiieCq5iMOezifJtZsyYysKIV8hq/TADxvAgNwIFEMH1 V9NjnjEcFSlLRsFpjm5SdSVRoc60aFBj/ond8= MIME-Version: 1.0 Received: by 10.42.1.1 with SMTP id 1mr3376791ice.8.1286957470300; Wed, 13 Oct 2010 01:11:10 -0700 (PDT) Received: by 10.231.184.3 with HTTP; Wed, 13 Oct 2010 01:11:10 -0700 (PDT) In-Reply-To: <201010121456.32819.jhb@freebsd.org> References: <201010120830.19872.jhb@freebsd.org> <201010121456.32819.jhb@freebsd.org> Date: Wed, 13 Oct 2010 01:11:10 -0700 Message-ID: From: Garrett Cooper To: John Baldwin Content-Type: multipart/mixed; boundary=00235448f209dbbba804927b2298 Cc: freebsd-hackers@freebsd.org, Jilles Tjoelker Subject: Re: [PATCH] Fix /bin/sh compilation with CFLAGS += -DDEBUG > 1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 08:11:11 -0000 --00235448f209dbbba804927b2298 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Oct 12, 2010 at 11:56 AM, John Baldwin wrote: > On Tuesday, October 12, 2010 2:31:36 pm Garrett Cooper wrote: >> On Tue, Oct 12, 2010 at 5:30 AM, John Baldwin wrote: >> > You should use %z to print size_t's, but even better is to just use %t >> > to print a ptrdiff_t (which is the type that holds the difference of t= wo >> > pointers). >> >> =A0 =A0 Ok. The overall temperature of using PRI* from POSIX seems like >> it's undesirable; is it just POSIX cruft that FreeBSD conforms to in >> theory only and doesn't really use in practice, or is there an example >> of real practical application where it's used in the sourcebase? > > PRI* are ugly. =A0FreeBSD provides it so that we are compliant and so tha= t > portable code can use it, but we do not use it in our source tree because > it is unreadable. Ok, I'll keep that in mind. >> > The various changes in jobs.c should use '%td' as well rather than (in= t) >> > casts. >> >> =A0 =A0 Ok. Tested build and runtime on amd64 and tested build-only with= i386. > > Hmm, jobs.c shouldn't need any of the (ptrdiff_t) casts as the expression > being printed is already a ptrdiff_t. =A0See this non-debug code in jobs.= c > for example: Good catch. Here's another patch minus the ptrdiff_t casts (again, builds just fine on i386, and runs perfectly fine on amd64). As you can probably tell, I haven't used the ptrdiff_t typedef before :). Thanks! -Garrett --00235448f209dbbba804927b2298 Content-Type: application/octet-stream; name="fix-bin-sh-DEBUG-functionality.diff" Content-Disposition: attachment; filename="fix-bin-sh-DEBUG-functionality.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gf7x6k9b0 SW5kZXg6IGJpbi9zaC9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBiaW4vc2gvTWFrZWZpbGUJKHJl dmlzaW9uIDIxMzY4MCkKKysrIGJpbi9zaC9NYWtlZmlsZQkod29ya2luZyBjb3B5KQpAQCAtMjEs NyArMjEsNyBAQAogTEZMQUdTPSAtOAkjIDgtYml0IGxleCBzY2FubmVyIGZvciBhcml0aG1ldGlj CiBDRkxBR1MrPS1EU0hFTEwgLUkuIC1JJHsuQ1VSRElSfQogIyBmb3IgZGVidWc6Ci0jIENGTEFH Uys9IC1nIC1EREVCVUc9MgorI0RFQlVHX0ZMQUdTKz0JLWcgLURERUJVRz0yCiBXQVJOUz89CTIK IFdGT1JNQVQ9MAogCkluZGV4OiBiaW4vc2gvZXhwYW5kLmMKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gYmluL3No L2V4cGFuZC5jCShyZXZpc2lvbiAyMTM2ODApCisrKyBiaW4vc2gvZXhwYW5kLmMJKHdvcmtpbmcg Y29weSkKQEAgLTQzLDE0ICs0MywxNSBAQAogI2luY2x1ZGUgPHN5cy90eXBlcy5oPgogI2luY2x1 ZGUgPHN5cy90aW1lLmg+CiAjaW5jbHVkZSA8c3lzL3N0YXQuaD4KKyNpbmNsdWRlIDxkaXJlbnQu aD4KICNpbmNsdWRlIDxlcnJuby5oPgotI2luY2x1ZGUgPGRpcmVudC5oPgotI2luY2x1ZGUgPHVu aXN0ZC5oPgorI2luY2x1ZGUgPGludHR5cGVzLmg+CisjaW5jbHVkZSA8bGltaXRzLmg+CiAjaW5j bHVkZSA8cHdkLmg+CisjaW5jbHVkZSA8c3RkaW8uaD4KICNpbmNsdWRlIDxzdGRsaWIuaD4KLSNp bmNsdWRlIDxsaW1pdHMuaD4KLSNpbmNsdWRlIDxzdGRpby5oPgogI2luY2x1ZGUgPHN0cmluZy5o PgorI2luY2x1ZGUgPHVuaXN0ZC5oPgogCiAvKgogICogUm91dGluZXMgdG8gZXhwYW5kIGFyZ3Vt ZW50cyB0byBjb21tYW5kcy4gIFdlIGhhdmUgdG8gZGVhbCB3aXRoCkBAIC00OTcsOSArNDk4LDkg QEAKIAkJZXhpdHN0YXR1cyA9IHdhaXRmb3Jqb2IoaW4uanAsIChpbnQgKilOVUxMKTsKIAlpZiAo cXVvdGVkID09IDApCiAJCXJlY29yZHJlZ2lvbihzdGFydGxvYywgZGVzdCAtIHN0YWNrYmxvY2so KSwgMCk7Ci0JVFJBQ0UoKCJldmFsYmFja3E6IHNpemU9JWQ6IFwiJS4qc1wiXG4iLAotCQkoZGVz dCAtIHN0YWNrYmxvY2soKSkgLSBzdGFydGxvYywKLQkJKGRlc3QgLSBzdGFja2Jsb2NrKCkpIC0g c3RhcnRsb2MsCisJVFJBQ0UoKCJleHBiYWNrcTogc2l6ZT0ldGQ6IFwiJS4qc1wiXG4iLAorCQko KGRlc3QgLSBzdGFja2Jsb2NrKCkpIC0gc3RhcnRsb2MpLAorCQkoaW50KSAoKGRlc3QgLSBzdGFj a2Jsb2NrKCkpIC0gc3RhcnRsb2MpLAogCQlzdGFja2Jsb2NrKCkgKyBzdGFydGxvYykpOwogCWV4 cGRlc3QgPSBkZXN0OwogCUlOVE9OOwpJbmRleDogYmluL3NoL2pvYnMuYwo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBiaW4vc2gvam9icy5jCShyZXZpc2lvbiAyMTM2ODApCisrKyBiaW4vc2gvam9icy5jCSh3b3Jr aW5nIGNvcHkpCkBAIC0zOCwxOCArMzgsMTggQEAKICNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KIF9f RkJTRElEKCIkRnJlZUJTRCQiKTsKIAorI2luY2x1ZGUgPHN5cy9pb2N0bC5oPgorI2luY2x1ZGUg PHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9yZXNvdXJjZS5oPgorI2luY2x1ZGUgPHN5cy9z dGRkZWYuaD4KKyNpbmNsdWRlIDxzeXMvdGltZS5oPgorI2luY2x1ZGUgPHN5cy93YWl0Lmg+Cisj aW5jbHVkZSA8ZXJybm8uaD4KICNpbmNsdWRlIDxmY250bC5oPgorI2luY2x1ZGUgPHBhdGhzLmg+ CiAjaW5jbHVkZSA8c2lnbmFsLmg+Ci0jaW5jbHVkZSA8ZXJybm8uaD4KLSNpbmNsdWRlIDxwYXRo cy5oPgorI2luY2x1ZGUgPHN0ZGxpYi5oPgogI2luY2x1ZGUgPHVuaXN0ZC5oPgotI2luY2x1ZGUg PHN0ZGxpYi5oPgotI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgotI2luY2x1ZGUgPHN5cy93YWl0Lmg+ Ci0jaW5jbHVkZSA8c3lzL3RpbWUuaD4KLSNpbmNsdWRlIDxzeXMvcmVzb3VyY2UuaD4KLSNpbmNs dWRlIDxwYXRocy5oPgotI2luY2x1ZGUgPHN5cy9pb2N0bC5oPgogCiAjaW5jbHVkZSAic2hlbGwu aCIKICNpZiBKT0JTCkBAIC02ODAsNyArNjgwLDcgQEAKIAkJanAtPnBzID0gJmpwLT5wczA7CiAJ fQogCUlOVE9OOwotCVRSQUNFKCgibWFrZWpvYiglcCwgJWQpIHJldHVybnMgJSUlZFxuIiwgKHZv aWQgKilub2RlLCBucHJvY3MsCisJVFJBQ0UoKCJtYWtlam9iKCVwLCAlZCkgcmV0dXJucyAlJSV0 ZFxuIiwgKHZvaWQgKilub2RlLCBucHJvY3MsCiAJICAgIGpwIC0gam9idGFiICsgMSkpOwogCXJl dHVybiBqcDsKIH0KQEAgLTc2Niw3ICs3NjYsNyBAQAogCXBpZF90IHBpZDsKIAlwaWRfdCBwZ3Jw OwogCi0JVFJBQ0UoKCJmb3Jrc2hlbGwoJSUlZCwgJXAsICVkKSBjYWxsZWRcbiIsIGpwIC0gam9i dGFiLCAodm9pZCAqKW4sCisJVFJBQ0UoKCJmb3Jrc2hlbGwoJSUldGQsICVwLCAlZCkgY2FsbGVk XG4iLCBqcCAtIGpvYnRhYiwgKHZvaWQgKiluLAogCSAgICBtb2RlKSk7CiAJSU5UT0ZGOwogCWlm IChtb2RlID09IEZPUktfQkcpCkBAIC05MDMsNyArOTAzLDcgQEAKIAlpbnQgc3Q7CiAKIAlJTlRP RkY7Ci0JVFJBQ0UoKCJ3YWl0Zm9yam9iKCUlJWQpIGNhbGxlZFxuIiwganAgLSBqb2J0YWIgKyAx KSk7CisJVFJBQ0UoKCJ3YWl0Zm9yam9iKCUlJXRkKSBjYWxsZWRcbiIsIGpwIC0gam9idGFiICsg MSkpOwogCXdoaWxlIChqcC0+c3RhdGUgPT0gMCkKIAkJaWYgKGRvd2FpdCgxLCBqcCkgPT0gLTEp CiAJCQlkb3RyYXAoKTsKQEAgLTEwMDQsNyArMTAwNCw3IEBACiAJCQlpZiAoc3RvcHBlZCkgewkJ Lyogc3RvcHBlZCBvciBkb25lICovCiAJCQkJaW50IHN0YXRlID0gZG9uZT8gSk9CRE9ORSA6IEpP QlNUT1BQRUQ7CiAJCQkJaWYgKGpwLT5zdGF0ZSAhPSBzdGF0ZSkgewotCQkJCQlUUkFDRSgoIkpv YiAlZDogY2hhbmdpbmcgc3RhdGUgZnJvbSAlZCB0byAlZFxuIiwganAgLSBqb2J0YWIgKyAxLCBq cC0+c3RhdGUsIHN0YXRlKSk7CisJCQkJCVRSQUNFKCgiSm9iICV0ZDogY2hhbmdpbmcgc3RhdGUg ZnJvbSAlZCB0byAlZFxuIiwganAgLSBqb2J0YWIgKyAxLCBqcC0+c3RhdGUsIHN0YXRlKSk7CiAJ CQkJCWpwLT5zdGF0ZSA9IHN0YXRlOwogCQkJCQlpZiAoanAgIT0gam9iKSB7CiAJCQkJCQlpZiAo ZG9uZSAmJiAhanAtPnJlbWVtYmVyZWQgJiYK --00235448f209dbbba804927b2298-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 13 18:01:10 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F9491065679; Wed, 13 Oct 2010 18:01:10 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from pikmeer.webweaving.org (pikmeer.webweaving.org [213.207.101.183]) by mx1.freebsd.org (Postfix) with ESMTP id DBC9F8FC0A; Wed, 13 Oct 2010 18:01:09 +0000 (UTC) Received: from neep.dmi.dev.local (ge2-0.rt2.rbsov.bbc.co.uk [212.58.239.38]) (authenticated bits=0) by pikmeer.webweaving.org (8.14.4/8.14.4) with ESMTP id o9DHJdZm015701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Oct 2010 17:19:40 GMT (envelope-from dirkx@webweaving.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dirk-Willem van Gulik In-Reply-To: <201010111214.11698.jhb@freebsd.org> Date: Wed, 13 Oct 2010 18:29:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0726C125-A94F-41F8-8A4C-8FBAF072ED03@webweaving.org> References: <4CB22E79.2010202@freebsd.org> <201010111214.11698.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (pikmeer.webweaving.org [213.207.101.183]); Wed, 13 Oct 2010 17:19:40 +0000 (UTC) Cc: freebsd-hackers@freebsd.org Subject: Re: anyone got advice on sendmail and TLS on 8.1? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 18:01:10 -0000 On 11 Oct 2010, at 17:14, John Baldwin wrote: >> TLS and authenticated email submission by me and my family >> able to forward the email anywhere (maybe just to my ISP but who=20 >> knows) (outgoing) >> non TLS submission from outside to reject all mail not to=20 >> elischer.{org,com} >> and deliver our mail to mailboxes or gmail (or where-ever = /etc/aliases=20 >> says.). I do pretty much this; from my *.mc: 1. Keys as usual - with limited CA trusted=20 define(`confCACERT', `/etc/pikmeer.webweaving.org.pem') define(`confCACERT_PATH', `/etc/ca-trusted') define(`confSERVER_CERT', `/etc/pikmeer.webweaving.org.pem') define(`confSERVER_KEY', `/etc/pikmeer.webweaving.org.key') And then at the bottom: dnl accept signed certs too - equivalent to SASL authenticated LOCAL_RULESETS SLocal_check_rcpt R$* $: $&{verify} ROK $# OK And then in the access file or ct/cw file just allow relay for , in your = case, elisher. I do the verify as a local ruleset - as I also allow a = SASL=20 TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5') define(`confAUTH_MECHANISMS', `DIGEST-MD5 CRAM-MD5 ') dnl define(`confDEF_AUTH_INFO', `/etc/mail/auth-info') define(`confDONT_BLAME_SENDMAIL',`GroupReadableSASLDBFile') define(`confDONT_BLAME_SENDMAIL',`GroupReadableSASLFile') define(`confRUN_AS_USER',`root:mail') on any SSL inbounds in lieu of a cert. Dw.= From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 13 21:30:21 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4186B106564A for ; Wed, 13 Oct 2010 21:30:21 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E8A8A8FC1C for ; Wed, 13 Oct 2010 21:30:20 +0000 (UTC) Received: by iwn8 with SMTP id 8so8418646iwn.13 for ; Wed, 13 Oct 2010 14:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=wkO7ifP9PIcdjkJHD91Ps31tQ3iQdbgcOE09ahp5XNw=; b=hu1E50Mukm07nQeErHxwxX5Yge7ixCaohQQ1dUx8GuQvLMucFFpg5abbFDVKKOzMy7 IE7aT6Acy95xHdcpA6K1o+L4gf5AgbG2hKrP1ccH47f5eFSj97K4ihsFttAa79Yvgslq ktI5O50+rYdq2FK8oomjBwnpT7BQ7PsCZ5U7g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=pbGj8jaZTRnVt7yIAid0SVzOI1E1ShXTcM44zxCTXALEh36DTreZOSM7dHdmB3nlco lRUne168t7ENeTqsISY7FhrHLT01pGlGYmCjOFlFtsmx6ZAlm+4fM8qy/9i66xlDMdMH UMu8Us+FQ6/UUWNgPQWHkDAsqQcw64XE+/IQ8= MIME-Version: 1.0 Received: by 10.231.190.75 with SMTP id dh11mr7511261ibb.189.1287005420235; Wed, 13 Oct 2010 14:30:20 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Wed, 13 Oct 2010 14:30:20 -0700 (PDT) Date: Wed, 13 Oct 2010 14:30:20 -0700 X-Google-Sender-Auth: OqgcuDoOxdnBe780JIPBdJ120Ls Message-ID: From: Garrett Cooper To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=0016367b6ecce5ae790492864c55 Subject: [PATCH] Bug with powerof2 macro in sys/param.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 21:30:21 -0000 --0016367b6ecce5ae790492864c55 Content-Type: text/plain; charset=ISO-8859-1 I was talking to someone today about this macro, and he noted that the algorithm is incorrect -- it fails the base case with ((x) == 0 -- which makes sense because 2^(x) cannot equal 0 (mathematically impossible, unless you consider the limit as x goes to negative infinity as log (0) / log(2) is undefined). I tested out his claim and he was right: $ ./test_powerof2 Assertion failed: (!powerof2(0)), function main, file test_powerof2.c, line 7. Abort trap: 6 (core dumped) Applying the following patch, everything's correct with the testcase I've written: $ ./test_powerof2 $ There are a few different places in the sourcebase where this macro is used, so I'm a bit wary of the implications of having this patch be committed because this might break functionality somewhere critical: sys/dev/cas/if_cas.c: CTASSERT(powerof2(n) && (n) >= (min) && (n) <= (max)) This is ok. sys/dev/aic7xxx/aic79xx.c: while (powerof2(sg_prefetch_align) == 0) This is ok. sys/dev/md/md.c: if (mdio->md_sectorsize != 0 && !powerof2(mdio->md_sectorsize)) This is fixed (attached). sys/dev/mpt/mpt_raid.c: powerof2(vol_pg->VolumeSettings.HotSparePool) This is ok. sys/dev/mpt/mpt_raid.c: powerof2(disk_pg->PhysDiskSettings.HotSparePool) This is ok. sys/dev/gem/if_gem.c:CTASSERT(powerof2(GEM_NRXDESC) && GEM_NRXDESC >= 32 && GEM_NRXDESC <= 8192); This is ok. sys/dev/gem/if_gem.c:CTASSERT(powerof2(GEM_NTXDESC) && GEM_NTXDESC >= 32 && GEM_NTXDESC <= 8192); This is ok. sys/dev/pci/pci.c: if (!powerof2(actual)) This looks ok. sys/dev/cxgb/cxgb_sge.c: while (!powerof2(fl_q_size)) sys/dev/cxgb/cxgb_sge.c: while (!powerof2(jumbo_q_size)) I don't feel comfortable enough to state whether or not these are problems. sys/dev/hme/if_hme.c:CTASSERT(powerof2(HME_NRXDESC) && HME_NRXDESC >= 32 && HME_NRXDESC <= 256); This is ok. sys/x86/x86/local_apic.c: KASSERT(powerof2(divisor), ("lapic: invalid divisor %u", divisor)); This is ok. sys/x86/x86/local_apic.c: KASSERT(powerof2(count), ("bad count")); This could be bad if msix is released and this was called, if I was reading the code correctly. sys/x86/x86/local_apic.c: KASSERT(powerof2(align), ("bad align")); This could be bad if msix is released and this was called, if I was reading the code correctly. sys/net/flowtable.c: ft->ft_lock_count = 2*(powerof2(mp_maxid + 1) ? (mp_maxid + 1): This could be bad. sys/geom/gate/g_gate.c: if (ggio->gctl_sectorsize > 0 && !powerof2(ggio->gctl_sectorsize)) { This is ok. sys/geom/stripe/g_stripe.c: if (!powerof2(md->md_stripesize)) { Not sure. sys/geom/geom_redboot.c: if (powerof2(cp->provider->mediasize)) Not sure. sys/i386/i386/i686_mem.c: powerof2((len)) && /* ... and power of two */ \ This is ok. sys/i386/i386/k6_mem.c: if (desc->mr_len < 131072 || !powerof2(desc->mr_len)) This is ok. sys/i386/pci/pci_pir.c: if (pci_link->pl_irqmask != 0 && powerof2(pci_link->pl_irqmask)) This is fixed (attached). sys/i386/pci/pci_pir.c: if (error && !powerof2(pci_link->pl_irqmask)) { Not sure. sys/netinet6/ip6_input.c: if (!powerof2(V_ip6_output_flowtable_size)) { This is ok. sys/amd64/amd64/amd64_mem.c: powerof2((len)) && /* ... and power of two */ \ This is ok. usr.sbin/mptutil/mpt_config.c:#define powerof2(x) ((((x)-1)&(x))==0) This is fixed (attached). usr.sbin/mptutil/mpt_config.c: if ((stripe_size < 512) || (!powerof2(stripe_size))) { This is fixed (attached). usr.sbin/mfiutil/mfi_config.c:#define powerof2(x) ((((x)-1)&(x))==0) This is fixed (attached). Could someone please review these patches and help me commit them? I'm testing out the patches I can (the amd64 and msi and net ones). Thanks, -Garrett --0016367b6ecce5ae790492864c55 Content-Type: text/x-patch; charset=US-ASCII; name="fix-sys-param-powerof2-macro-when-x-equals-zero.patch" Content-Disposition: attachment; filename="fix-sys-param-powerof2-macro-when-x-equals-zero.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gf8nmnqk0 SW5kZXg6IHN5cy9zeXMvcGFyYW0uaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvc3lzL3BhcmFtLmgJKHJl dmlzaW9uIDIxMTc2NykKKysrIHN5cy9zeXMvcGFyYW0uaAkod29ya2luZyBjb3B5KQpAQCAtMjU0 LDcgKzI1NCw3IEBACiAjZGVmaW5lCXJvdW5kZG93bih4LCB5KQkoKCh4KS8oeSkpKih5KSkKICNk ZWZpbmUJcm91bmR1cCh4LCB5KQkoKCgoeCkrKCh5KS0xKSkvKHkpKSooeSkpICAvKiB0byBhbnkg eSAqLwogI2RlZmluZQlyb3VuZHVwMih4LCB5KQkoKCh4KSsoKHkpLTEpKSYofigoeSktMSkpKSAv KiBpZiB5IGlzIHBvd2VycyBvZiB0d28gKi8KLSNkZWZpbmUgcG93ZXJvZjIoeCkJKCgoKHgpLTEp Jih4KSk9PTApCisjZGVmaW5lIHBvd2Vyb2YyKHgpCSgoeCkgIT0gMCAmJiAoKCgoeCktMSkmKHgp KT09MCkpCiAKIC8qIE1hY3JvcyBmb3IgbWluL21heC4gKi8KICNkZWZpbmUJTUlOKGEsYikgKCgo YSk8KGIpKT8oYSk6KGIpKQo= --0016367b6ecce5ae790492864c55 Content-Type: application/octet-stream; name="test_powerof2.c" Content-Disposition: attachment; filename="test_powerof2.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gf8npk301 I2luY2x1ZGUgPHN5cy9wYXJhbS5oPgojaW5jbHVkZSA8YXNzZXJ0Lmg+CgppbnQKbWFpbih2b2lk KQp7Cglhc3NlcnQgKCFwb3dlcm9mMigwKSk7Cglhc3NlcnQgKHBvd2Vyb2YyKDEpKTsKCWFzc2Vy dCAocG93ZXJvZjIoMikpOwoJYXNzZXJ0ICghcG93ZXJvZjIoMykpOwoJYXNzZXJ0ICghcG93ZXJv ZjIoNSkpOwoJYXNzZXJ0IChwb3dlcm9mMig4KSk7CglyZXR1cm4gKDApOwp9Cg== --0016367b6ecce5ae790492864c55 Content-Type: text/x-patch; charset=US-ASCII; name="mfiutil+mptutil-use-sys-param-powerof2.patch" Content-Disposition: attachment; filename="mfiutil+mptutil-use-sys-param-powerof2.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gf8nx1wt2 SW5kZXg6IHVzci5zYmluL21maXV0aWwvbWZpX2NvbmZpZy5jCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHVzci5z YmluL21maXV0aWwvbWZpX2NvbmZpZy5jCShyZXZpc2lvbiAyMTE3NjcpCisrKyB1c3Iuc2Jpbi9t Zml1dGlsL21maV9jb25maWcuYwkod29ya2luZyBjb3B5KQpAQCAtMjksNiArMjksNyBAQAogICog JEZyZWVCU0QkCiAgKi8KIAorI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgogI2luY2x1ZGUgPHN5cy90 eXBlcy5oPgogI2lmZGVmIERFQlVHCiAjaW5jbHVkZSA8c3lzL3N5c2N0bC5oPgpAQCAtNTIsOCAr NTMsNiBAQAogc3RhdGljIGludAlhZGRfc3BhcmUoaW50IGFjLCBjaGFyICoqYXYpOwogc3RhdGlj IGludAlyZW1vdmVfc3BhcmUoaW50IGFjLCBjaGFyICoqYXYpOwogCi0jZGVmaW5lIHBvd2Vyb2Yy KHgpICAgICgoKCh4KS0xKSYoeCkpPT0wKQotCiBzdGF0aWMgbG9uZwogZGVodW1hbml6ZShjb25z dCBjaGFyICp2YWx1ZSkKIHsKSW5kZXg6IHVzci5zYmluL21wdHV0aWwvbXB0X2NvbmZpZy5jCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIHVzci5zYmluL21wdHV0aWwvbXB0X2NvbmZpZy5jCShyZXZpc2lvbiAyMTE3 NjcpCisrKyB1c3Iuc2Jpbi9tcHR1dGlsL21wdF9jb25maWcuYwkod29ya2luZyBjb3B5KQpAQCAt NTAsOCArNTAsNiBAQAogc3RhdGljIHZvaWQJZHVtcF9jb25maWcoQ09ORklHX1BBR0VfUkFJRF9W T0xfMCAqdm9sKTsKICNlbmRpZgogCi0jZGVmaW5lIHBvd2Vyb2YyKHgpICAgICgoKCh4KS0xKSYo eCkpPT0wKQotCiBzdGF0aWMgbG9uZwogZGVodW1hbml6ZShjb25zdCBjaGFyICp2YWx1ZSkKIHsK --0016367b6ecce5ae790492864c55 Content-Type: text/x-patch; charset=US-ASCII; name="sys-md-md-fix-powerof2-invocation.patch" Content-Disposition: attachment; filename="sys-md-md-fix-powerof2-invocation.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gf8o0v5h3 SW5kZXg6IHN5cy9kZXYvbWQvbWQuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvZGV2L21kL21kLmMJKHJl dmlzaW9uIDIxMTc2NykKKysrIHN5cy9kZXYvbWQvbWQuYwkod29ya2luZyBjb3B5KQpAQCAtODMy LDcgKzgzMiw3IEBACiAJZXJyb3IgPSAwOwogCWlmIChtZGlvLT5tZF9vcHRpb25zICYgfihNRF9B VVRPVU5JVCB8IE1EX0NPTVBSRVNTIHwgTURfUkVTRVJWRSkpCiAJCXJldHVybiAoRUlOVkFMKTsK LQlpZiAobWRpby0+bWRfc2VjdG9yc2l6ZSAhPSAwICYmICFwb3dlcm9mMihtZGlvLT5tZF9zZWN0 b3JzaXplKSkKKwlpZiAoIXBvd2Vyb2YyKG1kaW8tPm1kX3NlY3RvcnNpemUpKQogCQlyZXR1cm4g KEVJTlZBTCk7CiAJLyogQ29tcHJlc3Npb24gZG9lc24ndCBtYWtlIHNlbnNlIGlmIHdlIGhhdmUg cmVzZXJ2ZWQgc3BhY2UgKi8KIAlpZiAobWRpby0+bWRfb3B0aW9ucyAmIE1EX1JFU0VSVkUpCg== --0016367b6ecce5ae790492864c55 Content-Type: text/x-patch; charset=US-ASCII; name="sys-i386-pci-pci_pir-remove-unnecessary-powerof2-clause.patch" Content-Disposition: attachment; filename="sys-i386-pci-pci_pir-remove-unnecessary-powerof2-clause.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gf8pce9p4 SW5kZXg6IHN5cy9pMzg2L3BjaS9wY2lfcGlyLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2kzODYvcGNp L3BjaV9waXIuYwkocmV2aXNpb24gMjEzODAyKQorKysgc3lzL2kzODYvcGNpL3BjaV9waXIuYwko d29ya2luZyBjb3B5KQpAQCAtNTI2LDcgKzUyNiw3IEBACiAJICogSVJRcyIgc2V0LgogCSAqLwog CWlmICghUENJX0lOVEVSUlVQVF9WQUxJRChwY2lfbGluay0+cGxfaXJxKSkgewotCQlpZiAocGNp X2xpbmstPnBsX2lycW1hc2sgIT0gMCAmJiBwb3dlcm9mMihwY2lfbGluay0+cGxfaXJxbWFzaykp CisJCWlmIChwb3dlcm9mMihwY2lfbGluay0+cGxfaXJxbWFzaykpCiAJCQlpcnEgPSBmZnMocGNp X2xpbmstPnBsX2lycW1hc2spIC0gMTsKIAkJZWxzZQogCQkJaXJxID0gcGNpX3Bpcl9jaG9vc2Vf aXJxKHBjaV9saW5rLAo= --0016367b6ecce5ae790492864c55-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 14 11:58:36 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 509FA1065675; Thu, 14 Oct 2010 11:58:36 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6927A8FC1B; Thu, 14 Oct 2010 11:58:34 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA02566; Thu, 14 Oct 2010 14:58:32 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CB6F068.1070406@icyb.net.ua> Date: Thu, 14 Oct 2010 14:58:32 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Garrett Cooper References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: [PATCH] Bug with powerof2 macro in sys/param.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 11:58:36 -0000 on 14/10/2010 00:30 Garrett Cooper said the following: > I was talking to someone today about this macro, and he noted that > the algorithm is incorrect -- it fails the base case with ((x) == 0 -- > which makes sense because 2^(x) cannot equal 0 (mathematically > impossible, unless you consider the limit as x goes to negative > infinity as log (0) / log(2) is undefined). I tested out his claim and > he was right: That's kind of obvious given the code. I think that this might be an intentional optimization. I guess that it doesn't really make sense to apply powerof2 to zero and the users of the macro should do the check on their own if they expect zero as input (many places in the do not allow that). -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 14 14:25:06 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF2E6106566C; Thu, 14 Oct 2010 14:25:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AA8588FC1E; Thu, 14 Oct 2010 14:25:06 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5FB4146C04; Thu, 14 Oct 2010 10:25:06 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 547398A01D; Thu, 14 Oct 2010 10:25:05 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 14 Oct 2010 09:37:51 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CB6F068.1070406@icyb.net.ua> In-Reply-To: <4CB6F068.1070406@icyb.net.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010140937.51953.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 14 Oct 2010 10:25:05 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Andriy Gapon , Garrett Cooper Subject: Re: [PATCH] Bug with powerof2 macro in sys/param.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 14:25:07 -0000 On Thursday, October 14, 2010 7:58:32 am Andriy Gapon wrote: > on 14/10/2010 00:30 Garrett Cooper said the following: > > I was talking to someone today about this macro, and he noted that > > the algorithm is incorrect -- it fails the base case with ((x) == 0 -- > > which makes sense because 2^(x) cannot equal 0 (mathematically > > impossible, unless you consider the limit as x goes to negative > > infinity as log (0) / log(2) is undefined). I tested out his claim and > > he was right: > > That's kind of obvious given the code. > I think that this might be an intentional optimization. > I guess that it doesn't really make sense to apply powerof2 to zero and the users > of the macro should do the check on their own if they expect zero as input (many > places in the do not allow that). I agree, the current macro is this way on purpose (and straight out of "Hacker's Delight"). Of the existing calls you weren't sure of: sys/dev/cxgb/cxgb_sge.c: while (!powerof2(fl_q_size)) sys/dev/cxgb/cxgb_sge.c: while (!powerof2(jumbo_q_size)) These are fine, will not be zero. sys/x86/x86/local_apic.c: KASSERT(powerof2(count), ("bad count")); sys/x86/x86/local_apic.c: KASSERT(powerof2(align), ("bad align")); These are fine. No code allocates zero IDT vectors. We never allocate IDT vectors for unallocated MSI or MSI-X IRQs. sys/net/flowtable.c: ft->ft_lock_count = 2*(powerof2(mp_maxid + 1) ? (mp_maxid + 1): Clearly, 'mp_maxid + 1' will not be zero (barring a bizarre overflow case which will not happen until we support 2^32 CPUs), so this is fine. sys/i386/pci/pci_pir.c: if (error && !powerof2(pci_link->pl_irqmask)) { This fine. Earlier in the function if pl_irqmask is zero, then all of the pci_pir_choose_irq() calls will fail, so this is only invoked if pl_irqmask is non-zero. In practice pl_irqmask is never zero anyway. I suspect the GEOM ones are also generally safe. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 14 20:38:47 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0006B10656A3 for ; Thu, 14 Oct 2010 20:38:46 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id A15728FC0A for ; Thu, 14 Oct 2010 20:38:46 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id o9EKNNrh044740 for ; Thu, 14 Oct 2010 15:23:23 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id o9EKNNds044739 for hackers@freebsd.org; Thu, 14 Oct 2010 15:23:23 -0500 (CDT) (envelope-from brooks) Date: Thu, 14 Oct 2010 15:23:23 -0500 From: Brooks Davis To: hackers@freebsd.org Message-ID: <20101014202323.GD42797@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ey/N+yb7u/X9mFhi" Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Thu, 14 Oct 2010 15:23:24 -0500 (CDT) Cc: Subject: negative permission scanner for periodic/security X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 20:38:47 -0000 --ey/N+yb7u/X9mFhi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable One of the side effects of increasing NGROUPS_MAX is that it's possible for a process to be in more groups that can be transmitted over NFS (<4). When that happens users are mostly denied access to things they should have access to. However, permission evaluation order in unix means that groups can be denied access to files the world can read using so called negative permissions. I've written a scanner (derived from 100.chksetuid) for the periodic security script to flag such files as they post a security risk (and nearly all the time are errors). I've not bothered looking for negative user permissions as that isn't broken over NFS and assuming the file is not on a read-only FS the user can just give theselves permissions again. One minor note: Before enabling this by default, ~6 files in the ports repo need fixing as they have world execute bits without user or group execute bits. Should this be enabled by default? It think so, but welcome discussion. -- Brooks --- /dev/null 2010-10-13 05:11:00.000000000 -0500 +++ etc/periodic/security/110.neggrpperm 2010-10-13 03:00:17.000000000 -0500 @@ -0,0 +1,54 @@ +#!/bin/sh - +# +# Copyright (c) 2001 The FreeBSD Project +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# 1. Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# 2. Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in the +# documentation and/or other materials provided with the distribution. +# +# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND +# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPO= SE +# ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE +# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTI= AL +# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRI= CT +# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +# SUCH DAMAGE. +# +# $FreeBSD$ +# + +# If there is a global system configuration file, suck it in. +# +if [ -r /etc/defaults/periodic.conf ] +then + . /etc/defaults/periodic.conf + source_periodic_confs +fi + +rc=3D0 + +case "$daily_status_security_neggrpperm_enable" in + [Yy][Ee][Ss]) + echo "" + echo 'Checking negative group permissions:' + MP=3D`mount -t ufs,zfs | awk '$0 !~ /no(suid|exec)/ { print $3 }'` + n=3D$(find -sx $MP /dev/null -type f \ + \( \( ! -perm +010 -and -perm +001 \) -or \ + \( ! -perm +020 -and -perm +002 \) -or \ + \( ! -perm +040 -and -perm +004 \) \) \ + -exec ls -liTd \{\} \+ | tee /dev/stderr | wc -l) + [ $n -gt 0 ] && rc=3D1 || rc=3D0 + ;; +esac + +exit $rc Index: etc/defaults/periodic.conf =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- etc/defaults/periodic.conf (revision 213358) +++ etc/defaults/periodic.conf (working copy) @@ -160,6 +160,9 @@ # 100.chksetuid daily_status_security_chksetuid_enable=3D"YES" =20 +# 110.neggrpperm +daily_status_security_neggrpperm_enable=3D"YES" + # 200.chkmounts daily_status_security_chkmounts_enable=3D"YES" #daily_status_security_chkmounts_ignore=3D"^amd:" # Don't check matching Index: share/man/man5/periodic.conf.5 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- share/man/man5/periodic.conf.5 (revision 213358) +++ share/man/man5/periodic.conf.5 (working copy) @@ -482,6 +482,14 @@ .Dq Li YES to compare the modes and modification times of setuid executables with the previous day's values. +.It Va daily_status_security_neggrpperm_enable +.Pq Vt bool +Set to +.Dq Li YES +to check for files where the group of a file has less permissions than +the world at large. +When users are in more than 14 supplemental groups these negative +permissions may not be enforced via NFS shares. .It Va daily_status_security_chkmounts_enable .Pq Vt bool Set to --ey/N+yb7u/X9mFhi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD4DBQFMt2a7XY6L6fI4GtQRAumJAJ9Kf/siylrtL8847RARxtUs+GA41gCYpHO+ A+pknvfOoppwmakXm3Dd/Q== =RoWe -----END PGP SIGNATURE----- --ey/N+yb7u/X9mFhi-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 03:56:39 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FF61106566B; Fri, 15 Oct 2010 03:56:39 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 04D1E8FC18; Fri, 15 Oct 2010 03:56:38 +0000 (UTC) Received: by iwn8 with SMTP id 8so431550iwn.13 for ; Thu, 14 Oct 2010 20:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=zIQce4TWq+cEO9O30RG3Uux9T17I2GBSi6IBXAww7Go=; b=TpAQoCAMSJpIhkblkwdGyzMUrZm1NXDzjGI8GD6tMm+lF8X7Y83fAjMaeKOmDNHuDS VXGsr+2lA/loiMhDdPPgCeKgpj+nhvKhJ8q5YMrSyOldvHuTQXfv0SHDt9l5Gz17HMEE xrzJRHEHIG8RMvYZJN3gtyWIbNyabvlABre9c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=kpKliajeFbK0gttfsRw8KzBSD4Gbd4XaPD5GWZ5jmMxSEXW4YqKevFGmnhYfkH6SiN wf2NEuiluKQq4pRy1OwnC9hoIcjFI0SKtVe4GFniTy9ajn0HvD38YMrIJQjiRujsKbKh 4G7EWs15pKm0nzwmDwA/+oXEftuyOXJ7tzSws= MIME-Version: 1.0 Received: by 10.231.146.141 with SMTP id h13mr126868ibv.1.1287114563659; Thu, 14 Oct 2010 20:49:23 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Thu, 14 Oct 2010 20:49:23 -0700 (PDT) In-Reply-To: <201010140937.51953.jhb@freebsd.org> References: <4CB6F068.1070406@icyb.net.ua> <201010140937.51953.jhb@freebsd.org> Date: Thu, 14 Oct 2010 20:49:23 -0700 X-Google-Sender-Auth: sNKERK22M7adntGSGNdlRGafKJ8 Message-ID: From: Garrett Cooper To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Andriy Gapon Subject: Re: [PATCH] Bug with powerof2 macro in sys/param.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 03:56:39 -0000 On Thu, Oct 14, 2010 at 6:37 AM, John Baldwin wrote: > On Thursday, October 14, 2010 7:58:32 am Andriy Gapon wrote: >> on 14/10/2010 00:30 Garrett Cooper said the following: >> > =A0 =A0 I was talking to someone today about this macro, and he noted = that >> > the algorithm is incorrect -- it fails the base case with ((x) =3D=3D = 0 -- >> > which makes sense because 2^(x) cannot equal 0 (mathematically >> > impossible, unless you consider the limit as x goes to negative >> > infinity as log (0) / log(2) is undefined). I tested out his claim and >> > he was right: >> >> That's kind of obvious given the code. >> I think that this might be an intentional optimization. >> I guess that it doesn't really make sense to apply powerof2 to zero and = the users >> of the macro should do the check on their own if they expect zero as inp= ut (many >> places in the do not allow that). But the point is that this could be micro-optimizing things incorrectly. I'm running simple iteration tests to see what the performance is like, but the runtime is going to take a while to produce stable results. Mathematically there is a conflict with the definition of the macro, so it might confuse folks who pay attention to the math as opposed to the details (if you want I'll gladly add a comment around the macro in a patch to note the caveats of using powerof2). > I agree, the current macro is this way on purpose (and straight out of > "Hacker's Delight"). > > Of the existing calls you weren't sure of: > > sys/dev/cxgb/cxgb_sge.c: =A0 =A0 =A0 while (!powerof2(fl_q_size)) > sys/dev/cxgb/cxgb_sge.c: =A0 =A0 =A0 while (!powerof2(jumbo_q_size)) > > These are fine, will not be zero. Good to know. > sys/x86/x86/local_apic.c: =A0 =A0 =A0KASSERT(powerof2(count), ("bad count= ")); > sys/x86/x86/local_apic.c: =A0 =A0 =A0KASSERT(powerof2(align), ("bad align= ")); > > These are fine. =A0No code allocates zero IDT vectors. =A0We never alloca= te IDT > vectors for unallocated MSI or MSI-X IRQs. Excellent. > sys/net/flowtable.c: =A0 =A0 =A0 =A0 =A0 ft->ft_lock_count =3D > 2*(powerof2(mp_maxid + 1) ? (mp_maxid + 1): > > Clearly, 'mp_maxid + 1' will not be zero (barring a bizarre overflow case > which will not happen until we support 2^32 CPUs), so this is fine. But that should be caught by the mp_machdep code, correct? > sys/i386/pci/pci_pir.c: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (error && > !powerof2(pci_link->pl_irqmask)) { > > This fine. =A0Earlier in the function if pl_irqmask is zero, then all of = the > pci_pir_choose_irq() calls will fail, so this is only invoked if pl_irqma= sk > is non-zero. =A0In practice pl_irqmask is never zero anyway. Ok. > I suspect the GEOM ones are also generally safe. Well, that is the overall feeling I was getting, but I'm not sure that they're ok 100% of the time. What about the other patches? The mfiutil and mptutil ones at least get the two beforementioned tools in sync with sys/param.h at least, so I see some degree of value in the patches (even if they're just cleanup). Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 12:27:55 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id E81281065670 for ; Fri, 15 Oct 2010 12:27:55 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from xps.daemonology.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with SMTP id 992F914EC81 for ; Fri, 15 Oct 2010 12:27:55 +0000 (UTC) Received: (qmail 1569 invoked from network); 15 Oct 2010 12:27:55 -0000 Received: from unknown (HELO xps.daemonology.net) (127.0.0.1) by localhost with SMTP; 15 Oct 2010 12:27:55 -0000 Message-ID: <4CB848CB.9090502@freebsd.org> Date: Fri, 15 Oct 2010 05:27:55 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100803 Thunderbird/3.0.6 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20101014120030.938F6106571F@hub.freebsd.org> In-Reply-To: <20101014120030.938F6106571F@hub.freebsd.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PATCH] Bug with powerof2 macro in sys/param.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 12:27:56 -0000 Garrett Cooper wrote: > I was talking to someone today about this macro, and he noted that > the algorithm is incorrect -- it fails the base case with ((x) == 0 -- > which makes sense because 2^(x) cannot equal 0 (mathematically > impossible, unless you consider the limit as x goes to negative > infinity as log (0) / log(2) is undefined). Integer arithmetic on all platforms FreeBSD supports is in the ring Z_{2^n} for appropriate values of n; and in this ring, 2^n is equal to 0. If you arbitrarily declare that !powerof2(0), then you get into the bizarre situation of powerof2(x) && !powerof2(2*x) for x = 1 << (n - 1); this seems far more astonishing than the well-understood fact that machine arithmetic operates with a modular ring, so it seems to me that your proposed patch would do more harm than good. -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 13:08:41 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 072BF10657EF; Fri, 15 Oct 2010 13:08:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EAD6F8FC13; Fri, 15 Oct 2010 13:08:37 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 82C2B46C05; Fri, 15 Oct 2010 09:08:37 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 90F3A8A027; Fri, 15 Oct 2010 09:08:36 -0400 (EDT) From: John Baldwin To: Garrett Cooper Date: Fri, 15 Oct 2010 08:51:14 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010140937.51953.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010150851.14749.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 15 Oct 2010 09:08:36 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org, Andriy Gapon Subject: Re: [PATCH] Bug with powerof2 macro in sys/param.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 13:08:41 -0000 On Thursday, October 14, 2010 11:49:23 pm Garrett Cooper wrote: > On Thu, Oct 14, 2010 at 6:37 AM, John Baldwin wrote: > > On Thursday, October 14, 2010 7:58:32 am Andriy Gapon wrote: > >> on 14/10/2010 00:30 Garrett Cooper said the following: > >> > I was talking to someone today about this macro, and he noted that > >> > the algorithm is incorrect -- it fails the base case with ((x) == 0 -- > >> > which makes sense because 2^(x) cannot equal 0 (mathematically > >> > impossible, unless you consider the limit as x goes to negative > >> > infinity as log (0) / log(2) is undefined). I tested out his claim and > >> > he was right: > >> > >> That's kind of obvious given the code. > >> I think that this might be an intentional optimization. > >> I guess that it doesn't really make sense to apply powerof2 to zero and the users > >> of the macro should do the check on their own if they expect zero as input (many > >> places in the do not allow that). > > But the point is that this could be micro-optimizing things > incorrectly. I'm running simple iteration tests to see what the > performance is like, but the runtime is going to take a while to > produce stable results. > > Mathematically there is a conflict with the definition of the macro, > so it might confuse folks who pay attention to the math as opposed to > the details (if you want I'll gladly add a comment around the macro in > a patch to note the caveats of using powerof2). We aren't dealing with mathematicians, but programmers. > > I agree, the current macro is this way on purpose (and straight out of > > "Hacker's Delight"). And this book trumps you on that case. Using the powerof2() macro as it currently stands is a widely-used practice among folks who write systems-level code. If you were writing a powerof2() function for a higher level language where performance doesn't matter and bit twiddling isn't common, then a super-safe variant of powerof2() might be appropriate. However, this is C, and C programmers are expected to know how this stuff works. > > sys/net/flowtable.c: ft->ft_lock_count = > > 2*(powerof2(mp_maxid + 1) ? (mp_maxid + 1): > > > > Clearly, 'mp_maxid + 1' will not be zero (barring a bizarre overflow case > > which will not happen until we support 2^32 CPUs), so this is fine. > > But that should be caught by the mp_machdep code, correct? Yes, hence "bizarre". It is also way unrealistic and not worth excessive pessimizations scattered throughout the tree. > What about the other patches? The mfiutil and mptutil ones at least > get the two beforementioned tools in sync with sys/param.h at least, > so I see some degree of value in the patches (even if they're just > cleanup). No, powerof2() should not change. It would most likely be a POLA violation to change how it works given 1) it's historical behavior, and 2) it's underlying idiom's common (and well-understood) use among the software world. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 14:49:31 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 198C11065673 for ; Fri, 15 Oct 2010 14:49:31 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 8A15C8FC18 for ; Fri, 15 Oct 2010 14:49:29 +0000 (UTC) Received: from park.js.berklix.net (p549A3DF3.dip.t-dialin.net [84.154.61.243]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o9FECVqi031360 for ; Fri, 15 Oct 2010 14:12:33 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o9FECOVj082293 for ; Fri, 15 Oct 2010 16:12:24 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o9FECJN5053082 for ; Fri, 15 Oct 2010 16:12:24 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201010151412.o9FECJN5053082@fire.js.berklix.net> To: hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Fri, 15 Oct 2010 16:12:19 +0200 Sender: jhs@berklix.com Cc: Subject: international crypto laws X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 14:49:31 -0000 To quote 8.1-RELEASE/src/crypto/README ... The separation between src/contrib and src/crypto is the result of an old USA law, which made these sources export controlled, so they had to be kept separate. As international crypto laws are ever changing play things of ignorant politicians, & a pain in the orifice to track, & as FreeBSD is an international project, it's not just USA law that can be problematic. We could outsource disinterest in the wold's mess of crypto laws, by adding a URL to this: http://rechten.uvt.nl/koops/cryptolaw/ Crypto Law Survey indexed by country Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not HTML, quoted-printable & base 64 spam formats. Top posting cripples itemised cumulative responses. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 16:49:23 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 238A8106566B for ; Fri, 15 Oct 2010 16:49:23 +0000 (UTC) (envelope-from pali.gabor@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 985BA8FC1C for ; Fri, 15 Oct 2010 16:49:12 +0000 (UTC) Received: by bwz16 with SMTP id 16so1351407bwz.13 for ; Fri, 15 Oct 2010 09:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:subject:x-enigmail-version :content-type:content-transfer-encoding; bh=MQsb51J+9UR321oAoayshhchof/j3rEoarpoEWnx9bE=; b=eJCew9EyNirLCAlwZgoSaQMMnDxutAdjbKFKgkS3+KJh9vkNcfRGAtOTQS/hvtZtcn d/CvY61IU6AAxhAyuwePX13u6nfep7t9OAYlYhKINHJSwdNotqYya7J+/8HtI1EX1BEo U8Za5dvDSm1Jk0MJ+dZUFlWDAjz9t7MuPaFv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:x-enigmail-version:content-type:content-transfer-encoding; b=BlE/dJxbEyezORzQ4hkXlkGK647argTltQfkBAsR0UYHP5RZ+fpF7dBEPBwh/jJQTs ZIx/xZB+E1CQfDRtX7jMzokfO6zWGplfPZJK9UtVyaE49nf+H02fB2Tx+LjkDz9jsDS3 MuxNjo+xEZlIIGDtWoFtN8yXRuYvICkeVd0Og= Received: by 10.204.103.11 with SMTP id i11mr705199bko.186.1287150469120; Fri, 15 Oct 2010 06:47:49 -0700 (PDT) Received: from [157.181.167.48] (oktnb48.inf.elte.hu [157.181.167.48]) by mx.google.com with ESMTPS id d27sm2677422bkw.2.2010.10.15.06.47.47 (version=SSLv3 cipher=RC4-MD5); Fri, 15 Oct 2010 06:47:47 -0700 (PDT) Sender: =?UTF-8?B?UMOBTEkgR8OhYm9yIErDoW5vcw==?= Message-ID: <4CB85C4F.1040107@FreeBSD.org> Date: Fri, 15 Oct 2010 15:51:11 +0200 From: Gabor PALI Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100925 Thunderbird/3.1.4 MIME-Version: 1.0 To: hackers@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Announcing EuroBSDCon 2011 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 16:49:23 -0000 EuroBSDCon 2011 =============== EuroBSDCon is the European technical conference for users and developers on BSD based systems. The EuroBSDCon 2011 conference will be held in the Netherlands from Thursday 6 October 2011 to Sunday 9 October 2011, with tutorials on Thursday and Friday and talks on Saturday and Sunday. Call for Proposals ------------------ The EuroBSDCon conference is inviting developers and users of BSD based systems to submit innovative and original papers not submitted to other European conferences on BSD related topics. Topics of interest to the conference include, but are not limited to applications, architecture, implementation, performance and security of BSD based operating systems, as well as topics concerning the economic or organizational aspects of BSD use. Presentations are expected to be 45 or 90 minutes, please indicate the approximate time slot size when submitting your abstract. Call for Tutorial Proposals --------------------------- The EuroBSDCon conference is inviting qualified practitioners in their field to submit proposals for half or full day tutorials on topics relevant to development, implementation and use of BSD based systems. Submission address ------------------ Proposals should be submitted by Email to Important dates --------------- The EuroBSDCon conference is accepting abstracts and tutorial proposals until May 15th, 2011. Other important dates will be announced soon at the conference website http://2011.eurobsdcon.org/ From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 17:56:36 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01CCA106566B for ; Fri, 15 Oct 2010 17:56:36 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id B31E78FC08 for ; Fri, 15 Oct 2010 17:56:35 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Fri, 15 Oct 2010 13:45:46 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 760D833C00; Fri, 15 Oct 2010 13:45:46 -0400 (EDT) Date: Fri, 15 Oct 2010 13:45:46 -0400 From: Ed Maste To: Message-ID: <20101015174546.GA84021@sandvine.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Cygwin termcap entry X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 17:56:36 -0000 I'd like to replace our termcap entry for cygwin with either one taken from /etc/termcap on a Cygwin system, as in the patch below, or maybe with the one from http://catb.org/esr/terminfo/termtypes.tc.gz. Any comments? -Ed Patch for Cygwin-provided entry: Index: share/termcap/termcap.src =================================================================== --- share/termcap/termcap.src (revision 213890) +++ share/termcap/termcap.src (working copy) @@ -4580,8 +4580,26 @@ linux-m|Linux Console no color:\ :pa@:Co@:AF@:AB@:op@:\ :tc=linux: -cygwin:\ - :xn@:op=\E[39;49m:Km=\E[M:tc=linux: +cygwin|ansi emulation for Cygwin:\ + :am:hs:mi:ms:xo:\ + :Co#8:it#8:pa#64:\ + :&7=^Z:@7=\E[4~:AB=\E[4%dm:AF=\E[3%dm:AL=\E[%dL:DC=\E[%dP:\ + :DL=\E[%dM:DO=\E[%dB:F1=\E[23~:F2=\E[24~:F3=\E[25~:\ + :F4=\E[26~:F5=\E[28~:F6=\E[29~:F7=\E[31~:F8=\E[32~:\ + :F9=\E[33~:FA=\E[34~:IC=\E[%d@:K2=\E[G:LE=\E[%dD:\ + :RI=\E[%dC:S2=\E[11m:S3=\E[10m:UP=\E[%dA:al=\E[L:bl=^G:\ + :cb=\E[1K:cd=\E[J:ce=\E[K:ch=\E[%i%dG:cl=\E[H\E[J:\ + :cm=\E[%i%d;%dH:cr=^M:cv=\E[%i%dd:dc=\E[P:dl=\E[M:do=\E[B:\ + :ec=\E[%dX:ei=\E[4l:fs=^G:ho=\E[H:ic=\E[@:im=\E[4h:\ + :k1=\E[[A:k2=\E[[B:k3=\E[[C:k4=\E[[D:k5=\E[[E:k6=\E[17~:\ + :k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:kD=\E[3~:\ + :kI=\E[2~:kN=\E[6~:kP=\E[5~:kb=\177:kd=\E[B:kh=\E[1~:\ + :kl=\E[D:kr=\E[C:ku=\E[A:le=^H:md=\E[1m:me=\E[0m:mk=\E[8m:\ + :mr=\E[7m:nd=\E[C:nw=^M^J:op=\E[39;49m:r1=\Ec\E]R:rc=\E8:\ + :sc=\E7:se=\E[27m:sf=^J:so=\E[7m:sr=\EM:ta=^I:\ + :te=\E[2J\E[?47l\E8:ti=\E7\E[?47h:ts=\E];:\ + :u6=\E[%i%d;%dR:u7=\E[6n:u8=\E[?6c:u9=\E[c:ue=\E[24m:\ + :up=\E[A:us=\E[4m: # Multilingual Sysinstall (kon2 console) # HOSOKAWA, Tatsumi (hosokawa@FreeBSD.org) kons25x|kons25-euc:\ From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 19:35:05 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADADD106566B; Fri, 15 Oct 2010 19:35:05 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 7A4858FC15; Fri, 15 Oct 2010 19:35:05 +0000 (UTC) Received: from c.earth.lavabit.com (c.earth.lavabit.com [192.168.111.12]) by karen.lavabit.com (Postfix) with ESMTP id A6B1C157549; Fri, 15 Oct 2010 14:35:04 -0500 (CDT) Received: from rui-macbook.lan (bl17-136-196.dsl.telepac.pt [188.82.136.196]) by lavabit.com with ESMTP id D42MLNF8MSPS; Fri, 15 Oct 2010 14:35:04 -0500 References: <2AD11EA8-18FC-46E1-AE97-184599A054AD@freebsd.org> <20101015191942.GA45582@freebsd.org> In-Reply-To: <20101015191942.GA45582@freebsd.org> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <1C20C791-3D0D-4695-BF82-FD8211323561@freebsd.org> Content-Transfer-Encoding: quoted-printable From: Rui Paulo Date: Fri, 15 Oct 2010 20:35:01 +0100 To: Roman Divacky X-Mailer: Apple Mail (2.1081) Cc: hackers@freebsd.org, "current@freebsd.org Current" Subject: Re: Removal of libobjc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 19:35:05 -0000 On 15 Oct 2010, at 20:19, Roman Divacky wrote: > On Fri, Oct 15, 2010 at 08:15:52PM +0100, Rui Paulo wrote: >> Hi, >>=20 >> I was hoping we could remove libobjc from the base system as it's = seriously outdated and it's not used by anything on the base system. >>=20 >> If there are any objections, please speak up. >=20 > please wait until the ports are converted to use libobjc2 (already in = progress).. >=20 > it should be a few days/weeks at most now I think Yes, I was just asking if someone was against it. Regards, -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 19:35:36 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04AE9106574A for ; Fri, 15 Oct 2010 19:35:36 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id B3CB68FC0C for ; Fri, 15 Oct 2010 19:35:34 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 5FC129CB06B; Fri, 15 Oct 2010 21:19:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2cbHK2FTLZo; Fri, 15 Oct 2010 21:19:43 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id E29A09CB23F; Fri, 15 Oct 2010 21:19:42 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id o9FJJgxa045690; Fri, 15 Oct 2010 21:19:42 +0200 (CEST) (envelope-from rdivacky) Date: Fri, 15 Oct 2010 21:19:42 +0200 From: Roman Divacky To: Rui Paulo Message-ID: <20101015191942.GA45582@freebsd.org> References: <2AD11EA8-18FC-46E1-AE97-184599A054AD@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2AD11EA8-18FC-46E1-AE97-184599A054AD@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: hackers@freebsd.org, "current@freebsd.org Current" Subject: Re: Removal of libobjc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 19:35:36 -0000 On Fri, Oct 15, 2010 at 08:15:52PM +0100, Rui Paulo wrote: > Hi, > > I was hoping we could remove libobjc from the base system as it's seriously outdated and it's not used by anything on the base system. > > If there are any objections, please speak up. please wait until the ports are converted to use libobjc2 (already in progress).. it should be a few days/weeks at most now I think roman From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 19:41:04 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F8E41065698 for ; Fri, 15 Oct 2010 19:41:04 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 4A94C8FC1A for ; Fri, 15 Oct 2010 19:41:04 +0000 (UTC) Received: from c.earth.lavabit.com (c.earth.lavabit.com [192.168.111.12]) by karen.lavabit.com (Postfix) with ESMTP id 93D5515754E; Fri, 15 Oct 2010 14:15:54 -0500 (CDT) Received: from rui-macbook.lan (bl17-136-196.dsl.telepac.pt [188.82.136.196]) by lavabit.com with ESMTP id RQ4ZTD7Z9OO3; Fri, 15 Oct 2010 14:15:54 -0500 From: Rui Paulo Content-Type: text/plain; charset=us-ascii Message-Id: <2AD11EA8-18FC-46E1-AE97-184599A054AD@freebsd.org> Date: Fri, 15 Oct 2010 20:15:52 +0100 To: hackers@freebsd.org, "current@freebsd.org Current" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Cc: Subject: Removal of libobjc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 19:41:04 -0000 Hi, I was hoping we could remove libobjc from the base system as it's = seriously outdated and it's not used by anything on the base system. If there are any objections, please speak up. Regards, -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 19:42:35 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D28201065672; Fri, 15 Oct 2010 19:42:35 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 869FA8FC12; Fri, 15 Oct 2010 19:42:34 +0000 (UTC) Received: by iwn6 with SMTP id 6so789679iwn.13 for ; Fri, 15 Oct 2010 12:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=vJjNBEKxn2t7GDFyWceXL5C3DBcobi7HobDBsKKTSfs=; b=IZlryoTyEpVlH6KtqPUdPpi9LbsO1gl3jOYYOGQznlr4pW5oO7SJl+DauZiFtkOyML XlNSGhczAGOqB2vKs/IJzRXLQ4G+lBF5eHqdkZtIJfYVIxGueI6AHXilf4AaHr1XU/z9 R5VeA5x4ZCENYMa85jjqUw+zHVvMmc0gBH8Qo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=qgNEXhf5S4YvLOsnDL77LKnYyp3nMQg7LOgyjnG4YMUvJeJaj7g8YUB6M1mB12N94R Um9SsY1EVmheaDZuck5tAuCU9JDva4NBQj1kgEBi4RNpvCaUHtM3mrSl1Zg0oc9yGzlI Tk5i7mvWFbOwrJc9LJaHP3N/riZBkbKUBV9Bw= MIME-Version: 1.0 Received: by 10.231.150.7 with SMTP id w7mr1152949ibv.14.1287171290536; Fri, 15 Oct 2010 12:34:50 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Fri, 15 Oct 2010 12:34:50 -0700 (PDT) In-Reply-To: <201010150851.14749.jhb@freebsd.org> References: <201010140937.51953.jhb@freebsd.org> <201010150851.14749.jhb@freebsd.org> Date: Fri, 15 Oct 2010 12:34:50 -0700 X-Google-Sender-Auth: YhDmGc3De91h5NwW4zKTYO8JtLM Message-ID: From: Garrett Cooper To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Andriy Gapon Subject: Re: [PATCH] Bug with powerof2 macro in sys/param.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 19:42:35 -0000 On Fri, Oct 15, 2010 at 5:51 AM, John Baldwin wrote: > On Thursday, October 14, 2010 11:49:23 pm Garrett Cooper wrote: >> On Thu, Oct 14, 2010 at 6:37 AM, John Baldwin wrote: >> > On Thursday, October 14, 2010 7:58:32 am Andriy Gapon wrote: >> >> on 14/10/2010 00:30 Garrett Cooper said the following: >> >> > =A0 =A0 I was talking to someone today about this macro, and he not= ed that >> >> > the algorithm is incorrect -- it fails the base case with ((x) =3D= =3D 0 -- >> >> > which makes sense because 2^(x) cannot equal 0 (mathematically >> >> > impossible, unless you consider the limit as x goes to negative >> >> > infinity as log (0) / log(2) is undefined). I tested out his claim = and >> >> > he was right: >> >> >> >> That's kind of obvious given the code. >> >> I think that this might be an intentional optimization. >> >> I guess that it doesn't really make sense to apply powerof2 to zero a= nd the users >> >> of the macro should do the check on their own if they expect zero as = input (many >> >> places in the do not allow that). >> >> But the point is that this could be micro-optimizing things >> incorrectly. I'm running simple iteration tests to see what the >> performance is like, but the runtime is going to take a while to >> produce stable results. >> >> Mathematically there is a conflict with the definition of the macro, >> so it might confuse folks who pay attention to the math as opposed to >> the details (if you want I'll gladly add a comment around the macro in >> a patch to note the caveats of using powerof2). > > We aren't dealing with mathematicians, but programmers. > >> > I agree, the current macro is this way on purpose (and straight out of >> > "Hacker's Delight"). > > And this book trumps you on that case. =A0Using the powerof2() macro as i= t > currently stands is a widely-used practice among folks who write > systems-level code. =A0If you were writing a powerof2() function for a hi= gher > level language where performance doesn't matter and bit twiddling isn't > common, then a super-safe variant of powerof2() might be appropriate. Ok, excellent point. > However, this is C, and C programmers are expected to know how this stuff > works. Yes, but compilers (when setup to optimize) should pick up on the fact that this clause in the conditional [(x) !=3D 0] is in fact covered by a number of these statements when bounding the input set of (x) to values greater than 0 (all of the areas I identified that I understood the context were bounded to at least positive integer value range), so it would be optimized way as an effective unreachable case. >> > sys/net/flowtable.c: =A0 =A0 =A0 =A0 =A0 ft->ft_lock_count =3D >> > 2*(powerof2(mp_maxid + 1) ? (mp_maxid + 1): >> > >> > Clearly, 'mp_maxid + 1' will not be zero (barring a bizarre overflow c= ase >> > which will not happen until we support 2^32 CPUs), so this is fine. >> >> But that should be caught by the mp_machdep code, correct? > > Yes, hence "bizarre". =A0 It is also way unrealistic and not worth excess= ive > pessimizations scattered throughout the tree. Agreed :). >> What about the other patches? The mfiutil and mptutil ones at least >> get the two beforementioned tools in sync with sys/param.h at least, >> so I see some degree of value in the patches (even if they're just >> cleanup). > > No, powerof2() should not change. =A0It would most likely be a POLA viola= tion > to change how it works given 1) it's historical behavior, and 2) it's > underlying idiom's common (and well-understood) use among the software > world. Ok. Given that similar logic is also employed in some of the other macros in sys/params.h, like roundup2, etc, and that logic is used more pervasively than powerof2, I agree that it's best to leave things be... otherwise the code would turn into a dyslexic mess `fixing' most of these relatively benign issues. Thanks Andriy, Colin, and John for the lookover and explanation :). Cheers, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 20:07:25 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F9E81065679; Fri, 15 Oct 2010 20:07:25 +0000 (UTC) (envelope-from 839273@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id DB7888FC14; Fri, 15 Oct 2010 20:07:24 +0000 (UTC) Received: by yxn35 with SMTP id 35so477222yxn.13 for ; Fri, 15 Oct 2010 13:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=mOTShYQVB3L7dwlLN73P2ZZdGjeBUlcs5uK+V7eEDK4=; b=TOQCNj/ZaEOjo/qkzDj0sPMTe8RvuE5dVS71NhD1H5E/AgpB29Zhb4CIAr6tM77IIU zy6y/8Ff4+JoJzYcqxN2KIduKR3bTiH7+hVlQSRc9hnQIsniFiYicGWcIyEfTvHjMGbe vEpTZ0IFgSfFfVYhVmTSr25Ewxhrw4EvWGdmw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=v9w3TFtjTq2rwSHUkeiuxf/CGYTvEhZbQOWGxVWyNfq+s54z7UJuWIfFAnZfXCskzY MSH2nwatnn0OyOiLHdnc2Ug24ztYOuTg9nu2TlofUipAmI1TaHo5BoXRPdVdjq3jizkj xbCLEObBgW+cj5+b9Bfjbl4uNWOH/qp36IkqY= MIME-Version: 1.0 Received: by 10.150.197.21 with SMTP id u21mr2118763ybf.348.1287171551334; Fri, 15 Oct 2010 12:39:11 -0700 (PDT) Sender: 839273@gmail.com Received: by 10.150.211.17 with HTTP; Fri, 15 Oct 2010 12:39:11 -0700 (PDT) In-Reply-To: <20101015174546.GA84021@sandvine.com> References: <20101015174546.GA84021@sandvine.com> Date: Fri, 15 Oct 2010 15:09:11 -0430 X-Google-Sender-Auth: Jvs80Tv7P6scVDRSzC6vPtqR0HQ Message-ID: From: Andres Perera To: Ed Maste Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org Subject: Re: Cygwin termcap entry X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 839273@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 20:07:25 -0000 On Fri, Oct 15, 2010 at 1:15 PM, Ed Maste wrote: > I'd like to replace our termcap entry for cygwin with either one taken > from /etc/termcap on a Cygwin system, as in the patch below, or maybe > with the one from http://catb.org/esr/terminfo/termtypes.tc.gz. > > Any comments? The problem is that it _does_ share capabilities with linux, so don't get rid of tc=linux. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 20:19:07 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23C2D1065672 for ; Fri, 15 Oct 2010 20:19:07 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id BD3628FC16 for ; Fri, 15 Oct 2010 20:19:06 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Fri, 15 Oct 2010 16:19:05 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id B4A5B33C00; Fri, 15 Oct 2010 16:19:05 -0400 (EDT) Date: Fri, 15 Oct 2010 16:19:05 -0400 From: Ed Maste To: <839273@gmail.com> Message-ID: <20101015201905.GA95390@sandvine.com> References: <20101015174546.GA84021@sandvine.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: Cygwin termcap entry X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 20:19:07 -0000 On Fri, Oct 15, 2010 at 03:09:11PM -0430, Andres Perera wrote: > On Fri, Oct 15, 2010 at 1:15 PM, Ed Maste wrote: > > I'd like to replace our termcap entry for cygwin with either one taken > > from /etc/termcap on a Cygwin system, as in the patch below, or maybe > > with the one from http://catb.org/esr/terminfo/termtypes.tc.gz. > > > > Any comments? > > The problem is that it _does_ share capabilities with linux, so don't > get rid of tc=linux. The one from catb.org has tc=ansi.sys instead; just because there are a common subset of capabilities doesn't necessarily imply that it should use tc=, in my opinion. Does it share capabilities with Linux because it is based on some code in Linux? -Ed From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 20:45:29 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 814251065670 for ; Fri, 15 Oct 2010 20:45:29 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1565B8FC0A for ; Fri, 15 Oct 2010 20:45:28 +0000 (UTC) Received: by ewy21 with SMTP id 21so867323ewy.13 for ; Fri, 15 Oct 2010 13:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:cc:content-type; bh=bXNLw36d49oCmjF+n/0xL5wc0jVpj/vWlJWy2u4vgKg=; b=RzwGzQSnkAOGBHBYOAykbOZLmscbQGZjT4N2Xslg7xsYcj9wtCpjIgfJCbKoffevJ9 0881MC4AnlAfEycDcx75EvL79Q8jGXmvePGrLnUXHErQJvNMkCyGz/uMXglbUA/GdIWu 5UV6mQL+C5V5AstIcD/FhwhOekjLMYKJl+asM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=nayX8k/LVDO49iHHvmUHoUyfRq1B5/6j4KOQ+c4fzjLp+tuKbD4DKV/9o6W6dOGcCw eDNze/ptuP+it2ow5BwwMNaxwrr/EGdwjU079nQ156uVlFpom35uoiPztpkKvxwPsCtd OI1TiFAVkprGj0VTdeVkENSFz/bFd2t0jjCNk= MIME-Version: 1.0 Received: by 10.213.108.73 with SMTP id e9mr1999544ebp.36.1287174119765; Fri, 15 Oct 2010 13:21:59 -0700 (PDT) Received: by 10.14.53.70 with HTTP; Fri, 15 Oct 2010 13:21:59 -0700 (PDT) Date: Fri, 15 Oct 2010 20:21:59 +0000 Message-ID: From: "b. f." To: jhb@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@FreeBSD.org Subject: Re: [PATCH] Bug with powerof2 macro in sys/param.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 20:45:29 -0000 >We aren't dealing with mathematicians, but programmers. I am attempting to reconcile this with Colin's rationale in terms of congruence classes over rings Z/nZ. ;) b. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 21:09:53 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A105B106566B; Fri, 15 Oct 2010 21:09:53 +0000 (UTC) (envelope-from andreast@FreeBSD.org) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 24EF18FC12; Fri, 15 Oct 2010 21:09:52 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-8-131.flashcable.ch [91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id o9FKYG0X043827; Fri, 15 Oct 2010 22:34:16 +0200 (CEST) (envelope-from andreast@FreeBSD.org) Message-ID: <4CB8BAC7.7030401@FreeBSD.org> Date: Fri, 15 Oct 2010 22:34:15 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org, sam@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: Subject: ad7418 developer/users? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 21:09:53 -0000 Hi all, I wrote a driver for my PowerMac7,2 which reads temperature and adc values from an ad7417, an ad7418 with four adc's. This driver would be ready for submission, but now I think about if it would make sense to bring these two drivers into the same source. For this idea I'd need some testers who have an ad7418. I saw the driver is used on some ARM configs. Anyone who has opinions, hw to test? Any help is appreciated. Thanks, Andreas From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 16 23:08:05 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 161251065670 for ; Sat, 16 Oct 2010 23:08:05 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 230A28FC08 for ; Sat, 16 Oct 2010 23:07:59 +0000 (UTC) Received: by iwn41 with SMTP id 41so1152373iwn.13 for ; Sat, 16 Oct 2010 16:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=lUmPNK33wQ53ZWfhW1VYC82cTXJI8f7yjEigC0Sjjxw=; b=M3XxBFx87e/DhKIPHIuCwB2DMH1UK4gjKXSEvJFPBqG1mXgRxiXMg6oe18FsFrj8cH vKnxa77wP/SBiTKGpCevXi4R8aurnNOX+duA145D1YRI+EmW3iE9WXz68kWuPk0m+nJP aVGxvIFRTLkcyOU8BNlYoM4sLGALbADVf/LCc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=roWSl0hhMZEsK0UpGLaMEE5t3AaeRP3j/4L5mE62DdnBKBl4tCUk/h7w8gyh0d6srW Tm+iHJxPswxy8aFY15M6cNAXgK7FGOrq8qGTEdXCcsn9egKkoW2D83mTgse4J+mbtj+a lsvKTft+ZzAn43Eg/0tcfcOWlo/yToQqzX3io= MIME-Version: 1.0 Received: by 10.231.10.141 with SMTP id p13mr1915718ibp.183.1287270479335; Sat, 16 Oct 2010 16:07:59 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Sat, 16 Oct 2010 16:07:59 -0700 (PDT) In-Reply-To: <8662zg586z.fsf@ds4.des.no> References: <86fwyq8rsc.fsf@ds4.des.no> <86d3tujh72.fsf@ds4.des.no> <864of680wv.fsf@ds4.des.no> <8662zkurx9.fsf@ds4.des.no> <8662zg586z.fsf@ds4.des.no> Date: Sat, 16 Oct 2010 16:07:59 -0700 X-Google-Sender-Auth: IKarnalozTF2cxgxVIpO7g_n1qo Message-ID: From: Garrett Cooper To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: multipart/mixed; boundary=00221532c7aca694360492c40306 Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: Why is TUNABLE_INT discouraged? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 23:08:05 -0000 --00221532c7aca694360492c40306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2010/8/12 Dag-Erling Sm=F8rgrav : > Garrett Cooper writes: >> Dag-Erling Sm=F8rgrav writes: >> > It might be a good idea to introduce TUNABLE_POINTER and TUNABLE_SIZE. >> I would actually argue against doing that because it would only create >> divergence between sysctl and tunable KPIs... > > Not if we also introduce corresponding SYSCTLs. =A0Note that my idea is t= o > have these as aliases for the correct primitive types. > >> (BTW, when you say TUNABLE_SIZE, I assume it would be a size_t quantity?= ) > > Yes. > >> Something might need to be done to the values returned by the tunables >> though, because they don't respect boundaries, and can overflow right >> now (which exacerbates the issue with values crammed into smaller >> datatypes)... > > Yes. =A0How about this: > > =A0- rename getenv_quad() to getenv_signed() and getenv_unsigned() > =A0- add min / max arguments > =A0- implement getenv_quad() (and all the others) in terms of > =A0 getenv_number() > > e.g. > > int > getenv_uint(const char *name, unsigned int *data) > { > =A0 =A0 =A0 =A0unsigned long long tmp; > =A0 =A0 =A0 =A0int rval; > > =A0 =A0 =A0 =A0if ((rval =3D getenv_unsigned(name, &tmp, 0, UINT_MAX)) = =3D=3D 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*data =3D (unsigned int)tmp; > =A0 =A0 =A0 =A0return (rval); > } > > (note that due to the min / max arguments, the complexity of handling > both signed and unsigned values in the same function probably exceeds > the complexity of having two very similar functions) Here's a draft of this work des@ challenged me to a while back. It works well as demonstrated with my tests. The only catch with detecting bounds is that if it's the minimum in the case of signed or maximum representable value in the case of unsigned, then strtoq, etc will clamp the value to the maximum representable value. Other than that it works well, and now tunables represented by unsigned values should work better. Please let me know what you all think. Thanks! -Garrett PS I added uquad_t for consistency in the APIs, even though quad_t was deprecated, but I didn't bump __FreeBSD_version__ -- wasn't sure if I should have done that). --00221532c7aca694360492c40306 Content-Type: application/octet-stream; name="test-tunables-draft1.log" Content-Disposition: attachment; filename="test-tunables-draft1.log" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gfd3iz6p1 IyBDb25zb2xlIG91dHB1dAojIGZvciBpIGluICovOyBkbyAoY2QgJGkgJiYgc2ggdGVzdCouc2gg Mj4vZGV2L251bGwpOyBkb25lCnRlc3RfaW50X3R1bmFibGUudHVuYWJsZT0iLTEiCnRlc3RfaW50 X3R1bmFibGUudHVuYWJsZT0iMCIKdGVzdF9pbnRfdHVuYWJsZS50dW5hYmxlPSI0MiIKdGVzdF9p bnRfdHVuYWJsZS50dW5hYmxlPSJhc2RmMTIzNCIKdGVzdF9pbnRfdHVuYWJsZS50dW5hYmxlPSIt MjE0NzQ4MzY0NyIKdGVzdF9pbnRfdHVuYWJsZS50dW5hYmxlPSItMjE0NzQ4MzY0OSIKdGVzdF9p bnRfdHVuYWJsZS50dW5hYmxlPSIyMTQ3NDgzNjQ2Igp0ZXN0X2ludF90dW5hYmxlLnR1bmFibGU9 IjIxNDc0ODM2NDgiCnRlc3RfbG9uZ190dW5hYmxlLnR1bmFibGU9IjAiCnRlc3RfbG9uZ190dW5h YmxlLnR1bmFibGU9IjQyIgp0ZXN0X2xvbmdfdHVuYWJsZS50dW5hYmxlPSJhc2RmMTIzNCIKdGVz dF9sb25nX3R1bmFibGUudHVuYWJsZT0iLTkyMjMzNzIwMzY4NTQ3NzU4MDkiCnRlc3RfbG9uZ190 dW5hYmxlLnR1bmFibGU9Ii05MjIzMzcyMDM2ODU0Nzc1ODA3Igp0ZXN0X2xvbmdfdHVuYWJsZS50 dW5hYmxlPSI5MjIzMzcyMDM2ODU0Nzc1ODA2Igp0ZXN0X2xvbmdfdHVuYWJsZS50dW5hYmxlPSI5 MjIzMzcyMDM2ODU0Nzc1ODA4Igp0ZXN0X3BvaW50ZXJfdHVuYWJsZS50dW5hYmxlPSItMSIKdGVz dF9wb2ludGVyX3R1bmFibGUudHVuYWJsZT0iMCIKdGVzdF9wb2ludGVyX3R1bmFibGUudHVuYWJs ZT0iNDIiCnRlc3RfcG9pbnRlcl90dW5hYmxlLnR1bmFibGU9IjM3MzU5Mjg1NTkiCnRlc3RfcG9p bnRlcl90dW5hYmxlLnR1bmFibGU9ImFzZGYxMjM0Igp0ZXN0X3BvaW50ZXJfdHVuYWJsZS50dW5h YmxlPSI4NTgwNDgxMDIzIgp0ZXN0X3BvaW50ZXJfdHVuYWJsZS50dW5hYmxlPSI4NTgwNDgxMDI1 Igp0ZXN0X3F1YWRfdHVuYWJsZS50dW5hYmxlPSIwIgp0ZXN0X3F1YWRfdHVuYWJsZS50dW5hYmxl PSI0MiIKdGVzdF9xdWFkX3R1bmFibGUudHVuYWJsZT0iYXNkZjEyMzQiCnRlc3RfcXVhZF90dW5h YmxlLnR1bmFibGU9Ii05MjIzMzcyMDM2ODU0Nzc1ODA5Igp0ZXN0X3F1YWRfdHVuYWJsZS50dW5h YmxlPSItOTIyMzM3MjAzNjg1NDc3NTgwNyIKdGVzdF9xdWFkX3R1bmFibGUudHVuYWJsZT0iOTIy MzM3MjAzNjg1NDc3NTgwNiIKdGVzdF9xdWFkX3R1bmFibGUudHVuYWJsZT0iOTIyMzM3MjAzNjg1 NDc3NTgwOCIKdGVzdF9zaXplX3R1bmFibGUudHVuYWJsZT0iLTEiCnRlc3Rfc2l6ZV90dW5hYmxl LnR1bmFibGU9IjAiCnRlc3Rfc2l6ZV90dW5hYmxlLnR1bmFibGU9IjQyIgp0ZXN0X3NpemVfdHVu YWJsZS50dW5hYmxlPSJhc2RmMTIzNCIKdGVzdF9zaXplX3R1bmFibGUudHVuYWJsZT0iOTIyMzM3 MjAzNjg1NDc3NTgwOCIKdGVzdF9zaXplX3R1bmFibGUudHVuYWJsZT0iMTg0NDY3NDQwNzM3MDk1 NTE2MTQiCnRlc3Rfc2l6ZV90dW5hYmxlLnR1bmFibGU9IjE4NDQ2NzQ0MDczNzA5NTUxNjE2Igp0 ZXN0X3N0cmluZ190dW5hYmxlLnR1bmFibGU9IiIKdGVzdF9zdHJpbmdfdHVuYWJsZS50dW5hYmxl PSJhc2RmMTIzNCIKdGVzdF9zdHJpbmdfdHVuYWJsZS50dW5hYmxlPSJjaGFyYWN0ZXIiCnRlc3Rf c3RyaW5nX3R1bmFibGUudHVuYWJsZT0iYXNvcnRvZmxvbmdpc2hzdHJpbmciCnRlc3RfdHVuYWJs ZV9zdWZmaXhlcy50dW5hYmxlPSItMSIKdGVzdF90dW5hYmxlX3N1ZmZpeGVzLnR1bmFibGU9Ii0x ZyIKdGVzdF90dW5hYmxlX3N1ZmZpeGVzLnR1bmFibGU9Ii0xRyIKdGVzdF90dW5hYmxlX3N1ZmZp eGVzLnR1bmFibGU9Ii0xayIKdGVzdF90dW5hYmxlX3N1ZmZpeGVzLnR1bmFibGU9Ii0xSyIKdGVz dF90dW5hYmxlX3N1ZmZpeGVzLnR1bmFibGU9Ii0xbSIKdGVzdF90dW5hYmxlX3N1ZmZpeGVzLnR1 bmFibGU9Ii0xTSIKdGVzdF90dW5hYmxlX3N1ZmZpeGVzLnR1bmFibGU9Ii0xdCIKdGVzdF90dW5h YmxlX3N1ZmZpeGVzLnR1bmFibGU9Ii0xVCIKdGVzdF90dW5hYmxlX3N1ZmZpeGVzLnR1bmFibGU9 Ii0xeiIKdGVzdF90dW5hYmxlX3N1ZmZpeGVzLnR1bmFibGU9Ii0xWiIKdGVzdF90dW5hYmxlX3N1 ZmZpeGVzLnR1bmFibGU9IjAiCnRlc3RfdHVuYWJsZV9zdWZmaXhlcy50dW5hYmxlPSIwZyIKdGVz dF90dW5hYmxlX3N1ZmZpeGVzLnR1bmFibGU9IjBHIgp0ZXN0X3R1bmFibGVfc3VmZml4ZXMudHVu YWJsZT0iMGsiCnRlc3RfdHVuYWJsZV9zdWZmaXhlcy50dW5hYmxlPSIwSyIKdGVzdF90dW5hYmxl X3N1ZmZpeGVzLnR1bmFibGU9IjBtIgp0ZXN0X3R1bmFibGVfc3VmZml4ZXMudHVuYWJsZT0iME0i CnRlc3RfdHVuYWJsZV9zdWZmaXhlcy50dW5hYmxlPSIwdCIKdGVzdF90dW5hYmxlX3N1ZmZpeGVz LnR1bmFibGU9IjBUIgp0ZXN0X3R1bmFibGVfc3VmZml4ZXMudHVuYWJsZT0iMHoiCnRlc3RfdHVu YWJsZV9zdWZmaXhlcy50dW5hYmxlPSIwWiIKdGVzdF90dW5hYmxlX3N1ZmZpeGVzLnR1bmFibGU9 IjEiCnRlc3RfdHVuYWJsZV9zdWZmaXhlcy50dW5hYmxlPSIxZyIKdGVzdF90dW5hYmxlX3N1ZmZp eGVzLnR1bmFibGU9IjFHIgp0ZXN0X3R1bmFibGVfc3VmZml4ZXMudHVuYWJsZT0iMWsiCnRlc3Rf dHVuYWJsZV9zdWZmaXhlcy50dW5hYmxlPSIxSyIKdGVzdF90dW5hYmxlX3N1ZmZpeGVzLnR1bmFi bGU9IjFtIgp0ZXN0X3R1bmFibGVfc3VmZml4ZXMudHVuYWJsZT0iMU0iCnRlc3RfdHVuYWJsZV9z dWZmaXhlcy50dW5hYmxlPSIxdCIKdGVzdF90dW5hYmxlX3N1ZmZpeGVzLnR1bmFibGU9IjFUIgp0 ZXN0X3R1bmFibGVfc3VmZml4ZXMudHVuYWJsZT0iMXoiCnRlc3RfdHVuYWJsZV9zdWZmaXhlcy50 dW5hYmxlPSIxWiIKdGVzdF91aW50X3R1bmFibGUudHVuYWJsZT0iLTEiCnRlc3RfdWludF90dW5h YmxlLnR1bmFibGU9IjAiCnRlc3RfdWludF90dW5hYmxlLnR1bmFibGU9IjQyIgp0ZXN0X3VpbnRf dHVuYWJsZS50dW5hYmxlPSJhc2RmMTIzNCIKdGVzdF91aW50X3R1bmFibGUudHVuYWJsZT0iMjE0 NzQ4MzY0OCIKdGVzdF91aW50X3R1bmFibGUudHVuYWJsZT0iNDI5NDk2NzI5NCIKdGVzdF91aW50 X3R1bmFibGUudHVuYWJsZT0iNDI5NDk2NzI5NiIKdGVzdF91bG9uZ190dW5hYmxlLnR1bmFibGU9 Ii0xIgp0ZXN0X3Vsb25nX3R1bmFibGUudHVuYWJsZT0iMCIKdGVzdF91bG9uZ190dW5hYmxlLnR1 bmFibGU9IjQyIgp0ZXN0X3Vsb25nX3R1bmFibGUudHVuYWJsZT0iYXNkZjEyMzQiCnRlc3RfdWxv bmdfdHVuYWJsZS50dW5hYmxlPSI5MjIzMzcyMDM2ODU0Nzc1ODA4Igp0ZXN0X3Vsb25nX3R1bmFi bGUudHVuYWJsZT0iMTg0NDY3NDQwNzM3MDk1NTE2MTQiCnRlc3RfdWxvbmdfdHVuYWJsZS50dW5h YmxlPSIxODQ0Njc0NDA3MzcwOTU1MTYxNiIKdGVzdF91cXVhZF90dW5hYmxlLnR1bmFibGU9Ii0x Igp0ZXN0X3VxdWFkX3R1bmFibGUudHVuYWJsZT0iMCIKdGVzdF91cXVhZF90dW5hYmxlLnR1bmFi bGU9IjQyIgp0ZXN0X3VxdWFkX3R1bmFibGUudHVuYWJsZT0iYXNkZjEyMzQiCnRlc3RfdXF1YWRf dHVuYWJsZS50dW5hYmxlPSI5MjIzMzcyMDM2ODU0Nzc1ODA4Igp0ZXN0X3VxdWFkX3R1bmFibGUu dHVuYWJsZT0iMTg0NDY3NDQwNzM3MDk1NTE2MTQiCnRlc3RfdXF1YWRfdHVuYWJsZS50dW5hYmxl PSIxODQ0Njc0NDA3MzcwOTU1MTYxNiIKIyBEbWVzZyBvdXRwdXQKdGVzdF9pbnRfdHVuYWJsZTog MAp0ZXN0X2ludF90dW5hYmxlOiAtMQp0ZXN0X2ludF90dW5hYmxlOiAwCnRlc3RfaW50X3R1bmFi bGU6IDQyCnRlc3RfaW50X3R1bmFibGU6IDAKdGVzdF9pbnRfdHVuYWJsZTogLTIxNDc0ODM2NDcK dGVzdF9pbnRfdHVuYWJsZTogMAp0ZXN0X2ludF90dW5hYmxlOiAyMTQ3NDgzNjQ2CnRlc3RfaW50 X3R1bmFibGU6IDAKdGVzdF9sb25nX3R1bmFibGU6IDAKdGVzdF9sb25nX3R1bmFibGU6IDAKdGVz dF9sb25nX3R1bmFibGU6IDQyCnRlc3RfbG9uZ190dW5hYmxlOiAwCnRlc3RfbG9uZ190dW5hYmxl OiAtOTIyMzM3MjAzNjg1NDc3NTgwOAp0ZXN0X2xvbmdfdHVuYWJsZTogLTkyMjMzNzIwMzY4NTQ3 NzU4MDcKdGVzdF9sb25nX3R1bmFibGU6IDkyMjMzNzIwMzY4NTQ3NzU4MDYKdGVzdF9sb25nX3R1 bmFibGU6IDkyMjMzNzIwMzY4NTQ3NzU4MDcKdGVzdF9wb2ludGVyX3R1bmFibGU6IGZmZmZmZmZm ZmZmZmZmZmYKdGVzdF9wb2ludGVyX3R1bmFibGU6IDAKdGVzdF9wb2ludGVyX3R1bmFibGU6IDJh CnRlc3RfcG9pbnRlcl90dW5hYmxlOiBkZWFkYmVlZgp0ZXN0X3BvaW50ZXJfdHVuYWJsZTogMAp0 ZXN0X3BvaW50ZXJfdHVuYWJsZTogMWZmNmZiZmZmCnRlc3RfcG9pbnRlcl90dW5hYmxlOiAxZmY2 ZmMwMDEKdGVzdF9xdWFkX3R1bmFibGU6IDAKdGVzdF9xdWFkX3R1bmFibGU6IDAKdGVzdF9xdWFk X3R1bmFibGU6IDQyCnRlc3RfcXVhZF90dW5hYmxlOiAwCnRlc3RfcXVhZF90dW5hYmxlOiAtOTIy MzM3MjAzNjg1NDc3NTgwOAp0ZXN0X3F1YWRfdHVuYWJsZTogLTkyMjMzNzIwMzY4NTQ3NzU4MDcK dGVzdF9xdWFkX3R1bmFibGU6IDkyMjMzNzIwMzY4NTQ3NzU4MDYKdGVzdF9xdWFkX3R1bmFibGU6 IDkyMjMzNzIwMzY4NTQ3NzU4MDcKdGVzdF9zaXplX3R1bmFibGU6IDAKdGVzdF9zaXplX3R1bmFi bGU6IDE4NDQ2NzQ0MDczNzA5NTUxNjE1CnRlc3Rfc2l6ZV90dW5hYmxlOiAwCnRlc3Rfc2l6ZV90 dW5hYmxlOiA0Mgp0ZXN0X3NpemVfdHVuYWJsZTogMAp0ZXN0X3NpemVfdHVuYWJsZTogOTIyMzM3 MjAzNjg1NDc3NTgwOAp0ZXN0X3NpemVfdHVuYWJsZTogMTg0NDY3NDQwNzM3MDk1NTE2MTQKdGVz dF9zaXplX3R1bmFibGU6IDE4NDQ2NzQ0MDczNzA5NTUxNjE1CnRlc3Rfc3RyaW5nX3R1bmFibGU6 IAp0ZXN0X3N0cmluZ190dW5hYmxlOiAKdGVzdF9zdHJpbmdfdHVuYWJsZTogYXNkZjEyMzQKdGVz dF9zdHJpbmdfdHVuYWJsZTogY2hhcmFjdGVyCnRlc3Rfc3RyaW5nX3R1bmFibGU6IGFzb3J0b2Zs bwp0ZXN0X3R1bmFibGVfc3VmZml4ZXM6IDAKdGVzdF90dW5hYmxlX3N1ZmZpeGVzOiAtMQp0ZXN0 X3R1bmFibGVfc3VmZml4ZXM6IC0xMDczNzQxODI0CnRlc3RfdHVuYWJsZV9zdWZmaXhlczogLTEw NzM3NDE4MjQKdGVzdF90dW5hYmxlX3N1ZmZpeGVzOiAtMTAyNAp0ZXN0X3R1bmFibGVfc3VmZml4 ZXM6IC0xMDI0CnRlc3RfdHVuYWJsZV9zdWZmaXhlczogLTEwNDg1NzYKdGVzdF90dW5hYmxlX3N1 ZmZpeGVzOiAtMTA0ODU3Ngp0ZXN0X3R1bmFibGVfc3VmZml4ZXM6IC0xMDk5NTExNjI3Nzc2CnRl c3RfdHVuYWJsZV9zdWZmaXhlczogLTEwOTk1MTE2Mjc3NzYKdGVzdF90dW5hYmxlX3N1ZmZpeGVz OiAwCnRlc3RfdHVuYWJsZV9zdWZmaXhlczogMAp0ZXN0X3R1bmFibGVfc3VmZml4ZXM6IDAKdGVz dF90dW5hYmxlX3N1ZmZpeGVzOiAwCnRlc3RfdHVuYWJsZV9zdWZmaXhlczogMAp0ZXN0X3R1bmFi bGVfc3VmZml4ZXM6IDAKdGVzdF90dW5hYmxlX3N1ZmZpeGVzOiAwCnRlc3RfdHVuYWJsZV9zdWZm aXhlczogMAp0ZXN0X3R1bmFibGVfc3VmZml4ZXM6IDAKdGVzdF90dW5hYmxlX3N1ZmZpeGVzOiAw CnRlc3RfdHVuYWJsZV9zdWZmaXhlczogMAp0ZXN0X3R1bmFibGVfc3VmZml4ZXM6IDAKdGVzdF90 dW5hYmxlX3N1ZmZpeGVzOiAwCnRlc3RfdHVuYWJsZV9zdWZmaXhlczogMQp0ZXN0X3R1bmFibGVf c3VmZml4ZXM6IDEwNzM3NDE4MjQKdGVzdF90dW5hYmxlX3N1ZmZpeGVzOiAxMDczNzQxODI0CnRl c3RfdHVuYWJsZV9zdWZmaXhlczogMTAyNAp0ZXN0X3R1bmFibGVfc3VmZml4ZXM6IDEwMjQKdGVz dF90dW5hYmxlX3N1ZmZpeGVzOiAxMDQ4NTc2CnRlc3RfdHVuYWJsZV9zdWZmaXhlczogMTA0ODU3 Ngp0ZXN0X3R1bmFibGVfc3VmZml4ZXM6IDEwOTk1MTE2Mjc3NzYKdGVzdF90dW5hYmxlX3N1ZmZp eGVzOiAxMDk5NTExNjI3Nzc2CnRlc3RfdHVuYWJsZV9zdWZmaXhlczogMAp0ZXN0X3R1bmFibGVf c3VmZml4ZXM6IDAKdGVzdF91aW50X3R1bmFibGU6IDAKdGVzdF91aW50X3R1bmFibGU6IDAKdGVz dF91aW50X3R1bmFibGU6IDAKdGVzdF91aW50X3R1bmFibGU6IDQyCnRlc3RfdWludF90dW5hYmxl OiAwCnRlc3RfdWludF90dW5hYmxlOiAyMTQ3NDgzNjQ4CnRlc3RfdWludF90dW5hYmxlOiA0Mjk0 OTY3Mjk0CnRlc3RfdWludF90dW5hYmxlOiAwCnRlc3RfdWxvbmdfdHVuYWJsZTogMAp0ZXN0X3Vs b25nX3R1bmFibGU6IDE4NDQ2NzQ0MDczNzA5NTUxNjE1CnRlc3RfdWxvbmdfdHVuYWJsZTogMAp0 ZXN0X3Vsb25nX3R1bmFibGU6IDQyCnRlc3RfdWxvbmdfdHVuYWJsZTogMAp0ZXN0X3Vsb25nX3R1 bmFibGU6IDkyMjMzNzIwMzY4NTQ3NzU4MDgKdGVzdF91bG9uZ190dW5hYmxlOiAxODQ0Njc0NDA3 MzcwOTU1MTYxNAp0ZXN0X3Vsb25nX3R1bmFibGU6IDE4NDQ2NzQ0MDczNzA5NTUxNjE1CnRlc3Rf dXF1YWRfdHVuYWJsZTogMAp0ZXN0X3VxdWFkX3R1bmFibGU6IDE4NDQ2NzQ0MDczNzA5NTUxNjE1 CnRlc3RfdXF1YWRfdHVuYWJsZTogMAp0ZXN0X3VxdWFkX3R1bmFibGU6IDQyCnRlc3RfdXF1YWRf dHVuYWJsZTogMAp0ZXN0X3VxdWFkX3R1bmFibGU6IDkyMjMzNzIwMzY4NTQ3NzU4MDgKdGVzdF91 cXVhZF90dW5hYmxlOiAxODQ0Njc0NDA3MzcwOTU1MTYxNAp0ZXN0X3VxdWFkX3R1bmFibGU6IDE4 NDQ2NzQ0MDczNzA5NTUxNjE1Cg== --00221532c7aca694360492c40306-- From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 16 23:16:20 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8371106564A; Sat, 16 Oct 2010 23:16:20 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 536348FC1A; Sat, 16 Oct 2010 23:16:20 +0000 (UTC) Received: by iwn41 with SMTP id 41so1156731iwn.13 for ; Sat, 16 Oct 2010 16:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=SmVNNZqj29Gn/qpNyq5Z13mghAyt156zWSENwnw6FqI=; b=PSh7CXDeHHnAqgQCkgma+VQpYHMY/Ym8bb48ZO+rI1o6S4nn5CnwEjsN7KrzqzY+Uz LLppeMN4Be25af7TxaHBYaENm3h0478ar3hKiZlOfGpu+k/LQwrBqKoBSBYZGtau4hGJ rL5kKBfR4CurUXZs/kvvG88A+dIy5C11x4klY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=oD2FQ+IyQ7NSLUZuhGLBXcwqgshVADwJtGi3eOeSu+e/J0hcSIsq00u6rw/ypVvzgQ zxulGm3d94obdIhRwsh2FYUh/7Scbyshpm19EFLrfyBBVE5/hvceHIxt1BoQD5fv1tFK g9kwykmbNQF0np0K4uQf3K+5Q1IU6nbP+FyZU= MIME-Version: 1.0 Received: by 10.231.147.202 with SMTP id m10mr2006806ibv.2.1287270979677; Sat, 16 Oct 2010 16:16:19 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Sat, 16 Oct 2010 16:16:19 -0700 (PDT) In-Reply-To: References: <86fwyq8rsc.fsf@ds4.des.no> <86d3tujh72.fsf@ds4.des.no> <864of680wv.fsf@ds4.des.no> <8662zkurx9.fsf@ds4.des.no> <8662zg586z.fsf@ds4.des.no> Date: Sat, 16 Oct 2010 16:16:19 -0700 X-Google-Sender-Auth: w8N4GVWJoN2GBLcFMaxLpKUkRHE Message-ID: From: Garrett Cooper To: Garrett Cooper Content-Type: multipart/mixed; boundary=001485ea873c7936730492c421bb Cc: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= , Ivan Voras , freebsd-hackers@freebsd.org Subject: Re: Why is TUNABLE_INT discouraged? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 23:16:20 -0000 --001485ea873c7936730492c421bb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2010/10/16 Garrett Cooper : > 2010/8/12 Dag-Erling Sm=F8rgrav : >> Garrett Cooper writes: >>> Dag-Erling Sm=F8rgrav writes: >>> > It might be a good idea to introduce TUNABLE_POINTER and TUNABLE_SIZE= . >>> I would actually argue against doing that because it would only create >>> divergence between sysctl and tunable KPIs... >> >> Not if we also introduce corresponding SYSCTLs. =A0Note that my idea is = to >> have these as aliases for the correct primitive types. >> >>> (BTW, when you say TUNABLE_SIZE, I assume it would be a size_t quantity= ?) >> >> Yes. >> >>> Something might need to be done to the values returned by the tunables >>> though, because they don't respect boundaries, and can overflow right >>> now (which exacerbates the issue with values crammed into smaller >>> datatypes)... >> >> Yes. =A0How about this: >> >> =A0- rename getenv_quad() to getenv_signed() and getenv_unsigned() >> =A0- add min / max arguments >> =A0- implement getenv_quad() (and all the others) in terms of >> =A0 getenv_number() >> >> e.g. >> >> int >> getenv_uint(const char *name, unsigned int *data) >> { >> =A0 =A0 =A0 =A0unsigned long long tmp; >> =A0 =A0 =A0 =A0int rval; >> >> =A0 =A0 =A0 =A0if ((rval =3D getenv_unsigned(name, &tmp, 0, UINT_MAX)) = =3D=3D 0) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*data =3D (unsigned int)tmp; >> =A0 =A0 =A0 =A0return (rval); >> } >> >> (note that due to the min / max arguments, the complexity of handling >> both signed and unsigned values in the same function probably exceeds >> the complexity of having two very similar functions) > > Here's a draft of this work des@ challenged me to a while back. It > works well as demonstrated with my tests. The only catch with > detecting bounds is that if it's the minimum in the case of signed or > maximum representable value in the case of unsigned, then strtoq, etc > will clamp the value to the maximum representable value. > > Other than that it works well, and now tunables represented by > unsigned values should work better. > > Please let me know what you all think. > > Thanks! > -Garrett > > PS I added uquad_t for consistency in the APIs, even though quad_t was > deprecated, but I didn't bump __FreeBSD_version__ -- wasn't sure if I > should have done that). Let's try with the patch attached... --001485ea873c7936730492c421bb Content-Type: application/octet-stream; name="tunables-enhancement.diff" Content-Disposition: attachment; filename="tunables-enhancement.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gfd3u0a11 SW5kZXg6IHN5cy9rZXJuL2tlcm5fZW52aXJvbm1lbnQuYwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMva2Vy bi9rZXJuX2Vudmlyb25tZW50LmMJKHJldmlzaW9uIDIxMzkzNykKKysrIHN5cy9rZXJuL2tlcm5f ZW52aXJvbm1lbnQuYwkod29ya2luZyBjb3B5KQpAQCAtNTAsNiArNTAsNyBAQAogI2luY2x1ZGUg PHN5cy9zeXNlbnQuaD4KICNpbmNsdWRlIDxzeXMvc3lzcHJvdG8uaD4KICNpbmNsdWRlIDxzeXMv bGlia2Vybi5oPgorI2luY2x1ZGUgPHN5cy9saW1pdHMuaD4KICNpbmNsdWRlIDxzeXMva2Vudi5o PgogCiAjaW5jbHVkZSA8c2VjdXJpdHkvbWFjL21hY19mcmFtZXdvcmsuaD4KQEAgLTQ0MiwzMiAr NDQzLDExNSBAQAogfQogCiAvKgotICogUmV0dXJuIGEgc3RyaW5nIHZhbHVlIGZyb20gYW4gZW52 aXJvbm1lbnQgdmFyaWFibGUuCisgKiBSZXR1cm4gdGhlIG11bHRpcGxpZXIgZm9yIGEgdXNlciBz cGVjaWZpZWQgc3VmZml4IGZyb20gYSBnZXRlbnYgY2FsbC4KICAqLwordWludG1heF90CitnZXRl bnZfcGFyc2Vfc3VmZml4KGNvbnN0IGNoYXIgc3VmZml4KQoreworCXVpbnRtYXhfdCBtdWx0aXBs aWVyID0gMTsKKworCXN3aXRjaCAoc3VmZml4KSB7CisJY2FzZSAndCc6IGNhc2UgJ1QnOgorCQlt dWx0aXBsaWVyICo9IDEwMjQ7CisJY2FzZSAnZyc6IGNhc2UgJ0cnOgorCQltdWx0aXBsaWVyICo9 IDEwMjQ7CisJY2FzZSAnbSc6IGNhc2UgJ00nOgorCQltdWx0aXBsaWVyICo9IDEwMjQ7CisJY2Fz ZSAnayc6IGNhc2UgJ0snOgorCQltdWx0aXBsaWVyICo9IDEwMjQ7CisJY2FzZSAnXDAnOgorCQli cmVhazsKKwlkZWZhdWx0OgorCQltdWx0aXBsaWVyID0gMDsKKwl9CisKKwlyZXR1cm4gKG11bHRp cGxpZXIpOworfQorCisvKgorICogUmV0dXJuIGEgc2lnbmVkIHF1YW50aXR5IGZyb20gYW4gZW52 aXJvbm1lbnQgdmFyaWFibGUuCisgKi8KIGludAotZ2V0ZW52X3N0cmluZyhjb25zdCBjaGFyICpu YW1lLCBjaGFyICpkYXRhLCBpbnQgc2l6ZSkKK2dldGVudl9zaWduZWQoY29uc3QgY2hhciAqbmFt ZSwgaW50bWF4X3QgKmRhdGEsIGNvbnN0IGludG1heF90IG1pbiwKKyAgICBjb25zdCBpbnRtYXhf dCBtYXgpCiB7Ci0JY2hhciAqdG1wOworCXVpbnRtYXhfdAltdWx0aXBsaWVyOworCWludG1heF90 CWl2OworCWludAkJcmV0X2NvZGU7CisJY2hhcgkJKnZhbHVlOworCWNoYXIJCSp2dHA7CiAKLQl0 bXAgPSBnZXRlbnYobmFtZSk7Ci0JaWYgKHRtcCAhPSBOVUxMKSB7Ci0JCXN0cmxjcHkoZGF0YSwg dG1wLCBzaXplKTsKLQkJZnJlZWVudih0bXApOwotCQlyZXR1cm4gKDEpOwotCX0gZWxzZQotCQly ZXR1cm4gKDApOworCXJldF9jb2RlID0gMDsKKworCXZhbHVlID0gZ2V0ZW52KG5hbWUpOworCWlm ICh2YWx1ZSA9PSBOVUxMKQorCQlyZXR1cm4gKHJldF9jb2RlKTsKKwlpdiA9IHN0cnRvcSh2YWx1 ZSwgJnZ0cCwgMCk7CisJaWYgKHZ0cCA9PSB2YWx1ZSB8fCAodnRwWzBdICE9ICdcMCcgJiYgdnRw WzFdICE9ICdcMCcpIHx8CisJICAgIChtdWx0aXBsaWVyID0gZ2V0ZW52X3BhcnNlX3N1ZmZpeCh2 dHBbMF0pKSA9PSAwKSB7CisJCS8qIAorCQkgKiBDYXRjaCBlcnJvcnMgaW4gcGFyc2luZyB0aGUg bnVtYmVyLCBiYWQgaW5wdXQsIG9yIHRoZQorCQkgKiBzdWZmaXggaWYgb25lIHdhcyBzcGVjaWZp ZWQuCisJCSAqLworCQk7CisJfSBlbHNlIHsKKwkJaXYgKj0gbXVsdGlwbGllcjsKKwkJaWYgKG1p biA8PSBpdiAmJiBpdiA8PSBtYXgpIHsKKwkJCSpkYXRhID0gaXY7CisJCQlyZXRfY29kZSA9IDE7 CisJCX0KKwl9CisJZnJlZWVudih2YWx1ZSk7CisJcmV0dXJuIChyZXRfY29kZSk7CiB9CiAKIC8q CisgKiBSZXR1cm4gYW4gdW5zaWduZWQgcXVhbnRpdHkgZnJvbSBhbiBlbnZpcm9ubWVudCB2YXJp YWJsZS4KKyAqLworaW50CitnZXRlbnZfdW5zaWduZWQoY29uc3QgY2hhciAqbmFtZSwgdWludG1h eF90ICpkYXRhLCBjb25zdCB1aW50bWF4X3QgbWluLAorICAgIGNvbnN0IHVpbnRtYXhfdCBtYXgp Cit7CisJdWludG1heF90CW11bHRpcGxpZXI7CisJdWludG1heF90CXVpdjsKKwlpbnQJCXJldF9j b2RlOworCWNoYXIJCSp2YWx1ZTsKKwljaGFyCQkqdnRwOworCisJcmV0X2NvZGUgPSAwOworCisJ dmFsdWUgPSBnZXRlbnYobmFtZSk7CisJaWYgKHZhbHVlID09IE5VTEwpCisJCXJldHVybiAocmV0 X2NvZGUpOworCXVpdiA9IHN0cnRvdXEodmFsdWUsICZ2dHAsIDApOworCWlmICh2dHAgPT0gdmFs dWUgfHwgKHZ0cFswXSAhPSAnXDAnICYmIHZ0cFsxXSAhPSAnXDAnKSB8fAorCSAgICAobXVsdGlw bGllciA9IGdldGVudl9wYXJzZV9zdWZmaXgodnRwWzBdKSkgPT0gMCkgeworCQkvKiAKKwkJICog Q2F0Y2ggZXJyb3JzIGluIHBhcnNpbmcgdGhlIG51bWJlciwgYmFkIGlucHV0LCBvciB0aGUKKwkJ ICogc3VmZml4IGlmIG9uZSB3YXMgc3BlY2lmaWVkLgorCQkgKi8KKwkJOworCX0gZWxzZSB7CisJ CXVpdiAqPSBtdWx0aXBsaWVyOworCQlpZiAobWluIDw9IHVpdiAmJiB1aXYgPD0gbWF4KSB7CisJ CQkqZGF0YSA9IHVpdjsKKwkJCXJldF9jb2RlID0gMTsKKwkJfQorCX0KKwlmcmVlZW52KHZhbHVl KTsKKwlyZXR1cm4gKHJldF9jb2RlKTsKK30KKworLyoKICAqIFJldHVybiBhbiBpbnRlZ2VyIHZh bHVlIGZyb20gYW4gZW52aXJvbm1lbnQgdmFyaWFibGUuCiAgKi8KIGludAogZ2V0ZW52X2ludChj b25zdCBjaGFyICpuYW1lLCBpbnQgKmRhdGEpCiB7Ci0JcXVhZF90IHRtcDsKKwlpbnRtYXhfdCB0 bXA7CiAJaW50IHJ2YWw7CiAKLQlydmFsID0gZ2V0ZW52X3F1YWQobmFtZSwgJnRtcCk7CisJcnZh bCA9IGdldGVudl9zaWduZWQobmFtZSwgJnRtcCwgSU5UX01JTiwgSU5UX01BWCk7CiAJaWYgKHJ2 YWwpCiAJCSpkYXRhID0gKGludCkgdG1wOwogCXJldHVybiAocnZhbCk7CkBAIC00NzksMTAgKzU2 MywxMCBAQAogaW50CiBnZXRlbnZfdWludChjb25zdCBjaGFyICpuYW1lLCB1bnNpZ25lZCBpbnQg KmRhdGEpCiB7Ci0JcXVhZF90IHRtcDsKKwlpbnRtYXhfdCB0bXA7CiAJaW50IHJ2YWw7CiAKLQly dmFsID0gZ2V0ZW52X3F1YWQobmFtZSwgJnRtcCk7CisJcnZhbCA9IGdldGVudl91bnNpZ25lZChu YW1lLCAmdG1wLCAwLCBVSU5UX01BWCk7CiAJaWYgKHJ2YWwpCiAJCSpkYXRhID0gKHVuc2lnbmVk IGludCkgdG1wOwogCXJldHVybiAocnZhbCk7CkBAIC00OTQsMTAgKzU3OCwxMCBAQAogaW50CiBn ZXRlbnZfbG9uZyhjb25zdCBjaGFyICpuYW1lLCBsb25nICpkYXRhKQogewotCXF1YWRfdCB0bXA7 CisJaW50bWF4X3QgdG1wOwogCWludCBydmFsOwogCi0JcnZhbCA9IGdldGVudl9xdWFkKG5hbWUs ICZ0bXApOworCXJ2YWwgPSBnZXRlbnZfc2lnbmVkKG5hbWUsICZ0bXAsIExPTkdfTUlOLCBMT05H X01BWCk7CiAJaWYgKHJ2YWwpCiAJCSpkYXRhID0gKGxvbmcpIHRtcDsKIAlyZXR1cm4gKHJ2YWwp OwpAQCAtNTA5LDUxICs1OTMsOTAgQEAKIGludAogZ2V0ZW52X3Vsb25nKGNvbnN0IGNoYXIgKm5h bWUsIHVuc2lnbmVkIGxvbmcgKmRhdGEpCiB7Ci0JcXVhZF90IHRtcDsKKwlpbnRtYXhfdCB0bXA7 CiAJaW50IHJ2YWw7CiAKLQlydmFsID0gZ2V0ZW52X3F1YWQobmFtZSwgJnRtcCk7CisJcnZhbCA9 IGdldGVudl91bnNpZ25lZChuYW1lLCAmdG1wLCAwLCBVTE9OR19NQVgpOwogCWlmIChydmFsKQog CQkqZGF0YSA9ICh1bnNpZ25lZCBsb25nKSB0bXA7CiAJcmV0dXJuIChydmFsKTsKIH0KIAogLyoK KyAqIFJldHVybiBhIHBvaW50ZXIgZnJvbSBhbiBlbnZpcm9ubWVudCB2YXJpYWJsZS4KKyAqLwor aW50CitnZXRlbnZfcG9pbnRlcihjb25zdCBjaGFyICpuYW1lLCB1aW50cHRyX3QgKmRhdGEpCit7 CisJaW50bWF4X3QgdG1wOworCWludCBydmFsOworCisJcnZhbCA9IGdldGVudl91bnNpZ25lZChu YW1lLCAmdG1wLCAwLCBVSU5UUFRSX01BWCk7CisJaWYgKHJ2YWwpCisJCSpkYXRhID0gKHVpbnRw dHJfdCkgdG1wOworCXJldHVybiAocnZhbCk7Cit9CisKKy8qCiAgKiBSZXR1cm4gYSBxdWFkX3Qg dmFsdWUgZnJvbSBhbiBlbnZpcm9ubWVudCB2YXJpYWJsZS4KICAqLwogaW50CiBnZXRlbnZfcXVh ZChjb25zdCBjaGFyICpuYW1lLCBxdWFkX3QgKmRhdGEpCiB7Ci0JY2hhcgkqdmFsdWU7Ci0JY2hh cgkqdnRwOwotCXF1YWRfdAlpdjsKKwlpbnRtYXhfdCB0bXA7CisJaW50IHJ2YWw7CiAKLQl2YWx1 ZSA9IGdldGVudihuYW1lKTsKLQlpZiAodmFsdWUgPT0gTlVMTCkKKwlydmFsID0gZ2V0ZW52X3Np Z25lZChuYW1lLCAmdG1wLCBRVUFEX01JTiwgUVVBRF9NQVgpOworCWlmIChydmFsKQorCQkqZGF0 YSA9IChxdWFkX3QpIHRtcDsKKwlyZXR1cm4gKHJ2YWwpOworfQorCisvKgorICogUmV0dXJuIGEg dXF1YWRfdCB2YWx1ZSBmcm9tIGFuIGVudmlyb25tZW50IHZhcmlhYmxlLgorICovCitpbnQKK2dl dGVudl91cXVhZChjb25zdCBjaGFyICpuYW1lLCB1cXVhZF90ICpkYXRhKQoreworCWludG1heF90 IHRtcDsKKwlpbnQgcnZhbDsKKworCXJ2YWwgPSBnZXRlbnZfdW5zaWduZWQobmFtZSwgJnRtcCwg MCwgVVFVQURfTUFYKTsKKwlpZiAocnZhbCkKKwkJKmRhdGEgPSAodXF1YWRfdCkgdG1wOworCXJl dHVybiAocnZhbCk7Cit9CisKKy8qCisgKiBSZXR1cm4gYSBzaXplX3QgdmFsdWUgZnJvbSBhbiBl bnZpcm9ubWVudCB2YXJpYWJsZS4KKyAqLworaW50CitnZXRlbnZfc2l6ZShjb25zdCBjaGFyICpu YW1lLCBzaXplX3QgKmRhdGEpCit7CisJaW50bWF4X3QgdG1wOworCWludCBydmFsOworCisJcnZh bCA9IGdldGVudl91bnNpZ25lZChuYW1lLCAmdG1wLCAwLCBTSVpFX01BWCk7CisJaWYgKHJ2YWwp CisJCSpkYXRhID0gKHNpemVfdCkgdG1wOworCXJldHVybiAocnZhbCk7Cit9CisKKy8qCisgKiBS ZXR1cm4gYSBzdHJpbmcgdmFsdWUgZnJvbSBhbiBlbnZpcm9ubWVudCB2YXJpYWJsZS4KKyAqLwor aW50CitnZXRlbnZfc3RyaW5nKGNvbnN0IGNoYXIgKm5hbWUsIGNoYXIgKmRhdGEsIHNpemVfdCBz aXplKQoreworCWNoYXIgKnRtcDsKKworCXRtcCA9IGdldGVudihuYW1lKTsKKwlpZiAodG1wICE9 IE5VTEwpIHsKKwkJc3RybGNweShkYXRhLCB0bXAsIHNpemUpOworCQlmcmVlZW52KHRtcCk7CisJ CXJldHVybiAoMSk7CisJfSBlbHNlCiAJCXJldHVybiAoMCk7Ci0JaXYgPSBzdHJ0b3EodmFsdWUs ICZ2dHAsIDApOwotCWlmICh2dHAgPT0gdmFsdWUgfHwgKHZ0cFswXSAhPSAnXDAnICYmIHZ0cFsx XSAhPSAnXDAnKSkgewotCQlmcmVlZW52KHZhbHVlKTsKLQkJcmV0dXJuICgwKTsKLQl9Ci0Jc3dp dGNoICh2dHBbMF0pIHsKLQljYXNlICd0JzogY2FzZSAnVCc6Ci0JCWl2ICo9IDEwMjQ7Ci0JY2Fz ZSAnZyc6IGNhc2UgJ0cnOgotCQlpdiAqPSAxMDI0OwotCWNhc2UgJ20nOiBjYXNlICdNJzoKLQkJ aXYgKj0gMTAyNDsKLQljYXNlICdrJzogY2FzZSAnSyc6Ci0JCWl2ICo9IDEwMjQ7Ci0JY2FzZSAn XDAnOgotCQlicmVhazsKLQlkZWZhdWx0OgotCQlmcmVlZW52KHZhbHVlKTsKLQkJcmV0dXJuICgw KTsKLQl9Ci0JKmRhdGEgPSBpdjsKLQlmcmVlZW52KHZhbHVlKTsKLQlyZXR1cm4gKDEpOwogfQog CiAvKgpAQCAtNTgzLDYgKzcwNiwxNCBAQAogfQogCiB2b2lkCit0dW5hYmxlX3VpbnRfaW5pdCh2 b2lkICpkYXRhKQoreworCXN0cnVjdCB0dW5hYmxlX3VpbnQgKmQgPSAoc3RydWN0IHR1bmFibGVf dWludCAqKWRhdGE7CisKKwlUVU5BQkxFX1VJTlRfRkVUQ0goZC0+cGF0aCwgZC0+dmFyKTsKK30K Kwordm9pZAogdHVuYWJsZV9sb25nX2luaXQodm9pZCAqZGF0YSkKIHsKIAlzdHJ1Y3QgdHVuYWJs ZV9sb25nICpkID0gKHN0cnVjdCB0dW5hYmxlX2xvbmcgKilkYXRhOwpAQCAtNTk5LDYgKzczMCwx NCBAQAogfQogCiB2b2lkCit0dW5hYmxlX3BvaW50ZXJfaW5pdCh2b2lkICpkYXRhKQoreworCXN0 cnVjdCB0dW5hYmxlX3BvaW50ZXIgKmQgPSAoc3RydWN0IHR1bmFibGVfcG9pbnRlciAqKWRhdGE7 CisKKwlUVU5BQkxFX1BPSU5URVJfRkVUQ0goZC0+cGF0aCwgZC0+dmFyKTsKK30KKwordm9pZAog dHVuYWJsZV9xdWFkX2luaXQodm9pZCAqZGF0YSkKIHsKIAlzdHJ1Y3QgdHVuYWJsZV9xdWFkICpk ID0gKHN0cnVjdCB0dW5hYmxlX3F1YWQgKilkYXRhOwpAQCAtNjA3LDYgKzc0NiwyMiBAQAogfQog CiB2b2lkCit0dW5hYmxlX3VxdWFkX2luaXQodm9pZCAqZGF0YSkKK3sKKwlzdHJ1Y3QgdHVuYWJs ZV91cXVhZCAqZCA9IChzdHJ1Y3QgdHVuYWJsZV91cXVhZCAqKWRhdGE7CisKKwlUVU5BQkxFX1VR VUFEX0ZFVENIKGQtPnBhdGgsIGQtPnZhcik7Cit9CisKK3ZvaWQKK3R1bmFibGVfc2l6ZV9pbml0 KHZvaWQgKmRhdGEpCit7CisJc3RydWN0IHR1bmFibGVfc2l6ZSAqZCA9IChzdHJ1Y3QgdHVuYWJs ZV9zaXplICopZGF0YTsKKworCVRVTkFCTEVfU0laRV9GRVRDSChkLT5wYXRoLCBkLT52YXIpOwor fQorCit2b2lkCiB0dW5hYmxlX3N0cl9pbml0KHZvaWQgKmRhdGEpCiB7CiAJc3RydWN0IHR1bmFi bGVfc3RyICpkID0gKHN0cnVjdCB0dW5hYmxlX3N0ciAqKWRhdGE7CkluZGV4OiBzeXMvc3lzL2tl cm5lbC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9zeXMva2VybmVsLmgJKHJldmlzaW9uIDIxMzkzNykK KysrIHN5cy9zeXMva2VybmVsLmgJKHdvcmtpbmcgY29weSkKQEAgLTI3NSw3ICsyNzUsOSBAQAog CiAvKgogICogaW50Ci0gKiBwbGVhc2UgYXZvaWQgdXNpbmcgZm9yIG5ldyB0dW5hYmxlcyEKKyAq CisgKiBQbGVhc2UgZG8gbm90IHVzZSBmb3IgYWRkcmVzc2VzIG9yIHBvaW50ZXJzICh1c2UgdGhl IHBvaW50ZXIgdHVuYWJsZQorICogaW5zdGVhZCksIG9yIHNpemVzICh1c2UgdGhlIHNpemUgdHVu YWJsZSBpbnN0ZWFkKS4KICAqLwogZXh0ZXJuIHZvaWQgdHVuYWJsZV9pbnRfaW5pdCh2b2lkICop Owogc3RydWN0IHR1bmFibGVfaW50IHsKQEAgLTI5NCw2ICsyOTYsMjggQEAKICNkZWZpbmUJVFVO QUJMRV9JTlRfRkVUQ0gocGF0aCwgdmFyKQlnZXRlbnZfaW50KChwYXRoKSwgKHZhcikpCiAKIC8q CisgKiB1bnNpZ25lZCBpbnQKKyAqCisgKiBQbGVhc2UgZG8gbm90IHVzZSBmb3IgYWRkcmVzc2Vz IG9yIHBvaW50ZXJzICh1c2UgdGhlIHBvaW50ZXIgdHVuYWJsZQorICogaW5zdGVhZCksIG9yIHNp emVzICh1c2UgdGhlIHNpemUgdHVuYWJsZSBpbnN0ZWFkKS4KKyAqLworZXh0ZXJuIHZvaWQgdHVu YWJsZV91aW50X2luaXQodm9pZCAqKTsKK3N0cnVjdCB0dW5hYmxlX3VpbnQgeworCWNvbnN0IGNo YXIgKnBhdGg7CisJdW5zaWduZWQgaW50ICp2YXI7Cit9OworI2RlZmluZQlUVU5BQkxFX1VJTlQo cGF0aCwgdmFyKQkJCQkJXAorCXN0YXRpYyBzdHJ1Y3QgdHVuYWJsZV91aW50IF9fQ09OQ0FUKF9f dHVuYWJsZV91aW50XywgX19MSU5FX18pID0geyBcCisJCShwYXRoKSwJCQkJCQlcCisJCSh2YXIp LAkJCQkJCVwKKwl9OwkJCQkJCQlcCisJU1lTSU5JVChfX0NPTkNBVChfX1R1bmFibGVfaW5pdF8s IF9fTElORV9fKSwJCVwKKwkgICAgU0lfU1VCX1RVTkFCTEVTLCBTSV9PUkRFUl9NSURETEUsIHR1 bmFibGVfdWludF9pbml0LCBcCisJICAgICZfX0NPTkNBVChfX3R1bmFibGVfdWludF8sIF9fTElO RV9fKSkKKworI2RlZmluZQlUVU5BQkxFX1VJTlRfRkVUQ0gocGF0aCwgdmFyKQlnZXRlbnZfdWlu dCgocGF0aCksICh2YXIpKQorCisvKgogICogbG9uZwogICovCiBleHRlcm4gdm9pZCB0dW5hYmxl X2xvbmdfaW5pdCh2b2lkICopOwpAQCAtMzMyLDggKzM1NiwyOCBAQAogI2RlZmluZQlUVU5BQkxF X1VMT05HX0ZFVENIKHBhdGgsIHZhcikJZ2V0ZW52X3Vsb25nKChwYXRoKSwgKHZhcikpCiAKIC8q Ci0gKiBxdWFkCisgKiBwb2ludGVyCiAgKi8KK2V4dGVybiB2b2lkIHR1bmFibGVfcG9pbnRlcl9p bml0KHZvaWQgKik7CitzdHJ1Y3QgdHVuYWJsZV9wb2ludGVyIHsKKwljb25zdCBjaGFyICpwYXRo OworCXVpbnRwdHJfdCAqdmFyOworfTsKKyNkZWZpbmUJVFVOQUJMRV9QT0lOVEVSKHBhdGgsIHZh cikJCQkJXAorCXN0YXRpYyBzdHJ1Y3QgdHVuYWJsZV9wb2ludGVyIF9fQ09OQ0FUKF9fdHVuYWJs ZV9wb2ludGVyXywgX19MSU5FX18pID0geyBcCisJCShwYXRoKSwJCQkJCQlcCisJCSh2YXIpLAkJ CQkJCVwKKwl9OwkJCQkJCQlcCisJU1lTSU5JVChfX0NPTkNBVChfX1R1bmFibGVfaW5pdF8sIF9f TElORV9fKSwJCVwKKwkgICAgU0lfU1VCX1RVTkFCTEVTLCBTSV9PUkRFUl9NSURETEUsIHR1bmFi bGVfcG9pbnRlcl9pbml0LCBcCisJICAgICZfX0NPTkNBVChfX3R1bmFibGVfcG9pbnRlcl8sIF9f TElORV9fKSkKKworI2RlZmluZQlUVU5BQkxFX1BPSU5URVJfRkVUQ0gocGF0aCwgdmFyKQkJCVwK KwlnZXRlbnZfcG9pbnRlcigocGF0aCksICh2YXIpKQorCisvKgorICogcXVhZF90CisgKi8KIGV4 dGVybiB2b2lkIHR1bmFibGVfcXVhZF9pbml0KHZvaWQgKik7CiBzdHJ1Y3QgdHVuYWJsZV9xdWFk IHsKIAljb25zdCBjaGFyICpwYXRoOwpAQCAtMzUwLDYgKzM5NCwyOCBAQAogCiAjZGVmaW5lCVRV TkFCTEVfUVVBRF9GRVRDSChwYXRoLCB2YXIpCWdldGVudl9xdWFkKChwYXRoKSwgKHZhcikpCiAK Ky8qCisgKiBzaXplX3QKKyAqLworZXh0ZXJuIHZvaWQgdHVuYWJsZV9zaXplX2luaXQodm9pZCAq KTsKK3N0cnVjdCB0dW5hYmxlX3NpemUgeworCWNvbnN0IGNoYXIgKnBhdGg7CisJc2l6ZV90ICp2 YXI7Cit9OworI2RlZmluZQlUVU5BQkxFX1NJWkUocGF0aCwgdmFyKQkJCQkJXAorCXN0YXRpYyBz dHJ1Y3QgdHVuYWJsZV9zaXplIF9fQ09OQ0FUKF9fdHVuYWJsZV9zaXplXywgX19MSU5FX18pID0g eyBcCisJCShwYXRoKSwJCQkJCQlcCisJCSh2YXIpLAkJCQkJCVwKKwl9OwkJCQkJCQlcCisJU1lT SU5JVChfX0NPTkNBVChfX1R1bmFibGVfaW5pdF8sIF9fTElORV9fKSwJCVwKKwkgICAgU0lfU1VC X1RVTkFCTEVTLCBTSV9PUkRFUl9NSURETEUsIHR1bmFibGVfc2l6ZV9pbml0LCBcCisJICAgICZf X0NPTkNBVChfX3R1bmFibGVfc2l6ZV8sIF9fTElORV9fKSkKKworI2RlZmluZQlUVU5BQkxFX1NJ WkVfRkVUQ0gocGF0aCwgdmFyKQlnZXRlbnZfc2l6ZSgocGF0aCksICh2YXIpKQorCisvKgorICog c3RyaW5ncworICovCiBleHRlcm4gdm9pZCB0dW5hYmxlX3N0cl9pbml0KHZvaWQgKik7CiBzdHJ1 Y3QgdHVuYWJsZV9zdHIgewogCWNvbnN0IGNoYXIgKnBhdGg7CkBAIC0zNjksNiArNDM1LDI1IEBA CiAjZGVmaW5lCVRVTkFCTEVfU1RSX0ZFVENIKHBhdGgsIHZhciwgc2l6ZSkJCQlcCiAJZ2V0ZW52 X3N0cmluZygocGF0aCksICh2YXIpLCAoc2l6ZSkpCiAKKy8qCisgKiB1cXVhZF90CisgKi8KK2V4 dGVybiB2b2lkIHR1bmFibGVfdXF1YWRfaW5pdCh2b2lkICopOworc3RydWN0IHR1bmFibGVfdXF1 YWQgeworCWNvbnN0IGNoYXIgKnBhdGg7CisJdXF1YWRfdCAqdmFyOworfTsKKyNkZWZpbmUJVFVO QUJMRV9VUVVBRChwYXRoLCB2YXIpCQkJCQlcCisJc3RhdGljIHN0cnVjdCB0dW5hYmxlX3VxdWFk IF9fQ09OQ0FUKF9fdHVuYWJsZV91cXVhZF8sIF9fTElORV9fKSA9IHsgXAorCQkocGF0aCksCQkJ CQkJXAorCQkodmFyKSwJCQkJCQlcCisJfTsJCQkJCQkJXAorCVNZU0lOSVQoX19DT05DQVQoX19U dW5hYmxlX2luaXRfLCBfX0xJTkVfXyksCQlcCisJICAgIFNJX1NVQl9UVU5BQkxFUywgU0lfT1JE RVJfTUlERExFLCB0dW5hYmxlX3VxdWFkX2luaXQsIFwKKwkgICAgJl9fQ09OQ0FUKF9fdHVuYWJs ZV91cXVhZF8sIF9fTElORV9fKSkKKworI2RlZmluZQlUVU5BQkxFX1VRVUFEX0ZFVENIKHBhdGgs IHZhcikJZ2V0ZW52X3VxdWFkKChwYXRoKSwgKHZhcikpCisKIHN0cnVjdCBpbnRyX2NvbmZpZ19o b29rIHsKIAlUQUlMUV9FTlRSWShpbnRyX2NvbmZpZ19ob29rKSBpY2hfbGlua3M7CiAJdm9pZAko KmljaF9mdW5jKSh2b2lkICphcmcpOwpJbmRleDogc3lzL3N5cy9zeXN0bS5oCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIHN5cy9zeXMvc3lzdG0uaAkocmV2aXNpb24gMjEzOTM3KQorKysgc3lzL3N5cy9zeXN0bS5o CSh3b3JraW5nIGNvcHkpCkBAIC0yNjAsMTIgKzI2MCwyMCBAQAogCiBjaGFyCSpnZXRlbnYoY29u c3QgY2hhciAqbmFtZSk7CiB2b2lkCWZyZWVlbnYoY2hhciAqZW52KTsKK3VpbnRtYXhfdCBnZXRl bnZfcGFyc2Vfc3VmZml4KGNvbnN0IGNoYXIgc3VmZml4KTsKK2ludAlnZXRlbnZfc2lnbmVkKGNv bnN0IGNoYXIgKm5hbWUsIGludG1heF90ICpkYXRhLCBjb25zdCBpbnRtYXhfdCBtaW4sCisJICAg IGNvbnN0IGludG1heF90IG1heCk7CitpbnQJZ2V0ZW52X3Vuc2lnbmVkKGNvbnN0IGNoYXIgKm5h bWUsIHVpbnRtYXhfdCAqZGF0YSwKKwkgICAgY29uc3QgdWludG1heF90IG1pbiwgY29uc3QgdWlu dG1heF90IG1heCk7CiBpbnQJZ2V0ZW52X2ludChjb25zdCBjaGFyICpuYW1lLCBpbnQgKmRhdGEp OwogaW50CWdldGVudl91aW50KGNvbnN0IGNoYXIgKm5hbWUsIHVuc2lnbmVkIGludCAqZGF0YSk7 CiBpbnQJZ2V0ZW52X2xvbmcoY29uc3QgY2hhciAqbmFtZSwgbG9uZyAqZGF0YSk7CiBpbnQJZ2V0 ZW52X3Vsb25nKGNvbnN0IGNoYXIgKm5hbWUsIHVuc2lnbmVkIGxvbmcgKmRhdGEpOwotaW50CWdl dGVudl9zdHJpbmcoY29uc3QgY2hhciAqbmFtZSwgY2hhciAqZGF0YSwgaW50IHNpemUpOworaW50 CWdldGVudl9wb2ludGVyKGNvbnN0IGNoYXIgKm5hbWUsIHVpbnRwdHJfdCAqZGF0YSk7CiBpbnQJ Z2V0ZW52X3F1YWQoY29uc3QgY2hhciAqbmFtZSwgcXVhZF90ICpkYXRhKTsKK2ludAlnZXRlbnZf dXF1YWQoY29uc3QgY2hhciAqbmFtZSwgdXF1YWRfdCAqZGF0YSk7CitpbnQJZ2V0ZW52X3NpemUo Y29uc3QgY2hhciAqbmFtZSwgc2l6ZV90ICpkYXRhKTsKK2ludAlnZXRlbnZfc3RyaW5nKGNvbnN0 IGNoYXIgKm5hbWUsIGNoYXIgKmRhdGEsIHNpemVfdCBzaXplKTsKIGludAlzZXRlbnYoY29uc3Qg Y2hhciAqbmFtZSwgY29uc3QgY2hhciAqdmFsdWUpOwogaW50CXVuc2V0ZW52KGNvbnN0IGNoYXIg Km5hbWUpOwogaW50CXRlc3RlbnYoY29uc3QgY2hhciAqbmFtZSk7CkluZGV4OiBzeXMvc3lzL3N5 c3RtLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gc3lzL3N5cy9zeXN0bS5oCShyZXZpc2lvbiAyMTM5MzcpCisr KyBzeXMvc3lzL3N5c3RtLmgJKHdvcmtpbmcgY29weSkKQEAgLTI2MCwxMiArMjYwLDIwIEBACiAK IGNoYXIJKmdldGVudihjb25zdCBjaGFyICpuYW1lKTsKIHZvaWQJZnJlZWVudihjaGFyICplbnYp OwordWludG1heF90IGdldGVudl9wYXJzZV9zdWZmaXgoY29uc3QgY2hhciBzdWZmaXgpOworaW50 CWdldGVudl9zaWduZWQoY29uc3QgY2hhciAqbmFtZSwgaW50bWF4X3QgKmRhdGEsIGNvbnN0IGlu dG1heF90IG1pbiwKKwkgICAgY29uc3QgaW50bWF4X3QgbWF4KTsKK2ludAlnZXRlbnZfdW5zaWdu ZWQoY29uc3QgY2hhciAqbmFtZSwgdWludG1heF90ICpkYXRhLAorCSAgICBjb25zdCB1aW50bWF4 X3QgbWluLCBjb25zdCB1aW50bWF4X3QgbWF4KTsKIGludAlnZXRlbnZfaW50KGNvbnN0IGNoYXIg Km5hbWUsIGludCAqZGF0YSk7CiBpbnQJZ2V0ZW52X3VpbnQoY29uc3QgY2hhciAqbmFtZSwgdW5z aWduZWQgaW50ICpkYXRhKTsKIGludAlnZXRlbnZfbG9uZyhjb25zdCBjaGFyICpuYW1lLCBsb25n ICpkYXRhKTsKIGludAlnZXRlbnZfdWxvbmcoY29uc3QgY2hhciAqbmFtZSwgdW5zaWduZWQgbG9u ZyAqZGF0YSk7Ci1pbnQJZ2V0ZW52X3N0cmluZyhjb25zdCBjaGFyICpuYW1lLCBjaGFyICpkYXRh LCBpbnQgc2l6ZSk7CitpbnQJZ2V0ZW52X3BvaW50ZXIoY29uc3QgY2hhciAqbmFtZSwgdWludHB0 cl90ICpkYXRhKTsKIGludAlnZXRlbnZfcXVhZChjb25zdCBjaGFyICpuYW1lLCBxdWFkX3QgKmRh dGEpOworaW50CWdldGVudl91cXVhZChjb25zdCBjaGFyICpuYW1lLCB1cXVhZF90ICpkYXRhKTsK K2ludAlnZXRlbnZfc2l6ZShjb25zdCBjaGFyICpuYW1lLCBzaXplX3QgKmRhdGEpOworaW50CWdl dGVudl9zdHJpbmcoY29uc3QgY2hhciAqbmFtZSwgY2hhciAqZGF0YSwgc2l6ZV90IHNpemUpOwog aW50CXNldGVudihjb25zdCBjaGFyICpuYW1lLCBjb25zdCBjaGFyICp2YWx1ZSk7CiBpbnQJdW5z ZXRlbnYoY29uc3QgY2hhciAqbmFtZSk7CiBpbnQJdGVzdGVudihjb25zdCBjaGFyICpuYW1lKTsK SW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvbG9uZy90ZXN0X2xvbmdfdHVuYWJsZS5z aAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL2xvbmcvdGVzdF9sb25n X3R1bmFibGUuc2gJKHJldmlzaW9uIDApCisrKyB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL2xv bmcvdGVzdF9sb25nX3R1bmFibGUuc2gJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsNDAgQEAKKyMh L2Jpbi9zaAorIworIyBFeHBlY3RlZCB2YWx1ZXM6CisjICh1bnNldCkgICAgOiAgICAgICAgICAg MAorIyAgICAgICAwICAgIDogICAgICAgICAgIDAKKyMgICAgICA0MiAgICA6ICAgICAgICAgIDQy CisjIGFzZGYxMjM0ICAgOiAgICAgICAgICAgMCAocmVqZWN0KQorIyBMT05HX01JTi0xIDogIExP TkdfTUlOCisjIExPTkdfTUlOKzEgOiAgTE9OR19NSU4rMQorIyBMT05HX01BWC0xIDogIExPTkdf TUFYLTEKKyMgTE9OR19NQVgrMSA6ICBMT05HX01BWAorIworCitNT0ROQU1FPSIkKGJhc2VuYW1l ICIkMCIgLnNoKSIKKwordGVzdF9tb2R1bGUoKSB7CisJa2xkbG9hZCAuLyRNT0ROQU1FLmtvCisJ a2xkdW5sb2FkIC4vJE1PRE5BTUUua28KK30KKworY2FzZSAiJCgkKGRpcm5hbWUgIiQwIikvLi4v dG9vbHMvZ2V0d29yZHNpemUpIiBpbgorMzIpCisJTE9OR19NSU5fTUlOVVNfMT0iLTIxNDc0ODM2 NDkiCisJTE9OR19NSU5fUExVU18xPSItMjE0NzQ4MzY0NyIKKwlMT05HX01BWF9NSU5VU18xPTIx NDc0ODM2NDcKKwlMT05HX01BWF9QTFVTXzE9MjE0NzQ4MzY0OQorCTs7Cis2NCkKKwlMT05HX01J Tl9NSU5VU18xPSItOTIyMzM3MjAzNjg1NDc3NTgwOSIKKwlMT05HX01JTl9QTFVTXzE9Ii05MjIz MzcyMDM2ODU0Nzc1ODA3IgorCUxPTkdfTUFYX01JTlVTXzE9OTIyMzM3MjAzNjg1NDc3NTgwNgor CUxPTkdfTUFYX1BMVVNfMT05MjIzMzcyMDM2ODU0Nzc1ODA4CisJOzsKK2VzYWMKK2tlbnYgLXUg JE1PRE5BTUUudHVuYWJsZSAyPi9kZXYvbnVsbAordGVzdF9tb2R1bGUKK2ZvciBpIGluIDAgNDIg YXNkZjEyMzQgJExPTkdfTUlOX01JTlVTXzEgJExPTkdfTUlOX1BMVVNfMSAkTE9OR19NQVhfTUlO VVNfMSAkTE9OR19NQVhfUExVU18xIDsgZG8KKwlrZW52ICRNT0ROQU1FLnR1bmFibGU9IiRpIgor CXRlc3RfbW9kdWxlCitkb25lCkluZGV4OiB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL2xvbmcv dGVzdF9sb25nX3R1bmFibGUuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFi bGVzL2xvbmcvdGVzdF9sb25nX3R1bmFibGUuYwkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jl c3Npb24vdHVuYWJsZXMvbG9uZy90ZXN0X2xvbmdfdHVuYWJsZS5jCShyZXZpc2lvbiAwKQpAQCAt MCwwICsxLDMxIEBACisjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjaW5jbHVkZSA8c3lzL3R5cGVz Lmg+CisjaW5jbHVkZSA8c3lzL3Byb2MuaD4KKyNpbmNsdWRlIDxzeXMvbW9kdWxlLmg+CisjaW5j bHVkZSA8c3lzL2tlcm5lbC5oPgorI2luY2x1ZGUgPHN5cy9zeXN0bS5oPgorCisjZGVmaW5lIE1P RFVMRV9OQU1FCSJ0ZXN0X2xvbmdfdHVuYWJsZSIKKworc3RhdGljIGxvbmcgdHVuYWJsZSA9IDA7 CisKK1RVTkFCTEVfTE9ORygidGVzdF9sb25nX3R1bmFibGUudHVuYWJsZSIsICZ0dW5hYmxlKTsK Kworc3RhdGljIGludAorbG9hZCAobW9kdWxlX3QgbSwgaW50IHdoYXQsIHZvaWQgKmFyZykKK3sK Kwlzd2l0Y2ggKHdoYXQpIHsKKwljYXNlIE1PRF9MT0FEOgorCQlwcmludGYoIiVzOiAlbGRcbiIs IE1PRFVMRV9OQU1FLCB0dW5hYmxlKTsKKwkJYnJlYWs7CisJfQorCXJldHVybiAoMCk7Cit9CisK K3N0YXRpYyBtb2R1bGVkYXRhX3QgdGVzdF9sb25nX3R1bmFibGVfbW9kID0geworCU1PRFVMRV9O QU1FLAorCWxvYWQsCit9OworREVDTEFSRV9NT0RVTEUodGVzdF9sb25nX3R1bmFibGUsIHRlc3Rf bG9uZ190dW5hYmxlX21vZCwgU0lfU1VCX0tMRCwKKyAgICBTSV9PUkRFUl9BTlkpOworTU9EVUxF X1ZFUlNJT04odGVzdF9sb25nX3R1bmFibGUsIDEpOwpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90 dW5hYmxlcy9sb25nL01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHRvb2xzL3JlZ3Jlc3Npb24vdHVu YWJsZXMvbG9uZy9NYWtlZmlsZQkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVu YWJsZXMvbG9uZy9NYWtlZmlsZQkocmV2aXNpb24gMCkKQEAgLTAsMCArMSw0IEBACitLTU9EPQl0 ZXN0X2xvbmdfdHVuYWJsZQorU1JDUz0JdGVzdF9sb25nX3R1bmFibGUuYworCisuaW5jbHVkZSA8 YnNkLmttb2QubWs+CkluZGV4OiB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3VpbnQvdGVzdF91 aW50X3R1bmFibGUuc2gKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy91 aW50L3Rlc3RfdWludF90dW5hYmxlLnNoCShyZXZpc2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lv bi90dW5hYmxlcy91aW50L3Rlc3RfdWludF90dW5hYmxlLnNoCShyZXZpc2lvbiAwKQpAQCAtMCww ICsxLDI5IEBACisjIS9iaW4vc2gKKyMKKyMgRXhwZWN0ZWQgdmFsdWVzOgorIyAodW5zZXQpICAg OiAgICAgICAgICAwCisjICAgICAgLTEgICA6ICAgICAgICAgIDAgKHJlamVjdCkgCisjICAgICAg IDAgICA6ICAgICAgICAgIDAKKyMgICAgICA0MiAgIDogICAgICAgICA0MgorIyBhc2RmMTIzNCAg OiAgICAgICAgICAwIChyZWplY3QpCisjIElOVF9NQVgrMSA6ICBJTlRfTUFYKzEKKyMgVUlOVF9N QVgtMTogVUlOVF9NQVgtMQorIyBVSU5UX01BWCsxOiAgICAgICAgICAwIChyZWplY3QpCisjCisK K01PRE5BTUU9IiQoYmFzZW5hbWUgIiQwIiAuc2gpIgorCit0ZXN0X21vZHVsZSgpIHsKKwlrbGRs b2FkIC4vJE1PRE5BTUUua28KKwlrbGR1bmxvYWQgLi8kTU9ETkFNRS5rbworfQorCitJTlRfTUFY X1BMVVNfT05FPTIxNDc0ODM2NDgKK1VJTlRfTUFYX01JTlVTX09ORT00Mjk0OTY3Mjk0CitVSU5U X01BWF9QTFVTX09ORT00Mjk0OTY3Mjk2CitrZW52IC11ICRNT0ROQU1FLnR1bmFibGUgMj4vZGV2 L251bGwKK3Rlc3RfbW9kdWxlCitmb3IgaSBpbiAtMSAwIDQyIGFzZGYxMjM0ICRJTlRfTUFYX1BM VVNfT05FICRVSU5UX01BWF9NSU5VU19PTkUgJFVJTlRfTUFYX1BMVVNfT05FOyBkbworCWtlbnYg JE1PRE5BTUUudHVuYWJsZT0iJGkiCisJdGVzdF9tb2R1bGUKK2RvbmUKSW5kZXg6IHRvb2xzL3Jl Z3Jlc3Npb24vdHVuYWJsZXMvdWludC90ZXN0X3VpbnRfdHVuYWJsZS5jCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdWludC90ZXN0X3VpbnRfdHVuYWJsZS5jCShyZXZp c2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy91aW50L3Rlc3RfdWludF90dW5h YmxlLmMJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsMzEgQEAKKyNpbmNsdWRlIDxzeXMvcGFyYW0u aD4KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNsdWRlIDxzeXMvcHJvYy5oPgorI2luY2x1 ZGUgPHN5cy9tb2R1bGUuaD4KKyNpbmNsdWRlIDxzeXMva2VybmVsLmg+CisjaW5jbHVkZSA8c3lz L3N5c3RtLmg+CisKKyNkZWZpbmUgTU9EVUxFX05BTUUJInRlc3RfdWludF90dW5hYmxlIgorCitz dGF0aWMgdW5zaWduZWQgaW50IHR1bmFibGUgPSAwOworCitUVU5BQkxFX1VJTlQoInRlc3RfdWlu dF90dW5hYmxlLnR1bmFibGUiLCAmdHVuYWJsZSk7CisKK3N0YXRpYyBpbnQKK2xvYWQgKG1vZHVs ZV90IG0sIGludCB3aGF0LCB2b2lkICphcmcpCit7CisJc3dpdGNoICh3aGF0KSB7CisJY2FzZSBN T0RfTE9BRDoKKwkJcHJpbnRmKCIlczogJXVcbiIsIE1PRFVMRV9OQU1FLCB0dW5hYmxlKTsKKwkJ YnJlYWs7CisJfQorCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBtb2R1bGVkYXRhX3QgdGVzdF91 aW50X3R1bmFibGVfbW9kID0geworCU1PRFVMRV9OQU1FLAorCWxvYWQsCit9OworREVDTEFSRV9N T0RVTEUodGVzdF91aW50X3R1bmFibGUsIHRlc3RfdWludF90dW5hYmxlX21vZCwgU0lfU1VCX0tM RCwKKyAgICBTSV9PUkRFUl9BTlkpOworTU9EVUxFX1ZFUlNJT04odGVzdF91aW50X3R1bmFibGUs IDEpOwpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy91aW50L01ha2VmaWxlCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KLS0tIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdWludC9NYWtlZmlsZQkocmV2aXNp b24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdWludC9NYWtlZmlsZQkocmV2aXNp b24gMCkKQEAgLTAsMCArMSw0IEBACitLTU9EPQl0ZXN0X3VpbnRfdHVuYWJsZQorU1JDUz0JdGVz dF91aW50X3R1bmFibGUuYworCisuaW5jbHVkZSA8YnNkLmttb2QubWs+CkluZGV4OiB0b29scy9y ZWdyZXNzaW9uL3R1bmFibGVzL3VxdWFkL3Rlc3RfdXF1YWRfdHVuYWJsZS5zaAo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3VxdWFkL3Rlc3RfdXF1YWRfdHVuYWJsZS5z aAkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdXF1YWQvdGVzdF91 cXVhZF90dW5hYmxlLnNoCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDM4IEBACisjIS9iaW4vc2gK KyMKKyMgRXhwZWN0ZWQgdmFsdWVzOgorIyAodW5zZXQpICAgIDogICAgICAgICAgIDAKKyMgICAg ICAtMSAgICA6ICAgVUxPTkdfTUFYCisjICAgICAgIDAgICAgOiAgICAgICAgICAgMAorIyAgICAg IDQyICAgIDogICAgICAgICAgNDIKKyMgYXNkZjEyMzQgICA6ICAgICAgICAgICAwIChyZWplY3Qp CisjIExPTkdfTUFYKzEgOiAgTE9OR19NQVgrMQorIyBVTE9OR19NQVgtMTogVUxPTkdfTUFYLTEK KyMgVUxPTkdfTUFYKzE6ICAgVUxPTkdfTUFYCisjCisKK01PRE5BTUU9IiQoYmFzZW5hbWUgIiQw IiAuc2gpIgorCit0ZXN0X21vZHVsZSgpIHsKKwlrbGRsb2FkIC4vJE1PRE5BTUUua28KKwlrbGR1 bmxvYWQgLi8kTU9ETkFNRS5rbworfQorCitjYXNlICIkKCQoZGlybmFtZSAiJDAiKS8uLi90b29s cy9nZXR3b3Jkc2l6ZSkiIGluCiszMikKKwlMT05HX01BWF9QTFVTXzE9MjE0NzQ4MzY0OQorCVVM T05HX01BWF9NSU5VU18xPTQyOTQ5NjcyOTUKKwlVTE9OR19NQVhfUExVU18xPTQyOTQ5NjcyOTcK Kwk7OworNjQpCisJTE9OR19NQVhfUExVU18xPTkyMjMzNzIwMzY4NTQ3NzU4MDgKKwlVTE9OR19N QVhfTUlOVVNfMT0xODQ0Njc0NDA3MzcwOTU1MTYxNAorCVVMT05HX01BWF9QTFVTXzE9MTg0NDY3 NDQwNzM3MDk1NTE2MTYKKwk7OworZXNhYwora2VudiAtdSAkTU9ETkFNRS50dW5hYmxlIDI+L2Rl di9udWxsCit0ZXN0X21vZHVsZQorZm9yIGkgaW4gLTEgMCA0MiBhc2RmMTIzNCAkTE9OR19NQVhf UExVU18xICRVTE9OR19NQVhfTUlOVVNfMSAkVUxPTkdfTUFYX1BMVVNfMTsgZG8KKwlrZW52ICRN T0ROQU1FLnR1bmFibGU9IiRpIgorCXRlc3RfbW9kdWxlCitkb25lCkluZGV4OiB0b29scy9yZWdy ZXNzaW9uL3R1bmFibGVzL3VxdWFkL3Rlc3RfdXF1YWRfdHVuYWJsZS5jCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdXF1YWQvdGVzdF91cXVhZF90dW5hYmxlLmMJKHJl dmlzaW9uIDApCisrKyB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3VxdWFkL3Rlc3RfdXF1YWRf dHVuYWJsZS5jCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDMxIEBACisjaW5jbHVkZSA8c3lzL3Bh cmFtLmg+CisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5jbHVkZSA8c3lzL3Byb2MuaD4KKyNp bmNsdWRlIDxzeXMvbW9kdWxlLmg+CisjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgorI2luY2x1ZGUg PHN5cy9zeXN0bS5oPgorCisjZGVmaW5lIE1PRFVMRV9OQU1FCSJ0ZXN0X3VxdWFkX3R1bmFibGUi CisKK3N0YXRpYyB1cXVhZF90IHR1bmFibGUgPSAwOworCitUVU5BQkxFX1VRVUFEKCJ0ZXN0X3Vx dWFkX3R1bmFibGUudHVuYWJsZSIsICZ0dW5hYmxlKTsKKworc3RhdGljIGludAorbG9hZCAobW9k dWxlX3QgbSwgaW50IHdoYXQsIHZvaWQgKmFyZykKK3sKKwlzd2l0Y2ggKHdoYXQpIHsKKwljYXNl IE1PRF9MT0FEOgorCQlwcmludGYoIiVzOiAlbHVcbiIsIE1PRFVMRV9OQU1FLCB0dW5hYmxlKTsK KwkJYnJlYWs7CisJfQorCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBtb2R1bGVkYXRhX3QgdGVz dF91cXVhZF90dW5hYmxlX21vZCA9IHsKKwlNT0RVTEVfTkFNRSwKKwlsb2FkLAorfTsKK0RFQ0xB UkVfTU9EVUxFKHRlc3RfdXF1YWRfdHVuYWJsZSwgdGVzdF91cXVhZF90dW5hYmxlX21vZCwgU0lf U1VCX0tMRCwKKyAgICBTSV9PUkRFUl9BTlkpOworTU9EVUxFX1ZFUlNJT04odGVzdF91cXVhZF90 dW5hYmxlLCAxKTsKSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdXF1YWQvTWFrZWZp bGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQotLS0gdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy91cXVhZC9NYWtlZmls ZQkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdXF1YWQvTWFrZWZp bGUJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsNCBAQAorS01PRD0JdGVzdF91cXVhZF90dW5hYmxl CitTUkNTPQl0ZXN0X3VxdWFkX3R1bmFibGUuYworCisuaW5jbHVkZSA8YnNkLmttb2QubWs+Cklu ZGV4OiB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3Rvb2xzL2dldHdvcmRzaXplLmMKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy90b29scy9nZXR3b3Jkc2l6ZS5jCShy ZXZpc2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy90b29scy9nZXR3b3Jkc2l6 ZS5jCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDkgQEAKKyNpbmNsdWRlIDxzeXMvZWxmLmg+Cisj aW5jbHVkZSA8c3RkaW8uaD4KKworaW50CittYWluKHZvaWQpCit7CisJcHJpbnRmKCIlZFxuIiwg X19FTEZfV09SRF9TSVpFKTsKKwlyZXR1cm4gKDApOworfQpJbmRleDogdG9vbHMvcmVncmVzc2lv bi90dW5hYmxlcy90b29scy9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9u L3R1bmFibGVzL3Rvb2xzL01ha2VmaWxlCShyZXZpc2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lv bi90dW5hYmxlcy90b29scy9NYWtlZmlsZQkocmV2aXNpb24gMCkKQEAgLTAsMCArMSw3IEBACitQ Uk9HPQkJZ2V0d29yZHNpemUKKworU1JDUz0JCWdldHdvcmRzaXplLmMKKworTk9fTUFOPQkJMQor CisuaW5jbHVkZSA8YnNkLnByb2cubWs+CkluZGV4OiB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVz L3BvaW50ZXIvdGVzdF9wb2ludGVyX3R1bmFibGUuc2gKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdG9vbHMvcmVn cmVzc2lvbi90dW5hYmxlcy9wb2ludGVyL3Rlc3RfcG9pbnRlcl90dW5hYmxlLnNoCShyZXZpc2lv biAwKQorKysgdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9wb2ludGVyL3Rlc3RfcG9pbnRlcl90 dW5hYmxlLnNoCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDI1IEBACisjIS9iaW4vc2gKKyMKKyMg RXhwZWN0ZWQgdmFsdWVzOgorIyAodW5zZXQpICAgICA6ICAgICAgICAgICAgMAorIyAgICAgIC0x ICAgICA6ICAgIEFsbCAweGYncworIyAgICAgICAwICAgICA6ICAgICAgICAgIDB4MAorIyAgICAg IDQyICAgICA6ICAgICAgICAgMHgyQQorIyAzNzM1OTI4NTU5ICA6ICAgMHhkZWFkYmVlZgorIyBh c2RmMTIzNCAgICA6ICAgICAgICAgICAgMCAocmVqZWN0KQorIyBody5waHlzbWVtLTE6IGh3LnBo eXNtZW0tMQorIyBody5waHlzbWVtKzE6IGh3LnBoeXNtZW0rMQorIworCitNT0ROQU1FPSIkKGJh c2VuYW1lICIkMCIgLnNoKSIKKwordGVzdF9tb2R1bGUoKSB7CisJa2xkbG9hZCAuLyRNT0ROQU1F LmtvCisJa2xkdW5sb2FkIC4vJE1PRE5BTUUua28KK30KKwordGVzdF9tb2R1bGUKK2ZvciBpIGlu IC0xIDAgNDIgMzczNTkyODU1OSBhc2RmMTIzNCAkKCggJChzeXNjdGwgLW4gaHcucGh5c21lbSkg LSAxICkpICQoKCAkKHN5c2N0bCAtbiBody5waHlzbWVtKSArIDEgKSk7IGRvCisJa2VudiAkTU9E TkFNRS50dW5hYmxlPSIkaSIKKwl0ZXN0X21vZHVsZQorZG9uZQpJbmRleDogdG9vbHMvcmVncmVz c2lvbi90dW5hYmxlcy9wb2ludGVyL3Rlc3RfcG9pbnRlcl90dW5hYmxlLmMKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9wb2ludGVyL3Rlc3RfcG9pbnRlcl90dW5hYmxl LmMJKHJldmlzaW9uIDApCisrKyB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3BvaW50ZXIvdGVz dF9wb2ludGVyX3R1bmFibGUuYwkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwzMSBAQAorI2luY2x1 ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5cy9w cm9jLmg+CisjaW5jbHVkZSA8c3lzL21vZHVsZS5oPgorI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4K KyNpbmNsdWRlIDxzeXMvc3lzdG0uaD4KKworI2RlZmluZSBNT0RVTEVfTkFNRQkidGVzdF9wb2lu dGVyX3R1bmFibGUiCisKK3N0YXRpYyB1aW50cHRyX3QgdHVuYWJsZTsKKworVFVOQUJMRV9QT0lO VEVSKCJ0ZXN0X3BvaW50ZXJfdHVuYWJsZS50dW5hYmxlIiwgJnR1bmFibGUpOworCitzdGF0aWMg aW50Citsb2FkIChtb2R1bGVfdCBtLCBpbnQgd2hhdCwgdm9pZCAqYXJnKQoreworCXN3aXRjaCAo d2hhdCkgeworCWNhc2UgTU9EX0xPQUQ6CisJCXByaW50ZigiJXM6ICVqeFxuIiwgTU9EVUxFX05B TUUsIHR1bmFibGUpOworCQlicmVhazsKKwl9CisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIG1v ZHVsZWRhdGFfdCB0ZXN0X3BvaW50ZXJfdHVuYWJsZV9tb2QgPSB7CisJTU9EVUxFX05BTUUsCisJ bG9hZCwKK307CitERUNMQVJFX01PRFVMRSh0ZXN0X3BvaW50ZXJfdHVuYWJsZSwgdGVzdF9wb2lu dGVyX3R1bmFibGVfbW9kLCBTSV9TVUJfS0xELAorICAgIFNJX09SREVSX0FOWSk7CitNT0RVTEVf VkVSU0lPTih0ZXN0X3BvaW50ZXJfdHVuYWJsZSwgMSk7CkluZGV4OiB0b29scy9yZWdyZXNzaW9u L3R1bmFibGVzL3BvaW50ZXIvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdG9vbHMvcmVncmVzc2lv bi90dW5hYmxlcy9wb2ludGVyL01ha2VmaWxlCShyZXZpc2lvbiAwKQorKysgdG9vbHMvcmVncmVz c2lvbi90dW5hYmxlcy9wb2ludGVyL01ha2VmaWxlCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDQg QEAKK0tNT0Q9CXRlc3RfcG9pbnRlcl90dW5hYmxlCitTUkNTPQl0ZXN0X3BvaW50ZXJfdHVuYWJs ZS5jCisKKy5pbmNsdWRlIDxic2Qua21vZC5taz4KSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVu YWJsZXMvc3VmZml4L3Rlc3RfdHVuYWJsZV9zdWZmaXhlcy5jCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHRvb2xz L3JlZ3Jlc3Npb24vdHVuYWJsZXMvc3VmZml4L3Rlc3RfdHVuYWJsZV9zdWZmaXhlcy5jCShyZXZp c2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9zdWZmaXgvdGVzdF90dW5hYmxl X3N1ZmZpeGVzLmMJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsMzEgQEAKKyNpbmNsdWRlIDxzeXMv cGFyYW0uaD4KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNsdWRlIDxzeXMvcHJvYy5oPgor I2luY2x1ZGUgPHN5cy9tb2R1bGUuaD4KKyNpbmNsdWRlIDxzeXMva2VybmVsLmg+CisjaW5jbHVk ZSA8c3lzL3N5c3RtLmg+CisKKyNkZWZpbmUgTU9EVUxFX05BTUUJInRlc3RfdHVuYWJsZV9zdWZm aXhlcyIKKworc3RhdGljIGxvbmcgdHVuYWJsZSA9IDA7CisKK1RVTkFCTEVfTE9ORygidGVzdF90 dW5hYmxlX3N1ZmZpeGVzLnR1bmFibGUiLCAmdHVuYWJsZSk7CisKK3N0YXRpYyBpbnQKK2xvYWQg KHN0cnVjdCBtb2R1bGUgKm0sIGludCB3aGF0LCB2b2lkICphcmcpCit7CisJc3dpdGNoICh3aGF0 KSB7CisJY2FzZSBNT0RfTE9BRDoKKwkJcHJpbnRmKCIlczogJWxkXG4iLCBNT0RVTEVfTkFNRSwg dHVuYWJsZSk7CisJCWJyZWFrOworCX0KKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgbW9kdWxl ZGF0YV90IHRlc3RfdHVuYWJsZV9zdWZmaXhlc19tb2QgPSB7CisJTU9EVUxFX05BTUUsCisJbG9h ZCwKK307CitERUNMQVJFX01PRFVMRSh0ZXN0X3R1bmFibGVfc3VmZml4ZXMsIHRlc3RfdHVuYWJs ZV9zdWZmaXhlc19tb2QsIFNJX1NVQl9LTEQsCisgICAgU0lfT1JERVJfQU5ZKTsKK01PRFVMRV9W RVJTSU9OKHRlc3RfdHVuYWJsZV9zdWZmaXhlcywgMSk7CkluZGV4OiB0b29scy9yZWdyZXNzaW9u L3R1bmFibGVzL3N1ZmZpeC9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9u L3R1bmFibGVzL3N1ZmZpeC9NYWtlZmlsZQkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Np b24vdHVuYWJsZXMvc3VmZml4L01ha2VmaWxlCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDQgQEAK K0tNT0Q9CXRlc3RfdHVuYWJsZV9zdWZmaXhlcworU1JDUz0JdGVzdF90dW5hYmxlX3N1ZmZpeGVz LmMKKworLmluY2x1ZGUgPGJzZC5rbW9kLm1rPgpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5h Ymxlcy9zdWZmaXgvdGVzdF90dW5hYmxlX3N1ZmZpeGVzLnNoCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHRvb2xz L3JlZ3Jlc3Npb24vdHVuYWJsZXMvc3VmZml4L3Rlc3RfdHVuYWJsZV9zdWZmaXhlcy5zaAkocmV2 aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvc3VmZml4L3Rlc3RfdHVuYWJs ZV9zdWZmaXhlcy5zaAkocmV2aXNpb24gMCkKQEAgLTAsMCArMSw0MSBAQAorIyEvYmluL3NoCisj CisjIEV4cGVjdGVkIHZhbHVlczoKKyMgKHVuc2V0KSAgIDogICAgICAgICAgIDAKKyMgICAgICAg ICAtMTogICAgICAgICAgLTEKKyMgICAgICAgIC0xZzogICAgIC0xMDI0XjMKKyMgICAgICAgIC0x RzogICAgIC0xMDI0XjMgKHNhbWUgYXMgMWcpIAorIyAgICAgICAgLTFrOiAgICAgICAtMTAyNAor IyAgICAgICAgLTFLOiAgICAgICAtMTAyNCAoc2FtZSBhcyAxSykKKyMgICAgICAgIC0xbTogICAg IC0xMDI0XjIKKyMgICAgICAgIC0xTTogICAgIC0xMDI0XjIgKHNhbWUgYXMgMW0pCisjICAgICAg ICAtMXQ6ICAgICAtMTAyNF40CisjICAgICAgICAtMVQ6ICAgICAtMTAyNF40IChzYW1lIGFzIDF0 KQorIyAgICAgICAgLTF6OiAgICAgICAgICAgMCAocmVqZWN0KQorIyAgICAgICAgICAxOiAgICAg ICAgICAgMQorIyAgICAgICAgIDFnOiAgICAgIDEwMjReMworIyAgICAgICAgIDFHOiAgICAgIDEw MjReMyAoc2FtZSBhcyAxZykgCisjICAgICAgICAgMWs6ICAgICAgICAxMDI0CisjICAgICAgICAg MUs6ICAgICAgICAxMDI0IChzYW1lIGFzIDFLKQorIyAgICAgICAgIDFtOiAgICAgIDEwMjReMgor IyAgICAgICAgIDFNOiAgICAgIDEwMjReMiAoc2FtZSBhcyAxbSkKKyMgICAgICAgICAxdDogICAg ICAxMDI0XjQKKyMgICAgICAgICAxVDogICAgICAxMDI0XjQgKHNhbWUgYXMgMXQpCisjICAgICAg ICAgMXo6ICAgICAgICAgICAwIChyZWplY3QpCisjICAgICAgICAgMVQ6ICAgICAgICAgICAwIChy ZWplY3QpCisKK01PRE5BTUU9IiQoYmFzZW5hbWUgIiQwIiAuc2gpIgorCit0ZXN0X21vZHVsZSgp IHsKKwlrbGRsb2FkIC4vJE1PRE5BTUUua28KKwlrbGR1bmxvYWQgLi8kTU9ETkFNRS5rbworfQor CitrZW52IC11ICRNT0ROQU1FLnR1bmFibGUgMj4vZGV2L251bGwKK3Rlc3RfbW9kdWxlCitmb3Ig aSBpbiAtMSAwIDE7IGRvCisJZm9yIGogaW4gJycgZyBHIGsgSyBtIE0gdCBUIHogWjsgZG8KKwkJ a2VudiAkTU9ETkFNRS50dW5hYmxlPSIkaSRqIgorCQl0ZXN0X21vZHVsZQorCWRvbmUKK2RvbmUK SW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdWxvbmcvdGVzdF91bG9uZ190dW5hYmxl LnNoCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KLS0tIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdWxvbmcvdGVzdF91 bG9uZ190dW5hYmxlLnNoCShyZXZpc2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lvbi90dW5hYmxl cy91bG9uZy90ZXN0X3Vsb25nX3R1bmFibGUuc2gJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsMzgg QEAKKyMhL2Jpbi9zaAorIworIyBFeHBlY3RlZCB2YWx1ZXM6CisjICh1bnNldCkgICAgOiAgICAg ICAgICAgMAorIyAgICAgIC0xICAgIDogICBVTE9OR19NQVgKKyMgICAgICAgMCAgICA6ICAgICAg ICAgICAwCisjICAgICAgNDIgICAgOiAgICAgICAgICA0MgorIyBhc2RmMTIzNCAgIDogICAgICAg ICAgIDAgKHJlamVjdCkKKyMgTE9OR19NQVgrMSA6ICBMT05HX01BWCsxCisjIFVMT05HX01BWC0x OiBVTE9OR19NQVgtMQorIyBVTE9OR19NQVgrMTogICBVTE9OR19NQVgKKyMKKworTU9ETkFNRT0i JChiYXNlbmFtZSAiJDAiIC5zaCkiCisKK3Rlc3RfbW9kdWxlKCkgeworCWtsZGxvYWQgLi8kTU9E TkFNRS5rbworCWtsZHVubG9hZCAuLyRNT0ROQU1FLmtvCit9CisKK2Nhc2UgIiQoJChkaXJuYW1l ICIkMCIpLy4uL3Rvb2xzL2dldHdvcmRzaXplKSIgaW4KKzMyKQorCUxPTkdfTUFYX1BMVVNfMT0y MTQ3NDgzNjQ5CisJVUxPTkdfTUFYX01JTlVTXzE9NDI5NDk2NzI5NQorCVVMT05HX01BWF9QTFVT XzE9NDI5NDk2NzI5NworCTs7Cis2NCkKKwlMT05HX01BWF9QTFVTXzE9OTIyMzM3MjAzNjg1NDc3 NTgwOAorCVVMT05HX01BWF9NSU5VU18xPTE4NDQ2NzQ0MDczNzA5NTUxNjE0CisJVUxPTkdfTUFY X1BMVVNfMT0xODQ0Njc0NDA3MzcwOTU1MTYxNgorCTs7Citlc2FjCitrZW52IC11ICRNT0ROQU1F LnR1bmFibGUgMj4vZGV2L251bGwKK3Rlc3RfbW9kdWxlCitmb3IgaSBpbiAtMSAwIDQyIGFzZGYx MjM0ICRMT05HX01BWF9QTFVTXzEgJFVMT05HX01BWF9NSU5VU18xICRVTE9OR19NQVhfUExVU18x OyBkbworCWtlbnYgJE1PRE5BTUUudHVuYWJsZT0iJGkiCisJdGVzdF9tb2R1bGUKK2RvbmUKSW5k ZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdWxvbmcvTWFrZWZpbGUKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy91bG9uZy9NYWtlZmlsZQkocmV2aXNpb24gMCkK KysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdWxvbmcvTWFrZWZpbGUJKHJldmlzaW9uIDAp CkBAIC0wLDAgKzEsNCBAQAorS01PRD0JdGVzdF91bG9uZ190dW5hYmxlCitTUkNTPQl0ZXN0X3Vs b25nX3R1bmFibGUuYworCisuaW5jbHVkZSA8YnNkLmttb2QubWs+CkluZGV4OiB0b29scy9yZWdy ZXNzaW9uL3R1bmFibGVzL3Vsb25nL3Rlc3RfdWxvbmdfdHVuYWJsZS5jCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdWxvbmcvdGVzdF91bG9uZ190dW5hYmxlLmMJKHJl dmlzaW9uIDApCisrKyB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3Vsb25nL3Rlc3RfdWxvbmdf dHVuYWJsZS5jCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDMxIEBACisjaW5jbHVkZSA8c3lzL3Bh cmFtLmg+CisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5jbHVkZSA8c3lzL3Byb2MuaD4KKyNp bmNsdWRlIDxzeXMvbW9kdWxlLmg+CisjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgorI2luY2x1ZGUg PHN5cy9zeXN0bS5oPgorCisjZGVmaW5lIE1PRFVMRV9OQU1FCSJ0ZXN0X3Vsb25nX3R1bmFibGUi CisKK3N0YXRpYyB1bnNpZ25lZCBsb25nIHR1bmFibGUgPSAwOworCitUVU5BQkxFX1VMT05HKCJ0 ZXN0X3Vsb25nX3R1bmFibGUudHVuYWJsZSIsICZ0dW5hYmxlKTsKKworc3RhdGljIGludAorbG9h ZCAobW9kdWxlX3QgbSwgaW50IHdoYXQsIHZvaWQgKmFyZykKK3sKKwlzd2l0Y2ggKHdoYXQpIHsK KwljYXNlIE1PRF9MT0FEOgorCQlwcmludGYoIiVzOiAlbHVcbiIsIE1PRFVMRV9OQU1FLCB0dW5h YmxlKTsKKwkJYnJlYWs7CisJfQorCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBtb2R1bGVkYXRh X3QgdGVzdF91bG9uZ190dW5hYmxlX21vZCA9IHsKKwlNT0RVTEVfTkFNRSwKKwlsb2FkLAorfTsK K0RFQ0xBUkVfTU9EVUxFKHRlc3RfdWxvbmdfdHVuYWJsZSwgdGVzdF91bG9uZ190dW5hYmxlX21v ZCwgU0lfU1VCX0tMRCwKKyAgICBTSV9PUkRFUl9BTlkpOworTU9EVUxFX1ZFUlNJT04odGVzdF91 bG9uZ190dW5hYmxlLCAxKTsKSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvc3RyaW5n L3Rlc3Rfc3RyaW5nX3R1bmFibGUuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1 bmFibGVzL3N0cmluZy90ZXN0X3N0cmluZ190dW5hYmxlLmMJKHJldmlzaW9uIDApCisrKyB0b29s cy9yZWdyZXNzaW9uL3R1bmFibGVzL3N0cmluZy90ZXN0X3N0cmluZ190dW5hYmxlLmMJKHJldmlz aW9uIDApCkBAIC0wLDAgKzEsMzEgQEAKKyNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKyNpbmNsdWRl IDxzeXMvdHlwZXMuaD4KKyNpbmNsdWRlIDxzeXMvcHJvYy5oPgorI2luY2x1ZGUgPHN5cy9tb2R1 bGUuaD4KKyNpbmNsdWRlIDxzeXMva2VybmVsLmg+CisjaW5jbHVkZSA8c3lzL3N5c3RtLmg+CisK KyNkZWZpbmUgTU9EVUxFX05BTUUJInRlc3Rfc3RyaW5nX3R1bmFibGUiCisKK3N0YXRpYyBjaGFy IHR1bmFibGVbMTBdOworCitUVU5BQkxFX1NUUigidGVzdF9zdHJpbmdfdHVuYWJsZS50dW5hYmxl IiwgdHVuYWJsZSwgc2l6ZW9mKHR1bmFibGUpKTsKKworc3RhdGljIGludAorbG9hZCAobW9kdWxl X3QgbSwgaW50IHdoYXQsIHZvaWQgKmFyZykKK3sKKwlzd2l0Y2ggKHdoYXQpIHsKKwljYXNlIE1P RF9MT0FEOgorCQlwcmludGYoIiVzOiAlc1xuIiwgTU9EVUxFX05BTUUsIHR1bmFibGUpOworCQli cmVhazsKKwl9CisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIG1vZHVsZWRhdGFfdCB0ZXN0X3N0 cmluZ190dW5hYmxlX21vZCA9IHsKKwlNT0RVTEVfTkFNRSwKKwlsb2FkLAorfTsKK0RFQ0xBUkVf TU9EVUxFKHRlc3Rfc3RyaW5nX3R1bmFibGUsIHRlc3Rfc3RyaW5nX3R1bmFibGVfbW9kLCBTSV9T VUJfS0xELAorICAgIFNJX09SREVSX0FOWSk7CitNT0RVTEVfVkVSU0lPTih0ZXN0X3N0cmluZ190 dW5hYmxlLCAxKTsKSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvc3RyaW5nL3Rlc3Rf c3RyaW5nX3R1bmFibGUuc2gKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdG9vbHMvcmVncmVzc2lvbi90dW5hYmxl cy9zdHJpbmcvdGVzdF9zdHJpbmdfdHVuYWJsZS5zaAkocmV2aXNpb24gMCkKKysrIHRvb2xzL3Jl Z3Jlc3Npb24vdHVuYWJsZXMvc3RyaW5nL3Rlc3Rfc3RyaW5nX3R1bmFibGUuc2gJKHJldmlzaW9u IDApCkBAIC0wLDAgKzEsMjIgQEAKKyMhL2Jpbi9zaAorIworIyBFeHBlY3RlZCB2YWx1ZXM6Cisj ICh1bnNldCkgICAgICAgICAgICAgIDogICAgICAgICAgIiIKKyMgIiIgICAgICAgICAgICAgICAg ICAgOiAgICAgICAgICAiIgorIyBhc2RmMTIzNCAgICAgICAgICAgICA6ICAgIGFzZGYxMjM0Cisj IGNoYXJhY3RlciAgICAgICAgICAgIDogICBjaGFyYWN0ZXIKKyMgYXNvcnRvZmxvbmdpc2hzdHJp bmcgOiAgIGFzb3J0b2ZsbworIworCitNT0ROQU1FPSIkKGJhc2VuYW1lICIkMCIgLnNoKSIKKwor dGVzdF9tb2R1bGUoKSB7CisJa2xkbG9hZCAuLyRNT0ROQU1FLmtvCisJa2xkdW5sb2FkIC4vJE1P RE5BTUUua28KK30KKwordGVzdF9tb2R1bGUKK2ZvciBpIGluICIiIGFzZGYxMjM0IGNoYXJhY3Rl ciBhc29ydG9mbG9uZ2lzaHN0cmluZzsgZG8KKwlrZW52ICRNT0ROQU1FLnR1bmFibGU9IiRpIgor CXRlc3RfbW9kdWxlCitkb25lCkluZGV4OiB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3N0cmlu Zy9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3N0cmlu Zy9NYWtlZmlsZQkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvc3Ry aW5nL01ha2VmaWxlCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDQgQEAKK0tNT0Q9CXRlc3Rfc3Ry aW5nX3R1bmFibGUKK1NSQ1M9CXRlc3Rfc3RyaW5nX3R1bmFibGUuYworCisuaW5jbHVkZSA8YnNk Lmttb2QubWs+CkluZGV4OiB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3F1YWQvdGVzdF9xdWFk X3R1bmFibGUuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3F1YWQv dGVzdF9xdWFkX3R1bmFibGUuYwkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVu YWJsZXMvcXVhZC90ZXN0X3F1YWRfdHVuYWJsZS5jCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDMx IEBACisjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5j bHVkZSA8c3lzL3Byb2MuaD4KKyNpbmNsdWRlIDxzeXMvbW9kdWxlLmg+CisjaW5jbHVkZSA8c3lz L2tlcm5lbC5oPgorI2luY2x1ZGUgPHN5cy9zeXN0bS5oPgorCisjZGVmaW5lIE1PRFVMRV9OQU1F CSJ0ZXN0X3F1YWRfdHVuYWJsZSIKKworc3RhdGljIHF1YWRfdCB0dW5hYmxlID0gMDsKKworVFVO QUJMRV9RVUFEKCJ0ZXN0X3F1YWRfdHVuYWJsZS50dW5hYmxlIiwgJnR1bmFibGUpOworCitzdGF0 aWMgaW50Citsb2FkIChtb2R1bGVfdCBtLCBpbnQgd2hhdCwgdm9pZCAqYXJnKQoreworCXN3aXRj aCAod2hhdCkgeworCWNhc2UgTU9EX0xPQUQ6CisJCXByaW50ZigiJXM6ICVsZFxuIiwgTU9EVUxF X05BTUUsIHR1bmFibGUpOworCQlicmVhazsKKwl9CisJcmV0dXJuICgwKTsKK30KKworc3RhdGlj IG1vZHVsZWRhdGFfdCB0ZXN0X3F1YWRfdHVuYWJsZV9tb2QgPSB7CisJTU9EVUxFX05BTUUsCisJ bG9hZCwKK307CitERUNMQVJFX01PRFVMRSh0ZXN0X3F1YWRfdHVuYWJsZSwgdGVzdF9xdWFkX3R1 bmFibGVfbW9kLCBTSV9TVUJfS0xELAorICAgIFNJX09SREVSX0FOWSk7CitNT0RVTEVfVkVSU0lP Tih0ZXN0X3F1YWRfdHVuYWJsZSwgMSk7CkluZGV4OiB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVz L3F1YWQvdGVzdF9xdWFkX3R1bmFibGUuc2gKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdG9vbHMvcmVncmVzc2lv bi90dW5hYmxlcy9xdWFkL3Rlc3RfcXVhZF90dW5hYmxlLnNoCShyZXZpc2lvbiAwKQorKysgdG9v bHMvcmVncmVzc2lvbi90dW5hYmxlcy9xdWFkL3Rlc3RfcXVhZF90dW5hYmxlLnNoCShyZXZpc2lv biAwKQpAQCAtMCwwICsxLDQwIEBACisjIS9iaW4vc2gKKyMKKyMgRXhwZWN0ZWQgdmFsdWVzOgor IyAodW5zZXQpICAgIDogICAgICAgICAgIDAKKyMgICAgICAgMCAgICA6ICAgICAgICAgICAwCisj ICAgICAgNDIgICAgOiAgICAgICAgICA0MgorIyBhc2RmMTIzNCAgIDogICAgICAgICAgIDAgKHJl amVjdCkKKyMgTE9OR19NSU4tMSA6ICBMT05HX01JTgorIyBMT05HX01JTisxIDogIExPTkdfTUlO KzEKKyMgTE9OR19NQVgtMSA6ICBMT05HX01BWC0xCisjIExPTkdfTUFYKzEgOiAgTE9OR19NQVgK KyMKKworTU9ETkFNRT0iJChiYXNlbmFtZSAiJDAiIC5zaCkiCisKK3Rlc3RfbW9kdWxlKCkgewor CWtsZGxvYWQgLi8kTU9ETkFNRS5rbworCWtsZHVubG9hZCAuLyRNT0ROQU1FLmtvCit9CisKK2Nh c2UgIiQoJChkaXJuYW1lICIkMCIpLy4uL3Rvb2xzL2dldHdvcmRzaXplKSIgaW4KKzMyKQorCUxP TkdfTUlOX01JTlVTXzE9Ii0yMTQ3NDgzNjQ5IgorCUxPTkdfTUlOX1BMVVNfMT0iLTIxNDc0ODM2 NDciCisJTE9OR19NQVhfTUlOVVNfMT0yMTQ3NDgzNjQ3CisJTE9OR19NQVhfUExVU18xPTIxNDc0 ODM2NDkKKwk7OworNjQpCisJTE9OR19NSU5fTUlOVVNfMT0iLTkyMjMzNzIwMzY4NTQ3NzU4MDki CisJTE9OR19NSU5fUExVU18xPSItOTIyMzM3MjAzNjg1NDc3NTgwNyIKKwlMT05HX01BWF9NSU5V U18xPTkyMjMzNzIwMzY4NTQ3NzU4MDYKKwlMT05HX01BWF9QTFVTXzE9OTIyMzM3MjAzNjg1NDc3 NTgwOAorCTs7Citlc2FjCitrZW52IC11ICRNT0ROQU1FLnR1bmFibGUgMj4vZGV2L251bGwKK3Rl c3RfbW9kdWxlCitmb3IgaSBpbiAwIDQyIGFzZGYxMjM0ICRMT05HX01JTl9NSU5VU18xICRMT05H X01JTl9QTFVTXzEgJExPTkdfTUFYX01JTlVTXzEgJExPTkdfTUFYX1BMVVNfMSA7IGRvCisJa2Vu diAkTU9ETkFNRS50dW5hYmxlPSIkaSIKKwl0ZXN0X21vZHVsZQorZG9uZQpJbmRleDogdG9vbHMv cmVncmVzc2lvbi90dW5hYmxlcy9xdWFkL01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHRvb2xzL3Jl Z3Jlc3Npb24vdHVuYWJsZXMvcXVhZC9NYWtlZmlsZQkocmV2aXNpb24gMCkKKysrIHRvb2xzL3Jl Z3Jlc3Npb24vdHVuYWJsZXMvcXVhZC9NYWtlZmlsZQkocmV2aXNpb24gMCkKQEAgLTAsMCArMSw0 IEBACitLTU9EPQl0ZXN0X3F1YWRfdHVuYWJsZQorU1JDUz0JdGVzdF9xdWFkX3R1bmFibGUuYwor CisuaW5jbHVkZSA8YnNkLmttb2QubWs+CkluZGV4OiB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVz L3NpemUvdGVzdF9zaXplX3R1bmFibGUuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9u L3R1bmFibGVzL3NpemUvdGVzdF9zaXplX3R1bmFibGUuYwkocmV2aXNpb24gMCkKKysrIHRvb2xz L3JlZ3Jlc3Npb24vdHVuYWJsZXMvc2l6ZS90ZXN0X3NpemVfdHVuYWJsZS5jCShyZXZpc2lvbiAw KQpAQCAtMCwwICsxLDMxIEBACisjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjaW5jbHVkZSA8c3lz L3R5cGVzLmg+CisjaW5jbHVkZSA8c3lzL3Byb2MuaD4KKyNpbmNsdWRlIDxzeXMvbW9kdWxlLmg+ CisjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgorI2luY2x1ZGUgPHN5cy9zeXN0bS5oPgorCisjZGVm aW5lIE1PRFVMRV9OQU1FCSJ0ZXN0X3NpemVfdHVuYWJsZSIKKworc3RhdGljIHNpemVfdCB0dW5h YmxlID0gMDsKKworVFVOQUJMRV9TSVpFKCJ0ZXN0X3NpemVfdHVuYWJsZS50dW5hYmxlIiwgJnR1 bmFibGUpOworCitzdGF0aWMgaW50Citsb2FkIChtb2R1bGVfdCBtLCBpbnQgd2hhdCwgdm9pZCAq YXJnKQoreworCXN3aXRjaCAod2hhdCkgeworCWNhc2UgTU9EX0xPQUQ6CisJCXByaW50ZigiJXM6 ICV6dVxuIiwgTU9EVUxFX05BTUUsIHR1bmFibGUpOworCQlicmVhazsKKwl9CisJcmV0dXJuICgw KTsKK30KKworc3RhdGljIG1vZHVsZWRhdGFfdCB0ZXN0X3NpemVfdHVuYWJsZV9tb2QgPSB7CisJ TU9EVUxFX05BTUUsCisJbG9hZCwKK307CitERUNMQVJFX01PRFVMRSh0ZXN0X3NpemVfdHVuYWJs ZSwgdGVzdF9zaXplX3R1bmFibGVfbW9kLCBTSV9TVUJfS0xELAorICAgIFNJX09SREVSX0FOWSk7 CitNT0RVTEVfVkVSU0lPTih0ZXN0X3NpemVfdHVuYWJsZSwgMSk7CkluZGV4OiB0b29scy9yZWdy ZXNzaW9uL3R1bmFibGVzL3NpemUvdGVzdF9zaXplX3R1bmFibGUuc2gKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g dG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9zaXplL3Rlc3Rfc2l6ZV90dW5hYmxlLnNoCShyZXZp c2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9zaXplL3Rlc3Rfc2l6ZV90dW5h YmxlLnNoCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDM4IEBACisjIS9iaW4vc2gKKyMKKyMgRXhw ZWN0ZWQgdmFsdWVzOgorIyAodW5zZXQpICAgIDogICAgICAgICAgIDAKKyMgICAgICAtMSAgICA6 ICAgVUxPTkdfTUFYCisjICAgICAgIDAgICAgOiAgICAgICAgICAgMAorIyAgICAgIDQyICAgIDog ICAgICAgICAgNDIKKyMgYXNkZjEyMzQgICA6ICAgICAgICAgICAwIChyZWplY3QpCisjIExPTkdf TUFYKzEgOiAgTE9OR19NQVgrMQorIyBVTE9OR19NQVgtMTogVUxPTkdfTUFYLTEKKyMgVUxPTkdf TUFYKzE6ICAgVUxPTkdfTUFYCisjCisKK01PRE5BTUU9IiQoYmFzZW5hbWUgIiQwIiAuc2gpIgor Cit0ZXN0X21vZHVsZSgpIHsKKwlrbGRsb2FkIC4vJE1PRE5BTUUua28KKwlrbGR1bmxvYWQgLi8k TU9ETkFNRS5rbworfQorCitjYXNlICIkKCQoZGlybmFtZSAiJDAiKS8uLi90b29scy9nZXR3b3Jk c2l6ZSkiIGluCiszMikKKwlMT05HX01BWF9QTFVTXzE9MjE0NzQ4MzY0OQorCVVMT05HX01BWF9N SU5VU18xPTQyOTQ5NjcyOTUKKwlVTE9OR19NQVhfUExVU18xPTQyOTQ5NjcyOTcKKwk7OworNjQp CisJTE9OR19NQVhfUExVU18xPTkyMjMzNzIwMzY4NTQ3NzU4MDgKKwlVTE9OR19NQVhfTUlOVVNf MT0xODQ0Njc0NDA3MzcwOTU1MTYxNAorCVVMT05HX01BWF9QTFVTXzE9MTg0NDY3NDQwNzM3MDk1 NTE2MTYKKwk7OworZXNhYwora2VudiAtdSAkTU9ETkFNRS50dW5hYmxlIDI+L2Rldi9udWxsCit0 ZXN0X21vZHVsZQorZm9yIGkgaW4gLTEgMCA0MiBhc2RmMTIzNCAkTE9OR19NQVhfUExVU18xICRV TE9OR19NQVhfTUlOVVNfMSAkVUxPTkdfTUFYX1BMVVNfMTsgZG8KKwlrZW52ICRNT0ROQU1FLnR1 bmFibGU9IiRpIgorCXRlc3RfbW9kdWxlCitkb25lCkluZGV4OiB0b29scy9yZWdyZXNzaW9uL3R1 bmFibGVzL3NpemUvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdG9vbHMvcmVncmVzc2lvbi90dW5h Ymxlcy9zaXplL01ha2VmaWxlCShyZXZpc2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lvbi90dW5h Ymxlcy9zaXplL01ha2VmaWxlCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDQgQEAKK0tNT0Q9CXRl c3Rfc2l6ZV90dW5hYmxlCitTUkNTPQl0ZXN0X3NpemVfdHVuYWJsZS5jCisKKy5pbmNsdWRlIDxi c2Qua21vZC5taz4KSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvaW50L3Rlc3RfaW50 X3R1bmFibGUuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL2ludC90 ZXN0X2ludF90dW5hYmxlLmMJKHJldmlzaW9uIDApCisrKyB0b29scy9yZWdyZXNzaW9uL3R1bmFi bGVzL2ludC90ZXN0X2ludF90dW5hYmxlLmMJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsMzEgQEAK KyNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNsdWRl IDxzeXMvcHJvYy5oPgorI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KKyNpbmNsdWRlIDxzeXMvc3lz dG0uaD4KKyNpbmNsdWRlIDxzeXMvbW9kdWxlLmg+CisKKyNkZWZpbmUgTU9EVUxFX05BTUUJInRl c3RfaW50X3R1bmFibGUiCisKK3N0YXRpYyBpbnQgdHVuYWJsZSA9IDA7CisKK1RVTkFCTEVfSU5U KCJ0ZXN0X2ludF90dW5hYmxlLnR1bmFibGUiLCAmdHVuYWJsZSk7CisKK3N0YXRpYyBpbnQKK2xv YWQgKG1vZHVsZV90IG0sIGludCB3aGF0LCB2b2lkICphcmcpCit7CisJc3dpdGNoICh3aGF0KSB7 CisJY2FzZSBNT0RfTE9BRDoKKwkJcHJpbnRmKCIlczogJWRcbiIsIE1PRFVMRV9OQU1FLCB0dW5h YmxlKTsKKwkJYnJlYWs7CisJfQorCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBtb2R1bGVkYXRh X3QgdGVzdF9pbnRfdHVuYWJsZV9tb2QgPSB7CisJTU9EVUxFX05BTUUsCisJbG9hZCwKK307CitE RUNMQVJFX01PRFVMRSh0ZXN0X2ludF90dW5hYmxlLCB0ZXN0X2ludF90dW5hYmxlX21vZCwgU0lf U1VCX0tMRCwKKyAgICBTSV9PUkRFUl9BTlkpOworTU9EVUxFX1ZFUlNJT04odGVzdF9pbnRfdHVu YWJsZSwgMSk7CkluZGV4OiB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL2ludC90ZXN0X2ludF90 dW5hYmxlLnNoCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvaW50L3Rl c3RfaW50X3R1bmFibGUuc2gJKHJldmlzaW9uIDApCisrKyB0b29scy9yZWdyZXNzaW9uL3R1bmFi bGVzL2ludC90ZXN0X2ludF90dW5hYmxlLnNoCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDMxIEBA CisjIS9iaW4vc2gKKyMKKyMgRXhwZWN0ZWQgdmFsdWVzOgorIyAodW5zZXQpICAgOiAgICAgICAg ICAgMAorIyAgICAgIC0xICAgOiAgICAgICAgICAtMQorIyAgICAgICAwICAgOiAgICAgICAgICAg MAorIyAgICAgIDQyICAgOiAgICAgICAgICA0MgorIyBhc2RmMTIzNCAgOiAgICAgICAgICAgMCAo cmVqZWN0KQorIyBJTlRfTUlOKzEgOiAgIElOVF9NSU4rMQorIyBJTlRfTUlOLTEgOiAgICAgICAg ICAgMCAocmVqZWN0KQorIyBJTlRfTUFYLTEgOiAgIElOVF9NQVgtMQorIyBJTlRfTUFYKzEgOiAg ICAgICAgICAgMCAocmVqZWN0KQorIworCitNT0ROQU1FPSIkKGJhc2VuYW1lICIkMCIgLnNoKSIK KwordGVzdF9tb2R1bGUoKSB7CisJa2xkbG9hZCAuLyRNT0ROQU1FLmtvCisJa2xkdW5sb2FkIC4v JE1PRE5BTUUua28KK30KKworSU5UX01JTl9QTFVTX09ORT0tMjE0NzQ4MzY0NworSU5UX01JTl9N SU5VU19PTkU9LTIxNDc0ODM2NDkKK0lOVF9NQVhfTUlOVVNfT05FPTIxNDc0ODM2NDYKK0lOVF9N QVhfUExVU19PTkU9MjE0NzQ4MzY0OAora2VudiAtdSAkTU9ETkFNRS50dW5hYmxlIDI+L2Rldi9u dWxsCit0ZXN0X21vZHVsZQorZm9yIGkgaW4gLTEgMCA0MiBhc2RmMTIzNCAkSU5UX01JTl9QTFVT X09ORSAkSU5UX01JTl9NSU5VU19PTkUgJElOVF9NQVhfTUlOVVNfT05FICRJTlRfTUFYX1BMVVNf T05FOyBkbworCWtlbnYgJE1PRE5BTUUudHVuYWJsZT0iJGkiCisJdGVzdF9tb2R1bGUKK2RvbmUK SW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvaW50L01ha2VmaWxlCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvaW50L01ha2VmaWxlCShyZXZpc2lvbiAwKQor KysgdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9pbnQvTWFrZWZpbGUJKHJldmlzaW9uIDApCkBA IC0wLDAgKzEsNCBAQAorS01PRD0JdGVzdF9pbnRfdHVuYWJsZQorU1JDUz0JdGVzdF9pbnRfdHVu YWJsZS5jCisKKy5pbmNsdWRlIDxic2Qua21vZC5taz4KSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24v dHVuYWJsZXMvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdG9vbHMvcmVncmVzc2lvbi90dW5hYmxl cy9NYWtlZmlsZQkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvTWFr ZWZpbGUJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsMTAgQEAKK1NVQkRJUj0JCXRvb2xzCQlcCisJ CWludCB1aW50CVwKKwkJbG9uZyB1bG9uZwlcCisJCXBvaW50ZXIJCVwKKwkJcXVhZCB1cXVhZAlc CisJCXNpemUJCVwKKwkJc3RyaW5nCQlcCisJCXN1ZmZpeAkJXAorCisuaW5jbHVkZSA8YnNkLnN1 YmRpci5taz4K --001485ea873c7936730492c421bb--