From owner-freebsd-arch@FreeBSD.ORG Sun Nov 11 00:54:58 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7EEC059F for ; Sun, 11 Nov 2012 00:54:58 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 2CBF58FC0C for ; Sun, 11 Nov 2012 00:54:58 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id qAB0svZC012636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sat, 10 Nov 2012 18:54:57 -0600 Resent-Message-Id: <201211110054.qAB0svZC012636@ltcfislmsgpa02.fnfis.com> Received: from [10.0.0.101] (10.14.152.61) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sat, 10 Nov 2012 18:54:56 -0600 Subject: HEADS UP: Forth Optimizations MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/mixed; boundary="Apple-Mail=_7B0FAB50-55AF-495E-9AC7-6EDA850F9A15" From: Devin Teske Resent-Cc: Devin Teske , Adrian Chadd Resent-From: Devin Teske Date: Sat, 10 Nov 2012 16:53:10 -0800 Resent-Date: Sat, 10 Nov 2012 16:54:55 -0800 Resent-To: Message-ID: To: X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-10_08:2012-11-10,2012-11-10,1970-01-01 signatures=0 Cc: Adrian Chadd , Devin Teske X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 00:54:58 -0000 --Apple-Mail=_7B0FAB50-55AF-495E-9AC7-6EDA850F9A15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Hi Everybody, Adrian (my co-mentor) wanted some additional eyes/names for review on a pat= ch I'm making to sys/boot/forth (patch attached as patch.txt). The patch makes no changes to user experience or functionality (but _does_ = fix one incident of stack leakage -- among other things). I wrote/tested this over a 2-day period using (as usual) VMware (under i386= ). I booted up several times (10+) and fiddled with many things (twiddled e= very knob, dropped to the loader prompt and went back to the menu several t= imes, tried throwing various options like boot_single=3D"YES" and boot_verb= ose=3D"YES" into loader.conf(5) to make sure dynamic initialization is stil= l working etc.). The only thing I noticed after applying the patch was a drop in heap usage = (one of the goals of the patch), showing that the optimizations did their j= ob to make a leaner running menu. Also, the code is a lot more readable and= got slightly reduced in size during the process. Can someone help review this for the commit log? --=20 Devin =3D=3D=3D + This patch does not change user experience or functionality + Cleanup syntax, slim-down code, and make things more readable + Introduce new +c! operator and ilk to reduce heap usage/allocations + Fix a stack leak in [unused] cycle_menuitem function while we're here (required misconfiguration and/or missing environment vars to occur) + Add safemode_enabled? safemode_enable and safemode_disable functions + Add singleuser_enabled? singleuser_enable singleuser_disable functions + Add verbose_enabled? verbose_enable and verbose_disable functions + Centralize strings (also to reduce heap usage) PR: Submitted by: Reviewed by: Your_Name_Here, adrian (co-mentor) [pending his/your review] Approved by: adrian (co-mentor) [pending his approval] Obtained from: MFC after: Security: --This line, and those below, will be ignored-- > Description of fields to fill in above: 76 columns --| > PR: If a GNATS PR is affected by the change. > Submitted by: If someone else sent in the change. > Reviewed by: If someone else reviewed your modification. > Approved by: If you needed approval for this commit. > Obtained from: If the change is from a third party. > MFC after: N [day[s]|week[s]|month[s]]. Request a reminder email. > Security: Vulnerability reference (one per line) or description. > Empty fields above will be automatically removed. M forth/menu-commands.4th M forth/menu.4th _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. --Apple-Mail=_7B0FAB50-55AF-495E-9AC7-6EDA850F9A15 Content-Disposition: attachment; filename="patch.txt" Content-Type: text/plain; name="patch.txt" Content-Transfer-Encoding: quoted-printable Index: menu-commands.4th =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- menu-commands.4th (revision 242835) +++ menu-commands.4th (working copy) @@ -31,6 +31,10 @@ include /boot/menusets.4th variable kernel_state variable root_state =20 +\=20 +\ ACPI +\=20 + : acpi_enable ( -- ) s" set acpi_load=3DYES" evaluate \ XXX deprecated but harmless s" set hint.acpi.0.disabled=3D0" evaluate @@ -58,9 +62,38 @@ variable root_state TRUE \ loop menu again ; =20 +\=20 +\ Safe Mode +\=20 + +: safemode_enabled? ( -- flag ) + s" kern.smp.disabled" getenv -1 <> dup if + swap drop ( c-addr flag -- flag ) + then +; + +: safemode_enable ( -- ) + s" set kern.smp.disabled=3D1" evaluate + s" set hw.ata.ata_dma=3D0" evaluate + s" set hw.ata.atapi_dma=3D0" evaluate + s" set hw.ata.wc=3D0" evaluate + s" set hw.eisa_slots=3D0" evaluate + s" set kern.eventtimer.periodic=3D1" evaluate + s" set kern.geom.part.check_integrity=3D0" evaluate +; + +: safemode_disable ( -- ) + s" kern.smp.disabled" unsetenv + s" hw.ata.ata_dma" unsetenv + s" hw.ata.atapi_dma" unsetenv + s" hw.ata.wc" unsetenv + s" hw.eisa_slots" unsetenv + s" kern.eventtimer.periodic" unsetenv + s" kern.geom.part.check_integrity" unsetenv +; + : init_safemode ( N -- N ) - s" kern.smp.disabled" getenv -1 <> if - drop ( n c-addr -- n ) \ unused + safemode_enabled? if toggle_menuitem ( n -- n ) then ; @@ -70,25 +103,10 @@ variable root_state =20 \ Now we're going to make the change effective =20 - s" toggle_stateN @" \ base name of toggle state var - -rot 2dup 12 + c! rot \ replace 'N' with ASCII numeral - - evaluate 0=3D if - s" kern.smp.disabled" unsetenv - s" hw.ata.ata_dma" unsetenv - s" hw.ata.atapi_dma" unsetenv - s" hw.ata.wc" unsetenv - s" hw.eisa_slots" unsetenv - s" kern.eventtimer.periodic" unsetenv - s" kern.geom.part.check_integrity" unsetenv + dup toggle_stateN @ 0=3D if + safemode_disable else - s" set kern.smp.disabled=3D1" evaluate - s" set hw.ata.ata_dma=3D0" evaluate - s" set hw.ata.atapi_dma=3D0" evaluate - s" set hw.ata.wc=3D0" evaluate - s" set hw.eisa_slots=3D0" evaluate - s" set kern.eventtimer.periodic=3D1" evaluate - s" set kern.geom.part.check_integrity=3D0" evaluate + safemode_enable then =20 menu-redraw @@ -96,9 +114,26 @@ variable root_state TRUE \ loop menu again ; =20 +\=20 +\ Single User Mode +\=20 + +: singleuser_enabled? ( -- flag ) + s" boot_single" getenv -1 <> dup if + swap drop ( c-addr flag -- flag ) + then +; + +: singleuser_enable ( -- ) + s" set boot_single=3DYES" evaluate +; + +: singleuser_disable ( -- ) + s" boot_single" unsetenv +; + : init_singleuser ( N -- N ) - s" boot_single" getenv -1 <> if - drop ( n c-addr -- n ) \ unused + singleuser_enabled? if toggle_menuitem ( n -- n ) then ; @@ -109,21 +144,35 @@ variable root_state =20 \ Now we're going to make the change effective =20 - s" toggle_stateN @" \ base name of toggle state var - -rot 2dup 12 + c! rot \ replace 'N' with ASCII numeral - - evaluate 0=3D if - s" boot_single" unsetenv + dup toggle_stateN @ 0=3D if + singleuser_disable else - s" set boot_single=3DYES" evaluate + singleuser_enable then =20 TRUE \ loop menu again ; =20 +\=20 +\ Verbose Boot +\=20 + +: verbose_enabled? ( -- flag ) + s" boot_verbose" getenv -1 <> dup if + swap drop ( c-addr flag -- flag ) + then +; + +: verbose_enable ( -- ) + s" set boot_verbose=3DYES" evaluate +; + +: verbose_disable ( -- ) + s" boot_verbose" unsetenv +; + : init_verbose ( N -- N ) - s" boot_verbose" getenv -1 <> if - drop ( n c-addr -- n ) \ unused + verbose_enabled? if toggle_menuitem ( n -- n ) then ; @@ -134,18 +183,19 @@ variable root_state =20 \ Now we're going to make the change effective =20 - s" toggle_stateN @" \ base name of toggle state var - -rot 2dup 12 + c! rot \ replace 'N' with ASCII numeral - - evaluate 0=3D if - s" boot_verbose" unsetenv + dup toggle_stateN @ 0=3D if + verbose_disable else - s" set boot_verbose=3DYES" evaluate + verbose_enable then =20 TRUE \ loop menu again ; =20 +\=20 +\ Escape to Prompt +\=20 + : goto_prompt ( N -- N FALSE ) =20 s" set autoboot_delay=3DNO" evaluate @@ -158,11 +208,12 @@ variable root_state FALSE \ exit the menu ; =20 +\=20 +\ Cyclestate (used by kernel/root below) +\=20 + : init_cyclestate ( N K -- N ) - over ( n k -- n k n ) - s" cycle_stateN" ( n k n -- n k n c-addr u ) - -rot tuck 11 + c! swap ( n k n c-addr u -- n k c-addr u ) - evaluate ( n k c-addr u -- n k addr ) + over cycle_stateN ( n k -- n k addr ) begin tuck @ ( n k addr -- n addr k c ) over <> ( n addr k c -- n addr k 0|-1 ) @@ -174,6 +225,10 @@ variable root_state 2drop ( n k addr -- n ) ; =20 +\ +\ Kernel +\=20 + : init_kernel ( N -- N ) kernel_state @ ( n -- n k ) init_cyclestate ( n k -- n ) @@ -185,21 +240,21 @@ variable root_state =20 \ Now we're going to make the change effective =20 - s" cycle_stateN" \ base name of array state var - -rot 2dup 11 + c! rot \ replace 'N' with ASCII numeral - evaluate \ translate name into address - @ \ dereference address into value + dup cycle_stateN @ dup kernel_state ! \ save a copy for re-initialization 48 + \ convert to ASCII numeral =20 s" set kernel=3D${kernel_prefix}${kernel[N]}${kernel_suffix}" - \ command to assemble full kernel-path - -rot tuck 36 + c! swap \ replace 'N' with array index value - evaluate \ sets $kernel to full kernel-path + 36 +c! \ replace 'N' with ASCII numeral + evaluate =20 TRUE \ loop menu again ; =20 +\=20 +\ Root +\=20 + : init_root ( N -- N ) root_state @ ( n -- n k ) init_cyclestate ( n k -- n ) @@ -211,21 +266,21 @@ variable root_state =20 \ Now we're going to make the change effective =20 - s" cycle_stateN" \ base name of array state var - -rot 2dup 11 + c! rot \ replace 'N' with ASCII numeral - evaluate \ translate name into address - @ \ dereference address into value + dup cycle_stateN @ dup root_state ! \ save a copy for re-initialization 48 + \ convert to ASCII numeral =20 s" set root=3D${root_prefix}${root[N]}${root_suffix}" - \ command to assemble root image-path - -rot tuck 30 + c! swap \ replace 'N' with array index value - evaluate \ sets $kernel to full kernel-path + 30 +c! \ replace 'N' with ASCII numeral + evaluate =20 TRUE \ loop menu again ; =20 +\=20 +\ Menusets +\=20 + : goto_menu ( N M -- N TRUE ) menu-unset menuset-loadsetnum ( n m -- n ) Index: menu.4th =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- menu.4th (revision 242835) +++ menu.4th (working copy) @@ -116,6 +116,48 @@ create init_text6 255 allot create init_text7 255 allot create init_text8 255 allot =20 +: +c! ( N C-ADDR/U K -- C-ADDR/U ) + 3 pick 3 pick ( n c-addr/u k -- n c-addr/u k n c-addr ) + rot + c! ( n c-addr/u k n c-addr -- n c-addr/u ) + rot drop ( n c-addr/u -- c-addr/u ) +; + +: menukeyN ( N -- ADDR ) s" menukeyN" 7 +c! evaluate ; +: init_stateN ( N -- ADDR ) s" init_stateN" 10 +c! evaluate ; +: toggle_stateN ( N -- ADDR ) s" toggle_stateN" 12 +c! evaluate ; +: cycle_stateN ( N -- ADDR ) s" cycle_stateN" 11 +c! evaluate ; +: init_textN ( N -- C-ADDR ) s" init_textN" 9 +c! evaluate ; + +: str_loader_menu_title ( -- C-ADDR/U ) s" loader_menu_title" ; +: str_loader_menu_timeout_x ( -- C-ADDR/U ) s" loader_menu_timeout_x" ; +: str_loader_menu_timeout_y ( -- C-ADDR/U ) s" loader_menu_timeout_y" ; +: str_menu_init ( -- C-ADDR/U ) s" menu_init" ; +: str_menu_timeout_command ( -- C-ADDR/U ) s" menu_timeout_command" ; +: str_menu_reboot ( -- C-ADDR/U ) s" menu_reboot" ; +: str_menu_acpi ( -- C-ADDR/U ) s" menu_acpi" ; +: str_menu_options ( -- C-ADDR/U ) s" menu_options" ; +: str_menu_optionstext ( -- C-ADDR/U ) s" menu_optionstext" ; + +: str_menu_init[x] ( -- C-ADDR/U ) s" menu_init[x]" ; +: str_menu_command[x] ( -- C-ADDR/U ) s" menu_command[x]" ; +: str_menu_caption[x] ( -- C-ADDR/U ) s" menu_caption[x]" ; +: str_ansi_caption[x] ( -- C-ADDR/U ) s" ansi_caption[x]" ; +: str_menu_keycode[x] ( -- C-ADDR/U ) s" menu_keycode[x]" ; +: str_toggled_text[x] ( -- C-ADDR/U ) s" toggled_text[x]" ; +: str_toggled_ansi[x] ( -- C-ADDR/U ) s" toggled_ansi[x]" ; +: str_menu_caption[x][y] ( -- C-ADDR/U ) s" menu_caption[x][y]" ; +: str_ansi_caption[x][y] ( -- C-ADDR/U ) s" ansi_caption[x][y]" ; + +: menu_init[x] ( N -- C-ADDR/U ) str_menu_init[x] 10 +c! = ; +: menu_command[x] ( N -- C-ADDR/U ) str_menu_command[x] 13 +c! = ; +: menu_caption[x] ( N -- C-ADDR/U ) str_menu_caption[x] 13 +c! = ; +: ansi_caption[x] ( N -- C-ADDR/U ) str_ansi_caption[x] 13 +c! = ; +: menu_keycode[x] ( N -- C-ADDR/U ) str_menu_keycode[x] 13 +c! = ; +: toggled_text[x] ( N -- C-ADDR/U ) str_toggled_text[x] 13 +c! = ; +: toggled_ansi[x] ( N -- C-ADDR/U ) str_toggled_ansi[x] 13 +c! = ; +: menu_caption[x][y] ( N M -- C-ADDR/U ) str_menu_caption[x][y] 16 +c! = 13 +c! ; +: ansi_caption[x][y] ( N M -- C-ADDR/U ) str_ansi_caption[x][y] 16 +c! = 13 +c! ; + : arch-i386? ( -- BOOL ) \ Returns TRUE (-1) on i386, FALSE (0) = otherwise. s" arch-i386" environment? dup if drop @@ -172,10 +214,7 @@ create init_text8 255 allot \ ASCII numeral equal to user-selected menu item must be on the = stack. \ We do not modify the stack, so the ASCII numeral is left on = top. =20 - s" init_textN" \ base name of buffer - -rot 2dup 9 + c! rot \ replace 'N' with ASCII num - - evaluate c@ 0=3D if + dup init_textN c@ 0=3D if \ NOTE: no need to check toggle_stateN since the first = time we \ are called, we will populate init_textN. Further, we = don't \ need to test whether menu_caption[x] (ansi_caption[x] = when @@ -184,18 +223,15 @@ create init_text8 255 allot =20 \ base name of environment variable loader_color? if - s" ansi_caption[x]" + dup ansi_caption[x] else - s" menu_caption[x]" + dup menu_caption[x] then=09 - -rot 2dup 13 + c! rot \ replace 'x' with ASCII = numeral =20 getenv dup -1 <> if =20 - s" init_textN" \ base name of buffer - 4 pick \ copy ASCII num to top - rot tuck 9 + c! swap \ replace 'N' with ASCII = num - evaluate + 2 pick ( n c-addr/u -- n c-addr/u n ) + init_textN ( n c-addr/u n -- n c-addr/u c-addr ) =20 \ now we have the buffer c-addr on top \ ( followed by c-addr/u of current caption ) @@ -227,36 +263,26 @@ create init_text8 255 allot \ negate the toggled state so that we reverse the flow on = subsequent \ calls. =20 - s" toggle_stateN @" \ base name of toggle state var - -rot 2dup 12 + c! rot \ replace 'N' with ASCII numeral - - evaluate 0=3D if + dup toggle_stateN @ 0=3D if \ state is OFF, toggle to ON =20 - \ base name of toggled text var + dup loader_color? if - s" toggled_ansi[x]" + toggled_ansi[x] else - s" toggled_text[x]" + toggled_text[x] then - -rot 2dup 13 + c! rot \ replace 'x' with ASCII num - getenv dup -1 <> if \ Assign toggled text to menu caption - - \ base name of caption var + 2 pick loader_color? if - s" ansi_caption[x]" + ansi_caption[x] else - s" menu_caption[x]" + menu_caption[x] then - 4 pick \ copy ASCII num to top - rot tuck 13 + c! swap \ replace 'x' with = ASCII num - - setenv \ set new caption + setenv else \ No toggled text, keep the same caption - drop then =20 @@ -264,30 +290,22 @@ create init_text8 255 allot else \ state is ON, toggle to OFF =20 - s" init_textN" \ base name of initial text = buffer - -rot 2dup 9 + c! rot \ replace 'N' with ASCII = numeral - evaluate \ convert string to c-addr - count \ convert c-addr to c-addr/u + dup init_textN count ( n -- n c-addr/u ) =20 - \ base name of caption var + \ Assign init_textN text to menu caption + 2 pick loader_color? if - s" ansi_caption[x]" + ansi_caption[x] else - s" menu_caption[x]" + menu_caption[x] then - 4 pick \ copy ASCII num to top - rot tuck 13 + c! swap \ replace 'x' with ASCII = numeral + setenv =20 - setenv \ set new caption - false \ new value of toggle state var (to be stored = below) + false \ new value of toggle state var (to be stored = below) then =20 \ now we'll store the new toggle state (on top of stack) - s" toggle_stateN" \ base name of toggle state var - 3 pick \ copy ASCII numeral to top - rot tuck 12 + c! swap \ replace 'N' with ASCII numeral - evaluate \ convert string to addr - ! \ store new value + over toggle_stateN ! ; =20 : cycle_menuitem ( N -- N ) \ cycles through array of choices for a = menuitem @@ -295,13 +313,8 @@ create init_text8 255 allot \ ASCII numeral equal to user-selected menu item must be on the = stack. \ We do not modify the stack, so the ASCII numeral is left on = top. =20 - s" cycle_stateN" \ base name of array state var - -rot 2dup 11 + c! rot \ replace 'N' with ASCII numeral + dup cycle_stateN dup @ 1+ \ get value and increment =20 - evaluate \ we now have a pointer to the proper variable - dup @ \ resolve the pointer (but leave it on the stack) - 1+ \ increment the value - \ Before assigning the (incremented) value back to the pointer, \ let's test for the existence of this particular array element. \ If the element exists, we'll store index value and move on. @@ -309,14 +322,12 @@ create init_text8 255 allot =20 dup 48 + \ duplicate Array index and convert to ASCII numeral =20 - \ base name of array caption text + 3 pick swap loader_color? if - s" ansi_caption[x][y]" =20 + ansi_caption[x][y] else - s" menu_caption[x][y]" =20 + menu_caption[x][y] then - -rot tuck 16 + c! swap \ replace 'y' with Array index - 4 pick rot tuck 13 + c! swap \ replace 'x' with menu choice =20 \ Now test for the existence of our incremented array index in = the \ form of $menu_caption[x][y] ($ansi_caption[x][y] with = loader_color @@ -329,19 +340,18 @@ create init_text8 255 allot drop ( incremented array index ) 0 ( new array index that will be stored later ) =20 - \ base name of caption var + 2 pick [char] 0 loader_color? if - s" ansi_caption[x][0]" + ansi_caption[x][y] else - s" menu_caption[x][0]" + menu_caption[x][y] then - 4 pick rot tuck 13 + c! swap \ replace 'x' with menu = choice - getenv dup -1 =3D if \ This is highly unlikely to occur, but to make \ sure that things move along smoothly, allocate \ a temporary NULL string =20 + drop ( getenv cruft ) s" " then then @@ -357,14 +367,14 @@ create init_text8 255 allot \=20 \ Let's perform what we need to with the above. =20 - \ base name of menuitem caption var + \ Assign array value text to menu caption + 4 pick loader_color? if - s" ansi_caption[x]" + ansi_caption[x] else - s" menu_caption[x]" + menu_caption[x] then - 6 pick rot tuck 13 + c! swap \ replace 'x' with menu choice - setenv \ set the new caption + setenv =20 swap ! \ update array state variable ; @@ -400,15 +410,15 @@ create init_text8 255 allot acpipresent? if acpienabled? if loader_color? if - s" toggled_ansi[x]" + str_toggled_ansi[x] else - s" toggled_text[x]" + str_toggled_text[x] then else loader_color? if - s" ansi_caption[x]" + str_ansi_caption[x] else - s" menu_caption[x]" + str_menu_caption[x] then then else @@ -426,7 +436,7 @@ create init_text8 255 allot : menu-create ( -- ) =20 \ Print the frame caption at (x,y) - s" loader_menu_title" getenv dup -1 =3D if + str_loader_menu_title getenv dup -1 =3D if drop s" Welcome to FreeBSD" then 24 over 2 / - 9 at-xy type=20 @@ -435,7 +445,7 @@ create init_text8 255 allot \ constructed dynamically -- as this function could conceivably = set \ the remaining environment variables to construct the menu = entirely). \=20 - s" menu_init" getenv dup -1 <> if + str_menu_init getenv dup -1 <> if evaluate else drop @@ -460,7 +470,7 @@ create init_text8 255 allot \ Initialize the ACPI option status. \=20 0 menuacpi ! - s" menu_acpi" getenv -1 <> if + str_menu_acpi getenv -1 <> if c@ dup 48 > over 57 < and if ( '1' <=3D c1 <=3D '8' ) menuacpi ! arch-i386? if acpipresent? if @@ -468,10 +478,7 @@ create init_text8 255 allot \ Set menu toggle state to active state \ (required by generic toggle_menuitem) \=20 - menuacpi @ - s" acpienabled? toggle_stateN !" - -rot tuck 25 + c! swap - evaluate + acpienabled? menuacpi @ toggle_stateN ! then then else drop @@ -482,7 +489,7 @@ create init_text8 255 allot \ Initialize the menu_options visual separator. \=20 0 menuoptions ! - s" menu_options" getenv -1 <> if + str_menu_options getenv -1 <> if c@ dup 48 > over 57 < and if ( '1' <=3D c1 <=3D '8' ) menuoptions ! else @@ -502,7 +509,7 @@ create init_text8 255 allot \ If the "Options:" separator, print it. dup menuoptions @ =3D if \ Optionally add a reboot option to the menu - s" menu_reboot" getenv -1 <> if + str_menu_reboot getenv -1 <> if drop s" Reboot" printmenuitem menureboot ! true menurebootadded ! @@ -512,7 +519,7 @@ create init_text8 255 allot menurow @ 2 + menurow ! menurow @ menuY @ + at-xy - s" menu_optionstext" getenv dup -1 <> if + str_menu_optionstext getenv dup -1 <> if type else drop ." Options:" @@ -521,17 +528,20 @@ create init_text8 255 allot =20 \ If this is the ACPI menu option, act accordingly. dup menuacpi @ =3D if - acpimenuitem ( -- C-Addr/U | -1 ) + dup acpimenuitem ( n -- n n c-addr/u | n n -1 ) + dup -1 <> if + 13 +c! ( n n c-addr/u -- n ) \ replace = 'x' + else + swap drop ( n n -1 -- n -1 ) + over menu_command[x] unsetenv + then else \ make sure we have not already initialized this = item - s" init_stateN" - -rot 2dup 10 + c! rot \ repace 'N' - evaluate dup @ 0=3D if + dup init_stateN dup @ 0=3D if 1 swap ! =20 \ If this menuitem has an initializer, = run it - s" menu_init[x]" - -rot 2dup 10 + c! rot \ replace 'x' + dup menu_init[x] getenv dup -1 <> if evaluate else @@ -542,34 +552,22 @@ create init_text8 255 allot then =20 loader_color? if - s" ansi_caption[x]" + dup ansi_caption[x] else - s" menu_caption[x]" + dup menu_caption[x] then then =20 - ( C-Addr/U | -1 ) dup -1 <> if - \ replace 'x' with current iteration - -rot 2dup 13 + c! rot - =20 \ test for environment variable getenv dup -1 <> if - printmenuitem ( C-Addr/U -- N ) - =20 - s" menukeyN !" \ generate cmd to store = result - -rot 2dup 7 + c! rot - =20 - evaluate + printmenuitem ( c-addr/u -- n ) + dup menukeyN ! else drop then else drop - - s" menu_command[x]" - -rot 2dup 13 + c! rot ( replace 'x' ) - unsetenv then =20 1+ dup 56 > \ add 1 to iterator, continue if less than = 57 @@ -578,7 +576,7 @@ create init_text8 255 allot =20 \ Optionally add a reboot option to the menu menurebootadded @ true <> if - s" menu_reboot" getenv -1 <> if + str_menu_reboot getenv -1 <> if drop \ no need for the value s" Reboot" \ menu caption (required by = printmenuitem) =20 @@ -596,45 +594,22 @@ create init_text8 255 allot \=20 : menu-timeout-update ( N -- ) =20 - dup 9 > if ( N N 9 -- N ) - drop ( N -- ) - 9 ( maximum: -- N ) - then + \ Enforce minimum/maximum + dup 9 > if drop 9 then + dup 0 < if drop 0 then =20 - dup 0 < if ( N N 0 -- N ) - drop ( N -- ) - 0 ( minimum: -- N ) - then + s" Autoboot in N seconds. [Space] to pause" ( n -- n c-addr/u ) =20 - 48 + ( convert single-digit numeral to ASCII: N 48 -- N ) + 2 pick 0> if + rot 48 + -rot ( n c-addr/u -- n' c-addr/u ) \ convert to = ASCII + 12 +c! ( n' c-addr/u -- c-addr/u ) \ replace = 'N' above =20 - s" Autoboot in N seconds. [Space] to pause" ( N -- N Addr C ) - - 2 pick 48 - 0> if ( N Addr C N 48 -- N Addr C ) - - \ Modify 'N' (Addr+12) above to reflect time-left - - -rot ( N Addr C -- C N Addr ) - tuck ( C N Addr -- C Addr N Addr ) - 12 + ( C Addr N Addr -- C Addr N Addr2 ) - c! ( C Addr N Addr2 -- C Addr ) - swap ( C Addr -- Addr C ) - - menu_timeout_x @ - menu_timeout_y @ - at-xy ( position cursor: Addr C N N -- Addr C ) - - type ( print message: Addr C -- ) - - else ( N Addr C N -- N Addr C ) - - menu_timeout_x @ - menu_timeout_y @ - at-xy ( position cursor: N Addr C N N -- N Addr C ) - - spaces ( erase message: N Addr C -- N Addr ) - 2drop ( N Addr -- ) - + menu_timeout_x @ menu_timeout_y @ at-xy \ position = cursor + type ( c-Addr/u -- ) \ print message + else + menu_timeout_x @ menu_timeout_y @ at-xy \ position = cursor + spaces ( n c-addr/u -- n c-addr ) \ erase message + 2drop ( n c-addr -- ) then =20 0 25 at-xy ( position cursor back at bottom-left ) @@ -682,7 +657,7 @@ create init_text8 255 allot \ (user did not cancel by = pressing ANY \ key) =20 - s" menu_timeout_command" getenv = dup + str_menu_timeout_command getenv = dup -1 =3D if drop \ clean-up else @@ -765,7 +740,7 @@ create init_text8 255 allot 0 menu_timeout_enabled ! \ start with automatic timeout disabled =20 \ check indication that automatic execution after delay is = requested - s" menu_timeout_command" getenv -1 <> if ( Addr C -1 -- | Addr ) + str_menu_timeout_command getenv -1 <> if ( Addr C -1 -- | Addr ) drop ( just testing existence right now: Addr -- ) =20 \ initialize state variables @@ -801,7 +776,7 @@ create init_text8 255 allot =20 menu_timeout_enabled @ 1 =3D if \ read custom column position (if set) - s" loader_menu_timeout_x" getenv dup -1 =3D if + str_loader_menu_timeout_x getenv dup -1 =3D if drop \ no custom column position menu_timeout_default_x \ use default = setting else @@ -813,7 +788,7 @@ create init_text8 255 allot menu_timeout_x ! ( store value on stack from = above ) =20 \ read custom row position (if set) - s" loader_menu_timeout_y" getenv dup -1 =3D if + str_loader_menu_timeout_y getenv dup -1 =3D if drop \ no custom row position menu_timeout_default_y \ use default = setting else @@ -852,13 +827,9 @@ create init_text8 255 allot =20 49 \ Iterator start (loop range 49 to 56; ASCII '1' to = '8') begin - s" menukeyN @" + dup menukeyN @ + rot tuck =3D if =20 - \ replace 'N' with current iteration - -rot 2dup 7 + c! rot - - evaluate rot tuck =3D if - \ Adjust for missing ACPI menuitem on = non-i386 arch-i386? true <> menuacpi @ 0<> and if menuacpi @ over 2dup < -rot =3D = or @@ -868,13 +839,8 @@ create init_text8 255 allot then then =20 - \ base env name for the value (x is a = number) - s" menu_command[x]" - - \ Copy ASCII number to string at offset = 13 - -rot 2dup 13 + c! rot - \ Test for the environment variable + dup menu_command[x] getenv dup -1 <> if \ Execute the stored procedure evaluate @@ -909,16 +875,14 @@ create init_text8 255 allot \=20 \ Check for menu keycode shortcut(s) \=20 - s" menu_keycode[x]" - -rot 2dup 13 + c! rot + dup menu_keycode[x] getenv dup -1 =3D if drop else ?number 0<> if rot tuck =3D if swap - s" menu_command[x]" - -rot 2dup 13 + c! rot + dup menu_command[x] getenv dup -1 <> if evaluate 0=3D if @@ -950,100 +914,43 @@ create init_text8 255 allot =20 49 \ Iterator start (loop range 49 to 56; ASCII '1' to '8') begin - \ Unset variables in-order of appearance in menu.4th(8) + dup menu_init[x] unsetenv \ menu initializer + dup menu_command[x] unsetenv \ menu command + dup menu_caption[x] unsetenv \ menu caption + dup ansi_caption[x] unsetenv \ ANSI caption + dup menu_keycode[x] unsetenv \ menu keycode + dup toggled_text[x] unsetenv \ toggle_menuitem = caption + dup toggled_ansi[x] unsetenv \ toggle_menuitem ANSI = caption =20 - s" menu_caption[x]" \ basename for caption variable - -rot 2dup 13 + c! rot \ replace 'x' with current = iteration - unsetenv \ not erroneous to unset unknown = var - - s" menu_command[x]" \ command basename - -rot 2dup 13 + c! rot \ replace 'x' - unsetenv - - s" menu_init[x]" \ initializer basename - -rot 2dup 10 + c! rot \ replace 'x' - unsetenv - - s" menu_keycode[x]" \ keycode basename - -rot 2dup 13 + c! rot \ replace 'x' - unsetenv - - s" ansi_caption[x]" \ ANSI caption basename - -rot 2dup 13 + c! rot \ replace 'x' - unsetenv - - s" toggled_text[x]" \ toggle_menuitem caption = basename - -rot 2dup 13 + c! rot \ replace 'x' - unsetenv - - s" toggled_ansi[x]" \ toggle_menuitem ANSI caption = basename - -rot 2dup 13 + c! rot \ replace 'x' - unsetenv - - s" menu_caption[x][y]" \ cycle_menuitem caption - -rot 2dup 13 + c! rot \ replace 'x' - 48 -rot + 48 \ Iterator start (inner range 48 to 57; ASCII '0' to = '9') begin - 16 2over rot + c! \ replace 'y' - 2dup unsetenv - - rot 1+ dup 57 > 2swap rot + \ cycle_menuitem caption and ANSI caption + 2dup menu_caption[x][y] unsetenv + 2dup ansi_caption[x][y] unsetenv + 1+ dup 57 > until - 2drop drop + drop \ inner iterator =20 - s" ansi_caption[x][y]" \ cycle_menuitem ANSI caption - -rot 2dup 13 + c! rot \ replace 'x' - 48 -rot - begin - 16 2over rot + c! \ replace 'y' - 2dup unsetenv + 0 over menukeyN ! \ used by menu-create, = menu-display + 0 over init_stateN ! \ used by menu-create + 0 over toggle_stateN ! \ used by toggle_menuitem + 0 over init_textN c! \ used by toggle_menuitem + 0 over cycle_stateN ! \ used by cycle_menuitem =20 - rot 1+ dup 57 > 2swap rot - until - 2drop drop - - s" 0 menukeyN !" \ basename for key association = var - -rot 2dup 9 + c! rot \ replace 'N' with current = iteration - evaluate \ assign zero (0) to key assoc. = var - - s" 0 init_stateN !" \ used by menu-create - -rot 2dup 12 + c! rot \ replace 'N' - evaluate - - s" 0 toggle_stateN !" \ used by toggle_menuitem - -rot 2dup 14 + c! rot \ replace 'N' - evaluate - - s" 0 cycle_stateN !" \ used by cycle_menuitem - -rot 2dup 13 + c! rot \ replace 'N' - evaluate - - s" 0 init_textN c!" \ used by toggle_menuitem - -rot 2dup 11 + c! rot \ replace 'N' - evaluate - 1+ dup 56 > \ increment, continue if less than 57 until drop \ iterator =20 - \ unset the timeout command - s" menu_timeout_command" unsetenv + str_menu_timeout_command unsetenv \ menu timeout command + str_menu_reboot unsetenv \ Reboot menu option = flag + str_menu_acpi unsetenv \ ACPI menu option flag + str_menu_options unsetenv \ Options separator flag + str_menu_optionstext unsetenv \ separator display text + str_menu_init unsetenv \ menu initializer =20 - \ clear the "Reboot" menu option flag - s" menu_reboot" unsetenv 0 menureboot ! - - \ clear the ACPI menu option flag - s" menu_acpi" unsetenv 0 menuacpi ! - - \ clear the "Options" menu separator flag - s" menu_options" unsetenv - s" menu_optionstext" unsetenv 0 menuoptions ! - - \ clear the menu initializer - s" menu_init" unsetenv ; =20 \ This function both unsets menu variables and visually erases the menu = area --Apple-Mail=_7B0FAB50-55AF-495E-9AC7-6EDA850F9A15-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 12 08:56:24 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26C082BC; Mon, 12 Nov 2012 08:56:24 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [IPv6:2001:a60:0:28:0:1:25:1]) by mx1.freebsd.org (Postfix) with ESMTP id 960E18FC1B; Mon, 12 Nov 2012 08:56:23 +0000 (UTC) Received: from frontend1.mail.m-online.net (frontend1.mail.intern.m-online.net [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 3Y0Qmt6Dr1z3hhmL; Mon, 12 Nov 2012 09:56:14 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 3Y0Qmt4pNlzbbgv; Mon, 12 Nov 2012 09:56:14 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.180]) by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavisd-new, port 10024) with ESMTP id qWfKuBZP5taz; Mon, 12 Nov 2012 09:53:38 +0100 (CET) Received: from ux32.reifenberger.com (ppp-93-104-38-109.dynamic.mnet-online.de [93.104.38.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPS; Mon, 12 Nov 2012 09:56:08 +0100 (CET) Date: Mon, 12 Nov 2012 09:56:10 +0100 From: mike To: freebsd-arch@freebsd.org Subject: Working on Bootforth / ficl In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: mike@reifenberger.com@mail.eeeit.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Adrian Chadd , Devin Teske X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 08:56:24 -0000 Hi, a few years ago I made an upgrade to ficl 4.0 and some other changes which brought among other things: - A somewhat simpler C-interface (IMHO) - Real compression for the softwords - A user-land ficl executable which acted exactly like the bootloader for better forth development A first step to get back on this topic would be to vendor import the related ficl versions (ficl33, ficl40, ficl41) and move the currently used ficl33 from sys/boot/ficl to sys/contrib/ficl and separate the local modifications from the vendor code. Any objections in general? What would be the preferred method? - Vendor import of ficl33 as described in the commiters guide - svn copy of ficl33 to sys/contrib/ficl - svn copy of the locally modified ficl33 files or reapply the local changes? Other suggestions? Thanks in advance! Greetings --- Michael Reifenberger From owner-freebsd-arch@FreeBSD.ORG Mon Nov 12 17:40:23 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA71E425; Mon, 12 Nov 2012 17:40:23 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id AD0BA8FC08; Mon, 12 Nov 2012 17:40:23 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id qACHeMvw009595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Nov 2012 11:40:22 -0600 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.16) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 12 Nov 2012 11:40:21 -0600 Subject: Re: Working on Bootforth / ficl MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Devin Teske In-Reply-To: Date: Mon, 12 Nov 2012 09:40:19 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: <1DE1DC5C-9D7F-4FC7-A27C-736B0B172DBF@fisglobal.com> References: To: mike X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-12_03:2012-11-12,2012-11-11,1970-01-01 signatures=0 Cc: Adrian Chadd , Devin Teske , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 17:40:24 -0000 On Nov 12, 2012, at 12:56 AM, mike wrote: > Hi, > a few years ago I made an upgrade to ficl 4.0 and some other changes whic= h brought among other things: - A somewhat simpler C-interface (IMHO) The simplified C interface would be welcome in the upcoming BE enhancements. > - Real compression for the softwoods I like the sound of that. > - A user-land ficl executable which acted exactly like the bootloader for= better > forth development >=20 Does it support "include" ? That's been one of the biggest things preventin= g me from simulating boot in userland. If it does, this would be a very gre= at addition. > A first step to get back on this topic would be to vendor import the rela= ted ficl versions (ficl33, ficl40, ficl41) and move the currently used ficl= 33 > from sys/boot/ficl to sys/contrib/ficl and separate the local modificatio= ns > from the vendor code. >=20 > Any objections in general? >=20 I've none, but you should seek opinions of others too. --=20 Devin P.S. Thank you! > What would be the preferred method? > - Vendor import of ficl33 as described in the commiters guide > - svn copy of ficl33 to sys/contrib/ficl > - svn copy of the locally modified ficl33 files or reapply the local chan= ges? >=20 > Other suggestions? >=20 > Thanks in advance! >=20 > Greetings > --- > Michael Reifenberger _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-arch@FreeBSD.ORG Mon Nov 12 18:44:07 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D3132CB; Mon, 12 Nov 2012 18:44:07 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id C05FC8FC13; Mon, 12 Nov 2012 18:44:06 +0000 (UTC) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTPS id D608211B48; Tue, 13 Nov 2012 04:43:58 +1000 (EST) Received: from Peter-Grehans-MacBook-Pro.local (c-67-190-8-21.hsd1.co.comcast.net [67.190.8.21]) by dommail.onthenet.com.au (MOS 4.2.4-GA) with ESMTP id BHP14009 (AUTH peterg@ptree32.com.au); Tue, 13 Nov 2012 04:43:55 +1000 Message-ID: <50A1435F.2010002@freebsd.org> Date: Mon, 12 Nov 2012 11:43:43 -0700 From: Peter Grehan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Devin Teske Subject: Re: Working on Bootforth / ficl References: <1DE1DC5C-9D7F-4FC7-A27C-736B0B172DBF@fisglobal.com> In-Reply-To: <1DE1DC5C-9D7F-4FC7-A27C-736B0B172DBF@fisglobal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Info: RCVD_IN_SORBS_DUL,RDNS_DYNAMIC,SPF_SOFTFAIL X-Junkmail-Status: score=24/51, host=dommail.onthenet.com.au Cc: mike , Devin Teske , Adrian Chadd , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:44:07 -0000 Hi Devin, >> - A user-land ficl executable which acted exactly like the >> bootloader for better forth development >> > > Does it support "include" ? That's been one of the biggest things > preventing me from simulating boot in userland. If it does, this > would be a very great addition. Have you had a look at sys/boot/userboot/test ? That should be able to (mostly?) help with userspace testing. later, Peter. From owner-freebsd-arch@FreeBSD.ORG Mon Nov 12 18:52:01 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6FFF87CD; Mon, 12 Nov 2012 18:52:01 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 300748FC13; Mon, 12 Nov 2012 18:52:00 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa06.fnfis.com (8.14.5/8.14.5) with ESMTP id qACIq0cH020948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Nov 2012 12:52:00 -0600 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 12 Nov 2012 12:51:59 -0600 Subject: Re: Working on Bootforth / ficl MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="iso-8859-1" From: Devin Teske In-Reply-To: <50A1435F.2010002@freebsd.org> Date: Mon, 12 Nov 2012 10:51:58 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: <4693988C-04B2-457F-9E4A-CB64840E05C6@fisglobal.com> References: <1DE1DC5C-9D7F-4FC7-A27C-736B0B172DBF@fisglobal.com> <50A1435F.2010002@freebsd.org> To: Peter Grehan X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-12_03:2012-11-12,2012-11-11,1970-01-01 signatures=0 Cc: mike , Devin Teske , Adrian Chadd , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:52:01 -0000 On Nov 12, 2012, at 10:43 AM, Peter Grehan wrote: > Hi Devin, >=20 >>> - A user-land ficl executable which acted exactly like the >>> bootloader for better forth development >>>=20 >>=20 >> Does it support "include" ? That's been one of the biggest things >> preventing me from simulating boot in userland. If it does, this >> would be a very great addition. >=20 > Have you had a look at sys/boot/userboot/test ? That should be able to (m= ostly?) help with userspace testing. >=20 Until now, I was only aware of "testmain" under sys/boot/ficl/ (and that do= esn't get me very far because it lacks "include"). I took a look at sys/boot/userboot/test and it looks a lot more robust. However, "test" currently doesn't compile (error below): =3D=3D=3D> test (all) Warning: Object directory not changed from original /usr/home/dteske/src/fr= eebsd_svn/base/head/sys/boot/userboot/test cc -O2 -pipe -I/usr/home/dteske/src/freebsd_svn/base/head/sys/boot/userboo= t/test/.. -I/usr/home/dteske/src/freebsd_svn/base/head/sys/boot/userboot/te= st/../../.. -std=3Dgnu99 -c test.c In file included from test.c:41: /usr/include/stdlib.h:54: error: expected '=3D', ',', ';', 'asm' or '__attr= ibute__' before 'wchar_t' /usr/include/stdlib.h:95: error: expected ')' before '*' token /usr/include/stdlib.h:96: error: expected ')' before '*' token /usr/include/stdlib.h:110: error: expected declaration specifiers or '...' = before 'wchar_t' /usr/include/stdlib.h:111: error: expected ';', ',' or ')' before '*' token *** Error code 1 Stop in /usr/home/dteske/src/freebsd_svn/base/head/sys/boot/userboot/test. *** Error code 1 --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-arch@FreeBSD.ORG Mon Nov 12 19:02:05 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CACDFFDF; Mon, 12 Nov 2012 19:02:05 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 73D928FC08; Mon, 12 Nov 2012 19:02:05 +0000 (UTC) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTPS id E6B3A11B48; Tue, 13 Nov 2012 05:02:03 +1000 (EST) Received: from jkaufman2-lxp.hq.netapp.com (pos-ext.netapp.com [198.95.226.40]) by dommail.onthenet.com.au (MOS 4.2.4-GA) with ESMTP id BHP14241 (AUTH peterg@ptree32.com.au); Tue, 13 Nov 2012 05:02:00 +1000 Message-ID: <50A147A5.80208@freebsd.org> Date: Mon, 12 Nov 2012 12:01:57 -0700 From: Peter Grehan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Devin Teske Subject: Re: Working on Bootforth / ficl References: <1DE1DC5C-9D7F-4FC7-A27C-736B0B172DBF@fisglobal.com> <50A1435F.2010002@freebsd.org> <4693988C-04B2-457F-9E4A-CB64840E05C6@fisglobal.com> In-Reply-To: <4693988C-04B2-457F-9E4A-CB64840E05C6@fisglobal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Info: SPF_SOFTFAIL X-Junkmail-Status: score=6/51, host=dommail.onthenet.com.au Cc: mike , Devin Teske , Adrian Chadd , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 19:02:05 -0000 Hi Devin, > However, "test" currently doesn't compile (error below): > > ===> test (all) > Warning: Object directory not changed from original /usr/home/dteske/src/freebsd_svn/base/head/sys/boot/userboot/test > cc -O2 -pipe -I/usr/home/dteske/src/freebsd_svn/base/head/sys/boot/userboot/test/.. -I/usr/home/dteske/src/freebsd_svn/base/head/sys/boot/userboot/test/../../.. -std=gnu99 -c test.c > In file included from test.c:41: > /usr/include/stdlib.h:54: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'wchar_t' > /usr/include/stdlib.h:95: error: expected ')' before '*' token > /usr/include/stdlib.h:96: error: expected ')' before '*' token > /usr/include/stdlib.h:110: error: expected declaration specifiers or '...' before 'wchar_t' > /usr/include/stdlib.h:111: error: expected ';', ',' or ')' before '*' token > *** Error code 1 > > Stop in /usr/home/dteske/src/freebsd_svn/base/head/sys/boot/userboot/test. > *** Error code 1 Hmmm, it's part of the stock build and I haven't seen any failures in that area. Was this part of a buildworld ? It may not build correctly from the directory itself. later, Peter. From owner-freebsd-arch@FreeBSD.ORG Mon Nov 12 19:05:12 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C088B114; Mon, 12 Nov 2012 19:05:12 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 7F62F8FC08; Mon, 12 Nov 2012 19:05:11 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id qACJ5BDp008037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Nov 2012 13:05:11 -0600 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.17) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 12 Nov 2012 13:05:10 -0600 Subject: Re: Working on Bootforth / ficl MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="iso-8859-1" From: Devin Teske In-Reply-To: <50A147A5.80208@freebsd.org> Date: Mon, 12 Nov 2012 11:05:09 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: <68C4FC13-08E2-485F-B4A6-DB4B5271859E@fisglobal.com> References: <1DE1DC5C-9D7F-4FC7-A27C-736B0B172DBF@fisglobal.com> <50A1435F.2010002@freebsd.org> <4693988C-04B2-457F-9E4A-CB64840E05C6@fisglobal.com> <50A147A5.80208@freebsd.org> To: Peter Grehan X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-12_03:2012-11-12,2012-11-11,1970-01-01 signatures=0 Cc: mike , Devin Teske , Adrian Chadd , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 19:05:12 -0000 On Nov 12, 2012, at 11:01 AM, Peter Grehan wrote: > Hi Devin, >=20 >> However, "test" currently doesn't compile (error below): >>=20 >> =3D=3D=3D> test (all) >> Warning: Object directory not changed from original /usr/home/dteske/src= /freebsd_svn/base/head/sys/boot/userboot/test >> cc -O2 -pipe -I/usr/home/dteske/src/freebsd_svn/base/head/sys/boot/user= boot/test/.. -I/usr/home/dteske/src/freebsd_svn/base/head/sys/boot/userboot= /test/../../.. -std=3Dgnu99 -c test.c >> In file included from test.c:41: >> /usr/include/stdlib.h:54: error: expected '=3D', ',', ';', 'asm' or '__a= ttribute__' before 'wchar_t' >> /usr/include/stdlib.h:95: error: expected ')' before '*' token >> /usr/include/stdlib.h:96: error: expected ')' before '*' token >> /usr/include/stdlib.h:110: error: expected declaration specifiers or '..= .' before 'wchar_t' >> /usr/include/stdlib.h:111: error: expected ';', ',' or ')' before '*' to= ken >> *** Error code 1 >>=20 >> Stop in /usr/home/dteske/src/freebsd_svn/base/head/sys/boot/userboot/tes= t. >> *** Error code 1 >=20 > Hmmm, it's part of the stock build and I haven't seen any failures in tha= t area. Was this part of a buildworld ? It may not build correctly from the= directory itself. >=20 Negative -- no buildworld. I figured since sys/boot/ficl/ could build "testmain" standalone that perha= ps userboot could too (what a shame). Next time I do a buildworld (or am mucking in one of my completed builds), = I'll check it out. --=20 Thanks, Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-arch@FreeBSD.ORG Mon Nov 12 19:09:38 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E50F28D; Mon, 12 Nov 2012 19:09:38 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 983CA8FC08; Mon, 12 Nov 2012 19:09:37 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so820135obc.13 for ; Mon, 12 Nov 2012 11:09:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7Z2zj3rPDxlNTV5D0k+i3Jpwi8ulGVNuyfMZBr8jSDU=; b=FG6pPCw5/0Mg/D3wxcCmpm24TMdhWrlnJ3TPU5cPlSigwxvKHsJpd5W9fDTGfEvWN2 zHrzk680nI8W+IBYQbwCNBmiZxGI1yN5u51MB5Xww4a+Jq5fWrYslNdXYVY9T4cZwz2o D6bIXHDbYXbfDTCdUjJmYgAO8cjEvIfMiuXTX4eC6IkQyRElpppTkKHCV3wOk6YhL9k0 9BLuD6tinRNQZ4JwoJdPZQzqYTpCwn8cZ8rpYG3+CLiPvjITyQ0ABvSvcKUfmwxh3Mgk HO5hpuXLUORpm5VoI8LOWggyQJkzEey2E/dm+0S1Uylodshwl1/60wLJZZhqUC9h/946 Y5aQ== MIME-Version: 1.0 Received: by 10.60.25.104 with SMTP id b8mr5179332oeg.18.1352747376568; Mon, 12 Nov 2012 11:09:36 -0800 (PST) Received: by 10.76.143.33 with HTTP; Mon, 12 Nov 2012 11:09:36 -0800 (PST) In-Reply-To: <68C4FC13-08E2-485F-B4A6-DB4B5271859E@fisglobal.com> References: <1DE1DC5C-9D7F-4FC7-A27C-736B0B172DBF@fisglobal.com> <50A1435F.2010002@freebsd.org> <4693988C-04B2-457F-9E4A-CB64840E05C6@fisglobal.com> <50A147A5.80208@freebsd.org> <68C4FC13-08E2-485F-B4A6-DB4B5271859E@fisglobal.com> Date: Mon, 12 Nov 2012 11:09:36 -0800 Message-ID: Subject: Re: Working on Bootforth / ficl From: Garrett Cooper To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: mike , Adrian Chadd , Peter Grehan , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 19:09:38 -0000 On Mon, Nov 12, 2012 at 11:05 AM, Devin Teske wrote: > > On Nov 12, 2012, at 11:01 AM, Peter Grehan wrote: > > > Hi Devin, > > > >> However, "test" currently doesn't compile (error below): > >> > >> ===> test (all) > >> Warning: Object directory not changed from original > /usr/home/dteske/src/freebsd_svn/base/head/sys/boot/userboot/test > >> cc -O2 -pipe > -I/usr/home/dteske/src/freebsd_svn/base/head/sys/boot/userboot/test/.. > -I/usr/home/dteske/src/freebsd_svn/base/head/sys/boot/userboot/test/../../.. > -std=gnu99 -c test.c > >> In file included from test.c:41: > >> /usr/include/stdlib.h:54: error: expected '=', ',', ';', 'asm' or > '__attribute__' before 'wchar_t' > >> /usr/include/stdlib.h:95: error: expected ')' before '*' token > >> /usr/include/stdlib.h:96: error: expected ')' before '*' token > >> /usr/include/stdlib.h:110: error: expected declaration specifiers or > '...' before 'wchar_t' > >> /usr/include/stdlib.h:111: error: expected ';', ',' or ')' before '*' > token > >> *** Error code 1 > >> > >> Stop in > /usr/home/dteske/src/freebsd_svn/base/head/sys/boot/userboot/test. > >> *** Error code 1 > > > > Hmmm, it's part of the stock build and I haven't seen any failures in > that area. Was this part of a buildworld ? It may not build correctly from > the directory itself. > > > > Negative -- no buildworld. > > I figured since sys/boot/ficl/ could build "testmain" standalone that > perhaps userboot could too (what a shame). > > Next time I do a buildworld (or am mucking in one of my completed builds), > I'll check it out. > I forgot about that. Pretty cool. -Garrett $ cd /usr/src/sys/boot/userboot/test; `make -V.OBJDIR`/test Consoles: userboot FreeBSD/amd64 User boot, Revision 1.1 (gcooper@forza.west.isilon.com, Thu Sep 20 19:21:42 PDT 2012) / can't load 'kernel' Type '?' for a list of commands, 'help' for more detailed help. OK not found OK OK OK load /kernel can't find '/kernel' From owner-freebsd-arch@FreeBSD.ORG Tue Nov 13 10:42:31 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37D1E3D8; Tue, 13 Nov 2012 10:42:31 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by mx1.freebsd.org (Postfix) with ESMTP id DDAAA8FC12; Tue, 13 Nov 2012 10:42:30 +0000 (UTC) Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 3Y14z665gbz4KK2x; Tue, 13 Nov 2012 11:37:22 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 3Y14z65sp7zbbj4; Tue, 13 Nov 2012 11:37:22 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.180]) by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavisd-new, port 10024) with ESMTP id TONF2XNu3ivm; Tue, 13 Nov 2012 11:34:48 +0100 (CET) Received: from ux32.reifenberger.com (ppp-93-104-63-242.dynamic.mnet-online.de [93.104.63.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPS; Tue, 13 Nov 2012 11:37:21 +0100 (CET) Date: Tue, 13 Nov 2012 11:37:23 +0100 From: mike To: Devin Teske Subject: Re: Working on Bootforth / ficl In-Reply-To: <1DE1DC5C-9D7F-4FC7-A27C-736B0B172DBF@fisglobal.com> Message-ID: References: <1DE1DC5C-9D7F-4FC7-A27C-736B0B172DBF@fisglobal.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: mike@reifenberger.com@mail.eeeit.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Adrian Chadd , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 10:42:31 -0000 On Mon, 12 Nov 2012, Devin Teske wrote: ... >> - A user-land ficl executable which acted exactly like the bootloader for better >> forth development >> > > Does it support "include" ? That's been one of the biggest things preventing me from simulating boot in userland. If it does, this would be a very great addition. > > Yes, if I remember right. I was able to do anything up to the boot command... include is allways there btw. Its implemented using libstand funtionality and wrapped into a FORTH word later on.. NB: Because on amd64 the loader gets compiled as a i386 binary I produced there a i386 userland binary too because it was simpler to implement. Shouldn't matter for bootforth testing purposes. Greetings --- Michael Reifenberger From owner-freebsd-arch@FreeBSD.ORG Tue Nov 13 11:18:09 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42588A6A for ; Tue, 13 Nov 2012 11:18:09 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 23EBA8FC14 for ; Tue, 13 Nov 2012 11:18:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qADBI9Ej004574 for ; Tue, 13 Nov 2012 11:18:09 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qADBI8eT004573 for arch@FreeBSD.org; Tue, 13 Nov 2012 11:18:08 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Tue, 13 Nov 2012 12:18:06 +0100 From: Baptiste Daroussin To: arch@FreeBSD.org Subject: Increasing MAXLOGNAME from 17 to 33 Message-ID: <20121113111806.GE62533@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r7U+bLA8boMOj+mD" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 11:18:09 -0000 --r7U+bLA8boMOj+mD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I want to increase MAXLOGNAME in sys/param.h from 17 to 33 to allow 32-character long usernames, the PR: misc/161091 and misc/133926 already requested for it. utmpx already allow 32 character long user names. I plan to bump the __FreeBSD_version at the same time because of the ABI breakage. This is simplify life of lots administrator, this value, is a common value for other operating systems. Do anyone have objections about it? regards, Bapt --r7U+bLA8boMOj+mD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCiLG4ACgkQ8kTtMUmk6ExxzQCgv0OCrlGB3COs6rC0PjLigdct aMoAnRY27RFx17Jxmz5KnL1mKBqxC/3p =ZG8F -----END PGP SIGNATURE----- --r7U+bLA8boMOj+mD-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 13 11:50:43 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6B74188; Tue, 13 Nov 2012 11:50:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 113A38FC12; Tue, 13 Nov 2012 11:50:42 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qADBoYr7037546; Tue, 13 Nov 2012 13:50:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-DKIM: OpenDKIM Filter v2.5.2 kib.kiev.ua qADBoYr7037546 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qADBoY3b037545; Tue, 13 Nov 2012 13:50:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 13 Nov 2012 13:50:34 +0200 From: Konstantin Belousov To: Baptiste Daroussin Subject: Re: Increasing MAXLOGNAME from 17 to 33 Message-ID: <20121113115034.GJ73505@kib.kiev.ua> References: <20121113111806.GE62533@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cUzoOeFTT7puyy6E" Content-Disposition: inline In-Reply-To: <20121113111806.GE62533@ithaqua.etoilebsd.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 11:50:43 -0000 --cUzoOeFTT7puyy6E Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2012 at 12:18:06PM +0100, Baptiste Daroussin wrote: > Hi, >=20 > I want to increase MAXLOGNAME in sys/param.h from 17 to 33 to allow 32-ch= aracter > long usernames, the PR: misc/161091 and misc/133926 already requested for= it. >=20 > utmpx already allow 32 character long user names. >=20 > I plan to bump the __FreeBSD_version at the same time because of the ABI > breakage. >=20 > This is simplify life of lots administrator, this value, is a common valu= e for > other operating systems. >=20 > Do anyone have objections about it? Yes, I have. Do not break the ABI, it is plain prohibited. You might consider increasing the constant only if providing ABI compatibility shims. In fact, the cursory look over the whole base system indicates that ABI breakage might be not that big and could be mitigated with relatively limited amount of the efforts. --cUzoOeFTT7puyy6E Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCiNAoACgkQC3+MBN1Mb4jPUwCeNk2Pp4hOQlp53nRmlitiNhMk kgIAn1BPmg0rbtolEo3j3lEUNX5C4zme =qgII -----END PGP SIGNATURE----- --cUzoOeFTT7puyy6E-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 13 18:34:16 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA8CE9AA for ; Tue, 13 Nov 2012 18:34:15 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C88238FC0C; Tue, 13 Nov 2012 18:34:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qADIYFbS028112; Tue, 13 Nov 2012 18:34:15 GMT (envelope-from bapt@freebsd.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qADIYFDP028109; Tue, 13 Nov 2012 18:34:15 GMT (envelope-from bapt@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@freebsd.org using -f Date: Tue, 13 Nov 2012 19:34:12 +0100 From: Baptiste Daroussin To: Konstantin Belousov Subject: Re: Increasing MAXLOGNAME from 17 to 33 Message-ID: <20121113183412.GA75103@ithaqua.etoilebsd.net> References: <20121113111806.GE62533@ithaqua.etoilebsd.net> <20121113115034.GJ73505@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <20121113115034.GJ73505@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 18:34:16 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2012 at 01:50:34PM +0200, Konstantin Belousov wrote: > On Tue, Nov 13, 2012 at 12:18:06PM +0100, Baptiste Daroussin wrote: > > Hi, > >=20 > > I want to increase MAXLOGNAME in sys/param.h from 17 to 33 to allow 32-= character > > long usernames, the PR: misc/161091 and misc/133926 already requested f= or it. > >=20 > > utmpx already allow 32 character long user names. > >=20 > > I plan to bump the __FreeBSD_version at the same time because of the ABI > > breakage. > >=20 > > This is simplify life of lots administrator, this value, is a common va= lue for > > other operating systems. > >=20 > > Do anyone have objections about it? >=20 > Yes, I have. Do not break the ABI, it is plain prohibited. > You might consider increasing the constant only if providing ABI > compatibility shims. >=20 > In fact, the cursory look over the whole base system indicates that ABI > breakage might be not that big and could be mitigated with relatively > limited amount of the efforts. Thanks cognet for the help on the following. After auditing base, it seems like this patch is enough http://people.freebsd.org/~bapt/maxlogname-33.diff The users of MAXLOGNAME in base are: bin/ps/ps.c kerberos5/lib/libgssapi_krb5/pname_to_uid.c lib/libc/posix1e/acl_to_text.c lib/libc/gen/getpwent.c lib/libc/gen/sysconf.c lib/libfetch/ftp.c lib/libc/gen/getlogin.c libexec/ftpd/ftpd.c libexec/atrun/atrun.c libexec/lukemftpd/nbsd2fbsd.h libexec/getty/main.c sys/sys/loginclass.h sys/sys/proc.h sys/kern/kern_prot.c sys/security/audit/audit_private.h sys/security/audit/audit_arg.c usr.bin/id/id.c usr.bin/at/at.c usr.bin/finger/sprint.c usr.bin/su/su.c usr.bin/find/ls.c usr.bin/login/login.c usr.bin/lastcomm/lastcomm.c usr.sbin/edquota/edquota.c usr.sbin/pwd_mkdb/pwd_mkdb.c usr.sbin/syslogd/syslogd.c usr.sbin/repquota/Repquota.c usr.sbin/sa/usrdb.c usr.sbin/pw/pwupd.c usr.sbin/pw/grupd.c usr.sbin/pw/pw_user.c usr.sbin/inetd/builtins.c The way they use it is ok, I don't see any problem with them. We also checked usage of LOGIN_NAME_MAX _SC_LOGIN_NAME_MAX and nothing in b= ase seems problematic at this point. last getlogin(2) is always used in base, I saw no direct usage of _getlogin= , and getlogin(2) correctly check the return value of _getlogin Last this patch makes getlogin(2) return the ERANGE error as it should be according to its manpage? Is there anything that have been missed there? regards, Bapt --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCikqQACgkQ8kTtMUmk6ExACgCgk8PqFSQP9yx4wRu/G/Y76OMi 5rwAnip09m1kwcpnlUZ8K4cziHCE7wgd =ms/h -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 13 18:42:51 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 69361B3F; Tue, 13 Nov 2012 18:42:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id B4A2E8FC12; Tue, 13 Nov 2012 18:42:50 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qADIgd5F089484; Tue, 13 Nov 2012 20:42:39 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qADIgd5F089484 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qADIgdoR089483; Tue, 13 Nov 2012 20:42:39 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 13 Nov 2012 20:42:38 +0200 From: Konstantin Belousov To: Baptiste Daroussin Subject: Re: Increasing MAXLOGNAME from 17 to 33 Message-ID: <20121113184238.GO73505@kib.kiev.ua> References: <20121113111806.GE62533@ithaqua.etoilebsd.net> <20121113115034.GJ73505@kib.kiev.ua> <20121113183412.GA75103@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4492t87HU5WhnhG2" Content-Disposition: inline In-Reply-To: <20121113183412.GA75103@ithaqua.etoilebsd.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 18:42:51 -0000 --4492t87HU5WhnhG2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2012 at 07:34:12PM +0100, Baptiste Daroussin wrote: > On Tue, Nov 13, 2012 at 01:50:34PM +0200, Konstantin Belousov wrote: > > On Tue, Nov 13, 2012 at 12:18:06PM +0100, Baptiste Daroussin wrote: > > > Hi, > > >=20 > > > I want to increase MAXLOGNAME in sys/param.h from 17 to 33 to allow 3= 2-character > > > long usernames, the PR: misc/161091 and misc/133926 already requested= for it. > > >=20 > > > utmpx already allow 32 character long user names. > > >=20 > > > I plan to bump the __FreeBSD_version at the same time because of the = ABI > > > breakage. > > >=20 > > > This is simplify life of lots administrator, this value, is a common = value for > > > other operating systems. > > >=20 > > > Do anyone have objections about it? > >=20 > > Yes, I have. Do not break the ABI, it is plain prohibited. > > You might consider increasing the constant only if providing ABI > > compatibility shims. > >=20 > > In fact, the cursory look over the whole base system indicates that ABI > > breakage might be not that big and could be mitigated with relatively > > limited amount of the efforts. >=20 > Thanks cognet for the help on the following. >=20 > After auditing base, it seems like this patch is enough > http://people.freebsd.org/~bapt/maxlogname-33.diff Regarding the patch, the dereferencing of p->p_session should be done under the proc lock to guarantee stability of p_pgrp, and under session mutex to prevent s_login modifications. Altogether, this means that the if() shall be moved down right before bcopy and locks unlocked on return. >=20 > The users of MAXLOGNAME in base are: > bin/ps/ps.c > kerberos5/lib/libgssapi_krb5/pname_to_uid.c > lib/libc/posix1e/acl_to_text.c > lib/libc/gen/getpwent.c > lib/libc/gen/sysconf.c > lib/libfetch/ftp.c > lib/libc/gen/getlogin.c > libexec/ftpd/ftpd.c > libexec/atrun/atrun.c > libexec/lukemftpd/nbsd2fbsd.h > libexec/getty/main.c > sys/sys/loginclass.h > sys/sys/proc.h > sys/kern/kern_prot.c > sys/security/audit/audit_private.h > sys/security/audit/audit_arg.c > usr.bin/id/id.c > usr.bin/at/at.c > usr.bin/finger/sprint.c > usr.bin/su/su.c > usr.bin/find/ls.c > usr.bin/login/login.c > usr.bin/lastcomm/lastcomm.c > usr.sbin/edquota/edquota.c > usr.sbin/pwd_mkdb/pwd_mkdb.c > usr.sbin/syslogd/syslogd.c > usr.sbin/repquota/Repquota.c > usr.sbin/sa/usrdb.c > usr.sbin/pw/pwupd.c > usr.sbin/pw/grupd.c > usr.sbin/pw/pw_user.c > usr.sbin/inetd/builtins.c >=20 > The way they use it is ok, I don't see any problem with them. > We also checked usage of LOGIN_NAME_MAX _SC_LOGIN_NAME_MAX and nothing in= base > seems problematic at this point. >=20 > last getlogin(2) is always used in base, I saw no direct usage of _getlog= in, and > getlogin(2) correctly check the return value of _getlogin >=20 > Last this patch makes getlogin(2) return the ERANGE error as it should be > according to its manpage? I do not quite understand the sentences. >=20 > Is there anything that have been missed there? Well, if the full audit of the base was performed and no issues are indeed found, this should be fine. I suggest to commit the fixed ERANGE patch separately. It definitely shall be merged, not sure about MAXLOGNAME increase. --4492t87HU5WhnhG2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCilJ4ACgkQC3+MBN1Mb4g8KQCgpKFBI1aDj66heZCccnJhAv2k 5psAn0UdAUPQ17WZlXm6GfrViYD5NcES =blfj -----END PGP SIGNATURE----- --4492t87HU5WhnhG2-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 13 18:45:20 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4EE6EBF8; Tue, 13 Nov 2012 18:45:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 99A9D8FC12; Tue, 13 Nov 2012 18:45:19 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qADIjCxe089802; Tue, 13 Nov 2012 20:45:12 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qADIjCxe089802 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qADIjCPN089797; Tue, 13 Nov 2012 20:45:12 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 13 Nov 2012 20:45:12 +0200 From: Konstantin Belousov To: Baptiste Daroussin Subject: Re: Increasing MAXLOGNAME from 17 to 33 Message-ID: <20121113184512.GP73505@kib.kiev.ua> References: <20121113111806.GE62533@ithaqua.etoilebsd.net> <20121113115034.GJ73505@kib.kiev.ua> <20121113183412.GA75103@ithaqua.etoilebsd.net> <20121113184238.GO73505@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XfTwdTn5e7P36tOV" Content-Disposition: inline In-Reply-To: <20121113184238.GO73505@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 18:45:20 -0000 --XfTwdTn5e7P36tOV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2012 at 08:42:38PM +0200, Konstantin Belousov wrote: > On Tue, Nov 13, 2012 at 07:34:12PM +0100, Baptiste Daroussin wrote: > > On Tue, Nov 13, 2012 at 01:50:34PM +0200, Konstantin Belousov wrote: > > > On Tue, Nov 13, 2012 at 12:18:06PM +0100, Baptiste Daroussin wrote: > > > > Hi, > > > >=20 > > > > I want to increase MAXLOGNAME in sys/param.h from 17 to 33 to allow= 32-character > > > > long usernames, the PR: misc/161091 and misc/133926 already request= ed for it. > > > >=20 > > > > utmpx already allow 32 character long user names. > > > >=20 > > > > I plan to bump the __FreeBSD_version at the same time because of th= e ABI > > > > breakage. > > > >=20 > > > > This is simplify life of lots administrator, this value, is a commo= n value for > > > > other operating systems. > > > >=20 > > > > Do anyone have objections about it? > > >=20 > > > Yes, I have. Do not break the ABI, it is plain prohibited. > > > You might consider increasing the constant only if providing ABI > > > compatibility shims. > > >=20 > > > In fact, the cursory look over the whole base system indicates that A= BI > > > breakage might be not that big and could be mitigated with relatively > > > limited amount of the efforts. > >=20 > > Thanks cognet for the help on the following. > >=20 > > After auditing base, it seems like this patch is enough > > http://people.freebsd.org/~bapt/maxlogname-33.diff > Regarding the patch, the dereferencing of p->p_session should be done > under the proc lock to guarantee stability of p_pgrp, and under session > mutex to prevent s_login modifications. Altogether, this means that the > if() shall be moved down right before bcopy and locks unlocked on return. >=20 Sorry, sent the reply too early. The alternative is to check for the length of the local 'login' variable after unlocks, right before copyout. > >=20 > > The users of MAXLOGNAME in base are: > > bin/ps/ps.c > > kerberos5/lib/libgssapi_krb5/pname_to_uid.c > > lib/libc/posix1e/acl_to_text.c > > lib/libc/gen/getpwent.c > > lib/libc/gen/sysconf.c > > lib/libfetch/ftp.c > > lib/libc/gen/getlogin.c > > libexec/ftpd/ftpd.c > > libexec/atrun/atrun.c > > libexec/lukemftpd/nbsd2fbsd.h > > libexec/getty/main.c > > sys/sys/loginclass.h > > sys/sys/proc.h > > sys/kern/kern_prot.c > > sys/security/audit/audit_private.h > > sys/security/audit/audit_arg.c > > usr.bin/id/id.c > > usr.bin/at/at.c > > usr.bin/finger/sprint.c > > usr.bin/su/su.c > > usr.bin/find/ls.c > > usr.bin/login/login.c > > usr.bin/lastcomm/lastcomm.c > > usr.sbin/edquota/edquota.c > > usr.sbin/pwd_mkdb/pwd_mkdb.c > > usr.sbin/syslogd/syslogd.c > > usr.sbin/repquota/Repquota.c > > usr.sbin/sa/usrdb.c > > usr.sbin/pw/pwupd.c > > usr.sbin/pw/grupd.c > > usr.sbin/pw/pw_user.c > > usr.sbin/inetd/builtins.c > >=20 > > The way they use it is ok, I don't see any problem with them. > > We also checked usage of LOGIN_NAME_MAX _SC_LOGIN_NAME_MAX and nothing = in base > > seems problematic at this point. > >=20 > > last getlogin(2) is always used in base, I saw no direct usage of _getl= ogin, and > > getlogin(2) correctly check the return value of _getlogin > >=20 > > Last this patch makes getlogin(2) return the ERANGE error as it should = be > > according to its manpage? > I do not quite understand the sentences. >=20 > >=20 > > Is there anything that have been missed there? > Well, if the full audit of the base was performed and no issues are > indeed found, this should be fine. >=20 > I suggest to commit the fixed ERANGE patch separately. It definitely shall > be merged, not sure about MAXLOGNAME increase. --XfTwdTn5e7P36tOV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCilTcACgkQC3+MBN1Mb4iOxACfd7xUkDg++oVpMyuHm9e16onI 2WgAoLzXBlbXJnH9OZctTWjQ9i9/SmNK =7XyR -----END PGP SIGNATURE----- --XfTwdTn5e7P36tOV-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 13 19:31:54 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3E7DF11; Tue, 13 Nov 2012 19:31:54 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id A133D8FC16; Tue, 13 Nov 2012 19:31:54 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-149-146.hsd1.ca.comcast.net [50.143.149.146]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id qADJVqHp001982 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 13 Nov 2012 11:31:53 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <50A2A023.6060903@freebsd.org> Date: Tue, 13 Nov 2012 11:31:47 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Increasing MAXLOGNAME from 17 to 33 References: <20121113111806.GE62533@ithaqua.etoilebsd.net> <20121113115034.GJ73505@kib.kiev.ua> In-Reply-To: <20121113115034.GJ73505@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Baptiste Daroussin X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 19:31:55 -0000 On 11/13/12 3:50 AM, Konstantin Belousov wrote: > On Tue, Nov 13, 2012 at 12:18:06PM +0100, Baptiste Daroussin wrote: >> Hi, >> >> I want to increase MAXLOGNAME in sys/param.h from 17 to 33 to allow 32-character >> long usernames, the PR: misc/161091 and misc/133926 already requested for it. >> >> utmpx already allow 32 character long user names. >> >> I plan to bump the __FreeBSD_version at the same time because of the ABI >> breakage. >> >> This is simplify life of lots administrator, this value, is a common value for >> other operating systems. >> >> Do anyone have objections about it? > Yes, I have. Do not break the ABI, it is plain prohibited. > You might consider increasing the constant only if providing ABI > compatibility shims. > > In fact, the cursory look over the whole base system indicates that ABI > breakage might be not that big and could be mitigated with relatively > limited amount of the efforts. we did this in 1996 at Whistle/IBM and saw no problems. it really is needed when you realise that Apple an Microsoft have much longer names and that we need to worry more about them than old FreeBSD I think. From owner-freebsd-arch@FreeBSD.ORG Tue Nov 13 19:46:12 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2CDB351 for ; Tue, 13 Nov 2012 19:46:12 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 277158FC14 for ; Tue, 13 Nov 2012 19:46:11 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so2679058lbb.13 for ; Tue, 13 Nov 2012 11:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FeV55i27cAnUapNuu97uL63MrIJimePMl1n2FcMbfP4=; b=OEnwP4G1yBkqmsX1V2BIYoO/iM5bKUXCqxRJwcjJt0L4A2ZV+mjmHf+VP4MUAft1KK SaYm2/JVQTSaFfCfmtN1tlqbkfsn6rhoO9X9RzV20NcJdBHbOVqrdtQ+0dcWE3ge+yTc 3Rlvu95qNnPQQkq37TIL0RfJgfff9fWlGpw08= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=FeV55i27cAnUapNuu97uL63MrIJimePMl1n2FcMbfP4=; b=KFnFOCNIS+9DO68SSU4M3tRy4CdG3CiCmFx2fwLyD7MhfQRz4W2KBLbTTKJjsPNYde bjKMQFQNRgcak3+6hgo9Gq+asvCHFh+/xxuRhAcYJerwaLh0O5hSQG50UD+uqWSNl97g 1VcN6BBoduIWQKL5H4wWGuTLWB7CH1T7EdUnl2hoLMqwM6cKGBWlpBv7jsqc5OYMS6Po 18eTFcuhe4DUp+SflJ663Z9rjUNMvfc8wJcPpfRq1OEN3XCU8cb6IZdW3s9hxm0v2Pns AvzaeqL9vDwtPn2XzQl5ruYaO1g5+OQivrY+xCbeG2Lj2/zbCIDFwJw/rXXUDLn45biI n4sQ== Received: by 10.112.85.199 with SMTP id j7mr9708238lbz.69.1352835971034; Tue, 13 Nov 2012 11:46:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.25.166 with HTTP; Tue, 13 Nov 2012 11:45:40 -0800 (PST) In-Reply-To: <20121113183412.GA75103@ithaqua.etoilebsd.net> References: <20121113111806.GE62533@ithaqua.etoilebsd.net> <20121113115034.GJ73505@kib.kiev.ua> <20121113183412.GA75103@ithaqua.etoilebsd.net> From: Eitan Adler Date: Tue, 13 Nov 2012 14:45:40 -0500 Message-ID: Subject: Re: Increasing MAXLOGNAME from 17 to 33 To: Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnnjtmnfZcDDU4W2OvJwRfq74cGZb9CJ13PGMrvw9t7GsSHUrVkUfhMF7W70y5XbG2C3AR5 Cc: Konstantin Belousov , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 19:46:12 -0000 On 13 November 2012 13:34, Baptiste Daroussin wrote: > On Tue, Nov 13, 2012 at 01:50:34PM +0200, Konstantin Belousov wrote: > > After auditing base, it seems like this patch is enough > http://people.freebsd.org/~bapt/maxlogname-33.diff I'm not sure, but doesn't access to p->p_session need to be under a lock? Something like (although the duplicate unlocking code is annoying): diff --git a/sys/kern/kern_prot.c b/sys/kern/kern_prot.c index 53af793..8a97994 100644 --- a/sys/kern/kern_prot.c +++ b/sys/kern/kern_prot.c @@ -2081,6 +2081,11 @@ sys_getlogin(struct thread *td, struct getlogin_args *uap) uap->namelen = MAXLOGNAME; PROC_LOCK(p); SESS_LOCK(p->p_session); + if (strlen(p->p_session->s_login) + 1 > uap->namelen) { + SESS_UNLOCK(p->p_session); + PROC_UNLOCK(p); + return (ERANGE); + } bcopy(p->p_session->s_login, login, uap->namelen); SESS_UNLOCK(p->p_session); PROC_UNLOCK(p); -- Eitan Adler From owner-freebsd-arch@FreeBSD.ORG Tue Nov 13 22:59:09 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35142D14 for ; Tue, 13 Nov 2012 22:59:09 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0BB828FC13; Tue, 13 Nov 2012 22:59:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qADMx8Zo046191; Tue, 13 Nov 2012 22:59:08 GMT (envelope-from bapt@freebsd.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qADMx8gC046190; Tue, 13 Nov 2012 22:59:08 GMT (envelope-from bapt@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@freebsd.org using -f Date: Tue, 13 Nov 2012 23:59:05 +0100 From: Baptiste Daroussin To: Konstantin Belousov Subject: Re: Increasing MAXLOGNAME from 17 to 33 Message-ID: <20121113225905.GB75103@ithaqua.etoilebsd.net> References: <20121113111806.GE62533@ithaqua.etoilebsd.net> <20121113115034.GJ73505@kib.kiev.ua> <20121113183412.GA75103@ithaqua.etoilebsd.net> <20121113184238.GO73505@kib.kiev.ua> <20121113184512.GP73505@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oLBj+sq0vYjzfsbl" Content-Disposition: inline In-Reply-To: <20121113184512.GP73505@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 22:59:09 -0000 --oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2012 at 08:45:12PM +0200, Konstantin Belousov wrote: > On Tue, Nov 13, 2012 at 08:42:38PM +0200, Konstantin Belousov wrote: > > On Tue, Nov 13, 2012 at 07:34:12PM +0100, Baptiste Daroussin wrote: > > > On Tue, Nov 13, 2012 at 01:50:34PM +0200, Konstantin Belousov wrote: > > > > On Tue, Nov 13, 2012 at 12:18:06PM +0100, Baptiste Daroussin wrote: > > > > > Hi, > > > > >=20 > > > > > I want to increase MAXLOGNAME in sys/param.h from 17 to 33 to all= ow 32-character > > > > > long usernames, the PR: misc/161091 and misc/133926 already reque= sted for it. > > > > >=20 > > > > > utmpx already allow 32 character long user names. > > > > >=20 > > > > > I plan to bump the __FreeBSD_version at the same time because of = the ABI > > > > > breakage. > > > > >=20 > > > > > This is simplify life of lots administrator, this value, is a com= mon value for > > > > > other operating systems. > > > > >=20 > > > > > Do anyone have objections about it? > > > >=20 > > > > Yes, I have. Do not break the ABI, it is plain prohibited. > > > > You might consider increasing the constant only if providing ABI > > > > compatibility shims. > > > >=20 > > > > In fact, the cursory look over the whole base system indicates that= ABI > > > > breakage might be not that big and could be mitigated with relative= ly > > > > limited amount of the efforts. > > >=20 > > > Thanks cognet for the help on the following. > > >=20 > > > After auditing base, it seems like this patch is enough > > > http://people.freebsd.org/~bapt/maxlogname-33.diff > > Regarding the patch, the dereferencing of p->p_session should be done > > under the proc lock to guarantee stability of p_pgrp, and under session > > mutex to prevent s_login modifications. Altogether, this means that the > > if() shall be moved down right before bcopy and locks unlocked on retur= n. > >=20 > Sorry, sent the reply too early. >=20 > The alternative is to check for the length of the local 'login' variable > after unlocks, right before copyout. >=20 like this? http://people.freebsd.org/~bapt/report-erange-if-login-is-larger-then-MAXLO= GNAME.diff regards, Bapt --oLBj+sq0vYjzfsbl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCi0LkACgkQ8kTtMUmk6EyRvwCfVWXqMEZStUMu5yDXDEyDDf1E vjEAn1f49XyyQ18vXqmp5pzSI8ILaLY9 =Sksf -----END PGP SIGNATURE----- --oLBj+sq0vYjzfsbl-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 13 23:04:39 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0343F22 for ; Tue, 13 Nov 2012 23:04:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 966288FC08 for ; Tue, 13 Nov 2012 23:04:38 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so2547719obc.13 for ; Tue, 13 Nov 2012 15:04:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Oux6nAlF5foPj60PUMKaaH+yMgH/hgMnbHhsE3PUWQI=; b=kTWUuNoOlWoGR6lahhuVlF0BnNJk6P6LEDqa08p3G0nTSv35R+Br4RTK3sOCN6i0s8 968IT7tMcCCqp1NnXfKdfFkOtfFq8b2sFSNkcNmaDuZsMc9NkMeH4dh0kHBoIwBLeokP 7g/jSR/h5kxhTlaJaFBgi8UJK2yPc7I1Wx758+WRV31vvpIp2xkZqjUr2luMzYLXquyu y1DCJHQAEqgUFbEW1cRyRQQUCL5ak0BL7CBBmJ3mV5g32cOXLC2qd6cxsE6twZM8dApJ L1KthRkUimM3Y4hJh4gOlJLG9dRXFIUSj4UPO+UktnTlhqrlfzZzXhCFU6RDDGyfZIDm ZL8Q== Received: by 10.60.4.136 with SMTP id k8mr18805056oek.94.1352847877685; Tue, 13 Nov 2012 15:04:37 -0800 (PST) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id c18sm11263923obc.17.2012.11.13.15.04.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Nov 2012 15:04:35 -0800 (PST) Sender: Warner Losh Subject: Re: Increasing MAXLOGNAME from 17 to 33 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20121113225905.GB75103@ithaqua.etoilebsd.net> Date: Tue, 13 Nov 2012 16:04:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <75177878-EA36-4472-BAEA-984A59F91057@bsdimp.com> References: <20121113111806.GE62533@ithaqua.etoilebsd.net> <20121113115034.GJ73505@kib.kiev.ua> <20121113183412.GA75103@ithaqua.etoilebsd.net> <20121113184238.GO73505@kib.kiev.ua> <20121113184512.GP73505@kib.kiev.ua> <20121113225905.GB75103@ithaqua.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQl3qbZfe+y1o+7frU7uC/dGxMYKrYBjk3SOhiZo/JNAscBO5NzbQKlEw/mF4ojki0smu+UU Cc: Konstantin Belousov , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:04:39 -0000 On Nov 13, 2012, at 3:59 PM, Baptiste Daroussin wrote: > On Tue, Nov 13, 2012 at 08:45:12PM +0200, Konstantin Belousov wrote: >> On Tue, Nov 13, 2012 at 08:42:38PM +0200, Konstantin Belousov wrote: >>> On Tue, Nov 13, 2012 at 07:34:12PM +0100, Baptiste Daroussin wrote: >>>> On Tue, Nov 13, 2012 at 01:50:34PM +0200, Konstantin Belousov = wrote: >>>>> On Tue, Nov 13, 2012 at 12:18:06PM +0100, Baptiste Daroussin = wrote: >>>>>> Hi, >>>>>>=20 >>>>>> I want to increase MAXLOGNAME in sys/param.h from 17 to 33 to = allow 32-character >>>>>> long usernames, the PR: misc/161091 and misc/133926 already = requested for it. >>>>>>=20 >>>>>> utmpx already allow 32 character long user names. >>>>>>=20 >>>>>> I plan to bump the __FreeBSD_version at the same time because of = the ABI >>>>>> breakage. >>>>>>=20 >>>>>> This is simplify life of lots administrator, this value, is a = common value for >>>>>> other operating systems. >>>>>>=20 >>>>>> Do anyone have objections about it? >>>>>=20 >>>>> Yes, I have. Do not break the ABI, it is plain prohibited. >>>>> You might consider increasing the constant only if providing ABI >>>>> compatibility shims. >>>>>=20 >>>>> In fact, the cursory look over the whole base system indicates = that ABI >>>>> breakage might be not that big and could be mitigated with = relatively >>>>> limited amount of the efforts. >>>>=20 >>>> Thanks cognet for the help on the following. >>>>=20 >>>> After auditing base, it seems like this patch is enough >>>> http://people.freebsd.org/~bapt/maxlogname-33.diff >>> Regarding the patch, the dereferencing of p->p_session should be = done >>> under the proc lock to guarantee stability of p_pgrp, and under = session >>> mutex to prevent s_login modifications. Altogether, this means that = the >>> if() shall be moved down right before bcopy and locks unlocked on = return. >>>=20 >> Sorry, sent the reply too early. >>=20 >> The alternative is to check for the length of the local 'login' = variable >> after unlocks, right before copyout. >>=20 > like this? > = http://people.freebsd.org/~bapt/report-erange-if-login-is-larger-then-MAXL= OGNAME.diff Isn't that check too late? Warner= From owner-freebsd-arch@FreeBSD.ORG Wed Nov 14 05:00:54 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 499F12AA for ; Wed, 14 Nov 2012 05:00:54 +0000 (UTC) (envelope-from 3hCWjUAoGDOUOfbU-fVbUNXX.JVTMYLLIZK-HYJOMYLLIZK.VYN@photos-server.bounces.google.com) Received: from mail-ob0-f202.google.com (mail-ob0-f202.google.com [209.85.214.202]) by mx1.freebsd.org (Postfix) with ESMTP id DE7208FC22 for ; Wed, 14 Nov 2012 05:00:53 +0000 (UTC) Received: by mail-ob0-f202.google.com with SMTP id tb18so11259obb.1 for ; Tue, 13 Nov 2012 21:00:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.130.199 with SMTP id hn7mt12380350icc.24.1352869252568; Tue, 13 Nov 2012 21:00:52 -0800 (PST) Message-ID: <20cf307f3b003a172004ce6d6b67@google.com> Date: Wed, 14 Nov 2012 05:00:52 +0000 Subject: freight forwarder & logistics provider shared photos with you From: "freight forwarder & logistics provider" To: freebsd-arch@freebsd.org Content-Type: multipart/mixed; boundary=20cf307f3b003afc4704ce6d6b87 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: freight forwarder & logistics provider List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 05:00:54 -0000 --20cf307f3b003afc4704ce6d6b87 Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Content-Transfer-Encoding: base64 RGVhciBNeSBGcmllbmQNCg0KICAgICAgICAgTmljZSBkYXksIEh5dW4gWW91bmcgaXMgYSBsZWFk aW5nIHByb2Zlc3Npb25hbCBmcmVpZ2h0IGZvcndhcmRlciAgDQphbmQgbG9naXN0aWNzIHByb3Zp ZGVyIHdobyBmb2N1cyBvbiB0aGUgc2hpcG1lbnQgZnJvbSBTb3V0aCBDaGluYSB0byBhbGwgIA0K dGhlIHdvcmxkLiBIeXVuIFlvdW5nIHN0YXJ0ZWQgZnJlaWdodCBmb3J3YXJkaW5nIG9wZXJhdGlv biBhdCBTaGVuemhlbiBpbiAgDQoyMDA0LiBCYXNlZCBhdCBTaGVuemhlbiwgb3VyIGFtYml0aW9u IGhhdmUgcHVzaGVkIHVzIGZvcndhcmQgdG8gZXhwYW5kIHRvICANCm90aGVyIGNpdGllcyBpbiBz b3V0aCBvZiBDaGluYS4gTm93IHdlIGhhdmUgY2FwYWNpdHkgb2YgaGFuZGluZyBzaGlwbWVudCB0 byAgDQpvciBmcm9tIGFsbCB0aGUgcG9ydHMgaW4gc291dGggb2YgQ2hpbmEuDQogICAgICAgICAg IEhvbGRzIHdoaWxlIHdob2xlIC0gaGVhcnRlZGx5IGFjaGlldmVzIHRoZSBiZXN0IGVudGVycHJp c2UgIA0Kb2JqZWN0aXZlLCBXaXRoIHRoZSBncmVhdCBzdXBwb3J0IG9mIG91ciBnbG9iYWwgYWdl bmN5LCB3ZSBwcm92aWRlIHNlcnZpY2VzICANCnRvIG91ciBjdXN0b21lcnMgdGhyb3VnaCBwcm9j ZXNzLWRyaXZlbiBvcGVyYXRpb24gdGVhbSwgYWR2YW5jZWQgIA0KaW5mb3JtYXRpb24gc3lzdGVt LCBhbmQgc3Ryb25nIG1hbmFnZW1lbnQgdGVhbS4NCg0KR2xhbmNlIHRvIG91ciBjb21wYW55Og0K MS4JU2VhIEZyZWlnaHQsIGluY2x1ZGVkIEZDTCZMQ0w7DQoyLglBaXIgRnJlaWdodDsNCjMuCUV4 cHJlc3MsIGluY2x1ZGVkIERITCxVUFMsRkVERVgsU0FHQVdBIGFuZCBTQ09SRUpQOw0KNC4JSW1w b3J0ICYgRXhwb3J0Ow0KNS4JTGFuZCBUcmFuc3BvcnRhdGlvbi4NCg0KICAgICAgICAgICBXZSBz ZWVrIG5vIHN0cm9uZ2VzdCBvbmx5IG1vcmUgc3BlY2lhbGl6ZWQsIHNlbmlvci4gWW91ciAgDQpz YXRpc2ZpZWQgd2lsbCBiZSBvdXIgbWF4aW1hbCBwcmlkZS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KU2hlbnpoZW4gSHl1biBZb3VuZyBJbnRlcm5hdGlvbmFsIFRyYW5zcG9ydGF0aW9uIENPLixM VEQNCkphY2t5IFlhbmcNCg0KQWRkOiBGbG9vciA3JjgsIFNvdXRoIEJhb5JhbiBSb2FkLCBMdW9o dSBEaXN0cmljdCwgU2hlbnpoZW4sIEd1YW5nZG9uZywgIA0KQ2hpbmEuDQo= --20cf307f3b003afc4704ce6d6b87-- From owner-freebsd-arch@FreeBSD.ORG Wed Nov 14 05:45:34 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1560DCB; Wed, 14 Nov 2012 05:45:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 87CB08FC08; Wed, 14 Nov 2012 05:45:33 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qAE5jNuq060086; Wed, 14 Nov 2012 07:45:23 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qAE5jNuq060086 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qAE5jN1k060085; Wed, 14 Nov 2012 07:45:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 14 Nov 2012 07:45:23 +0200 From: Konstantin Belousov To: Warner Losh Subject: Re: Increasing MAXLOGNAME from 17 to 33 Message-ID: <20121114054523.GU73505@kib.kiev.ua> References: <20121113111806.GE62533@ithaqua.etoilebsd.net> <20121113115034.GJ73505@kib.kiev.ua> <20121113183412.GA75103@ithaqua.etoilebsd.net> <20121113184238.GO73505@kib.kiev.ua> <20121113184512.GP73505@kib.kiev.ua> <20121113225905.GB75103@ithaqua.etoilebsd.net> <75177878-EA36-4472-BAEA-984A59F91057@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QJR8KKzOCBB+4dVz" Content-Disposition: inline In-Reply-To: <75177878-EA36-4472-BAEA-984A59F91057@bsdimp.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org, Baptiste Daroussin X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 05:45:34 -0000 --QJR8KKzOCBB+4dVz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2012 at 04:04:33PM -0700, Warner Losh wrote: >=20 > On Nov 13, 2012, at 3:59 PM, Baptiste Daroussin wrote: >=20 > > On Tue, Nov 13, 2012 at 08:45:12PM +0200, Konstantin Belousov wrote: > >> On Tue, Nov 13, 2012 at 08:42:38PM +0200, Konstantin Belousov wrote: > >>> On Tue, Nov 13, 2012 at 07:34:12PM +0100, Baptiste Daroussin wrote: > >>>> On Tue, Nov 13, 2012 at 01:50:34PM +0200, Konstantin Belousov wrote: > >>>>> On Tue, Nov 13, 2012 at 12:18:06PM +0100, Baptiste Daroussin wrote: > >>>>>> Hi, > >>>>>>=20 > >>>>>> I want to increase MAXLOGNAME in sys/param.h from 17 to 33 to allo= w 32-character > >>>>>> long usernames, the PR: misc/161091 and misc/133926 already reques= ted for it. > >>>>>>=20 > >>>>>> utmpx already allow 32 character long user names. > >>>>>>=20 > >>>>>> I plan to bump the __FreeBSD_version at the same time because of t= he ABI > >>>>>> breakage. > >>>>>>=20 > >>>>>> This is simplify life of lots administrator, this value, is a comm= on value for > >>>>>> other operating systems. > >>>>>>=20 > >>>>>> Do anyone have objections about it? > >>>>>=20 > >>>>> Yes, I have. Do not break the ABI, it is plain prohibited. > >>>>> You might consider increasing the constant only if providing ABI > >>>>> compatibility shims. > >>>>>=20 > >>>>> In fact, the cursory look over the whole base system indicates that= ABI > >>>>> breakage might be not that big and could be mitigated with relative= ly > >>>>> limited amount of the efforts. > >>>>=20 > >>>> Thanks cognet for the help on the following. > >>>>=20 > >>>> After auditing base, it seems like this patch is enough > >>>> http://people.freebsd.org/~bapt/maxlogname-33.diff > >>> Regarding the patch, the dereferencing of p->p_session should be done > >>> under the proc lock to guarantee stability of p_pgrp, and under sessi= on > >>> mutex to prevent s_login modifications. Altogether, this means that t= he > >>> if() shall be moved down right before bcopy and locks unlocked on ret= urn. > >>>=20 > >> Sorry, sent the reply too early. > >>=20 > >> The alternative is to check for the length of the local 'login' variab= le > >> after unlocks, right before copyout. > >>=20 > > like this? > > http://people.freebsd.org/~bapt/report-erange-if-login-is-larger-then-M= AXLOGNAME.diff >=20 > Isn't that check too late? >=20 No, it is not, The uap->namelen is clamped before the block shown in the patch. I think that the patch is fine and should be merged into stable branches as well. While there, you could add a space between 'return' and '(' in the last line of the sys_getlogin(), in separate commit. Thanks. --QJR8KKzOCBB+4dVz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEUEARECAAYFAlCjL/MACgkQC3+MBN1Mb4jsuwCfbB3jKttSWxgygkBP/zLgaxJO s5EAmIZmvAqICNYDa/xakg5L29cO9Cc= =V9cY -----END PGP SIGNATURE----- --QJR8KKzOCBB+4dVz-- From owner-freebsd-arch@FreeBSD.ORG Wed Nov 14 09:28:11 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB22FE03; Wed, 14 Nov 2012 09:28:11 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5932F8FC15; Wed, 14 Nov 2012 09:28:11 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so243983obc.13 for ; Wed, 14 Nov 2012 01:28:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=cBf4a/ykEX9zxKVI3Hkf6tDXQ9jWfOajAZT2AAIArqo=; b=rECjtoteGzTdLb2ip3G1YGPXSHniP44sQffreHPDMCcvwzdDXaHv6pj9zRbEGyzS+k T4Kj+CX0jg/9U0bJv1WiTnFPpN6jmXfwhTU7cIpr7ztY2vHksxq9w5JUrvGZGObLxCJ4 VMGnF6U6dPHiBN/sOa0rAi0uAzjqvUO5XIVCw/ySJnUqD3IoO78hc/vWSQ/YwHKtM/B6 Jf7GTdj5d8S0gfQBdp1xYm8M32KALHuIr37fjU0ed5SRp3HEEvLox0+TpVuMtEuNwRdT X0Cd7OVhIQVqOYLwiWLO5dpprYhUFEllZASPCMLhd/jndo9HE1I+o3aDXf+14WArB0hH 4LIQ== MIME-Version: 1.0 Received: by 10.182.131.100 with SMTP id ol4mr20286539obb.38.1352885284895; Wed, 14 Nov 2012 01:28:04 -0800 (PST) Received: by 10.76.143.33 with HTTP; Wed, 14 Nov 2012 01:28:04 -0800 (PST) Date: Wed, 14 Nov 2012 01:28:04 -0800 Message-ID: Subject: [RFC] test layout/standardization for FreeBSD From: Garrett Cooper To: "freebsd-arch@FreeBSD.org Arch" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: George Neville-Neil , Marcel Moolenaar , Matthew Fleming X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:28:12 -0000 As David O'Brien noted at the BSD Vendor Support, some of the requirements for standardizing the test process and layout in FreeBSD aren't clear today. I asked for feedback from some of the stakeholders of the FreeBSD test automation effort (gnn, marcel, mdf, sjg) I've been working with, and here is a summary of the agreed upon method for organizing tests in FreeBSD. Please provide constructive criticism, feel free to ask questions, etc if any of the points below could be clarified/improved upon; items 1. and 3. are straightforward, but item 2. is still up to some debate, in particular item 2.i and 2.iii. The agreed upon items will be added to the wiki (http://wiki.freebsd.org/TestingFreeBSD ). Thanks! -Garrett 1. Userland tests: - Tests will go into a tests/ subdirectory, e.g. for source directory lib/libc/, there will be a tests directory lib/libc/tests/; for bin/date, there will be a tests directory bin/date/tests/. 2. Kernel tests: i. The user will be able to invoke buildkernel -DWITH_TESTS build all applicable testcases and install them into ${TESTSBASE}/sys/... . ii. Generic kernel tests will go into tests/sys/ and will be included in the standard build process. Example: sys/tests/capsicum/... sys/tests/kern/acct/... sys/tests/kern/read/... sys/tests/kern/write/... iii. Driver specific testcases should live close to the source, e.g. mps(4) testcases should live in sys/dev/mps/tests/, and mps(4) unittest programs/modules should be compiled/linked as part of the standard module build process. Moreover the build logic should live under sys/modules/mps/tests/ [*]. The install path is vendor/developer specific, but should be ${TESTSBASE}/sys/${DEV}/ in order to match FreeBSD's layout. This will require another minor piece of build infrastructure (kern.test.mk) in order to ensure proper versioning, and I will work on drafting up that next item if it's agreed that this is the correct direction for standardizing driver testcases. 3. Jumping into tests/ subdirectories should be handled transparently via bsd.subdir.mk like so: diff --git a/share/mk/bsd.subdir.mk b/share/mk/bsd.subdir.mk index 38a9080..a0e9984 100644 --- a/share/mk/bsd.subdir.mk +++ b/share/mk/bsd.subdir.mk @@ -43,6 +43,11 @@ distribute: .endfor .endif +.if ${MK_TESTS} != "no" && exists(${.CURDIR}/tests/Makefile) +SUBDIR+= tests +SUBDIR_TARGETS+= test +.endif + _SUBDIR: .USE .if defined(SUBDIR) && !empty(SUBDIR) && !defined(NO_SUBDIR) @${_+_}set -e; for entry in ${SUBDIR}; do \ This will require adding an additional knob (MK_TESTS) to bsd.own.mk. [*] How we run and handle driver-specific kernel testcases is outside the scope of this note as we do not have the full NetBSD testing infrastructure (RUMP, et all) to commit to a full-scale plan [yet]. This needs to be worked out sometime in the next 1~2 years and/or should done as a GSoC project. From owner-freebsd-arch@FreeBSD.ORG Wed Nov 14 09:43:09 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 627126E9; Wed, 14 Nov 2012 09:43:09 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 124E18FC15; Wed, 14 Nov 2012 09:43:08 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id F40BB8A412; Wed, 14 Nov 2012 09:43:01 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id qAE9h10L007100; Wed, 14 Nov 2012 09:43:01 GMT (envelope-from phk@phk.freebsd.dk) To: Garrett Cooper Subject: Re: [RFC] test layout/standardization for FreeBSD In-reply-to: From: "Poul-Henning Kamp" References: Date: Wed, 14 Nov 2012 09:43:01 +0000 Message-ID: <7099.1352886181@critter.freebsd.dk> Cc: George Neville-Neil , Marcel Moolenaar , Matthew Fleming , "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:43:09 -0000 -------- In message , Garrett Cooper writes: >I asked for feedback from some of the stakeholders of >the FreeBSD test automation effort [...] Can I throw in something here ? A very important thing is to have systematic metadata about test-cases, in particular: A) Is the test 100% deterministic, or is there a risk of random failure ? B) Is the test reliable on a heavily loaded machine ? C) Estimated duration of test etc. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Nov 14 10:09:59 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C8D1D10; Wed, 14 Nov 2012 10:09:59 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id AD92B8FC13; Wed, 14 Nov 2012 10:09:58 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so270001oag.13 for ; Wed, 14 Nov 2012 02:09:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C7ElJ5eNl1knoT5lEASi6Om+WBT8CwAZAKFJ7Q7YqSE=; b=v5Nf36WN50mRFZ9Z36UhNlTddGmZXfyj57Mhkgob3rwedOeQk6oltds6zD0fHgccTk HIqCGWCiMmZ09eypyPyvpspU9DmxluvqFBsKJFYkH04nHhlS9gl04TPFLzRnBSRJBwKB Rfh5q7h3FDTs4mlkYTe1QDXPibNkPom1SkQeibxX7LNKMO49dsSiZPd2UtIn8iFfWwgf fPcdseCoBOrxyw8bbBacazpP/G1oohCUIl97+sM7gSSLjT8+iXEc62SiBQydHmhkg0i9 /VY9g0+CKNBCsFzP0kY7UhJTvyY8n3Co56JZycaezMznIFsqD6XdugCwkfRlA63UmzVH Nt0A== MIME-Version: 1.0 Received: by 10.60.170.114 with SMTP id al18mr20166671oec.56.1352887797940; Wed, 14 Nov 2012 02:09:57 -0800 (PST) Received: by 10.76.143.33 with HTTP; Wed, 14 Nov 2012 02:09:57 -0800 (PST) In-Reply-To: <7099.1352886181@critter.freebsd.dk> References: <7099.1352886181@critter.freebsd.dk> Date: Wed, 14 Nov 2012 02:09:57 -0800 Message-ID: Subject: Re: [RFC] test layout/standardization for FreeBSD From: Garrett Cooper To: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: George Neville-Neil , Marcel Moolenaar , Matthew Fleming , "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 10:09:59 -0000 On Wed, Nov 14, 2012 at 1:43 AM, Poul-Henning Kamp wrote: > -------- > In message 40RE3j0na4B6-VhZFwhMdkw-6CYhoxKKHumg@mail.gmail.com> > , Garrett Cooper writes: > > >I asked for feedback from some of the stakeholders of > >the FreeBSD test automation effort [...] > > Can I throw in something here ? > > A very important thing is to have systematic metadata about test-cases, > in particular: > > A) Is the test 100% deterministic, or is there a risk of random failure ? > > B) Is the test reliable on a heavily loaded machine ? > > C) Estimated duration of test > > etc. > - These are important points and to be clear based on discussion prior to and up to the vendor summit, the goal was to provide deterministic unittests for the first prototype (which covers point A and implicitly point B); the goal from an end-user perspective as to how they would be affected today is that unless make test[kernel,world] was actually called, it would just built and install the tests as necessary - Point C cannot be accurately answered as it depends on what tests are are in a tree, run via `make test[kernel,world]`, etc. (going into B) further) Other items such as fault tolerance, stress, etc need to be worked into the overall test ecosystem of FreeBSD (I recognize the need for integrating pho's stress2 project into FreeBSD proper so it's run on a regular basis, the need for adding to stress2, etc), but it wasn't in the scope of the initial work being done for the ATF FreeBSD port / in the short to medium term for test automation on FreeBSD and as such hasn't been planned in the overall "automation roadmap". Going further, as far as items B/C are concerned I would argue that they are highly dependent upon the test matter, how the testcases are implemented, etc. From my perspective the goal is to have (from a functional perspective) simple testcases that exercise functionality to ensure that requirements noted in manpages (because that's the user facing documentation) are adhered to and not regressed, and then move on to other more critical items requiring attention (again, stress, fault tolerance, etc). Less deterministic items need to be factored out of standard runs and/or decorated (like how one can do in python) such that they aren't necessarily executed by default, but rather when explicitly requested, either as individual tests or as a group of tests. As the phrase goes, "Rome wasn't built in a day". Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Wed Nov 14 10:34:14 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2AD3297C; Wed, 14 Nov 2012 10:34:14 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D18E88FC14; Wed, 14 Nov 2012 10:34:13 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 910F88A412; Wed, 14 Nov 2012 10:34:12 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id qAEAYBn6007286; Wed, 14 Nov 2012 10:34:11 GMT (envelope-from phk@phk.freebsd.dk) To: Garrett Cooper Subject: Re: [RFC] test layout/standardization for FreeBSD In-reply-to: From: "Poul-Henning Kamp" References: <7099.1352886181@critter.freebsd.dk> Date: Wed, 14 Nov 2012 10:34:11 +0000 Message-ID: <7285.1352889251@critter.freebsd.dk> Cc: George Neville-Neil , Marcel Moolenaar , Matthew Fleming , "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 10:34:14 -0000 -------- In message , Garrett Cooper writes: >> A very important thing is to have systematic metadata about test-cases, >> in particular: >> >> A) Is the test 100% deterministic, or is there a risk of random failure ? >> >> B) Is the test reliable on a heavily loaded machine ? >> >> C) Estimated duration of test >- These are important points and to be clear based on discussion prior to >and up to the vendor summit, the goal was to provide deterministic >unittests for the first prototype [...] That's very laudable, but deterministic tests are not always possible, and therefore your design should be able to handle non-deterministic tests even if you are going to frown upon them for all eternity. >- Point C cannot be accurately answered as it depends on what tests are are >in a tree, run via `make test[kernel,world]`, etc. Point C is very important, because if you want to leave space for comprehensive tests, you will have tests that take many minutes to execute, and again, you may not like them, but please make space for them in your design. >(going into B) further) Other items such as fault tolerance, stress, etc >need to be worked into the overall test ecosystem of FreeBSD [...] That is not what I'm talking about here, I'm talking about recording for each and every unit-test if it can be expected to work on a system under high load or not. The point I am trying to drive home here, is that a test-case without metadata as to its behaviour is not a good idea. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Nov 14 21:45:12 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA2B979B for ; Wed, 14 Nov 2012 21:45:12 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 6BD368FC0C for ; Wed, 14 Nov 2012 21:45:12 +0000 (UTC) Message-ID: <50A410B5.9070001@FreeBSD.org> Date: Wed, 14 Nov 2012 16:44:21 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121031 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: [RFC] bsd.cpu.mk update for newer processors X-Enigmail-Version: 1.4.5 Content-Type: multipart/mixed; boundary="------------030501020705070507090201" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 21:45:12 -0000 This is a multi-part message in MIME format. --------------030501020705070507090201 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Since we have enabled clang by default on current, I'd like to update bsd.cpu.mk as well. Please see the attachment. It is also available from here: http://people.freebsd.org/~jkim/cpu.diff I only added most popular SIMD features to MACHINE_CPU (i.e., sse4a, sse41, sse42, and avx) and clang-supported archs to CPUTYPE (i.e., amdfam10, btver1, bdver1, bdver2, corei7, corei7-avx, and core-avx-i). Any objection? Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCkELUACgkQmlay1b9qnVPDrQCfSPgrD0TtoTzURBiWXqyBF5Qy cV4AoImF+M42jXpVUyb9jEh8GMPEcoft =oG+P -----END PGP SIGNATURE----- --------------030501020705070507090201 Content-Type: text/plain; charset=UTF-8; name="cpu.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="cpu.diff" SW5kZXg6IHNoYXJlL21rL2JzZC5jcHUubWsKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2hhcmUvbWsv YnNkLmNwdS5tawkocmV2aXNpb24gMjQzMDQyKQorKysgc2hhcmUvbWsvYnNkLmNwdS5tawko d29ya2luZyBjb3B5KQpAQCAtMjcsMTAgKzI3LDEwIEBAIE1BQ0hJTkVfQ1BVID0gbWlwcwog IyBiZXR3ZWVuIGUuZy4gaTU4NiBhbmQgcGVudGl1bSkKIAogLiBpZiAke01BQ0hJTkVfQ1BV QVJDSH0gPT0gImkzODYiCi0uICBpZiAke0NQVVRZUEV9ID09ICJub2NvbmEiCisuICBpZiAk e0NQVVRZUEV9ID09ICJub2NvbmEiIHx8ICR7Q1BVVFlQRX0gPT0gImNvcmUiIHx8IFwKKyAg ICAke0NQVVRZUEV9ID09ICJjb3JlMiIgfHwgJHtDUFVUWVBFfSA9PSAiY29yZWk3IiB8fCBc CisgICAgJHtDUFVUWVBFfSA9PSAiY29yZWk3LWF2eCIgfHwgJHtDUFVUWVBFfSA9PSAiY29y ZS1hdngtaSIKIENQVVRZUEUgPSBwcmVzY290dAotLiAgZWxpZiAke0NQVVRZUEV9ID09ICJj b3JlIgotQ1BVVFlQRSA9IHByZXNjb3R0CiAuICBlbGlmICR7Q1BVVFlQRX0gPT0gInA0Igog Q1BVVFlQRSA9IHBlbnRpdW00CiAuICBlbGlmICR7Q1BVVFlQRX0gPT0gInA0bSIKQEAgLTUw LDEwICs1MCwxMSBAQCBDUFVUWVBFID0gcGVudGl1bS1tbXgKIC4gIGVsaWYgJHtDUFVUWVBF fSA9PSAiaTU4NiIKIENQVVRZUEUgPSBwZW50aXVtCiAuICBlbGlmICR7Q1BVVFlQRX0gPT0g Im9wdGVyb24tc3NlMyIgfHwgJHtDUFVUWVBFfSA9PSAiYXRobG9uNjQtc3NlMyIgfHwgXAot ICAgICAke0NQVVRZUEV9ID09ICJrOC1zc2UzIgorICAgICR7Q1BVVFlQRX0gPT0gIms4LXNz ZTMiIHx8ICR7Q1BVVFlQRX0gPT0gImFtZGZhbTEwIiB8fCBcCisgICAgJHtDUFVUWVBFfSA9 PSAiYnR2ZXIxIiB8fCAke0NQVVRZUEV9ID09ICJiZHZlcjEiIHx8ICR7Q1BVVFlQRX0gPT0g ImJkdmVyMiIKIENQVVRZUEUgPSBwcmVzY290dAogLiAgZWxpZiAke0NQVVRZUEV9ID09ICJv cHRlcm9uIiB8fCAke0NQVVRZUEV9ID09ICJhdGhsb242NCIgfHwgXAotICAgICAke0NQVVRZ UEV9ID09ICJrOCIKKyAgICAke0NQVVRZUEV9ID09ICJrOCIKIENQVVRZUEUgPSBhdGhsb24t bXAKIC4gIGVsaWYgJHtDUFVUWVBFfSA9PSAiazciCiBDUFVUWVBFID0gYXRobG9uCkBAIC0x NDIsNyArMTQzLDE0IEBAIF9DUFVDRkxBR1MgPSAtbWNwdT11bHRyYXNwYXJjMwogIyBwcmVz ZW5jZSBvZiBhIENQVSBmZWF0dXJlLgogCiAuIGlmICR7TUFDSElORV9DUFVBUkNIfSA9PSAi aTM4NiIKLS4gIGlmICR7Q1BVVFlQRX0gPT0gIm9wdGVyb24tc3NlMyIgfHwgJHtDUFVUWVBF fSA9PSAiYXRobG9uNjQtc3NlMyIKKy4gIGlmICR7Q1BVVFlQRX0gPT0gImJkdmVyMSIgfHwg JHtDUFVUWVBFfSA9PSAiYmR2ZXIyIgorTUFDSElORV9DUFUgPSBhdnggc3NlNDIgc3NlNDEg c3NzZTMgc3NlNGEgc3NlMyBzc2UyIHNzZSBtbXggazYgazUgaTU4NiBpNDg2IGkzODYKKy4g IGVsaWYgJHtDUFVUWVBFfSA9PSAiYnR2ZXIxIgorTUFDSElORV9DUFUgPSBzc3NlMyBzc2U0 YSBzc2UzIHNzZTIgc3NlIG1teCBrNiBrNSBpNTg2IGk0ODYgaTM4NgorLiAgZWxpZiAke0NQ VVRZUEV9ID09ICJhbWRmYW0xMCIKK01BQ0hJTkVfQ1BVID0gYXRobG9uLXhwIGF0aGxvbiBr NyAzZG5vdyBzc2U0YSBzc2UzIHNzZTIgc3NlIG1teCBrNiBrNSBpNTg2IFwKKyAgICBpNDg2 IGkzODYKKy4gIGVsaWYgJHtDUFVUWVBFfSA9PSAib3B0ZXJvbi1zc2UzIiB8fCAke0NQVVRZ UEV9ID09ICJhdGhsb242NC1zc2UzIgogTUFDSElORV9DUFUgPSBhdGhsb24teHAgYXRobG9u IGs3IDNkbm93IHNzZTMgc3NlMiBzc2UgbW14IGs2IGs1IGk1ODYgaTQ4NiBpMzg2CiAuICBl bGlmICR7Q1BVVFlQRX0gPT0gIm9wdGVyb24iIHx8ICR7Q1BVVFlQRX0gPT0gImF0aGxvbjY0 IgogTUFDSElORV9DUFUgPSBhdGhsb24teHAgYXRobG9uIGs3IDNkbm93IHNzZTIgc3NlIG1t eCBrNiBrNSBpNTg2IGk0ODYgaTM4NgpAQCAtMTYzLDExICsxNzEsMTYgQEAgTUFDSElORV9D UFUgPSAzZG5vdyBtbXggaTU4NiBpNDg2IGkzODYKIE1BQ0hJTkVfQ1BVID0gc3NlIG1teCBp NTg2IGk0ODYgaTM4NgogLiAgZWxpZiAke0NQVVRZUEV9ID09ICJjNyIKIE1BQ0hJTkVfQ1BV ID0gc3NlMyBzc2UyIHNzZSBpNjg2IG1teCBpNTg2IGk0ODYgaTM4NgorLiAgZWxpZiAke0NQ VVRZUEV9ID09ICJjb3JlaTctYXZ4IiB8fCAke0NQVVRZUEV9ID09ICJjb3JlLWF2eC1pIgor TUFDSElORV9DUFUgPSBhdnggc3NlNDIgc3NlNDEgc3NzZTMgc3NlMyBzc2UyIHNzZSBpNjg2 IG1teCBpNTg2IGk0ODYgaTM4NgorLiAgZWxpZiAke0NQVVRZUEV9ID09ICJjb3JlaTciCitN QUNISU5FX0NQVSA9IHNzZTQyIHNzZTQxIHNzc2UzIHNzZTMgc3NlMiBzc2UgaTY4NiBtbXgg aTU4NiBpNDg2IGkzODYKIC4gIGVsaWYgJHtDUFVUWVBFfSA9PSAiY29yZTIiCiBNQUNISU5F X0NQVSA9IHNzc2UzIHNzZTMgc3NlMiBzc2UgaTY4NiBtbXggaTU4NiBpNDg2IGkzODYKIC4g IGVsaWYgJHtDUFVUWVBFfSA9PSAicHJlc2NvdHQiCiBNQUNISU5FX0NQVSA9IHNzZTMgc3Nl MiBzc2UgaTY4NiBtbXggaTU4NiBpNDg2IGkzODYKLS4gIGVsaWYgJHtDUFVUWVBFfSA9PSAi cGVudGl1bTQiIHx8ICR7Q1BVVFlQRX0gPT0gInBlbnRpdW00bSIgfHwgJHtDUFVUWVBFfSA9 PSAicGVudGl1bS1tIgorLiAgZWxpZiAke0NQVVRZUEV9ID09ICJwZW50aXVtNCIgfHwgJHtD UFVUWVBFfSA9PSAicGVudGl1bTRtIiB8fCBcCisgICAgJHtDUFVUWVBFfSA9PSAicGVudGl1 bS1tIgogTUFDSElORV9DUFUgPSBzc2UyIHNzZSBpNjg2IG1teCBpNTg2IGk0ODYgaTM4Ngog LiAgZWxpZiAke0NQVVRZUEV9ID09ICJwZW50aXVtMyIgfHwgJHtDUFVUWVBFfSA9PSAicGVu dGl1bTNtIgogTUFDSElORV9DUFUgPSBzc2UgaTY4NiBtbXggaTU4NiBpNDg2IGkzODYKQEAg LTE4NSwxMCArMTk4LDIyIEBAIE1BQ0hJTkVfQ1BVID0gaTQ4NiBpMzg2CiBNQUNISU5FX0NQ VSA9IGkzODYKIC4gIGVuZGlmCiAuIGVsaWYgJHtNQUNISU5FX0NQVUFSQ0h9ID09ICJhbWQ2 NCIKLS4gIGlmICR7Q1BVVFlQRX0gPT0gIm9wdGVyb24tc3NlMyIgfHwgJHtDUFVUWVBFfSA9 PSAiYXRobG9uNjQtc3NlMyIgfHwgJHtDUFVUWVBFfSA9PSAiazgtc3NlMyIKKy4gIGlmICR7 Q1BVVFlQRX0gPT0gImJkdmVyMSIgfHwgJHtDUFVUWVBFfSA9PSAiYmR2ZXIyIgorTUFDSElO RV9DUFUgPSBhdnggc3NlNDIgc3NlNDEgc3NzZTMgc3NlNGEgc3NlMworLiAgZWxpZiAke0NQ VVRZUEV9ID09ICJidHZlcjEiCitNQUNISU5FX0NQVSA9IHNzc2UzIHNzZTRhIHNzZTMKKy4g IGVsaWYgJHtDUFVUWVBFfSA9PSAiYW1kZmFtMTAiCitNQUNISU5FX0NQVSA9IGs4IDNkbm93 IHNzZTRhIHNzZTMKKy4gIGVsaWYgJHtDUFVUWVBFfSA9PSAib3B0ZXJvbi1zc2UzIiB8fCAk e0NQVVRZUEV9ID09ICJhdGhsb242NC1zc2UzIiB8fCBcCisgICAgJHtDUFVUWVBFfSA9PSAi azgtc3NlMyIKIE1BQ0hJTkVfQ1BVID0gazggM2Rub3cgc3NlMwotLiAgZWxpZiAke0NQVVRZ UEV9ID09ICJvcHRlcm9uIiB8fCAke0NQVVRZUEV9ID09ICJhdGhsb242NCIgfHwgJHtDUFVU WVBFfSA9PSAiazgiCisuICBlbGlmICR7Q1BVVFlQRX0gPT0gIm9wdGVyb24iIHx8ICR7Q1BV VFlQRX0gPT0gImF0aGxvbjY0IiB8fCBcCisgICAgJHtDUFVUWVBFfSA9PSAiazgiCiBNQUNI SU5FX0NQVSA9IGs4IDNkbm93CisuICBlbGlmICR7Q1BVVFlQRX0gPT0gImNvcmVpNy1hdngi IHx8ICR7Q1BVVFlQRX0gPT0gImNvcmUtYXZ4LWkiCitNQUNISU5FX0NQVSA9IGF2eCBzc2U0 MiBzc2U0MSBzc3NlMyBzc2UzCisuICBlbGlmICR7Q1BVVFlQRX0gPT0gImNvcmVpNyIKK01B Q0hJTkVfQ1BVID0gc3NlNDIgc3NlNDEgc3NzZTMgc3NlMwogLiAgZWxpZiAke0NQVVRZUEV9 ID09ICJjb3JlMiIKIE1BQ0hJTkVfQ1BVID0gc3NzZTMgc3NlMwogLiAgZWxpZiAke0NQVVRZ UEV9ID09ICJub2NvbmEiCg== --------------030501020705070507090201-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 00:47:01 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF45D25F for ; Thu, 15 Nov 2012 00:47:01 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5A9B98FC17 for ; Thu, 15 Nov 2012 00:47:01 +0000 (UTC) Message-ID: <50A43B52.8030102@FreeBSD.org> Date: Wed, 14 Nov 2012 19:46:10 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121031 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: [RFC] Generic population count function X-Enigmail-Version: 1.4.5 Content-Type: multipart/mixed; boundary="------------050306080403080108050002" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 00:47:02 -0000 This is a multi-part message in MIME format. --------------050306080403080108050002 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I implemented generic population count function. Please see the attachment. It is also available from here: http://people.freebsd.org/~jkim/bitcount.diff The idea is to make use of CPU-supported population count instructions if available and the compiler supports them (i.e., clang), especially for larger than 32-bit data. The patch also has use cases for the new function (i.e., counting number of bits in IPv6 address[*]). Any objection? Jung-uk Kim * PS: BTW, I am not sure whether this is correct: - --- sys/netpfil/ipfw/ip_fw_table.c +++ sys/netpfil/ipfw/ip_fw_table.c @@ -720,11 +717,10 @@ dump_table_xentry_extended(struct radix_node *rn, switch (tbl->type) { #ifdef INET6 case IPFW_TABLE_CIDR: - - /* Count IPv6 mask */ - - v = (uint32_t *)&n->m.mask6.sin6_addr; - - for (i = 0; i < sizeof(struct in6_addr) / 4; i++, v++) - - xent->masklen += bitcount32(*v); - - memcpy(&xent->k, &n->a.addr6.sin6_addr, sizeof(struct in6_addr)); + xent->masklen += bitcount(&n->m.mask6.sin6_addr, + sizeof(struct in6_addr)); + memcpy(&xent->k, &n->a.addr6.sin6_addr, + sizeof(struct in6_addr)); break; #endif case IPFW_TABLE_INTERFACE: Is xent->masklen initialized to a non-zero value somewhere, i.e., shouldn't we just use '=' instead of '+=' here? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCkO1IACgkQmlay1b9qnVNzggCfW+Fri0Aj4TDDXcAoPc4SaATB clQAnikNhO6JVJ+Ez71cbdQV5Qy4uHam =r4nt -----END PGP SIGNATURE----- --------------050306080403080108050002 Content-Type: text/plain; charset=UTF-8; name="bitcount.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bitcount.diff" SW5kZXg6IHN5cy9uZXRncmFwaC9uZXRmbG93L25ldGZsb3cuYwo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBzeXMvbmV0Z3JhcGgvbmV0Zmxvdy9uZXRmbG93LmMJKHJldmlzaW9uIDI0MzA0MikKKysr IHN5cy9uZXRncmFwaC9uZXRmbG93L25ldGZsb3cuYwkod29ya2luZyBjb3B5KQpAQCAtNDA5 LDEyICs0MDksOSBAQCBoYXNoX2luc2VydChwcml2X3AgcHJpdiwgc3RydWN0IGZsb3dfaGFz aF9lbnRyeSAqaAogfQogCiAjaWZkZWYgSU5FVDYKLS8qIFhYWDogbWFrZSBub3JtYWwgZnVu Y3Rpb24sIGluc3RlYWQgb2YuLiAqLwotI2RlZmluZSBpcHY2X21hc2tsZW4oeCkJCWJpdGNv dW50MzIoKHgpLl9fdTZfYWRkci5fX3U2X2FkZHIzMlswXSkgKyBcCi0JCQkJYml0Y291bnQz MigoeCkuX191Nl9hZGRyLl9fdTZfYWRkcjMyWzFdKSArIFwKLQkJCQliaXRjb3VudDMyKCh4 KS5fX3U2X2FkZHIuX191Nl9hZGRyMzJbMl0pICsgXAotCQkJCWJpdGNvdW50MzIoKHgpLl9f dTZfYWRkci5fX3U2X2FkZHIzMlszXSkKLSNkZWZpbmUgUlRfTUFTSzYoeCkJKGlwdjZfbWFz a2xlbigoKHN0cnVjdCBzb2NrYWRkcl9pbjYgKilydF9tYXNrKHgpKS0+c2luNl9hZGRyKSkK KyNkZWZpbmUgUlRfTUFTSzYoeCkgXAorCWJpdGNvdW50KCYoKHN0cnVjdCBzb2NrYWRkcl9p bjYgKilydF9tYXNrKHgpKS0+c2luNl9hZGRyLCBcCisJICAgIHNpemVvZihzdHJ1Y3QgaW42 X2FkZHIpKQogc3RhdGljIGludAogaGFzaDZfaW5zZXJ0KHByaXZfcCBwcml2LCBzdHJ1Y3Qg Zmxvd19oYXNoX2VudHJ5ICpoc2g2LCBzdHJ1Y3QgZmxvdzZfcmVjICpyLAogCWludCBwbGVu LCB1aW50OF90IGZsYWdzLCB1aW50OF90IHRjcF9mbGFncykKQEAgLTUwNSw3ICs1MDIsNiBA QCBoYXNoNl9pbnNlcnQocHJpdl9wIHByaXYsIHN0cnVjdCBmbG93X2hhc2hfZW50cnkgKgog CiAJcmV0dXJuICgwKTsKIH0KLSN1bmRlZiBpcHY2X21hc2tsZW4KICN1bmRlZiBSVF9NQVNL NgogI2VuZGlmCiAKSW5kZXg6IHN5cy9uZXRwZmlsL2lwZncvaXBfZndfdGFibGUuYwo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3X3RhYmxlLmMJKHJldmlzaW9u IDI0MzA0MikKKysrIHN5cy9uZXRwZmlsL2lwZncvaXBfZndfdGFibGUuYwkod29ya2luZyBj b3B5KQpAQCAtNzA2LDEwICs3MDYsNyBAQCBkdW1wX3RhYmxlX3hlbnRyeV9leHRlbmRlZChz dHJ1Y3QgcmFkaXhfbm9kZSAqcm4sCiAJc3RydWN0IHRhYmxlX3hlbnRyeSAqIGNvbnN0IG4g PSAoc3RydWN0IHRhYmxlX3hlbnRyeSAqKXJuOwogCWlwZndfeHRhYmxlICogY29uc3QgdGJs ID0gYXJnOwogCWlwZndfdGFibGVfeGVudHJ5ICp4ZW50OwotI2lmZGVmIElORVQ2Ci0JaW50 IGk7Ci0JdWludDMyX3QgKnY7Ci0jZW5kaWYKKwogCS8qIE91dCBvZiBtZW1vcnksIHJldHVy bmluZyAqLwogCWlmICh0YmwtPmNudCA9PSB0YmwtPnNpemUpCiAJCXJldHVybiAoMSk7CkBA IC03MjAsMTEgKzcxNywxMCBAQCBkdW1wX3RhYmxlX3hlbnRyeV9leHRlbmRlZChzdHJ1Y3Qg cmFkaXhfbm9kZSAqcm4sCiAJc3dpdGNoICh0YmwtPnR5cGUpIHsKICNpZmRlZiBJTkVUNgog CWNhc2UgSVBGV19UQUJMRV9DSURSOgotCQkvKiBDb3VudCBJUHY2IG1hc2sgKi8KLQkJdiA9 ICh1aW50MzJfdCAqKSZuLT5tLm1hc2s2LnNpbjZfYWRkcjsKLQkJZm9yIChpID0gMDsgaSA8 IHNpemVvZihzdHJ1Y3QgaW42X2FkZHIpIC8gNDsgaSsrLCB2KyspCi0JCQl4ZW50LT5tYXNr bGVuICs9IGJpdGNvdW50MzIoKnYpOwotCQltZW1jcHkoJnhlbnQtPmssICZuLT5hLmFkZHI2 LnNpbjZfYWRkciwgc2l6ZW9mKHN0cnVjdCBpbjZfYWRkcikpOworCQl4ZW50LT5tYXNrbGVu ICs9IGJpdGNvdW50KCZuLT5tLm1hc2s2LnNpbjZfYWRkciwKKwkJICAgIHNpemVvZihzdHJ1 Y3QgaW42X2FkZHIpKTsKKwkJbWVtY3B5KCZ4ZW50LT5rLCAmbi0+YS5hZGRyNi5zaW42X2Fk ZHIsCisJCSAgICBzaXplb2Yoc3RydWN0IGluNl9hZGRyKSk7CiAJCWJyZWFrOwogI2VuZGlm CiAJY2FzZSBJUEZXX1RBQkxFX0lOVEVSRkFDRToKSW5kZXg6IHN5cy9zeXMvYml0Y291bnQu aAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSBzeXMvc3lzL2JpdGNvdW50LmgJKHJldmlzaW9uIDApCisr KyBzeXMvc3lzL2JpdGNvdW50LmgJKHdvcmtpbmcgY29weSkKQEAgLTAsMCArMSwxMDYgQEAK Ky8qLQorICogQ29weXJpZ2h0IChjKSAyMDEyIEp1bmctdWsgS2ltIDxqa2ltQEZyZWVCU0Qu b3JnPgorICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBh bmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAq IG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dp bmcgY29uZGl0aW9ucworICogYXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBz b3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3Rp Y2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWlt ZXIuCisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1 Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29u ZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQorICogICAgZG9j dW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRp c3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBB VVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBBTlkgRVhQUkVTUyBP UiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBU SEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5F U1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5P IEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQorICog Rk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExB UlksIE9SIENPTlNFUVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBM SU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBPUiBTRVJW SUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVS UlVQVElPTikKKyAqIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJ TElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRP UlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkg V0FZCisgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklT RUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCisgKiBTVUNIIERBTUFHRS4KKyAqCisgKiAkRnJl ZUJTRCQKKyAqLworCisjaWZuZGVmIF9TWVNfQklUQ09VTlRfSF8KKyNkZWZpbmUJX1NZU19C SVRDT1VOVF9IXworCisjaW5jbHVkZSA8c3lzL2NkZWZzLmg+CisjaW5jbHVkZSA8c3lzL3R5 cGVzLmg+CisKKyNpZiBfX0dOVUNfUFJFUkVRX18oMywgNCkKKyNkZWZpbmUJX19CSVRDT1VO VCh4KQlfX2J1aWx0aW5fcG9wY291bnRsKHgpCisjZGVmaW5lCV9fQklUQ09VTlQzMih4KQlf X2J1aWx0aW5fcG9wY291bnQoeCkKKyNkZWZpbmUJX19CSVRDT1VOVF9UCXVfbG9uZworI2Vs c2UKKyNkZWZpbmUJX19CSVRDT1VOVCh4KQlfX2JpdGNvdW50MzIoeCkKKyNkZWZpbmUJX19C SVRDT1VOVDMyKHgpCV9fYml0Y291bnQzMih4KQorI2RlZmluZQlfX0JJVENPVU5UX1QJdWlu dDMyX3QKKyNlbmRpZgorCisvKgorICogUG9wdWxhdGlvbiBjb3VudCBhbGdvcml0aG0gdXNp bmcgU1dBUiBhcHByb2FjaAorICogLSAiU0lNRCBXaXRoaW4gQSBSZWdpc3RlciIuCisgKi8K K3N0YXRpYyBfX2lubGluZSBpbnQKK19fYml0Y291bnQzMih1aW50MzJfdCB4KQoreworCisJ eCArPSB+KCh4ID4+IDEpICYgMHg1NTU1NTU1NSkgKyAxOworCXggPSAoeCAmIDB4MzMzMzMz MzMpICsgKCh4ID4+IDIpICYgMHgzMzMzMzMzMyk7CisJeCA9ICh4ICsgKHggPj4gNCkpICYg MHgwZjBmMGYwZjsKKwl4ICs9IHggPj4gODsKKwl4ICs9IHggPj4gMTY7CisJcmV0dXJuICh4 ICYgMHgzZik7Cit9CisKK3N0YXRpYyBfX2lubGluZSBpbnQKK2JpdGNvdW50KHZvaWQgKnAs IGludCBsZW4pCit7CisJX19CSVRDT1VOVF9UIHg7CisJdV9jaGFyICpzdHI7CisJaW50IGNv dW50OworCisJLyoKKwkgKiBOdW1iZXIgb2YgYml0cyBtdXN0IGJlIG5vbi16ZXJvIGFuZCBs ZXNzIG9yIGVxdWFsIHRvIElOVF9NQVguCisJICovCisJaWYgKGxlbiA8PSAwIHx8IGxlbiA+ PSAweDEwMDAwMDAwKQorCQlyZXR1cm4gKC0xKTsKKworCWZvciAoY291bnQgPSAwLCBzdHIg PSBwOyBsZW4gPiAwOyBsZW4gLT0gc2l6ZW9mKHgpKSB7CisJCWlmIChsZW4gLyBzaXplb2Yo eCkgPiAwKSB7CisJCQl4ID0gKihfX0JJVENPVU5UX1QgKilzdHI7CisJCQlzdHIgKz0gc2l6 ZW9mKHgpOworCQl9IGVsc2UgeworCQkJLyogQnl0ZSBvcmRlciBpcyBub3QgaW1wb3J0YW50 IGhlcmUuICovCisJCQlmb3IgKHggPSAwOyBsZW4gPiAwOyBzdHIrKywgbGVuLS0pCisJCQkJ eCB8PSAqc3RyIDw8IChsZW4gKiA4KTsKKwkJfQorCQljb3VudCArPSBfX0JJVENPVU5UKHgp OworCX0KKwlyZXR1cm4gKGNvdW50KTsKK30KKworc3RhdGljIF9faW5saW5lIGludAorYml0 Y291bnQxNih1aW50MTZfdCB4KQoreworCisJcmV0dXJuIChfX0JJVENPVU5UMzIoeCkpOwor fQorCitzdGF0aWMgX19pbmxpbmUgaW50CitiaXRjb3VudDMyKHVpbnQzMl90IHgpCit7CisK KwlyZXR1cm4gKF9fQklUQ09VTlQzMih4KSk7Cit9CisKKyN1bmRlZiBfX0JJVENPVU5UCisj dW5kZWYgX19CSVRDT1VOVDMyCisjdW5kZWYgX19CSVRDT1VOVF9UCisKKyNlbmRpZiAvKiAh X1NZU19CSVRDT1VOVF9IXyAqLwoKUHJvcGVydHkgY2hhbmdlcyBvbjogc3lzL3N5cy9iaXRj b3VudC5oCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KQWRkZWQ6IHN2bjplb2wtc3R5bGUKIyMgLTAsMCArMSAj IworbmF0aXZlClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgcHJvcGVydHkKQWRkZWQ6IHN2bjpt aW1lLXR5cGUKIyMgLTAsMCArMSAjIwordGV4dC9wbGFpbgpcIE5vIG5ld2xpbmUgYXQgZW5k IG9mIHByb3BlcnR5CkFkZGVkOiBzdm46a2V5d29yZHMKIyMgLTAsMCArMSAjIworRnJlZUJT RD0lSApcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIHByb3BlcnR5CkluZGV4OiBzeXMvc3lzL3N5 c3RtLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL3N5cy9zeXN0bS5oCShyZXZpc2lvbiAyNDMw NDIpCisrKyBzeXMvc3lzL3N5c3RtLmgJKHdvcmtpbmcgY29weSkKQEAgLTQwLDYgKzQwLDcg QEAKIAogI2luY2x1ZGUgPG1hY2hpbmUvYXRvbWljLmg+CiAjaW5jbHVkZSA8bWFjaGluZS9j cHVmdW5jLmg+CisjaW5jbHVkZSA8c3lzL2JpdGNvdW50Lmg+CiAjaW5jbHVkZSA8c3lzL2Nh bGxvdXQuaD4KICNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KICNpbmNsdWRlIDxzeXMvcXVldWUu aD4KQEAgLTM4NywzMSArMzg4LDQgQEAgaW50IGFsbG9jX3Vucl9zcGVjaWZpYyhzdHJ1Y3Qg dW5yaGRyICp1aCwgdV9pbnQgaXQKIGludCBhbGxvY191bnJsKHN0cnVjdCB1bnJoZHIgKnVo KTsKIHZvaWQgZnJlZV91bnIoc3RydWN0IHVucmhkciAqdWgsIHVfaW50IGl0ZW0pOwogCi0v KgotICogUG9wdWxhdGlvbiBjb3VudCBhbGdvcml0aG0gdXNpbmcgU1dBUiBhcHByb2FjaAot ICogLSAiU0lNRCBXaXRoaW4gQSBSZWdpc3RlciIuCi0gKi8KLXN0YXRpYyBfX2lubGluZSB1 aW50MzJfdAotYml0Y291bnQzMih1aW50MzJfdCB4KQotewotCi0JeCA9ICh4ICYgMHg1NTU1 NTU1NSkgKyAoKHggJiAweGFhYWFhYWFhKSA+PiAxKTsKLQl4ID0gKHggJiAweDMzMzMzMzMz KSArICgoeCAmIDB4Y2NjY2NjY2MpID4+IDIpOwotCXggPSAoeCArICh4ID4+IDQpKSAmIDB4 MGYwZjBmMGY7Ci0JeCA9ICh4ICsgKHggPj4gOCkpOwotCXggPSAoeCArICh4ID4+IDE2KSkg JiAweDAwMDAwMGZmOwotCXJldHVybiAoeCk7Ci19Ci0KLXN0YXRpYyBfX2lubGluZSB1aW50 MTZfdAotYml0Y291bnQxNih1aW50MzJfdCB4KQotewotCi0JeCA9ICh4ICYgMHg1NTU1KSAr ICgoeCAmIDB4YWFhYSkgPj4gMSk7Ci0JeCA9ICh4ICYgMHgzMzMzKSArICgoeCAmIDB4Y2Nj YykgPj4gMik7Ci0JeCA9ICh4ICsgKHggPj4gNCkpICYgMHgwZjBmOwotCXggPSAoeCArICh4 ID4+IDgpKSAmIDB4MDBmZjsKLQlyZXR1cm4gKHgpOwotfQotCiAjZW5kaWYgLyogIV9TWVNf U1lTVE1fSF8gKi8K --------------050306080403080108050002-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 05:04:07 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A8E1F65; Thu, 15 Nov 2012 05:04:07 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id C91158FC0C; Thu, 15 Nov 2012 05:04:06 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-149-146.hsd1.ca.comcast.net [50.143.149.146]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id qAF53xNA008119 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Nov 2012 21:04:00 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <50A477BA.4020700@freebsd.org> Date: Wed, 14 Nov 2012 21:03:54 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Jung-uk Kim Subject: Re: [RFC] Generic population count function References: <50A43B52.8030102@FreeBSD.org> In-Reply-To: <50A43B52.8030102@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 05:04:07 -0000 On 11/14/12 4:46 PM, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I implemented generic population count function. Please see the > attachment. It is also available from here: > > http://people.freebsd.org/~jkim/bitcount.diff > > The idea is to make use of CPU-supported population count instructions > if available and the compiler supports them (i.e., clang), especially > for larger than 32-bit data. The patch also has use cases for the new > function (i.e., counting number of bits in IPv6 address[*]). > > Any objection? there are more efficient algorithms than the one you show in bitcount.h see the bit-twidling site: http://graphics.stanford.edu/~seander/bithacks.html > > Jung-uk Kim > > * PS: BTW, I am not sure whether this is correct: > > - --- sys/netpfil/ipfw/ip_fw_table.c > +++ sys/netpfil/ipfw/ip_fw_table.c > @@ -720,11 +717,10 @@ dump_table_xentry_extended(struct radix_node *rn, > switch (tbl->type) { > #ifdef INET6 > case IPFW_TABLE_CIDR: > - - /* Count IPv6 mask */ > - - v = (uint32_t *)&n->m.mask6.sin6_addr; > - - for (i = 0; i < sizeof(struct in6_addr) / 4; i++, v++) > - - xent->masklen += bitcount32(*v); > - - memcpy(&xent->k, &n->a.addr6.sin6_addr, sizeof(struct > in6_addr)); > + xent->masklen += bitcount(&n->m.mask6.sin6_addr, > + sizeof(struct in6_addr)); > + memcpy(&xent->k, &n->a.addr6.sin6_addr, > + sizeof(struct in6_addr)); > break; > #endif > case IPFW_TABLE_INTERFACE: > > Is xent->masklen initialized to a non-zero value somewhere, i.e., > shouldn't we just use '=' instead of '+=' here? > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.19 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlCkO1IACgkQmlay1b9qnVNzggCfW+Fri0Aj4TDDXcAoPc4SaATB > clQAnikNhO6JVJ+Ez71cbdQV5Qy4uHam > =r4nt > -----END PGP SIGNATURE----- > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 06:15:48 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 152D09E4; Thu, 15 Nov 2012 06:15:48 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id B7B0A8FC08; Thu, 15 Nov 2012 06:15:47 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so1654740obc.13 for ; Wed, 14 Nov 2012 22:15:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=+X3hI/ivxIXd0+H7ewJ23HBr6k+KpZ9WITZjfUjX/Yk=; b=IafJ1gysZKKUZlwTlbfs9FmDYKfS/ZcbL8uPQI7JemgHxTLyfXPYFWpXQ1HwnSEULE i+6ySnP5hNWjz8zrZ6hia0TVioK3R89tev5WtjRYig9qXHjk8eZzXmehlJ3vVBWzCg1O HHHZWEMJFfNJZWsGhjitQPkCqpbVR/iYFksxHfuxwG+tZsTMoSQCnfnqofAaPtFJsUxm nO4CzMFvgWSnT5PtTI+//VGltF9FWUEA4f7K0hqA33B9vCjT7+y9xcnZgV/ym+lLMmrU XHRHAJwRb7FauzhRZC3CkrfNikpR7t7zjq6YXdCmTOg53O7Wyh8rzjwcyTclMfD8Iwek 3u/Q== MIME-Version: 1.0 Received: by 10.182.69.50 with SMTP id b18mr52208obu.75.1352960146780; Wed, 14 Nov 2012 22:15:46 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.76.27.65 with HTTP; Wed, 14 Nov 2012 22:15:46 -0800 (PST) Date: Wed, 14 Nov 2012 22:15:46 -0800 X-Google-Sender-Auth: 0Rz1azTUUeP__CP-U11sAXzxaeA Message-ID: Subject: [RFQ] make witness panic an option From: Adrian Chadd To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=14dae93b5780f1b3ca04ce8294f5 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 06:15:48 -0000 --14dae93b5780f1b3ca04ce8294f5 Content-Type: text/plain; charset=ISO-8859-1 Hi all, When debugging and writing wireless drivers/stack code, I like to sprinkle lots of locking assertions everywhere. However, this does cause things to panic quite often during active development. This patch (against stable/9) makes the actual panic itself configurable. It still prints the message regardless. This has allowed me to sprinkle more locking assertions everywhere to investigate whether particular paths have been hit or not. I don't necessarily want those to panic the kernel. I'd like everyone to consider this for FreeBSD-HEAD. Thanks! Adrian --14dae93b5780f1b3ca04ce8294f5 Content-Type: application/octet-stream; name="20121114-witness-1.diff" Content-Disposition: attachment; filename="20121114-witness-1.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h9jhl24w0 SW5kZXg6IHN5cy9rZXJuL3N1YnJfd2l0bmVzcy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9rZXJuL3N1 YnJfd2l0bmVzcy5jCShyZXZpc2lvbiAyNDE0OTEpCisrKyBzeXMva2Vybi9zdWJyX3dpdG5lc3Mu Ywkod29ya2luZyBjb3B5KQpAQCAtMzE5LDYgKzMxOSwyOCBAQAogCXJldHVybiAoYS0+ZnJvbSA9 PSBiLT5mcm9tICYmIGEtPnRvID09IGItPnRvKTsKIH0KIAorLyoKKyAqIFdoZXRoZXIgdG8gcGFu aWMgb3Igbm90IHdoZW4gYSB3aXRuZXNzIGNvbmRpdGlvbiBvY2N1cnMuCisgKi8KK3N0YXRpYyBp bnQgd2l0bmVzc19kb3BhbmljID0gMTsKKworLyoKKyAqIEhhbmRsZSB3aGV0aGVyIHRvIHBhbmlj IG9yIG1lcmVseSBwcmludCBhbiBpbmZvcm1hdGl2ZSBtZXNzYWdlLgorICovCitzdGF0aWMgdm9p ZAord2l0bmVzc19wYW5pYyhjb25zdCBjaGFyICpmbXQsIC4uLikKK3sKKwl2YV9saXN0IGFwOwor CisJdmFfc3RhcnQoYXAsIGZtdCk7CisJdnByaW50ZihmbXQsIGFwKTsKKwl2YV9lbmQoYXApOwor CisJLyogWFhYIGl0J2QgYmUgbmljZSB0byBtYWludGFpbiB0aGUgY29ycmVjdCBwYW5pY3N0ciAq LworCWlmICh3aXRuZXNzX2RvcGFuaWMpCisJCXBhbmljKCJ3aXRuZXNzXG4iKTsKK30KKwogc3Rh dGljIGludAlfaXNpdG15eChzdHJ1Y3Qgd2l0bmVzcyAqdzEsIHN0cnVjdCB3aXRuZXNzICp3Miwg aW50IHJtYXNrLAogCQkgICAgY29uc3QgY2hhciAqZm5hbWUpOwogI2lmZGVmIEtEQgpAQCAtNDA1 LDYgKzQyNyw5IEBACiBUVU5BQkxFX0lOVCgiZGVidWcud2l0bmVzcy5rZGIiLCAmd2l0bmVzc19r ZGIpOwogU1lTQ1RMX0lOVChfZGVidWdfd2l0bmVzcywgT0lEX0FVVE8sIGtkYiwgQ1RMRkxBR19S VywgJndpdG5lc3Nfa2RiLCAwLCAiIik7CiAKK1RVTkFCTEVfSU5UKCJkZWJ1Zy53aXRuZXNzLnBh bmljIiwgJndpdG5lc3NfZG9wYW5pYyk7CitTWVNDVExfSU5UKF9kZWJ1Z193aXRuZXNzLCBPSURf QVVUTywgcGFuaWMsIENUTEZMQUdfUlcsICZ3aXRuZXNzX2RvcGFuaWMsIDAsICIiKTsKKwogLyoK ICAqIFdoZW4gS0RCIGlzIGVuYWJsZWQgYW5kIHdpdG5lc3NfdHJhY2UgaXMgMSwgaXQgd2lsbCBj YXVzZSB0aGUgc3lzdGVtCiAgKiB0byBwcmludCBhIHN0YWNrIHRyYWNlOgpAQCAtNzIyLDE4ICs3 NDcsNiBAQAogICovCiBzdGF0aWMgaW50IHdpdG5lc3Nfc3Bpbl93YXJuID0gMDsKIAotLyogVHJp bSB1c2VsZXNzIGdhcmJhZ2UgZnJvbSBmaWxlbmFtZXMuICovCi1zdGF0aWMgY29uc3QgY2hhciAq Ci1maXh1cF9maWxlbmFtZShjb25zdCBjaGFyICpmaWxlKQotewotCi0JaWYgKGZpbGUgPT0gTlVM TCkKLQkJcmV0dXJuIChOVUxMKTsKLQl3aGlsZSAoc3RybmNtcChmaWxlLCAiLi4vIiwgMykgPT0g MCkKLQkJZmlsZSArPSAzOwotCXJldHVybiAoZmlsZSk7Ci19Ci0KIC8qCiAgKiBUaGUgV0lUTkVT Uy1lbmFibGVkIGRpYWdub3N0aWMgY29kZS4gIE5vdGUgdGhhdCB0aGUgd2l0bmVzcyBjb2RlIGRv ZXMKICAqIGFzc3VtZSB0aGF0IHRoZSBlYXJseSBib290IGlzIHNpbmdsZS10aHJlYWRlZCBhdCBs ZWFzdCB1bnRpbCBhZnRlciB0aGlzCkBAIC04MjQsMTUgKzgzNywxNSBAQAogCWNsYXNzID0gTE9D S19DTEFTUyhsb2NrKTsKIAlpZiAoKGxvY2stPmxvX2ZsYWdzICYgTE9fUkVDVVJTQUJMRSkgIT0g MCAmJgogCSAgICAoY2xhc3MtPmxjX2ZsYWdzICYgTENfUkVDVVJTQUJMRSkgPT0gMCkKLQkJcGFu aWMoIiVzOiBsb2NrICglcykgJXMgY2FuIG5vdCBiZSByZWN1cnNhYmxlIiwgX19mdW5jX18sCisJ CXdpdG5lc3NfcGFuaWMoIiVzOiBsb2NrICglcykgJXMgY2FuIG5vdCBiZSByZWN1cnNhYmxlIiwg X19mdW5jX18sCiAJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSk7CiAJaWYgKChs b2NrLT5sb19mbGFncyAmIExPX1NMRUVQQUJMRSkgIT0gMCAmJgogCSAgICAoY2xhc3MtPmxjX2Zs YWdzICYgTENfU0xFRVBBQkxFKSA9PSAwKQotCQlwYW5pYygiJXM6IGxvY2sgKCVzKSAlcyBjYW4g bm90IGJlIHNsZWVwYWJsZSIsIF9fZnVuY19fLAorCQl3aXRuZXNzX3BhbmljKCIlczogbG9jayAo JXMpICVzIGNhbiBub3QgYmUgc2xlZXBhYmxlIiwgX19mdW5jX18sCiAJCSAgICBjbGFzcy0+bGNf bmFtZSwgbG9jay0+bG9fbmFtZSk7CiAJaWYgKChsb2NrLT5sb19mbGFncyAmIExPX1VQR1JBREFC TEUpICE9IDAgJiYKIAkgICAgKGNsYXNzLT5sY19mbGFncyAmIExDX1VQR1JBREFCTEUpID09IDAp Ci0JCXBhbmljKCIlczogbG9jayAoJXMpICVzIGNhbiBub3QgYmUgdXBncmFkYWJsZSIsIF9fZnVu Y19fLAorCQl3aXRuZXNzX3BhbmljKCIlczogbG9jayAoJXMpICVzIGNhbiBub3QgYmUgdXBncmFk YWJsZSIsIF9fZnVuY19fLAogCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUpOwog CiAJLyoKQEAgLTg0OSw3ICs4NjIsNyBAQAogCQlwZW5kaW5nX2xvY2tzW3BlbmRpbmdfY250XS53 aF9sb2NrID0gbG9jazsKIAkJcGVuZGluZ19sb2Nrc1twZW5kaW5nX2NudCsrXS53aF90eXBlID0g dHlwZTsKIAkJaWYgKHBlbmRpbmdfY250ID4gV0lUTkVTU19QRU5ETElTVCkKLQkJCXBhbmljKCIl czogcGVuZGluZyBsb2NrcyBsaXN0IGlzIHRvbyBzbWFsbCwgYnVtcCBpdFxuIiwKKwkJCXdpdG5l c3NfcGFuaWMoIiVzOiBwZW5kaW5nIGxvY2tzIGxpc3QgaXMgdG9vIHNtYWxsLCBidW1wIGl0XG4i LAogCQkJICAgIF9fZnVuY19fKTsKIAl9IGVsc2UKIAkJbG9jay0+bG9fd2l0bmVzcyA9IGVucm9s bCh0eXBlLCBjbGFzcyk7CkBAIC04NjQsNyArODc3LDcgQEAKIAljbGFzcyA9IExPQ0tfQ0xBU1Mo bG9jayk7CiAKIAlpZiAod2l0bmVzc19jb2xkKQotCQlwYW5pYygibG9jayAoJXMpICVzIGRlc3Ry b3llZCB3aGlsZSB3aXRuZXNzX2NvbGQiLAorCQl3aXRuZXNzX3BhbmljKCJsb2NrICglcykgJXMg ZGVzdHJveWVkIHdoaWxlIHdpdG5lc3NfY29sZCIsCiAJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9j ay0+bG9fbmFtZSk7CiAKIAkvKiBYWFg6IG5lZWQgdG8gdmVyaWZ5IHRoYXQgbm8gb25lIGhvbGRz IHRoZSBsb2NrICovCkBAIC05MzksNyArOTUyLDcgQEAKICAJfQogIAl3LT53X2Rpc3BsYXllZCA9 IDE7CiAJaWYgKHctPndfZmlsZSAhPSBOVUxMICYmIHctPndfbGluZSAhPSAwKQotCQlwcm50KCIg LS0gbGFzdCBhY3F1aXJlZCBAICVzOiVkXG4iLCBmaXh1cF9maWxlbmFtZSh3LT53X2ZpbGUpLAor CQlwcm50KCIgLS0gbGFzdCBhY3F1aXJlZCBAICVzOiVkXG4iLCB3LT53X2ZpbGUsCiAJCSAgICB3 LT53X2xpbmUpOwogCWVsc2UKIAkJcHJudCgiIC0tIG5ldmVyIGFjcXVpcmVkXG4iKTsKQEAgLTEw MTUsNiArMTAyOCwxOCBAQAogfQogI2VuZGlmIC8qIEREQiAqLwogCisvKiBUcmltIHVzZWxlc3Mg Z2FyYmFnZSBmcm9tIGZpbGVuYW1lcy4gKi8KK3N0YXRpYyBjb25zdCBjaGFyICoKK2ZpeHVwX2Zp bGVuYW1lKGNvbnN0IGNoYXIgKmZpbGUpCit7CisKKwlpZiAoZmlsZSA9PSBOVUxMKQorCQlyZXR1 cm4gKE5VTEwpOworCXdoaWxlIChzdHJuY21wKGZpbGUsICIuLi8iLCAzKSA9PSAwKQorCQlmaWxl ICs9IDM7CisJcmV0dXJuIChmaWxlKTsKK30KKwogaW50CiB3aXRuZXNzX2RlZmluZW9yZGVyKHN0 cnVjdCBsb2NrX29iamVjdCAqbG9jazEsIHN0cnVjdCBsb2NrX29iamVjdCAqbG9jazIpCiB7CkBA IC0xMDc1LDkgKzExMDAsOCBAQAogCQkgKiBhbGwgc3BpbiBsb2Nrcy4KIAkJICovCiAJCWlmICh0 ZC0+dGRfY3JpdG5lc3QgIT0gMCAmJiAha2RiX2FjdGl2ZSkKLQkJCXBhbmljKCJibG9ja2FibGUg c2xlZXAgbG9jayAoJXMpICVzIEAgJXM6JWQiLAotCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2Nr LT5sb19uYW1lLAotCQkJICAgIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJCXdpdG5l c3NfcGFuaWMoImJsb2NrYWJsZSBzbGVlcCBsb2NrICglcykgJXMgQCAlczolZCIsCisJCQkgICAg Y2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUsIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5l KTsKIAogCQkvKgogCQkgKiBJZiB0aGlzIGlzIHRoZSBmaXJzdCBsb2NrIGFjcXVpcmVkIHRoZW4g anVzdCByZXR1cm4gYXMKQEAgLTExMTUsMjAgKzExMzksMTggQEAKIAkJaWYgKChsb2NrMS0+bGlf ZmxhZ3MgJiBMSV9FWENMVVNJVkUpICE9IDAgJiYKIAkJICAgIChmbGFncyAmIExPUF9FWENMVVNJ VkUpID09IDApIHsKIAkJCXByaW50Zigic2hhcmVkIGxvY2sgb2YgKCVzKSAlcyBAICVzOiVkXG4i LAotCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lLAotCQkJICAgIGZpeHVwX2Zp bGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFt ZSwgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCQkJcHJpbnRmKCJ3aGlsZSBleGNsdXNp dmVseSBsb2NrZWQgZnJvbSAlczolZFxuIiwKIAkJCSAgICBmaXh1cF9maWxlbmFtZShsb2NrMS0+ bGlfZmlsZSksIGxvY2sxLT5saV9saW5lKTsKLQkJCXBhbmljKCJzaGFyZS0+ZXhjbCIpOworCQkJ d2l0bmVzc19wYW5pYygic2hhcmUtPmV4Y2wiKTsKIAkJfQogCQlpZiAoKGxvY2sxLT5saV9mbGFn cyAmIExJX0VYQ0xVU0lWRSkgPT0gMCAmJgogCQkgICAgKGZsYWdzICYgTE9QX0VYQ0xVU0lWRSkg IT0gMCkgewogCQkJcHJpbnRmKCJleGNsdXNpdmUgbG9jayBvZiAoJXMpICVzIEAgJXM6JWRcbiIs Ci0JCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUsCi0JCQkgICAgZml4dXBfZmls ZW5hbWUoZmlsZSksIGxpbmUpOworCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1l LCBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CiAJCQlwcmludGYoIndoaWxlIHNoYXJlIGxv Y2tlZCBmcm9tICVzOiVkXG4iLAogCQkJICAgIGZpeHVwX2ZpbGVuYW1lKGxvY2sxLT5saV9maWxl KSwgbG9jazEtPmxpX2xpbmUpOwotCQkJcGFuaWMoImV4Y2wtPnNoYXJlIik7CisJCQl3aXRuZXNz X3BhbmljKCJleGNsLT5zaGFyZSIpOwogCQl9CiAJCXJldHVybjsKIAl9CkBAIC0xMTgwLDEyICsx MjAyLDExIEBACiAJCQkgICAgImFjcXVpcmluZyBkdXBsaWNhdGUgbG9jayBvZiBzYW1lIHR5cGU6 IFwiJXNcIlxuIiwgCiAJCQkgICAgdy0+d19uYW1lKTsKIAkJCXByaW50ZigiIDFzdCAlcyBAICVz OiVkXG4iLCBwbG9jay0+bGlfbG9jay0+bG9fbmFtZSwKLQkJCSAgICBmaXh1cF9maWxlbmFtZShw bG9jay0+bGlfZmlsZSksIHBsb2NrLT5saV9saW5lKTsKLQkJCXByaW50ZigiIDJuZCAlcyBAICVz OiVkXG4iLCBsb2NrLT5sb19uYW1lLAotCQkJICAgIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5l KTsKKwkJCSAgICAgICBmaXh1cF9maWxlbmFtZShwbG9jay0+bGlfZmlsZSksIHBsb2NrLT5saV9s aW5lKTsKKwkJCXByaW50ZigiIDJuZCAlcyBAICVzOiVkXG4iLCBsb2NrLT5sb19uYW1lLCBmaXh1 cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CiAJCQl3aXRuZXNzX2RlYnVnZ2VyKDEpOwotCQl9IGVs c2UKLQkJCW10eF91bmxvY2tfc3Bpbigmd19tdHgpOworCQkgICAgfSBlbHNlCisJCQkgICAgbXR4 X3VubG9ja19zcGluKCZ3X210eCk7CiAJCXJldHVybjsKIAl9CiAJbXR4X2Fzc2VydCgmd19tdHgs IE1BX09XTkVEKTsKQEAgLTEzMjMsMjQgKzEzNDQsMTkgQEAKIAkJCWlmIChpIDwgMCkgewogCQkJ CXByaW50ZigiIDFzdCAlcCAlcyAoJXMpIEAgJXM6JWRcbiIsCiAJCQkJICAgIGxvY2sxLT5saV9s b2NrLCBsb2NrMS0+bGlfbG9jay0+bG9fbmFtZSwKLQkJCQkgICAgdzEtPndfbmFtZSwgZml4dXBf ZmlsZW5hbWUobG9jazEtPmxpX2ZpbGUpLAotCQkJCSAgICBsb2NrMS0+bGlfbGluZSk7CisJCQkJ ICAgIHcxLT53X25hbWUsIGZpeHVwX2ZpbGVuYW1lKGxvY2sxLT5saV9maWxlKSwgbG9jazEtPmxp X2xpbmUpOwogCQkJCXByaW50ZigiIDJuZCAlcCAlcyAoJXMpIEAgJXM6JWRcbiIsIGxvY2ssCi0J CQkJICAgIGxvY2stPmxvX25hbWUsIHctPndfbmFtZSwKLQkJCQkgICAgZml4dXBfZmlsZW5hbWUo ZmlsZSksIGxpbmUpOworCQkJCSAgICBsb2NrLT5sb19uYW1lLCB3LT53X25hbWUsIGZpeHVwX2Zp bGVuYW1lKGZpbGUpLCBsaW5lKTsKIAkJCX0gZWxzZSB7CiAJCQkJcHJpbnRmKCIgMXN0ICVwICVz ICglcykgQCAlczolZFxuIiwKIAkJCQkgICAgbG9jazItPmxpX2xvY2ssIGxvY2syLT5saV9sb2Nr LT5sb19uYW1lLAogCQkJCSAgICBsb2NrMi0+bGlfbG9jay0+bG9fd2l0bmVzcy0+d19uYW1lLAot CQkJCSAgICBmaXh1cF9maWxlbmFtZShsb2NrMi0+bGlfZmlsZSksCi0JCQkJICAgIGxvY2syLT5s aV9saW5lKTsKKwkJCQkgICAgZml4dXBfZmlsZW5hbWUobG9jazItPmxpX2ZpbGUpLCBsb2NrMi0+ bGlfbGluZSk7CiAJCQkJcHJpbnRmKCIgMm5kICVwICVzICglcykgQCAlczolZFxuIiwKIAkJCQkg ICAgbG9jazEtPmxpX2xvY2ssIGxvY2sxLT5saV9sb2NrLT5sb19uYW1lLAotCQkJCSAgICB3MS0+ d19uYW1lLCBmaXh1cF9maWxlbmFtZShsb2NrMS0+bGlfZmlsZSksCi0JCQkJICAgIGxvY2sxLT5s aV9saW5lKTsKKwkJCQkgICAgdzEtPndfbmFtZSwgZml4dXBfZmlsZW5hbWUobG9jazEtPmxpX2Zp bGUpLCBsb2NrMS0+bGlfbGluZSk7CiAJCQkJcHJpbnRmKCIgM3JkICVwICVzICglcykgQCAlczol ZFxuIiwgbG9jaywKLQkJCQkgICAgbG9jay0+bG9fbmFtZSwgdy0+d19uYW1lLAotCQkJCSAgICBm aXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CisJCQkJICAgIGxvY2stPmxvX25hbWUsIHctPndf bmFtZSwgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCQkJfQogCQkJd2l0bmVzc19kZWJ1 Z2dlcigxKTsKIAkJCXJldHVybjsKQEAgLTE0MzUsMjkgKzE0NTEsMjQgQEAKIAljbGFzcyA9IExP Q0tfQ0xBU1MobG9jayk7CiAJaWYgKHdpdG5lc3Nfd2F0Y2gpIHsKIAkJaWYgKChsb2NrLT5sb19m bGFncyAmIExPX1VQR1JBREFCTEUpID09IDApCi0JCQlwYW5pYygidXBncmFkZSBvZiBub24tdXBn cmFkYWJsZSBsb2NrICglcykgJXMgQCAlczolZCIsCi0JCQkgICAgY2xhc3MtPmxjX25hbWUsIGxv Y2stPmxvX25hbWUsCi0JCQkgICAgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOworCQkJd2l0 bmVzc19wYW5pYygidXBncmFkZSBvZiBub24tdXBncmFkYWJsZSBsb2NrICglcykgJXMgQCAlczol ZCIsCisJCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUsIGZpeHVwX2ZpbGVuYW1l KGZpbGUpLCBsaW5lKTsKIAkJaWYgKChjbGFzcy0+bGNfZmxhZ3MgJiBMQ19TTEVFUExPQ0spID09 IDApCi0JCQlwYW5pYygidXBncmFkZSBvZiBub24tc2xlZXAgbG9jayAoJXMpICVzIEAgJXM6JWQi LAotCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lLAotCQkJICAgIGZpeHVwX2Zp bGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJCXdpdG5lc3NfcGFuaWMoInVwZ3JhZGUgb2Ygbm9uLXNs ZWVwIGxvY2sgKCVzKSAlcyBAICVzOiVkIiwKKwkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+ bG9fbmFtZSwgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCX0KIAlpbnN0YW5jZSA9IGZp bmRfaW5zdGFuY2UoY3VydGhyZWFkLT50ZF9zbGVlcGxvY2tzLCBsb2NrKTsKIAlpZiAoaW5zdGFu Y2UgPT0gTlVMTCkKLQkJcGFuaWMoInVwZ3JhZGUgb2YgdW5sb2NrZWQgbG9jayAoJXMpICVzIEAg JXM6JWQiLAotCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUsCi0JCSAgICBmaXh1 cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CisJCXdpdG5lc3NfcGFuaWMoInVwZ3JhZGUgb2YgdW5s b2NrZWQgbG9jayAoJXMpICVzIEAgJXM6JWQiLAorCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2st PmxvX25hbWUsIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKIAlpZiAod2l0bmVzc193YXRj aCkgewogCQlpZiAoKGluc3RhbmNlLT5saV9mbGFncyAmIExJX0VYQ0xVU0lWRSkgIT0gMCkKLQkJ CXBhbmljKCJ1cGdyYWRlIG9mIGV4Y2x1c2l2ZSBsb2NrICglcykgJXMgQCAlczolZCIsCi0JCQkg ICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUsCi0JCQkgICAgZml4dXBfZmlsZW5hbWUo ZmlsZSksIGxpbmUpOworCQkJd2l0bmVzc19wYW5pYygidXBncmFkZSBvZiBleGNsdXNpdmUgbG9j ayAoJXMpICVzIEAgJXM6JWQiLAorCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1l LCBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CiAJCWlmICgoaW5zdGFuY2UtPmxpX2ZsYWdz ICYgTElfUkVDVVJTRU1BU0spICE9IDApCi0JCQlwYW5pYygidXBncmFkZSBvZiByZWN1cnNlZCBs b2NrICglcykgJXMgcj0lZCBAICVzOiVkIiwKKwkJCXdpdG5lc3NfcGFuaWMoInVwZ3JhZGUgb2Yg cmVjdXJzZWQgbG9jayAoJXMpICVzIHI9JWQgQCAlczolZCIsCiAJCQkgICAgY2xhc3MtPmxjX25h bWUsIGxvY2stPmxvX25hbWUsCi0JCQkgICAgaW5zdGFuY2UtPmxpX2ZsYWdzICYgTElfUkVDVVJT RU1BU0ssCi0JCQkgICAgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOworCQkJICAgIGluc3Rh bmNlLT5saV9mbGFncyAmIExJX1JFQ1VSU0VNQVNLLCBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGlu ZSk7CiAJfQogCWluc3RhbmNlLT5saV9mbGFncyB8PSBMSV9FWENMVVNJVkU7CiB9CkBAIC0xNDc1 LDI5ICsxNDg2LDI0IEBACiAJY2xhc3MgPSBMT0NLX0NMQVNTKGxvY2spOwogCWlmICh3aXRuZXNz X3dhdGNoKSB7CiAJCWlmICgobG9jay0+bG9fZmxhZ3MgJiBMT19VUEdSQURBQkxFKSA9PSAwKQot CQlwYW5pYygiZG93bmdyYWRlIG9mIG5vbi11cGdyYWRhYmxlIGxvY2sgKCVzKSAlcyBAICVzOiVk IiwKLQkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSwKLQkJCSAgICBmaXh1cF9m aWxlbmFtZShmaWxlKSwgbGluZSk7CisJCXdpdG5lc3NfcGFuaWMoImRvd25ncmFkZSBvZiBub24t dXBncmFkYWJsZSBsb2NrICglcykgJXMgQCAlczolZCIsCisJCQkgICAgY2xhc3MtPmxjX25hbWUs IGxvY2stPmxvX25hbWUsIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKIAkJaWYgKChjbGFz cy0+bGNfZmxhZ3MgJiBMQ19TTEVFUExPQ0spID09IDApCi0JCQlwYW5pYygiZG93bmdyYWRlIG9m IG5vbi1zbGVlcCBsb2NrICglcykgJXMgQCAlczolZCIsCi0JCQkgICAgY2xhc3MtPmxjX25hbWUs IGxvY2stPmxvX25hbWUsCi0JCQkgICAgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOworCQkJ d2l0bmVzc19wYW5pYygiZG93bmdyYWRlIG9mIG5vbi1zbGVlcCBsb2NrICglcykgJXMgQCAlczol ZCIsCisJCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUsIGZpeHVwX2ZpbGVuYW1l KGZpbGUpLCBsaW5lKTsKIAl9CiAJaW5zdGFuY2UgPSBmaW5kX2luc3RhbmNlKGN1cnRocmVhZC0+ dGRfc2xlZXBsb2NrcywgbG9jayk7CiAJaWYgKGluc3RhbmNlID09IE5VTEwpCi0JCXBhbmljKCJk b3duZ3JhZGUgb2YgdW5sb2NrZWQgbG9jayAoJXMpICVzIEAgJXM6JWQiLAotCQkgICAgY2xhc3Mt PmxjX25hbWUsIGxvY2stPmxvX25hbWUsCi0JCSAgICBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGlu ZSk7CisJCXdpdG5lc3NfcGFuaWMoImRvd25ncmFkZSBvZiB1bmxvY2tlZCBsb2NrICglcykgJXMg QCAlczolZCIsCisJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSwgZml4dXBfZmls ZW5hbWUoZmlsZSksIGxpbmUpOwogCWlmICh3aXRuZXNzX3dhdGNoKSB7CiAJCWlmICgoaW5zdGFu Y2UtPmxpX2ZsYWdzICYgTElfRVhDTFVTSVZFKSA9PSAwKQotCQkJcGFuaWMoImRvd25ncmFkZSBv ZiBzaGFyZWQgbG9jayAoJXMpICVzIEAgJXM6JWQiLAotCQkJICAgIGNsYXNzLT5sY19uYW1lLCBs b2NrLT5sb19uYW1lLAotCQkJICAgIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJCXdp dG5lc3NfcGFuaWMoImRvd25ncmFkZSBvZiBzaGFyZWQgbG9jayAoJXMpICVzIEAgJXM6JWQiLAor CQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lLCBmaXh1cF9maWxlbmFtZShmaWxl KSwgbGluZSk7CiAJCWlmICgoaW5zdGFuY2UtPmxpX2ZsYWdzICYgTElfUkVDVVJTRU1BU0spICE9 IDApCi0JCQlwYW5pYygiZG93bmdyYWRlIG9mIHJlY3Vyc2VkIGxvY2sgKCVzKSAlcyByPSVkIEAg JXM6JWQiLAorCQkJd2l0bmVzc19wYW5pYygiZG93bmdyYWRlIG9mIHJlY3Vyc2VkIGxvY2sgKCVz KSAlcyByPSVkIEAgJXM6JWQiLAogCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1l LAotCQkJICAgIGluc3RhbmNlLT5saV9mbGFncyAmIExJX1JFQ1VSU0VNQVNLLAotCQkJICAgIGZp eHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJCSAgICBpbnN0YW5jZS0+bGlfZmxhZ3MgJiBM SV9SRUNVUlNFTUFTSywgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCX0KIAlpbnN0YW5j ZS0+bGlfZmxhZ3MgJj0gfkxJX0VYQ0xVU0lWRTsKIH0KQEAgLTE1MDYsMTEgKzE1MTIsMTEgQEAK IHdpdG5lc3NfdW5sb2NrKHN0cnVjdCBsb2NrX29iamVjdCAqbG9jaywgaW50IGZsYWdzLCBjb25z dCBjaGFyICpmaWxlLCBpbnQgbGluZSkKIHsKIAlzdHJ1Y3QgbG9ja19saXN0X2VudHJ5ICoqbG9j a19saXN0LCAqbGxlOwotCXN0cnVjdCBsb2NrX2luc3RhbmNlICppbnN0YW5jZTsKKwlzdHJ1Y3Qg bG9ja19pbnN0YW5jZSAqaW5zdGFuY2UgPSBOVUxMOwogCXN0cnVjdCBsb2NrX2NsYXNzICpjbGFz czsKIAlzdHJ1Y3QgdGhyZWFkICp0ZDsKIAlyZWdpc3Rlcl90IHM7Ci0JaW50IGksIGo7CisJaW50 IGkgPSAwLCBqOwogCiAJaWYgKHdpdG5lc3NfY29sZCB8fCBsb2NrLT5sb193aXRuZXNzID09IE5V TEwgfHwgcGFuaWNzdHIgIT0gTlVMTCkKIAkJcmV0dXJuOwpAQCAtMTUzNyw3ICsxNTQzLDcgQEAK IAkgKiBldmVudHVhbCByZWdpc3RlciBsb2NrcyBhbmQgcmVtb3ZlIHRoZW0uCiAJICovCiAJaWYg KHdpdG5lc3Nfd2F0Y2ggPiAwKQotCQlwYW5pYygibG9jayAoJXMpICVzIG5vdCBsb2NrZWQgQCAl czolZCIsIGNsYXNzLT5sY19uYW1lLAorCQl3aXRuZXNzX3BhbmljKCJsb2NrICglcykgJXMgbm90 IGxvY2tlZCBAICVzOiVkIiwgY2xhc3MtPmxjX25hbWUsCiAJCSAgICBsb2NrLT5sb19uYW1lLCBm aXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CiAJZWxzZQogCQlyZXR1cm47CkBAIC0xNTUwLDE2 ICsxNTU2LDE1IEBACiAJCSAgICBsb2NrLT5sb19uYW1lLCBmaXh1cF9maWxlbmFtZShmaWxlKSwg bGluZSk7CiAJCXByaW50Zigid2hpbGUgZXhjbHVzaXZlbHkgbG9ja2VkIGZyb20gJXM6JWRcbiIs CiAJCSAgICBmaXh1cF9maWxlbmFtZShpbnN0YW5jZS0+bGlfZmlsZSksIGluc3RhbmNlLT5saV9s aW5lKTsKLQkJcGFuaWMoImV4Y2wtPnVzaGFyZSIpOworCQl3aXRuZXNzX3BhbmljKCJleGNsLT51 c2hhcmUiKTsKIAl9CiAJaWYgKChpbnN0YW5jZS0+bGlfZmxhZ3MgJiBMSV9FWENMVVNJVkUpID09 IDAgJiYgd2l0bmVzc193YXRjaCA+IDAgJiYKIAkgICAgKGZsYWdzICYgTE9QX0VYQ0xVU0lWRSkg IT0gMCkgewogCQlwcmludGYoImV4Y2x1c2l2ZSB1bmxvY2sgb2YgKCVzKSAlcyBAICVzOiVkXG4i LCBjbGFzcy0+bGNfbmFtZSwKIAkJICAgIGxvY2stPmxvX25hbWUsIGZpeHVwX2ZpbGVuYW1lKGZp bGUpLCBsaW5lKTsKLQkJcHJpbnRmKCJ3aGlsZSBzaGFyZSBsb2NrZWQgZnJvbSAlczolZFxuIiwK LQkJICAgIGZpeHVwX2ZpbGVuYW1lKGluc3RhbmNlLT5saV9maWxlKSwKKwkJcHJpbnRmKCJ3aGls ZSBzaGFyZSBsb2NrZWQgZnJvbSAlczolZFxuIiwgZml4dXBfZmlsZW5hbWUoaW5zdGFuY2UtPmxp X2ZpbGUpLAogCQkgICAgaW5zdGFuY2UtPmxpX2xpbmUpOwotCQlwYW5pYygic2hhcmUtPnVleGNs Iik7CisJCXdpdG5lc3NfcGFuaWMoInNoYXJlLT51ZXhjbCIpOwogCX0KIAkvKiBJZiB3ZSBhcmUg cmVjdXJzZWQsIHVucmVjdXJzZS4gKi8KIAlpZiAoKGluc3RhbmNlLT5saV9mbGFncyAmIExJX1JF Q1VSU0VNQVNLKSA+IDApIHsKQEAgLTE1NzMsNyArMTU3OCw3IEBACiAJaWYgKChpbnN0YW5jZS0+ bGlfZmxhZ3MgJiBMSV9OT1JFTEVBU0UpICE9IDAgJiYgd2l0bmVzc193YXRjaCA+IDApIHsKIAkJ cHJpbnRmKCJmb3JiaWRkZW4gdW5sb2NrIG9mICglcykgJXMgQCAlczolZFxuIiwgY2xhc3MtPmxj X25hbWUsCiAJCSAgICBsb2NrLT5sb19uYW1lLCBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7 Ci0JCXBhbmljKCJsb2NrIG1hcmtlZCBub3JlbGVhc2UiKTsKKwkJd2l0bmVzc19wYW5pYygibG9j ayBtYXJrZWQgbm9yZWxlYXNlIik7CiAJfQogCiAJLyogT3RoZXJ3aXNlLCByZW1vdmUgdGhpcyBp dGVtIGZyb20gdGhlIGxpc3QuICovCkBAIC0xNjI4LDcgKzE2MzMsNyBAQAogCQkJCXdpdG5lc3Nf bGlzdF9sb2NrKCZsbGUtPmxsX2NoaWxkcmVuW2ldLCBwcmludGYpOwogCQkJCQogCQkJfQotCQlw YW5pYygiVGhyZWFkICVwIGNhbm5vdCBleGl0IHdoaWxlIGhvbGRpbmcgc2xlZXBsb2Nrc1xuIiwg dGQpOworCQl3aXRuZXNzX3BhbmljKCJUaHJlYWQgJXAgY2Fubm90IGV4aXQgd2hpbGUgaG9sZGlu ZyBzbGVlcGxvY2tzXG4iLCB0ZCk7CiAJfQogCXdpdG5lc3NfbG9ja19saXN0X2ZyZWUobGxlKTsK IH0KQEAgLTE3MDksNyArMTcxNCw3IEBACiAJfSBlbHNlCiAJCXNjaGVkX3VucGluKCk7CiAJaWYg KGZsYWdzICYgV0FSTl9QQU5JQyAmJiBuKQotCQlwYW5pYygiJXMiLCBfX2Z1bmNfXyk7CisJCXdp dG5lc3NfcGFuaWMoIiVzIiwgX19mdW5jX18pOwogCWVsc2UKIAkJd2l0bmVzc19kZWJ1Z2dlcihu KTsKIAlyZXR1cm4gKG4pOwpAQCAtMTc1NSw3ICsxNzYwLDcgQEAKIAl9IGVsc2UgaWYgKChsb2Nr X2NsYXNzLT5sY19mbGFncyAmIExDX1NMRUVQTE9DSykpCiAJCXR5cGVsaXN0ID0gJndfc2xlZXA7 CiAJZWxzZQotCQlwYW5pYygibG9jayBjbGFzcyAlcyBpcyBub3Qgc2xlZXAgb3Igc3BpbiIsCisJ CXdpdG5lc3NfcGFuaWMoImxvY2sgY2xhc3MgJXMgaXMgbm90IHNsZWVwIG9yIHNwaW4iLAogCQkg ICAgbG9ja19jbGFzcy0+bGNfbmFtZSk7CiAKIAltdHhfbG9ja19zcGluKCZ3X210eCk7CkBAIC0x Nzg2LDcgKzE3OTEsNyBAQAogCXctPndfcmVmY291bnQrKzsKIAltdHhfdW5sb2NrX3NwaW4oJndf bXR4KTsKIAlpZiAobG9ja19jbGFzcyAhPSB3LT53X2NsYXNzKQotCQlwYW5pYygKKwkJd2l0bmVz c19wYW5pYygKIAkJCSJsb2NrICglcykgJXMgZG9lcyBub3QgbWF0Y2ggZWFybGllciAoJXMpIGxv Y2siLAogCQkJZGVzY3JpcHRpb24sIGxvY2tfY2xhc3MtPmxjX25hbWUsCiAJCQl3LT53X2NsYXNz LT5sY19uYW1lKTsKQEAgLTE5MjAsNyArMTkyNSw3IEBACiAJaWYgKCF3aXRuZXNzX2xvY2tfdHlw ZV9lcXVhbChwYXJlbnQsIGNoaWxkKSkgewogCQlpZiAod2l0bmVzc19jb2xkID09IDApCiAJCQlt dHhfdW5sb2NrX3NwaW4oJndfbXR4KTsKLQkJcGFuaWMoIiVzOiBwYXJlbnQgXCIlc1wiICglcykg YW5kIGNoaWxkIFwiJXNcIiAoJXMpIGFyZSBub3QgIgorCQl3aXRuZXNzX3BhbmljKCIlczogcGFy ZW50IFwiJXNcIiAoJXMpIGFuZCBjaGlsZCBcIiVzXCIgKCVzKSBhcmUgbm90ICIKIAkJICAgICJ0 aGUgc2FtZSBsb2NrIHR5cGUiLCBfX2Z1bmNfXywgcGFyZW50LT53X25hbWUsCiAJCSAgICBwYXJl bnQtPndfY2xhc3MtPmxjX25hbWUsIGNoaWxkLT53X25hbWUsCiAJCSAgICBjaGlsZC0+d19jbGFz cy0+bGNfbmFtZSk7CkBAIC0yMTAyLDggKzIxMDcsOCBAQAogCWlmIChsb2NrLT5sb193aXRuZXNz LT53X25hbWUgIT0gbG9jay0+bG9fbmFtZSkKIAkJcHJudCgiICglcykiLCBsb2NrLT5sb193aXRu ZXNzLT53X25hbWUpOwogCXBybnQoIiByID0gJWQgKCVwKSBsb2NrZWQgQCAlczolZFxuIiwKLQkg ICAgaW5zdGFuY2UtPmxpX2ZsYWdzICYgTElfUkVDVVJTRU1BU0ssIGxvY2ssCi0JICAgIGZpeHVw X2ZpbGVuYW1lKGluc3RhbmNlLT5saV9maWxlKSwgaW5zdGFuY2UtPmxpX2xpbmUpOworCSAgICBp bnN0YW5jZS0+bGlfZmxhZ3MgJiBMSV9SRUNVUlNFTUFTSywgbG9jaywgZml4dXBfZmlsZW5hbWUo aW5zdGFuY2UtPmxpX2ZpbGUpLAorCSAgICBpbnN0YW5jZS0+bGlfbGluZSk7CiB9CiAKICNpZmRl ZiBEREIKQEAgLTIxNzQsMTMgKzIxNzksNiBAQAogCXN0cnVjdCBsb2NrX2luc3RhbmNlICppbnN0 YW5jZTsKIAlzdHJ1Y3QgbG9ja19jbGFzcyAqY2xhc3M7CiAKLQkvKgotCSAqIFRoaXMgZnVuY3Rp b24gaXMgdXNlZCBpbmRlcGVuZGVudGx5IGluIGxvY2tpbmcgY29kZSB0byBkZWFsIHdpdGgKLQkg KiBHaWFudCwgU0NIRURVTEVSX1NUT1BQRUQoKSBjaGVjayBjYW4gYmUgcmVtb3ZlZCBoZXJlIGFm dGVyIEdpYW50Ci0JICogaXMgZ29uZS4KLQkgKi8KLQlpZiAoU0NIRURVTEVSX1NUT1BQRUQoKSkK LQkJcmV0dXJuOwogCUtBU1NFUlQod2l0bmVzc19jb2xkID09IDAsICgiJXM6IHdpdG5lc3NfY29s ZCIsIF9fZnVuY19fKSk7CiAJaWYgKGxvY2stPmxvX3dpdG5lc3MgPT0gTlVMTCB8fCB3aXRuZXNz X3dhdGNoID09IC0xIHx8IHBhbmljc3RyICE9IE5VTEwpCiAJCXJldHVybjsKQEAgLTIxOTQsNyAr MjE5Miw3IEBACiAJfQogCWluc3RhbmNlID0gZmluZF9pbnN0YW5jZShsb2NrX2xpc3QsIGxvY2sp OwogCWlmIChpbnN0YW5jZSA9PSBOVUxMKQotCQlwYW5pYygiJXM6IGxvY2sgKCVzKSAlcyBub3Qg bG9ja2VkIiwgX19mdW5jX18sCisJCXdpdG5lc3NfcGFuaWMoIiVzOiBsb2NrICglcykgJXMgbm90 IGxvY2tlZCIsIF9fZnVuY19fLAogCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUp OwogCSpmaWxlcCA9IGluc3RhbmNlLT5saV9maWxlOwogCSpsaW5lcCA9IGluc3RhbmNlLT5saV9s aW5lOwpAQCAtMjIwNywxMyArMjIwNSw2IEBACiAJc3RydWN0IGxvY2tfaW5zdGFuY2UgKmluc3Rh bmNlOwogCXN0cnVjdCBsb2NrX2NsYXNzICpjbGFzczsKIAotCS8qCi0JICogVGhpcyBmdW5jdGlv biBpcyB1c2VkIGluZGVwZW5kZW50bHkgaW4gbG9ja2luZyBjb2RlIHRvIGRlYWwgd2l0aAotCSAq IEdpYW50LCBTQ0hFRFVMRVJfU1RPUFBFRCgpIGNoZWNrIGNhbiBiZSByZW1vdmVkIGhlcmUgYWZ0 ZXIgR2lhbnQKLQkgKiBpcyBnb25lLgotCSAqLwotCWlmIChTQ0hFRFVMRVJfU1RPUFBFRCgpKQot CQlyZXR1cm47CiAJS0FTU0VSVCh3aXRuZXNzX2NvbGQgPT0gMCwgKCIlczogd2l0bmVzc19jb2xk IiwgX19mdW5jX18pKTsKIAlpZiAobG9jay0+bG9fd2l0bmVzcyA9PSBOVUxMIHx8IHdpdG5lc3Nf d2F0Y2ggPT0gLTEgfHwgcGFuaWNzdHIgIT0gTlVMTCkKIAkJcmV0dXJuOwpAQCAtMjIyNyw3ICsy MjE4LDcgQEAKIAl9CiAJaW5zdGFuY2UgPSBmaW5kX2luc3RhbmNlKGxvY2tfbGlzdCwgbG9jayk7 CiAJaWYgKGluc3RhbmNlID09IE5VTEwpCi0JCXBhbmljKCIlczogbG9jayAoJXMpICVzIG5vdCBs b2NrZWQiLCBfX2Z1bmNfXywKKwkJd2l0bmVzc19wYW5pYygiJXM6IGxvY2sgKCVzKSAlcyBub3Qg bG9ja2VkIiwgX19mdW5jX18sCiAJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSk7 CiAJbG9jay0+bG9fd2l0bmVzcy0+d19maWxlID0gZmlsZTsKIAlsb2NrLT5sb193aXRuZXNzLT53 X2xpbmUgPSBsaW5lOwpAQCAtMjIzOSw3ICsyMjMwLDcgQEAKIHdpdG5lc3NfYXNzZXJ0KHN0cnVj dCBsb2NrX29iamVjdCAqbG9jaywgaW50IGZsYWdzLCBjb25zdCBjaGFyICpmaWxlLCBpbnQgbGlu ZSkKIHsKICNpZmRlZiBJTlZBUklBTlRfU1VQUE9SVAotCXN0cnVjdCBsb2NrX2luc3RhbmNlICpp bnN0YW5jZTsKKwlzdHJ1Y3QgbG9ja19pbnN0YW5jZSAqaW5zdGFuY2UgPSBOVUxMOwogCXN0cnVj dCBsb2NrX2NsYXNzICpjbGFzczsKIAogCWlmIChsb2NrLT5sb193aXRuZXNzID09IE5VTEwgfHwg d2l0bmVzc193YXRjaCA8IDEgfHwgcGFuaWNzdHIgIT0gTlVMTCkKQEAgLTIyNTAsMTUgKzIyNDEs MTQgQEAKIAllbHNlIGlmICgoY2xhc3MtPmxjX2ZsYWdzICYgTENfU1BJTkxPQ0spICE9IDApCiAJ CWluc3RhbmNlID0gZmluZF9pbnN0YW5jZShQQ1BVX0dFVChzcGlubG9ja3MpLCBsb2NrKTsKIAll bHNlIHsKLQkJcGFuaWMoIkxvY2sgKCVzKSAlcyBpcyBub3Qgc2xlZXAgb3Igc3BpbiEiLAorCQl3 aXRuZXNzX3BhbmljKCJMb2NrICglcykgJXMgaXMgbm90IHNsZWVwIG9yIHNwaW4hIiwKIAkJICAg IGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lKTsKIAl9CiAJc3dpdGNoIChmbGFncykgewog CWNhc2UgTEFfVU5MT0NLRUQ6CiAJCWlmIChpbnN0YW5jZSAhPSBOVUxMKQotCQkJcGFuaWMoIkxv Y2sgKCVzKSAlcyBsb2NrZWQgQCAlczolZC4iLAotCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2Nr LT5sb19uYW1lLAotCQkJICAgIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJCXdpdG5l c3NfcGFuaWMoIkxvY2sgKCVzKSAlcyBsb2NrZWQgQCAlczolZC4iLAorCQkJICAgIGNsYXNzLT5s Y19uYW1lLCBsb2NrLT5sb19uYW1lLCBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CiAJCWJy ZWFrOwogCWNhc2UgTEFfTE9DS0VEOgogCWNhc2UgTEFfTE9DS0VEIHwgTEFfUkVDVVJTRUQ6CkBA IC0yMjcwLDM1ICsyMjYwLDI5IEBACiAJY2FzZSBMQV9YTE9DS0VEIHwgTEFfUkVDVVJTRUQ6CiAJ Y2FzZSBMQV9YTE9DS0VEIHwgTEFfTk9UUkVDVVJTRUQ6CiAJCWlmIChpbnN0YW5jZSA9PSBOVUxM KSB7Ci0JCQlwYW5pYygiTG9jayAoJXMpICVzIG5vdCBsb2NrZWQgQCAlczolZC4iLAotCQkJICAg IGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lLAotCQkJICAgIGZpeHVwX2ZpbGVuYW1lKGZp bGUpLCBsaW5lKTsKKwkJCXdpdG5lc3NfcGFuaWMoIkxvY2sgKCVzKSAlcyBub3QgbG9ja2VkIEAg JXM6JWQuIiwKKwkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSwgZml4dXBfZmls ZW5hbWUoZmlsZSksIGxpbmUpOwogCQkJYnJlYWs7CiAJCX0KIAkJaWYgKChmbGFncyAmIExBX1hM T0NLRUQpICE9IDAgJiYKIAkJICAgIChpbnN0YW5jZS0+bGlfZmxhZ3MgJiBMSV9FWENMVVNJVkUp ID09IDApCi0JCQlwYW5pYygiTG9jayAoJXMpICVzIG5vdCBleGNsdXNpdmVseSBsb2NrZWQgQCAl czolZC4iLAotCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lLAotCQkJICAgIGZp eHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJCXdpdG5lc3NfcGFuaWMoIkxvY2sgKCVzKSAl cyBub3QgZXhjbHVzaXZlbHkgbG9ja2VkIEAgJXM6JWQuIiwKKwkJCSAgICBjbGFzcy0+bGNfbmFt ZSwgbG9jay0+bG9fbmFtZSwgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCQlpZiAoKGZs YWdzICYgTEFfU0xPQ0tFRCkgIT0gMCAmJgogCQkgICAgKGluc3RhbmNlLT5saV9mbGFncyAmIExJ X0VYQ0xVU0lWRSkgIT0gMCkKLQkJCXBhbmljKCJMb2NrICglcykgJXMgZXhjbHVzaXZlbHkgbG9j a2VkIEAgJXM6JWQuIiwKLQkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSwKLQkJ CSAgICBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CisJCQl3aXRuZXNzX3BhbmljKCJMb2Nr ICglcykgJXMgZXhjbHVzaXZlbHkgbG9ja2VkIEAgJXM6JWQuIiwKKwkJCSAgICBjbGFzcy0+bGNf bmFtZSwgbG9jay0+bG9fbmFtZSwgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCQlpZiAo KGZsYWdzICYgTEFfUkVDVVJTRUQpICE9IDAgJiYKIAkJICAgIChpbnN0YW5jZS0+bGlfZmxhZ3Mg JiBMSV9SRUNVUlNFTUFTSykgPT0gMCkKLQkJCXBhbmljKCJMb2NrICglcykgJXMgbm90IHJlY3Vy c2VkIEAgJXM6JWQuIiwKLQkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSwKLQkJ CSAgICBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CisJCQl3aXRuZXNzX3BhbmljKCJMb2Nr ICglcykgJXMgbm90IHJlY3Vyc2VkIEAgJXM6JWQuIiwKKwkJCSAgICBjbGFzcy0+bGNfbmFtZSwg bG9jay0+bG9fbmFtZSwgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCQlpZiAoKGZsYWdz ICYgTEFfTk9UUkVDVVJTRUQpICE9IDAgJiYKIAkJICAgIChpbnN0YW5jZS0+bGlfZmxhZ3MgJiBM SV9SRUNVUlNFTUFTSykgIT0gMCkKLQkJCXBhbmljKCJMb2NrICglcykgJXMgcmVjdXJzZWQgQCAl czolZC4iLAotCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lLAotCQkJICAgIGZp eHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJCXdpdG5lc3NfcGFuaWMoIkxvY2sgKCVzKSAl cyByZWN1cnNlZCBAICVzOiVkLiIsCisJCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25h bWUsIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKIAkJYnJlYWs7CiAJZGVmYXVsdDoKLQkJ cGFuaWMoIkludmFsaWQgbG9jayBhc3NlcnRpb24gYXQgJXM6JWQuIiwKLQkJICAgIGZpeHVwX2Zp bGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJd2l0bmVzc19wYW5pYygiSW52YWxpZCBsb2NrIGFzc2Vy dGlvbiBhdCAlczolZC4iLCBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CiAKIAl9CiAjZW5k aWYJLyogSU5WQVJJQU5UX1NVUFBPUlQgKi8KQEAgLTIzMjMsNyArMjMwNyw3IEBACiAJfQogCWlu c3RhbmNlID0gZmluZF9pbnN0YW5jZShsb2NrX2xpc3QsIGxvY2spOwogCWlmIChpbnN0YW5jZSA9 PSBOVUxMKQotCQlwYW5pYygiJXM6IGxvY2sgKCVzKSAlcyBub3QgbG9ja2VkIiwgX19mdW5jX18s CisJCXdpdG5lc3NfcGFuaWMoIiVzOiBsb2NrICglcykgJXMgbm90IGxvY2tlZCIsIF9fZnVuY19f LAogCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUpOwogCiAJaWYgKHNldCkK --14dae93b5780f1b3ca04ce8294f5-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 08:33:02 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B084B23; Thu, 15 Nov 2012 08:33:02 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id 8AD298FC16; Thu, 15 Nov 2012 08:33:01 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qAF8WoBQ025930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2012 19:32:51 +1100 Date: Thu, 15 Nov 2012 19:32:50 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Jung-uk Kim Subject: Re: [RFC] Generic population count function In-Reply-To: <50A43B52.8030102@FreeBSD.org> Message-ID: <20121115181009.D42162@besplex.bde.org> References: <50A43B52.8030102@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-Cloudmark-Score: 0 X-Optus-Cloudmark-Analysis: v=2.0 cv=eqGHVfVX c=1 sm=1 a=nz2LO5XVLtEA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=hMQG39urcAQA:10 a=6I5d2MoRAAAA:8 a=Y1UM5pQ7PpipOtpjvNUA:9 a=CjuIK1q_8ugA:10 a=3M_0ICQ7WrFIE0d4:21 a=Ei4GSbzkcvkxRff1:21 a=bxQHXO5Py4tHmhUgaywp5w==:117 Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 08:33:02 -0000 On Wed, 14 Nov 2012, Jung-uk Kim wrote: > I implemented generic population count function. Please see the > attachment. It is also available from here: > > http://people.freebsd.org/~jkim/bitcount.diff > > The idea is to make use of CPU-supported population count instructions > if available and the compiler supports them (i.e., clang), especially > for larger than 32-bit data. The patch also has use cases for the new > function (i.e., counting number of bits in IPv6 address[*]). > > Any objection? This is rather over-engineered for something that is used once or twice, but it is good to move the functions out of sys/systm.h where they weren't even usable outside the kernel. The implementation of the ffs() family has similar non-problems. No one cares because they are rarely used, but... cperciva@ wrote the lookup table part of the following set of implementations of ffs() and fls(). A lookup table is the best general method, though it can be beaten by unportable methodw in some cases. I added more methods and a test framework to this (test framework not always included). The methods are: - gcc builtin - cpufunc inline - ilog inline for fls only (repeat some internals of ilogb(3)) - ilogb library for fls only (just use the standard function ilogb()). This and the last method might not handle all cases correctly (especially when FPU traps are enabled). Otherwise, they are much better than the loops in the portable implementation in libc, up to 53 bits. 64 bits are also easy if the system has real long doubles. - ilogbm0 inline (alternative of previous) - library ffs()/fls() - alternative library fls() - lookup table for ffs() only (orginal cperciva@) method). @ #include @ @ #if defined(CPUFUNC_FFS) || defined(CPUFUNC_FLS) @ #define _KERNEL /* now needed to get non-builtin */ @ #include @ /* MI library versions: */ @ #elif ILOGBM0_FLS @ #include "/usr/src/lib/msun/src/s_ilogb.c" @ #elif LIBMET0_FLS @ #include "/usr/src/lib/libc/string/ffs.c" @ #elif LIBMET0_FFS @ #include "/usr/src/lib/libc/string/fls.c" @ #endif @ @ #include @ #include @ #include @ @ static int ffslut32[32]; @ @ static inline int @ ilog_fls(int x) @ { @ union { @ float fvalue; @ uint32_t uvalue; @ } u; @ @ if (x <= 0) @ return (x == 0 ? 0 : 32); @ u.fvalue = x; @ return ((u.uvalue >> 23) - 127 + 1); This is hacked too much for efficiency. Conversion to float can't overflow for 32-bit ints, but it gives rounding problems. I now know more about what made this slow using doubles and how to avoid the slowness using integer SSE packing instructions. Unfortunately, compilers don't understand this. (amd64 will use FP SSE and not be slow). As mentioned above, this is portable up to 53 bits, so on 32-bit systems it may be extendable to work on 64-bit integers or arrays of uint32_t and be signficantly faster than hardware 32-bit instructions then. But repacking for this would be painful. @ } @ @ static inline int @ ilogb_fls(int x) @ { @ return (x == 0 ? 0 : ilogbf(x) + 1); @ } @ @ static inline int @ lut_ffs(int mask) @ { @ return (mask ? ffslut32[(((mask & (-mask)) * 0x0FB9AC52) >> 27) + 16] : 0); @ } The lookup table method is not the trivial lookup 8 bits at a time followed by large code to select the first nonzero set of 8 bits. It magically reduces from 32 bits to 5 for a single lookup. popcount() is easier with a trivial method (just add up the results). I don't know if it can be reduced to a single 5-bit lookup. @ @ int z[4096]; @ @ main() @ { @ volatile int v; @ int i, j; @ @ for (j = 0; j < 32; j++) { @ i = 1 << j; @ ffslut32[(((i & -i) * 0x0FB9AC52) >> 27) + 16] = j + 1; @ } @ for (i = 0; i < 4096; i++) @ #ifdef UNIFORM @ z[i] = random(); @ #elif RANDBIT @ z[i] = 1 << random(); /* Yes, this is sloppy. */ @ #elif ALLZERO @ continue; @ #elif ALLONE_ @ z[i] = 1; @ #elif ALLLAST @ z[i] = 1 << 31; /* More sloppiness. */ @ #else @ #error "No distribution" @ continue; @ #endif @ for (j = 0; j < 10000; j++) @ for (i = 0; i < 4096; i++) @ #ifdef BUILTIN_FFS @ v = __builtin_ffs(z[i]); @ #elif CPUFUNC_FFS @ v = ffs(z[i]); @ #elif CPUFUNC_FLS @ v = fls(z[i]); @ #elif ILOGMET_FLS @ v = ilog_fls(z[i]); @ #elif ILOGBME_FLS @ v = ilogb_fls(z[i]); @ #elif ILOGBM0_FLS @ v = ilogb_fls(z[i]); @ #elif LIBMET0_FFS @ v = ffs(z[i]); @ #elif LIBMET0_FLS @ v = fls(z[i]); @ #elif LIBMETH_FFS @ v = ffs(z[i]); @ #elif LIBMETH_FLS @ v = fls(z[i]); @ #elif LUTMETH_FFS @ v = lut_ffs(z[i]); @ #else @ #error "No method" @ ; @ #endif @ #ifdef PRINTLUT @ for (j = 0; j < 32; j++) { @ i = 1 << j; @ printf("%5d: %d %d\n", j, lut_ffs(j), @ (((i & -i) * 0x0FB9AC52) >> 27) + 16); @ #endif @ #ifdef TEST @ for (j = 0; ; j++) { @ if (lut_ffs(j) != __builtin_ffs(j)) @ fprintf(stderr, "lut_ffs(%d) failed: %d %d\n", @ j, lut_ffs(j), __builtin_ffs(j)); @ if (ilog_fls(j) != fls(j)) @ fprintf(stderr, "ilog_fls(%d) failed: %d %d\n", @ j, ilogb_fls(j), fls(j)); @ if (j + 1 == 0) @ break; @ } @ #endif @ } In a game program, I use simple lookups of 13-bit ints to count cards and find the highest card in 13-bit sets of suits of cards. This works better than any hardware method (especially when there is none, but I would have used gcc builtin fls() if it were faster, or maybe I didn't care since the program has lots of tables and one more to give a fast portable fls() was simplest). I only noticed the following in your version: - including is a style bug because sys/types.h includes it - you removed the silly special inline for bitcount16() but still implement bitcount16(), presumably for compatibiltiy. But it is incompatible since the old version has the bogus return type uint16_t. It seems to be used just twice: in intel_sdvo.c, it is blindly converted to bool in 1 place and to unsigned int in 1 place. Both of these uses are for device initialization so their efficiency is especially uniportant. - bitcount32() is also incompatible since the old version has the slightly less bogus return type uint32_t. At least the args have correct type, unlike the ffs() family. Bruce From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 13:27:35 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90B2F502; Thu, 15 Nov 2012 13:27:35 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0D2A18FC0C; Thu, 15 Nov 2012 13:27:34 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so1277747qcs.13 for ; Thu, 15 Nov 2012 05:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kjp9lZN2nPy3aTeCO34QPAJrwBvbhN2Gcdqfz/q9588=; b=MelmHWl1d6Ri1A+qjO/0uSUpCfC8YkuYIL12cqmGtERcuuG+89aJ4Iz//rHTQVIQEG 7HIZN1leMQyrDq0H7ymD5KpszHo5Qkow0Py2J88liumlEJadAv9MCYu0dNedvgyR0IqF Z6THrbrqwkEjMTcqXghg0yjMwVJ1Lsj7uU/KOMYS1jmF/sYZFAXdJXgpUfoJ7Wr8kNgA 2oMa1ODCxilaEZnJVzW3HPVA+/CmoeTSfD4vJrHAcOgT+aZiJCaucrFreofYdiGDSYVk 5rXpjlEibKhdoheRuNUX1izGEhqXmGCNG7OouSlIXc4cvHFUkBa7jS4g9pIVPLgoJpTI 3b4A== MIME-Version: 1.0 Received: by 10.224.194.134 with SMTP id dy6mr1044256qab.81.1352986053363; Thu, 15 Nov 2012 05:27:33 -0800 (PST) Received: by 10.229.117.1 with HTTP; Thu, 15 Nov 2012 05:27:33 -0800 (PST) In-Reply-To: References: Date: Thu, 15 Nov 2012 14:27:33 +0100 Message-ID: Subject: Re: [RFQ] make witness panic an option From: Giovanni Trematerra To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 13:27:35 -0000 On Thu, Nov 15, 2012 at 7:15 AM, Adrian Chadd wrote: > Hi all, > > When debugging and writing wireless drivers/stack code, I like to > sprinkle lots of locking assertions everywhere. However, this does > cause things to panic quite often during active development. > > This patch (against stable/9) makes the actual panic itself > configurable. It still prints the message regardless. > This has allowed me to sprinkle more locking assertions everywhere to > investigate whether particular paths have been hit or not. I don't > necessarily want those to panic the kernel. > > I'd like everyone to consider this for FreeBSD-HEAD. I really do think that is a very bad idea. When a locking assertion fails you have just to stop your mind and think what's wrong, no way to postpone on this. -- Gianni From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 16:37:51 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BE3E36B5; Thu, 15 Nov 2012 16:37:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 85F538FC0C; Thu, 15 Nov 2012 16:37:51 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kp6so1279899pab.13 for ; Thu, 15 Nov 2012 08:37:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Hax9OoliXpccxGrtLR2vkRCIXBxNG1yKwlvMk0RUXRc=; b=YUxsYsXpQYRrHi8ba8waS60qRly4mwRxmt8wvejHSObD5gp5uo0QLvl3gZUbH1yQQ9 mVZY647PS18OjpK3XpxHTyVDLu49JITMnAiZVqAppZB/nmBQxlvqYs6yi3yLM3ndQuEf Q6InGF7axUveopUVKrQATrsmzCNqTrT7/CiwJya0rjRFcFWk9cU0XLg3nsWWD/PKImGU rZo0u8E65t34ewA2anP9XQpPBqGbpVkAlCRyEVhh6unq8HmWKIh3wARjvy2ci1NdBefm XEA7z72KoiK4iF5oXVrJcpM63EEGltKsFabjzkX6v+WvMCKKM/fxYGt9C/NlGwccISku vTcA== MIME-Version: 1.0 Received: by 10.66.85.134 with SMTP id h6mr4714259paz.36.1352997471336; Thu, 15 Nov 2012 08:37:51 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Thu, 15 Nov 2012 08:37:51 -0800 (PST) In-Reply-To: References: Date: Thu, 15 Nov 2012 08:37:51 -0800 X-Google-Sender-Auth: t1znI8gbjtaOqflWpgDKI8n8H7s Message-ID: Subject: Re: [RFQ] make witness panic an option From: Adrian Chadd To: Giovanni Trematerra Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 16:37:51 -0000 On 15 November 2012 05:27, Giovanni Trematerra wrote: > I really do think that is a very bad idea. > When a locking assertion fails you have just to stop your mind and > think what's wrong, > no way to postpone on this. Not all witness panics are actually fatal. For a developer who is sufficiently cluey in their area, they are quite likely able to just stare at the code paths for a while to figure out why the incorrectness occured. As I said, I do this primarily so I can sprinkle lots of lock owned/unowned assertions around my driver(s) and then use that to catch when things aren't being correct. Having to reboot upon _every_ lock assertion quickly got old. Adrian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 16:39:58 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23A7792D; Thu, 15 Nov 2012 16:39:58 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3821C8FC08; Thu, 15 Nov 2012 16:39:56 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so1730127lah.13 for ; Thu, 15 Nov 2012 08:39:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Dm8wzhvVjwZHDAUWyfOaV34sC0YK7PLTTtxqJBJVjVY=; b=amuffdSsc1OvbxmqYBOusT1dRYIxigWVRJhkxeOAz6eW/B4XtnKqqZVLyPoIx0ksx1 xOYfhsZDY2wjXAheIZsS82CYN0m+h2UNBltPaP2e8MbwONrUTTrS9KhVaMXr0qIDZCW9 uxEMUQOR0EVPaNOZogn16DGk+/pH8cH4cH+70NovUaDTMnQH6N+UPQKJljnUmcxFXxfX naN3IGKih5RzoK3CqdTGicBr3to3GdW9pzFLN6frmANy16zceCzn6b6N59z5KdAI+7cz 13/3LLffBkLS6It5WH/LMoaRvyXQcCk14Vm9edOWF1Mco+zVxWJHtf2oCnw7JyXetIkC 67XA== MIME-Version: 1.0 Received: by 10.152.132.3 with SMTP id oq3mr1598733lab.18.1352997596012; Thu, 15 Nov 2012 08:39:56 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 08:39:55 -0800 (PST) In-Reply-To: References: Date: Thu, 15 Nov 2012 16:39:55 +0000 X-Google-Sender-Auth: l4M5Za3t4iOfBIVQh5SEs-Izwcs Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Giovanni Trematerra , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 16:39:58 -0000 On 11/15/12, Adrian Chadd wrote: > On 15 November 2012 05:27, Giovanni Trematerra > wrote: > >> I really do think that is a very bad idea. >> When a locking assertion fails you have just to stop your mind and >> think what's wrong, >> no way to postpone on this. > > Not all witness panics are actually fatal. For a developer who is > sufficiently cluey in their area, they are quite likely able to just > stare at the code paths for a while to figure out why the > incorrectness occured. The problem is that such mechanism can be abused, just like the BLESSING one and that's why this is disabled by default. I believe having a mechanism to use printf for witness is not a good idea. > As I said, I do this primarily so I can sprinkle lots of lock > owned/unowned assertions around my driver(s) and then use that to > catch when things aren't being correct. Having to reboot upon _every_ > lock assertion quickly got old. You can use it as a local patch then. This is not really the usual way to develop locking policies. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 17:39:46 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C439FE05; Thu, 15 Nov 2012 17:39:46 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 903FB8FC12; Thu, 15 Nov 2012 17:39:46 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qAFHdcDt039031; Thu, 15 Nov 2012 10:39:38 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qAFHdZMB024995; Thu, 15 Nov 2012 10:39:35 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: [RFQ] make witness panic an option From: Ian Lepore To: Adrian Chadd In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Nov 2012 10:39:35 -0700 Message-ID: <1353001175.1217.153.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:39:46 -0000 On Wed, 2012-11-14 at 22:15 -0800, Adrian Chadd wrote: > Hi all, > > When debugging and writing wireless drivers/stack code, I like to > sprinkle lots of locking assertions everywhere. However, this does > cause things to panic quite often during active development. > > This patch (against stable/9) makes the actual panic itself > configurable. It still prints the message regardless. > > This has allowed me to sprinkle more locking assertions everywhere to > investigate whether particular paths have been hit or not. I don't > necessarily want those to panic the kernel. > > I'd like everyone to consider this for FreeBSD-HEAD. > > Thanks! I strongly support this, because I'm tired of having to hack it in by hand every time I need it. You can't boot an arm platform right now (on freebsd 8, 9, or 10) without a LOR very early in the boot. Once you get past that, 2 or 3 device drivers I use panic way before we even get to mounting root. Those panics can clearly be ignored, because we've been shipping products for years based on this code. (It's on my to-do list to fix them, but more pressing problems are higher on the list.) When a new problem crops up that isn't harmless, it totally sucks that I can't just turn on witness without first hacking the code to make the known problems non-panicky. -- Ian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 17:48:00 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A824975; Thu, 15 Nov 2012 17:48:00 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id BF46C8FC12; Thu, 15 Nov 2012 17:47:59 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so1803763lah.13 for ; Thu, 15 Nov 2012 09:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Xw6bdC+I6eFvkTXqwe+Mo9bEXEeVNz0MqNR4heZsnOk=; b=N9Gwly5kod5mO29CnLO8nyvOhkfhF556UHnKZi/wd0FLvllKajx+KSHvHsm3GkYa97 VcnnV3sDXLoXSuaxN5IOwNMtrrrBEw1RFlIXgDpsVES0itXR9d96T5QSPOc6ictejUl0 1u5/VOQNi7l2P7lJzoxP0jbjTApgK4TdYPxXdId6hI9R1g7MQJRx7CzXoRGi02pGneqL aRJcM9jpRVodpD1KgMcNmk2yBtupKINTxcb3rhUv1sp676evlItueRQHXBmbfDpXihze 0TxbD2BEC4iYA5DyZbsePWfHjRwA2Vi61zhjCRRjSM58OyjLZUq1MwP/WQDwvX7/60ye DCuQ== MIME-Version: 1.0 Received: by 10.152.110.234 with SMTP id id10mr1839112lab.15.1353001678357; Thu, 15 Nov 2012 09:47:58 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 09:47:58 -0800 (PST) In-Reply-To: <1353001175.1217.153.camel@revolution.hippie.lan> References: <1353001175.1217.153.camel@revolution.hippie.lan> Date: Thu, 15 Nov 2012 17:47:58 +0000 X-Google-Sender-Auth: acsIoPDz87qrn1kfVH81V7-EOkQ Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, Adrian Chadd , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:48:00 -0000 On 11/15/12, Ian Lepore wrote: > On Wed, 2012-11-14 at 22:15 -0800, Adrian Chadd wrote: >> Hi all, >> >> When debugging and writing wireless drivers/stack code, I like to >> sprinkle lots of locking assertions everywhere. However, this does >> cause things to panic quite often during active development. >> >> This patch (against stable/9) makes the actual panic itself >> configurable. It still prints the message regardless. >> >> This has allowed me to sprinkle more locking assertions everywhere to >> investigate whether particular paths have been hit or not. I don't >> necessarily want those to panic the kernel. >> >> I'd like everyone to consider this for FreeBSD-HEAD. >> >> Thanks! > > I strongly support this, because I'm tired of having to hack it in by > hand every time I need it. > > You can't boot an arm platform right now (on freebsd 8, 9, or 10) > without a LOR very early in the boot. Once you get past that, 2 or 3 > device drivers I use panic way before we even get to mounting root. > Those panics can clearly be ignored, because we've been shipping > products for years based on this code. (It's on my to-do list to fix > them, but more pressing problems are higher on the list.) This is a ridicolous motivation. What are the panics in question? Why they are not fixed yet? Without WITNESS_KDB you should not panic even in cases where WITNESS yells. So if you do, it means there is a more subdole breakage going on here. Do you really think that an abusable mechanism will help here rather than fixing the actual problems? > When a new problem crops up that isn't harmless, it totally sucks that I > can't just turn on witness without first hacking the code to make the > known problems non-panicky. I really don't understand what are these "harmless problems" here. I just know one and it is between the dirhash lock and the bufwait lock for UFS, which is carefully documented in the code comments. All the others cases haven't been analyzed deeply enough to quantify them as "harmless". Can you please make real examples? Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 17:56:23 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC10629B for ; Thu, 15 Nov 2012 17:56:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7A22A8FC0C for ; Thu, 15 Nov 2012 17:56:23 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so2411813obc.13 for ; Thu, 15 Nov 2012 09:56:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Q8SFrS7WLIfT9llpZ/gg0GR2wFSWpUMEED98gONNncI=; b=B9jw4lkhN3iw1hnAoViVfoaWjFDbrrvp9JFgq+W0YcbYEb+KNfGGwDdreE3dAuI7pO 6Lq3GQNOBYDMetwTU1bKRLRFhDM+96Z/Kefvi/Hd2Qu9e/VzjnNRDn7xZILpGM4XnTTr jV1QRtIw94a5/I4irurh0IxxIXi28Jy3Y6dqaRa0DwbNtiezX0GZR0hmy6CE0Wjpm9Zc Z8kzFQCXZxRRhO00UK0HjN49WiMak23TIDNmwiTENuj4tyS7TIn6C0/NqAX/f9NiYRX1 k037m4FaKyS9n33xH8aBjKegOJhMhHjrcsCPKb3O2y0ahibNPH7NQwjh7rfoEAgwpQCc LlVg== Received: by 10.60.10.133 with SMTP id i5mr1574894oeb.11.1353002182724; Thu, 15 Nov 2012 09:56:22 -0800 (PST) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id m8sm12902611oeb.3.2012.11.15.09.56.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 09:56:21 -0800 (PST) Sender: Warner Losh Subject: Re: [RFQ] make witness panic an option Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Thu, 15 Nov 2012 10:56:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> References: <1353001175.1217.153.camel@revolution.hippie.lan> To: attilio@FreeBSD.org X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQk7VNlx2LixyO5ZiN5kYEAUhSTp7OuO5F5eVx8GYT61GV2nFfbl5Sv9iBfKnCuBfLr4BQpy Cc: Ian Lepore , Adrian Chadd , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:56:24 -0000 On Nov 15, 2012, at 10:47 AM, Attilio Rao wrote: > On 11/15/12, Ian Lepore wrote: >> On Wed, 2012-11-14 at 22:15 -0800, Adrian Chadd wrote: >>> Hi all, >>>=20 >>> When debugging and writing wireless drivers/stack code, I like to >>> sprinkle lots of locking assertions everywhere. However, this does >>> cause things to panic quite often during active development. >>>=20 >>> This patch (against stable/9) makes the actual panic itself >>> configurable. It still prints the message regardless. >>>=20 >>> This has allowed me to sprinkle more locking assertions everywhere = to >>> investigate whether particular paths have been hit or not. I don't >>> necessarily want those to panic the kernel. >>>=20 >>> I'd like everyone to consider this for FreeBSD-HEAD. >>>=20 >>> Thanks! >>=20 >> I strongly support this, because I'm tired of having to hack it in by >> hand every time I need it. >>=20 >> You can't boot an arm platform right now (on freebsd 8, 9, or 10) >> without a LOR very early in the boot. Once you get past that, 2 or 3 >> device drivers I use panic way before we even get to mounting root. >> Those panics can clearly be ignored, because we've been shipping >> products for years based on this code. (It's on my to-do list to fix >> them, but more pressing problems are higher on the list.) >=20 > This is a ridicolous motivation. > What are the panics in question? Why they are not fixed yet? > Without WITNESS_KDB you should not panic even in cases where WITNESS > yells. So if you do, it means there is a more subdole breakage going > on here. >=20 > Do you really think that an abusable mechanism will help here rather > than fixing the actual problems? >=20 >> When a new problem crops up that isn't harmless, it totally sucks = that I >> can't just turn on witness without first hacking the code to make the >> known problems non-panicky. >=20 > I really don't understand what are these "harmless problems" here. > I just know one and it is between the dirhash lock and the bufwait > lock for UFS, which is carefully documented in the code comments. All > the others cases haven't been analyzed deeply enough to quantify them > as "harmless". >=20 > Can you please make real examples? It sounds like he's more worried about introducing LoRs into his = wireless code. They are harmless, for him, and he can fix them by = reloading the driver. They are only harmful if he loses a race. Warner= From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 17:58:30 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 410E643E; Thu, 15 Nov 2012 17:58:30 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 447438FC0C; Thu, 15 Nov 2012 17:58:28 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so1891590lbb.13 for ; Thu, 15 Nov 2012 09:58:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/784YJ7P0phbTjZnjIudSY1gbTQjewTS+Tc82oaldHY=; b=ZYIXLC5POxipwbcNZys+dSrFMEwu1MeF4EZneJo3NuD+9wESecjwsP2rc9aWUgWuDm gER40RsNvquk67EU377fzkbwhp4S9DXY3MktXfH5vAxJASmFII3gPGp9/aKf+cW3DkuN 5rkIwRHJN+Be777VrgVd/9J0/a3YP84khxxUfzE4cDQ+VC5kKUrQRsTvdEmflQF+rS2F jh//SWHM/2Gwr77bnHR3osvT5nhaCp6VTKdJOmcBNcw6oUbZkDVrNI3HJt+bdFz95nmB ezUHQMk0gYbefFP5Jj1Hc9J9wbfR4szsqpPbdd73XuKsVZC2LVhQMsOP8gcMKfMC0WfR RzfQ== MIME-Version: 1.0 Received: by 10.152.110.234 with SMTP id id10mr1866385lab.15.1353002307844; Thu, 15 Nov 2012 09:58:27 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 09:58:27 -0800 (PST) In-Reply-To: <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> References: <1353001175.1217.153.camel@revolution.hippie.lan> <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> Date: Thu, 15 Nov 2012 17:58:27 +0000 X-Google-Sender-Auth: jS2zDfgxw6VU2nTA6v7jwLNjc20 Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Warner Losh Content-Type: text/plain; charset=UTF-8 Cc: Ian Lepore , Adrian Chadd , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:58:30 -0000 On 11/15/12, Warner Losh wrote: > > On Nov 15, 2012, at 10:47 AM, Attilio Rao wrote: > >> On 11/15/12, Ian Lepore wrote: >>> On Wed, 2012-11-14 at 22:15 -0800, Adrian Chadd wrote: >>>> Hi all, >>>> >>>> When debugging and writing wireless drivers/stack code, I like to >>>> sprinkle lots of locking assertions everywhere. However, this does >>>> cause things to panic quite often during active development. >>>> >>>> This patch (against stable/9) makes the actual panic itself >>>> configurable. It still prints the message regardless. >>>> >>>> This has allowed me to sprinkle more locking assertions everywhere to >>>> investigate whether particular paths have been hit or not. I don't >>>> necessarily want those to panic the kernel. >>>> >>>> I'd like everyone to consider this for FreeBSD-HEAD. >>>> >>>> Thanks! >>> >>> I strongly support this, because I'm tired of having to hack it in by >>> hand every time I need it. >>> >>> You can't boot an arm platform right now (on freebsd 8, 9, or 10) >>> without a LOR very early in the boot. Once you get past that, 2 or 3 >>> device drivers I use panic way before we even get to mounting root. >>> Those panics can clearly be ignored, because we've been shipping >>> products for years based on this code. (It's on my to-do list to fix >>> them, but more pressing problems are higher on the list.) >> >> This is a ridicolous motivation. >> What are the panics in question? Why they are not fixed yet? >> Without WITNESS_KDB you should not panic even in cases where WITNESS >> yells. So if you do, it means there is a more subdole breakage going >> on here. >> >> Do you really think that an abusable mechanism will help here rather >> than fixing the actual problems? >> >>> When a new problem crops up that isn't harmless, it totally sucks that I >>> can't just turn on witness without first hacking the code to make the >>> known problems non-panicky. >> >> I really don't understand what are these "harmless problems" here. >> I just know one and it is between the dirhash lock and the bufwait >> lock for UFS, which is carefully documented in the code comments. All >> the others cases haven't been analyzed deeply enough to quantify them >> as "harmless". >> >> Can you please make real examples? > > It sounds like he's more worried about introducing LoRs into his wireless > code. They are harmless, for him, and he can fix them by reloading the > driver. They are only harmful if he loses a race. Without WITNESS_KDB the kernel won't panic if this is really the case, if it is only about LOR yelling. Otherwise the breakage is more serious and I would like to see a real case example. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 17:59:14 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 930BB5D5; Thu, 15 Nov 2012 17:59:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 52DCD8FC08; Thu, 15 Nov 2012 17:59:14 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so827459dad.13 for ; Thu, 15 Nov 2012 09:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lsTSqNwiglElUieJ8bqooKQr4sX4OF18lf04F75MTy8=; b=S8mPUyxGDmIVc8HeV1VfUdXHyup/tYBUkHsd3yqpmnN7IZPruYAPeG4wDDEG/+VytK 0LbCnfDICDl3dBD9K+4cgOMIhygxEc5BtYssIzW8xRC44egjO4HNM65b5tU9D3ME9pSZ eHPCfbq/IXmsRPLBnUcGx43QUzRvv5IKebGokwaSrfYjIWAXOsvu/CWtypTueDHr/RBs EfK8a7NOb6bEdfWzHj51MczjofdPEgNLG/m852o0Xx5w5pQZjD5WOwHoEyk5l6zX6bn+ TPHGsPqULygUHSaRs6UAsDvPKP+juAJF0+zaKPKv4PVH3uOBFUUkcoPMBPNBkPFKVAxO iokg== MIME-Version: 1.0 Received: by 10.68.247.134 with SMTP id ye6mr1210085pbc.69.1353002348592; Thu, 15 Nov 2012 09:59:08 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Thu, 15 Nov 2012 09:59:08 -0800 (PST) In-Reply-To: <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> References: <1353001175.1217.153.camel@revolution.hippie.lan> <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> Date: Thu, 15 Nov 2012 09:59:08 -0800 X-Google-Sender-Auth: od1Pefj0sjviGAww4NVES9DFaL4 Message-ID: Subject: Re: [RFQ] make witness panic an option From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: attilio@freebsd.org, Ian Lepore , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:59:14 -0000 On 15 November 2012 09:56, Warner Losh wrote: >> Do you really think that an abusable mechanism will help here rather > It sounds like he's more worried about introducing LoRs into his wireless code. They are harmless, for him, and he can fix them by reloading the driver. They are only harmful if he loses a race. LOR's and lock assertions. Ie, I want to find out at run time that a lock wasnt' held at a certain position but continue soldiering on. That's how I've been finding out all of the races in net80211/ath, as there wasn't locking where there needed to be. Adrian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 18:01:19 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E347678E; Thu, 15 Nov 2012 18:01:19 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id E8C6E8FC0C; Thu, 15 Nov 2012 18:01:17 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so1894894lbb.13 for ; Thu, 15 Nov 2012 10:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=47n18/O51NP7s5CydvLVUh0eppMNfXXPtS1svfyXOOg=; b=tB/cY1xKjHlShukor721m4HLSpkLxrNFUaOLsNOJDWZb5xZd0vM/sZ7dByyd4rur/B B29ORtErxXYPAVEge6mgvag4/IQ4PuWoQBHENjcS2BtGNGyWiEqLQZ8vIzib9QksD89j 1mdRhl3KksKXKvaTJC8W47oKCVXh3BqprvENuRn2cuCmdAIJC5F61EcUX48S4OYahnEM HOViSfVAvJDkL/o5le6/rE8zInKBnIY6aGzYmAEGoI4BpakMNwqtoZMXNE2RwiKetUx/ 9s04vLB6IwQfs/XB5rZ3GQ1duclDsbF1FclbM6+Wj0W1NYsnIoQ9u8nCx9B+0zc5Cpba 258g== MIME-Version: 1.0 Received: by 10.112.47.129 with SMTP id d1mr906520lbn.115.1353002476703; Thu, 15 Nov 2012 10:01:16 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 10:01:16 -0800 (PST) In-Reply-To: References: <1353001175.1217.153.camel@revolution.hippie.lan> <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> Date: Thu, 15 Nov 2012 18:01:16 +0000 X-Google-Sender-Auth: ffz8GaTNpAB9qgttem20d2ZLAM0 Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: Ian Lepore , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:01:20 -0000 On 11/15/12, Adrian Chadd wrote: > On 15 November 2012 09:56, Warner Losh wrote: > >>> Do you really think that an abusable mechanism will help here rather > >> It sounds like he's more worried about introducing LoRs into his wireless >> code. They are harmless, for him, and he can fix them by reloading the >> driver. They are only harmful if he loses a race. > > LOR's and lock assertions. Ie, I want to find out at run time that a > lock wasnt' held at a certain position but continue soldiering on. > That's how I've been finding out all of the races in net80211/ath, as > there wasn't locking where there needed to be. I think that your worries are focused more around the latter than the former, which can be easilly shut down already today. And frankly I will never be in favor of a patch that automatically shutdowns lock assertion. Please patch your local code to do so but don't add any generic/upstream/all-around mechanism for that. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 18:05:39 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C804AA93; Thu, 15 Nov 2012 18:05:39 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 861758FC19; Thu, 15 Nov 2012 18:05:39 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kp6so1343688pab.13 for ; Thu, 15 Nov 2012 10:05:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5KiudfFWpVUT8SO8AmCj9ZeGusK0Nw9XGqKBQy9KIZ0=; b=Dqeh9DiGVXhCRc3MIvG5i6b4OMDmILGrom9UMGYuZDxxD7PMUtns+pDmSQDeEif49S 7Sy439g9aaGwsmO48Xox3h5ncsPgnGtJQGIMmYtGbR5HMznGKjRi37yb1zHNfQgozL6i 7k3LzzUJeXyp0mIM4pL6Zeccfbof70PC0gKTJ/FDAl0XJDs3GOfWaciTQ2zuXkw4vORX xWu9Q2glY7pgSlV1w1j7M1PdUTJcCOwPwWk1EmrXMTimOWjqn0Pcr/rXGLUYj2bThcla NrujuhQfysOFfWoQrD3Vfmh/fLy1dwfzDcgy9dbHWLyNz8s31Yo6vC7fNRitkqk8Y05r HL+A== MIME-Version: 1.0 Received: by 10.68.238.199 with SMTP id vm7mr6959752pbc.105.1353002739276; Thu, 15 Nov 2012 10:05:39 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Thu, 15 Nov 2012 10:05:39 -0800 (PST) In-Reply-To: References: <1353001175.1217.153.camel@revolution.hippie.lan> <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> Date: Thu, 15 Nov 2012 10:05:39 -0800 X-Google-Sender-Auth: eeSF1SKe-_FUXeAsxEMyAhRsFpA Message-ID: Subject: Re: [RFQ] make witness panic an option From: Adrian Chadd To: attilio@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Ian Lepore , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:05:39 -0000 On 15 November 2012 10:01, Attilio Rao wrote: > I think that your worries are focused more around the latter than the > former, which can be easilly shut down already today. > > And frankly I will never be in favor of a patch that automatically > shutdowns lock assertion. Please patch your local code to do so but > don't add any generic/upstream/all-around mechanism for that. Would a comprimise be ok? Ie, if I pushed everything but the sysctl upstream, and just defaulted it to always panic? That way my diff wouldn't have to be a big thing; I'd just add the sysctl. adrian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 18:10:52 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9147196; Thu, 15 Nov 2012 18:10:52 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id F2F138FC20; Thu, 15 Nov 2012 18:10:51 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so1827087lah.13 for ; Thu, 15 Nov 2012 10:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LEWTr6tRSOnHjaTKdYVhTzng2rbGRQeojE+a+UG+OjE=; b=EikVC4ZmvKF47uo6JHKwdrpbgmn/pyHX4WWZ6K3niB07mVxoJv3/iy7IITGE4RCtqx QxsPJ1je/VXFOr2fkFDYE8bUJ4JTyM5VLtAztIYTCaM4QZBID50ANdH0W9sA7OopnBgs WzajBSb2DQdQULYNr2waFyqvCr3ZCExrpDKvrXUVCh2wi2mNv5X6biBRqaW/Ye0aSt5/ Y+yemPOGJCLxW7IkXbuZukfjd//nPk3n8UEGO3FbgsFhllPnPjLCxiNDceds5YgL/IZU gvZc8AOj8EOqS+DSs1PMrLv6p2FYJLai+SOSYpIasjrH9J10pUx4tL1ronP2uS/wZUVE zWEQ== MIME-Version: 1.0 Received: by 10.112.36.200 with SMTP id s8mr947677lbj.92.1353003050811; Thu, 15 Nov 2012 10:10:50 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 10:10:50 -0800 (PST) In-Reply-To: References: <1353001175.1217.153.camel@revolution.hippie.lan> <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> Date: Thu, 15 Nov 2012 18:10:50 +0000 X-Google-Sender-Auth: TBPzVA_QUUO44JqNNX09ms-iIoE Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: Ian Lepore , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:10:53 -0000 On 11/15/12, Adrian Chadd wrote: > On 15 November 2012 10:01, Attilio Rao wrote: >> I think that your worries are focused more around the latter than the >> former, which can be easilly shut down already today. >> >> And frankly I will never be in favor of a patch that automatically >> shutdowns lock assertion. Please patch your local code to do so but >> don't add any generic/upstream/all-around mechanism for that. > > Would a comprimise be ok? Ie, if I pushed everything but the sysctl > upstream, and just defaulted it to always panic? > > That way my diff wouldn't have to be a big thing; I'd just add the sysctl. I cannot forbid you from doing anything, I'm just giving you my opinion as the person who co-authored current WITNESS and locking primitives code. I think what you want to do is dangerous and highly abusable, so I'm not in favor of it at all, in whatever form it is. I understand you want to minimize your development patchset with upstream, but I think this is certainly not the way to go. That's also why I never formalized the BLESSING mechanism in WITNESS, for example. I already see WITNESS_KDB as an abuse, but at least until we have a way to make specific LOR (based on file/line, unfortunately) to be marked as "harmless" there is no way we can get rid of WITNESS_KDB. Said all that, you are free to do what you want, but if you commit anything in this area make sure your patch is reviewed by someone else and to state my firm disagreement with this approach in the commit message. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 18:38:22 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6933EF85; Thu, 15 Nov 2012 18:38:22 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CF7108FC12; Thu, 15 Nov 2012 18:38:20 +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 UAA05460; Thu, 15 Nov 2012 20:38:17 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50A53699.30703@FreeBSD.org> Date: Thu, 15 Nov 2012 20:38:17 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Warner Losh Subject: Re: [RFQ] make witness panic an option References: <1353001175.1217.153.camel@revolution.hippie.lan> <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> In-Reply-To: <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, Ian Lepore , Adrian Chadd , freebsd-hackers@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:38:22 -0000 on 15/11/2012 19:56 Warner Losh said the following: > It sounds like he's more worried about introducing LoRs into his wireless code. "Mere" LORs do not result in panic, by default. Only more serious lock-related issues lead to panics. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 19:31:16 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D1308A9 for ; Thu, 15 Nov 2012 19:31:16 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id EB9078FC19; Thu, 15 Nov 2012 19:31:15 +0000 (UTC) Message-ID: <50A542D1.6030006@FreeBSD.org> Date: Thu, 15 Nov 2012 14:30:25 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121031 Thunderbird/16.0.2 MIME-Version: 1.0 To: Bruce Evans Subject: Re: [RFC] Generic population count function References: <50A43B52.8030102@FreeBSD.org> <20121115181009.D42162@besplex.bde.org> In-Reply-To: <20121115181009.D42162@besplex.bde.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 19:31:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-11-15 03:32:50 -0500, Bruce Evans wrote: > On Wed, 14 Nov 2012, Jung-uk Kim wrote: > >> I implemented generic population count function. Please see the >> attachment. It is also available from here: >> >> http://people.freebsd.org/~jkim/bitcount.diff >> >> The idea is to make use of CPU-supported population count >> instructions if available and the compiler supports them (i.e., >> clang), especially for larger than 32-bit data. The patch also >> has use cases for the new function (i.e., counting number of bits >> in IPv6 address[*]). >> >> Any objection? > > This is rather over-engineered for something that is used once or > twice, but it is good to move the functions out of sys/systm.h > where they weren't even usable outside the kernel. There's little history behind it, actually. When I wrote the following patch, I was looking for fast population count function available in FreeBSD: http://svnweb.freebsd.org/ports/head/java/openjdk6/files/patch-set?annotate=306138#l5437 I searched everywhere and found this: http://www.dalkescientific.com/writings/diary/archive/2011/11/02/faster_popcount_update.html but I ended up (ab)using count() method for bitset in C++ because there's no portable way to do so. The GCC-supplied bitset header uses __builtin_popcount(), naturally. :-) BTW, I intent to add CPU_COUNT() macro to sys/cpuset.h with this bitcount() function. [Snip ffs() issues] > I only noticed the following in your version: - including > is a style bug because sys/types.h includes it Will fix, thanks! > - you removed the silly special inline for bitcount16() but still > implement bitcount16(), presumably for compatibiltiy. Precisely. I don't want to see angry kib@. ;-) > But it is incompatible since the old version has the bogus return > type uint16_t. Yes, I noticed that, too. I believe kib@ added it to make Linux -> FreeBSD conversion easier, i.e., http://lxr.linux.no/#linux+v3.6.6/drivers/gpu/drm/i915/intel_sdvo.c#L1279 http://lxr.linux.no/#linux+v3.6.6/drivers/gpu/drm/i915/intel_sdvo.c#L1913 BTW, I found Linux has very simple ("naive") population count (aka, Hamming weight) macros: http://lxr.linux.no/#linux+v3.6.6/include/asm-generic/bitops/const_hweight.h __builtin_popcount() family should do much better than this. ;-) > It seems to be used just twice: in intel_sdvo.c, it is blindly > converted to bool in 1 place and to unsigned int in 1 place. Both > of these uses are for device initialization so their efficiency is > especially uniportant. Correct. > - bitcount32() is also incompatible since the old version has the > slightly less bogus return type uint32_t. At least the args have > correct type, unlike the ffs() family. Yes, it is little incompatible but *intentional*. I looked through entire source code and found no problem. The return value is always <= 32 anyway. :-) Thanks for the review, Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlClQtAACgkQmlay1b9qnVMZUwCfQhimEbrL87o+KOITt27nNgNS pWAAniWs9Jzf6W2CkiIyozSSfLqW1YJK =DOpK -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 19:55:14 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2616D6C; Thu, 15 Nov 2012 19:55:14 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 8142E8FC0C; Thu, 15 Nov 2012 19:55:14 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qAFJtCta042825; Thu, 15 Nov 2012 12:55:13 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qAFJtAMF025220; Thu, 15 Nov 2012 12:55:10 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: [RFQ] make witness panic an option From: Ian Lepore To: attilio@FreeBSD.org In-Reply-To: References: <1353001175.1217.153.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Nov 2012 12:55:10 -0700 Message-ID: <1353009310.1217.172.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Adrian Chadd , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 19:55:15 -0000 On Thu, 2012-11-15 at 17:47 +0000, Attilio Rao wrote: > On 11/15/12, Ian Lepore wrote: > > On Wed, 2012-11-14 at 22:15 -0800, Adrian Chadd wrote: > >> Hi all, > >> > >> When debugging and writing wireless drivers/stack code, I like to > >> sprinkle lots of locking assertions everywhere. However, this does > >> cause things to panic quite often during active development. > >> > >> This patch (against stable/9) makes the actual panic itself > >> configurable. It still prints the message regardless. > >> > >> This has allowed me to sprinkle more locking assertions everywhere to > >> investigate whether particular paths have been hit or not. I don't > >> necessarily want those to panic the kernel. > >> > >> I'd like everyone to consider this for FreeBSD-HEAD. > >> > >> Thanks! > > > > I strongly support this, because I'm tired of having to hack it in by > > hand every time I need it. > > > > You can't boot an arm platform right now (on freebsd 8, 9, or 10) > > without a LOR very early in the boot. Once you get past that, 2 or 3 > > device drivers I use panic way before we even get to mounting root. > > Those panics can clearly be ignored, because we've been shipping > > products for years based on this code. (It's on my to-do list to fix > > them, but more pressing problems are higher on the list.) > > This is a ridicolous motivation. > What are the panics in question? Why they are not fixed yet? > Without WITNESS_KDB you should not panic even in cases where WITNESS > yells. So if you do, it means there is a more subdole breakage going > on here. > > Do you really think that an abusable mechanism will help here rather > than fixing the actual problems? > > > When a new problem crops up that isn't harmless, it totally sucks that I > > can't just turn on witness without first hacking the code to make the > > known problems non-panicky. > > I really don't understand what are these "harmless problems" here. > I just know one and it is between the dirhash lock and the bufwait > lock for UFS, which is carefully documented in the code comments. All > the others cases haven't been analyzed deeply enough to quantify them > as "harmless". > > Can you please make real examples? > No. Since you've made it abundantly clear in this thread that you are not open to anyone else's opinion and won't change your mind, I'm not going to waste even 10 seconds explaining my perfectly valid needs. I'll just keep hacking the code up to not panic when I need to. -- Ian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 19:56:41 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95944F19; Thu, 15 Nov 2012 19:56:41 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 420D28FC14; Thu, 15 Nov 2012 19:56:41 +0000 (UTC) Message-ID: <50A548C6.5070208@FreeBSD.org> Date: Thu, 15 Nov 2012 14:55:50 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121031 Thunderbird/16.0.2 MIME-Version: 1.0 To: Julian Elischer Subject: Re: [RFC] Generic population count function References: <50A43B52.8030102@FreeBSD.org> <50A477BA.4020700@freebsd.org> In-Reply-To: <50A477BA.4020700@freebsd.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 19:56:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-11-15 00:03:54 -0500, Julian Elischer wrote: > there are more efficient algorithms than the one you show in > bitcount.h see the bit-twidling site: > > http://graphics.stanford.edu/~seander/bithacks.html Yes, I know that. __bitcount32() is a fall-back for *unsupported* compilers anyway, I didn't see much point in improving it further. If you are looking for better population count functions, this site is better, actually: http://www.dalkescientific.com/writings/diary/archive/2011/11/02/faster_popcount_update.html Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlClSMYACgkQmlay1b9qnVPIegCgyPDEgRaKkgEj9TWAfI09G5Cg ugQAn1orRlZDSqUUTYa2fCIwtYSIAegh =49wE -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 20:00:51 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9CE916C; Thu, 15 Nov 2012 20:00:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 642C08FC08; Thu, 15 Nov 2012 20:00:51 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kp6so1425293pab.13 for ; Thu, 15 Nov 2012 12:00:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pFKWZYoG4p30Vf0Gsb0S0WV/+8kDLrdtb1B53AxVM04=; b=Ak4uyRK+vc0ABwP7IEEqun3qB5953yIMV6PtuCQ0iNpiS3g/MuMRft4t60mD4YbzZh x8yQZ3VHS6D39NCdMLYLBTY6r7fSuT7yKYJ8iuzdbyGeCu1mUg0XlP0v0zpzrOTqmiPS lHMIUpfoPeUMXdOV+4d0n4vOP+FSCJak4yIzokXnCiuXjHF6StvRGFzu6+ZLwOqBE6ex IIw4j5I7pWx3LoBeEV/rkcN0ofdp5zcbBS3HUiG+kQ1r9JewroMW8Y+IvBlclse7RLsp JmtQAc1kwcjhE6V/iZjC5PIJOXz2JLPlNO9PqqXizCcpFaAmlvpV4wQINC/jk7i5eQRq bEpA== MIME-Version: 1.0 Received: by 10.68.209.166 with SMTP id mn6mr2239018pbc.95.1353009651011; Thu, 15 Nov 2012 12:00:51 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Thu, 15 Nov 2012 12:00:50 -0800 (PST) In-Reply-To: <1353009310.1217.172.camel@revolution.hippie.lan> References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> Date: Thu, 15 Nov 2012 12:00:50 -0800 X-Google-Sender-Auth: RF_RGCRWPC2aiz4sv-W4m-smavM Message-ID: Subject: Re: [RFQ] make witness panic an option From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: attilio@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:00:52 -0000 On 15 November 2012 11:55, Ian Lepore wrote: > Since you've made it abundantly clear in this thread that you are not > open to anyone else's opinion and won't change your mind, I'm not going > to waste even 10 seconds explaining my perfectly valid needs. > > I'll just keep hacking the code up to not panic when I need to. I agree with Attilio - any driver or subsystem that's causing witness panics need to be fixed. But I think my change is invaluable for development, where you want to improve and debug the locking and lock interactions of a subsystem. adrian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 20:51:14 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C80914AD; Thu, 15 Nov 2012 20:51:14 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 63A6F8FC19; Thu, 15 Nov 2012 20:51:13 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA06347; Thu, 15 Nov 2012 22:51:11 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TZ6P0-000Nza-LF; Thu, 15 Nov 2012 22:51:10 +0200 Message-ID: <50A555BD.1010105@FreeBSD.org> Date: Thu, 15 Nov 2012 22:51:09 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [RFQ] make witness panic an option References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, Ian Lepore , freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:51:14 -0000 on 15/11/2012 22:00 Adrian Chadd said the following: > But I think my change is invaluable for development, where you want to > improve and debug the locking and lock interactions of a subsystem. My practical experience was that if you mess up one lock in one place, then it is a total mess further on. but apparently you've got a different practical experience :-) What would indeed be invaluable to _me_ - if the LOR messages also produced the stack(s) where a supposedly correct lock order was learned. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 22:07:07 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81E7D195; Thu, 15 Nov 2012 22:07:07 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3A5848FC17; Thu, 15 Nov 2012 22:07:06 +0000 (UTC) Received: from sa-nc-cs-75.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id qAFM6vEi092196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Nov 2012 14:06:59 -0800 (PST) (envelope-from marcel@xcllnt.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [RFC] test layout/standardization for FreeBSD From: Marcel Moolenaar In-Reply-To: <7099.1352886181@critter.freebsd.dk> Date: Thu, 15 Nov 2012 14:06:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7099.1352886181@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.1499) Cc: Garrett Cooper , George Neville-Neil , Matthew Fleming , "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 22:07:07 -0000 On Nov 14, 2012, at 1:43 AM, Poul-Henning Kamp = wrote: > -------- > In message = > , Garrett Cooper writes: >=20 >> I asked for feedback from some of the stakeholders of >> the FreeBSD test automation effort [...] >=20 > Can I throw in something here ? >=20 > A very important thing is to have systematic metadata about = test-cases, > in particular: >=20 > A) Is the test 100% deterministic, or is there a risk of random = failure ? >=20 > B) Is the test reliable on a heavily loaded machine ? >=20 > C) Estimated duration of test I can't disagree, but I would argue that it's not more important than having testcases. I'm not trying to be flippant, but we need to get off the ground first before we try to retract the landing gear. I would argue that if we build this stuff out, we either hit the problems that meta data would solve or we don't. If we do, we also have real examples to work with. If we don't then we didn't "waste" time. Since at this point in time it's just an academic exercise that doesn't yield anything concrete, we're more likely than not wasting time. For example: If a test is not reliable on a heavily loaded machine, then the test is ipso facto not 100% deterministic. So, B implies A. How is this different from a meta data perspective? If we test a RNG, are we ever going to be 100% deterministic? Also, the estimated duration for tests is very platform specific. What exactly does it mean when the actual runtime is shorter or longer than the estimated time? What's the error margin we're comfortable with? Why that error margin? Did the test FAIL if it took too long or ran too short? If not, then what is it for? In short: I'm not sure we can discuss anything concrete just yet. So let's wait until we can. I don't expect a lot of difficulty collecting statistics and data. So let's do that first. The easy cases will show up soon I think and we'll sort those out first. Think functional tests vs performance tests and white-box vs black-box. Eventually we'll have buckets and we'll find that meta data is a lot easier to define and use on a per bucket basis.... Maybe not... Let's just see... $0.02 --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 22:54:37 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 003B9ED6 for ; Thu, 15 Nov 2012 22:54:36 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 94AF38FC12; Thu, 15 Nov 2012 22:54:36 +0000 (UTC) Message-ID: <50A57279.3040607@FreeBSD.org> Date: Thu, 15 Nov 2012 17:53:45 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121031 Thunderbird/16.0.2 MIME-Version: 1.0 To: Bruce Evans Subject: Re: [RFC] Generic population count function References: <50A43B52.8030102@FreeBSD.org> <20121115181009.D42162@besplex.bde.org> In-Reply-To: <20121115181009.D42162@besplex.bde.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 22:54:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-11-15 03:32:50 -0500, Bruce Evans wrote: > The implementation of the ffs() family has similar non-problems. > No one cares because they are rarely used, but... cperciva@ wrote > the lookup table part of the following set of implementations of > ffs() and fls(). A lookup table is the best general method, though > it can be beaten by unportable methodw in some cases. I added more > methods and a test framework to this (test framework not always > included). The methods are: - gcc builtin - cpufunc inline Talking about cpufunc ffsl(), I found something strange about clang: % cat ffs.c #include #include int ffs_cpufunc(long x) /* copied from cpufunc.h as is */ { return (x == 0 ? x : (int)bsfq((u_long)x) + 1); } int ffs_builtin(long x) { return (__builtin_ffsl(x)); } % clang -O2 -c ffs.c % objdump -d ffs.o ffs.o: file format elf64-x86-64-freebsd Disassembly of section .text: 0000000000000000 : 0: 48 85 ff test %rdi,%rdi 3: 74 21 je 26 5: 48 89 7c 24 f8 mov %rdi,-0x8(%rsp) a: 48 0f bc 4c 24 f8 bsf -0x8(%rsp),%rcx 10: 48 c1 e1 20 shl $0x20,%rcx 14: 48 b8 00 00 00 00 01 mov $0x100000000,%rax 1b: 00 00 00 1e: 48 01 c8 add %rcx,%rax 21: 48 c1 e8 20 shr $0x20,%rax 25: c3 retq 26: 31 c0 xor %eax,%eax 28: c3 retq 29: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) 0000000000000030 : 30: 48 0f bc cf bsf %rdi,%rcx 34: ff c1 inc %ecx 36: 31 c0 xor %eax,%eax 38: 48 85 ff test %rdi,%rdi 3b: 0f 45 c1 cmovne %ecx,%eax 3e: c3 retq Note clang generates very inefficient code for ffsl() from cpufunc.h. It is using memory, setting an unused bit, etc. :-( Both GCC 4.2 and 4.8 generate "good code", of course: % gcc -O2 -c ffs.c % objdump -d ffs.o ffs.o: file format elf64-x86-64-freebsd Disassembly of section .text: 0000000000000000 : 0: 31 c0 xor %eax,%eax 2: 48 85 ff test %rdi,%rdi 5: 74 07 je e 7: 48 0f bc c7 bsf %rdi,%rax b: 83 c0 01 add $0x1,%eax e: f3 c3 repz retq 0000000000000010 : 10: 48 0f bc ff bsf %rdi,%rdi 14: 48 c7 c0 ff ff ff ff mov $0xffffffffffffffff,%rax 1b: 48 0f 44 f8 cmove %rax,%rdi 1f: 48 83 c7 01 add $0x1,%rdi 23: 89 f8 mov %edi,%eax 25: c3 retq % gcc48 -O2 -c ffs.c % objdump -d ffs.o ffs.o: file format elf64-x86-64-freebsd Disassembly of section .text: 0000000000000000 : 0: 31 c0 xor %eax,%eax 2: 48 85 ff test %rdi,%rdi 5: 75 09 jne 10 7: f3 c3 repz retq 9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) 10: 48 0f bc c7 bsf %rdi,%rax 14: 83 c0 01 add $0x1,%eax 17: c3 retq 18: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1) 1f: 00 0000000000000020 : 20: 48 0f bc c7 bsf %rdi,%rax 24: 48 c7 c2 ff ff ff ff mov $0xffffffffffffffff,%rdx 2b: 48 0f 44 c2 cmove %rdx,%rax 2f: 48 83 c0 01 add $0x1,%rax 33: c3 retq FYI, Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlClcnkACgkQmlay1b9qnVPQYACgjEYpPDgLfkskpm3+2vRNjCuJ n5AAn30JxrFS9kLoejh+4BZFD/MnfAvT =4yS7 -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 23:17:10 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A74409BA; Thu, 15 Nov 2012 23:17:10 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 75A2C8FC08; Thu, 15 Nov 2012 23:17:10 +0000 (UTC) Received: from kruse-124.4.ixsystems.com (drawbridge.ixsystems.com [206.40.55.65]) by elvis.mu.org (Postfix) with ESMTPSA id 4B4B61A3D8D; Thu, 15 Nov 2012 15:17:04 -0800 (PST) Message-ID: <50A57815.4060104@mu.org> Date: Thu, 15 Nov 2012 15:17:41 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [RFQ] make witness panic an option References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:17:10 -0000 On 11/14/12 10:15 PM, Adrian Chadd wrote: > Hi all, > > When debugging and writing wireless drivers/stack code, I like to > sprinkle lots of locking assertions everywhere. However, this does > cause things to panic quite often during active development. > > This patch (against stable/9) makes the actual panic itself > configurable. It still prints the message regardless. > > This has allowed me to sprinkle more locking assertions everywhere to > investigate whether particular paths have been hit or not. I don't > necessarily want those to panic the kernel. > > I'd like everyone to consider this for FreeBSD-HEAD. > > Thanks! Adrian, you seem be getting reluctance on your patch which is surprising since we have "witness_kdb" option which pretty much does exactly what you want... ...except where you need it to. That is unfortunate. Perhaps if you switched those panics to a WITNESS_WARN that would do what you need/want? You could pass a special flag into WITNESS_WARN that said "i'm going to pass you a NULL ptr for lock object... just behave as if there was an error". that should make things more concise. Will that be sufficient? -Alfred > > > > Adrian > > > _______________________________________________ > 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-arch@FreeBSD.ORG Thu Nov 15 23:19:29 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9ACB9C1F; Thu, 15 Nov 2012 23:19:29 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 77A638FC12; Thu, 15 Nov 2012 23:19:29 +0000 (UTC) Received: from kruse-124.4.ixsystems.com (drawbridge.ixsystems.com [206.40.55.65]) by elvis.mu.org (Postfix) with ESMTPSA id D8A771A3D8D; Thu, 15 Nov 2012 15:19:28 -0800 (PST) Message-ID: <50A578A6.1030005@mu.org> Date: Thu, 15 Nov 2012 15:20:06 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: [RFQ] make witness panic an option References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> <50A555BD.1010105@FreeBSD.org> In-Reply-To: <50A555BD.1010105@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, Ian Lepore , Adrian Chadd , freebsd-hackers@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:19:29 -0000 On 11/15/12 12:51 PM, Andriy Gapon wrote: > on 15/11/2012 22:00 Adrian Chadd said the following: >> But I think my change is invaluable for development, where you want to >> improve and debug the locking and lock interactions of a subsystem. > My practical experience was that if you mess up one lock in one place, then it > is a total mess further on. but apparently you've got a different practical > experience :-) > > What would indeed be invaluable to _me_ - if the LOR messages also produced the > stack(s) where a supposedly correct lock order was learned. > Adrian is right. In a large scale environment breakages will be introduced in places you do not have access to. We need to enable developers to skip these areas and test their own code. Without Adrian's concept then it forces someone who may have no idea about a subsystem to either be blocked, or to have to put his work aside to work on a problem that is someone else's responsibility. I locked down SMP at a large company in a FreeBSD code base and had this same problem. Adrian's patch would have helped all of us tremendously. Adrian, can you look at my suggestion to merge with witness_kdb and see if that will suffice? -Alfred From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 23:38:07 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6435D5BC; Thu, 15 Nov 2012 23:38:07 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 37F7C8FC13; Thu, 15 Nov 2012 23:38:06 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so2182799lbb.13 for ; Thu, 15 Nov 2012 15:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=59fXcjSOGzjdxybEZJU5FyWyLXXjWnlX2A1ncV1wX3E=; b=uIBJqE7kZ+G5C/FIwnacIyHHnd6O17lx9oiOLjUpWEDFK55aOHEc6jSO9973QS0/hr qN3vDWMqe7NysB2fx5gdC/3DoIEpGiIYMO2bjoUK2XPSww0pc3HFFpyJ6nDWIpOWhiEN 7ZlVfdVsD8YKuwKokCOaxXo8UsKCS90i9fHsobmpuIvqcSTvxTtp3H8CcW3UF4DTbDUW NEjvaFRDq4akIRfrL+EwOlTKxbZW9cq2QrSxKQzfgEP7/ivTQtUipsUeZmWoLiEK9nY9 Ed2YX2vUXwE/DMGY1OwRWTTOB3RjpXjMU+zW4jRl7vQERkq7DN1WOx2J4SHwMldXP7kd 4oxQ== MIME-Version: 1.0 Received: by 10.112.36.200 with SMTP id s8mr1267148lbj.92.1353022684920; Thu, 15 Nov 2012 15:38:04 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 15:38:04 -0800 (PST) In-Reply-To: <50A555BD.1010105@FreeBSD.org> References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> <50A555BD.1010105@FreeBSD.org> Date: Thu, 15 Nov 2012 23:38:04 +0000 X-Google-Sender-Auth: O7HR17qiUsPNiPQPPnHwqI3xmLk Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: Ian Lepore , Adrian Chadd , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:38:07 -0000 On Thu, Nov 15, 2012 at 8:51 PM, Andriy Gapon wrote: > on 15/11/2012 22:00 Adrian Chadd said the following: >> But I think my change is invaluable for development, where you want to >> improve and debug the locking and lock interactions of a subsystem. > > My practical experience was that if you mess up one lock in one place, then it > is a total mess further on. but apparently you've got a different practical > experience :) > What would indeed be invaluable to _me_ - if the LOR messages also produced the > stack(s) where a supposedly correct lock order was learned. Please note that the "supposedly correct lock order", as for the definition that it is correct, can be used in several different stacks. I don't see the point of saving it somewhere. The only helpful case would be if the "wrong order" is catched first. If this is really the case, I suggest you to force the order you expect in the static table so that the first time the wrong order happens it yells. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 01:03:19 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8274B8 for ; Fri, 16 Nov 2012 01:03:19 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5BBD58FC08 for ; Fri, 16 Nov 2012 01:03:19 +0000 (UTC) Message-ID: <50A590A4.2040406@FreeBSD.org> Date: Thu, 15 Nov 2012 20:02:28 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121031 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: [RFC] bsd.cpu.mk update for newer processors References: <50A410B5.9070001@FreeBSD.org> In-Reply-To: <50A410B5.9070001@FreeBSD.org> X-Enigmail-Version: 1.4.5 Content-Type: multipart/mixed; boundary="------------080802080106010609000609" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 01:03:19 -0000 This is a multi-part message in MIME format. --------------080802080106010609000609 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-11-14 16:44:21 -0500, Jung-uk Kim wrote: > Since we have enabled clang by default on current, I'd like to > update bsd.cpu.mk as well. Please see the attachment. It is also > available from here: > > http://people.freebsd.org/~jkim/cpu.diff > > I only added most popular SIMD features to MACHINE_CPU (i.e., > sse4a, sse41, sse42, and avx) and clang-supported archs to CPUTYPE > (i.e., amdfam10, btver1, bdver1, bdver2, corei7, corei7-avx, and > core-avx-i). I updated the patch to include xop for bdver1 and bdver2: http://people.freebsd.org/~jkim/cpu2.diff I think the feature is too important to miss out. If nobody objects, I am going to commit it around next Monday. Thanks, Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlClkKQACgkQmlay1b9qnVNCdQCeN7kFUWlBxFtVVxG005MsMWZ4 o5UAnR3i3G9ohHJJYnloWaClg9DWIHDL =Zsq3 -----END PGP SIGNATURE----- --------------080802080106010609000609 Content-Type: text/plain; charset=UTF-8; name="cpu2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cpu2.diff" Index: share/mk/bsd.cpu.mk =================================================================== --- share/mk/bsd.cpu.mk (revision 243111) +++ share/mk/bsd.cpu.mk (working copy) @@ -27,10 +27,10 @@ MACHINE_CPU = mips # between e.g. i586 and pentium) . if ${MACHINE_CPUARCH} == "i386" -. if ${CPUTYPE} == "nocona" +. if ${CPUTYPE} == "nocona" || ${CPUTYPE} == "core" || \ + ${CPUTYPE} == "core2" || ${CPUTYPE} == "corei7" || \ + ${CPUTYPE} == "corei7-avx" || ${CPUTYPE} == "core-avx-i" CPUTYPE = prescott -. elif ${CPUTYPE} == "core" -CPUTYPE = prescott . elif ${CPUTYPE} == "p4" CPUTYPE = pentium4 . elif ${CPUTYPE} == "p4m" @@ -50,10 +50,11 @@ CPUTYPE = pentium-mmx . elif ${CPUTYPE} == "i586" CPUTYPE = pentium . elif ${CPUTYPE} == "opteron-sse3" || ${CPUTYPE} == "athlon64-sse3" || \ - ${CPUTYPE} == "k8-sse3" + ${CPUTYPE} == "k8-sse3" || ${CPUTYPE} == "amdfam10" || \ + ${CPUTYPE} == "btver1" || ${CPUTYPE} == "bdver1" || ${CPUTYPE} == "bdver2" CPUTYPE = prescott . elif ${CPUTYPE} == "opteron" || ${CPUTYPE} == "athlon64" || \ - ${CPUTYPE} == "k8" + ${CPUTYPE} == "k8" CPUTYPE = athlon-mp . elif ${CPUTYPE} == "k7" CPUTYPE = athlon @@ -142,7 +143,15 @@ _CPUCFLAGS = -mcpu=ultrasparc3 # presence of a CPU feature. . if ${MACHINE_CPUARCH} == "i386" -. if ${CPUTYPE} == "opteron-sse3" || ${CPUTYPE} == "athlon64-sse3" +. if ${CPUTYPE} == "bdver1" || ${CPUTYPE} == "bdver2" +MACHINE_CPU = xop avx sse42 sse41 ssse3 sse4a sse3 sse2 sse mmx k6 k5 i586 +MACHINE_CPU += i486 i386 +. elif ${CPUTYPE} == "btver1" +MACHINE_CPU = ssse3 sse4a sse3 sse2 sse mmx k6 k5 i586 i486 i386 +. elif ${CPUTYPE} == "amdfam10" +MACHINE_CPU = athlon-xp athlon k7 3dnow sse4a sse3 sse2 sse mmx k6 k5 i586 +MACHINE_CPU += i486 i386 +. elif ${CPUTYPE} == "opteron-sse3" || ${CPUTYPE} == "athlon64-sse3" MACHINE_CPU = athlon-xp athlon k7 3dnow sse3 sse2 sse mmx k6 k5 i586 i486 i386 . elif ${CPUTYPE} == "opteron" || ${CPUTYPE} == "athlon64" MACHINE_CPU = athlon-xp athlon k7 3dnow sse2 sse mmx k6 k5 i586 i486 i386 @@ -163,11 +172,16 @@ MACHINE_CPU = 3dnow mmx i586 i486 i386 MACHINE_CPU = sse mmx i586 i486 i386 . elif ${CPUTYPE} == "c7" MACHINE_CPU = sse3 sse2 sse i686 mmx i586 i486 i386 +. elif ${CPUTYPE} == "corei7-avx" || ${CPUTYPE} == "core-avx-i" +MACHINE_CPU = avx sse42 sse41 ssse3 sse3 sse2 sse i686 mmx i586 i486 i386 +. elif ${CPUTYPE} == "corei7" +MACHINE_CPU = sse42 sse41 ssse3 sse3 sse2 sse i686 mmx i586 i486 i386 . elif ${CPUTYPE} == "core2" MACHINE_CPU = ssse3 sse3 sse2 sse i686 mmx i586 i486 i386 . elif ${CPUTYPE} == "prescott" MACHINE_CPU = sse3 sse2 sse i686 mmx i586 i486 i386 -. elif ${CPUTYPE} == "pentium4" || ${CPUTYPE} == "pentium4m" || ${CPUTYPE} == "pentium-m" +. elif ${CPUTYPE} == "pentium4" || ${CPUTYPE} == "pentium4m" || \ + ${CPUTYPE} == "pentium-m" MACHINE_CPU = sse2 sse i686 mmx i586 i486 i386 . elif ${CPUTYPE} == "pentium3" || ${CPUTYPE} == "pentium3m" MACHINE_CPU = sse i686 mmx i586 i486 i386 @@ -185,10 +199,22 @@ MACHINE_CPU = i486 i386 MACHINE_CPU = i386 . endif . elif ${MACHINE_CPUARCH} == "amd64" -. if ${CPUTYPE} == "opteron-sse3" || ${CPUTYPE} == "athlon64-sse3" || ${CPUTYPE} == "k8-sse3" +. if ${CPUTYPE} == "bdver1" || ${CPUTYPE} == "bdver2" +MACHINE_CPU = xop avx sse42 sse41 ssse3 sse4a sse3 +. elif ${CPUTYPE} == "btver1" +MACHINE_CPU = ssse3 sse4a sse3 +. elif ${CPUTYPE} == "amdfam10" +MACHINE_CPU = k8 3dnow sse4a sse3 +. elif ${CPUTYPE} == "opteron-sse3" || ${CPUTYPE} == "athlon64-sse3" || \ + ${CPUTYPE} == "k8-sse3" MACHINE_CPU = k8 3dnow sse3 -. elif ${CPUTYPE} == "opteron" || ${CPUTYPE} == "athlon64" || ${CPUTYPE} == "k8" +. elif ${CPUTYPE} == "opteron" || ${CPUTYPE} == "athlon64" || \ + ${CPUTYPE} == "k8" MACHINE_CPU = k8 3dnow +. elif ${CPUTYPE} == "corei7-avx" || ${CPUTYPE} == "core-avx-i" +MACHINE_CPU = avx sse42 sse41 ssse3 sse3 +. elif ${CPUTYPE} == "corei7" +MACHINE_CPU = sse42 sse41 ssse3 sse3 . elif ${CPUTYPE} == "core2" MACHINE_CPU = ssse3 sse3 . elif ${CPUTYPE} == "nocona" --------------080802080106010609000609-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 01:16:08 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C4C0A430 for ; Fri, 16 Nov 2012 01:16:08 +0000 (UTC) (envelope-from postmaster@mailpod.hostingplatform.com) Received: from atl4mhob11.myregisteredsite.com (atl4mhob11.myregisteredsite.com [209.17.115.49]) by mx1.freebsd.org (Postfix) with ESMTP id 6695D8FC15 for ; Fri, 16 Nov 2012 01:16:07 +0000 (UTC) Received: from mailpod1.hostingplatform.com (mailpod1.networksolutionsemail.com [206.188.198.65]) by atl4mhob11.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAG1G6rn013707 for ; Thu, 15 Nov 2012 20:16:07 -0500 Received: (qmail 24546 invoked by uid 0); 16 Nov 2012 01:16:06 -0000 Received: (qmail 31645 invoked by uid 0); 15 Nov 2012 18:11:08 -0000 Received: from unknown (HELO atl4mhib17.myregisteredsite.com) (209) by 0 with SMTP; 15 Nov 2012 18:11:08 -0000 Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by atl4mhib17.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAFIB6cg007503 for ; Thu, 15 Nov 2012 13:11:07 -0500 Received: from hub.freebsd.org (hub.FreeBSD.org [8.8.178.136]) by mx2.freebsd.org (Postfix) with ESMTP id 108553B59A3; Thu, 15 Nov 2012 18:11:00 +0000 (UTC) Received: from hub.FreeBSD.org (hub.FreeBSD.org [8.8.178.136]) by hub.freebsd.org (Postfix) with ESMTP id 5155B23E; Thu, 15 Nov 2012 18:11:00 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9147196; Thu, 15 Nov 2012 18:10:52 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id F2F138FC20; Thu, 15 Nov 2012 18:10:51 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so1827087lah.13 for ; Thu, 15 Nov 2012 10:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LEWTr6tRSOnHjaTKdYVhTzng2rbGRQeojE+a+UG+OjE=; b=EikVC4ZmvKF47uo6JHKwdrpbgmn/pyHX4WWZ6K3niB07mVxoJv3/iy7IITGE4RCtqx QxsPJ1je/VXFOr2fkFDYE8bUJ4JTyM5VLtAztIYTCaM4QZBID50ANdH0W9sA7OopnBgs WzajBSb2DQdQULYNr2waFyqvCr3ZCExrpDKvrXUVCh2wi2mNv5X6biBRqaW/Ye0aSt5/ Y+yemPOGJCLxW7IkXbuZukfjd//nPk3n8UEGO3FbgsFhllPnPjLCxiNDceds5YgL/IZU gvZc8AOj8EOqS+DSs1PMrLv6p2FYJLai+SOSYpIasjrH9J10pUx4tL1ronP2uS/wZUVE zWEQ== MIME-Version: 1.0 Received: by 10.112.36.200 with SMTP id s8mr947677lbj.92.1353003050811; Thu, 15 Nov 2012 10:10:50 -0800 (PST) Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 10:10:50 -0800 (PST) In-Reply-To: References: <1353001175.1217.153.camel@revolution.hippie.lan> <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> Date: Thu, 15 Nov 2012 18:10:50 +0000 X-Google-Sender-Auth: TBPzVA_QUUO44JqNNX09ms-iIoE Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Adrian Chadd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-SpamScore: 0 X-MailHub-Apparently-To: mjm@michaelmeltzer.com X-MailHub-Forwarded: Yes Cc: Ian Lepore , freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 01:16:08 -0000 On 11/15/12, Adrian Chadd wrote: > On 15 November 2012 10:01, Attilio Rao wrote: >> I think that your worries are focused more around the latter than the >> former, which can be easilly shut down already today. >> >> And frankly I will never be in favor of a patch that automatically >> shutdowns lock assertion. Please patch your local code to do so but >> don't add any generic/upstream/all-around mechanism for that. > > Would a comprimise be ok? Ie, if I pushed everything but the sysctl > upstream, and just defaulted it to always panic? > > That way my diff wouldn't have to be a big thing; I'd just add the sysctl. I cannot forbid you from doing anything, I'm just giving you my opinion as the person who co-authored current WITNESS and locking primitives code. I think what you want to do is dangerous and highly abusable, so I'm not in favor of it at all, in whatever form it is. I understand you want to minimize your development patchset with upstream, but I think this is certainly not the way to go. That's also why I never formalized the BLESSING mechanism in WITNESS, for example. I already see WITNESS_KDB as an abuse, but at least until we have a way to make specific LOR (based on file/line, unfortunately) to be marked as "harmless" there is no way we can get rid of WITNESS_KDB. Said all that, you are free to do what you want, but if you commit anything in this area make sure your patch is reviewed by someone else and to state my firm disagreement with this approach in the commit message. Attilio -- Peace can only be achieved by understanding - A. Einstein _______________________________________________ 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-arch@FreeBSD.ORG Fri Nov 16 01:36:02 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F324CCEB for ; Fri, 16 Nov 2012 01:36:01 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 97E638FC08 for ; Fri, 16 Nov 2012 01:36:01 +0000 (UTC) Message-ID: <50A5984E.8030305@FreeBSD.org> Date: Thu, 15 Nov 2012 20:35:10 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121031 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: [RFC] Generic population count function References: <50A43B52.8030102@FreeBSD.org> In-Reply-To: <50A43B52.8030102@FreeBSD.org> X-Enigmail-Version: 1.4.5 Content-Type: multipart/mixed; boundary="------------090401070006080406090307" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 01:36:02 -0000 This is a multi-part message in MIME format. --------------090401070006080406090307 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-11-14 19:46:10 -0500, Jung-uk Kim wrote: > I implemented generic population count function. Please see the > attachment. It is also available from here: > > http://people.freebsd.org/~jkim/bitcount.diff > > The idea is to make use of CPU-supported population count > instructions if available and the compiler supports them (i.e., > clang), especially for larger than 32-bit data. The patch also has > use cases for the new function (i.e., counting number of bits in > IPv6 address[*]). Now the patch is updated with a style fix (i.e., removed from bitcount.h): http://people.freebsd.org/~jkim/bitcount2.diff Also, I added another use case, i.e., CPU_COUNT() to count the number of bits in cpuset_t. If nobody objects, I am going to commit it around next Monday. Thanks, Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlClmE4ACgkQmlay1b9qnVPoagCgp+QVEkAP4PPPlg1Zh4v3K1o0 q2QAoKJG15yB7jz2J091lOAq1gPceeHY =q56J -----END PGP SIGNATURE----- --------------090401070006080406090307 Content-Type: text/plain; charset=UTF-8; name="bitcount2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bitcount2.diff" Index: sys/netgraph/netflow/netflow.c =================================================================== --- sys/netgraph/netflow/netflow.c (revision 243111) +++ sys/netgraph/netflow/netflow.c (working copy) @@ -409,12 +409,9 @@ hash_insert(priv_p priv, struct flow_hash_entry *h } #ifdef INET6 -/* XXX: make normal function, instead of.. */ -#define ipv6_masklen(x) bitcount32((x).__u6_addr.__u6_addr32[0]) + \ - bitcount32((x).__u6_addr.__u6_addr32[1]) + \ - bitcount32((x).__u6_addr.__u6_addr32[2]) + \ - bitcount32((x).__u6_addr.__u6_addr32[3]) -#define RT_MASK6(x) (ipv6_masklen(((struct sockaddr_in6 *)rt_mask(x))->sin6_addr)) +#define RT_MASK6(x) \ + bitcount(&((struct sockaddr_in6 *)rt_mask(x))->sin6_addr, \ + sizeof(struct in6_addr)) static int hash6_insert(priv_p priv, struct flow_hash_entry *hsh6, struct flow6_rec *r, int plen, uint8_t flags, uint8_t tcp_flags) @@ -505,7 +502,6 @@ hash6_insert(priv_p priv, struct flow_hash_entry * return (0); } -#undef ipv6_masklen #undef RT_MASK6 #endif Index: sys/netpfil/ipfw/ip_fw_table.c =================================================================== --- sys/netpfil/ipfw/ip_fw_table.c (revision 243111) +++ sys/netpfil/ipfw/ip_fw_table.c (working copy) @@ -706,10 +706,7 @@ dump_table_xentry_extended(struct radix_node *rn, struct table_xentry * const n = (struct table_xentry *)rn; ipfw_xtable * const tbl = arg; ipfw_table_xentry *xent; -#ifdef INET6 - int i; - uint32_t *v; -#endif + /* Out of memory, returning */ if (tbl->cnt == tbl->size) return (1); @@ -720,11 +717,10 @@ dump_table_xentry_extended(struct radix_node *rn, switch (tbl->type) { #ifdef INET6 case IPFW_TABLE_CIDR: - /* Count IPv6 mask */ - v = (uint32_t *)&n->m.mask6.sin6_addr; - for (i = 0; i < sizeof(struct in6_addr) / 4; i++, v++) - xent->masklen += bitcount32(*v); - memcpy(&xent->k, &n->a.addr6.sin6_addr, sizeof(struct in6_addr)); + xent->masklen += bitcount(&n->m.mask6.sin6_addr, + sizeof(struct in6_addr)); + memcpy(&xent->k, &n->a.addr6.sin6_addr, + sizeof(struct in6_addr)); break; #endif case IPFW_TABLE_INTERFACE: Index: sys/sys/bitcount.h =================================================================== --- sys/sys/bitcount.h (revision 0) +++ sys/sys/bitcount.h (working copy) @@ -0,0 +1,105 @@ +/*- + * Copyright (c) 2012 Jung-uk Kim + * 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 PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * 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, STRICT + * 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$ + */ + +#ifndef _SYS_BITCOUNT_H_ +#define _SYS_BITCOUNT_H_ + +#include + +#if __GNUC_PREREQ__(3, 4) +#define __BITCOUNT(x) __builtin_popcountl(x) +#define __BITCOUNT32(x) __builtin_popcount(x) +#define __BITCOUNT_T u_long +#else +#define __BITCOUNT(x) __bitcount32(x) +#define __BITCOUNT32(x) __bitcount32(x) +#define __BITCOUNT_T uint32_t +#endif + +/* + * Population count algorithm using SWAR approach + * - "SIMD Within A Register". + */ +static __inline int +__bitcount32(uint32_t x) +{ + + x += ~((x >> 1) & 0x55555555) + 1; + x = (x & 0x33333333) + ((x >> 2) & 0x33333333); + x = (x + (x >> 4)) & 0x0f0f0f0f; + x += x >> 8; + x += x >> 16; + return (x & 0x3f); +} + +static __inline int +bitcount(void *p, int len) +{ + __BITCOUNT_T x; + u_char *str; + int count; + + /* + * Number of bits must be non-zero and less or equal to INT_MAX. + */ + if (len <= 0 || len >= 0x10000000) + return (-1); + + for (count = 0, str = p; len > 0; len -= sizeof(x)) { + if (len / sizeof(x) > 0) { + x = *(__BITCOUNT_T *)str; + str += sizeof(x); + } else { + /* Byte order is not important here. */ + for (x = 0; len > 0; str++, len--) + x |= *str << (len * 8); + } + count += __BITCOUNT(x); + } + return (count); +} + +static __inline int +bitcount16(uint16_t x) +{ + + return (__BITCOUNT32(x)); +} + +static __inline int +bitcount32(uint32_t x) +{ + + return (__BITCOUNT32(x)); +} + +#undef __BITCOUNT +#undef __BITCOUNT32 +#undef __BITCOUNT_T + +#endif /* !_SYS_BITCOUNT_H_ */ Property changes on: sys/sys/bitcount.h ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: sys/sys/cpuset.h =================================================================== --- sys/sys/cpuset.h (revision 243111) +++ sys/sys/cpuset.h (working copy) @@ -33,6 +33,7 @@ #define _SYS_CPUSET_H_ #include +#include #define CPUSETBUFSIZ ((2 + sizeof(long) * 2) * _NCPUWORDS) @@ -44,6 +45,7 @@ ((long)1 << ((_NCPUWORDS == 1) ? (__size_t)(n) : ((n) % _NCPUBITS))) #define __cpuset_word(n) ((_NCPUWORDS == 1) ? 0 : ((n) / _NCPUBITS)) +#define CPU_COUNT(p) bitcount(p, sizeof(long) * _NCPUWORDS) #define CPU_CLR(n, p) ((p)->__bits[__cpuset_word(n)] &= ~__cpuset_mask(n)) #define CPU_COPY(f, t) (void)(*(t) = *(f)) #define CPU_ISSET(n, p) (((p)->__bits[__cpuset_word(n)] & __cpuset_mask(n)) != 0) Index: sys/sys/systm.h =================================================================== --- sys/sys/systm.h (revision 243111) +++ sys/sys/systm.h (working copy) @@ -40,6 +40,7 @@ #include #include +#include #include #include #include @@ -387,31 +388,4 @@ int alloc_unr_specific(struct unrhdr *uh, u_int it int alloc_unrl(struct unrhdr *uh); void free_unr(struct unrhdr *uh, u_int item); -/* - * Population count algorithm using SWAR approach - * - "SIMD Within A Register". - */ -static __inline uint32_t -bitcount32(uint32_t x) -{ - - x = (x & 0x55555555) + ((x & 0xaaaaaaaa) >> 1); - x = (x & 0x33333333) + ((x & 0xcccccccc) >> 2); - x = (x + (x >> 4)) & 0x0f0f0f0f; - x = (x + (x >> 8)); - x = (x + (x >> 16)) & 0x000000ff; - return (x); -} - -static __inline uint16_t -bitcount16(uint32_t x) -{ - - x = (x & 0x5555) + ((x & 0xaaaa) >> 1); - x = (x & 0x3333) + ((x & 0xcccc) >> 2); - x = (x + (x >> 4)) & 0x0f0f; - x = (x + (x >> 8)) & 0x00ff; - return (x); -} - #endif /* !_SYS_SYSTM_H_ */ --------------090401070006080406090307-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 01:48:01 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 509754AB for ; Fri, 16 Nov 2012 01:48:01 +0000 (UTC) (envelope-from postmaster@mailpod.hostingplatform.com) Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by mx1.freebsd.org (Postfix) with ESMTP id E195E8FC13 for ; Fri, 16 Nov 2012 01:48:00 +0000 (UTC) Received: from mailpod1.hostingplatform.com (mailpod1.networksolutionsemail.com [206.188.198.65]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAG1m0ND018566 for ; Thu, 15 Nov 2012 20:48:00 -0500 Received: (qmail 12667 invoked by uid 0); 16 Nov 2012 01:48:00 -0000 Received: (qmail 32120 invoked by uid 0); 15 Nov 2012 17:57:04 -0000 Received: from unknown (HELO atl4mhib42.myregisteredsite.com) (209) by 0 with SMTP; 15 Nov 2012 17:57:04 -0000 Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by atl4mhib42.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAFHv1nv032376 for ; Thu, 15 Nov 2012 12:57:01 -0500 Received: from hub.freebsd.org (hub.FreeBSD.org [8.8.178.136]) by mx2.freebsd.org (Postfix) with ESMTP id 4B6AB3B5D7B; Thu, 15 Nov 2012 17:56:37 +0000 (UTC) Received: from hub.FreeBSD.org (hub.FreeBSD.org [8.8.178.136]) by hub.freebsd.org (Postfix) with ESMTP id 686CA3DC; Thu, 15 Nov 2012 17:56:37 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3CBF29D for ; Thu, 15 Nov 2012 17:56:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id A537B8FC14 for ; Thu, 15 Nov 2012 17:56:23 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so2409833oag.13 for ; Thu, 15 Nov 2012 09:56:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Q8SFrS7WLIfT9llpZ/gg0GR2wFSWpUMEED98gONNncI=; b=L4oHlgxKV/uYmCGap7vFNxxc9yj8pf1wPMQ/E0rFSoRPkAlCpEdjYDnGRjSqucEoFr OgwrlB9HXn33zD+MgtvJsuI677U+uKobP2tUBRFI3x3EwUf3jJmbEpl8TYQPJjN5PyBr P0M8vt1Uh+eCa3sZ9BIpumOictAkpy2Q6W0mig1f32IzN48xguZeEnMmvlNyw6zeOA0O JZJnyELCb1zG3ODmzOiLHAWbrxXYeYFWlwAJfXQ3auwSB1NmnlabHofQxk8H1gbsSxes OCJIKNa+UIvG8a/M9dKJW6WtVDt1oMz/hwu34HS75q98M7yd6b5b0RI92kQBXwgNd4Gh 1hvQ== Received: by 10.60.10.133 with SMTP id i5mr1574894oeb.11.1353002182724; Thu, 15 Nov 2012 09:56:22 -0800 (PST) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id m8sm12902611oeb.3.2012.11.15.09.56.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 09:56:21 -0800 (PST) Subject: Re: [RFQ] make witness panic an option Mime-Version: 1.0 (Apple Message framework v1085) From: Warner Losh In-Reply-To: Date: Thu, 15 Nov 2012 10:56:17 -0700 Message-Id: <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> References: <1353001175.1217.153.camel@revolution.hippie.lan> To: attilio@FreeBSD.org X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmSwLPuMypES8ja2cHJ1nzIsffgVbdDtBnp+r8cH7mCpLt82C6AKIRmmKwU8cbD7QZF/Rnh X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-SpamScore: 0 X-MailHub-Apparently-To: mjm@michaelmeltzer.com X-MailHub-Forwarded: Yes Cc: Ian Lepore , Adrian Chadd , freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 01:48:01 -0000 On Nov 15, 2012, at 10:47 AM, Attilio Rao wrote: > On 11/15/12, Ian Lepore wrote: >> On Wed, 2012-11-14 at 22:15 -0800, Adrian Chadd wrote: >>> Hi all, >>> >>> When debugging and writing wireless drivers/stack code, I like to >>> sprinkle lots of locking assertions everywhere. However, this does >>> cause things to panic quite often during active development. >>> >>> This patch (against stable/9) makes the actual panic itself >>> configurable. It still prints the message regardless. >>> >>> This has allowed me to sprinkle more locking assertions everywhere to >>> investigate whether particular paths have been hit or not. I don't >>> necessarily want those to panic the kernel. >>> >>> I'd like everyone to consider this for FreeBSD-HEAD. >>> >>> Thanks! >> >> I strongly support this, because I'm tired of having to hack it in by >> hand every time I need it. >> >> You can't boot an arm platform right now (on freebsd 8, 9, or 10) >> without a LOR very early in the boot. Once you get past that, 2 or 3 >> device drivers I use panic way before we even get to mounting root. >> Those panics can clearly be ignored, because we've been shipping >> products for years based on this code. (It's on my to-do list to fix >> them, but more pressing problems are higher on the list.) > > This is a ridicolous motivation. > What are the panics in question? Why they are not fixed yet? > Without WITNESS_KDB you should not panic even in cases where WITNESS > yells. So if you do, it means there is a more subdole breakage going > on here. > > Do you really think that an abusable mechanism will help here rather > than fixing the actual problems? > >> When a new problem crops up that isn't harmless, it totally sucks that I >> can't just turn on witness without first hacking the code to make the >> known problems non-panicky. > > I really don't understand what are these "harmless problems" here. > I just know one and it is between the dirhash lock and the bufwait > lock for UFS, which is carefully documented in the code comments. All > the others cases haven't been analyzed deeply enough to quantify them > as "harmless". > > Can you please make real examples? It sounds like he's more worried about introducing LoRs into his wireless code. They are harmless, for him, and he can fix them by reloading the driver. They are only harmful if he loses a race. Warner _______________________________________________ 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-arch@FreeBSD.ORG Fri Nov 16 02:22:28 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9CFDBB7; Fri, 16 Nov 2012 02:22:28 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 585238FC16; Fri, 16 Nov 2012 02:22:28 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id qAG2MQKi027104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 15 Nov 2012 20:22:26 -0600 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 15 Nov 2012 20:22:25 -0600 From: Devin Teske Subject: HEADS-UP: Boot Loader Interface Fixes Date: Thu, 15 Nov 2012 18:22:24 -0800 Message-ID: <9643EC52-E905-43FB-8B18-5EF052271725@fisglobal.com> To: MIME-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-15_07:2012-11-15,2012-11-15,1970-01-01 signatures=0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , Devin Teske X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 02:22:28 -0000 Hi All, I'm back with more changes to the boot loader menu. First, don't panic! Second, calm down! Let's go over where we've been so-far so we don't repeat it here. 1. Changing the order of items should be avoided as it "moves the goal post= s" Agreed. This is not always avoidable, but should be avoided if possible. 2. Hiding "Single User" mode behind a submenu is bad. Agreed. It's been suggested, "why can't it be an action item?" I've thought= about it and it doesn't seem right to be an action item because it's a set= ting in loader.conf(5). However, nobody said it can't be both an action ite= m _and_ a boolean option. =3D=3D=3D Now that we've covered those basics, let me explain the current situation: If you are a proponent of the "goal posts" argument, then you may find your= self astonished one day to find that the following procedure does not work: + Boot to beastie menu + Press V to enable verbosity + Press Enter to boot The reason the above may fail and violate POLA is because of the improvemen= ts made in SVN r241523. Since r241523, adding something like: boot_verbose=3D"YES" to loader.conf(5) will not cause the boot menu to display a default ON-stat= us for the Verbose boot option. In this case, booting and pressing V will d= isable verbose boot. Given that all boot options in the menu are dynamically-initializing and wi= ll inherit the states of their respective options from loader.conf(5), a ne= w problem emerges: Q. How does one go about restoring the defaults in the event that a system= doesn't boot? Furthermore, the person may not know what the defaults are. The need arises to have a "Load Defaults" option. However, the introduction of this new menu item would both crowd the main m= enu and (unless appended to the end) violate the first rule of not re-order= ing items (which we just argued that it doesn't matter if you memorize the = numbers, their initial state may be negated from what the user expects). The latter arguments of crowded main-menu and that the memorization of numb= ers is broken right now brings up the good idea of utilizing submenus (reas= oning that if we have to make a change, best to make a change that can last= ). =3D=3D=3D I want to move the boot options into a submenu. This submenu will have all = the boot options you see today on the main menu. At the same time, add a "Load Defaults" action item for resetting the vario= us boot options to their hard-coded defaults (overriding loader.conf(5) inh= eritance). =3D=3D=3D While proposing this, I realize that we need an easy way to get to single-u= ser mode. So in-addition to be able to access SUM as a boolean option in th= e "Boot Options" submenu, I propose adding a new "alternate boot" menu item= to the main menu. At the same time, I've recognized the need to have more feedback in the "Bo= ot" option. For example, it would be nice if setting boot_single=3D"YES" in= loader.conf(5) that the first menu item said "Boot Single User [Enter]" --= vociferating the default boot action. Meanwhile, the "Alternate Boot" (not= actually titled that) gives a quick and easy way of booting Multi-User in = the case of boot_single=3D"YES" or vice-versa. =3D=3D=3D Last, but not least, pictures=85 Here's the proposed new main-menu (with loader_color=3D"YES" in loader.conf= (5)): https://twitter.com/devinteske/status/267082532976218113 and here's the submenu for the Boot Options: https://twitter.com/devinteske/status/267083020400488449 --=20 Devin P.S. http://bikeshed.org =3D=3D=3D Make the following interface changes to my beastie boot menu: + Move boot options to a submenu + Add a new "Boot Single" menu item=20 + Make "Boot" item and new "Boot Single" item reverse when boot_single is s= et + Add new "Load Defaults" item (in new "Boot Options" submenu) for overridd= ing loader.conf(5) provided values with system defaults. PR: Submitted by: Reviewed by: adrian (co-mentor) [pending your review] Approved by: adrian (co-mentor) [pending your approval] Obtained from: MFC after: Security: --This line, and those below, will be ignored-- > Description of fields to fill in above: 76 columns --| > PR: If a GNATS PR is affected by the change. > Submitted by: If someone else sent in the change. > Reviewed by: If someone else reviewed your modification. > Approved by: If you needed approval for this commit. > Obtained from: If the change is from a third party. > MFC after: N [day[s]|week[s]|month[s]]. Request a reminder email. > Security: Vulnerability reference (one per line) or description. > Empty fields above will be automatically removed. M forth/menu-commands.4th M forth/menu.rc _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 02:32:23 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5CB80E2A for ; Fri, 16 Nov 2012 02:32:23 +0000 (UTC) (envelope-from postmaster@mailpod.hostingplatform.com) Received: from atl4mhob09.myregisteredsite.com (atl4mhob09.myregisteredsite.com [209.17.115.47]) by mx1.freebsd.org (Postfix) with ESMTP id E8B678FC14 for ; Fri, 16 Nov 2012 02:32:22 +0000 (UTC) Received: from mailpod1.hostingplatform.com (mailpod1.networksolutionsemail.com [206.188.198.65]) by atl4mhob09.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAG2WMLg023417 for ; Thu, 15 Nov 2012 21:32:22 -0500 Received: (qmail 12543 invoked by uid 0); 16 Nov 2012 02:32:21 -0000 Received: (qmail 26396 invoked by uid 0); 15 Nov 2012 17:59:33 -0000 Received: from unknown (HELO atl4mhib45.myregisteredsite.com) (209) by 0 with SMTP; 15 Nov 2012 17:59:33 -0000 Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by atl4mhib45.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAFHxWgl002275 for ; Thu, 15 Nov 2012 12:59:32 -0500 Received: from hub.freebsd.org (hub.FreeBSD.org [8.8.178.136]) by mx2.freebsd.org (Postfix) with ESMTP id 404623B5792; Thu, 15 Nov 2012 17:59:22 +0000 (UTC) Received: from hub.FreeBSD.org (hub.FreeBSD.org [8.8.178.136]) by hub.freebsd.org (Postfix) with ESMTP id 9950C67D; Thu, 15 Nov 2012 17:59:21 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 930BB5D5; Thu, 15 Nov 2012 17:59:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 52DCD8FC08; Thu, 15 Nov 2012 17:59:14 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so827459dad.13 for ; Thu, 15 Nov 2012 09:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lsTSqNwiglElUieJ8bqooKQr4sX4OF18lf04F75MTy8=; b=S8mPUyxGDmIVc8HeV1VfUdXHyup/tYBUkHsd3yqpmnN7IZPruYAPeG4wDDEG/+VytK 0LbCnfDICDl3dBD9K+4cgOMIhygxEc5BtYssIzW8xRC44egjO4HNM65b5tU9D3ME9pSZ eHPCfbq/IXmsRPLBnUcGx43QUzRvv5IKebGokwaSrfYjIWAXOsvu/CWtypTueDHr/RBs EfK8a7NOb6bEdfWzHj51MczjofdPEgNLG/m852o0Xx5w5pQZjD5WOwHoEyk5l6zX6bn+ TPHGsPqULygUHSaRs6UAsDvPKP+juAJF0+zaKPKv4PVH3uOBFUUkcoPMBPNBkPFKVAxO iokg== MIME-Version: 1.0 Received: by 10.68.247.134 with SMTP id ye6mr1210085pbc.69.1353002348592; Thu, 15 Nov 2012 09:59:08 -0800 (PST) Received: by 10.68.124.130 with HTTP; Thu, 15 Nov 2012 09:59:08 -0800 (PST) In-Reply-To: <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> References: <1353001175.1217.153.camel@revolution.hippie.lan> <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> Date: Thu, 15 Nov 2012 09:59:08 -0800 X-Google-Sender-Auth: od1Pefj0sjviGAww4NVES9DFaL4 Message-ID: Subject: Re: [RFQ] make witness panic an option From: Adrian Chadd To: Warner Losh X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-SpamScore: 0 X-MailHub-Apparently-To: mjm@michaelmeltzer.com X-MailHub-Forwarded: Yes Cc: attilio@freebsd.org, Ian Lepore , freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 02:32:23 -0000 On 15 November 2012 09:56, Warner Losh wrote: >> Do you really think that an abusable mechanism will help here rather > It sounds like he's more worried about introducing LoRs into his wireless code. They are harmless, for him, and he can fix them by reloading the driver. They are only harmful if he loses a race. LOR's and lock assertions. Ie, I want to find out at run time that a lock wasnt' held at a certain position but continue soldiering on. That's how I've been finding out all of the races in net80211/ath, as there wasn't locking where there needed to be. Adrian _______________________________________________ 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-arch@FreeBSD.ORG Fri Nov 16 02:38:53 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C60779; Fri, 16 Nov 2012 02:38:53 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 03B5C8FC08; Fri, 16 Nov 2012 02:38:52 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.5/8.14.5/NETPLEX) with ESMTP id qAG2cknV062370; Thu, 15 Nov 2012 21:38:46 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.7 (mail.netplex.net [204.213.176.10]); Thu, 15 Nov 2012 21:38:46 -0500 (EST) Date: Thu, 15 Nov 2012 21:38:46 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Devin Teske Subject: Re: HEADS-UP: Boot Loader Interface Fixes In-Reply-To: <9643EC52-E905-43FB-8B18-5EF052271725@fisglobal.com> Message-ID: References: <9643EC52-E905-43FB-8B18-5EF052271725@fisglobal.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Adrian Chadd , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 02:38:53 -0000 On Thu, 15 Nov 2012, Devin Teske wrote: > Hi All, > > I'm back with more changes to the boot loader menu. > > First, don't panic! > > Second, calm down! > > Let's go over where we've been so-far so we don't repeat it here. > > 1. Changing the order of items should be avoided as it "moves the goal posts" > > Agreed. This is not always avoidable, but should be avoided if possible. > > 2. Hiding "Single User" mode behind a submenu is bad. > > Agreed. It's been suggested, "why can't it be an action item?" I've thought about it and it doesn't seem right to be an action item because it's a setting in loader.conf(5). However, nobody said it can't be both an action item _and_ a boolean option. > > === > > Now that we've covered those basics, let me explain the current situation: > > If you are a proponent of the "goal posts" argument, then you may find yourself astonished one day to find that the following procedure does not work: > > + Boot to beastie menu > + Press V to enable verbosity > + Press Enter to boot > > The reason the above may fail and violate POLA is because of the improvements made in SVN r241523. Since r241523, adding something like: > > boot_verbose="YES" > > to loader.conf(5) will not cause the boot menu to display a default ON-status for the Verbose boot option. In this case, booting and pressing V will disable verbose boot. > > Given that all boot options in the menu are dynamically-initializing and will inherit the states of their respective options from loader.conf(5), a new problem emerges: > > Q. How does one go about restoring the defaults in the event that a system doesn't boot? > > Furthermore, the person may not know what the defaults are. > > The need arises to have a "Load Defaults" option. > > However, the introduction of this new menu item would both crowd the main menu and (unless appended to the end) violate the first rule of not re-ordering items (which we just argued that it doesn't matter if you memorize the numbers, their initial state may be negated from what the user expects). > > The latter arguments of crowded main-menu and that the memorization of numbers is broken right now brings up the good idea of utilizing submenus (reasoning that if we have to make a change, best to make a change that can last). > > === > > I want to move the boot options into a submenu. This submenu will have all the boot options you see today on the main menu. > > At the same time, add a "Load Defaults" action item for resetting the various boot options to their hard-coded defaults (overriding loader.conf(5) inheritance). > > === > > While proposing this, I realize that we need an easy way to get to single-user mode. So in-addition to be able to access SUM as a boolean option in the "Boot Options" submenu, I propose adding a new "alternate boot" menu item to the main menu. > > At the same time, I've recognized the need to have more feedback in the "Boot" option. For example, it would be nice if setting boot_single="YES" in loader.conf(5) that the first menu item said "Boot Single User [Enter]" -- vociferating the default boot action. Meanwhile, the "Alternate Boot" (not actually titled that) gives a quick and easy way of booting Multi-User in the case of boot_single="YES" or vice-versa. I always disliked adding the large FreeBSD logo and beastie to the boot screen. Nearly 3/4 of the real-estate is that. I'd rather put all the information on one screen and do away with the large logo and beastie. Perhaps there should be an option to "6: Show Large Logo and Beastie" ;-) -- DE From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 02:45:25 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6FE621E6; Fri, 16 Nov 2012 02:45:25 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 2D0728FC08; Fri, 16 Nov 2012 02:45:24 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id qAG2jN90031141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 15 Nov 2012 20:45:24 -0600 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 15 Nov 2012 20:45:23 -0600 Subject: Re: HEADS-UP: Boot Loader Interface Fixes MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Devin Teske In-Reply-To: Date: Thu, 15 Nov 2012 18:45:21 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: <8706EBE6-0068-49F5-9654-D0F3EE050331@fisglobal.com> References: <9643EC52-E905-43FB-8B18-5EF052271725@fisglobal.com> To: Daniel Eischen X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-15_07:2012-11-15,2012-11-15,1970-01-01 signatures=0 Cc: Adrian Chadd , Devin Teske , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 02:45:25 -0000 On Nov 15, 2012, at 6:38 PM, Daniel Eischen wrote: > On Thu, 15 Nov 2012, Devin Teske wrote: >=20 >> Hi All, >>=20 >> I'm back with more changes to the boot loader menu. >>=20 >> First, don't panic! >>=20 >> Second, calm down! >>=20 >> Let's go over where we've been so-far so we don't repeat it here. >>=20 >> 1. Changing the order of items should be avoided as it "moves the goal p= osts" >>=20 >> Agreed. This is not always avoidable, but should be avoided if possible. >>=20 >> 2. Hiding "Single User" mode behind a submenu is bad. >>=20 >> Agreed. It's been suggested, "why can't it be an action item?" I've thou= ght about it and it doesn't seem right to be an action item because it's a = setting in loader.conf(5). However, nobody said it can't be both an action = item _and_ a boolean option. >>=20 >> =3D=3D=3D >>=20 >> Now that we've covered those basics, let me explain the current situatio= n: >>=20 >> If you are a proponent of the "goal posts" argument, then you may find y= ourself astonished one day to find that the following procedure does not wo= rk: >>=20 >> + Boot to beastie menu >> + Press V to enable verbosity >> + Press Enter to boot >>=20 >> The reason the above may fail and violate POLA is because of the improve= ments made in SVN r241523. Since r241523, adding something like: >>=20 >> boot_verbose=3D"YES" >>=20 >> to loader.conf(5) will not cause the boot menu to display a default ON-s= tatus for the Verbose boot option. In this case, booting and pressing V wil= l disable verbose boot. >>=20 >> Given that all boot options in the menu are dynamically-initializing and= will inherit the states of their respective options from loader.conf(5), a= new problem emerges: >>=20 >> Q. How does one go about restoring the defaults in the event that a sys= tem doesn't boot? >>=20 >> Furthermore, the person may not know what the defaults are. >>=20 >> The need arises to have a "Load Defaults" option. >>=20 >> However, the introduction of this new menu item would both crowd the mai= n menu and (unless appended to the end) violate the first rule of not re-or= dering items (which we just argued that it doesn't matter if you memorize t= he numbers, their initial state may be negated from what the user expects). >>=20 >> The latter arguments of crowded main-menu and that the memorization of n= umbers is broken right now brings up the good idea of utilizing submenus (r= easoning that if we have to make a change, best to make a change that can l= ast). >>=20 >> =3D=3D=3D >>=20 >> I want to move the boot options into a submenu. This submenu will have a= ll the boot options you see today on the main menu. >>=20 >> At the same time, add a "Load Defaults" action item for resetting the va= rious boot options to their hard-coded defaults (overriding loader.conf(5) = inheritance). >>=20 >> =3D=3D=3D >>=20 >> While proposing this, I realize that we need an easy way to get to singl= e-user mode. So in-addition to be able to access SUM as a boolean option in= the "Boot Options" submenu, I propose adding a new "alternate boot" menu i= tem to the main menu. >>=20 >> At the same time, I've recognized the need to have more feedback in the = "Boot" option. For example, it would be nice if setting boot_single=3D"YES"= in loader.conf(5) that the first menu item said "Boot Single User [Enter]"= -- vociferating the default boot action. Meanwhile, the "Alternate Boot" (= not actually titled that) gives a quick and easy way of booting Multi-User = in the case of boot_single=3D"YES" or vice-versa. >=20 > I always disliked adding the large FreeBSD logo and beastie > to the boot screen. Nearly 3/4 of the real-estate is that. >=20 echo "loader_logo=3Dnone" >> /boot/loader.conf echo "loader_brand=3Dnone" >> /boot/loader.conf --=20 Devin > I'd rather put all the information on one screen and do > away with the large logo and beastie. Perhaps there > should be an option to "6: Show Large Logo and Beastie" ;-) >=20 > --=20 > DE _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 02:47:34 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9386D3B6; Fri, 16 Nov 2012 02:47:34 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 539F18FC12; Fri, 16 Nov 2012 02:47:34 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id qAG2lX9O001011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 15 Nov 2012 20:47:33 -0600 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.16) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 15 Nov 2012 20:47:32 -0600 Subject: Re: HEADS-UP: Boot Loader Interface Fixes MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Devin Teske In-Reply-To: <8706EBE6-0068-49F5-9654-D0F3EE050331@fisglobal.com> Date: Thu, 15 Nov 2012 18:47:30 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: <8225B7E0-B153-4511-9CFB-841C5FA8B327@fisglobal.com> References: <9643EC52-E905-43FB-8B18-5EF052271725@fisglobal.com> <8706EBE6-0068-49F5-9654-D0F3EE050331@fisglobal.com> To: Devin Teske X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-15_07:2012-11-15,2012-11-15,1970-01-01 signatures=0 Cc: Daniel Eischen , Adrian Chadd , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 02:47:34 -0000 On Nov 15, 2012, at 6:45 PM, Devin Teske wrote: >=20 > On Nov 15, 2012, at 6:38 PM, Daniel Eischen wrote: >=20 >> On Thu, 15 Nov 2012, Devin Teske wrote: >>=20 >>> Hi All, >>>=20 >>> I'm back with more changes to the boot loader menu. >>>=20 >>> First, don't panic! >>>=20 >>> Second, calm down! >>>=20 >>> Let's go over where we've been so-far so we don't repeat it here. >>>=20 >>> 1. Changing the order of items should be avoided as it "moves the goal = posts" >>>=20 >>> Agreed. This is not always avoidable, but should be avoided if possible. >>>=20 >>> 2. Hiding "Single User" mode behind a submenu is bad. >>>=20 >>> Agreed. It's been suggested, "why can't it be an action item?" I've tho= ught about it and it doesn't seem right to be an action item because it's a= setting in loader.conf(5). However, nobody said it can't be both an action= item _and_ a boolean option. >>>=20 >>> =3D=3D=3D >>>=20 >>> Now that we've covered those basics, let me explain the current situati= on: >>>=20 >>> If you are a proponent of the "goal posts" argument, then you may find = yourself astonished one day to find that the following procedure does not w= ork: >>>=20 >>> + Boot to beastie menu >>> + Press V to enable verbosity >>> + Press Enter to boot >>>=20 >>> The reason the above may fail and violate POLA is because of the improv= ements made in SVN r241523. Since r241523, adding something like: >>>=20 >>> boot_verbose=3D"YES" >>>=20 >>> to loader.conf(5) will not cause the boot menu to display a default ON-= status for the Verbose boot option. In this case, booting and pressing V wi= ll disable verbose boot. >>>=20 >>> Given that all boot options in the menu are dynamically-initializing an= d will inherit the states of their respective options from loader.conf(5), = a new problem emerges: >>>=20 >>> Q. How does one go about restoring the defaults in the event that a sy= stem doesn't boot? >>>=20 >>> Furthermore, the person may not know what the defaults are. >>>=20 >>> The need arises to have a "Load Defaults" option. >>>=20 >>> However, the introduction of this new menu item would both crowd the ma= in menu and (unless appended to the end) violate the first rule of not re-o= rdering items (which we just argued that it doesn't matter if you memorize = the numbers, their initial state may be negated from what the user expects). >>>=20 >>> The latter arguments of crowded main-menu and that the memorization of = numbers is broken right now brings up the good idea of utilizing submenus (= reasoning that if we have to make a change, best to make a change that can = last). >>>=20 >>> =3D=3D=3D >>>=20 >>> I want to move the boot options into a submenu. This submenu will have = all the boot options you see today on the main menu. >>>=20 >>> At the same time, add a "Load Defaults" action item for resetting the v= arious boot options to their hard-coded defaults (overriding loader.conf(5)= inheritance). >>>=20 >>> =3D=3D=3D >>>=20 >>> While proposing this, I realize that we need an easy way to get to sing= le-user mode. So in-addition to be able to access SUM as a boolean option i= n the "Boot Options" submenu, I propose adding a new "alternate boot" menu = item to the main menu. >>>=20 >>> At the same time, I've recognized the need to have more feedback in the= "Boot" option. For example, it would be nice if setting boot_single=3D"YES= " in loader.conf(5) that the first menu item said "Boot Single User [Enter]= " -- vociferating the default boot action. Meanwhile, the "Alternate Boot" = (not actually titled that) gives a quick and easy way of booting Multi-User= in the case of boot_single=3D"YES" or vice-versa. >>=20 >> I always disliked adding the large FreeBSD logo and beastie >> to the boot screen. Nearly 3/4 of the real-estate is that. >>=20 >=20 > echo "loader_logo=3Dnone" >> /boot/loader.conf Documented in beastie.4th(8) > echo "loader_brand=3Dnone" >> /boot/loader.conf Documented in brand.4th(8) > --=20 > Devin >=20 >=20 >> I'd rather put all the information on one screen and do >> away with the large logo and beastie. Perhaps there >> should be an option to "6: Show Large Logo and Beastie" ;-) >>=20 >> --=20 >> DE >=20 > _____________ > The information contained in this message is proprietary and/or confident= ial. 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 awa= re that any message addressed to our domain is subject to archiving and rev= iew by persons other than the intended recipient. Thank you. _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 02:50:30 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93156557; Fri, 16 Nov 2012 02:50:30 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3BD508FC13; Fri, 16 Nov 2012 02:50:30 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.5/8.14.5/NETPLEX) with ESMTP id qAG2oT44004452; Thu, 15 Nov 2012 21:50:29 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.7 (mail.netplex.net [204.213.176.10]); Thu, 15 Nov 2012 21:50:29 -0500 (EST) Date: Thu, 15 Nov 2012 21:50:29 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Devin Teske Subject: Re: HEADS-UP: Boot Loader Interface Fixes In-Reply-To: <8706EBE6-0068-49F5-9654-D0F3EE050331@fisglobal.com> Message-ID: References: <9643EC52-E905-43FB-8B18-5EF052271725@fisglobal.com> <8706EBE6-0068-49F5-9654-D0F3EE050331@fisglobal.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Adrian Chadd , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 02:50:30 -0000 On Thu, 15 Nov 2012, Devin Teske wrote: > > On Nov 15, 2012, at 6:38 PM, Daniel Eischen wrote: > >> I always disliked adding the large FreeBSD logo and beastie >> to the boot screen. Nearly 3/4 of the real-estate is that. >> > > echo "loader_logo=none" >> /boot/loader.conf > echo "loader_brand=none" >> /boot/loader.conf Yeah, yeah, I know :-) But if it wasn't the default and you had more real-state, would that change your menus? BTW, I do like your menus, and could get used to them. I would just prefer everything on the same screen. -- DE From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 03:01:38 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F855C74; Fri, 16 Nov 2012 03:01:38 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id C5D0D8FC1B; Fri, 16 Nov 2012 03:01:37 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.5/8.14.5/NETPLEX) with ESMTP id qAG31aHP013127; Thu, 15 Nov 2012 22:01:36 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.7 (mail.netplex.net [204.213.176.10]); Thu, 15 Nov 2012 22:01:37 -0500 (EST) Date: Thu, 15 Nov 2012 22:01:36 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Devin Teske Subject: Re: HEADS-UP: Boot Loader Interface Fixes In-Reply-To: Message-ID: References: <9643EC52-E905-43FB-8B18-5EF052271725@fisglobal.com> <8706EBE6-0068-49F5-9654-D0F3EE050331@fisglobal.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Adrian Chadd , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 03:01:38 -0000 On Thu, 15 Nov 2012, Daniel Eischen wrote: > On Thu, 15 Nov 2012, Devin Teske wrote: > >> >> On Nov 15, 2012, at 6:38 PM, Daniel Eischen wrote: >> >>> I always disliked adding the large FreeBSD logo and beastie >>> to the boot screen. Nearly 3/4 of the real-estate is that. >>> >> >> echo "loader_logo=none" >> /boot/loader.conf >> echo "loader_brand=none" >> /boot/loader.conf > > Yeah, yeah, I know :-) > > But if it wasn't the default and you had more > real-state, would that change your menus? > > BTW, I do like your menus, and could get used to > them. I would just prefer everything on the same > screen. Actually, the more I look at them, the more I like them - I think they're an improvement over the current menu. -- DE From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 04:07:43 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B337B00; Fri, 16 Nov 2012 04:07:43 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 0A0AF8FC15; Fri, 16 Nov 2012 04:07:42 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id qAG47fqV029591 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 15 Nov 2012 22:07:42 -0600 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 15 Nov 2012 22:07:40 -0600 Subject: Re: HEADS-UP: Boot Loader Interface Fixes MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Devin Teske In-Reply-To: Date: Thu, 15 Nov 2012 20:07:39 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: <0AC3461D-2B3C-4097-885A-95F302E7892B@fisglobal.com> References: <9643EC52-E905-43FB-8B18-5EF052271725@fisglobal.com> <8706EBE6-0068-49F5-9654-D0F3EE050331@fisglobal.com> To: Daniel Eischen X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-16_01:2012-11-15,2012-11-16,1970-01-01 signatures=0 Cc: Adrian Chadd , Devin Teske , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 04:07:43 -0000 On Nov 15, 2012, at 6:50 PM, Daniel Eischen wrote: > On Thu, 15 Nov 2012, Devin Teske wrote: >=20 >>=20 >> On Nov 15, 2012, at 6:38 PM, Daniel Eischen wrote: >>=20 >>> I always disliked adding the large FreeBSD logo and beastie >>> to the boot screen. Nearly 3/4 of the real-estate is that. >>>=20 >>=20 >> echo "loader_logo=3Dnone" >> /boot/loader.conf >> echo "loader_brand=3Dnone" >> /boot/loader.conf >=20 > Yeah, yeah, I know :-) >=20 > But if it wasn't the default and you had more > real-state, would that change your menus? >=20 The menu just wasn't designed to handle more than 8 configurable options wi= th a static optional "Reboot", bringing the max to 9 total. Giving more screen real estate won't change that and it's non-trivial to ex= tend the code to allow items in the A-Z range. > BTW, I do like your menus, and could get used to > them. I would just prefer everything on the same > screen. >=20 I find I rarely (if ever) use those options (beside single-user -- which wa= s elevated to new heights in this patch). One of the things I like about this new menu is that it restores the 8.x fu= nctionality that if you press "s", you immediately boot into single-user (u= nlike 9.0 and 9.1 where you'll have to press "s" then Enter -- if this patc= h makes it into HEAD in time for 9.2, I'll MFC and 9.2+ will act like 8.3 a= nd older). --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 07:15:03 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7979D9B; Fri, 16 Nov 2012 07:15:03 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 378F28FC13; Fri, 16 Nov 2012 07:15:02 +0000 (UTC) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qAG77Bo3032135; Fri, 16 Nov 2012 18:07:11 +1100 Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qAG770Ih009910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Nov 2012 18:07:02 +1100 Date: Fri, 16 Nov 2012 18:07:00 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Jung-uk Kim Subject: Re: [RFC] Generic population count function In-Reply-To: <50A548C6.5070208@FreeBSD.org> Message-ID: <20121116171923.L1135@besplex.bde.org> References: <50A43B52.8030102@FreeBSD.org> <50A477BA.4020700@freebsd.org> <50A548C6.5070208@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-Cloudmark-Score: 0 X-Optus-Cloudmark-Analysis: v=2.0 cv=F/YP7ddN c=1 sm=1 a=nz2LO5XVLtEA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=hMQG39urcAQA:10 a=cqvmlmxeAAAA:8 a=qDOkOHFhAAAA:8 a=d9KzjkUFrCz0tZpBnxYA:9 a=CjuIK1q_8ugA:10 a=t_ttxzwXqboA:10 a=gosoKpmXwM4A:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 07:15:03 -0000 On Thu, 15 Nov 2012, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2012-11-15 00:03:54 -0500, Julian Elischer wrote: >> there are more efficient algorithms than the one you show in >> bitcount.h see the bit-twidling site: >> >> http://graphics.stanford.edu/~seander/bithacks.html > > Yes, I know that. __bitcount32() is a fall-back for *unsupported* > compilers anyway, I didn't see much point in improving it further. If Unsupported arches? That is most of them, since most don't have popcount in hardware. I still think the fallback should be to a simple lookup table. The old bitcount32() and bitcount16() do lots of shifts by more than 1, so they assume that the hardware has a fast barrel shifter. This assumption is satisfied on x86 starting with i486 IIRC. They have lots of instructions so they assume that instructions are fast. This assumption is not quite satisfied on modern x86, since there are many serial dependencies between the instructions. A simple lookup method would assume fast memory, which is usually not satisified, or cached memory, which often is. The optimality of alternative implementations is even more MD. The above URL gives some 64-bit implementations for 14, 24 and 32-bit counts (the magic in __bitcount32() can be optimized by using wider masks), but that is obviously not going to work well if it is used on 32-bit systems where the 64-bit arithmetic is emulated. > you are looking for better population count functions, this site is > better, actually: > > http://www.dalkescientific.com/writings/diary/archive/2011/11/02/faster_popcount_update.html It agrees with me by saying that the conclusion in 2008 was that the lookup table was competitive :-). Things are a little different now, but it is even more complicated to even consider all the possibilities. The best methods (when there is no hardware popcount) mostly use SSE, and that should have been better in 2008 too, but SSE is not always available even on x86, and is unavailable in practice in the kernel (you don't want to switch the FP state just to do a couple of popcounts). gcc's builtin popcount is fairly useless since it often reduces to a libcall. I just tried __builtin_popcount() and got the following results: - gcc-3.3.3: unavailable - gcc-4.2.1: reduces to the libcall of __popcountdi2, at least with no -march and with -march=native on freefall. __popcountdi2 is used for both 32-bit and 64-bit counts. - clang: does the same bitcount32() inline, with the final 2 shifts optimized to a single multiplication. That is with no -march. With -march=native, it issues a popcountl instruction. Similarly in both cases for __builtin_popcountl(). Unsimilarly for __builtin_popcountimax(): clang is broken and doesn't have it. It only has __builtin_popcount[2-letter-expletive](). Not too bad, but possibly still worse than a libcall could do: - distributions can't be compiled with -march=native, so they can't use popcount[lq], but perhaps the library can - bitcount32() is probably suboptimal for a shift-and-mask version on a 64-bit arch. Bruce From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 07:19:38 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6ADE5E51; Fri, 16 Nov 2012 07:19:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id ED4F78FC0C; Fri, 16 Nov 2012 07:19:36 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA12480; Fri, 16 Nov 2012 09:19:34 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TZGD8-000135-3s; Fri, 16 Nov 2012 09:19:34 +0200 Message-ID: <50A5E904.9040808@FreeBSD.org> Date: Fri, 16 Nov 2012 09:19:32 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: attilio@FreeBSD.org Subject: Re: [RFQ] make witness panic an option References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> <50A555BD.1010105@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ian Lepore , Adrian Chadd , freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 07:19:38 -0000 on 16/11/2012 01:38 Attilio Rao said the following: > On Thu, Nov 15, 2012 at 8:51 PM, Andriy Gapon wrote: >> on 15/11/2012 22:00 Adrian Chadd said the following: >>> But I think my change is invaluable for development, where you want to >>> improve and debug the locking and lock interactions of a subsystem. >> >> My practical experience was that if you mess up one lock in one place, then it >> is a total mess further on. but apparently you've got a different practical >> experience :) >> What would indeed be invaluable to _me_ - if the LOR messages also produced the >> stack(s) where a supposedly correct lock order was learned. > > Please note that the "supposedly correct lock order", as for the > definition that it is correct, can be used in several different > stacks. I don't see the point of saving it somewhere. > The only helpful case would be if the "wrong order" is catched first. > If this is really the case, I suggest you to force the order you > expect in the static table so that the first time the wrong order > happens it yells. Exactly my point - if I am a user of some code, not its developer, and I don't know which one is the correct order I would have had the complete information from the very start instead of having to jump through the hoops. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 07:22:36 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54E6AFEE; Fri, 16 Nov 2012 07:22:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EFA858FC08; Fri, 16 Nov 2012 07:22:33 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA12528; Fri, 16 Nov 2012 09:22:29 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TZGFw-00013D-SJ; Fri, 16 Nov 2012 09:22:28 +0200 Message-ID: <50A5E9B4.5040807@FreeBSD.org> Date: Fri, 16 Nov 2012 09:22:28 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Alfred Perlstein Subject: Re: [RFQ] make witness panic an option References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> <50A555BD.1010105@FreeBSD.org> <50A578A6.1030005@mu.org> In-Reply-To: <50A578A6.1030005@mu.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, Ian Lepore , Adrian Chadd , freebsd-hackers@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 07:22:36 -0000 on 16/11/2012 01:20 Alfred Perlstein said the following: > We need to enable developers to skip these areas and test their own code. I wish that there was a magic knob to ignore build breakages, so that the developers could test how their own code compiles :-) On a serious note, why stop here? E.g. Solaris seems to have knob to ignore all asserts (just to print a message, but not panic). -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 08:26:43 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 00161BA; Fri, 16 Nov 2012 08:26:42 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id CAB2D8FC08; Fri, 16 Nov 2012 08:26:42 +0000 (UTC) Received: from Alfreds-MacBook-Pro-5.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 5A55C1A3D93; Fri, 16 Nov 2012 00:26:41 -0800 (PST) Message-ID: <50A5F8C1.6010700@mu.org> Date: Fri, 16 Nov 2012 00:26:41 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: [RFQ] make witness panic an option References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> <50A555BD.1010105@FreeBSD.org> <50A578A6.1030005@mu.org> <50A5E9B4.5040807@FreeBSD.org> In-Reply-To: <50A5E9B4.5040807@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, Ian Lepore , Adrian Chadd , freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 08:26:43 -0000 On 11/15/12 11:22 PM, Andriy Gapon wrote: > on 16/11/2012 01:20 Alfred Perlstein said the following: >> We need to enable developers to skip these areas and test their own code. > I wish that there was a magic knob to ignore build breakages, so that the > developers could test how their own code compiles :-) There is, it's called updating to known good tinderbox build and basing changes off of that. > > On a serious note, why stop here? E.g. Solaris seems to have knob to ignore all > asserts (just to print a message, but not panic). > There is no reason why not to add such a thing, in fact it would be really handy for some of our users who need asserts, but sometimes can't clean up the entire code base. Adding another option to tag asserts so that it was sort of like: KASSERT((cond, section, "string")); would be interesting, then you could turn KASSERTS on based on "vfs" or possibly file by file. -Alfred From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 09:43:54 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89B06239; Fri, 16 Nov 2012 09:43:54 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id E554D8FC16; Fri, 16 Nov 2012 09:43:52 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qAG9hffi001324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Nov 2012 20:43:43 +1100 Date: Fri, 16 Nov 2012 20:43:41 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Jung-uk Kim Subject: Re: [RFC] Generic population count function In-Reply-To: <50A57279.3040607@FreeBSD.org> Message-ID: <20121116181327.B1135@besplex.bde.org> References: <50A43B52.8030102@FreeBSD.org> <20121115181009.D42162@besplex.bde.org> <50A57279.3040607@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-Cloudmark-Score: 0 X-Optus-Cloudmark-Analysis: v=2.0 cv=F/YP7ddN c=1 sm=1 a=nz2LO5XVLtEA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=hMQG39urcAQA:10 a=-IBTbTj7cW--95rJWrEA:9 a=CjuIK1q_8ugA:10 a=HwjIeC0YGvoPcmIo:21 a=x2ltjYn3tV1NASuS:21 a=bxQHXO5Py4tHmhUgaywp5w==:117 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 09:43:54 -0000 On Thu, 15 Nov 2012, Jung-uk Kim wrote: > On 2012-11-15 03:32:50 -0500, Bruce Evans wrote: >> The implementation of the ffs() family has similar non-problems. >> No one cares because they are rarely used, but... cperciva@ wrote >> the lookup table part of the following set of implementations of >> ffs() and fls(). A lookup table is the best general method, though >> it can be beaten by unportable methodw in some cases. I added more >> methods and a test framework to this (test framework not always >> included). The methods are: - gcc builtin - cpufunc inline > > Talking about cpufunc ffsl(), I found something strange about clang: My old optimization is probably wrong on amd64 for this anyway, since all amd64 CPUs have cmove so there is no poor branching in the gcc builtin to avoid (I should also check this on i386 -- maybe gcc's branching is best if the CPU has a branch predictor. No x86 CPUs had branch prediction when my old optimization was implemented (except i486 predicts always in a fixed way)). amd64 cpufunc.h changed ffs() to use __builtin_ffs, but for some reason it still uses my old optimization for ffsl(). > % cat ffs.c > #include > #include > int ffs_cpufunc(long x) /* copied from cpufunc.h as is */ > { return (x == 0 ? x : (int)bsfq((u_long)x) + 1); } > int ffs_builtin(long x) > { return (__builtin_ffsl(x)); } > > % clang -O2 -c ffs.c > % objdump -d ffs.o > > ffs.o: file format elf64-x86-64-freebsd > > Disassembly of section .text: > > 0000000000000000 : > 0: 48 85 ff test %rdi,%rdi > 3: 74 21 je 26 > 5: 48 89 7c 24 f8 mov %rdi,-0x8(%rsp) > a: 48 0f bc 4c 24 f8 bsf -0x8(%rsp),%rcx This seems to be the i386 ffs() cpufunc, since it only does a 32-bit bsf. I get a 64-bit bsf, but similarly strange memory operations and shifting (see below). > 10: 48 c1 e1 20 shl $0x20,%rcx > 14: 48 b8 00 00 00 00 01 mov $0x100000000,%rax > 1b: 00 00 00 > 1e: 48 01 c8 add %rcx,%rax > 21: 48 c1 e8 20 shr $0x20,%rax > 25: c3 retq > 26: 31 c0 xor %eax,%eax > 28: c3 retq > 29: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) > > 0000000000000030 : > 30: 48 0f bc cf bsf %rdi,%rcx > 34: ff c1 inc %ecx > 36: 31 c0 xor %eax,%eax > 38: 48 85 ff test %rdi,%rdi > 3b: 0f 45 c1 cmovne %ecx,%eax > 3e: c3 retq > > Note clang generates very inefficient code for ffsl() from cpufunc.h. > It is using memory, setting an unused bit, etc. :-( Even the builtin takes 1 more instruction than the best gcc one. I get the following for @ .type g,@function @ g: # @g @ .cfi_startproc @ # BB#0: # %entry @ testq %rdi, %rdi @ je .LBB1_1 @ # BB#2: # %cond.false.i @ movq %rdi, -8(%rsp) @ #APP @ bsfq -8(%rsp),%rcx Bogus memory operations. @ #NO_APP @ shlq $32, %rcx @ movabsq $4294967296, %rax # imm = 0x100000000 Even stranger. BTW, the assembler code is low-quality in a different way than gdb's disassembly. The annotation helps. gcc would only print the decimal value, which is fairly easy to decrypt to the shifted 1 bit here, but usually isn't. @ addq %rcx, %rax @ shrq $32, %rax @ # kill: EAX EAX RAX The annotation gives a hint about the strange shifting. It seems to be something to do with partial register conversions. @ ret @ .LBB1_1: @ xorl %eax, %eax @ # kill: EAX EAX RAX @ ret @ .Ltmp1: @ .size g, .Ltmp1-g @ .cfi_endproc This was easy to fix, though I don't understand the fix :-). First, bsfq() bogusly requrns u_long instead of int (this may be my fault for returning u_int in i386 bsf(). The hardware generates an unsigned value, but we don't want that in the API). bsfq() returns a result in rax instead of in eax, and for some reason this confuses clang into generating the strange shifts. Apparently it is trying to handle partial register or ABI problems. When we return an int in eax, are we required to do anything with the top bits in rax? I know that some operations clear them automagically, but not what happens for incl. Maybe incl does the right thing, but does it slowly if the partial register is not handled properly, and the shifting is to handle it properly. Anyway, after changing bsfq() to return int (using a bad type/hardware pun to pretend that bsfq only sets the low bits, the generated code becomes): @ .type g,@function @ g: # @g @ .cfi_startproc @ # BB#0: # %entry @ testq %rdi, %rdi @ je .LBB1_1 @ # BB#2: # %cond.false.i @ movq %rdi, -8(%rsp) @ #APP @ bsfq -8(%rsp),%eax @ #NO_APP @ incl %eax @ ret @ .LBB1_1: @ xorl %eax, %eax @ ret @ .Ltmp1: @ .size g, .Ltmp1-g @ .cfi_endproc Here is the bad type/hardware pun: @ static __inline int @ bsfq(u_long mask) @ { @ int result; @ @ __asm __volatile("bsfq %1,%0" : "=r" (result) : "rm" (mask)); @ return (result); @ } I just changed the return type to int, and the type of `result' to int. But the latter is not really right, since bsfq really produces a 64-bit value. If there are any partial register problems, then I would have expected clang to do better knowing that the value is 64 bits. ffsl() casts the value returned by bsfq() to int, so that the addition is only a 32-bit one. clang cannot know that the upper 33 bits are always 0 so that the cast cannot overflow and the behaviour is defined. It seems to be handling the undefined case in an unusual way. Suppose that bsfq() returns (1 << 31) so that the behaviour is in fact undefined. Then the usual undefined behaviour is for casting it to int to produce the 32-bit INT_MIN, and then adding 1 to produce (INT_MIN + 1). clang's fancy shifting code instead first shifts to (1 << 63), then adds (1 << 32), then shifts back to give the same result except now with the upper bits all 0, while (INT_MIN + 1) would have the upper bits all 1 if it were promoted to 64 bits or if the upper bits were automatically set to 1 to sign-extend the result of incl (does this happen?). If the type of `result' is left as u_long so that there is no type pun in the asm, but the function type is changed to int, then the strange shifts are still produced. This is unsuprising, since we this just doubles the conversion to int. It is more suprising that if we do the addition of 1 on u_longs, then clang still produces the strange shifts -- it is careful not to use incl to add 1 even in this case, but shifts so that it can add (1 << 32). clang doesn't produce the strange shifts if bsfq() is replaced by a non-inline function that returns u_long. It still shows the "kill EAX" annotation then. Another thing that works is changing the return expression from (mask == 0 ? mask : ...) to (mask == 0 ? 0 : ...). Apparently clang doesn't properly optimize away the promotion of '(int)bsfq(...) + 1)' to long to match the type of `mask'. Replacing the 0 by 0L confuses it again. Here is a cut-down example: @ unsigned long foo(void); @ @ int @ bar(unsigned long mask) @ { @ return (mask == 0 ? 0L : (int)foo() + 1); @ } Now the further cutting down of removing the (int) cast makes the problem go away. So fairly ordinary code is affected by this. Maybe I was wrong about it having no effect in otherwise-not-cut-down example. The memory operations are obviously possible because the constraint in the asm allows them, but why does clang prefer them when the arg starts in a register? Removing the allowance would pessimize cases where the arg is not in a register. > Both GCC 4.2 and 4.8 generate "good code", of course: > > % gcc -O2 -c ffs.c > % objdump -d ffs.o > > ffs.o: file format elf64-x86-64-freebsd > > Disassembly of section .text: > > 0000000000000000 : > 0: 31 c0 xor %eax,%eax > 2: 48 85 ff test %rdi,%rdi > 5: 74 07 je e > 7: 48 0f bc c7 bsf %rdi,%rax > b: 83 c0 01 add $0x1,%eax > e: f3 c3 repz retq je takes 1 cycle for the usual case of branch not taken on i486, so this is good for i486. With branch prediction, IIRC the initial prediction for cold branches is "taken" for forward branches (so that if (foo) branches over the presumed-special case for foo). The above is backwards for that. I thought that gcc generated a branch with order something like the reverse of the above, but now I can't find any version of gcc that generates a branch for __builtin_ffs(). gcc-3.3.3 -march=i386 generates a setcc and 2 more instructions than the add after the bsf. setcc is not as good as cmove, and on i386 it takes 4/5 cycles, and on i486 it takes 4/3 cycles. The branch must be much better on i486, though I don't really believe its official timing of 1/3 for not-taken/taken. > 0000000000000010 : > 10: 48 0f bc ff bsf %rdi,%rdi > 14: 48 c7 c0 ff ff ff ff mov $0xffffffffffffffff,%rax > 1b: 48 0f 44 f8 cmove %rax,%rdi > 1f: 48 83 c7 01 add $0x1,%rdi > 23: 89 f8 mov %edi,%eax > 25: c3 retq This is not as good as the gcc48 version (it has 1 more instruction) to compensate for building the result in a wrong place (%edi instead of %eax), but I get the gcc48 code from gcc-4.2.1 too. > % gcc48 -O2 -c ffs.c > % objdump -d ffs.o > > ffs.o: file format elf64-x86-64-freebsd > > Disassembly of section .text: > > 0000000000000000 : > 0: 31 c0 xor %eax,%eax > 2: 48 85 ff test %rdi,%rdi > 5: 75 09 jne 10 > 7: f3 c3 repz retq > 9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) > 10: 48 0f bc c7 bsf %rdi,%rax > 14: 83 c0 01 add $0x1,%eax > 17: c3 retq > 18: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1) > 1f: 00 This does a lot of padding for the branch target. Another reason to avoid branches. Here the branching and the padding for it are just bad, since we expect the branch to not be taken. gcc48 is guessing the branch probabilities backwards (see below). Ignore some of what I said about organizing the branch for best prediction. I was thinking that the branch was in the asm so that gcc couldn't organize it. But it is in the C code, and gcc is organizing it strangely. I tried adding __predict_true() and __predict_false(). It is __predict_false() that gives the current organization, for both gcc-4.2.1 and clang. This shows that the above is backwards about the default for cold branches, and that the organization without any __predict_foo() is correct for gcc4.2.1 and clang but backwards for gcc48. > 0000000000000020 : > 20: 48 0f bc c7 bsf %rdi,%rax > 24: 48 c7 c2 ff ff ff ff mov $0xffffffffffffffff,%rdx > 2b: 48 0f 44 c2 cmove %rdx,%rax > 2f: 48 83 c0 01 add $0x1,%rax > 33: c3 retq Bruce From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 12:34:52 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 08817902; Fri, 16 Nov 2012 12:34:52 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 16BD28FC13; Fri, 16 Nov 2012 12:34:49 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so2648482lbb.13 for ; Fri, 16 Nov 2012 04:34:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=h1VKn6jICIer4+luGNM9zcnP28FEZvV9ZvIyCumJXYk=; b=ZGONhXRn+YAOh6j3pMTFoerFG5ky186UaeeodpSdx4XU+7GltscoNT54SNxM/15LLL 2SV/JYPod6xtZ/XflHs3SUluy8d0dYyUCivMvtHkCKWHhqTXHffR/qaycZnU4G3q+4zo yMIkBxsrRR9Fr4dmzrpOlU04aaQIpXSpZlMrPF/zdMrG7R56hCpLoOSbFS+keeeMiyOS +LbLoDOBgrYDfOWHqYnf0yAZPtK/giVcXKpRn5P6OdEo1tiSJSiYL6Qd9ionNj+FtOXc tnUpmg+JtbUNhQxppCyqQDmBa8wQ0tW2X7QA3x8zK1GYkqJcMxudq0wy1CuHgnYpxTij euuA== MIME-Version: 1.0 Received: by 10.152.110.234 with SMTP id id10mr4158218lab.15.1353069288423; Fri, 16 Nov 2012 04:34:48 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Fri, 16 Nov 2012 04:34:48 -0800 (PST) In-Reply-To: <50A5E904.9040808@FreeBSD.org> References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> <50A555BD.1010105@FreeBSD.org> <50A5E904.9040808@FreeBSD.org> Date: Fri, 16 Nov 2012 12:34:48 +0000 X-Google-Sender-Auth: rUcjWfXHcYOS78nbvmgr34faToI Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: Ian Lepore , Adrian Chadd , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 12:34:52 -0000 On Fri, Nov 16, 2012 at 7:19 AM, Andriy Gapon wrote: > on 16/11/2012 01:38 Attilio Rao said the following: >> On Thu, Nov 15, 2012 at 8:51 PM, Andriy Gapon wrote: >>> on 15/11/2012 22:00 Adrian Chadd said the following: >>>> But I think my change is invaluable for development, where you want to >>>> improve and debug the locking and lock interactions of a subsystem. >>> >>> My practical experience was that if you mess up one lock in one place, then it >>> is a total mess further on. but apparently you've got a different practical >>> experience :) >>> What would indeed be invaluable to _me_ - if the LOR messages also produced the >>> stack(s) where a supposedly correct lock order was learned. >> >> Please note that the "supposedly correct lock order", as for the >> definition that it is correct, can be used in several different >> stacks. I don't see the point of saving it somewhere. >> The only helpful case would be if the "wrong order" is catched first. >> If this is really the case, I suggest you to force the order you >> expect in the static table so that the first time the wrong order >> happens it yells. > > Exactly my point - if I am a user of some code, not its developer, and I don't > know which one is the correct order I would have had the complete information > from the very start instead of having to jump through the hoops. I don't agree -- such informations are only useful to developers and also what should we do, store all the valid stacktraces? I don't understand what are you expecting here honestly. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 18:18:35 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CB0D611; Fri, 16 Nov 2012 18:18:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id B7B558FC13; Fri, 16 Nov 2012 18:18:34 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kp6so2176966pab.13 for ; Fri, 16 Nov 2012 10:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nRysIY4X4RfararhPqj5VTqIbtfZCBOY1GFCTBbZ3Dw=; b=FcDn2FmlGFtb+K+5mZHGtACC7Ij9zrmR5cJ4epJc7ie3geFXj1gTQrctK6SZPRb7FB po358bqxbjrxOS+qD7DCVhAjq5bZrtVRfv92sz6SvS63i4A4sqPUaloUhQykQCVpyBOm gua5z3LBGVhntQU14c+AzEj3ia5dw5zLc67EXj6aiDZAbkjbKKUI2FMUZXUq9RooRlm4 tVtpNPqah7MFfS1vJuV4IPL2hZ/Ol/icdzbp8mjUGQVEgXZ8OoOG52aOG0CQpPKvMask B8JDeBNmL9FPFk1ST4USPevkxDcOnEGadl7ENKyJBM1Ykk9oJROJPtlzD1oG2NhKhVdo qdRg== MIME-Version: 1.0 Received: by 10.68.251.197 with SMTP id zm5mr17414616pbc.30.1353089914166; Fri, 16 Nov 2012 10:18:34 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Fri, 16 Nov 2012 10:18:34 -0800 (PST) In-Reply-To: <50A5F8C1.6010700@mu.org> References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> <50A555BD.1010105@FreeBSD.org> <50A578A6.1030005@mu.org> <50A5E9B4.5040807@FreeBSD.org> <50A5F8C1.6010700@mu.org> Date: Fri, 16 Nov 2012 10:18:34 -0800 X-Google-Sender-Auth: 4fp_vWprDQa8_kIohSiLQx8kh2k Message-ID: Subject: Re: [RFQ] make witness panic an option From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 Cc: attilio@freebsd.org, Ian Lepore , freebsd-arch@freebsd.org, Andriy Gapon , freebsd-hackers@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 18:18:35 -0000 On 16 November 2012 00:26, Alfred Perlstein wrote: > Adding another option to tag asserts so that it was sort of like: > > KASSERT((cond, section, "string")); would be interesting, then you could > turn KASSERTS on based on "vfs" or possibly file by file. That's orthogonal to my developer-focused request. I'm also a big fan of correctly using asserts/panics - ie, asserts shouldn't replace correct error handling. (Yes, I'm guilty of this in ath(4), but I have plans soon to rectify this.) Adrian From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 18:36:08 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2633BAE4; Fri, 16 Nov 2012 18:36:08 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id F2FE28FC08; Fri, 16 Nov 2012 18:36:07 +0000 (UTC) Received: from Alfreds-MacBook-Pro-5.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id F05911A3DB3; Fri, 16 Nov 2012 10:36:06 -0800 (PST) Message-ID: <50A68796.60603@mu.org> Date: Fri, 16 Nov 2012 10:36:06 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [RFQ] make witness panic an option References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> <50A555BD.1010105@FreeBSD.org> <50A578A6.1030005@mu.org> <50A5E9B4.5040807@FreeBSD.org> <50A5F8C1.6010700@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: attilio@freebsd.org, Ian Lepore , freebsd-arch@freebsd.org, Andriy Gapon , freebsd-hackers@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 18:36:08 -0000 On 11/16/12 10:18 AM, Adrian Chadd wrote: > On 16 November 2012 00:26, Alfred Perlstein wrote: > >> Adding another option to tag asserts so that it was sort of like: >> >> KASSERT((cond, section, "string")); would be interesting, then you could >> turn KASSERTS on based on "vfs" or possibly file by file. > That's orthogonal to my developer-focused request. I'm also a big fan > of correctly using asserts/panics - ie, asserts shouldn't replace > correct error handling. > (Yes, I'm guilty of this in ath(4), but I have plans soon to rectify this.) > > > > Adrian I apologize if you took a wishlist item for me as a request for you to take on/augment your patch. It was not my intention. Back to your work, I like your patch quite a bit, I am wondering though if it can be worked into something under witness_kdb though. -Alfred