From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 20 03:08:11 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 CB6E2106564A for ; Sun, 20 Mar 2011 03:08:11 +0000 (UTC) (envelope-from forandom@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 879B18FC21 for ; Sun, 20 Mar 2011 03:08:11 +0000 (UTC) Received: by iyj12 with SMTP id 12so6328534iyj.13 for ; Sat, 19 Mar 2011 20:08:11 -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=iKW5TYHysq8PhBG9HS/ygJHX9qYAF+5SAmeIAbq2xG8=; b=jufhxg78t6GfUHt1eT3qJrgxZ9+k1bXTDnJV+YgPyPPvxEK5Y3Mq3Af9vReiQLb/lh LQ5AopUW5AkjcXhRw/AEpOwBijSWODqUny7pvz40Y80wCbHJ5TWB4JgsIyr+f+5QYj7j 0FSjizZTBHDgeYMuZSlN9cFMp6LYrLmFKD7GE= 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=dKN/1UL6i3cW3ZDgc7j7C5bLAvtcthfNuVjgkn+kkAcvE/IGD4ZLjSL5HZ2gLTCSNE IbRa+oaFeRawKIZT+hxhlW6cZN/xPLCDqdye/dr5bt8WnKxb2w2QW7kR1RrtO0sy0u3m wYoXRuDfPnWeUpQvi6kLRD6kgWlVLx5MumKak= MIME-Version: 1.0 Received: by 10.231.193.233 with SMTP id dv41mr2612667ibb.186.1300590490983; Sat, 19 Mar 2011 20:08:10 -0700 (PDT) Sender: forandom@gmail.com Received: by 10.231.144.201 with HTTP; Sat, 19 Mar 2011 20:08:10 -0700 (PDT) In-Reply-To: <20110319174115.GA33282@dchagin.static.corbina.ru> References: <20110319174115.GA33282@dchagin.static.corbina.ru> Date: Sun, 20 Mar 2011 11:08:10 +0800 X-Google-Sender-Auth: D3sJ71A70VfbMe6JirGuyZvf_IU Message-ID: From: Xingxing Pan To: Chagin Dmitry Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC'11: DWARF2 call frame information 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, 20 Mar 2011 03:08:11 -0000 2011/3/20 Chagin Dmitry : > On Sun, Mar 20, 2011 at 12:36:39AM +0800, Xingxing Pan wrote: >> Hi, everyone. >> >> I'm a student interested in the project "DWARF2 call frame >> information" for Summer of Code 2011. >> I'd like to know which compiler I will work on to add DWARF2 support. >> This project is not tagged by "suggested". Will it be ok to choose it >> as the target? >> > > hi Xingxing, > > You should carefully reread the proposed idea. Especially in the > "A debug kernel is not able to show stack traces with cross > exceptions anymore. This is because we do not emit any dwarf2 > call frame information for any assembler code, since gdb switched > to the dwarf2 format" part. > > And, of course, this work is very important for the community. So, IMO, > it will be ok as the target :) > Thank you. > > -- > Have fun! > chd > Hi chd, Thank you for your reply. I thought the dwarf2 call frame information was generated by the toolchain. That's why I care about the states of the compiler. I'm not quite understand the proposed idea. Could you show me more details of the project? I really appreciate your support. Thank you. Xingxing Pan From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 20 07:18:58 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 A8BF2106564A for ; Sun, 20 Mar 2011 07:18:58 +0000 (UTC) (envelope-from dchagin@dchagin.static.corbina.ru) Received: from contrabass.corbina.net (contrabass.post.ru [85.21.78.5]) by mx1.freebsd.org (Postfix) with ESMTP id 56FA88FC0A for ; Sun, 20 Mar 2011 07:18:57 +0000 (UTC) Received: from corbina.ru (mail.post.ru [195.14.50.16]) by contrabass.corbina.net (Postfix) with ESMTP id 33B89CBC93; Sun, 20 Mar 2011 10:18:54 +0300 (MSK) X-Virus-Scanned: by cgpav Uf39PSi9pFi9oFi9 Received: from [10.208.22.99] (HELO dchagin.static.corbina.ru) by corbina.ru (CommuniGate Pro SMTP 5.1.14) with ESMTPS id 309796565; Sun, 20 Mar 2011 10:18:54 +0300 Received: from dchagin.static.corbina.ru (localhost [127.0.0.1]) by dchagin.static.corbina.ru (8.14.4/8.14.4) with ESMTP id p2K7IrMe032988; Sun, 20 Mar 2011 10:18:53 +0300 (MSK) (envelope-from dchagin@dchagin.static.corbina.ru) Received: (from dchagin@localhost) by dchagin.static.corbina.ru (8.14.4/8.14.4/Submit) id p2K7Il99032807; Sun, 20 Mar 2011 10:18:47 +0300 (MSK) (envelope-from dchagin) Date: Sun, 20 Mar 2011 10:18:47 +0300 From: Chagin Dmitry To: Xingxing Pan Message-ID: <20110320071847.GA10579@dchagin.static.corbina.ru> References: <20110319174115.GA33282@dchagin.static.corbina.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC'11: DWARF2 call frame information 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, 20 Mar 2011 07:18:58 -0000 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 20, 2011 at 11:08:10AM +0800, Xingxing Pan wrote: > 2011/3/20 Chagin Dmitry : > > On Sun, Mar 20, 2011 at 12:36:39AM +0800, Xingxing Pan wrote: > >> Hi, everyone. > >> > >> I'm a student interested in the project "DWARF2 call frame > >> information" for Summer of Code 2011. > >> I'd like to know which compiler I will work on to add DWARF2 support. > >> This project is not tagged by "suggested". Will it be ok to choose it > >> as the target? > >> > > > > hi Xingxing, > > > > You should carefully reread the proposed idea. Especially in the > > "A debug kernel is not able to show stack traces with cross > > exceptions anymore. This is because we do not emit any dwarf2 > > call frame information for any assembler code, since gdb switched > > to the dwarf2 format" part. > > > > And, of course, this work is very important for the community. So, IMO, > > it will be ok as the target :) > > Thank you. > > > > -- > > Have fun! > > chd > > >=20 > Hi chd, >=20 > Thank you for your reply. I thought the dwarf2 call frame information > was generated by the toolchain. mostly yes. but not in the assembler code written by hand. > That's why I care about the states of the compiler. > I'm not quite understand the proposed idea. Could you show me more > details of the project? > I really appreciate your support. >=20 hm, you should add the .cfi directive in each .S file by hand: http://www.logix.cz/michal/devel/gas-cfi/ --=20 Have fun! chd --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAk2FqlYACgkQ0t2Tb3OO/O25FwCeOjO+c3sDZ13b09cCom1/TVdW tg8AoIoake8QLWbKjWF8qI29jgHagmYs =6zHk -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 20 08:33: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 C9472106564A for ; Sun, 20 Mar 2011 08:33:30 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 214A58FC08 for ; Sun, 20 Mar 2011 08:33:29 +0000 (UTC) Received: by fxm11 with SMTP id 11so5569968fxm.13 for ; Sun, 20 Mar 2011 01:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=K8lRCZVqz0SmlOlDWXuhv/ArxtPg/wOHywDPG1bCS+A=; b=mk5oMPTtMwklP6PzTdbe5fDnyRMs6yLpfMZhWBdsiMTTgecpv1pkWHkaRewBVpvzYl SzcQ43yhkj368JX0WEs2iGTSerYfBk8pP+fyKI0+R4R645h/51B4QKvQ0GAvpk6PFUQE qlbz4vo9W8GlDzeX2xx4a+jgFkrWF8lNTFIRg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=DudGaVW0Cma6LgTNzRb0H5rnmGYicfQDWpDwqjZy5ma5x+DUCGpt86PP8yOd5CfaYt dsuYC00MD5tTXXVBFYjTc47dXE8di3Ptp9tnzl1mcj0yYZY4jza9AAcMMdvzCrQ5/7ib 3CZzjKxJN/fLdh41PEnYKydtB4QUpAexnH8cw= MIME-Version: 1.0 Received: by 10.223.127.213 with SMTP id h21mr1711349fas.139.1300608179691; Sun, 20 Mar 2011 01:02:59 -0700 (PDT) Received: by 10.223.115.148 with HTTP; Sun, 20 Mar 2011 01:02:59 -0700 (PDT) In-Reply-To: References: Date: Sun, 20 Mar 2011 03:02:59 -0500 Message-ID: From: Alan Cox To: J L Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Question about Reverse Mappings in FreeBSD. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 08:33:30 -0000 On Fri, Mar 18, 2011 at 7:30 PM, J L wrote: > I read an article about Reverse Mappings technique in memory management > part. It improves a lot from Linux 2.4 to 2.6. I am wondering is FreeBSD > also have this feature? Which source files should I go to find these? I > want > to do some study on this. > Wish someone can enlighten me. Thank you. > Reverse mappings are implemented by the machine-dependent layer of the virtual memory system, which is called the "pmap". Look for files named pmap.c in the source tree, such as sys/amd64/amd64/pmap.c. In particular, look for the code that manages pv entries. Alan From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 20 15:24: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 2D45F106566C; Sun, 20 Mar 2011 15:24:23 +0000 (UTC) (envelope-from forandom@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 C827B8FC12; Sun, 20 Mar 2011 15:24:22 +0000 (UTC) Received: by qwc9 with SMTP id 9so4055707qwc.13 for ; Sun, 20 Mar 2011 08:24:22 -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=o145XuKVJbU7vKNTYU+CiVShk8UM9LgEUyzz2fDy0R4=; b=ZZ3OHDUw8C2qBvl4W+J3f9DUBPwLSat3WRPFD3qXz4zvNzUUuMZqrmvr+JjAvrBcy7 fCTmFu1yBYLYpyt3KfFqAkyqOfIo2ooQZeE8TgD2kifM5tfcxxZGRWIPLlhnOrL3F8UH DZnDIXC1+ol7Nmsbz0ErFV4sV2uUQVQ0rxYts= 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=xcO3c8/lBxJMAbOdQbW4gPvKltKo56JG+xO3F9u6ZFtUURD+0sHFhzIEBC3wF7Wk0k Uu+GWTtV4KRqykNvpJ9vSAfuKHYKAwB9mKEXWQPVoHGkW5TO2irIKvh0FzYgnlbFCCzL 0ZyNs17M5cnSz4W8EZWEK+DNoIR0wJ67GBfFU= MIME-Version: 1.0 Received: by 10.229.142.139 with SMTP id q11mr2424085qcu.163.1300634661905; Sun, 20 Mar 2011 08:24:21 -0700 (PDT) Sender: forandom@gmail.com Received: by 10.229.222.148 with HTTP; Sun, 20 Mar 2011 08:24:21 -0700 (PDT) In-Reply-To: <20110320071847.GA10579@dchagin.static.corbina.ru> References: <20110319174115.GA33282@dchagin.static.corbina.ru> <20110320071847.GA10579@dchagin.static.corbina.ru> Date: Sun, 20 Mar 2011 23:24:21 +0800 X-Google-Sender-Auth: hlAnYwXCmYYSd0-P0UoQL72oGtg Message-ID: From: Xingxing Pan To: Chagin Dmitry Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC'11: DWARF2 call frame information 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, 20 Mar 2011 15:24:23 -0000 2011/3/20 Chagin Dmitry : > On Sun, Mar 20, 2011 at 11:08:10AM +0800, Xingxing Pan wrote: >> 2011/3/20 Chagin Dmitry : >> > On Sun, Mar 20, 2011 at 12:36:39AM +0800, Xingxing Pan wrote: >> >> Hi, everyone. >> >> >> >> I'm a student interested in the project "DWARF2 call frame >> >> information" for Summer of Code 2011. >> >> I'd like to know which compiler I will work on to add DWARF2 support. >> >> This project is not tagged by "suggested". Will it be ok to choose it >> >> as the target? >> >> >> > >> > hi Xingxing, >> > >> > You should carefully reread the proposed idea. Especially in the >> > "A debug kernel is not able to show stack traces with cross >> > exceptions anymore. This is because we do not emit any dwarf2 >> > call frame information for any assembler code, since gdb switched >> > to the dwarf2 format" part. >> > >> > And, of course, this work is very important for the community. So, IMO, >> > it will be ok as the target :) >> > Thank you. >> > >> > -- >> > Have fun! >> > chd >> > >> >> Hi chd, >> >> Thank you for your reply. I thought the dwarf2 call frame information >> was generated by the toolchain. > > mostly yes. but not in the assembler code written by hand. > >> That's why I care about the states of the compiler. >> I'm not quite understand the proposed idea. Could you show me more >> details of the project? >> I really appreciate your support. >> > > hm, you should add the .cfi directive in each .S file by hand: > http://www.logix.cz/michal/devel/gas-cfi/ > > -- > Have fun! > chd > Thanks for your reply. I think I have got the idea. For the object files generated by the toolchain, there's no need to worry about DWARF call frame information if the DWARF is supported by the toolchain.But the assembly written by hand is an exception. Different architecture has different assembly. That means I have to add DWARF for all these architectures currently supported by FreeBSD. Maybe I need a powerfull script. Xingxing Pan From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 20 17:51:23 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 7F6A61065673; Sun, 20 Mar 2011 17:51:23 +0000 (UTC) Date: Sun, 20 Mar 2011 17:51:23 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20110320175123.GA65715@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: issues with kern.devstat.all 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, 20 Mar 2011 17:51:23 -0000 hi there, could somebody explain the following behavior running a recent CURRENT on amd64? otaku% sysctl kern.devstat kern.devstat.numdevs: 6 kern.devstat.generation: 222 kern.devstat.version: 6 otaku% sysctl kern.devstat.all otaku% echo $? 0 otaku% sysctl -d kern.devstat.all kern.devstat.all: All devices in the devstat list cheers. alex -- a13x From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 20 18:19:21 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 CA016106566C for ; Sun, 20 Mar 2011 18:19:21 +0000 (UTC) (envelope-from dchagin@dchagin.static.corbina.ru) Received: from contrabass.corbina.net (contrabass.post.ru [85.21.78.5]) by mx1.freebsd.org (Postfix) with ESMTP id 784BC8FC0A for ; Sun, 20 Mar 2011 18:19:21 +0000 (UTC) Received: from corbina.ru (mail.post.ru [195.14.50.16]) by contrabass.corbina.net (Postfix) with ESMTP id DD6E9CB430; Sun, 20 Mar 2011 21:19:17 +0300 (MSK) X-Virus-Scanned: by cgpav Uf39PSi9pFi9oFi9 Received: from [10.208.22.99] (HELO dchagin.static.corbina.ru) by corbina.ru (CommuniGate Pro SMTP 5.1.14) with ESMTPS id 309890796; Sun, 20 Mar 2011 21:19:17 +0300 Received: from dchagin.static.corbina.ru (localhost [127.0.0.1]) by dchagin.static.corbina.ru (8.14.4/8.14.4) with ESMTP id p2KIJHHr079884; Sun, 20 Mar 2011 21:19:17 +0300 (MSK) (envelope-from dchagin@dchagin.static.corbina.ru) Received: (from dchagin@localhost) by dchagin.static.corbina.ru (8.14.4/8.14.4/Submit) id p2KIJBtg079883; Sun, 20 Mar 2011 21:19:11 +0300 (MSK) (envelope-from dchagin) Date: Sun, 20 Mar 2011 21:19:11 +0300 From: Chagin Dmitry To: Xingxing Pan Message-ID: <20110320181911.GA79862@dchagin.static.corbina.ru> References: <20110319174115.GA33282@dchagin.static.corbina.ru> <20110320071847.GA10579@dchagin.static.corbina.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC'11: DWARF2 call frame information 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, 20 Mar 2011 18:19:21 -0000 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 20, 2011 at 11:24:21PM +0800, Xingxing Pan wrote: > >> > > > > hm, you should add the .cfi directive in each .S file by hand: > > http://www.logix.cz/michal/devel/gas-cfi/ > > > > -- > > Have fun! > > chd > > >=20 > Thanks for your reply. I think I have got the idea. > For the object files generated by the toolchain, there's no need to worry= about > DWARF call frame information if the DWARF is supported by the toolchain.B= ut > the assembly written by hand is an exception. > Different architecture has different assembly. That means I have to add D= WARF > for all these architectures currently supported by FreeBSD. Maybe I need a > powerfull script. >=20 > Xingxing Pan hmm, which script? I think enough amd64, i386 and amd64/ia32. I suggest to write a example before continuing the conversation about the GSoC. For example (bcopy || bzero) && cpu_switch. Is it ok for you? --=20 Have fun! chd --envbJBWh7q8WU6mo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAk2GRR4ACgkQ0t2Tb3OO/O3egQCdHuG41cf1S7Khfh5HccRe39eH LboAoJ9HMg7z/Dbdr0R5tCmBhhNanGuF =H80E -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 21 04:37: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 A557D1065670 for ; Mon, 21 Mar 2011 04:37:20 +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 66D238FC0C for ; Mon, 21 Mar 2011 04:37:20 +0000 (UTC) Received: by iwn33 with SMTP id 33so7140126iwn.13 for ; Sun, 20 Mar 2011 21:37:19 -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:in-reply-to :message-id:references:user-agent:x-openpgp-key-id :x-openpgp-key-fingerprint:mime-version:content-type; bh=6aMtQ/MvqluodZDnHQirJ7DBaIjW6RNEx4dVrbLxHAo=; b=Fg7LRzq4rHwaqXE10OkWkAI6ve8hriddwe5Y/EFdjFYIxvE09cGXKvxoro6A4R1CQv baK0Hn92UYIR5Px5u6zvZwMmmEFv9HnNAwdWvDH40mK/dBAKPsbbEMhVxA9YiWeM0iRJ eM+7OBVhZawH67ONr46I/ZncDlYCLwk6asv+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=K/cYR6qhBq3SwD9pNSa2S11D02UAsi8ILjapd/WzmZ94dBjwBQNzzuOekcvMxXB0kB GkDyygO1/Ogk6N1V5tsMx1WB5CMZuf8J36inOq4AdUNupBJvmh/dL22MB0tO5L8XnV0C +FKtxIr2fF9O00e4yjdMqmBvYs5DT2Ijrla5c= Received: by 10.42.149.6 with SMTP id t6mr465035icv.366.1300682239722; Sun, 20 Mar 2011 21:37:19 -0700 (PDT) Received: from disbatch.dataix.local (adsl-99-181-148-152.dsl.klmzmi.sbcglobal.net [99.181.148.152]) by mx.google.com with ESMTPS id s1sm701707iba.58.2011.03.20.21.37.16 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 20 Mar 2011 21:37:18 -0700 (PDT) Sender: "J. Hellenthal" Date: Mon, 21 Mar 2011 00:37:09 -0400 From: "J. Hellenthal" To: Alexander Best In-Reply-To: <20110320175123.GA65715@freebsd.org> Message-ID: References: <20110320175123.GA65715@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: issues with kern.devstat.all 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, 21 Mar 2011 04:37:20 -0000 On Sun, 20 Mar 2011 13:51, arundel@ wrote: > hi there, > > could somebody explain the following behavior running a recent CURRENT on amd64? > > otaku% sysctl kern.devstat > kern.devstat.numdevs: 6 > kern.devstat.generation: 222 > kern.devstat.version: 6 > otaku% sysctl kern.devstat.all > otaku% echo $? > 0 > otaku% sysctl -d kern.devstat.all > kern.devstat.all: All devices in the devstat list > This is an opaque sysctl. You can use the (-o) flag to see the format and the first sixteen bytes or use (-x) to see the full output. There are plenty of these in the sysctl tree, they are just not normally conveyed directly to the user without the proper flags given as the output is not very useful to the human eye and contains to much output in any other format to be useful. What this one specifically relates to IDK, maybe someone else can tune in for further information. See ( sysctl -A ) for further interesting details. -- Regards, J. Hellenthal (0x89D8547E) JJH48-ARIN From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 21 09:36: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 800FC106564A; Mon, 21 Mar 2011 09:36:14 +0000 (UTC) (envelope-from forandom@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 25D098FC1A; Mon, 21 Mar 2011 09:36:13 +0000 (UTC) Received: by qyk35 with SMTP id 35so2081900qyk.13 for ; Mon, 21 Mar 2011 02:36:13 -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=FKrllTslEjH7j/3zZDH33YhQ3YdaG2DBLkuHwf3sfnM=; b=mBayA3bA1ahLzEoPloGP0Z+v1LUhGmawJaGo7/jHLSRvggMFyB6UgOsxX2swwqYX4+ 9zqnz+oxbvB4lso1x6TNVVtfuoBRK5Vbw4Dga976+65P99v0opIZUL0d1omBUVGdU/Nz VG046W1UR749JH7ikXNjpis8dXob/7zRNcAQ4= 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=dpwQ15ZOG99mmoMelXp8lVD1h6ahsBQaql+SWaELacqkZKspw9H7at82gNUXjgpYeB pbx9LVBIO3RmvxTFjXRBkI6LbckjgAamhzTQbLvU0ieTfQFITrbQP31nrHREUIFYDL1S lNXFMZ8ziCPZ8pryczkaxXhtvZoy91b54vzZI= MIME-Version: 1.0 Received: by 10.229.142.139 with SMTP id q11mr2924353qcu.163.1300700173226; Mon, 21 Mar 2011 02:36:13 -0700 (PDT) Sender: forandom@gmail.com Received: by 10.229.222.148 with HTTP; Mon, 21 Mar 2011 02:36:13 -0700 (PDT) In-Reply-To: <20110320181911.GA79862@dchagin.static.corbina.ru> References: <20110319174115.GA33282@dchagin.static.corbina.ru> <20110320071847.GA10579@dchagin.static.corbina.ru> <20110320181911.GA79862@dchagin.static.corbina.ru> Date: Mon, 21 Mar 2011 17:36:13 +0800 X-Google-Sender-Auth: J9-CRkjtQIZBHkDB625e8ssLhR8 Message-ID: From: Xingxing Pan To: Chagin Dmitry Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC'11: DWARF2 call frame information 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, 21 Mar 2011 09:36:14 -0000 2011/3/21 Chagin Dmitry : > On Sun, Mar 20, 2011 at 11:24:21PM +0800, Xingxing Pan wrote: >> >> >> > >> > hm, you should add the .cfi directive in each .S file by hand: >> > http://www.logix.cz/michal/devel/gas-cfi/ >> > >> > -- >> > Have fun! >> > chd >> > >> >> Thanks for your reply. I think I have got the idea. >> For the object files generated by the toolchain, there's no need to worry about >> DWARF call frame information if the DWARF is supported by the toolchain.But >> the assembly written by hand is an exception. >> Different architecture has different assembly. That means I have to add DWARF >> for all these architectures currently supported by FreeBSD. Maybe I need a >> powerfull script. >> >> Xingxing Pan > > hmm, which script? I think enough amd64, i386 and amd64/ia32. > > I suggest to write a example before continuing the conversation > about the GSoC. For example (bcopy || bzero) && cpu_switch. > Is it ok for you? > > -- > Have fun! > chd > Hi Chargin, Thank you for your reply. The followings shows how I try to add DWARF for bcopy. --- ../8.2.0/sys/i386/include/asm.h 2011-03-21 14:35:56.111973722 +0800 +++ asm.h 2011-03-21 15:25:31.564636162 +0800 @@ -71,7 +71,7 @@ #define _ENTRY(x) _START_ENTRY; \ .globl CNAME(x); .type CNAME(x),@function; CNAME(x): -#define END(x) .size x, . - x +#define END(x) .cfi_endproc; .size x, . - x #ifdef PROF #define ALTENTRY(x) _ENTRY(x); \ @@ -80,9 +80,10 @@ popl %ebp; \ jmp 9f #define ENTRY(x) _ENTRY(x); \ - pushl %ebp; movl %esp,%ebp; \ + .cfi_startproc; \ + pushl %ebp; .cfi_adjust_cfa_offset 4; movl %esp,%ebp; .cfi_def_cfa_register %ebp; \ call PIC_PLT(HIDENAME(mcount)); \ - popl %ebp; \ + popl %ebp; .cfi_def_cfa %esp, 4; \ --- bcopy.S 2011-03-21 15:51:26.804203809 +0800 +++ ../8.2.0/lib/libc/i386/string/bcopy.S 2011-03-21 14:28:15.023069890 +0800 @@ -51,9 +51,7 @@ ENTRY(bcopy) #endif #endif pushl %esi - .cfi_adjust_cfa_offset 4; pushl %edi - .cfi_adjust_cfa_offset 4; #if defined(MEMCOPY) || defined(MEMMOVE) movl 12(%esp),%edi movl 16(%esp),%esi @@ -77,9 +75,7 @@ ENTRY(bcopy) rep movsb popl %edi - .cfi_adjust_cfa_offset -4; popl %esi - .cfi_adjust_cfa_offset -4; ret 1: addl %ecx,%edi /* copy backwards. */ @@ -98,9 +94,7 @@ ENTRY(bcopy) rep movsl popl %edi - .cfi_adjust_cfa_offset -4; popl %esi - .cfi_adjust_cfa_offset -4; cld ret #ifdef MEMCOPY But I don't know how to add DWARF for cpu_switch, because I have no idea about the circumstance when we need to backtrace through this function. Suppose there's a cpu switch like this, threadA->kernel->threadB. Then should the expected backtrace has the following result? threadB's stack kernel's stack threadA's stack From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 21 17:32: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 6AE0C106566B for ; Mon, 21 Mar 2011 17:32:27 +0000 (UTC) (envelope-from dchagin@dchagin.static.corbina.ru) Received: from contrabass.corbina.net (contrabass.post.ru [85.21.78.5]) by mx1.freebsd.org (Postfix) with ESMTP id DA2128FC16 for ; Mon, 21 Mar 2011 17:32:26 +0000 (UTC) Received: from corbina.ru (mail.post.ru [195.14.50.16]) by contrabass.corbina.net (Postfix) with ESMTP id 76AABCBADF; Mon, 21 Mar 2011 20:32:18 +0300 (MSK) X-Virus-Scanned: by cgpav Uf39PSi9pFi9oFi9 Received: from [10.208.22.99] (HELO dchagin.static.corbina.ru) by corbina.ru (CommuniGate Pro SMTP 5.1.14) with ESMTPS id 310184608; Mon, 21 Mar 2011 20:32:18 +0300 Received: from dchagin.static.corbina.ru (localhost [127.0.0.1]) by dchagin.static.corbina.ru (8.14.4/8.14.4) with ESMTP id p2LHWAHj007705; Mon, 21 Mar 2011 20:32:10 +0300 (MSK) (envelope-from dchagin@dchagin.static.corbina.ru) Received: (from dchagin@localhost) by dchagin.static.corbina.ru (8.14.4/8.14.4/Submit) id p2LHW4Sn007704; Mon, 21 Mar 2011 20:32:04 +0300 (MSK) (envelope-from dchagin) Date: Mon, 21 Mar 2011 20:32:04 +0300 From: Chagin Dmitry To: Xingxing Pan Message-ID: <20110321173204.GA7575@dchagin.static.corbina.ru> References: <20110319174115.GA33282@dchagin.static.corbina.ru> <20110320071847.GA10579@dchagin.static.corbina.ru> <20110320181911.GA79862@dchagin.static.corbina.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC'11: DWARF2 call frame information 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, 21 Mar 2011 17:32:27 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 21, 2011 at 05:36:13PM +0800, Xingxing Pan wrote: > 2011/3/21 Chagin Dmitry : > >> powerfull script. > >> > >> Xingxing Pan > > > > hmm, which script? I think enough amd64, i386 and amd64/ia32. > > > > I suggest to write a example before continuing the conversation > > about the GSoC. For example (bcopy || bzero) && cpu_switch. > > Is it ok for you? > > > > -- > > Have fun! > > chd > > >=20 > Hi Chargin, >=20 > Thank you for your reply. > The followings shows how I try to add DWARF for bcopy. >=20 > --- ../8.2.0/sys/i386/include/asm.h 2011-03-21 14:35:56.111973722 +08= 00 > +++ asm.h 2011-03-21 15:25:31.564636162 +0800 > @@ -71,7 +71,7 @@ >=20 > #define _ENTRY(x) _START_ENTRY; \ > .globl CNAME(x); .type CNAME(x),@function; CNAME(= x): > -#define END(x) .size x, . - x > +#define END(x) .cfi_endproc; .size x, . - x >=20 > #ifdef PROF > #define ALTENTRY(x) _ENTRY(x); \ > @@ -80,9 +80,10 @@ > popl %ebp; \ > jmp 9f > #define ENTRY(x) _ENTRY(x); \ > - pushl %ebp; movl %esp,%ebp; \ > + .cfi_startproc; \ > + pushl %ebp; .cfi_adjust_cfa_offset 4; movl > %esp,%ebp; .cfi_def_cfa_register %ebp; \ > call PIC_PLT(HIDENAME(mcount)); \ > - popl %ebp; \ > + popl %ebp; .cfi_def_cfa %esp, 4; \ >=20 > --- bcopy.S 2011-03-21 15:51:26.804203809 +0800 > +++ ../8.2.0/lib/libc/i386/string/bcopy.S 2011-03-21 > 14:28:15.023069890 +0800 > @@ -51,9 +51,7 @@ ENTRY(bcopy) > #endif > #endif > pushl %esi > - .cfi_adjust_cfa_offset 4; > pushl %edi > - .cfi_adjust_cfa_offset 4; > #if defined(MEMCOPY) || defined(MEMMOVE) > movl 12(%esp),%edi > movl 16(%esp),%esi > @@ -77,9 +75,7 @@ ENTRY(bcopy) > rep > movsb > popl %edi > - .cfi_adjust_cfa_offset -4; > popl %esi > - .cfi_adjust_cfa_offset -4; > ret > 1: > addl %ecx,%edi /* copy backwards. */ > @@ -98,9 +94,7 @@ ENTRY(bcopy) > rep > movsl > popl %edi > - .cfi_adjust_cfa_offset -4; > popl %esi > - .cfi_adjust_cfa_offset -4; > cld > ret > #ifdef MEMCOPY >=20 > But I don't know how to add DWARF for cpu_switch, because I have no > idea about the circumstance when we need to backtrace through this > function. Suppose there's a cpu switch like this, > threadA->kernel->threadB. Then should the expected backtrace has the > following result? >=20 > threadB's stack > kernel's stack > threadA's stack hmm, ok. good, avoid cpu_switch. First of all, please, read style(9) man page. In the second, evaluate the proposed plan (discussed with kib@): 1) Annotate libc, msun, rtld, libthr (you) 2) vdso (I'm) 3) Annotate signal trampolines (you, after vdso) And i'm going to understand what I need to do to start GSoC for you. Thanks! --=20 Have fun! chd --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAk2Hi5MACgkQ0t2Tb3OO/O3rTACg0XJGhmPRSfhehoO7uwQKaD+R qxIAoKzWWBBtMUZIW5vH29ArSc4O/OOz =iV/9 -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 21 17:36: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 9FA12106566C; Mon, 21 Mar 2011 17:36:25 +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 2323D8FC18; Mon, 21 Mar 2011 17:36:24 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id C96808DB37; Mon, 21 Mar 2011 18:19:25 +0100 (CET) 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 qZm1XgtV6El2; Mon, 21 Mar 2011 18:19:23 +0100 (CET) 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 B5C2D8DB26; Mon, 21 Mar 2011 18:19:23 +0100 (CET) Received: (from www@localhost) by hosting.syscare.sk (8.14.4/8.14.4/Submit) id p2LHJNgO044442; Mon, 21 Mar 2011 18:19:23 +0100 (CET) (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: Mon, 21 Mar 2011 18:19:23 +0100 From: Daniel Gerzo Organization: The FreeBSD Project Mail-Followup-To: Message-ID: <9520844e1b99c3d38c96b33e5692eb8c@rulez.sk> X-Sender: danger@FreeBSD.org User-Agent: Roundcube Webmail/0.5.1 Cc: Subject: 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: Mon, 21 Mar 2011 17:36:25 -0000 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 Mon Mar 21 20:00: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 26848106566C; Mon, 21 Mar 2011 20:00:32 +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 B6CB98FC13; Mon, 21 Mar 2011 20:00:31 +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 p2LK0Qkb082969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2011 22:00:26 +0200 (EET) (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 p2LK0Qkj012285; Mon, 21 Mar 2011 22:00:26 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2LK0Qrl012284; Mon, 21 Mar 2011 22:00:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 21 Mar 2011 22:00:25 +0200 From: Kostik Belousov To: Chagin Dmitry Message-ID: <20110321200025.GP78089@deviant.kiev.zoral.com.ua> References: <20110319174115.GA33282@dchagin.static.corbina.ru> <20110320071847.GA10579@dchagin.static.corbina.ru> <20110320181911.GA79862@dchagin.static.corbina.ru> <20110321173204.GA7575@dchagin.static.corbina.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sTMCexX3B034v4B2" Content-Disposition: inline In-Reply-To: <20110321173204.GA7575@dchagin.static.corbina.ru> 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: Xingxing Pan , freebsd-hackers@freebsd.org Subject: Re: GSoC'11: DWARF2 call frame information 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, 21 Mar 2011 20:00:32 -0000 --sTMCexX3B034v4B2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 21, 2011 at 08:32:04PM +0300, Chagin Dmitry wrote: > On Mon, Mar 21, 2011 at 05:36:13PM +0800, Xingxing Pan wrote: > > 2011/3/21 Chagin Dmitry : > > >> powerfull script. > > >> > > >> Xingxing Pan > > > > > > hmm, which script? I think enough amd64, i386 and amd64/ia32. > > > > > > I suggest to write a example before continuing the conversation > > > about the GSoC. For example (bcopy || bzero) && cpu_switch. > > > Is it ok for you? > > > > > > -- > > > Have fun! > > > chd > > > > >=20 > > Hi Chargin, > >=20 > > Thank you for your reply. > > The followings shows how I try to add DWARF for bcopy. > >=20 > > --- ../8.2.0/sys/i386/include/asm.h 2011-03-21 14:35:56.111973722 += 0800 > > +++ asm.h 2011-03-21 15:25:31.564636162 +0800 > > @@ -71,7 +71,7 @@ > >=20 > > #define _ENTRY(x) _START_ENTRY; \ > > .globl CNAME(x); .type CNAME(x),@function; CNAM= E(x): > > -#define END(x) .size x, . - x > > +#define END(x) .cfi_endproc; .size x, . - x > >=20 > > #ifdef PROF > > #define ALTENTRY(x) _ENTRY(x); \ > > @@ -80,9 +80,10 @@ > > popl %ebp; \ > > jmp 9f > > #define ENTRY(x) _ENTRY(x); \ > > - pushl %ebp; movl %esp,%ebp; \ > > + .cfi_startproc; \ > > + pushl %ebp; .cfi_adjust_cfa_offset 4; movl > > %esp,%ebp; .cfi_def_cfa_register %ebp; \ > > call PIC_PLT(HIDENAME(mcount)); \ > > - popl %ebp; \ > > + popl %ebp; .cfi_def_cfa %esp, 4; \ > >=20 > > --- bcopy.S 2011-03-21 15:51:26.804203809 +0800 > > +++ ../8.2.0/lib/libc/i386/string/bcopy.S 2011-03-21 > > 14:28:15.023069890 +0800 > > @@ -51,9 +51,7 @@ ENTRY(bcopy) > > #endif > > #endif > > pushl %esi > > - .cfi_adjust_cfa_offset 4; > > pushl %edi > > - .cfi_adjust_cfa_offset 4; > > #if defined(MEMCOPY) || defined(MEMMOVE) > > movl 12(%esp),%edi > > movl 16(%esp),%esi > > @@ -77,9 +75,7 @@ ENTRY(bcopy) > > rep > > movsb > > popl %edi > > - .cfi_adjust_cfa_offset -4; > > popl %esi > > - .cfi_adjust_cfa_offset -4; > > ret > > 1: > > addl %ecx,%edi /* copy backwards. */ > > @@ -98,9 +94,7 @@ ENTRY(bcopy) > > rep > > movsl > > popl %edi > > - .cfi_adjust_cfa_offset -4; > > popl %esi > > - .cfi_adjust_cfa_offset -4; > > cld > > ret > > #ifdef MEMCOPY > >=20 > > But I don't know how to add DWARF for cpu_switch, because I have no > > idea about the circumstance when we need to backtrace through this > > function. Suppose there's a cpu switch like this, > > threadA->kernel->threadB. Then should the expected backtrace has the > > following result? > >=20 > > threadB's stack > > kernel's stack > > threadA's stack >=20 >=20 > hmm, ok. good, avoid cpu_switch. > First of all, please, read style(9) man page. > In the second, evaluate the proposed plan (discussed with kib@): >=20 > 1) Annotate libc, msun, rtld, libthr (you) 1a) Develop and implement a testing plan to verify the implementation. 1b) consider doing full register tracking for assembler code. > 2) vdso (I'm) > 3) Annotate signal trampolines (you, after vdso) >=20 > And i'm going to understand what I need to do to start GSoC for you. > Thanks! >=20 >=20 > --=20 > Have fun! > chd --sTMCexX3B034v4B2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2HrlkACgkQC3+MBN1Mb4hfYQCg3lmQYglUgzn6Tv2wJOyv5CWn rQYAn1FK4OTGuqdirl6MVhu/B4aO1XBh =sCxJ -----END PGP SIGNATURE----- --sTMCexX3B034v4B2-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 21 21:15: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 823601065676 for ; Mon, 21 Mar 2011 21:15:40 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 208C48FC24 for ; Mon, 21 Mar 2011 21:15:39 +0000 (UTC) Received: by fxm11 with SMTP id 11so6978882fxm.13 for ; Mon, 21 Mar 2011 14:15:38 -0700 (PDT) Received: by 10.223.14.207 with SMTP id h15mr2616144faa.50.1300742114990; Mon, 21 Mar 2011 14:15:14 -0700 (PDT) Received: from [10.254.254.77] (ppp95-165-158-246.pppoe.spdop.ru [95.165.158.246]) by mx.google.com with ESMTPS id n9sm2012846fax.3.2011.03.21.14.15.12 (version=SSLv3 cipher=OTHER); Mon, 21 Mar 2011 14:15:13 -0700 (PDT) Message-ID: <4D87BFDA.90007@zonov.org> Date: Tue, 22 Mar 2011 00:15:06 +0300 From: Andrey Zonov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Alexander Best References: <20110320175123.GA65715@freebsd.org> In-Reply-To: <20110320175123.GA65715@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Re: issues with kern.devstat.all 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, 21 Mar 2011 21:15:40 -0000 Hi, This sysctl contains a binary data. You can see it using -o or -x sysctl's key. Additional information is at devstat(3) manpage. -- Andrey Zonov 20.03.2011 20:51, Alexander Best пишет: > hi there, > > could somebody explain the following behavior running a recent CURRENT on amd64? > > otaku% sysctl kern.devstat > kern.devstat.numdevs: 6 > kern.devstat.generation: 222 > kern.devstat.version: 6 > otaku% sysctl kern.devstat.all > otaku% echo $? > 0 > otaku% sysctl -d kern.devstat.all > kern.devstat.all: All devices in the devstat list > > cheers. > alex > From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 22 15:15: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 6C82C106567B; Tue, 22 Mar 2011 15:15:27 +0000 (UTC) (envelope-from forandom@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 078DE8FC08; Tue, 22 Mar 2011 15:15:26 +0000 (UTC) Received: by qyk35 with SMTP id 35so3561456qyk.13 for ; Tue, 22 Mar 2011 08:15:26 -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=9bu5PurFlugtiFO/C1dbX0mCOcO5y9yZ0qXTCicXi34=; b=j8oDj+6S7xpPhCrM+nvRv9EMrNLze+BBPfTUB+ckytiA2fg5bnc4AsZDEvjswrs1Im 5R0ivlay4pamApjutSH5lrbIA0FUjnG1t/3Kz2MAn3x08CVl2by+oxNLKFKfNbNjWXKe oqf2a/URSZCxdcElTFYIiGHkHB3bhF9qUEYfk= 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=CvIT8p8Cz6eDODGVdWxMtDrR27HeGlaEr2By8HEKfspq2sLCbLedf8TreyfnsmRyv4 adzHW7oeQ9j/codirvlHY0VS6RL9shs2JmvkkmSqz+6xH0Ewr+Dqm98IVZ1orcfZmLbT d7MhF/ZslwH+LUDmWljyMPK7JTKi1fRU2rEjU= MIME-Version: 1.0 Received: by 10.229.122.81 with SMTP id k17mr4821835qcr.239.1300806926190; Tue, 22 Mar 2011 08:15:26 -0700 (PDT) Sender: forandom@gmail.com Received: by 10.229.222.148 with HTTP; Tue, 22 Mar 2011 08:15:25 -0700 (PDT) In-Reply-To: <20110321173204.GA7575@dchagin.static.corbina.ru> References: <20110319174115.GA33282@dchagin.static.corbina.ru> <20110320071847.GA10579@dchagin.static.corbina.ru> <20110320181911.GA79862@dchagin.static.corbina.ru> <20110321173204.GA7575@dchagin.static.corbina.ru> Date: Tue, 22 Mar 2011 23:15:25 +0800 X-Google-Sender-Auth: k0uJEnKZ-8C2LbctEt_DP22NHtM Message-ID: From: Xingxing Pan To: Chagin Dmitry Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC'11: DWARF2 call frame information 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, 22 Mar 2011 15:15:27 -0000 2011/3/22 Chagin Dmitry : > On Mon, Mar 21, 2011 at 05:36:13PM +0800, Xingxing Pan wrote: >> 2011/3/21 Chagin Dmitry : >> >> powerfull script. >> >> >> >> Xingxing Pan >> > >> > hmm, which script? I think enough amd64, i386 and amd64/ia32. >> > >> > I suggest to write a example before continuing the conversation >> > about the GSoC. For example (bcopy || bzero) && cpu_switch. >> > Is it ok for you? >> > >> > -- >> > Have fun! >> > chd >> > >> >> Hi Chargin, >> >> Thank you for your reply. >> The followings shows how I try to add DWARF for bcopy. >> >> --- ../8.2.0/sys/i386/include/asm.h =A0 =A0 2011-03-21 14:35:56.11197372= 2 +0800 >> +++ asm.h =A0 =A0 =A0 2011-03-21 15:25:31.564636162 +0800 >> @@ -71,7 +71,7 @@ >> >> =A0#define _ENTRY(x) =A0 =A0 =A0_START_ENTRY; \ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .globl CNAME(x); .type C= NAME(x),@function; CNAME(x): >> -#define =A0 =A0 =A0 =A0END(x) =A0 =A0 =A0 =A0 =A0.size x, . - x >> +#define =A0 =A0 =A0 =A0END(x) =A0 =A0 =A0 =A0 =A0.cfi_endproc; .size x,= . - x >> >> =A0#ifdef PROF >> =A0#define =A0 =A0 =A0 =A0ALTENTRY(x) =A0 =A0 _ENTRY(x); \ >> @@ -80,9 +80,10 @@ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 popl %ebp; \ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 jmp 9f >> =A0#define =A0 =A0 =A0 =A0ENTRY(x) =A0 =A0 =A0 =A0_ENTRY(x); \ >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pushl %ebp; movl %esp,%ebp= ; \ >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .cfi_startproc; \ >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pushl %ebp; .cfi_adjust_cf= a_offset 4; movl >> %esp,%ebp; .cfi_def_cfa_register %ebp; \ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 call PIC_PLT(HIDENAME(mc= ount)); \ >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 popl %ebp; \ >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 popl %ebp; .cfi_def_cfa %e= sp, 4; \ >> >> --- bcopy.S =A0 =A0 2011-03-21 15:51:26.804203809 +0800 >> +++ ../8.2.0/lib/libc/i386/string/bcopy.S =A0 =A0 =A0 2011-03-21 >> 14:28:15.023069890 +0800 >> @@ -51,9 +51,7 @@ ENTRY(bcopy) >> =A0#endif >> =A0#endif >> =A0 =A0 =A0 =A0 pushl =A0 %esi >> - =A0 =A0 =A0 .cfi_adjust_cfa_offset 4; >> =A0 =A0 =A0 =A0 pushl =A0 %edi >> - =A0 =A0 =A0 .cfi_adjust_cfa_offset 4; >> =A0#if defined(MEMCOPY) || defined(MEMMOVE) >> =A0 =A0 =A0 =A0 movl =A0 =A012(%esp),%edi >> =A0 =A0 =A0 =A0 movl =A0 =A016(%esp),%esi >> @@ -77,9 +75,7 @@ ENTRY(bcopy) >> =A0 =A0 =A0 =A0 rep >> =A0 =A0 =A0 =A0 movsb >> =A0 =A0 =A0 =A0 popl =A0 =A0%edi >> - =A0 =A0 =A0 .cfi_adjust_cfa_offset -4; >> =A0 =A0 =A0 =A0 popl =A0 =A0%esi >> - =A0 =A0 =A0 .cfi_adjust_cfa_offset -4; >> =A0 =A0 =A0 =A0 ret >> =A01: >> =A0 =A0 =A0 =A0 addl =A0 =A0%ecx,%edi =A0 =A0 =A0 /* copy backwards. */ >> @@ -98,9 +94,7 @@ ENTRY(bcopy) >> =A0 =A0 =A0 =A0 rep >> =A0 =A0 =A0 =A0 movsl >> =A0 =A0 =A0 =A0 popl =A0 =A0%edi >> - =A0 =A0 =A0 .cfi_adjust_cfa_offset -4; >> =A0 =A0 =A0 =A0 popl =A0 =A0%esi >> - =A0 =A0 =A0 .cfi_adjust_cfa_offset -4; >> =A0 =A0 =A0 =A0 cld >> =A0 =A0 =A0 =A0 ret >> =A0#ifdef MEMCOPY >> >> But I don't know how to add DWARF for cpu_switch, because I have no >> idea about the circumstance when we need to backtrace through this >> function. Suppose there's a cpu switch like this, >> threadA->kernel->threadB. Then should the expected backtrace has the >> following result? >> >> threadB's stack >> kernel's stack >> threadA's stack > > > hmm, ok. good, avoid cpu_switch. > First of all, please, read style(9) man page. > In the second, evaluate the proposed plan (discussed with kib@): > > 1) Annotate libc, msun, rtld, libthr (you) > 2) vdso (I'm) > 3) Annotate signal trampolines (you, after vdso) > > And i'm going to understand what I need to do to start GSoC for you. > Thanks! > > > -- > Have fun! > chd > I think the plan is ok for me. Thank you. Xingxing Pan From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 22 15:39: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 E9D9D106566B; Tue, 22 Mar 2011 15:39:59 +0000 (UTC) (envelope-from forandom@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 863388FC12; Tue, 22 Mar 2011 15:39:59 +0000 (UTC) Received: by qwc9 with SMTP id 9so5753627qwc.13 for ; Tue, 22 Mar 2011 08:39:58 -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=xXAnJvdc05KciaxVmcjrGY47JHxI+xLz0G1fnvWWov4=; b=S4YEF6VHUzvKlUaHVlugDZQ3P/7rZCXjO076mv43rd7808bZ+Znxz4xCXZ7EKJnqA6 f2CdXp7bQpfnl8zQh0tIOrzHVgnG6q6tnd5/ia81PT2oJFZquWmc6i8bsw9AbS2sjH/C gTseJTtooFllD7rDBMnRkMhgHnIHudolanfp8= 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=emXk0l2Op6n1OHS37TvA15poRx0hheUR8NJ9W6TbpoWzLCpWwlXlBkTXcq0EWdVBZ9 3YpXtC0HRgaQfYroySmhBrm8FkAR+STM8Cri9bTEbCJ+xAhZnfC/fnzXrSw6NY9DFLIa iRBIdlbAl7UCWWF/B9Fz71yhI7v8hTttvni9c= MIME-Version: 1.0 Received: by 10.229.142.139 with SMTP id q11mr4832284qcu.163.1300808398351; Tue, 22 Mar 2011 08:39:58 -0700 (PDT) Sender: forandom@gmail.com Received: by 10.229.222.148 with HTTP; Tue, 22 Mar 2011 08:39:58 -0700 (PDT) In-Reply-To: <20110321200025.GP78089@deviant.kiev.zoral.com.ua> References: <20110319174115.GA33282@dchagin.static.corbina.ru> <20110320071847.GA10579@dchagin.static.corbina.ru> <20110320181911.GA79862@dchagin.static.corbina.ru> <20110321173204.GA7575@dchagin.static.corbina.ru> <20110321200025.GP78089@deviant.kiev.zoral.com.ua> Date: Tue, 22 Mar 2011 23:39:58 +0800 X-Google-Sender-Auth: 7keWT0jHR_P82EzzO38RrlejHIw Message-ID: From: Xingxing Pan To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Chagin Dmitry Subject: Re: GSoC'11: DWARF2 call frame information 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, 22 Mar 2011 15:40:00 -0000 2011/3/22 Kostik Belousov : > On Mon, Mar 21, 2011 at 08:32:04PM +0300, Chagin Dmitry wrote: >> On Mon, Mar 21, 2011 at 05:36:13PM +0800, Xingxing Pan wrote: >> > 2011/3/21 Chagin Dmitry : >> > >> powerfull script. >> > >> >> > >> Xingxing Pan >> > > >> > > hmm, which script? I think enough amd64, i386 and amd64/ia32. >> > > >> > > I suggest to write a example before continuing the conversation >> > > about the GSoC. For example (bcopy || bzero) && cpu_switch. >> > > Is it ok for you? >> > > >> > > -- >> > > Have fun! >> > > chd >> > > >> > >> > Hi Chargin, >> > >> > Thank you for your reply. >> > The followings shows how I try to add DWARF for bcopy. >> > >> > --- ../8.2.0/sys/i386/include/asm.h =A0 =A0 2011-03-21 14:35:56.111973= 722 +0800 >> > +++ asm.h =A0 =A0 =A0 2011-03-21 15:25:31.564636162 +0800 >> > @@ -71,7 +71,7 @@ >> > >> > =A0#define _ENTRY(x) =A0 =A0 =A0_START_ENTRY; \ >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .globl CNAME(x); .type= CNAME(x),@function; CNAME(x): >> > -#define =A0 =A0 =A0 =A0END(x) =A0 =A0 =A0 =A0 =A0.size x, . - x >> > +#define =A0 =A0 =A0 =A0END(x) =A0 =A0 =A0 =A0 =A0.cfi_endproc; .size = x, . - x >> > >> > =A0#ifdef PROF >> > =A0#define =A0 =A0 =A0 =A0ALTENTRY(x) =A0 =A0 _ENTRY(x); \ >> > @@ -80,9 +80,10 @@ >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 popl %ebp; \ >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 jmp 9f >> > =A0#define =A0 =A0 =A0 =A0ENTRY(x) =A0 =A0 =A0 =A0_ENTRY(x); \ >> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pushl %ebp; movl %esp,%e= bp; \ >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .cfi_startproc; \ >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pushl %ebp; .cfi_adjust_= cfa_offset 4; movl >> > %esp,%ebp; .cfi_def_cfa_register %ebp; \ >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 call PIC_PLT(HIDENAME(= mcount)); \ >> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 popl %ebp; \ >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 popl %ebp; .cfi_def_cfa = %esp, 4; \ >> > >> > --- bcopy.S =A0 =A0 2011-03-21 15:51:26.804203809 +0800 >> > +++ ../8.2.0/lib/libc/i386/string/bcopy.S =A0 =A0 =A0 2011-03-21 >> > 14:28:15.023069890 +0800 >> > @@ -51,9 +51,7 @@ ENTRY(bcopy) >> > =A0#endif >> > =A0#endif >> > =A0 =A0 =A0 =A0 pushl =A0 %esi >> > - =A0 =A0 =A0 .cfi_adjust_cfa_offset 4; >> > =A0 =A0 =A0 =A0 pushl =A0 %edi >> > - =A0 =A0 =A0 .cfi_adjust_cfa_offset 4; >> > =A0#if defined(MEMCOPY) || defined(MEMMOVE) >> > =A0 =A0 =A0 =A0 movl =A0 =A012(%esp),%edi >> > =A0 =A0 =A0 =A0 movl =A0 =A016(%esp),%esi >> > @@ -77,9 +75,7 @@ ENTRY(bcopy) >> > =A0 =A0 =A0 =A0 rep >> > =A0 =A0 =A0 =A0 movsb >> > =A0 =A0 =A0 =A0 popl =A0 =A0%edi >> > - =A0 =A0 =A0 .cfi_adjust_cfa_offset -4; >> > =A0 =A0 =A0 =A0 popl =A0 =A0%esi >> > - =A0 =A0 =A0 .cfi_adjust_cfa_offset -4; >> > =A0 =A0 =A0 =A0 ret >> > =A01: >> > =A0 =A0 =A0 =A0 addl =A0 =A0%ecx,%edi =A0 =A0 =A0 /* copy backwards. *= / >> > @@ -98,9 +94,7 @@ ENTRY(bcopy) >> > =A0 =A0 =A0 =A0 rep >> > =A0 =A0 =A0 =A0 movsl >> > =A0 =A0 =A0 =A0 popl =A0 =A0%edi >> > - =A0 =A0 =A0 .cfi_adjust_cfa_offset -4; >> > =A0 =A0 =A0 =A0 popl =A0 =A0%esi >> > - =A0 =A0 =A0 .cfi_adjust_cfa_offset -4; >> > =A0 =A0 =A0 =A0 cld >> > =A0 =A0 =A0 =A0 ret >> > =A0#ifdef MEMCOPY >> > >> > But I don't know how to add DWARF for cpu_switch, because I have no >> > idea about the circumstance when we need to backtrace through this >> > function. Suppose there's a cpu switch like this, >> > threadA->kernel->threadB. Then should the expected backtrace has the >> > following result? >> > >> > threadB's stack >> > kernel's stack >> > threadA's stack >> >> >> hmm, ok. good, avoid cpu_switch. >> First of all, please, read style(9) man page. >> In the second, evaluate the proposed plan (discussed with kib@): >> >> 1) Annotate libc, msun, rtld, libthr (you) > 1a) Develop and implement a testing plan to verify the implementation. > 1b) consider doing full register tracking for assembler code. > >> 2) vdso (I'm) >> 3) Annotate signal trampolines (you, after vdso) >> >> And i'm going to understand what I need to do to start GSoC for you. >> Thanks! >> >> >> -- >> Have fun! >> chd > > > Hi Kostik, I think the basic testing method can be using GDB to set breakpoint in functions and observing the backtrace result. GDB uses Expect. I can learn something from GDB's testsuite. AFAIK, CFA and return address are enough for unwinding. Dose full register tracking means to emit DWARF for all the registers's saving and restoring in the life time of the function? Thanks. Xingxing Pan From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 22 16:31: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 B8937106566C for ; Tue, 22 Mar 2011 16:31:52 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) by mx1.freebsd.org (Postfix) with ESMTP id 741028FC15 for ; Tue, 22 Mar 2011 16:31:52 +0000 (UTC) Received: by mail.embedded-brains.de (Postfix, from userid 65534) id 61F756F7E09; Tue, 22 Mar 2011 17:12:59 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fidibus.eb.z X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from [192.168.96.31] (eb0011.eb.z [192.168.96.31]) by mail.embedded-brains.de (Postfix) with ESMTP id 859196F7DF7 for ; Tue, 22 Mar 2011 17:12:58 +0100 (CET) Message-ID: <4D88CA8A.3020808@embedded-brains.de> Date: Tue, 22 Mar 2011 17:12:58 +0100 From: Sebastian Huber User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101125 SUSE/3.0.11 Lightning/1.0b1 Thunderbird/3.0.11 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: PowerPC e500v2 and IEEE 754 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, 22 Mar 2011 16:31:52 -0000 Hello does anyone know if FreeBSD provides the software support for full IEEE 754 conformance on a PowerPC e500v2 core (for example QorIQ series from Freescale)? Have a nice day! -- Sebastian Huber, embedded brains GmbH Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany Phone : +49 89 18 90 80 79-6 Fax : +49 89 18 90 80 79-9 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 22 17:11: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 02C47106566C for ; Tue, 22 Mar 2011 17:11:19 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3ABE68FC1C for ; Tue, 22 Mar 2011 17:11:17 +0000 (UTC) Received: by wwc33 with SMTP id 33so8994584wwc.31 for ; Tue, 22 Mar 2011 10:11:17 -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=75zgEJTrSz/fcZ748Tsj6wET1V9oQQd4MPpvIPEw+JA=; b=vBNmmaEanfhHlJRaap5eLckBm3yH0qsqMw3HjOEXAYpXCTOJHNwVxcEDjNTDNC0KrX BGiFFjs0Bb+W2AOFsgv4YvpTzbVkwowNIDLCtihUYlJPxV4Eq3FRhXtql0MW14LddxRK uEmtPZk+vICClblYS8+kaV3kjO6CSBWnOMvrw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=S1m94RT2HJd7ruAsJ0XXnb/+xWeuOOyVtHCamXqwLqBQfMHcpcoaY2nsy/e609C4QL iNexue1bPhOM1PqHCS/3hjSUOtfjnpv8ZfPC5Hm2gwLZjMJjL0fiTtmEOyKKYYqPBBJ2 +ZG+BzfBYWlSiNSE4c7lNqlRg6MC7j/ZcMLAw= MIME-Version: 1.0 Received: by 10.216.44.208 with SMTP id n58mr7248788web.39.1300813865504; Tue, 22 Mar 2011 10:11:05 -0700 (PDT) Received: by 10.216.52.209 with HTTP; Tue, 22 Mar 2011 10:11:04 -0700 (PDT) Date: Tue, 22 Mar 2011 10:11:04 -0700 Message-ID: From: Matthew Fleming To: freebsd-hackers Content-Type: multipart/mixed; boundary=0016367b5e425f5ca6049f15543e Subject: DMA controller on Northbridge? 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, 22 Mar 2011 17:11:19 -0000 --0016367b5e425f5ca6049f15543e Content-Type: text/plain; charset=ISO-8859-1 How can I tell if the Northbridge on a machine has a built-in DMA controller? And if it does, what device would I use to control it? I ask because I'm working with a PCI card that has a 36-bit physical address limit, and that means bounce buffers when using more than 64GB of memory. I'd prefer not to use bounce buffers, and since the card's memory that I'm using is mapped into the physical space of the FreeBSD host, the entire address space of the card that I care about is available to FreeBSD. So while pio to the card's memory is too slow to be useful, if there was a way to use a DMA controller on the motherboard to get data into and out of the card, that may be preferable to using the card's DMAC with the limited address space. But all that's just theory -- I have no idea how to tell whether the mobo has a DMAC, and if it does, how to control it. Help? :-) Attached is the boot dmesg; I can also run pciconf commands, etc., to help out with figuring out what I have. Thanks, matthew --0016367b5e425f5ca6049f15543e Content-Type: text/plain; charset=US-ASCII; name="dmesg.txt" Content-Disposition: attachment; filename="dmesg.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gll30d6i0 Q29weXJpZ2h0IChjKSAyMDAxLTIwMTEgSXNpbG9uIFN5c3RlbXMgTExDLiAgQWxsIHJpZ2h0cyBy ZXNlcnZlZC4KQ29weXJpZ2h0IChjKSAxOTkyLTIwMTEgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29w eXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTky LCAxOTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlh LiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsg b2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KSXNpbG9uIE9uZUZTIHZIRUFEIEJfNzQ2NihERUJV Ryk6IDB4NjA1MDEwRTAwMUQyQTAwOiBTYXQgTWFyIDE5IDEyOjAyOjEyIEdNVCAyMDExCiAgICBy b290QG1kZi1ybnYtMTovZGF0YS9zYi9oZWFkL29iai9kYXRhL3NiL2hlYWQvc3JjL3N5cy9JUS5h bWQ2NC5kZWJ1ZyBhbWQ2NApXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3Qg cmVkdWNlZCBwZXJmb3JtYW5jZS4KSXNpbG9uOiBtb2RlbCA0NCBmYW1pbHkgNiBzdGVwcGluZyAy OyBoaWdobWVtIGVuYWJsZWQuCk1FTUdVQVJEIERFQlVHR0lORyBBTExPQ0FUT1IgSU5JVElBTEla RUQ6CglNRU1HVUFSRCBtYXAgYmFzZTogMHhmZmZmZmY4MDAwNDAwMDAwCglNRU1HVUFSRCBtYXAg bGltaXQ6IDB4ZmZmZmZmODdhZTU0ODAwMAoJTUVNR1VBUkQgbWFwIHNpemU6IDMyMjEyMjU2IEtC eXRlcwpUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApD UFU6IEludGVsKFIpIFhlb24oUikgQ1BVICAgICAgICAgICBFNTYyMCAgQCAyLjQwR0h6ICgyMzk0 LjAyLU1IeiBLOC1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHgy MDZjMiAgU3RlcHBpbmcgPSAyCiAgRmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxU U0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixD TEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVy ZXMyPTB4MjllZTNmZjxTU0UzLFBDTE1VTFFEUSxEVEVTNjQsTU9OLERTX0NQTCxWTVgsU01YLEVT VCxUTTIsU1NTRTMsQ1gxNix4VFBSLFBEQ00sUENJRCxEQ0EsU1NFNC4xLFNTRTQuMixQT1BDTlQs QUVTTkk+CiAgQU1EIEZlYXR1cmVzPTB4MmMxMDA4MDA8U1lTQ0FMTCxOWCxQYWdlMUdCLFJEVFND UCxMTT4KICBBTUQgRmVhdHVyZXMyPTB4MTxMQUhGPgogIFRTQzogUC1zdGF0ZSBpbnZhcmlhbnQK dXNhYmxlIG1lbW9yeSA9IDI1NjQ3Njg1NjMyICgyNDQ1OSBNQikKZml4X3R1bmFibGUoKTogcmV0 dXJuaW5nIDY1NTM2IGZvciB0dW5hYmxlICJuYnVmIiwgbWVtID0gMjU3Njk4MDM3NzYKZml4X3R1 bmFibGUoKTogcmV0dXJuaW5nIDY1NTM2IGZvciB0dW5hYmxlICJuYnVmIiwgbWVtID0gMjU3Njk4 MDM3NzYKYXZhaWwgbWVtb3J5ICA9IDI0NTYyMzcyNjA4ICgyMzQyNCBNQikKZml4X3R1bmFibGUo KTogcmV0dXJuaW5nIDY3MTA4ODY0IGZvciB0dW5hYmxlICJoaXJ1bm5pbmdzcGFjZSIsIG1lbSA9 IDI1NzY5ODAzNzc2CmZpeF90dW5hYmxlKCk6IHJldHVybmluZyA2NjA2MDI4OCBmb3IgdHVuYWJs ZSAibG9ydW5uaW5nc3BhY2UiLCBtZW0gPSAyNTc2OTgwMzc3NgpmaXhfdHVuYWJsZSgpOiByZXR1 cm5pbmcgMTAwMDAgZm9yIHR1bmFibGUgImxvZGlydHlidWZmZXJzIiwgbWVtID0gMjU3Njk4MDM3 NzYKZml4X3R1bmFibGUoKTogcmV0dXJuaW5nIDEwMjUwIGZvciB0dW5hYmxlICJoaWRpcnR5YnVm ZmVycyIsIG1lbSA9IDI1NzY5ODAzNzc2CmZpeF90dW5hYmxlKCk6IHJldHVybmluZyAyNTYyIGZv ciB0dW5hYmxlICJkaXJ0eWJ1ZnRocmVzaCIsIG1lbSA9IDI1NzY5ODAzNzc2CkFDUEkgQVBJQyBU YWJsZTogPDA5MjExMCBBUElDMjAxMz4KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3Rl bSBEZXRlY3RlZDogOCBDUFVzCkZyZWVCU0QvU01QOiAyIHBhY2thZ2UocykgeCA0IGNvcmUocykK IGNwdTAgKEJTUCk6IEFQSUMgSUQ6ICAwCiBjcHUxIChBUCk6IEFQSUMgSUQ6ICAyCiBjcHUyIChB UCk6IEFQSUMgSUQ6IDE4CiBjcHUzIChBUCk6IEFQSUMgSUQ6IDIwCiBjcHU0IChBUCk6IEFQSUMg SUQ6IDMyCiBjcHU1IChBUCk6IEFQSUMgSUQ6IDM0CiBjcHU2IChBUCk6IEFQSUMgSUQ6IDUwCiBj cHU3IChBUCk6IEFQSUMgSUQ6IDUyCmlvYXBpYzA6IENoYW5naW5nIEFQSUMgSUQgdG8gMQppb2Fw aWMxOiBDaGFuZ2luZyBBUElDIElEIHRvIDMKaW9hcGljMCA8VmVyc2lvbiAyLjA+IGlycXMgMC0y MyBvbiBtb3RoZXJib2FyZAppb2FwaWMxIDxWZXJzaW9uIDIuMD4gaXJxcyAyNC00NyBvbiBtb3Ro ZXJib2FyZApyZWdpc3RlcmVkIGZpcm13YXJlIHNldCA8aXNwXzEwNDA+CnJlZ2lzdGVyZWQgZmly bXdhcmUgc2V0IDxpc3BfMTA0MF9pdD4KcmVnaXN0ZXJlZCBmaXJtd2FyZSBzZXQgPGlzcF8xMDgw PgpyZWdpc3RlcmVkIGZpcm13YXJlIHNldCA8aXNwXzEwODBfaXQ+CnJlZ2lzdGVyZWQgZmlybXdh cmUgc2V0IDxpc3BfMTIxNjA+CnJlZ2lzdGVyZWQgZmlybXdhcmUgc2V0IDxpc3BfMTIxNjBfaXQ+ CnJlZ2lzdGVyZWQgZmlybXdhcmUgc2V0IDxpc3BfMjEwMD4KcmVnaXN0ZXJlZCBmaXJtd2FyZSBz ZXQgPGlzcF8yMjAwPgpyZWdpc3RlcmVkIGZpcm13YXJlIHNldCA8aXNwXzIzMDA+CnJlZ2lzdGVy ZWQgZmlybXdhcmUgc2V0IDxpc3BfMjMyMj4KcmVnaXN0ZXJlZCBmaXJtd2FyZSBzZXQgPGlzcF8y NDAwPgppbWRkMC05OiBJc2lsb24gTWlycm9yZWQgRGlzayBEcml2ZXIKRmlicmUgQ2hhbm5lbCBE ZXZpY2UgTWFuYWdlciAoZmNkbSkgaXMgbG9hZGVkCmFjcGkwOiA8TkVDID4gb24gbW90aGVyYm9h cmQKYWNwaTA6IFtJVEhSRUFEXQphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkKYWNwaTA6IHJl c2VydmF0aW9uIG9mIDAsIGEwMDAwICgzKSBmYWlsZWQKYWNwaTA6IHJlc2VydmF0aW9uIG9mIDEw MDAwMCwgYmZmMDAwMDAgKDMpIGZhaWxlZApUaW1lY291bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVu Y3kgMzU3OTU0NSBIeiBxdWFsaXR5IDEwMDAKYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQg My41Nzk1NDVNSHo+IHBvcnQgMHg4MDgtMHg4MGIgb24gYWNwaTAKYWNwaV9ocGV0MDogPEhpZ2gg UHJlY2lzaW9uIEV2ZW50IFRpbWVyPiBpb21lbSAweGZlZDAwMDAwLTB4ZmVkMDAzZmYgb24gYWNw aTAKVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDIwMDAK cGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApw Y2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMApwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+ IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2k5OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2li MjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAzLjAgb24gcGNpMApwY2k4OiA8QUNQ SSBQQ0kgYnVzPiBvbiBwY2liMgpwY2k4OiA8c2VyaWFsIGJ1cz4gYXQgZGV2aWNlIDAuMCAobm8g ZHJpdmVyIGF0dGFjaGVkKQpwY2liMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA1 LjAgb24gcGNpMApwY2k3OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMwpjeGdiYzA6IDxDaGVsc2lv IFQzMjAsIDIgcG9ydHM+IG1lbSAweGZhZTdlMDAwLTB4ZmFlN2VmZmYsMHhmYWU3ZjAwMC0weGZh ZTdmZmZmIGlycSAyNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTcKY3hnYmMwOiBTRlAgbW9kdWxlIHZl bmRvciBpcyBGSU5JU0FSIENPUlAuICAgCmN4Z2JjMDogU0ZQIHBhcnQgbnVtYmVyIGlzIEZUTFg4 NTcxRDNCQ0wgICAKY3hnYmMwOiBhZWwyMDA1IHBoeTogbW9kdHlwZToxCmN4Z2JjMDogU0ZQIG1v ZHVsZSB2ZW5kb3IgaXMgRklOSVNBUiBDT1JQLiAgIApjeGdiYzA6IFNGUCBwYXJ0IG51bWJlciBp cyBGVExYODU3MUQzQkNMICAgCmN4Z2JjMDogYWVsMjAwNSBwaHk6IG1vZHR5cGU6MQpjeGdiYzA6 IHVzaW5nIE1TSS1YIGludGVycnVwdHMgKDkgdmVjdG9ycykKY3hnYjA6IDxQb3J0IDAgMTBHQkFT RS1SPiBvbiBjeGdiYzAKY3hnYjA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjA3OjQzOjA2OmQxOjM5 CmN4Z2IxOiA8UG9ydCAxIDEwR0JBU0UtUj4gb24gY3hnYmMwCmN4Z2IxOiBFdGhlcm5ldCBhZGRy ZXNzOiAwMDowNzo0MzowNjpkMTozYQpjeGdiYzA6IEZpcm13YXJlIFZlcnNpb24gNy44LjAKcGNp YjQ6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgNy4wIG9uIHBjaTAKcGNpNjogPEFD UEkgUENJIGJ1cz4gb24gcGNpYjQKcm52MDogcm52X3BjaV9wcm9iZTogIzQxMTogRm91bmQgTlZS QU0gZGV2aWNlOklzaWxvbiBOVlJBTSAoUk5WLTUxMiBNQikgIFBDSWUgLzQgYmxvY2sgc2l6ZToy MDAgU3Vic3lzdGVtIERJRDoweDIxIFZJRDoweDQ5NTMKcm52MDogPElzaWxvbiBOVlJBTSAoUk5W LTUxMiBNQikgIFBDSWUgLzQ+IG1lbSAweGZhNzAwMDAwLTB4ZmE3ZmZmZmYsMHhmYTgwMDAwMC0w eGZhYmZmZmZmLDB4YzAwMDAwMDAtMHhkZmZmZmZmZiBpcnEgMzAgYXQgZGV2aWNlIDAuMCBvbiBw Y2k2CnJudjA6IFtJVEhSRUFEXQpybnYwOiBybnZfc29jX2ludF9lbmFibGU6ICM2MDA6IE1TSVIw IHdhcyBzZWxlY3RlZCBmb3IgRlcgY29tbWFuZCBjb21wbGV0aW9uIGludGVycnVwdHMsIG1hc2s6 KDB4MSkKcGNpYjU6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgOS4wIG9uIHBjaTAK cGNpNTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjUKbXBzMDogPExTSSBTQVMyMDA4PiBwb3J0IDB4 ZTAwMC0weGUwZmYgbWVtIDB4ZmFkM2MwMDAtMHhmYWQzZmZmZiwweGZhZDQwMDAwLTB4ZmFkN2Zm ZmYgaXJxIDMyIGF0IGRldmljZSAwLjAgb24gcGNpNQptcHMwOiBGaXJtd2FyZTogMDcuMDAuMDAu MDAKbXBzMDogSU9DQ2FwYWJpbGl0aWVzOiAxMjg1YzxTY3NpVGFza0Z1bGwsRGlhZ1RyYWNlLFNu YXBCdWYsRUVEUCxUcmFuc1JldHJ5LEV2ZW50UmVwbGF5LEhvc3REaXNjPgptcHMwOiBlbmFibGlu ZyB1bm1hcHBlZCBpbwptcHMwOiBtcHNzYXNfc3RhcnR1cF9pbmNyZW1lbnQgZnJlZXppbmcgc2lt cQppc2lfc2ltX2luaXQgbXBzMAptcHMwOiBbSVRIUkVBRF0KcGNpMDogPGJhc2UgcGVyaXBoZXJh bCwgaW50ZXJydXB0IGNvbnRyb2xsZXI+IGF0IGRldmljZSAyMC4wIChubyBkcml2ZXIgYXR0YWNo ZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWwsIGludGVycnVwdCBjb250cm9sbGVyPiBhdCBkZXZp Y2UgMjAuMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8YmFzZSBwZXJpcGhlcmFsLCBpbnRl cnJ1cHQgY29udHJvbGxlcj4gYXQgZGV2aWNlIDIwLjIgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNp MDogPGJhc2UgcGVyaXBoZXJhbCwgaW50ZXJydXB0IGNvbnRyb2xsZXI+IGF0IGRldmljZSAyMC4z IChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmljZSAy Mi4wIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmlj ZSAyMi4xIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRl dmljZSAyMi4yIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0 IGRldmljZSAyMi4zIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+ IGF0IGRldmljZSAyMi40IChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVy YWw+IGF0IGRldmljZSAyMi41IChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlw aGVyYWw+IGF0IGRldmljZSAyMi42IChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBl cmlwaGVyYWw+IGF0IGRldmljZSAyMi43IChubyBkcml2ZXIgYXR0YWNoZWQpCnVoY2kwOiA8VUhD SSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHhiZTgwLTB4YmU5ZiBpcnEgMTYgYXQg ZGV2aWNlIDI2LjAgb24gcGNpMAp1aGNpMDogW0dJQU5ULUxPQ0tFRF0KdWhjaTA6IFtJVEhSRUFE XQp1c2IwOiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kwCnVzYjA6IFVT QiByZXZpc2lvbiAxLjAKdWh1YjA6IDxJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJl diAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNiMAp1aHViMDogMiBwb3J0cyB3aXRoIDIgcmVtb3Zh YmxlLCBzZWxmIHBvd2VyZWQKdWhjaTE6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4g cG9ydCAweGJlMjAtMHhiZTNmIGlycSAyMSBhdCBkZXZpY2UgMjYuMSBvbiBwY2kwCnVoY2kxOiBb R0lBTlQtTE9DS0VEXQp1aGNpMTogW0lUSFJFQURdCnVzYjE6IDxVSENJIChnZW5lcmljKSBVU0Ig Y29udHJvbGxlcj4gb24gdWhjaTEKdXNiMTogVVNCIHJldmlzaW9uIDEuMAp1aHViMTogPEludGVs IFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2Ix CnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aGNpMjogPFVI Q0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4YmRjMC0weGJkZGYgaXJxIDE5IGF0 IGRldmljZSAyNi4yIG9uIHBjaTAKdWhjaTI6IFtHSUFOVC1MT0NLRURdCnVoY2kyOiBbSVRIUkVB RF0KdXNiMjogPFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMgp1c2IyOiBV U0IgcmV2aXNpb24gMS4wCnVodWIyOiA8SW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCBy ZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjIKdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92 YWJsZSwgc2VsZiBwb3dlcmVkCmVoY2kwOiA8RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250cm9s bGVyPiBtZW0gMHhmYWNmYTAwMC0weGZhY2ZhM2ZmIGlycSAxOCBhdCBkZXZpY2UgMjYuNyBvbiBw Y2kwCmVoY2kwOiBbR0lBTlQtTE9DS0VEXQplaGNpMDogW0lUSFJFQURdCnVzYjM6IEVIQ0kgdmVy c2lvbiAxLjAKdXNiMzogY29tcGFuaW9uIGNvbnRyb2xsZXJzLCAyIHBvcnRzIGVhY2g6IHVzYjAg dXNiMSB1c2IyCnVzYjM6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVo Y2kwCnVzYjM6IFVTQiByZXZpc2lvbiAyLjAKdWh1YjM6IDxJbnRlbCBFSENJIHJvb3QgaHViLCBj bGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNiMwp1aHViMzogNiBwb3J0cyB3 aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKcGNpYjY6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdl PiBpcnEgMTcgYXQgZGV2aWNlIDI4LjAgb24gcGNpMApwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBw Y2liNgpwY2liNzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNyBhdCBkZXZpY2UgMjguNCBv biBwY2kwCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI3CmVtMDogPEludGVsKFIpIFBSTy8x MDAwIE5ldHdvcmsgQ29ubmVjdGlvbiA2LjkuNj4gcG9ydCAweGNmODAtMHhjZjlmIG1lbSAweGZh NWUwMDAwLTB4ZmE1ZmZmZmYsMHhmYTVkYzAwMC0weGZhNWRmZmZmIGlycSAxNiBhdCBkZXZpY2Ug MC4wIG9uIHBjaTMKZW0wOiBVc2luZyBNU0lYIGludGVycnVwdHMKZW0wOiBlbV9mbG93X2NvbnRy b2xfdHVuYWJsZSBpczogMCBhbmQgZW1fZmxvd19jb250cm9sX3N5c2N0bCBpcyAwCmVtMDogRGlz YWJsaW5nIGhhcmR3YXJlIGZsb3cgY29udHJvbCAKZW0wOiBbSVRIUkVBRF0KZW0wOiBbSVRIUkVB RF0KZW0wOiBbSVRIUkVBRF0KZW0wOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDozMDo0ODpkZDowNDo1 MgpwY2liODogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgMjguNSBvbiBw Y2kwCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI4CmVtMTogPEludGVsKFIpIFBSTy8xMDAw IE5ldHdvcmsgQ29ubmVjdGlvbiA2LjkuNj4gcG9ydCAweGRmODAtMHhkZjlmIG1lbSAweGZhNmUw MDAwLTB4ZmE2ZmZmZmYsMHhmYTZkYzAwMC0weGZhNmRmZmZmIGlycSAxNyBhdCBkZXZpY2UgMC4w IG9uIHBjaTQKZW0xOiBVc2luZyBNU0lYIGludGVycnVwdHMKZW0xOiBlbV9mbG93X2NvbnRyb2xf dHVuYWJsZSBpczogMCBhbmQgZW1fZmxvd19jb250cm9sX3N5c2N0bCBpcyAwCmVtMTogRGlzYWJs aW5nIGhhcmR3YXJlIGZsb3cgY29udHJvbCAKZW0xOiBbSVRIUkVBRF0KZW0xOiBbSVRIUkVBRF0K ZW0xOiBbSVRIUkVBRF0KZW0xOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDozMDo0ODpkZDowNDo1Mwp1 aGNpMzogPFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4YmYwMC0weGJmMWYg aXJxIDIzIGF0IGRldmljZSAyOS4wIG9uIHBjaTAKdWhjaTM6IFtHSUFOVC1MT0NLRURdCnVoY2kz OiBbSVRIUkVBRF0KdXNiNDogPFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNp Mwp1c2I0OiBVU0IgcmV2aXNpb24gMS4wCnVodWI0OiA8SW50ZWwgVUhDSSByb290IGh1YiwgY2xh c3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjQKdWh1YjQ6IDIgcG9ydHMgd2l0 aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVoY2k0OiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNv bnRyb2xsZXI+IHBvcnQgMHhiZWMwLTB4YmVkZiBpcnEgMTkgYXQgZGV2aWNlIDI5LjEgb24gcGNp MAp1aGNpNDogW0dJQU5ULUxPQ0tFRF0KdWhjaTQ6IFtJVEhSRUFEXQp1c2I1OiA8VUhDSSAoZ2Vu ZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2k0CnVzYjU6IFVTQiByZXZpc2lvbiAxLjAKdWh1 YjU6IDxJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIg MT4gb24gdXNiNQp1aHViNTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQK dWhjaTU6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gcG9ydCAweGJlYTAtMHhiZWJm IGlycSAxOCBhdCBkZXZpY2UgMjkuMiBvbiBwY2kwCnVoY2k1OiBbR0lBTlQtTE9DS0VEXQp1aGNp NTogW0lUSFJFQURdCnVzYjY6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gdWhj aTUKdXNiNjogVVNCIHJldmlzaW9uIDEuMAp1aHViNjogPEludGVsIFVIQ0kgcm9vdCBodWIsIGNs YXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2I2CnVodWI2OiAyIHBvcnRzIHdp dGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAplaGNpMTogPEVIQ0kgKGdlbmVyaWMpIFVTQiAy LjAgY29udHJvbGxlcj4gbWVtIDB4ZmFjZmMwMDAtMHhmYWNmYzNmZiBpcnEgMjMgYXQgZGV2aWNl IDI5Ljcgb24gcGNpMAplaGNpMTogW0dJQU5ULUxPQ0tFRF0KZWhjaTE6IFtJVEhSRUFEXQp1c2I3 OiBFSENJIHZlcnNpb24gMS4wCnVzYjc6IGNvbXBhbmlvbiBjb250cm9sbGVycywgMiBwb3J0cyBl YWNoOiB1c2I0IHVzYjUgdXNiNgp1c2I3OiA8RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250cm9s bGVyPiBvbiBlaGNpMQp1c2I3OiBVU0IgcmV2aXNpb24gMi4wCnVodWI3OiA8SW50ZWwgRUhDSSBy b290IGh1YiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjcKdWh1Yjc6 IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnBjaWI5OiA8QUNQSSBQQ0kt UENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBv biBwY2liOQp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gbWVtIDB4ZjcwMDAwMDAt MHhmN2ZmZmZmZiwweGY5N2ZjMDAwLTB4Zjk3ZmZmZmYsMHhmOTgwMDAwMC0weGY5ZmZmZmZmIGly cSAxNiBhdCBkZXZpY2UgMy4wIG9uIHBjaTEKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2 aWNlIDMxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKYXRhcGNpMDogPElDSDEw IFNBVEEzMDAgY29udHJvbGxlcj4gcG9ydCAweGJmZjAtMHhiZmY3LDB4YmY4Yy0weGJmOGYsMHhi ZmUwLTB4YmZlNywweGJmODgtMHhiZjhiLDB4YmZhMC0weGJmYWYsMHhiZjkwLTB4YmY5ZiBpcnEg MTkgYXQgZGV2aWNlIDMxLjIgb24gcGNpMAphdGFwY2kwOiBbR0lBTlQtTE9DS0VEXQphdGFwY2kw OiBbSVRIUkVBRF0KYXRhMjogY2hhbm5lbCAjMCBvbiBhdGFwY2kwCmF0YTI6IFtHSUFOVC1MT0NL RURdCmF0YTI6IFtJVEhSRUFEXQphdGEzOiBjaGFubmVsICMxIG9uIGF0YXBjaTAKYXRhMzogW0dJ QU5ULUxPQ0tFRF0KYXRhMzogW0lUSFJFQURdCmlzaV9pMmM6IGZvdW5kIEludGVsIElDSDEwIFNN QnVzIENvbnRyb2xsZXIKaXNpX2kyYzAgcG9ydCAweDQwMC0weDQxZiBtZW0gMHhmYWNmZTAwMC0w eGZhY2ZlMGZmIGlycSAxOCBhdCBkZXZpY2UgMzEuMyBvbiBwY2kwCmlzaV9pMmMwOiBbR0lBTlQt TE9DS0VEXQppc2lfaTJjMDogW0lUSFJFQURdCmF0YXBjaTE6IDxJQ0gxMCBTQVRBMzAwIGNvbnRy b2xsZXI+IHBvcnQgMHhiZjgwLTB4YmY4NywweGJmN2MtMHhiZjdmLDB4YmYyOC0weGJmMmYsMHhi ZjI0LTB4YmYyNywweGJmNjAtMHhiZjZmLDB4YmYzMC0weGJmM2YgaXJxIDE5IGF0IGRldmljZSAz MS41IG9uIHBjaTAKYXRhcGNpMTogW0dJQU5ULUxPQ0tFRF0KYXRhcGNpMTogW0lUSFJFQURdCmF0 YTQ6IGNoYW5uZWwgIzAgb24gYXRhcGNpMQphdGE0OiBbR0lBTlQtTE9DS0VEXQphdGE0OiBbSVRI UkVBRF0KYXRhNTogY2hhbm5lbCAjMSBvbiBhdGFwY2kxCmF0YTU6IFtHSUFOVC1MT0NLRURdCmF0 YTU6IFtJVEhSRUFEXQphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0b24+IG9uIGFjcGkwCnNpbzA6 IGNvbmZpZ3VyZWQgaXJxIDQgbm90IGluIGJpdG1hcCBvZiBwcm9iZWQgaXJxcyAwCnNpbzA6IHBv cnQgbWF5IG5vdCBiZSBlbmFibGVkCnNpbzA6IGNvbmZpZ3VyZWQgaXJxIDQgbm90IGluIGJpdG1h cCBvZiBwcm9iZWQgaXJxcyAwCnNpbzA6IHBvcnQgbWF5IG5vdCBiZSBlbmFibGVkCnNpbzA6IDwx NjU1MEEtY29tcGF0aWJsZSBDT00gcG9ydD4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAw eDkwIG9uIGFjcGkwCnNpbzA6IHR5cGUgMTY1NTBBLCBjb25zb2xlCnNpbzA6IFtGSUxURVJdCnNp bzE6IGNvbmZpZ3VyZWQgaXJxIDMgbm90IGluIGJpdG1hcCBvZiBwcm9iZWQgaXJxcyAwCnNpbzE6 IHBvcnQgbWF5IG5vdCBiZSBlbmFibGVkCnNpbzE6IGNvbmZpZ3VyZWQgaXJxIDMgbm90IGluIGJp dG1hcCBvZiBwcm9iZWQgaXJxcyAwCnNpbzE6IHBvcnQgbWF5IG5vdCBiZSBlbmFibGVkCnNpbzE6 IDwxNjU1MEEtY29tcGF0aWJsZSBDT00gcG9ydD4gcG9ydCAweDJmOC0weDJmZiBpcnEgMyBvbiBh Y3BpMApzaW8xOiB0eXBlIDE2NTUwQQpzaW8xOiBbRklMVEVSXQpzaW8yOiBjb25maWd1cmVkIGly cSA1IG5vdCBpbiBiaXRtYXAgb2YgcHJvYmVkIGlycXMgMApzaW8yOiBwb3J0IG1heSBub3QgYmUg ZW5hYmxlZApzaW8yOiBjb25maWd1cmVkIGlycSA1IG5vdCBpbiBiaXRtYXAgb2YgcHJvYmVkIGly cXMgMApzaW8yOiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZApzaW8yOiA8MTY1NTBBLWNvbXBhdGli bGUgQ09NIHBvcnQ+IHBvcnQgMHgzZTgtMHgzZWYgaXJxIDUgb24gYWNwaTAKc2lvMjogdHlwZSAx NjU1MEEKc2lvMjogW0ZJTFRFUl0KY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApBQ1BJIFdhcm5p bmcgKHRidXRpbHMtMDI0Myk6IEluY29ycmVjdCBjaGVja3N1bSBpbiB0YWJsZSBbT0VNQl0gLSAg OTEsIHNob3VsZCBiZSA4RSBbMjAwNzAzMjBdCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1 MjogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUzOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTQ6IDxB Q1BJIENQVT4gb24gYWNwaTAKY3B1NTogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHU2OiA8QUNQSSBD UFU+IG9uIGFjcGkwCmNwdTc6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3J5cHRvc29mdDA6IDxzb2Z0 d2FyZSBjcnlwdG8+IG9uIG1vdGhlcmJvYXJkCnFwaTA6IDxRUEkgc3lzdGVtIGJ1cz4gb24gbW90 aGVyYm9hcmQKcGNpYjEwOiA8UVBJIEhvc3QtUENJIGJyaWRnZT4gcGNpYnVzIDI1NCBvbiBxcGkw CnBjaTI1NDogPFBDSSBidXM+IG9uIHBjaWIxMApwY2liMTE6IDxRUEkgSG9zdC1QQ0kgYnJpZGdl PiBwY2lidXMgMjU1IG9uIHFwaTAKcGNpMjU1OiA8UENJIGJ1cz4gb24gcGNpYjExCm9ybTA6IDxJ U0EgT3B0aW9uIFJPTT4gYXQgaW9tZW0gMHhjMDAwMC0weGM3ZmZmIG9uIGlzYTAKYXRhMCBhdCBw b3J0IDB4MWYwLTB4MWY3LDB4M2Y2IGlycSAxNCBvbiBpc2EwCmF0YTA6IFtHSUFOVC1MT0NLRURd CmF0YTA6IFtJVEhSRUFEXQphdGExIGF0IHBvcnQgMHgxNzAtMHgxNzcsMHgzNzYgaXJxIDE1IG9u IGlzYTAKYXRhMTogW0dJQU5ULUxPQ0tFRF0KYXRhMTogW0lUSFJFQURdCmF0a2JkYzA6IDxLZXli b2FyZCBjb250cm9sbGVyIChpODA0Mik+IGF0IHBvcnQgMHg2MCwweDY0IG9uIGlzYTAKc2MwOiA8 U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1 YWwgY29uc29sZXMsIGZsYWdzPTB4MTAwPgp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0 IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwCmZpeF90dW5hYmxlKCk6 IHJldHVybmluZyAxNTAwMDAwIGZvciB0dW5hYmxlICJkZXNpcmVkdm5vZGVzIiwgbWVtID0gMjU3 Njk4MDM3NzYKZml4X3R1bmFibGUoKTogcmV0dXJuaW5nIDE1MDAwMDAgZm9yIHR1bmFibGUgIndh bnRmcmVldm5vZGVzIiwgbWVtID0gMjU3Njk4MDM3NzYKZml4X3R1bmFibGUoKTogcmV0dXJuaW5n IDM4NDAwMCBmb3IgdHVuYWJsZSAibWRzX2Jsb2NrX2xhenlfbG9ja3MiLCBtZW0gPSAyNTc2OTgw Mzc3NgpzZWw6IGxvYWRlZApUaW1lY291bnRlcnMgdGljayBldmVyeSAxMC4wMDAgbXNlYwphZDQ6 IGx1biA0IC0+IChwaHlzKSB1bml0IDAKaW9zY2hlZF9pbml0OiBpb3NjaGVkIGluaXRlZAphZDQ6 IGx1biA0IC0+IChwaHlzKSB1bml0IDAKYWQ0OiA8U2FuRGlzayBTU0QgUDQgOEdCL1NTRCA4LjAw LCBTTjoxMDMzMzMzMCwgNzY0MU1CIFNBVEExNTA+IG9uIGF0YTItbWFzdGVyCmFkNzogbHVuIDcg LT4gKHBoeXMpIHVuaXQgMQphZDc6IGx1biA3IC0+IChwaHlzKSB1bml0IDEKYWQ3OiA8U2FuRGlz ayBTU0QgUDQgOEdCL1NTRCA4LjAwLCBTTjoxMDMzMzMzMCwgNzY0MU1CIFNBVEExNTA+IG9uIGF0 YTMtc2xhdmUKbXBzMDogbXBzX3NlbmRfcG9ydGVuYWJsZQptcHMwOiB0YXJnZXQgMCBoYW5kbGUg MCBjaGFuZ2VkIGxpbmtyYXRlIGZyb20gMHgwIHRvIDB4MCwgc3RhdHVzIDB4MwptcHMwOiB0YXJn ZXQgMCBoYW5kbGUgMCBjaGFuZ2VkIGxpbmtyYXRlIGZyb20gMHgwIHRvIDB4MCwgc3RhdHVzIDB4 MwptcHMwOiB0YXJnZXQgMCBoYW5kbGUgMCBjaGFuZ2VkIGxpbmtyYXRlIGZyb20gMHgwIHRvIDB4 MCwgc3RhdHVzIDB4MwptcHMwOiB0YXJnZXQgMCBoYW5kbGUgMCBjaGFuZ2VkIGxpbmtyYXRlIGZy b20gMHgwIHRvIDB4MCwgc3RhdHVzIDB4MwptcHMwOiB0YXJnZXQgMCBoYW5kbGUgMCBjaGFuZ2Vk IGxpbmtyYXRlIGZyb20gMHgwIHRvIDB4MCwgc3RhdHVzIDB4MwptcHMwOiBMU0kgZXhwYW5kZXIg ZGV0ZWN0ZWQKbXBzMDogQXNzaWduZWQgdGFyZ2V0IGlkIDEyMCB0byA8YjA1MTAxNTBiZjAwMDAw MC81MDAxNTFiMDAwMDAwMGJmPgptcHMwOiBGb3VuZCBkZXZpY2UgPDE5MDI8U21wVGFyZyxEaXJl Y3QsTHNpRGV2PixFZGdlIEV4cGFuZGVyPiA8Ni4wR2Jwcz4gPDB4MDAwOT4gPDIvMD4gPDEvMD4g PGIwNTEwMTUwYmYwMDAwMDAvNTAwMTUxYjAwMDAwMDBiZj4KbXBzMDogQXNzaWduZWQgdGFyZ2V0 IGlkIDEwIHRvIDxjNTAwNTA0NTFlZjIyYi81MDAwYzUwMDJiZjIxZTQ1PgptcHMwOiBGb3VuZCBk ZXZpY2UgPDQwMTxTc3BUYXJnPixFbmQgRGV2aWNlPiA8Ni4wR2Jwcz4gPDB4MDAxMD4gPDAvMD4g PDkvMTA+IDwwMGM1MDA1MDQ1MWVmMjJiLzUwMDBjNTAwMmJmMjFlNDU+Cm1wczA6IEFzc2lnbmVk IHRhcmdldCBpZCAxMSB0byA8YzUwMDUwNWQ4ZTFiMWIvNTAwMGM1MDAxYjFiOGU1ZD4KbXBzMDog Rm91bmQgZGV2aWNlIDw0MDE8U3NwVGFyZz4sRW5kIERldmljZT4gPDYuMEdicHM+IDwweDAwMTE+ IDwwLzA+IDw5LzExPiA8MDBjNTAwNTA1ZDhlMWIxYi81MDAwYzUwMDFiMWI4ZTVkPgptcHMwOiBB c3NpZ25lZCB0YXJnZXQgaWQgMTIgdG8gPGM1MDA1MGNkNTVmMTJiLzUwMDBjNTAwMmJmMTU1Y2Q+ Cm1wczA6IEZvdW5kIGRldmljZSA8NDAxPFNzcFRhcmc+LEVuZCBEZXZpY2U+IDw2LjBHYnBzPiA8 MHgwMDEyPiA8MC8wPiA8OS8xMj4gPDAwYzUwMDUwY2Q1NWYxMmIvNTAwMGM1MDAyYmYxNTVjZD4K bXBzMDogQXNzaWduZWQgdGFyZ2V0IGlkIDEzIHRvIDxjNTAwNTBjZDFhZjIyYi81MDAwYzUwMDJi ZjIxYWNkPgptcHMwOiBGb3VuZCBkZXZpY2UgPDQwMTxTc3BUYXJnPixFbmQgRGV2aWNlPiA8Ni4w R2Jwcz4gPDB4MDAxMz4gPDAvMD4gPDkvMTM+IDwwMGM1MDA1MGNkMWFmMjJiLzUwMDBjNTAwMmJm MjFhY2Q+Cm1wczA6IEFzc2lnbmVkIHRhcmdldCBpZCAxNCB0byA8YzUwMDUwOTkyMGYyMmIvNTAw MGM1MDAyYmYyMjA5OT4KbXBzMDogRm91bmQgZGV2aWNlIDw0MDE8U3NwVGFyZz4sRW5kIERldmlj ZT4gPDYuMEdicHM+IDwweDAwMTQ+IDwwLzA+IDw5LzE0PiA8MDBjNTAwNTA5OTIwZjIyYi81MDAw YzUwMDJiZjIyMDk5PgptcHMwOiBBc3NpZ25lZCB0YXJnZXQgaWQgMTUgdG8gPGM1MDA1MDg1MjBm MjJiLzUwMDBjNTAwMmJmMjIwODU+Cm1wczA6IEZvdW5kIGRldmljZSA8NDAxPFNzcFRhcmc+LEVu ZCBEZXZpY2U+IDw2LjBHYnBzPiA8MHgwMDE1PiA8MC8wPiA8OS8xNT4gPDAwYzUwMDUwODUyMGYy MmIvNTAwMGM1MDAyYmYyMjA4NT4KbXBzMDogQXNzaWduZWQgdGFyZ2V0IGlkIDE2IHRvIDxjNTAw NTBmZDk0MWIxYi81MDAwYzUwMDFiMWI5NGZkPgptcHMwOiBGb3VuZCBkZXZpY2UgPDQwMTxTc3BU YXJnPixFbmQgRGV2aWNlPiA8Ni4wR2Jwcz4gPDB4MDAxNj4gPDAvMD4gPDkvMTY+IDwwMGM1MDA1 MGZkOTQxYjFiLzUwMDBjNTAwMWIxYjk0ZmQ+Cm1wczA6IEFzc2lnbmVkIHRhcmdldCBpZCAxNyB0 byA8YzUwMDUwOTk1NTIwMWIvNTAwMGM1MDAxYjIwNTU5OT4KbXBzMDogRm91bmQgZGV2aWNlIDw0 MDE8U3NwVGFyZz4sRW5kIERldmljZT4gPDYuMEdicHM+IDwweDAwMTc+IDwwLzA+IDw5LzE3PiA8 MDBjNTAwNTA5OTU1MjAxYi81MDAwYzUwMDFiMjA1NTk5PgptcHMwOiBBc3NpZ25lZCB0YXJnZXQg aWQgMTggdG8gPGM1MDA1MGI5MDRmMjJiLzUwMDBjNTAwMmJmMjA0Yjk+Cm1wczA6IEZvdW5kIGRl dmljZSA8NDAxPFNzcFRhcmc+LEVuZCBEZXZpY2U+IDw2LjBHYnBzPiA8MHgwMDE4PiA8MC8wPiA8 OS8xOD4gPDAwYzUwMDUwYjkwNGYyMmIvNTAwMGM1MDAyYmYyMDRiOT4KbXBzMDogQXNzaWduZWQg dGFyZ2V0IGlkIDE5IHRvIDxjNTAwNTBiNTY2ZWMyYi81MDAwYzUwMDJiZWM2NmI1PgptcHMwOiBG b3VuZCBkZXZpY2UgPDQwMTxTc3BUYXJnPixFbmQgRGV2aWNlPiA8Ni4wR2Jwcz4gPDB4MDAxOT4g PDAvMD4gPDkvMTk+IDwwMGM1MDA1MGI1NjZlYzJiLzUwMDBjNTAwMmJlYzY2YjU+Cm1wczA6IEFz c2lnbmVkIHRhcmdldCBpZCAyMCB0byA8YzUwMDUwNzk2NmVjMmIvNTAwMGM1MDAyYmVjNjY3OT4K bXBzMDogRm91bmQgZGV2aWNlIDw0MDE8U3NwVGFyZz4sRW5kIERldmljZT4gPDYuMEdicHM+IDww eDAwMWE+IDwwLzA+IDw5LzIwPiA8MDBjNTAwNTA3OTY2ZWMyYi81MDAwYzUwMDJiZWM2Njc5Pgpt cHMwOiBBc3NpZ25lZCB0YXJnZXQgaWQgMjEgdG8gPGM1MDA1MGIxOGFmMTJiLzUwMDBjNTAwMmJm MThhYjE+Cm1wczA6IEZvdW5kIGRldmljZSA8NDAxPFNzcFRhcmc+LEVuZCBEZXZpY2U+IDw2LjBH YnBzPiA8MHgwMDFiPiA8MC8wPiA8OS8yMT4gPDAwYzUwMDUwYjE4YWYxMmIvNTAwMGM1MDAyYmYx OGFiMT4KbXBzMDogQXNzaWduZWQgdGFyZ2V0IGlkIDIyIHRvIDxjNTAwNTAxMTY2ZWMyYi81MDAw YzUwMDJiZWM2NjExPgptcHMwOiBGb3VuZCBkZXZpY2UgPDQwMTxTc3BUYXJnPixFbmQgRGV2aWNl PiA8Ni4wR2Jwcz4gPDB4MDAxYz4gPDAvMD4gPDkvMjI+IDwwMGM1MDA1MDExNjZlYzJiLzUwMDBj NTAwMmJlYzY2MTE+Cm1wczA6IEFzc2lnbmVkIHRhcmdldCBpZCAyMyB0byA8YzUwMDUwZDUxYWYy MmIvNTAwMGM1MDAyYmYyMWFkNT4KbXBzMDogRm91bmQgZGV2aWNlIDw0MDE8U3NwVGFyZz4sRW5k IERldmljZT4gPDYuMEdicHM+IDwweDAwMWQ+IDwwLzA+IDw5LzIzPiA8MDBjNTAwNTBkNTFhZjIy Yi81MDAwYzUwMDJiZjIxYWQ1PgptcHMwOiBBc3NpZ25lZCB0YXJnZXQgaWQgMjQgdG8gPGM1MDA1 MDcxZDlmMTJiLzUwMDBjNTAwMmJmMWQ5NzE+Cm1wczA6IEZvdW5kIGRldmljZSA8NDAxPFNzcFRh cmc+LEVuZCBEZXZpY2U+IDw2LjBHYnBzPiA8MHgwMDFlPiA8MC8wPiA8OS8yND4gPDAwYzUwMDUw NzFkOWYxMmIvNTAwMGM1MDAyYmYxZDk3MT4KbXBzMDogQXNzaWduZWQgdGFyZ2V0IGlkIDI1IHRv IDxjNTAwNTA1MTIwZjIyYi81MDAwYzUwMDJiZjIyMDUxPgptcHMwOiBGb3VuZCBkZXZpY2UgPDQw MTxTc3BUYXJnPixFbmQgRGV2aWNlPiA8Ni4wR2Jwcz4gPDB4MDAxZj4gPDAvMD4gPDkvMjU+IDww MGM1MDA1MDUxMjBmMjJiLzUwMDBjNTAwMmJmMjIwNTE+Cm1wczA6IEFzc2lnbmVkIHRhcmdldCBp ZCAyNiB0byA8YzUwMDUwZTE1Y2YxMmIvNTAwMGM1MDAyYmYxNWNlMT4KbXBzMDogRm91bmQgZGV2 aWNlIDw0MDE8U3NwVGFyZz4sRW5kIERldmljZT4gPDYuMEdicHM+IDwweDAwMjA+IDwwLzA+IDw5 LzI2PiA8MDBjNTAwNTBlMTVjZjEyYi81MDAwYzUwMDJiZjE1Y2UxPgptcHMwOiBBc3NpZ25lZCB0 YXJnZXQgaWQgMjcgdG8gPGM1MDA1MDg1MWVmMjJiLzUwMDBjNTAwMmJmMjFlODU+Cm1wczA6IEZv dW5kIGRldmljZSA8NDAxPFNzcFRhcmc+LEVuZCBEZXZpY2U+IDw2LjBHYnBzPiA8MHgwMDIxPiA8 MC8wPiA8OS8yNz4gPDAwYzUwMDUwODUxZWYyMmIvNTAwMGM1MDAyYmYyMWU4NT4KbXBzMDogQXNz aWduZWQgdGFyZ2V0IGlkIDEwMCB0byA8YjA1MTAxNTBiZDAwMDAwMC81MDAxNTFiMDAwMDAwMGJk PgptcHMwOiBGb3VuZCBkZXZpY2UgPDQ0NTE8U21wSW5pdCxTc3BJbml0LFNzcFRhcmcsU2VwRGV2 PixFbmQgRGV2aWNlPiA8Ni4wR2Jwcz4gPDB4MDAyMj4gPDIvMD4gPDkvMzY+IDxiMDUxMDE1MGJk MDAwMDAwLzUwMDE1MWIwMDAwMDAwYmQ+CmlzaV9zaW1fYWRkX2Rpc2sgc2ltIG1wczAgdGFyZ2V0 IDEwIGV4cCA5IHBoeSAxMCBwYXRoIDAKaXNpX3NpbV9hZGRfZGlzayBzaW0gbXBzMCB0YXJnZXQg MTEgZXhwIDkgcGh5IDExIHBhdGggMAppc2lfc2ltX2FkZF9kaXNrIHNpbSBtcHMwIHRhcmdldCAx MiBleHAgOSBwaHkgMTIgcGF0aCAwCmlzaV9zaW1fYWRkX2Rpc2sgc2ltIG1wczAgdGFyZ2V0IDEz IGV4cCA5IHBoeSAxMyBwYXRoIDAKaXNpX3NpbV9hZGRfZGlzayBzaW0gbXBzMCB0YXJnZXQgMTQg ZXhwIDkgcGh5IDE0IHBhdGggMAppc2lfc2ltX2FkZF9kaXNrIHNpbSBtcHMwIHRhcmdldCAxNSBl eHAgOSBwaHkgMTUgcGF0aCAwCmlzaV9zaW1fYWRkX2Rpc2sgc2ltIG1wczAgdGFyZ2V0IDE2IGV4 cCA5IHBoeSAxNiBwYXRoIDAKaXNpX3NpbV9hZGRfZGlzayBzaW0gbXBzMCB0YXJnZXQgMTcgZXhw IDkgcGh5IDE3IHBhdGggMAppc2lfc2ltX2FkZF9kaXNrIHNpbSBtcHMwIHRhcmdldCAxOCBleHAg OSBwaHkgMTggcGF0aCAwCmlzaV9zaW1fYWRkX2Rpc2sgc2ltIG1wczAgdGFyZ2V0IDE5IGV4cCA5 IHBoeSAxOSBwYXRoIDAKaXNpX3NpbV9hZGRfZGlzayBzaW0gbXBzMCB0YXJnZXQgMjAgZXhwIDkg cGh5IDIwIHBhdGggMAppc2lfc2ltX2FkZF9kaXNrIHNpbSBtcHMwIHRhcmdldCAyMSBleHAgOSBw aHkgMjEgcGF0aCAwCmlzaV9zaW1fYWRkX2Rpc2sgc2ltIG1wczAgdGFyZ2V0IDIyIGV4cCA5IHBo eSAyMiBwYXRoIDAKaXNpX3NpbV9hZGRfZGlzayBzaW0gbXBzMCB0YXJnZXQgMjMgZXhwIDkgcGh5 IDIzIHBhdGggMAppc2lfc2ltX2FkZF9kaXNrIHNpbSBtcHMwIHRhcmdldCAyNCBleHAgOSBwaHkg MjQgcGF0aCAwCmlzaV9zaW1fYWRkX2Rpc2sgc2ltIG1wczAgdGFyZ2V0IDI1IGV4cCA5IHBoeSAy NSBwYXRoIDAKaXNpX3NpbV9hZGRfZGlzayBzaW0gbXBzMCB0YXJnZXQgMjYgZXhwIDkgcGh5IDI2 IHBhdGggMAppc2lfc2ltX2FkZF9kaXNrIHNpbSBtcHMwIHRhcmdldCAyNyBleHAgOSBwaHkgMjcg cGF0aCAwCmlzaV9zaW1fYWRkX2Rpc2sgc2ltIG1wczAgdGFyZ2V0IDEwMCBleHAgOSBwaHkgMzYg cGF0aCAwCm1wczA6IEFzc2lnbmVkIHRhcmdldCBpZCA0IHRvIDxhNzIwNTAwMGRhZjQzMDAxLzUw MDE1MWIwMDAwMDAwODQ+Cm1wczA6IEZvdW5kIGRldmljZSA8ODE8U2F0YURldj4sRW5kIERldmlj ZT4gPDEuNUdicHM+IDwweDAwMGE+IDwwLzA+IDw5LzQ+IDxhNzIwNTAwMGRhZjQzMDAxLzUwMDE1 MWIwMDAwMDAwODQ+CmlzaV9zaW1fYWRkX2Rpc2sgc2ltIG1wczAgdGFyZ2V0IDQgZXhwIDkgcGh5 IDQgcGF0aCAwCm1wczA6IEFzc2lnbmVkIHRhcmdldCBpZCA1IHRvIDxhNzIwNTAwMGRiNzczMDAx LzUwMDE1MWIwMDAwMDAwODU+Cm1wczA6IEZvdW5kIGRldmljZSA8ODE8U2F0YURldj4sRW5kIERl dmljZT4gPDEuNUdicHM+IDwweDAwMGI+IDwwLzA+IDw5LzU+IDxhNzIwNTAwMGRiNzczMDAxLzUw MDE1MWIwMDAwMDAwODU+Cm1wczA6IEFzc2lnbmVkIHRhcmdldCBpZCA2IHRvIDxhNzIwNTAwMGRi NDUzMDAxLzUwMDE1MWIwMDAwMDAwODY+Cm1wczA6IEZvdW5kIGRldmljZSA8ODE8U2F0YURldj4s RW5kIERldmljZT4gPDEuNUdicHM+IDwweDAwMGM+IDwwLzA+IDw5LzY+IDxhNzIwNTAwMGRiNDUz MDAxLzUwMDE1MWIwMDAwMDAwODY+Cm1wczA6IEFzc2lnbmVkIHRhcmdldCBpZCA3IHRvIDxhNzIw NTAwMGRiNmQzMDAxLzUwMDE1MWIwMDAwMDAwODc+Cm1wczA6IEZvdW5kIGRldmljZSA8ODE8U2F0 YURldj4sRW5kIERldmljZT4gPDEuNUdicHM+IDwweDAwMGQ+IDwwLzA+IDw5Lzc+IDxhNzIwNTAw MGRiNmQzMDAxLzUwMDE1MWIwMDAwMDAwODc+Cm1wczA6IEFzc2lnbmVkIHRhcmdldCBpZCA4IHRv IDxhNzIwNTAwMGRiNDQzMDAxLzUwMDE1MWIwMDAwMDAwODg+Cm1wczA6IEZvdW5kIGRldmljZSA8 ODE8U2F0YURldj4sRW5kIERldmljZT4gPDEuNUdicHM+IDwweDAwMGU+IDwwLzA+IDw5Lzg+IDxh NzIwNTAwMGRiNDQzMDAxLzUwMDE1MWIwMDAwMDAwODg+Cm1wczA6IEFzc2lnbmVkIHRhcmdldCBp ZCA5IHRvIDxhNzIwNTAwMGRiNjIzMDAxLzUwMDE1MWIwMDAwMDAwODk+Cm1wczA6IEZvdW5kIGRl dmljZSA8ODE8U2F0YURldj4sRW5kIERldmljZT4gPDEuNUdicHM+IDwweDAwMGY+IDwwLzA+IDw5 Lzk+IDxhNzIwNTAwMGRiNjIzMDAxLzUwMDE1MWIwMDAwMDAwODk+Cm1wczA6IG1wc3Nhc19zdGFy dHVwX2RlY3JlbWVudCByZWxlYXNpbmcgc2ltcQppc2lfc2ltX2FkZF9kaXNrIHNpbSBtcHMwIHRh cmdldCA1IGV4cCA5IHBoeSA1IHBhdGggMAppc2lfc2ltX2FkZF9kaXNrIHNpbSBtcHMwIHRhcmdl dCA2IGV4cCA5IHBoeSA2IHBhdGggMAppc2lfc2ltX2FkZF9kaXNrIHNpbSBtcHMwIHRhcmdldCA3 IGV4cCA5IHBoeSA3IHBhdGggMAppc2lfc2ltX2FkZF9kaXNrIHNpbSBtcHMwIHRhcmdldCA4IGV4 cCA5IHBoeSA4IHBhdGggMAppc2lfc2ltX2FkZF9kaXNrIHNpbSBtcHMwIHRhcmdldCA5IGV4cCA5 IHBoeSA5IHBhdGggMApuZG1wX3NhOiB2ZXJzaW9uIDIwMDkwMTE2CnNlczAgYXQgbXBzMCBidXMg MCB0YXJnZXQgMTAwIGx1biAwCnNlczA6IDxJc2lsb24gU0FTMlgzNiAwNjAwPiBGaXhlZCBFbmNs b3N1cmUgU2VydmljZXMgU0NTSS01IGRldmljZSAKc2VzMDogNjAwLjAwME1CL3MgdHJhbnNmZXJz CnNlczA6IFNDU0ktMyBTRVMgRGV2aWNlCmRhMSBhdCBtcHMwIGJ1cyAwIHRhcmdldCA0IGx1biAw CmRhMTogPEFUQSBTVEVDICAgIE1BQ0g4IElPIDIyNjk+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NT SS01IGRldmljZSAKZGExOiAxNTAuMDAwTUIvcyB0cmFuc2ZlcnMKZGExOiBDb21tYW5kIFF1ZXVl aW5nIEVuYWJsZWQKZGExOiA5NTM5Nk1CICgxOTUzNzE1NjggYmxrcykKZGEyIGF0IG1wczAgYnVz IDAgdGFyZ2V0IDUgbHVuIDAKZGEyOiA8QVRBIFNURUMgICAgTUFDSDggSU8gMjI2OT4gRml4ZWQg RGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApkYTI6IDE1MC4wMDBNQi9zIHRyYW5zZmVycwpk YTI6IENvbW1hbmQgUXVldWVpbmcgRW5hYmxlZApkYTI6IDk1Mzk2TUIgKDE5NTM3MTU2OCBibGtz KQpkYTMgYXQgbXBzMCBidXMgMCB0YXJnZXQgNiBsdW4gMApkYTM6IDxBVEEgU1RFQyAgICBNQUNI OCBJTyAyMjY5PiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZpY2UgCmRhMzogMTUwLjAw ME1CL3MgdHJhbnNmZXJzCmRhMzogQ29tbWFuZCBRdWV1ZWluZyBFbmFibGVkCmRhMzogOTUzOTZN QiAoMTk1MzcxNTY4IGJsa3MpCmRhNCBhdCBtcHMwIGJ1cyAwIHRhcmdldCA3IGx1biAwCmRhNDog PEFUQSBTVEVDICAgIE1BQ0g4IElPIDIyNjk+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS01IGRl dmljZSAKZGE0OiAxNTAuMDAwTUIvcyB0cmFuc2ZlcnMKZGE0OiBDb21tYW5kIFF1ZXVlaW5nIEVu YWJsZWQKZGE0OiA5NTM5Nk1CICgxOTUzNzE1NjggYmxrcykKZGE1IGF0IG1wczAgYnVzIDAgdGFy Z2V0IDggbHVuIDAKZGE1OiA8QVRBIFNURUMgICAgTUFDSDggSU8gMjI2OT4gRml4ZWQgRGlyZWN0 IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApkYTU6IDE1MC4wMDBNQi9zIHRyYW5zZmVycwpkYTU6IENv bW1hbmQgUXVldWVpbmcgRW5hYmxlZApkYTU6IDk1Mzk2TUIgKDE5NTM3MTU2OCBibGtzKQpkYTYg YXQgbXBzMCBidXMgMCB0YXJnZXQgOSBsdW4gMApkYTY6IDxBVEEgU1RFQyAgICBNQUNIOCBJTyAy MjY5PiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZpY2UgCmRhNjogMTUwLjAwME1CL3Mg dHJhbnNmZXJzCmRhNjogQ29tbWFuZCBRdWV1ZWluZyBFbmFibGVkCmRhNjogOTUzOTZNQiAoMTk1 MzcxNTY4IGJsa3MpCmRhNyBhdCBtcHMwIGJ1cyAwIHRhcmdldCAxMCBsdW4gMApkYTc6IDxTRUFH QVRFIFNUOTMwMDYwM1NTIDAwMDY+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS01IGRldmljZSAK ZGE3OiA2MDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGE3OiBDb21tYW5kIFF1ZXVlaW5nIEVuYWJsZWQK ZGE3OiAyODYxMDJNQiAoNTg1OTM3NTAwIGJsa3MpCmRhOCBhdCBtcHMwIGJ1cyAwIHRhcmdldCAx MSBsdW4gMApkYTg6IDxTRUFHQVRFIFNUOTMwMDYwM1NTIDAwMDY+IEZpeGVkIERpcmVjdCBBY2Nl c3MgU0NTSS01IGRldmljZSAKZGE4OiA2MDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGE4OiBDb21tYW5k IFF1ZXVlaW5nIEVuYWJsZWQKZGE4OiAyODYxMDJNQiAoNTg1OTM3NTAwIGJsa3MpCmRhOSBhdCBt cHMwIGJ1cyAwIHRhcmdldCAxMiBsdW4gMApkYTk6IDxTRUFHQVRFIFNUOTMwMDYwM1NTIDAwMDY+ IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS01IGRldmljZSAKZGE5OiA2MDAuMDAwTUIvcyB0cmFu c2ZlcnMKZGE5OiBDb21tYW5kIFF1ZXVlaW5nIEVuYWJsZWQKZGE5OiAyODYxMDJNQiAoNTg1OTM3 NTAwIGJsa3MpCmRhMTAgYXQgbXBzMCBidXMgMCB0YXJnZXQgMTMgbHVuIDAKZGExMDogPFNFQUdB VEUgU1Q5MzAwNjAzU1MgMDAwNj4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApk YTEwOiA2MDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGExMDogQ29tbWFuZCBRdWV1ZWluZyBFbmFibGVk CmRhMTA6IDI4NjEwMk1CICg1ODU5Mzc1MDAgYmxrcykKZGExMSBhdCBtcHMwIGJ1cyAwIHRhcmdl dCAxNCBsdW4gMApkYTExOiA8U0VBR0FURSBTVDkzMDA2MDNTUyAwMDA2PiBGaXhlZCBEaXJlY3Qg QWNjZXNzIFNDU0ktNSBkZXZpY2UgCmRhMTE6IDYwMC4wMDBNQi9zIHRyYW5zZmVycwpkYTExOiBD b21tYW5kIFF1ZXVlaW5nIEVuYWJsZWQKZGExMTogMjg2MTAyTUIgKDU4NTkzNzUwMCBibGtzKQpk YTEyIGF0IG1wczAgYnVzIDAgdGFyZ2V0IDE1IGx1biAwCmRhMTI6IDxTRUFHQVRFIFNUOTMwMDYw M1NTIDAwMDY+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS01IGRldmljZSAKZGExMjogNjAwLjAw ME1CL3MgdHJhbnNmZXJzCmRhMTI6IENvbW1hbmQgUXVldWVpbmcgRW5hYmxlZApkYTEyOiAyODYx MDJNQiAoNTg1OTM3NTAwIGJsa3MpCmRhMTMgYXQgbXBzMCBidXMgMCB0YXJnZXQgMTYgbHVuIDAK ZGExMzogPFNFQUdBVEUgU1Q5MzAwNjAzU1MgMDAwNj4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJ LTUgZGV2aWNlIApkYTEzOiA2MDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGExMzogQ29tbWFuZCBRdWV1 ZWluZyBFbmFibGVkCmRhMTM6IDI4NjEwMk1CICg1ODU5Mzc1MDAgYmxrcykKZGExNCBhdCBtcHMw IGJ1cyAwIHRhcmdldCAxNyBsdW4gMApkYTE0OiA8U0VBR0FURSBTVDkzMDA2MDNTUyAwMDA2PiBG aXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZpY2UgCmRhMTQ6IDYwMC4wMDBNQi9zIHRyYW5z ZmVycwpkYTE0OiBDb21tYW5kIFF1ZXVlaW5nIEVuYWJsZWQKZGExNDogMjg2MTAyTUIgKDU4NTkz NzUwMCBibGtzKQpkYTE1IGF0IG1wczAgYnVzIDAgdGFyZ2V0IDE4IGx1biAwCmRhMTU6IDxTRUFH QVRFIFNUOTMwMDYwM1NTIDAwMDY+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS01IGRldmljZSAK ZGExNTogNjAwLjAwME1CL3MgdHJhbnNmZXJzCmRhMTU6IENvbW1hbmQgUXVldWVpbmcgRW5hYmxl ZApkYTE1OiAyODYxMDJNQiAoNTg1OTM3NTAwIGJsa3MpCmRhMTYgYXQgbXBzMCBidXMgMCB0YXJn ZXQgMTkgbHVuIDAKZGExNjogPFNFQUdBVEUgU1Q5MzAwNjAzU1MgMDAwNj4gRml4ZWQgRGlyZWN0 IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApkYTE2OiA2MDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGExNjog Q29tbWFuZCBRdWV1ZWluZyBFbmFibGVkCmRhMTY6IDI4NjEwMk1CICg1ODU5Mzc1MDAgYmxrcykK ZGExNyBhdCBtcHMwIGJ1cyAwIHRhcmdldCAyMCBsdW4gMApkYTE3OiA8U0VBR0FURSBTVDkzMDA2 MDNTUyAwMDA2PiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZpY2UgCmRhMTc6IDYwMC4w MDBNQi9zIHRyYW5zZmVycwpkYTE3OiBDb21tYW5kIFF1ZXVlaW5nIEVuYWJsZWQKZGExNzogMjg2 MTAyTUIgKDU4NTkzNzUwMCBibGtzKQpkYTE4IGF0IG1wczAgYnVzIDAgdGFyZ2V0IDIxIGx1biAw CmRhMTg6IDxTRUFHQVRFIFNUOTMwMDYwM1NTIDAwMDY+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NT SS01IGRldmljZSAKZGExODogNjAwLjAwME1CL3MgdHJhbnNmZXJzCmRhMTg6IENvbW1hbmQgUXVl dWVpbmcgRW5hYmxlZApkYTE4OiAyODYxMDJNQiAoNTg1OTM3NTAwIGJsa3MpCmRhMTkgYXQgbXBz MCBidXMgMCB0YXJnZXQgMjIgbHVuIDAKZGExOTogPFNFQUdBVEUgU1Q5MzAwNjAzU1MgMDAwNj4g Rml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApkYTE5OiA2MDAuMDAwTUIvcyB0cmFu c2ZlcnMKZGExOTogQ29tbWFuZCBRdWV1ZWluZyBFbmFibGVkCmRhMTk6IDI4NjEwMk1CICg1ODU5 Mzc1MDAgYmxrcykKZGEyMCBhdCBtcHMwIGJ1cyAwIHRhcmdldCAyMyBsdW4gMApkYTIwOiA8U0VB R0FURSBTVDkzMDA2MDNTUyAwMDA2PiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZpY2Ug CmRhMjA6IDYwMC4wMDBNQi9zIHRyYW5zZmVycwpkYTIwOiBDb21tYW5kIFF1ZXVlaW5nIEVuYWJs ZWQKZGEyMDogMjg2MTAyTUIgKDU4NTkzNzUwMCBibGtzKQpkYTIxIGF0IG1wczAgYnVzIDAgdGFy Z2V0IDI0IGx1biAwCmRhMjE6IDxTRUFHQVRFIFNUOTMwMDYwM1NTIDAwMDY+IEZpeGVkIERpcmVj dCBBY2Nlc3MgU0NTSS01IGRldmljZSAKZGEyMTogNjAwLjAwME1CL3MgdHJhbnNmZXJzCmRhMjE6 IENvbW1hbmQgUXVldWVpbmcgRW5hYmxlZApkYTIxOiAyODYxMDJNQiAoNTg1OTM3NTAwIGJsa3Mp CmRhMjIgYXQgbXBzMCBidXMgMCB0YXJnZXQgMjUgbHVuIDAKZGEyMjogPFNFQUdBVEUgU1Q5MzAw NjAzU1MgMDAwNj4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApkYTIyOiA2MDAu MDAwTUIvcyB0cmFuc2ZlcnMKZGEyMjogQ29tbWFuZCBRdWV1ZWluZyBFbmFibGVkCmRhMjI6IDI4 NjEwMk1CICg1ODU5Mzc1MDAgYmxrcykKZGEyMyBhdCBtcHMwIGJ1cyAwIHRhcmdldCAyNiBsdW4g MApkYTIzOiA8U0VBR0FURSBTVDkzMDA2MDNTUyAwMDA2PiBGaXhlZCBEaXJlY3QgQWNjZXNzIFND U0ktNSBkZXZpY2UgCmRhMjM6IDYwMC4wMDBNQi9zIHRyYW5zZmVycwpkYTIzOiBDb21tYW5kIFF1 ZXVlaW5nIEVuYWJsZWQKZGEyMzogMjg2MTAyTUIgKDU4NTkzNzUwMCBibGtzKQpkYTI0IGF0IG1w czAgYnVzIDAgdGFyZ2V0IDI3IGx1biAwCmRhMjQ6IDxTRUFHQVRFIFNUOTMwMDYwM1NTIDAwMDY+ IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS01IGRldmljZSAKZGEyNDogNjAwLjAwME1CL3MgdHJh bnNmZXJzCmRhMjQ6IENvbW1hbmQgUXVldWVpbmcgRW5hYmxlZApkYTI0OiAyODYxMDJNQiAoNTg1 OTM3NTAwIGJsa3MpCm1wczA6IG1wc19zdGFydHVwX2NvbXBsZXRlCm1wczA6IGRpc2VzdGFibGlz aCBjb25maWcgaW50cmhvb2sKSW5pdGlhbGl6aW5nIGNvbXByZXNzaW9uIGZvciBwYW5pYyBkdW1w cy4KU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhCiAgQ1BVOiBJbnRlbChSKSBYZW9uKFIpIENQVSAg ICAgICAgICAgRTU2MjAgIEAgMi40MEdIeiAoMjM5NC4wMi1NSHogSzgtY2xhc3MgQ1BVKQogIE9y aWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4MjA2YzIgIFN0ZXBwaW5nID0gMgogIEZlYXR1 cmVzPTB4YmZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNF UCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixT U0UsU1NFMixTUyxIVFQsVE0sUEJFPgogIEZlYXR1cmVzMj0weDI5ZWUzZmY8U1NFMyxQQ0xNVUxR RFEsRFRFUzY0LE1PTixEU19DUEwsVk1YLFNNWCxFU1QsVE0yLFNTU0UzLENYMTYseFRQUixQRENN LFBDSUQsRENBLFNTRTQuMSxTU0U0LjIsUE9QQ05ULEFFU05JPgogIEFNRCBGZWF0dXJlcz0weDJj MTAwODAwPFNZU0NBTEwsTlgsUGFnZTFHQixSRFRTQ1AsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8 TEFIRj4KICBUU0M6IFAtc3RhdGUgaW52YXJpYW50ClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQog IENQVTogSW50ZWwoUikgWGVvbihSKSBDUFUgICAgICAgICAgIEU1NjIwICBAIDIuNDBHSHogKDIz OTQuMDItTUh6IEs4LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAw eDIwNmMyICBTdGVwcGluZyA9IDIKICBGZWF0dXJlcz0weGJmZWJmYmZmPEZQVSxWTUUsREUsUFNF LFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2 LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1MsSFRULFRNLFBCRT4KICBGZWF0 dXJlczI9MHgyOWVlM2ZmPFNTRTMsUENMTVVMUURRLERURVM2NCxNT04sRFNfQ1BMLFZNWCxTTVgs RVNULFRNMixTU1NFMyxDWDE2LHhUUFIsUERDTSxQQ0lELERDQSxTU0U0LjEsU1NFNC4yLFBPUENO VCxBRVNOST4KICBBTUQgRmVhdHVyZXM9MHgyYzEwMDgwMDxTWVNDQUxMLE5YLFBhZ2UxR0IsUkRU U0NQLExNPgogIEFNRCBGZWF0dXJlczI9MHgxPExBSEY+CiAgVFNDOiBQLXN0YXRlIGludmFyaWFu dApTTVA6IEFQIENQVSAjNiBMYXVuY2hlZCEKICBDUFU6IEludGVsKFIpIFhlb24oUikgQ1BVICAg ICAgICAgICBFNTYyMCAgQCAyLjQwR0h6ICgyMzk0LjAyLU1IeiBLOC1jbGFzcyBDUFUpCiAgT3Jp Z2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHgyMDZjMiAgU3RlcHBpbmcgPSAyCiAgRmVhdHVy ZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQ LE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNT RSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVyZXMyPTB4MjllZTNmZjxTU0UzLFBDTE1VTFFE USxEVEVTNjQsTU9OLERTX0NQTCxWTVgsU01YLEVTVCxUTTIsU1NTRTMsQ1gxNix4VFBSLFBEQ00s UENJRCxEQ0EsU1NFNC4xLFNTRTQuMixQT1BDTlQsQUVTTkk+CiAgQU1EIEZlYXR1cmVzPTB4MmMx MDA4MDA8U1lTQ0FMTCxOWCxQYWdlMUdCLFJEVFNDUCxMTT4KICBBTUQgRmVhdHVyZXMyPTB4MTxM QUhGPgogIFRTQzogUC1zdGF0ZSBpbnZhcmlhbnQKU01QOiBBUCBDUFUgIzIgTGF1bmNoZWQhCiAg Q1BVOiBJbnRlbChSKSBYZW9uKFIpIENQVSAgICAgICAgICAgRTU2MjAgIEAgMi40MEdIeiAoMjM5 NC4wMi1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4 MjA2YzIgIFN0ZXBwaW5nID0gMgogIEZlYXR1cmVzPTB4YmZlYmZiZmY8RlBVLFZNRSxERSxQU0Us VFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYs Q0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixTU0UsU1NFMixTUyxIVFQsVE0sUEJFPgogIEZlYXR1 cmVzMj0weDI5ZWUzZmY8U1NFMyxQQ0xNVUxRRFEsRFRFUzY0LE1PTixEU19DUEwsVk1YLFNNWCxF U1QsVE0yLFNTU0UzLENYMTYseFRQUixQRENNLFBDSUQsRENBLFNTRTQuMSxTU0U0LjIsUE9QQ05U LEFFU05JPgogIEFNRCBGZWF0dXJlcz0weDJjMTAwODAwPFNZU0NBTEwsTlgsUGFnZTFHQixSRFRT Q1AsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8TEFIRj4KICBUU0M6IFAtc3RhdGUgaW52YXJpYW50 ClNNUDogQVAgQ1BVICM0IExhdW5jaGVkIQogIENQVTogSW50ZWwoUikgWGVvbihSKSBDUFUgICAg ICAgICAgIEU1NjIwICBAIDIuNDBHSHogKDIzOTQuMDItTUh6IEs4LWNsYXNzIENQVSkKICBPcmln aW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDIwNmMyICBTdGVwcGluZyA9IDIKICBGZWF0dXJl cz0weGJmZWJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAs TVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NF LFNTRTIsU1MsSFRULFRNLFBCRT4KICBGZWF0dXJlczI9MHgyOWVlM2ZmPFNTRTMsUENMTVVMUURR LERURVM2NCxNT04sRFNfQ1BMLFZNWCxTTVgsRVNULFRNMixTU1NFMyxDWDE2LHhUUFIsUERDTSxQ Q0lELERDQSxTU0U0LjEsU1NFNC4yLFBPUENOVCxBRVNOST4KICBBTUQgRmVhdHVyZXM9MHgyYzEw MDgwMDxTWVNDQUxMLE5YLFBhZ2UxR0IsUkRUU0NQLExNPgogIEFNRCBGZWF0dXJlczI9MHgxPExB SEY+CiAgVFNDOiBQLXN0YXRlIGludmFyaWFudApTTVA6IEFQIENQVSAjNyBMYXVuY2hlZCEKICBD UFU6IEludGVsKFIpIFhlb24oUikgQ1BVICAgICAgICAgICBFNTYyMCAgQCAyLjQwR0h6ICgyMzk0 LjAyLU1IeiBLOC1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHgy MDZjMiAgU3RlcHBpbmcgPSAyCiAgRmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxU U0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixD TEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVy ZXMyPTB4MjllZTNmZjxTU0UzLFBDTE1VTFFEUSxEVEVTNjQsTU9OLERTX0NQTCxWTVgsU01YLEVT VCxUTTIsU1NTRTMsQ1gxNix4VFBSLFBEQ00sUENJRCxEQ0EsU1NFNC4xLFNTRTQuMixQT1BDTlQs QUVTTkk+CiAgQU1EIEZlYXR1cmVzPTB4MmMxMDA4MDA8U1lTQ0FMTCxOWCxQYWdlMUdCLFJEVFND UCxMTT4KICBBTUQgRmVhdHVyZXMyPTB4MTxMQUhGPgogIFRTQzogUC1zdGF0ZSBpbnZhcmlhbnQK U01QOiBBUCBDUFUgIzUgTGF1bmNoZWQhCiAgQ1BVOiBJbnRlbChSKSBYZW9uKFIpIENQVSAgICAg ICAgICAgRTU2MjAgIEAgMi40MEdIeiAoMjM5NC4wMi1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdp biA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4MjA2YzIgIFN0ZXBwaW5nID0gMgogIEZlYXR1cmVz PTB4YmZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxN VFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixTU0Us U1NFMixTUyxIVFQsVE0sUEJFPgogIEZlYXR1cmVzMj0weDI5ZWUzZmY8U1NFMyxQQ0xNVUxRRFEs RFRFUzY0LE1PTixEU19DUEwsVk1YLFNNWCxFU1QsVE0yLFNTU0UzLENYMTYseFRQUixQRENNLFBD SUQsRENBLFNTRTQuMSxTU0U0LjIsUE9QQ05ULEFFU05JPgogIEFNRCBGZWF0dXJlcz0weDJjMTAw ODAwPFNZU0NBTEwsTlgsUGFnZTFHQixSRFRTQ1AsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8TEFI Rj4KICBUU0M6IFAtc3RhdGUgaW52YXJpYW50CldBUk5JTkc6IFdJVE5FU1Mgb3B0aW9uIGVuYWJs ZWQsIGV4cGVjdCByZWR1Y2VkIHBlcmZvcm1hbmNlLgpSdW5uaW5nIG1seDRfaWJfaW5pdCAoMHhm ZmZmZmZmZjgyYTczYjAwKQpSdW5uaW5nIG1seDRfaW5pdCAoMHhmZmZmZmZmZjgyOTU4MjcwKQpj dXJyZGV2PWRpc2swcDQ6Cm1seDQwOiA8bWx4ND4gbWVtIDB4ZmFmMDAwMDAtMHhmYWZmZmZmZiww eGY4ODAwMDAwLTB4ZjhmZmZmZmYgaXJxIDI0IGF0IGRldmljZSAwLjAgb24gcGNpOApJbmZvOm1s eDRfY29yZTogTWVsbGFub3ggQ29ubmVjdFggY29yZSBkcml2ZXIgdjEuMC1vZmVkMS41LjEgKEFw cmlsIDQsIDIwMDgpCkluZm86bWx4NF9jb3JlOiBJbml0aWFsaXppbmcgbWx4NAptbHg0MDogW0lU SFJFQURdCm1seDQwOiBbSVRIUkVBRF0KSW5mbzptbHg0X2liOiBNZWxsYW5veCBDb25uZWN0WCBJ bmZpbmlCYW5kIGRyaXZlciB2MS4wLW9mZWQxLjUuMSAoQXByaWwgNCwgMjAwOCkKRGVidWc6SFcg bm9kZV9kZXNjOiBNVDI1NDA4IENvbm5lY3RYIE1lbGxhbm94IFRlY2hub2xvZ2llcwpJbmZvOm5v ZGVfZGVzYzogSXNpbG9uSVEgdkhFQUQgLSAtIEJfNzQ2NihERUJVRykKR0VPTV9NSVJST1I6IERl dmljZSBtaXJyb3Ivcm9vdDEgbGF1bmNoZWQgKDIvMikuClRyeWluZyB0byBtb3VudCByb290IGZy b20gdWZzOi9kZXYvbWlycm9yL3Jvb3QxCmliMDogV0FSTklORzogdXNpbmcgb2Jzb2xldGVkIGlm X3dhdGNoZG9nIGludGVyZmFjZQppYjE6IFdBUk5JTkc6IHVzaW5nIG9ic29sZXRlZCBpZl93YXRj aGRvZyBpbnRlcmZhY2UKR0VPTV9NSVJST1I6IERldmljZSBtaXJyb3IvdmFyLWNyYXNoIGxhdW5j aGVkICgxLzEpLgpHRU9NX01JUlJPUjogRGV2aWNlIG1pcnJvci9tZmcgbGF1bmNoZWQgKDIvMiku CkdFT01fTUlSUk9SOiBEZXZpY2UgbWlycm9yL2pvdXJuYWwtYmFja3VwIGxhdW5jaGVkICgyLzIp LgpHRU9NX01JUlJPUjogRGV2aWNlIG1pcnJvci92YXIxIGxhdW5jaGVkICgyLzIpLgpHRU9NX01J UlJPUjogRGV2aWNlIG1pcnJvci92YXIwIGxhdW5jaGVkICgyLzIpLgpHRU9NX01JUlJPUjogRGV2 aWNlIG1pcnJvci9yb290MCBsYXVuY2hlZCAoMi8yKS4KY3hnYmMwOiBbSVRIUkVBRF0KY3hnYmMw OiBbSVRIUkVBRF0KY3hnYmMwOiBbSVRIUkVBRF0KY3hnYmMwOiBbSVRIUkVBRF0KY3hnYmMwOiBb SVRIUkVBRF0KY3hnYmMwOiBbSVRIUkVBRF0KY3hnYmMwOiBbSVRIUkVBRF0KY3hnYmMwOiBbSVRI UkVBRF0KY3hnYmMwOiBbSVRIUkVBRF0KY3hnYmMwOiBzdGFydGluZyB0aHJlYWQgZm9yIDAKY3hn YmMwOiBzdGFydGluZyB0aHJlYWQgZm9yIDQKZXJyb3IgPSAwCmNoYW5nZSB0byBjZWxvZyBpaWQg YmFzZSAwIC0+IDcwMzY4NzQ0MTgxNTU4ICgxOjM4OTQpCmVtMDogZW1fZmxvd19jb250cm9sX3R1 bmFibGUgaXM6IDAgYW5kIGVtX2Zsb3dfY29udHJvbF9zeXNjdGwgaXMgMAplbTA6IERpc2FibGlu ZyBoYXJkd2FyZSBmbG93IGNvbnRyb2wgCmVtMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04K ZW0xOiBlbV9mbG93X2NvbnRyb2xfdHVuYWJsZSBpczogMCBhbmQgZW1fZmxvd19jb250cm9sX3N5 c2N0bCBpcyAwCmVtMTogRGlzYWJsaW5nIGhhcmR3YXJlIGZsb3cgY29udHJvbCAKZW0xOiBsaW5r IHN0YXRlIGNoYW5nZWQgdG8gRE9XTgplbTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUAplbTE6 IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUAptbHg0XzA6IHBvcnQgMiBsaW5rIGlzIGRvd24KbWx4 NF8wOiBwb3J0IDIgbGluayBpcyB1cAo= --0016367b5e425f5ca6049f15543e-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 22 17:12: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 6BD811065686 for ; Tue, 22 Mar 2011 17:12:26 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 256848FC0A for ; Tue, 22 Mar 2011 17:12:25 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 8117BC3835; Tue, 22 Mar 2011 17:52:39 +0100 (CET) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id oaDod86844ni; Tue, 22 Mar 2011 17:52:39 +0100 (CET) Received: from [10.0.0.79] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 02C85C3832; Tue, 22 Mar 2011 17:52:38 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <4D88CA8A.3020808@embedded-brains.de> Date: Tue, 22 Mar 2011 17:52:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3AD09272-7064-4279-AFAE-6E583C49D1D2@semihalf.com> References: <4D88CA8A.3020808@embedded-brains.de> To: Sebastian Huber X-Mailer: Apple Mail (2.1082) Cc: freebsd-hackers@freebsd.org Subject: Re: PowerPC e500v2 and IEEE 754 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, 22 Mar 2011 17:12:26 -0000 On 2011-03-22, at 17:12, Sebastian Huber wrote: > Hello >=20 > does anyone know if FreeBSD provides the software support for full = IEEE 754 > conformance on a PowerPC e500v2 core (for example QorIQ series from = Freescale)? Do you mean using the floating point APU in E500? We basically run with = soft floats only, either at GCC level or kernel-side FPU emulation, the = floating point APU is not utilised currently. Rafal From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 22 17:30: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 F19F7106564A; Tue, 22 Mar 2011 17:30:51 +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 CD1478FC15; Tue, 22 Mar 2011 17:30:51 +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 p2MHUnkx013232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Mar 2011 10:30:51 -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 p2MHUnfA013231; Tue, 22 Mar 2011 10:30:49 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA02254; Tue, 22 Mar 11 09:28:57 PST Date: Tue, 22 Mar 2011 10:28:51 -0700 From: perryh@pluto.rain.com To: panxingxing@mprc.pku.edu.cn Message-Id: <4d88dc53.+BnpvakcLKUHMZGE%perryh@pluto.rain.com> References: <20110319174115.GA33282@dchagin.static.corbina.ru> <20110320071847.GA10579@dchagin.static.corbina.ru> <20110320181911.GA79862@dchagin.static.corbina.ru> <20110321173204.GA7575@dchagin.static.corbina.ru> <20110321200025.GP78089@deviant.kiev.zoral.com.ua> 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: kostikbel@gmail.com, freebsd-hackers@freebsd.org, dchagin@freebsd.org Subject: Re: GSoC'11: DWARF2 call frame information 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, 22 Mar 2011 17:30:52 -0000 Xingxing Pan wrote: > Dose full register tracking means to emit DWARF for all the > registers's saving and restoring in the life time of the function? Most assembly functions are leaves, so saving/restoring around calls to lower-level functions will be infrequent. I suspect it would be more useful to emit debug records that show how the registers are being used, so that gdb can display meaningful names along with their values. And yes, this requires reading and understanding the comments if the code is well commented, or analyzing the code if it is not well commented. It can't be automated. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 22 17:32:21 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 8F09E1065675 for ; Tue, 22 Mar 2011 17:32:21 +0000 (UTC) (envelope-from marktinguely@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 552A78FC1E for ; Tue, 22 Mar 2011 17:32:21 +0000 (UTC) Received: by iyj12 with SMTP id 12so9198774iyj.13 for ; Tue, 22 Mar 2011 10:32:20 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jGKk/MKRfa2191jtAJ3viLqLN0qdjsi5nd4Vvu18zhE=; b=deUskqnCaj2kEYBY8a0Wm7hRjElZKvU50yeynsH3OSPfkHIwIWoxV4Ix6u55G6HVDf gwtQPGA4FlbThxrCC0M5yTNonZOIrWVN8YdRLIoHKhV33lf1K0yv7uIvXo+gbuau44hM rcab665pOerSamaBKY2gDQxKrobE5Sz8ryldY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=x9EPlemQ29s4sQJQes99L+DJyk+Gb0GII+tfrG8qez22bfcqVM6HajS1yCNX3tvR+I sK6t1oU3EDNPhr2OjiWglSZquB0mtdnnjB6k+aaju+IE5KAbaap0U4BCqstQrsprFe+V J41iGllprwegPFOrvS5B9PdHNr+f4TfrX00Ec= Received: by 10.43.54.18 with SMTP id vs18mr9230240icb.313.1300815140433; Tue, 22 Mar 2011 10:32:20 -0700 (PDT) Received: from [192.168.1.104] (c-24-245-26-12.hsd1.mn.comcast.net [24.245.26.12]) by mx.google.com with ESMTPS id 41sm4518327ibi.10.2011.03.22.10.32.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2011 10:32:19 -0700 (PDT) Message-ID: <4D88DD20.7020104@gmail.com> Date: Tue, 22 Mar 2011 12:32:16 -0500 From: Mark Tinguely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: DMA controller on Northbridge? 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, 22 Mar 2011 17:32:21 -0000 On 3/22/2011 12:11 PM, Matthew Fleming wrote: > How can I tell if the Northbridge on a machine has a built-in DMA > controller? And if it does, what device would I use to control it? > > I ask because I'm working with a PCI card that has a 36-bit physical > address limit, and that means bounce buffers when using more than 64GB > of memory. I'd prefer not to use bounce buffers, and since the card's > memory that I'm using is mapped into the physical space of the FreeBSD > host, the entire address space of the card that I care about is > available to FreeBSD. So while pio to the card's memory is too slow > to be useful, if there was a way to use a DMA controller on the > motherboard to get data into and out of the card, that may be > preferable to using the card's DMAC with the limited address space. > > But all that's just theory -- I have no idea how to tell whether the > mobo has a DMAC, and if it does, how to control it. Help? :-) > > Attached is the boot dmesg; I can also run pciconf commands, etc., to > help out with figuring out what I have. > > Thanks, > matthew > > > _______________________________________________ > 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" Sounds like you are referring to IOMMU: http://software.intel.com/en-us/blogs/2009/03/02/intels-virtualization-for-directed-io-aka-iommu-part-1/ --Mark Tinguely From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 22 18:12: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 3ACE31065670 for ; Tue, 22 Mar 2011 18:12:27 +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 CB80F8FC1A for ; Tue, 22 Mar 2011 18:12:26 +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 p2MICJ9d095200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Mar 2011 20:12:19 +0200 (EET) (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 p2MICJhs019763; Tue, 22 Mar 2011 20:12:19 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2MICJd0019762; Tue, 22 Mar 2011 20:12:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Mar 2011 20:12:19 +0200 From: Kostik Belousov To: Matthew Fleming Message-ID: <20110322181219.GU78089@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J7e1NV0wt6ySF7jo" 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 Subject: Re: DMA controller on Northbridge? 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, 22 Mar 2011 18:12:27 -0000 --J7e1NV0wt6ySF7jo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 22, 2011 at 10:11:04AM -0700, Matthew Fleming wrote: > How can I tell if the Northbridge on a machine has a built-in DMA > controller? And if it does, what device would I use to control it? >=20 > I ask because I'm working with a PCI card that has a 36-bit physical > address limit, and that means bounce buffers when using more than 64GB > of memory. I'd prefer not to use bounce buffers, and since the card's > memory that I'm using is mapped into the physical space of the FreeBSD > host, the entire address space of the card that I care about is > available to FreeBSD. So while pio to the card's memory is too slow > to be useful, if there was a way to use a DMA controller on the > motherboard to get data into and out of the card, that may be > preferable to using the card's DMAC with the limited address space. >=20 > But all that's just theory -- I have no idea how to tell whether the > mobo has a DMAC, and if it does, how to control it. Help? :-) >=20 > Attached is the boot dmesg; I can also run pciconf commands, etc., to > help out with figuring out what I have. I believe what are you looking for is ftp://download.intel.com/technology/.../Intel(r)_VT_for_Direct_IO.pdf On my X58 machine it is shown like this: none6@pci0:0:22:2: class=3D0x088000 card=3D0xf38015d9 chip=3D0x34328086 r= ev=3D0x12 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'DMA Engine' class =3D base peripheral cap 11[80] =3D MSI-X supports 1 message in map 0x10 cap 10[90] =3D PCI-Express 2 root endpoint max data 128(128) link x0(x0) cap 01[e0] =3D powerspec 3 supports D0 D3 current D0 --J7e1NV0wt6ySF7jo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2I5oMACgkQC3+MBN1Mb4gUeACeL42bSSf4wYnuIln1Coyq8gMK 24EAoLwk/hrrVsfObn91pUQpqlw9ZiSN =ux7n -----END PGP SIGNATURE----- --J7e1NV0wt6ySF7jo-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 22 18:20: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 49599106567F; Tue, 22 Mar 2011 18:20:13 +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 8CD5C8FC17; Tue, 22 Mar 2011 18:20:12 +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 p2MIK7cS095807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Mar 2011 20:20:07 +0200 (EET) (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 p2MIK7Is019795; Tue, 22 Mar 2011 20:20:07 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2MIK7nL019794; Tue, 22 Mar 2011 20:20:07 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Mar 2011 20:20:07 +0200 From: Kostik Belousov To: Xingxing Pan Message-ID: <20110322182007.GV78089@deviant.kiev.zoral.com.ua> References: <20110319174115.GA33282@dchagin.static.corbina.ru> <20110320071847.GA10579@dchagin.static.corbina.ru> <20110320181911.GA79862@dchagin.static.corbina.ru> <20110321173204.GA7575@dchagin.static.corbina.ru> <20110321200025.GP78089@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k5TNUgu2IV3nirhI" 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, Chagin Dmitry Subject: Re: GSoC'11: DWARF2 call frame information 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, 22 Mar 2011 18:20:13 -0000 --k5TNUgu2IV3nirhI Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 22, 2011 at 11:39:58PM +0800, Xingxing Pan wrote: > 2011/3/22 Kostik Belousov : > > On Mon, Mar 21, 2011 at 08:32:04PM +0300, Chagin Dmitry wrote: > >> On Mon, Mar 21, 2011 at 05:36:13PM +0800, Xingxing Pan wrote: > >> > 2011/3/21 Chagin Dmitry : > >> > >> powerfull script. > >> > >> > >> > >> Xingxing Pan > >> > > > >> > > hmm, which script? I think enough amd64, i386 and amd64/ia32. > >> > > > >> > > I suggest to write a example before continuing the conversation > >> > > about the GSoC. For example (bcopy || bzero) && cpu_switch. > >> > > Is it ok for you? > >> > > > >> > > -- > >> > > Have fun! > >> > > chd > >> > > > >> > > >> > Hi Chargin, > >> > > >> > Thank you for your reply. > >> > The followings shows how I try to add DWARF for bcopy. > >> > > >> > --- ../8.2.0/sys/i386/include/asm.h =9A =9A 2011-03-21 14:35:56.1119= 73722 +0800 > >> > +++ asm.h =9A =9A =9A 2011-03-21 15:25:31.564636162 +0800 > >> > @@ -71,7 +71,7 @@ > >> > > >> > =9A#define _ENTRY(x) =9A =9A =9A_START_ENTRY; \ > >> > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A .globl CNAME(x); .ty= pe CNAME(x),@function; CNAME(x): > >> > -#define =9A =9A =9A =9AEND(x) =9A =9A =9A =9A =9A.size x, . - x > >> > +#define =9A =9A =9A =9AEND(x) =9A =9A =9A =9A =9A.cfi_endproc; .siz= e x, . - x > >> > > >> > =9A#ifdef PROF > >> > =9A#define =9A =9A =9A =9AALTENTRY(x) =9A =9A _ENTRY(x); \ > >> > @@ -80,9 +80,10 @@ > >> > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A popl %ebp; \ > >> > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A jmp 9f > >> > =9A#define =9A =9A =9A =9AENTRY(x) =9A =9A =9A =9A_ENTRY(x); \ > >> > - =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A pushl %ebp; movl %esp,= %ebp; \ > >> > + =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A .cfi_startproc; \ > >> > + =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A pushl %ebp; .cfi_adjus= t_cfa_offset 4; movl > >> > %esp,%ebp; .cfi_def_cfa_register %ebp; \ > >> > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A call PIC_PLT(HIDENAM= E(mcount)); \ > >> > - =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A popl %ebp; \ > >> > + =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A popl %ebp; .cfi_def_cf= a %esp, 4; \ > >> > > >> > --- bcopy.S =9A =9A 2011-03-21 15:51:26.804203809 +0800 > >> > +++ ../8.2.0/lib/libc/i386/string/bcopy.S =9A =9A =9A 2011-03-21 > >> > 14:28:15.023069890 +0800 > >> > @@ -51,9 +51,7 @@ ENTRY(bcopy) > >> > =9A#endif > >> > =9A#endif > >> > =9A =9A =9A =9A pushl =9A %esi > >> > - =9A =9A =9A .cfi_adjust_cfa_offset 4; > >> > =9A =9A =9A =9A pushl =9A %edi > >> > - =9A =9A =9A .cfi_adjust_cfa_offset 4; > >> > =9A#if defined(MEMCOPY) || defined(MEMMOVE) > >> > =9A =9A =9A =9A movl =9A =9A12(%esp),%edi > >> > =9A =9A =9A =9A movl =9A =9A16(%esp),%esi > >> > @@ -77,9 +75,7 @@ ENTRY(bcopy) > >> > =9A =9A =9A =9A rep > >> > =9A =9A =9A =9A movsb > >> > =9A =9A =9A =9A popl =9A =9A%edi > >> > - =9A =9A =9A .cfi_adjust_cfa_offset -4; > >> > =9A =9A =9A =9A popl =9A =9A%esi > >> > - =9A =9A =9A .cfi_adjust_cfa_offset -4; > >> > =9A =9A =9A =9A ret > >> > =9A1: > >> > =9A =9A =9A =9A addl =9A =9A%ecx,%edi =9A =9A =9A /* copy backwards.= */ > >> > @@ -98,9 +94,7 @@ ENTRY(bcopy) > >> > =9A =9A =9A =9A rep > >> > =9A =9A =9A =9A movsl > >> > =9A =9A =9A =9A popl =9A =9A%edi > >> > - =9A =9A =9A .cfi_adjust_cfa_offset -4; > >> > =9A =9A =9A =9A popl =9A =9A%esi > >> > - =9A =9A =9A .cfi_adjust_cfa_offset -4; > >> > =9A =9A =9A =9A cld > >> > =9A =9A =9A =9A ret > >> > =9A#ifdef MEMCOPY > >> > > >> > But I don't know how to add DWARF for cpu_switch, because I have no > >> > idea about the circumstance when we need to backtrace through this > >> > function. Suppose there's a cpu switch like this, > >> > threadA->kernel->threadB. Then should the expected backtrace has the > >> > following result? > >> > > >> > threadB's stack > >> > kernel's stack > >> > threadA's stack > >> > >> > >> hmm, ok. good, avoid cpu_switch. > >> First of all, please, read style(9) man page. > >> In the second, evaluate the proposed plan (discussed with kib@): > >> > >> 1) Annotate libc, msun, rtld, libthr (you) > > 1a) Develop and implement a testing plan to verify the implementation. > > 1b) consider doing full register tracking for assembler code. > > > >> 2) vdso (I'm) > >> 3) Annotate signal trampolines (you, after vdso) > >> > >> And i'm going to understand what I need to do to start GSoC for you. > >> Thanks! > >> > >> > >> -- > >> Have fun! > >> chd > > > > > > >=20 > Hi Kostik, >=20 > I think the basic testing method can be using GDB to set breakpoint in > functions and observing the backtrace result. GDB uses Expect. I can > learn something from GDB's testsuite. Sounds good. >=20 > AFAIK, CFA and return address are enough for unwinding. Dose full > register tracking > means to emit DWARF for all the registers's saving and restoring in > the life time of the function? Not only save and restore, but also for move around. I am mostly about the syscall entry sequence on amd64, see the description of the `syscall' instruction and handling of %rcx in libc sources. Rarely used routines could be left aside. --k5TNUgu2IV3nirhI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEUEARECAAYFAk2I6FYACgkQC3+MBN1Mb4j60wCfdq9vKzB/bauW++Wd3pPckSh+ H9cAl1RGmx0k3/v3U3/DtlBBaOwkrW8= =YxhI -----END PGP SIGNATURE----- --k5TNUgu2IV3nirhI-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 22 18:56: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 C591E106566B for ; Tue, 22 Mar 2011 18:56:02 +0000 (UTC) (envelope-from mdf356@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 5DC328FC08 for ; Tue, 22 Mar 2011 18:56:01 +0000 (UTC) Received: by wyf23 with SMTP id 23so7682732wyf.13 for ; Tue, 22 Mar 2011 11:56:01 -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=j1DdiB0JzUddYAxUYrCKDl1jPk33NAPW4e7TtGjPT7Q=; b=o/6yTPray8FFOV3RNVBKyrDzcmMvYzHbM+nZVAu05BvxA6iC2t38S5RTpGRpDyzJTO hNtn2fMYfNzjeT8MHDpvMYYEbK786g/jMNN4Jy94Mv1jnkrOmEan0KBTbmIaca8TxLDm CaNww4PTmDrHTw0Ghr9NWecFTM88baHKbiJDg= 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=m7732hG02eYNGV98pIf6I5OEYMfSmrM7THeKAvEop3DPz9mJBN2sSvUmzGO68cDTkH a68jOIEFj7a0NRPWx6cuurOhw4uT9JIPI6YAZJd0UNKM/BprBF4ebyRs15GuIkvQcNha SO9exy+3NaETNomCLQIoEtu5jRmt8n+NqBRQY= MIME-Version: 1.0 Received: by 10.216.69.3 with SMTP id m3mr6345396wed.9.1300820159431; Tue, 22 Mar 2011 11:55:59 -0700 (PDT) Received: by 10.216.52.209 with HTTP; Tue, 22 Mar 2011 11:55:59 -0700 (PDT) In-Reply-To: <20110322181219.GU78089@deviant.kiev.zoral.com.ua> References: <20110322181219.GU78089@deviant.kiev.zoral.com.ua> Date: Tue, 22 Mar 2011 11:55:59 -0700 Message-ID: From: Matthew Fleming To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers Subject: Re: DMA controller on Northbridge? 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, 22 Mar 2011 18:56:02 -0000 On Tue, Mar 22, 2011 at 11:12 AM, Kostik Belousov wro= te: > On Tue, Mar 22, 2011 at 10:11:04AM -0700, Matthew Fleming wrote: >> How can I tell if the Northbridge on a machine has a built-in DMA >> controller? =A0And if it does, what device would I use to control it? >> >> I ask because I'm working with a PCI card that has a 36-bit physical >> address limit, and that means bounce buffers when using more than 64GB >> of memory. =A0I'd prefer not to use bounce buffers, and since the card's >> memory that I'm using is mapped into the physical space of the FreeBSD >> host, the entire address space of the card that I care about is >> available to FreeBSD. =A0So while pio to the card's memory is too slow >> to be useful, if there was a way to use a DMA controller on the >> motherboard to get data into and out of the card, that may be >> preferable to using the card's DMAC with the limited address space. >> >> But all that's just theory -- I have no idea how to tell whether the >> mobo has a DMAC, and if it does, how to control it. =A0Help? :-) >> >> Attached is the boot dmesg; I can also run pciconf commands, etc., to >> help out with figuring out what I have. > > I believe what are you looking for is > ftp://download.intel.com/technology/.../Intel(r)_VT_for_Direct_IO.pdf This link doesn't work for me. > On my X58 machine it is shown like this: > none6@pci0:0:22:2: =A0 class=3D0x088000 card=3D0xf38015d9 chip=3D0x343280= 86 rev=3D0x12 hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'Intel Corporation' > =A0 =A0device =A0 =A0 =3D 'DMA Engine' > =A0 =A0class =A0 =A0 =A0=3D base peripheral > =A0 =A0cap 11[80] =3D MSI-X supports 1 message in map 0x10 > =A0 =A0cap 10[90] =3D PCI-Express 2 root endpoint max data 128(128) link = x0(x0) > =A0 =A0cap 01[e0] =3D powerspec 3 =A0supports D0 D3 =A0current D0 I do seem to have several DMA Engine entries in pciconf on this hardware. Hopefully the above doc will explain what to do. :-) Thanks, matthew From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 22 18:58: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 6AF301065675 for ; Tue, 22 Mar 2011 18:58:06 +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 0495C8FC15 for ; Tue, 22 Mar 2011 18:58:05 +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 p2MIw1bL098959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Mar 2011 20:58:02 +0200 (EET) (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 p2MIw12b020011; Tue, 22 Mar 2011 20:58:01 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2MIw1M3020010; Tue, 22 Mar 2011 20:58:01 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Mar 2011 20:58:01 +0200 From: Kostik Belousov To: Matthew Fleming Message-ID: <20110322185801.GW78089@deviant.kiev.zoral.com.ua> References: <20110322181219.GU78089@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eOOSeChkSGCyDSuc" 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 Subject: Re: DMA controller on Northbridge? 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, 22 Mar 2011 18:58:06 -0000 --eOOSeChkSGCyDSuc Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 22, 2011 at 11:55:59AM -0700, Matthew Fleming wrote: > On Tue, Mar 22, 2011 at 11:12 AM, Kostik Belousov w= rote: > > On Tue, Mar 22, 2011 at 10:11:04AM -0700, Matthew Fleming wrote: > >> How can I tell if the Northbridge on a machine has a built-in DMA > >> controller? =9AAnd if it does, what device would I use to control it? > >> > >> I ask because I'm working with a PCI card that has a 36-bit physical > >> address limit, and that means bounce buffers when using more than 64GB > >> of memory. =9AI'd prefer not to use bounce buffers, and since the card= 's > >> memory that I'm using is mapped into the physical space of the FreeBSD > >> host, the entire address space of the card that I care about is > >> available to FreeBSD. =9ASo while pio to the card's memory is too slow > >> to be useful, if there was a way to use a DMA controller on the > >> motherboard to get data into and out of the card, that may be > >> preferable to using the card's DMAC with the limited address space. > >> > >> But all that's just theory -- I have no idea how to tell whether the > >> mobo has a DMAC, and if it does, how to control it. =9AHelp? :-) > >> > >> Attached is the boot dmesg; I can also run pciconf commands, etc., to > >> help out with figuring out what I have. > > > > I believe what are you looking for is > > ftp://download.intel.com/technology/.../Intel(r)_VT_for_Direct_IO.pdf Oops. ftp://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct= _IO.pdf >=20 > This link doesn't work for me. >=20 > > On my X58 machine it is shown like this: > > none6@pci0:0:22:2: =9A class=3D0x088000 card=3D0xf38015d9 chip=3D0x3432= 8086 rev=3D0x12 hdr=3D0x00 > > =9A =9Avendor =9A =9A =3D 'Intel Corporation' > > =9A =9Adevice =9A =9A =3D 'DMA Engine' > > =9A =9Aclass =9A =9A =9A=3D base peripheral > > =9A =9Acap 11[80] =3D MSI-X supports 1 message in map 0x10 > > =9A =9Acap 10[90] =3D PCI-Express 2 root endpoint max data 128(128) lin= k x0(x0) > > =9A =9Acap 01[e0] =3D powerspec 3 =9Asupports D0 D3 =9Acurrent D0 >=20 > I do seem to have several DMA Engine entries in pciconf on this > hardware. Hopefully the above doc will explain what to do. :-) >=20 > Thanks, > matthew --eOOSeChkSGCyDSuc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2I8TkACgkQC3+MBN1Mb4ihfACfQkWJTF9skHJ5Omk59moxN0j4 04cAn2bzAg33v3i8FbB/h+I9MJ2Z7BES =+cn0 -----END PGP SIGNATURE----- --eOOSeChkSGCyDSuc-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 22 21:46: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 9F493106564A; Tue, 22 Mar 2011 21:46:10 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0AE768FC19; Tue, 22 Mar 2011 21:46:09 +0000 (UTC) Received: by fxm11 with SMTP id 11so8240658fxm.13 for ; Tue, 22 Mar 2011 14:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:references:x-comment-to :sender:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=fR18mJ7kxAIrTUU2rHyICIw/qVlUOSaCjACSM4JNkkQ=; b=Vo/oWaslBcdvgFz9+9WHBi9hQ42LoEynZ/QdRKy5CgfLY/M9DXWcvWkuUSd1k18AaU 3fjUurdL1IA+wYrvY6V4n5MGajvqu6xJ5Cz9D0httoqjS66N1/b3auwJ8MnTVlWIN2vt Mx88boyyTO0OSBQdnJekam1QpImA6C0cIC6Fw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=gR4EcHB+xdlBHLu0yNdIi0Xc0Xf/wkJurh1HJxp15Pt73bToE/4VAgLjAur8JMUi/Y zMhEtUg3sSsf9//yzlOCU/zK+S2BxPeB3kn8vA+aMkUydI0iB6kk8L+ml0OtF7taKVIO EV77A33dFqzRV4G/ganA0Q60xBMd4Ev7qTFOg= Received: by 10.223.24.213 with SMTP id w21mr1926735fab.113.1300828681325; Tue, 22 Mar 2011 14:18:01 -0700 (PDT) Received: from localhost ([95.69.172.154]) by mx.google.com with ESMTPS id c11sm3168107fav.2.2011.03.22.14.17.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2011 14:18:00 -0700 (PDT) From: Mikolaj Golub To: Andrey Zonov References: <20110320175123.GA65715@freebsd.org> <4D87BFDA.90007@zonov.org> X-Comment-To: Andrey Zonov Sender: Mikolaj Golub Date: Tue, 22 Mar 2011 23:17:57 +0200 In-Reply-To: <4D87BFDA.90007@zonov.org> (Andrey Zonov's message of "Tue, 22 Mar 2011 00:15:06 +0300") Message-ID: <86y646c0sa.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alexander Best , freebsd-hackers@freebsd.org Subject: Re: issues with kern.devstat.all 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, 22 Mar 2011 21:46:10 -0000 On Tue, 22 Mar 2011 00:15:06 +0300 Andrey Zonov wrote: AZ> Hi, AZ> This sysctl contains a binary data. You can see it using -o or -x AZ> sysctl's key. AZ> Additional information is at devstat(3) manpage. Or try sysutils/devstat :-) -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 22 23:45: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 9BC421065678 for ; Tue, 22 Mar 2011 23:45:26 +0000 (UTC) (envelope-from lgj@usenix.org) Received: from lonestar.usenix.org (lonestar.usenix.org [131.106.3.102]) by mx1.freebsd.org (Postfix) with ESMTP id 85EF78FC17 for ; Tue, 22 Mar 2011 23:45:26 +0000 (UTC) Received: from negroni.usenix.org (negroni.usenix.org [131.106.3.145]) (authenticated bits=0) by lonestar.usenix.org (8.14.2/8.14.2) with ESMTP id p2MNhDH4019141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 22 Mar 2011 16:45:26 -0700 (PDT) From: Lionel Garth Jones Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 22 Mar 2011 16:43:51 -0700 Message-Id: To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-DCC-USENIX-Metrics: lonestar; whitelist X-Spam-Status: No, score=0.7 required=6.0 tests=ALL_TRUSTED, FH_DATE_PAST_20XX autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lonestar X-Mailman-Approved-At: Wed, 23 Mar 2011 01:01:07 +0000 Subject: Hot-ICE '11 Workshop Is Approaching 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, 22 Mar 2011 23:45:26 -0000 We're writing to remind you that the first Workshop on Hot Topics in Management of Internet, Cloud, and Enterprise Networks and Service (Hot-ICE '11) is just a week away. There's still time! Register today and join us in Boston, MA, on March 29, 2011. Hot-ICE '11 will bring together researchers and practitioners working on network and service management in the Internet, cloud, and enterprise domains. The scope of Hot-ICE includes all aspects of network and service management. The program includes sessions on cloud and resource management, service management, network management, and datacenter networking. In addition, a mini-panel will close each session. Check out the full program at: http://www.usenix.org/events/hotice11/tech/ Hot-ICE evolved from earlier Internet Network Management (INM) workshops, which more recently combined with the Workshop on Research on Enterprise Networking (WREN). As such, Hot-ICE, while a new workshop, is serving an established community, but with a broader scope, in recognition of the evolving concerns of the community. Hot-ICE '11 will be co-located with the 8th USENIX Symposium on Networked Systems Design and Implementation (NSDI '11), which will take place March 30-April 1, 2011. Find out more and register today at: http://www.usenix.org/hotice11/progb On behalf of the Hot-ICE '11 Program Committee, Anees Shaikh, IBM Research Kobus Van der Merwe, AT&T Labs--Research Hot-ICE '11 Program Co-Chairs hotice11chairs@usenix.org ----------------------------------------------------------------------- Workshop on Hot Topics in Management of Internet, Cloud, and Enterprise Networks and Services (Hot-ICE '11) March 29, 2011 Boston, MA, USA http://www.usenix.org/hotice11/progb Sponsored by USENIX ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 23 06:05:41 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 839AB1065679 for ; Wed, 23 Mar 2011 06:05:41 +0000 (UTC) (envelope-from lichray@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 42E608FC14 for ; Wed, 23 Mar 2011 06:05:40 +0000 (UTC) Received: by qwc9 with SMTP id 9so6306368qwc.13 for ; Tue, 22 Mar 2011 23:05:40 -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=orHEuMIG85H/PEeKRriziACpK1Ts1jhvWrKHHzSW4xc=; b=vSFlov48aZITce30kxN5g3k77uV1p5Go9+LJ1wr8MP+YIL7l5vmPaoNaQdQziOSVwr l5lr1b0uQH84rMWuZK4283pNR92sFU1/sY6CF77G1/fS0z09m2cp0HayPoe2jjdJKPzX LCn10CmzDs5X0tZNdBVwdTyxXC0up6MR5phsA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=BKcgSdOgNq7cXhL8+j9GQcK5sj7f1YR20hJkgOz7S+pzYcrjnNTHiicOzWFvSFVkzX TCBXZxzWpgkhobQv4oSAYw/W31ipgWenmCWTWQ9JsnUVt2jleMLHdrjkTZ11MAR77OtJ g6ENy97bvAxSIuH+NgT0xmpIS8gG+e87HiJbo= MIME-Version: 1.0 Received: by 10.224.179.142 with SMTP id bq14mr1223904qab.205.1300858784505; Tue, 22 Mar 2011 22:39:44 -0700 (PDT) Received: by 10.224.20.19 with HTTP; Tue, 22 Mar 2011 22:39:44 -0700 (PDT) Date: Wed, 23 Mar 2011 00:39:44 -0500 Message-ID: From: Zhihao Yuan To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: [GSoC] About the idea: Unicode support in vi 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, 23 Mar 2011 06:05:41 -0000 Hi, I'm a Computer Science student at Northern Illinois University, and I used FreeBSD for a long time. I'm interested in the idea that to improve the nvi in the base system. My proposal is slightly different: I want to fork nvi and make it iconv-awared (or mbyte-mode tunable, like tcsh), so that it can deal with more encodings. Can that be a GSoC project proposal? -- Zhihao Yuan The best way to predict the future is to invent it. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 23 07:38: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 374EF10656B5 for ; Wed, 23 Mar 2011 07:38:40 +0000 (UTC) (envelope-from lichray@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 E03748FC08 for ; Wed, 23 Mar 2011 07:38:39 +0000 (UTC) Received: by qwc9 with SMTP id 9so6338840qwc.13 for ; Wed, 23 Mar 2011 00:38: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=mSh5prSC2diuM3YbO2nWr3Q2Y8nvsCUD1S23IfkDjVQ=; b=IH9P1m8sgX7Dx013ICDeBOkbU696ykkordT1bsBGbgA0B4aW1f9Ny+dVeqzt15icL8 aGtXDK2Sisf3fFXPUMZ5xVE6iuVlL/8d+tk4HeExKemQ22mYHCXUMMruBvzrwS5CjCA5 qX6Jx0mKEoYMyd55xwagBfgGsp7E1wX1cDxYQ= 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=uq08w8rurtttsSNL3amvH0QHVggNKLy2F22wAotPO8XwpqLEReUcwPsDvRGbSeqyci 6V4HPHnhlVH9kWIQHSqFy6bpyruIPEUFI9EGUbtR6sIIVElmBdXHX6GNH+WLoAwmX5sg W0wrZuLykWsVKA8qYJr9GrCP007dNpJC2dd/A= MIME-Version: 1.0 Received: by 10.224.211.65 with SMTP id gn1mr5566546qab.355.1300865917371; Wed, 23 Mar 2011 00:38:37 -0700 (PDT) Received: by 10.224.20.19 with HTTP; Wed, 23 Mar 2011 00:38:37 -0700 (PDT) In-Reply-To: <86mxkm1erm.fsf@gmail.com> References: <86mxkm1erm.fsf@gmail.com> Date: Wed, 23 Mar 2011 02:38:37 -0500 Message-ID: From: Zhihao Yuan To: Pan Tsu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 23 Mar 2011 07:38:40 -0000 On Wed, Mar 23, 2011 at 2:23 AM, Pan Tsu wrote: > Zhihao Yuan writes: > >> Hi, >> >> I'm a Computer Science student at Northern Illinois University, and I >> used FreeBSD for a long time. I'm interested in the idea that to >> improve the nvi in the base system. My proposal is slightly different: >> I want to fork nvi and make it iconv-awared (or mbyte-mode tunable, >> like tcsh), so that it can deal with more encodings. Can that be a >> GSoC project proposal? > > Why not just use "traditional vi"? > > =C2=A0http://ex-vi.sourceforge.net/ (lives under editors/2bsd-vi) > > This one lacks of many feature, compared with nvi. I'm not sure whether the FreeBSD system administrators (who opens 100 ssh sessions) agree with that to replace the nvi in base system with this one. However, it's source code can be a great reference for a mbyte-capable nvi. --=20 Zhihao Yuan The best way to predict the future is to invent it. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 23 07:48: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 E7570106567F for ; Wed, 23 Mar 2011 07:48:33 +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 BBD428FC1E for ; Wed, 23 Mar 2011 07:48:33 +0000 (UTC) Received: by thought.org (Postfix, from userid 1001) id 29F9FE80451; Wed, 23 Mar 2011 00:32:35 -0700 (PDT) Date: Wed, 23 Mar 2011 00:32:34 -0700 From: Gary Kline To: Zhihao Yuan Message-ID: <20110323073234.GA17217@thought.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: freebsd-hackers@freebsd.org Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 23 Mar 2011 07:48:34 -0000 On Wed, Mar 23, 2011 at 12:39:44AM -0500, Zhihao Yuan wrote: > Hi, > > I'm a Computer Science student at Northern Illinois University, and I > used FreeBSD for a long time. I'm interested in the idea that to > improve the nvi in the base system. My proposal is slightly different: > I want to fork nvi and make it iconv-awared (or mbyte-mode tunable, > like tcsh), so that it can deal with more encodings. Can that be a > GSoC project proposal? > I'm only speaking for myself [obviously], but I think this would be an excellent idea. I'm using nvi on my FreeBSD server; works fine. But using it on my Ubuntu desktop dails because the "default vi" is vim. vim and nvi are incompat. Having using vi since the earth was formed, I am waaaay stuck with it. Please do keep me posted if you rxpand nvi. gary kline > -- > Zhihao Yuan > The best way to predict the future is to invent it. > _______________________________________________ > 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 Wed Mar 23 09:02: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 C31261065693 for ; Wed, 23 Mar 2011 09:02:46 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 4CE828FC16 for ; Wed, 23 Mar 2011 09:02:45 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id p2N92iIk002449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Mar 2011 10:02:44 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.4/8.14.4) with ESMTP id p2N91uZW028635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Mar 2011 10:01:57 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id p2N91u4W080345; Wed, 23 Mar 2011 10:01:56 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id p2N91uTL080344; Wed, 23 Mar 2011 10:01:56 +0100 (CET) (envelope-from ticso) Date: Wed, 23 Mar 2011 10:01:56 +0100 From: Bernd Walter To: Zhihao Yuan Message-ID: <20110323090156.GQ65750@cicely7.cicely.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-hackers@freebsd.org Subject: Re: [GSoC] About the idea: Unicode support in vi X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 09:02:46 -0000 On Wed, Mar 23, 2011 at 12:39:44AM -0500, Zhihao Yuan wrote: > Hi, > > I'm a Computer Science student at Northern Illinois University, and I > used FreeBSD for a long time. I'm interested in the idea that to > improve the nvi in the base system. My proposal is slightly different: > I want to fork nvi and make it iconv-awared (or mbyte-mode tunable, > like tcsh), so that it can deal with more encodings. Can that be a > GSoC project proposal? This is a very great idea. I'm missing this feature more and more. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 23 09:44: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 631B5106564A for ; Wed, 23 Mar 2011 09:44:59 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 1C5B48FC15 for ; Wed, 23 Mar 2011 09:44:58 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id F09C15AC81; Wed, 23 Mar 2011 10:13:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id EEDB15AC5F; Wed, 23 Mar 2011 10:13:58 +0100 (CET) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id D32765CD2C; Wed, 23 Mar 2011 10:13:58 +0100 (CET) Received: from lexx.ifp.tuwien.ac.at ([128.131.127.223]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.5.2FP1) with ESMTP id 2011032310135854-22905 ; Wed, 23 Mar 2011 10:13:58 +0100 Date: Wed, 23 Mar 2011 10:13:56 +0100 From: Alexey Shuvaev To: Zhihao Yuan Message-ID: <20110323091356.GA9549@lexx.ifp.tuwien.ac.at> References: MIME-Version: 1.0 In-Reply-To: Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.5.2FP1|November 29, 2010) at 03/23/2011 10:13:58 AM, Serialize by Router on domino1/uni-wuerzburg(Release 8.5.2FP1|November 29, 2010) at 03/23/2011 10:13:58 AM, Serialize complete at 03/23/2011 10:13:58 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: freebsd-hackers@freebsd.org Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 23 Mar 2011 09:44:59 -0000 On Wed, Mar 23, 2011 at 12:39:44AM -0500, Zhihao Yuan wrote: > Hi, > > I'm a Computer Science student at Northern Illinois University, and I > used FreeBSD for a long time. I'm interested in the idea that to > improve the nvi in the base system. My proposal is slightly different: > I want to fork nvi and make it iconv-awared (or mbyte-mode tunable, > like tcsh), so that it can deal with more encodings. Can that be a > GSoC project proposal? > +1 here! ports/editors/nvi-devel is another starting point here. As far as I understand it is a further development of nvi which is in base. What I don't like about it is a dependency on databases/db3 and changed (worse, in my opinion) handling of keystrokes in 'insert' mode. But it is iconv-aware implementation already. My 0.02$, Alexey. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 23 07:45:58 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 1044E10656D9 for ; Wed, 23 Mar 2011 07:45:58 +0000 (UTC) (envelope-from inyaoo@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 911B88FC12 for ; Wed, 23 Mar 2011 07:45:57 +0000 (UTC) Received: by ewy1 with SMTP id 1so2312264ewy.13 for ; Wed, 23 Mar 2011 00:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=mUU1HgZJzn5+Bt+E0yXW0VJqsHIZSJjYRATjwc9KZY4=; b=aFcsFnb5WMxtWNbWXSrnj25RtInHgy6K3mLz0+l9yWTItErWZvRnFRISPtgdJucdmy bX5XhVDOx88ntYF0qgHIiH/gQAoSvxmp9OvSlQ8s6HaTprJ/dcPzNEGVMW5SNNlR1WDv hq9JGji85Qoj8lTkrO7dWwyCCQZMBGkXhYC1o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=mwQiOyQbFj42LZYu1pfIdB31dax+1rt6+b2ZTOsO9W0dQ3MwbqcVzTNpsQ4TE1igp9 8Z2derR7HlmAz/h4nVy2Wb+fBOmtbZSape8cOh8H1QIVkGSg/N/kyyb6P7miaAl0+bRu qtnRZe1tMjcVRVilE21Fj/NezClyMeNL/Qwp4= Received: by 10.14.37.75 with SMTP id x51mr2282521eea.71.1300865034738; Wed, 23 Mar 2011 00:23:54 -0700 (PDT) Received: from localhost ([80.62.217.18]) by mx.google.com with ESMTPS id w59sm3386821eeh.3.2011.03.23.00.23.50 (version=SSLv3 cipher=OTHER); Wed, 23 Mar 2011 00:23:53 -0700 (PDT) From: Pan Tsu To: Zhihao Yuan References: Date: Wed, 23 Mar 2011 10:23:41 +0300 In-Reply-To: (Zhihao Yuan's message of "Wed, 23 Mar 2011 00:39:44 -0500") Message-ID: <86mxkm1erm.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Mailman-Approved-At: Wed, 23 Mar 2011 11:11:07 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 23 Mar 2011 07:45:58 -0000 --=-=-= Content-Type: text/plain Zhihao Yuan writes: > Hi, > > I'm a Computer Science student at Northern Illinois University, and I > used FreeBSD for a long time. I'm interested in the idea that to > improve the nvi in the base system. My proposal is slightly different: > I want to fork nvi and make it iconv-awared (or mbyte-mode tunable, > like tcsh), so that it can deal with more encodings. Can that be a > GSoC project proposal? Why not just use "traditional vi"? http://ex-vi.sourceforge.net/ (lives under editors/2bsd-vi) --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=contrib_ex-vi.diff don't forget to extract sources into contrib/ex-vi diff --git a/rescue/rescue/Makefile b/rescue/rescue/Makefile index d62b6f4..e6d8686 100644 --- a/rescue/rescue/Makefile +++ b/rescue/rescue/Makefile @@ -218,7 +218,8 @@ CRUNCH_LIBS+= -larchive -lmd CRUNCH_LIBS+= -lcrypto .endif -CRUNCH_PROGS_usr.bin+= vi +CRUNCH_SRCDIRS+= usr.bin/ex-vi +CRUNCH_PROGS_usr.bin/ex-vi+= vi CRUNCH_ALIAS_vi= ex CRUNCH_PROGS_usr.bin+= id diff --git a/usr.bin/Makefile b/usr.bin/Makefile index f7965f1..ffde23d 100644 --- a/usr.bin/Makefile +++ b/usr.bin/Makefile @@ -169,7 +174,7 @@ SUBDIR= alias \ users \ uudecode \ uuencode \ - vi \ + ex-vi \ vis \ vmstat \ w \ diff --git a/usr.bin/ex-vi/Makefile b/usr.bin/ex-vi/Makefile new file mode 100644 index 0000000..d4db4a5 --- /dev/null +++ b/usr.bin/ex-vi/Makefile @@ -0,0 +1,5 @@ +# $FreeBSD$ + +SUBDIR= expreserve exrecover vi + +.include diff --git a/usr.bin/ex-vi/Makefile.inc b/usr.bin/ex-vi/Makefile.inc new file mode 100644 index 0000000..4b1eb39 --- /dev/null +++ b/usr.bin/ex-vi/Makefile.inc @@ -0,0 +1,11 @@ +# $FreeBSD$ + +SRCDIR= ${.CURDIR}/../../../contrib/ex-vi +.PATH: ${SRCDIR} + +LIBEXECDIR?=/usr/libexec +CFLAGS+=-DVMUNIX + +WARNS?= 1 + +.include "${.CURDIR}/../../Makefile.inc" diff --git a/usr.bin/ex-vi/expreserve/Makefile b/usr.bin/ex-vi/expreserve/Makefile new file mode 100644 index 0000000..ad1d953 --- /dev/null +++ b/usr.bin/ex-vi/expreserve/Makefile @@ -0,0 +1,7 @@ +# $FreeBSD$ + +PROG= expreserve +BINDIR= ${LIBEXECDIR} +NO_MAN= + +.include diff --git a/usr.bin/ex-vi/exrecover/Makefile b/usr.bin/ex-vi/exrecover/Makefile new file mode 100644 index 0000000..e808926 --- /dev/null +++ b/usr.bin/ex-vi/exrecover/Makefile @@ -0,0 +1,9 @@ +# $FreeBSD$ + +PROG= exrecover +BINDIR= ${LIBEXECDIR} +NO_MAN= + +SRCS= exrecover.c mapmalloc.c + +.include diff --git a/usr.bin/ex-vi/vi/Makefile b/usr.bin/ex-vi/vi/Makefile new file mode 100644 index 0000000..d974280 --- /dev/null +++ b/usr.bin/ex-vi/vi/Makefile @@ -0,0 +1,26 @@ +# $FreeBSD$ + +PROG= vi +MAN= ex.1 vi.1 +SRCS= ex.c ex_addr.c ex_cmds.c ex_cmds2.c ex_cmdsub.c \ + ex_data.c ex_extern.c ex_get.c ex_io.c ex_put.c ex_re.c \ + ex_set.c ex_subr.c ex_tagio.c ex_temp.c ex_tty.c ex_unix.c \ + ex_v.c ex_vadj.c ex_vget.c ex_vmain.c ex_voper.c \ + ex_vops.c ex_vops2.c ex_vops3.c ex_vput.c ex_vwind.c \ + printf.c ex_version.c mapmalloc.c + +.for l in ex edit vedit view +LINKS+= ${BINDIR}/vi ${BINDIR}/${l} +.endfor +MLINKS+=ex.1 edit.1 vi.1 vedit.1 vi.1 view.1 + +CFLAGS+=-DUXRE -DREG_ANGLES=0 -DNO_BE_BACKSLASH +CFLAGS+=-DEXPRESERVE=\"${LIBEXECDIR}/expreserve\" \ + -DEXRECOVER=\"${LIBEXECDIR}/exrecover\" +CFLAGS+=-DLISPCODE -DCHDIR -DFASTTAG -DUCVISUAL -DMB -DBIT8 +#CFLAGS+=-DLARGEF + +LDADD+= -lncurses +DPADD+= ${LIBNCURSES} + +.include --=-=-=-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 23 13:38:25 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 2D0CB106566B for ; Wed, 23 Mar 2011 13:38:25 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id 8E48D8FC0C for ; Wed, 23 Mar 2011 13:38:24 +0000 (UTC) Received: (qmail invoked by alias); 23 Mar 2011 13:38:22 -0000 Received: from f055109075.adsl.alicedsl.de (EHLO mandree.no-ip.org) [78.55.109.75] by mail.gmx.net (mp064) with SMTP; 23 Mar 2011 14:38:22 +0100 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX18hgzNJhaQhy5cZhx5ZLqVBXGl5XMsADiO0uPpD4I oHx721O/ZwBjSP Received: from apollo.emma.line.org (apollo.emma.line.org [192.168.0.4]) by merlin.emma.line.org (Postfix) with ESMTP id C330294630 for ; Wed, 23 Mar 2011 14:38:20 +0100 (CET) Received: from [IPv6:::1] (unknown [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id 8E74A25AD87 for ; Wed, 23 Mar 2011 14:38:20 +0100 (CET) Message-ID: <4D89F7CC.1020405@gmx.de> Date: Wed, 23 Mar 2011 14:38:20 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Mnenhy/0.8.3 Thunderbird/3.1.8 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20110323091356.GA9549@lexx.ifp.tuwien.ac.at> In-Reply-To: <20110323091356.GA9549@lexx.ifp.tuwien.ac.at> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 23 Mar 2011 13:38:25 -0000 Am 23.03.2011 10:13, schrieb Alexey Shuvaev: > On Wed, Mar 23, 2011 at 12:39:44AM -0500, Zhihao Yuan wrote: >> Hi, >> >> I'm a Computer Science student at Northern Illinois University, and I >> used FreeBSD for a long time. I'm interested in the idea that to >> improve the nvi in the base system. My proposal is slightly different: >> I want to fork nvi and make it iconv-awared (or mbyte-mode tunable, >> like tcsh), so that it can deal with more encodings. Can that be a >> GSoC project proposal? >> > +1 here! > > ports/editors/nvi-devel is another starting point here. As far as I understand > it is a further development of nvi which is in base. What I don't like > about it is a dependency on databases/db3 and changed (worse, in my opinion) > handling of keystrokes in 'insert' mode. But it is iconv-aware implementation > already. nvi-devel is bit-rotten. Most releases date from 2004, and there was a patchlevel-release in 2007 apparently, since then it's been left to bit rot. I'm thinking about just killing databases/db3 and see what happens with nvi-devel. I tried convincing it to work with db41, and while it compiles, it somehow abuses Berkeley DB in a way I don't see during debugging and barfs with "Invalid argument" on a DB->open call on a recovery file. Also, the documentation says it depends on 3.1, but then we've been using 3.3 for ages, but even the first release of nvi-devel to use Berkeley DB was released when 4.2 was already out. There seems to be some code to make it work (which in itself is buggy it uses broken comparisons for its version checks), but it doesn't work for reasons I don't see with gdb. Berkeley DB doesn't like the way it's being used and errors out with EINVAL. However, I don't care enough to build a debug-enabled version of Berkeley DB to see where abandoned nvi-devel might abuse bdb. vim works for me, supports Unicode, and for "fewer dependencies", we have vim-lite. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 23 15: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 6523B106566B for ; Wed, 23 Mar 2011 15:06:42 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 195A08FC14 for ; Wed, 23 Mar 2011 15:06:41 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 076005AC6B; Wed, 23 Mar 2011 16:06:41 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id F3EF15AC5C; Wed, 23 Mar 2011 16:06:40 +0100 (CET) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id CF59D5CC5C; Wed, 23 Mar 2011 16:06:40 +0100 (CET) Received: from lexx.ifp.tuwien.ac.at ([128.131.127.223]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.5.2FP1) with ESMTP id 2011032316063980-25753 ; Wed, 23 Mar 2011 16:06:39 +0100 Date: Wed, 23 Mar 2011 16:06:39 +0100 From: Alexey Shuvaev To: Matthias Andree Message-ID: <20110323150639.GA14558@lexx.ifp.tuwien.ac.at> References: <20110323091356.GA9549@lexx.ifp.tuwien.ac.at> <4D89F7CC.1020405@gmx.de> MIME-Version: 1.0 In-Reply-To: <4D89F7CC.1020405@gmx.de> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.5.2FP1|November 29, 2010) at 03/23/2011 04:06:39 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.5.2FP1|November 29, 2010) at 03/23/2011 04:06:40 PM, Serialize complete at 03/23/2011 04:06:40 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: freebsd-hackers@freebsd.org Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 23 Mar 2011 15:06:42 -0000 On Wed, Mar 23, 2011 at 02:38:20PM +0100, Matthias Andree wrote: > Am 23.03.2011 10:13, schrieb Alexey Shuvaev: > > On Wed, Mar 23, 2011 at 12:39:44AM -0500, Zhihao Yuan wrote: > >> Hi, > >> > >> I'm a Computer Science student at Northern Illinois University, and I > >> used FreeBSD for a long time. I'm interested in the idea that to > >> improve the nvi in the base system. My proposal is slightly different: > >> I want to fork nvi and make it iconv-awared (or mbyte-mode tunable, > >> like tcsh), so that it can deal with more encodings. Can that be a > >> GSoC project proposal? > >> > > +1 here! > > > > ports/editors/nvi-devel is another starting point here. As far as I understand > > it is a further development of nvi which is in base. What I don't like > > about it is a dependency on databases/db3 and changed (worse, in my opinion) > > handling of keystrokes in 'insert' mode. But it is iconv-aware implementation > > already. > > nvi-devel is bit-rotten. Most releases date from 2004, and there was a > patchlevel-release in 2007 apparently, since then it's been left to bit rot. > > I'm thinking about just killing databases/db3 and see what happens with > nvi-devel. I tried convincing it to work with db41, and while it > compiles, it somehow abuses Berkeley DB in a way I don't see during > debugging and barfs with "Invalid argument" on a DB->open call on a > recovery file. > > Also, the documentation says it depends on 3.1, but then we've been > using 3.3 for ages, but even the first release of nvi-devel to use > Berkeley DB was released when 4.2 was already out. There seems to be > some code to make it work (which in itself is buggy it uses broken > comparisons for its version checks), but it doesn't work for reasons I > don't see with gdb. Berkeley DB doesn't like the way it's being used > and errors out with EINVAL. However, I don't care enough to build a > debug-enabled version of Berkeley DB to see where abandoned nvi-devel > might abuse bdb. > Yes, nvi-devel is not developed any more, but I was saying that nvi in base is even older than nvi-devel, and it is worth looking at it. At least for the iconv support. As for the BDB, maybe strip it just out, if possible? > vim works for me, supports Unicode, and for "fewer dependencies", we > have vim-lite. > From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 23 15:13: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 976A01065676 for ; Wed, 23 Mar 2011 15:13:09 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id DBB768FC0A for ; Wed, 23 Mar 2011 15:13:08 +0000 (UTC) Received: (qmail invoked by alias); 23 Mar 2011 15:13:07 -0000 Received: from f055109075.adsl.alicedsl.de (EHLO mandree.no-ip.org) [78.55.109.75] by mail.gmx.net (mp006) with SMTP; 23 Mar 2011 16:13:07 +0100 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX19hP/dV/kNhMwPFR7UD2kNY6HQXhlpw7Hwbh8FSbS LLJakDKBToTl26 Received: from apollo.emma.line.org (apollo.emma.line.org [192.168.0.4]) by merlin.emma.line.org (Postfix) with ESMTP id BFC64945E1; Wed, 23 Mar 2011 16:13:05 +0100 (CET) Received: from [IPv6:::1] (unknown [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id 86C6225AD87; Wed, 23 Mar 2011 16:13:05 +0100 (CET) Message-ID: <4D8A0E01.8090605@gmx.de> Date: Wed, 23 Mar 2011 16:13:05 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Mnenhy/0.8.3 Thunderbird/3.1.8 MIME-Version: 1.0 To: Alexey Shuvaev References: <20110323091356.GA9549@lexx.ifp.tuwien.ac.at> <4D89F7CC.1020405@gmx.de> <20110323150639.GA14558@lexx.ifp.tuwien.ac.at> In-Reply-To: <20110323150639.GA14558@lexx.ifp.tuwien.ac.at> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-hackers@freebsd.org Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 23 Mar 2011 15:13:09 -0000 Am 23.03.2011 16:06, schrieb Alexey Shuvaev: > Yes, nvi-devel is not developed any more, but I was saying that nvi > in base is even older than nvi-devel, and it is worth looking at > it. At least for the iconv support. As for the BDB, maybe strip it just > out, if possible? I don't believe it's possible, because it uses a RECNO database that is backed by a text file, i. e. it crucially relies on it for data management apparently. But at least db51 and db42 work fine, apparently it was a db41-specific incompatibility that broke nvi-devel 1.81.6_4. Compiling WITH_BDB_HIGHEST=yes should help for the nonce. We're fixing the port to use 4.2 at least. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 23 16:06:03 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 960FF1065670 for ; Wed, 23 Mar 2011 16:06:03 +0000 (UTC) (envelope-from inyaoo@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 245178FC08 for ; Wed, 23 Mar 2011 16:06:02 +0000 (UTC) Received: by fxm11 with SMTP id 11so9036538fxm.13 for ; Wed, 23 Mar 2011 09:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=b7RBPF6GMcagHTabEDPV5/gf3FX1zRZ3fAzNFgwDHrw=; b=C4xtIR8v4+DHff84wup2Fgj4wuW/r4cKJpMhvZpz/QRGn3QcelfhxWmKVYBt1hzjCk 2RUtgXu+yhIAq+jFDe09HvrOjGWO9p9M7upoQ5bNVRUeA7cUpu8o3kIh8JJS/JUfjJBN XmSo0cKdetuxg9nLEy6GIj2sYw7qcUU9v9FoE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=bljXFBfuL0gMxILeglCLkYSWWhi9kVmz6ujlE97MBI4jf8n4yVWstAwCpdqfJtdRlt jc9nMwfiaWceBampO4TKLq1TgbtEGP4b1TVcOCpjJyRsPjcZsX8EXYG7Ojpi66iVFgX7 mDakbujNpfd1FuCU2z8LZeK0m64kJQtmqnNpc= Received: by 10.223.78.193 with SMTP id m1mr118382fak.45.1300896314823; Wed, 23 Mar 2011 09:05:14 -0700 (PDT) Received: from localhost (c-cd6f70d5.017-62-6b73642.cust.bredbandsbolaget.se [213.112.111.205]) by mx.google.com with ESMTPS id j11sm3521921faa.44.2011.03.23.09.05.11 (version=SSLv3 cipher=OTHER); Wed, 23 Mar 2011 09:05:13 -0700 (PDT) From: Pan Tsu To: Zhihao Yuan References: <86mxkm1erm.fsf@gmail.com> Date: Wed, 23 Mar 2011 19:05:03 +0300 In-Reply-To: (Zhihao Yuan's message of "Wed, 23 Mar 2011 02:38:37 -0500") Message-ID: <86aaglx1ow.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-Mailman-Approved-At: Wed, 23 Mar 2011 16:26:45 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 23 Mar 2011 16:06:03 -0000 Zhihao Yuan writes: >> Why not just use "traditional vi"? >> >> http://ex-vi.sourceforge.net/ (lives under editors/2bsd-vi) > > This one lacks of many feature, compared with nvi. nvi also lacks some features, e.g. lisp, modelines, sourceany. ex-vi is more lightweight # both built with DEBUG_FLAGS=-ggdb + mg(1) for reference $ du -Ah * 1.9M nvi 556K ex-vi 505K mg $ size * text data bss dec hex filename 329080 1952 4528 335560 51ec8 nvi 175675 5048 233024 413747 65033 ex-vi 128570 9760 10184 148514 24422 mg > I'm not sure whether the FreeBSD system administrators (who opens 100 > ssh sessions) agree with that to replace the nvi in base system with > this one. Do they expect more features beyond POSIX vi? > However, it's source code can be a great reference for a mbyte-capable > nvi. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 23 20:36:07 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 42E5D106564A for ; Wed, 23 Mar 2011 20:36:07 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id E92D88FC21 for ; Wed, 23 Mar 2011 20:36:06 +0000 (UTC) Received: by qyk35 with SMTP id 35so4915380qyk.13 for ; Wed, 23 Mar 2011 13:36:06 -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=ZfW9AnXfZfpfqtUa1RGQDKE8wrX6TRjBjJLxvXR8fTE=; b=QO1QQOsc5OT8Nca669gv+pKjYr4zdUAECLHta5SB6SxCQuu6n7THsLFCTbcY4d672t 7YLPckgUp4LespFqH5Pral9wjN7BZuUae02/Xd6/GQq8a1sSPKNQ0SVbMTJWJ6wHgdkL 3GARJUzxvWaCADi1eCTN9Zq9HfZ97FNW825zQ= 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=mE+43SAn23wCLpqLvZ52PU36FkQI/Id1UG4ARyiNPw12NZOJM6sTIixuK52RpHKdqS DIPHr+6I2vHjywNzy+DgmQ70ypN33YCrv9855+3O9Grz8n5qoBjN+0msuC6UOfZzsYca 3uBY+uhAehvtBAloK82rkxdj14lcxj8a3C0D4= MIME-Version: 1.0 Received: by 10.224.71.69 with SMTP id g5mr6476910qaj.305.1300912564518; Wed, 23 Mar 2011 13:36:04 -0700 (PDT) Received: by 10.224.20.19 with HTTP; Wed, 23 Mar 2011 13:36:04 -0700 (PDT) In-Reply-To: <86aaglx1ow.fsf@gmail.com> References: <86mxkm1erm.fsf@gmail.com> <86aaglx1ow.fsf@gmail.com> Date: Wed, 23 Mar 2011 15:36:04 -0500 Message-ID: From: Zhihao Yuan To: Pan Tsu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 23 Mar 2011 20:36:07 -0000 On Wed, Mar 23, 2011 at 11:05 AM, Pan Tsu wrote: > Zhihao Yuan writes: > >>> Why not just use "traditional vi"? >>> >>> =C2=A0 http://ex-vi.sourceforge.net/ (lives under editors/2bsd-vi) >> >> This one lacks of many feature, compared with nvi. > > nvi also lacks some features, e.g. lisp, modelines, sourceany. > ex-vi is more lightweight > > =C2=A0# both built with DEBUG_FLAGS=3D-ggdb + mg(1) for reference > > =C2=A0$ =C2=A0du -Ah * > =C2=A01.9M =C2=A0 =C2=A0nvi > =C2=A0556K =C2=A0 =C2=A0ex-vi > =C2=A0505K =C2=A0 =C2=A0mg > > =C2=A0$ size * > =C2=A0 =C2=A0 text =C2=A0 =C2=A0data =C2=A0 =C2=A0 bss =C2=A0 =C2=A0 dec = =C2=A0 =C2=A0 hex filename > =C2=A0 329080 =C2=A0 =C2=A01952 =C2=A0 =C2=A04528 =C2=A0335560 =C2=A0 51e= c8 nvi > =C2=A0 175675 =C2=A0 =C2=A05048 =C2=A0233024 =C2=A0413747 =C2=A0 65033 ex= -vi > =C2=A0 128570 =C2=A0 =C2=A09760 =C2=A0 10184 =C2=A0148514 =C2=A0 24422 mg nvi is a rewrite of the original vi, so this only shows that the new implementation uses more symbols. The actual binary results are just a 120K difference. > >> I'm not sure whether the FreeBSD system administrators (who opens 100 >> ssh sessions) agree with that to replace the nvi in base system with >> this one. > > Do they expect more features beyond POSIX vi? Like multiple windows. This has been discussed y other BSDs before. > >> However, it's source code can be a great reference for a mbyte-capable >> nvi. > --=20 Zhihao Yuan The best way to predict the future is to invent it. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 23 22:16: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 329201065673 for ; Wed, 23 Mar 2011 22:16:40 +0000 (UTC) (envelope-from lacombar@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 EC5128FC19 for ; Wed, 23 Mar 2011 22:16:39 +0000 (UTC) Received: by iwn33 with SMTP id 33so10845509iwn.13 for ; Wed, 23 Mar 2011 15:16: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=sEUkYxlV5UWiRfg9dVWgydV+OsPnrcQGFvzUqVK8wzI=; b=GTWTfieRjX1FagF0KbaEpXPTcCwHFyYVmxGo85Lf+kZJeAkagekqZ0yxuYjQ31vu83 WhGFFnN49AagYMMYx+MuzKU6SQuNJ3bi7IuydSsSApBaTXoq6CO+laPtZeRMg++EhmvU CiBmL852xynG47FSrMVVNXFrXAxsc8Io8IhVU= 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=hVTP4yURRIaSuTB74OOwscnpwKZgTp2CLQKYgZpq302nqfQ0qSZ0o3F+ao2dXHOUEo BAComSY4oH0woze7rH46XCD6UCQkzhxX9Upgn4qx1jkWe2GMp7vVl66LsGYcPoEI43BH mK9kP0MFQw+XPdHI+RY2z/r1N42lP/WbRg8y4= MIME-Version: 1.0 Received: by 10.43.63.72 with SMTP id xd8mr7786icb.215.1300917005677; Wed, 23 Mar 2011 14:50:05 -0700 (PDT) Received: by 10.42.146.72 with HTTP; Wed, 23 Mar 2011 14:50:05 -0700 (PDT) In-Reply-To: References: <86mxkm1erm.fsf@gmail.com> <86aaglx1ow.fsf@gmail.com> Date: Wed, 23 Mar 2011 17:50:05 -0400 Message-ID: From: Arnaud Lacombe To: Zhihao Yuan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Pan Tsu Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 23 Mar 2011 22:16:40 -0000 Hi, On Wed, Mar 23, 2011 at 4:36 PM, Zhihao Yuan wrote: > On Wed, Mar 23, 2011 at 11:05 AM, Pan Tsu wrote: >> Zhihao Yuan writes: >>> I'm not sure whether the FreeBSD system administrators (who opens 100 >>> ssh sessions) agree with that to replace the nvi in base system with >>> this one. >> >> Do they expect more features beyond POSIX vi? > > Like multiple windows. This has been discussed y other BSDs before. > For the reference, on the Linux side, busybox do all what an admin would reasonably expect (I mean _all_ the basic userland, not just editing text) in a binary smaller than nvi. Now, it's true that _you_ might not care about size/bloat, at least accept that some do. - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 23 23:32: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 817CD106566B for ; Wed, 23 Mar 2011 23:32:06 +0000 (UTC) (envelope-from lichray@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 30A818FC0C for ; Wed, 23 Mar 2011 23:32:06 +0000 (UTC) Received: by qwc9 with SMTP id 9so7039235qwc.13 for ; Wed, 23 Mar 2011 16:32:05 -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=idFNiRlZkLyCcRORmILcUVrJy8FFfpZwhwnmXSP4HDQ=; b=kQlYd7hvQbX0UODkJo0kWY6rmiA90Yx9JNKFi3MKWTnIVcDGyINhj+L8ArR8cNcxms 1ic8NQdxU33qGF0aW35mmZ52G0g22Tkbr8D18AzlGHoSq1RptOSMEG5ZngOi7+e7k0p/ gPLggXfYY7n7b00dVkIs7GSBSfKG3VOdxZs3s= 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=JVOrlOK4M0jIzaxbzM/b34OsIoOo65kfEnViIIBgl5XTex5fMuIV09zP06qAHtxUob yj1ZJCfZs/W9vlXxBZIGQkugw9BfVE9ixF5Gk8KTyVojIdfhHbdF0wApHZXDYsMciysP /RC0TvXhI1LhHJmnr/M1GPp2zzG4qJp46qkt8= MIME-Version: 1.0 Received: by 10.224.200.196 with SMTP id ex4mr6554850qab.5.1300923125379; Wed, 23 Mar 2011 16:32:05 -0700 (PDT) Received: by 10.224.20.19 with HTTP; Wed, 23 Mar 2011 16:32:05 -0700 (PDT) In-Reply-To: References: <86mxkm1erm.fsf@gmail.com> <86aaglx1ow.fsf@gmail.com> Date: Wed, 23 Mar 2011 18:32:05 -0500 Message-ID: From: Zhihao Yuan To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Pan Tsu Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 23 Mar 2011 23:32:06 -0000 On Wed, Mar 23, 2011 at 4:50 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Mar 23, 2011 at 4:36 PM, Zhihao Yuan wrote: >> On Wed, Mar 23, 2011 at 11:05 AM, Pan Tsu wrote: >>> Zhihao Yuan writes: >>>> I'm not sure whether the FreeBSD system administrators (who opens 100 >>>> ssh sessions) agree with that to replace the nvi in base system with >>>> this one. >>> >>> Do they expect more features beyond POSIX vi? >> >> Like multiple windows. This has been discussed y other BSDs before. >> > For the reference, on the Linux side, busybox do all what an admin > would reasonably expect (I mean _all_ the basic userland, not just > editing text) in a binary smaller than nvi. Now, it's true that _you_ > might not care about size/bloat, at least accept that some do. > > =C2=A0- Arnaud > Among *all* the GNU/Linux distributions I used, they include a vim compiled in tiny mode (ln -s it to vi), which doubles the size of nvi, in their base systems. A vim.tiny contains much more features compared with nvi, but it's not compatible with POSIX vi. --=20 Zhihao Yuan The best way to predict the future is to invent it. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 00:26:08 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 92DF9106566C for ; Thu, 24 Mar 2011 00:26:08 +0000 (UTC) (envelope-from lacombar@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 582EA8FC14 for ; Thu, 24 Mar 2011 00:26:08 +0000 (UTC) Received: by iyj12 with SMTP id 12so11012977iyj.13 for ; Wed, 23 Mar 2011 17:26:07 -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=3Mct6zAm3TBIRfPR+xcDLfkYqCSJbNUzP2AfRHjVCQM=; b=KqR7JMqOotKyIvbkBybIWmn1t74SoyJYIvPUlpsXb0QqYmZPUjNQCYSWmDF+AyFuTJ URC7LZXkxq4Hh6TWTkGXJkFDNtxkM74eQc3CKjPndl3gxKZ2HcN4KbOeP5qLiU2HPUxs 6NBlkIEBx/37KlXShDzltcMYXi7hdXA4ctfPY= 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=Wrq9YlfRu8w8++G1zxq+FXhIZICZIRwdLLBvT4JJPP41zfURfcsAnOPhj80rO3ccw8 qTYq8kp3OPKu6fgGwyvyEVnKLyHvNQJ0/fQ018PJq22qM1+YkH0xlmHbO2GchVTDx41f i9donnxemxTy27BvDXy5yTjrJEBxGj+LwsZb4= MIME-Version: 1.0 Received: by 10.42.219.65 with SMTP id ht1mr3414777icb.14.1300926367533; Wed, 23 Mar 2011 17:26:07 -0700 (PDT) Received: by 10.42.146.72 with HTTP; Wed, 23 Mar 2011 17:26:07 -0700 (PDT) In-Reply-To: References: <86mxkm1erm.fsf@gmail.com> <86aaglx1ow.fsf@gmail.com> Date: Wed, 23 Mar 2011 20:26:07 -0400 Message-ID: From: Arnaud Lacombe To: Zhihao Yuan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Pan Tsu Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 24 Mar 2011 00:26:08 -0000 Hi, On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan wrote: > Among *all* the GNU/Linux distributions I used, they include a vim > compiled in tiny mode (ln -s it to vi), which doubles the size of nvi, > in their base systems. A vim.tiny contains much more features compared > with nvi, but it's not compatible with POSIX vi. > Let's compare the comparable, I don't really care if PCbsd ship vim as its default, but FreeBSD as the base is not only aimed at desktop specifically. So you should take into account that I may want to run FreeBSD on an adm5120 board with 32MB of RAM, without having a text editor consuming too much disk-space/ram. - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 01:20: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 00DBD106566C for ; Thu, 24 Mar 2011 01:20:09 +0000 (UTC) (envelope-from lichray@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 9DEF28FC16 for ; Thu, 24 Mar 2011 01:20:08 +0000 (UTC) Received: by qwc9 with SMTP id 9so7081591qwc.13 for ; Wed, 23 Mar 2011 18:20:07 -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=FYwedZcplAv99J3eSQ90ZTWkQR/uLv5vOemfitMJafk=; b=cwPvFeZ0WQxlTbtT5T74q2/2mCJwUlIyLVcZny5FHc9uvDS/zKvOtfK80m9SU3tK5P 8W/QQ5zpWroNOWSLQCTOz3Fe2IP+Lfupr3axfhQaqRqhCvPdu8X6et8rcIJGUUb1mXjJ rbNZhbyUfdNlIPWlfEeGoRYFeWqWf3DLGNjyo= 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=M1ylY1dh36yntntOCPPJDfLt0MQhXQiTUsQdHO9B4FW09uKlPmTBbK/QwNrgkZI39E 1LPoLubajcNT8fFbem3j15X3RvchvnwJ0NkCPPdVZbup2y46MEdCeRZrMHtD4B2M2BCS GcEcA3YADkxSGbKttU5+r1Y7QeIrzmF5nLGOE= MIME-Version: 1.0 Received: by 10.224.18.195 with SMTP id x3mr6025342qaa.55.1300929607171; Wed, 23 Mar 2011 18:20:07 -0700 (PDT) Received: by 10.224.20.19 with HTTP; Wed, 23 Mar 2011 18:20:07 -0700 (PDT) In-Reply-To: References: <86mxkm1erm.fsf@gmail.com> <86aaglx1ow.fsf@gmail.com> Date: Wed, 23 Mar 2011 20:20:07 -0500 Message-ID: From: Zhihao Yuan To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Pan Tsu Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 24 Mar 2011 01:20:09 -0000 On Wed, Mar 23, 2011 at 7:26 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan wrote: >> Among *all* the GNU/Linux distributions I used, they include a vim >> compiled in tiny mode (ln -s it to vi), which doubles the size of nvi, >> in their base systems. A vim.tiny contains much more features compared >> with nvi, but it's not compatible with POSIX vi. >> > Let's compare the comparable, I don't really care if PCbsd ship vim as > its default, but FreeBSD as the base is not only aimed at desktop > specifically. So you should take into account that I may want to run > FreeBSD on an adm5120 board with 32MB of RAM, without having a text > editor consuming too much disk-space/ram. > > =C2=A0- Arnaud > If you really want to use vi in a 32MB mem environment, the ex-vi may make sense. It consumes 1600KB memory while nvi consumes 2000KB. Note that the ee editor uses same amount memory as ex-vi. So basically, if no one disagree that we can drop the infinite undo, multiple buffer, multiple window and some other potential missing features, we can replace the nvi in the base system with ex-vi. --=20 Zhihao Yuan The best way to predict the future is to invent it. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 03:11: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 AA8C61065679 for ; Thu, 24 Mar 2011 03:11:48 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254:10::3c]) by mx1.freebsd.org (Postfix) with ESMTP id 634C48FC0C for ; Thu, 24 Mar 2011 03:11:48 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.4/8.14.4) with ESMTP id p2O3Blgm074087; Wed, 23 Mar 2011 23:11:47 -0400 (EDT) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.4/8.14.4/Submit) id p2O3Bl5j074086; Wed, 23 Mar 2011 23:11:47 -0400 (EDT) (envelope-from lidl) Date: Wed, 23 Mar 2011 23:11:47 -0400 From: Kurt Lidl To: Zhihao Yuan Message-ID: <20110324031147.GA73950@pix.net> References: <86mxkm1erm.fsf@gmail.com> <86aaglx1ow.fsf@gmail.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: freebsd-hackers@freebsd.org Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 24 Mar 2011 03:11:48 -0000 On Wed, Mar 23, 2011 at 08:20:07PM -0500, Zhihao Yuan wrote: > On Wed, Mar 23, 2011 at 7:26 PM, Arnaud Lacombe wrote: > > Hi, > > > > On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan wrote: > >> Among *all* the GNU/Linux distributions I used, they include a vim > >> compiled in tiny mode (ln -s it to vi), which doubles the size of nvi, > >> in their base systems. A vim.tiny contains much more features compared > >> with nvi, but it's not compatible with POSIX vi. > >> > > Let's compare the comparable, I don't really care if PCbsd ship vim as > > its default, but FreeBSD as the base is not only aimed at desktop > > specifically. So you should take into account that I may want to run > > FreeBSD on an adm5120 board with 32MB of RAM, without having a text > > editor consuming too much disk-space/ram. > > > > ??- Arnaud > > If you really want to use vi in a 32MB mem environment, the ex-vi may > make sense. It consumes 1600KB memory while nvi consumes 2000KB. Note > that the ee editor uses same amount memory as ex-vi. > > So basically, if no one disagree that we can drop the infinite undo, > multiple buffer, multiple window and some other potential missing > features, we can replace the nvi in the base system with ex-vi. Please don't do this. I use nvi every day on FreeBSD. I use the multi-level undo daily, and the multiple window feature, if not daily, at least weekly. -Kurt From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 03:47: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 386B91065673 for ; Thu, 24 Mar 2011 03:47:10 +0000 (UTC) (envelope-from inyaoo@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 B411B8FC08 for ; Thu, 24 Mar 2011 03:47:09 +0000 (UTC) Received: by wyf23 with SMTP id 23so9229315wyf.13 for ; Wed, 23 Mar 2011 20:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=0ZUkw6bXukOdmbMp9DDMRbst0k0GCuDC6Z8Wox5dxKw=; b=QSiptlxGUie9ncAxjKoHy81k+oX40tsaBK/CK8qRjar40wyc02L90RK2oX4uLTutKt 4YZVdI+q5W8kFvImQXcKpi7++DPHcxYKHfk+bfncLM6cRc1e0a/H8YxZAnvjzCBCGITk dzWYzcyKjaylOc7C9lRNE7R6Pek5OLmfgimUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=uIToXA5qYChv3LvaSXuOEnNYNbrTo07dKpNpv18qzYhwcsN8mVaxwDZmi3WpeSK+28 M5ZmnBZP7Ec+yCxB1cCVP3HGdDgsonGx1SsEYyqEb4B029DILYZw7oOyxmmbRxlv6CRo CvfbA6ouIEMCON1gHFGNDS3Kxb6i5b1AZygzE= Received: by 10.227.208.73 with SMTP id gb9mr7303614wbb.194.1300938428762; Wed, 23 Mar 2011 20:47:08 -0700 (PDT) Received: from localhost (load-me-in-a-browser-if-this-tor-node-is-causing-you-grief.riseup.net [77.109.139.87]) by mx.google.com with ESMTPS id bs4sm2244040wbb.18.2011.03.23.20.46.58 (version=SSLv3 cipher=OTHER); Wed, 23 Mar 2011 20:47:07 -0700 (PDT) From: Pan Tsu To: Zhihao Yuan References: <86mxkm1erm.fsf@gmail.com> <86aaglx1ow.fsf@gmail.com> Date: Thu, 24 Mar 2011 06:46:53 +0300 In-Reply-To: (Zhihao Yuan's message of "Wed, 23 Mar 2011 20:20:07 -0500") Message-ID: <86k4fpb2oi.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-hackers@freebsd.org, Arnaud Lacombe Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 24 Mar 2011 03:47:10 -0000 Zhihao Yuan writes: > If you really want to use vi in a 32MB mem environment, the ex-vi may > make sense. It consumes 1600KB memory while nvi consumes 2000KB. Note > that the ee editor uses same amount memory as ex-vi. ex-vi memory usage can be reduced a bit, e.g. by ~20% if you drop -DLISPCODE -DCHDIR -DFASTTAG -DUCVISUAL -DMB -DBIT8 in particular multibyte support. > So basically, if no one disagree that we can drop the infinite undo, > multiple buffer, multiple window and some other potential missing > features, we can replace the nvi in the base system with ex-vi. If the intent is to make all interactive editors in base unicode aware then I wonder if you can use similar excuse when window(1) was kicked out but for missing features, i.e. use ports. As for other editors, ed(1) seems to support editing UTF-8. I've used it to read/edit cyrillic and CJK texts in single user mode before found out about ex-vi. And ee(1)... why not add unicode support there as a GSoC? From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 06:16: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 E6AB71065670 for ; Thu, 24 Mar 2011 06:16:33 +0000 (UTC) (envelope-from lichray@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 94C4F8FC08 for ; Thu, 24 Mar 2011 06:16:33 +0000 (UTC) Received: by qwc9 with SMTP id 9so7174287qwc.13 for ; Wed, 23 Mar 2011 23:16:32 -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=cg8ScjGn6nl/BFwON1KJmwoUUGSdzlmZiaXZEpSQRQQ=; b=DTOs8AI09ODz6iaCe8gerqo831+mv/dUZYrvOtQha0GPzilAmXJub9zNqA0u/hl2Ty miS2r7IzJnLivyZ8kwPwTfYCbZ8C+UpIXtigFQ0IGG1+aXZCTV+rznInfGTHH+Qjw9IJ u1EjKxbLFWJOFiNKGtKDlogM/AiFyAJi7kmgc= 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=wx8PBvVK0nGj3PHQletRpvpERAeBmVMz182FwfWxSBnQrCBTw1BJfWk07WMN1s9+Rx J4WvOAaBdeWrWwDsDvqDAt6Y00m59WQ7qOwd4Y6VYAOgHDHEBLT4jyXWf2er9POmf062 NNrMGOpoXaXE0KDH5LH1n94zANZWeGgZaYybQ= MIME-Version: 1.0 Received: by 10.224.61.1 with SMTP id r1mr4471882qah.105.1300947392432; Wed, 23 Mar 2011 23:16:32 -0700 (PDT) Received: by 10.224.20.19 with HTTP; Wed, 23 Mar 2011 23:16:32 -0700 (PDT) In-Reply-To: <86k4fpb2oi.fsf@gmail.com> References: <86mxkm1erm.fsf@gmail.com> <86aaglx1ow.fsf@gmail.com> <86k4fpb2oi.fsf@gmail.com> Date: Thu, 24 Mar 2011 01:16:32 -0500 Message-ID: From: Zhihao Yuan To: Pan Tsu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Arnaud Lacombe Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 24 Mar 2011 06:16:34 -0000 On Wed, Mar 23, 2011 at 10:46 PM, Pan Tsu wrote: > Zhihao Yuan writes: > >> If you really want to use vi in a 32MB mem environment, the ex-vi may >> make sense. It consumes 1600KB memory while nvi consumes 2000KB. Note >> that the ee editor uses same amount memory as ex-vi. > > ex-vi memory usage can be reduced a bit, e.g. by ~20% if you drop > =C2=A0-DLISPCODE -DCHDIR -DFASTTAG -DUCVISUAL -DMB -DBIT8 > in particular multibyte support. > >> So basically, if no one disagree that we can drop the infinite undo, >> multiple buffer, multiple window and some other potential missing >> features, we can replace the nvi in the base system with ex-vi. > > If the intent is to make all interactive editors in base unicode aware > then I wonder if you can use similar excuse when window(1) was kicked > out but for missing features, i.e. use ports. If user accepts the window or even screen in ports, they can also accept ex-vi staying in ports. > > As for other editors, ed(1) seems to support editing UTF-8. I've used it > to read/edit cyrillic and CJK texts in single user mode before found out > about ex-vi. And ee(1)... why not add unicode support there as a GSoC? > ed seems works, but it's not either vi or ex. I'm not typically like ee... I sill wondering why we kept it in base system. It does not work when termcap is not correct, so I still need to use ed in such a case. Same thing happens to ex-vi. --=20 Zhihao Yuan The best way to predict the future is to invent it. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 08:46: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 E6A951065670 for ; Thu, 24 Mar 2011 08:46:15 +0000 (UTC) (envelope-from inyaoo@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 7CF908FC12 for ; Thu, 24 Mar 2011 08:46:15 +0000 (UTC) Received: by wyf23 with SMTP id 23so9451441wyf.13 for ; Thu, 24 Mar 2011 01:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:references:date:message-id :user-agent:mime-version:content-type; bh=8QniMvfiEIzUf6NZmPi1zCrpD/rypGbZBXPa+ImXeLk=; b=X233Uufk9YrsedX+9JjvNDl/MOvW0th9i+rjYBlxxVVPPI+b2KaQHZm0mHahCCMaEn NiDYx+hLebfeKdW6PXjGX9hycGHhdbbrOjyoVfOga2j66+flpBE1q3TAPeccvoqtUtSS T2wneLjAarE9HzZpxt/VjKO9S8ZAo+/BI+8G0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-type; b=qJxnEEA8vGpHuO21b/DuE4ZWk3WoeofMbcrAvX9/Ia+bHqqlCRCAEEXy1RtKXtDydp Q4jF/GZC070GnaWGFLaFMCnieU4Sw0vV3u/4yxcSutU+NNLSB8UvKC9p7tENNvbZMBov ydWb4J2E3xblvl9MsEQPSu8XCEKf2FcaiGrq0= Received: by 10.216.120.129 with SMTP id p1mr7731000weh.81.1300956374401; Thu, 24 Mar 2011 01:46:14 -0700 (PDT) Received: from localhost (tor3.anonymizer.ccc.de [80.237.226.73]) by mx.google.com with ESMTPS id l5sm3644939wej.32.2011.03.24.01.46.08 (version=SSLv3 cipher=OTHER); Thu, 24 Mar 2011 01:46:10 -0700 (PDT) From: Pan Tsu To: Oliver Fromme References: <20110323171443.GA59972@freebsd.org> <201103231750.p2NHoSF6009826@lurza.secnetix.de> Date: Thu, 24 Mar 2011 11:46:04 +0300 Message-ID: <868vw4hpo3.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-hackers@freebsd.org Subject: Is BOOTWAIT still used? (Was: kernel memory checks on boot vs. boot time) 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, 24 Mar 2011 08:46:16 -0000 Oliver Fromme writes: [...] > To be honest, I don't think that loader takes so much time. > When you set autoboot_delay="-1" and beastie_disable="YES", > the time spent in loader is negligible. (I'm assuming that > you also set BOOTWAIT=0 in make.conf, so boot2 doesn't wait > for a keypress either. I think the default is to wait 3 > seconds.) Is BOOTWAIT still used? A quick grep in sys/boot shows nothing. Digging history, BOOTWAIT never made its way from sys/i386/boot to sys/boot/i386 and was removed in r58284 around 11y ago. And more recently it disappeared from pc98, see r201342. %% Index: share/examples/etc/make.conf =================================================================== --- share/examples/etc/make.conf (revision 219947) +++ share/examples/etc/make.conf (working copy) @@ -138,14 +138,6 @@ #PRINTERDEVICE= ps # # -# How long to wait for a console keypress before booting the default kernel. -# This value is approximately in milliseconds. Keypresses are accepted by the -# BIOS before booting from disk, making it possible to give custom boot -# parameters even when this is set to 0. -# -#BOOTWAIT=0 -#BOOTWAIT=30000 -# # By default, the system will always use the keyboard/video card as system # console. However, the boot blocks may be dynamically configured to use a # serial port in addition to or instead of the keyboard/video console. Index: share/man/man5/make.conf.5 =================================================================== --- share/man/man5/make.conf.5 (revision 219947) +++ share/man/man5/make.conf.5 (working copy) @@ -330,14 +330,6 @@ This defaults to The following list provides a name and short description for variables that are only used doing a kernel build: .Bl -tag -width Ar -.It Va BOOTWAIT -.Pq Vt int -Controls the amount of time the kernel waits for a console keypress -before booting the default kernel. -The value is approximately milliseconds. -Keypresses are accepted by the BIOS before booting from disk, -making it possible to give custom boot parameters even when this is -set to 0. .It Va COPTFLAGS .Pq Vt str Controls the compiler settings when building the %% From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 09:31: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 D61D31065688; Thu, 24 Mar 2011 09:31:18 +0000 (UTC) (envelope-from jing.huang.pku@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 780628FC18; Thu, 24 Mar 2011 09:31:18 +0000 (UTC) Received: by qyk27 with SMTP id 27so7658064qyk.13 for ; Thu, 24 Mar 2011 02:31:17 -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:cc :content-type; bh=1Rjpfy168l9xD15+OLFoRng70GyiPM5QdrHqdQuD9YI=; b=usCqc0A+PKF5TEf7ncqCb5XaBiQhyxyNDLTe5dSn2BV0e5HhQgm56QY2p+QM/wxIIe yhDLRegz/9TS92vvPrW+6NGX1dHsqj6AeY2ZUzv7kQRNh/thUF6mjc8Nbz2Jpy8fWN2X h36iOjHwMeHci1rruQjonFBK0lokPctys+ZdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=AS73dEHzHdEzbu02w1HS9tRfFuXODwppS63DdEurvHR/sOftamMsadsbvRtIZGnfkf KBfuOVtSq9lecpXgogvBjG0qOEoUzKSqU2yoapTa0xDVEr0IMaI8MQD3raAFTxR/N8f/ ke54/r35fvKA797OwdWrJCFqcorS988xCaJeI= MIME-Version: 1.0 Received: by 10.224.49.149 with SMTP id v21mr6959649qaf.26.1300957202647; Thu, 24 Mar 2011 02:00:02 -0700 (PDT) Received: by 10.229.100.132 with HTTP; Thu, 24 Mar 2011 02:00:02 -0700 (PDT) Date: Thu, 24 Mar 2011 17:00:02 +0800 Message-ID: From: Jing Huang To: kris@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, hackers@FreeBSD.org Subject: Timecounter Project (GSoc2011) 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, 24 Mar 2011 09:31:18 -0000 Hi Everyone, I am a student of Peking University in China. I am interest in the FreeBSD project of "Timecounter Performance Improvements". I am familiar with Linux kernel and virtualization systems, like KVM and Xen. I have maintained the Linux Server for my College for last whole year. Recently, I learned a lot about KVM and assigned VMs to students who need them. I also have experience of install and config FreeBSD system. In this scenario, I plan to use both tsc and shared memory to calculate precise time in user mode. The shared memory includes system_time, tsc_system_time and factor_tsc-system_time. a) system_time is the current time since the system boots, and it will be updated by time interrupt handling function. b) tsc_system_time is the tsc value when system_time update, and it is used to calculate rough delta. c) factor_tsc-system_time records the correspondence between tsc and time. It is used to calculate precise delta. When the process invokes gettimeofday, our mechanism will calculate time like: system_time+ ( factor_tsc-system_time(instant_rdtsc - tsc_system_time ) ). We see factor_tsc-system_time as a computing method here. I could refer to the relative implementation in KVM or Xen virtual machine. The real problem is that tsc counter is CPU sensitive. Our process will get wrong tsc value when switching to another CPU. I plan to force the FreeBSD kernel to update shared memory when monitoring context switch event. Alternatively, we can build NR_CPUS shared memories, and every CPU has one. Hmm.. how to recognize which CPU we are using in user mode? We also consider the CPU frequency, because tsc counter is related to it. When kernel changes CPU frequency, the shared memory should be update subsequently. Would some one give me some suggestions? Looking forward to your reply. yours sincerely. Jing From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 09:31:18 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 D61D31065688; Thu, 24 Mar 2011 09:31:18 +0000 (UTC) (envelope-from jing.huang.pku@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 780628FC18; Thu, 24 Mar 2011 09:31:18 +0000 (UTC) Received: by qyk27 with SMTP id 27so7658064qyk.13 for ; Thu, 24 Mar 2011 02:31:17 -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:cc :content-type; bh=1Rjpfy168l9xD15+OLFoRng70GyiPM5QdrHqdQuD9YI=; b=usCqc0A+PKF5TEf7ncqCb5XaBiQhyxyNDLTe5dSn2BV0e5HhQgm56QY2p+QM/wxIIe yhDLRegz/9TS92vvPrW+6NGX1dHsqj6AeY2ZUzv7kQRNh/thUF6mjc8Nbz2Jpy8fWN2X h36iOjHwMeHci1rruQjonFBK0lokPctys+ZdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=AS73dEHzHdEzbu02w1HS9tRfFuXODwppS63DdEurvHR/sOftamMsadsbvRtIZGnfkf KBfuOVtSq9lecpXgogvBjG0qOEoUzKSqU2yoapTa0xDVEr0IMaI8MQD3raAFTxR/N8f/ ke54/r35fvKA797OwdWrJCFqcorS988xCaJeI= MIME-Version: 1.0 Received: by 10.224.49.149 with SMTP id v21mr6959649qaf.26.1300957202647; Thu, 24 Mar 2011 02:00:02 -0700 (PDT) Received: by 10.229.100.132 with HTTP; Thu, 24 Mar 2011 02:00:02 -0700 (PDT) Date: Thu, 24 Mar 2011 17:00:02 +0800 Message-ID: From: Jing Huang To: kris@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, hackers@FreeBSD.org Subject: Timecounter Project (GSoc2011) 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, 24 Mar 2011 09:31:19 -0000 Hi Everyone, I am a student of Peking University in China. I am interest in the FreeBSD project of "Timecounter Performance Improvements". I am familiar with Linux kernel and virtualization systems, like KVM and Xen. I have maintained the Linux Server for my College for last whole year. Recently, I learned a lot about KVM and assigned VMs to students who need them. I also have experience of install and config FreeBSD system. In this scenario, I plan to use both tsc and shared memory to calculate precise time in user mode. The shared memory includes system_time, tsc_system_time and factor_tsc-system_time. a) system_time is the current time since the system boots, and it will be updated by time interrupt handling function. b) tsc_system_time is the tsc value when system_time update, and it is used to calculate rough delta. c) factor_tsc-system_time records the correspondence between tsc and time. It is used to calculate precise delta. When the process invokes gettimeofday, our mechanism will calculate time like: system_time+ ( factor_tsc-system_time(instant_rdtsc - tsc_system_time ) ). We see factor_tsc-system_time as a computing method here. I could refer to the relative implementation in KVM or Xen virtual machine. The real problem is that tsc counter is CPU sensitive. Our process will get wrong tsc value when switching to another CPU. I plan to force the FreeBSD kernel to update shared memory when monitoring context switch event. Alternatively, we can build NR_CPUS shared memories, and every CPU has one. Hmm.. how to recognize which CPU we are using in user mode? We also consider the CPU frequency, because tsc counter is related to it. When kernel changes CPU frequency, the shared memory should be update subsequently. Would some one give me some suggestions? Looking forward to your reply. yours sincerely. Jing From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 09:54: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 5B1771065672 for ; Thu, 24 Mar 2011 09:54:06 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id D46BE8FC08 for ; Thu, 24 Mar 2011 09:54:05 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id p2O9rnJe047841; Thu, 24 Mar 2011 10:54:04 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id p2O9rnAi047839; Thu, 24 Mar 2011 10:53:49 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <201103240953.p2O9rnAi047839@lurza.secnetix.de> To: inyaoo@gmail.com (Pan Tsu) Date: Thu, 24 Mar 2011 10:53:49 +0100 (CET) In-Reply-To: <868vw4hpo3.fsf@gmail.com> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Thu, 24 Mar 2011 10:54:04 +0100 (CET) Cc: freebsd-hackers@freebsd.org Subject: Re: Is BOOTWAIT still used? (Was: kernel memory checks on boot vs. boot time) 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, 24 Mar 2011 09:54:06 -0000 Pan Tsu wrote: > Oliver Fromme writes: > > [...] > > To be honest, I don't think that loader takes so much time. > > When you set autoboot_delay="-1" and beastie_disable="YES", > > the time spent in loader is negligible. (I'm assuming that > > you also set BOOTWAIT=0 in make.conf, so boot2 doesn't wait > > for a keypress either. I think the default is to wait 3 > > seconds.) > > Is BOOTWAIT still used? A quick grep in sys/boot shows nothing. You're right, unfortunately. boot0 still has a configurable timeout which is 10 seconds by default. It can be configured via BOOT_BOOT0_TICKS in make conf (default is 182 because the BIOS ticks run at 18.2 Hz). However, the 3 seconds delay is hardcoded in boot2.c: if (!keyhit(3*SECOND)) { load(); I have no idea why it isn't configurable anymore. Is there a reason for that? I'll write a patch unless anybody objects. > Digging history, BOOTWAIT never made its way from sys/i386/boot > to sys/boot/i386 and was removed in r58284 around 11y ago. 11 years ago?!? Time to either update the documentation or -- better yet -- bring the feature back, I would say. Being able to shave 3 seconds off the boot time of a HTPC (among others) is not negligible. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I have stopped reading Stephen King novels. Now I just read C code instead." -- Richard A. O'Keefe From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 10:39:56 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 C4128106564A for ; Thu, 24 Mar 2011 10:39:56 +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 7F7C78FC0C for ; Thu, 24 Mar 2011 10:39:56 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q2hxL-0000ef-9I for freebsd-hackers@freebsd.org; Thu, 24 Mar 2011 11:39:55 +0100 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 ; Thu, 24 Mar 2011 11:39:55 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Mar 2011 11:39:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Thu, 24 Mar 2011 11:39:43 +0100 Lines: 16 Message-ID: References: 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: X-Enigmail-Version: 1.1.2 Subject: Re: Timecounter Project (GSoc2011) 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, 24 Mar 2011 10:39:56 -0000 On 24/03/2011 10:00, Jing Huang wrote: > Hi Everyone, > > I am a student of Peking University in China. I am interest > in the FreeBSD project of "Timecounter Performance Improvements". > > I am familiar with Linux kernel and virtualization systems, > like KVM and Xen. I have maintained the Linux Server for my College > for last whole year. Recently, I learned a lot about KVM and assigned > VMs to students who need them. I also have experience of install and > config FreeBSD system. Offtopic for your specific requests, but if you or these students would like to finish porting KVM to FreeBSD, that would also be a great GSoC project! From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 11:11: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 343631065672 for ; Thu, 24 Mar 2011 11:11:28 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id B8A598FC18 for ; Thu, 24 Mar 2011 11:11:27 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id p2OBBP8R027773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Mar 2011 12:11:25 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.4/8.14.4) with ESMTP id p2OBBI9A091854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Mar 2011 12:11:18 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id p2OBBIJb088229; Thu, 24 Mar 2011 12:11:18 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id p2OBBInW088228; Thu, 24 Mar 2011 12:11:18 +0100 (CET) (envelope-from ticso) Date: Thu, 24 Mar 2011 12:11:18 +0100 From: Bernd Walter To: Zhihao Yuan Message-ID: <20110324111118.GF65750@cicely7.cicely.de> References: <86mxkm1erm.fsf@gmail.com> <86aaglx1ow.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-hackers@freebsd.org, Pan Tsu , Arnaud Lacombe Subject: Re: [GSoC] About the idea: Unicode support in vi X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 11:11:28 -0000 On Wed, Mar 23, 2011 at 08:20:07PM -0500, Zhihao Yuan wrote: > On Wed, Mar 23, 2011 at 7:26 PM, Arnaud Lacombe wrote: > > Hi, > > > > On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan wrote: > >> Among *all* the GNU/Linux distributions I used, they include a vim > >> compiled in tiny mode (ln -s it to vi), which doubles the size of nvi, > >> in their base systems. A vim.tiny contains much more features compared > >> with nvi, but it's not compatible with POSIX vi. > >> > > Let's compare the comparable, I don't really care if PCbsd ship vim as > > its default, but FreeBSD as the base is not only aimed at desktop > > specifically. So you should take into account that I may want to run > > FreeBSD on an adm5120 board with 32MB of RAM, without having a text > > editor consuming too much disk-space/ram. > > > >  - Arnaud > > > > If you really want to use vi in a 32MB mem environment, the ex-vi may > make sense. It consumes 1600KB memory while nvi consumes 2000KB. Note > that the ee editor uses same amount memory as ex-vi. If you really want to save memory - RAM and filesystem - in such a reduced way, then you need something else. /bin/sh without history, reduced termcap, sparsed rc.d and you should also consider static linked crunchgen binaries. This has nothing to do with any other typical installation. Also Linux doesn't do this - there are Linux distributions using bloated featured binaries and there are tiny distributions with low footprint tools such as busybox. > So basically, if no one disagree that we can drop the infinite undo, > multiple buffer, multiple window and some other potential missing > features, we can replace the nvi in the base system with ex-vi. Of course people will disagree. The thread is about adding unicode support this means they want to stay with the features of our current editor. I like the window feature of nvi, but I don't really need it for the system editor, but having Unicode support would be a big win and multiple undo is very valueable for a system editor. Of course this isn't one of the must have features on a memory constrained box, but only because you have a higher pressure. It is true that you can easily add your favourite editor from ports, but it is also true that I often get phone calls to help them with their systems and in this case you want a useable editor, which is just there for sure. If a machine isn't online, e.g. because of a trashed filesystem you can't install a random editor and must live with what's there to fix the situation. And yes - I also often use ed in many crashed situations, because it is easier to fix e.g. an fstab with ed and reboot than to setup your terminal environment. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 11:21: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 87609106566B for ; Thu, 24 Mar 2011 11:21:48 +0000 (UTC) (envelope-from lichray@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 27BE38FC17 for ; Thu, 24 Mar 2011 11:21:47 +0000 (UTC) Received: by qwc9 with SMTP id 9so7295522qwc.13 for ; Thu, 24 Mar 2011 04:21:47 -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=s6uSeky2+TszqWpQR4orzUIxEyHD4fbyoAcoGiSI2D8=; b=ui3PIToxMZhxTEmSZw7eAjrYnK0++5e1OSZ4llIqDbtWYJ2eYIm2UnIXMm4gOatNCa fqHvnt/Mts8ebu5O1rVKDpjaAP7v8IDKJthv2+Awe24KhXI7ShZZUGrqB1ri/y/8kuFu q0i6QIZZ+VP3+/61ooc3TWIHwoSvPy7lxzG34= 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=VIGOSrdwwWdLAKHK4j5Kdyco0Ep7msvhMhcuaZQEM8mCrewnIEnxTgaGrWP0px6dcf qYFce7qdvBsCIWTgGrEZE9JGjMxmFI95XWkG2IxS+XvApRuqmjo1aa6HI6B060tHh32R eBk+GzAjs398fzN1Gf+oDNqeyCBEHWa44QFgs= MIME-Version: 1.0 Received: by 10.224.71.69 with SMTP id g5mr7008859qaj.305.1300965705952; Thu, 24 Mar 2011 04:21:45 -0700 (PDT) Received: by 10.224.20.19 with HTTP; Thu, 24 Mar 2011 04:21:45 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Mar 2011 06:21:45 -0500 Message-ID: From: Zhihao Yuan To: Ivan Voras Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Timecounter Project (GSoc2011) 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, 24 Mar 2011 11:21:48 -0000 On Thu, Mar 24, 2011 at 5:39 AM, Ivan Voras wrote: > On 24/03/2011 10:00, Jing Huang wrote: >> >> Hi Everyone, >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I am a student of Peking University in= China. I am interest >> in the FreeBSD project of "Timecounter Performance Improvements". >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I am familiar with Linux kernel and vi= rtualization systems, >> like KVM and Xen. I have maintained the Linux Server for my College >> for last whole year. Recently, I learned a lot about KVM and assigned >> VMs to students who need them. I also have experience of install and >> config FreeBSD system. > > Offtopic for your specific requests, but if you or these students would l= ike > to finish porting KVM to FreeBSD, that would also be a great GSoC project= ! > Linux KVM was ported to FreeBSD before: http://retis.sssup.it/~fabio/freebsd/lkvm/ But their code are not clean, and the implementation only support FreeBSD 6/7 (due to the changes to the USB stack). Since there may be another big project to clean up their code, FreeBSD dropped that GSoC result. > > _______________________________________________ > 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 Zhihao Yuan The best way to predict the future is to invent it. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 11:49:25 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 56FC1106566B for ; Thu, 24 Mar 2011 11:49:25 +0000 (UTC) (envelope-from lichray@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 0126E8FC15 for ; Thu, 24 Mar 2011 11:49:24 +0000 (UTC) Received: by qwc9 with SMTP id 9so7310615qwc.13 for ; Thu, 24 Mar 2011 04:49:24 -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=X30GkmKTNB1TGUxIFcvNunHFSUNZ6zsEyKsoHk6ljYQ=; b=XyAsap5vvNWMtiVb8RiA73BXKdC3xQk5FvzFzRTyO7Fdt8OivQgYvSTUOwq2QiXbBa kpYLZmSWV6pe/M/b0XGvkE3gR3AObmRPpAxcTkcxkpY6hbfjE2LR8oSmP118OrIQfgSI H+Ie+M8ei57ajRxUsvMiAHFu9VvaOKhyPm/jY= 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=R/nVZldRt6ZIPhfgYGbEFhEpVz1NV0gKU3xzgPVVd+EFyqhBHkpQ2A20V/42N18uX0 FBXfqnlH4XUo1cbIjXKV4BEWNJSOpFgugij8oHuXEEOuxL3nLmQgaAKcHfb+g+MNJe/P p9bOYRWJdS4Eqy8Oq1Z+e+dRjRZ5DLqvfRAA0= MIME-Version: 1.0 Received: by 10.224.138.16 with SMTP id y16mr6947142qat.255.1300967364087; Thu, 24 Mar 2011 04:49:24 -0700 (PDT) Received: by 10.224.20.19 with HTTP; Thu, 24 Mar 2011 04:49:24 -0700 (PDT) In-Reply-To: <20110324111118.GF65750@cicely7.cicely.de> References: <86mxkm1erm.fsf@gmail.com> <86aaglx1ow.fsf@gmail.com> <20110324111118.GF65750@cicely7.cicely.de> Date: Thu, 24 Mar 2011 06:49:24 -0500 Message-ID: From: Zhihao Yuan To: ticso@cicely.de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Bernd Walter , Pan Tsu , Arnaud Lacombe Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 24 Mar 2011 11:49:25 -0000 On Thu, Mar 24, 2011 at 6:11 AM, Bernd Walter wro= te: > On Wed, Mar 23, 2011 at 08:20:07PM -0500, Zhihao Yuan wrote: >> On Wed, Mar 23, 2011 at 7:26 PM, Arnaud Lacombe wro= te: >> > Hi, >> > >> > On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan wrote= : >> >> Among *all* the GNU/Linux distributions I used, they include a vim >> >> compiled in tiny mode (ln -s it to vi), which doubles the size of nvi= , >> >> in their base systems. A vim.tiny contains much more features compare= d >> >> with nvi, but it's not compatible with POSIX vi. >> >> >> > Let's compare the comparable, I don't really care if PCbsd ship vim as >> > its default, but FreeBSD as the base is not only aimed at desktop >> > specifically. So you should take into account that I may want to run >> > FreeBSD on an adm5120 board with 32MB of RAM, without having a text >> > editor consuming too much disk-space/ram. >> > >> > =C2=A0- Arnaud >> > >> >> If you really want to use vi in a 32MB mem environment, the ex-vi may >> make sense. It consumes 1600KB memory while nvi consumes 2000KB. Note >> that the ee editor uses same amount memory as ex-vi. > > If you really want to save memory - RAM and filesystem - in such a reduce= d > way, then you need something else. > /bin/sh without history, reduced termcap, sparsed rc.d and you should > also consider static linked crunchgen binaries. > This has nothing to do with any other typical installation. > Also Linux doesn't do this - there are Linux distributions using bloated > featured binaries and there are tiny distributions with low footprint > tools such as busybox. > >> So basically, if no one disagree that we can drop the infinite undo, >> multiple buffer, multiple window and some other potential missing >> features, we can replace the nvi in the base system with ex-vi. > > Of course people will disagree. > The thread is about adding unicode support this means they want to stay > with the features of our current editor. > I like the window feature of nvi, but I don't =C2=A0really need it for th= e > system editor, but having Unicode support would be a big win and multiple > undo is very valueable for a system editor. > Of course this isn't one of the must have features on a memory constraine= d > box, but only because you have a higher pressure. > It is true that you can easily add your favourite editor from ports, > but it is also true that I often get phone calls to help them with their > systems and in this case you want a useable editor, which is just there > for sure. > If a machine isn't online, e.g. because of a trashed filesystem you can't > install a random editor and must live with what's there to fix the > situation. > And yes - I also often use ed in many crashed situations, because it > is easier to fix e.g. an fstab with ed and reboot than to setup your > terminal environment. > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > Let clean up the my points: 1. ex-vi is POSIX vi compatible, and it supports mbyte encodings. But there are lots of work need to be done if we want to use it to replace the current nvi in the base system; 2. nvi does not use iconv, nvi-m17n only supports limited non-Unicode mbyte encodings, nvi-devel has too many problems. So we don't have a nvi which comes with fully mbyte enconding support; 3. Since other textproc tools, even include ed, support mbyte encodings, we do need a improved nvi; 4. Maybe compared with other kernel related GSoC proposals, this one seems to be easier. But on the other hand, the goal is useful, and the scale of the goal gives it more chance to become really useful. It that reasonable? --=20 Zhihao Yuan The best way to predict the future is to invent it. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 12:28: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 9BB88106566B for ; Thu, 24 Mar 2011 12:28:02 +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 555758FC18 for ; Thu, 24 Mar 2011 12:28:02 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q2jdt-00028B-Q1 for freebsd-hackers@freebsd.org; Thu, 24 Mar 2011 13:27:57 +0100 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 ; Thu, 24 Mar 2011 13:27:57 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Mar 2011 13:27:57 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Thu, 24 Mar 2011 13:27:44 +0100 Lines: 31 Message-ID: References: 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: X-Enigmail-Version: 1.1.2 Subject: Re: Timecounter Project (GSoc2011) 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, 24 Mar 2011 12:28:02 -0000 On 24/03/2011 12:21, Zhihao Yuan wrote: > On Thu, Mar 24, 2011 at 5:39 AM, Ivan Voras wrote: >> On 24/03/2011 10:00, Jing Huang wrote: >>> >>> Hi Everyone, >>> >>> I am a student of Peking University in China. I am interest >>> in the FreeBSD project of "Timecounter Performance Improvements". >>> >>> I am familiar with Linux kernel and virtualization systems, >>> like KVM and Xen. I have maintained the Linux Server for my College >>> for last whole year. Recently, I learned a lot about KVM and assigned >>> VMs to students who need them. I also have experience of install and >>> config FreeBSD system. >> >> Offtopic for your specific requests, but if you or these students would like >> to finish porting KVM to FreeBSD, that would also be a great GSoC project! >> > > Linux KVM was ported to FreeBSD before: > http://retis.sssup.it/~fabio/freebsd/lkvm/ > > But their code are not clean, and the implementation only support > FreeBSD 6/7 (due to the changes to the USB stack). Since there may be > another big project to clean up their code, FreeBSD dropped that GSoC > result. Yes, that is why I suggested finishing the port :) There is enough work in finishing the KVM port that it can be a new GSoC project. (also, finishing FUSE...) From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 13:11: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 56761106566B; Thu, 24 Mar 2011 13:11:39 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id E45168FC15; Thu, 24 Mar 2011 13:11:38 +0000 (UTC) Received: by qyk35 with SMTP id 35so5378646qyk.13 for ; Thu, 24 Mar 2011 06:11: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=AhYsMdg6Y/j0sKQxmTLtyGFq2ukB2uFf0HReSxgMr68=; b=VCdWHTy3Pp1ho8ZB4Lh9TsR7vBGGYO/oKyiYGgGmICzjK1SuYJ6EHWNcX0Mc7NB20h 1iKy3T9hRExGsc8x35IAaEew0C+fTVSPCQt3wZUE3RAmITl3m/l7OqRue/Rp43CR3FZS U0u6eKjavOxvgMcZ1I8ur35DLg9A46Bp6GAE8= 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=DfP6+E2/IBLYcecoExtVEN3/5iwXUsqU9QKH40hnyVmf6wb9C8C0DDmjdCb7HZciJ8 E4dE8tigeZpTD0ijH9G8jA3v0XrrGgYgxqOmh8dwPJjC94IkSQu0b/odwiq4QZ2VTLCQ u+iGrIlHiXsZFH5frifEYhtU/MSpwyrKv+g94= MIME-Version: 1.0 Received: by 10.224.71.69 with SMTP id g5mr7138574qaj.305.1300972297929; Thu, 24 Mar 2011 06:11:37 -0700 (PDT) Received: by 10.224.20.19 with HTTP; Thu, 24 Mar 2011 06:11:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Mar 2011 08:11:37 -0500 Message-ID: From: Zhihao Yuan To: Ivan Voras Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Timecounter Project (GSoc2011) 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, 24 Mar 2011 13:11:39 -0000 On Thu, Mar 24, 2011 at 7:27 AM, Ivan Voras wrote: > On 24/03/2011 12:21, Zhihao Yuan wrote: >> >> On Thu, Mar 24, 2011 at 5:39 AM, Ivan Voras =C2=A0wr= ote: >>> >>> On 24/03/2011 10:00, Jing Huang wrote: >>>> >>>> Hi Everyone, >>>> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I am a student of Peking University = in China. I am interest >>>> in the FreeBSD project of "Timecounter Performance Improvements". >>>> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I am familiar with Linux kernel and = virtualization systems, >>>> like KVM and Xen. I have maintained the Linux Server for my College >>>> for last whole year. Recently, I learned a lot about KVM and assigned >>>> VMs to students who need them. I also have experience of install and >>>> config FreeBSD system. >>> >>> Offtopic for your specific requests, but if you or these students would >>> like >>> to finish porting KVM to FreeBSD, that would also be a great GSoC >>> project! >>> >> >> Linux KVM was ported to FreeBSD before: >> http://retis.sssup.it/~fabio/freebsd/lkvm/ >> >> But their code are not clean, and the implementation only support >> FreeBSD 6/7 (due to the changes to the USB stack). Since there may be >> another big project to clean up their code, FreeBSD dropped that GSoC >> result. > > Yes, that is why I suggested finishing the port :) There is enough work i= n > finishing the KVM port that it can be a new GSoC project. > > (also, finishing FUSE...) > > _______________________________________________ > 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= " > Well, it depends on the decision of core team. AFAIC, to make the KVM to be committed is very hard, especially for a GSoC project. But... I think the thread is not talking about the KVM itself... FUSE works. It's in the ports, as well as many file systems. --=20 Zhihao Yuan The best way to predict the future is to invent it. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 13: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 6FB78106566C for ; Thu, 24 Mar 2011 13:17:12 +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 272778FC15 for ; Thu, 24 Mar 2011 13:17:11 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q2kPV-0003Yc-V6 for freebsd-hackers@freebsd.org; Thu, 24 Mar 2011 14:17:09 +0100 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 ; Thu, 24 Mar 2011 14:17:09 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Mar 2011 14:17:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Thu, 24 Mar 2011 14:16:57 +0100 Lines: 13 Message-ID: References: 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: X-Enigmail-Version: 1.1.2 Subject: Re: Timecounter Project (GSoc2011) 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, 24 Mar 2011 13:17:12 -0000 On 24/03/2011 14:11, Zhihao Yuan wrote: > Well, it depends on the decision of core team. AFAIC, to make the KVM > to be committed is very hard, especially for a GSoC project. Ah, please read what I'm saying: finish, not commit. > But... I think the thread is not talking about the KVM itself... > > FUSE works. It's in the ports, as well as many file systems. No, it doesn't work. It crashes. Google will show you many bug reports, including mine. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 13:34: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 A09DA1065670; Thu, 24 Mar 2011 13:34:36 +0000 (UTC) (envelope-from jing.huang.pku@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 27B368FC08; Thu, 24 Mar 2011 13:34:35 +0000 (UTC) Received: by qyk35 with SMTP id 35so5396131qyk.13 for ; Thu, 24 Mar 2011 06:34:35 -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:cc :content-type; bh=8wjV/LZ1Xro1RtFpKkqsqx6MTX+NvjbioO1aov7sLDA=; b=WGjmGpk134an/sq+y/CTuehTLLJeSY0AjJRsXlEBu+pYpVL5M2IJndvrsYEGn6+rOi Cvd5OM97IT/IPeGEyV1U0jQYC6MkC0iJZvwYOL6sef7ujakRwYp1ZYgMrDIU6bw0PTnN wWHqfGtiEtKbwdPRscAKNClGNPwDCV6SE2mkw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=NcviuDg0AkZL7mYP2IOnZ3bLhBOYMILM0qjljK0BWSbnpR7sDPlgexvC4/AjYtYUUW wrAqUHwS7H610YQBc6k5M867+OJ1IL0T1wdL1cIsvE39CbCIcTwSRUYsiydy/YYX3G6b Y451ahhEa3bEbEJQkbxq8x7AtpBP8/bNlY2bE= MIME-Version: 1.0 Received: by 10.229.141.129 with SMTP id m1mr7051438qcu.52.1300973675221; Thu, 24 Mar 2011 06:34:35 -0700 (PDT) Received: by 10.229.100.132 with HTTP; Thu, 24 Mar 2011 06:34:35 -0700 (PDT) Date: Thu, 24 Mar 2011 21:34:35 +0800 Message-ID: From: Jing Huang To: ivoras@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: [GSoc] Timeconter Performance Improvements 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, 24 Mar 2011 13:34:36 -0000 Hi, Thanks for your replay. That is just my self-introduction:) I want to borrow the shared memory idea from KVM, I am not want to port a whole KVM:) But for this project, there are some basic problems. As I know, tsc counter is CPU specific. If the process running on a multi-core platform, we must consider switching problem. The one way, we can let the kernel to take of this. When switching to another CPU, the kernel will reset the shared memory according to the new CPU. The second way, we can use CPUID instruction to get the info of current CPU, which can be executed in user mode ether. At the same time, the kernel maintains shared memory for each CPU. When invoke gettimeofday, the function will calculate precise time with current CPU's shared memory. I don't know which is better? Could I need to deal other problems? Jing. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 15:46: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 3D2FB106566C for ; Thu, 24 Mar 2011 15:46:30 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id C9BC38FC08 for ; Thu, 24 Mar 2011 15:46:29 +0000 (UTC) Received: by eyg7 with SMTP id 7so68760eyg.13 for ; Thu, 24 Mar 2011 08:46:28 -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=j7MdYAJeKGZWxznmqavKVdn7fvwMt/kESHRpwBWLy00=; b=MvzL3S/sYeQkPPnZGFFDGdi8vxtm2whJC7oCSBbYCWA8+vT6EnrDsL4pJgslpnTQxw aTNc6iNe7ZSs4rcZwbPVCWXexOjLgjBIYg8195HpY0qDTCsPZwYQ449w50s6lDXcY/n+ T4dHFZHANq8nNQzqbRX2VJ9LGwEjpz7NSv/Ac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=K5DIIBSrm8qOBJWjV3fuPQXrvtrFVntzSsdZnIcJ9znglnmv2a1JRX1bDCHwqv18D4 v+A07aYjxZz2aeziKRKCGnz9T5/vS3dpUGTTfAq4PzW6qc6WpEbIER1o1cvbKzp3WdaC YFAUyQOweJ7RqLinvPRrLNcLEBmAoSD+bsVUI= MIME-Version: 1.0 Received: by 10.213.26.210 with SMTP id f18mr434856ebc.19.1300981588335; Thu, 24 Mar 2011 08:46:28 -0700 (PDT) Received: by 10.213.19.205 with HTTP; Thu, 24 Mar 2011 08:46:28 -0700 (PDT) Date: Thu, 24 Mar 2011 11:46:28 -0400 Message-ID: From: Ryan Stone To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: kgdb patches for newer versions of gdb 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, 24 Mar 2011 15:46:30 -0000 At work we cross-compile several kld modules. They just upgraded to gcc 4.5, but gdb 6.X is not compatible with the debug symbols produced by gcc 4.5. Has anybody ever tried merging kgdb into a newer gdb version? Anybody have patches that they can share? From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 17:45: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 09EA0106566B for ; Thu, 24 Mar 2011 17:45:19 +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 C47578FC16 for ; Thu, 24 Mar 2011 17:45:17 +0000 (UTC) Received: by thought.org (Postfix, from userid 1001) id 889A0E8040D; Thu, 24 Mar 2011 10:45:15 -0700 (PDT) Date: Thu, 24 Mar 2011 10:45:15 -0700 From: Gary Kline To: Zhihao Yuan Message-ID: <20110324174515.GA15209@thought.org> References: <86mxkm1erm.fsf@gmail.com> <86aaglx1ow.fsf@gmail.com> <20110324111118.GF65750@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Arnaud Lacombe , freebsd-hackers@freebsd.org, Bernd Walter , ticso@cicely.de, Pan Tsu Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 24 Mar 2011 17:45:19 -0000 On Thu, Mar 24, 2011 at 06:49:24AM -0500, Zhihao Yuan wrote: > On Thu, Mar 24, 2011 at 6:11 AM, Bernd Walter wrote: > > > > Let clean up the my points: > 1. ex-vi is POSIX vi compatible, and it supports mbyte encodings. But > there are lots of work need to be done if we want to use it to replace > the current nvi in the base system; > 2. nvi does not use iconv, nvi-m17n only supports limited non-Unicode > mbyte encodings, nvi-devel has too many problems. So we don't have a > nvi which comes with fully mbyte enconding support; > 3. Since other textproc tools, even include ed, support mbyte > encodings, we do need a improved nvi; > 4. Maybe compared with other kernel related GSoC proposals, this one > seems to be easier. But on the other hand, the goal is useful, and the > scale of the goal gives it more chance to become really useful. > > It that reasonable? > > -- > Zhihao Yuan > The best way to predict the future is to invent it. it makes sense to upgrade nvi rather that ex-vi ... for reasons prev'ly mentioned. talking about space/memory and even processor speed seems like a non-issue. i would like to be able to be editing a file with vim [[ for WHATEVER reason ]] and pick up or resume editing the same file with nvi. Of course there are dozens of alley-ways and twists and turns we all can get into is arguing this-and-that about the fine-grained details. It boils down to an issue of usefulness-- as i see it. be nice to have a "feature for feature, bug for bug" clone of vi that nvi used to claim to be. again: have nvi and vim be interchangable. oh: and then give the new nvi to the linux guys and let then deal with any port or build issues. > -- 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 Thu Mar 24 19:56:16 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 D3CDC1065673 for ; Thu, 24 Mar 2011 19:56:16 +0000 (UTC) (envelope-from dudinskyj@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5CF548FC14 for ; Thu, 24 Mar 2011 19:56:16 +0000 (UTC) Received: by fxm11 with SMTP id 11so477139fxm.13 for ; Thu, 24 Mar 2011 12:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=HfHwIb+8qhQK48fCfH0LvfIAjPGz7urIjuwwCNRvBsE=; b=timClC3XF5ItnbRdi81NaOWHsDMsU2z4s3MRmboOISO8DmThN/oLPramceX1ZGaxqV oc+efAdsRXEvyMHGeMGYwpytyOi0mbtlT82Foqt47uq2iRGyPlrAoxUmYPjm6ucQ3BH+ 5VHi48l6X3tj483lqqShVEQixscrS9Vf0bHEc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; b=XfTisdj9b2vZLBP/+bGc5CkMWfF7yL6QquYz5VPuOk3UaxOGcXFffdILaAIbxwy90e u3Z9AG6pXaHcqR/3MfpaZD4tRho41zv4THRLgJlQZEh38PgkWRXE2k3+ZFKK9QKC6s3M t2cbRTkyCv/i+FpdKDiWhwC5MCelhAWx/TMsI= Received: by 10.223.1.136 with SMTP id 8mr707871faf.0.1300995025583; Thu, 24 Mar 2011 12:30:25 -0700 (PDT) Received: from LocalHost ([92.249.73.111]) by mx.google.com with ESMTPS id o17sm112575fal.1.2011.03.24.12.30.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Mar 2011 12:30:24 -0700 (PDT) From: Dudinskyi Olexandr To: Date: Thu, 24 Mar 2011 21:30:20 +0200 Message-ID: <000001cbea59$eb1c4b00$c154e100$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvqVtIgqH5sNbj/TV6XMpCrhgA6Kg== Content-Language: uk X-Mailman-Approved-At: Thu, 24 Mar 2011 20:26:37 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: GSoC 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, 24 Mar 2011 19:56:16 -0000 Hello. My name is Dudinskyi Oleksandr. I am a student of National aviation = university, Ukraine. I want to participate in GSoC 2011 with your = organization. My project: Disk device error counters, iostat =E2=80=93e. I thing this project is very necessary in the FreeBSD system. Now I = make a plan to develop this project. What you can say about the idea of =E2=80=8B=E2=80=8Bmy project? And = what about the favor of this project? My mentor: Andriy Gapon. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 22:08: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 AABB4106564A for ; Thu, 24 Mar 2011 22:08:04 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 3649F8FC0C for ; Thu, 24 Mar 2011 22:08:03 +0000 (UTC) Received: from park.js.berklix.net (p5B22F965.dip.t-dialin.net [91.34.249.101]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id p2OM81vA074187; Thu, 24 Mar 2011 22:08:02 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id p2OM7pf5087394; Thu, 24 Mar 2011 23:07:51 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id p2OM7f6J009261; Thu, 24 Mar 2011 23:07:46 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201103242207.p2OM7f6J009261@fire.js.berklix.net> To: freebsd-hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Thu, 24 Mar 2011 01:16:32 EST." Date: Thu, 24 Mar 2011 23:07:41 +0100 Sender: jhs@berklix.com Cc: Zhihao Yuan Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 24 Mar 2011 22:08:04 -0000 Zhihao Yuan wrote: > ed seems works, but it's not either vi or ex. > I'm not typically like ee... I sill wondering why we kept it in base > system. It does not work when termcap is not correct, so I still need > to use ed in such a case. Same thing happens to ex-vi. History: ee was added long ago by emacs afficionado jkh@ for the sys installer eg /etc/inetd.conf Small vi clones in source were available then too, on DOS 3.2 & Minix, One was called Stevie, I can't remember the others. Replacing ee with a mini vi clone would be a return to Unix. One would need to co-ordinate on Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, Not HTML, Not base 64. Reply below text sections not at top, to avoid breaking cumulative context. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 22:14: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 939EE106564A for ; Thu, 24 Mar 2011 22:14:46 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 426BB8FC1C for ; Thu, 24 Mar 2011 22:14:45 +0000 (UTC) Received: by qyk35 with SMTP id 35so5807155qyk.13 for ; Thu, 24 Mar 2011 15:14:45 -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=rrG9KVhLVzrwDolALjnX2PPkfgX5OkdhUGCINKc8reg=; b=FlpXbayJclZcgikLqo90Jwxh9a1E/XpAC6IK4eI8kiXgU+N9itSN2iRGfiBT646Jy3 maqtqYDIm6+fqEXy9QjFHCQLEj4orjt7u05LkDp1EKyfPESFWbgg5Taf6BJ3hKBHQFR0 u9K1Amfo8A2w2MQT3KS0A4dR0FnQDW9rtNRWg= 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=vr9RUbHbjYPl8/8YDnEy5daYP+a9DLfxtNB9cGPM045ge4BnK2kAmwf4qYN8pyM76/ NiMcj2ni8I7ZUkYurY4ohXzR1CHNT2boaxqJo95jsbrDbgN9Ns4DhcM2L5A9IoUahHsd 24oSmnft3yR6wC2QAHb+7nbIKH6jkkhRV7BLc= MIME-Version: 1.0 Received: by 10.224.71.69 with SMTP id g5mr17407qaj.305.1301004885245; Thu, 24 Mar 2011 15:14:45 -0700 (PDT) Received: by 10.224.20.19 with HTTP; Thu, 24 Mar 2011 15:14:45 -0700 (PDT) In-Reply-To: <201103242207.p2OM7f6J009261@fire.js.berklix.net> References: <201103242207.p2OM7f6J009261@fire.js.berklix.net> Date: Thu, 24 Mar 2011 17:14:45 -0500 Message-ID: From: Zhihao Yuan To: "Julian H. Stacey" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 24 Mar 2011 22:14:46 -0000 On Thu, Mar 24, 2011 at 5:07 PM, Julian H. Stacey wrote: > Zhihao Yuan wrote: > >> ed seems works, but it's not either vi or ex. >> I'm not typically like ee... I sill wondering why we kept it in base >> system. It does not work when termcap is not correct, so I still need >> to use ed in such a case. Same thing happens to ex-vi. > > History: > =C2=A0ee was added long ago by emacs afficionado jkh@ for the > =C2=A0sys installer eg /etc/inetd.conf > =C2=A0Small vi clones in source were available then too, on DOS 3.2 & Min= ix, > =C2=A0One was called Stevie, I can't remember the others. > > Replacing ee with a mini vi clone would be a return to Unix. > One would need to co-ordinate on O-O-Ok... Let emacs guys do emacs stuff. I need to go looking for a possible mentor on nvi... > > Cheers, > Julian > -- > Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix= .com > =C2=A0Mail plain text; =C2=A0Not quoted-printable, Not HTML, Not base 64. > =C2=A0Reply below text sections not at top, to avoid breaking cumulative = context. > --=20 Zhihao Yuan The best way to predict the future is to invent it. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 22:18: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 8691C106566B for ; Thu, 24 Mar 2011 22:18:04 +0000 (UTC) (envelope-from johans@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 16B548FC22 for ; Thu, 24 Mar 2011 22:18:04 +0000 (UTC) Received: by mx1.stack.nl (Postfix, from userid 65534) id 5C9C13593D4; Thu, 24 Mar 2011 23:18:02 +0100 (CET) X-Spam-DCC: STAT_FI_X86_64_VIRTUAL: scanner01.stack.nl 1245; Body=3 Fuz1=3 Fuz2=3 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on scanner01.stack.nl X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_OPENWHOIS,NO_RELAYS autolearn=no version=3.2.5 X-Spam-Relay-Country: _RELAYCOUNTRY_ Received: from mud.stack.nl (mud.stack.nl [IPv6:2001:610:1108:5011::70]) by mx1.stack.nl (Postfix) with ESMTP id D88893593C7; Thu, 24 Mar 2011 23:17:57 +0100 (CET) Received: by mud.stack.nl (Postfix, from userid 801) id CA86F11482; Thu, 24 Mar 2011 23:17:57 +0100 (CET) Date: Thu, 24 Mar 2011 23:17:57 +0100 From: Johan van Selst To: Zhihao Yuan Message-ID: <20110324221757.GA20441@mud.stack.nl> References: <86mxkm1erm.fsf@gmail.com> <86aaglx1ow.fsf@gmail.com> <20110324111118.GF65750@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Arnaud Lacombe , freebsd-hackers@freebsd.org, Bernd Walter , ticso@cicely.de, Pan Tsu Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 24 Mar 2011 22:18:04 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Zhihao Yuan wrote: > 2. nvi does not use iconv, nvi-m17n only supports limited non-Unicode > mbyte encodings, nvi-devel has too many problems. So we don't have a > nvi which comes with fully mbyte enconding support; Could you please eleborate on the nvi-devel problems? I'm the current maintainer of this port, and as far as I know it's fully functional. nvi-devel does have proper UTF-8 support via libiconv. It is based on the nvi version we currently have in base and much of the code base is still identical. Johan --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iF4EAREIAAYFAk2LwxQACgkQAEpMHW8nCPRP2gEA2BqQ7zNZ9dsXS7IKOym3NE5I SQnnX6ZnEVOUiHFkwW8A+QHdOcrRaDvFIYCizhRYJ3hME9Q8Ln2pcszhjJ/aanxU =Bi4U -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 00:21:15 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 9042A1065672; Fri, 25 Mar 2011 00:21:15 +0000 (UTC) Date: Fri, 25 Mar 2011 00:21:15 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20110325002115.GA323@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Switching to [KMGTPE]i prefixes? 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, 25 Mar 2011 00:21:15 -0000 hi there, i hacked up humanized_number(3) a bit in order to produce the following df(1) output: otaku% df -hi; df -Hi Filesystem Size Used Avail Capacity iused ifree %iused Mounted on /dev/ada0p3 217Gi 430Mi 200Gi 0% 6.2k 29M 0% / devfs 1.0Ki 1.0Ki 0B 100% 0 0 100% /dev /dev/ufs/varfs 2Gi 286Mi 1.5Gi 16% 27k 254k 10% /var /dev/ufs/usrfs 890Gi 758Gi 60Gi 93% 1.0M 119M 1% /usr linprocfs 4.0Ki 4.0Ki 0B 100% 1 0 100% /usr/compat/linux/proc linsysfs 4.0Ki 4.0Ki 0B 100% 1 0 100% /usr/compat/linux/sys devfs 1.0Ki 1.0Ki 0B 100% 0 0 100% /usr/compat/linux/dev linprocfs 4.0Ki 4.0Ki 0B 100% 1 0 100% /usr/local/gentoo-stage3/proc linsysfs 4.0Ki 4.0Ki 0B 100% 1 0 100% /usr/local/gentoo-stage3/sys devfs 1.0Ki 1.0Ki 0B 100% 0 0 100% /usr/local/gentoo-stage3/dev tmpfs 2.0Gi 1.3Mi 2Gi 0% 21 524k 0% /tmp /dev/cd0 4.2Gi 4.2Gi 0B 100% 0 0 100% /media/dvd Filesystem Size Used Avail Capacity iused ifree %iused Mounted on /dev/ada0p3 233G 451M 214G 0% 6.2k 29M 0% / devfs 1.0k 1.0k 0B 100% 0 0 100% /dev /dev/ufs/varfs 2.1G 300M 1.6G 16% 27k 254k 10% /var /dev/ufs/usrfs 956G 814G 65G 93% 1.0M 119M 1% /usr linprocfs 4.1k 4.1k 0B 100% 1 0 100% /usr/compat/linux/proc linsysfs 4.1k 4.1k 0B 100% 1 0 100% /usr/compat/linux/sys devfs 1.0k 1.0k 0B 100% 0 0 100% /usr/compat/linux/dev linprocfs 4.1k 4.1k 0B 100% 1 0 100% /usr/local/gentoo-stage3/proc linsysfs 4.1k 4.1k 0B 100% 1 0 100% /usr/local/gentoo-stage3/sys devfs 1.0k 1.0k 0B 100% 0 0 100% /usr/local/gentoo-stage3/dev tmpfs 2.1G 1.3M 2.1G 0% 21 524k 0% /tmp /dev/cd0 4.5G 4.5G 0B 100% 0 0 100% /media/dvd any thoughts whether this is something freebsd might benefit from or has it been decided that the current notion of prefixes mustn't be changed. cheers. alex -- a13x From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 01:35: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 ECF2E106564A for ; Fri, 25 Mar 2011 01:35:50 +0000 (UTC) (envelope-from lichray@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 A101C8FC12 for ; Fri, 25 Mar 2011 01:35:50 +0000 (UTC) Received: by qyk27 with SMTP id 27so450633qyk.13 for ; Thu, 24 Mar 2011 18:35: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=lvVA0XiS7OfFwxsNeuijY0zidOFSGvB6cLC2kmIvnIo=; b=RgVCaFIhBCCWRfd0HxQOCROzfm/RhY010DBCRP2ORPp2kCIfnUFfbyIUJXWKZqlDf4 PHVm8DLnKdKDt3j/nxLQVM0BFsIAtwilYla/ggKTig9go7UeNEPeg9Tiet+Umhj23lep 7NWrcR3NIeDqIXiK/nXPCdC9a2qled3133yxM= 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=TW/almf9K7KOXhJtBEX2PAiEqTFUmu1LlHn1C+7QHf/76dsJNeHqqMXUjBtCQ7SCsO RueUyNTRtURmostgJ0/TV6uSmTmMNrx6KQM6p8noCIDz8gFVKH6V+VmG1BpVs4d+Hk1p cJ6Fp34HAegdDixNIkSIkuLVkS9XT1WcNSCO0= MIME-Version: 1.0 Received: by 10.224.200.196 with SMTP id ex4mr140060qab.5.1301016949579; Thu, 24 Mar 2011 18:35:49 -0700 (PDT) Received: by 10.224.20.19 with HTTP; Thu, 24 Mar 2011 18:35:49 -0700 (PDT) In-Reply-To: <20110324221757.GA20441@mud.stack.nl> References: <86mxkm1erm.fsf@gmail.com> <86aaglx1ow.fsf@gmail.com> <20110324111118.GF65750@cicely7.cicely.de> <20110324221757.GA20441@mud.stack.nl> Date: Thu, 24 Mar 2011 20:35:49 -0500 Message-ID: From: Zhihao Yuan To: Johan van Selst Content-Type: text/plain; charset=UTF-8 Cc: Arnaud Lacombe , freebsd-hackers@freebsd.org, Bernd Walter , ticso@cicely.de, Pan Tsu Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 25 Mar 2011 01:35:51 -0000 On Thu, Mar 24, 2011 at 5:17 PM, Johan van Selst wrote: > Zhihao Yuan wrote: >> 2. nvi does not use iconv, nvi-m17n only supports limited non-Unicode >> mbyte encodings, nvi-devel has too many problems. So we don't have a >> nvi which comes with fully mbyte enconding support; > > Could you please eleborate on the nvi-devel problems? I'm the current > maintainer of this port, and as far as I know it's fully functional. > nvi-devel does have proper UTF-8 support via libiconv. It is based on > the nvi version we currently have in base and much of the code base is > still identical. > > > Johan > 1. It does not support non-Unicode encodings. Actually, these encodings are mainstream in multi-byte encodings world. A proper iconv-awared implementation should be able to handle all of the encodings in `iconv -l`; 2. It depends on DB3/4. We won't accept DB3/4 in base system and we won't accept nvi-devel. 3. It's not 100% compatible with nvi 1.79. -- Zhihao Yuan The best way to predict the future is to invent it. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 01:55:09 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id F2A4B1065672; Fri, 25 Mar 2011 01:55:08 +0000 (UTC) Date: Fri, 25 Mar 2011 01:55:08 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20110325015508.GA14565@freebsd.org> References: <20110325002115.GA323@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <20110325002115.GA323@freebsd.org> Subject: Re: Switching to [KMGTPE]i prefixes? 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, 25 Mar 2011 01:55:09 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline here's a rough draft. it introduces a new flag called HN_IEC_PREFIXES so nothing should get broken and each utility can decide for itself whether to use the SI binary, SI decimal or the IEC certified prefixes. another possibility would be to #ifdef the extra code. this would offer the possibility to turn the new code on or off without having to adjust any utilities. of course this behaviour should be disabled by default in order to maintain compatibility. cheers. alex -- a13x --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="IEC_80000_13.diff" diff --git a/lib/libutil/humanize_number.c b/lib/libutil/humanize_number.c index 75bcb46..b6677c3 100644 --- a/lib/libutil/humanize_number.c +++ b/lib/libutil/humanize_number.c @@ -47,7 +47,7 @@ humanize_number(char *buf, size_t len, int64_t quotient, const char *suffix, int scale, int flags) { const char *prefixes, *sep; - int i, r, remainder, maxscale, s1, s2, sign; + int i, r, remainder, maxscale, s1, s2, shift, sign; int64_t divisor, max; size_t baselen; @@ -57,26 +57,45 @@ humanize_number(char *buf, size_t len, int64_t quotient, remainder = 0; + /* + * With HN_DIVISOR_1000 defined in flags, SI prefixes for decimal + * multiplies are being used. Without this flag, SI prefixes for + * binary multiplies are being used. If however HN_IEC_PREFIXES is + * defined in flags, the prefixes recommended by the International + * Electrotechnical Commission (IEC) for binary multiplies in + * IEC 80000-3 (superseeding IEC 60027-2) (i.e. Ki, Mi, Gi...) are + * being used. + * + * Please note that HN_DIVISOR_1000 and HN_IEC_PREFIXES are mutually + * exclusive. The default behavior is to use SI prefixes for binary + * multiplies. + */ + if ((flags & HN_DIVISOR_1000) && (flags & HN_IEC_PREFIXES)) + return (-1); if (flags & HN_DIVISOR_1000) { - /* SI for decimal multiplies */ divisor = 1000; + shift = 1; if (flags & HN_B) prefixes = "B\0k\0M\0G\0T\0P\0E"; else prefixes = "\0\0k\0M\0G\0T\0P\0E"; + } else if (flags & HN_IEC_PREFIXES) { + divisor = 1024; + shift = 2; + if (flags & HN_B) + prefixes = "B\0\0\0Ki\0\0Mi\0\0Gi\0\0Ti\0\0Pi\0\0Ei"; + else + prefixes = "\0\0\0\0Ki\0\0Mi\0\0Gi\0\0Ti\0\0Pi\0\0Ei"; } else { - /* - * binary multiplies - * XXX IEC 60027-2 recommends Ki, Mi, Gi... - */ divisor = 1024; + shift = 1; if (flags & HN_B) prefixes = "B\0K\0M\0G\0T\0P\0E"; else prefixes = "\0\0K\0M\0G\0T\0P\0E"; } -#define SCALE2PREFIX(scale) (&prefixes[(scale) << 1]) +#define SCALE2PREFIX(scale) (&prefixes[(scale) << shift]) maxscale = 7; if (scale >= maxscale && @@ -102,6 +121,10 @@ humanize_number(char *buf, size_t len, int64_t quotient, sep = " "; baselen++; } + if (flags & HN_IEC_PREFIXES) { + baselen ++; + len ++; + } baselen += strlen(suffix); /* Check if enough room for `x y' + suffix + `\0' */ diff --git a/lib/libutil/libutil.h b/lib/libutil/libutil.h index 66104e9..295a8d3 100644 --- a/lib/libutil/libutil.h +++ b/lib/libutil/libutil.h @@ -220,6 +220,7 @@ __END_DECLS #define HN_NOSPACE 0x02 #define HN_B 0x04 #define HN_DIVISOR_1000 0x08 +#define HN_IEC_PREFIXES 0x0f #define HN_GETSCALE 0x10 #define HN_AUTOSCALE 0x20 --YiEDa0DAkWCtVeE4-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 02:46:58 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 2AD1B1065670; Fri, 25 Mar 2011 02:46:58 +0000 (UTC) Date: Fri, 25 Mar 2011 02:46:58 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20110325024658.GA19544@freebsd.org> References: <20110325002115.GA323@freebsd.org> <20110325015508.GA14565@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <20110325015508.GA14565@freebsd.org> Subject: Re: Switching to [KMGTPE]i prefixes? 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, 25 Mar 2011 02:46:58 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline here is a revised patch. it also includes the necessary changes to the humanize_number(3) man page. cheers. alex -- a13x --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="IEC_80000_13.diff" diff --git a/lib/libutil/humanize_number.3 b/lib/libutil/humanize_number.3 index 82925ba..841da3f 100644 --- a/lib/libutil/humanize_number.3 +++ b/lib/libutil/humanize_number.3 @@ -68,17 +68,22 @@ then divide by 1024 until it will. In this case, prefix .Fa suffix -with the appropriate SI designator. +with the appropriate SI (or IEC) designator. The .Fn humanize_number function -follows the traditional computer science conventions rather than the proposed -SI power of two convention. +follows the traditional computer science conventions by default rather than the proposed +IEC power of two convention or the power of ten notion. +This behaviour however can be altered by the +.Dv HN_DIVISOR_1000 +and +.Dv HN_IEC_PREFIXES +flags. .Pp -The prefixes are: +The default prefixes are: .Bl -column "Prefix" "Description" "1000000000000000000" -offset indent .It Sy "Prefix" Ta Sy "Description" Ta Sy "Multiplier" Ta Sy "Multiplier 1000x" -.It Li k Ta No kilo Ta 1024 Ta 1000 +.It Li * Ta No kilo Ta 1024 Ta 1000 .It Li M Ta No mega Ta 1048576 Ta 1000000 .It Li G Ta No giga Ta 1073741824 Ta 1000000000 .It Li T Ta No tera Ta 1099511627776 Ta 1000000000000 @@ -86,6 +91,19 @@ The prefixes are: .It Li E Ta No exa Ta 1152921504606846976 Ta 1000000000000000000 .El .Pp +* An uppercase K indicates a power of two, a lowercase k a power of ten. +.Pp +The IEC power of two (IEC 80000-13) prefixes are: +.Bl -column "Prefix" "Description" "1000000000000000000" -offset indent +.It Sy "Prefix" Ta Sy "Description" Ta Sy "Multiplier" +.It Li Ki Ta No kibi Ta 1024 +.It Li Mi Ta No mebi Ta 1048576 +.It Li Gi Ta No gibi Ta 1073741824 +.It Li Ti Ta No tebi Ta 1099511627776 +.It Li Pi Ta No pebi Ta 1125899906842624 +.It Li Ei Ta No exbi Ta 1152921504606846976 +.El +.Pp The .Fa len argument must be at least 4 plus the length of @@ -127,6 +145,11 @@ Use Divide .Fa number with 1000 instead of 1024. +.It Dv HN_IEC_PREFIXES +Use the IEC notion of prefixes (Ki, Mi, Gi...). +This flag has no effect when +.Dv HN_DIVISOR_1000 +is also specified. .El .Sh RETURN VALUES The @@ -148,3 +171,7 @@ function first appeared in .Nx 2.0 and then in .Fx 5.3 . +The +.Dv HN_IEC_PREFIXES +flag was introduced in +.Fx 9.0 . diff --git a/lib/libutil/humanize_number.c b/lib/libutil/humanize_number.c index 75bcb46..efa06cb 100644 --- a/lib/libutil/humanize_number.c +++ b/lib/libutil/humanize_number.c @@ -47,7 +47,7 @@ humanize_number(char *buf, size_t len, int64_t quotient, const char *suffix, int scale, int flags) { const char *prefixes, *sep; - int i, r, remainder, maxscale, s1, s2, sign; + int i, r, remainder, maxscale, s1, s2, shift, sign; int64_t divisor, max; size_t baselen; @@ -57,26 +57,41 @@ humanize_number(char *buf, size_t len, int64_t quotient, remainder = 0; + /* + * With HN_DIVISOR_1000 defined, SI prefixes for decimal multiplies + * are used. Without this flag, the raditional power of two prefixes + * are used. If however HN_IEC_PREFIXES is defined, the power of + * two prefixes recommended by the International Electrotechnical + * Commission (IEC) in IEC 80000-3 (superseeding IEC 60027-2) + * (i.e. Ki, Mi, Gi...) are used. + * + * Please note that HN_DIVISOR_1000 takes priority over HN_IEC_PREFIXES. + * The default behavior is to use the traditional power of two prefixes. + */ if (flags & HN_DIVISOR_1000) { - /* SI for decimal multiplies */ divisor = 1000; + shift = 1; if (flags & HN_B) prefixes = "B\0k\0M\0G\0T\0P\0E"; else prefixes = "\0\0k\0M\0G\0T\0P\0E"; + } else if (flags & HN_IEC_PREFIXES) { + divisor = 1024; + shift = 2; + if (flags & HN_B) + prefixes = "B\0\0\0Ki\0\0Mi\0\0Gi\0\0Ti\0\0Pi\0\0Ei"; + else + prefixes = "\0\0\0\0Ki\0\0Mi\0\0Gi\0\0Ti\0\0Pi\0\0Ei"; } else { - /* - * binary multiplies - * XXX IEC 60027-2 recommends Ki, Mi, Gi... - */ divisor = 1024; + shift = 1; if (flags & HN_B) prefixes = "B\0K\0M\0G\0T\0P\0E"; else prefixes = "\0\0K\0M\0G\0T\0P\0E"; } -#define SCALE2PREFIX(scale) (&prefixes[(scale) << 1]) +#define SCALE2PREFIX(scale) (&prefixes[(scale) << shift]) maxscale = 7; if (scale >= maxscale && @@ -102,6 +117,10 @@ humanize_number(char *buf, size_t len, int64_t quotient, sep = " "; baselen++; } + if (flags & HN_IEC_PREFIXES) { + baselen ++; + len ++; + } baselen += strlen(suffix); /* Check if enough room for `x y' + suffix + `\0' */ diff --git a/lib/libutil/libutil.h b/lib/libutil/libutil.h index 66104e9..295a8d3 100644 --- a/lib/libutil/libutil.h +++ b/lib/libutil/libutil.h @@ -220,6 +220,7 @@ __END_DECLS #define HN_NOSPACE 0x02 #define HN_B 0x04 #define HN_DIVISOR_1000 0x08 +#define HN_IEC_PREFIXES 0x0f #define HN_GETSCALE 0x10 #define HN_AUTOSCALE 0x20 --CE+1k2dSO48ffgeK-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 04:19: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 2A1C4106564A; Fri, 25 Mar 2011 04:19:24 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id B15348FC08; Fri, 25 Mar 2011 04:19:23 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 77DB0E77C8; Fri, 25 Mar 2011 04:19:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=HTNci1M9T32K vsrwHr6QLr2Sn0A=; b=cDr6Zqtv6mAT1l5uFNFEIIuS8QoM1Jn66oLWk++JxuQW j36eBlMW1NF7O3wAIks5osKG3J3JK9tOm+wfhS7Mt8tBIApEBDhzM/4PwfevRWWx n6w+ficwuey6JSyMWPJYOcrmiSX+SWsBAxAGRO251ExJuaex+FD19PQJGmulWXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=xLSPOK ddNgkSGY3mApUisnj2EZsLjNNxYuOdAxMJRUOys5YyPEhYboSAuPq3Kr9Do09791 Hps5LiOH35U9902DLZlXc3PwUpWr2S6RU70KFc7ILW1JrRmjkS88SxrZx1HTi673 gAw9+EHNAzEd2PCbOhCwiYuy/5v6Fzknms0ks= Received: from unknown (client-86-31-236-253.oxfd.adsl.virginmedia.com [86.31.236.253]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 12449E77B3; Fri, 25 Mar 2011 04:19:22 +0000 (GMT) Date: Fri, 25 Mar 2011 04:19:05 +0000 From: Bruce Cran To: Alexander Best Message-ID: <20110325041905.00006711@unknown> In-Reply-To: <20110325002115.GA323@freebsd.org> References: <20110325002115.GA323@freebsd.org> X-Mailer: Claws Mail 3.7.8cvs9 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Switching to [KMGTPE]i prefixes? 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, 25 Mar 2011 04:19:24 -0000 On Fri, 25 Mar 2011 00:21:15 +0000 Alexander Best wrote: > i hacked up humanized_number(3) a bit in order to produce the > following df(1) output: > [...] > 4.2Gi 4.2Gi 0B 100% 0 0 100% /media/dvd I don't know if it's correct, but Snow Leopard uses "Bi" for bytes. -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 05:41: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 12B5C106564A; Fri, 25 Mar 2011 05:41: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 CAB688FC12; Fri, 25 Mar 2011 05:41:14 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63] (may be forged)) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id p2P5cxtK039240; Thu, 24 Mar 2011 23:38:59 -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: <20110325015508.GA14565@freebsd.org> Date: Thu, 24 Mar 2011 23:38:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110325002115.GA323@freebsd.org> <20110325015508.GA14565@freebsd.org> To: Alexander Best X-Mailer: Apple Mail (2.1082) Cc: freebsd-hackers@freebsd.org Subject: Re: Switching to [KMGTPE]i prefixes? 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, 25 Mar 2011 05:41:15 -0000 The new flag is '0x0f' but it should be '0x40' since that's a bit = field... I did some doodling with this as well in my tree, and came up with = something similar. I had an ifdef that forced the new mode, but I was = never happy with the results. Warner On Mar 24, 2011, at 7:55 PM, Alexander Best wrote: > here's a rough draft. it introduces a new flag called HN_IEC_PREFIXES = so > nothing should get broken and each utility can decide for itself = whether to use > the SI binary, SI decimal or the IEC certified prefixes. >=20 > another possibility would be to #ifdef the extra code. this would = offer the > possibility to turn the new code on or off without having to adjust = any > utilities. of course this behaviour should be disabled by default in = order to > maintain compatibility. >=20 > cheers. > alex >=20 > --=20 > a13x > _______________________________________________ > 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 Mar 25 09:40: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 5F6AE106566C for ; Fri, 25 Mar 2011 09:40:50 +0000 (UTC) (envelope-from johans@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id E0F508FC14 for ; Fri, 25 Mar 2011 09:40:49 +0000 (UTC) Received: by mx1.stack.nl (Postfix, from userid 65534) id ED4101DD9B6; Fri, 25 Mar 2011 10:40:48 +0100 (CET) X-Spam-DCC: SION: scanner01.stack.nl 1111; Body=3 Fuz1=3 Fuz2=3 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on scanner01.stack.nl X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_OPENWHOIS,NO_RELAYS autolearn=no version=3.2.5 X-Spam-Relay-Country: _RELAYCOUNTRY_ Received: from mud.stack.nl (mud.stack.nl [IPv6:2001:610:1108:5011::70]) by mx1.stack.nl (Postfix) with ESMTP id 9FBA01DD64E; Fri, 25 Mar 2011 10:40:44 +0100 (CET) Received: by mud.stack.nl (Postfix, from userid 801) id 8A70111482; Fri, 25 Mar 2011 10:40:44 +0100 (CET) Date: Fri, 25 Mar 2011 10:40:44 +0100 From: Johan van Selst To: Zhihao Yuan Message-ID: <20110325094044.GA41319@mud.stack.nl> References: <86aaglx1ow.fsf@gmail.com> <20110324111118.GF65750@cicely7.cicely.de> <20110324221757.GA20441@mud.stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Arnaud Lacombe , freebsd-hackers@freebsd.org, Bernd Walter , ticso@cicely.de, Pan Tsu Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 25 Mar 2011 09:40:50 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Zhihao Yuan wrote: > > Could you please eleborate on the nvi-devel problems? I'm the current > > maintainer of this port, and as far as I know it's fully functional. > 1. It does not support non-Unicode encodings. Actually, these > encodings are mainstream in multi-byte encodings world. A proper > iconv-awared implementation should be able to handle all of the > encodings in `iconv -l`; > 2. It depends on DB3/4. We won't accept DB3/4 in base system and we > won't accept nvi-devel. > 3. It's not 100% compatible with nvi 1.79. Thank you for explaining. Indeed, all valid points and I fully agree that nvi-devel is not fit for inclusion in base as it is. In fact, the nvi from base is probably a better starting point (than nvi-devel) to create an editor that is fully compatible with nvi 1.79 and supports all multi-byte encodings. And when you, or someone, else creates such an editor, I will be pleased to remove the obsoleted port of nvi-devel. Johan --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iF4EAREIAAYFAk2MYxoACgkQAEpMHW8nCPQezQD/ezL20Q2D2wShen2R9afe1bHl XZ5sTCKDdmVefqqbPEoA/j8NdqGtf8Ta6Ve6jqY4HhnY9v6tmpP/pRe8NZbKsCmv =dCWy -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 10:13:04 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 4779C1065674; Fri, 25 Mar 2011 10:13:04 +0000 (UTC) Date: Fri, 25 Mar 2011 10:13:04 +0000 From: Alexander Best To: Bruce Cran Message-ID: <20110325101304.GA56260@freebsd.org> References: <20110325002115.GA323@freebsd.org> <20110325041905.00006711@unknown> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110325041905.00006711@unknown> Cc: freebsd-hackers@freebsd.org Subject: Re: Switching to [KMGTPE]i prefixes? 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, 25 Mar 2011 10:13:04 -0000 On Fri Mar 25 11, Bruce Cran wrote: > On Fri, 25 Mar 2011 00:21:15 +0000 > Alexander Best wrote: > > > i hacked up humanized_number(3) a bit in order to produce the > > following df(1) output: > > [...] > > 4.2Gi 4.2Gi 0B 100% 0 0 100% /media/dvd > > I don't know if it's correct, but Snow Leopard uses "Bi" for bytes. hmmm...i'm wondering why they do that. there's no reason for that, because 1 bytes is 8 bit no matter if you use a power of one or a power of ten. cheers. alex > > -- > Bruce Cran -- a13x From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 10:27:34 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 4F8D01065670; Fri, 25 Mar 2011 10:27:33 +0000 (UTC) Date: Fri, 25 Mar 2011 10:27:33 +0000 From: Alexander Best To: Warner Losh Message-ID: <20110325102733.GB56260@freebsd.org> References: <20110325002115.GA323@freebsd.org> <20110325015508.GA14565@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: Switching to [KMGTPE]i prefixes? 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, 25 Mar 2011 10:27:34 -0000 On Thu Mar 24 11, Warner Losh wrote: > The new flag is '0x0f' but it should be '0x40' since that's a bit field... thanks for the hint. i've updated that particular line in libutil.h. > > I did some doodling with this as well in my tree, and came up with something similar. I had an ifdef that forced the new mode, but I was never happy with the results. > > Warner > > > On Mar 24, 2011, at 7:55 PM, Alexander Best wrote: > > > here's a rough draft. it introduces a new flag called HN_IEC_PREFIXES so > > nothing should get broken and each utility can decide for itself whether to use > > the SI binary, SI decimal or the IEC certified prefixes. > > > > another possibility would be to #ifdef the extra code. this would offer the > > possibility to turn the new code on or off without having to adjust any > > utilities. of course this behaviour should be disabled by default in order to > > maintain compatibility. > > > > cheers. > > alex > > > > -- > > a13x > > _______________________________________________ > > 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" -- a13x From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 10:40:52 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 BB6F51065670; Fri, 25 Mar 2011 10:40:52 +0000 (UTC) (envelope-from baptiste.daroussin@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 258188FC1E; Fri, 25 Mar 2011 10:40:51 +0000 (UTC) Received: by wyf23 with SMTP id 23so1073971wyf.13 for ; Fri, 25 Mar 2011 03:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:subject:message-id :mime-version:content-type:content-disposition:user-agent; bh=pjiZh3Fout4W9yLPRajqB/kSvs5rtznlRSHZy8Qa2LM=; b=AtaEcnjDydxhSnQsWHt6NlfIpz3yopsrP/O7rmxEj4qWQMyFfEgu3QBebApuLGV7Kx JptCrHgIMv1q21Ak6Eg3PTzeh2LE5JiH1tH9kbY7lFltlQMdj03BxgOUOkzyBU8OwVxr YSfWs+OnvUGNQ12jSO4mlQstUQ6ydiJILbdtY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=r402P9l9Ag7CJgZcFyykp9RRr6NxDzmlzhzjS/x9TkrAOBXDO+JnfQtZf6BkLEXt5p Q79nTRABZrfZYjSL3sAXHnsE0bY3YhjSULHqJiDRX6vbmBN223QII9kPMonOxb62DySM pRc5uZjA/u5ZktaPeR94yo82VaO23d84JOTR8= Received: by 10.216.190.40 with SMTP id d40mr536147wen.34.1301047875455; Fri, 25 Mar 2011 03:11:15 -0700 (PDT) Received: from azathoth.lan (mlr78-1-82-232-208-178.fbx.proxad.net [82.232.208.178]) by mx.google.com with ESMTPS id z50sm279026weq.47.2011.03.25.03.11.13 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Mar 2011 03:11:14 -0700 (PDT) Sender: Baptiste Daroussin Date: Fri, 25 Mar 2011 11:11:11 +0100 From: Baptiste Daroussin To: ports@FreeBSD.org, hackers@FreeBSD.org, current@FreeBSD.org Message-ID: <20110325101111.GA36840@azathoth.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install 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, 25 Mar 2011 10:40:52 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, miwi@ launched the new thing called Experimental Call For Testing, it's our turn :) Julien Laffaye (jlaffaye@) and I, helped by Philippe Pepiot (huge contributor) have been working since the end of the last GSoC on a rewrite of pkg_install. pkgng is a binary package manager written from scratch for FreeBSD. After a long period of technology testing, (json, tinycdb, bdb, etc) and we now have achieved to implement the basic functionnality. We would greatly approciate to have some feedback, wider testing, patching, documenting etc, before implementing the higher level features. pkgng is built on top of a new libpkg, which allow to deal with the database of installed packages, to deal with remote repositories, manage packages: creation, installation gathering informations, registering new ports. features supported are or will be : - smooth integration with bsd.port.mk (including bsd.pkg.mk line 2486) which allow to have a bsd.port.mk which deal with both pkg_install and pkgng. (done in alpha) - the register command can analyse elf files when registering a new port to discover forgotten dependencies if necessary. (done in alpha using libelf) - the register command has two mode available : when dealing with old fashion ports it just registers the package, in new mode it does everything that would have been done by pkg add when installing the package : should display messages, execute post-install, execute @exec etc. (old fashion done in the alpha) - pkg add supports two mode : the old fashion one (no real upgrade support) and new one: upgrade scripts supported. (old fashion in the alpha) - new scripts supported +PREINSTALL +POSTINSTALL, +PREDEINSTALL, +POSTDEINSTALL, +PREUPGRADE, +POSTUPGRADE as well as the old fashion scripts : +INSTALL +DEINSTALL +UPGRADE (all supported *UPGRADES aren't supported in the alpha) - new +MANIFEST (plist-like format) with new metadatas : options, arch, os version, etc. (done in the alpha) - pkgng supports checking arch of the package which means that users won't be able to install sparc64 binary package into amd64 machines. (not done yet) - a special architecture "all" allows to specify when a package can be used on every architecture. (not done yet) - @dirrm and @dirrmtry are now deprecated, pkgng can discover itself which directory has to be removed. (done in the alpha but needs love :)) - new repository (apt-like feature) (only the repository generation is done) - real support for reverse dependency (no ugly +REQUIRED_BY) (done in the alpha) - test unit (libcheck) on libpkg. (done in the alpha needs some more love) - many more In term of technology we decided to use a sqlite3 database, and to prevent potential trolling, sqlite3 is used in it's amalgamation form which means it is incorporated in the code sources (as recommanded by sqlite developpers like a statically linked library) on build we only activate the features we need in sqlite. The alpha release come with an experimental tool "pkg2ng" to convert an existing package database to the new pkgng database format. So one can test pkgng without rebuild all its packages. One of the thing we are thinking about pkgng is to perhaps be able to provide it only as a ports (with simple script in base to boostrap/install it). That would allow pkgng to live with the ports to be able to easily integrate new features without having to support very old version of pkgng. design: pkgng is composed of : - a clean library "libpkg" that does all the work - a modern cli frontend (pkg) which accept subcommands, basically type pkg add, pkg info, pkg create etc. a dedicated subcommand exists for ports: pkg register which goal is to only supported adding to the database what is already installed. more informations can be found here: http://git.etoilebsd.net/pkgng/tree/docs/GOALS, http://git.etoilebsd.net/pkgng/tree/README http://git.etoilebsd.net/pkgng/tree/docs/TODO To download the alpha: http://git.etoilebsd.net/pkgng/snapshot/pkgng-0.1-alpha1.tar.gz Build it with debugging information: make DEBUG_FLAGS="-g -O0 -DDEBUG" Developpement site: http://git.etoilebsd.net/pkgng/ IRC chan: #pkgng@freenode Beware that pkgng is in alpha states, it can kill kittens and eat puppies, and for sure it will do it so now you are warned. regards, bapt, --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2Maj8ACgkQ8kTtMUmk6EyXfQCgvm3Jxn56dYsUn4reW+4TNXXR /ykAoJld7THTIRcj6Ep5xBNnPFEswv07 =qzf7 -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 10:50: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 9CE6E1065673 for ; Fri, 25 Mar 2011 10:50:32 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 2394C8FC14 for ; Fri, 25 Mar 2011 10:50:31 +0000 (UTC) Received: from mail35.syd.optusnet.com.au (mail35.syd.optusnet.com.au [211.29.133.51]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p2P8OW7h019756 for ; Fri, 25 Mar 2011 19:24:32 +1100 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail35.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p2P8OSTW021801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Mar 2011 19:24:29 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p2P8ORgB056455; Fri, 25 Mar 2011 19:24:27 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p2P8OR7n056454; Fri, 25 Mar 2011 19:24:27 +1100 (EST) (envelope-from peter) Date: Fri, 25 Mar 2011 19:24:27 +1100 From: Peter Jeremy To: Jing Huang Message-ID: <20110325082427.GA56170@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: [GSoc] Timeconter Performance Improvements 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, 25 Mar 2011 10:50:32 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Mar-24 17:00:02 +0800, Jing Huang wrote: > In this scenario, I plan to use both tsc and shared memory to >calculate precise time in user mode. The shared memory includes >system_time, tsc_system_time and factor_tsc-system_time. This sounds like a reasonable approach to me. Note that once we implement a shared page, there is probably a variety of other information we could usefully place on that page. SunOS 4.x included a page of shared memory per CPU. This was mapped as an array (indexed by CPU number) at one address and the page reflecting the current CPU was additionally mapped at another fixed address. This allowed a process to both refer to data on its CPU as well any CPU on the system. > We also consider the CPU frequency, because tsc counter is >related to it. When kernel changes CPU frequency, the shared memory >should be update subsequently. Two issues with this, particularly on x86 without invariant TSC: - looking up the current CPU frequency may not be a cheap operation - the reported CPU frequency appears to be just an approximate value, rather than the actual TSC frequency. On 2011-Mar-24 21:34:35 +0800, Jing Huang wrote: > As I know, tsc counter is CPU specific. If the process running on >a multi-core platform, we must consider switching problem. The one >way, we can let the kernel to take of this. When switching to another >CPU, the kernel will reset the shared memory according to the new CPU. I'm not sure what the cost of managing this page mapping will be. >The second way, we can use CPUID instruction to get the info of >current CPU, which can be executed in user mode ether. At the same >time, the kernel maintains shared memory for each CPU. When invoke >gettimeofday, the function will calculate precise time with current >CPU's shared memory. This approach suffers from a race condition between the CPUID instruction and accessing the appropriate shared page - there is the potential for an interrupt causing the process to be switched to a different CPU, resulting in an incorrect page being accessed. --=20 Peter Jeremy --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk2MUTsACgkQ/opHv/APuIeKAwCfSWSPl5kfMdsUC4D1gjM2cI0w V0sAoJ7JccSKE4nR/t9s+Jl2wYECdZr0 =SC5O -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 11:09:04 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 05DBF1065672 for ; Fri, 25 Mar 2011 11:09:04 +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 463BD8FC1A for ; Fri, 25 Mar 2011 11:09:02 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA12365; Fri, 25 Mar 2011 12:56:57 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Q34hN-000Kul-IV; Fri, 25 Mar 2011 12:56:57 +0200 Message-ID: <4D8C74F8.4010303@freebsd.org> Date: Fri, 25 Mar 2011 12:56:56 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alexander Leidinger References: <20110325105213.53217afxpg1kj7s4@webmail.leidinger.net> In-Reply-To: <20110325105213.53217afxpg1kj7s4@webmail.leidinger.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: dtrace sdt problem: my fault or a generic problem (SYSINIT not working as expected for modules)? 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, 25 Mar 2011 11:09:04 -0000 on 25/03/2011 11:52 Alexander Leidinger said the following: > As I read it, it looks a little bit like the SYSINIT of the SDT probes didn't > work as expected for my new probes (does this work in modules? fxr.watson.org > AFAICS only lists SDT probes in kernel-code, not in module-code), a hit with the > clue-bat is welcome. My reading of the code is that all modules with SDT proivders/probes should be loaded before sdt module itself. SYSINIT in your module(s) works as expect, but dtrace_register() is not called on your SDT provider. See sys/cddl/dev/sdt/sdt.c for details: sdt_modevent -> sdt_load -> sdt_provider_listall(sdt_provider_reg_callback) -> dtrace_register. I am not saying that this behavior is correct/desired, just that this is what we have now. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 06:23:50 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 E073D106564A for ; Fri, 25 Mar 2011 06:23:50 +0000 (UTC) (envelope-from lazaax@sys7server.net) Received: from sys7server.net (chapulin.mx [204.109.59.30]) by mx1.freebsd.org (Postfix) with ESMTP id A58288FC14 for ; Fri, 25 Mar 2011 06:23:50 +0000 (UTC) Received: from antiserver.sys7.mx ([10.154.0.6]) by sys7server.net (8.14.4/8.14.4) with ESMTP id p2OKaxIN043237 for ; Thu, 24 Mar 2011 20:36:59 GMT (envelope-from lazaax@sys7server.net) Message-ID: <4D8CA837.1090403@sys7server.net> Date: Fri, 25 Mar 2011 08:35:35 -0600 From: lazaax User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: hackers@freebsd.org References: <000001cbea59$eb1c4b00$c154e100$@com> In-Reply-To: <000001cbea59$eb1c4b00$c154e100$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 25 Mar 2011 11:12:28 +0000 Cc: Subject: Re: GSoC 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, 25 Mar 2011 06:23:51 -0000 Dudinskyi Olexandr wrote: > Hello. > > My name is Dudinskyi Oleksandr. I am a student of National aviation university, Ukraine. I want to participate in GSoC 2011 with your organization. > > My project: Disk device error counters, iostat –e. > > I thing this project is very necessary in the FreeBSD system. Now I make a plan to develop this project. > > What you can say about the idea of ​​my project? And what about the favor of this project? > > My mentor: Andriy Gapon. > > _______________________________________________ > 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" > > > > hi im lazaax i dont study but i like unix system and do some things i have a proyect called sys7server i like to participate on gsoc and tell about sys7 and sys7server proyects .. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 09:25:27 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 5E66F106564A for ; Fri, 25 Mar 2011 09:25:27 +0000 (UTC) (envelope-from dudinskyj@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id E1D338FC15 for ; Fri, 25 Mar 2011 09:25:26 +0000 (UTC) Received: by fxm11 with SMTP id 11so1191902fxm.13 for ; Fri, 25 Mar 2011 02:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=qdM8639BCBjYuXpzjUR8unMML5mSyuG0PnISkK3is+0=; b=Fop8QG4GoIgkdm0JLhDmatl3J9yN8Cczun3BDbhd672PuPUJUpdMMxRL0YeaL8uIuk QehmvE2Ak4sFaSbc+R5Thd/k1pjyPN5TNxRJ38ZWnrd6ZzQ67bceYm1Bi1QKyUlkHSkd OOMnAXpnab7tUO5rz5igcwdYZzhkVExkjpbro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; b=Xo6PLheWqcHeFAlAYgAutg1zEcQl6ZrqSM6q2mR8DpvS/otqYGbXLMB8amY83jROYx TbNvPicbF2zd5vek27dPLnFPU0Hq8nK2H8PuIAa674HVOnsyQ3Nsrmv9GRsp5OthKar7 mS0tvPlQmfwNoK3E7IHBCNmJjAWdy0iYQoiTY= Received: by 10.223.76.129 with SMTP id c1mr121935fak.107.1301045125791; Fri, 25 Mar 2011 02:25:25 -0700 (PDT) Received: from LocalHost ([92.249.73.111]) by mx.google.com with ESMTPS id 17sm306718far.43.2011.03.25.02.25.23 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Mar 2011 02:25:24 -0700 (PDT) From: Dudinskyi Olexandr To: Date: Fri, 25 Mar 2011 11:25:19 +0200 Message-ID: <000501cbeace$9008a7c0$b019f740$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvqVtIgqH5sNbj/TV6XMpCrhgA6KgAd4vaw Content-Language: uk X-Mailman-Approved-At: Fri, 25 Mar 2011 11:12:44 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: GSoC 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, 25 Mar 2011 09:25:27 -0000 Hello. My name is Dudinskyi Oleksandr. I am a student of National aviation = university, Ukraine. I want to participate in GSoC 2011 with your = organization. My project: Disk device error counters, iostat =E2=80=93e. I thing this project is very necessary in the FreeBSD system. Now I = make a plan to develop this project. What you can say about the idea of =E2=80=8B=E2=80=8Bmy project? And = what about the favor of this project? My mentor: Andriy Gapon. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 09:52:28 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 CF09E1065672; Fri, 25 Mar 2011 09:52:28 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 501928FC13; Fri, 25 Mar 2011 09:52:28 +0000 (UTC) Received: from outgoing.leidinger.net (p5B1553A9.dip.t-dialin.net [91.21.83.169]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id D086D844015; Fri, 25 Mar 2011 10:52:22 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id ADBAB1462; Fri, 25 Mar 2011 10:52:19 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p2P9qE6Y063874; Fri, 25 Mar 2011 10:52:14 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 25 Mar 2011 10:52:13 +0100 Message-ID: <20110325105213.53217afxpg1kj7s4@webmail.leidinger.net> Date: Fri, 25 Mar 2011 10:52:13 +0100 From: Alexander Leidinger To: Andriy Gapon , hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: D086D844015.A0ADB X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.887, required 6, autolearn=disabled, J_CHICKENPOX_52 0.60, J_CHICKENPOX_73 0.60, J_CHICKENPOX_74 0.60, TW_TQ 0.08, T_FILL_THIS_FORM_SHORT 0.01) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1301651543.64359@IpvCjUbKvIJAgs8iB2OBYQ X-EBL-Spam-Status: No X-Mailman-Approved-At: Fri, 25 Mar 2011 11:13:07 +0000 Cc: Subject: dtrace sdt problem: my fault or a generic problem (SYSINIT not working as expected for modules)? 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, 25 Mar 2011 09:52:28 -0000 Hi, I'm in the process of adding some SDT probes to the linuxulator. Unfortunately I get a kernel panic while doing a "dtrace -l -P linuxulator". What I see in kgdb puzzles me. Maybe someone can help out? The id of the provider is 0x0, I would expect this is a little problem. Debugging session follows with some discussion inline and afterwards. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x48 fault code = supervisor read, page not present instruction pointer = 0x20:0x80db03db stack pointer = 0x28:0xafb4d7f8 frame pointer = 0x28:0xafb4d83c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1415 (initial thread) trap number = 12 panic: page fault Uptime: 10m4s #5 0x8071e9c6 in trap (frame=0xafb4d7b8) at ../../../i386/i386/trap.c:553 #6 0x8070aa4c in calltrap () at ../../../i386/i386/exception.s:168 #7 0x80db03db in dtrace_probe_lookup (prid=0, mod=0xafb4d8e0 "emul", func=0xafb4d8a0 "linux_schedtail", name=0xafb4d860 "return") at /usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:7807 #8 0x80ee0955 in sdt_probe_callback (probe=0x859daca0, arg=0x0) at /usr/src/sys/modules/dtrace/sdt/../../../cddl/dev/sdt/sdt.c:131 (kgdb) up 7 During symbol reading, Incomplete CFI data; unspecified registers at 0x80560633. #7 0x80db03db in dtrace_probe_lookup (prid=0x0, mod=0xafb4d8e0 "emul", func=0xafb4d8a0 "linux_schedtail", name=0xafb4d860 "return") at /usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:7807 7807 pkey.dtpk_mmatch = mod ? &dtrace_match_string : &dtrace_match_nul; prid is zero...? (kgdb) list 7802 int match; 7803 7804 pkey.dtpk_prov = ((dtrace_provider_t *)prid)->dtpv_name; 7805 pkey.dtpk_pmatch = &dtrace_match_string; 7806 pkey.dtpk_mod = mod; 7807 pkey.dtpk_mmatch = mod ? &dtrace_match_string : &dtrace_match_nul; 7808 pkey.dtpk_func = func; 7809 pkey.dtpk_fmatch = func ? &dtrace_match_string : &dtrace_match_nul; 7810 pkey.dtpk_name = name; 7811 pkey.dtpk_nmatch = name ? &dtrace_match_string : &dtrace_match_nul; (kgdb) print pkey $1 = { dtpk_prov = 0x1e58
, dtpk_pmatch = 0xafb4d83c, dtpk_mod = 0x80db1143 "\213E203034[^_]\220 ,S200d\213\025", dtpk_mmatch = 0x80ed531c , dtpk_func = 0x80dc68d8 "/usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c", dtpk_fmatch = 0x1e58, dtpk_name = 0x1e18
, dtpk_nmatch = 0x72e, dtpk_id = 0x72f } (kgdb) print ((dtrace_provider_t *)prid)->dtpv_name Cannot access memory at address 0x48 Ok, prid is NULL, so this is not a surprise, but why is it NULL? (kgdb) print prid $2 = 0x0 (kgdb) print mod $3 = 0xafb4d8e0 "emul" (kgdb) up 1 #8 0x80ee0955 in sdt_probe_callback (probe=0x859daca0, arg=0x0) at /usr/src/sys/modules/dtrace/sdt/../../../cddl/dev/sdt/sdt.c:131 131 if (dtrace_probe_lookup(prov->id, mod, func, name) != 0) (kgdb) list 126 */ 127 strlcpy(mod, probe->mod, sizeof(mod)); 128 strlcpy(func, probe->func, sizeof(func)); 129 strlcpy(name, probe->name, sizeof(name)); 130 131 if (dtrace_probe_lookup(prov->id, mod, func, name) != 0) 132 return (0); 133 134 (void) dtrace_probe_create(prov->id, probe->mod, probe->func, 135 probe->name, 0, probe); (kgdb) print prov $4 = (struct sdt_provider *) 0x859da520 (kgdb) print *prov $5 = { name = 0x859d719d "linuxulator", prov_entry = { tqe_next = 0x0, tqe_prev = 0x807bbac4 }, probe_list = { tqh_first = 0x859daca0, tqh_last = 0x859e442c }, id = 0x0 } (kgdb) print probe $6 = (struct sdt_probe *) 0x859daca0 (kgdb) print *probe $7 = { version = 0x34, state = SDT_INIT, prov = 0x859da520, probe_entry = { tqe_next = 0x859dac40, tqe_prev = 0x859da52c }, argtype_list = { tqh_first = 0x0, tqh_last = 0x859dacb4 }, mod = 0x859d7204 "emul", func = 0x859d72af "linux_schedtail", name = 0x859d721f "return", id = 0x0, n_args = 0x0 } It looks suspicious to mee that the id is NULL. Here is what I do: kernel with KDTRACE_HOOKS, makeoptions WITH_CTF=yes, DDB_CTF. The SDT probes are in linux.ko which is loaded after the dtrace, cyclic, sdt, profile, fbt, systrace and lockstat modules. My patches are at http://www.Leidinger.net/FreeBSD/current-patches/linuxulator-dtrace.diff linux_emul.c contains LIN_SDT_PROVIDER_DEFINE(LINUX_DTRACE); which is just a mapping of SDT_PROVIDE_DEFINE. All other files contain the corresponding DECLARE. Actually the kernel crashed at another place which uses automatically generated probes via a macro, and I removed those probes to see if I made a mistake in this macro. Now it crashes for this probe which I added directly in this place by hand. I do not know if this is the first of my probes which is causing the crash, or if this is somewhere after already processing some of my probes. Is there a way to find this out with kgdb? Without linux.ko loaded, "dtrace -l | head" works as expected. As I am forward porting my SDT probes from a -current from 2008, and my probes worked back then, the probes themself should not be a big problem. I assume my use of the SDT_PROBE_DEFINE[1-5] macros is OK (sys/compat/linux/linux_dtrace.h), reviews welcome. As I read it, it looks a little bit like the SYSINIT of the SDT probes didn't work as expected for my new probes (does this work in modules? fxr.watson.org AFAICS only lists SDT probes in kernel-code, not in module-code), a hit with the clue-bat is welcome. Any hints how to debug this further are welcome. Bye, Alexander. -- Foolproof Operation: No provision for adjustment. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 12:25: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 DB6A11065680; Fri, 25 Mar 2011 12:25:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B1F958FC2A; Fri, 25 Mar 2011 12:25:12 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 677CD46B0D; Fri, 25 Mar 2011 08:25:12 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EE3DF8A027; Fri, 25 Mar 2011 08:25:11 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 25 Mar 2011 08:18:38 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110311; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103250818.38470.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 25 Mar 2011 08:25:12 -0400 (EDT) Cc: ivoras@freebsd.org, Jing Huang Subject: Re: [GSoc] Timeconter Performance Improvements 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, 25 Mar 2011 12:25:12 -0000 On Thursday, March 24, 2011 9:34:35 am Jing Huang wrote: > Hi, > > Thanks for your replay. That is just my self-introduction:) I want > to borrow the shared memory idea from KVM, I am not want to port a > whole KVM:) But for this project, there are some basic problems. > > As I know, tsc counter is CPU specific. If the process running on > a multi-core platform, we must consider switching problem. The one > way, we can let the kernel to take of this. When switching to another > CPU, the kernel will reset the shared memory according to the new CPU. > The second way, we can use CPUID instruction to get the info of > current CPU, which can be executed in user mode ether. At the same > time, the kernel maintains shared memory for each CPU. When invoke > gettimeofday, the function will calculate precise time with current > CPU's shared memory. > > I don't know which is better? Could I need to deal other problems? For modern Intel CPUs you can just assume that the TSCs are in sync across packages. They also have invariant TSC's meaning that the frequency doesn't change. You can easily export a copy of the current 'timehands' structure when the TSC is used as the timecounter and then just reimplement bintime() in userland. This assumes you use the TSC as the kernel's timecounter, but you really need to do that so that ntpd_adjtime() is taken into account, etc. That will give a very fast and very cheap timecounter. I believe we already have a shared page (it holds the signal trampoline now) for at least the x86 platform (probably some others as well). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 13:15:05 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 C00BE1065674; Fri, 25 Mar 2011 13:15:05 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6A0748FC14; Fri, 25 Mar 2011 13:15:05 +0000 (UTC) Received: from outgoing.leidinger.net (p5B1553A9.dip.t-dialin.net [91.21.83.169]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 33153844018; Fri, 25 Mar 2011 14:14:58 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 026E01478; Fri, 25 Mar 2011 14:14:54 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p2PDEnQL015309; Fri, 25 Mar 2011 14:14:49 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 25 Mar 2011 14:14:49 +0100 Message-ID: <20110325141449.175625s5pqmtbrk0@webmail.leidinger.net> Date: Fri, 25 Mar 2011 14:14:49 +0100 From: Alexander Leidinger To: Andriy Gapon References: <20110325105213.53217afxpg1kj7s4@webmail.leidinger.net> <4D8C74F8.4010303@freebsd.org> In-Reply-To: <4D8C74F8.4010303@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 33153844018.AD0D7 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.2, required 6, autolearn=disabled, J_CHICKENPOX_32 0.60, J_CHICKENPOX_52 0.60) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1301663700.12118@3o/7kx0J3iGf1hdraGEkIw X-EBL-Spam-Status: No X-Mailman-Approved-At: Fri, 25 Mar 2011 13:25:18 +0000 Cc: hackers@freebsd.org Subject: Re: dtrace sdt problem: my fault or a generic problem (SYSINIT not working as expected for modules)? 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, 25 Mar 2011 13:15:05 -0000 Quoting Andriy Gapon (from Fri, 25 Mar 2011 12:56:56 +0200): > on 25/03/2011 11:52 Alexander Leidinger said the following: >> As I read it, it looks a little bit like the SYSINIT of the SDT >> probes didn't >> work as expected for my new probes (does this work in modules? >> fxr.watson.org >> AFAICS only lists SDT probes in kernel-code, not in module-code), a >> hit with the >> clue-bat is welcome. > > My reading of the code is that all modules with SDT proivders/probes > should be > loaded before sdt module itself. > SYSINIT in your module(s) works as expect, but dtrace_register() is > not called > on your SDT provider. See sys/cddl/dev/sdt/sdt.c for details: > sdt_modevent -> > sdt_load -> sdt_provider_listall(sdt_provider_reg_callback) -> > dtrace_register. So if I load linux.ko before sdt.ko, or if I unload sdt.ko and reload it, it should work? I'm going to try this after sending this mail. > I am not saying that this behavior is correct/desired, just that > this is what we > have now. Is someone working on this? If not, what would be a solution for this? Adding a call (which one) to the modevent of the module which is using SDT probes? Can we prevent a kernel panic for this case (maybe detecting a NULL ID and skipping... or maybe even registering it)? Something to add to the ideas list as a GSoC entry, or is this too small/big? Bye, Alexander. -- One way to make your old car run better is to look up the price of a new model. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 13:45: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 93DA1106566B for ; Fri, 25 Mar 2011 13:45:42 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254:10::3c]) by mx1.freebsd.org (Postfix) with ESMTP id 4B7B88FC15 for ; Fri, 25 Mar 2011 13:45:42 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.4/8.14.4) with ESMTP id p2PDjcU9022490; Fri, 25 Mar 2011 09:45:38 -0400 (EDT) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.4/8.14.4/Submit) id p2PDjbFb022489; Fri, 25 Mar 2011 09:45:37 -0400 (EDT) (envelope-from lidl) Date: Fri, 25 Mar 2011 09:45:37 -0400 From: Kurt Lidl To: Johan van Selst Message-ID: <20110325134537.GB21904@pix.net> References: <20110324111118.GF65750@cicely7.cicely.de> <20110324221757.GA20441@mud.stack.nl> <20110325094044.GA41319@mud.stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110325094044.GA41319@mud.stack.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Arnaud Lacombe , freebsd-hackers@freebsd.org, Bernd Walter , Zhihao Yuan , Pan Tsu , ticso@cicely.de Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 25 Mar 2011 13:45:42 -0000 On Fri, Mar 25, 2011 at 10:40:44AM +0100, Johan van Selst wrote: > Zhihao Yuan wrote: > > > Could you please eleborate on the nvi-devel problems? I'm the current > > > maintainer of this port, and as far as I know it's fully functional. > > 1. It does not support non-Unicode encodings. Actually, these > > encodings are mainstream in multi-byte encodings world. A proper > > iconv-awared implementation should be able to handle all of the > > encodings in `iconv -l`; > > 2. It depends on DB3/4. We won't accept DB3/4 in base system and we > > won't accept nvi-devel. > > 3. It's not 100% compatible with nvi 1.79. > > Thank you for explaining. Indeed, all valid points and I fully agree > that nvi-devel is not fit for inclusion in base as it is. In fact, the > nvi from base is probably a better starting point (than nvi-devel) to > create an editor that is fully compatible with nvi 1.79 and supports all > multi-byte encodings. And when you, or someone, else creates such an > editor, I will be pleased to remove the obsoleted port of nvi-devel. Has anyone looked at the nvi work that has taken place in NetBSD in the last year or so? I think they've put in a bunch of wide character support. I'm not sure if their DB code relies on bdb newer than what is in libc or not. -Kurt From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 14:15:13 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 4C6A0106564A; Fri, 25 Mar 2011 14:15:13 +0000 (UTC) (envelope-from baptiste.daroussin@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 EB24E8FC0A; Fri, 25 Mar 2011 14:15:12 +0000 (UTC) Received: by iyj12 with SMTP id 12so1410794iyj.13 for ; Fri, 25 Mar 2011 07:15:12 -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:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=nBULJhR38e8GSfbFlpTplnIi5jp4wpDS0fb0QAMqadc=; b=swMZtHCXWEpjIKWDKKGfHF5EVhity71DrXDprFyehJmcWJNzPcUe518R2xLOtjq4w+ Niyxsoqd3Pjj0hVOkPpPqeVySz1mSZVs/KDyW/nYUvxt/7S4Q6dUnh0Wc0/Mt1+qK3GB OBW+m+ggk8JISzDl3s/iLTuBH3w3nKwHuyC5A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=isSkVJY6WHpDCtT0+DhBImeAcvJU1ZE1vjMkTTq5S6H3RcBbK6WxUMW5PXMrpPhh// fj7UpSfQ/BXrFRaKAieEKFEj+bhk7MsNc+E2mUNu0TsFxfdjKjv4bgPawjIT+rKTl8kv RxYlJwgO+fXGz2ockFzgT720y5x7Fn9KziTwY= Received: by 10.231.148.17 with SMTP id n17mr854134ibv.85.1301062512072; Fri, 25 Mar 2011 07:15:12 -0700 (PDT) MIME-Version: 1.0 Sender: baptiste.daroussin@gmail.com Received: by 10.231.182.76 with HTTP; Fri, 25 Mar 2011 07:14:52 -0700 (PDT) In-Reply-To: <20110325150653.21132ej6abxmjpgk@webmail.leidinger.net> References: <20110325101111.GA36840@azathoth.lan> <20110325150653.21132ej6abxmjpgk@webmail.leidinger.net> From: Baptiste Daroussin Date: Fri, 25 Mar 2011 15:14:52 +0100 X-Google-Sender-Auth: UdOeOCb25mJYduHPZn6j8N2-kj0 Message-ID: To: Alexander Leidinger Content-Type: text/plain; charset=ISO-8859-1 Cc: ports@freebsd.org, hackers@freebsd.org, current@freebsd.org Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install 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, 25 Mar 2011 14:15:13 -0000 2011/3/25 Alexander Leidinger : > Quoting Baptiste Daroussin (from Fri, 25 Mar 2011 > 11:11:11 +0100): > >> pkgng is a binary package manager written from scratch for FreeBSD. > > I didn't had a look at it, just some comments about some parts you > explained. > >> features supported are or will be : > >> - the register command can analyse elf files when registering a new port >> to >> discover forgotten dependencies if necessary. (done in alpha using libelf) > > This will probably fail if LD_LIBRARY_PATH is used, or if we are installing > linuxulator ports. > this isn't activated by default, and if activated is only intended to work on freebsd elf files. This is done to workaround some bugguy ports not to be used in production, pkg register shows in warning in that case so that user/maintainers are warned they have something to fix. >> >> - a special architecture "all" allows to specify when a package can be >> used >> on every architecture. (not done yet) > > What if a package is able to install on a subset, e.g. the linuxulator ports > are for amd64 and i386? > No clue for that at the moment but we are open to suggestions. > What about DB corruption/loss? Do you keep the /var/db/pkg//xxx > files even with pkgng and only use the DB as a way to speed up some work (so > the DB corruption just requires to run pkg2ng), or are you lost of the DB is > lost? > Nothing is done about DB corruption/loss, I am not sure we need to do something. Maybe. Currently a filesystem corruption/loss on /var/db/pkg would do the same. but it is sqlite so we can perhaps provide a way to get compressed dump so user can periodically backup their database. regards, Bapt From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 15:29: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 89D2C1065676; Fri, 25 Mar 2011 15:29:55 +0000 (UTC) (envelope-from julien.laffaye@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 19B218FC1C; Fri, 25 Mar 2011 15:29:54 +0000 (UTC) Received: by gwb15 with SMTP id 15so576311gwb.13 for ; Fri, 25 Mar 2011 08:29:54 -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=kL/C0kvR953FR6nHUoA2moQYutPRlh+qfCVWZXQGTnI=; b=lyXuaOY7JueL32sJ1vCcEPuktDMOqafaYKycXIONYIQV6aaqS1/lddnbJlpDQs14zf 8ICchoQai+gbXPQ/jKDygxshUQkCHUxlWP0VxZklOjBszTl7vIKa7TZ9qdlKPSsE7/4a UhwXh6+uwnDmtEyttmNrKWTttggIw4jZRGRxA= 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=VPyKA9MgX76sU9yJNa8cBWt+/n8wWbU07OdBcOAjPkkdqr/AsKquCCADhy9z0mtbFp OVB1xGl2TUmtieAgD2Inmy8rhDMTh11aHaFMRytLqpv2SVLu8c9R9jOQNi456SzLHsu0 vQs/GgwK+yIeZY0dbbYYuos0Jy4tJZyGo2EE4= MIME-Version: 1.0 Received: by 10.236.78.133 with SMTP id g5mr1315748yhe.35.1301065385885; Fri, 25 Mar 2011 08:03:05 -0700 (PDT) Sender: julien.laffaye@gmail.com Received: by 10.236.105.212 with HTTP; Fri, 25 Mar 2011 08:03:05 -0700 (PDT) In-Reply-To: <20110325153814.20287h1594npcu80@webmail.leidinger.net> References: <20110325101111.GA36840@azathoth.lan> <20110325150653.21132ej6abxmjpgk@webmail.leidinger.net> <20110325153814.20287h1594npcu80@webmail.leidinger.net> Date: Fri, 25 Mar 2011 15:03:05 +0000 X-Google-Sender-Auth: MI45DCBFuMYG7jXWX1JVZvQfsYo Message-ID: From: Julien Laffaye To: Alexander Leidinger Content-Type: text/plain; charset=ISO-8859-1 Cc: ports@freebsd.org, Baptiste Daroussin , hackers@freebsd.org, current@freebsd.org Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install 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, 25 Mar 2011 15:29:55 -0000 On Fri, Mar 25, 2011 at 2:38 PM, Alexander Leidinger wrote: > Quoting Baptiste Daroussin (from Fri, 25 Mar 2011 > 15:14:52 +0100): > >> 2011/3/25 Alexander Leidinger : >>> >>> Quoting Baptiste Daroussin (from Fri, 25 Mar 2011 >>> 11:11:11 +0100): >>> >>>> pkgng is a binary package manager written from scratch for FreeBSD. >>> >>> I didn't had a look at it, just some comments about some parts you >>> explained. >>> >>>> features supported are or will be : > >>>> - a special architecture "all" allows to specify when a package can be >>>> used >>>> on every architecture. (not done yet) >>> >>> What if a package is able to install on a subset, e.g. the linuxulator >>> ports >>> are for amd64 and i386? >>> >> >> No clue for that at the moment but we are open to suggestions. > > The suggestion is easy, allow a way to specify a set of valid architectures. That looks reasonable and easy to implement. > >>> What about DB corruption/loss? Do you keep the /var/db/pkg//xxx >>> files even with pkgng and only use the DB as a way to speed up some work >>> (so >>> the DB corruption just requires to run pkg2ng), or are you lost of the DB >>> is >>> lost? >>> >> >> Nothing is done about DB corruption/loss, I am not sure we need to do >> something. >> Maybe. > > I would say "for sure". Info: In Solaris 10 sqlite is used for the service > managenemt framework (SMF). It is possible that the DB is corrupt in some > bad situations. In this case you have to rebuild the DB (script provided, > been there, had to use it). If sqlite is properly used with transactions, it is very hard to corrupt the database. But if hardware lies to us and say that the data is on disk whereas it isnt... what can we do? Another potential problem is fsync(), but if it is broken on FreeBSD we want to fix it! BTW, the goal is to only have the database and not the flat files. If you are paranoid about power outage, use something like zfs snapshots... > >> Currently a filesystem corruption/loss on /var/db/pkg would do the same. > > Put a corruption of /var/db/pkg/xyz-1/+REQUIRED_BY would only affect a small > part, and this part could be even recovered from (pkgdb from portupgrade is > able to do it). With sqlite we have atomicity! And locks! > >> but it is sqlite so we can perhaps provide a way to get compressed >> dump so user can periodically backup their database. > > It needs to be automated. Maybe periodic daily... but maybe this is not > often enough after a day of a lot of changes (think about it this way: do > you want to lose a day of changes?). The current FS based DB is very robust, > partly because there is redundant data, pertly because losing a file just > means that the very limited subset of information is lost (and a reinstall > of one port will fix it). > > Bye, > Alexander. Regards, Julien From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 15:35:23 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 45E121065677; Fri, 25 Mar 2011 15:35:23 +0000 (UTC) (envelope-from gahr@gahrfit.gahr.ch) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0E9238FC13; Fri, 25 Mar 2011 15:35:23 +0000 (UTC) Received: from gahrfit.gahr.ch (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2PFZLUb037512; Fri, 25 Mar 2011 15:35:22 GMT (envelope-from gahr@gahrfit.gahr.ch) Received: by gahrfit.gahr.ch (Postfix, from userid 1001) id 44E1345025; Fri, 25 Mar 2011 16:35:21 +0100 (CET) Date: Fri, 25 Mar 2011 16:35:21 +0100 From: Pietro Cerutti To: Julien Laffaye Message-ID: <20110325153520.GB23861@gahrfit.gahr.ch> References: <20110325101111.GA36840@azathoth.lan> <20110325150653.21132ej6abxmjpgk@webmail.leidinger.net> <20110325153814.20287h1594npcu80@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: X-PGP-Key: 0x9571F78E X-PGP-Fingerprint: 1203 92B5 3919 AF84 9B97 28D6 C0C2 6A98 9571 F78E User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ports@freebsd.org, Alexander Leidinger , Baptiste Daroussin , hackers@freebsd.org, current@freebsd.org Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gahr@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 15:35:23 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Mar-25, 15:03, Julien Laffaye wrote: > >>> What about DB corruption/loss? Do you keep the /var/db/pkg//= xxx > >>> files even with pkgng and only use the DB as a way to speed up some w= ork > >>> (so > >>> the DB corruption just requires to run pkg2ng), or are you lost of th= e DB > >>> is > >>> lost? > >>> > >> > >> Nothing is done about DB corruption/loss, I am not sure we need to do > >> something. > >> Maybe. > > > > I would say "for sure". Info: In Solaris 10 sqlite is used for the serv= ice > > managenemt framework (SMF). It is possible that the DB is corrupt in so= me > > bad situations. In this case you have to rebuild the DB (script provide= d, > > been there, had to use it). >=20 > If sqlite is properly used with transactions, it is very hard to > corrupt the database. But if hardware lies to us and say that the data > is on disk whereas it isnt... what can we do? > Another potential problem is fsync(), but if it is broken on FreeBSD > we want to fix it! >=20 > BTW, the goal is to only have the database and not the flat files. > If you are paranoid about power outage, use something like zfs snapshots.= =2E. No need to look for strange scenarios, I'm surely going to sudo rm -f the f= ile more sooner than later, so... maybe just save a copy? --=20 Pietro Cerutti The FreeBSD Project gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2MtjgACgkQwMJqmJVx945uOwCg3+l6a53XfIhLsR8ylmV5es+N +d0An1d8oFP80eUC0Q4Wz3tUpk4hEOnB =W0Yb -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 15:41: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 68FEB1065670; Fri, 25 Mar 2011 15:41:55 +0000 (UTC) (envelope-from baptiste.daroussin@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 0EE468FC1B; Fri, 25 Mar 2011 15:41:54 +0000 (UTC) Received: by iwn33 with SMTP id 33so1467364iwn.13 for ; Fri, 25 Mar 2011 08:41:54 -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:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=maBIL6bLjr1N3yYifLa7A0goEC7hUCT/cPEr/FnI6aE=; b=XRt9uG/tmfXtyTpYpCGXsLTfGk7ItIpf8216gAg97RGNY58YIk7OvU1Xs9QVEZeb0L Z8IrOI/IJcOzxkq0b/JRre9ZzDtTGV/uHQgIMcrfAVol+L//iWXxJEFD2CsnEyJSdWsT W+D5atPtd4L7UCGsFUo8E1paQ9k4Cu3ptipME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=YcfNpelUHG7wgM6mEX6x/gsET4UcOpmu6jZr3CEUGO1s1TKfzs9K5+JCzx4XIHCXRX XZ8bcINeClfHd0fecab9AOvzcD7arhiUQqJPzlez6MmCW2IAQS5H+9q0lAUeiR+IBi1T lUXAap3xCW2dcbdG6pa/8sUUkM21QsFm1kME0= Received: by 10.43.65.72 with SMTP id xl8mr1419264icb.211.1301067714051; Fri, 25 Mar 2011 08:41:54 -0700 (PDT) MIME-Version: 1.0 Sender: baptiste.daroussin@gmail.com Received: by 10.231.182.76 with HTTP; Fri, 25 Mar 2011 08:41:34 -0700 (PDT) In-Reply-To: <20110325153520.GB23861@gahrfit.gahr.ch> References: <20110325101111.GA36840@azathoth.lan> <20110325150653.21132ej6abxmjpgk@webmail.leidinger.net> <20110325153814.20287h1594npcu80@webmail.leidinger.net> <20110325153520.GB23861@gahrfit.gahr.ch> From: Baptiste Daroussin Date: Fri, 25 Mar 2011 16:41:34 +0100 X-Google-Sender-Auth: iPWxLq6kxQEpqppKoZJcsnn-yTs Message-ID: To: gahr@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: ports@freebsd.org, Alexander Leidinger , hackers@freebsd.org, current@freebsd.org, Julien Laffaye Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install 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, 25 Mar 2011 15:41:55 -0000 2011/3/25 Pietro Cerutti : > On 2011-Mar-25, 15:03, Julien Laffaye wrote: >> >>> What about DB corruption/loss? Do you keep the /var/db/pkg//xxx >> >>> files even with pkgng and only use the DB as a way to speed up some work >> >>> (so >> >>> the DB corruption just requires to run pkg2ng), or are you lost of the DB >> >>> is >> >>> lost? >> >>> >> >> >> >> Nothing is done about DB corruption/loss, I am not sure we need to do >> >> something. >> >> Maybe. >> > >> > I would say "for sure". Info: In Solaris 10 sqlite is used for the service >> > managenemt framework (SMF). It is possible that the DB is corrupt in some >> > bad situations. In this case you have to rebuild the DB (script provided, >> > been there, had to use it). >> >> If sqlite is properly used with transactions, it is very hard to >> corrupt the database. But if hardware lies to us and say that the data >> is on disk whereas it isnt... what can we do? >> Another potential problem is fsync(), but if it is broken on FreeBSD >> we want to fix it! >> >> BTW, the goal is to only have the database and not the flat files. >> If you are paranoid about power outage, use something like zfs snapshots... > > No need to look for strange scenarios, I'm surely going to sudo rm -f the file > more sooner than later, so... maybe just save a copy? > > -- > Pietro Cerutti > The FreeBSD Project > gahr@FreeBSD.org > > PGP Public Key: > http://gahr.ch/pgp > I think we can provide a periodic script activable by users (I let other decide if it has to be activated by default or not) that does a pkg backup /path/to/file/backup and xz it. because copying can be a huge. 40Mo for the database here, corresponding to 70Mo in the old format and to 600 packages. the dump xzed is only 3Mo regards, Bapt From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 13:50:58 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 80E65106564A; Fri, 25 Mar 2011 13:50:58 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 32F488FC17; Fri, 25 Mar 2011 13:50:57 +0000 (UTC) Received: from outgoing.leidinger.net (p5B1553A9.dip.t-dialin.net [91.21.83.169]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id D3822844017; Fri, 25 Mar 2011 14:50:52 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id CA2E8147C; Fri, 25 Mar 2011 14:50:48 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p2PDomXZ024202; Fri, 25 Mar 2011 14:50:48 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 25 Mar 2011 14:50:47 +0100 Message-ID: <20110325145047.13886kra3kep90w8@webmail.leidinger.net> Date: Fri, 25 Mar 2011 14:50:47 +0100 From: Alexander Leidinger To: Alexander Leidinger References: <20110325105213.53217afxpg1kj7s4@webmail.leidinger.net> <4D8C74F8.4010303@freebsd.org> <20110325141449.175625s5pqmtbrk0@webmail.leidinger.net> In-Reply-To: <20110325141449.175625s5pqmtbrk0@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: D3822844017.AC763 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.2, required 6, autolearn=disabled, J_CHICKENPOX_32 0.60, J_CHICKENPOX_52 0.60) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1301665854.21566@hhn4/ikeAERbTEcfwsQ2Ww X-EBL-Spam-Status: No X-Mailman-Approved-At: Fri, 25 Mar 2011 15:47:52 +0000 Cc: hackers@freebsd.org, Andriy Gapon Subject: Re: dtrace sdt problem: my fault or a generic problem (SYSINIT not working as expected for modules)? 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, 25 Mar 2011 13:50:58 -0000 Quoting Alexander Leidinger (from Fri, 25 Mar 2011 14:14:49 +0100): > Quoting Andriy Gapon (from Fri, 25 Mar 2011 > 12:56:56 +0200): > >> on 25/03/2011 11:52 Alexander Leidinger said the following: >>> As I read it, it looks a little bit like the SYSINIT of the SDT >>> probes didn't >>> work as expected for my new probes (does this work in modules? >>> fxr.watson.org >>> AFAICS only lists SDT probes in kernel-code, not in module-code), >>> a hit with the >>> clue-bat is welcome. >> >> My reading of the code is that all modules with SDT >> proivders/probes should be >> loaded before sdt module itself. >> SYSINIT in your module(s) works as expect, but dtrace_register() is >> not called >> on your SDT provider. See sys/cddl/dev/sdt/sdt.c for details: >> sdt_modevent -> >> sdt_load -> sdt_provider_listall(sdt_provider_reg_callback) -> >> dtrace_register. > > So if I load linux.ko before sdt.ko, or if I unload sdt.ko and > reload it, it should work? I'm going to try this after sending this > mail. Unloading sdt.ko was a bad idea... currently I'm waiting the machine recovers from this rude action. It seems there are some modunload checks missing to prevent a kernel panic by unloading sdt.ko when it is not safe. Do we have a place where we can document the current state of afairs, or shall I just add something to the wiki pages (the unload problem to the DTrace page and the load the module with SDT probes before the sdt.ko in the DTrace/HowToAddSDTProbes page)? Bye, Alexander. -- BOFH excuse #378: Operators killed by year 2000 bug bite http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 14:07:02 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 85A62106566C; Fri, 25 Mar 2011 14:07:02 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id C0C268FC1B; Fri, 25 Mar 2011 14:07:01 +0000 (UTC) Received: from outgoing.leidinger.net (p5B1553A9.dip.t-dialin.net [91.21.83.169]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 3CED9844017; Fri, 25 Mar 2011 15:06:57 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id E51001480; Fri, 25 Mar 2011 15:06:53 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p2PE6rms028319; Fri, 25 Mar 2011 15:06:53 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 25 Mar 2011 15:06:53 +0100 Message-ID: <20110325150653.21132ej6abxmjpgk@webmail.leidinger.net> Date: Fri, 25 Mar 2011 15:06:53 +0100 From: Alexander Leidinger To: Baptiste Daroussin References: <20110325101111.GA36840@azathoth.lan> In-Reply-To: <20110325101111.GA36840@azathoth.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 3CED9844017.AE190 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.077, required 6, autolearn=disabled, TW_KG 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1301666818.37353@xRZhXvU4vJZiIP5vNJ+yEA X-EBL-Spam-Status: No X-Mailman-Approved-At: Fri, 25 Mar 2011 15:48:07 +0000 Cc: ports@FreeBSD.org, hackers@FreeBSD.org, current@FreeBSD.org Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install 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, 25 Mar 2011 14:07:02 -0000 Quoting Baptiste Daroussin (from Fri, 25 Mar 2011 11:11:11 +0100): > pkgng is a binary package manager written from scratch for FreeBSD. I didn't had a look at it, just some comments about some parts you explained. > features supported are or will be : > - the register command can analyse elf files when registering a new port to > discover forgotten dependencies if necessary. (done in alpha using libelf) This will probably fail if LD_LIBRARY_PATH is used, or if we are installing linuxulator ports. > - new +MANIFEST (plist-like format) with new metadatas : options, arch, os > version, etc. (done in the alpha) > > - pkgng supports checking arch of the package which means that users > won't be able to install sparc64 binary package into amd64 machines. > (not done yet) > > - a special architecture "all" allows to specify when a package can be used > on every architecture. (not done yet) What if a package is able to install on a subset, e.g. the linuxulator ports are for amd64 and i386? > In term of technology we decided to use a sqlite3 database, and to > prevent potential trolling, sqlite3 is used in it's amalgamation form > which means it is incorporated in the code sources (as recommanded by > sqlite developpers like a statically linked library) on build we only > activate the features we need in sqlite. > > The alpha release come with an experimental tool "pkg2ng" to convert > an existing package database to the new pkgng database format. So one > can test pkgng without rebuild all its packages. What about DB corruption/loss? Do you keep the /var/db/pkg//xxx files even with pkgng and only use the DB as a way to speed up some work (so the DB corruption just requires to run pkg2ng), or are you lost of the DB is lost? Bye, Alexander. -- Real computer scientists don't comment their code. The identifiers are so long they can't afford the disk space. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 14:38:31 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 0F1981065677; Fri, 25 Mar 2011 14:38:31 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 64D708FC15; Fri, 25 Mar 2011 14:38:30 +0000 (UTC) Received: from outgoing.leidinger.net (p5B1553A9.dip.t-dialin.net [91.21.83.169]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 95AFF844017; Fri, 25 Mar 2011 15:38:23 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 933CD1485; Fri, 25 Mar 2011 15:38:20 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p2PEcF0U036113; Fri, 25 Mar 2011 15:38:15 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 25 Mar 2011 15:38:14 +0100 Message-ID: <20110325153814.20287h1594npcu80@webmail.leidinger.net> Date: Fri, 25 Mar 2011 15:38:14 +0100 From: Alexander Leidinger To: Baptiste Daroussin References: <20110325101111.GA36840@azathoth.lan> <20110325150653.21132ej6abxmjpgk@webmail.leidinger.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 95AFF844017.AFCC4 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.077, required 6, autolearn=disabled, TW_KG 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1301668706.98996@8dLvdr1UCaeNUw34HdkXtg X-EBL-Spam-Status: No X-Mailman-Approved-At: Fri, 25 Mar 2011 15:54:19 +0000 Cc: ports@freebsd.org, hackers@freebsd.org, current@freebsd.org Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install 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, 25 Mar 2011 14:38:31 -0000 Quoting Baptiste Daroussin (from Fri, 25 Mar 2011 15:14:52 +0100): > 2011/3/25 Alexander Leidinger : >> Quoting Baptiste Daroussin (from Fri, 25 Mar 2011 >> 11:11:11 +0100): >> >>> pkgng is a binary package manager written from scratch for FreeBSD. >> >> I didn't had a look at it, just some comments about some parts you >> explained. >> >>> features supported are or will be : >>> - a special architecture "all" allows to specify when a package can be >>> used >>> on every architecture. (not done yet) >> >> What if a package is able to install on a subset, e.g. the linuxulator ports >> are for amd64 and i386? >> > > No clue for that at the moment but we are open to suggestions. The suggestion is easy, allow a way to specify a set of valid architectures. >> What about DB corruption/loss? Do you keep the /var/db/pkg//xxx >> files even with pkgng and only use the DB as a way to speed up some work (so >> the DB corruption just requires to run pkg2ng), or are you lost of the DB is >> lost? >> > > Nothing is done about DB corruption/loss, I am not sure we need to > do something. > Maybe. I would say "for sure". Info: In Solaris 10 sqlite is used for the service managenemt framework (SMF). It is possible that the DB is corrupt in some bad situations. In this case you have to rebuild the DB (script provided, been there, had to use it). > Currently a filesystem corruption/loss on /var/db/pkg would do the same. Put a corruption of /var/db/pkg/xyz-1/+REQUIRED_BY would only affect a small part, and this part could be even recovered from (pkgdb from portupgrade is able to do it). > but it is sqlite so we can perhaps provide a way to get compressed > dump so user can periodically backup their database. It needs to be automated. Maybe periodic daily... but maybe this is not often enough after a day of a lot of changes (think about it this way: do you want to lose a day of changes?). The current FS based DB is very robust, partly because there is redundant data, pertly because losing a file just means that the very limited subset of information is lost (and a reinstall of one port will fix it). Bye, Alexander. -- Programming is an unnatural act. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 16:35:59 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 4BB9D1065673; Fri, 25 Mar 2011 16:35:59 +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 78CAA8FC08; Fri, 25 Mar 2011 16:35:57 +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 SAA16076; Fri, 25 Mar 2011 18:35:54 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4D8CC468.2000904@freebsd.org> Date: Fri, 25 Mar 2011 18:35:52 +0200 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: gahr@freebsd.org References: <20110325101111.GA36840@azathoth.lan> <20110325150653.21132ej6abxmjpgk@webmail.leidinger.net> <20110325153814.20287h1594npcu80@webmail.leidinger.net> <20110325153520.GB23861@gahrfit.gahr.ch> In-Reply-To: <20110325153520.GB23861@gahrfit.gahr.ch> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Baptiste Daroussin , current@freebsd.org, Julien Laffaye , ports@freebsd.org, hackers@freebsd.org, Alexander Leidinger Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install 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, 25 Mar 2011 16:35:59 -0000 on 25/03/2011 17:35 Pietro Cerutti said the following: > No need to look for strange scenarios, I'm surely going to sudo rm -f the file > more sooner than later, so... maybe just save a copy? I even can rm -rf / by accident. What's your solution to this? :) P.S. one solution would be a subcase of the other -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 17:22:58 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 98A7D106564A; Fri, 25 Mar 2011 17:22:58 +0000 (UTC) (envelope-from lists@eitanadler.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 25C2A8FC1F; Fri, 25 Mar 2011 17:22:57 +0000 (UTC) Received: by iyj12 with SMTP id 12so1616472iyj.13 for ; Fri, 25 Mar 2011 10:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OxrwXRYrPrkHDXM5haH/Yh/iufSUuRlynTv5ePqaZuQ=; b=OaEn27yskrlJDrVVRProoUbza81ccZgbU3JccwHdWLHhh53/bnB4cSKZWtgPfQtYoD Pr42hlAGSH+H+ohmiDpH5LNoaJilyrhMzySYKi3c57LWSUU+EPJ5gSPPDgKoai9+0NLK nhe0a/0Z9FtJKSc6/VyBpFQAHMnCx42v0rHVA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=QqRVPVxucdztC5aqCt8BT+SKLmORLzisZRGgk/3KOMEMfd9kNCdzVcoEP/3RZY7CHF XNzGnT0+8QuiDrUob1wym1jzlUorJ6wg11lP/qj7+voCqcmIik36OPJQu+dUE2e6RHM/ M+d40xNJgT9VFLhSlS3YuWRLsWbp88K/0Nx9c= Received: by 10.43.58.14 with SMTP id wi14mr1576910icb.396.1301072275460; Fri, 25 Mar 2011 09:57:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.153.197 with HTTP; Fri, 25 Mar 2011 09:54:35 -0700 (PDT) In-Reply-To: <4D8CC468.2000904@freebsd.org> References: <20110325101111.GA36840@azathoth.lan> <20110325150653.21132ej6abxmjpgk@webmail.leidinger.net> <20110325153814.20287h1594npcu80@webmail.leidinger.net> <20110325153520.GB23861@gahrfit.gahr.ch> <4D8CC468.2000904@freebsd.org> From: Eitan Adler Date: Fri, 25 Mar 2011 11:54:35 -0500 Message-ID: To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: Baptiste Daroussin , current@freebsd.org, Julien Laffaye , ports@freebsd.org, hackers@freebsd.org, gahr@freebsd.org, Alexander Leidinger Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install 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, 25 Mar 2011 17:22:58 -0000 On Fri, Mar 25, 2011 at 11:35 AM, Andriy Gapon wrote: > on 25/03/2011 17:35 Pietro Cerutti said the following: >> No need to look for strange scenarios, I'm surely going to sudo rm -f the file >> more sooner than later, so... maybe just save a copy? > > I even can rm -rf / by accident. > What's your solution to this? :) rm -rf / rm: "/" may not be removed -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 18:39:11 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 D6084106564A for ; Fri, 25 Mar 2011 18:39:11 +0000 (UTC) (envelope-from lichray@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 86A548FC12 for ; Fri, 25 Mar 2011 18:39:11 +0000 (UTC) Received: by qwc9 with SMTP id 9so895953qwc.13 for ; Fri, 25 Mar 2011 11:39:10 -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=uuOm5j+VfOtOQJxzDLE8SXWUU6o3ltIIL2MQh1Y0TdY=; b=mE8yb7O0kNbeT6IbzxEmQ29eMG6FYomBHt0SwhPp3ezb19HoHR49oETrD5WShxvk+D iXcB4SKgrltLOck5rtxNeyk9mCqwRGwxiLhLw+o6gFD9leu579bDGlNlTlqe652hVBUG S2YMK5zgRpSX+n/+t8yBkHr2YNpwYhn4C/Akk= 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=c5H4+ZUUTNBtdsS5BIaiEsyVdMGWbAPF39p5Dn4TF6nzCPB4AJeOSPYz0H47fRe9jx YKjSyWg10vKfKJWlpjhkz2MaXeSZKvtEvAl8t1EYDvnsj1WPUqypSlHXTU9jWBNTe08y mkm4DqBJcxa+A3scmqri/gAClYQr6PIkfspvk= MIME-Version: 1.0 Received: by 10.224.41.11 with SMTP id m11mr976684qae.155.1301078350759; Fri, 25 Mar 2011 11:39:10 -0700 (PDT) Received: by 10.224.20.19 with HTTP; Fri, 25 Mar 2011 11:39:10 -0700 (PDT) In-Reply-To: <20110325134537.GB21904@pix.net> References: <20110324111118.GF65750@cicely7.cicely.de> <20110324221757.GA20441@mud.stack.nl> <20110325094044.GA41319@mud.stack.nl> <20110325134537.GB21904@pix.net> Date: Fri, 25 Mar 2011 13:39:10 -0500 Message-ID: From: Zhihao Yuan To: Kurt Lidl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Johan van Selst , Arnaud Lacombe , freebsd-hackers@freebsd.org, Bernd Walter , Pan Tsu , ticso@cicely.de Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 25 Mar 2011 18:39:12 -0000 On Fri, Mar 25, 2011 at 8:45 AM, Kurt Lidl wrote: > On Fri, Mar 25, 2011 at 10:40:44AM +0100, Johan van Selst wrote: >> Zhihao Yuan wrote: >> > > Could you please eleborate on the nvi-devel problems? I'm the curren= t >> > > maintainer of this port, and as far as I know it's fully functional. >> > 1. It does not support non-Unicode encodings. Actually, these >> > encodings are mainstream in multi-byte encodings world. A proper >> > iconv-awared implementation should be able to handle all of the >> > encodings in `iconv -l`; >> > 2. It depends on DB3/4. We won't accept DB3/4 in base system and we >> > won't accept nvi-devel. >> > 3. It's not 100% compatible with nvi 1.79. >> >> Thank you for explaining. Indeed, all valid points and I fully agree >> that nvi-devel is not fit for inclusion in base as it is. In fact, the >> nvi from base is probably a better starting point (than nvi-devel) to >> create an editor that is fully compatible with nvi 1.79 and supports all >> multi-byte encodings. And when you, or someone, else creates such an >> editor, I will be pleased to remove the obsoleted port of nvi-devel. > > Has anyone looked at the nvi work that has taken place in NetBSD > in the last year or so? I have checked that. It's just a latest nvi 1.85. > > I think they've put in a bunch of wide character support. =C2=A0I'm not > sure if their DB code relies on bdb newer than what is in libc or not. > > -Kurt > --=20 Zhihao Yuan The best way to predict the future is to invent it. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 18:47: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 9475A106566B; Fri, 25 Mar 2011 18:47:09 +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 510078FC08; Fri, 25 Mar 2011 18:47:09 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63] (may be forged)) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id p2PIZDK8050088; Fri, 25 Mar 2011 12:35:14 -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: <20110325024658.GA19544@freebsd.org> Date: Fri, 25 Mar 2011 12:35:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <336A9ACD-29BF-41C9-BC25-917CC1E4587D@bsdimp.com> References: <20110325002115.GA323@freebsd.org> <20110325015508.GA14565@freebsd.org> <20110325024658.GA19544@freebsd.org> To: Alexander Best X-Mailer: Apple Mail (2.1082) Cc: freebsd-hackers@FreeBSD.org Subject: Re: Switching to [KMGTPE]i prefixes? 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, 25 Mar 2011 18:47:09 -0000 One difference between this patch, and the patch I came up with, was = that I used arrays of character pointers to the names of the symbols to = use. This got around the problem that you have with the 'shift' you had = to introduce to get things more or less correct. It also made for the = possibility of having different kinds of units in the future that = weren't a power of 2 -1 bytes long. It also simplified the code a = little. Perhaps you would consider this improvement when devising future = patches. Warner On Mar 24, 2011, at 8:46 PM, Alexander Best wrote: > here is a revised patch. it also includes the necessary changes to the > humanize_number(3) man page. >=20 > cheers. > alex >=20 > --=20 > a13x > _______________________________________________ > 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 Mar 25 19:53:26 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 0BB76106566C; Fri, 25 Mar 2011 19:53:26 +0000 (UTC) Date: Fri, 25 Mar 2011 19:53:26 +0000 From: Alexander Best To: Warner Losh Message-ID: <20110325195325.GA69264@freebsd.org> References: <20110325002115.GA323@freebsd.org> <20110325015508.GA14565@freebsd.org> <20110325024658.GA19544@freebsd.org> <336A9ACD-29BF-41C9-BC25-917CC1E4587D@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <336A9ACD-29BF-41C9-BC25-917CC1E4587D@bsdimp.com> Cc: freebsd-hackers@FreeBSD.org Subject: Re: Switching to [KMGTPE]i prefixes? 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, 25 Mar 2011 19:53:26 -0000 On Fri Mar 25 11, Warner Losh wrote: > One difference between this patch, and the patch I came up with, was that I used arrays of character pointers to the names of the symbols to use. This got around the problem that you have with the 'shift' you had to introduce to get things more or less correct. It also made for the possibility of having different kinds of units in the future that weren't a power of 2 -1 bytes long. It also simplified the code a little. > > Perhaps you would consider this improvement when devising future patches. would you mind sharing your patch or pinpoint me to the according thread? cheers. alex > > Warner > > > On Mar 24, 2011, at 8:46 PM, Alexander Best wrote: > > > here is a revised patch. it also includes the necessary changes to the > > humanize_number(3) man page. > > > > cheers. > > alex > > > > -- > > a13x > > _______________________________________________ > > 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" -- a13x From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 19:49:02 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 0991B106564A; Fri, 25 Mar 2011 19:49:01 +0000 (UTC) (envelope-from dickey@saltmine.radix.net) Received: from saltmine.radix.net (saltmine.radix.net [207.192.128.40]) by mx1.freebsd.org (Postfix) with ESMTP id 802B08FC0C; Fri, 25 Mar 2011 19:49:01 +0000 (UTC) Received: from saltmine.radix.net (localhost [127.0.0.1]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id p2PJWisw009337; Fri, 25 Mar 2011 15:32:44 -0400 (EDT) Received: (from dickey@localhost) by saltmine.radix.net (8.12.2/8.12.2/Submit) id p2PJWdar009336; Fri, 25 Mar 2011 15:32:39 -0400 (EDT) Date: Fri, 25 Mar 2011 15:32:39 -0400 From: Thomas Dickey To: Eitan Adler Message-ID: <20110325193239.GA8697@saltmine.radix.net> References: <20110325101111.GA36840@azathoth.lan> <20110325150653.21132ej6abxmjpgk@webmail.leidinger.net> <20110325153814.20287h1594npcu80@webmail.leidinger.net> <20110325153520.GB23861@gahrfit.gahr.ch> <4D8CC468.2000904@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Mailman-Approved-At: Fri, 25 Mar 2011 20:00:39 +0000 Cc: ports@freebsd.org, hackers@freebsd.org, current@freebsd.org, gahr@freebsd.org Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install 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, 25 Mar 2011 19:49:02 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 25, 2011 at 11:54:35AM -0500, Eitan Adler wrote: > On Fri, Mar 25, 2011 at 11:35 AM, Andriy Gapon wrote: > > on 25/03/2011 17:35 Pietro Cerutti said the following: > >> No need to look for strange scenarios, I'm surely going to sudo rm -f = the file > >> more sooner than later, so... maybe just save a copy? > > > > I even can rm -rf / by accident. > > What's your solution to this? :) >=20 > rm -rf / > rm: "/" may not be removed referring to the CVS, this should improve the approach. cd /tmp rm -rf ../* ymmv --=20 Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQFNjO3VtIqByHxlDocRAu57AJ9sXU3nCRc2b3DBQvdXWxDPeOpOewCgl3Xo aT66X/ALGG9KVd/cEWIBvFc= =uGvx -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 20:14:47 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 EA1C6106566B; Fri, 25 Mar 2011 20:14:46 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 593958FC1B; Fri, 25 Mar 2011 20:14:46 +0000 (UTC) Received: from outgoing.leidinger.net (p5B1553A9.dip.t-dialin.net [91.21.83.169]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id DAB80844017; Fri, 25 Mar 2011 21:14:41 +0100 (CET) Received: from unknown (IO.Leidinger.net [192.168.2.110]) by outgoing.leidinger.net (Postfix) with ESMTP id 0121614A9; Fri, 25 Mar 2011 21:14:38 +0100 (CET) Date: Fri, 25 Mar 2011 21:14:39 +0100 From: Alexander Leidinger To: gahr@freebsd.org Message-ID: <20110325211439.00004dda@unknown> In-Reply-To: <20110325153520.GB23861@gahrfit.gahr.ch> References: <20110325101111.GA36840@azathoth.lan> <20110325150653.21132ej6abxmjpgk@webmail.leidinger.net> <20110325153814.20287h1594npcu80@webmail.leidinger.net> <20110325153520.GB23861@gahrfit.gahr.ch> X-Mailer: Claws Mail 3.7.8cvs47 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: DAB80844017.A081C X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.846, required 6, autolearn=disabled, ALL_TRUSTED -1.00, TW_KG 0.08, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1301688882.63594@6X9bXvURTkigw9HJYLbInA X-EBL-Spam-Status: No X-Mailman-Approved-At: Fri, 25 Mar 2011 20:33:52 +0000 Cc: Baptiste, current@freebsd.org, Julien Laffaye , Daroussin , ports@freebsd.org, hackers@freebsd.org Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install 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, 25 Mar 2011 20:14:47 -0000 On Fri, 25 Mar 2011 16:35:21 +0100 Pietro Cerutti wrote: > On 2011-Mar-25, 15:03, Julien Laffaye wrote: > > >>> What about DB corruption/loss? Do you keep > > >>> the /var/db/pkg//xxx files even with pkgng and only > > >>> use the DB as a way to speed up some work (so > > >>> the DB corruption just requires to run pkg2ng), or are you lost > > >>> of the DB is > > >>> lost? > > >>> > > >> > > >> Nothing is done about DB corruption/loss, I am not sure we need > > >> to do something. > > >> Maybe. > > > > > > I would say "for sure". Info: In Solaris 10 sqlite is used for > > > the service managenemt framework (SMF). It is possible that the > > > DB is corrupt in some bad situations. In this case you have to > > > rebuild the DB (script provided, been there, had to use it). > > > > If sqlite is properly used with transactions, it is very hard to > > corrupt the database. But if hardware lies to us and say that the And as I told above, I even had such a case (more than once), and the hardware was not buggy. What do you want to tell in this case, "life sucks, reinstall everything"? > > data is on disk whereas it isnt... what can we do? Sometimes you have to stay with broken hardware. > > Another potential problem is fsync(), but if it is broken on FreeBSD > > we want to fix it! > > > > BTW, the goal is to only have the database and not the flat files. > > If you are paranoid about power outage, use something like zfs > > snapshots... There are more FS than only ZFS (personally I use ZFS, and I have snapshots, but this is not a good solution for this problem). As I told already, if it isn't automatic, nearly nobody will use it. And the package management stuff has to be automatic, no freshman will think about setting up a snapshot script when he starts to use packages/ports. > No need to look for strange scenarios, I'm surely going to sudo rm -f > the file more sooner than later, so... maybe just save a copy? A copy or two would be enough, but it has to be done automatically, and once a day is not enough. A copy after each X modifications maybe (for suitable definitions of X and 'modifications'). Bye, Alexander. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 20:46:57 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 001841065670; Fri, 25 Mar 2011 20:46:56 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5645E8FC1D; Fri, 25 Mar 2011 20:46:55 +0000 (UTC) Received: by yxl31 with SMTP id 31so703605yxl.13 for ; Fri, 25 Mar 2011 13:46:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.13.11 with SMTP id q11mr1414657ybi.272.1301084664953; Fri, 25 Mar 2011 13:24:24 -0700 (PDT) Received: by 10.150.143.9 with HTTP; Fri, 25 Mar 2011 13:24:24 -0700 (PDT) Received: by 10.150.143.9 with HTTP; Fri, 25 Mar 2011 13:24:24 -0700 (PDT) Date: Fri, 25 Mar 2011 13:24:24 -0700 Message-ID: From: Jos Backus To: Alexander Leidinger Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Daroussin , current@freebsd.org, Julien Laffaye , ports@freebsd.org, hackers@freebsd.org, gahr@freebsd.org, Baptiste@freebsd.org Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install 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, 25 Mar 2011 20:46:57 -0000 As far as package managers go, yum, which is used widely, uses SQLite. -- Peace cannot be achieved through violence, it can only be attained through understanding. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 21:13:06 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 CEE7F1065674; Fri, 25 Mar 2011 21:13:06 +0000 (UTC) (envelope-from yanegomi@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 BB2308FC1D; Fri, 25 Mar 2011 21:13:05 +0000 (UTC) Received: by wyf23 with SMTP id 23so1660440wyf.13 for ; Fri, 25 Mar 2011 14:13:04 -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=cUnF30A0EiLnPiiKXB5G6jlDPdyudcLaEK7bevmXRFQ=; b=A1ezVe+GKW7IOEhYg2qyMXgNcQlo3ClnlM8A08uIqnk5CE/5RlcXJ3IOJs5U4t+UhF VgRer4r9yZDWeJ5+zal3ts61+qtKKWe9aGNPxT6tovYqR3XnWYMh2NV31Y5eqFpPCxBq g1I9SQ3wNuXWOfYNupRafPc170L0UgKbm0XKA= 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=UyXO6GCdmv0L5MS74jNS2SxWJd7vAaF2XV710xxa4n/hM3FRfKDapdWUvqa6dvu/30 0j1TjnjNZZsPorvz243K5hu+JXFm8fntsyDUfpKvYvx4gYjU9Zsw0S+JAYq1VPUDVmBt NHITgi+vxqBfyhUUhCpHu6rXjCpxdp24L+Kyw= MIME-Version: 1.0 Received: by 10.217.7.66 with SMTP id z44mr919649wes.100.1301086033606; Fri, 25 Mar 2011 13:47:13 -0700 (PDT) Received: by 10.216.173.142 with HTTP; Fri, 25 Mar 2011 13:47:13 -0700 (PDT) In-Reply-To: <20110325211439.00004dda@unknown> References: <20110325101111.GA36840@azathoth.lan> <20110325150653.21132ej6abxmjpgk@webmail.leidinger.net> <20110325153814.20287h1594npcu80@webmail.leidinger.net> <20110325153520.GB23861@gahrfit.gahr.ch> <20110325211439.00004dda@unknown> Date: Fri, 25 Mar 2011 13:47:13 -0700 Message-ID: From: Garrett Cooper To: Alexander Leidinger Content-Type: text/plain; charset=ISO-8859-1 Cc: Daroussin , current@freebsd.org, Julien Laffaye , ports@freebsd.org, hackers@freebsd.org, gahr@freebsd.org, Baptiste@freebsd.org Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install 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, 25 Mar 2011 21:13:06 -0000 On Fri, Mar 25, 2011 at 1:14 PM, Alexander Leidinger wrote: > On Fri, 25 Mar 2011 16:35:21 +0100 Pietro Cerutti > wrote: > >> On 2011-Mar-25, 15:03, Julien Laffaye wrote: >> > >>> What about DB corruption/loss? Do you keep >> > >>> the /var/db/pkg//xxx files even with pkgng and only >> > >>> use the DB as a way to speed up some work (so >> > >>> the DB corruption just requires to run pkg2ng), or are you lost >> > >>> of the DB is >> > >>> lost? >> > >>> >> > >> >> > >> Nothing is done about DB corruption/loss, I am not sure we need >> > >> to do something. >> > >> Maybe. >> > > >> > > I would say "for sure". Info: In Solaris 10 sqlite is used for >> > > the service managenemt framework (SMF). It is possible that the >> > > DB is corrupt in some bad situations. In this case you have to >> > > rebuild the DB (script provided, been there, had to use it). >> > >> > If sqlite is properly used with transactions, it is very hard to >> > corrupt the database. But if hardware lies to us and say that the > > And as I told above, I even had such a case (more than once), and the > hardware was not buggy. What do you want to tell in this case, "life > sucks, reinstall everything"? If you use binary packages, pulling down everything should be trivial, fast, and easy to install. If you're using ports, well then things are going to be slow as expected. >> > data is on disk whereas it isnt... what can we do? > > Sometimes you have to stay with broken hardware. Sometimes you have to go buy new parts? Playing with broken hardware is like playing with fire -- sometimes you'll get burned if it goes out of commission during critical operations. I would be more concerned about overall system operation than having a packaging system that can handle all error conditions that should be rightfully handled by various kernel subsystems. If the kernel's doing it's job, then the packaging manager can do its job as well. >> > Another potential problem is fsync(), but if it is broken on FreeBSD >> > we want to fix it! >> > >> > BTW, the goal is to only have the database and not the flat files. >> > If you are paranoid about power outage, use something like zfs >> > snapshots... > > There are more FS than only ZFS (personally I use ZFS, and I have > snapshots, but this is not a good solution for this problem). A lot of filesystems feature snapshot'ing, including UFS. If you aren't smart enough to back up your data you're toast if the data is gone. I would be more concerned about the program getting killed, not getting properly cleaned up, etc as this is something that the package manager frontend (or whatever the official name is) should catch and fail gracefully with. Things need to follow an ACID methodology and be recoverable in the event that it can't be ACID, or it's no better than pkg_install/ports currently is if it's caught in the middle of a critical operation today installing or removing software. If SQLite can't deliver this level of ACID-like capability, then pkg_install needs to be redesigned. > As I told already, if it isn't automatic, nearly nobody will use it. > And the package management stuff has to be automatic, no freshman will > think about setting up a snapshot script when he starts to use > packages/ports. I'd just provide an export command to print out a (JSON?) version of the information, and move on. None of the other major packaging systems out there that I know of use flat files for this data, and I would rather not make it automatic because it's an unnecessary performance hit. If the user feels the need for backing up his/her data they will. If not, they're SoL in the event of a crash. >> No need to look for strange scenarios, I'm surely going to sudo rm -f >> the file more sooner than later, so... maybe just save a copy? > > A copy or two would be enough, but it has to be done automatically, and > once a day is not enough. A copy after each X modifications maybe > (for suitable definitions of X and 'modifications'). Please see my comment above. There's no reason why this belongs in a packaging system (you can add it as an external tool, but the point is to avoid architectural mistakes that leaked into the old pkg_install over the period of 10 years or so). Thanks, -Garrett PS Sorry for being so hardnosed on this, but I want something that's fast and correct, instead of something bloated, slow, half-baked, harder to test, etc. pkg_install gets executed enough times during a port upgrade that having something more streamlined for most usecases is the only way to go, and there's enough code that doesn't get executed on a regular basis that has no business being in pkg_install. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 21:38:15 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 D50FA106564A; Fri, 25 Mar 2011 21:38:15 +0000 (UTC) (envelope-from baptiste.daroussin@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 80DF28FC16; Fri, 25 Mar 2011 21:38:15 +0000 (UTC) Received: by iwn33 with SMTP id 33so1854367iwn.13 for ; Fri, 25 Mar 2011 14:38:15 -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:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=LVt6khElnWGe2uvyM7HMMDcWeSApzX+tShzbin8l4tA=; b=ffZoG2mQfPhBTfYrfEyUSpD701xiagPdx5jr8a7tDeC/cGht/CMsGywOfKAxcLifkF 7l/EyjtrSrn709+UzqFH5uTvIxplLBbVAd3r7lUYw++wqPqJtW9GoSPM2Q4BvrreeQJ5 Z0CrE9ViEb0P3x8EmCkDYiK7d2LXelxm1cJmg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=OqBuj/NdJnQcxeh4Ee3eA/9OQqkq18+2dIyqzCZV1ZwMFY1ZaR/Q8YZMQDfMOv4xj+ NKS6DLhNGbf5Kna0fTSPDtdCjvTGQtq8iAbMW7wNfpFZNBlHNUJSf6397wbRBfNKHYX7 Gj/PdRUJPT09TrgygzV8Xtqn1H9Kr/RJXqy88= Received: by 10.43.64.18 with SMTP id xg18mr1946907icb.144.1301089095084; Fri, 25 Mar 2011 14:38:15 -0700 (PDT) MIME-Version: 1.0 Sender: baptiste.daroussin@gmail.com Received: by 10.231.182.76 with HTTP; Fri, 25 Mar 2011 14:37:55 -0700 (PDT) In-Reply-To: <4D8D09C2.2050500@rawbw.com> References: <20110325101111.GA36840@azathoth.lan> <4D8D09C2.2050500@rawbw.com> From: Baptiste Daroussin Date: Fri, 25 Mar 2011 21:37:55 +0000 X-Google-Sender-Auth: zRLDz9bdAAO1hVXm0d9bcUeN6RQ Message-ID: To: Yuri Content-Type: text/plain; charset=ISO-8859-1 Cc: ports@freebsd.org, hackers@freebsd.org, current@freebsd.org Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install 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, 25 Mar 2011 21:38:15 -0000 2011/3/25 Yuri : > On 03/25/2011 03:11, Baptiste Daroussin wrote: >> >> Julien Laffaye (jlaffaye@) and I, helped by Philippe Pepiot (huge >> contributor) have been working since the end of the last GSoC on a >> rewrite of pkg_install. >> >> pkgng is a binary package manager written from scratch for FreeBSD. >> > > How does it relate to portmaster and portupgrade packages, which both have > (or include) supposedly the same functionality? > > Yuri > both have to be adapted, portupgrade throught maybe some ruby bindings to libpkg, portmaster by patching it to use pkg frontend instead of pkg_* tools (as I did for the ports (see ports/bsd.pkgng.mk in the git tree) regards, Bapt From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 21:53: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 66C4C106566B; Fri, 25 Mar 2011 21:53:25 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id E52308FC26; Fri, 25 Mar 2011 21:53:24 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p2PLRX0C034367; Fri, 25 Mar 2011 14:27:33 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4D8D09C2.2050500@rawbw.com> Date: Fri, 25 Mar 2011 14:31:46 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101211 Thunderbird/3.0.11 MIME-Version: 1.0 To: Baptiste Daroussin References: <20110325101111.GA36840@azathoth.lan> In-Reply-To: <20110325101111.GA36840@azathoth.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, hackers@freebsd.org, current@freebsd.org Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install 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, 25 Mar 2011 21:53:25 -0000 On 03/25/2011 03:11, Baptiste Daroussin wrote: > Julien Laffaye (jlaffaye@) and I, helped by Philippe Pepiot (huge > contributor) have been working since the end of the last GSoC on a > rewrite of pkg_install. > > pkgng is a binary package manager written from scratch for FreeBSD. > How does it relate to portmaster and portupgrade packages, which both have (or include) supposedly the same functionality? Yuri From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 21:56: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 1331C106564A; Fri, 25 Mar 2011 21:56:40 +0000 (UTC) (envelope-from delphij@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 BDEE98FC0C; Fri, 25 Mar 2011 21:56:39 +0000 (UTC) Received: by iwn33 with SMTP id 33so1871703iwn.13 for ; Fri, 25 Mar 2011 14:56: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=5dPbtWdrPVne85fZJZILh5tV9Igg5+Ube2IS2JzzonM=; b=jJqjw9MgZ3BJA51JokQRxhnkjpycjDmqj5zw/8D1caSF4cDKmM0YvIOKgNHNaEVZhx YQiZ89KAjoUQVpmzI0C8d2HBjr11vIG65hKXJkQa05jzDDB0xOnMvcMBCTIl9FJRO+4D /p+z6GL/dfnc1mpwxxPhS5zNhsbvB/U32qVIY= 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=V3Fg7DorikoNHB5plecQa0NqQBNtJQQ72KCacecNVosMaL2I7FdL7yrThPwV50TQjK vKTKuI3IwY5w1G80Od0EeiyjG63StYHPKPmjhue03hhqBLxmdZvwGrZ4F3Tykbt7/Pv8 moGNFNJi+3uWRv64cjNrJpWfwQX1bUm+I5V/4= MIME-Version: 1.0 Received: by 10.231.197.27 with SMTP id ei27mr1196649ibb.198.1301088786221; Fri, 25 Mar 2011 14:33:06 -0700 (PDT) Received: by 10.231.143.209 with HTTP; Fri, 25 Mar 2011 14:33:06 -0700 (PDT) In-Reply-To: <20110325195325.GA69264@freebsd.org> References: <20110325002115.GA323@freebsd.org> <20110325015508.GA14565@freebsd.org> <20110325024658.GA19544@freebsd.org> <336A9ACD-29BF-41C9-BC25-917CC1E4587D@bsdimp.com> <20110325195325.GA69264@freebsd.org> Date: Fri, 25 Mar 2011 14:33:06 -0700 Message-ID: From: Xin LI To: Alexander Best Content-Type: multipart/mixed; boundary=00032556582eec92cd049f555622 Cc: freebsd-hackers@freebsd.org Subject: Re: Switching to [KMGTPE]i prefixes? 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, 25 Mar 2011 21:56:40 -0000 --00032556582eec92cd049f555622 Content-Type: text/plain; charset=UTF-8 FYI I have a patch and I have incorporated some of Alexander's idea. Difference: - Use of both HN_DIVISOR_1000 and HN_IEC_PREFIXES triggers an assertion. I think it doesn't make sense to return since this is an API violation and we should just tell the caller explicitly; - DIVISOR_1000 and !1000 cases use just same prefixes, so merge them while keeping divisor intact; - Make prefixes table consistently long. I have no strong opinion on this one, though, it's just what my original version used and I can change it to the way Alexander did if there is an advantage of doing that way. (Note, it seems that we use HN_ prefix for both 'scale' and 'flags', I have sorted them by value but HN_IEC_PREFIXES should really belong to the flags group). Cheers, -- Xin LI http://www.delphij.net --00032556582eec92cd049f555622 Content-Type: text/x-patch; charset=US-ASCII; name="humanize_number.c.diff" Content-Disposition: attachment; filename="humanize_number.c.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_glpmfu710 SW5kZXg6IGh1bWFuaXplX251bWJlci5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGh1bWFuaXplX251bWJlci5j CShyZXZpc2lvbiAyMjAwMDkpCisrKyBodW1hbml6ZV9udW1iZXIuYwkod29ya2luZyBjb3B5KQpA QCAtNTQsMjkgKzU0LDMxIEBACiAJYXNzZXJ0KGJ1ZiAhPSBOVUxMKTsKIAlhc3NlcnQoc3VmZml4 ICE9IE5VTEwpOwogCWFzc2VydChzY2FsZSA+PSAwKTsKKwlhc3NlcnQoISgoZmxhZ3MgJiBITl9E SVZJU09SXzEwMDApICYmIChmbGFncyAmIEhOX0lFQ19QUkVGSVhFUykpKTsKIAogCXJlbWFpbmRl ciA9IDA7CiAKLQlpZiAoZmxhZ3MgJiBITl9ESVZJU09SXzEwMDApIHsKLQkJLyogU0kgZm9yIGRl Y2ltYWwgbXVsdGlwbGllcyAqLwotCQlkaXZpc29yID0gMTAwMDsKKwlpZiAoZmxhZ3MgJiBITl9J RUNfUFJFRklYRVMpIHsKKwkJYmFzZWxlbiA9IDI7CisJCWRpdmlzb3IgPSAxMDI0OwogCQlpZiAo ZmxhZ3MgJiBITl9CKQotCQkJcHJlZml4ZXMgPSAiQlwwa1wwTVwwR1wwVFwwUFwwRSI7CisJCQlw cmVmaXhlcyA9ICJCXDBcMEtpXDBNaVwwR2lcMFRpXDBQaVwwRWkiOwogCQllbHNlCi0JCQlwcmVm aXhlcyA9ICJcMFwwa1wwTVwwR1wwVFwwUFwwRSI7CisJCQlwcmVmaXhlcyA9ICJcMFwwS2lcME1p XDBHaVwwVGlcMFBpXDBFaSI7CiAJfSBlbHNlIHsKLQkJLyoKLQkJICogYmluYXJ5IG11bHRpcGxp ZXMKLQkJICogWFhYIElFQyA2MDAyNy0yIHJlY29tbWVuZHMgS2ksIE1pLCBHaS4uLgotCQkgKi8K LQkJZGl2aXNvciA9IDEwMjQ7CisJCWJhc2VsZW4gPSAxOworCQlpZiAoZmxhZ3MgJiBITl9ESVZJ U09SXzEwMDApCisJCQlkaXZpc29yID0gMTAwMDsKKwkJZWxzZQorCQkJZGl2aXNvciA9IDEwMjQ7 CisKIAkJaWYgKGZsYWdzICYgSE5fQikKLQkJCXByZWZpeGVzID0gIkJcMEtcME1cMEdcMFRcMFBc MEUiOworCQkJcHJlZml4ZXMgPSAiQlwwXDBrXDBcME1cMFwwR1wwXDBUXDBcMFBcMFwwRSI7CiAJ CWVsc2UKLQkJCXByZWZpeGVzID0gIlwwXDBLXDBNXDBHXDBUXDBQXDBFIjsKKwkJCXByZWZpeGVz ID0gIlwwXDBcMGtcMFwwTVwwXDBHXDBcMFRcMFwwUFwwXDBFIjsKIAl9CiAKLSNkZWZpbmUJU0NB TEUyUFJFRklYKHNjYWxlKQkoJnByZWZpeGVzWyhzY2FsZSkgPDwgMV0pCisjZGVmaW5lCVNDQUxF MlBSRUZJWChzY2FsZSkJKCZwcmVmaXhlc1soc2NhbGUpICogM10pCiAJbWF4c2NhbGUgPSA3Owog CiAJaWYgKHNjYWxlID49IG1heHNjYWxlICYmCkBAIC05MSwxMCArOTMsMTAgQEAKIAlpZiAocXVv dGllbnQgPCAwKSB7CiAJCXNpZ24gPSAtMTsKIAkJcXVvdGllbnQgPSAtcXVvdGllbnQ7Ci0JCWJh c2VsZW4gPSAzOwkJLyogc2lnbiwgZGlnaXQsIHByZWZpeCAqLworCQliYXNlbGVuICs9IDI7CQkv KiBzaWduLCBkaWdpdCAqLwogCX0gZWxzZSB7CiAJCXNpZ24gPSAxOwotCQliYXNlbGVuID0gMjsJ CS8qIGRpZ2l0LCBwcmVmaXggKi8KKwkJYmFzZWxlbiArPSAxOwkJLyogZGlnaXQgKi8KIAl9CiAJ aWYgKGZsYWdzICYgSE5fTk9TUEFDRSkKIAkJc2VwID0gIiI7CkluZGV4OiBsaWJ1dGlsLmgKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQotLS0gbGlidXRpbC5oCShyZXZpc2lvbiAyMjAwMDkpCisrKyBsaWJ1dGlsLmgJKHdv cmtpbmcgY29weSkKQEAgLTIyMyw2ICsyMjMsNyBAQAogCiAjZGVmaW5lIEhOX0dFVFNDQUxFCQkw eDEwCiAjZGVmaW5lIEhOX0FVVE9TQ0FMRQkJMHgyMAorI2RlZmluZSBITl9JRUNfUFJFRklYRVMJ CTB4NDAKIAogLyogaGV4ZHVtcCgzKSAqLwogI2RlZmluZQlIRF9DT0xVTU5fTUFTSwkJMHhmZgo= --00032556582eec92cd049f555622-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 21:52:54 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 1A2841065674; Fri, 25 Mar 2011 21:52:54 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5A66A8FC15; Fri, 25 Mar 2011 21:52:53 +0000 (UTC) Received: from outgoing.leidinger.net (p5B1553A9.dip.t-dialin.net [91.21.83.169]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id CBA98844015; Fri, 25 Mar 2011 22:52:47 +0100 (CET) Received: from unknown (IO.Leidinger.net [192.168.2.110]) by outgoing.leidinger.net (Postfix) with ESMTP id 16C3414B8; Fri, 25 Mar 2011 22:52:45 +0100 (CET) Date: Fri, 25 Mar 2011 22:52:44 +0100 From: Alexander Leidinger To: Garrett Cooper Message-ID: <20110325225244.00002d0b@unknown> In-Reply-To: References: <20110325101111.GA36840@azathoth.lan> <20110325150653.21132ej6abxmjpgk@webmail.leidinger.net> <20110325153814.20287h1594npcu80@webmail.leidinger.net> <20110325153520.GB23861@gahrfit.gahr.ch> <20110325211439.00004dda@unknown> X-Mailer: Claws Mail 3.7.8cvs47 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: CBA98844015.A31C5 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.246, required 6, autolearn=disabled, ALL_TRUSTED -1.00, J_CHICKENPOX_83 0.60, TW_KG 0.08, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1301694769.72701@Md6/OUcK4PqKvfQn1p4k8w X-EBL-Spam-Status: No X-Mailman-Approved-At: Fri, 25 Mar 2011 22:24:33 +0000 Cc: current@freebsd.org, Daroussin , Julien, Laffaye , ports@freebsd.org, hackers@freebsd.org, gahr@freebsd.org, Baptiste@freebsd.org Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install 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, 25 Mar 2011 21:52:54 -0000 On Fri, 25 Mar 2011 13:47:13 -0700 Garrett Cooper wrote: > On Fri, Mar 25, 2011 at 1:14 PM, Alexander Leidinger > wrote: > > On Fri, 25 Mar 2011 16:35:21 +0100 Pietro Cerutti > > wrote: > > > >> On 2011-Mar-25, 15:03, Julien Laffaye wrote: > >> > >>> What about DB corruption/loss? Do you keep > >> > >>> the /var/db/pkg//xxx files even with pkgng and only > >> > >>> use the DB as a way to speed up some work (so > >> > >>> the DB corruption just requires to run pkg2ng), or are you > >> > >>> lost of the DB is > >> > >>> lost? > >> > >>> > >> > >> > >> > >> Nothing is done about DB corruption/loss, I am not sure we > >> > >> need to do something. > >> > >> Maybe. > >> > > > >> > > I would say "for sure". Info: In Solaris 10 sqlite is used for > >> > > the service managenemt framework (SMF). It is possible that the > >> > > DB is corrupt in some bad situations. In this case you have to > >> > > rebuild the DB (script provided, been there, had to use it). > >> > > >> > If sqlite is properly used with transactions, it is very hard to > >> > corrupt the database. But if hardware lies to us and say that the > > > > And as I told above, I even had such a case (more than once), and > > the hardware was not buggy. What do you want to tell in this case, > > "life sucks, reinstall everything"? > > If you use binary packages, pulling down everything should be trivial, > fast, and easy to install. If you're using ports, well then things are > going to be slow as expected. And if there is a fast way to cut down the slow part... why not? > >> > data is on disk whereas it isnt... what can we do? > > > > Sometimes you have to stay with broken hardware. > > Sometimes you have to go buy new parts? Yes, but if we talk e.g. about aging hardware, having the luck to get hit directly in the parts which hurt is not nice. You want to have the time to find a suitable replacement. > Playing with broken hardware is like playing with fire -- sometimes > you'll get burned if it goes out of commission during critical > operations. I would be more concerned about overall system operation > than having a packaging system that can handle all error conditions > that should be rightfully handled by various kernel subsystems. If the > kernel's doing it's job, then the packaging manager can do its job as > well. You know that the world is not an ideal one. Shit happens and Murphy visits you. > >> > Another potential problem is fsync(), but if it is broken on > >> > FreeBSD we want to fix it! > >> > > >> > BTW, the goal is to only have the database and not the flat > >> > files. If you are paranoid about power outage, use something > >> > like zfs snapshots... > > > > There are more FS than only ZFS (personally I use ZFS, and I have > > snapshots, but this is not a good solution for this problem). > > A lot of filesystems feature snapshot'ing, including UFS. If you > aren't smart enough to back up your data you're toast if the data is > gone. So... why do we have /var/backups/master.passwd.bak then? To make life easy. > I would be more concerned about the program getting killed, not > getting properly cleaned up, etc as this is something that the package > manager frontend (or whatever the official name is) should catch and > fail gracefully with. Things need to follow an ACID methodology and be > recoverable in the event that it can't be ACID, or it's no better than > pkg_install/ports currently is if it's caught in the middle of a > critical operation today installing or removing software. I agree. > If SQLite can't deliver this level of ACID-like capability, then > pkg_install needs to be redesigned. AFAIK it can. > > As I told already, if it isn't automatic, nearly nobody will use it. > > And the package management stuff has to be automatic, no freshman > > will think about setting up a snapshot script when he starts to use > > packages/ports. > > I'd just provide an export command to print out a (JSON?) > version of the information, and move on. None of the other major > packaging systems out there that I know of use flat files for this > data, and I would rather not make it automatic because it's an > unnecessary performance hit. If the user feels the need for backing up > his/her data they will. If not, they're SoL in the event of a crash. - It does not need to be done with every change. - You do not know if it is a performance hit or not, we do not have numbers. - If making an automatic export after X modifications is not expensive, I say: why not? It would make more easy in case of fire. > >> No need to look for strange scenarios, I'm surely going to sudo rm > >> -f the file more sooner than later, so... maybe just save a copy? > > > > A copy or two would be enough, but it has to be done automatically, > > and once a day is not enough. A copy after each X modifications > > maybe (for suitable definitions of X and 'modifications'). > > Please see my comment above. There's no reason why this belongs in a > packaging system (you can add it as an external tool, but the point is > to avoid architectural mistakes that leaked into the old pkg_install > over the period of 10 years or so). Backups are not for architectural mistakes, they are for situations where something went wrong. Something may go wrong even without architectural mistakes. Safety nets are good. They are even better if they do not cost anything. We do not know how much this would cost, but does this mean we are not even allowed to talk about it? If the penalty is too big, sure, ditch the idea of doing it often, but as long as we do not know the numbers, please, don't tell the end of the world is near. > Thanks, > -Garrett > > PS Sorry for being so hardnosed on this, but I want something that's > fast and correct, instead of something bloated, slow, half-baked, > harder to test, etc. pkg_install gets executed enough times during a > port upgrade that having something more streamlined for most usecases > is the only way to go, and there's enough code that doesn't get > executed on a regular basis that has no business being in pkg_install. I agree fully with you, I also hope for something very fast, but as long as we do not have numbers, please ... Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 22:32:03 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 35F491065670; Fri, 25 Mar 2011 22:32:03 +0000 (UTC) Date: Fri, 25 Mar 2011 22:32:03 +0000 From: Alexander Best To: Xin LI Message-ID: <20110325223203.GA95976@freebsd.org> References: <20110325002115.GA323@freebsd.org> <20110325015508.GA14565@freebsd.org> <20110325024658.GA19544@freebsd.org> <336A9ACD-29BF-41C9-BC25-917CC1E4587D@bsdimp.com> <20110325195325.GA69264@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: Switching to [KMGTPE]i prefixes? 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, 25 Mar 2011 22:32:03 -0000 On Fri Mar 25 11, Xin LI wrote: > FYI I have a patch and I have incorporated some of Alexander's idea. > > Difference: > > - Use of both HN_DIVISOR_1000 and HN_IEC_PREFIXES triggers an > assertion. I think it doesn't make sense to return since this is an > API violation and we should just tell the caller explicitly; actually i vote for removing all asserts in humanize_number.c and return -1 based upon the later checks. the existing assert(buf != NULL); assert(suffix != NULL); checks aren't really needed, since buf and suffix are also checked later on. so just having: if (scale <= 0 || (scale >= maxscale && (scale & (HN_AUTOSCALE | HN_GETSCALE)) == 0)) return (-1); if (buf == NULL || suffix == NULL) return (-1); if ((flags & (HN_DIVISOR_1000 | HN_IEC_PREFIXES)) == 0) return (-1); ...should be enough. > - DIVISOR_1000 and !1000 cases use just same prefixes, so merge them > while keeping divisor intact; good idea. however i think you should add a comment to point out that the default behavior is !DIVISOR_1000 && !HN_IEC_PREFIXES. one has to look very closely to find out. > - Make prefixes table consistently long. I have no strong opinion on > this one, though, it's just what my original version used and I can > change it to the way Alexander did if there is an advantage of doing > that way. i think the way you're doing it is nicer than how i implemented it. > > (Note, it seems that we use HN_ prefix for both 'scale' and 'flags', I > have sorted them by value but HN_IEC_PREFIXES should really belong to > the flags group). this is odd indeed. actually the possible 'scale' and 'flags' flags should not have the same prefixes. but it appears we're stuck with this. i think sorting me should sort them into the two groups and not value wise. so it's #define HN_DECIMAL 0x01 #define HN_NOSPACE 0x02 #define HN_B 0x04 #define HN_DIVISOR_1000 0x08 #define HN_IEC_PREFIXES 0x40 #define HN_GETSCALE 0x10 #define HN_AUTOSCALE 0x20 > > Cheers, > -- > Xin LI http://www.delphij.net -- a13x From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 22:40:27 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id B1B0F1065679; Fri, 25 Mar 2011 22:40:27 +0000 (UTC) Date: Fri, 25 Mar 2011 22:40:27 +0000 From: Alexander Best To: Xin LI Message-ID: <20110325224027.GA859@freebsd.org> References: <20110325002115.GA323@freebsd.org> <20110325015508.GA14565@freebsd.org> <20110325024658.GA19544@freebsd.org> <336A9ACD-29BF-41C9-BC25-917CC1E4587D@bsdimp.com> <20110325195325.GA69264@freebsd.org> <20110325223203.GA95976@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline In-Reply-To: <20110325223203.GA95976@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Switching to [KMGTPE]i prefixes? 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, 25 Mar 2011 22:40:27 -0000 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri Mar 25 11, Alexander Best wrote: > On Fri Mar 25 11, Xin LI wrote: > > FYI I have a patch and I have incorporated some of Alexander's idea. this is what i had in mind (see attached patch). cheers. alex > > > > Difference: > > > > - Use of both HN_DIVISOR_1000 and HN_IEC_PREFIXES triggers an > > assertion. I think it doesn't make sense to return since this is an > > API violation and we should just tell the caller explicitly; > > actually i vote for removing all asserts in humanize_number.c and return -1 > based upon the later checks. > > the existing > > assert(buf != NULL); > assert(suffix != NULL); > > checks aren't really needed, since buf and suffix are also checked later on. so > just having: > > if (scale <= 0 || (scale >= maxscale && > (scale & (HN_AUTOSCALE | HN_GETSCALE)) == 0)) > return (-1); > > if (buf == NULL || suffix == NULL) > return (-1); > > if ((flags & (HN_DIVISOR_1000 | HN_IEC_PREFIXES)) == 0) > return (-1); > > ...should be enough. > > > - DIVISOR_1000 and !1000 cases use just same prefixes, so merge them > > while keeping divisor intact; > > good idea. however i think you should add a comment to point out that the > default behavior is !DIVISOR_1000 && !HN_IEC_PREFIXES. one has to look very > closely to find out. > > > - Make prefixes table consistently long. I have no strong opinion on > > this one, though, it's just what my original version used and I can > > change it to the way Alexander did if there is an advantage of doing > > that way. > > i think the way you're doing it is nicer than how i implemented it. > > > > > (Note, it seems that we use HN_ prefix for both 'scale' and 'flags', I > > have sorted them by value but HN_IEC_PREFIXES should really belong to > > the flags group). > > this is odd indeed. actually the possible 'scale' and 'flags' flags should > not have the same prefixes. but it appears we're stuck with this. > > i think sorting me should sort them into the two groups and not value wise. > so it's > > #define HN_DECIMAL 0x01 > #define HN_NOSPACE 0x02 > #define HN_B 0x04 > #define HN_DIVISOR_1000 0x08 > #define HN_IEC_PREFIXES 0x40 > > #define HN_GETSCALE 0x10 > #define HN_AUTOSCALE 0x20 > > > > > Cheers, > > -- > > Xin LI http://www.delphij.net > > > > -- > a13x -- a13x --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="humanize_number.c.diff" diff --git a/lib/libutil/humanize_number.c b/lib/libutil/humanize_number.c index 75bcb46..e086478 100644 --- a/lib/libutil/humanize_number.c +++ b/lib/libutil/humanize_number.c @@ -33,11 +33,8 @@ #include __FBSDID("$FreeBSD$"); -#include -#include #include #include -#include #include #include #include @@ -51,50 +48,50 @@ humanize_number(char *buf, size_t len, int64_t quotient, int64_t divisor, max; size_t baselen; - assert(buf != NULL); - assert(suffix != NULL); - assert(scale >= 0); - remainder = 0; - if (flags & HN_DIVISOR_1000) { - /* SI for decimal multiplies */ - divisor = 1000; + if (flags & HN_IEC_PREFIXES) { + baselen = 2; + divisor = 1024; if (flags & HN_B) - prefixes = "B\0k\0M\0G\0T\0P\0E"; + prefixes = "B\0\0Ki\0Mi\0Gi\0Ti\0Pi\0Ei"; else - prefixes = "\0\0k\0M\0G\0T\0P\0E"; - } else { - /* - * binary multiplies - * XXX IEC 60027-2 recommends Ki, Mi, Gi... - */ - divisor = 1024; + prefixes = "\0\0Ki\0Mi\0Gi\0Ti\0Pi\0Ei"; + else { + baselen = 1; + if (flags & HN_DIVISOR_1000) + divisor = 1000; + else + /* default case */ + divisor = 1024; if (flags & HN_B) - prefixes = "B\0K\0M\0G\0T\0P\0E"; + prefixes = "B\0\0k\0\0M\0\0G\0\0T\0\0P\0\0E"; else - prefixes = "\0\0K\0M\0G\0T\0P\0E"; + prefixes = "\0\0\0k\0\0M\0\0G\0\0T\0\0P\0\0E"; } -#define SCALE2PREFIX(scale) (&prefixes[(scale) << 1]) - maxscale = 7; +#define SCALE2PREFIX(scale) (&prefixes[(scale) * 3]) + maxscale = 7; /* XXX cannot scale past `exa' */ - if (scale >= maxscale && - (scale & (HN_AUTOSCALE | HN_GETSCALE)) == 0) + if (scale <= 0 || (scale >= maxscale && + (scale & (HN_AUTOSCALE | HN_GETSCALE)) == 0)) return (-1); if (buf == NULL || suffix == NULL) return (-1); + if (flags & (HN_DIVISOR_1000 | HN_IEC_PREFIXES)) + return (-1); + if (len > 0) buf[0] = '\0'; if (quotient < 0) { sign = -1; quotient = -quotient; - baselen = 3; /* sign, digit, prefix */ + baselen += 2; /* sign, digit */ } else { sign = 1; - baselen = 2; /* digit, prefix */ + baselen += 1; /* digit */ } if (flags & HN_NOSPACE) sep = ""; --C7zPtVaVf+AK4Oqc-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 23:17: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 F17BF106566B; Fri, 25 Mar 2011 23:17:57 +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 AE8F08FC16; Fri, 25 Mar 2011 23:17:57 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63] (may be forged)) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id p2PNCTT4053922; Fri, 25 Mar 2011 17:12:29 -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: Fri, 25 Mar 2011 15:50:54 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110325002115.GA323@freebsd.org> <20110325015508.GA14565@freebsd.org> <20110325024658.GA19544@freebsd.org> <336A9ACD-29BF-41C9-BC25-917CC1E4587D@bsdimp.com> <20110325195325.GA69264@freebsd.org> To: Xin LI X-Mailer: Apple Mail (2.1082) Cc: Alexander Best , freebsd-hackers@FreeBSD.org Subject: Re: Switching to [KMGTPE]i prefixes? 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, 25 Mar 2011 23:17:58 -0000 On Mar 25, 2011, at 3:33 PM, Xin LI wrote: > FYI I have a patch and I have incorporated some of Alexander's idea. >=20 > Difference: >=20 > - Use of both HN_DIVISOR_1000 and HN_IEC_PREFIXES triggers an > assertion. I think it doesn't make sense to return since this is an > API violation and we should just tell the caller explicitly; > - DIVISOR_1000 and !1000 cases use just same prefixes, so merge them > while keeping divisor intact; > - Make prefixes table consistently long. I have no strong opinion on > this one, though, it's just what my original version used and I can > change it to the way Alexander did if there is an advantage of doing > that way. I did this in my first iteration, but switched to the array version = after. Either is good, honestly. > (Note, it seems that we use HN_ prefix for both 'scale' and 'flags', I > have sorted them by value but HN_IEC_PREFIXES should really belong to > the flags group). How did you guys deal with programs like df that now need to do special = buffer size hacks to get consistent results? Warner From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 23:27:07 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 2BC24106566C; Fri, 25 Mar 2011 23:27:07 +0000 (UTC) (envelope-from delphij@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 D453E8FC08; Fri, 25 Mar 2011 23:27:06 +0000 (UTC) Received: by iyj12 with SMTP id 12so1992802iyj.13 for ; Fri, 25 Mar 2011 16:27:06 -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=BLJkaWJrj/QZnraupBMzmv94I3gu7f3EFUtQVrX10P4=; b=IETpx7iMdg9ixXcWmx9IvKd6fYe3I0Z8h8gzmM/uSzBHDwlo+JDMvDXN4Ku69JUI/x wAzSzXSDHrAE2QRIGoUY7oIcRWvkxXCtAm9BGayxwpSc2M6YNh4+do0r/WlTgUv/bZye 1LNhywL1fV4jkzvcSgXIm+e+vzBU/+RaftQbo= 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=xp8BQMNjCdxG8kAgoE0XYOUtCmnTaoHx5U5j/zAIVcrBr1z/8nMBwHJTWT4Wd+UWhb jLaWr2rDdDUz14S6SJo70vrGMaoyzGuAYx9pcGm5yrD7rmL61qVMLsTsPE0zT/Grw5HV YT3u4f1fwSBTlHPd6q/y1WfqzQoEsvSUKh1gU= MIME-Version: 1.0 Received: by 10.231.194.195 with SMTP id dz3mr1369011ibb.148.1301095626294; Fri, 25 Mar 2011 16:27:06 -0700 (PDT) Received: by 10.231.143.209 with HTTP; Fri, 25 Mar 2011 16:27:06 -0700 (PDT) In-Reply-To: <20110325223203.GA95976@freebsd.org> References: <20110325002115.GA323@freebsd.org> <20110325015508.GA14565@freebsd.org> <20110325024658.GA19544@freebsd.org> <336A9ACD-29BF-41C9-BC25-917CC1E4587D@bsdimp.com> <20110325195325.GA69264@freebsd.org> <20110325223203.GA95976@freebsd.org> Date: Fri, 25 Mar 2011 16:27:06 -0700 Message-ID: From: Xin LI To: Alexander Best Content-Type: multipart/mixed; boundary=00504502cc8f9fc715049f56ee36 Cc: freebsd-hackers@freebsd.org Subject: Re: Switching to [KMGTPE]i prefixes? 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, 25 Mar 2011 23:27:07 -0000 --00504502cc8f9fc715049f56ee36 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 25, 2011 at 3:32 PM, Alexander Best wrote= : > On Fri Mar 25 11, Xin LI wrote: >> FYI I have a patch and I have incorporated some of Alexander's idea. >> >> Difference: >> >> =C2=A0- Use of both HN_DIVISOR_1000 and HN_IEC_PREFIXES triggers an >> assertion. =C2=A0I think it doesn't make sense to return since this is a= n >> API violation and we should just tell the caller explicitly; > > actually i vote for removing all asserts in humanize_number.c and return = -1 > based upon the later checks. > > the existing > > assert(buf !=3D NULL); > assert(suffix !=3D NULL); > > checks aren't really needed, since buf and suffix are also checked later = on. so > just having: Well, one of my believes is that a program should crash as early as possible, and with clear statement about "Why I crashed", when it's compiled with debugging aids, like assertions. To test or not to test these cases in a release binary on the other hand really depends on whether there is security or other bad implications. This generally makes developers' life easier, as they don't have to pursue into the code to find out why the program crashed, etc. Unlike system calls, humanize_number(3) does not indicate what's wrong via errno, e.g. it tells you "No I can't" rather than a reason of "Why I can't do that". Assertions here gives it an opportunity to say it loudly. If however the program is compiled with -DNDEBUG, these assertions would became no-op. At this stage, in my opinion, only basic tests should be done and we fall back to returning -1, or at least, not crash the program in a mysterious way. For this reasons, I think the assertion here against flags is right, it does not hurt if we proceed with both flags set, as we do not access undefined memory nor overwrite undefined memory. Furthermore, these values are more likely to be hard-wired at caller, where the assertion should catch the case. > =C2=A0 =C2=A0 =C2=A0 =C2=A0if (scale <=3D 0 || (scale >=3D maxscale && > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(scale & (HN_AUTOSCALE | HN_GETS= CALE)) =3D=3D 0)) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return (-1); I think this one is good to have for both assertion and tests. Note that I think it should be scale < 0 here, scale =3D=3D 0 seems to be a valid value. > =C2=A0 =C2=A0 =C2=A0 =C2=A0if (buf =3D=3D NULL || suffix =3D=3D NULL) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return (-1); This duplication is necessary in my opinion. It's a protection against NULL pointer deference at runtime. > =C2=A0 =C2=A0 =C2=A0 =C2=A0if ((flags & (HN_DIVISOR_1000 | HN_IEC_PREFIXE= S)) =3D=3D 0) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return (-1); I'd vote no for this one for the reason above. >> =C2=A0- DIVISOR_1000 and !1000 cases use just same prefixes, so merge th= em >> while keeping divisor intact; > > good idea. however i think you should add a comment to point out that the > default behavior is !DIVISOR_1000 && !HN_IEC_PREFIXES. one has to look ve= ry > closely to find out. Will do. > #define HN_DECIMAL =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x01 > #define HN_NOSPACE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x02 > #define HN_B =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A00x04 > #define HN_DIVISOR_1000 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x08 > #define HN_IEC_PREFIXES =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x40 > > #define HN_GETSCALE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x10 > #define HN_AUTOSCALE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x20 Thinking again and I think we are just fine to use HN_IEC_PREFIXES =3D=3D 0x10 here. I don't think there is a reason why we can't use 0x10 for flags. Here is what in my mind. I have stolen some comments from your version of patch to explain the meaning of the HN_IEC_PREFIXES option as well. --=20 Xin LI http://www.delphij.net --00504502cc8f9fc715049f56ee36 Content-Type: text/x-patch; charset=US-ASCII; name="humanize_number.c.diff" Content-Disposition: attachment; filename="humanize_number.c.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_glpqpog20 SW5kZXg6IGh1bWFuaXplX251bWJlci5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGh1bWFuaXplX251bWJlci5j CShyZXZpc2lvbiAyMjAwMDkpCisrKyBodW1hbml6ZV9udW1iZXIuYwkod29ya2luZyBjb3B5KQpA QCAtNDIsNDUgKzQyLDU5IEBACiAjaW5jbHVkZSA8bG9jYWxlLmg+CiAjaW5jbHVkZSA8bGlidXRp bC5oPgogCitzdGF0aWMgY29uc3QgaW50IG1heHNjYWxlID0gNzsKKwogaW50CiBodW1hbml6ZV9u dW1iZXIoY2hhciAqYnVmLCBzaXplX3QgbGVuLCBpbnQ2NF90IHF1b3RpZW50LAogICAgIGNvbnN0 IGNoYXIgKnN1ZmZpeCwgaW50IHNjYWxlLCBpbnQgZmxhZ3MpCiB7CiAJY29uc3QgY2hhciAqcHJl Zml4ZXMsICpzZXA7Ci0JaW50CWksIHIsIHJlbWFpbmRlciwgbWF4c2NhbGUsIHMxLCBzMiwgc2ln bjsKKwlpbnQJaSwgciwgcmVtYWluZGVyLCBzMSwgczIsIHNpZ247CiAJaW50NjRfdAlkaXZpc29y LCBtYXg7CiAJc2l6ZV90CWJhc2VsZW47CiAKIAlhc3NlcnQoYnVmICE9IE5VTEwpOwogCWFzc2Vy dChzdWZmaXggIT0gTlVMTCk7CiAJYXNzZXJ0KHNjYWxlID49IDApOworCWFzc2VydChzY2FsZSA8 IG1heHNjYWxlIHx8ICgoKHNjYWxlICYgKEhOX0FVVE9TQ0FMRSB8IEhOX0dFVFNDQUxFKSkgIT0g MCkpKTsKKwlhc3NlcnQoISgoZmxhZ3MgJiBITl9ESVZJU09SXzEwMDApICYmIChmbGFncyAmIEhO X0lFQ19QUkVGSVhFUykpKTsKIAogCXJlbWFpbmRlciA9IDA7CiAKLQlpZiAoZmxhZ3MgJiBITl9E SVZJU09SXzEwMDApIHsKLQkJLyogU0kgZm9yIGRlY2ltYWwgbXVsdGlwbGllcyAqLwotCQlkaXZp c29yID0gMTAwMDsKLQkJaWYgKGZsYWdzICYgSE5fQikKLQkJCXByZWZpeGVzID0gIkJcMGtcME1c MEdcMFRcMFBcMEUiOwotCQllbHNlCi0JCQlwcmVmaXhlcyA9ICJcMFwwa1wwTVwwR1wwVFwwUFww RSI7Ci0JfSBlbHNlIHsKKwlpZiAoZmxhZ3MgJiBITl9JRUNfUFJFRklYRVMpIHsKKwkJYmFzZWxl biA9IDI7CiAJCS8qCi0JCSAqIGJpbmFyeSBtdWx0aXBsaWVzCi0JCSAqIFhYWCBJRUMgNjAwMjct MiByZWNvbW1lbmRzIEtpLCBNaSwgR2kuLi4KKwkJICogVXNlIHRoZSBwcmVmaXhlcyBmb3IgcG93 ZXIgb2YgdHdvIHJlY29tbWVuZGVkIGJ5CisJCSAqIHRoZSBJbnRlcm5hdGlvbmFsIEVsZWN0cm90 ZWNobmljYWwgQ29tbWlzc2lvbgorCQkgKiAoSUVDKSBpbiBJRUMgODAwMDAtMyAoc3VwZXJzZWVk aW5nIElFQyA2MDAyNy0yKQorCQkgKiAoaS5lLiBLaSwgTWksIEdpLi4uKS4KKwkJICoKKwkJICog SE5fSUVDX1BSRUZJWEVTIGltcGxpZXMgYSBkaXZpc29yIG9mIDEwMjQgaGVyZQorCQkgKiAodXNl IG9mIEhOX0RJVklTT1JfMTAwMCB3b3VsZCBoYXZlIHRyaWdnZXJlZAorCQkgKiBhbiBhc3NlcnRp b24gZWFybGllcikuCiAJCSAqLwogCQlkaXZpc29yID0gMTAyNDsKIAkJaWYgKGZsYWdzICYgSE5f QikKLQkJCXByZWZpeGVzID0gIkJcMEtcME1cMEdcMFRcMFBcMEUiOworCQkJcHJlZml4ZXMgPSAi QlwwXDBLaVwwTWlcMEdpXDBUaVwwUGlcMEVpIjsKIAkJZWxzZQotCQkJcHJlZml4ZXMgPSAiXDBc MEtcME1cMEdcMFRcMFBcMEUiOworCQkJcHJlZml4ZXMgPSAiXDBcMEtpXDBNaVwwR2lcMFRpXDBQ aVwwRWkiOworCX0gZWxzZSB7CisJCWJhc2VsZW4gPSAxOworCQlpZiAoZmxhZ3MgJiBITl9ESVZJ U09SXzEwMDApCisJCQlkaXZpc29yID0gMTAwMDsKKwkJZWxzZQorCQkJZGl2aXNvciA9IDEwMjQ7 CisKKwkJaWYgKGZsYWdzICYgSE5fQikKKwkJCXByZWZpeGVzID0gIkJcMFwwa1wwXDBNXDBcMEdc MFwwVFwwXDBQXDBcMEUiOworCQllbHNlCisJCQlwcmVmaXhlcyA9ICJcMFwwXDBrXDBcME1cMFww R1wwXDBUXDBcMFBcMFwwRSI7CiAJfQogCi0jZGVmaW5lCVNDQUxFMlBSRUZJWChzY2FsZSkJKCZw cmVmaXhlc1soc2NhbGUpIDw8IDFdKQotCW1heHNjYWxlID0gNzsKKyNkZWZpbmUJU0NBTEUyUFJF RklYKHNjYWxlKQkoJnByZWZpeGVzWyhzY2FsZSkgKiAzXSkKIAotCWlmIChzY2FsZSA+PSBtYXhz Y2FsZSAmJgotCSAgICAoc2NhbGUgJiAoSE5fQVVUT1NDQUxFIHwgSE5fR0VUU0NBTEUpKSA9PSAw KQorCWlmIChzY2FsZSA8IDAgfHwgKHNjYWxlID49IG1heHNjYWxlICYmCisJICAgIChzY2FsZSAm IChITl9BVVRPU0NBTEUgfCBITl9HRVRTQ0FMRSkpID09IDApKQogCQlyZXR1cm4gKC0xKTsKIAog CWlmIChidWYgPT0gTlVMTCB8fCBzdWZmaXggPT0gTlVMTCkKQEAgLTkxLDEwICsxMDUsMTAgQEAK IAlpZiAocXVvdGllbnQgPCAwKSB7CiAJCXNpZ24gPSAtMTsKIAkJcXVvdGllbnQgPSAtcXVvdGll bnQ7Ci0JCWJhc2VsZW4gPSAzOwkJLyogc2lnbiwgZGlnaXQsIHByZWZpeCAqLworCQliYXNlbGVu ICs9IDI7CQkvKiBzaWduLCBkaWdpdCAqLwogCX0gZWxzZSB7CiAJCXNpZ24gPSAxOwotCQliYXNl bGVuID0gMjsJCS8qIGRpZ2l0LCBwcmVmaXggKi8KKwkJYmFzZWxlbiArPSAxOwkJLyogZGlnaXQg Ki8KIAl9CiAJaWYgKGZsYWdzICYgSE5fTk9TUEFDRSkKIAkJc2VwID0gIiI7CkluZGV4OiBsaWJ1 dGlsLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gbGlidXRpbC5oCShyZXZpc2lvbiAyMjAwMDkpCisrKyBsaWJ1 dGlsLmgJKHdvcmtpbmcgY29weSkKQEAgLTIyMCw3ICsyMjAsOSBAQAogI2RlZmluZSBITl9OT1NQ QUNFCQkweDAyCiAjZGVmaW5lIEhOX0IJCQkweDA0CiAjZGVmaW5lIEhOX0RJVklTT1JfMTAwMAkJ MHgwOAorI2RlZmluZSBITl9JRUNfUFJFRklYRVMJCTB4MTAKIAorLyogbWF4c2NhbGUgPSAweDA3 ICovCiAjZGVmaW5lIEhOX0dFVFNDQUxFCQkweDEwCiAjZGVmaW5lIEhOX0FVVE9TQ0FMRQkJMHgy MAogCg== --00504502cc8f9fc715049f56ee36-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 23:28: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 ACF521065670; Fri, 25 Mar 2011 23:28:26 +0000 (UTC) (envelope-from delphij@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 64E658FC13; Fri, 25 Mar 2011 23:28:26 +0000 (UTC) Received: by iyj12 with SMTP id 12so1993859iyj.13 for ; Fri, 25 Mar 2011 16:28:26 -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=4aWpqRDJZygvCFmV69m8KhltpAV1S1S1R1anAWa6Y9Q=; b=j0p8z12vUaGRDxMQu7JLxhwzUxWoHpnwEL9zHp/FS6Cf2s5PTw+9b1NoL9yoBhCi3Q lmlMdb41hzzwiVJr/l4K4ZhCP9bpE8FblTd0fYTYcPCmjtI0q6fkE4+gCLbFSWGzPI/4 rZyvSQhvhaw1n0DOfiwM5AGSndCjwo5BPa+a0= 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=T9nhxzGkcTooM38GVLew9NZrKDJ246bDlxFiMwZhy7iS3CGFYcraRNTZGtYuoSCygW RrUnOnhte5pcyD+gE01vgPDHkzlICIcYVMMThkYCyJFobq/5qlhj8EvovOq/TLuiK0Pu RjaNnpTSiSGMlfZ5qOQUCa79OMp0FC+J+it6U= MIME-Version: 1.0 Received: by 10.231.197.27 with SMTP id ei27mr1279395ibb.198.1301095706027; Fri, 25 Mar 2011 16:28:26 -0700 (PDT) Received: by 10.231.143.209 with HTTP; Fri, 25 Mar 2011 16:28:25 -0700 (PDT) In-Reply-To: References: <20110325002115.GA323@freebsd.org> <20110325015508.GA14565@freebsd.org> <20110325024658.GA19544@freebsd.org> <336A9ACD-29BF-41C9-BC25-917CC1E4587D@bsdimp.com> <20110325195325.GA69264@freebsd.org> Date: Fri, 25 Mar 2011 16:28:25 -0700 Message-ID: From: Xin LI To: Warner Losh Content-Type: text/plain; charset=UTF-8 Cc: Alexander Best , freebsd-hackers@freebsd.org Subject: Re: Switching to [KMGTPE]i prefixes? 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, 25 Mar 2011 23:28:26 -0000 On Fri, Mar 25, 2011 at 2:50 PM, Warner Losh wrote: > How did you guys deal with programs like df that now need to do special buffer size hacks to get consistent results? I think it doesn't really matter - caller have to specify using IEC prefixes explicitly, so old binaries won't be broken. They must be updated to use the IEC prefixes. Cheers, -- Xin LI http://www.delphij.net From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 23:44: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 1BA08106564A; Fri, 25 Mar 2011 23:44:49 +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 BE7758FC12; Fri, 25 Mar 2011 23:44:48 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63] (may be forged)) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id p2PNc6ql054135; Fri, 25 Mar 2011 17:38:08 -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: Fri, 25 Mar 2011 17:38:06 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <89A0FF76-7907-4815-85D2-F87968939B66@bsdimp.com> References: <20110325002115.GA323@freebsd.org> <20110325015508.GA14565@freebsd.org> <20110325024658.GA19544@freebsd.org> <336A9ACD-29BF-41C9-BC25-917CC1E4587D@bsdimp.com> <20110325195325.GA69264@freebsd.org> To: Xin LI X-Mailer: Apple Mail (2.1082) Cc: Alexander Best , freebsd-hackers@freebsd.org Subject: Re: Switching to [KMGTPE]i prefixes? 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, 25 Mar 2011 23:44:49 -0000 On Mar 25, 2011, at 5:28 PM, Xin LI wrote: > On Fri, Mar 25, 2011 at 2:50 PM, Warner Losh wrote: >> How did you guys deal with programs like df that now need to do = special buffer size hacks to get consistent results? >=20 > I think it doesn't really matter - caller have to specify using IEC > prefixes explicitly, so old binaries won't be broken. They must be > updated to use the IEC prefixes. My patch had a 'force IEC prefixes' compile time option which did. However, you'll have to monkey around with df to get it to do the right = thing since the buffer sizes and such will need to be 1 longer for the = extra 'i' in the mix now... And it can' t be unconditional, since then = you'd get different results with the non IEC case. That's a short way of saying that this patch is necessary, but not = sufficient for the current system. We'll need a lot of tweaks to the = rest of the system for it to behave correctly. Warner From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 00:13:51 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 04DC1106566B; Sat, 26 Mar 2011 00:13:51 +0000 (UTC) Date: Sat, 26 Mar 2011 00:13:51 +0000 From: Alexander Best To: Xin LI Message-ID: <20110326001350.GA10718@freebsd.org> References: <20110325002115.GA323@freebsd.org> <20110325015508.GA14565@freebsd.org> <20110325024658.GA19544@freebsd.org> <336A9ACD-29BF-41C9-BC25-917CC1E4587D@bsdimp.com> <20110325195325.GA69264@freebsd.org> <20110325223203.GA95976@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: Switching to [KMGTPE]i prefixes? 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, 26 Mar 2011 00:13:51 -0000 On Fri Mar 25 11, Xin LI wrote: > On Fri, Mar 25, 2011 at 3:32 PM, Alexander Best wrote: > > On Fri Mar 25 11, Xin LI wrote: > >> FYI I have a patch and I have incorporated some of Alexander's idea. > >> > >> Difference: > >> > >>  - Use of both HN_DIVISOR_1000 and HN_IEC_PREFIXES triggers an > >> assertion.  I think it doesn't make sense to return since this is an > >> API violation and we should just tell the caller explicitly; > > > > actually i vote for removing all asserts in humanize_number.c and return -1 > > based upon the later checks. > > > > the existing > > > > assert(buf != NULL); > > assert(suffix != NULL); > > > > checks aren't really needed, since buf and suffix are also checked later on. so > > just having: > > Well, one of my believes is that a program should crash as early as > possible, and with clear statement about "Why I crashed", when it's > compiled with debugging aids, like assertions. To test or not to test > these cases in a release binary on the other hand really depends on > whether there is security or other bad implications. This generally > makes developers' life easier, as they don't have to pursue into the > code to find out why the program crashed, etc. > > Unlike system calls, humanize_number(3) does not indicate what's wrong > via errno, e.g. it tells you "No I can't" rather than a reason of "Why > I can't do that". Assertions here gives it an opportunity to say it > loudly. > > If however the program is compiled with -DNDEBUG, these assertions > would became no-op. At this stage, in my opinion, only basic tests > should be done and we fall back to returning -1, or at least, not > crash the program in a mysterious way. > > For this reasons, I think the assertion here against flags is right, > it does not hurt if we proceed with both flags set, as we do not > access undefined memory nor overwrite undefined memory. Furthermore, > these values are more likely to be hard-wired at caller, where the > assertion should catch the case. > > >        if (scale <= 0 || (scale >= maxscale && > >            (scale & (HN_AUTOSCALE | HN_GETSCALE)) == 0)) > >                return (-1); > > I think this one is good to have for both assertion and tests. Note > that I think it should be scale < 0 here, scale == 0 seems to be a > valid value. > > >        if (buf == NULL || suffix == NULL) > >                return (-1); > > This duplication is necessary in my opinion. It's a protection > against NULL pointer deference at runtime. > > >        if ((flags & (HN_DIVISOR_1000 | HN_IEC_PREFIXES)) == 0) > >                return (-1); > > I'd vote no for this one for the reason above. > > >>  - DIVISOR_1000 and !1000 cases use just same prefixes, so merge them > >> while keeping divisor intact; > > > > good idea. however i think you should add a comment to point out that the > > default behavior is !DIVISOR_1000 && !HN_IEC_PREFIXES. one has to look very > > closely to find out. > > Will do. > > > #define HN_DECIMAL              0x01 > > #define HN_NOSPACE              0x02 > > #define HN_B                    0x04 > > #define HN_DIVISOR_1000         0x08 > > #define HN_IEC_PREFIXES         0x40 > > > > #define HN_GETSCALE             0x10 > > #define HN_AUTOSCALE            0x20 > > Thinking again and I think we are just fine to use HN_IEC_PREFIXES == > 0x10 here. I don't think there is a reason why we can't use 0x10 for > flags. > > Here is what in my mind. I have stolen some comments from your > version of patch to explain the meaning of the HN_IEC_PREFIXES option > as well. very nice. to me the patch looks close to perfect and most importantly it won't break anything. :) even though the patch won't have any direct impact, it enables all other base utilities to make use of the IEC prefixes. no idea how that turns out. maybe the community votes to keep the current prefixes. the main point however is: now there's a chance to chose. :) i think the patch also requires a few humanize_number(3) man page changes. you might want to cherry pick from http://people.freebsd.org/~arundel/drafts/libutil.diff ...my changes to the man page are probably a bit too elaborate. cheers. alex > > -- > Xin LI http://www.delphij.net -- a13x From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 00:42: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 ADB1F106566C for ; Sat, 26 Mar 2011 00:42:43 +0000 (UTC) (envelope-from mwm@mired.org) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6752A8FC13 for ; Sat, 26 Mar 2011 00:42:43 +0000 (UTC) Received: by gwb15 with SMTP id 15so767355gwb.13 for ; Fri, 25 Mar 2011 17:42:42 -0700 (PDT) Received: by 10.150.94.15 with SMTP id r15mr1403172ybb.393.1301098683385; Fri, 25 Mar 2011 17:18:03 -0700 (PDT) Received: from bhuda.mired.org (h176.175.90.75.dynamic.ip.windstream.net [75.90.175.176]) by mx.google.com with ESMTPS id u37sm202004yba.7.2011.03.25.17.18.02 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Mar 2011 17:18:02 -0700 (PDT) Date: Fri, 25 Mar 2011 20:17:43 -0400 From: Mike Meyer To: freebsd-hackers@freebsd.org Message-ID: <20110325201743.20885f22@bhuda.mired.org> In-Reply-To: References: <20110325101111.GA36840@azathoth.lan> <20110325150653.21132ej6abxmjpgk@webmail.leidinger.net> Organization: Meyer Consulting X-Mailer: Claws Mail 3.7.7 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install 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, 26 Mar 2011 00:42:43 -0000 On Fri, 25 Mar 2011 15:14:52 +0100 Baptiste Daroussin wrote: > 2011/3/25 Alexander Leidinger : > >> - the register command can analyse elf files when registering a new port > >> to > >> discover forgotten dependencies if necessary. (done in alpha using libelf) > > This will probably fail if LD_LIBRARY_PATH is used, or if we are installing > > linuxulator ports. > this isn't activated by default, and if activated is only intended to > work on freebsd elf files. > This is done to workaround some bugguy ports not to be used in > production, pkg register shows in warning in that case so that > user/maintainers are warned they have something to fix. How about dealing with 32-bit x86 packages on an amd64 install? http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 06:19:44 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 6262D106566B for ; Sat, 26 Mar 2011 06:19:44 +0000 (UTC) (envelope-from lichray@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 0F5B98FC17 for ; Sat, 26 Mar 2011 06:19:43 +0000 (UTC) Received: by qwc9 with SMTP id 9so1146711qwc.13 for ; Fri, 25 Mar 2011 23:19:43 -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=xyTxHw9XZ3rHn4lzkyQ+Efl7sLDICF4QePOQqaknZ34=; b=Yt/Zm+md5aF4P1Ch3dqMb4NZQl5qMcklC3CiFe5xNlSZ1wJJEQCYnsnNiTaJDOJ6e0 FXeCLd1GpkOkWLnuxR7zr9GQ4YEpC1mD9b1sK+WqQvEn5D5iiXEpgKNzdRfpKsgbrTI2 pQzp2JAJXxg0zTd757jwQbjXl76VTywji6D5I= 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=Sl16o3codmKNPmUGlm+pJgDrDFaAymgEXZiHZZIrAEu038Br1gJk6Hsz3lYa2udczX tgZclkrhWgdPE/P4So2YFC5w4bMbGFsDfHGmQ3osaGIsPUJOHB0exRaNEJ+pp3I9g6qM GdQVqT2aN1z97N/y1D5l1UF1wZIO1BWY1HgOQ= MIME-Version: 1.0 Received: by 10.224.138.16 with SMTP id y16mr1423295qat.255.1301120383194; Fri, 25 Mar 2011 23:19:43 -0700 (PDT) Received: by 10.224.20.19 with HTTP; Fri, 25 Mar 2011 23:19:43 -0700 (PDT) In-Reply-To: References: <20110324111118.GF65750@cicely7.cicely.de> <20110324221757.GA20441@mud.stack.nl> <20110325094044.GA41319@mud.stack.nl> <20110325134537.GB21904@pix.net> Date: Sat, 26 Mar 2011 01:19:43 -0500 Message-ID: From: Zhihao Yuan To: Kurt Lidl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Johan van Selst , Arnaud Lacombe , freebsd-hackers@freebsd.org, Bernd Walter , Pan Tsu , ticso@cicely.de Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 26 Mar 2011 06:19:44 -0000 On Fri, Mar 25, 2011 at 1:39 PM, Zhihao Yuan wrote: > On Fri, Mar 25, 2011 at 8:45 AM, Kurt Lidl wrote: >> On Fri, Mar 25, 2011 at 10:40:44AM +0100, Johan van Selst wrote: >>> Zhihao Yuan wrote: >>> > > Could you please eleborate on the nvi-devel problems? I'm the curre= nt >>> > > maintainer of this port, and as far as I know it's fully functional= . >>> > 1. It does not support non-Unicode encodings. Actually, these >>> > encodings are mainstream in multi-byte encodings world. A proper >>> > iconv-awared implementation should be able to handle all of the >>> > encodings in `iconv -l`; >>> > 2. It depends on DB3/4. We won't accept DB3/4 in base system and we >>> > won't accept nvi-devel. >>> > 3. It's not 100% compatible with nvi 1.79. >>> >>> Thank you for explaining. Indeed, all valid points and I fully agree >>> that nvi-devel is not fit for inclusion in base as it is. In fact, the >>> nvi from base is probably a better starting point (than nvi-devel) to >>> create an editor that is fully compatible with nvi 1.79 and supports al= l >>> multi-byte encodings. And when you, or someone, else creates such an >>> editor, I will be pleased to remove the obsoleted port of nvi-devel. >> >> Has anyone looked at the nvi work that has taken place in NetBSD >> in the last year or so? > > I have checked that. It's just a latest nvi 1.85. > >> >> I think they've put in a bunch of wide character support. =C2=A0I'm not >> sure if their DB code relies on bdb newer than what is in libc or not. >> >> -Kurt >> > > -- > Zhihao Yuan > The best way to predict the future is to invent it. > Sorry to spam in the group... Since the application time is coming, I do need a possible mentor. I was told that nvi in the base system was not managed by a dedicated people. So I hope I can talk with someone who is free during the summer, and has some interests to help me :) --=20 Zhihao Yuan The best way to predict the future is to invent it. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 08:45:44 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 13EF81065678 for ; Sat, 26 Mar 2011 08:45:44 +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 B2A9F8FC27 for ; Sat, 26 Mar 2011 08:45:43 +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 p2Q8jbw5018585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 26 Mar 2011 09:45:42 +0100 (CET) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.4/8.14.4/Submit) id p2Q8jb7x018584 for freebsd-hackers@freebsd.org; Sat, 26 Mar 2011 09:45:37 +0100 (CET) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Sat, 26 Mar 2011 09:45:37 +0100 From: Paul Schenkeveld To: freebsd-hackers@freebsd.org Message-ID: <20110326084537.GA18254@psconsult.nl> References: <86mxkm1erm.fsf@gmail.com> <86aaglx1ow.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 26 Mar 2011 08:45:44 -0000 On Wed, Mar 23, 2011 at 08:20:07PM -0500, Zhihao Yuan wrote: > On Wed, Mar 23, 2011 at 7:26 PM, Arnaud Lacombe wrote: > > Hi, > > > > On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan wrote: > >> Among *all* the GNU/Linux distributions I used, they include a vim > >> compiled in tiny mode (ln -s it to vi), which doubles the size of nvi, > >> in their base systems. A vim.tiny contains much more features compared > >> with nvi, but it's not compatible with POSIX vi. > >> > > Let's compare the comparable, I don't really care if PCbsd ship vim as > > its default, but FreeBSD as the base is not only aimed at desktop > > specifically. So you should take into account that I may want to run > > FreeBSD on an adm5120 board with 32MB of RAM, without having a text > > editor consuming too much disk-space/ram. > > > >  - Arnaud > > > > If you really want to use vi in a 32MB mem environment, the ex-vi may > make sense. It consumes 1600KB memory while nvi consumes 2000KB. Note > that the ee editor uses same amount memory as ex-vi. > > So basically, if no one disagree that we can drop the infinite undo, > multiple buffer, multiple window and some other potential missing > features, we can replace the nvi in the base system with ex-vi. I like the idea of adding Unicode support to nvi but I hate the idea of replacing nvi in the base system by something else. I've been there before, when administering a heterogenous environment with Unix, BSD and Linux systems, being a heavy user of vi, it's frustrating if commands in various versions of vi do not behave *exactly* the same, e.g. different versions of vi leave the cursor in different places after undo, the effect of the repeat command (.) after an undo command, the availability or not to do something like /pattern/z. to find and position the found text in the middle of the screen so you can immediately see the context. Administering hundreds of FreeBSD systems at various sites would become a nightmare if frequently used utilities in the base system do not behave exactly the same between different builds, a true POLA violation I think. I truly hope that adding unicode to nvi doesn't change the behaviour of nvi, at least not when not using actually Unicode. I think it makes more sense to grow a WITHOUT_NVI knob in buildworld so that people building for embedded systems can exclude nvi and include another version of vi when really pressed for space, like we can replace the base systems sendmail by sendmail from ports or another MTA. Regards, Paul Schenkeveld From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 08:55: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 7D7E71065672 for ; Sat, 26 Mar 2011 08:55:15 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 3017F8FC12 for ; Sat, 26 Mar 2011 08:55:14 +0000 (UTC) Received: by qyk35 with SMTP id 35so155613qyk.13 for ; Sat, 26 Mar 2011 01:55:14 -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=FqKvgh5Kg09zuI7n7y0NUhIJvTkvpWkFvQmduzUAl1E=; b=NUxtV6A8FMusApEdT9gWm+VZHIhQ7w7S+d3iRBf4Bs8UHt+SOmGc60inMQArFXVkeo e7sntIfqFzjqr/Qt8bjmuVBfrlYmqqPiz1VQllqcRPRcaitolsqhOKL5mZjNldcZqNop DroeMNv8/fvn3/eqszldngx7i/9IePF4jcy4M= 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=K2WpNEbwHVzU27oXgkM+mbPc0LYsKX8cyFTaMbzDd5Xu7RiX21QhPKsVy85z1zIJs6 vUVqKFxhcsZoNaaftmaCVhQ2bBexsZFO04ceWpca95Denae8rHIGgQ+ZrlSCLKu4Wgpk Ldk8hsr1rZwoiiCMiQRAtT8zPH6naigtWyUOY= MIME-Version: 1.0 Received: by 10.224.211.65 with SMTP id gn1mr1510586qab.355.1301129712643; Sat, 26 Mar 2011 01:55:12 -0700 (PDT) Received: by 10.224.20.19 with HTTP; Sat, 26 Mar 2011 01:55:12 -0700 (PDT) In-Reply-To: <20110326084537.GA18254@psconsult.nl> References: <86mxkm1erm.fsf@gmail.com> <86aaglx1ow.fsf@gmail.com> <20110326084537.GA18254@psconsult.nl> Date: Sat, 26 Mar 2011 03:55:12 -0500 Message-ID: From: Zhihao Yuan To: Paul Schenkeveld Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: [GSoC] About the idea: Unicode support in vi 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, 26 Mar 2011 08:55:15 -0000 On Sat, Mar 26, 2011 at 3:45 AM, Paul Schenkeveld wr= ote: > On Wed, Mar 23, 2011 at 08:20:07PM -0500, Zhihao Yuan wrote: >> On Wed, Mar 23, 2011 at 7:26 PM, Arnaud Lacombe wro= te: >> > Hi, >> > >> > On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan wrote= : >> >> Among *all* the GNU/Linux distributions I used, they include a vim >> >> compiled in tiny mode (ln -s it to vi), which doubles the size of nvi= , >> >> in their base systems. A vim.tiny contains much more features compare= d >> >> with nvi, but it's not compatible with POSIX vi. >> >> >> > Let's compare the comparable, I don't really care if PCbsd ship vim as >> > its default, but FreeBSD as the base is not only aimed at desktop >> > specifically. So you should take into account that I may want to run >> > FreeBSD on an adm5120 board with 32MB of RAM, without having a text >> > editor consuming too much disk-space/ram. >> > >> > =C2=A0- Arnaud >> > >> >> If you really want to use vi in a 32MB mem environment, the ex-vi may >> make sense. It consumes 1600KB memory while nvi consumes 2000KB. Note >> that the ee editor uses same amount memory as ex-vi. >> >> So basically, if no one disagree that we can drop the infinite undo, >> multiple buffer, multiple window and some other potential missing >> features, we can replace the nvi in the base system with ex-vi. > > I like the idea of adding Unicode support to nvi but I hate the idea of > replacing nvi in the base system by something else. =C2=A0I've been there > before, when administering a heterogenous environment with Unix, BSD and > Linux systems, being a heavy user of vi, it's frustrating if commands in > various versions of vi do not behave *exactly* the same, e.g. different > versions of vi leave the cursor in different places after undo, the > effect of the repeat command (.) after an undo command, the availability > or not to do something like /pattern/z. to find and position the found > text in the middle of the screen so you can immediately see the context. > > Administering hundreds of FreeBSD systems at various sites would become > a nightmare if frequently used utilities in the base system do not > behave exactly the same between different builds, a true POLA violation > I think. =C2=A0I truly hope that adding unicode to nvi doesn't change the > behaviour of nvi, at least not when not using actually Unicode. I will improve nvi only, and I won't break the traditional functions. But your words reminds me that, perhaps the move of cursor is a problem for a mbytes-enabled vi. We will see. > > I think it makes more sense to grow a WITHOUT_NVI knob in buildworld so > that people building for embedded systems can exclude nvi and include > another version of vi when really pressed for space, like we can replace > the base systems sendmail by sendmail from ports or another MTA. > > Regards, > > Paul Schenkeveld > _______________________________________________ > 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 Zhihao Yuan The best way to predict the future is to invent it. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 09:43:58 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 C51C8106566B for ; Sat, 26 Mar 2011 09:43:58 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 568808FC0A for ; Sat, 26 Mar 2011 09:43:57 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id p2Q9huGr081882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 26 Mar 2011 10:43:56 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.4/8.14.4) with ESMTP id p2Q9hrHM073411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Mar 2011 10:43:53 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id p2Q9hrgE006735; Sat, 26 Mar 2011 10:43:53 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id p2Q9hqAL006734; Sat, 26 Mar 2011 10:43:52 +0100 (CET) (envelope-from ticso) Date: Sat, 26 Mar 2011 10:43:52 +0100 From: Bernd Walter To: Zhihao Yuan Message-ID: <20110326094352.GJ65750@cicely7.cicely.de> References: <86mxkm1erm.fsf@gmail.com> <86aaglx1ow.fsf@gmail.com> <20110326084537.GA18254@psconsult.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-hackers@freebsd.org, Paul Schenkeveld Subject: Re: [GSoC] About the idea: Unicode support in vi X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 09:43:58 -0000 On Sat, Mar 26, 2011 at 03:55:12AM -0500, Zhihao Yuan wrote: > On Sat, Mar 26, 2011 at 3:45 AM, Paul Schenkeveld wrote: > > On Wed, Mar 23, 2011 at 08:20:07PM -0500, Zhihao Yuan wrote: > >> On Wed, Mar 23, 2011 at 7:26 PM, Arnaud Lacombe wrote: > > > > I like the idea of adding Unicode support to nvi but I hate the idea of > > replacing nvi in the base system by something else.  I've been there > > before, when administering a heterogenous environment with Unix, BSD and > > Linux systems, being a heavy user of vi, it's frustrating if commands in > > various versions of vi do not behave *exactly* the same, e.g. different > > versions of vi leave the cursor in different places after undo, the > > effect of the repeat command (.) after an undo command, the availability > > or not to do something like /pattern/z. to find and position the found > > text in the middle of the screen so you can immediately see the context. > > > > Administering hundreds of FreeBSD systems at various sites would become > > a nightmare if frequently used utilities in the base system do not > > behave exactly the same between different builds, a true POLA violation > > I think.  I truly hope that adding unicode to nvi doesn't change the > > behaviour of nvi, at least not when not using actually Unicode. > > I will improve nvi only, and I won't break the traditional functions. > But your words reminds me that, perhaps the move of cursor is a > problem for a mbytes-enabled vi. We will see. It especially is if characters are double wide on output, which happens at least with some chinese ones. I really hope you will find a mentor soon enough. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 10:51: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 77F081065670 for ; Sat, 26 Mar 2011 10:51:23 +0000 (UTC) (envelope-from baptiste.daroussin@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 3C2C78FC13 for ; Sat, 26 Mar 2011 10:51:22 +0000 (UTC) Received: by iwn33 with SMTP id 33so2358356iwn.13 for ; Sat, 26 Mar 2011 03:51:22 -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:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=pKXq9IKfHQLO0hHmPppMt27LN0S6zTBZiYPVMobkeP4=; b=eA6SP3DQUg1o9BQ6KZgPfNDTn6FrczNBFbs/kFdFpeup6uEB8Y7QLA+VxyXHp5o4Jo O4PV66tBlQmnlxBKMnt9pmC7u1yM0n0dqTNKD8NCN7Ya3i34FInVmZWTRkZOYjNSOvEQ 1cKABc5mshwzhgBxNfr0GTxpX2xjMhlpZH4ps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=roclsV4DYdk5opReb8XlfaghrFVS+lErXIE2wENYkCxsXVUCf/bE2MfigjUbcSK5LD hJ+ME/NGE3rm4gwYBuTe1dYjB2jyTmIwa2JXOFmLs1V3wnXjqWJU8XqnEtz9YvOPBFjX /aTc71+bWGqENBlaACVMHNhch9Yx876qJe1wc= Received: by 10.231.121.1 with SMTP id f1mr1832946ibr.35.1301135078211; Sat, 26 Mar 2011 03:24:38 -0700 (PDT) MIME-Version: 1.0 Sender: baptiste.daroussin@gmail.com Received: by 10.231.182.76 with HTTP; Sat, 26 Mar 2011 03:24:18 -0700 (PDT) In-Reply-To: <20110325201743.20885f22@bhuda.mired.org> References: <20110325101111.GA36840@azathoth.lan> <20110325150653.21132ej6abxmjpgk@webmail.leidinger.net> <20110325201743.20885f22@bhuda.mired.org> From: Baptiste Daroussin Date: Sat, 26 Mar 2011 10:24:18 +0000 X-Google-Sender-Auth: 8duzMSo2ZrYPkKeIEISltvl4sjg Message-ID: To: Mike Meyer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install 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, 26 Mar 2011 10:51:23 -0000 2011/3/26 Mike Meyer : > On Fri, 25 Mar 2011 15:14:52 +0100 > Baptiste Daroussin wrote: >> 2011/3/25 Alexander Leidinger : >> >> - the register command can analyse elf files when registering a new p= ort >> >> to >> >> discover forgotten dependencies if necessary. (done in alpha using li= belf) >> > This will probably fail if LD_LIBRARY_PATH is used, or if we are insta= lling >> > linuxulator ports. >> this isn't activated by default, and if activated is only intended to >> work on freebsd elf files. >> This is done to workaround some bugguy ports not to be used in >> production, pkg register shows in warning in that case so that >> user/maintainers are warned they have something to fix. > > How about dealing with 32-bit x86 packages on an amd64 install? > > =A0 =A0 -- > Mike Meyer =A0 =A0 =A0 =A0 =A0 =A0 =A0http://www.mired.or= g/consulting.html > Independent Software developer/SCM consultant, email for more information= . > > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > _______________________________________________ > 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= " > 32bits x86 packages on amd64 simply are ignored by the elf introspection (currently) From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 12:16: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 8A3F7106566B; Sat, 26 Mar 2011 12:16:51 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.freebsd.org (Postfix) with ESMTP id 1ED0A8FC1C; Sat, 26 Mar 2011 12:16:50 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p2QCGmIi029069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Mar 2011 23:16:49 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p2QCGlXM003887; Sat, 26 Mar 2011 23:16:47 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p2QCGlZB003886; Sat, 26 Mar 2011 23:16:47 +1100 (EST) (envelope-from peter) Date: Sat, 26 Mar 2011 23:16:46 +1100 From: Peter Jeremy To: John Baldwin Message-ID: <20110326121646.GA2367@server.vk2pj.dyndns.org> References: <201103250818.38470.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: <201103250818.38470.jhb@freebsd.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, Jing Huang Subject: Re: [GSoc] Timeconter Performance Improvements 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, 26 Mar 2011 12:16:51 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Mar-25 08:18:38 -0400, John Baldwin wrote: >For modern Intel CPUs you can just assume that the TSCs are in sync across= =20 >packages. They also have invariant TSC's meaning that the frequency doesn= 't=20 >change. Synchronised P-state invariant TSCs vastly simplify the problem but not everyone has them. Should the fallback be more complexity to support per-CPU TSC counts and varying frequencies or a fallback to reading the time via a syscall? >I believe we already have a shared page (it holds the signal trampoline no= w) >for at least the x86 platform (probably some others as well). r217151 for amd64 and r217400 for ppc. It doesn't appear to be supported on other platforms. My reading of the code is that there is a single shared page used by all processes/CPUs. In order to support non-synchronised TSCs, this would need to be changed to per-CPU. --=20 Peter Jeremy --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk2N2S4ACgkQ/opHv/APuIfNUgCfUYaQuUIOedvWArXwv5vGU3fz NzkAoJz5/SiaU5J2gfSECav9EqAv6MgW =59We -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 13:00: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 4A9F21065670; Sat, 26 Mar 2011 13:00:35 +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 B74BA8FC08; Sat, 26 Mar 2011 13:00:34 +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 p2QD0QvU095124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Mar 2011 15:00:26 +0200 (EET) (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 p2QD0QFh059573; Sat, 26 Mar 2011 15:00:26 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2QD0QZv059572; Sat, 26 Mar 2011 15:00:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Mar 2011 15:00:26 +0200 From: Kostik Belousov To: Peter Jeremy Message-ID: <20110326130026.GZ78089@deviant.kiev.zoral.com.ua> References: <201103250818.38470.jhb@freebsd.org> <20110326121646.GA2367@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EZkH4bgFGiJLZO53" Content-Disposition: inline In-Reply-To: <20110326121646.GA2367@server.vk2pj.dyndns.org> 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, Jing Huang Subject: Re: [GSoc] Timeconter Performance Improvements 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, 26 Mar 2011 13:00:35 -0000 --EZkH4bgFGiJLZO53 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 26, 2011 at 11:16:46PM +1100, Peter Jeremy wrote: > On 2011-Mar-25 08:18:38 -0400, John Baldwin wrote: > >For modern Intel CPUs you can just assume that the TSCs are in sync acro= ss=20 > >packages. They also have invariant TSC's meaning that the frequency doe= sn't=20 > >change. >=20 > Synchronised P-state invariant TSCs vastly simplify the problem but > not everyone has them. Should the fallback be more complexity to > support per-CPU TSC counts and varying frequencies or a fallback to > reading the time via a syscall? >=20 > >I believe we already have a shared page (it holds the signal trampoline = now) > >for at least the x86 platform (probably some others as well). >=20 > r217151 for amd64 and r217400 for ppc. It doesn't appear to be > supported on other platforms. My reading of the code is that there is > a single shared page used by all processes/CPUs. In order to support > non-synchronised TSCs, this would need to be changed to per-CPU. Not neccessary. If you have a reliable way to access proper private per-CPU page from the array, then you could use the same method to access the array in the single page. IMO, per-cpu page in process address space at the same address for all pages is too costly. I think we can target a modern hardware for user-mode tsc, this is the kind of machines that are used for benchmarks anyway. --EZkH4bgFGiJLZO53 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2N42oACgkQC3+MBN1Mb4jC2gCfRfzQhjGNHLdqO78Wf+NJmz45 PRQAoNqIrLjQ7fWoVR6EeXy5aspj4GZr =BdhB -----END PGP SIGNATURE----- --EZkH4bgFGiJLZO53-- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 13:04:42 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 9344F106564A; Sat, 26 Mar 2011 13:04:42 +0000 (UTC) (envelope-from dnaeon@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 CB7738FC0A; Sat, 26 Mar 2011 13:04:41 +0000 (UTC) Received: by wwk4 with SMTP id 4so382015wwk.1 for ; Sat, 26 Mar 2011 06:04:40 -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=dllrjaKf98SLVS8i96NOegwSrv6kXj+3OJGHY6TDLa4=; b=tRqV6lU4Gi7uX33KamShOCc8rui52sWuDtXOhp7CmuXMKcThz1vW3wVB5+DSgn8KEL PIOEn1UkwHuq1wJRI6RmuiHXr3Ejcjmikl0zfhnJcPALXXMLLMS0YSH7IwR66rRTDjXH umkrxycRcWOIu2gmyrr0OOI5b51JNbkSw5Qh0= 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=XCwpZ90y6o6QzpIiV6Z1SqUKnNEjNkT+/qlyeOXZh/ehR3Vqcjre9fYoBH8H/OWAx7 ZxEHueo9ASuZMZvE7K+QruL4tx2OeCqHgR5IBTWJGD+2WSXYVCpxKOpfS5QhoCdKt+7C nqnMTTO9YeDFRiaJ7ZEc3jSQ3su2r9DKdglg8= MIME-Version: 1.0 Received: by 10.227.171.207 with SMTP id i15mr1841828wbz.121.1301143140426; Sat, 26 Mar 2011 05:39:00 -0700 (PDT) Received: by 10.227.132.73 with HTTP; Sat, 26 Mar 2011 05:39:00 -0700 (PDT) In-Reply-To: <20110325101111.GA36840@azathoth.lan> References: <20110325101111.GA36840@azathoth.lan> Date: Sat, 26 Mar 2011 14:39:00 +0200 Message-ID: From: Marin Atanasov Nikolov To: Baptiste Daroussin Content-Type: multipart/mixed; boundary=20cf30025cdeafe9f4049f61fed9 Cc: ports@freebsd.org, hackers@freebsd.org, current@freebsd.org Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install 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, 26 Mar 2011 13:04:42 -0000 --20cf30025cdeafe9f4049f61fed9 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 25, 2011 at 12:11 PM, Baptiste Daroussin wrote: > Hi all, > Hi, Great news! I'll try to contribute with what I can for this project! I've mirrored the pkgng Git repo here as well: - http://git.unix-heaven.org/cgit.cgi/pkgng/ And attached is my first patch :) Could you please review and if possible, apply it? Regards, Marin -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org http://www.unix-heaven.org/ --20cf30025cdeafe9f4049f61fed9 Content-Type: text/x-patch; charset=US-ASCII; name="0001-Clarify-a-bit-more-the-GOALS-and-some-other-minor-ch.patch" Content-Disposition: attachment; filename="0001-Clarify-a-bit-more-the-GOALS-and-some-other-minor-ch.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_glqixvfc1 RnJvbSBiZDE3YWQxZGZhMzM2NzE3ZmNjOTI0MjE3NTUyZGFkZDUyMzZlZDVmIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBNYXJpbiBBdGFuYXNvdiBOaWtvbG92IDxkYWVtb25AdW5peC1o ZWF2ZW4ub3JnPgpEYXRlOiBTYXQsIDI2IE1hciAyMDExIDE0OjE5OjA0ICswMjAwClN1YmplY3Q6 IFtQQVRDSF0gQ2xhcmlmeSBhIGJpdCBtb3JlIHRoZSBHT0FMUyBhbmQgc29tZSBvdGhlciBtaW5v ciBjaGFuZ2VzCgoJLSBDbGFyaWZ5IEdPQUxTIGEgYml0IG1vcmUKCS0gQWRkZWQgbWFpbi5oIHdo aWNoIGNvbnRhaW5zIENNRF9NQVhfTEVOCgktIFVzZSBzdHJubGVuKCkgaW5zdGVhZCBvZiBzdHJs ZW4oKSBpbiBtYWluLmMKCS0gVXNlIGZsb2F0IG51bWJlcnMgaW4gZmV0Y2hfc3RhdHVzKCkKLS0t CiBkb2NzL0dPQUxTIHwgIDE3OCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KIHBrZy9hZGQuYyAgfCAgICAyICstCiBwa2cvbWFpbi5j IHwgICAgOSArKy0tCiBwa2cvbWFpbi5oIHwgICAgNyArKysKIDQgZmlsZXMgY2hhbmdlZCwgMTI2 IGluc2VydGlvbnMoKyksIDcwIGRlbGV0aW9ucygtKQogY3JlYXRlIG1vZGUgMTAwNjQ0IHBrZy9t YWluLmgKCmRpZmYgLS1naXQgYS9kb2NzL0dPQUxTIGIvZG9jcy9HT0FMUwppbmRleCAxYzM4MWQy Li5jY2YzNDE0IDEwMDY0NAotLS0gYS9kb2NzL0dPQUxTCisrKyBiL2RvY3MvR09BTFMKQEAgLTEs MTA0ICsxLDE1MiBAQAotY29tYW1uZHM6Citwa2duZyAtIE5ldyB2ZXJzaW9uIG9mIEZyZWVCU0Qn cyBwa2dfaW5zdGFsbAorCitUYWJsZSBvZiBDb250ZW50czoKKworICAgIDEuIEF2YWlsYWJsZSBj b21tYW5kcyBvZiBwa2duZworICAgIDIuIEF2YWlsYWJsZSBzdWJjb21tYW5kcyBvZiBwa2duZwor ICAgIDMuIEdlbmVyYWwgYmVoYXZpb3VyCisgICAgNC4gTmV3IG1hbmlmZXN0IGZvcm1hdAorCTQu MS4gRHVyaW5nIG5ldyBpbnN0YWxsCisJNC4yLiBEdXJpbmcgcGFja2FnZSBkZWxldGlvbgorCTQu My4gRHVyaW5nIHVwZ3JhZGUgb2YgYSBwYWNrYWdlCisgICAgNS4gQWRkaXRpb25hbCByZXNvdXJj ZXMKKworCisxLiBBdmFpbGFibGUgY29tbWFuZHMgb2YgcGtnbmc6CistLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCisKIC0gcGtnOgotCS0gb25lIGNvbW1hbmQgdG8gcnVsZSB0aGVtIGFs bAotCS0gZWFjaCB0aW1lIHBrZyBoYXMgdG8gcXVlcnkgdGhlIGluc3RhbGxlZCBkYXRhYmFzZSBp dCB3aWxsIHRyeSB0byBmaXJzdAotCSAgcmVhZCB0aGUgY2FjaGUgaXMgdGhlIGNhY2hlIGlzIHRv byBvbGQgKGNoZWNrIGJ1dCBsYXN0IG10aW1lIG9mIHRoZQotCSAgZGlyZWN0b3J5KSBpdCB3aWxs IHJlZ2VuZXJhdGUgdGhlIGNhY2hlIGZyb20gaW5zdGFsbGVkIHBhY2thZ2UKKworCS0gT25lIGNv bW1hbmQgdG8gcnVsZSB0aGVtIGFsbAorCS0gRWFjaCB0aW1lIGBwa2cnIGhhcyB0byBxdWVyeSB0 aGUgcGFja2FnZSBkYXRhYmFzZSBpdCB3aWxsIHRyeSB0byBmaXJzdAorCSAgcmVhZCB0aGUgY2Fj aGUgYW5kIGlmIHRoZSBjYWNoZSBpcyB0b28gb2xkIChjaGVjayBieSBsYXN0IG10aW1lIG9mIHRo ZQorCSAgZGlyZWN0b3J5KSBpdCB3aWxsIHJlZ2VuZXJhdGUgdGhlIGNhY2hlIGZvciB0aGUgaW5z dGFsbGVkIHBhY2thZ2VzLgogCiAtIHBrZ18qOgotCXRoaXMgd2lsbCBiZSBzaGVsbCBzY3JpcHQg dGhlaXIgZ29hbCBpcyB0byBiZSAxMDAlIGNvbXBhdGlibGUgd2l0aAotCXBrZ19pbnN0YWxsIHRo ZXkgd2lsbCBjYWxsIHBrZyB3aGljaCB0aGUgZ29vZCBvcHRpb25zIChub3Qgc3VyZSBpdCB3aWxs Ci0JYmUgcmVhbGx5IGRvbmUgaW4gdGhlIGVuZCkKIAotc3ViY29tbWFuZHM6CisJLSBUaGVzZSB3 aWxsIGJlIHNoZWxsIHNjcmlwdHMsIHdoaWNoIGdvYWwgaXMgdG8gYmUgMTAwJSBjb21wYXRpYmxl IHdpdGgKKwkgIHBrZ19pbnN0YWxsLiBUaGV5IHdpbGwgY2FsbCBgcGtnJyB3aXRoIHRoZSBhcHBy b3ByaWF0ZSBvcHRpb25zIChub3Qgc3VyZQorCSAgaXQgd2lsbCBiZSByZWFsbHkgZG9uZSBpbiB0 aGUgZW5kKS4KKworMi4gQXZhaWxhYmxlIHN1YmNvbW1hbmRzIG9mIHBrZ25nOgorLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorCiAtIGFkZDoKLQktIGluc3RhbGxzIGEgcGFja2Fn ZSBpZiBsb2NhbCBwYWNrYWdlIGlzIGdpdmVuCi0JLSBtYW5hZ2UgaHR0cC9mdHAgdXJsIHRvIGRv d25sb2FkIHRocm91Z2h0IGxpYmZldGNoIGEgcGFja2FnZSBhbmQgdHJ5IHRvCi0JICBpbnN0YWxs IGl0LgotCS0gaW4gdGhlIHR3byBwcmV2aW91cyBjYXNlLCBpZiB0aGUgcGFja2FnZSBhcyBub3Qg aW5zdGFsbGVkIGRlcGVuZGVuY2llcwotCSAgaXQgd2lsbCB0cnkgdG8gZmV0Y2gvZmluZCB0aGVt IGluIHRoZSBzYW1lIHBsYWNlIHRoZSBvcmlnaW5hbCBwYWNrYWdlCi0JICB3YXMuCi0JLSBpdCB3 aWxsIG1hbmFnZSBhIGNvbXBsZXRlbHkgbmV3IHJlcG9zaXRvcnkgZm9ybWF0IHBrZyBhZGQgYmxh IHdpbGwKLQkgIGNoZWNrIGluIHRoZSBkYXRhYmFzZSBvZiB0aGUgcmVwb3NpdG9yeSBpZiB0aGUg aXMgYSBibGEgcGFja2FnZSBhbmQKLQkgIGluc3RhbGwgaXQgYXMgd2VsbCBhcyBpdCdzIGRlcGVu ZGVuY2llcyBidXQgdGhlIGRlcGVuZGVuY2llcyB3aWxsIGJlCi0JICBjb21wdXRlIGJlZm9yZSBi ZWdpbmluZyB0aGUgZmV0Y2ggaW5zdGFsbCBwcm9jZXNzLCB0byBiZSBzdXJlCi0JICBldmVyeXRo aW5nIGlzIG9rLgotCS0gc2hvdWxkIGJlIGFibGUgdG8gb25seSB0YWtlIGEgcGxpc3Qgb3IgYSBt YW5pZmVzdCBpbiBhcmd1bWVudAorCisJLSBJbnN0YWxscyBhIHBhY2thZ2UgaWYgYSBsb2NhbCBw YWNrYWdlIGlzIGdpdmVuCisJLSBNYW5hZ2VzIGZ0cC9odHRwIGRvd25sb2FkcyBvZiBwYWNrYWdl cyB0aHJvdWdoIGxpYmZldGNoIGFuZAorCSAgdHJpZXMgdG8gaW5zdGFsbCB0aGVtLgorCS0gSW4g dGhlIHR3byBwcmV2aW91cyBjYXNlcywgaWYgYSBwYWNrYWdlIGRvZXMgbm90IGhhdmUgaXQncyAK KwkgIGRlcGVuZGVuY2llcyBpbnN0YWxsZWQsIGBwa2duZycgd2lsbCB0cnkgdG8gZmV0Y2gvZmlu ZCB0aGVtIGluIHRoZSBzYW1lCisJICBwbGFjZSBhcyB0aGUgb3JpZ2luYWwgcGFja2FnZSB3YXMu CisJLSBJdCB3aWxsIG1hbmFnZSBhIGNvbXBsZXRlbHkgbmV3IHJlcG9zaXRvcnkgZm9ybWF0LiAK KwkgIGBwa2cgYWRkIDxmb28+JyB3aWxsIGNoZWNrIGluIHRoZSBkYXRhYmFzZSBvZiB0aGUgcmVw b3NpdG9yeSBmb3IgCisJICBwYWNrYWdlIDxmb28+IGFuZCB0cnkgdG8gaW5zdGFsbCBpdCBhcyB3 ZWxsIGFzIGl0J3MgZGVwZW5kZW5jaWVzLgorCSAgRGVwZW5kZW5jaWVzIHdpbGwgYmUgY29tcHV0 ZWQgYmVmb3JlIGJlZ2lubmluZyB0aGUgZmV0Y2gvaW5zdGFsbAorCSAgcHJvY2VzcyB0byBlbnN1 cmUgdGhhdCBldmVyeXRoaW5nIHdpbGwgYmUgT0suCisJLSBTaG91bGQgYmUgYWJsZSB0byBvbmx5 IHRha2UgYSBwbGlzdCBvciBhIG1hbmlmZXN0IGluIGFyZ3VtZW50CiAJICBjb25zaWRlcmluZyB0 aGUgZmlsZXMgYXJlIGFscmVhZHkgaW5zdGFsbGVkCiAKIC0gcmVwbzoKLQktIHRha2VzIG9ubHkg b25lIGFyZ3VtZW50IGFuZCBnZW5lcmF0ZSB0d28gZGF0YWJhc2VzIGZpbGVzIChtYXliZSBtb3Jl IGZvcgotCSAgdGhlIHRpbWUgd2Ugd2lsbCBiZSB3aWxsaW5nIHRvIHdvcmsgd2l0aCBVUERBVElO RyBhbmQgTU9WRUQpIHRoZSBmaXJzdAotCSAgcmVwbyBjb250YWluIGV2ZXJ5IGluZm9ybWF0aW9u cyBjb25jZXJuaW5nIGEgcGFja2FnZSBleGNlcHQgZmlsZXMKLQkgICh3aGljaCB3aWxsIGJlIGlu IHRoZSBzZWNvbmQgb25lKSArIGl0IHdpbGwgY29tcHV0ZSBhbmQgYWRkIGEgc2hhMjU2Ci0JICBz dW0gZm9yIGVhY2ggcGFja2FnZS4KLQkgIHRoZSBkYXRhYmFzZSB3aWxsIGJlIGEgc3FsaXRlIGZp bGUgY29tcHJlc3NlZCB3aXRoIHRoZSB4eiBmb3JtYXQuCi0JICB0aGUgZGF0YWJhc2Ugd2lsbCBi ZSBzaWduZWQgc28gd2UgY2FuIHRydXN0IHRoZSBzaGEyNTYgb2YgdGhlCi0JICBwYWNrYWdlcywg c28gaWYgYSBwYWNrYWdlIGhhcyB0aGUgZXhwZWN0ZWQgaGFzaCwgaXQgaXMgY29uc2lkZXJlZAor CisJLSBUYWtlcyBvbmx5IG9uZSBhcmd1bWVudCBhbmQgZ2VuZXJhdGVzIHR3byBkYXRhYmFzZSBm aWxlcyAobWF5YmUgbW9yZSBmb3IKKwkgIHRoZSB0aW1lIHdlIHdpbGwgYmUgd2lsbGluZyB0byB3 b3JrIHdpdGggVVBEQVRJTkcgYW5kIE1PVkVEKS4KKwkgIFRoZSBmaXJzdCByZXBvIGNvbnRhaW5z IGFsbCBpbmZvcm1hdGlvbiBhYm91dCBhIHBhY2thZ2UsIGV4Y2VwdCBmb3IKKwkgIHRoZSBmaWxl cyAod2hpY2ggd2lsbCBiZSBpbiB0aGUgc2Vjb25kIG9uZSkgKyBpdCB3aWxsIGNvbXB1dGUgYW5k IAorCSAgYWRkIGEgc2hhMjU2IHN1bSBmb3IgZWFjaCBwYWNrYWdlLgorCS0gVGhlIGRhdGFiYXNl IHdpbGwgYmUgYSBzcWxpdGUgZmlsZSBjb21wcmVzc2VkIHdpdGggdGhlIHh6IGZvcm1hdC4KKwkt IFRoZSBkYXRhYmFzZSB3aWxsIGJlIHNpZ25lZCBzbyB3ZSBjYW4gdHJ1c3QgdGhlIHNoYTI1NiBv ZiB0aGUKKwkgIHBhY2thZ2VzLCBhbmQgaWYgYSBwYWNrYWdlIGhhcyB0aGUgZXhwZWN0ZWQgaGFz aCwgaXQgaXMgY29uc2lkZXJlZAogCSAgdHJ1c3RlZC4KIAogLSBzZWFyY2g6Ci0JLSB3aWxsIHNl YXJjaCBib3RoIHRoZSByZW1vdGUgcmVwb3NpdG9yeSB0byBnaXZlcyBpbmZvcm1hdGlvbnMKLQkg IHRvIHVzZXJzCisKKwktIFdpbGwgc2VhcmNoIGJvdGggb2YgdGhlIHJlbW90ZSByZXBvc2l0b3Jp ZXMgdG8gcHJvdmlkZSBpbmZvcm1hdGlvbgorCSAgdG8gdGhlIHVzZXJzLgogCiAtIGluZm86IAot CS0gd2lsbCBnaXZlIHRvIHVzZXJzIGFueSBpbmZvcm1hdGlvbnMgYWJvdXQgbG9jYWwgcGFja2Fn ZQorCisJLSBXaWxsIHByb3ZpZGUgYW55IGluZm9ybWF0aW9uIHRvIHRoZSB1c2VycyBhYm91dCBh IGxvY2FsIHBhY2thZ2UuCiAKIC0gY3JlYXRlOgotCS0gd2lsbCBjcmVhdGUgdGhlIHBhY2thZ2Ug aW4gdGhlIG5ldyBmb3JtYXQgKCtNQU5JRkVTVCkgaW4gdHh6ICh0YXIueHopCi0JICBkaXJlY3Rs eSBvcHRpb25zIHRvIGNyZWF0ZSB0YnogYW5kIHRneiB3aWxsIGJlIHByb3ZpZGVkLgotCS0gaXQg c2hvdWxkIGJlIGFibGUgdG8gY3JlYXRlIGEgcGFja2FnZSBmb3IgYSAiZmFrZXJvb3QiIGRpcmVj dG9yeQorICAgIAorCS0gV2lsbCBjcmVhdGUgdGhlIHBhY2thZ2UgaW4gdGhlIG5ldyBmb3JtYXQg KCtNQU5JRkVTVCkgaW4gdHh6ICh0YXIueHopLgorCS0gT3B0aW9ucyBmb3IgY3JlYXRpbmcgdGJ6 IGFuZCB0Z3ogd2lsbCBiZSBwcm92aWRlZC4KKwktIEl0IHNob3VsZCBiZSBhYmxlIHRvIGNyZWF0 ZSBhIHBhY2thZ2UgZm9yIGEgImZha2Vyb290IiBkaXJlY3RvcnkKIAkgIHRha2luZyBhIHBsaXN0 IG9yIGEgbWFuaWZlc3QgaW4gYXJndW1lbnRzICh0aGUgcGxpc3QgaXMgZm9yCi0JICBjb21wYXRp YmlsaXR5IHdoaWNoIGJzZC5wb3J0cy5taworCSAgY29tcGF0aWJpbGl0eSB3aXRoIGJzZC5wb3J0 cy5taykKIAogLSBkZWxldGU6Ci0JLSB3aWxsIGRlbGV0ZSBhIHBhY2thZ2Ugbm9ybWFsbHkgdG8g YmUgYWJsZSB0byByZW1vdmUgdGhlIGVtcHR5Ci0JICBkaXJlY3RvcmllcyBjbGVhbmx5IGl0IHdp bGwgZGVsZXRlIGV2ZXJ5IGRpcmVjdG9yeSAoZm91bmQgaW4gdGhlIHBhdGgKLQkgIG9mIHRoZSBm aWxlcykgdGhhdCBhcmUgbm90IGluIHRoZSBwYWNrYWdlICtNVFJFRSAobXRyZWUgY29udGFpbnMg dGhlCi0JICBvZmZpY2lhbCBoaWVyKDcpCisKKwktIFdpbGwgZGVsZXRlIGEgcGFja2FnZS4gVG8g YmUgYWJsZSB0byByZW1vdmUgdGhlIGVtcHR5IGRpcmVjdG9yaWVzCisJICBjbGVhbmx5IGl0IHdp bGwgZGVsZXRlIGV2ZXJ5IGRpcmVjdG9yeSAoZm91bmQgaW4gdGhlIHBhdGggb2YgdGhlIAorCSAg ZmlsZXMpLCB3aGljaCBhcmUgbm90IGluIHRoZSBwYWNrYWdlICtNVFJFRSAobXRyZWUgY29udGFp bnMgdGhlIAorCSAgb2ZmaWNpYWwgaGllcig3KSkuCiAKIC0gdXBncmFkZToKLQktIHdpbGwgY29t cHV0ZSB0aGUgcmVtb3RlIHJlcG9zaXRvcnkgdG8gY2hlY2sgaXMgdGhlcmUgaXMgbmV3IHVwZ3Jh ZGVzCisKKwktIFdpbGwgY29tcHV0ZSB0aGUgcmVtb3RlIHJlcG9zaXRvcnkgdG8gY2hlY2sgaWYg dGhlcmUgYXJlIG5ldyB1cGdyYWRlcwogCSAgYXZhaWxhYmxlIGFuZCBhcHBseSB0aGVtLgogCiAt IHVwZGF0ZToKLQktIHdpbGwgZmV0Y2ggdGhlIHJlbW90ZSByZXBvc2l0b3J5IGNhY2hlIGZpbGVz CisKKwktIFdpbGwgZmV0Y2ggdGhlIHJlbW90ZSByZXBvc2l0b3J5IGNhY2hlIGZpbGVzLgogCiAt IGxpbnQ6IAotCS0gd2lsbCBjaGVjayBmb3IgdGhlIGdpdmVuIHBhY2thZ2UgYW5kIHdhcm4gdGhl IHVzZXIgYWJvdXQgcHJvYmxlbXMgOgorCisJLSBXaWxsIGNoZWNrIGZvciB0aGUgZ2l2ZW4gcGFj a2FnZSBhbmQgd2FybiB0aGUgdXNlciBhYm91dCBwb3NzaWJsZSBwcm9ibGVtczoKIAkqIGJhZCBw cmVmaXgKIAkqIHNldHVpZHMKIAkqIGV0YwogCi1HZW5lcmFsIGJlaGF2aW91cjoKLXRoZSBtYW5p ZmVzdCBjb250YWlucyBjb21wYXRpYmlsaXR5IGtleXdvcmRzOiBleGVjLCB1bmV4ZWMgd2hpY2gg d2lsbCBiZQotZXhlY3V0ZWQgYXMgdGhlcmUgYXJlIGluIHBrZ19pbnN0YWxsIGJ1dCB3aWxsIGRp c3BsYXkgYSB3YXJuaW5nIHRvIHNob3cgdGhlIHVzZXIKLWV4ZWMvdW5leGVjIGlzIGRlcHJlY2F0 ZWQKKzMuIEdlbmVyYWwgYmVoYXZpb3VyOgorLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisKK1RoZSBt YW5pZmVzdCBjb250YWlucyBjb21wYXRpYmlsaXR5IGtleXdvcmRzOiBleGVjLCB1bmV4ZWMgd2hp Y2ggd2lsbCBiZQorZXhlY3V0ZWQgYXMgdGhleSBhcmUgaW4gcGtnX2luc3RhbGwsIGJ1dCB3aWxs IGRpc3BsYXkgYSB3YXJuaW5nIHRvIHNob3cgdGhlIHVzZXIKK2V4ZWMvdW5leGVjIGlzIGRlcHJl Y2F0ZWQuCisKK0lmIGluc3RhbGwgYW5kIGRlaW5zdGFsbCBzY3JpcHRzIGFyZSBwcmVzZW50IHRo ZXkgd2lsbCBiZSBleGVjdXRlZCBhcyB0aGV5IHdlcmUgaW4KK3BrZ19pbnN0YWxsLCBhbmQgdGhl IHVzZXIgd2lsbCBiZSB3YXJuZWQgdGhhdCB0aGV5IGFyZSBkZXByZWNhdGVkLgorCis0LiBOZXcg bWFuaWZlc3QgZm9ybWF0CistLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisKK1RoZSBuZXcgbWFuaWZl c3QgZm9ybWF0IHdpbGwgaGF2ZToKIAotaWYgaW5zdGFsbCBhbmQgZGVpbnN0YWxsIHNjcmlwdHMg YXJlIGZvdW5kIHRoZXkgd2lsbCBiZSBleGVjdXRlZCBhcyB0aGV5IHdlcmUgaW4KLXBrZ19pbnN0 YWxsIHdhcm5pbmcgZm9yIGRlcHJlY2F0ZWQKKyAgICA0LjEuIER1cmluZyBuZXcgaW5zdGFsbAor ICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisgICAgCisgICAgLSBwcmUtaW5zdGFsbAorICAg IC0gcG9zdC1pbnN0YWxsCiAKLXRoZSBuZXcgbWFuaWZlc3QgZm9ybWF0IHdpbGwgaGF2ZToKLWlu IGNhc2Ugb2YgYSBuZXcgaW5zdGFsbDoKLXByZS1pbnN0YWxsCi1wb3N0LWluc3RhbGwKKyAgICA0 LjIuIER1cmluZyBwYWNrYWdlIGRlbGV0aW9uCisgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQogCi1pbiBjYXNlIG9mIGEgcGtnIGRlbGV0ZToKLXByZS11bmluc3RhbGwKLXBvc3QtdW5p bnN0YWxsCisgICAgLSBwcmUtdW5pbnN0YWxsCisgICAgLSBwb3N0LXVuaW5zdGFsbAogCi1pbiBj YXNlIG9mIGFuIHVwZ3JhZGUgOiAKLXByZS11cGdyYWRlCi1wb3N0LXVwZ3JhZGUKKyAgICA0LjMu IER1cmluZyB1cGdyYWRlIG9mIGEgcGFja2FnZQorICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tCisKKyAgICAtIHByZS11cGdyYWRlCisgICAgLSBwb3N0LXVwZ3JhZGUKKworVGhl eSBjb3VsZCBiZSBmaWxlcyAtICtQUkUtKiwgK1BPU1QtKiwgZXRjLgorCitUaGV5IGNvdWxkIGJl IHNoIHN0cmluZyBpbiB0aGUgbWFuaWZlc3QgaW4gYXJyYXlzOgogCi10aGV5IGNvdWxkIGJlIGZp bGVzICtQUkUtKiArUE9TVCogZXRjCi10aGV5IGNvdWxkIGJlIHNoIHN0cmluZyBpbiB0aGUgbWFu aWZlc3QgaW4gYXJyYXlzOgogInByZS1pbnN0YWxsIjogWwogICAgICAgICAiL3Vzci9zYmluL3B3 IHVzZXJhZGQgZm9vIiwKIF0sCiAKLXRoZXkgY291bGQgYmUgYm90aAorVGhleSBjb3VsZCBiZSBi b3RoLgorCis1LiBBZGRpdGlvbmFsIHJlc291cmNlcworLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K KworU29tZSBpbmZvcm1hdGlvbiBjYW4gYmUgZm91bmQgaGVyZSBhbmQgaWYgdGhlcmUgYXJlIGNv bmZsaWN0cywgdGhpcyBmaWxlCitpcyByaWdodCBvbmUgOikKKworICAgIC0gaHR0cDovL3dpa2ku ZnJlZWJzZC5vcmcvUGtnX2luc3RhbGwyX3NwZWNzCiAKLXNvbWUgaW5mb3JtYXRpb25zIGNvdWxk IGJlIGZvdW5kIGhlcmUgaWYgdGhlcmUgaXMgY29uZmxpY3RzIGluIHRoZSB0d28sIHRoaXMgZmls ZQotaXMgcmlnaHQgOik6Ci1odHRwOi8vd2lraS5mcmVlYnNkLm9yZy9Qa2dfaW5zdGFsbDJfc3Bl Y3MKZGlmZiAtLWdpdCBhL3BrZy9hZGQuYyBiL3BrZy9hZGQuYwppbmRleCA1MDc1OGI0Li4yMmNi NzJkIDEwMDY0NAotLS0gYS9wa2cvYWRkLmMKKysrIGIvcGtnL2FkZC5jCkBAIC0xOCw3ICsxOCw3 IEBAIGZldGNoX3N0YXR1cyh2b2lkICpkYXRhLCBjb25zdCBjaGFyICp1cmwsIG9mZl90IHRvdGFs LCBvZmZfdCBkb25lLCB0aW1lX3QgZWxhcHNlCiAJZGF0YSA9IE5VTEw7CiAJZWxhcHNlZCA9IDA7 CiAKLQlwZXJjZW50ID0gKChmbG9hdClkb25lIC8gKGZsb2F0KXRvdGFsKSAqIDEwMDsKKwlwZXJj ZW50ID0gKChmbG9hdClkb25lIC8gKGZsb2F0KXRvdGFsKSAqIDEwMC4wOwogCXByaW50ZigiXHJG ZXRjaGluZyAlcy4uLiAlZCUlIiwgdXJsLCBwZXJjZW50KTsKIAogCWlmIChkb25lID09IHRvdGFs KQpkaWZmIC0tZ2l0IGEvcGtnL21haW4uYyBiL3BrZy9tYWluLmMKaW5kZXggZWRmNmYzZi4uZjQ2 NjEwZCAxMDA2NDQKLS0tIGEvcGtnL21haW4uYworKysgYi9wa2cvbWFpbi5jCkBAIC01LDYgKzUs NyBAQAogI2luY2x1ZGUgPHN0cmluZy5oPgogI2luY2x1ZGUgPHN5c2V4aXRzLmg+CiAKKyNpbmNs dWRlICJtYWluLmgiCiAjaW5jbHVkZSAiY3JlYXRlLmgiCiAjaW5jbHVkZSAiZGVsZXRlLmgiCiAj aW5jbHVkZSAiaW5mby5oIgpAQCAtNTksMTEgKzYwLDExIEBAIGV4ZWNfaGVscChpbnQgYXJnYywg Y2hhciAqKmFyZ3YpCiB7CiAJaWYgKGFyZ2MgIT0gMikgewogCQl1c2FnZV9oZWxwKCk7Ci0JCXJl dHVybihFWF9VU0FHRSk7CisJCXJldHVybiAoRVhfVVNBR0UpOwogCX0KIAogCWZvciAoaW50IGkg PSAwOyBpIDwgY21kX2xlbjsgaSsrKSB7Ci0JCWlmIChzdHJjbXAoY21kW2ldLm5hbWUsIGFyZ3Zb MV0pID09IDApIHsKKwkJaWYgKHN0cm5jbXAoY21kW2ldLm5hbWUsIGFyZ3ZbMV0sIENNRF9NQVhf TEVOKSA9PSAwKSB7CiAJCQlhc3NlcnQoY21kW2ldLnVzYWdlICE9IE5VTEwpOwogCQkJY21kW2ld LnVzYWdlKCk7CiAJCQlyZXR1cm4gKDApOwpAQCAtODYsMTEgKzg3LDExIEBAIG1haW4oaW50IGFy Z2MsIGNoYXIgKiphcmd2KQogCWlmIChhcmdjIDwgMikKIAkJdXNhZ2UoKTsKIAotCWxlbiA9IHN0 cmxlbihhcmd2WzFdKTsKKwlsZW4gPSBzdHJubGVuKGFyZ3ZbMV0sIENNRF9NQVhfTEVOKTsKIAlm b3IgKGkgPSAwOyBpIDwgY21kX2xlbjsgaSsrKSB7CiAJCWlmIChzdHJuY21wKGFyZ3ZbMV0sIGNt ZFtpXS5uYW1lLCBsZW4pID09IDApIHsKIAkJCS8qIGlmIHdlIGhhdmUgdGhlIGV4YWN0IGNtZCAq LwotCQkJaWYgKGxlbiA9PSBzdHJsZW4oY21kW2ldLm5hbWUpKSB7CisJCQlpZiAobGVuID09IHN0 cm5sZW4oY21kW2ldLm5hbWUsIENNRF9NQVhfTEVOKSkgewogCQkJCWNvbW1hbmQgPSAmY21kW2ld OwogCQkJCWFtYmlndW91cyA9IDA7CiAJCQkJYnJlYWs7CmRpZmYgLS1naXQgYS9wa2cvbWFpbi5o IGIvcGtnL21haW4uaApuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi5lMTJiNGVi Ci0tLSAvZGV2L251bGwKKysrIGIvcGtnL21haW4uaApAQCAtMCwwICsxLDcgQEAKKyNpZm5kZWYg X01BSU5fSAorI2RlZmluZSBfTUFJTl9ICisKKyNkZWZpbmUgQ01EX01BWF9MRU4gMzIgCisKKyNl bmRpZgorCi0tIAoxLjcuMi4zCgo= --20cf30025cdeafe9f4049f61fed9-- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 14:12: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 763251065676 for ; Sat, 26 Mar 2011 14:12:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4AF338FC12 for ; Sat, 26 Mar 2011 14:12:35 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D46A046B51; Sat, 26 Mar 2011 10:12:34 -0400 (EDT) Received: from kavik.baldwin.cx (c-68-36-150-83.hsd1.nj.comcast.net [68.36.150.83]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 633D58A01B; Sat, 26 Mar 2011 10:12:34 -0400 (EDT) From: John Baldwin To: Peter Jeremy Date: Sat, 26 Mar 2011 10:12:32 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-RC1; KDE/4.5.5; i386; ; ) References: <201103250818.38470.jhb@freebsd.org> <20110326121646.GA2367@server.vk2pj.dyndns.org> In-Reply-To: <20110326121646.GA2367@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201103261012.32884.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Sat, 26 Mar 2011 10:12:34 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, Jing Huang Subject: Re: [GSoc] Timeconter Performance Improvements 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, 26 Mar 2011 14:12:35 -0000 On Saturday, March 26, 2011 08:16:46 am Peter Jeremy wrote: > On 2011-Mar-25 08:18:38 -0400, John Baldwin wrote: > >For modern Intel CPUs you can just assume that the TSCs are in sync across > >packages. They also have invariant TSC's meaning that the frequency > >doesn't change. > > Synchronised P-state invariant TSCs vastly simplify the problem but > not everyone has them. Should the fallback be more complexity to > support per-CPU TSC counts and varying frequencies or a fallback to > reading the time via a syscall? I think we should just fallback to a syscall in that case. We will also need to do that if the TSC is not used as the timecounter (or always duplicate the ntp_adjtime() work we do for the current timecounter for the TSC timecounter). Doing this easy case may give us the most bang for the buck, and it is also a good first milestone. Once that is in place we can decide what the value is in extending it to support harder variations. One thing we do need to think about is if the shared page should just export a fixed set of global data, or if it should export routines. The latter approach is more complex, but it makes the ABI boundary between userland and the kernel more friendly to future changes. I believe Linux does the latter approach? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 14:43: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 B1709106566B for ; Sat, 26 Mar 2011 14:43:04 +0000 (UTC) (envelope-from jing.huang.pku@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 500788FC08 for ; Sat, 26 Mar 2011 14:43:03 +0000 (UTC) Received: by qyk35 with SMTP id 35so253103qyk.13 for ; Sat, 26 Mar 2011 07:43: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 :content-transfer-encoding; bh=ASNbEmPP+JE/X3fpIGBYW/ByjJQldTd8CB8n/83t+7U=; b=NHGey5fmtUUAg11zssv1Zn5ZvNRC6dy4RJX0eFxJz8xzsmLYKDcDZXIZ0/9LfaFBXq QZ77eyU6K8Vm0hpdOwHSjjpTqd/KGWERSzrmIBscGGupGePC3zk42ydrjXccShIVG+1A vbOe1erX1O3JNs3rrtDbqlmT5dGXUE1cwV4ak= 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=XN43/obJiaLMDtb2Xshe/czjc+rYnfe6T0ayGsOyOqUO53aXsczabEpGxCbOh4JSUF k+WUsmCJC/rbeHd8XDDALcGWR7J6FuajSIiyPVoGBcqKGMVBfRXMv20Ff+zLpjXeBLAK D6NqgqMWtrRIqJp/IdMn6Gl6CrEbt3IIUO+Vc= MIME-Version: 1.0 Received: by 10.229.141.129 with SMTP id m1mr1688753qcu.52.1301150583554; Sat, 26 Mar 2011 07:43:03 -0700 (PDT) Received: by 10.229.100.132 with HTTP; Sat, 26 Mar 2011 07:43:03 -0700 (PDT) In-Reply-To: <201103261012.32884.jhb@freebsd.org> References: <201103250818.38470.jhb@freebsd.org> <20110326121646.GA2367@server.vk2pj.dyndns.org> <201103261012.32884.jhb@freebsd.org> Date: Sat, 26 Mar 2011 22:43:03 +0800 Message-ID: From: Jing Huang To: John Baldwin Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: kostikbel@gmail.com, freebsd-hackers@freebsd.org Subject: Re: [GSoc] Timeconter Performance Improvements 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, 26 Mar 2011 14:43:04 -0000 Hi, Thanks for you all sincerely. Under your guidance, I read the specification of TSC in Intel Manual and learned the hardware feature of TSC: Processor families increment the time-stamp counter differently: =95 For Pentium M processors (family [06H], models [09H, 0DH]); for Pent= ium 4 processors, Intel Xeon processors (family [0FH], models [00H, 01H, or 02H])= ; and for P6 family processors: the time-stamp counter increments with every internal processor clock cycle. =95 For Pentium 4 processors, Intel Xeon processors (family [0FH], models [03H and higher]); for Intel Core Solo and Intel Core Duo processors (family [06H], = model [0EH]); for the Intel Xeon processor 5100 series and Intel Core 2 Duo proce= ssors (family [06H], model [0FH]); for Intel Core 2 and Intel Xeon processors (fa= mily [06H], display_model [17H]); for Intel Atom processors (family [06H], display_model [1CH]): the time-stamp counter increments at a constant rate. Maybe we would implement gettimeofday as fellows. Firstly, use cpuid to find the family and models of current CPU. If the CPU support constant TSC, we look up the shared page and calculate the precise time in usermode. If the platform has invariant TSCs, and we just fallback to a syscall. So, I think a single global shared page maybe proper. On Sat, Mar 26, 2011 at 10:12 PM, John Baldwin wrote: > On Saturday, March 26, 2011 08:16:46 am Peter Jeremy wrote: >> On 2011-Mar-25 08:18:38 -0400, John Baldwin wrote: >> >For modern Intel CPUs you can just assume that the TSCs are in sync acr= oss >> >packages. =A0They also have invariant TSC's meaning that the frequency >> >doesn't change. >> >> Synchronised P-state invariant TSCs vastly simplify the problem but >> not everyone has them. =A0Should the fallback be more complexity to >> support per-CPU TSC counts and varying frequencies or a fallback to >> reading the time via a syscall? > > I think we should just fallback to a syscall in that case. =A0We will als= o need > to do that if the TSC is not used as the timecounter (or always duplicate= the > ntp_adjtime() work we do for the current timecounter for the TSC timecoun= ter). > > Doing this easy case may give us the most bang for the buck, and it is al= so a > good first milestone. =A0Once that is in place we can decide what the val= ue is > in extending it to support harder variations. > > One thing we do need to think about is if the shared page should just exp= ort a > fixed set of global data, or if it should export routines. =A0The latter > approach is more complex, but it makes the ABI boundary between userland = and > the kernel more friendly to future changes. =A0I believe Linux does the l= atter > approach? > > -- > John Baldwin > From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 14:51: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 A9DB6106566C; Sat, 26 Mar 2011 14:51:28 +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 3E3E08FC0C; Sat, 26 Mar 2011 14:51:27 +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 p2QEpKQ1003717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Mar 2011 16:51:20 +0200 (EET) (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 p2QEpKku060057; Sat, 26 Mar 2011 16:51:20 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2QEpKF6060056; Sat, 26 Mar 2011 16:51:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Mar 2011 16:51:20 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20110326145120.GC78089@deviant.kiev.zoral.com.ua> References: <201103250818.38470.jhb@freebsd.org> <20110326121646.GA2367@server.vk2pj.dyndns.org> <201103261012.32884.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="83IWDyxC26lT0edO" Content-Disposition: inline In-Reply-To: <201103261012.32884.jhb@freebsd.org> 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, Jing Huang Subject: Re: [GSoc] Timeconter Performance Improvements 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, 26 Mar 2011 14:51:28 -0000 --83IWDyxC26lT0edO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 26, 2011 at 10:12:32AM -0400, John Baldwin wrote: > On Saturday, March 26, 2011 08:16:46 am Peter Jeremy wrote: > > On 2011-Mar-25 08:18:38 -0400, John Baldwin wrote: > > >For modern Intel CPUs you can just assume that the TSCs are in sync ac= ross > > >packages. They also have invariant TSC's meaning that the frequency > > >doesn't change. > >=20 > > Synchronised P-state invariant TSCs vastly simplify the problem but > > not everyone has them. Should the fallback be more complexity to > > support per-CPU TSC counts and varying frequencies or a fallback to > > reading the time via a syscall? >=20 > I think we should just fallback to a syscall in that case. We will also = need=20 > to do that if the TSC is not used as the timecounter (or always duplicate= the=20 > ntp_adjtime() work we do for the current timecounter for the TSC timecoun= ter). >=20 > Doing this easy case may give us the most bang for the buck, and it is al= so a=20 > good first milestone. Once that is in place we can decide what the value= is=20 > in extending it to support harder variations. >=20 > One thing we do need to think about is if the shared page should just exp= ort a > fixed set of global data, or if it should export routines. The latter=20 > approach is more complex, but it makes the ABI boundary between userland = and=20 > the kernel more friendly to future changes. I believe Linux does the lat= ter=20 > approach? Linux uses a so-called vdso, which is linked into the process. I think that the efforts to implement a vdso approximately equal to the efforts required to implement timecounters in the user mode. On the other hand, with vdso we could properly annotate signal trampolines with the unwind info, that is also a big win. --83IWDyxC26lT0edO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2N/WgACgkQC3+MBN1Mb4iLhACgjFUKhs+u3z+ix1npeg90b/SW 5twAmwauqkkhMeWxuTktDGfKps/j86ab =Dn/T -----END PGP SIGNATURE----- --83IWDyxC26lT0edO-- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 16:37:14 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 78AAA1065670 for ; Sat, 26 Mar 2011 16:37:14 +0000 (UTC) (envelope-from vrachil@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 31DEB8FC13 for ; Sat, 26 Mar 2011 16:37:13 +0000 (UTC) Received: by qyk27 with SMTP id 27so1422526qyk.13 for ; Sat, 26 Mar 2011 09:37:13 -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=uByGHAMUniMu0Xs9fMcvzJ7R88SSjjDelZ6Mp2A0b7I=; b=OpvhQzocGQrVOb3TPnoAnZd2Px2xGtAAAxg8HwPNaSQMaP0icKFTSCr8Ky+HX+h6GO 6CbA8MtgYOZXxi6lw7HrIyYCypKAOrRVJEe8uVdaAmv6boNFFvEXewWC+V9Ti7NFNK5U APIMfk/M8YLVkJ09RXiNJSxlasDR0O0vt2h2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=YNWpVB+WHerlFXlhDhIncO+Ax/MU8i6JN6yTQrw4remYO1sGXCkaLPHUsFyxR2DLDN lz9ju8mj6mFw/OAgD4itGPggVdO2hqgmKglABGKFhzYXguPI7ZKJEX4E5ilruw8rB6GH cLj/DT8SXTaZMz+IIh3/WZ//h6vR7YGsonCfo= Received: by 10.229.44.129 with SMTP id a1mr1724701qcf.228.1301155815117; Sat, 26 Mar 2011 09:10:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.245.204 with HTTP; Sat, 26 Mar 2011 09:09:55 -0700 (PDT) From: Ilias-Dimitrios Vrachnis Date: Sat, 26 Mar 2011 18:09:55 +0200 Message-ID: To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: [SoC] Jails management webui 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, 26 Mar 2011 16:37:14 -0000 Hello, my name is Ilias, and I am a student from Greece. I wanted to propose an idea for this year's summer of code, but I am not sure how useful it actually is for others. I would like to create a webui to manage the jails on a system. The only other alternative I could find at the moment is a webmin plugin. The thing is that webmin is a fairly generic tool that can do a lot of things. My idea was to create a django-based application designed specifically for jail management and deployment. Does this functionality actually appeal to people? Is it feasible as a SoC project? Regards, Ilias From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 17:46:29 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 3F9EE106566B for ; Sat, 26 Mar 2011 17:46:29 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id 2BA738FC14 for ; Sat, 26 Mar 2011 17:46:28 +0000 (UTC) Received: from [173.241.25.35] (port=49618 helo=[10.0.0.103]) by postoffice.vicor.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.74) (envelope-from ) id 1Q3X7o-0005SF-6u; Sat, 26 Mar 2011 10:18:10 -0700 References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <880CCF47-FE30-4092-BDBA-825414E347D3@vicor.com> X-Mailer: iPhone Mail (8C148) From: Devin Teske Date: Sat, 26 Mar 2011 10:18:06 -0700 To: Ilias-Dimitrios Vrachnis X-Scan-Signature: 3ac2881c5dcc75402359056e13437500 X-Scan-Host: postoffice.vicor.com Cc: "hackers@freebsd.org" Subject: Re: [SoC] Jails management webui 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, 26 Mar 2011 17:46:29 -0000 On Mar 26, 2011, at 9:09 AM, Ilias-Dimitrios Vrachnis wr= ote: > Hello, >=20 > my name is Ilias, and I am a student from Greece. > I wanted to propose an idea for this year's summer of code, > but I am not sure how useful it actually is for others. >=20 > I would like to create a webui to manage the jails on a system. > The only other alternative I could find at the moment is > a webmin plugin. The thing is that webmin is a fairly generic tool > that can do a lot of things. My idea was to create a django-based > application designed specifically for jail management and deployment. >=20 > Does this functionality actually appeal to people? I think this is a great idea. > Is it feasible as a SoC project? I think that your best chance at success is going to be to design your proje= ct around the fact that the jail management landscape (in the scope of both t= he utilities offered in the base for managing jails at the command-line and t= he capabilities of what a jail can do such as mount ''jail-friendly'' vfs ty= pes when allowed via sysctl-knob, etc). There are several e-mails in the -jail@ list which can provide a good idea a= s to the direction of the jail landscape. So, for example, I'd design a web interface that has the ability to mount NFS= from within the jail (via jexec perhaps) not just into the jail (from the b= ase-host). Even though ZFS is about the only ''jail-friendly'' vfs type, NFS= should eventually make it's way into that group, and once it does, it would= be nice if the web interface either supported it or was modular enough to e= xtend the capability to support said feature. --=20 Cheers, Devin > Regards, > Ilias > _______________________________________________ > 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 Sat Mar 26 17:46:29 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 41BEC106566C for ; Sat, 26 Mar 2011 17:46:29 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id 2C82E8FC16 for ; Sat, 26 Mar 2011 17:46:28 +0000 (UTC) Received: from [173.241.25.35] (port=49621 helo=[10.0.0.103]) by postoffice.vicor.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.74) (envelope-from ) id 1Q3X9z-0005So-Iu; Sat, 26 Mar 2011 10:20:25 -0700 References: <880CCF47-FE30-4092-BDBA-825414E347D3@vicor.com> In-Reply-To: <880CCF47-FE30-4092-BDBA-825414E347D3@vicor.com> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8C148) From: Devin Teske Date: Sat, 26 Mar 2011 10:20:23 -0700 To: Devin Teske X-Scan-Signature: c66048eb54ba88ba13f9c2ee4f43f66f X-Scan-Host: postoffice.vicor.com Cc: Ilias-Dimitrios Vrachnis , "hackers@freebsd.org" Subject: Re: [SoC] Jails management webui 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, 26 Mar 2011 17:46:29 -0000 On Mar 26, 2011, at 10:18 AM, Devin Teske wrote: > On Mar 26, 2011, at 9:09 AM, Ilias-Dimitrios Vrachnis w= rote: >=20 >> Hello, >>=20 >> my name is Ilias, and I am a student from Greece. >> I wanted to propose an idea for this year's summer of code, >> but I am not sure how useful it actually is for others. >>=20 >> I would like to create a webui to manage the jails on a system. >> The only other alternative I could find at the moment is >> a webmin plugin. The thing is that webmin is a fairly generic tool >> that can do a lot of things. My idea was to create a django-based >> application designed specifically for jail management and deployment. >>=20 >> Does this functionality actually appeal to people? >=20 > I think this is a great idea. >=20 >> Is it feasible as a SoC project? >=20 > I think that your best chance at success is going to be to design your pro= ject around the fact that the jail management landscape is changing > (in the scope of both the utilities offered in the base for managing jails= at the command-line and the capabilities of what a jail can do such as moun= t ''jail-friendly'' vfs types when allowed via sysctl-knob, etc). >=20 > There are several e-mails in the -jail@ list which can provide a good idea= as to the direction of the jail landscape. >=20 > So, for example, I'd design a web interface that has the ability to mount N= FS from within the jail (via jexec perhaps) not just into the jail (from the= base-host). Even though ZFS is about the only ''jail-friendly'' vfs type, N= FS should eventually make it's way into that group, and once it does, it wou= ld be nice if the web interface either supported it or was modular enough to= extend the capability to support said feature. > --=20 > Cheers, > Devin >=20 >=20 >> Regards, >> Ilias >> _______________________________________________ >> 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 Sat Mar 26 18:02: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 61BB8106566C; Sat, 26 Mar 2011 18:02:43 +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 058CD8FC0A; Sat, 26 Mar 2011 18:02:42 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63] (may be forged)) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id p2QI2cRD063735; Sat, 26 Mar 2011 12:02:38 -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: <201103261012.32884.jhb@freebsd.org> Date: Sat, 26 Mar 2011 12:02:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201103250818.38470.jhb@freebsd.org> <20110326121646.GA2367@server.vk2pj.dyndns.org> <201103261012.32884.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1082) Cc: freebsd-hackers@FreeBSD.org, Jing Huang Subject: Re: [GSoc] Timeconter Performance Improvements 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, 26 Mar 2011 18:02:43 -0000 On Mar 26, 2011, at 8:12 AM, John Baldwin wrote: > On Saturday, March 26, 2011 08:16:46 am Peter Jeremy wrote: >> On 2011-Mar-25 08:18:38 -0400, John Baldwin wrote: >>> For modern Intel CPUs you can just assume that the TSCs are in sync = across >>> packages. They also have invariant TSC's meaning that the frequency >>> doesn't change. >>=20 >> Synchronised P-state invariant TSCs vastly simplify the problem but >> not everyone has them. Should the fallback be more complexity to >> support per-CPU TSC counts and varying frequencies or a fallback to >> reading the time via a syscall? >=20 > I think we should just fallback to a syscall in that case. We will = also need=20 > to do that if the TSC is not used as the timecounter (or always = duplicate the=20 > ntp_adjtime() work we do for the current timecounter for the TSC = timecounter). Logically, the code should look like: if (can_do_fast_time) do_the_fast_time else call the kernel We can expand what can or can't do the fast time later once we get the = basics working. > Doing this easy case may give us the most bang for the buck, and it is = also a=20 > good first milestone. Once that is in place we can decide what the = value is=20 > in extending it to support harder variations. Agreed. > One thing we do need to think about is if the shared page should just = export a > fixed set of global data, or if it should export routines. The latter=20= > approach is more complex, but it makes the ABI boundary between = userland and=20 > the kernel more friendly to future changes. I believe Linux does the = latter=20 > approach? There's nothing that says we can't couple this with loading a = cpu-specific shared library, which would also insulate things. Having a single page of both data and code strikes me as unwise. Having = one of each wouldn't be too bad. Warner= From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 23:02: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 9D7CD106566B; Sat, 26 Mar 2011 23:02:08 +0000 (UTC) (envelope-from julien.laffaye@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 B74CF8FC08; Sat, 26 Mar 2011 23:02:07 +0000 (UTC) Received: by wyf23 with SMTP id 23so2282736wyf.13 for ; Sat, 26 Mar 2011 16:02:06 -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=7k0vTUUlMxMxRAyO1WGtpjCYuPSi4LBGec/5ziDwPpE=; b=IIbdI32W1fd2ST6RZF7JPFv59yML6R+Syodu9DnIw4nz8yEgsMup1G/JeuqXKee1b3 /dOSxnjhDOBNrN7+RCqzMDOzwdWGgHA7kaAwcE4ASbSPnkKar67Fo/QW5chRnDD8znRc qg4PWpjzgmIE6NWQkQMOImhQfeLh/cer7z9Ic= 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=ouxfJ1DFtLV5c3LMsYqxElYMS29Non383dx8Gu7Yyot8Oj3yhvtCmUXloA0RYCWep6 98KpOUvClNGQvi/t1JiGpiPBu4xgwg/OR6RYasY7D7kAD00gZSXVkwkERsXc+TDtGnwu BW6mCCIu9YGMcZ0m8aNLoOMOPjxQnGfzgaq14= MIME-Version: 1.0 Received: by 10.216.136.67 with SMTP id v45mr1197277wei.106.1301180526817; Sat, 26 Mar 2011 16:02:06 -0700 (PDT) Sender: julien.laffaye@gmail.com Received: by 10.216.167.85 with HTTP; Sat, 26 Mar 2011 16:02:06 -0700 (PDT) In-Reply-To: <20110325101111.GA36840@azathoth.lan> References: <20110325101111.GA36840@azathoth.lan> Date: Sat, 26 Mar 2011 23:02:06 +0000 X-Google-Sender-Auth: yHKfzpLH7FDeBTyLLmeGzN0_GdY Message-ID: From: Julien Laffaye To: Baptiste Daroussin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ports@freebsd.org, hackers@freebsd.org, current@freebsd.org Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install 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, 26 Mar 2011 23:02:08 -0000 On Fri, Mar 25, 2011 at 10:11 AM, Baptiste Daroussin wro= te: > =A0Developpement site: http://git.etoilebsd.net/pkgng/ FYI, we moved to github[1] in order to have a bug tracker, pull request and code review. Also, I recommend to build from the HEAD of the git repository, to not report fixed compilation warnings/bugs. [1]: https://github.com/pkgng/pkgng