From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 3 08:15:22 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9CEC1065672 for ; Sun, 3 Apr 2011 08:15:22 +0000 (UTC) (envelope-from andreast@FreeBSD.org) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 769F08FC12 for ; Sun, 3 Apr 2011 08:15:21 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-8-131.flashcable.ch [91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id p337wYlK030342 for ; Sun, 3 Apr 2011 09:58:36 +0200 (CEST) (envelope-from andreast@FreeBSD.org) Message-ID: <4D9828AA.3030206@FreeBSD.org> Date: Sun, 03 Apr 2011 09:58:34 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: Subject: kernel dumps on powerpc/pmap questions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 08:15:22 -0000 Hello all, to investigate a system lockup I need to implement kerneldumps on powerpc. Well, exactly on PowerMacs. The booke should already support this feature. Right now I'm at the point where I can dump something, means the mechanism to be able to get a (core) dump for example via 'call doadump' in db works. I can restore the dump via savecore. I took the approach from booke and implemented the necessary functions for PowerMacs. But here I'm offline. I do not understand what I want to dump, means which part of the memory. Once I know what to dump, where do I find the information, which addresses? How can I get a picture of the memory organization form powermacs? Is there a pointer available about pmap in the kernel to find out a bit more on this topic? What is really needed to be able to run kgdb on a core file to be able to find where the kernel crashed? I know the questions are a bit vague, but I need an entry point. I appreciate any pointer to implement this feature. Tia, Andreas From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 3 11:17:46 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16F911065670 for ; Sun, 3 Apr 2011 11:17:46 +0000 (UTC) (envelope-from aavzz@yandex.ru) Received: from forward15.mail.yandex.net (forward15.mail.yandex.net [95.108.130.119]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6AB8FC0A for ; Sun, 3 Apr 2011 11:17:45 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward15.mail.yandex.net (Yandex) with ESMTP id 899359E11DA for ; Sun, 3 Apr 2011 15:17:43 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1301829463; bh=tcTosqmZyDp88GkYqRM39vhIJw8twaEEPocxnxI96cY=; h=Subject:From:To:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=APjcUiW0unS4dIvR5U9C8n2yslgjUbejYEiVOnF8x1XRDLwmLoajDR41yL6B1S5TY SzWt9vw5tPODd5DWMu+wpCbO1tpiDLT5Zqs9i1G95NgD91gGZt4Lpv9hN2QvNLCsrC 8kJdR9/16hG96QSHTUHJG44LZilkAoL/gAOjyFW8= Received: from [10.88.1.200] (unknown [91.210.24.40]) by smtp13.mail.yandex.net (Yandex) with ESMTPA id 2EF9B389805C for ; Sun, 3 Apr 2011 15:17:43 +0400 (MSD) From: Alex Zimnitsky To: freebsd-hackers@freebsd.org In-Reply-To: <1301766412.2122.9.camel@localhost> References: <1301766412.2122.9.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Sun, 03 Apr 2011 15:19:35 +0400 Message-ID: <1301829575.2165.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit Subject: Re: cp1251 screenmap X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 11:17:46 -0000 Arghhh, that was keymap actually /usr/share/syscons/keymaps/ru.koi8-r.kbd | V /usr/share/syscons/keymaps/ru.cp1251.kbd sorry On Sat, 2011-04-02 at 21:46 +0400, Alex Zimnitsky wrote: > Hello, hackers > > Screenmap for cp1251 appears to be missing. > I tweaked a little koi8-r screenmap to produce cp1251 one. > > Here it goes > > > > -------------------CUT----------------- CUT -------------------------- > # alt > # scan cntrl alt alt cntrl lock > # code base shift cntrl shift alt shift cntrl shift state > # ------------------------------------------------------------------ > 000 nop nop nop nop nop nop nop nop O > 001 esc esc nop nop 155 155 debug nop O > 002 '1' '!' nop nop 177 161 nop nop O > 003 '2' '@' nul nul 178 192 128 128 O > 004 '3' '#' nop nop 179 163 nop nop O > 005 '4' '$' nop nop 180 164 nop nop O > 006 '5' '%' nop nop 181 165 nop nop O > 007 '6' '^' rs rs 182 222 158 158 O > 008 '7' '&' nop nop 183 166 nop nop O > 009 '8' '*' nop nop 184 170 nop nop O > 010 '9' '(' nop nop 185 168 nop nop O > 011 '0' ')' nop nop 176 169 nop nop O > 012 '-' '_' us us 173 223 159 159 O > 013 '=' '+' nop nop 189 171 nop nop O > 014 bs bs del del 136 136 255 255 O > 015 ht btab nop nop 137 btab nop nop O > 016 'q' 'Q' dc1 dc1 241 209 145 145 C > 017 'w' 'W' etb etb 247 215 151 151 C > 018 'e' 'E' enq enq 229 197 133 133 C > 019 'r' 'R' dc2 dc2 242 210 146 146 C > 020 't' 'T' dc4 dc4 244 212 148 148 C > 021 'y' 'Y' em em 249 217 153 153 C > 022 'u' 'U' nak nak 245 213 149 149 C > 023 'i' 'I' ht ht 233 201 137 137 C > 024 'o' 'O' si si 239 207 143 143 C > 025 'p' 'P' dle dle 240 208 144 144 C > 026 '[' '{' esc esc 219 251 155 155 O > 027 ']' '}' gs gs 221 253 157 157 O > 028 cr cr nl nl 141 141 138 138 O > 029 lctrl lctrl lctrl lctrl lctrl lctrl lctrl lctrl O > 030 'a' 'A' soh soh 225 193 129 129 C > 031 's' 'S' dc3 dc3 243 211 147 147 C > 032 'd' 'D' eot eot 228 196 132 132 C > 033 'f' 'F' ack ack 230 198 134 134 C > 034 'g' 'G' bel bel 231 199 135 135 C > 035 'h' 'H' bs bs 232 200 136 136 C > 036 'j' 'J' nl nl 234 202 138 138 C > 037 'k' 'K' vt vt 235 203 139 139 C > 038 'l' 'L' ff ff 236 204 140 140 C > 039 ';' ':' nop nop 187 186 nop nop O > 040 ''' '"' nop nop 167 162 nop nop O > 041 '`' '~' nop nop 224 254 nop nop O > 042 lshift lshift lshift lshift lshift lshift lshift lshift O > 043 '\' '|' fs fs 220 252 156 156 O > 044 'z' 'Z' sub sub 250 218 154 154 C > 045 'x' 'X' can can 248 216 152 152 C > 046 'c' 'C' etx etx 227 195 131 131 C > 047 'v' 'V' syn syn 246 214 150 150 C > 048 'b' 'B' stx stx 226 194 130 130 C > 049 'n' 'N' so so 238 206 142 142 C > 050 'm' 'M' cr cr 237 205 141 141 C > 051 ',' '<' nop nop 172 188 nop nop O > 052 '.' '>' nop nop 174 190 nop nop O > 053 '/' '?' nop nop 175 191 nop nop O > 054 rshift rshift rshift rshift rshift rshift rshift rshift O > 055 '*' '*' nl nl 170 170 138 138 O > 056 lalt lalt lalt lalt lalt lalt lalt lalt O > 057 ' ' ' ' nul ' ' 160 160 susp 160 O > 058 alock clock clock clock clock clock clock clock O > 059 fkey01 fkey13 fkey25 fkey37 scr01 scr11 scr01 scr11 O > 060 fkey02 fkey14 fkey26 fkey38 scr02 scr12 scr02 scr12 O > 061 fkey03 fkey15 fkey27 fkey39 scr03 scr13 scr03 scr13 O > 062 fkey04 fkey16 fkey28 fkey40 scr04 scr14 scr04 scr14 O > 063 fkey05 fkey17 fkey29 fkey41 scr05 scr15 scr05 scr15 O > 064 fkey06 fkey18 fkey30 fkey42 scr06 scr16 scr06 scr16 O > 065 fkey07 fkey19 fkey31 fkey43 scr07 scr07 scr07 scr07 O > 066 fkey08 fkey20 fkey32 fkey44 scr08 scr08 scr08 scr08 O > 067 fkey09 fkey21 fkey33 fkey45 scr09 scr09 scr09 scr09 O > 068 fkey10 fkey22 fkey34 fkey46 scr10 scr10 scr10 scr10 O > 069 nlock nlock nlock nlock nlock nlock nlock nlock O > 070 slock slock slock slock slock slock slock slock O > 071 fkey49 '7' '7' '7' 183 183 183 183 N > 072 fkey50 '8' '8' '8' 184 184 184 184 N > 073 fkey51 '9' '9' '9' 185 185 185 185 N > 074 fkey52 '-' '-' '-' 173 173 173 173 N > 075 fkey53 '4' '4' '4' 180 180 180 180 N > 076 fkey54 '5' '5' '5' 181 181 181 181 N > 077 fkey55 '6' '6' '6' 182 182 182 182 N > 078 fkey56 '+' '+' '+' 171 171 171 171 N > 079 fkey57 '1' '1' '1' 177 177 177 177 N > 080 fkey58 '2' '2' '2' 178 178 178 178 N > 081 fkey59 '3' '3' '3' 179 179 179 179 N > 082 fkey60 '0' '0' '0' 176 176 176 176 N > 083 del '.' '.' '.' 174 174 boot boot N > 084 alock alock alock alock alock alock alock alock O > 085 nop nop nop nop nop nop nop nop O > 086 nop nop nop nop nop nop nop nop O > 087 fkey11 fkey23 fkey35 fkey47 scr11 scr11 scr11 scr11 O > 088 fkey12 fkey24 fkey36 fkey48 scr12 scr12 scr12 scr12 O > 089 cr cr nl nl 141 141 138 138 O > 090 rctrl rctrl rctrl rctrl rctrl rctrl rctrl rctrl O > 091 '/' '/' nop nop 175 175 nop nop O > 092 nscr pscr debug debug nop nop nop nop O > 093 ralt ralt ralt ralt ralt ralt ralt ralt O > 094 fkey49 fkey49 fkey49 fkey49 fkey49 fkey49 fkey49 fkey49 O > 095 fkey50 fkey50 fkey50 fkey50 fkey50 fkey50 fkey50 fkey50 O > 096 fkey51 fkey51 fkey51 fkey51 fkey51 fkey51 fkey51 fkey51 O > 097 fkey53 fkey53 fkey53 fkey53 fkey53 fkey53 fkey53 fkey53 O > 098 fkey55 fkey55 fkey55 fkey55 fkey55 fkey55 fkey55 fkey55 O > 099 fkey57 fkey57 fkey57 fkey57 fkey57 fkey57 fkey57 fkey57 O > 100 fkey58 fkey58 fkey58 fkey58 fkey58 fkey58 fkey58 fkey58 O > 101 fkey59 fkey59 fkey59 fkey59 fkey59 fkey59 fkey59 fkey59 O > 102 fkey60 paste fkey60 fkey60 fkey60 fkey60 fkey60 fkey60 O > 103 fkey61 fkey61 fkey61 fkey61 fkey61 fkey61 boot fkey61 O > 104 slock saver slock saver susp nop susp nop O > 105 fkey62 fkey62 fkey62 fkey62 fkey62 fkey62 fkey62 fkey62 O > 106 fkey63 fkey63 fkey63 fkey63 fkey63 fkey63 fkey63 fkey63 O > 107 fkey64 fkey64 fkey64 fkey64 fkey64 fkey64 fkey64 fkey64 O > 108 nop nop nop nop nop nop nop nop O > 109 nop nop nop nop nop nop nop nop O > 110 nop nop nop nop nop nop nop nop O > 111 nop nop nop nop nop nop nop nop O > 112 nop nop nop nop nop nop nop nop O > 113 nop nop nop nop nop nop nop nop O > 114 nop nop nop nop nop nop nop nop O > 115 nop nop nop nop nop nop nop nop O > 116 nop nop nop nop nop nop nop nop O > 117 nop nop nop nop nop nop nop nop O > 118 nop nop nop nop nop nop nop nop O > 119 nop nop nop nop nop nop nop nop O > 120 nop nop nop nop nop nop nop nop O > 121 nop nop nop nop nop nop nop nop O > 122 nop nop nop nop nop nop nop nop O > 123 nop nop nop nop nop nop nop nop O > 124 nop nop nop nop nop nop nop nop O > 125 nop nop nop nop nop nop nop nop O > 126 nop nop nop nop nop nop nop nop O > 127 nop nop nop nop nop nop nop nop O > 128 nop nop nop nop nop nop nop nop O > 129 esc esc nop nop 155 155 debug nop O > 130 '!' '1' nop nop 177 161 nop nop O > 131 '"' '2' nul nul 178 192 128 128 O > 132 ''' '3' nop nop 179 163 nop nop O > 133 '*' '4' nop nop 180 164 nop nop O > 134 ':' '5' nop nop 181 165 nop nop O > 135 ',' '6' rs rs 182 222 158 158 O > 136 '.' '7' nop nop 183 166 nop nop O > 137 ';' '8' nop nop 184 170 nop nop O > 138 '(' '9' nop nop 185 168 nop nop O > 139 ')' '0' nop nop 176 169 nop nop O > 140 '-' '_' us us 173 223 159 159 O > 141 '=' '+' nop nop 189 171 nop nop O > 142 bs bs del del 136 136 255 255 O > 143 ht btab nop nop 137 btab nop nop O > 144 233 201 dc1 dc1 241 209 145 145 C > 145 246 214 etb etb 247 215 151 151 C > 146 243 211 enq enq 229 197 133 133 C > 147 234 202 dc2 dc2 242 210 146 146 C > 148 229 197 dc4 dc4 244 212 148 148 C > 149 237 205 em em 249 217 153 153 C > 150 227 195 nak nak 245 213 149 149 C > 151 248 216 ht ht 233 201 137 137 C > 152 249 217 si si 239 207 143 143 C > 153 231 199 dle dle 240 208 144 144 C > 154 245 213 esc esc 219 251 155 155 C > 155 250 218 gs gs 221 253 157 157 C > 156 cr cr nl nl 141 141 138 138 O > 157 lctrl lctrl lctrl lctrl lctrl lctrl lctrl lctrl O > 158 244 212 soh soh 225 193 129 129 C > 159 251 219 dc3 dc3 243 211 147 147 C > 160 226 194 eot eot 228 196 132 132 C > 161 224 192 ack ack 230 198 134 134 C > 162 239 207 bel bel 231 199 135 135 C > 163 240 208 bs bs 232 200 136 136 C > 164 238 206 nl nl 234 202 138 138 C > 165 235 203 vt vt 235 203 139 139 C > 166 228 196 ff ff 236 204 140 140 C > 167 230 198 nop nop 187 186 nop nop C > 168 253 221 nop nop 167 162 nop nop C > 169 184 168 nop nop 224 254 nop nop C > 170 lshift lshift lshift lshift lshift lshift lshift lshift O > 171 '\' '|' fs fs 220 252 156 156 O > 172 255 223 sub sub 250 218 154 154 C > 173 247 215 can can 248 216 152 152 C > 174 241 209 etx etx 227 195 131 131 C > 175 236 204 syn syn 246 214 150 150 C > 176 232 200 stx stx 226 194 130 130 C > 177 242 210 so so 238 206 142 142 C > 178 252 220 cr cr 237 205 141 141 C > 179 225 193 nop nop 172 188 nop nop C > 180 254 222 nop nop 174 190 nop nop C > 181 '/' '?' nop nop 175 191 nop nop O > 182 rshift rshift rshift rshift rshift rshift rshift rshift O > 183 '*' '*' nl nl 170 170 138 138 O > 184 lalt lalt lalt lalt lalt lalt lalt lalt O > 185 ' ' ' ' nul ' ' 160 160 160 160 O > 186 alock clock clock clock clock clock clock clock O > 187 fkey01 fkey13 fkey25 fkey37 scr01 scr11 scr01 scr11 O > 188 fkey02 fkey14 fkey26 fkey38 scr02 scr12 scr02 scr12 O > 189 fkey03 fkey15 fkey27 fkey39 scr03 scr13 scr03 scr13 O > 190 fkey04 fkey16 fkey28 fkey40 scr04 scr14 scr04 scr14 O > 191 fkey05 fkey17 fkey29 fkey41 scr05 scr15 scr05 scr15 O > 192 fkey06 fkey18 fkey30 fkey42 scr06 scr16 scr06 scr16 O > 193 fkey07 fkey19 fkey31 fkey43 scr07 scr07 scr07 scr07 O > 194 fkey08 fkey20 fkey32 fkey44 scr08 scr08 scr08 scr08 O > 195 fkey09 fkey21 fkey33 fkey45 scr09 scr09 scr09 scr09 O > 196 fkey10 fkey22 fkey34 fkey46 scr10 scr10 scr10 scr10 O > 197 nlock nlock nlock nlock nlock nlock nlock nlock O > 198 slock slock slock slock slock slock slock slock O > 199 fkey49 '7' '7' '7' 183 183 183 183 N > 200 fkey50 '8' '8' '8' 184 184 184 184 N > 201 fkey51 '9' '9' '9' 185 185 185 185 N > 202 fkey52 '-' '-' '-' 173 173 173 173 N > 203 fkey53 '4' '4' '4' 180 180 180 180 N > 204 fkey54 '5' '5' '5' 181 181 181 181 N > 205 fkey55 '6' '6' '6' 182 182 182 182 N > 206 fkey56 '+' '+' '+' 171 171 171 171 N > 207 fkey57 '1' '1' '1' 177 177 177 177 N > 208 fkey58 '2' '2' '2' 178 178 178 178 N > 209 fkey59 '3' '3' '3' 179 179 179 179 N > 210 fkey60 '0' '0' '0' 176 176 176 176 N > 211 del '.' '.' '.' 174 174 boot boot N > 212 alock alock alock alock alock alock alock alock O > 213 nop nop nop nop nop nop nop nop O > 214 nop nop nop nop nop nop nop nop O > 215 fkey11 fkey23 fkey35 fkey47 scr11 scr11 scr11 scr11 O > 216 fkey12 fkey24 fkey36 fkey48 scr12 scr12 scr12 scr12 O > 217 cr cr nl nl 141 141 138 138 O > 218 rctrl rctrl rctrl rctrl rctrl rctrl rctrl rctrl O > 219 '/' '/' nop nop 175 175 nop nop O > 220 nscr pscr debug debug nop nop nop nop O > 221 ralt ralt ralt ralt ralt ralt ralt ralt O > 222 fkey49 fkey49 fkey49 fkey49 fkey49 fkey49 fkey49 fkey49 O > 223 fkey50 fkey50 fkey50 fkey50 fkey50 fkey50 fkey50 fkey50 O > 224 fkey51 fkey51 fkey51 fkey51 fkey51 fkey51 fkey51 fkey51 O > 225 fkey53 fkey53 fkey53 fkey53 fkey53 fkey53 fkey53 fkey53 O > 226 fkey55 fkey55 fkey55 fkey55 fkey55 fkey55 fkey55 fkey55 O > 227 fkey57 fkey57 fkey57 fkey57 fkey57 fkey57 fkey57 fkey57 O > 228 fkey58 fkey58 fkey58 fkey58 fkey58 fkey58 fkey58 fkey58 O > 229 fkey59 fkey59 fkey59 fkey59 fkey59 fkey59 fkey59 fkey59 O > 230 fkey60 paste fkey60 fkey60 fkey60 fkey60 fkey60 fkey60 O > 231 fkey61 fkey61 fkey61 fkey61 fkey61 fkey61 boot fkey61 O > 232 slock saver slock saver susp nop susp nop O > 233 fkey62 fkey62 fkey62 fkey62 fkey62 fkey62 fkey62 fkey62 O > 234 fkey63 fkey63 fkey63 fkey63 fkey63 fkey63 fkey63 fkey63 O > 235 fkey64 fkey64 fkey64 fkey64 fkey64 fkey64 fkey64 fkey64 O > 236 nop nop nop nop nop nop nop nop O > ---------------------------- CUT --------------------------------------- > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 3 12:15:02 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F150D106564A for ; Sun, 3 Apr 2011 12:15:01 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9350C8FC0A for ; Sun, 3 Apr 2011 12:15:01 +0000 (UTC) Received: by vxc34 with SMTP id 34so4472271vxc.13 for ; Sun, 03 Apr 2011 05:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=b9x50ZVFyqhyLTwSVUqrLwKbRS3mwem3QZIqabtPV1c=; b=LnGPgpFk7FSQjACzW2oZBeEDVWMgim2zXY5Qp0vPidIZyFAv5sbxJDQlpkaXv7n4nr TV9DHi3DIPCIZwPvIymTqmdlOxOxkNE9QGBBbuhcOKDNa3T9AvGncZpxvNWWRrHz3y6m YH6VD8j70R5Hd5fRiUylxc9UtNGz0ypGzF4n0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Y1A9xymNIRjyqpsL/8rYlL37fn+Jax4bDknGO02AYNizv/dcWCFz5qM4amxCm6fQLz nYTj9927bCjD5KncMPt/pciVFDwkdZfy3A44lJPc+SmApormlMoasibtr1eHwb4Oz1uw kfsCh5afPzZnC2AGfX1o8lN4U8KlbtPwfnHfc= MIME-Version: 1.0 Received: by 10.220.198.200 with SMTP id ep8mr1603410vcb.132.1301832899531; Sun, 03 Apr 2011 05:14:59 -0700 (PDT) Received: by 10.220.186.138 with HTTP; Sun, 3 Apr 2011 05:14:59 -0700 (PDT) In-Reply-To: <4D9828AA.3030206@FreeBSD.org> References: <4D9828AA.3030206@FreeBSD.org> Date: Sun, 3 Apr 2011 08:14:59 -0400 Message-ID: From: Super Bisquit To: Andreas Tobler Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: kernel dumps on powerpc/pmap questions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 12:15:02 -0000 Why don't you ask Whitehorn or other members of the FreeBSD PowerPC team this question. Very few of the hackers deal with anything outside of standard i386 and AMD64 platforms. nwhitehorn@freebsd.org chmeeedalf@gmail.com Justin Hibbits On 4/3/11, Andreas Tobler wrote: > Hello all, > > to investigate a system lockup I need to implement kerneldumps on > powerpc. Well, exactly on PowerMacs. The booke should already support > this feature. > > Right now I'm at the point where I can dump something, means the > mechanism to be able to get a (core) dump for example via 'call doadump' > in db works. I can restore the dump via savecore. > > I took the approach from booke and implemented the necessary functions > for PowerMacs. But here I'm offline. > > I do not understand what I want to dump, means which part of the memory. > Once I know what to dump, where do I find the information, which addresses? > > How can I get a picture of the memory organization form powermacs? > Is there a pointer available about pmap in the kernel to find out a bit > more on this topic? > > What is really needed to be able to run kgdb on a core file to be able > to find where the kernel crashed? > > I know the questions are a bit vague, but I need an entry point. > > I appreciate any pointer to implement this feature. > > Tia, > Andreas > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 3 12:17:40 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A72FE1065670; Sun, 3 Apr 2011 12:17:40 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2D4EF8FC16; Sun, 3 Apr 2011 12:17:39 +0000 (UTC) Received: by vws18 with SMTP id 18so4440090vws.13 for ; Sun, 03 Apr 2011 05:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7lPcZCE4bsvLbz7FA9QPC2+tMEcdhIyEz23W2arNgvc=; b=j+dlIxNT0XSEbyXInonBk3SL/ceW+ipAEhC7nTGU3cCbbaHXhSWTvfiwYALSjwR0C/ v3ve3Evn5sk2oTFhJsmy7xYLEOHemT0YlouKtNY5pIm7jfTXphDEeAGoEPWxBNSraBl3 NNAQT70nsbe6f8NZ3xahgiAYKcKnsC0r1ZbXA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Zy7ylgbXRQ1qjEtp3lgLPt38VvIcXG7xAv0mxVwCz9UYH/a5Vknzqo3COKZ9Bjfi+X ZQBcA/DJuihyGSQGqpfoy9PRTeTx+z+B6Yo1lC+mLGQZ7Rj+/5nHDWnWNfxsAu0gr2Y6 r6plMzuBfNb14O7J1RRCuDLwFVzPiIpxJfESQ= MIME-Version: 1.0 Received: by 10.220.193.193 with SMTP id dv1mr408376vcb.97.1301833058585; Sun, 03 Apr 2011 05:17:38 -0700 (PDT) Received: by 10.220.186.138 with HTTP; Sun, 3 Apr 2011 05:17:38 -0700 (PDT) In-Reply-To: References: <4D9828AA.3030206@FreeBSD.org> Date: Sun, 3 Apr 2011 08:17:38 -0400 Message-ID: From: Super Bisquit To: Andreas Tobler , nwhitehorn@freebsd.org, chmeeedalf@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: kernel dumps on powerpc/pmap questions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 12:17:40 -0000 Apologies; but, he can get more help from one of the two of you before he can get any from the FreeBSD hacker mailing list. On 4/3/11, Super Bisquit wrote: > Why don't you ask Whitehorn or other members of the FreeBSD PowerPC > team this question. Very few of the hackers deal with anything outside > of standard i386 and AMD64 platforms. > > nwhitehorn@freebsd.org > chmeeedalf@gmail.com Justin Hibbits > > > > On 4/3/11, Andreas Tobler wrote: >> Hello all, >> >> to investigate a system lockup I need to implement kerneldumps on >> powerpc. Well, exactly on PowerMacs. The booke should already support >> this feature. >> >> Right now I'm at the point where I can dump something, means the >> mechanism to be able to get a (core) dump for example via 'call doadump' >> in db works. I can restore the dump via savecore. >> >> I took the approach from booke and implemented the necessary functions >> for PowerMacs. But here I'm offline. >> >> I do not understand what I want to dump, means which part of the memory. >> Once I know what to dump, where do I find the information, which >> addresses? >> >> How can I get a picture of the memory organization form powermacs? >> Is there a pointer available about pmap in the kernel to find out a bit >> more on this topic? >> >> What is really needed to be able to run kgdb on a core file to be able >> to find where the kernel crashed? >> >> I know the questions are a bit vague, but I need an entry point. >> >> I appreciate any pointer to implement this feature. >> >> Tia, >> Andreas >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" >> > From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 3 18:25:06 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A647A106566B; Sun, 3 Apr 2011 18:25:06 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 4C1468FC14; Sun, 3 Apr 2011 18:25:05 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 5677245CA0; Sun, 3 Apr 2011 20:06:49 +0200 (CEST) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 45D3645C8A; Sun, 3 Apr 2011 20:06:44 +0200 (CEST) Date: Sun, 3 Apr 2011 20:06:36 +0200 From: Pawel Jakub Dawidek To: Andriy Gapon Message-ID: <20110403180636.GF1849@garage.freebsd.pl> References: <4D95E162.40605@FreeBSD.org> <4D95ECDE.1020504@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="27ZtN5FSuKKSZcBU" Content-Disposition: inline In-Reply-To: <4D95ECDE.1020504@FreeBSD.org> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: FreeBSD Hackers , FreeBSD Arch Subject: Re: looking for error codes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 18:25:06 -0000 --27ZtN5FSuKKSZcBU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 01, 2011 at 06:18:54PM +0300, Andriy Gapon wrote: > on 01/04/2011 18:04 Andrew Duane said the following: > > AFAIK, FreeBSD does not really detect read-only media. This was somethi= ng I had to add as a small project here at work, and was considering cleani= ng up to try to get into CURRENT. If there's a real need for it, I could sp= eed that up. > >=20 >=20 > Yes, that's exactly the problem that I am looking at. > So if you have anything to share it will be greatly appreciated at least = by me. > But I think many more people could benefit from it (e.g. those having SD/= SDHC/etc > cards). Once you detect read-only media, I suggest to implement the support by adding new DISKFLAG_READONLY to disk(9) API and simply deny write access in g_disk_access() when DISKFLAG_READONLY is set. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --27ZtN5FSuKKSZcBU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk2YtywACgkQForvXbEpPzSpQgCgyEDLFfXaU7g3MN7rug61d+k1 D+cAn0J9QZZxe24Qk2vi+GucC6KLIrkW =pJXb -----END PGP SIGNATURE----- --27ZtN5FSuKKSZcBU-- From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 3 19:06:27 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A98E106564A for ; Sun, 3 Apr 2011 19:06:27 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-qw0-f45.google.com (mail-qw0-f45.google.com [209.85.216.45]) by mx1.freebsd.org (Postfix) with ESMTP id BA65E8FC14 for ; Sun, 3 Apr 2011 19:06:26 +0000 (UTC) Received: by qwj8 with SMTP id 8so4434148qwj.18 for ; Sun, 03 Apr 2011 12:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=fgQYSEvI4h7ryuzL5R++mhL1Ahp1Z0Ko4IVzGZrbKQc=; b=UZW6h67pXaAK1LIPCfkcGkF79mlvy8Z4dQ0Z13vcurF7nDJqRPwKaH8rPRJksVb716 nEUcfQSwg7sqp9o3ejsFsNmawkYp7Cn9CoxmZGmXdJ6fSQd19PU7WD8dPJ026QRLuXa9 aIj7amUF2qN2qmckOnqccUqQBawOzeJecycQI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=nFSdwsZWLCvTabTkbdFTBHmwbuX91oBtCRiV77yuUji8ydrUp0Tc7+iuwwTEXU4rnH OIIkfvFnZnreho7bLAy9TATtzgkEvq+ucLPhneIIU+UJ657fe7OqBru/Oj4MnsAgE29L BRFrHZrCtU1fyiiyhtTc5Onu5GaDeq/ioG/pM= MIME-Version: 1.0 Received: by 10.224.138.16 with SMTP id y16mr5205604qat.255.1301857585822; Sun, 03 Apr 2011 12:06:25 -0700 (PDT) Received: by 10.224.20.19 with HTTP; Sun, 3 Apr 2011 12:06:25 -0700 (PDT) Date: Sun, 3 Apr 2011 14:06:25 -0500 Message-ID: From: Zhihao Yuan To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: my GSoC proposal "Multibyte Encoding Support in Nvi" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 19:06:27 -0000 Hi, The whole document in HTML is available at: http://socghop.appspot.com/gsoc/proposal/review/google/gsoc2011/zy/1 The reStructuredText source is available at: https://github.com/lichray/gsoc2011 Thanks to everyone who replied my post before :) -- Zhihao Yuan The best way to predict the future is to invent it. From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 3 19:09:17 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CC13106564A for ; Sun, 3 Apr 2011 19:09:17 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D32268FC16 for ; Sun, 3 Apr 2011 19:09:16 +0000 (UTC) Received: by bwz12 with SMTP id 12so4463813bwz.13 for ; Sun, 03 Apr 2011 12:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:from:date:message-id :subject:to:content-type; bh=FNMu7Q+k8jWTv8uuHzXaTAZXP/dKmhYfXuX+cThjV8s=; b=wcz0B1+mBxw5+CYcfmJIuvWPOZNmuhTXrE5187dIUEB/RmTt+jPWbfLGa8igiy7fF6 At+6SR5OxsKlvE53hNbE4sn6hwevvlA8lhMaPEHBBV8jZ8S127Qrp0a9tGeFKu7p2deh 7zkYQjyWPsGch13EciTH/v9T7vR77Kl//pu40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:from:date:message-id:subject:to:content-type; b=hOYSeL39vvZc3EvcvwsqsjXHft3jsFNOY8nHxLs1BPxjR9Nw/SWSVR0qeYKVTCp+oX /JXEKop1OsK2OpHwbs0TbUeTr16vZsvbTYz7PjxSK3WiEE9g0Nj0EFkjw1Tzb0ME0S+b /FVLd9yQdJ/odl7Y092Vecch1Xdg4TwtWg53I= Received: by 10.204.18.193 with SMTP id x1mr2045378bka.79.1301856044130; Sun, 03 Apr 2011 11:40:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.205.64.142 with HTTP; Sun, 3 Apr 2011 11:40:14 -0700 (PDT) From: Chris Rees Date: Sun, 3 Apr 2011 19:40:14 +0100 Message-ID: To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: State of FreeBSD/xbox X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: utisoft@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 19:09:17 -0000 Hi all, I've got an xbox running at my parents' house as a backup MX, among other things. Ages ago I updated it from 7.2 -> 8.1, and I ended up with no end of trouble, and finished by restoring a backup. I emailed rink@, although he replied it appears a case of ENOTIME. Am I the last person on the planet running FreeBSD on an Xbox? I'm planning on hacking around a bit to see if I can fix it next week, but I was wondering if anyone else had similar ideas or a solution! In short-- FreeBSD/xbox is bitrotted (or so it appears!) Chris From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 3 19:26:23 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE0AE106566B for ; Sun, 3 Apr 2011 19:26:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 65FC28FC14 for ; Sun, 3 Apr 2011 19:26:22 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p33JQIcN063338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Apr 2011 22:26:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p33JQISo039161; Sun, 3 Apr 2011 22:26:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p33JQIo0039160; Sun, 3 Apr 2011 22:26:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 3 Apr 2011 22:26:18 +0300 From: Kostik Belousov To: Chris Rees Message-ID: <20110403192618.GS78089@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6mXK9IF1od1efpEf" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: State of FreeBSD/xbox X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 19:26:24 -0000 --6mXK9IF1od1efpEf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 03, 2011 at 07:40:14PM +0100, Chris Rees wrote: > Hi all, >=20 > I've got an xbox running at my parents' house as a backup MX, among > other things. >=20 > Ages ago I updated it from 7.2 -> 8.1, and I ended up with no end of > trouble, and finished by restoring a backup. I emailed rink@, although > he replied it appears a case of ENOTIME. >=20 > Am I the last person on the planet running FreeBSD on an Xbox? I'm > planning on hacking around a bit to see if I can fix it next week, but > I was wondering if anyone else had similar ideas or a solution! >=20 > In short-- FreeBSD/xbox is bitrotted (or so it appears!) I wanted to remove XBOX for long time. With the introduction of Xen PV, i386/machdep.c became too convoluted. On the other hand, if you can bring it back to life, I definitely would not have an argument for removal. --6mXK9IF1od1efpEf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2YydoACgkQC3+MBN1Mb4hJkACfeysCC0QMOvR9F8EzzLFpuOyE KEgAoKl2VkOmzUBn/oYaKhMWVmOXGV/+ =Ww2R -----END PGP SIGNATURE----- --6mXK9IF1od1efpEf-- From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 3 20:23:52 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1866F106564A; Sun, 3 Apr 2011 20:23:52 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (unknown [IPv6:2001:aa8:ffff:2::fff0:2]) by mx1.freebsd.org (Postfix) with ESMTP id A2AE28FC18; Sun, 3 Apr 2011 20:23:51 +0000 (UTC) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.4/8.14.4) with ESMTP id p33KNntr055504; Sun, 3 Apr 2011 22:23:49 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.4/8.14.4/Submit) id p33KNnEX054921; Sun, 3 Apr 2011 22:23:49 +0200 (CEST) (envelope-from lars) Date: Sun, 3 Apr 2011 22:23:49 +0200 From: Lars Engels To: Kostik Belousov Message-ID: <20110403202349.GH14379@e-new.0x20.net> References: <20110403192618.GS78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/qIPZgKzMPM+y5U5" Content-Disposition: inline In-Reply-To: <20110403192618.GS78089@deviant.kiev.zoral.com.ua> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.1-RELEASE User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sun, 03 Apr 2011 20:35:37 +0000 Cc: freebsd-hackers@freebsd.org, ed@freebsd.org, Chris Rees Subject: Re: State of FreeBSD/xbox X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 20:23:52 -0000 --/qIPZgKzMPM+y5U5 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 03, 2011 at 10:26:18PM +0300, Kostik Belousov wrote: > On Sun, Apr 03, 2011 at 07:40:14PM +0100, Chris Rees wrote: > > Hi all, > >=20 > > I've got an xbox running at my parents' house as a backup MX, among > > other things. > >=20 > > Ages ago I updated it from 7.2 -> 8.1, and I ended up with no end of > > trouble, and finished by restoring a backup. I emailed rink@, although > > he replied it appears a case of ENOTIME. > >=20 > > Am I the last person on the planet running FreeBSD on an Xbox? I'm > > planning on hacking around a bit to see if I can fix it next week, but > > I was wondering if anyone else had similar ideas or a solution! > >=20 > > In short-- FreeBSD/xbox is bitrotted (or so it appears!) >=20 > I wanted to remove XBOX for long time. With the introduction of Xen PV, > i386/machdep.c became too convoluted. On the other hand, if you can > bring it back to life, I definitely would not have an argument for remova= l. Maybe Ed (CC'ed) can help you? --/qIPZgKzMPM+y5U5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk2Y11UACgkQKc512sD3afi94ACgnCZHr0sL8jTYVtfW77dtG2Ed lSwAmwbk3wOJ+woYHPfsWU5I9sxYrRqQ =5l9V -----END PGP SIGNATURE----- --/qIPZgKzMPM+y5U5-- From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 3 21:11:29 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3008106564A for ; Sun, 3 Apr 2011 21:11:29 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 92E688FC08 for ; Sun, 3 Apr 2011 21:11:29 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 665162A28CDB; Sun, 3 Apr 2011 23:11:28 +0200 (CEST) Date: Sun, 3 Apr 2011 23:11:28 +0200 From: Ed Schouten To: Kostik Belousov Message-ID: <20110403211128.GB14454@hoeg.nl> References: <20110403192618.GS78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kXdP64Ggrk/fb43R" Content-Disposition: inline In-Reply-To: <20110403192618.GS78089@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, Chris Rees Subject: Re: State of FreeBSD/xbox X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 21:11:30 -0000 --kXdP64Ggrk/fb43R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Chris, Kostik, * Kostik Belousov , 20110403 21:26: > On Sun, Apr 03, 2011 at 07:40:14PM +0100, Chris Rees wrote: > > In short-- FreeBSD/xbox is bitrotted (or so it appears!) Well, I did run FreeBSD HEAD on my Xbox only a couple of weeks ago and it worked properly. I remember jhb@ made some PCI changes some time ago that caused some breakage, but that got fixed as far as I know. So what kind of problems are you experiencing? > I wanted to remove XBOX for long time. With the introduction of Xen PV, > i386/machdep.c became too convoluted. On the other hand, if you can > bring it back to life, I definitely would not have an argument for remova= l. Sure. It was pretty awesome to see FreeBSD run on an Xbox, but nowadays you can even get Android phones having better specs. Say, if the Xbox code makes it hard to implement some kind of cool feature, I really wouldn't mind seeing it go, as long as it's left the way it is in the stable branches. --=20 Ed Schouten WWW: http://80386.nl/ --kXdP64Ggrk/fb43R Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQIcBAEBAgAGBQJNmOKAAAoJEG5e2P40kaK7VB8P/RHxhT2ITZ/7oyZuMvhvluSt iKTabl5rShg9EbzxCicqjA1xAT2mVGyHIRFOeZjlNARlO/KLDxylJgYrtl7P/Yv9 EGb2VMyA/f4+BUx+zDeox0TEFaxYudmMnOpUQFdV8ELaNBHonXXOyoZZ12rtI6I1 QKfQ9cf9K4yE/hpMTYE3NkAy+c7XjlfsqTo1U3dAqxZWxQTVm0Qa30fqYJRCuS7i yglprebhh827dvymxkfQZr1H79K14VL7FwlkLIMnGPzfy6rUx8FdfCRQtd1Icg0B dHTWsHVGIX2GWyDS8+UB548BkiUh6DpOC+htOkt3pCZIgyWosYb3KQudzW06kByt F7bwO4c39fIRLaxUX7Tt8oox/rKo05Bxb6ZQ/4p3ptdRBzIChDLbZqDiCDdi7gOJ Bw0leoHEWG6gWyNZe8EpKBBG1617doF7y68oaOGsNNxcluif7Xr+w6VrhLJY8hsk PJoORX1TQXi+hvWiJJ8etgMmU2/m8Om8kdhCa1IzEhT54T9WgCo+iTTZ0d3zjOwe ZHN1QSXbTUAK3zdRU4RkHocUt3L+JvBuBtKOilCu1AMjPU2v0/guXWhKYZn5qe9+ 7go9mzQ44gRBiWvpJWn2YTz71RjMVvDkRfTyPKDWui0WP2H7PUGVOi8thlMeVi64 T4qWlaJGDTwd96I1R1Uq =4y5X -----END PGP SIGNATURE----- --kXdP64Ggrk/fb43R-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 4 02:18:51 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0308B106564A for ; Mon, 4 Apr 2011 02:18:51 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id A93FA8FC0A for ; Mon, 4 Apr 2011 02:18:50 +0000 (UTC) Received: by iyj12 with SMTP id 12so6900200iyj.13 for ; Sun, 03 Apr 2011 19:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=lpBPQeqAw+lAEpspBg3VmCj1Lzfrpi51odEN8CPYsN8=; b=BKjmhfRoEZKQHSDCtfm2knL3HWtXsiVqChSmnigebLPWMOecyPDfsEl/4fK/T3876j hqrfheZvj0AIqS7NAbKnLpFKiw56xJfEONY/HJMalUFAK5kVp8vImtFNH/5rYeMhMcJ6 +Tz8pVkUcYhiUoph7nsZv0Gj8SYDOpLcddmQk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=KNzTosEgod+SLM4xtkQwyGt/gCmWSHe4tPzEqIidT3IOGprEwOPNXagAQHcl2Dq/QC CnRYWaFmRnJEhfHquFJu/3uzBaXQeoOZe71uMlqkFyOON9YZNRG97UcghdNZam9daBy2 Nc1V3+g0xCjSh8d69EnTf2bSTl+3VPLTNok5Q= Received: by 10.42.163.138 with SMTP id c10mr10225190icy.269.1301883529797; Sun, 03 Apr 2011 19:18:49 -0700 (PDT) Received: from DataIX.net (adsl-99-181-155-201.dsl.klmzmi.sbcglobal.net [99.181.155.201]) by mx.google.com with ESMTPS id 8sm3394452iba.21.2011.04.03.19.18.46 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Apr 2011 19:18:46 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p342IhKv095073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Apr 2011 22:18:44 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p342If2o095072; Sun, 3 Apr 2011 22:18:41 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sun, 3 Apr 2011 22:18:41 -0400 From: jhell To: kwiat@panic.pl Message-ID: <20110404021841.GA89599@DataIX.net> References: <20110119160404.5d47ad6f@stokrotka.t1.gda.wp-sa.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <20110119160404.5d47ad6f@stokrotka.t1.gda.wp-sa.pl> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/eyM1RI Cc: freebsd-hackers Subject: Re: Question about FreeBSD and long usernames X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 02:18:51 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Description: Bad use of vipw(8) and bad counting routines Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 19, 2011 at 04:04:04PM +0100, Mateusz Kwiatkowski wrote: > Hi,=20 >=20 > I have noticed inconsistent behaviour of some tools while working with > long usernames. >=20 I dont get why you would need or want to work with longer usernames but if that is your goal then lets continue below... > At first, 17 chars username (UT_NAMESIZE is set to 16, MAXLOGNAME to > 17): > # pw user add verylongusername=20 > pwd_mkdb: jira_pawprintgames: username too long >=20 The problem here is not ``verylongusername'' thats exactly 16 characters in the U.S. not sure where you think the other 2 characters came from. jira_pawprintgames: is 18 characters long and that is where pw(8) is bailing out. Utility is working correctly as it should here. > But it is possible to create such user with vipw: > # id verylongusername > uid=3D1005(verylongusername) gid=3D1003(users) groups=3D1003(users) As stated above your not adding a very long user name here, but vipw is exactly of the type (editor) does not really need to verify what your putting into the file and shouldnt... its editing and if you have added a user name that long then its a failure on the admins part for doing so. >=20 > We can make use of this account: > su - verylongusername > % id > uid=3D1005(verylongusername) gid=3D1003(users) groups=3D1003(users) I sure hope so its 16 charaters long. >=20 > # passwd verylongusername > Changing local password for verylongusername > New Password: > Retype New Password: > # Same as previous statement. >=20 > 18 chars username: > # id verylongusername1=20 > uid=3D1006(verylongusername1) gid=3D1003(users) groups=3D1003(users) >=20 > # su - verylongusername1 > su: username too long This is 17 characters, you are now exactly 1 character past the limit and this is where you start seeing failures and think it is an inconsistancy though everything before was correct except ``jira_pawprintgames'' >=20 > # sudo -u verylongusername1 id > uid=3D1006(verylongusername1) gid=3D1003(users) groups=3D1003(users) >=20 This is not of the base system, though the maintainer may be interested in a patch that makes this cooperate with the standard maximum length of a username. It may just be that sudo(1) is just mapping to the UID & GID here rather than checking lenght. > It's possible to change password: > # passwd verylongusername1 > Changing local password for verylongusername1 > New Password: > Retype New Password: > # It is not passwd's job to determine what it can and cannot set a password on so even in this situation if you have managed to vipw(8) and add a user with astronomical length, it is not the utilities fault its PEBKAC. >=20 > When trying to login with ssh (17 chars username worked ok): > Jan 19 14:46:08 xxxx sshd[39050]: setlogin(verylongusername1): > Invalid argument >=20 > Why some tools deny using long usernames, while > others permit? Should it be corrected? I do not see a problem at all using a correct length and not trying to force a username into the passwd by means of vipw(8). --=20 Regards, J. Hellenthal JJH48-ARIN 0x89D8547E --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x89D8547E iQEcBAEBAgAGBQJNmSqBAAoJEJBXh4mJ2FR+6DMH/3x8ddC/Rf+jgs1K52lUSpdc wzjekzEXEcgvPlXucnTf3CgD/OSs+45VIlUENVsHQZl7c448MidK/EYx4b/JkM8R Q5KtQ9qMjNBwHO7kO1iglUZv2jl+3adiWDSX/QZse9DjMa3yyOQeGohEx5tIFHi0 liKaMd3AK8gw019c5jLN4NpCEVJv+eT8cejMQi9NtSGNSXVJJ2xZjTLNE1VNIUOV I1x7cwNTxSuS5NFHoJ5LCuuJMgjeCIPomjletOQyS+fGNuxcK9Mkm/r1Jd16NTrh 1rAGQ82SLExKmIowAz89QHf7FgRD1qDa1N/GaiuDVsr9E7Jhcyejho9kwNzI/HA= =vwyb -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 4 03:34:54 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDBC0106566C for ; Mon, 4 Apr 2011 03:34:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 529BB8FC0A for ; Mon, 4 Apr 2011 03:34:54 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p343WoWx068720 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 3 Apr 2011 21:32:54 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 3 Apr 2011 21:32:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <67129025-D490-494B-8B82-01947229987F@bsdimp.com> References: To: utisoft@gmail.com X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sun, 03 Apr 2011 21:32:54 -0600 (MDT) Cc: freebsd-hackers@FreeBSD.org Subject: Re: State of FreeBSD/xbox X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 03:34:54 -0000 I always wanted to run FreeBSD/xbox, but I never got it going because I = never had the right hacker dongle... Warner On Apr 3, 2011, at 12:40 PM, Chris Rees wrote: > Hi all, >=20 > I've got an xbox running at my parents' house as a backup MX, among > other things. >=20 > Ages ago I updated it from 7.2 -> 8.1, and I ended up with no end of > trouble, and finished by restoring a backup. I emailed rink@, although > he replied it appears a case of ENOTIME. >=20 > Am I the last person on the planet running FreeBSD on an Xbox? I'm > planning on hacking around a bit to see if I can fix it next week, but > I was wondering if anyone else had similar ideas or a solution! >=20 > In short-- FreeBSD/xbox is bitrotted (or so it appears!) >=20 > Chris > _______________________________________________ > 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" >=20 >=20 From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 4 03:35:23 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04A981065670; Mon, 4 Apr 2011 03:35:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id AFE658FC1B; Mon, 4 Apr 2011 03:35:22 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p343UAtQ068716 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 3 Apr 2011 21:30:13 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20110403180636.GF1849@garage.freebsd.pl> Date: Sun, 3 Apr 2011 21:30:10 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <15B9A193-6298-459C-A2E3-E049C1E186FB@bsdimp.com> References: <4D95E162.40605@FreeBSD.org> <4D95ECDE.1020504@FreeBSD.org> <20110403180636.GF1849@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sun, 03 Apr 2011 21:30:13 -0600 (MDT) Cc: FreeBSD Hackers , Andriy Gapon , FreeBSD Arch Subject: Re: looking for error codes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 03:35:23 -0000 On Apr 3, 2011, at 12:06 PM, Pawel Jakub Dawidek wrote: > On Fri, Apr 01, 2011 at 06:18:54PM +0300, Andriy Gapon wrote: >> on 01/04/2011 18:04 Andrew Duane said the following: >>> AFAIK, FreeBSD does not really detect read-only media. This was = something I had to add as a small project here at work, and was = considering cleaning up to try to get into CURRENT. If there's a real = need for it, I could speed that up. >>>=20 >>=20 >> Yes, that's exactly the problem that I am looking at. >> So if you have anything to share it will be greatly appreciated at = least by me. >> But I think many more people could benefit from it (e.g. those having = SD/SDHC/etc >> cards). >=20 > Once you detect read-only media, I suggest to implement the support by > adding new DISKFLAG_READONLY to disk(9) API and simply deny write = access > in g_disk_access() when DISKFLAG_READONLY is set. And if I pop out the SD card and flip the switch, what then? Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 4 14:10:17 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D7CD1065670 for ; Mon, 4 Apr 2011 14:10:17 +0000 (UTC) (envelope-from philip@paeps.cx) Received: from rincewind.paeps.cx (rincewind.paeps.cx [IPv6:2002:596a:f092::149]) by mx1.freebsd.org (Postfix) with ESMTP id 148EF8FC1B for ; Mon, 4 Apr 2011 14:10:17 +0000 (UTC) Received: by rincewind.paeps.cx (Postfix, from userid 1001) id 2E07FD7445E; Mon, 4 Apr 2011 16:10:16 +0200 (CEST) Date: Mon, 4 Apr 2011 16:10:16 +0200 From: Philip Paeps To: hackers@freebsd.org Message-ID: <20110404141016.GL71940@rincewind.paeps.cx> Mail-Followup-To: hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-PGP-Fingerprint: 356B AE02 4763 F739 2FA2 E438 2649 E628 C5D3 4D05 X-Date: Prickle-Prickle, Discord 21, 3177 YOLD X-Phase-of-Moon: The Moon is Waxing Crescent (1% of Full) X-Philip-Conspiracy: There is no conspiracy Organization: Happily Disorganized User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Updating PCI vendors database X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 14:10:17 -0000 It looks like our /usr/share/misc/pci_vendors list (used only by pciconf as far as I can tell) has become rather stale. We also appear to be tracking sources which no longer exist. Would anyone object if I updated this list to source the same database used by Linux distributions at http://pciids.sourceforge.net/v2.2/pci.ids? It helps that our pciconf looks to be compatible with that format. We just ignore subvendor and subdevice, but it doesn't appear to matter that the file contains this information. I could cull the subvendor/subdevice from the list though. Any views? Reason I'm looking into this is because one of my customers would like their name to be correct when I import the driver I've been working on for them. :) - Philip -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 4 14:19:45 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 119AF106564A for ; Mon, 4 Apr 2011 14:19:45 +0000 (UTC) (envelope-from philip@paeps.cx) Received: from rincewind.paeps.cx (rincewind.paeps.cx [IPv6:2002:596a:f092::149]) by mx1.freebsd.org (Postfix) with ESMTP id CB06A8FC1E for ; Mon, 4 Apr 2011 14:19:44 +0000 (UTC) Received: by rincewind.paeps.cx (Postfix, from userid 1001) id 356C5D7445E; Mon, 4 Apr 2011 16:19:44 +0200 (CEST) Date: Mon, 4 Apr 2011 16:19:44 +0200 From: Philip Paeps To: hackers@freebsd.org Message-ID: <20110404141944.GN71940@rincewind.paeps.cx> Mail-Followup-To: hackers@freebsd.org References: <20110404141016.GL71940@rincewind.paeps.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110404141016.GL71940@rincewind.paeps.cx> X-PGP-Fingerprint: 356B AE02 4763 F739 2FA2 E438 2649 E628 C5D3 4D05 X-Date: Prickle-Prickle, Discord 21, 3177 YOLD X-Phase-of-Moon: The Moon is Waxing Crescent (1% of Full) X-Philip-Conspiracy: There is no conspiracy Organization: Happily Disorganized User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Updating PCI vendors database X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 14:19:45 -0000 On 2011-04-04 16:10:16 (+0200), Philip Paeps wrote: > Would anyone object if I updated this list to source the same database used > by Linux distributions at http://pciids.sourceforge.net/v2.2/pci.ids? It occurs to me that people would want to verify that this list does actually work and that we gain (rather than lose) coverage from it. A sanity test I've run on a couple of machines: % fetch http://pciids.sourceforge.net/v2.2/pci.ids % pciconf -lv > /tmp/pciconflv.old % PCICONF_VENDOR_DATABASE=pci.ids pciconf -lv >/tmp/pciconflv.new % diff -u /tmp/pciconflv.old /tmp/pciconflv.new In all cases I've seen so far, the new list yields better (more correct and up to date) results than the exising list. In no cases has pciconf complained about the new list. - Philip -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 4 14:31:55 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFEC0106564A for ; Mon, 4 Apr 2011 14:31:55 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id B17808FC15 for ; Mon, 4 Apr 2011 14:31:55 +0000 (UTC) Received: by pwj8 with SMTP id 8so1829162pwj.13 for ; Mon, 04 Apr 2011 07:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=i3yzNXaP3evrkb/CpPm+cw3hkAFfYiiI1rL6mb+7uLY=; b=P2Nzs1FfHipnaNL1QDz5lZekvxANg/pP+YYwxQApbjQQm6dndx5eR21TIOpzRxTNvo 0IiM+/gqHUCuE2yV1ZLpYEwSme4WttZe2Nhlhlvy/Ps4NGdarmprKG054XeqjOLtARfY 62XRtsJtcItgcYsGAbwcvfjI091BCFNx+9Fl4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=i49GsN27DZXTu5T1+UxzsP6MYAWsX9cPkI2LE7faKjM83axuhqmLAqgT0WwCO7Ydj9 24lN8sS0yQpWjH35de6SHJzWx+6tp3zRsIinvaba9Is87f8A+HBJSZ59hPha8iBrD1nr 5TtY85rfIn1K+sSh5+nTQblPwFFFvKmWt4Q0Q= MIME-Version: 1.0 Received: by 10.143.24.39 with SMTP id b39mr6307593wfj.341.1301927515065; Mon, 04 Apr 2011 07:31:55 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.68.42.3 with HTTP; Mon, 4 Apr 2011 07:31:53 -0700 (PDT) In-Reply-To: <20110404141944.GN71940@rincewind.paeps.cx> References: <20110404141016.GL71940@rincewind.paeps.cx> <20110404141944.GN71940@rincewind.paeps.cx> Date: Mon, 4 Apr 2011 07:31:53 -0700 X-Google-Sender-Auth: EU5Q1u5W6iaZ6Vm6lnE2hiTnHCw Message-ID: From: Garrett Cooper To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Philip Paeps Subject: Re: Updating PCI vendors database X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 14:31:56 -0000 On Mon, Apr 4, 2011 at 7:19 AM, Philip Paeps wrote: > On 2011-04-04 16:10:16 (+0200), Philip Paeps wrote: >> Would anyone object if I updated this list to source the same database u= sed >> by Linux distributions at http://pciids.sourceforge.net/v2.2/pci.ids? > > It occurs to me that people would want to verify that this list does actu= ally > work and that we gain (rather than lose) coverage from it. > > A sanity test I've run on a couple of machines: > > =A0% fetch http://pciids.sourceforge.net/v2.2/pci.ids > =A0% pciconf -lv > /tmp/pciconflv.old > =A0% PCICONF_VENDOR_DATABASE=3Dpci.ids pciconf -lv >/tmp/pciconflv.new > =A0% diff -u /tmp/pciconflv.old /tmp/pciconflv.new > > In all cases I've seen so far, the new list yields better (more correct a= nd up > to date) results than the exising list. =A0In no cases has pciconf compla= ined > about the new list. I've copy-pasted the discussion I brought this up to Warner/Brooks several months ago for review. The big problem is that the descriptions with the previous source and the new source clash, so this would cause a huge amount of diff churn; plus I think there are a few entries missing from each area (at least there were the last time I looked -- maybe our pci_vendors is more spartan than the new source is today). Thanks, -Garrett On Sun, Aug 01, 2010 at 11:10:26PM -0700, Garrett Cooper wrote: > On Sun, Aug 1, 2010 at 6:12 PM, M. Warner Losh wrote: > > In message: > > ? ? ? ? ? ?Garrett Cooper writes: > > : Hi Warner and Brooks, > > : ? ? I'm trying to add some debug code to uart(4) to detect a new PCI > > : ID and I noticed that some devices were reporting incorrect PCI > > : descriptions according to the probe output. Ultimately, it turns out > > : our copy of pci_vendors doesn't have the device (X-Fi audio card), so > > : it can't find the reference, and it fails to iterate through the > > : entire bus :(... > > : ? ? I was looking at http://pciids.sourceforge.net/v2.2/pci.ids > > : though, and it has this PCI ID (and a lot more PCI IDs). If I write a > > : conversion tool for this format, would the project be interested in > > : using it in place of the mk_pci_vendors.pl script? > > > > How does this compare with just updating the list that we currently > > pull from? > > Ran a quick test with a current PCI ID tables: > > $ fetch -o vendors.txt 'http://www.pcidatabase.com/reports.php?type=3Dcsv= ' > fetch: http://www.pcidatabase.com/reports.php?type=3Dcsv: size of remote > file is not known > vendors.txt 495 kB 77 kBps > $ fetch http://members.datafast.net.au/dft0802/downloads/pcidevs.txt > pcidevs.txt 100% of 840 kB 124 kBps > $ perl /usr/src/tools/tools/pciid/mk_pci_vendors.pl | awk '! /;/' | wc -l > 11218 > > Versus my script: > > $ fetch -o - http://pciids.sourceforge.net/v2.2/pci.ids | > ~/parse-pci-ids.py | wc -l > - 100% of 644 kB 54 kBps 0= 0m00s > 11317 > $ wc -l ~/pci-vendors-table > 11236 /usr/home/gcooper/pci-vendors-table > > There isn't as much difference as I thought (a lot of the pci.ids > table was subdevices, oddly enough). > Here's my script (not polished with the note stating that it's > autogenerated, etc). Yes, I know I could have written it in awk or > perl, but I just wanted to try and see what the difference was :)... > Thanks, > -Garrett > > #!/usr/bin/env python > > import re > import sys > > COMMENT_RE =3D re.compile('#.*') > HAS_SUBVENDOR =3D re.compile('^\t\t') > EMPTY_LINE_RE =3D re.compile('^\s*$') > > for line in sys.stdin.readlines(): > if not HAS_SUBVENDOR.search(line): > line =3D COMMENT_RE.sub('', line) > line =3D EMPTY_LINE_RE.sub('', line) > if line: > sys.stdout.write(line) > I can see adding this to the list of inputs as a backup to the other two. I can't really see throwing out the current entries and causing churn in descriptions. -- Brooks From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 4 14:39:25 2011 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE498106564A for ; Mon, 4 Apr 2011 14:39:25 +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 24C5C8FC0A for ; Mon, 4 Apr 2011 14:39:24 +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 RAA12861 for ; Mon, 04 Apr 2011 17:39:22 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4D99D81A.7000903@FreeBSD.org> Date: Mon, 04 Apr 2011 17:39:22 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: hackers@FreeBSD.org References: <20110404141016.GL71940@rincewind.paeps.cx> In-Reply-To: <20110404141016.GL71940@rincewind.paeps.cx> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: Updating PCI vendors database X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 14:39:25 -0000 on 04/04/2011 17:10 Philip Paeps said the following: > It looks like our /usr/share/misc/pci_vendors list (used only by pciconf as > far as I can tell) has become rather stale. We also appear to be tracking > sources which no longer exist. > > Would anyone object if I updated this list to source the same database used by > Linux distributions at http://pciids.sourceforge.net/v2.2/pci.ids? > > It helps that our pciconf looks to be compatible with that format. We just > ignore subvendor and subdevice, but it doesn't appear to matter that the file > contains this information. > > I could cull the subvendor/subdevice from the list though. > > Any views? > > Reason I'm looking into this is because one of my customers would like their > name to be correct when I import the driver I've been working on for them. :) This is just for your information: http://thread.gmane.org/gmane.os.freebsd.current/127979/focus=128577 Maybe you'll find something useful there. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 4 14:52:03 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E2CD1065674; Mon, 4 Apr 2011 14:52:03 +0000 (UTC) (envelope-from philip@paeps.cx) Received: from rincewind.paeps.cx (rincewind.paeps.cx [IPv6:2002:596a:f092::149]) by mx1.freebsd.org (Postfix) with ESMTP id 09BC08FC1B; Mon, 4 Apr 2011 14:52:03 +0000 (UTC) Received: by rincewind.paeps.cx (Postfix, from userid 1001) id 70AC2D7445C; Mon, 4 Apr 2011 16:51:59 +0200 (CEST) Date: Mon, 4 Apr 2011 16:51:59 +0200 From: Philip Paeps To: Garrett Cooper Message-ID: <20110404145159.GO71940@rincewind.paeps.cx> Mail-Followup-To: Garrett Cooper , hackers@freebsd.org References: <20110404141016.GL71940@rincewind.paeps.cx> <20110404141944.GN71940@rincewind.paeps.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-PGP-Fingerprint: 356B AE02 4763 F739 2FA2 E438 2649 E628 C5D3 4D05 X-Date: Prickle-Prickle, Discord 21, 3177 YOLD X-Phase-of-Moon: The Moon is Waxing Crescent (1% of Full) X-Philip-Conspiracy: There is no conspiracy Organization: Happily Disorganized User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hackers@freebsd.org Subject: Re: Updating PCI vendors database X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 14:52:03 -0000 On 2011-04-04 07:31:53 (-0700), Garrett Cooper wrote: > On Mon, Apr 4, 2011 at 7:19 AM, Philip Paeps wrote: > > On 2011-04-04 16:10:16 (+0200), Philip Paeps wrote: > >> Would anyone object if I updated this list to source the same database used > >> by Linux distributions at http://pciids.sourceforge.net/v2.2/pci.ids? > > > > It occurs to me that people would want to verify that this list does actually > > work and that we gain (rather than lose) coverage from it. > > > > A sanity test I've run on a couple of machines: > > > >  % fetch http://pciids.sourceforge.net/v2.2/pci.ids > >  % pciconf -lv > /tmp/pciconflv.old > >  % PCICONF_VENDOR_DATABASE=pci.ids pciconf -lv >/tmp/pciconflv.new > >  % diff -u /tmp/pciconflv.old /tmp/pciconflv.new > > > > In all cases I've seen so far, the new list yields better (more correct and up > > to date) results than the exising list.  In no cases has pciconf complained > > about the new list. > > I've copy-pasted the discussion I brought this up to Warner/Brooks > several months ago for review. I think at that point, the lists we're currently sourcing still existed. As of this morning, I don't seem to be able to find Craig Hart's list of PCI IDs anywhere on the net. It's certainly no long available at the address listed in the source tree. > The big problem is that the descriptions with the previous source and the > new source clash, so this would cause a huge amount of diff churn; This would be a problem I agree, but not a huge one. If the churn would be too large, I would be hesitant to push this to any stable branches. But I don't think the churn should be a problem for HEAD. It doesn't look to me like the churn is too large on the machines I've used it on. Generally, the changes I've seen is devices which lacked a device description now have one, and devices which had a wrong or incomplete description now have a complete and (as far as I can tell) correct one. This feels like an improvement to me. :) > plus I think there are a few entries missing from each area (at least there > were the last time I looked -- maybe our pci_vendors is more spartan than > the new source is today). The new list is much more complete than the list we have currently. For one thing, it also includes subvendors and subdevices, which the current list lacks. Our pciconf doesn't care about those currently, but could be made to care. I also don't think we should underestimate the value of sharing a list with Linux (especially if the licence on the list is friendly to sharing it) and potentially other operating system vendors. - Philip -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 4 14:57:50 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27CA3106568B for ; Mon, 4 Apr 2011 14:57:50 +0000 (UTC) (envelope-from philip@paeps.cx) Received: from rincewind.paeps.cx (rincewind.paeps.cx [IPv6:2002:596a:f092::149]) by mx1.freebsd.org (Postfix) with ESMTP id D963A8FC18 for ; Mon, 4 Apr 2011 14:57:48 +0000 (UTC) Received: by rincewind.paeps.cx (Postfix, from userid 1001) id 4B5A6D7445C; Mon, 4 Apr 2011 16:57:48 +0200 (CEST) Date: Mon, 4 Apr 2011 16:57:48 +0200 From: Philip Paeps To: freebsd-hackers@freebsd.org Message-ID: <20110404145748.GP71940@rincewind.paeps.cx> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20110404141016.GL71940@rincewind.paeps.cx> <4D99D81A.7000903@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4D99D81A.7000903@FreeBSD.org> X-PGP-Fingerprint: 356B AE02 4763 F739 2FA2 E438 2649 E628 C5D3 4D05 X-Date: Prickle-Prickle, Discord 21, 3177 YOLD X-Phase-of-Moon: The Moon is Waxing Crescent (1% of Full) X-Philip-Conspiracy: There is no conspiracy Organization: Happily Disorganized User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Updating PCI vendors database X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 14:57:50 -0000 On 2011-04-04 17:39:22 (+0300), Andriy Gapon wrote: > on 04/04/2011 17:10 Philip Paeps said the following: > > It looks like our /usr/share/misc/pci_vendors list (used only by pciconf as > > far as I can tell) has become rather stale. We also appear to be tracking > > sources which no longer exist. > > > > Would anyone object if I updated this list to source the same database used by > > Linux distributions at http://pciids.sourceforge.net/v2.2/pci.ids? > > > > It helps that our pciconf looks to be compatible with that format. We just > > ignore subvendor and subdevice, but it doesn't appear to matter that the file > > contains this information. > > > > I could cull the subvendor/subdevice from the list though. > > > > Any views? > > > > Reason I'm looking into this is because one of my customers would like their > > name to be correct when I import the driver I've been working on for them. :) > > This is just for your information: > http://thread.gmane.org/gmane.os.freebsd.current/127979/focus=128577 > Maybe you'll find something useful there. Thanks. I've just read through that discussion. It doesn't look like there were any "serious" objections to pulling in the new list, other than verifying that the new list contains all the entries the current list contains. I am not entirely sure what the little side-discussion about using # instead of ; as a comment marker is about. It looks to me like the pci.ids file "Just Works"[tm] with our pciconf(8). Maybe Garrett can elaborate on that? I think we should just go with the new list, but I'll hold off for a bit to let others object. ;) - Philip -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. You can't fix it if it ain't broke. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 4 15:51:04 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CD14106566C; Mon, 4 Apr 2011 15:51:04 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 65C058FC18; Mon, 4 Apr 2011 15:51:04 +0000 (UTC) Received: by pwj8 with SMTP id 8so1884701pwj.13 for ; Mon, 04 Apr 2011 08:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DNuPXR+8vMY0dLVco81ht9XVD9F/Qm02klG1yYFxKLU=; b=wkigHs21QDJQZA0Y4VqA7cQyfzWdfk7nfxKLQFEh92FJKXY1lpNnNL5lRhfGa3aui5 H5wncU+Sx0F15NEelign/LuOO0XVOzoWfXFQvIxM+jBYK5jYrVV73BOLS8IG2tpxplWz IuRRw1ucgvzMlFs+DII7L6ph0ooG+PPKIbuA4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qq3OnF7G5BtmTX6zvIpRScL31evWJExfa1fX+zTwM3O6h8r5jDXTU2pYPmCXLCJzkZ PIkl4WPN9TCpArtpTDaQLu2tcQMA39nzdaq1wyVnG2Vj/idiCrOid0nfA3MyjIzda8FB dvmuKzGxSVOVgJg/v13BONX5byVaOUlR8U6rs= MIME-Version: 1.0 Received: by 10.143.24.39 with SMTP id b39mr6376790wfj.341.1301932263829; Mon, 04 Apr 2011 08:51:03 -0700 (PDT) Received: by 10.68.42.3 with HTTP; Mon, 4 Apr 2011 08:51:03 -0700 (PDT) In-Reply-To: <20110404145748.GP71940@rincewind.paeps.cx> References: <20110404141016.GL71940@rincewind.paeps.cx> <4D99D81A.7000903@FreeBSD.org> <20110404145748.GP71940@rincewind.paeps.cx> Date: Mon, 4 Apr 2011 08:51:03 -0700 Message-ID: From: Garrett Cooper To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=001636e0b6211b70b204a019ba92 Cc: Philip Paeps Subject: Re: Updating PCI vendors database X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 15:51:04 -0000 --001636e0b6211b70b204a019ba92 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Apr 4, 2011 at 7:57 AM, Philip Paeps wrote: > On 2011-04-04 17:39:22 (+0300), Andriy Gapon wrote: >> on 04/04/2011 17:10 Philip Paeps said the following: >> > It looks like our /usr/share/misc/pci_vendors list (used only by pcico= nf as >> > far as I can tell) has become rather stale. =A0We also appear to be tr= acking >> > sources which no longer exist. >> > >> > Would anyone object if I updated this list to source the same database= used by >> > Linux distributions at http://pciids.sourceforge.net/v2.2/pci.ids? >> > >> > It helps that our pciconf looks to be compatible with that format. =A0= We just >> > ignore subvendor and subdevice, but it doesn't appear to matter that t= he file >> > contains this information. >> > >> > I could cull the subvendor/subdevice from the list though. >> > >> > Any views? >> > >> > Reason I'm looking into this is because one of my customers would like= their >> > name to be correct when I import the driver I've been working on for t= hem. :) >> >> This is just for your information: >> http://thread.gmane.org/gmane.os.freebsd.current/127979/focus=3D128577 >> Maybe you'll find something useful there. > > Thanks. =A0I've just read through that discussion. =A0It doesn't look lik= e there > were any "serious" objections to pulling in the new list, other than veri= fying > that the new list contains all the entries the current list contains. > > I am not entirely sure what the little side-discussion about using # inst= ead > of ; as a comment marker is about. =A0It looks to me like the pci.ids fil= e "Just > Works"[tm] with our pciconf(8). =A0Maybe Garrett can elaborate on that? Well, close. You can substitute the hashes with semicolons, but you need to get rid of subvendor / subdevice. The format is: vendor-id\040\040vendor-description \011device-id\040\040device-description \011\011subvendor-id\040subdevice-id\040\040subsystem-name (it's also documented in the top of the file, but just to be pedantic I noted it here) pciconf already supports hash based comments: /* * Scan input lines from the database */ for (;;) { if (fgets(buf, sizeof(buf), db) =3D=3D NULL) break; if ((ch =3D strchr(buf, '#')) !=3D NULL) *ch =3D '\0'; so no work needs to be done there. Setting PCICONF_VENDOR_DATABASE to pci.ids worked, but all the items on my box are different in the new file (all device descriptions, but also some of the vendor descriptions dealing with my nVidia card, Realtek NIC, and LSI card) [it would be interesting to see who's correct in terms of corporation branding :)..]. So this definitely isn't MFC-able :). > I think we should just go with the new list, but I'll hold off for a bit = to > let others object. ;) +1, just for the fact that our sources are becoming stale. I wonder though what other OSes like NetBSD/OpenBSD/[Open]Solaris/IlluminOS use however for tracking PCI IDs, as the sources for pci.ids aren't necessarily the vendor itself and in some cases are end-users. I thought some of our other sources were based on data provided by vendors. Thanks, -Garrett --001636e0b6211b70b204a019ba92 Content-Type: application/octet-stream; name="pci-vendors.output" Content-Disposition: attachment; filename="pci-vendors.output" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gm3kqkxh0 aG9zdGIwQHBjaTA6MDowOjA6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHg4MzZiMTA0MyBjaGlwPTB4 MzQwNTgwODYgcmV2PTB4MTMgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9y YXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1F1aWNrUGF0aCBBcmNoaXRlY3R1cmUgSS9PIEh1YiB0 byBFU0kgUG9ydCcKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBIT1NU LVBDSQpwY2liMUBwY2kwOjA6MTowOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4ODM2YjEwNDMgY2hp cD0weDM0MDg4MDg2IHJldj0weDEzIGhkcj0weDAxCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENv cnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdRdWlja1BhdGggQXJjaGl0ZWN0dXJlIEkvTyBI dWIgUENJIEV4cHJlc3MgUm9vdCBQb3J0IDEnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBz dWJjbGFzcyAgID0gUENJLVBDSQpwY2liNEBwY2kwOjA6MzowOgljbGFzcz0weDA2MDQwMCBjYXJk PTB4ODM2YjEwNDMgY2hpcD0weDM0MGE4MDg2IHJldj0weDEzIGhkcj0weDAxCiAgICB2ZW5kb3Ig ICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdRdWlja1BhdGggQXJj aGl0ZWN0dXJlIEkvTyBIdWIgUENJIEV4cHJlc3MgUm9vdCBQb3J0IDMnCiAgICBjbGFzcyAgICAg ID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQpwY2liNUBwY2kwOjA6NzowOgljbGFz cz0weDA2MDQwMCBjYXJkPTB4ODM2YjEwNDMgY2hpcD0weDM0MGU4MDg2IHJldj0weDEzIGhkcj0w eDAxCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9 ICdRdWlja1BhdGggQXJjaGl0ZWN0dXJlIEkvTyBIdWIgUENJIEV4cHJlc3MgUm9vdCBQb3J0IDcn CiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQpub25lMEBw Y2kwOjA6MjA6MDoJY2xhc3M9MHgwODAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgzNDJlODA4 NiByZXY9MHgxMyBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicK ICAgIGRldmljZSAgICAgPSAnUXVpY2tQYXRoIEFyY2hpdGVjdHVyZSBJL08gSHViIFN5c3RlbSBN YW5hZ2VtZW50IFJlZ2lzdGVycycKICAgIGNsYXNzICAgICAgPSBiYXNlIHBlcmlwaGVyYWwKICAg IHN1YmNsYXNzICAgPSBpbnRlcnJ1cHQgY29udHJvbGxlcgpub25lMUBwY2kwOjA6MjA6MToJY2xh c3M9MHgwODAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgzNDIyODA4NiByZXY9MHgxMyBoZHI9 MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAg PSAnUXVpY2tQYXRoIEFyY2hpdGVjdHVyZSBJL08gSHViIEdQSU8gYW5kIFNjcmF0Y2ggUGFkIFJl Z2lzdGVycycKICAgIGNsYXNzICAgICAgPSBiYXNlIHBlcmlwaGVyYWwKICAgIHN1YmNsYXNzICAg PSBpbnRlcnJ1cHQgY29udHJvbGxlcgpub25lMkBwY2kwOjA6MjA6MjoJY2xhc3M9MHgwODAwMDAg Y2FyZD0weDAwMDAwMDAwIGNoaXA9MHgzNDIzODA4NiByZXY9MHgxMyBoZHI9MHgwMAogICAgdmVu ZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnUXVpY2tQYXRo IEFyY2hpdGVjdHVyZSBJL08gSHViIENvbnRyb2wgU3RhdHVzIGFuZCBSQVMgUmVnaXN0ZXJzJwog ICAgY2xhc3MgICAgICA9IGJhc2UgcGVyaXBoZXJhbAogICAgc3ViY2xhc3MgICA9IGludGVycnVw dCBjb250cm9sbGVyCm5vbmUzQHBjaTA6MDoyMDozOgljbGFzcz0weDA4MDAwMCBjYXJkPTB4MDAw MDAwMDAgY2hpcD0weDM0Mzg4MDg2IHJldj0weDEzIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0g J0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdRdWlja1BhdGggQXJjaGl0ZWN0 dXJlIEkvTyBIdWIgVGhyb3R0bGUgUmVnaXN0ZXJzJwogICAgY2xhc3MgICAgICA9IGJhc2UgcGVy aXBoZXJhbAogICAgc3ViY2xhc3MgICA9IGludGVycnVwdCBjb250cm9sbGVyCnVoY2kwQHBjaTA6 MDoyNjowOgljbGFzcz0weDBjMDMwMCBjYXJkPTB4ODJkNDEwNDMgY2hpcD0weDNhMzc4MDg2IHJl dj0weDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAg ZGV2aWNlICAgICA9ICdVU0IgVUhDSSBDb250cm9sbGVyICo0JwogICAgY2xhc3MgICAgICA9IHNl cmlhbCBidXMKICAgIHN1YmNsYXNzICAgPSBVU0IKdWhjaTFAcGNpMDowOjI2OjE6CWNsYXNzPTB4 MGMwMzAwIGNhcmQ9MHg4MmQ0MTA0MyBjaGlwPTB4M2EzODgwODYgcmV2PTB4MDAgaGRyPTB4MDAK ICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1VT QiBVSENJIENvbnRyb2xsZXIgKjUnCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cwogICAgc3Vi Y2xhc3MgICA9IFVTQgp1aGNpMkBwY2kwOjA6MjY6MjoJY2xhc3M9MHgwYzAzMDAgY2FyZD0weDgy ZDQxMDQzIGNoaXA9MHgzYTM5ODA4NiByZXY9MHgwMCBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9 ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVVNCIFVIQ0kgQ29udHJvbGxl ciAqNicKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCmVo Y2kwQHBjaTA6MDoyNjo3OgljbGFzcz0weDBjMDMyMCBjYXJkPTB4ODJkNDEwNDMgY2hpcD0weDNh M2M4MDg2IHJldj0weDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0 aW9uJwogICAgZGV2aWNlICAgICA9ICdVU0IgRUhDSSBDb250cm9sbGVyICoyJwogICAgY2xhc3Mg ICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzICAgPSBVU0IKcGNpYjZAcGNpMDowOjI4OjA6 CWNsYXNzPTB4MDYwNDAwIGNhcmQ9MHg4MmVhMTA0MyBjaGlwPTB4M2E0MDgwODYgcmV2PTB4MDAg aGRyPTB4MDEKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2Ug ICAgID0gJ1BDSSBFeHByZXNzIFBvcnQgMScKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1 YmNsYXNzICAgPSBQQ0ktUENJCnBjaWI3QHBjaTA6MDoyODoxOgljbGFzcz0weDA2MDQwMCBjYXJk PTB4ODJlYTEwNDMgY2hpcD0weDNhNDI4MDg2IHJldj0weDAwIGhkcj0weDAxCiAgICB2ZW5kb3Ig ICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdQQ0kgRXhwcmVzcyBQ b3J0IDInCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQp1 aGNpM0BwY2kwOjA6Mjk6MDoJY2xhc3M9MHgwYzAzMDAgY2FyZD0weDgyZDQxMDQzIGNoaXA9MHgz YTM0ODA4NiByZXY9MHgwMCBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3Jh dGlvbicKICAgIGRldmljZSAgICAgPSAnVVNCIFVIQ0kgQ29udHJvbGxlciAqMScKICAgIGNsYXNz ICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCnVoY2k0QHBjaTA6MDoyOTox OgljbGFzcz0weDBjMDMwMCBjYXJkPTB4ODJkNDEwNDMgY2hpcD0weDNhMzU4MDg2IHJldj0weDAw IGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNl ICAgICA9ICdVU0IgVUhDSSBDb250cm9sbGVyICoyJwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBi dXMKICAgIHN1YmNsYXNzICAgPSBVU0IKdWhjaTVAcGNpMDowOjI5OjI6CWNsYXNzPTB4MGMwMzAw IGNhcmQ9MHg4MmQ0MTA0MyBjaGlwPTB4M2EzNjgwODYgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZl bmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1VTQiBVSENJ IENvbnRyb2xsZXIgKjMnCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cwogICAgc3ViY2xhc3Mg ICA9IFVTQgplaGNpMUBwY2kwOjA6Mjk6NzoJY2xhc3M9MHgwYzAzMjAgY2FyZD0weDgyZDQxMDQz IGNoaXA9MHgzYTNhODA4NiByZXY9MHgwMCBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRl bCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVVNCIEVIQ0kgQ29udHJvbGxlciAqMScK ICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCnBjaWI4QHBj aTA6MDozMDowOgljbGFzcz0weDA2MDQwMSBjYXJkPTB4ODJkNDEwNDMgY2hpcD0weDI0NGU4MDg2 IHJldj0weDkwIGhkcj0weDAxCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwog ICAgZGV2aWNlICAgICA9ICc4MjgwMSBGYW1pbHkgKElDSDIvMy80LzUvNi83LzgvOSw2M3h4RVNC KSBIdWIgSW50ZXJmYWNlIHRvIFBDSSBCcmlkZ2UnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAg ICBzdWJjbGFzcyAgID0gUENJLVBDSQppc2FiMEBwY2kwOjA6MzE6MDoJY2xhc3M9MHgwNjAxMDAg Y2FyZD0weDgyZDQxMDQzIGNoaXA9MHgzYTE2ODA4NiByZXY9MHgwMCBoZHI9MHgwMAogICAgdmVu ZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnTFBDIEludGVy ZmFjZSBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9 IFBDSS1JU0EKYWhjaTBAcGNpMDowOjMxOjI6CWNsYXNzPTB4MDEwNjAxIGNhcmQ9MHg4MmQ0MTA0 MyBjaGlwPTB4M2EyMjgwODYgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnSW50 ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJzYgcG9ydCBTQVRBIEFIQ0kgQ29udHJv bGxlcicKICAgIGNsYXNzICAgICAgPSBtYXNzIHN0b3JhZ2UKICAgIHN1YmNsYXNzICAgPSBTQVRB CmljaHNtYjBAcGNpMDowOjMxOjM6CWNsYXNzPTB4MGMwNTAwIGNhcmQ9MHg4MmQ0MTA0MyBjaGlw PTB4M2EzMDgwODYgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29y cG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1NNQiBjb250cm9sbGVyICAoNTAwMTE0NTgpJwog ICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzICAgPSBTTUJ1cwpwY2liMkBw Y2kwOjE6MDowOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDAxMjUxMDMz IHJldj0weDA2IGhkcj0weDAxCiAgICB2ZW5kb3IgICAgID0gJ05FQyBFbGVjdHJvbmljcyBIb25n IEtvbmcnCiAgICBkZXZpY2UgICAgID0gJ3VQRDcyMDQwMCBQQ0kgRXhwcmVzcyAtIFBDSS9QQ0kt WCBCcmlkZ2UnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gUENJLVBD SQpwY2liM0BwY2kwOjE6MDoxOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0w eDAxMjUxMDMzIHJldj0weDA2IGhkcj0weDAxCiAgICB2ZW5kb3IgICAgID0gJ05FQyBFbGVjdHJv bmljcyBIb25nIEtvbmcnCiAgICBkZXZpY2UgICAgID0gJ3VQRDcyMDQwMCBQQ0kgRXhwcmVzcyAt IFBDSS9QQ0ktWCBCcmlkZ2UnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAg ID0gUENJLVBDSQp2Z2FwY2kwQHBjaTA6NDowOjA6CWNsYXNzPTB4MDMwMDAwIGNhcmQ9MHhjOTU0 Mzg0MiBjaGlwPTB4MDY0MDEwZGUgcmV2PTB4YTEgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAn TlZJRElBIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdOVklESUEgR2VGb3JjZSA5NTAw IEdUIChHOTYpJwogICAgY2xhc3MgICAgICA9IGRpc3BsYXkKICAgIHN1YmNsYXNzICAgPSBWR0EK bWZpMEBwY2kwOjU6MDowOgljbGFzcz0weDAxMDQwMCBjYXJkPTB4MTAxMjEwMDAgY2hpcD0weDAw NjAxMDAwIHJldj0weDA0IGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0xTSSBMb2dpYyAoV2Fz OiBTeW1iaW9zIExvZ2ljLCBOQ1IpJwogICAgZGV2aWNlICAgICA9ICdTQVMxMDc4IFBDSS1YIEZ1 c2lvbi1NUFQgU0FTJwogICAgY2xhc3MgICAgICA9IG1hc3Mgc3RvcmFnZQogICAgc3ViY2xhc3Mg ICA9IFJBSUQKcmUwQHBjaTA6NjowOjA6CWNsYXNzPTB4MDIwMDAwIGNhcmQ9MHg4MzY3MTA0MyBj aGlwPTB4ODE2ODEwZWMgcmV2PTB4MDIgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnUmVhbHRl ayBTZW1pY29uZHVjdG9yJwogICAgZGV2aWNlICAgICA9ICdHaWdhYml0IEV0aGVybmV0IE5JQyhO RElTIDYuMCkgKFJUTDgxNjgvODExMS84MTExYyknCiAgICBjbGFzcyAgICAgID0gbmV0d29yawog ICAgc3ViY2xhc3MgICA9IGV0aGVybmV0CmVtdTEwa3gwQHBjaTA6ODowOjA6CWNsYXNzPTB4MDQw MTAwIGNhcmQ9MHgxMDIxMTEwMiBjaGlwPTB4MDAwODExMDIgcmV2PTB4MDAgaGRyPTB4MDAKICAg IHZlbmRvciAgICAgPSAnQ3JlYXRpdmUgVGVjaG5vbG9neSBMVEQuJwogICAgZGV2aWNlICAgICA9 ICdzb3VuZCBibGFzdGVyIEF1ZGlneSAyIChjYTAxMDgpJwogICAgY2xhc3MgICAgICA9IG11bHRp bWVkaWEKICAgIHN1YmNsYXNzICAgPSBhdWRpbwpmd29oY2kwQHBjaTA6ODo0OjA6CWNsYXNzPTB4 MGMwMDEwIGNhcmQ9MHg4MjU5MTA0MyBjaGlwPTB4NTgxMTExYzEgcmV2PTB4NzAgaGRyPTB4MDAK ICAgIHZlbmRvciAgICAgPSAnTHVjZW50L0FnZXJlIFN5c3RlbXMgKFdhczogQVQmVCBNaWNyb0Vs ZWN0cm9uaWNzKScKICAgIGRldmljZSAgICAgPSAnMTM5NEEgUENJIFBIWS9MaW5rIE9wZW4gSG9z dCBDdHJsciBJL0YgKEZXMzIyKScKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJj bGFzcyAgID0gRmlyZVdpcmUKaG9zdGIxQHBjaTA6MjU1OjA6MDoJY2xhc3M9MHgwNjAwMDAgY2Fy ZD0weDgwODY4MDg2IGNoaXA9MHgyYzQxODA4NiByZXY9MHgwNSBoZHI9MHgwMAogICAgdmVuZG9y ICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1 YmNsYXNzICAgPSBIT1NULVBDSQpob3N0YjJAcGNpMDoyNTU6MDoxOgljbGFzcz0weDA2MDAwMCBj YXJkPTB4ODA4NjgwODYgY2hpcD0weDJjMDE4MDg2IHJldj0weDA1IGhkcj0weDAwCiAgICB2ZW5k b3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdRdWlja1BhdGgg QXJjaGl0ZWN0dXJlIFN5c3RlbSBBZGRyZXNzIERlY29kZXInCiAgICBjbGFzcyAgICAgID0gYnJp ZGdlCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kKaG9zdGIzQHBjaTA6MjU1OjI6MDoJY2xhc3M9 MHgwNjAwMDAgY2FyZD0weDgwODY4MDg2IGNoaXA9MHgyYzEwODA4NiByZXY9MHgwNSBoZHI9MHgw MAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAn UXVpY2tQYXRoIEludGVyY29ubmVjdCBMaW5rIDAnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAg ICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kKaG9zdGI0QHBjaTA6MjU1OjI6MToJY2xhc3M9MHgwNjAw MDAgY2FyZD0weDgwODY4MDg2IGNoaXA9MHgyYzExODA4NiByZXY9MHgwNSBoZHI9MHgwMAogICAg dmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnUXVpY2tQ YXRoIEludGVyY29ubmVjdCBQaHlzaWNhbCAwJwogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAg c3ViY2xhc3MgICA9IEhPU1QtUENJCmhvc3RiNUBwY2kwOjI1NTozOjA6CWNsYXNzPTB4MDYwMDAw IGNhcmQ9MHg4MDg2ODA4NiBjaGlwPTB4MmMxODgwODYgcmV2PTB4MDUgaGRyPTB4MDAKICAgIHZl bmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1F1aWNrUGF0 aCBNZW1vcnkgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNz ICAgPSBIT1NULVBDSQpob3N0YjZAcGNpMDoyNTU6MzoxOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4 ODA4NjgwODYgY2hpcD0weDJjMTk4MDg2IHJldj0weDA1IGhkcj0weDAwCiAgICB2ZW5kb3IgICAg ID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdRdWlja1BhdGggTWVtb3J5 IENvbnRyb2xsZXIgVGFyZ2V0IEFkZHJlc3MgRGVjb2RlcicKICAgIGNsYXNzICAgICAgPSBicmlk Z2UKICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQpob3N0YjdAcGNpMDoyNTU6Mzo0OgljbGFzcz0w eDA2MDAwMCBjYXJkPTB4ODA4NjgwODYgY2hpcD0weDJjMWM4MDg2IHJldj0weDA1IGhkcj0weDAw CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdR dWlja1BhdGggTWVtb3J5IENvbnRyb2xsZXIgVGVzdCBSZWdpc3RlcnMnCiAgICBjbGFzcyAgICAg ID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kKaG9zdGI4QHBjaTA6MjU1OjQ6MDoJ Y2xhc3M9MHgwNjAwMDAgY2FyZD0weDgwODY4MDg2IGNoaXA9MHgyYzIwODA4NiByZXY9MHgwNSBo ZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAg ICAgPSAnUXVpY2tQYXRoIE1lbW9yeSBDb250cm9sbGVyIENoYW5uZWwgMCBDb250cm9sIFJlZ2lz dGVycycKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQpo b3N0YjlAcGNpMDoyNTU6NDoxOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4ODA4NjgwODYgY2hpcD0w eDJjMjE4MDg2IHJldj0weDA1IGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBv cmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdRdWlja1BhdGggTWVtb3J5IENvbnRyb2xsZXIgQ2hh bm5lbCAwIEFkZHJlc3MgUmVnaXN0ZXJzJwogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAgc3Vi Y2xhc3MgICA9IEhPU1QtUENJCmhvc3RiMTBAcGNpMDoyNTU6NDoyOgljbGFzcz0weDA2MDAwMCBj YXJkPTB4ODA4NjgwODYgY2hpcD0weDJjMjI4MDg2IHJldj0weDA1IGhkcj0weDAwCiAgICB2ZW5k b3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdRdWlja1BhdGgg TWVtb3J5IENvbnRyb2xsZXIgQ2hhbm5lbCAwIFJhbmsgUmVnaXN0ZXJzJwogICAgY2xhc3MgICAg ICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJCmhvc3RiMTFAcGNpMDoyNTU6NDoz OgljbGFzcz0weDA2MDAwMCBjYXJkPTB4ODA4NjgwODYgY2hpcD0weDJjMjM4MDg2IHJldj0weDA1 IGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNl ICAgICA9ICdRdWlja1BhdGggTWVtb3J5IENvbnRyb2xsZXIgQ2hhbm5lbCAwIFRoZXJtYWwgQ29u dHJvbCBSZWdpc3RlcnMnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0g SE9TVC1QQ0kKaG9zdGIxMkBwY2kwOjI1NTo1OjA6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHg4MDg2 ODA4NiBjaGlwPTB4MmMyODgwODYgcmV2PTB4MDUgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAn SW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1F1aWNrUGF0aCBNZW1vcnkgQ29u dHJvbGxlciBDaGFubmVsIDEgQ29udHJvbCBSZWdpc3RlcnMnCiAgICBjbGFzcyAgICAgID0gYnJp ZGdlCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kKaG9zdGIxM0BwY2kwOjI1NTo1OjE6CWNsYXNz PTB4MDYwMDAwIGNhcmQ9MHg4MDg2ODA4NiBjaGlwPTB4MmMyOTgwODYgcmV2PTB4MDUgaGRyPTB4 MDAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0g J1F1aWNrUGF0aCBNZW1vcnkgQ29udHJvbGxlciBDaGFubmVsIDEgQWRkcmVzcyBSZWdpc3RlcnMn CiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kKaG9zdGIx NEBwY2kwOjI1NTo1OjI6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHg4MDg2ODA4NiBjaGlwPTB4MmMy YTgwODYgcmV2PTB4MDUgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRp b24nCiAgICBkZXZpY2UgICAgID0gJ1F1aWNrUGF0aCBNZW1vcnkgQ29udHJvbGxlciBDaGFubmVs IDEgUmFuayBSZWdpc3RlcnMnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAg ID0gSE9TVC1QQ0kKaG9zdGIxNUBwY2kwOjI1NTo1OjM6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHg4 MDg2ODA4NiBjaGlwPTB4MmMyYjgwODYgcmV2PTB4MDUgaGRyPTB4MDAKICAgIHZlbmRvciAgICAg PSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1F1aWNrUGF0aCBNZW1vcnkg Q29udHJvbGxlciBDaGFubmVsIDEgVGhlcm1hbCBDb250cm9sIFJlZ2lzdGVycycKICAgIGNsYXNz ICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQpob3N0YjE2QHBjaTA6MjU1 OjY6MDoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDgwODY4MDg2IGNoaXA9MHgyYzMwODA4NiByZXY9 MHgwNSBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRl dmljZSAgICAgPSAnUXVpY2tQYXRoIE1lbW9yeSBDb250cm9sbGVyIENoYW5uZWwgMiBDb250cm9s IFJlZ2lzdGVycycKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBIT1NU LVBDSQpob3N0YjE3QHBjaTA6MjU1OjY6MToJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDgwODY4MDg2 IGNoaXA9MHgyYzMxODA4NiByZXY9MHgwNSBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRl bCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnUXVpY2tQYXRoIE1lbW9yeSBDb250cm9s bGVyIENoYW5uZWwgMiBBZGRyZXNzIFJlZ2lzdGVycycKICAgIGNsYXNzICAgICAgPSBicmlkZ2UK ICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQpob3N0YjE4QHBjaTA6MjU1OjY6MjoJY2xhc3M9MHgw NjAwMDAgY2FyZD0weDgwODY4MDg2IGNoaXA9MHgyYzMyODA4NiByZXY9MHgwNSBoZHI9MHgwMAog ICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnUXVp Y2tQYXRoIE1lbW9yeSBDb250cm9sbGVyIENoYW5uZWwgMiBSYW5rIFJlZ2lzdGVycycKICAgIGNs YXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQpob3N0YjE5QHBjaTA6 MjU1OjY6MzoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDgwODY4MDg2IGNoaXA9MHgyYzMzODA4NiBy ZXY9MHgwNSBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAg IGRldmljZSAgICAgPSAnUXVpY2tQYXRoIE1lbW9yeSBDb250cm9sbGVyIENoYW5uZWwgMiBUaGVy bWFsIENvbnRyb2wgUmVnaXN0ZXJzJwogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xh c3MgICA9IEhPU1QtUENJCg== --001636e0b6211b70b204a019ba92 Content-Type: application/octet-stream; name="pci-ids.output" Content-Disposition: attachment; filename="pci-ids.output" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gm3kqrrp1 aG9zdGIwQHBjaTA6MDowOjA6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHg4MzZiMTA0MyBjaGlwPTB4 MzQwNTgwODYgcmV2PTB4MTMgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9y YXRpb24nCiAgICBkZXZpY2UgICAgID0gJzU1MjAvNTUwMC9YNTggSS9PIEh1YiB0byBFU0kgUG9y dCcKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQpwY2li MUBwY2kwOjA6MTowOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4ODM2YjEwNDMgY2hpcD0weDM0MDg4 MDg2IHJldj0weDEzIGhkcj0weDAxCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9u JwogICAgZGV2aWNlICAgICA9ICc1NTIwLzU1MDAvWDU4IEkvTyBIdWIgUENJIEV4cHJlc3MgUm9v dCBQb3J0IDEnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gUENJLVBD SQpwY2liNEBwY2kwOjA6MzowOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4ODM2YjEwNDMgY2hpcD0w eDM0MGE4MDg2IHJldj0weDEzIGhkcj0weDAxCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBv cmF0aW9uJwogICAgZGV2aWNlICAgICA9ICc1NTIwLzU1MDAvWDU4IEkvTyBIdWIgUENJIEV4cHJl c3MgUm9vdCBQb3J0IDMnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0g UENJLVBDSQpwY2liNUBwY2kwOjA6NzowOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4ODM2YjEwNDMg Y2hpcD0weDM0MGU4MDg2IHJldj0weDEzIGhkcj0weDAxCiAgICB2ZW5kb3IgICAgID0gJ0ludGVs IENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICc1NTIwLzU1MDAvWDU4IEkvTyBIdWIgUENJ IEV4cHJlc3MgUm9vdCBQb3J0IDcnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFz cyAgID0gUENJLVBDSQpub25lMEBwY2kwOjA6MjA6MDoJY2xhc3M9MHgwODAwMDAgY2FyZD0weDAw MDAwMDAwIGNoaXA9MHgzNDJlODA4NiByZXY9MHgxMyBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9 ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnNTUyMC81NTAwL1g1OCBJL08g SHViIFN5c3RlbSBNYW5hZ2VtZW50IFJlZ2lzdGVycycKICAgIGNsYXNzICAgICAgPSBiYXNlIHBl cmlwaGVyYWwKICAgIHN1YmNsYXNzICAgPSBpbnRlcnJ1cHQgY29udHJvbGxlcgpub25lMUBwY2kw OjA6MjA6MToJY2xhc3M9MHgwODAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgzNDIyODA4NiBy ZXY9MHgxMyBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAg IGRldmljZSAgICAgPSAnNTUyMC81NTAwL1g1OCBJL08gSHViIEdQSU8gYW5kIFNjcmF0Y2ggUGFk IFJlZ2lzdGVycycKICAgIGNsYXNzICAgICAgPSBiYXNlIHBlcmlwaGVyYWwKICAgIHN1YmNsYXNz ICAgPSBpbnRlcnJ1cHQgY29udHJvbGxlcgpub25lMkBwY2kwOjA6MjA6MjoJY2xhc3M9MHgwODAw MDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgzNDIzODA4NiByZXY9MHgxMyBoZHI9MHgwMAogICAg dmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnNTUyMC81 NTAwL1g1OCBJL08gSHViIENvbnRyb2wgU3RhdHVzIGFuZCBSQVMgUmVnaXN0ZXJzJwogICAgY2xh c3MgICAgICA9IGJhc2UgcGVyaXBoZXJhbAogICAgc3ViY2xhc3MgICA9IGludGVycnVwdCBjb250 cm9sbGVyCm5vbmUzQHBjaTA6MDoyMDozOgljbGFzcz0weDA4MDAwMCBjYXJkPTB4MDAwMDAwMDAg Y2hpcD0weDM0Mzg4MDg2IHJldj0weDEzIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVs IENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICc1NTIwLzU1MDAvWDU4IEkvTyBIdWIgVGhy b3R0bGUgUmVnaXN0ZXJzJwogICAgY2xhc3MgICAgICA9IGJhc2UgcGVyaXBoZXJhbAogICAgc3Vi Y2xhc3MgICA9IGludGVycnVwdCBjb250cm9sbGVyCnVoY2kwQHBjaTA6MDoyNjowOgljbGFzcz0w eDBjMDMwMCBjYXJkPTB4ODJkNDEwNDMgY2hpcD0weDNhMzc4MDg2IHJldj0weDAwIGhkcj0weDAw CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICc4 MjgwMUpJIChJQ0gxMCBGYW1pbHkpIFVTQiBVSENJIENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAg ID0gc2VyaWFsIGJ1cwogICAgc3ViY2xhc3MgICA9IFVTQgp1aGNpMUBwY2kwOjA6MjY6MToJY2xh c3M9MHgwYzAzMDAgY2FyZD0weDgyZDQxMDQzIGNoaXA9MHgzYTM4ODA4NiByZXY9MHgwMCBoZHI9 MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAg PSAnODI4MDFKSSAoSUNIMTAgRmFtaWx5KSBVU0IgVUhDSSBDb250cm9sbGVyJwogICAgY2xhc3Mg ICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzICAgPSBVU0IKdWhjaTJAcGNpMDowOjI2OjI6 CWNsYXNzPTB4MGMwMzAwIGNhcmQ9MHg4MmQ0MTA0MyBjaGlwPTB4M2EzOTgwODYgcmV2PTB4MDAg aGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2Ug ICAgID0gJzgyODAxSkkgKElDSDEwIEZhbWlseSkgVVNCIFVIQ0kgQ29udHJvbGxlcicKICAgIGNs YXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCmVoY2kwQHBjaTA6MDoy Njo3OgljbGFzcz0weDBjMDMyMCBjYXJkPTB4ODJkNDEwNDMgY2hpcD0weDNhM2M4MDg2IHJldj0w eDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2 aWNlICAgICA9ICc4MjgwMUpJIChJQ0gxMCBGYW1pbHkpIFVTQjIgRUhDSSBDb250cm9sbGVyJwog ICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzICAgPSBVU0IKcGNpYjZAcGNp MDowOjI4OjA6CWNsYXNzPTB4MDYwNDAwIGNhcmQ9MHg4MmVhMTA0MyBjaGlwPTB4M2E0MDgwODYg cmV2PTB4MDAgaGRyPTB4MDEKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAg ICBkZXZpY2UgICAgID0gJzgyODAxSkkgKElDSDEwIEZhbWlseSkgUENJIEV4cHJlc3MgUm9vdCBQ b3J0IDEnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQpw Y2liN0BwY2kwOjA6Mjg6MToJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDgyZWExMDQzIGNoaXA9MHgz YTQyODA4NiByZXY9MHgwMCBoZHI9MHgwMQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3Jh dGlvbicKICAgIGRldmljZSAgICAgPSAnODI4MDFKSSAoSUNIMTAgRmFtaWx5KSBQQ0kgRXhwcmVz cyBQb3J0IDInCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gUENJLVBD SQp1aGNpM0BwY2kwOjA6Mjk6MDoJY2xhc3M9MHgwYzAzMDAgY2FyZD0weDgyZDQxMDQzIGNoaXA9 MHgzYTM0ODA4NiByZXY9MHgwMCBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jw b3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnODI4MDFKSSAoSUNIMTAgRmFtaWx5KSBVU0IgVUhD SSBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzICAg PSBVU0IKdWhjaTRAcGNpMDowOjI5OjE6CWNsYXNzPTB4MGMwMzAwIGNhcmQ9MHg4MmQ0MTA0MyBj aGlwPTB4M2EzNTgwODYgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwg Q29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJzgyODAxSkkgKElDSDEwIEZhbWlseSkgVVNC IFVIQ0kgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFz cyAgID0gVVNCCnVoY2k1QHBjaTA6MDoyOToyOgljbGFzcz0weDBjMDMwMCBjYXJkPTB4ODJkNDEw NDMgY2hpcD0weDNhMzY4MDg2IHJldj0weDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0lu dGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICc4MjgwMUpJIChJQ0gxMCBGYW1pbHkp IFVTQiBVSENJIENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cwogICAgc3Vi Y2xhc3MgICA9IFVTQgplaGNpMUBwY2kwOjA6Mjk6NzoJY2xhc3M9MHgwYzAzMjAgY2FyZD0weDgy ZDQxMDQzIGNoaXA9MHgzYTNhODA4NiByZXY9MHgwMCBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9 ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnODI4MDFKSSAoSUNIMTAgRmFt aWx5KSBVU0IyIEVIQ0kgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAg ICBzdWJjbGFzcyAgID0gVVNCCnBjaWI4QHBjaTA6MDozMDowOgljbGFzcz0weDA2MDQwMSBjYXJk PTB4ODJkNDEwNDMgY2hpcD0weDI0NGU4MDg2IHJldj0weDkwIGhkcj0weDAxCiAgICB2ZW5kb3Ig ICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICc4MjgwMSBQQ0kgQnJp ZGdlJwogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kKaXNh YjBAcGNpMDowOjMxOjA6CWNsYXNzPTB4MDYwMTAwIGNhcmQ9MHg4MmQ0MTA0MyBjaGlwPTB4M2Ex NjgwODYgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRp b24nCiAgICBkZXZpY2UgICAgID0gJzgyODAxSklSIChJQ0gxMFIpIExQQyBJbnRlcmZhY2UgQ29u dHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktSVNB CmFoY2kwQHBjaTA6MDozMToyOgljbGFzcz0weDAxMDYwMSBjYXJkPTB4ODJkNDEwNDMgY2hpcD0w eDNhMjI4MDg2IHJldj0weDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBv cmF0aW9uJwogICAgZGV2aWNlICAgICA9ICc4MjgwMUpJIChJQ0gxMCBGYW1pbHkpIFNBVEEgQUhD SSBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IG1hc3Mgc3RvcmFnZQogICAgc3ViY2xhc3Mg ICA9IFNBVEEKaWNoc21iMEBwY2kwOjA6MzE6MzoJY2xhc3M9MHgwYzA1MDAgY2FyZD0weDgyZDQx MDQzIGNoaXA9MHgzYTMwODA4NiByZXY9MHgwMCBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJ bnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnODI4MDFKSSAoSUNIMTAgRmFtaWx5 KSBTTUJ1cyBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNs YXNzICAgPSBTTUJ1cwpwY2liMkBwY2kwOjE6MDowOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4MDAw MDAwMDAgY2hpcD0weDAxMjUxMDMzIHJldj0weDA2IGhkcj0weDAxCiAgICB2ZW5kb3IgICAgID0g J05FQyBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAndVBENzIwNDAwIFBDSSBFeHByZXNz IC0gUENJL1BDSS1YIEJyaWRnZScKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNz ICAgPSBQQ0ktUENJCnBjaWIzQHBjaTA6MTowOjE6CWNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgwMDAw MDAwMCBjaGlwPTB4MDEyNTEwMzMgcmV2PTB4MDYgaGRyPTB4MDEKICAgIHZlbmRvciAgICAgPSAn TkVDIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICd1UEQ3MjA0MDAgUENJIEV4cHJlc3Mg LSBQQ0kvUENJLVggQnJpZGdlJwogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3Mg ICA9IFBDSS1QQ0kKdmdhcGNpMEBwY2kwOjQ6MDowOgljbGFzcz0weDAzMDAwMCBjYXJkPTB4Yzk1 NDM4NDIgY2hpcD0weDA2NDAxMGRlIHJldj0weGExIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0g J25WaWRpYSBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnRzk2IFtHZUZvcmNlIDk1MDAg R1RdJwogICAgY2xhc3MgICAgICA9IGRpc3BsYXkKICAgIHN1YmNsYXNzICAgPSBWR0EKbWZpMEBw Y2kwOjU6MDowOgljbGFzcz0weDAxMDQwMCBjYXJkPTB4MTAxMjEwMDAgY2hpcD0weDAwNjAxMDAw IHJldj0weDA0IGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0xTSSBMb2dpYyAvIFN5bWJpb3Mg TG9naWMnCiAgICBkZXZpY2UgICAgID0gJ01lZ2FSQUlEIFNBUyAxMDc4JwogICAgY2xhc3MgICAg ICA9IG1hc3Mgc3RvcmFnZQogICAgc3ViY2xhc3MgICA9IFJBSUQKcmUwQHBjaTA6NjowOjA6CWNs YXNzPTB4MDIwMDAwIGNhcmQ9MHg4MzY3MTA0MyBjaGlwPTB4ODE2ODEwZWMgcmV2PTB4MDIgaGRy PTB4MDAKICAgIHZlbmRvciAgICAgPSAnUmVhbHRlayBTZW1pY29uZHVjdG9yIENvLiwgTHRkLicK ICAgIGRldmljZSAgICAgPSAnUlRMODExMS84MTY4QiBQQ0kgRXhwcmVzcyBHaWdhYml0IEV0aGVy bmV0IGNvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gbmV0d29yawogICAgc3ViY2xhc3MgICA9 IGV0aGVybmV0CmVtdTEwa3gwQHBjaTA6ODowOjA6CWNsYXNzPTB4MDQwMTAwIGNhcmQ9MHgxMDIx MTEwMiBjaGlwPTB4MDAwODExMDIgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAn Q3JlYXRpdmUgTGFicycKICAgIGRldmljZSAgICAgPSAnU0IwNDAwIEF1ZGlneTIgVmFsdWUnCiAg ICBjbGFzcyAgICAgID0gbXVsdGltZWRpYQogICAgc3ViY2xhc3MgICA9IGF1ZGlvCmZ3b2hjaTBA cGNpMDo4OjQ6MDoJY2xhc3M9MHgwYzAwMTAgY2FyZD0weDgyNTkxMDQzIGNoaXA9MHg1ODExMTFj MSByZXY9MHg3MCBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdBZ2VyZSBTeXN0ZW1zJwogICAg ZGV2aWNlICAgICA9ICdGVzMyMi8zMjMnCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cwogICAg c3ViY2xhc3MgICA9IEZpcmVXaXJlCmhvc3RiMUBwY2kwOjI1NTowOjA6CWNsYXNzPTB4MDYwMDAw IGNhcmQ9MHg4MDg2ODA4NiBjaGlwPTB4MmM0MTgwODYgcmV2PTB4MDUgaGRyPTB4MDAKICAgIHZl bmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1hlb24gNTUw MC9Db3JlIGk3IFF1aWNrUGF0aCBBcmNoaXRlY3R1cmUgR2VuZXJpYyBOb24tQ29yZSBSZWdpc3Rl cnMnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kKaG9z dGIyQHBjaTA6MjU1OjA6MToJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDgwODY4MDg2IGNoaXA9MHgy YzAxODA4NiByZXY9MHgwNSBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3Jh dGlvbicKICAgIGRldmljZSAgICAgPSAnWGVvbiA1NTAwL0NvcmUgaTcgUXVpY2tQYXRoIEFyY2hp dGVjdHVyZSBTeXN0ZW0gQWRkcmVzcyBEZWNvZGVyJwogICAgY2xhc3MgICAgICA9IGJyaWRnZQog ICAgc3ViY2xhc3MgICA9IEhPU1QtUENJCmhvc3RiM0BwY2kwOjI1NToyOjA6CWNsYXNzPTB4MDYw MDAwIGNhcmQ9MHg4MDg2ODA4NiBjaGlwPTB4MmMxMDgwODYgcmV2PTB4MDUgaGRyPTB4MDAKICAg IHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1hlb24g NTUwMC9Db3JlIGk3IFFQSSBMaW5rIDAnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJj bGFzcyAgID0gSE9TVC1QQ0kKaG9zdGI0QHBjaTA6MjU1OjI6MToJY2xhc3M9MHgwNjAwMDAgY2Fy ZD0weDgwODY4MDg2IGNoaXA9MHgyYzExODA4NiByZXY9MHgwNSBoZHI9MHgwMAogICAgdmVuZG9y ICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnWGVvbiA1NTAwL0Nv cmUgaTcgUVBJIFBoeXNpY2FsIDAnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFz cyAgID0gSE9TVC1QQ0kKaG9zdGI1QHBjaTA6MjU1OjM6MDoJY2xhc3M9MHgwNjAwMDAgY2FyZD0w eDgwODY4MDg2IGNoaXA9MHgyYzE4ODA4NiByZXY9MHgwNSBoZHI9MHgwMAogICAgdmVuZG9yICAg ICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnWGVvbiA1NTAwL0NvcmUg aTcgSW50ZWdyYXRlZCBNZW1vcnkgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBicmlkZ2UK ICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQpob3N0YjZAcGNpMDoyNTU6MzoxOgljbGFzcz0weDA2 MDAwMCBjYXJkPTB4ODA4NjgwODYgY2hpcD0weDJjMTk4MDg2IHJldj0weDA1IGhkcj0weDAwCiAg ICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdYZW9u IDU1MDAvQ29yZSBpNyBJbnRlZ3JhdGVkIE1lbW9yeSBDb250cm9sbGVyIFRhcmdldCBBZGRyZXNz IERlY29kZXInCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gSE9TVC1Q Q0kKaG9zdGI3QHBjaTA6MjU1OjM6NDoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDgwODY4MDg2IGNo aXA9MHgyYzFjODA4NiByZXY9MHgwNSBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBD b3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnWGVvbiA1NTAwL0NvcmUgaTcgSW50ZWdyYXRl ZCBNZW1vcnkgQ29udHJvbGxlciBUZXN0IFJlZ2lzdGVycycKICAgIGNsYXNzICAgICAgPSBicmlk Z2UKICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQpob3N0YjhAcGNpMDoyNTU6NDowOgljbGFzcz0w eDA2MDAwMCBjYXJkPTB4ODA4NjgwODYgY2hpcD0weDJjMjA4MDg2IHJldj0weDA1IGhkcj0weDAw CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdY ZW9uIDU1MDAvQ29yZSBpNyBJbnRlZ3JhdGVkIE1lbW9yeSBDb250cm9sbGVyIENoYW5uZWwgMCBD b250cm9sIFJlZ2lzdGVycycKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAg PSBIT1NULVBDSQpob3N0YjlAcGNpMDoyNTU6NDoxOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4ODA4 NjgwODYgY2hpcD0weDJjMjE4MDg2IHJldj0weDA1IGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0g J0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdYZW9uIDU1MDAvQ29yZSBpNyBJ bnRlZ3JhdGVkIE1lbW9yeSBDb250cm9sbGVyIENoYW5uZWwgMCBBZGRyZXNzIFJlZ2lzdGVycycK ICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQpob3N0YjEw QHBjaTA6MjU1OjQ6MjoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDgwODY4MDg2IGNoaXA9MHgyYzIy ODA4NiByZXY9MHgwNSBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlv bicKICAgIGRldmljZSAgICAgPSAnWGVvbiA1NTAwL0NvcmUgaTcgSW50ZWdyYXRlZCBNZW1vcnkg Q29udHJvbGxlciBDaGFubmVsIDAgUmFuayBSZWdpc3RlcnMnCiAgICBjbGFzcyAgICAgID0gYnJp ZGdlCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kKaG9zdGIxMUBwY2kwOjI1NTo0OjM6CWNsYXNz PTB4MDYwMDAwIGNhcmQ9MHg4MDg2ODA4NiBjaGlwPTB4MmMyMzgwODYgcmV2PTB4MDUgaGRyPTB4 MDAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0g J1hlb24gNTUwMC9Db3JlIGk3IEludGVncmF0ZWQgTWVtb3J5IENvbnRyb2xsZXIgQ2hhbm5lbCAw IFRoZXJtYWwgQ29udHJvbCBSZWdpc3RlcnMnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBz dWJjbGFzcyAgID0gSE9TVC1QQ0kKaG9zdGIxMkBwY2kwOjI1NTo1OjA6CWNsYXNzPTB4MDYwMDAw IGNhcmQ9MHg4MDg2ODA4NiBjaGlwPTB4MmMyODgwODYgcmV2PTB4MDUgaGRyPTB4MDAKICAgIHZl bmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1hlb24gNTUw MC9Db3JlIGk3IEludGVncmF0ZWQgTWVtb3J5IENvbnRyb2xsZXIgQ2hhbm5lbCAxIENvbnRyb2wg UmVnaXN0ZXJzJwogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IEhPU1Qt UENJCmhvc3RiMTNAcGNpMDoyNTU6NToxOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4ODA4NjgwODYg Y2hpcD0weDJjMjk4MDg2IHJldj0weDA1IGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVs IENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdYZW9uIDU1MDAvQ29yZSBpNyBJbnRlZ3Jh dGVkIE1lbW9yeSBDb250cm9sbGVyIENoYW5uZWwgMSBBZGRyZXNzIFJlZ2lzdGVycycKICAgIGNs YXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQpob3N0YjE0QHBjaTA6 MjU1OjU6MjoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDgwODY4MDg2IGNoaXA9MHgyYzJhODA4NiBy ZXY9MHgwNSBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAg IGRldmljZSAgICAgPSAnWGVvbiA1NTAwL0NvcmUgaTcgSW50ZWdyYXRlZCBNZW1vcnkgQ29udHJv bGxlciBDaGFubmVsIDEgUmFuayBSZWdpc3RlcnMnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAg ICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kKaG9zdGIxNUBwY2kwOjI1NTo1OjM6CWNsYXNzPTB4MDYw MDAwIGNhcmQ9MHg4MDg2ODA4NiBjaGlwPTB4MmMyYjgwODYgcmV2PTB4MDUgaGRyPTB4MDAKICAg IHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1hlb24g NTUwMC9Db3JlIGk3IEludGVncmF0ZWQgTWVtb3J5IENvbnRyb2xsZXIgQ2hhbm5lbCAxIFRoZXJt YWwgQ29udHJvbCBSZWdpc3RlcnMnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFz cyAgID0gSE9TVC1QQ0kKaG9zdGIxNkBwY2kwOjI1NTo2OjA6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9 MHg4MDg2ODA4NiBjaGlwPTB4MmMzMDgwODYgcmV2PTB4MDUgaGRyPTB4MDAKICAgIHZlbmRvciAg ICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1hlb24gNTUwMC9Db3Jl IGk3IEludGVncmF0ZWQgTWVtb3J5IENvbnRyb2xsZXIgQ2hhbm5lbCAyIENvbnRyb2wgUmVnaXN0 ZXJzJwogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJCmhv c3RiMTdAcGNpMDoyNTU6NjoxOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4ODA4NjgwODYgY2hpcD0w eDJjMzE4MDg2IHJldj0weDA1IGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBv cmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdYZW9uIDU1MDAvQ29yZSBpNyBJbnRlZ3JhdGVkIE1l bW9yeSBDb250cm9sbGVyIENoYW5uZWwgMiBBZGRyZXNzIFJlZ2lzdGVycycKICAgIGNsYXNzICAg ICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQpob3N0YjE4QHBjaTA6MjU1OjY6 MjoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDgwODY4MDg2IGNoaXA9MHgyYzMyODA4NiByZXY9MHgw NSBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmlj ZSAgICAgPSAnWGVvbiA1NTAwL0NvcmUgaTcgSW50ZWdyYXRlZCBNZW1vcnkgQ29udHJvbGxlciBD aGFubmVsIDIgUmFuayBSZWdpc3RlcnMnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJj bGFzcyAgID0gSE9TVC1QQ0kKaG9zdGIxOUBwY2kwOjI1NTo2OjM6CWNsYXNzPTB4MDYwMDAwIGNh cmQ9MHg4MDg2ODA4NiBjaGlwPTB4MmMzMzgwODYgcmV2PTB4MDUgaGRyPTB4MDAKICAgIHZlbmRv ciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1hlb24gNTUwMC9D b3JlIGk3IEludGVncmF0ZWQgTWVtb3J5IENvbnRyb2xsZXIgQ2hhbm5lbCAyIFRoZXJtYWwgQ29u dHJvbCBSZWdpc3RlcnMnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0g SE9TVC1QQ0kK --001636e0b6211b70b204a019ba92-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 4 16:01:16 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89A99106567F for ; Mon, 4 Apr 2011 16:01:16 +0000 (UTC) (envelope-from philip@paeps.cx) Received: from rincewind.paeps.cx (rincewind.paeps.cx [IPv6:2002:596a:f092::149]) by mx1.freebsd.org (Postfix) with ESMTP id 0C6FC8FC13 for ; Mon, 4 Apr 2011 16:01:16 +0000 (UTC) Received: by rincewind.paeps.cx (Postfix, from userid 1001) id 64C0FD7445E; Mon, 4 Apr 2011 18:01:15 +0200 (CEST) Date: Mon, 4 Apr 2011 18:01:15 +0200 From: Philip Paeps To: freebsd-hackers@freebsd.org Message-ID: <20110404160115.GS71940@rincewind.paeps.cx> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20110404141016.GL71940@rincewind.paeps.cx> <4D99D81A.7000903@FreeBSD.org> <20110404145748.GP71940@rincewind.paeps.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-PGP-Fingerprint: 356B AE02 4763 F739 2FA2 E438 2649 E628 C5D3 4D05 X-Date: Prickle-Prickle, Discord 21, 3177 YOLD X-Phase-of-Moon: The Moon is Waxing Crescent (1% of Full) X-Philip-Conspiracy: There is no conspiracy Organization: Happily Disorganized User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Updating PCI vendors database X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:01:16 -0000 On 2011-04-04 08:51:03 (-0700), Garrett Cooper wrote: > On Mon, Apr 4, 2011 at 7:57 AM, Philip Paeps wrote: > > On 2011-04-04 17:39:22 (+0300), Andriy Gapon wrote: > >> on 04/04/2011 17:10 Philip Paeps said the following: > >> > Would anyone object if I updated this list to source the same database > >> > used by Linux distributions at > >> > http://pciids.sourceforge.net/v2.2/pci.ids? > >> > > >> > It helps that our pciconf looks to be compatible with that format.  We > >> > just ignore subvendor and subdevice, but it doesn't appear to matter > >> > that the file contains this information. > >> > [...] > >> > >> This is just for your information: > >> http://thread.gmane.org/gmane.os.freebsd.current/127979/focus=128577 > >> Maybe you'll find something useful there. > > > > Thanks.  I've just read through that discussion.  It doesn't look like > > there were any "serious" objections to pulling in the new list, other than > > verifying that the new list contains all the entries the current list > > contains. > > > > I am not entirely sure what the little side-discussion about using # > > instead of ; as a comment marker is about.  It looks to me like the > > pci.ids file "Just Works"[tm] with our pciconf(8).  Maybe Garrett can > > elaborate on that? > > Well, close. You can substitute the hashes with semicolons, but you > need to get rid of subvendor / subdevice. The presence of the subvendor/subdevice entries doesn't appear to affect the correctness of the output on the machines I've tested it on. Cursorily reading through the pciconf(8) source code suggests it ignores that data (and as it happens the presence of subvendors and subdevices). I think the "most correct" thing to do would be to teach pciconf(8) about subvendors and subdevices and pull in the new list as-is. I'll take a look at adding support for that later today. It shouldn't be much work. > Setting PCICONF_VENDOR_DATABASE to pci.ids worked, but all the items on my > box are different in the new file (all device descriptions, but also some of > the vendor descriptions dealing with my nVidia card, Realtek NIC, and LSI > card) [it would be interesting to see who's correct in terms of corporation > branding :)..]. So this definitely isn't MFC-able :). It doesn't look like they're fundamentally different through. The strings changed, but still seem to be describing the same devices. I'm happy to agree that this isn't MFC-able. > > I think we should just go with the new list, but I'll hold off for a bit > > to let others object. ;) > > +1, just for the fact that our sources are becoming stale. I wonder though > what other OSes like NetBSD/OpenBSD/[Open]Solaris/IlluminOS use however for > tracking PCI IDs, as the sources for pci.ids aren't necessarily the vendor > itself and in some cases are end-users. I thought some of our other sources > were based on data provided by vendors. A comment from jfv@ in the thread from a few months ago, suggests that at least Intel contributes directly to the pci.ids list. One measurement isn't a valid statistic though. - Philip -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 4 16:11:12 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5D001065673 for ; Mon, 4 Apr 2011 16:11:12 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.freebsd.org (Postfix) with SMTP id 0D9658FC08 for ; Mon, 4 Apr 2011 16:11:11 +0000 (UTC) Received: (qmail 91192 invoked from network); 4 Apr 2011 15:44:29 -0000 Received: from unknown (HELO alex.andxor.it) (192.168.2.30) by andxor.it with SMTP; 4 Apr 2011 15:44:29 -0000 Message-ID: <4D99E75D.6050004@FreeBSD.org> Date: Mon, 04 Apr 2011 17:44:29 +0200 From: Alex Dupre User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; it; rv:1.9.1.18) Gecko/20110324 SeaMonkey/2.0.13 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20110404141016.GL71940@rincewind.paeps.cx> <4D99D81A.7000903@FreeBSD.org> <20110404145748.GP71940@rincewind.paeps.cx> In-Reply-To: <20110404145748.GP71940@rincewind.paeps.cx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Updating PCI vendors database X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:11:12 -0000 Philip Paeps ha scritto: >> This is just for your information: >> http://thread.gmane.org/gmane.os.freebsd.current/127979/focus=128577 >> Maybe you'll find something useful there. > > Thanks. I've just read through that discussion. It doesn't look like there > were any "serious" objections to pulling in the new list, other than verifying > that the new list contains all the entries the current list contains. The discussion went on privately (dunno why) beetween John, Warner, Brooks, me and a few others. I suggest you to contact John Baldwin before taking actions, I've updated also the merged lists. -- Alex Dupre From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 4 16:17:49 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 527FC106566C for ; Mon, 4 Apr 2011 16:17:49 +0000 (UTC) (envelope-from philip@paeps.cx) Received: from rincewind.paeps.cx (rincewind.paeps.cx [IPv6:2002:596a:f092::149]) by mx1.freebsd.org (Postfix) with ESMTP id CC1B48FC14 for ; Mon, 4 Apr 2011 16:17:48 +0000 (UTC) Received: by rincewind.paeps.cx (Postfix, from userid 1001) id 3DE23D7445E; Mon, 4 Apr 2011 18:17:48 +0200 (CEST) Date: Mon, 4 Apr 2011 18:17:48 +0200 From: Philip Paeps To: freebsd-hackers@freebsd.org Message-ID: <20110404161748.GT71940@rincewind.paeps.cx> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20110404141016.GL71940@rincewind.paeps.cx> <4D99D81A.7000903@FreeBSD.org> <20110404145748.GP71940@rincewind.paeps.cx> <4D99E75D.6050004@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4D99E75D.6050004@FreeBSD.org> X-PGP-Fingerprint: 356B AE02 4763 F739 2FA2 E438 2649 E628 C5D3 4D05 X-Date: Prickle-Prickle, Discord 21, 3177 YOLD X-Phase-of-Moon: The Moon is Waxing Crescent (2% of Full) X-Philip-Conspiracy: There is no conspiracy Organization: Happily Disorganized User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Updating PCI vendors database X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:17:49 -0000 On 2011-04-04 17:44:29 (+0200), Alex Dupre wrote: > Philip Paeps ha scritto: > >> This is just for your information: > >> http://thread.gmane.org/gmane.os.freebsd.current/127979/focus=128577 > >> Maybe you'll find something useful there. > > > > Thanks. I've just read through that discussion. It doesn't look like there > > were any "serious" objections to pulling in the new list, other than verifying > > that the new list contains all the entries the current list contains. > > The discussion went on privately (dunno why) beetween John, Warner, Brooks, > me and a few others. I suggest you to contact John Baldwin before taking > actions, I've updated also the merged lists. Thanks. I'll talk to them. - Philip -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. I thought that said "Windows has been installed for your safety". -- SlimeyPete, looking at safety signs on a train From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 4 16:19:31 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFD80106567A; Mon, 4 Apr 2011 16:19:31 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6E0278FC1B; Mon, 4 Apr 2011 16:19:31 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p34GGKxl076282 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 4 Apr 2011 10:16:23 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20110404160115.GS71940@rincewind.paeps.cx> Date: Mon, 4 Apr 2011 10:16:14 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9AFA2D0E-60E2-49DA-A1B3-029A67D36674@bsdimp.com> References: <20110404141016.GL71940@rincewind.paeps.cx> <4D99D81A.7000903@FreeBSD.org> <20110404145748.GP71940@rincewind.paeps.cx> <20110404160115.GS71940@rincewind.paeps.cx> To: Philip Paeps X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 04 Apr 2011 10:16:23 -0600 (MDT) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Updating PCI vendors database X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:19:31 -0000 On Apr 4, 2011, at 10:01 AM, Philip Paeps wrote: >>> I think we should just go with the new list, but I'll hold off for a = bit >>> to let others object. ;) >>=20 >> +1, just for the fact that our sources are becoming stale. I wonder = though >> what other OSes like NetBSD/OpenBSD/[Open]Solaris/IlluminOS use = however for >> tracking PCI IDs, as the sources for pci.ids aren't necessarily the = vendor >> itself and in some cases are end-users. I thought some of our other = sources >> were based on data provided by vendors. >=20 > A comment from jfv@ in the thread from a few months ago, suggests that = at > least Intel contributes directly to the pci.ids list. One measurement = isn't > a valid statistic though. Since the old list appears to have disappeared, I'd go with the new one. = There were patches floating about even. The new list had worse = coverage than the old one for some old PCI gear, so I suggested using = the new one in preference to the old one and if there were good entries = in the old one to try to merge those into the new one over time and wean = us from the old one. If the old one is gone, the path forward is clear. Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 4 16:25:30 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BA531065677 for ; Mon, 4 Apr 2011 16:25:30 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id AB9138FC15 for ; Mon, 4 Apr 2011 16:25:29 +0000 (UTC) Received: by wyf23 with SMTP id 23so5641940wyf.13 for ; Mon, 04 Apr 2011 09:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:from:to:subject:date:x-mailer; bh=LafGuPOvp2lP3C5KeCWytQX3F24PN/7eU3GBxyVhl04=; b=RYDucrCVZr5KXv1uVErhbPKDfW3W4la6h8fkC51hgL8tGGs0QVg/WWuWeJeQMPnnGS sojssb+vYBriraRxLDFdng71raKprWr3V0NZh9zcy6U/cLot2CPQ5Gxg9kmG6H7azNce XuyC9A16QTBxw++HgB7pmpDDweMxyz4aSt9s8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:x-mailer; b=qqVDOuLXCZFGVLDzpTlEq58x7HxU8AThFcuf096i3+hxKS0cTLRbA5qi2Wt2rQZvzj CzZUljz0iU1T6QRvs2kwwnjCtqkZ6G/uG4lQj1jX1S9MdmIdiYJBU7UMlws6q2E7+yld eetwmPRJ0E8uUt78GRbV8eXHvK2B49c/FmokQ= Received: by 10.216.167.65 with SMTP id h43mr4091424wel.17.1301934328564; Mon, 04 Apr 2011 09:25:28 -0700 (PDT) Received: from DEV (78-1-186-55.adsl.net.t-com.hr [78.1.186.55]) by mx.google.com with ESMTPS id f30sm2336041wef.7.2011.04.04.09.25.26 (version=SSLv3 cipher=OTHER); Mon, 04 Apr 2011 09:25:27 -0700 (PDT) Message-ID: <20110404.162515.125.1@DEV> From: rank1seeker@gmail.com To: freebsd-hackers@freebsd.org Date: Mon, 04 Apr 2011 18:25:15 +0200 X-Mailer: POP Peeper (3.7.0.0) Subject: Extending sed's exit codes functionality X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:25:30 -0000 http://forums.freebsd.org/showthread.php?p=129996 Domagoj S. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 4 18:04:39 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 16E6B106564A for ; Mon, 4 Apr 2011 18:04:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 01571150E80 for ; Mon, 4 Apr 2011 18:04:38 +0000 (UTC) Message-ID: <4D9A0836.7070403@FreeBSD.org> Date: Mon, 04 Apr 2011 11:04:38 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: hackers@freebsd.org References: <20110404141016.GL71940@rincewind.paeps.cx> In-Reply-To: <20110404141016.GL71940@rincewind.paeps.cx> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Updating PCI vendors database X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 18:04:39 -0000 On 04/04/2011 07:10, Philip Paeps wrote: > It looks like our /usr/share/misc/pci_vendors list (used only by pciconf as > far as I can tell) has become rather stale. We also appear to be tracking > sources which no longer exist. > > Would anyone object if I updated this list to source the same database used by > Linux distributions at http://pciids.sourceforge.net/v2.2/pci.ids? > > It helps that our pciconf looks to be compatible with that format. We just > ignore subvendor and subdevice, but it doesn't appear to matter that the file > contains this information. > > I could cull the subvendor/subdevice from the list though. > > Any views? Having read this thread, and the last one, my opinion is, let's do it already. :) Repo churn should not, under any circumstances, be a consideration in technical improvements. I agree with those who have said that the new list should be confirmed to be a superset of the old, and anything missing should be merged in. Checking with Jack about Intel stuff is also reasonable, as would be cross-checking with what NetBSD and OpenBSD are doing (and perhaps communicating with them about your work). So, not a slam-dunk, but definitely a clear path forward. Oh, and I personally don't see a problem with MFC'ing this, but I'm willing to be convinced. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 4 18:50:08 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BF68106564A for ; Mon, 4 Apr 2011 18:50:08 +0000 (UTC) (envelope-from philip@paeps.cx) Received: from rincewind.paeps.cx (rincewind.paeps.cx [IPv6:2002:596a:f092::149]) by mx1.freebsd.org (Postfix) with ESMTP id 4124C8FC12 for ; Mon, 4 Apr 2011 18:50:08 +0000 (UTC) Received: by rincewind.paeps.cx (Postfix, from userid 1001) id A53BCD7445E; Mon, 4 Apr 2011 20:50:07 +0200 (CEST) Date: Mon, 4 Apr 2011 20:50:07 +0200 From: Philip Paeps To: hackers@freebsd.org Message-ID: <20110404185007.GX71940@rincewind.paeps.cx> Mail-Followup-To: hackers@freebsd.org References: <20110404141016.GL71940@rincewind.paeps.cx> <4D9A0836.7070403@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4D9A0836.7070403@FreeBSD.org> X-PGP-Fingerprint: 356B AE02 4763 F739 2FA2 E438 2649 E628 C5D3 4D05 X-Date: Prickle-Prickle, Discord 21, 3177 YOLD X-Phase-of-Moon: The Moon is Waxing Crescent (2% of Full) X-Philip-Conspiracy: There is no conspiracy Organization: Happily Disorganized User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Updating PCI vendors database X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 18:50:08 -0000 On 2011-04-04 11:04:38 (-0700), Doug Barton wrote: > On 04/04/2011 07:10, Philip Paeps wrote: > > It looks like our /usr/share/misc/pci_vendors list (used only by pciconf > > as far as I can tell) has become rather stale. We also appear to be > > tracking sources which no longer exist. > > > > Would anyone object if I updated this list to source the same database > > used by Linux distributions at http://pciids.sourceforge.net/v2.2/pci.ids? > > > > It helps that our pciconf looks to be compatible with that format. We > > just ignore subvendor and subdevice, but it doesn't appear to matter that > > the file contains this information. > > > > I could cull the subvendor/subdevice from the list though. > > > > Any views? > > Having read this thread, and the last one, my opinion is, let's do it > already. :) I'll wait a little longer for more comments but then: yes, I'll go and do it. > Repo churn should not, under any circumstances, be a consideration in > technical improvements. I agree with those who have said that the new list > should be confirmed to be a superset of the old, and anything missing should > be merged in. Checking with Jack about Intel stuff is also reasonable, as > would be cross-checking with what NetBSD and OpenBSD are doing (and perhaps > communicating with them about your work). > > So, not a slam-dunk, but definitely a clear path forward. Oh, and I > personally don't see a problem with MFC'ing this, but I'm willing to be > convinced. I was thinking of putting it in head and waiting a good while for the screaming to subside and the fires to go out before raising the idea of merging it to stable. Barring any clear counterindications, I'll just "do this" in the next day or so. - Philip -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 4 22:28:49 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA5D51065676 for ; Mon, 4 Apr 2011 22:28:49 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id B13348FC15 for ; Mon, 4 Apr 2011 22:28:49 +0000 (UTC) Received: by pzk27 with SMTP id 27so1863499pzk.13 for ; Mon, 04 Apr 2011 15:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=a4PK2m+yAOv5PzlSS+PFtn4xwPWrnus9XeRO5CC2mX8=; b=BfUxcQnzZ87jW4GjkNa+LC3suUtcy/7ca3XdABZ17VNHWoGSnWB3IyknnqeXLYuWHO hpCv1rY90CgL1oncP4SqmY3H+dFDRwbcB02q8amlcfqQW6AFunqzjo/qBLp01QwY8yBX 0qJX5BbLJs6aTFExeir0YCLHbz2Saxbqufd3g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=F5IgZ8JLoXBuiPjo9E1fo/ABMczlc8Aj71YHS0XOSb9iOP62BDk14ctgb087KDG6d1 IIsC3KMLwwPDYjbMR8gpmmyavcVBN1AlFGqeW/XkUZlHfGaiMDNbWHV8QPs4Ial0sqjr 9zZRiuhuhi3yNv0ArZXaFUkP+NBDJ4RoPMfwg= MIME-Version: 1.0 Received: by 10.143.153.13 with SMTP id f13mr6636659wfo.380.1301956128928; Mon, 04 Apr 2011 15:28:48 -0700 (PDT) Received: by 10.68.42.3 with HTTP; Mon, 4 Apr 2011 15:28:48 -0700 (PDT) In-Reply-To: <20110404.162515.125.1@DEV> References: <20110404.162515.125.1@DEV> Date: Mon, 4 Apr 2011 15:28:48 -0700 Message-ID: From: Garrett Cooper To: rank1seeker@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: Extending sed's exit codes functionality X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 22:28:49 -0000 On Mon, Apr 4, 2011 at 9:25 AM, wrote: > http://forums.freebsd.org/showthread.php?p=129996 gordon@'s observation seems valid: http://forums.freebsd.org/showpost.php?p=130007&postcount=2 ? Your other question about grep returning 141 was because it caught SIGPIPE, so probably a *csh bug (I wouldn't be surprised). When in doubt, simplify (and don't use csh)! $ csh -c "cat /sys/conf/NOTES | grep -m 1 '^device' /sys/conf/NOTES; echo \$?" device hwpmc # Driver (also a loadable module) 141 $ env ENV=/dev/null sh -c "cat /sys/conf/NOTES | grep -m 1 '^device' /sys/conf/NOTES; echo \$?" device hwpmc # Driver (also a loadable module) 0 You might want to ktrace/truss the piped process to figure out why it's catching SIGPIPE, and maybe submit a bug report once you figure out why csh isn't playing nicely. Happy hunting. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 5 03:30:39 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B150106564A; Tue, 5 Apr 2011 03:30:39 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 395AE8FC16; Tue, 5 Apr 2011 03:30:39 +0000 (UTC) Received: by pxi6 with SMTP id 6so4915680pxi.17 for ; Mon, 04 Apr 2011 20:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hhUgOKOTTX5IVeJ/iJVY0vN/PGVOLViWK+I3Pe19mng=; b=UZWbGP8GPKhC5RrZEyNsT96D3ddAsnY0mri4D/jUKj5qm+KfAPhVyPI3NNgILKTK4k veRdYoWDZzBPU5wVBpbxEGyaXEK7k/r2f8YF63OLfams9MuYhopwD2v3XYZAD1/5O3Sf 2fk+8RuN/QK1qSp2fkuAvsas7EoDKL+pm9RTo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jfi1gXOFN34WPJvMReqB6MgjJaAXb6Pd4bItoQiArpz6jUcBsiA+3g/89SdnnO+nWG pWQuQFuAvP36vwAnXbuxQdczmvc4rqVFCXCwgBLD0fo8bxaGbkxBQdaDRh8gpnmq2TM0 8BlL0k3Ab6qc3Was3gZMjRaUzij+fbiveSSVc= MIME-Version: 1.0 Received: by 10.142.248.21 with SMTP id v21mr7079769wfh.56.1301974238700; Mon, 04 Apr 2011 20:30:38 -0700 (PDT) Received: by 10.68.42.3 with HTTP; Mon, 4 Apr 2011 20:30:38 -0700 (PDT) In-Reply-To: <4D9A0836.7070403@FreeBSD.org> References: <20110404141016.GL71940@rincewind.paeps.cx> <4D9A0836.7070403@FreeBSD.org> Date: Mon, 4 Apr 2011 20:30:38 -0700 Message-ID: From: Garrett Cooper To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: Updating PCI vendors database X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 03:30:39 -0000 On Mon, Apr 4, 2011 at 11:04 AM, Doug Barton wrote: > On 04/04/2011 07:10, Philip Paeps wrote: >> >> It looks like our /usr/share/misc/pci_vendors list (used only by pciconf >> as >> far as I can tell) has become rather stale. =A0We also appear to be trac= king >> sources which no longer exist. >> >> Would anyone object if I updated this list to source the same database >> used by >> Linux distributions at http://pciids.sourceforge.net/v2.2/pci.ids? >> >> It helps that our pciconf looks to be compatible with that format. =A0We >> just >> ignore subvendor and subdevice, but it doesn't appear to matter that the >> file >> contains this information. >> >> I could cull the subvendor/subdevice from the list though. >> >> Any views? > > Having read this thread, and the last one, my opinion is, let's do it > already. :) =A0Repo churn should not, under any circumstances, be a > consideration in technical improvements. I agree with those who have said > that the new list should be confirmed to be a superset of the old, and > anything missing should be merged in. Checking with Jack about Intel stuf= f > is also reasonable, as would be cross-checking with what NetBSD and OpenB= SD > are doing (and perhaps communicating with them about your work). 1. People may have automation that depends on this output. 2. Some braindead SCMs may be problematic with this change (p4? *COUGH*). Someone at $WORK recently backported a copy of pci_vendors from CURRENT to STABLE without any issues (needed a few PCI IDs for new hardware), but that might not have been as true with this shift to using pci.ids. > So, not a slam-dunk, but definitely a clear path forward. Oh, and I > personally don't see a problem with MFC'ing this, but I'm willing to be > convinced. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 5 04:30:46 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 9DD38106564A for ; Tue, 5 Apr 2011 04:30:46 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 1335F14EEE9; Tue, 5 Apr 2011 04:30:45 +0000 (UTC) Message-ID: <4D9A9AF5.9020807@FreeBSD.org> Date: Mon, 04 Apr 2011 21:30:45 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: Garrett Cooper References: <20110404141016.GL71940@rincewind.paeps.cx> <4D9A0836.7070403@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: Updating PCI vendors database X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 04:30:46 -0000 On 04/04/2011 20:30, Garrett Cooper wrote: > 1. People may have automation that depends on this output. To the extent that they rely on information that is out of date, fixing this is a feature. However I cannot imagine that this would be much of an issue. > 2. Some braindead SCMs may be problematic with this change (p4?*COUGH*). Eh? I don't parse this. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 5 04:36:22 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43D94106564A; Tue, 5 Apr 2011 04:36:22 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 127BF8FC0C; Tue, 5 Apr 2011 04:36:21 +0000 (UTC) Received: by pzk27 with SMTP id 27so414pzk.13 for ; Mon, 04 Apr 2011 21:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HYCsqaI2KKhMWFJJxeXLvQFo6fEJaU58Wde2f/i2sHE=; b=jB3k8bfnOt4MUGDMBPjCRvsr16iW3dDvV1ouupVGq+c20eP08NyYmsdDMxpuVE3kDA Gzc8q3fASruZ4WUUpvjS2BzhTRk30y92wVGNLS/UpQLCuHpbQUMHB1frjYMpZTEvF9Gz ivDrNz+b41N5mNps0LwIkcR1IIAPG7r6SxwGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rzEFswhDYiljbZzmafbiexjZ6MGYElrQUoBcafLermyuFqMIL5dEBX1NQIoDCEA870 Q57okmAb7/a7I1FO8C+YIiwTtHMIzxyyeaAPyNsADbFdBXbWMhF5VXojlHs6B4bZvdti YW6YNkBuF5tY0pypkt+F9xDD8GR+UrbifPsto= MIME-Version: 1.0 Received: by 10.142.237.20 with SMTP id k20mr7526626wfh.170.1301978181452; Mon, 04 Apr 2011 21:36:21 -0700 (PDT) Received: by 10.68.42.3 with HTTP; Mon, 4 Apr 2011 21:36:21 -0700 (PDT) In-Reply-To: <4D9A9AF5.9020807@FreeBSD.org> References: <20110404141016.GL71940@rincewind.paeps.cx> <4D9A0836.7070403@FreeBSD.org> <4D9A9AF5.9020807@FreeBSD.org> Date: Mon, 4 Apr 2011 21:36:21 -0700 Message-ID: From: Garrett Cooper To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: hackers@freebsd.org Subject: Re: Updating PCI vendors database X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 04:36:22 -0000 On Mon, Apr 4, 2011 at 9:30 PM, Doug Barton wrote: > On 04/04/2011 20:30, Garrett Cooper wrote: >> >> 1. People may have automation that depends on this output. > > To the extent that they rely on information that is out of date, fixing this > is a feature. However I cannot imagine that this would be much of an issue. > >> 2. Some braindead SCMs may be problematic with this change (p4?*COUGH*). > > Eh? I don't parse this. perforce doesn't always grok large changes (especially deletions -- it gets ditzy). The last change that was committed by someone at $WORK to this file was several thousand lines long, and that was just additions IIRC. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 5 04:45:47 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 4FC7B106564A for ; Tue, 5 Apr 2011 04:45:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 318CC1539A1; Tue, 5 Apr 2011 04:45:46 +0000 (UTC) Message-ID: <4D9A9E78.8040902@FreeBSD.org> Date: Mon, 04 Apr 2011 21:45:44 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: Garrett Cooper References: <20110404141016.GL71940@rincewind.paeps.cx> <4D9A0836.7070403@FreeBSD.org> <4D9A9AF5.9020807@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: Updating PCI vendors database X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 04:45:47 -0000 On 04/04/2011 21:36, Garrett Cooper wrote: >>> 2. Some braindead SCMs may be problematic with this change (p4?*COUGH*). >> > >> > Eh? I don't parse this. > perforce doesn't always grok large changes (especially deletions -- it > gets ditzy). The last change that was committed by someone at $WORK to > this file was several thousand lines long, and that was just additions > IIRC. Thanks for bringing this up, but I don't care. :) The tools serve us, not the other way around. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 5 13:19:39 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07886106564A; Tue, 5 Apr 2011 13:19:39 +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 AECB68FC17; Tue, 5 Apr 2011 13:19:37 +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 QAA04405; Tue, 05 Apr 2011 16:19:35 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4D9B16E7.2070208@FreeBSD.org> Date: Tue, 05 Apr 2011 16:19:35 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: FreeBSD Arch , FreeBSD Hackers References: <4D95E162.40605@FreeBSD.org> In-Reply-To: <4D95E162.40605@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org Subject: Re: looking for error codes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 13:19:39 -0000 on 01/04/2011 17:29 Andriy Gapon said the following: > > I am looking for error codes that would unambiguously signal that a disk drive has > readonly or write-protected media and that disk drive has no media at the moment. > I foresee these error codes being used mostly between disk peripheral drivers and > filesystem drivers. > > I will appreciate your suggestions. > > P.S. > I see that Linux uses EROFS and ENOMEDIUM for these purposes. > I am not sure about EROFS in this role. > And we don't have ENOMEDIUM (nor EMEDIUMTYPE). Thanks for all the error code suggestions so far :-) It seems that ENODEV could be a good choice for signaling readonly or write-protected media on write access: 19 ENODEV Operation not supported by device. An attempt was made to apply an inappropriate function to a device, for example, trying to read a write-only device such as a printer. BTW, SCSI code currently maps that condition to EACCES, but I don't think that that is the best choice - the error could be also produced by "permissions-related" checks. E.g. from intro(2): 13 EACCES Permission denied. An attempt was made to access a file in a way forbidden by its file access permissions. As for the ENOMEDIUM, I don't think that adding a distinct error code here would provide any new useful abilities. So, ENXIO should still be a good option. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 5 14:14:51 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 530EE106566B for ; Tue, 5 Apr 2011 14:14:51 +0000 (UTC) (envelope-from gnehzuil@gmail.com) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 26AD18FC19 for ; Tue, 5 Apr 2011 14:14:50 +0000 (UTC) Received: by pxi6 with SMTP id 6so424297pxi.17 for ; Tue, 05 Apr 2011 07:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=4PxI3pgGYCRMbxXUCL9H/EkWt86SqORFvrbJW5Mn7YA=; b=odbOLD5rovt43CPxzBMb4J+FZ68vvSiPzEO7J6SjbSe0vK2YZJx2/OSx1VU1AnrqcO Wq60fBcPUhsoj6o3VmDWCnrWi9nNpsEdWqpBVm5vu1wyIvvOH37obNIMMsxSK2PkMWqR FcKtz2AkqTvdxunzgS1ssBFB61LjZaQ4B3OSM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=pEPIVDmM3NuRJp31lc1XL4l9WpSKwUiiJlQWenmxoASxhl5dtQuIuu3vCcCcsydEmx 9VDNam8snvDrBH5V6jFi5DVwFWiAYmUlg632JaJLnCEa2BwFDcWo10LWf1kg1AMIz4J7 0DllqlTEgmbDFcSpLEWl3laErw/v2LZos5npg= Received: by 10.142.135.21 with SMTP id i21mr8087187wfd.418.1302011340898; Tue, 05 Apr 2011 06:49:00 -0700 (PDT) Received: from [192.168.1.247] ([166.111.68.197]) by mx.google.com with ESMTPS id x11sm9035480wfd.1.2011.04.05.06.48.57 (version=SSLv3 cipher=OTHER); Tue, 05 Apr 2011 06:48:59 -0700 (PDT) Message-ID: <4D9B1DC2.1050205@gmail.com> Date: Tue, 05 Apr 2011 21:48:50 +0800 From: gnehzuil User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Pedro F. Giffuni" Subject: [gsoc] HTree Directory Index and Journal in ext2fs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 14:14:51 -0000 Hello, I would like to apply a new project "HTree Directory Index and Journal in ext2fs" in GSoC 2011. This project is not in ideas page. But this project can improve ext2fs in FreeBSD. Last year, I have participated GSoC 2010 and have implemented a preallocation algorithm in ext2fs and make it can read ext4 file system in read-only mode. I have try to read htree dir index in ext4 read-only mode. Yet I don't finish it. I am plan to implement a htree dir index in ext2fs before midterm evaluation. Next I will try to implement journal in ext2fs. I think I can borrow some ideas from WAPBL in NetBSD. Best regards, lz From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 5 14:31:50 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CE02106564A for ; Tue, 5 Apr 2011 14:31:50 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 349E08FC1C for ; Tue, 5 Apr 2011 14:31:49 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q77ID-0003oq-B7 for freebsd-hackers@freebsd.org; Tue, 05 Apr 2011 16:31:41 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2011 16:31:41 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2011 16:31:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Tue, 05 Apr 2011 16:31:23 +0200 Lines: 20 Message-ID: References: <4D9B1DC2.1050205@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <4D9B1DC2.1050205@gmail.com> X-Enigmail-Version: 1.1.2 Subject: Re: [gsoc] HTree Directory Index and Journal in ext2fs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 14:31:50 -0000 On 05/04/2011 15:48, gnehzuil wrote: > Hello, > > I would like to apply a new project "HTree Directory Index and Journal > in ext2fs" in GSoC 2011. This project is not in ideas page. But this > project can improve ext2fs in FreeBSD. > > Last year, I have participated GSoC 2010 and have implemented a > preallocation algorithm in ext2fs and make it can read ext4 file system > in read-only mode. I have try to read htree dir index in ext4 read-only > mode. Yet I don't finish it. I am plan to implement a htree dir index in > ext2fs before midterm evaluation. > > Next I will try to implement journal in ext2fs. I think I can borrow > some ideas from WAPBL in NetBSD. When you say 'journal in ext2fs' do you mean ext3-compatible or something different entirely? I don't think that a journalling addition to our ext2fs which would not make it compatible with ext3 would be useful. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 5 15:12:43 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 484DE1065672 for ; Tue, 5 Apr 2011 15:12:43 +0000 (UTC) (envelope-from gnehzuil@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 012488FC18 for ; Tue, 5 Apr 2011 15:12:42 +0000 (UTC) Received: by iwn33 with SMTP id 33so544621iwn.13 for ; Tue, 05 Apr 2011 08:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=osKOiqsOhAFiAnGeXSwQ8tQXQcrmkUYEF40yUPXL2Gw=; b=hcW2w7ULkrkYkpje0icAWX8X7BfGDbbcMB6cN8CQDErPRjoPUKsMQqqCOuVreYCSZj N+A1dn5gMYRiQCL4hmbUrFPlikrkSqIbXuKUzyyQ4iilO0NvbdGHOwjGzLHSOGTQtgXB uamWpQuXFfn5ocRz3KVZySSi5KkL+4FZDjxm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HtJZYhDovT0riZ9lU5Cr0sTBTdXlwcj57j2Hc2VtcKfLZ8WoF2/v4aTaQO/qH6dLNG iIYS77kN8IRbGN+pUnSpwoAzn1SU125qNJizZCmkvQ/Qn/pjBP5b11i6lh51BIWYXDPo qL+HPmhHgdA/5C+UK4kZU6PmSoyQR1iCzJdbs= MIME-Version: 1.0 Received: by 10.42.97.69 with SMTP id m5mr12452451icn.116.1302016362171; Tue, 05 Apr 2011 08:12:42 -0700 (PDT) Received: by 10.42.180.131 with HTTP; Tue, 5 Apr 2011 08:12:42 -0700 (PDT) In-Reply-To: References: <4D9B1DC2.1050205@gmail.com> Date: Tue, 5 Apr 2011 23:12:42 +0800 Message-ID: From: gnehzuil gnehzuil To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: [gsoc] HTree Directory Index and Journal in ext2fs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 15:12:43 -0000 2011/4/5 Ivan Voras > On 05/04/2011 15:48, gnehzuil wrote: > >> Hello, >> >> I would like to apply a new project "HTree Directory Index and Journal >> in ext2fs" in GSoC 2011. This project is not in ideas page. But this >> project can improve ext2fs in FreeBSD. >> >> Last year, I have participated GSoC 2010 and have implemented a >> preallocation algorithm in ext2fs and make it can read ext4 file system >> in read-only mode. I have try to read htree dir index in ext4 read-only >> mode. Yet I don't finish it. I am plan to implement a htree dir index in >> ext2fs before midterm evaluation. >> >> Next I will try to implement journal in ext2fs. I think I can borrow >> some ideas from WAPBL in NetBSD. >> > > When you say 'journal in ext2fs' do you mean ext3-compatible or something > different entirely? I don't think that a journalling addition to our ext2fs > which would not make it compatible with ext3 would be useful. > IMHO, I want to add a ext3-compatible journal. In previously discussion, Pedro and I have mentioned WAPBL and its performance is awesome. So I want to look at it and maybe I can borrow some good ideas. > > > _______________________________________________ > 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" > -- Liu Zheng gnehzuil@gmail.com CNU NetLab Tsinghua CSCW From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 5 21:49:34 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87198106566C; Tue, 5 Apr 2011 21:49:34 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id CE01B8FC13; Tue, 5 Apr 2011 21:49:32 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.4/8.14.4) with ESMTP id p35ERZEj012105; Tue, 5 Apr 2011 09:27:35 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.4/8.14.4/Submit) id p35ERZe0012104; Tue, 5 Apr 2011 09:27:35 -0500 (CDT) (envelope-from brooks) Date: Tue, 5 Apr 2011 09:27:35 -0500 From: Brooks Davis To: Garrett Cooper Message-ID: <20110405142735.GO63248@lor.one-eyed-alien.net> References: <20110404141016.GL71940@rincewind.paeps.cx> <4D9A0836.7070403@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ztcJpsdPpsnnlAp8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 05 Apr 2011 09:27:36 -0500 (CDT) Cc: hackers@freebsd.org, Doug Barton Subject: Re: Updating PCI vendors database X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 21:49:34 -0000 --ztcJpsdPpsnnlAp8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 04, 2011 at 08:30:38PM -0700, Garrett Cooper wrote: > On Mon, Apr 4, 2011 at 11:04 AM, Doug Barton wrote: > > On 04/04/2011 07:10, Philip Paeps wrote: > >> > >> It looks like our /usr/share/misc/pci_vendors list (used only by pcico= nf > >> as > >> far as I can tell) has become rather stale. ?We also appear to be trac= king > >> sources which no longer exist. > >> > >> Would anyone object if I updated this list to source the same database > >> used by > >> Linux distributions at http://pciids.sourceforge.net/v2.2/pci.ids? > >> > >> It helps that our pciconf looks to be compatible with that format. ?We > >> just > >> ignore subvendor and subdevice, but it doesn't appear to matter that t= he > >> file > >> contains this information. > >> > >> I could cull the subvendor/subdevice from the list though. > >> > >> Any views? > > > > Having read this thread, and the last one, my opinion is, let's do it > > already. :) ?Repo churn should not, under any circumstances, be a > > consideration in technical improvements. I agree with those who have sa= id > > that the new list should be confirmed to be a superset of the old, and > > anything missing should be merged in. Checking with Jack about Intel st= uff > > is also reasonable, as would be cross-checking with what NetBSD and Ope= nBSD > > are doing (and perhaps communicating with them about your work). >=20 > 1. People may have automation that depends on this output. This was my only concern about churn in the previous conversation. Given that the lists were using are defunct, we should just move to pci.ids unless someone verifies that a signficant number of devices are missing. If that were to happen I'd just add a local source file to merge into pci.ids and let pci.ids be the master. -- Brooks --ztcJpsdPpsnnlAp8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFNmybXXY6L6fI4GtQRAgFgAJ9pPaFZDwnGGEmCN1+gowjhNDUa/QCdEs0D OqsXbyAsbEcQWBHfWK3lqyM= =3kBI -----END PGP SIGNATURE----- --ztcJpsdPpsnnlAp8-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 6 02:28:13 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03E78106564A for ; Wed, 6 Apr 2011 02:28:13 +0000 (UTC) (envelope-from mrkotfw@gmail.com) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id D53B18FC0A for ; Wed, 6 Apr 2011 02:28:12 +0000 (UTC) Received: by pxi6 with SMTP id 6so956882pxi.17 for ; Tue, 05 Apr 2011 19:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=Zgx1h6Z1Yuz9EiZ4Q5QES9RuaNVErOTpo3PtP3rIEHc=; b=s05kx3WcmZj0lcspn/O+8iMiubrOkMX37OekmfVUavJvCfPoqIjdPEpS5f1LcXjSix 6+GmC3jCXg1oAPwrgqW/sMAMlrhkW6UELr4eON49qrbSFSnHSLd9UtzMYTftdEtShnWQ I2A/VQkOAK4PtVNVMZ05xpZ/hYCseLkffOVzc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=w/QmUJWxkxjRx7ze4UnQEPHp83bVLPzftINX/P7NOJO9e0ypdRCIbVDVBam7MeDW57 YzoSurc9J8lHtfNrYIpzTs4QXnCZoKf/+/BcM7ADwGx1a7M50NgUATp8/ZzWsLAy2oB6 BakyI6fB4bUZiRJ2MlOqRyD2hVE2u5ccJy04s= Received: by 10.142.218.2 with SMTP id q2mr344348wfg.395.1302055244121; Tue, 05 Apr 2011 19:00:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.64.199 with HTTP; Tue, 5 Apr 2011 19:00:24 -0700 (PDT) From: Israel Jacques Date: Tue, 5 Apr 2011 19:00:24 -0700 Message-ID: To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: GSoC: Avoiding syscall overhead X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 02:28:13 -0000 Hello, I have sent a copy to one of the people listed as technical support (atillio@). My name is Israel Jacques and I'm an undergrad at the University of California, Berkeley. I am interested in working on removing overhead from the 'SETPROCTITLE(3)' library routine. I see that in the ideas page work has already begun to make this optimization. However, searching through the mailing lists I have not found much discussion on it. After looking through the archives (see references), I have some (crude) high level ideas as to how to approach the problem. The idea, as suggested is to have a shared page between the kernel and a userland process. Having such a shared page would avoid having to invoke sysctl() which causes a the large overhead of a context switch. The shared page 1. needs to be pinned as to avoid having it be paged out. 2. needs to stay alive for the entire duration of the process. 3. needs to be unique for every process. Initially, I was thinking that a shared page should be created for ALL processes, but that would expose vital information to all other processes. Furthermore, any other process can alter the information of another process. As suggested in [9], allocating memory and reserving some region of the process address space, pinning it, and setting the correct page permissions (permissions in the PTE?) would be enough to create such a shared page. Though, letting the process know of this page would require a system call. Again, suggested in reference [9] would add a section in the ELF which would then have a global variable of (potentially) a pointer to a struct with the process information. Of course, a process could mistakenly use the pointer to access outside the bounds of the page and cause trouble. Furthermore, checks need to be made to insure that the process itself doesn't corrupt the information in the struct. Also, for every access a mutex would be needed as to avoid possible race conditions between both the kernel and the process. I'll be looking to go through: src/sys/vm src/lib/libc/gen/setproctitle.c src/sys/kern/sysv_shm.c ...and the VM portion of the "4.4BSD" book. (I just received my FreeBSD book today!) References: [1] http://lists.freebsd.org/pipermail/freebsd-hackers/2009-October/029750.html [2] http://lists.freebsd.org/pipermail/freebsd-performance/2006-June/002038.html [3] http://lists.freebsd.org/pipermail/freebsd-stable/2006-October/029983.html [4] http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039392.html [5] http://lists.freebsd.org/pipermail/freebsd-performance/2008-January/003107.html [6] http://lists.freebsd.org/pipermail/freebsd-hackers/2008-March/023875.html [7] http://lists.freebsd.org/pipermail/freebsd-hackers/2005-November/014452.html [8] http://lists.freebsd.org/pipermail/freebsd-hackers/2011-February/034419.html [9] http://lists.freebsd.org/pipermail/freebsd-hackers/2005-November/014453.html From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 6 02:51:33 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA635106566B; Wed, 6 Apr 2011 02:51:33 +0000 (UTC) (envelope-from mrkotfw@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8E1E48FC0C; Wed, 6 Apr 2011 02:51:33 +0000 (UTC) Received: by pzk27 with SMTP id 27so498516pzk.13 for ; Tue, 05 Apr 2011 19:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VX9h3Ufle+mm6AOXjQp5a1Ap3iczwIRf7k+MiPgL0UY=; b=MV0w0uF5K7ReH0cbX+7cubP1qyGGggUlrg9/5oDS0E54CIDJufLXVGjrgjv/x9XVHf n/H8JMwwWlHbtgdhWUN56DplK7wth1eu1yZH9EbB4qjFYTdc3ZMRQbvGXs7y6TkTTI8y Hgi8AGsYBWdX7QvQQtvO/w1RmS5Gz/dUcVO7k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=FbAOfAsc1LqbrYD8kY363qRA7OjPhGd7Ds811gFNTc0IwpyTyabqZ9+llhOxqor2l6 QpWgcH5oX508hGpLQzdFZitE+lRTPdefh249uOXS0NYWiDW89pLSTWfeyVEPYVCv0STR Spzv3iWdU/cVklFKI2LCj/TqJctYvG0DWy/FM= Received: by 10.142.218.2 with SMTP id q2mr382600wfg.395.1302058293111; Tue, 05 Apr 2011 19:51:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.64.199 with HTTP; Tue, 5 Apr 2011 19:51:13 -0700 (PDT) In-Reply-To: References: From: Israel Jacques Date: Tue, 5 Apr 2011 19:51:13 -0700 Message-ID: To: Artem Belevich Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC: Avoiding syscall overhead X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 02:51:33 -0000 On Tue, Apr 5, 2011 at 19:43, Artem Belevich wrote: > On Tue, Apr 5, 2011 at 7:00 PM, Israel Jacques wrote: >> I'll be looking to go through: >> src/sys/vm >> src/lib/libc/gen/setproctitle.c >> src/sys/kern/sysv_shm.c >> ...and the VM portion of the "4.4BSD" book. >> (I just received my FreeBSD book today!) > > You may also want to take a look at "Solaris Internals" book. It may > give you some food for thought. > ISBN: 9780131482098 Thank you. Will do. > --Artem > From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 6 03:10:19 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF308106566C for ; Wed, 6 Apr 2011 03:10:19 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 68FDC8FC1A for ; Wed, 6 Apr 2011 03:10:19 +0000 (UTC) Received: by qwc9 with SMTP id 9so685449qwc.13 for ; Tue, 05 Apr 2011 20:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=O69LT/I97k9B+Y0KrrYLqKsvaf4EB6gFJtscGYHUeiY=; b=u9UUKqOjHjk5AANtaWriYPlwH25hyTj/va9XAOyA5+ZBsBvNY81OoIPFwsZ1rBDVfS XZD7/gFEos8Jz/FyYWM53cIvrrJCalX6BLNSsHaQ2X5geeY0b1vPy8NfwRW2IUrHtRim idfLIPy+PV0tI9vJz3jhnQ6XJg3i72hBrJznA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=UHcFo2vE9OrfUBQP1L/igKn3q/FBM8OMJtCJdHknlG7X/cluPaNFbTLbw/HnkW05jZ p3PI7qZhFhugsm9KM+PUG0N2WsN7iu+VOposnxn43fffU7k+DKaYkFd6Zq6mGp4w1b8l yPfjXunlnUJu72G3GL/uu1zscwwMvnoAn6gN8= MIME-Version: 1.0 Received: by 10.229.42.142 with SMTP id s14mr326373qce.174.1302057826825; Tue, 05 Apr 2011 19:43:46 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.229.233.195 with HTTP; Tue, 5 Apr 2011 19:43:46 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Apr 2011 19:43:46 -0700 X-Google-Sender-Auth: 0MsSUHcz68wbC8vbYEvPYA636ro Message-ID: From: Artem Belevich To: Israel Jacques Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC: Avoiding syscall overhead X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 03:10:19 -0000 On Tue, Apr 5, 2011 at 7:00 PM, Israel Jacques wrote: > I'll be looking to go through: > src/sys/vm > src/lib/libc/gen/setproctitle.c > src/sys/kern/sysv_shm.c > ...and the VM portion of the "4.4BSD" book. > (I just received my FreeBSD book today!) You may also want to take a look at "Solaris Internals" book. It may give you some food for thought. ISBN: 9780131482098 --Artem From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 6 11:19:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1DA71065670; Wed, 6 Apr 2011 11:19:57 +0000 (UTC) (envelope-from gnehzuil@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7A08FC12; Wed, 6 Apr 2011 11:19:57 +0000 (UTC) Received: by pvg11 with SMTP id 11so622326pvg.13 for ; Wed, 06 Apr 2011 04:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=idEFUc9tuJLSo3FLRzC/ltakAcMR/QPX/RDfawQagek=; b=o+FVTY/vqyQJQqy/fdrlXMbbfWlTyMm9rXOrgYgi2SFHnNR2luP9cyfSGajbrNl3Es rTKawKx08yLCVJEQzZlDzAP1o6CQcruIBE7iQGDQbu9rYUCdvRGewRaWcrS3tcuN4/LZ NAw11JBrWjciTsaZk6dERfq4oIvkWlMXAqkM4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=wedPfKUD4wm4ERQ9nN2ziEvOCWQefYr8zY8dd8wu59Z54hlaMV83XI1Q41ZdPzY25T BhkiUefhIIwhgh6+UCLsM8r73wlE30gZf7EIArCvofVvBE37/8QEBT78+AEQulyEuMnw VHEIbSm8ba9ksM+LC0k/5jXUW5nbx4x+Bp7SQ= Received: by 10.142.249.34 with SMTP id w34mr789199wfh.301.1302088796824; Wed, 06 Apr 2011 04:19:56 -0700 (PDT) Received: from [192.168.1.247] ([166.111.68.197]) by mx.google.com with ESMTPS id p40sm683963wfc.5.2011.04.06.04.19.53 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 04:19:56 -0700 (PDT) Message-ID: <4D9C4C50.7050106@gmail.com> Date: Wed, 06 Apr 2011 19:19:44 +0800 From: gnehzuil User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ivan Voras References: <372567.37207.qm@web113510.mail.gq1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Pedro F. Giffuni" , freebsd-hackers@freebsd.org Subject: Re: Fw: [gsoc] HTree Directory Index and Journal in ext2fs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 11:19:57 -0000 On 04/06/2011 06:41 PM, Ivan Voras wrote: > >> Zheng meant ext3 metadata-only journalling. I was >> against this sometime ago but the WAPBL paper convinced >> me otherwise, plus the Haiku guys already did it. >> >> http://www.haiku-os.org/blog/jvff/2010-08-05_ext3_journal_implementation > I'm not familiar with Haiku code; is there any chance their > implementation is based on the FreeBSDs, to help porting? Hi, AFAIK, Haiku is an operating system, which is implemented by C++. In Haiku, it supports journal in ext3 file system. So I think maybe it can help me to implement a ext3-compatible journal in FreeBSD. Best regards, lz From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 7 09:13:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A29FB106566B; Thu, 7 Apr 2011 09:13:26 +0000 (UTC) (envelope-from webmaster@kibab.com) Received: from mx0.deglitch.com (cl-414.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:19d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 594C28FC17; Thu, 7 Apr 2011 09:13:26 +0000 (UTC) Received: from zugang.kibab.com (unknown [78.110.54.255]) by mx0.deglitch.com (Postfix) with ESMTPA id C5AC08FC2D; Thu, 7 Apr 2011 13:13:24 +0400 (MSD) Received: from 139.149.1.231 (SquirrelMail authenticated user kibab) by zugang.kibab.com with HTTP; Thu, 7 Apr 2011 13:13:24 +0400 Message-ID: <8f579ecd416ebcd14db4dad6631df74c.squirrel@zugang.kibab.com> Date: Thu, 7 Apr 2011 13:13:24 +0400 From: "Ilya Bakulin" To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: rwatson@freebsd.org Subject: [GSoC] Capsicum application adaptation and core libraries X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 09:13:26 -0000 Hi all, some time ago I've read a paper about Capsicum (it was published at Google reseach papers page). I think that this is an interesting technology, and adopting it for use in FreeBSD base system is worth an effort. Also I see this idea as GSoC suggested idea on Ideas page [1]. So I'd like to take this as a possible GSoC project for this summer. As the task description seems to be very broad, I'd like to be more specific about what is to be done during the summer. As core Capsicum libraries will appear in FreeBSD 9 anyway, I think it's possible to take several applications from the base system and modify them to use Capsicum sandboxes. For example, the FreeBSD syslog daemon might be an interesting application to adapt to compartmentalisation model. Exact list of applications that will be adapted is to be discussed. Primary focus should be, however on "sbin" and "usr.sbin" world parts. Do you think that this work may be useful? [1] http://wiki.freebsd.org/IdeasPage#head-18b374cddb7998946780392a7f7a38848e7be27c -- Regards, Ilya Bakulin http://kibab.com xmpp://kibab612@jabber.ru From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 7 09:31:55 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 936A11065679 for ; Thu, 7 Apr 2011 09:31:55 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 53B6B8FC19 for ; Thu, 7 Apr 2011 09:31:55 +0000 (UTC) Received: from [192.168.2.112] (host86-147-11-178.range86-147.btcentralplus.com [86.147.11.178]) by cyrus.watson.org (Postfix) with ESMTPSA id 0DD2046B35; Thu, 7 Apr 2011 05:31:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" X-Priority: 3 (Normal) In-Reply-To: <8f579ecd416ebcd14db4dad6631df74c.squirrel@zugang.kibab.com> Date: Thu, 7 Apr 2011 10:31:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8f579ecd416ebcd14db4dad6631df74c.squirrel@zugang.kibab.com> To: Ilya Bakulin X-Mailer: Apple Mail (2.1084) Cc: freebsd-hackers@freebsd.org Subject: Re: [GSoC] Capsicum application adaptation and core libraries X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 09:31:55 -0000 On 7 Apr 2011, at 10:13, Ilya Bakulin wrote: > some time ago I've read a paper about Capsicum (it was published at = Google > reseach papers page). I think that this is an interesting technology, = and > adopting it for use in FreeBSD base system is worth an effort. Also I = see > this idea as GSoC suggested idea on Ideas page [1]. >=20 > So I'd like to take this as a possible GSoC project for this summer. = As > the task description seems to be very broad, I'd like to be more = specific > about what is to be done during the summer. >=20 > As core Capsicum libraries will appear in FreeBSD 9 anyway, I think = it's > possible to take several applications from the base system and modify = them > to use Capsicum sandboxes. For example, the FreeBSD syslog daemon = might be > an interesting application to adapt to compartmentalisation model. = Exact > list of applications that will be adapted is to be discussed. Primary > focus should be, however on "sbin" and "usr.sbin" world parts. >=20 > Do you think that this work may be useful? Hi Ilya: I think this sort of project would be great for Google Summer of Code. A = results-oriented effort, which starts with a specific set of system = services or components, and works back into their dependencies (such as = critical libraries, missing Capsicum features, etc) sounds like a good = way to go about it. A key question throughout, needs to be "what is = protected from whom" -- each use of compartmentalisation comes with = performance cost and code complexity, and selecting the most valuable = applications will be a central part of the work. Critical system services, such as syslogd, etc, sound like good places = to begin, as well as nailing down use of Capsicum in dhclient, sshd, = etc, which we've experimented with but haven't yet merged into FreeBSD. = It would also be interesting to apply Capsicum to pipeline components = such as gzcat, grep, sed, nroff (and in the future, and perhaps a better = match, mandoc), so that when components operate on streams and don't = require additional inputs and outputs, they operate entirely in = sandboxes. As will become clear once you dig in, there are some missing things = needed to really round out the Capsicum API. The web page refers largely = to "services" for sandboxes -- as capability mode forbids creating new = network connections, potential services to sandboxes include passing in = pre-connected sockets, files/subtrees based on policy, etc, that might = be expressed somehow: by the application writer during sandbox setup, or = be dynamic in response to changing situations. Another interesting direction to run in might be to start pushing = Capsicum support into higher level applications that desperately need = it: PDF rendering, for example! There's a lot of interesting work to be = done here. However, the remaining proposal period is pretty short -- I'd = encourage you to put together as concrete a proposal as possible -- = necessarily somewhat open-ended, but lay out in moderate detail how = you'd spend the first month: specific policy and security goals, = concrete tasks, elements to change, and what you think the challenges = are, etc. Robert= From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 7 17:25:13 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B92A1065689; Thu, 7 Apr 2011 17:25:13 +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 557978FC0A; Thu, 7 Apr 2011 17:25:10 +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 UAA20232; Thu, 07 Apr 2011 20:25:09 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4D9DF375.4080506@FreeBSD.org> Date: Thu, 07 Apr 2011 20:25:09 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.org, freebsd-fs@FreeBSD.org, FreeBSD Hackers X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: retry mounting with ro when rw fails X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 17:25:13 -0000 [sorry for double post, it should have been "hackers" not "hardware"] Guys, could you please review and comment on the following patch? http://people.freebsd.org/~avg/mount-retry-ro.diff Thank you! The patch consists of two parts. The first part is in CAM/SCSI to make sure that ENODEV is consistently returned to signal that an operation is not supported by a device (in accordance to intro(2)) and specifically to return ENODEV on write attempt to a read-only or write-protected media. Making this change in SCSI should cover real SCSI devices, as well as ATAPI through ahci/siis/atapicam or similar, plus majority (all?) of USB Mass Storage devices. The second part is in vfs_mount code. The idea is to re-try a mount call if we get the ENODEV error, and mounting was not already in read-only mode, and there was no explicit rw or noro option; the second try is changed to ro. I did only basic testing with an SD card in write-protected mode and a USB card-reader. Since I am not very familiar with vfs_mount code I might have missed some important details. A sample test log, just in case: ugen2.2: at usbus2 umass0: on usbus2 da0 at umass-sim0 bus 0 scbus7 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 488MB (1000448 512 byte sectors: 64H 32S/T 488C) da1 at umass-sim0 bus 0 scbus7 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present da2 at umass-sim0 bus 0 scbus7 target 0 lun 2 da2: Removable Direct Access SCSI-0 device da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da3 at umass-sim0 bus 0 scbus7 target 0 lun 3 da3: Removable Direct Access SCSI-0 device da3: 40.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present GEOM: da0s1: EBR has non empty bootcode. (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 0 0 0 0 ea 0 0 8 0 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: DATA PROTECT csi:0,aa,55,61 asc:27,0 (Write protected) field replaceable unit: 1 g_vfs_done():da0s1[WRITE(offset=512, length=4096)]error = 19 (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 0 0 0 0 ea 0 0 8 0 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: DATA PROTECT csi:0,aa,55,61 asc:27,0 (Write protected) field replaceable unit: 1 g_vfs_done():da0s1[WRITE(offset=512, length=4096)]error = 19 vfs_donmount: R/W mount failed, possibly R/O media, falling back to R/O mount -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 7 17:52:05 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C2121065674 for ; Thu, 7 Apr 2011 17:52:05 +0000 (UTC) (envelope-from cronfy@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1B9268FC14 for ; Thu, 7 Apr 2011 17:52:04 +0000 (UTC) Received: by gxk28 with SMTP id 28so1289811gxk.13 for ; Thu, 07 Apr 2011 10:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=glMhzIbYrV3cMlIMudsheGWpHFWFSeVNGWnXXGIoA78=; b=MV8mrIzDwl//VPYgL4VWefp7tP+96c23ZFo5ltkEwrqoBCx/qJ5Qpq7cIqaRwU4YOX g24RhUlGSitCgXv+I9QDAS4CsURL9MfzNcLZ7pvIN9JD1My9hLYK5PskxlMtgdJl3aJL MGuetub52hzfbhBTXdFGJQT3dZQiD/737bH0o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=lUTUtueiYdk+HVMP5qd4KyNGAA/zQlTCkvVdPzjuEQxlpvMZ3JyzbYHjLtT3/DSucG Hg3Q7hFxqqeSV0D0JB8tPo/wkLgRkt1Bf9JNolQ6K5QJg0qDtJ5SbQbNunerF33Xs8u+ fMVyq2gfXp2q8cbB6s0EnOekToz0eJzqY5oxA= Received: by 10.91.126.14 with SMTP id d14mr1048144agn.58.1302197208073; Thu, 07 Apr 2011 10:26:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.67.6 with HTTP; Thu, 7 Apr 2011 10:26:18 -0700 (PDT) From: cronfy Date: Thu, 7 Apr 2011 21:26:18 +0400 Message-ID: To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: call boot(0) from DDB to avoid filesystem corruption X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 17:52:05 -0000 Hello! I am trying to find a way to avoid filesystem corruption after system crashes. I am using FreeBSD 7.3 with DDB enabled. Sometimes system freezes and only DDB (via CTRL-ALT-ESC) is available. Documentation says there is 'call boot(0)' function that performs graceful shutdown from DDB. To test it, I set up fresh install of FreeBSD 7.3 on a new server. Then I started background 'tar -zxf ports.tar.gz' on all partitions: /home, /usr, /var, /tmp and finally /. Waited ~30 seconds and pressed CTRL-ALT-ESC -> call boot(0) -> Enter. Unfortunately, DDB freezed on syncing bufdaemon. I had been waiting for ~5 minutes, but system freezed completely: I could not drop to DDB anymore and keyboard was not working. I had to restart by reset. What can be the reason of this last system freeze? I am using Adaptec controller 3405 with FreeBSD's driver, can it be the cause? I do not know indeed how to ask a good question about this situation because I have no more ideas. Any help would be appreciated! -- cronfy From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 7 20:10:59 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1B3C106564A; Thu, 7 Apr 2011 20:10:59 +0000 (UTC) (envelope-from webmaster@kibab.com) Received: from mx0.deglitch.com (cl-414.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:19d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 404708FC19; Thu, 7 Apr 2011 20:10:59 +0000 (UTC) Received: from kibab-nb.kibab.com (ppp85-140-43-111.pppoe.mtu-net.ru [85.140.43.111]) by mx0.deglitch.com (Postfix) with ESMTPSA id C25858FC2D; Fri, 8 Apr 2011 00:10:57 +0400 (MSD) Message-ID: <4D9E1A5B.5000605@kibab.com> Date: Fri, 08 Apr 2011 00:11:07 +0400 From: Ilya Bakulin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.9) Gecko/20101007 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Robert N. M. Watson" References: <8f579ecd416ebcd14db4dad6631df74c.squirrel@zugang.kibab.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: [GSoC] Capsicum application adaptation and core libraries X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 20:11:00 -0000 On 07.04.2011 13:31, Robert N. M. Watson wrote: > On 7 Apr 2011, at 10:13, Ilya Bakulin wrote: > >> some time ago I've read a paper about Capsicum (it was published at Google >> reseach papers page). I think that this is an interesting technology, and >> adopting it for use in FreeBSD base system is worth an effort. Also I see >> this idea as GSoC suggested idea on Ideas page [1]. >> >> So I'd like to take this as a possible GSoC project for this summer. As >> the task description seems to be very broad, I'd like to be more specific >> about what is to be done during the summer. >> >> As core Capsicum libraries will appear in FreeBSD 9 anyway, I think it's >> possible to take several applications from the base system and modify them >> to use Capsicum sandboxes. For example, the FreeBSD syslog daemon might be >> an interesting application to adapt to compartmentalisation model. Exact >> list of applications that will be adapted is to be discussed. Primary >> focus should be, however on "sbin" and "usr.sbin" world parts. >> >> Do you think that this work may be useful? > Hi Ilya: > > I think this sort of project would be great for Google Summer of Code. A results-oriented effort, which starts with a specific set of system services or components, and works back into their dependencies (such as critical libraries, missing Capsicum features, etc) sounds like a good way to go about it. A key question throughout, needs to be "what is protected from whom" -- each use of compartmentalisation comes with performance cost and code complexity, and selecting the most valuable applications will be a central part of the work. > > Critical system services, such as syslogd, etc, sound like good places to begin, as well as nailing down use of Capsicum in dhclient, sshd, etc, which we've experimented with but haven't yet merged into FreeBSD. It would also be interesting to apply Capsicum to pipeline components such as gzcat, grep, sed, nroff (and in the future, and perhaps a better match, mandoc), so that when components operate on streams and don't require additional inputs and outputs, they operate entirely in sandboxes. > > As will become clear once you dig in, there are some missing things needed to really round out the Capsicum API. The web page refers largely to "services" for sandboxes -- as capability mode forbids creating new network connections, potential services to sandboxes include passing in pre-connected sockets, files/subtrees based on policy, etc, that might be expressed somehow: by the application writer during sandbox setup, or be dynamic in response to changing situations. > > Another interesting direction to run in might be to start pushing Capsicum support into higher level applications that desperately need it: PDF rendering, for example! There's a lot of interesting work to be done here. However, the remaining proposal period is pretty short -- I'd encourage you to put together as concrete a proposal as possible -- necessarily somewhat open-ended, but lay out in moderate detail how you'd spend the first month: specific policy and security goals, concrete tasks, elements to change, and what you think the challenges are, etc. > > Robert > !DSPAM:4d9d84a210433086818784! > > Hi Robert, thank you for your comments. I've posted a project proposal to GSoC website [1]. I've tried to take your suggestions into account. If there are any questions, I'll be happy to answer them. [1] http://socghop.appspot.com/gsoc/proposal/review/google/gsoc2011/kibab/1 -- Regards, Ilya Bakulin http://kibab.com xmpp://kibab612@jabber.ru From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 7 20:20:54 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96A82106566B; Thu, 7 Apr 2011 20:20:54 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 5BF9C8FC15; Thu, 7 Apr 2011 20:20:54 +0000 (UTC) Received: by pxi6 with SMTP id 6so2673149pxi.17 for ; Thu, 07 Apr 2011 13:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JX+fEMf/0gprv0XxszezUm4x3vq6rUMb2kC0B7E8C8o=; b=Hzgbeo2qKBMWoeW/1vZKQfTQ7UTwU+Tqq/kaOHYRuYnPP87vcM36ltak931OBX/Kz/ FYn/KsOa7kg5mlyXYgmlTm/FcLjqWKSRGPlZCav5aKMFbH6hQKc0vA6BpLKtmV611ZeT oxZcueCen43LkNE0fd6sX0KfR7LlDYfttsKvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pwrrDY5AguWvPp5dhR77gMc9VYODZJL3d70dzgqdO5k+7OOaqCfkOqt9e4hkJuz5Yr ISW+fU725NeZKGpfO4wWE4XN/4SUsO+QwyZe64zvFFe7HHPOkiCBtJSn0H9NnmsJzp3S /6n2Mt6F1/5B8YI6RfyKRFLM7Dh5vjOFQ7wtY= MIME-Version: 1.0 Received: by 10.143.39.17 with SMTP id r17mr964391wfj.113.1302207653707; Thu, 07 Apr 2011 13:20:53 -0700 (PDT) Received: by 10.68.42.3 with HTTP; Thu, 7 Apr 2011 13:20:53 -0700 (PDT) In-Reply-To: <4D9DF375.4080506@FreeBSD.org> References: <4D9DF375.4080506@FreeBSD.org> Date: Thu, 7 Apr 2011 13:20:53 -0700 Message-ID: From: Garrett Cooper To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-scsi@freebsd.org, FreeBSD Hackers Subject: Re: retry mounting with ro when rw fails X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 20:20:54 -0000 On Thu, Apr 7, 2011 at 10:25 AM, Andriy Gapon wrote: > > [sorry for double post, it should have been "hackers" not "hardware"] > > Guys, > could you please review and comment on the following patch? > http://people.freebsd.org/~avg/mount-retry-ro.diff > Thank you! > > The patch consists of two parts. > > The first part is in CAM/SCSI to make sure that ENODEV is consistently re= turned to > signal that an operation is not supported by a device (in accordance to i= ntro(2)) > and specifically to return ENODEV on write attempt to a read-only or > write-protected media. =A0Making this change in SCSI should cover real SC= SI devices, > as well as ATAPI through ahci/siis/atapicam or similar, plus majority (al= l?) of > USB Mass Storage devices. > > The second part is in vfs_mount code. =A0The idea is to re-try a mount ca= ll if we > get the ENODEV error, and mounting was not already in read-only mode, and= there > was no explicit rw or noro option; the second try is changed to ro. > > I did only basic testing with an SD card in write-protected mode and a US= B > card-reader. =A0Since I am not very familiar with vfs_mount code I might = have missed > some important details. As a generic question / observation, maybe we should just implement 'errors=3Dremount-ro' (or a reasonable facsimile) like Linux has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or [Open]Solaris sported similar functionality. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 00:13:43 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D6EF1065673 for ; Fri, 8 Apr 2011 00:13:43 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 545E68FC14 for ; Fri, 8 Apr 2011 00:13:43 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta05.emeryville.ca.mail.comcast.net with comcast id Unmr1g0041HpZEsA5o0Ykn; Fri, 08 Apr 2011 00:00:32 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta14.emeryville.ca.mail.comcast.net with comcast id Uo0R1g00s1t3BNj8ao0S19; Fri, 08 Apr 2011 00:00:31 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7AEEB9B422; Thu, 7 Apr 2011 17:00:25 -0700 (PDT) Date: Thu, 7 Apr 2011 17:00:25 -0700 From: Jeremy Chadwick To: Garrett Cooper Message-ID: <20110408000025.GA16252@icarus.home.lan> References: <4D9DF375.4080506@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 08 Apr 2011 01:44:59 +0000 Cc: freebsd-fs@freebsd.org, freebsd-scsi@freebsd.org, Andriy Gapon , FreeBSD Hackers Subject: Re: retry mounting with ro when rw fails X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 00:13:43 -0000 On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote: > On Thu, Apr 7, 2011 at 10:25 AM, Andriy Gapon wrote: > > > > [sorry for double post, it should have been "hackers" not "hardware"] > > > > Guys, > > could you please review and comment on the following patch? > > http://people.freebsd.org/~avg/mount-retry-ro.diff > > Thank you! > > > > The patch consists of two parts. > > > > The first part is in CAM/SCSI to make sure that ENODEV is consistently returned to > > signal that an operation is not supported by a device (in accordance to intro(2)) > > and specifically to return ENODEV on write attempt to a read-only or > > write-protected media. ?Making this change in SCSI should cover real SCSI devices, > > as well as ATAPI through ahci/siis/atapicam or similar, plus majority (all?) of > > USB Mass Storage devices. > > > > The second part is in vfs_mount code. ?The idea is to re-try a mount call if we > > get the ENODEV error, and mounting was not already in read-only mode, and there > > was no explicit rw or noro option; the second try is changed to ro. > > > > I did only basic testing with an SD card in write-protected mode and a USB > > card-reader. ?Since I am not very familiar with vfs_mount code I might have missed > > some important details. > > As a generic question / observation, maybe we should just > implement 'errors=remount-ro' (or a reasonable facsimile) like Linux > has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or > [Open]Solaris sported similar functionality. I was going to recommend exactly this. :-) I like the idea of Andriy's patch, but would feel more comfortable if it were only used if a mount option was specified (-o errors=remount-ro"). Why: Are there any conditions where ENODEV is returned to the underlying vfs layer for things like unexpected hardware issues? I would imagine the latter would be ENXIO, but I'm not certain. An example situation: 1. User inserts USB flash drive/etc. 2. User tries to mount disk R/W manually 3. Weird/bizarre hardware issue happens mid-mount (drive falling off the bus, or maybe even the user yanking the drive right in the middle) -- could this ever return ENODEV? 4. Kernel attempts re-mount, which also fails, or possibly panics due to some underlying condition which nobody predicted 5. User mails mailing list If I'm worrying over nothing, then perfect. :-) My other concern is whether or not this mechanism change could caused some sort of "infinite loop" within devd(8)/devctl(4) where the daemon gets very confused as to what's going on or some automated commands get run when they shouldn't. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 02:16:46 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBAA81065670; Fri, 8 Apr 2011 02:16:45 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 76C1A8FC0A; Fri, 8 Apr 2011 02:16:45 +0000 (UTC) Received: by pwj8 with SMTP id 8so1425939pwj.13 for ; Thu, 07 Apr 2011 19:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kpT/2d4MXnsBu5MHzOKiNh1Wg0A3NsW/hoJOXYlrNoQ=; b=u73BnxZejx0aPjIJuOE2VXYFDjfY7Dl8AIFgcWQfsM8hhrbhZy3cpVEFpp5ouzNZ6e r76WL8aSf7Aou18dceFayW0xpUKF4O0uGP1QvQD/uM/j7Mpd0W5i7dgVUy/4npezERBH ldm/T/Mik9DRue+qNU4cZHhkBBfHBuOa7UjL4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VW8Jc1rPHHqFbpFm5oeR/3x/ep0w9jBF4iAcyJzK+U+Yuegletww0Q/RXvYplNnOmm a/tdWxK7ZZNaOrgifdmnorwot7KEXzKnvDzWsGj2GzMPam9/Sp8w/9vAeBmMzcIdnTUl AoS8HSIk3IWJz95c+MhPI6mooutKPxEQvAGlc= MIME-Version: 1.0 Received: by 10.143.24.39 with SMTP id b39mr1225326wfj.341.1302229004786; Thu, 07 Apr 2011 19:16:44 -0700 (PDT) Received: by 10.68.42.3 with HTTP; Thu, 7 Apr 2011 19:16:44 -0700 (PDT) In-Reply-To: <20110408000025.GA16252@icarus.home.lan> References: <4D9DF375.4080506@FreeBSD.org> <20110408000025.GA16252@icarus.home.lan> Date: Thu, 7 Apr 2011 19:16:44 -0700 Message-ID: From: Garrett Cooper To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-scsi@freebsd.org, Andriy Gapon , FreeBSD Hackers Subject: Re: retry mounting with ro when rw fails X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 02:16:46 -0000 On Thu, Apr 7, 2011 at 5:00 PM, Jeremy Chadwick wrote: > On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote: >> On Thu, Apr 7, 2011 at 10:25 AM, Andriy Gapon wrote: >> > >> > [sorry for double post, it should have been "hackers" not "hardware"] >> > >> > Guys, >> > could you please review and comment on the following patch? >> > http://people.freebsd.org/~avg/mount-retry-ro.diff >> > Thank you! >> > >> > The patch consists of two parts. >> > >> > The first part is in CAM/SCSI to make sure that ENODEV is consistently= returned to >> > signal that an operation is not supported by a device (in accordance t= o intro(2)) >> > and specifically to return ENODEV on write attempt to a read-only or >> > write-protected media. ?Making this change in SCSI should cover real S= CSI devices, >> > as well as ATAPI through ahci/siis/atapicam or similar, plus majority = (all?) of >> > USB Mass Storage devices. >> > >> > The second part is in vfs_mount code. ?The idea is to re-try a mount c= all if we >> > get the ENODEV error, and mounting was not already in read-only mode, = and there >> > was no explicit rw or noro option; the second try is changed to ro. >> > >> > I did only basic testing with an SD card in write-protected mode and a= USB >> > card-reader. ?Since I am not very familiar with vfs_mount code I might= have missed >> > some important details. >> >> =A0 =A0 As a generic question / observation, maybe we should just >> implement 'errors=3Dremount-ro' (or a reasonable facsimile) like Linux >> has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or >> [Open]Solaris sported similar functionality. > > I was going to recommend exactly this. =A0:-) > > I like the idea of Andriy's patch, but would feel more comfortable if it > were only used if a mount option was specified (-o errors=3Dremount-ro"). > Why: > > Are there any conditions where ENODEV is returned to the underlying vfs > layer for things like unexpected hardware issues? =A0I would imagine the > latter would be ENXIO, but I'm not certain. =A0An example situation: > > 1. User inserts USB flash drive/etc. > 2. User tries to mount disk R/W manually > 3. Weird/bizarre hardware issue happens mid-mount (drive falling off > =A0 the bus, or maybe even the user yanking the drive right in the > =A0 middle) -- could this ever return ENODEV? > 4. Kernel attempts re-mount, which also fails, or possibly panics > =A0 due to some underlying condition which nobody predicted > 5. User mails mailing list > > If I'm worrying over nothing, then perfect. =A0:-) =A0My other concern is > whether or not this mechanism change could caused some sort of "infinite > loop" within devd(8)/devctl(4) where the daemon gets very confused as to > what's going on or some automated commands get run when they shouldn't. Yeah. It seems like something else like EINVAL (just an example -- probably a bad one) would be better. Also, please be careful as returning ENODEV seems to be UFS-specific: The following errors can occur for a ufs file system mount: [ENODEV] A component of ufs_args fspec does not exist. Also, Tom Rhodes has a similar change to what I suggested on the backburner, but it hasn't been 100% fleshed out yet. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 11:45:40 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5238B106566B; Fri, 8 Apr 2011 11:45:40 +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 63A218FC1B; Fri, 8 Apr 2011 11:45:38 +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 OAA05250; Fri, 08 Apr 2011 14:45:32 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4D9EF55C.5070300@FreeBSD.org> Date: Fri, 08 Apr 2011 14:45:32 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jeremy Chadwick References: <4D9DF375.4080506@FreeBSD.org> <20110408000025.GA16252@icarus.home.lan> In-Reply-To: <20110408000025.GA16252@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-fs@FreeBSD.org, FreeBSD Hackers Subject: Re: retry mounting with ro when rw fails X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 11:45:40 -0000 on 08/04/2011 03:00 Jeremy Chadwick said the following: > On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote: >> On Thu, Apr 7, 2011 at 10:25 AM, Andriy Gapon wrote: >>> >>> [sorry for double post, it should have been "hackers" not "hardware"] >>> >>> Guys, >>> could you please review and comment on the following patch? >>> http://people.freebsd.org/~avg/mount-retry-ro.diff >>> Thank you! >>> >>> The patch consists of two parts. >>> >>> The first part is in CAM/SCSI to make sure that ENODEV is consistently returned to >>> signal that an operation is not supported by a device (in accordance to intro(2)) >>> and specifically to return ENODEV on write attempt to a read-only or >>> write-protected media. ?Making this change in SCSI should cover real SCSI devices, >>> as well as ATAPI through ahci/siis/atapicam or similar, plus majority (all?) of >>> USB Mass Storage devices. >>> >>> The second part is in vfs_mount code. ?The idea is to re-try a mount call if we >>> get the ENODEV error, and mounting was not already in read-only mode, and there >>> was no explicit rw or noro option; the second try is changed to ro. >>> >>> I did only basic testing with an SD card in write-protected mode and a USB >>> card-reader. ?Since I am not very familiar with vfs_mount code I might have missed >>> some important details. >> >> As a generic question / observation, maybe we should just >> implement 'errors=remount-ro' (or a reasonable facsimile) like Linux >> has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or >> [Open]Solaris sported similar functionality. > > I was going to recommend exactly this. :-) > > I like the idea of Andriy's patch, but would feel more comfortable if it > were only used if a mount option was specified (-o errors=remount-ro"). Having the option is appealing, but my main motivation was the simplicity that comes from having that enabled by default. That is, you absolutely want an R/W mount then use -o rw, you need R/O then explicitly -o ro, you "just want" to get that media mounted then the default behavior tries its best. > Why: > > Are there any conditions where ENODEV is returned to the underlying vfs > layer for things like unexpected hardware issues? I would imagine the > latter would be ENXIO, but I'm not certain. An example situation: > > 1. User inserts USB flash drive/etc. > 2. User tries to mount disk R/W manually > 3. Weird/bizarre hardware issue happens mid-mount (drive falling off > the bus, or maybe even the user yanking the drive right in the > middle) -- could this ever return ENODEV? It shouldn't. If that happens then the underlying layers should be fixed. > 4. Kernel attempts re-mount, which also fails, or possibly panics > due to some underlying condition which nobody predicted > 5. User mails mailing list > > If I'm worrying over nothing, then perfect. :-) My other concern is > whether or not this mechanism change could caused some sort of "infinite > loop" within devd(8)/devctl(4) where the daemon gets very confused as to > what's going on or some automated commands get run when they shouldn't. I can't see how that can happen. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 11:48:36 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E82DB1065676; Fri, 8 Apr 2011 11:48: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 05ED38FC17; Fri, 8 Apr 2011 11:48:35 +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 OAA05282; Fri, 08 Apr 2011 14:48:31 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4D9EF60F.1010704@FreeBSD.org> Date: Fri, 08 Apr 2011 14:48:31 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Garrett Cooper References: <4D9DF375.4080506@FreeBSD.org> <20110408000025.GA16252@icarus.home.lan> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, FreeBSD Hackers , Jeremy Chadwick Subject: Re: retry mounting with ro when rw fails X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 11:48:37 -0000 on 08/04/2011 05:16 Garrett Cooper said the following: > Yeah. It seems like something else like EINVAL (just an example -- > probably a bad one) would be better. Also, please be careful as > returning ENODEV seems to be UFS-specific: I wonder how you arrived at that conclusion. See intro(2) or grep the sources. > > The following errors can occur for a ufs file system mount: > > [ENODEV] A component of ufs_args fspec does not exist. That documented specific use of ENODEV in UFS doesn't make ENODEV UFS-specific. Besides I don't ENODEV anywhere under sys/ufs. > Also, Tom Rhodes has a similar change to what I suggested on the > backburner, but it hasn't been 100% fleshed out yet. I like that approach too. It has its advantages. But I don't give up yet on my suggestion. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 12:11:06 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 250A61065674; Fri, 8 Apr 2011 12:11:06 +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 37B2B8FC15; Fri, 8 Apr 2011 12:11:04 +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 PAA05618; Fri, 08 Apr 2011 15:11:01 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4D9EFB55.1000706@FreeBSD.org> Date: Fri, 08 Apr 2011 15:11:01 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Garrett Cooper References: <4D9DF375.4080506@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, FreeBSD Hackers Subject: Re: retry mounting with ro when rw fails X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 12:11:06 -0000 on 07/04/2011 23:20 Garrett Cooper said the following: > > As a generic question / observation, maybe we should just > implement 'errors=remount-ro' (or a reasonable facsimile) like Linux > has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or > [Open]Solaris sported similar functionality. No problem, I am OK with being first. Then, I only want to deal with media that is "semi-permanently" or permanetly read-only. That's why I handle only failure to mount media as R/W. But from what I read 'errors=remount-ro' in Linux has to do with errors that happen after filesystem is mounted. That is, you mounted a filesystem, you work with it, you get some error (e.g. because of bad blocks), you auto-downgrade the filesystem to readonly. This may be a nice feature, but this is something different from what I proposed. And, AFAIK, Linux does what I propose by default, without any additional options. Google for "block device ... is write-protected, mounting read-only". But yes, it seems that they handle this situation entirely in userland. And I am not against it. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 12:20:23 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E78DE1065673; Fri, 8 Apr 2011 12:20:23 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id 83EBE8FC12; Fri, 8 Apr 2011 12:20:23 +0000 (UTC) Received: from c122-106-155-58.carlnfd1.nsw.optusnet.com.au (c122-106-155-58.carlnfd1.nsw.optusnet.com.au [122.106.155.58]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p38CKJ8w026370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Apr 2011 22:20:20 +1000 Date: Fri, 8 Apr 2011 22:20:19 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andriy Gapon In-Reply-To: <4D9EF55C.5070300@FreeBSD.org> Message-ID: <20110408214920.I1265@besplex.bde.org> References: <4D9DF375.4080506@FreeBSD.org> <20110408000025.GA16252@icarus.home.lan> <4D9EF55C.5070300@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 08 Apr 2011 12:24:45 +0000 Cc: Garrett Cooper , freebsd-fs@freebsd.org, Jeremy Chadwick , FreeBSD Hackers Subject: Re: retry mounting with ro when rw fails X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 12:20:24 -0000 On Fri, 8 Apr 2011, Andriy Gapon wrote: > on 08/04/2011 03:00 Jeremy Chadwick said the following: >> On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote: >>> As a generic question / observation, maybe we should just >>> implement 'errors=remount-ro' (or a reasonable facsimile) like Linux >>> has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or >>> [Open]Solaris sported similar functionality. >> >> I was going to recommend exactly this. :-) >> >> I like the idea of Andriy's patch, but would feel more comfortable if it >> were only used if a mount option was specified (-o errors=remount-ro"). > > Having the option is appealing, but my main motivation was the simplicity that > comes from having that enabled by default. > That is, you absolutely want an R/W mount then use -o rw, you need R/O then > explicitly -o ro, you "just want" to get that media mounted then the default > behavior tries its best. But the default behaviour is backwards, especially for read-mostly removable media. The default should be ro, possibly with an automagic upgrade to rw iff the media really needs to be written too. Writing timestamps for file system and inode access times doesn't count as "really needs to be written to". I think I prefer requiring an explicit upgrade to rw. rw implies writing access times unless you also use noatime, and I wouldn't want noatime to be set automagically depending on whether rw is set explicitly, so I would want noatime to be set explicitly, and once you do that then you can easily set rw or ro at the same time. A new rm (read mostly) or "rwa" (read or write automagically) flag could give automatic upgrade from ro to rw. I'd also like automatic downgrade to ro after a file system has not been written to for some time (this would avoid fscks in most cases for read-mostly file systems. The ro flag should be per-cylinder-group in ffs so that on big disks, most parts are read-only most of the time and don't need to be checked). Bruce From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 12:27:28 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2887C1065670 for ; Fri, 8 Apr 2011 12:27:28 +0000 (UTC) (envelope-from boogie@lazybytes.org) Received: from mail.lazybytes.org (mail.lazybytes.org [195.54.209.3]) by mx1.freebsd.org (Postfix) with ESMTP id D65048FC17 for ; Fri, 8 Apr 2011 12:27:27 +0000 (UTC) Received: from [95.108.170.237] (dhcp170-237-red.yandex.net [95.108.170.237]) by mail.lazybytes.org (Postfix) with ESMTPSA id 65932546 for ; Fri, 8 Apr 2011 16:08:25 +0400 (MSD) Message-ID: <4D9EFAC6.4020906@lazybytes.org> Date: Fri, 08 Apr 2011 16:08:38 +0400 From: Sergey Vinogradov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Lanikai/3.1.9 MIME-Version: 1.0 To: FreeBSD Hackers Content-Type: multipart/mixed; boundary="------------090300000608040101010202" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.lazybytes.org); Fri, 08 Apr 2011 16:08:25 +0400 (MSD) Cc: Subject: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 12:27:28 -0000 This is a multi-part message in MIME format. --------------090300000608040101010202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, hackers. I have a question: why ipv4 netmask is displayed by ifconfig in hex format? Isn't dot-decimal notation more human-readable? Will the attached patch break something in the very bad way? -- wbr, Boo --------------090300000608040101010202 Content-Type: text/plain; name="af_inet.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="af_inet.c.patch" --- af_inet.c.orig 2011-04-07 18:48:28.850931143 +0400 +++ af_inet.c 2011-04-08 11:45:51.556706573 +0400 @@ -79,7 +79,7 @@ sin = (struct sockaddr_in *)ifa->ifa_netmask; if (sin == NULL) sin = &null_sin; - printf("netmask 0x%lx ", (unsigned long)ntohl(sin->sin_addr.s_addr)); + printf("netmask %s ", inet_ntoa(sin->sin_addr)); if (ifa->ifa_flags & IFF_BROADCAST) { sin = (struct sockaddr_in *)ifa->ifa_broadaddr; --------------090300000608040101010202-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 12:37:53 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBBE0106564A; Fri, 8 Apr 2011 12:37:53 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by mx1.freebsd.org (Postfix) with ESMTP id 0AF6F8FC12; Fri, 8 Apr 2011 12:37:45 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ8BmNemoQOOIqPLZBS+qQ7rKwwzsaan@postini.com; Fri, 08 Apr 2011 05:37:53 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 8 Apr 2011 05:34:50 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 8 Apr 2011 08:36:35 -0400 From: Andrew Duane To: Bruce Evans , Andriy Gapon Date: Fri, 8 Apr 2011 08:36:33 -0400 Thread-Topic: retry mounting with ro when rw fails Thread-Index: Acv15/dwjMS1LW5+RZe5mMMKTZtQ9gAAMwHw Message-ID: References: <4D9DF375.4080506@FreeBSD.org> <20110408000025.GA16252@icarus.home.lan> <4D9EF55C.5070300@FreeBSD.org> <20110408214920.I1265@besplex.bde.org> In-Reply-To: <20110408214920.I1265@besplex.bde.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Garrett Cooper , "freebsd-fs@freebsd.org" , FreeBSD, Jeremy Chadwick , Hackers Subject: RE: retry mounting with ro when rw fails X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 12:37:53 -0000 I had been letting this discussion settle a little bit before jumping in, b= ut we've done some work in this area for a few of our platforms. The work w= as rather ham-fisted, but I've been looking for a way to try to get it clea= ned up and back to FreeBSD. Basically, we have a way of detecting that our disk is physically write-pro= tected, a pretty common scenario. Given that, I made some surgical changes = to the mount path to prevent read-write mounts of the disk at all. You can'= t allow that, because even attempts to update the superblock or timestamp w= ill fail and leave buffers outstanding. Over time, this eventually panics t= he system. My implementation simply drops the read-write flag and mounts th= e FS readonly, rather than return a failure (which stopped the startup RC s= cripts). What I was hoping to do was design a better mechanism for passing that R/O = detection from the device to the filesystem code. Our implementation uses a= platform sysctl that checks the incoming device name against some hardware= or software settings. Ick. I don't know enough about device/GEOM calls to = do it better though. =A0................................... Andrew Duane Juniper Networks o=A0=A0=A0+1 978 589 0551 m=A0 +1 603-770-7088 aduane@juniper.net =A0 -----Original Message----- From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd-hackers@freeb= sd.org] On Behalf Of Bruce Evans Sent: Friday, April 08, 2011 8:20 AM To: Andriy Gapon Cc: Garrett Cooper; freebsd-fs@freebsd.org; Jeremy Chadwick; FreeBSD Hacker= s Subject: Re: retry mounting with ro when rw fails On Fri, 8 Apr 2011, Andriy Gapon wrote: > on 08/04/2011 03:00 Jeremy Chadwick said the following: >> On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote: >>> As a generic question / observation, maybe we should just >>> implement 'errors=3Dremount-ro' (or a reasonable facsimile) like Linux >>> has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or >>> [Open]Solaris sported similar functionality. >> >> I was going to recommend exactly this. :-) >> >> I like the idea of Andriy's patch, but would feel more comfortable if it >> were only used if a mount option was specified (-o errors=3Dremount-ro")= . > > Having the option is appealing, but my main motivation was the simplicity= that > comes from having that enabled by default. > That is, you absolutely want an R/W mount then use -o rw, you need R/O th= en > explicitly -o ro, you "just want" to get that media mounted then the defa= ult > behavior tries its best. But the default behaviour is backwards, especially for read-mostly removable media. The default should be ro, possibly with an automagic upgrade to rw iff the media really needs to be written too. Writing timestamps for file system and inode access times doesn't count as "really needs to be written to". I think I prefer requiring an explicit upgrade to rw. rw implies writing access times unless you also use noatime, and I wouldn't want noatime to be set automagically depending on whether rw is set explicitly, so I would want noatime to be set explicitly, and once you do that then you can easily set rw or ro at the same time. A new rm (read mostly) or "rwa" (read or write automagically) flag could give automatic upgrade from ro to rw. I'd also like automatic downgrade to ro after a file system has not been written to for some time (this would avoid fscks in most cases for read-mostly file systems. The ro flag should be per-cylinder-group in ffs so that on big disks, most parts are read-only most of the time and don't need to be checked). Bruce _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 14:43:38 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2333F106567B for ; Fri, 8 Apr 2011 14:43:38 +0000 (UTC) (envelope-from hosting@syscare.sk) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id D25EE8FC1F for ; Fri, 8 Apr 2011 14:43:37 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id 94F8494ED3 for ; Fri, 8 Apr 2011 16:27:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id W2bpjEixNgfh for ; Fri, 8 Apr 2011 16:27:08 +0200 (CEST) Received: from hosting.syscare.sk (hosting [188.40.39.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by services.syscare.sk (Postfix) with ESMTPS id E2E0494EBF for ; Fri, 8 Apr 2011 16:27:08 +0200 (CEST) Received: (from www@localhost) by hosting.syscare.sk (8.14.4/8.14.4/Submit) id p38ER8V1020349; Fri, 8 Apr 2011 16:27:08 +0200 (CEST) (envelope-from hosting@syscare.sk) X-Authentication-Warning: hosting.syscare.sk: www set sender to hosting@syscare.sk using -f To: X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 08 Apr 2011 15:27:08 +0100 From: Daniel Gerzo Organization: The FreeBSD Project In-Reply-To: <4D9EFAC6.4020906@lazybytes.org> References: <4D9EFAC6.4020906@lazybytes.org> Message-ID: <4e8c0b7c62b660d2d309c61ca0d00cf1@rulez.sk> X-Sender: danger@FreeBSD.org User-Agent: Roundcube Webmail/0.5.1 Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 14:43:38 -0000 On Fri, 08 Apr 2011 16:08:38 +0400, Sergey Vinogradov wrote: > Hi, hackers. > I have a question: why ipv4 netmask is displayed by ifconfig in hex > format? Isn't dot-decimal notation more human-readable? Will the > attached patch break something in the very bad way? At least, it may break some scripts. I guess it would be better to add an option to display netmask in a dot-decimal format. -- Kind regards Daniel From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 15:20:51 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44EA51065670; Fri, 8 Apr 2011 15:20:51 +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 5E47C8FC0A; Fri, 8 Apr 2011 15:20:49 +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 SAA07956; Fri, 08 Apr 2011 18:20:35 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4D9F27C3.5030306@FreeBSD.org> Date: Fri, 08 Apr 2011 18:20:35 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Bruce Evans References: <4D9DF375.4080506@FreeBSD.org> <20110408000025.GA16252@icarus.home.lan> <4D9EF55C.5070300@FreeBSD.org> <20110408214920.I1265@besplex.bde.org> In-Reply-To: <20110408214920.I1265@besplex.bde.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, FreeBSD Hackers Subject: Re: retry mounting with ro when rw fails X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 15:20:51 -0000 on 08/04/2011 15:20 Bruce Evans said the following: > But the default behaviour is backwards, especially for read-mostly > removable media. The default should be ro, possibly with an automagic > upgrade to rw iff the media really needs to be written too. Writing > timestamps for file system and inode access times doesn't count as > "really needs to be written to". > > I think I prefer requiring an explicit upgrade to rw. rw implies > writing access times unless you also use noatime, and I wouldn't want > noatime to be set automagically depending on whether rw is set explicitly, > so I would want noatime to be set explicitly, and once you do that > then you can easily set rw or ro at the same time. A new rm (read mostly) > or "rwa" (read or write automagically) flag could give automatic upgrade > from ro to rw. I'd also like automatic downgrade to ro after a file > system has not been written to for some time (this would avoid fscks > in most cases for read-mostly file systems. The ro flag should be > per-cylinder-group in ffs so that on big disks, most parts are read-only > most of the time and don't need to be checked). This is a very good idea, I would like to get that too, but it's a bit more work than the "auto"-mounting. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 15:23:43 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BF8E106567D; Fri, 8 Apr 2011 15:23:43 +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 D9CB08FC16; Fri, 8 Apr 2011 15:23:41 +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 SAA07973; Fri, 08 Apr 2011 18:23:24 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4D9F286B.4010102@FreeBSD.org> Date: Fri, 08 Apr 2011 18:23:23 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Andrew Duane References: <4D9DF375.4080506@FreeBSD.org> <20110408000025.GA16252@icarus.home.lan> <4D9EF55C.5070300@FreeBSD.org> <20110408214920.I1265@besplex.bde.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" , FreeBSD Hackers , Bruce Evans , freebsd-scsi@FreeBSD.org Subject: Re: retry mounting with ro when rw fails X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 15:23:43 -0000 on 08/04/2011 15:36 Andrew Duane said the following: > What I was hoping to do was design a better mechanism for passing that R/O > detection from the device to the filesystem code. Our implementation uses a > platform sysctl that checks the incoming device name against some hardware or > software settings. Ick. I don't know enough about device/GEOM calls to do it > better though. I am actually not aware of any way to inquiry write-protection status from hardware. There are distinct SCSI sense codes for that, but you get them only after a failed write attempt. But there are many things that I don't know about... -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 15:27:23 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83CBD1065670 for ; Fri, 8 Apr 2011 15:27:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4686E8FC17 for ; Fri, 8 Apr 2011 15:27:23 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p38FN5Cn029903 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 8 Apr 2011 09:23:06 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4D9EFAC6.4020906@lazybytes.org> Date: Fri, 8 Apr 2011 09:23:05 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7EA5889E-77EF-4BAE-9655-C33692A75602@bsdimp.com> References: <4D9EFAC6.4020906@lazybytes.org> To: Sergey Vinogradov X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Fri, 08 Apr 2011 09:23:06 -0600 (MDT) Cc: FreeBSD Hackers Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 15:27:23 -0000 On Apr 8, 2011, at 6:08 AM, Sergey Vinogradov wrote: > Hi, hackers. > I have a question: why ipv4 netmask is displayed by ifconfig in hex = format? Isn't dot-decimal notation more human-readable? Will the = attached patch break something in the very bad way? This is a gratuitous change that would break scripts. Hex has been used = for a very long time, and most people know how to cope. If we really wanted to make it human readable, we'd output 10.2.3.4/24 Warner From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 15:36:32 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 368B71065670 for ; Fri, 8 Apr 2011 15:36:32 +0000 (UTC) (envelope-from boogie@lazybytes.org) Received: from mail.lazybytes.org (mail.lazybytes.org [195.54.209.3]) by mx1.freebsd.org (Postfix) with ESMTP id E6A388FC14 for ; Fri, 8 Apr 2011 15:36:31 +0000 (UTC) Received: from [95.108.170.237] (dhcp170-237-red.yandex.net [95.108.170.237]) by mail.lazybytes.org (Postfix) with ESMTPSA id DF1688FD; Fri, 8 Apr 2011 19:36:30 +0400 (MSD) Message-ID: <4D9F2B8D.3040104@lazybytes.org> Date: Fri, 08 Apr 2011 19:36:45 +0400 From: Sergey Vinogradov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Lanikai/3.1.9 MIME-Version: 1.0 To: Mike Oliver References: <4D9EFAC6.4020906@lazybytes.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.lazybytes.org); Fri, 08 Apr 2011 19:36:30 +0400 (MSD) Cc: FreeBSD Hackers Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 15:36:32 -0000 On 08.04.2011 19:23, Mike Oliver wrote: > On Fri, Apr 8, 2011 at 08:08, Sergey Vinogradov wrote: >> Hi, hackers. >> I have a question: why ipv4 netmask is displayed by ifconfig in hex format? >> Isn't dot-decimal notation more human-readable? Will the attached patch >> break something in the very bad way? > > Who's using IPv4 anymore? ;-) Long live IPv4! :) > Seriously though, if you give a small amount of time to learning the > hex -> binary translations then you would see how convenient it is to > use hex rather than decimal when representing what are ultimately > binary numbers. > > See this blog entry by Jeff Doyle... > > http://www.networkworld.com/community/blog/how-are-your-hexadecimal-skills The article is great, but dot-decimal notation is de-facto standard for stand-alone network mask representation. Like CIDR is standard for IP blocks represenation. That's the reason I've started this thread. And despite the greatness of the article you've mentioned, I think it's a bad itea to hardcode its URL into ifconfig's output. You know, for every single user reading it, and choosing the "way of hex" ;) -- wbr, Boo From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 15:40:43 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF2211065672 for ; Fri, 8 Apr 2011 15:40:43 +0000 (UTC) (envelope-from boogie@lazybytes.org) Received: from mail.lazybytes.org (mail.lazybytes.org [195.54.209.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9A6B08FC13 for ; Fri, 8 Apr 2011 15:40:43 +0000 (UTC) Received: from [95.108.170.237] (dhcp170-237-red.yandex.net [95.108.170.237]) by mail.lazybytes.org (Postfix) with ESMTPSA id 81981912; Fri, 8 Apr 2011 19:40:42 +0400 (MSD) Message-ID: <4D9F2C88.4010205@lazybytes.org> Date: Fri, 08 Apr 2011 19:40:56 +0400 From: Sergey Vinogradov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Lanikai/3.1.9 MIME-Version: 1.0 To: Warner Losh References: <4D9EFAC6.4020906@lazybytes.org> <7EA5889E-77EF-4BAE-9655-C33692A75602@bsdimp.com> In-Reply-To: <7EA5889E-77EF-4BAE-9655-C33692A75602@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.lazybytes.org); Fri, 08 Apr 2011 19:40:42 +0400 (MSD) Cc: FreeBSD Hackers Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 15:40:44 -0000 On 08.04.2011 19:23, Warner Losh wrote: > > On Apr 8, 2011, at 6:08 AM, Sergey Vinogradov wrote: > >> Hi, hackers. >> I have a question: why ipv4 netmask is displayed by ifconfig in hex format? Isn't dot-decimal notation more human-readable? Will the attached patch break something in the very bad way? > > This is a gratuitous change that would break scripts. Hex has been used for a very long time, and most people know how to cope. > > If we really wanted to make it human readable, we'd output 10.2.3.4/24 > > Warner So, maybe, while following the POLA, we should add an option, as Daniel mentioned above? To output the CIDR? -- wbr, Boo From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 15:52:16 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DD9F1065670 for ; Fri, 8 Apr 2011 15:52:16 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2F24C8FC1B for ; Fri, 8 Apr 2011 15:52:15 +0000 (UTC) Received: by wwc33 with SMTP id 33so4225797wwc.31 for ; Fri, 08 Apr 2011 08:52:15 -0700 (PDT) Received: by 10.227.59.210 with SMTP id m18mr2358784wbh.112.1302277935144; Fri, 08 Apr 2011 08:52:15 -0700 (PDT) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id z13sm1790708wbd.12.2011.04.08.08.52.13 (version=SSLv3 cipher=OTHER); Fri, 08 Apr 2011 08:52:14 -0700 (PDT) Message-ID: <4D9F2F2C.2060602@my.gd> Date: Fri, 08 Apr 2011 17:52:12 +0200 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4D9EFAC6.4020906@lazybytes.org> <7EA5889E-77EF-4BAE-9655-C33692A75602@bsdimp.com> <4D9F2C88.4010205@lazybytes.org> In-Reply-To: <4D9F2C88.4010205@lazybytes.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 15:52:16 -0000 On 4/8/11 5:40 PM, Sergey Vinogradov wrote: > On 08.04.2011 19:23, Warner Losh wrote: >> >> On Apr 8, 2011, at 6:08 AM, Sergey Vinogradov wrote: >> >>> Hi, hackers. >>> I have a question: why ipv4 netmask is displayed by ifconfig in hex >>> format? Isn't dot-decimal notation more human-readable? Will the >>> attached patch break something in the very bad way? >> >> This is a gratuitous change that would break scripts. Hex has been >> used for a very long time, and most people know how to cope. >> >> If we really wanted to make it human readable, we'd output 10.2.3.4/24 >> >> Warner > So, maybe, while following the POLA, we should add an option, as Daniel > mentioned above? To output the CIDR? > Seconded :) From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 15:53:10 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1D7B1065679 for ; Fri, 8 Apr 2011 15:53:10 +0000 (UTC) (envelope-from mwoliver@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6B83B8FC19 for ; Fri, 8 Apr 2011 15:53:10 +0000 (UTC) Received: by vxc34 with SMTP id 34so3477933vxc.13 for ; Fri, 08 Apr 2011 08:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YQmER1rgWHDIgbpDh8qZ06uy8hbGYqksVYdDVhWL6DY=; b=IbuWB6MfprNZu8541p6WBGNDYPrx0f/bdcOsBYerFzGAYkggdUq2qNssYxGdd1oA1T 0iFCvRQiIQdlh4T9SGYN0wYtlyC3KGpdYfqJjrhmLkTVwbh6ozfDVxy+hbNImoFq2VST PcAYMmTWcE/PQkuSEVGNRuYDT6khvRShNM950= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NSqfrTVOaw7kEU/jdTSlmCDqvYQlf1BoXki5e7LUj2X1LkXUlizG3ppIQhFEFDThwI Pp+wQ2NmkQ2yFj0YAuXpQA5SPqKKZFrOaPPUzpCzqMPlbMFTa6THEe1W6YaBLDHSybEQ gFDjWmMIXuNKIWbehky0knqVLZkF12g3gwOKc= MIME-Version: 1.0 Received: by 10.52.179.3 with SMTP id dc3mr3273465vdc.157.1302276239624; Fri, 08 Apr 2011 08:23:59 -0700 (PDT) Received: by 10.220.45.76 with HTTP; Fri, 8 Apr 2011 08:23:59 -0700 (PDT) In-Reply-To: <4D9EFAC6.4020906@lazybytes.org> References: <4D9EFAC6.4020906@lazybytes.org> Date: Fri, 8 Apr 2011 11:23:59 -0400 Message-ID: From: Mike Oliver To: Sergey Vinogradov Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Hackers Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 15:53:10 -0000 On Fri, Apr 8, 2011 at 08:08, Sergey Vinogradov wrote: > Hi, hackers. > I have a question: why ipv4 netmask is displayed by ifconfig in hex format? > Isn't dot-decimal notation more human-readable? Will the attached patch > break something in the very bad way? Who's using IPv4 anymore? ;-) Seriously though, if you give a small amount of time to learning the hex -> binary translations then you would see how convenient it is to use hex rather than decimal when representing what are ultimately binary numbers. See this blog entry by Jeff Doyle... http://www.networkworld.com/community/blog/how-are-your-hexadecimal-skills -- Mike Oliver, KT2T +1-863-738-2334 kt2t@arrl.net -or- mwoliver@gmail.com Twitter: @mwoliver From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 15:53:16 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCDF91065670 for ; Fri, 8 Apr 2011 15:53:16 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id B22768FC13 for ; Fri, 8 Apr 2011 15:53:16 +0000 (UTC) Received: by pvg11 with SMTP id 11so1669901pvg.13 for ; Fri, 08 Apr 2011 08:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LH9eo6+sP13H5M9aVYM0XKv+FsOeTsZ1GKcvXOn40k0=; b=scOYVRMWH/QD5es5xOvpWZa/jTIqPeqqMMtNQw5iAckqcvpPJ0AS9Dh3blff57VREf wDZtDgglV4IjFA1V0+IJww7VdGIL77bY2hzLM3tf+ahKNTcQpU5EgtBaerGYobPNmM09 dEf1AaHCMB5DqypMriUbzgweZYbM+7ZNL6PYM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Cs6piRQ/WNADLuerSV1OsEbK/uNx5G/+wut+XQi2t2LsUtn2JHw9Q4eQ1IuAq2n9Yj 08mxAcj/2JOJQHmAbFI5UikGX7sPFp7VhxFy6+6x+lFRSU/KPaqs9phKIgGVMCJOHQ7k YbBnrtcakquPxwXrB7MFLpONxcalqVxuLbNAw= MIME-Version: 1.0 Received: by 10.142.248.21 with SMTP id v21mr1905515wfh.56.1302277996107; Fri, 08 Apr 2011 08:53:16 -0700 (PDT) Received: by 10.68.42.3 with HTTP; Fri, 8 Apr 2011 08:53:16 -0700 (PDT) In-Reply-To: <4D9F2C88.4010205@lazybytes.org> References: <4D9EFAC6.4020906@lazybytes.org> <7EA5889E-77EF-4BAE-9655-C33692A75602@bsdimp.com> <4D9F2C88.4010205@lazybytes.org> Date: Fri, 8 Apr 2011 08:53:16 -0700 Message-ID: From: Garrett Cooper To: Sergey Vinogradov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 15:53:16 -0000 On Fri, Apr 8, 2011 at 8:40 AM, Sergey Vinogradov wr= ote: > On 08.04.2011 19:23, Warner Losh wrote: >> >> On Apr 8, 2011, at 6:08 AM, Sergey Vinogradov wrote: >> >>> Hi, hackers. >>> I have a question: why ipv4 netmask is displayed by ifconfig in hex >>> format? Isn't dot-decimal notation more human-readable? Will the attach= ed >>> patch break something in the very bad way? >> >> This is a gratuitous change that would break scripts. =A0Hex has been us= ed >> for a very long time, and most people know how to cope. >> >> If we really wanted to make it human readable, we'd output 10.2.3.4/24 Except that developers have to resort to jumping through a few hoops to get things printed out in a format to pass into other commands that expect a dot-decimal format. One thing I've been curious about for a while that I haven't had an opportunity to look into is: what does IPV6 look like? I understand that the /netmask bit is added to the end of addresses, but what does the netmask actually look like? > So, maybe, while following the POLA, we should add an option, as Daniel > mentioned above? To output the CIDR? Eh... I don't know if doing this would be wise because it might break some 3rd party mechanisms for parsing the output (as broken as you might think it is), in particular (for example) because people can alias the ifconfig command to something else. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 16:06:15 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF057106564A for ; Fri, 8 Apr 2011 16:06:15 +0000 (UTC) (envelope-from mike@urgle.com) Received: from anchor-post-1.mail.demon.net (anchor-post-1.mail.demon.net [195.173.77.132]) by mx1.freebsd.org (Postfix) with ESMTP id 78C678FC08 for ; Fri, 8 Apr 2011 16:06:15 +0000 (UTC) Received: from cheddar.urgle.com ([80.177.40.53]) by anchor-post-1.mail.demon.net with esmtp (Exim 4.69) id 1Q8E1p-0004CE-gU; Fri, 08 Apr 2011 15:55:21 +0000 Received: from mike by cheddar.urgle.com with local (Exim 4.75 (FreeBSD)) (envelope-from ) id 1Q8E1o-000Aca-C1; Fri, 08 Apr 2011 15:55:20 +0000 Date: Fri, 8 Apr 2011 16:55:20 +0100 From: Mike Bristow To: Sergey Vinogradov Message-ID: <20110408155520.GA40792@cheddar.urgle.com> References: <4D9EFAC6.4020906@lazybytes.org> <7EA5889E-77EF-4BAE-9655-C33692A75602@bsdimp.com> <4D9F2C88.4010205@lazybytes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D9F2C88.4010205@lazybytes.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Hackers Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 16:06:15 -0000 On Fri, Apr 08, 2011 at 07:40:56PM +0400, Sergey Vinogradov wrote: > On 08.04.2011 19:23, Warner Losh wrote: > > On Apr 8, 2011, at 6:08 AM, Sergey Vinogradov wrote: > > If we really wanted to make it human readable, we'd output 10.2.3.4/24 > > So, maybe, while following the POLA, we should add an option, as Daniel > mentioned above? To output the CIDR? Non-contigous netmasks are legal in IPv4. What do you do if someone adds the CIDR flag but the netmask cannot be represented in CIDR notation? Cheers, Mike -- Mike Bristow mike@urgle.com From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 16:29:18 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AEF1106566B for ; Fri, 8 Apr 2011 16:29:18 +0000 (UTC) (envelope-from mwoliver@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 575728FC0C for ; Fri, 8 Apr 2011 16:29:17 +0000 (UTC) Received: by vws18 with SMTP id 18so3483871vws.13 for ; Fri, 08 Apr 2011 09:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HU6XKit3A54EueK05Na/9auxpBAZ8jOf1s43hQdQQRw=; b=pZpsyUyp7UnUEVNgzcucRtefOrrhSsze+HQH0KzohXrrGebimD4iYramd94RE7julu f/DZ5rBME+kHrrtUQBzRMJSvk/6O6FU/725ZuBHCvg6tUNwQTc0d4tYWbGtG4gsUwZX9 UgH1ot4T1czwFuivlnfuRB6DqcEGE0iQ389I8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nqKMwJIKWh1kO9lmjf9mmTXM/nFkVtEUpvYCXJPv4OeknfHU3wfksgDgzi7k0hGYrm qb93LEADZ6kjX65tTFiJ3NI/YUoSbHJG6cMse3bhLwRMRoMyXK3mNd38OFuwG8iGMd5A xfPlffedpoJkqP/hGF4NgCPKIFgLQcMRS6hS8= MIME-Version: 1.0 Received: by 10.52.69.169 with SMTP id f9mr3481740vdu.117.1302280156922; Fri, 08 Apr 2011 09:29:16 -0700 (PDT) Received: by 10.220.45.76 with HTTP; Fri, 8 Apr 2011 09:29:16 -0700 (PDT) In-Reply-To: References: <4D9EFAC6.4020906@lazybytes.org> <7EA5889E-77EF-4BAE-9655-C33692A75602@bsdimp.com> <4D9F2C88.4010205@lazybytes.org> Date: Fri, 8 Apr 2011 12:29:16 -0400 Message-ID: From: Mike Oliver To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Hackers , Sergey Vinogradov Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 16:29:18 -0000 On Fri, Apr 8, 2011 at 11:53, Garrett Cooper wrote: > > One thing I've been curious about for a while that I haven't had an > opportunity to look into is: what does IPV6 look like? I understand > that the /netmask bit is added to the end of addresses, but what does > the netmask actually look like? http://testmyipv6.com/ipv6_subnet_calc.html -- Mike Oliver, KT2T +1-863-738-2334 kt2t@arrl.net -or- mwoliver@gmail.com Twitter: @mwoliver From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 16:47:20 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F3E7106568A; Fri, 8 Apr 2011 16:47:20 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by mx1.freebsd.org (Postfix) with ESMTP id C8D278FC16; Fri, 8 Apr 2011 16:47:13 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ88EFo/4nuoeLgyiOrLkJ9ea9lbxtpc@postini.com; Fri, 08 Apr 2011 09:47:19 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 8 Apr 2011 09:43:39 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 8 Apr 2011 12:45:24 -0400 From: Andrew Duane To: Andriy Gapon Date: Fri, 8 Apr 2011 12:45:23 -0400 Thread-Topic: retry mounting with ro when rw fails Thread-Index: Acv2AO1qThMsSukkTE2FDMO0vOVbogAC01og Message-ID: References: <4D9DF375.4080506@FreeBSD.org> <20110408000025.GA16252@icarus.home.lan> <4D9EF55C.5070300@FreeBSD.org> <20110408214920.I1265@besplex.bde.org> <4D9F286B.4010102@FreeBSD.org> In-Reply-To: <4D9F286B.4010102@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-fs@freebsd.org" , FreeBSD Hackers , Bruce Evans , "freebsd-scsi@FreeBSD.org" Subject: RE: retry mounting with ro when rw fails X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 16:47:20 -0000 For SCSI-attached disks, yes. But other hardware has write-protect sensing = (SD cards, CD-roms, our platform). So if you can do that, you should Cleaning up after a failed write is a real problem, one that I needed to av= oid.=20 /Andrew =20 -----Original Message----- From: Andriy Gapon [mailto:avg@FreeBSD.org]=20 Sent: Friday, April 08, 2011 11:23 AM To: Andrew Duane Cc: Bruce Evans; freebsd-fs@freebsd.org; FreeBSD Hackers; freebsd-scsi@Free= BSD.org Subject: Re: retry mounting with ro when rw fails on 08/04/2011 15:36 Andrew Duane said the following: > What I was hoping to do was design a better mechanism for passing that R/= O > detection from the device to the filesystem code. Our implementation uses= a > platform sysctl that checks the incoming device name against some hardwar= e or > software settings. Ick. I don't know enough about device/GEOM calls to do= it > better though. I am actually not aware of any way to inquiry write-protection status from hardware. There are distinct SCSI sense codes for that, but you get them o= nly after a failed write attempt. But there are many things that I don't know about... --=20 Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 17:47:28 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EFA5106564A for ; Fri, 8 Apr 2011 17:47:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id F0AEF8FC0A for ; Fri, 8 Apr 2011 17:47:27 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p38HhMjc031230 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 8 Apr 2011 11:43:24 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20110408155520.GA40792@cheddar.urgle.com> Date: Fri, 8 Apr 2011 11:43:16 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: <4D9EFAC6.4020906@lazybytes.org> <7EA5889E-77EF-4BAE-9655-C33692A75602@bsdimp.com> <4D9F2C88.4010205@lazybytes.org> <20110408155520.GA40792@cheddar.urgle.com> To: Mike Bristow X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Fri, 08 Apr 2011 11:43:24 -0600 (MDT) Cc: FreeBSD Hackers , Sergey Vinogradov Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 17:47:28 -0000 On Apr 8, 2011, at 9:55 AM, Mike Bristow wrote: > On Fri, Apr 08, 2011 at 07:40:56PM +0400, Sergey Vinogradov wrote: >> On 08.04.2011 19:23, Warner Losh wrote: >>> On Apr 8, 2011, at 6:08 AM, Sergey Vinogradov wrote: >>> If we really wanted to make it human readable, we'd output 10.2.3.4/24 >> >> So, maybe, while following the POLA, we should add an option, as Daniel >> mentioned above? To output the CIDR? > > Non-contigous netmasks are legal in IPv4. What do you do if someone adds > the CIDR flag but the netmask cannot be represented in CIDR notation? They have become illegal in the fullness of time. Warner From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 18:57:37 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20C42106566B for ; Fri, 8 Apr 2011 18:57:37 +0000 (UTC) (envelope-from boogie@lazybytes.org) Received: from mail.lazybytes.org (mail.lazybytes.org [195.54.209.3]) by mx1.freebsd.org (Postfix) with ESMTP id CC0238FC13 for ; Fri, 8 Apr 2011 18:57:35 +0000 (UTC) Received: from [192.168.13.4] (unknown [192.168.13.4]) by mail.lazybytes.org (Postfix) with ESMTPSA id E597EC69; Fri, 8 Apr 2011 22:57:33 +0400 (MSD) Message-ID: <4D9F5A96.6040501@lazybytes.org> Date: Fri, 08 Apr 2011 22:57:26 +0400 From: Sergey Vinogradov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Garrett Cooper References: <4D9EFAC6.4020906@lazybytes.org> <7EA5889E-77EF-4BAE-9655-C33692A75602@bsdimp.com> <4D9F2C88.4010205@lazybytes.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.lazybytes.org); Fri, 08 Apr 2011 22:57:34 +0400 (MSD) Cc: FreeBSD Hackers Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 18:57:37 -0000 [snip] >> So, maybe, while following the POLA, we should add an option, as Daniel >> mentioned above? To output the CIDR? > > Eh... I don't know if doing this would be wise because it might break > some 3rd party mechanisms for parsing the output (as broken as you > might think it is), in particular (for example) because people can > alias the ifconfig command to something else. If we'll introduce such ifconfig option (i.e. ifconfig -c) nothing is going to break: ifconfig's default behavior won't change, and people, who will alias `ifconfig' to `ifconfig -c' are their own enemies. User should think about consequences of such actions. -- wbr, Boo From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 19:00:10 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B4601065672 for ; Fri, 8 Apr 2011 19:00:10 +0000 (UTC) (envelope-from boogie@lazybytes.org) Received: from mail.lazybytes.org (mail.lazybytes.org [195.54.209.3]) by mx1.freebsd.org (Postfix) with ESMTP id D837B8FC12 for ; Fri, 8 Apr 2011 19:00:09 +0000 (UTC) Received: from [192.168.13.4] (unknown [192.168.13.4]) by mail.lazybytes.org (Postfix) with ESMTPSA id C96E2C7A; Fri, 8 Apr 2011 23:00:08 +0400 (MSD) Message-ID: <4D9F5B31.9000509@lazybytes.org> Date: Fri, 08 Apr 2011 23:00:01 +0400 From: Sergey Vinogradov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Mike Bristow References: <4D9EFAC6.4020906@lazybytes.org> <7EA5889E-77EF-4BAE-9655-C33692A75602@bsdimp.com> <4D9F2C88.4010205@lazybytes.org> <20110408155520.GA40792@cheddar.urgle.com> In-Reply-To: <20110408155520.GA40792@cheddar.urgle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.lazybytes.org); Fri, 08 Apr 2011 23:00:08 +0400 (MSD) Cc: FreeBSD Hackers Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 19:00:10 -0000 08.04.2011 19:55, Mike Bristow пишет: > On Fri, Apr 08, 2011 at 07:40:56PM +0400, Sergey Vinogradov wrote: >> On 08.04.2011 19:23, Warner Losh wrote: >>> On Apr 8, 2011, at 6:08 AM, Sergey Vinogradov wrote: >>> If we really wanted to make it human readable, we'd output 10.2.3.4/24 >> >> So, maybe, while following the POLA, we should add an option, as Daniel >> mentioned above? To output the CIDR? > > Non-contigous netmasks are legal in IPv4. What do you do if someone adds > the CIDR flag but the netmask cannot be represented in CIDR notation? > > Cheers, > Mike And boom goes the dynamite. Reverting to my first proposal about changing only netmask notation. -- wbr, Boo From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 19:20:15 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ED621065673 for ; Fri, 8 Apr 2011 19:20:15 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id CCBD08FC0C for ; Fri, 8 Apr 2011 19:20:14 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p38JGNBd031964 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 8 Apr 2011 13:16:24 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=utf-8 From: Warner Losh In-Reply-To: <4D9F5B31.9000509@lazybytes.org> Date: Fri, 8 Apr 2011 13:16:17 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8B793E28-0426-46CC-AB10-E0257AF6707D@bsdimp.com> References: <4D9EFAC6.4020906@lazybytes.org> <7EA5889E-77EF-4BAE-9655-C33692A75602@bsdimp.com> <4D9F2C88.4010205@lazybytes.org> <20110408155520.GA40792@cheddar.urgle.com> <4D9F5B31.9000509@lazybytes.org> To: Sergey Vinogradov X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Fri, 08 Apr 2011 13:16:25 -0600 (MDT) Cc: FreeBSD Hackers Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 19:20:15 -0000 On Apr 8, 2011, at 1:00 PM, Sergey Vinogradov wrote: > 08.04.2011 19:55, Mike Bristow =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> On Fri, Apr 08, 2011 at 07:40:56PM +0400, Sergey Vinogradov wrote: >>> On 08.04.2011 19:23, Warner Losh wrote: >>>> On Apr 8, 2011, at 6:08 AM, Sergey Vinogradov wrote: >>>> If we really wanted to make it human readable, we'd output = 10.2.3.4/24 >>>=20 >>> So, maybe, while following the POLA, we should add an option, as = Daniel >>> mentioned above? To output the CIDR? >>=20 >> Non-contigous netmasks are legal in IPv4. What do you do if someone = adds >> the CIDR flag but the netmask cannot be represented in CIDR notation? >=20 > And boom goes the dynamite. Reverting to my first proposal about = changing only netmask notation. Non-contiguous netmasks are *not* legal anymore in IPv4. They have gone = the way of the dodo. While some stacks still support it, a growing = number of an interesting number of bugs with them that actual = deployments with non-contiguous submasks becomes more hassle than it is = worth. Warner From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 20:22:48 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FBFB106566B for ; Fri, 8 Apr 2011 20:22:48 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (unknown [IPv6:2001:7b8:30f:e0::5059:ee8a]) by mx1.freebsd.org (Postfix) with ESMTP id 4F12B8FC13 for ; Fri, 8 Apr 2011 20:22:48 +0000 (UTC) Received: from mx1.psconsult.nl (psc11.adsl.iaf.nl [80.89.238.138]) by mx1.psconsult.nl (8.14.4/8.14.4) with ESMTP id p38KMg9q031408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Apr 2011 22:22:47 +0200 (CEST) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.4/8.14.4/Submit) id p38KMgBn031407 for freebsd-hackers@freebsd.org; Fri, 8 Apr 2011 22:22:42 +0200 (CEST) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Fri, 8 Apr 2011 22:22:42 +0200 From: Paul Schenkeveld To: freebsd-hackers@freebsd.org Message-ID: <20110408202241.GA31041@psconsult.nl> References: <4D9EFAC6.4020906@lazybytes.org> <7EA5889E-77EF-4BAE-9655-C33692A75602@bsdimp.com> <4D9F2C88.4010205@lazybytes.org> <20110408155520.GA40792@cheddar.urgle.com> <4D9F5B31.9000509@lazybytes.org> <8B793E28-0426-46CC-AB10-E0257AF6707D@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8B793E28-0426-46CC-AB10-E0257AF6707D@bsdimp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 20:22:48 -0000 On Fri, Apr 08, 2011 at 01:16:17PM -0600, Warner Losh wrote: > > On Apr 8, 2011, at 1:00 PM, Sergey Vinogradov wrote: > > > 08.04.2011 19:55, Mike Bristow пишет: > >> On Fri, Apr 08, 2011 at 07:40:56PM +0400, Sergey Vinogradov wrote: > >>> On 08.04.2011 19:23, Warner Losh wrote: > >>>> On Apr 8, 2011, at 6:08 AM, Sergey Vinogradov wrote: > >>>> If we really wanted to make it human readable, we'd output 10.2.3.4/24 > >>> > >>> So, maybe, while following the POLA, we should add an option, as Daniel > >>> mentioned above? To output the CIDR? > >> > >> Non-contigous netmasks are legal in IPv4. What do you do if someone adds > >> the CIDR flag but the netmask cannot be represented in CIDR notation? > > > > And boom goes the dynamite. Reverting to my first proposal about changing only netmask notation. > > Non-contiguous netmasks are *not* legal anymore in IPv4. They have gone the way of the dodo. While some stacks still support it, a growing number of an interesting number of bugs with them that actual deployments with non-contiguous submasks becomes more hassle than it is worth. Although non-contiguous netmasks are not legal anymore in IPv4, our ifconfig still allows to do something like: # ifconfig em0 inet 10.0.5.2 netmask 255.0.255.0 # ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=219b ether xx:xx:xx:xx:xx:xx inet 10.0.5.2 netmask 0xff00ff00 broadcast 10.255.5.255 media: Ethernet autoselect (1000baseT ) status: active If we allow ifconfig to set non-contiguous netmasks, it cannot be output in CIDR notation. Perhaps a compromise could be: -t Prefer dotted decimal over hex. -c If the netmask is contiguous, print it in CIDR, otherwise in hex (without -d) or dotted decimal (with -d). -d is already in use, hence -t although -D is also available. Does this make everyone happy? > Warner Paul Schenkeveld From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 22:16:54 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87873106566B for ; Fri, 8 Apr 2011 22:16:54 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3fd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id DF10D8FC0A for ; Fri, 8 Apr 2011 22:16:53 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.4/8.14.4) with ESMTP id p38MGo3m030567 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 8 Apr 2011 23:16:50 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp.infracaninophile.co.uk p38MGo3m030567 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1302301010; bh=JpsyhXx1Lm8PwWAQXCICnSC5cukCfl4Um6J5BhCE0ow=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Cc:Content-Type:Date:From:In-Reply-To: Message-ID:Mime-Version:References:To; z=Message-ID:=20<4D9F894C.1030700@infracaninophile.co.uk>|Date:=20F ri,=2008=20Apr=202011=2023:16:44=20+0100|From:=20Matthew=20Seaman= 20|User-Agent:=20Mozilla/5.0=20(M acintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B=20en-US=3B=20r v:1.9.2.15)=20Gecko/20110303=20Thunderbird/3.1.9|MIME-Version:=201 .0|To:=20freebsd-hackers@freebsd.org|Subject:=20Re:=20ifconfig=20o utput:=20ipv4=20netmask=20format|References:=20<4D9EFAC6.4020906@l azybytes.org>=09<7EA5889E-77EF-4BAE-9655-C33692A75602@bsdimp.com>= 09<4D9F2C88.4010205@lazybytes.org>=20|In-Reply-To:=20|X-Enigmail-Version:=201.1.1|OpenPGP:=20i d=3D60AE908C|Content-Type:=20multipart/signed=3B=20micalg=3Dpgp-sh a1=3B=0D=0A=20protocol=3D"application/pgp-signature"=3B=0D=0A=20bo undary=3D"------------enigD925B34CA594A9E6ABB5A5FA"; b=vuB/n75THUU/VeHk/YTO2K6kMQYRxO1UjcHYCF67JsV+2dHqIDF8+SoLAScNro5t6 5F12R70OoMlRRDT3GUFRXry6vnOKOlftIkunD7qGHqJbnTHi+36qhXsRrPVbrv21YQ DGxAEnZDVTZSwW89xcIhoTrKrxJijIOYAHbe4dJ4= Message-ID: <4D9F894C.1030700@infracaninophile.co.uk> Date: Fri, 08 Apr 2011 23:16:44 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4D9EFAC6.4020906@lazybytes.org> <7EA5889E-77EF-4BAE-9655-C33692A75602@bsdimp.com> <4D9F2C88.4010205@lazybytes.org> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD925B34CA594A9E6ABB5A5FA" X-Virus-Scanned: clamav-milter 0.97 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,SPF_FAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lucid-nonsense.infracaninophile.co.uk Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 22:16:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD925B34CA594A9E6ABB5A5FA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 08/04/2011 16:53, Garrett Cooper wrote: > One thing I've been curious about for a while that I haven't had an > opportunity to look into is: what does IPV6 look like? I understand > that the /netmask bit is added to the end of addresses, but what does > the netmask actually look like? Like this: lucid-nonsense:~:% ifconfig re0 inet6 re0: flags=3D8843 metric 0 mtu 15= 00 options=3D389b inet6 fe80::e2cb:4eff:fe26:6481%re0 prefixlen 64 scopeid 0x1 inet6 2001:8b0:151:1:e2cb:4eff:fe26:6481 prefixlen 64 inet6 2001:8b0:151:1:: prefixlen 64 anycast inet6 2001:8b0:151:1:3950:9ee6:9c6b:8a8b prefixlen 64 inet6 2001:8b0:151:1:3fd3:cd67:fafa:3d78 prefixlen 64 inet6 2001:8b0:151:1:78ea:429a:bbd9:f62f prefixlen 64 inet6 2001:8b0:151:1:d2f:23d1:314c:5e2e prefixlen 64 inet6 2001:8b0:151:1:57f9:9484:e8b0:12d1 prefixlen 128 IPv6 doesn't deal in netmasks per-se: just in the length of the network prefix. (64 is typical. 48 also fairly common.) Cheers --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enigD925B34CA594A9E6ABB5A5FA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2fiVIACgkQ8Mjk52CukIxKtQCfS1tuNEb9hyo6VYTmPrEPvomJ iMoAni65SzTagY/miUiNKwTQGgVPbfN8 =w6Fh -----END PGP SIGNATURE----- --------------enigD925B34CA594A9E6ABB5A5FA-- From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 02:08:46 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5092106566C for ; Sat, 9 Apr 2011 02:08:46 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 5B7FE8FC14 for ; Sat, 9 Apr 2011 02:08:46 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 08B0725D3885; Sat, 9 Apr 2011 02:08:44 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 0C189159C8A2; Sat, 9 Apr 2011 02:08:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id rGeX11rNVIOI; Sat, 9 Apr 2011 02:08:43 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 0F71B159C8A0; Sat, 9 Apr 2011 02:08:41 +0000 (UTC) Date: Sat, 9 Apr 2011 02:08:40 +0000 (UTC) From: "Bjoern A. Zeeb" To: Warner Losh In-Reply-To: <8B793E28-0426-46CC-AB10-E0257AF6707D@bsdimp.com> Message-ID: References: <4D9EFAC6.4020906@lazybytes.org> <7EA5889E-77EF-4BAE-9655-C33692A75602@bsdimp.com> <4D9F2C88.4010205@lazybytes.org> <20110408155520.GA40792@cheddar.urgle.com> <4D9F5B31.9000509@lazybytes.org> <8B793E28-0426-46CC-AB10-E0257AF6707D@bsdimp.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Hackers , Sergey Vinogradov Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 02:08:46 -0000 On Fri, 8 Apr 2011, Warner Losh wrote: > Non-contiguous netmasks are *not* legal anymore in IPv4. Just reference the RFC and everyone will agree... *oops* ;-) On the general thread: I'd seriously stop bothering with any decisions that will change the way IPv4 works or has worked or the output tools gave people for 20 or more years unless there is a really good reason. Do not break things just because you don't like it. It's hardcoded into too many brains^Wscripts. just my 0.01cts. PS: I am all for making things more restrictive no longer thinking inet is the default but even that's hard... -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 04:55:02 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6AF1106566B for ; Sat, 9 Apr 2011 04:55:02 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7A4378FC0C for ; Sat, 9 Apr 2011 04:55:02 +0000 (UTC) Received: by iwn33 with SMTP id 33so4856936iwn.13 for ; Fri, 08 Apr 2011 21:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=RS7A4/j5yVkwitY5nKTMMNPs/AMsYcfTg0Iw+PVCSpc=; b=DnetmXPb00ILXkqGZqbI9pIM2Y+Fe0WQad5CP9yI4wSqn2FYGZ3q87lUwSKkMpqzyK eUz0nvQLWG+tUaOWxkaRvf2UKOPOrI1iIG3zH5L3bNlYxAj468J5j4FCfNjzXaDZeID/ Jdfer//nCWAh2nLpWg8UfyOJvvlKRKbHpJ444= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=XLouTqCCn7OYuSLxQ1R3Bmdhz/KP0QMy7jxA8ZFU0FAsJn2l/ZOl0WgL9T/Abh9koV WBqFVmioJs2OpC+mU+TFzOhnZifNZEN/JKRUXltge6huTSDDEWSdjXsP6WrcKLQF9+B7 tdeyviyKhyj7uD8APsu60FGmcst7U3LLa1YYo= Received: by 10.42.136.71 with SMTP id s7mr3761132ict.476.1302324901711; Fri, 08 Apr 2011 21:55:01 -0700 (PDT) Received: from DataIX.net (adsl-99-190-87-163.dsl.klmzmi.sbcglobal.net [99.190.87.163]) by mx.google.com with ESMTPS id wo11sm2178117icb.8.2011.04.08.21.54.59 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2011 21:55:00 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p394st1Z008584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Apr 2011 00:54:56 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p394ssL3008583; Sat, 9 Apr 2011 00:54:54 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sat, 9 Apr 2011 00:54:54 -0400 From: "J. Hellenthal" To: Sergey Vinogradov Message-ID: <20110409045453.GA91335@DataIX.net> References: <4D9EFAC6.4020906@lazybytes.org> <4D9F2B8D.3040104@lazybytes.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <4D9F2B8D.3040104@lazybytes.org> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: FreeBSD Hackers , Mike Oliver Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 04:55:02 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 08, 2011 at 07:36:45PM +0400, Sergey Vinogradov wrote: >On 08.04.2011 19:23, Mike Oliver wrote: >>On Fri, Apr 8, 2011 at 08:08, Sergey Vinogradov wr= ote: >>>Hi, hackers. >>>I have a question: why ipv4 netmask is displayed by ifconfig in hex form= at? >>>Isn't dot-decimal notation more human-readable? Will the attached patch >>>break something in the very bad way? >> >>Who's using IPv4 anymore? ;-) >Long live IPv4! :) > >>Seriously though, if you give a small amount of time to learning the >>hex -> binary translations then you would see how convenient it is to >>use hex rather than decimal when representing what are ultimately >>binary numbers. >> >>See this blog entry by Jeff Doyle... >> >>http://www.networkworld.com/community/blog/how-are-your-hexadecimal-skills >The article is great, but dot-decimal notation is de-facto standard >for stand-alone network mask representation. Like CIDR is standard for >IP blocks represenation. That's the reason I've started this thread. >And despite the greatness of the article you've mentioned, I think >it's a bad itea to hardcode its URL into ifconfig's output. You know, >for every single user reading it, and choosing the "way of hex" ;) > This is the year 2011 right ? when are we going to support new users rather than supporting old outdated washed up "scripts" ? I for one am for this change, given that there are lots of users from the PC-BSD community that do not read hexadecimal, octal and other such forms like a programmer does. And just because the change can be made does not mean that a compatibility shim cannot be put into place that restores the old functionality. It is time to stop living in the past and start thinking about the future. These types of things are what causes forks of projects to happen ultimately yielding in less contributors and developers. I for one hate to see things like that happen. --=20 J. Hellenthal --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNn+adAAoJEJBXh4mJ2FR+DAoH/RCEboQajelKGOCLLMaMn2OD yrqhLvox/b/93gT8n0bfH2XEYaHbwod+oglSquJV7f1Re2CLNZ0VcUHF7MFmjbuI Zzg8WYv7cYFSwfnoFGsHuGLicnAEBVGURbgciLqjcbDLdP+bvE7R2/fms9ohUUmB ot8x3SGCllRjltKtzkG4OWWXrZzNdgwLIOI1VaehWV2O7aEQYmFtts9bKSYC072f crDIdADGen6u3b/+uufmVMKIl7PFIh3h2qEym2gHybghHhThBT30Z5U6T5E97ZId tqmlU1p+YWMCsKDRrOCCLGPVCYH5aGAO1HJOmqIuMCNAEmG7vW6/FRRshCrmlLo= =PrKU -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 05:33:18 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D6BC106566B for ; Sat, 9 Apr 2011 05:33:18 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6E80D8FC14 for ; Sat, 9 Apr 2011 05:33:18 +0000 (UTC) Received: by pzk27 with SMTP id 27so1928824pzk.13 for ; Fri, 08 Apr 2011 22:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=m824tWnkYsTnXUUq973j5hzku4WyUrQK+SpawdCMjfI=; b=K2NG0IAD7M03fez0f6XY0HYYF93W3oliQlNHrE2RYjN7CxNgzG3K9c5gCus039gFIh zcyzhycaRbxZ9F2QO6No4m89I4+/jRO2QjWjNT/E4JDkQhWZKMdedvN9qnClTzQMSfuu cXZVCKiH6Cbgq2DTUJQYFWVehMClrleHerwgQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=k3iO8rsy60rsOxelIrPOuVi+2vDTYnT9rsHrYt21/H/Fn/owG95MkugEwjHSnP81fJ 4haHatpI+kVi0Pn2FcpEXC8/ctDO+vrvH6AC/vNX7DhssGEct1fyzkfpX4OK9CupSqoM cUJC1On9Bp9hOQ00/ea4yEq4718QVMD4+WBIw= MIME-Version: 1.0 Received: by 10.143.39.17 with SMTP id r17mr2551313wfj.113.1302327197060; Fri, 08 Apr 2011 22:33:17 -0700 (PDT) Received: by 10.68.42.3 with HTTP; Fri, 8 Apr 2011 22:33:17 -0700 (PDT) In-Reply-To: <20110409045453.GA91335@DataIX.net> References: <4D9EFAC6.4020906@lazybytes.org> <4D9F2B8D.3040104@lazybytes.org> <20110409045453.GA91335@DataIX.net> Date: Fri, 8 Apr 2011 22:33:17 -0700 Message-ID: From: Garrett Cooper To: "J. Hellenthal" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , Sergey Vinogradov , Mike Oliver Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 05:33:18 -0000 On Fri, Apr 8, 2011 at 9:54 PM, J. Hellenthal wrote: > On Fri, Apr 08, 2011 at 07:36:45PM +0400, Sergey Vinogradov wrote: >>On 08.04.2011 19:23, Mike Oliver wrote: >>>On Fri, Apr 8, 2011 at 08:08, Sergey Vinogradov = =A0wrote: >>>>Hi, hackers. >>>>I have a question: why ipv4 netmask is displayed by ifconfig in hex for= mat? >>>>Isn't dot-decimal notation more human-readable? Will the attached patch >>>>break something in the very bad way? >>> >>>Who's using IPv4 anymore? =A0;-) >>Long live IPv4! :) >> >>>Seriously though, if you give a small amount of time to learning the >>>hex -> =A0binary translations then you would see how convenient it is to >>>use hex rather than decimal when representing what are ultimately >>>binary numbers. >>> >>>See this blog entry by Jeff Doyle... >>> >>>http://www.networkworld.com/community/blog/how-are-your-hexadecimal-skil= ls >>The article is great, but dot-decimal notation is de-facto standard >>for stand-alone network mask representation. Like CIDR is standard for >>IP blocks represenation. That's the reason I've started this thread. >>And despite the greatness of the article you've mentioned, I think >>it's a bad itea to hardcode its URL into ifconfig's output. You know, >>for every single user reading it, and choosing the "way of hex" ;) >> > > This is the year 2011 right ? when are we going to support new users > rather than supporting old outdated washed up "scripts" ? > > I for one am for this change, given that there are lots of users from > the PC-BSD community that do not read hexadecimal, octal and other such > forms like a programmer does. > > And just because the change can be made does not mean that a > compatibility shim cannot be put into place that restores the old > functionality. > > > It is time to stop living in the past and start thinking about the > future. These types of things are what causes forks of projects to > happen ultimately yielding in less contributors and developers. I for > one hate to see things like that happen. I understand your pain and while I've been on your side of the fence several times in the past dealing with different things of this sort, having to maintain backwards compatibility is a painful reality of past design choices or mistakes. pkg_install and sysinstall are one of many examples, but there are of course other areas as well. Although I see the value of your and Sergey's argument, the problem is that it may cause unexpected breakage for other third parties that depend on a particular behavior in FreeBSD as Bjoern and others have suggested; I have a script at least that does properly parse out the hex output in order to set IPs properly with ipmitool, and I would be perturbed to have to hack around this further in my script. Mind you, this script is in my workspace, but having to track minor output changes like this across versions of FreeBSD, or interface changes like the semi-gratuitous removal of /dev/c in 8.x still had to be worked out on many branches my group maintains at $WORK. Getting back on track, I think that more 'user friendly' variants of FreeBSD, e.g. PCBSD, etc, could and should diverge with this one line patch as they're not mainline FreeBSD and the change is trivial for less hex inclined users as you suggest. Granted, this is just one of many bikeshed topics. Funny how many lines of debate have been written and how many feathers have been unnecessarily ruffled over the output of one printf. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 06:30:59 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 826CB106566C for ; Sat, 9 Apr 2011 06:30:59 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 343B58FC13 for ; Sat, 9 Apr 2011 06:30:59 +0000 (UTC) Received: by iwn33 with SMTP id 33so4908063iwn.13 for ; Fri, 08 Apr 2011 23:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=3ZcX6ctDxmYRX6DZtEgAm1TkiZvJh8wI9PcrfsKVgXE=; b=NvqdE+JZOmlB+D18rLhIjldGMa9Kwm6SK2HMdsvwaJaaFykoqBBQq4LCgRh2gBOKhq 18aw/qg43sXxWkYTMybeqk2n0Lvla00hvPBq3m55E4iK8y8g39FzYv2teJJKgLJrvXX6 ekNWbniGSuBrwz8mDBxXSb+Ngg6KZfVzm9xDw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=QmNFgCarvkqsBwBonkAiVWV4SNvIm/wewPpzMztcuI72VxQymwElWwJy3YyAMSkwSJ o/3Nmg7c+ZYfxYcgDn7czygonYeUNXE4cYZ52JgLb2DJRNs6WccQseU48SSUgIphIUCE f9AlH8QLKkWOno2OfnQtCkLRZCCIuackRLk+8= Received: by 10.43.58.148 with SMTP id wk20mr4365835icb.242.1302330657979; Fri, 08 Apr 2011 23:30:57 -0700 (PDT) Received: from DataIX.net (adsl-99-190-87-163.dsl.klmzmi.sbcglobal.net [99.190.87.163]) by mx.google.com with ESMTPS id g16sm2407096ibb.37.2011.04.08.23.30.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2011 23:30:55 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p396UjoC071878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Apr 2011 02:30:46 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p396UhMM071877; Sat, 9 Apr 2011 02:30:43 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sat, 9 Apr 2011 02:30:42 -0400 From: "J. Hellenthal" To: Garrett Cooper Message-ID: <20110409063042.GB91335@DataIX.net> References: <4D9EFAC6.4020906@lazybytes.org> <4D9F2B8D.3040104@lazybytes.org> <20110409045453.GA91335@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bn2rw/3z4jIqBvZU" Content-Disposition: inline In-Reply-To: X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: FreeBSD Hackers , Sergey Vinogradov , Mike Oliver Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 06:30:59 -0000 --Bn2rw/3z4jIqBvZU Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 08, 2011 at 10:33:17PM -0700, Garrett Cooper wrote: >On Fri, Apr 8, 2011 at 9:54 PM, J. Hellenthal wrote: >> On Fri, Apr 08, 2011 at 07:36:45PM +0400, Sergey Vinogradov wrote: >>>On 08.04.2011 19:23, Mike Oliver wrote: >>>>On Fri, Apr 8, 2011 at 08:08, Sergey Vinogradov = =A0wrote: >>>>>Hi, hackers. >>>>>I have a question: why ipv4 netmask is displayed by ifconfig in hex fo= rmat? >>>>>Isn't dot-decimal notation more human-readable? Will the attached patch >>>>>break something in the very bad way? >>>> >>>>Who's using IPv4 anymore? =A0;-) >>>Long live IPv4! :) >>> >>>>Seriously though, if you give a small amount of time to learning the >>>>hex -> =A0binary translations then you would see how convenient it is to >>>>use hex rather than decimal when representing what are ultimately >>>>binary numbers. >>>> >>>>See this blog entry by Jeff Doyle... >>>> >>>>http://www.networkworld.com/community/blog/how-are-your-hexadecimal-ski= lls >>>The article is great, but dot-decimal notation is de-facto standard >>>for stand-alone network mask representation. Like CIDR is standard for >>>IP blocks represenation. That's the reason I've started this thread. >>>And despite the greatness of the article you've mentioned, I think >>>it's a bad itea to hardcode its URL into ifconfig's output. You know, >>>for every single user reading it, and choosing the "way of hex" ;) >>> >> >> This is the year 2011 right ? when are we going to support new users >> rather than supporting old outdated washed up "scripts" ? >> >> I for one am for this change, given that there are lots of users from >> the PC-BSD community that do not read hexadecimal, octal and other such >> forms like a programmer does. >> >> And just because the change can be made does not mean that a >> compatibility shim cannot be put into place that restores the old >> functionality. >> >> >> It is time to stop living in the past and start thinking about the >> future. These types of things are what causes forks of projects to >> happen ultimately yielding in less contributors and developers. I for >> one hate to see things like that happen. > >I understand your pain and while I've been on your side of the fence >several times in the past dealing with different things of this sort, >having to maintain backwards compatibility is a painful reality of >past design choices or mistakes. pkg_install and sysinstall are one of >many examples, but there are of course other areas as well. > >Although I see the value of your and Sergey's argument, the problem is >that it may cause unexpected breakage for other third parties that >depend on a particular behavior in FreeBSD as Bjoern and others have >suggested; I have a script at least that does properly parse out the >hex output in order to set IPs properly with ipmitool, and I would be >perturbed to have to hack around this further in my script. Mind you, >this script is in my workspace, but having to track minor output >changes like this across versions of FreeBSD, or interface changes >like the semi-gratuitous removal of /dev/c in 8.x still had to >be worked out on many branches my group maintains at $WORK. > >Getting back on track, I think that more 'user friendly' variants of >FreeBSD, e.g. PCBSD, etc, could and should diverge with this one line >patch as they're not mainline FreeBSD and the change is trivial for >less hex inclined users as you suggest. > >Granted, this is just one of many bikeshed topics. Funny how many >lines of debate have been written and how many feathers have been >unnecessarily ruffled over the output of one printf. > Yeah I can agree with that. In either case right now (to me) it makes utterly no difference and is just a cosmetic fix as I can read hex, oct, dec in either fashion and convert between them quickly. I just hate to see other non-technical users fall subject to the same things that have been support way past a deprecation period that should have ended 10+ years ago. Anyway there are so many views on this, in any case the right decision is made going forth and positives and negatives can be discussed then. --=20 J. Hellenthal --Bn2rw/3z4jIqBvZU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNn/0SAAoJEJBXh4mJ2FR+Oe8H+gLwePnpZPTB6maCSkluopLF wuEZLBafAQun2uizxcJU21qq2FwKnlPhiM6xErXCsBTUguiGhHwpgeJahA58LCdO oMQiPcvWEfgVycV8lkSxVENsqAEEYCCbdyRyer0VklosL+1zUI06Cbj4aL0E0qZ3 xLwQuFKj3cJYO2NB9EBmS/u2GJRCiqC8ULsR5fKrrx59m2Ece2hQCV+DGJtHhCXB 8TpFoueISUErAFlV+Qoz5sEWwQa5o8geD3XD2039bPYhm8OasIbWQOCnE49s2lkh r+hKzMoXEIe+tWuty+jdZxmzU2oEkkYzj1bMeKkuc/25gKU8aVr1hJaGyvM8XDU= =5j+B -----END PGP SIGNATURE----- --Bn2rw/3z4jIqBvZU-- From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 08:08:53 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41737106564A; Sat, 9 Apr 2011 08:08:53 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id 007968FC0C; Sat, 9 Apr 2011 08:08:52 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id B3C5C94E7F; Sat, 9 Apr 2011 09:43:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id EAXcr2jP3HGN; Sat, 9 Apr 2011 09:43:51 +0200 (CEST) Received: from danger-mbp.local (188-167-63-91.dynamic.chello.sk [188.167.63.91]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.syscare.sk (Postfix) with ESMTPSA id 9113C94E6A; Sat, 9 Apr 2011 09:43:51 +0200 (CEST) Message-ID: <4DA00E3A.8020009@FreeBSD.org> Date: Sat, 09 Apr 2011 09:43:54 +0200 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17pre) Gecko/20110331 Lanikai/3.1.10pre MIME-Version: 1.0 To: current@freebsd.org, hackers@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Fwd: HEADSUP: Call for FreeBSD Status Reports - 1Q/2011 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 08:08:53 -0000 Hello, I would like to remind you that the submission due date (April 15th) is approaching quickly and to this date I have received _only_ 3 submissions. Please try to find a few minutes and submit your reports so that we can inform our community about the progress made in the first quarter of 2011. Thanks! -------- Original Message -------- Subject: HEADSUP: Call for FreeBSD Status Reports - 1Q/2011 Date: Mon, 21 Mar 2011 18:19:23 +0100 From: Daniel Gerzo Organization: The FreeBSD Project To: , Dear all, I would like to remind you that the next round of status reports covering the first quarter of 2011 is due on April 15th, 2011. As this initiative is very popular among our users, I would like to ask you to submit your status reports soon, so that we can compile the report on time. Do not hesitate and write us a few lines; a short description about what you are working on, what your plans and goals are, or any other information that you consider interested is always welcome. This way we can inform our community about your great work! Check out the reports from the past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome too. Note that the submissions are accepted from anyone involved within the FreeBSD community, you do not have to be a FreeBSD committer. Anything related to FreeBSD can be covered. Please email us the filled-in XML template which can be found at http://www.freebsd.org/news/status/report-sample.xml to monthly@FreeBSD.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- Kind regards Daniel Gerzo From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 08:11:46 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B781F106566C for ; Sat, 9 Apr 2011 08:11:46 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 95E2B8FC12 for ; Sat, 9 Apr 2011 08:11:46 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p398BftB018221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 9 Apr 2011 01:11:41 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p398Bf2K018220; Sat, 9 Apr 2011 01:11:41 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA08865; Sat, 9 Apr 11 01:01:32 PDT Date: Sat, 09 Apr 2011 01:00:58 -0700 From: perryh@pluto.rain.com To: imp@bsdimp.com Message-Id: <4da0123a.X/iA9ZZt1x2Me/Kg%perryh@pluto.rain.com> References: <4D9EFAC6.4020906@lazybytes.org> <7EA5889E-77EF-4BAE-9655-C33692A75602@bsdimp.com> <4D9F2C88.4010205@lazybytes.org> <20110408155520.GA40792@cheddar.urgle.com> In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, boogie@lazybytes.org Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 08:11:46 -0000 Warner Losh wrote: > > Non-contigous netmasks are legal in IPv4 ... > > They have become illegal in the fullness of time. and/or the fullness of the address space, I suspect :) Even if they were legal, I have a hard time imagining a practical use case. From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 12:07:14 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83BFF1065675 for ; Sat, 9 Apr 2011 12:07:14 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id EB5D78FC16 for ; Sat, 9 Apr 2011 12:07:12 +0000 (UTC) Received: by pwj8 with SMTP id 8so2026914pwj.13 for ; Sat, 09 Apr 2011 05:07:12 -0700 (PDT) Received: by 10.142.131.1 with SMTP id e1mr2869972wfd.292.1302350831982; Sat, 09 Apr 2011 05:07:11 -0700 (PDT) Received: from dfleuriot.local ([83.167.62.196]) by mx.google.com with ESMTPS id x11sm5054414wfd.13.2011.04.09.05.07.10 (version=SSLv3 cipher=OTHER); Sat, 09 Apr 2011 05:07:11 -0700 (PDT) Message-ID: <4DA04BEB.6010608@my.gd> Date: Sat, 09 Apr 2011 14:07:07 +0200 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4D9EFAC6.4020906@lazybytes.org> <4D9F2B8D.3040104@lazybytes.org> <20110409045453.GA91335@DataIX.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 12:07:14 -0000 On 4/9/11 7:33 AM, Garrett Cooper wrote: > > Although I see the value of your and Sergey's argument, the problem is > that it may cause unexpected breakage for other third parties that > depend on a particular behavior in FreeBSD as Bjoern and others have > suggested; I have a script at least that does properly parse out the > hex output in order to set IPs properly with ipmitool, and I would be > perturbed to have to hack around this further in my script. > > Thanks, > -Garrett > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" If the proposed change was made an option via a knob as has been suggested, that would leave your script unscathed. One might or might not like the option, and then choose to use it or disregard it. Given that one can configure their interfaces by giving a CIDR notation (like: ifconfig re0 inet 192.168.0.1/24) , it makes sense that one should be able to output the CIDR notation as well. I for one see absolutely no valid reason why the change should be rejected if it doesn't change ifconfig's default behaviour and doesn't cause any regression ? A valid reason would be: nobody wants it. But then, some people do seem to want it. I would like this option really, would prolly alias it while I'm at it. From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 15:59:09 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E47A2106564A; Sat, 9 Apr 2011 15:59:09 +0000 (UTC) (envelope-from chris.richardson.bsd@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3154C8FC20; Sat, 9 Apr 2011 15:59:08 +0000 (UTC) Received: by wwk4 with SMTP id 4so1418451wwk.1 for ; Sat, 09 Apr 2011 08:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=gZPTCj7bUeaPzYlATgyoA/xmNwrFUq00/YTEldw4bMg=; b=rC0k/s2VIrqahs38p+ia8VCdigpbMp1PHopsp2kPrNCAUxPQ7QIKuoTsShWMMBLtdk smsNvJ6+YMTJVXKVchVQFIh4GYKUjNiCa+5VII3YR1/qLblgV9Pk8DX4g5y2o+nHPo24 Pe63Ed64uPA/RqR+U+0qeUYl4ikmgyA7cugaQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=u5hQ/OJf1vyjqv5u1UFckyKIUU8Eca6dOxSY3bo55gcvUpbPI3VXH2lV0PmoIXl0WA I727IEPWDVFbYB9DeW5OiKGF/280LZmWNawZ597F6qsihyomHmPdxtIxGDqoYzDAHzpu ZTG2BffeULs9h7ZvYKP3RV47hf02cnaySEYjo= MIME-Version: 1.0 Received: by 10.227.131.23 with SMTP id v23mr3374316wbs.53.1302363096212; Sat, 09 Apr 2011 08:31:36 -0700 (PDT) Received: by 10.227.143.133 with HTTP; Sat, 9 Apr 2011 08:31:36 -0700 (PDT) Date: Sat, 9 Apr 2011 17:31:36 +0200 Message-ID: From: Chris Richardson To: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Kernel Tracking Question.. regarding kernel and boot files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 15:59:10 -0000 Hi all, I am totally new to FreeBSD. I was involved within project which will trace the kernel. I used ktrace but I could not get appropriate results about the files being opened. I don't see any of the boot files boot0-1 or 2 in the ktrace.out file. Where did they go? Is ktrace the best "trace suite" for freebsd kernel? What about going through source code .. Is it better to use Combination of Ecllipse/Qemu and FreeBSD Source tree? Does this method will provide us with someway to see how booting process invokes the kernel to memory ? Any help will be appreciated. Yours, Chris From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 16:51:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7FF2106564A for ; Sat, 9 Apr 2011 16:51:26 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from imr-ma02.mx.aol.com (imr-ma02.mx.aol.com [64.12.206.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8900B8FC08 for ; Sat, 9 Apr 2011 16:51:26 +0000 (UTC) Received: from imo-ma04.mx.aol.com (imo-ma04.mx.aol.com [64.12.78.139]) by imr-ma02.mx.aol.com (8.14.1/8.14.1) with ESMTP id p39GfFrj007301 for ; Sat, 9 Apr 2011 12:41:15 -0400 Received: from dieterbsd@engineer.com by imo-ma04.mx.aol.com (mail_out_v42.9.) id n.e79.9cd27f6 (56026) for ; Sat, 9 Apr 2011 12:41:10 -0400 (EDT) Received: from smtprly-md03.mx.aol.com (smtprly-md03.mx.aol.com [64.12.143.156]) by cia-md07.mx.aol.com (v129.9) with ESMTP id MAILCIAMD078-d4374da08c2115f; Sat, 09 Apr 2011 12:41:10 -0400 Received: from web-mmc-m02 (web-mmc-m02.sim.aol.com [64.12.224.135]) by smtprly-md03.mx.aol.com (v129.9) with ESMTP id MAILSMTPRLYMD036-d4374da08c2115f; Sat, 09 Apr 2011 12:41:05 -0400 To: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Date: Sat, 09 Apr 2011 12:41:05 -0400 X-MB-Message-Source: WebUI X-AOL-IP: 67.206.165.243 X-MB-Message-Type: User MIME-Version: 1.0 From: dieterbsd@engineer.com Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailer: Mail.com Webmail 33490-STANDARD Received: from 67.206.165.243 by web-mmc-m02.sysops.aol.com (64.12.224.135) with HTTP (WebMailUI); Sat, 09 Apr 2011 12:41:05 -0400 Message-Id: <8CDC4EC0DEBF3BD-18FC-3276@web-mmc-m02.sysops.aol.com> X-Spam-Flag: NO X-AOL-SENDER: dieterbsd@engineer.com Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 16:51:26 -0000 Paul Schenkeveld writes: > Although non-contiguous netmasks are not legal anymore in IPv4, our > ifconfig still allows to do something like: > > # ifconfig em0 inet 10.0.5.2 netmask 255.0.255.0 > # ifconfig em0 > em0: flags=3D8843 metric 0=20 mtu 1500 > =20 options=3D219b > ether xx:xx:xx:xx:xx:xx > inet 10.0.5.2 netmask 0xff00ff00 broadcast 10.255.5.255 > media: Ethernet autoselect (1000baseT ) > status: active If this is no longer legal, should ifconfig issue a warning? J. Hellenthal writes: > This is the year 2011 right ? when are we going to support new users > rather than supporting old outdated washed up "scripts" ? Change for the sake of change is not progress. Perhaps when you get more experience you will understand the "joy" of spending massive=20 amounts of time attempting to deal with gratuitious changes. Personally, I'd prefer to be spending my time fixing things that are truly broken rather than repainting the bikeshed in today's fashionable color. And unfortunately there are things that are badly broken. Things that cause data loss. Hardware that isn't supported properly. Some of these are in the PR database if you need a list of useful things to work on. As far as ifconfig goes, I'm in the camp that says 1) Leave the default alone to avoid breaking scripts. 2) Add an option for those who want it. (Put some thought into it, don't just do the first thing that springs to mind.) 3) Those that want a different default can use an alias. From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 17:16:26 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E736B1065674 for ; Sat, 9 Apr 2011 17:16:26 +0000 (UTC) (envelope-from mike@urgle.com) Received: from lon1-post-2.mail.demon.net (lon1-post-2.mail.demon.net [195.173.77.149]) by mx1.freebsd.org (Postfix) with ESMTP id AF97A8FC15 for ; Sat, 9 Apr 2011 17:16:26 +0000 (UTC) Received: from cheddar.urgle.com ([80.177.40.53]) by lon1-post-2.mail.demon.net with esmtp (Exim 4.69) id 1Q8bYx-0003Dz-cK; Sat, 09 Apr 2011 17:03:07 +0000 Received: from mike by cheddar.urgle.com with local (Exim 4.75 (FreeBSD)) (envelope-from ) id 1Q8bYx-000DIu-Bv; Sat, 09 Apr 2011 17:03:07 +0000 Date: Sat, 9 Apr 2011 18:03:07 +0100 From: Mike Bristow To: Warner Losh Message-ID: <20110409170307.GA50972@cheddar.urgle.com> References: <4D9EFAC6.4020906@lazybytes.org> <7EA5889E-77EF-4BAE-9655-C33692A75602@bsdimp.com> <4D9F2C88.4010205@lazybytes.org> <20110408155520.GA40792@cheddar.urgle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Sergey Vinogradov , hackers@freebsd.org Subject: Re: ifconfig output: ipv4 netmask format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 17:16:27 -0000 On Fri, Apr 08, 2011 at 11:43:16AM -0600, Warner Losh wrote: > > Non-contigous netmasks are legal in IPv4. What do you do if someone adds > > the CIDR flag but the netmask cannot be represented in CIDR notation? > > They have become illegal in the fullness of time. I'll rephrase my point, then: not all netmasks, legal or otherwise, that are accepted by ifconfig, can be represented in CIDR notation (see below). I guess the fact that ifconfig accepts them is a bug - but that merely changes my comment to "Non-contigous netmasks are accepted for IPv4 addresses by some (buggy) utilities. What do you do if someone adds the CIDR flag, but the netmask cannot be represented in CIDR notation?". Cheers, Mike [root@cheddar ~]# ifconfig bridge99 create [root@cheddar ~]# ifconfig bridge99 127.255.0.1 netmask 255.255.255.1 [root@cheddar ~]# ifconfig bridge99 bridge99: flags=8843 metric 0 mtu 1500 ether d6:c6:07:a9:7e:b9 inet 127.255.0.1 netmask 0xffffff01 broadcast 127.255.0.255 [root@cheddar ~]# uname -a FreeBSD cheddar.urgle.com 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 24 23:04:32 GMT 2011 root@cheddar.urgle.com:/usr/obj/usr/src/sys/GENERIC amd64 [root@cheddar ~]# -- Mike Bristow mike@urgle.com From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 17:37:24 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C1AF1065678 for ; Sat, 9 Apr 2011 17:37:24 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8C54C8FC15 for ; Sat, 9 Apr 2011 17:37:23 +0000 (UTC) Received: by vws18 with SMTP id 18so4155190vws.13 for ; Sat, 09 Apr 2011 10:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=Tw1qDl9PwIDBDDpXmDcSfZ7qFR6nekDBFGfk+qK2pLU=; b=EQhMZxCf4PX+169dtFQS4dsBoapxmLs9wwl0Go4ml0OsrM9+eDLqF4/quh8UpLHwrh dnAAfWB67JCEDsGMsTM8cEDRNyMfFrz3sDNY5CTNpeLY/ZxadMVWcY1nRtbloQk7hYVT QtErvrxS1n/EEFJwnq0trJUzHeKFbBnjdJ4zs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JSySAFbClLanSdpQorbZqYqvK+/6Gu5Ycadut5L+r7jm/2EsFp1E/9KgELgR943XHY OfXdUfpYyRY0MCU3zFTQuD5eVf31OlunN241x6CNcJcuFiolwacwNeW+CZXFXziBY0CE +LGy2BjcU0yy6O07WotE+XosCQo1ls3ErVx4A= MIME-Version: 1.0 Received: by 10.52.165.134 with SMTP id yy6mr5079637vdb.312.1302369306657; Sat, 09 Apr 2011 10:15:06 -0700 (PDT) Received: by 10.52.187.73 with HTTP; Sat, 9 Apr 2011 10:15:06 -0700 (PDT) Date: Sat, 9 Apr 2011 13:15:06 -0400 Message-ID: From: Joe Schaefer To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: imposing memory limits in FreeBSD 8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 17:37:24 -0000 While I am thrilled about the newfound zfs stability that upgrading to 8 has brought, one of the things that seems to have been dropped is support for process memory limits. I have a few servers that occasionally run out of swap due to runaway httpd daemons, and the ulimit -m settings in the startup scripts we use stopped working upon upgrading from FreeBSD 6. I've tried fiddling with the daemon class in login.conf to no avail either. About the only thing I haven't tried is running httpd under djb's softlimit executable. Here's my daemon class in login.conf: daemon:\ :memoryuse=1g:\ :datasize=1g:\ :stacksize=1g:\ :tc=default: and proof that `limits` groks the config: # limits -eHC daemon ulimit -t unlimited; ulimit -f unlimited; ulimit -d 1048576; ulimit -s 1048576; ulimit -c unlimited; ulimit -m 1048576; ulimit -l unlimited; ulimit -u unlimited; ulimit -n unlimited; ulimit -b unlimited; ulimit -v unlimited; ulimit -p unlimited; ulimit -w unlimited; Any tips from admins who have successfully imposed memory constraints in 8.x? From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 19:06:42 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 800AD106566C for ; Sat, 9 Apr 2011 19:06:42 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2EFF38FC15 for ; Sat, 9 Apr 2011 19:06:41 +0000 (UTC) Received: by qyk27 with SMTP id 27so3159103qyk.13 for ; Sat, 09 Apr 2011 12:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9NLwxQAVTNS4kjzMX0zSOPf1lrVDeKBjqxavwhn63gE=; b=SUBiUPMdJvDybIgt1RRKZjGYdKSMW9FVCHfyUwM3NAGOAGSYUkX2nRSz9EKZkIO8q8 lIRjG5wGWqazMgMXIOIn6VSuJgkyTvDjru8Uy2rWH+aDr7KA+q07+X8FWii6WPK9yeG8 gAg7oTJ4BndwRvc/KpUiFRHdd1Yt6B+lV5Y3g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vHAJ2f8BcE3zhyYgcOebzmOIMQ5TLM60iYjH13SpKhtC40sWiHhvUwAoTDg8Tl5IZd h6feHARApIMmW3zdUUZ49x7/Dq1HzDFoHUrOo20fIQeQ2smu1xA65I/Nad5cyF8sqGwO TTdNrOl61BxXRh2bcyi3vJkmW9s8BCgy9gucY= MIME-Version: 1.0 Received: by 10.229.63.229 with SMTP id c37mr2927024qci.212.1302376001103; Sat, 09 Apr 2011 12:06:41 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.229.233.195 with HTTP; Sat, 9 Apr 2011 12:06:41 -0700 (PDT) In-Reply-To: References: Date: Sat, 9 Apr 2011 12:06:41 -0700 X-Google-Sender-Auth: LtkubF5CSsarOUIiQl-n-VnLHbw Message-ID: From: Artem Belevich To: Joe Schaefer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: imposing memory limits in FreeBSD 8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 19:06:42 -0000 On Sat, Apr 9, 2011 at 10:15 AM, Joe Schaefer wrote: > While I am thrilled about the newfound zfs stability that upgrading to 8 > has brought, one of the things that seems to have been dropped is > support for process memory limits. =A0I have a few servers that occasiona= lly > run out of swap due to runaway httpd daemons, and the ulimit -m settings > in the startup scripts we use stopped working upon upgrading from FreeBSD= 6. > > I've tried fiddling with the daemon class in login.conf to no avail > either. =A0About > the only thing I haven't tried is running httpd under djb's softlimit > executable. > Here's my daemon class in login.conf: > > daemon:\ > =A0 =A0 =A0 =A0:memoryuse=3D1g:\ > =A0 =A0 =A0 =A0:datasize=3D1g:\ > =A0 =A0 =A0 =A0:stacksize=3D1g:\ > =A0 =A0 =A0 =A0:tc=3Ddefault: > > and proof that `limits` groks the config: > > # limits -eHC daemon > ulimit -t unlimited; > ulimit -f unlimited; > ulimit -d 1048576; > ulimit -s 1048576; > ulimit -c unlimited; > ulimit -m 1048576; > ulimit -l unlimited; > ulimit -u unlimited; > ulimit -n unlimited; > ulimit -b unlimited; > ulimit -v unlimited; > ulimit -p unlimited; > ulimit -w unlimited; > > Any tips from admins who have successfully imposed memory constraints in = 8.x? If I recall it correctly, in -8 malloc defaults to mmap for memory allocations, so RLIMIT_DATA no longer applies. You have to set RLIMIT_VMEM, but be careful as that would include everything mmapped in even if it does not use much of that. rpc.statd is one example of that -- it mmaps in ~256M but has only ~400K resident set size. Another option would be to make malloc() switch back to sbrk() with MALLOC_OPTIONS=3DD. This way datasize limit will still be in effect. --Artem From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 19:17:12 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CAF6106566C; Sat, 9 Apr 2011 19:17:12 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id B166D8FC15; Sat, 9 Apr 2011 19:17:11 +0000 (UTC) Received: by vxc34 with SMTP id 34so4220195vxc.13 for ; Sat, 09 Apr 2011 12:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SpMtD8X1AtWAg4WvnTknEbjWvyptB66YyWXepTHFAmc=; b=VC/5CMOehaeieZnUejFs4TCbgSUkGfZjP7pY1501crZrPrTvfAaB8hHQ3gtEnSXB0W IJErnvJ8kQnX8WOFwyYEEnjV0Gfm/yG9TqdCx9BtpeeTrqMyQTyo78UAPaOUhiOBMdtP UonBE5kOU4L8M7IjSfBg6jxB6RIqzaBLDB0aA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BWGKLBoiFbT/sXPQ2fTFZfSZTKN3evU6uCS9ich5IzhIMHlYIkqqIT424E+OoeB/sT u1zlgGUxWflj6bHqbOe6lcDlQSy1S74FHdm0m3KQewIHX7TUBEUjq6uxMnI3JkOFOtA1 HNjesW+7zOTkLeY6Rd+62lOB5J2bVVTGUJ3D0= MIME-Version: 1.0 Received: by 10.52.18.74 with SMTP id u10mr5228263vdd.192.1302376630759; Sat, 09 Apr 2011 12:17:10 -0700 (PDT) Received: by 10.52.187.73 with HTTP; Sat, 9 Apr 2011 12:17:10 -0700 (PDT) In-Reply-To: References: Date: Sat, 9 Apr 2011 15:17:10 -0400 Message-ID: From: Joe Schaefer To: Artem Belevich Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org Subject: Re: imposing memory limits in FreeBSD 8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 19:17:12 -0000 On Sat, Apr 9, 2011 at 3:06 PM, Artem Belevich wrote: > On Sat, Apr 9, 2011 at 10:15 AM, Joe Schaefer wrote: >> While I am thrilled about the newfound zfs stability that upgrading to 8 >> has brought, one of the things that seems to have been dropped is >> support for process memory limits. I have a few servers that occasionally >> run out of swap due to runaway httpd daemons, and the ulimit -m settings >> in the startup scripts we use stopped working upon upgrading from FreeBSD 6. >> >> I've tried fiddling with the daemon class in login.conf to no avail >> either. About >> the only thing I haven't tried is running httpd under djb's softlimit >> executable. >> Here's my daemon class in login.conf: >> >> daemon:\ >> :memoryuse=1g:\ >> :datasize=1g:\ >> :stacksize=1g:\ >> :tc=default: >> >> and proof that `limits` groks the config: >> >> # limits -eHC daemon >> ulimit -t unlimited; >> ulimit -f unlimited; >> ulimit -d 1048576; >> ulimit -s 1048576; >> ulimit -c unlimited; >> ulimit -m 1048576; >> ulimit -l unlimited; >> ulimit -u unlimited; >> ulimit -n unlimited; >> ulimit -b unlimited; >> ulimit -v unlimited; >> ulimit -p unlimited; >> ulimit -w unlimited; >> >> Any tips from admins who have successfully imposed memory constraints in 8.x? > > If I recall it correctly, in -8 malloc defaults to mmap for memory > allocations, so RLIMIT_DATA no longer applies. > You have to set RLIMIT_VMEM, but be careful as that would include > everything mmapped in even if it does not use much of that. rpc.statd > is one example of that -- it mmaps in ~256M but has only ~400K > resident set size. > > Another option would be to make malloc() switch back to sbrk() with > MALLOC_OPTIONS=D. This way datasize limit will still be in effect. Thanks for the tip. My concern is with runaway processes that are pushing the server into swap, so it's pretty easy to pick them out based on what top reports for their SIZE. I'll try the vmem limit and let you know how that works out. From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 19:31:23 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CED2A106566B; Sat, 9 Apr 2011 19:31:23 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6D32E8FC17; Sat, 9 Apr 2011 19:31:23 +0000 (UTC) Received: by vxc34 with SMTP id 34so4224528vxc.13 for ; Sat, 09 Apr 2011 12:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=e72Gx39W6o8K+HJwrVyiGE3smS9bKs/lGtdNVISoIPY=; b=i96bEpl8a1eAAUtIYZmWjIe+6kO37NHbS99+sCya3AJUybfab7+i++RWflqy2twUdS Qr2XPjhWdaHTTgLfTetkG/0xP5Mmmbm+k37g5fLwH1xMRnepohA+qkQw52I4SmzJO0oO t8/h/w951agyAtiIJ+yxlgWgQxdAhDIE3Ltf4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=L5ozUDy2yRShmJe8MhALwiEQCHeqJ/QJo/m8fJc0brMgzv7/Cd7SZ6ieAANzJpi5qj 1M4NRjGkuttxU9C0rhIsj4E8e7EoWh/6s1bFomlfJeY6mUh1mplrcuyW6qCNZFd2Ue+J ED7PZHLFIaKmzVKluHmcWedGphbVF79lQ5V0Y= MIME-Version: 1.0 Received: by 10.52.94.75 with SMTP id da11mr1970318vdb.152.1302377482556; Sat, 09 Apr 2011 12:31:22 -0700 (PDT) Received: by 10.52.187.73 with HTTP; Sat, 9 Apr 2011 12:31:22 -0700 (PDT) In-Reply-To: References: Date: Sat, 9 Apr 2011 15:31:22 -0400 Message-ID: From: Joe Schaefer To: Artem Belevich Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org Subject: Re: imposing memory limits in FreeBSD 8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 19:31:24 -0000 On Sat, Apr 9, 2011 at 3:17 PM, Joe Schaefer wrote: > On Sat, Apr 9, 2011 at 3:06 PM, Artem Belevich wrote: >> On Sat, Apr 9, 2011 at 10:15 AM, Joe Schaefer wrote: >>> While I am thrilled about the newfound zfs stability that upgrading to 8 >>> has brought, one of the things that seems to have been dropped is >>> support for process memory limits. I have a few servers that occasionally >>> run out of swap due to runaway httpd daemons, and the ulimit -m settings >>> in the startup scripts we use stopped working upon upgrading from FreeBSD 6. >>> >>> I've tried fiddling with the daemon class in login.conf to no avail >>> either. About >>> the only thing I haven't tried is running httpd under djb's softlimit >>> executable. >>> Here's my daemon class in login.conf: >>> >>> daemon:\ >>> :memoryuse=1g:\ >>> :datasize=1g:\ >>> :stacksize=1g:\ >>> :tc=default: >>> >>> and proof that `limits` groks the config: >>> >>> # limits -eHC daemon >>> ulimit -t unlimited; >>> ulimit -f unlimited; >>> ulimit -d 1048576; >>> ulimit -s 1048576; >>> ulimit -c unlimited; >>> ulimit -m 1048576; >>> ulimit -l unlimited; >>> ulimit -u unlimited; >>> ulimit -n unlimited; >>> ulimit -b unlimited; >>> ulimit -v unlimited; >>> ulimit -p unlimited; >>> ulimit -w unlimited; >>> >>> Any tips from admins who have successfully imposed memory constraints in 8.x? >> >> If I recall it correctly, in -8 malloc defaults to mmap for memory >> allocations, so RLIMIT_DATA no longer applies. >> You have to set RLIMIT_VMEM, but be careful as that would include >> everything mmapped in even if it does not use much of that. rpc.statd >> is one example of that -- it mmaps in ~256M but has only ~400K >> resident set size. >> >> Another option would be to make malloc() switch back to sbrk() with >> MALLOC_OPTIONS=D. This way datasize limit will still be in effect. > > Thanks for the tip. My concern is with runaway processes that are pushing the > server into swap, so it's pretty easy to pick them out based on what top reports > for their SIZE. I'll try the vmem limit and let you know how that works out. > Sweet- if the expected behavior is to send the process a SIGABORT when it hits the limit, it's working perfectly. From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 19:56:13 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0B301065672 for ; Sat, 9 Apr 2011 19:56:13 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from imr-ma04.mx.aol.com (imr-ma04.mx.aol.com [64.12.206.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6FE268FC12 for ; Sat, 9 Apr 2011 19:56:12 +0000 (UTC) Received: from imo-da03.mx.aol.com (imo-da03.mx.aol.com [205.188.169.201]) by imr-ma04.mx.aol.com (8.14.1/8.14.1) with ESMTP id p39JuAEW005550 for ; Sat, 9 Apr 2011 15:56:10 -0400 Received: from dieterbsd@engineer.com by imo-da03.mx.aol.com (mail_out_v42.9.) id n.c74.79a92a97 (43999) for ; Sat, 9 Apr 2011 15:56:05 -0400 (EDT) Received: from smtprly-dc02.mx.aol.com (smtprly-dc02.mx.aol.com [205.188.170.2]) by cia-dd06.mx.aol.com (v129.9) with ESMTP id MAILCIADD068-d2f34da0b9d2286; Sat, 09 Apr 2011 15:56:05 -0400 Received: from web-mmc-m02 (web-mmc-m02.sim.aol.com [64.12.224.135]) by smtprly-dc02.mx.aol.com (v129.9) with ESMTP id MAILSMTPRLYDC022-d2f34da0b9d2286; Sat, 09 Apr 2011 15:56:02 -0400 To: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Date: Sat, 09 Apr 2011 15:56:02 -0400 X-MB-Message-Source: WebUI X-AOL-IP: 67.206.164.51 X-MB-Message-Type: User MIME-Version: 1.0 From: dieterbsd@engineer.com Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailer: Mail.com Webmail 33490-STANDARD Received: from 67.206.164.51 by web-mmc-m02.sysops.aol.com (64.12.224.135) with HTTP (WebMailUI); Sat, 09 Apr 2011 15:56:02 -0400 Message-Id: <8CDC50749BB9940-18FC-38C6@web-mmc-m02.sysops.aol.com> X-Spam-Flag: NO X-AOL-SENDER: dieterbsd@engineer.com Subject: *printf(9) and PRINTF_BUFR_SIZE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 19:56:13 -0000 While working on other problems with *printf(9), log(9), etc. I stumbled upon: options PRINTF_BUFR_SIZE=3D128 # Prevent printf output being=20 interspersed. Question 1: Am I correct in thinking that PRINTF_BUFR_SIZE is supposed to prevent this: ada2: 300.000MB/s transfuhub2: 3 ports with 3 removable, self powered ers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled Question 2: Why is vprintf() the only function that does this buffering? As far as I can tell, the various functions that call kvprintf()=20 directly without going through vprintf() do not get buffered. I'm thinking that kvprintf() would be a better place for the buffering. Or would this=20 break something? From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 20:20:48 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE0B4106566C for ; Sat, 9 Apr 2011 20:20:48 +0000 (UTC) (envelope-from kline@thought.org) Received: from thought.org (plato.thought.org [209.180.213.209]) by mx1.freebsd.org (Postfix) with ESMTP id 45DB48FC18 for ; Sat, 9 Apr 2011 20:20:47 +0000 (UTC) Received: by thought.org (Postfix, from userid 1001) id 347F9E805AA; Sat, 9 Apr 2011 13:20:47 -0700 (PDT) Date: Sat, 9 Apr 2011 13:20:47 -0700 From: Gary Kline To: Daniel Gerzo Message-ID: <20110409202047.GA12600@thought.org> References: <4DA00E3A.8020009@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA00E3A.8020009@FreeBSD.org> X-Organization: Thought Unlimited. Public service Unix since 1986. X-Of_Interest: With 24++ years of service to the Unix community. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: Fwd: HEADSUP: Call for FreeBSD Status Reports - 1Q/2011 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 20:20:48 -0000 For my short post [to everyone], I'll top post. I am/have-been trying to write a user-side audio, "key-click" driver for every Open OS--essentially the BSD distros and the Linux. I am looking for people interested and who know both python and C/C++. -g On Sat, Apr 09, 2011 at 09:43:54AM +0200, Daniel Gerzo wrote: > Hello, > > I would like to remind you that the submission due date (April 15th) > is approaching quickly and to this date I have received _only_ 3 > submissions. > > Please try to find a few minutes and submit your reports so that we > can inform our community about the progress made in the first > quarter of 2011. > > Thanks! > > -------- Original Message -------- > Subject: HEADSUP: Call for FreeBSD Status Reports - 1Q/2011 > Date: Mon, 21 Mar 2011 18:19:23 +0100 > From: Daniel Gerzo > Organization: The FreeBSD Project > To: , > > Dear all, > > I would like to remind you that the next round of status reports > covering the first quarter of 2011 is due on April 15th, 2011. As this > initiative is very popular among our users, I would like to > ask you to submit your status reports soon, so that we can compile the > report on time. > > Do not hesitate and write us a few lines; a short description about > what you are working on, what your plans and goals are, or any other > information that you consider interested is always welcome. This way > we can inform our community about your great work! > Check out the reports from the past to get some inspiration of what > your submission should look like. > > If you know about a project that should be included in the status > report, please let us know as well, so we can poke the responsible > people to provide us with something useful. Updates to submissions from > the last report are welcome too. > > Note that the submissions are accepted from anyone involved within the > FreeBSD community, you do not have to be a FreeBSD committer. Anything > related to FreeBSD can be covered. > > Please email us the filled-in XML template which can be found at > http://www.freebsd.org/news/status/report-sample.xml to > monthly@FreeBSD.org, or alternatively use our web based form located at > http://www.freebsd.org/cgi/monthly.cgi. > > For more information, please visit http://www.freebsd.org/news/status/. > > We are looking forward to see your submissions! > > -- > Kind regards > Daniel Gerzo > _______________________________________________ > 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" -- Gary Kline kline@thought.org http://www.thought.org Public Service Unix Journey Toward the Dawn, E-Book: http://www.thought.org The 7.98a release of Jottings: http://jottings.thought.org From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 20:36:25 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id BF3651065672; Sat, 9 Apr 2011 20:36:25 +0000 (UTC) Date: Sat, 9 Apr 2011 20:36:25 +0000 From: Alexander Best To: dieterbsd@engineer.com Message-ID: <20110409203625.GA50231@freebsd.org> References: <8CDC50749BB9940-18FC-38C6@web-mmc-m02.sysops.aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8CDC50749BB9940-18FC-38C6@web-mmc-m02.sysops.aol.com> Cc: freebsd-hackers@freebsd.org Subject: Re: *printf(9) and PRINTF_BUFR_SIZE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 20:36:25 -0000 On Sat Apr 9 11, dieterbsd@engineer.com wrote: > While working on other problems with *printf(9), log(9), etc. > I stumbled upon: > > options PRINTF_BUFR_SIZE=128 # Prevent printf output being > interspersed. > > Question 1: Am I correct in thinking that PRINTF_BUFR_SIZE is supposed > to prevent this: > > ada2: 300.000MB/s transfuhub2: 3 ports with 3 removable, self powered > ers (SATA 2.x, UDMA6, PIO 8192bytes) > ada2: Command Queueing enabled > > Question 2: Why is vprintf() the only function that does this buffering? > As far as I can tell, the various functions that call kvprintf() > directly > without going through vprintf() do not get buffered. I'm thinking that > kvprintf() would be a better place for the buffering. Or would this > break > something? i remember this issue was discussed a few times before. you might want to take a look at [1]. cheers. alex [1] http://docs.freebsd.org/cgi/mid.cgi?AANLkTinPhcc8Z_BdvoEQUv-ZXlHAYOTQJwlUQDVO8iJ9 > > -- a13x From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 21:51:20 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F498106564A; Sat, 9 Apr 2011 21:51:20 +0000 (UTC) (envelope-from chris.richardson.bsd@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B9C1E8FC14; Sat, 9 Apr 2011 21:51:19 +0000 (UTC) Received: by wyf23 with SMTP id 23so4504531wyf.13 for ; Sat, 09 Apr 2011 14:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Avn8NVJ548QWD/JwzOUFqKhBYWQC9I7oF7ndfZYoS/0=; b=GEWDFK4/kO5v9KASeEIAkFBODIGwcegtijq4BwqZmp3FpbKUINPE+/vmYXCBsFck3G tse5eHBDzP86WMllBcNKn/Xip6gpldFGPzotlBXlZPigWBZsac9OelXFjs4lA8AI/3OJ 8N8ihqxfieIYrXRGxZS8zucY5tJKVrrg3WSxg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=M3KnSH5C3QKM/nZ+xIrbPLt2i3NRbkf4WiEIz9D5dlklE3xMLXNtH+rDNJ6XGTRt4H odfe3O7sa828+lQkVh2f4ojp+ROod5I0NX0w4jJzryr306rw7E4GWBcxkxmW7MNx64i6 A7o361w8n+ARNCBJIuZ0VR6mShEKthepBfkrQ= MIME-Version: 1.0 Received: by 10.227.157.68 with SMTP id a4mr3521839wbx.198.1302385878663; Sat, 09 Apr 2011 14:51:18 -0700 (PDT) Received: by 10.227.143.133 with HTTP; Sat, 9 Apr 2011 14:51:18 -0700 (PDT) In-Reply-To: References: Date: Sat, 9 Apr 2011 23:51:18 +0200 Message-ID: From: Chris Richardson To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-emulation@freebsd.org, Chuck Swiger , freebsd-current@freebsd.org Subject: Re: Kernel Tracking Question.. regarding kernel and boot files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 21:51:20 -0000 On Sat, Apr 9, 2011 at 10:34 PM, Chuck Swiger wrote: > Hi, Chris-- > > [ ...Reply-to: set to direct towards the most appropriate list... ] > > On Apr 9, 2011, at 8:31 AM, Chris Richardson wrote: > > I am totally new to FreeBSD. I was involved within project which will > > trace the kernel. I used ktrace but I could not get appropriate results > > about the files being opened. I don't see any of the boot files boot0-1 > or 2 > > in the ktrace.out file. Where did they go? > > The bootstrap loader stages are what loads and runs the kernel. > ktrace isn't available until afterwards, when the kernel is running. > > > Is ktrace the best "trace suite" for freebsd kernel? > > Kinda depends on what you are doing. Setting up good logging and making > userland > interfaces for getting to useful information (cf vmstat, ps, iostat, etc) > is > more likely to be useful over the longer run. > > What about if I wanna see the interaction between boot process and kernel loading. > > What about going through source code .. Is it better to > > use Combination of Ecllipse/Qemu and FreeBSD Source tree? > > Eclipse is an editor. If you like it in particular, free free to use it, > otherwise pick something else you'd prefer to use for C code. > > > Does this method will provide us with someway to see how booting process > invokes > > the kernel to memory ? Any help will be appreciated. > > You're asking about the process here: > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-blocks.html > > ...? Frankly, none of these are especially big, start by reviewing the > source > code for 'em. > > Yeah. this file provides me with the stages in theoretical way. How about implementing it using qemu to emulate livecd to see what is going on boot0. Do you have an idea about that ? Good Luck, > Regards, > -- > -Chuck > > > From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 21:35:35 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A149C106564A; Sat, 9 Apr 2011 21:35:35 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by mx1.freebsd.org (Postfix) with ESMTP id 8510B8FC0A; Sat, 9 Apr 2011 21:35:35 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [10.1.2.92] ([173.200.187.194]) by asmtp019.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LJE005R1JU4HC70@asmtp019.mac.com>; Sat, 09 Apr 2011 13:34:53 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-04-09_07:2011-04-09, 2011-04-09, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1104090086 From: Chuck Swiger In-reply-to: Date: Sat, 09 Apr 2011 13:34:52 -0700 Message-id: References: To: Chris Richardson X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Sat, 09 Apr 2011 23:45:15 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: Kernel Tracking Question.. regarding kernel and boot files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 21:35:35 -0000 Hi, Chris-- [ ...Reply-to: set to direct towards the most appropriate list... ] On Apr 9, 2011, at 8:31 AM, Chris Richardson wrote: > I am totally new to FreeBSD. I was involved within project which will > trace the kernel. I used ktrace but I could not get appropriate results > about the files being opened. I don't see any of the boot files boot0-1 or 2 > in the ktrace.out file. Where did they go? The bootstrap loader stages are what loads and runs the kernel. ktrace isn't available until afterwards, when the kernel is running. > Is ktrace the best "trace suite" for freebsd kernel? Kinda depends on what you are doing. Setting up good logging and making userland interfaces for getting to useful information (cf vmstat, ps, iostat, etc) is more likely to be useful over the longer run. > What about going through source code .. Is it better to > use Combination of Ecllipse/Qemu and FreeBSD Source tree? Eclipse is an editor. If you like it in particular, free free to use it, otherwise pick something else you'd prefer to use for C code. > Does this method will provide us with someway to see how booting process invokes > the kernel to memory ? Any help will be appreciated. You're asking about the process here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-blocks.html ...? Frankly, none of these are especially big, start by reviewing the source code for 'em. Regards, -- -Chuck