From owner-freebsd-arch@FreeBSD.ORG Sun Feb 21 06:06:06 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 728341065679 for ; Sun, 21 Feb 2010 06:06:06 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4CB248FC17 for ; Sun, 21 Feb 2010 06:06:06 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.3/8.14.3) id o1L5qZgW011201 for freebsd-arch@freebsd.org; Sun, 21 Feb 2010 05:52:35 GMT (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id 5ihdauz3sen9paf8a32svb6rfe; for freebsd-arch@freebsd.org; Sun, 21 Feb 2010 05:52:35 +0000 (UTC) (envelope-from kientzle@freebsd.org) Message-ID: <4B80CA57.9000808@freebsd.org> Date: Sat, 20 Feb 2010 21:53:27 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090601 SeaMonkey/1.1.16 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Importing liblzma, xz X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 06:06:06 -0000 Since there were some more questions about this recently on -hackers, I figured I should go ahead and start the process on this. I believe -arch is the correct place to ask: Does anyone have any concerns about importing the liblzma libraries and associated command-line tools from Lasse Collin's "xz utils" package into FreeBSD's base system? The code in question is all currently in the public domain, so there should be no problems with licensing. More information about the xz project: http://tukaani.org/xz/ According to that page, the final 5.0 production version should be released pretty soon. Cheers, Tim From owner-freebsd-arch@FreeBSD.ORG Sun Feb 21 12:47:15 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CFE1106568B; Sun, 21 Feb 2010 12:47:15 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id C4FE68FC08; Sun, 21 Feb 2010 12:47:14 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 0113B1FFC51; Sun, 21 Feb 2010 12:47:13 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id B2A02844C2; Sun, 21 Feb 2010 13:47:13 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Tim Kientzle References: <4B80CA57.9000808@freebsd.org> Date: Sun, 21 Feb 2010 13:47:13 +0100 In-Reply-To: <4B80CA57.9000808@freebsd.org> (Tim Kientzle's message of "Sat, 20 Feb 2010 21:53:27 -0800") Message-ID: <86635qeoxa.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: Importing liblzma, xz X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 12:47:15 -0000 Tim Kientzle writes: > Does anyone have any concerns about importing the liblzma libraries > and associated command-line tools from Lasse Collin's "xz utils" > package into FreeBSD's base system? I'm in favor. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sun Feb 21 17:51:54 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDAD1106566B; Sun, 21 Feb 2010 17:51:54 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 7440D8FC12; Sun, 21 Feb 2010 17:51:54 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 1CF461CD18; Sun, 21 Feb 2010 18:51:53 +0100 (CET) Date: Sun, 21 Feb 2010 18:51:53 +0100 From: Ed Schouten To: Tim Kientzle Message-ID: <20100221175153.GQ8200@hoeg.nl> References: <4B80CA57.9000808@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YkilVOb9qhI0mB+X" Content-Disposition: inline In-Reply-To: <4B80CA57.9000808@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-arch@freebsd.org Subject: Re: Importing liblzma, xz X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 17:51:54 -0000 --YkilVOb9qhI0mB+X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Tim, * Tim Kientzle wrote: > Does anyone have any concerns about importing > the liblzma libraries and associated command-line > tools from Lasse Collin's "xz utils" > package into FreeBSD's base system? That would be awesome! --=20 Ed Schouten WWW: http://80386.nl/ --YkilVOb9qhI0mB+X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuBcrkACgkQ52SDGA2eCwUAsgCePCH1dr29ylAmmld/ObYNEfFq jvQAnR4n44cjoL8OiYmybG21zmPjLbx/ =tTxb -----END PGP SIGNATURE----- --YkilVOb9qhI0mB+X-- From owner-freebsd-arch@FreeBSD.ORG Mon Feb 22 04:45:06 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B4C2106566B for ; Mon, 22 Feb 2010 04:45:06 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 14E198FC08 for ; Mon, 22 Feb 2010 04:45:05 +0000 (UTC) Received: (qmail 31585 invoked by uid 399); 22 Feb 2010 04:45:04 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 22 Feb 2010 04:45:04 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B820BCF.2090908@FreeBSD.org> Date: Sun, 21 Feb 2010 20:45:03 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100218 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Future plans for BIND versions in the base, and DNSSEC readiness X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 04:45:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Howdy, This message is to describe the current status of BIND support in FreeBSD, list my plans for the future, and solicit comments from the community. If you have any feedback, particularly if you disagree with my proposed course of action, please speak up sooner rather than later. In the past release policies for both FreeBSD and BIND have been different than what they have evolved into. In the last few years both FreeBSD and BIND have done major version releases on a much more aggressive schedule, and the policies for what does and does not go into a major version release have been modified. With the larger number of extant BIND releases ISC has also updated their End of Life (EOL) policies for older versions as well. Given that all up to date versions of BIND (and other name server software options) are available in the ports tree, and given the desire not to violate POLA for our users by making changes to the BIND version in a given branch we have traditionally made the decision not to update them. The current status of our supported branches is as follows: FreeBSD Version | BIND Version | BIND Status - ------------------------------------------------------------------------ 6 | 9.3.6-P1 | EOL - ------------------------------------------------------------------------ 7 | 9.4-ESV | Supported through 2010-12-31 - ------------------------------------------------------------------------ 8 | 9.6.1-P3 | Active development - ------------------------------------------------------------------------ HEAD | 9.6.1-P3 | Active development - ------------------------------------------------------------------------ The new development in that list is the 9.4-ESV version. You can see ISC's policy on Extended Support Versions at https://www.isc.org/softwaresupportpolicy. This is a new policy for them to provide a longer time period of support for certain versions. This 9.4-ESV will not be supported for the full 3 years, so after 2010-12-31 FreeBSD 7 users with serious DNS needs will either have to upgrade to a newer FreeBSD version or they will have to use a supported version of BIND (or another name server) from ports, the same way that FreeBSD 6 users need to do now. The upcoming DNSSEC signing of the root zone will likely make such an upgrade necessary anyway (see below). For FreeBSD version 8 there will be at least one more regular release of BIND 9.6 (9.6.2), and that -ESV version will be supported for 3 years after it is released. Therefore in all likelihood we will have full support for BIND 9.6 throughout the lifetime of FreeBSD version 8. BIND version 9.7.0 is the latest new-feature release from ISC. The major differences between this version and 9.6 have to do with better support for DNSSEC, including better automation support for "unattended" signing. A more detailed list of 9.7's new features is available at https://www.isc.org/software/bind/new-features/9.7. My plan is to import BIND 9.7 into HEAD. Assuming that it is still the most current BIND version when FreeBSD 9-RELEASE is ready to go it's the version that it will be released with. This should hopefully allow that version of FreeBSD to have a supported version of BIND throughout its lifetime as well. DNSSEC Considerations - --------------------- I think most people are familiar with the concept of DNSSEC. It provides cryptographic signatures on DNS responses that allow resolving name servers with the right software to be sure that the answer they received is the same one that the domain holder intended. While there are many early adopters of DNSSEC today, including many Top Level Domains (TLDs) the linchpin event that most people are waiting for in order to get really excited about DNSSEC deployment is the signing of the root zone. The plans for this have been laid, and the first stages of the deployment of the signed zone are already under way. You can read all about these plans, and the projected timetable at http://www.root-dnssec.org/. The key elements of the timetable are that by the end of May all root name servers will be serving a zone that contains DNSSEC signatures, although they will be unvalidatable (for a variety of complicated reasons outside the scope of this document). Assuming that there are no show-stopping problems in the initial deployment phases by July 1st the real root zone keys will have been published, and the real zone will be signed on the root name servers. There are two implementation details for DNSSEC signing of the root zone that are important for people interested in configuring their resolvers for validation to begin planning for now. The first is the much greater size of the DNS responses that include DNSSEC information. Any name server software that is modern enough to support DNSSEC also implements something called EDNS which allows name servers to operate with UDP packet sizes up to 4096 bytes, which is much greater than the 512 bytes that were specified in the earliest DNS standards. Unfortunately, although the EDNS standard has been around for a long time there are still many "middleboxes" (firewalls, broadband routers, etc.) that have problems with these larger responses. You can test your network by using the tools and techniques described at the following sites: https://www.dns-oarc.net/oarc/services/replysizetest http://labs.ripe.net/content/testing-your-resolver-dns-reply-size-issues The other important issue with the DNSSEC signing of the root zone (and the reason for including it here) is the key protocol that will be used. The RSA/SHA256 key protocol was only recently codified in an RFC, and BIND version 9.7.0 is the first release version of BIND to support it. This support will be backported to version 9.6.2 as well, however it will not be ported to 9.4-ESV. Therefore users of FreeBSD 6 and 7 who wish to validate DNSSEC signatures will either have to update to FreeBSD 8 or 9; or they will have to update their name server software via the ports. I hope that this overview is useful. Regards, Doug - -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEAREDAAYFAkuCC88ACgkQyIakK9Wy8PuiJwCgm1QYtcNNC6awe5a3iKW3xuBv C58An3Mlioa6eHidWDZOCAjjqgk8JVkf =9GL0 -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Mon Feb 22 11:06:53 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D3421065676 for ; Mon, 22 Feb 2010 11:06:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 22EC98FC0A for ; Mon, 22 Feb 2010 11:06:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1MB6rtH039629 for ; Mon, 22 Feb 2010 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1MB6qun039627 for freebsd-arch@FreeBSD.org; Mon, 22 Feb 2010 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 22 Feb 2010 11:06:52 GMT Message-Id: <201002221106.o1MB6qun039627@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 11:06:53 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Tue Feb 23 06:15:28 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 614AE1065670 for ; Tue, 23 Feb 2010 06:15:28 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from hosting.nash.net.ua (hosting.nash.net.ua [193.151.252.10]) by mx1.freebsd.org (Postfix) with SMTP id 24CC28FC16 for ; Tue, 23 Feb 2010 06:15:26 +0000 (UTC) Received: (qmail 18726 invoked by uid 509); 23 Feb 2010 06:00:24 -0000 Received: from ravenloft.kiev.ua (91.123.146.100) by hosting.nash.net.ua with SMTP; 23 Feb 2010 06:00:24 -0000 Date: Mon, 22 Feb 2010 08:09:52 +0200 From: Alex Kozlov To: Tim Kientzle , freebsd-arch@freebsd.org, spam@rm-rf.kiev.ua Message-ID: <20100222060952.GA29507@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Importing liblzma, xz X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 06:15:28 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Feb 20, 2010 at 09:53:27PM -0800, Tim Kientzle wrote: > Since there were some more questions about this > recently on -hackers, I figured I should go ahead > and start the process on this. > > I believe -arch is the correct place to ask: > > Does anyone have any concerns about importing > the liblzma libraries and associated command-line > tools from Lasse Collin's "xz utils" > package into FreeBSD's base system? > > The code in question is all currently in the > public domain, so there should be no problems > with licensing. > > More information about the xz project: > http://tukaani.org/xz/ > > According to that page, the final 5.0 production > version should be released pretty soon. Good idea. I even make a rough draft of liblzma port some time ago (see attach). -- Adios --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.txt" Index: liblzma/Makefile @@ -0,0 +1,35 @@ +LIB= lzma +SHLIB_MAJOR= 0 + +WARNS?=3 # XXX + +LDADD= -lpthread + +CFLAGS+= -I${.CURDIR} \ + -I${.CURDIR}/api \ + -I${.CURDIR}/check \ + -I${.CURDIR}/common \ + -I${.CURDIR}/delta \ + -I${.CURDIR}/lz \ + -I${.CURDIR}/lzma \ + -I${.CURDIR}/rangecoder \ + -I${.CURDIR}/simple \ + -I${.CURDIR}/subblock \ + -I/usr/src/include \ + -DHAVE_CONFIG_H -D_THREAD_SAFE -fvisibility=hidden -std=gnu99 + +.include "${.CURDIR}/api/Makefile.inc" +.include "${.CURDIR}/check/Makefile.inc" +.include "${.CURDIR}/common/Makefile.inc" +.include "${.CURDIR}/delta/Makefile.inc" +.include "${.CURDIR}/lz/Makefile.inc" +.include "${.CURDIR}/lzma/Makefile.inc" +.include "${.CURDIR}/rangecoder/Makefile.inc" +.include "${.CURDIR}/simple/Makefile.inc" +.include "${.CURDIR}/subblock/Makefile.inc" + +CLEANFILES= ${SOBJS} + +all: ${SOBJS} + +.include Index: liblzma/api/Makefile.inc @@ -0,0 +1,12 @@ +.PATH: ${.CURDIR}/api + +INCSGROUPS= INCS INCSLZMA + +INCS= lzma.h + +INCSLZMADIR= ${INCLUDEDIR}/lzma +INCSLZMA= lzma/base.h lzma/check.h lzma/filter.h lzma/lzma.h \ + lzma/version.h lzma/bcj.h lzma/container.h \ + lzma/index.h lzma/stream_flags.h lzma/vli.h \ + lzma/block.h lzma/delta.h lzma/index_hash.h \ + lzma/subblock.h Index: liblzma/check/Makefile.inc @@ -1,51 +1,12 @@ -## -## Author: Lasse Collin -## -## This file has been put into the public domain. -## You can do whatever you want with this file. -## +.PATH: ${.CURDIR}/check -EXTRA_DIST += \ - check/crc32_tablegen.c \ - check/crc64_tablegen.c +SRCS+= check.c -liblzma_la_SOURCES += \ - check/check.c \ - check/check.h \ - check/crc_macros.h +# CHECK_CRC32 +SRCS+= crc32_table.c crc32_fast.c -if COND_CHECK_CRC32 -if COND_SMALL -liblzma_la_SOURCES += check/crc32_small.c -else -liblzma_la_SOURCES += \ - check/crc32_table.c \ - check/crc32_table_le.h \ - check/crc32_table_be.h -if COND_ASM_X86 -liblzma_la_SOURCES += check/crc32_x86.S -else -liblzma_la_SOURCES += check/crc32_fast.c -endif -endif -endif +# CHECK_CRC64 +SRCS+= crc64_table.c crc64_fast.c -if COND_CHECK_CRC64 -if COND_SMALL -liblzma_la_SOURCES += check/crc64_small.c -else -liblzma_la_SOURCES += \ - check/crc64_table.c \ - check/crc64_table_le.h \ - check/crc64_table_be.h -if COND_ASM_X86 -liblzma_la_SOURCES += check/crc64_x86.S -else -liblzma_la_SOURCES += check/crc64_fast.c -endif -endif -endif - -if COND_CHECK_SHA256 -liblzma_la_SOURCES += check/sha256.c -endif +# CHECK_SHA256 +SRCS+= sha256.c Index: liblzma/check/crc32_fast.c @@ -49,7 +49,7 @@ // Calculate the CRC32 using the slice-by-eight algorithm. while (buf < limit) { - crc ^= *(uint32_t *)(buf); + crc ^= *(const uint32_t *)(buf); buf += 4; crc = lzma_crc32_table[7][A(crc)] @@ -57,7 +57,7 @@ ^ lzma_crc32_table[5][C(crc)] ^ lzma_crc32_table[4][D(crc)]; - const uint32_t tmp = *(uint32_t *)(buf); + const uint32_t tmp = *(const uint32_t *)(buf); buf += 4; // At least with some compilers, it is critical for Index: liblzma/check/crc64_fast.c @@ -48,7 +48,7 @@ #ifdef WORDS_BIGENDIAN const uint32_t tmp = (crc >> 32) ^ *(uint32_t *)(buf); #else - const uint32_t tmp = crc ^ *(uint32_t *)(buf); + const uint32_t tmp = crc ^ *(const uint32_t *)(buf); #endif buf += 4; Index: liblzma/check/sha256.c @@ -30,7 +30,7 @@ #include "check.h" #ifndef WORDS_BIGENDIAN -# include "../../common/bswap.h" +# include "bswap.h" #endif // At least on x86, GCC is able to optimize this to a rotate instruction. @@ -87,7 +87,7 @@ static void transform(uint32_t state[static 8], const uint32_t data[static 16]) { - uint32_t W[16]; + uint32_t W[16] = {0}; //XXX Silence gcc uint32_t T[8]; // Copy state[] to working vars. Index: liblzma/common/Makefile.inc @@ -1,67 +1,18 @@ -## -## Author: Lasse Collin -## -## This file has been put into the public domain. -## You can do whatever you want with this file. -## +.PATH: ${.CURDIR}/common -liblzma_la_SOURCES += \ - common/common.c \ - common/common.h \ - common/bsr.h \ - common/block_util.c \ - common/easy_preset.c \ - common/easy_preset.h \ - common/filter_common.c \ - common/filter_common.h \ - common/index.c \ - common/index.h \ - common/stream_flags_common.c \ - common/stream_flags_common.h \ - common/vli_size.c +SRCS+= common.c block_util.c easy_preset.c filter_common.c index.c \ + stream_flags_common.c vli_size.c -if COND_MAIN_ENCODER -liblzma_la_SOURCES += \ - common/alone_encoder.c \ - common/block_buffer_encoder.c \ - common/block_encoder.c \ - common/block_encoder.h \ - common/block_header_encoder.c \ - common/easy_buffer_encoder.c \ - common/easy_encoder.c \ - common/easy_encoder_memusage.c \ - common/filter_buffer_encoder.c \ - common/filter_encoder.c \ - common/filter_encoder.h \ - common/filter_flags_encoder.c \ - common/index_encoder.c \ - common/index_encoder.h \ - common/stream_buffer_encoder.c \ - common/stream_encoder.c \ - common/stream_encoder.h \ - common/stream_flags_encoder.c \ - common/vli_encoder.c -endif +# MAIN_ENCODER +SRCS+= alone_encoder.c block_buffer_encoder.c block_encoder.c \ + block_header_encoder.c easy_encoder.c easy_encoder_memusage.c \ + filter_buffer_encoder.c filter_encoder.c filter_flags_encoder.c \ + index_encoder.c stream_buffer_encoder.c stream_encoder.c \ + stream_flags_encoder.c vli_encoder.c -if COND_MAIN_DECODER -liblzma_la_SOURCES += \ - common/alone_decoder.c \ - common/alone_decoder.h \ - common/auto_decoder.c \ - common/block_buffer_decoder.c \ - common/block_decoder.c \ - common/block_decoder.h \ - common/block_header_decoder.c \ - common/easy_decoder_memusage.c \ - common/filter_buffer_decoder.c \ - common/filter_decoder.c \ - common/filter_decoder.h \ - common/filter_flags_decoder.c \ - common/index_decoder.c \ - common/index_hash.c \ - common/stream_buffer_decoder.c \ - common/stream_decoder.c \ - common/stream_decoder.h \ - common/stream_flags_decoder.c \ - common/vli_decoder.c -endif +# MAIN_DECODER +SRCS+= alone_decoder.c auto_decoder.c block_buffer_decoder.c \ + block_decoder.c block_header_decoder.c easy_decoder_memusage.c \ + filter_buffer_decoder.c filter_decoder.c filter_flags_decoder.c \ + index_decoder.c index_hash.c stream_buffer_decoder.c stream_decoder.c \ + stream_flags_decoder.c vli_decoder.c Index: liblzma/common/config.h @@ -0,0 +1,71 @@ +#if defined(__i386__) +# define HAVE_ASM_X86 1 +#elif defined(__amd64__) +# define HAVE_ASM_X86_64 1 +#endif + +#define HAVE_CHECK_CRC32 1 +#define HAVE_CHECK_CRC64 1 +#define HAVE_CHECK_SHA256 1 +#define HAVE_DECODER 1 +#define HAVE_DECODER_ARM 1 +#define HAVE_DECODER_ARMTHUMB 1 +#define HAVE_DECODER_DELTA 1 +#define HAVE_DECODER_IA64 1 +#define HAVE_DECODER_LZMA1 1 +#define HAVE_DECODER_LZMA2 1 +#define HAVE_DECODER_POWERPC 1 +#define HAVE_DECODER_SPARC 1 +/* Define to 1 if subblock decoder is enabled. */ +/* #undef HAVE_DECODER_SUBBLOCK */ +#define HAVE_DECODER_X86 1 +#define HAVE_ENCODER 1 +#define HAVE_ENCODER_ARM 1 +#define HAVE_ENCODER_ARMTHUMB 1 +#define HAVE_ENCODER_DELTA 1 +#define HAVE_ENCODER_IA64 1 +#define HAVE_ENCODER_LZMA1 1 +#define HAVE_ENCODER_LZMA2 1 +#define HAVE_ENCODER_POWERPC 1 +#define HAVE_ENCODER_SPARC 1 +/* Define to 1 if subblock encoder is enabled. */ +/* #undef HAVE_ENCODER_SUBBLOCK */ +#define HAVE_ENCODER_X86 1 + +/* XXX test on other platforms */ +#if defined(__i386__) || defined(__amd64__) +# define HAVE_FAST_UNALIGNED_ACCESS 1 +#endif + +#define HAVE_MF_BT2 1 +#define HAVE_MF_BT3 1 +#define HAVE_MF_BT4 1 +#define HAVE_MF_HC3 1 +#define HAVE_MF_HC4 1 + +/* Define to 1 to disable debugging code. */ +#define NDEBUG 1 + +#define HAVE_PTHREAD 1 + +/* Define to 1 if optimizing for size. */ +/* #undef HAVE_SMALL */ +#define HAVE_INTTYPES_H 1 +#define HAVE_STDBOOL_H 1 +#define HAVE_STRING_H 1 +#define HAVE_SYS_ENDIAN_H 1 +#define HAVE_VISIBILITY 1 +#define STDC_HEADERS 1 + +/* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most + significant byte first (like Motorola and SPARC, unlike Intel and VAX). */ +#if defined __BIG_ENDIAN__ +# define WORDS_BIGENDIAN 1 +#elif ! defined __LITTLE_ENDIAN__ +/* # undef WORDS_BIGENDIAN */ +#endif + +/* Enable GNU extensions on systems that have them. */ +#ifndef _GNU_SOURCE +# define _GNU_SOURCE 1 +#endif Index: liblzma/delta/Makefile.inc @@ -1,23 +1,9 @@ -## -## Author: Lasse Collin -## -## This file has been put into the public domain. -## You can do whatever you want with this file. -## +.PATH: ${.CURDIR}/delta -liblzma_la_SOURCES += \ - delta/delta_common.c \ - delta/delta_common.h \ - delta/delta_private.h +SRCS+= delta_common.c -if COND_ENCODER_DELTA -liblzma_la_SOURCES += \ - delta/delta_encoder.c \ - delta/delta_encoder.h -endif +# ENCODER_DELTA +SRCS+= delta_encoder.c -if COND_DECODER_DELTA -liblzma_la_SOURCES += \ - delta/delta_decoder.c \ - delta/delta_decoder.h -endif +# DECODER_DELTA +SRCS+= delta_decoder.c Index: liblzma/lz/Makefile.inc @@ -1,21 +1,7 @@ -## -## Author: Lasse Collin -## -## This file has been put into the public domain. -## You can do whatever you want with this file. -## +.PATH: ${.CURDIR}/lz -if COND_ENCODER_LZ -liblzma_la_SOURCES += \ - lz/lz_encoder.c \ - lz/lz_encoder.h \ - lz/lz_encoder_hash.h \ - lz/lz_encoder_mf.c -endif +# ENCODER_LZ +SRCS+= lz_encoder.c lz_encoder_mf.c - -if COND_DECODER_LZ -liblzma_la_SOURCES += \ - lz/lz_decoder.c \ - lz/lz_decoder.h -endif +# DECODER_LZ +SRCS+= lz_decoder.c Index: liblzma/lzma/Makefile.inc @@ -1,43 +1,16 @@ -## -## Author: Lasse Collin -## -## This file has been put into the public domain. -## You can do whatever you want with this file. -## +.PATH: ${.CURDIR}/lzma -EXTRA_DIST += lzma/fastpos_tablegen.c +SRCS+= fastpos_table.c -liblzma_la_SOURCES += lzma/lzma_common.h +# ENCODER_LZMA1 +SRCS+= lzma_encoder.c lzma_encoder_presets.c lzma_encoder_optimum_fast.c \ + lzma_encoder_optimum_normal.c -if COND_ENCODER_LZMA1 -liblzma_la_SOURCES += \ - lzma/fastpos.h \ - lzma/lzma_encoder.h \ - lzma/lzma_encoder.c \ - lzma/lzma_encoder_presets.c \ - lzma/lzma_encoder_private.h \ - lzma/lzma_encoder_optimum_fast.c \ - lzma/lzma_encoder_optimum_normal.c +# DECODER_LZMA1 +SRCS+= lzma_decoder.c -if !COND_SMALL -liblzma_la_SOURCES += lzma/fastpos_table.c -endif -endif +# ENCODER_LZMA2 +SRCS+= lzma2_encoder.c -if COND_DECODER_LZMA1 -liblzma_la_SOURCES += \ - lzma/lzma_decoder.c \ - lzma/lzma_decoder.h -endif - -if COND_ENCODER_LZMA2 -liblzma_la_SOURCES += \ - lzma/lzma2_encoder.c \ - lzma/lzma2_encoder.h -endif - -if COND_DECODER_LZMA2 -liblzma_la_SOURCES += \ - lzma/lzma2_decoder.c \ - lzma/lzma2_decoder.h -endif +# DECODER_LZMA2 +SRCS+= lzma2_decoder.c Index: liblzma/rangecoder/Makefile.inc @@ -1,21 +1,4 @@ -## -## Author: Lasse Collin -## -## This file has been put into the public domain. -## You can do whatever you want with this file. -## +.PATH: ${.CURDIR}/rangecoder -EXTRA_DIST += rangecoder/price_tablegen.c - -liblzma_la_SOURCES += rangecoder/range_common.h - -if COND_ENCODER_LZMA1 -liblzma_la_SOURCES += \ - rangecoder/range_encoder.h \ - rangecoder/price.h \ - rangecoder/price_table.c -endif - -if COND_DECODER_LZMA1 -liblzma_la_SOURCES += rangecoder/range_decoder.h -endif +#ENCODER_LZMA1 +SRCS+= price_table.c Index: liblzma/simple/Makefile.inc @@ -1,47 +1,27 @@ -## -## Author: Lasse Collin -## -## This file has been put into the public domain. -## You can do whatever you want with this file. -## - -liblzma_la_SOURCES += \ - simple/simple_coder.c \ - simple/simple_coder.h \ - simple/simple_private.h - -if COND_ENCODER_SIMPLE -liblzma_la_SOURCES += \ - simple/simple_encoder.c \ - simple/simple_encoder.h -endif - -if COND_DECODER_SIMPLE -liblzma_la_SOURCES += \ - simple/simple_decoder.c \ - simple/simple_decoder.h -endif - -if COND_FILTER_X86 -liblzma_la_SOURCES += simple/x86.c -endif - -if COND_FILTER_POWERPC -liblzma_la_SOURCES += simple/powerpc.c -endif - -if COND_FILTER_IA64 -liblzma_la_SOURCES += simple/ia64.c -endif - -if COND_FILTER_ARM -liblzma_la_SOURCES += simple/arm.c -endif - -if COND_FILTER_ARMTHUMB -liblzma_la_SOURCES += simple/armthumb.c -endif - -if COND_FILTER_SPARC -liblzma_la_SOURCES += simple/sparc.c -endif +.PATH: ${.CURDIR}/simple + +SRCS+= simple_coder.c + +# ENCODER_SIMPLE +SRCS+= simple_encoder.c + +# DECODER_SIMPLE +SRCS+= simple_decoder.c + +# FILTER_X86 +SRCS+= x86.c + +# FILTER_POWERPC +SRCS+= powerpc.c + +# FILTER_IA64 +SRCS+= ia64.c + +# FILTER_ARM +SRCS+= arm.c + +# FILTER_ARMTHUMB +SRCS+= armthumb.c + +# FILTER_SPARC +SRCS+= sparc.c Index: liblzma/subblock/Makefile.inc @@ -1,20 +1,7 @@ -## -## Author: Lasse Collin -## -## This file has been put into the public domain. -## You can do whatever you want with this file. -## +.PATH: ${.CURDIR}/subblock -if COND_ENCODER_SUBBLOCK -liblzma_la_SOURCES += \ - subblock/subblock_encoder.c \ - subblock/subblock_encoder.h -endif +# ENCODER_SUBBLOCK +SRCS+= subblock_encoder.c -if COND_DECODER_SUBBLOCK -liblzma_la_SOURCES += \ - subblock/subblock_decoder.c \ - subblock/subblock_decoder.h \ - subblock/subblock_decoder_helper.c \ - subblock/subblock_decoder_helper.h -endif +# DECODER_SUBBLOCK +SRCS+= subblock_decoder.c subblock_decoder_helper.c --a8Wt8u1KmwUX3Y2C-- From owner-freebsd-arch@FreeBSD.ORG Tue Feb 23 07:19:04 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D14291065670; Tue, 23 Feb 2010 07:19:04 +0000 (UTC) (envelope-from rajatjain@juniper.net) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by mx1.freebsd.org (Postfix) with ESMTP id 3DCE18FC12; Tue, 23 Feb 2010 07:19:04 +0000 (UTC) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKS4OBZ34W5IL1/4ymY+6O/BE5E9sukt0M@postini.com; Mon, 22 Feb 2010 23:19:04 PST Received: from emailbng1.jnpr.net (10.209.194.15) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.1.393.1; Mon, 22 Feb 2010 23:16:44 -0800 Received: from emailbng3.jnpr.net ([10.209.194.27]) by emailbng1.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 12:46:41 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Feb 2010 12:46:40 +0530 Message-ID: <8506939B503B404A84BBB12293FC45F606B88C39@emailbng3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Strategy for PCI resource management (for supporting hot-plug) Thread-Index: Acq0WCUiblKr9+OlQeafGqGQtTgEow== From: Rajat Jain To: , X-OriginalArrivalTime: 23 Feb 2010 07:16:41.0758 (UTC) FILETIME=[25C9BBE0:01CAB458] Cc: freebsd-ia32@freebsd.org, freebsd-ppc@freebsd.org Subject: Strategy for PCI resource management (for supporting hot-plug) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 07:19:04 -0000 Hi, I'm trying to add PCI-E hotplug support to the FreeBSD. As a first step for the PCI-E hotplug support, I'm trying to decide on a resource management / allocation strategy for the PCI memory / IO and the bus numbers. Can you please comment on the following approach that I am considering for resource allocation: PROBLEM STATEMENT: ------------------ Given a memory range [A->B], IO range [C->D], and limited (256) bus numbers, enumerate the PCI tree of a system, leaving enough "holes" in between to allow addition of future devices. PROPOSED STRATEGY: ------------------ 1) When booting, start enumerating in a depth-first-search order. While enumeration, always keep track of: * The next bus number (x) that can be allocated * The next Memory space pointer (A + y) starting which allocation can be=20 done. ("y" is the memory already allocated). * The next IO Space pointer (C + z) starting which allocation can be done. ("z" is the IO space already allocated). Keep incrementing the above as the resources are allocated. 2) Allocate bus numbers sequentially while traversing down from root to a leaf node (end point). When going down traversing a bridge: * Allocate the next available bus number (x) to the secondary bus of=20 bridge. * Temporarily mark the subordinate bridge as 0xFF (to allow discovery of=20 maximum buses). * Temporarily assign all the remaining available memory space to bridge [(A+x) -> B]. Ditto for IO space. 3) When a leaf node (End point) is reached, allocate the memory / IO resource requested by the device, and increment the pointers.=20 4) While passing a bridge in the upward direction, tweak the bridge registers such that its resources are ONLY ENOUGH to address the needs of all the PCI tree below it, and if it has its own internal memory mapped registers, some memory for it as well. The above is the standard depth-first algorithm for resource allocation. Here is the addition to support hot-plug: At each bridge that supports hot-plug, in addition to the resources that would have normally been allocated to this bridge, additionally pre-allocate and assign to bridge (in anticipation of any new devices that may be added later): a) "RSRVE_NUM_BUS" number of busses, to cater to any bridges, PCI trees=20 present on the device plugged. b) "RSRVE_MEM" amount of memory space, to cater to all the PCI devices that=20 may be attached later on. c) "RESRVE_IO" amount of IO space, to cater to all PCI devices that may be=20 attached later on. Please note that the above RSRVE* are constants defining the amount of resources to be set aside for /below each HOT-PLUGGABLE bridge; their values may be tweaked via a compile time option or via a sysctl.=20 FEW COMMENTS ------------ =20 1) The strategy is fairly generic and tweak-able since it does not waste a lot of resources (The developer neds to pick up a smart bvalue for howmuch resources to reserve at each hot-pluggable slot): * The reservations shall be done only for hot-pluggable bridges * The developer can tweak the values (even disable it) for how much=20 Resources shall be allocated for each hot-pluggable bridge. =20 2) One point of debate is what happens if there are too much resource demands in the system (too many devices or the developer configures too many resources to be allocated for each hot-pluggable devices). For e.g. consider that while enumeration we find that all the resources are already allocated, while there are more devices that need resources. So do we simply do not enumerate them? Etc... Overall, how does the above look? Thanks & Best Regards, Rajat Jain From owner-freebsd-arch@FreeBSD.ORG Tue Feb 23 08:21:14 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCB0A1065694; Tue, 23 Feb 2010 08:21:14 +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 673CA8FC15; Tue, 23 Feb 2010 08:21:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o1N8GVCm035900; Tue, 23 Feb 2010 01:16:31 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 23 Feb 2010 01:16:30 -0700 (MST) Message-Id: <20100223.011630.74715282.imp@bsdimp.com> To: rajatjain@juniper.net From: Warner Losh In-Reply-To: <8506939B503B404A84BBB12293FC45F606B88C39@emailbng3.jnpr.net> References: <8506939B503B404A84BBB12293FC45F606B88C39@emailbng3.jnpr.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-ia32@FreeBSD.org, freebsd-new-bus@FreeBSD.org, freebsd-ppc@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Strategy for PCI resource management (for supporting hot-plug) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 08:21:14 -0000 From: Rajat Jain Subject: Strategy for PCI resource management (for supporting hot-plug) Date: Tue, 23 Feb 2010 12:46:40 +0530 > > Hi, > > I'm trying to add PCI-E hotplug support to the FreeBSD. As a first step > for the PCI-E hotplug support, I'm trying to decide on a resource > management / allocation strategy for the PCI memory / IO and the bus > numbers. Can you please comment on the following approach that I am > considering for resource allocation: > > PROBLEM STATEMENT: > ------------------ > Given a memory range [A->B], IO range [C->D], and limited (256) bus > numbers, enumerate the PCI tree of a system, leaving enough "holes" in > between to allow addition of future devices. > > PROPOSED STRATEGY: > ------------------ > 1) When booting, start enumerating in a depth-first-search order. While > enumeration, always keep track of: > > * The next bus number (x) that can be allocated > > * The next Memory space pointer (A + y) starting which allocation can > be > done. ("y" is the memory already allocated). > > * The next IO Space pointer (C + z) starting which allocation can be > done. > ("z" is the IO space already allocated). > > Keep incrementing the above as the resources are allocated. IO space and memory space are bus addresses, which may have a mapping to another domain. > 2) Allocate bus numbers sequentially while traversing down from root to > a leaf node (end point). When going down traversing a bridge: > > * Allocate the next available bus number (x) to the secondary bus of > bridge. > > * Temporarily mark the subordinate bridge as 0xFF (to allow discovery > of > maximum buses). > > * Temporarily assign all the remaining available memory space to bridge > > [(A+x) -> B]. Ditto for IO space. I'm sure this is wise. > 3) When a leaf node (End point) is reached, allocate the memory / IO > resource requested by the device, and increment the pointers. keep in mind that devices may not have drivers allocataed to them at bus enumeration of time. with hot-plug devices, you might not even know all the devices that are there or could be there. > 4) While passing a bridge in the upward direction, tweak the bridge > registers such that its resources are ONLY ENOUGH to address the needs > of all the PCI tree below it, and if it has its own internal memory > mapped registers, some memory for it as well. How does one deal with adding a device that has a bridge on it? I think that the only enough part is likely going to lead to prroblems as you'll need to move other resources if a new device arrives here. > The above is the standard depth-first algorithm for resource allocation. > Here is the addition to support hot-plug: the above won't quite work for cardbus :) But that's a hot-plug device... > At each bridge that supports hot-plug, in addition to the resources that > would have normally been allocated to this bridge, additionally > pre-allocate and assign to bridge (in anticipation of any new devices > that may be added later): In addition, or total? if it were total, you could more easily allocate memory or io space ranges in a more determnistic way when you have to deal with booting with or without a device that's present. > a) "RSRVE_NUM_BUS" number of busses, to cater to any bridges, PCI trees > present on the device plugged. This one might make sense, but if we have multiple levels then you'll run out. if you have 4 additional bridges, you can't allocate X additional busses at the root, then you can only (X-4)/4 at each level. > b) "RSRVE_MEM" amount of memory space, to cater to all the PCI devices > that > may be attached later on. > > c) "RESRVE_IO" amount of IO space, to cater to all PCI devices that may > be > attached later on. similar comments apply here. > Please note that the above RSRVE* are constants defining the amount of > resources to be set aside for /below each HOT-PLUGGABLE bridge; their > values may be tweaked via a compile time option or via a sysctl. > > FEW COMMENTS > ------------ > > 1) The strategy is fairly generic and tweak-able since it does not waste > a lot of resources (The developer neds to pick up a smart bvalue for > howmuch resources to reserve at each hot-pluggable slot): > > * The reservations shall be done only for hot-pluggable bridges > > * The developer can tweak the values (even disable it) for how much > Resources shall be allocated for each hot-pluggable bridge. I'd like to understand the details of this better. especially when you have multiple layers where devices that have bridges are hot-plugged into the system. For example, three's a cardbus to pci bridge, which has 3 PCI slots behind it. These slots may have, say, a quad ethernet card which has a pci bridge to allow the 4 pci nics behind it. New while this example may be dated, newer pci-e also allows for it... > 2) One point of debate is what happens if there are too much resource > demands in the system (too many devices or the developer configures too > many resources to be allocated for each hot-pluggable devices). For e.g. > consider that while enumeration we find that all the resources are > already allocated, while there are more devices that need resources. So > do we simply do not enumerate them? Etc... How is this different than normal resource failure? And how will you know at initial enumearation what devices will be plugged in? > Overall, how does the above look? In general, it looks fairly good. I'm just worried about the multiple layer case :) Warner > Thanks & Best Regards, > > Rajat Jain > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Tue Feb 23 14:02:44 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9B031065670; Tue, 23 Feb 2010 14:02:44 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f185.google.com (mail-iw0-f185.google.com [209.85.223.185]) by mx1.freebsd.org (Postfix) with ESMTP id 906868FC1B; Tue, 23 Feb 2010 14:02:44 +0000 (UTC) Received: by iwn15 with SMTP id 15so3078475iwn.7 for ; Tue, 23 Feb 2010 06:02:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=CDL/sZejUu4e5XX6eURcWG9ZHhZNnOYYNcRg2XDBSVc=; b=spixNNFzS6IKAJm4B+Qb1rP08mvDFHf8jv7dxnETZ183Qf56xjDhl7ikEiQ41uk+L6 so9+FOpmedQkMjnKNOBuHX01a3KSj/WrFdWpoZcdjNKZhO5+YdOCEIik1RCYHCfXurXU 9YvzMu3kYy4eYNkEJIxNjfB6xHXCwcN9+ibfI= 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=U+Funx24cSSbuve18uOPYTbvf91fm0xbIITeo+P1ADNd+0BEuvTUkqG9Sdx7zUDmDM g6lTnuW50sJgTYHjT9Z6BnSogY3ajgggTAkZm52NEqw1Np65k0yMnQSgzSMtMO14ycSe gLCwmnYGRtD6a9kHeQiQgmMhNAvla/JtOL4AE= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.154.207 with SMTP id p15mr227861ibw.71.1266933759014; Tue, 23 Feb 2010 06:02:39 -0800 (PST) In-Reply-To: <8506939B503B404A84BBB12293FC45F606B88C39@emailbng3.jnpr.net> References: <8506939B503B404A84BBB12293FC45F606B88C39@emailbng3.jnpr.net> Date: Tue, 23 Feb 2010 15:02:38 +0100 X-Google-Sender-Auth: 1238ac7ec9e8960b Message-ID: <3bbf2fe11002230602t28701370l2712f836ebaee03@mail.gmail.com> From: Attilio Rao To: Rajat Jain Content-Type: text/plain; charset=UTF-8 Cc: freebsd-ia32@freebsd.org, freebsd-new-bus@freebsd.org, freebsd-ppc@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Strategy for PCI resource management (for supporting hot-plug) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 14:02:45 -0000 2010/2/23 Rajat Jain : > > Hi, > > I'm trying to add PCI-E hotplug support to the FreeBSD. As a first step > for the PCI-E hotplug support, I'm trying to decide on a resource > management / allocation strategy for the PCI memory / IO and the bus > numbers. Can you please comment on the following approach that I am > considering for resource allocation: You may also coordinate with jhb@ which is working on a multipass layer for improving resource mapping/allocation. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Tue Feb 23 13:28:52 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A0BB106568D for ; Tue, 23 Feb 2010 13:28:52 +0000 (UTC) (envelope-from cjpvicente@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id EF70F8FC17 for ; Tue, 23 Feb 2010 13:28:51 +0000 (UTC) Received: by bwz8 with SMTP id 8so2695328bwz.3 for ; Tue, 23 Feb 2010 05:28:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=9LoARVmHLfjgT/Ew/D9V9WYnSCsIQxrsdN+95XyMIq8=; b=Vy0/6QLb09Qw7esOVNfMWd3otR1xFXBo7TcYidUslTAbx0W5CXSmR8OTTjxeBPrQvg MqMlanpZE4utsEfgC5Telkp2XqUIaveUkn86vu5jbd7KUNKB89W7Wkb7UESUjel41ZU+ /qBdn14AFhbqLhueQy9fTBQmMx9t+9uE03A60= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=EYfcIzvGf36tQCCYpxkA5IziG/6/qFhnE/hoCCp/F96yQFpOsDILu4f6igS3lQE5Xg 1JosaJYI1DauUPwAZDRQ5KDvPNVhGeZK1/2PIe9fmc1uRaXDQgt7sQEWUQ08SkzgmiQC lHaPD7oSdERsHtPfxZaLB3QZBCT5pojWadLs4= MIME-Version: 1.0 Received: by 10.204.2.202 with SMTP id 10mr2556674bkk.206.1266930320854; Tue, 23 Feb 2010 05:05:20 -0800 (PST) Date: Tue, 23 Feb 2010 13:05:20 +0000 Message-ID: From: Carlos Vicente To: freebsd-arch@FreeBSD.org X-Mailman-Approved-At: Tue, 23 Feb 2010 14:35:23 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Intel Atom processor X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 13:28:52 -0000 Hi, I would like to know if all the Intel Atom Processors are supported on FreeBSD 7.2. The reason is that I want to implement a Firewall system with = a less expensive processor, so I came up with this solution, but I don't want to buy it without your confirmation. Keep up the great work. Thanks in advance. Best regards, Carlos Vicente --=20 ---------------------------------------------------------------------------= --- Este e-mail e quaisquer ficheiros a ele anexados s=E3o confidenciais e destinados, exclusivamente, =E0 pessoa ou entidade a quem foi endere=E7ado. Se recebeu = este e-mail por erro, por favor, contacte-nos. Obrigado. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify us. Antes de imprimir este e-mail pense se necessita mesmo de o fazer From owner-freebsd-arch@FreeBSD.ORG Tue Feb 23 16:03:30 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F11F106568B for ; Tue, 23 Feb 2010 16:03:30 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout7.freenet.de (mout7.freenet.de [IPv6:2001:748:100:40::2:9]) by mx1.freebsd.org (Postfix) with ESMTP id EF32F8FC1C for ; Tue, 23 Feb 2010 16:03:29 +0000 (UTC) Received: from [195.4.92.23] (helo=13.mx.freenet.de) by mout7.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #1) id 1NjxEP-0000an-Bp; Tue, 23 Feb 2010 17:03:29 +0100 Received: from p57ae2621.dip0.t-ipconnect.de ([87.174.38.33]:30469 helo=ernst.jennejohn.org) by 13.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #2) id 1NjxEP-0006Sn-07; Tue, 23 Feb 2010 17:03:29 +0100 Date: Tue, 23 Feb 2010 17:03:28 +0100 From: Gary Jennejohn To: Carlos Vicente Message-ID: <20100223170328.5f8afdf7@ernst.jennejohn.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.4 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: Intel Atom processor X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 16:03:30 -0000 On Tue, 23 Feb 2010 13:05:20 +0000 Carlos Vicente wrote: > I would like to know if all the Intel Atom Processors are supported on > FreeBSD 7.2. The reason is that I want to implement a Firewall system with a > less expensive processor, so I came up with this solution, but I don't want > to buy it without your confirmation. > It would make things easier if you mentioned which CPU you have in mind. --- Gary Jennejohn From owner-freebsd-arch@FreeBSD.ORG Tue Feb 23 17:04:34 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6DF21065672; Tue, 23 Feb 2010 17:04:34 +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 877AB8FC0A; Tue, 23 Feb 2010 17:04:34 +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 022D046B03; Tue, 23 Feb 2010 12:04:34 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 859EF8A021; Tue, 23 Feb 2010 12:04:21 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 23 Feb 2010 10:27:20 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <8506939B503B404A84BBB12293FC45F606B88C39@emailbng3.jnpr.net> In-Reply-To: <8506939B503B404A84BBB12293FC45F606B88C39@emailbng3.jnpr.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002231027.20749.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 23 Feb 2010 12:04:21 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.3 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Rajat Jain , freebsd-ia32@freebsd.org, freebsd-new-bus@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: Strategy for PCI resource management (for supporting hot-plug) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 17:04:34 -0000 On Tuesday 23 February 2010 2:16:40 am Rajat Jain wrote: > > Hi, > > I'm trying to add PCI-E hotplug support to the FreeBSD. As a first step > for the PCI-E hotplug support, I'm trying to decide on a resource > management / allocation strategy for the PCI memory / IO and the bus > numbers. Can you please comment on the following approach that I am > considering for resource allocation: > > PROBLEM STATEMENT: > ------------------ > Given a memory range [A->B], IO range [C->D], and limited (256) bus > numbers, enumerate the PCI tree of a system, leaving enough "holes" in > between to allow addition of future devices. > > PROPOSED STRATEGY: > ------------------ > 1) When booting, start enumerating in a depth-first-search order. While > enumeration, always keep track of: > > * The next bus number (x) that can be allocated > > * The next Memory space pointer (A + y) starting which allocation can > be > done. ("y" is the memory already allocated). > > * The next IO Space pointer (C + z) starting which allocation can be > done. > ("z" is the IO space already allocated). > > Keep incrementing the above as the resources are allocated. > > 2) Allocate bus numbers sequentially while traversing down from root to > a leaf node (end point). When going down traversing a bridge: > > * Allocate the next available bus number (x) to the secondary bus of > bridge. > > * Temporarily mark the subordinate bridge as 0xFF (to allow discovery > of > maximum buses). > > * Temporarily assign all the remaining available memory space to bridge > > [(A+x) -> B]. Ditto for IO space. > > 3) When a leaf node (End point) is reached, allocate the memory / IO > resource requested by the device, and increment the pointers. > > 4) While passing a bridge in the upward direction, tweak the bridge > registers such that its resources are ONLY ENOUGH to address the needs > of all the PCI tree below it, and if it has its own internal memory > mapped registers, some memory for it as well. > > The above is the standard depth-first algorithm for resource allocation. > Here is the addition to support hot-plug: > > At each bridge that supports hot-plug, in addition to the resources that > would have normally been allocated to this bridge, additionally > pre-allocate and assign to bridge (in anticipation of any new devices > that may be added later): > > a) "RSRVE_NUM_BUS" number of busses, to cater to any bridges, PCI trees > present on the device plugged. > > b) "RSRVE_MEM" amount of memory space, to cater to all the PCI devices > that > may be attached later on. > > c) "RESRVE_IO" amount of IO space, to cater to all PCI devices that may > be > attached later on. > > Please note that the above RSRVE* are constants defining the amount of > resources to be set aside for /below each HOT-PLUGGABLE bridge; their > values may be tweaked via a compile time option or via a sysctl. > > FEW COMMENTS > ------------ > > 1) The strategy is fairly generic and tweak-able since it does not waste > a lot of resources (The developer neds to pick up a smart bvalue for > howmuch resources to reserve at each hot-pluggable slot): > > * The reservations shall be done only for hot-pluggable bridges > > * The developer can tweak the values (even disable it) for how much > Resources shall be allocated for each hot-pluggable bridge. > > 2) One point of debate is what happens if there are too much resource > demands in the system (too many devices or the developer configures too > many resources to be allocated for each hot-pluggable devices). For e.g. > consider that while enumeration we find that all the resources are > already allocated, while there are more devices that need resources. So > do we simply do not enumerate them? Etc... > > Overall, how does the above look? I think one wrinkle is that we should try to preserve the resources that the firmware has set for devices, at least on x86. I had also wanted to make use of multipass for this, but that requires a bit more work to split the PCI bus attach up into separate steps. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Feb 23 21:13:11 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D70C81065679 for ; Tue, 23 Feb 2010 21:13:11 +0000 (UTC) (envelope-from rink@gloom.codethulu.net) Received: from mx1.codethulu.net (mail.codethulu.net [77.243.236.173]) by mx1.freebsd.org (Postfix) with ESMTP id AA54B8FC1C for ; Tue, 23 Feb 2010 21:13:11 +0000 (UTC) Received: from anathema.codethulu.net (mail.codethulu.net [77.243.236.173]) by mx1.codethulu.net (Postfix) with ESMTP id D058E3758DEE; Tue, 23 Feb 2010 21:58:07 +0100 (CET) X-Virus-Scanned: amavisd-new at codethulu.net Received: from mx1.codethulu.net ([77.243.236.173]) by anathema.codethulu.net (anathema.codethulu.net [77.243.236.173]) (amavisd-new, port 10024) with ESMTP id SxKKH9QbaqF5; Tue, 23 Feb 2010 21:58:03 +0100 (CET) Received: from gloom.codethulu.net (mail.codethulu.net [77.243.236.173]) by mx1.codethulu.net (Postfix) with ESMTP id 9C8D83758DAB; Tue, 23 Feb 2010 21:58:03 +0100 (CET) Received: by gloom.codethulu.net (Postfix, from userid 1000) id 974136D455; Tue, 23 Feb 2010 21:58:03 +0100 (CET) Date: Tue, 23 Feb 2010 21:58:03 +0100 From: Rink Springer To: Carlos Vicente Message-ID: <20100223205803.GA6333@rink.nu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-arch@FreeBSD.org Subject: Re: Intel Atom processor X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 21:13:11 -0000 Hi Carlos, On Tue, Feb 23, 2010 at 01:05:20PM +0000, Carlos Vicente wrote: > I would like to know if all the Intel Atom Processors are supported on > FreeBSD 7.2. The reason is that I want to implement a Firewall system with a > less expensive processor, so I came up with this solution, but I don't want > to buy it without your confirmation. I'm using an Intel Atom 330 as my home router, and it works great (I do run FreeBSD 8 on it, but 7 would work fine as well). Same goes for the Atom in my Acer Aspire One netbook (1.6GHz); there shouldn't be any problems. Regards, -- Rink P.W. Springer - http://rink.nu "Beauty often seduces us on the road to truth." - Dr. Wilson From owner-freebsd-arch@FreeBSD.ORG Wed Feb 24 01:36:31 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34819106566C; Wed, 24 Feb 2010 01:36:31 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by mx1.freebsd.org (Postfix) with ESMTP id F256C8FC13; Wed, 24 Feb 2010 01:36:30 +0000 (UTC) Received: from vms061.mailsrvcs.net ([unknown] [192.168.1.2]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0KYB00JFIG3V29A5@vms173019.mailsrvcs.net>; Tue, 23 Feb 2010 16:35:56 -0600 (CST) Received: from 65.242.108.162 ([65.242.108.162]) by vms061.mailsrvcs.net (Verizon Webmail) with HTTP; Tue, 23 Feb 2010 16:35:55 -0600 (CST) Date: Tue, 23 Feb 2010 16:35:55 -0600 (CST) From: Sergey Babkin To: jhb@freebsd.org Message-id: <24099271.347187.1266964555857.JavaMail.root@vms061.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit X-Originating-IP: [65.242.108.162] Cc: rajatjain@juniper.net, freebsd-ia32@freebsd.org, freebsd-new-bus@freebsd.org, freebsd-ppc@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Re: Strategy for PCI resource management (for supporting hot-plug) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 01:36:31 -0000 (Sorry, if the email comes out looking weird, I want to give another try to see if the provider has fixed the formatting issues i nthe web interface or not). On Tuesday 23 February 2010 2:16:40 am Rajat Jain wrote: > > Hi, > > I'm trying to add PCI-E hotplug support to the FreeBSD. As a first step > for the PCI-E hotplug support, I'm trying to decide on a resource > management / allocation strategy for the PCI memory / IO and the bus > numbers. Can you please comment on the following approach that I am > considering for resource allocation: > > PROBLEM STATEMENT: > ------------------ > Given a memory range [A->B], IO range [C->D], and limited (256) bus > numbers, enumerate the PCI tree of a system, leaving enough "holes" in > between to allow addition of future devices. > > PROPOSED STRATEGY: > ------------------ > 1) When booting, start enumerating in a depth-first-search order. While > enumeration, always keep track of: > > * The next bus number (x) that can be allocated > > * The next Memory space pointer (A + y) starting which allocation can > be > done. ("y" is the memory already allocated). > > * The next IO Space pointer (C + z) starting which allocation can be > done. > ("z" is the IO space already allocated). > > Keep incrementing the above as the resources are allocated. > > 2) Allocate bus numbers sequentially while traversing down from root to > a leaf node (end point). When going down traversing a bridge: > > * Allocate the next available bus number (x) to the secondary bus of > bridge. > > * Temporarily mark the subordinate bridge as 0xFF (to allow discovery > of > maximum buses). > > * Temporarily assign all the remaining available memory space to bridge > > [(A+x) -> B]. Ditto for IO space. > > 3) When a leaf node (End point) is reached, allocate the memory / IO > resource requested by the device, and increment the pointers. > > 4) While passing a bridge in the upward direction, tweak the bridge > registers such that its resources are ONLY ENOUGH to address the needs > of all the PCI tree below it, and if it has its own internal memory > mapped registers, some memory for it as well. > > The above is the standard depth-first algorithm for resource allocation. > Here is the addition to support hot-plug: > > At each bridge that supports hot-plug, in addition to the resources that > would have normally been allocated to this bridge, additionally > pre-allocate and assign to bridge (in anticipation of any new devices > that may be added later): > > a) "RSRVE_NUM_BUS" number of busses, to cater to any bridges, PCI trees > present on the device plugged. > > b) "RSRVE_MEM" amount of memory space, to cater to all the PCI devices > that > may be attached later on. > > c) "RESRVE_IO" amount of IO space, to cater to all PCI devices that may > be > attached later on. A kind of stupid question: should the reserve amounts depend on the level of the bridge? Perhaps the priidges closer to the root should get more reserves. Perhaps it doesn't matter so much durin gthe initial enumeration but ma matter latter after a hot plug. Suppose we have the Bridge B1 that gets RSRVE resources attached to it during the initial enumeration. Then someone comes and hot-plugs a bridge B2 under B1. B2 then I guess will also try to get a reserve of RSRVE resources for itself, so it would take the whole original reserve of B1 to itself. If someone comes later and tries to hot-plug another bridge B3 under B1, that bridge would not get any resources and the plugging would fail. -SB From owner-freebsd-arch@FreeBSD.ORG Wed Feb 24 03:32:50 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DB00106566B for ; Wed, 24 Feb 2010 03:32:50 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-08.arcor-online.net (mail-in-08.arcor-online.net [151.189.21.48]) by mx1.freebsd.org (Postfix) with ESMTP id 045548FC08 for ; Wed, 24 Feb 2010 03:32:49 +0000 (UTC) Received: from mail-in-03-z2.arcor-online.net (mail-in-03-z2.arcor-online.net [151.189.8.15]) by mx.arcor.de (Postfix) with ESMTP id 290122AED81 for ; Wed, 24 Feb 2010 00:11:35 +0100 (CET) Received: from mail-in-04.arcor-online.net (mail-in-04.arcor-online.net [151.189.21.44]) by mail-in-03-z2.arcor-online.net (Postfix) with ESMTP id 20E212D30AF for ; Wed, 24 Feb 2010 00:11:35 +0100 (CET) Received: from lorvorc.mips.inka.de (dslb-088-067-124-198.pools.arcor-ip.net [88.67.124.198]) by mail-in-04.arcor-online.net (Postfix) with ESMTPS id DD66933A73E for ; Wed, 24 Feb 2010 00:11:34 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-04.arcor-online.net DD66933A73E Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.4/8.14.3) with ESMTP id o1NNBYYI082805 for ; Wed, 24 Feb 2010 00:11:34 +0100 (CET) (envelope-from mailnull@lorvorc.mips.inka.de) Received: (from mailnull@localhost) by lorvorc.mips.inka.de (8.14.4/8.14.4/Submit) id o1NNBYKm082804 for freebsd-arch@freebsd.org; Wed, 24 Feb 2010 00:11:34 +0100 (CET) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Tue, 23 Feb 2010 23:11:34 +0000 (UTC) Message-ID: References: <4B80CA57.9000808@freebsd.org> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-arch@freebsd.org Subject: Re: Importing liblzma, xz X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 03:32:50 -0000 Tim Kientzle wrote: > More information about the xz project: > http://tukaani.org/xz/ > > According to that page, the final 5.0 production > version should be released pretty soon. That note has been there for five months. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-arch@FreeBSD.ORG Wed Feb 24 04:35:19 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDADB106566B; Wed, 24 Feb 2010 04:35:19 +0000 (UTC) (envelope-from rajatjain@juniper.net) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by mx1.freebsd.org (Postfix) with ESMTP id CCD708FC16; Wed, 24 Feb 2010 04:35:18 +0000 (UTC) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKS4SshmVUaDSyL+FTm5ptlGPCuZEBf9AD@postini.com; Tue, 23 Feb 2010 20:35:19 PST Received: from gaugeboson.jnpr.net (10.209.194.17) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server id 8.1.393.1; Tue, 23 Feb 2010 20:32:39 -0800 Received: from emailbng3.jnpr.net ([10.209.194.27]) by gaugeboson.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 10:02:36 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Feb 2010 10:02:35 +0530 Message-ID: <8506939B503B404A84BBB12293FC45F606B88E55@emailbng3.jnpr.net> In-Reply-To: <24099271.347187.1266964555857.JavaMail.root@vms061.mailsrvcs.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Strategy for PCI resource management (for supporting hot-plug) Thread-Index: Acq02NJfpnyCYOSsRvKUNhQqcZ9VZQAMFnBg References: <24099271.347187.1266964555857.JavaMail.root@vms061.mailsrvcs.net> From: Rajat Jain To: Sergey Babkin , X-OriginalArrivalTime: 24 Feb 2010 04:32:36.0576 (UTC) FILETIME=[6403EE00:01CAB50A] Cc: freebsd-ia32@freebsd.org, freebsd-new-bus@freebsd.org, freebsd-ppc@freebsd.org, freebsd-arch@freebsd.org Subject: RE: Re: Strategy for PCI resource management (for supporting hot-plug) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 04:35:19 -0000 Hello Sergey, > A kind of stupid question: should the reserve amounts depend on the level > of the bridge? > Perhaps the priidges closer to the root should get more reserves. Perhaps > it doesn't > matter so much durin gthe initial enumeration but ma matter latter after a > hot plug. One clarification perhaps I did not give in my proposal. We would reserve resources (bus numbers / memory / IO) only for bridges that are CAPABLE of HOT-PLUG. The rest of the bridges would get their usual share of resources.=20 Now, the same amount of reserved resources gets assigned to each HOT-PLUG capable bridge, irrespective of at which level it is in hierarchy. This is because no matter where it is, there is equal probability of a new card being plugged in at ANY of those slots.=20 The only problem as you say is when we plug in a PCI card, which has a HOT-PLUGGABLE SLOT on it (on which we can plug in more cards). (This is because a bridge wants extra reserved resources only when it is hot-plug capable). Do such devices exist? Since theoretically possible, but practically extremely rare, I say we do not support this case. Comments? Thanks, Rajat Jain > -----Original Message----- > From: Sergey Babkin [mailto:babkin@verizon.net] > Sent: Wednesday, February 24, 2010 4:06 AM > To: jhb@freebsd.org > Cc: freebsd-arch@freebsd.org; Rajat Jain; freebsd-ia32@freebsd.org; > freebsd-new-bus@freebsd.org; freebsd-ppc@freebsd.org > Subject: Re: Re: Strategy for PCI resource management (for supporting hot- > plug) >=20 > (Sorry, if the email comes out looking weird, I want to give another try > to see if the provider has > fixed the formatting issues i nthe web interface or not). >=20 > On Tuesday 23 February 2010 2:16:40 am Rajat Jain wrote: > > > > Hi, > > > > I'm trying to add PCI-E hotplug support to the FreeBSD. As a first step > > for the PCI-E hotplug support, I'm trying to decide on a resource > > management / allocation strategy for the PCI memory / IO and the bus > > numbers. Can you please comment on the following approach that I am > > considering for resource allocation: > > > > PROBLEM STATEMENT: > > ------------------ > > Given a memory range [A->B], IO range [C->D], and limited (256) bus > > numbers, enumerate the PCI tree of a system, leaving enough "holes" in > > between to allow addition of future devices. > > > > PROPOSED STRATEGY: > > ------------------ > > 1) When booting, start enumerating in a depth-first-search order. While > > enumeration, always keep track of: > > > > * The next bus number (x) that can be allocated > > > > * The next Memory space pointer (A + y) starting which allocation can > > be > > done. ("y" is the memory already allocated). > > > > * The next IO Space pointer (C + z) starting which allocation can be > > done. > > ("z" is the IO space already allocated). > > > > Keep incrementing the above as the resources are allocated. > > > > 2) Allocate bus numbers sequentially while traversing down from root to > > a leaf node (end point). When going down traversing a bridge: > > > > * Allocate the next available bus number (x) to the secondary bus of > > bridge. > > > > * Temporarily mark the subordinate bridge as 0xFF (to allow discovery > > of > > maximum buses). > > > > * Temporarily assign all the remaining available memory space to bridge > > > > [(A+x) -> B]. Ditto for IO space. > > > > 3) When a leaf node (End point) is reached, allocate the memory / IO > > resource requested by the device, and increment the pointers. > > > > 4) While passing a bridge in the upward direction, tweak the bridge > > registers such that its resources are ONLY ENOUGH to address the needs > > of all the PCI tree below it, and if it has its own internal memory > > mapped registers, some memory for it as well. > > > > The above is the standard depth-first algorithm for resource allocation. > > Here is the addition to support hot-plug: > > > > At each bridge that supports hot-plug, in addition to the resources that > > would have normally been allocated to this bridge, additionally > > pre-allocate and assign to bridge (in anticipation of any new devices > > that may be added later): > > > > a) "RSRVE_NUM_BUS" number of busses, to cater to any bridges, PCI trees > > present on the device plugged. > > > > b) "RSRVE_MEM" amount of memory space, to cater to all the PCI devices > > that > > may be attached later on. > > > > c) "RESRVE_IO" amount of IO space, to cater to all PCI devices that may > > be > > attached later on. >=20 > A kind of stupid question: should the reserve amounts depend on the level > of the bridge? > Perhaps the priidges closer to the root should get more reserves. Perhaps > it doesn't > matter so much durin gthe initial enumeration but ma matter latter after a > hot plug. >=20 > Suppose we have the Bridge B1 that gets RSRVE resources attached to it > during > the initial enumeration. Then someone comes and hot-plugs a bridge B2 > under B1. > B2 then I guess will also try to get a reserve of RSRVE resources for > itself, so it would > take the whole original reserve of B1 to itself. If someone comes later > and tries > to hot-plug another bridge B3 under B1, that bridge would not get any > resources > and the plugging would fail. >=20 > -SB From owner-freebsd-arch@FreeBSD.ORG Wed Feb 24 04:42:28 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44208106566B for ; Wed, 24 Feb 2010 04:42:28 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 036B08FC15 for ; Wed, 24 Feb 2010 04:42:26 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.3/8.14.3) id o1O4gZD7046844; Wed, 24 Feb 2010 04:42:35 GMT (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id zqrr8bjinv63wq3dtq75gfd8i6; Wed, 24 Feb 2010 04:42:35 +0000 (UTC) (envelope-from kientzle@freebsd.org) Message-ID: <4B84AE74.9010209@freebsd.org> Date: Tue, 23 Feb 2010 20:43:32 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090601 SeaMonkey/1.1.16 MIME-Version: 1.0 To: Christian Weisgerber References: <4B80CA57.9000808@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Importing liblzma, xz X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 04:42:28 -0000 Christian Weisgerber wrote: > Tim Kientzle wrote: > >> More information about the xz project: >> http://tukaani.org/xz/ >> >> According to that page, the final 5.0 production >> version should be released pretty soon. > > That note has been there for five months. Yes, it has. That's why I'd like to go ahead and import 4.999.9beta into FreeBSD-CURRENT. ;-) Tim From owner-freebsd-arch@FreeBSD.ORG Wed Feb 24 11:46:00 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62A211065679 for ; Wed, 24 Feb 2010 11:46:00 +0000 (UTC) (envelope-from cjpvicente@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id E75798FC0C for ; Wed, 24 Feb 2010 11:45:59 +0000 (UTC) Received: by bwz8 with SMTP id 8so3597788bwz.3 for ; Wed, 24 Feb 2010 03:45:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=WHRFPAZ2yHUxJxhqSKxv3UmOthzJ1pSScD96+wQDMOM=; b=RDhGGNRLhvszITjjgTvNL0EdwI4e0mv9vdWYvYLd8FEC808TYZ/T4wYEpvW7o8ffKs jwYu5QCanpSOLiUi/Iy0S+CRhvvLHdM5wJy8N1Mx6PbydAF6k3/7t3v2NUlRLrKitch1 uV9cJBjzdidTC0wpa/hq7nZAPsab2ULsLGBxI= 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=MKl5LmIZUqvqkYus8+eHb1KPKQUDs7IXDl35VUFPx1kVe9RlansO4Nna0MOXxHp5UQ Wa/hTNPu4yBb3+eDz5svLvx7be4WpVmDH/mD+JDF8/iuN9JzEysEgt+IG0IROPldKWRk 1JWCnR5jw4uoEt24zATJ6u6nu+4w1CUE8wGa8= MIME-Version: 1.0 Received: by 10.204.140.18 with SMTP id g18mr4762779bku.47.1267011952781; Wed, 24 Feb 2010 03:45:52 -0800 (PST) In-Reply-To: <20100223205803.GA6333@rink.nu> References: <20100223205803.GA6333@rink.nu> Date: Wed, 24 Feb 2010 11:45:50 +0000 Message-ID: From: Carlos Vicente To: Rink Springer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arch@freebsd.org Subject: Re: Intel Atom processor X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 11:46:00 -0000 Rink, thank you for your help. Regards, Carlos On Tue, Feb 23, 2010 at 8:58 PM, Rink Springer wrote: > Hi Carlos, > > On Tue, Feb 23, 2010 at 01:05:20PM +0000, Carlos Vicente wrote: > > I would like to know if all the Intel Atom Processors are supported on > > FreeBSD 7.2. The reason is that I want to implement a Firewall system > with a > > less expensive processor, so I came up with this solution, but I don't > want > > to buy it without your confirmation. > > I'm using an Intel Atom 330 as my home router, and it works great (I do > run FreeBSD 8 on it, but 7 would work fine as well). Same goes for the > Atom in my Acer Aspire One netbook (1.6GHz); there shouldn't be any > problems. > > Regards, > > -- > Rink P.W. Springer - http://rink.nu > "Beauty often seduces us on the road to truth." > - Dr. Wilson > --=20 ---------------------------------------------------------------------------= --- Este e-mail e quaisquer ficheiros a ele anexados s=E3o confidenciais e destinados, exclusivamente, =E0 pessoa ou entidade a quem foi endere=E7ado. Se recebeu = este e-mail por erro, por favor, contacte-nos. Obrigado. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify us. Antes de imprimir este e-mail pense se necessita mesmo de o fazer From owner-freebsd-arch@FreeBSD.ORG Wed Feb 24 15:18:42 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 819D91065670 for ; Wed, 24 Feb 2010 15:18:42 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f185.google.com (mail-iw0-f185.google.com [209.85.223.185]) by mx1.freebsd.org (Postfix) with ESMTP id 475F78FC08 for ; Wed, 24 Feb 2010 15:18:41 +0000 (UTC) Received: by iwn15 with SMTP id 15so4192988iwn.7 for ; Wed, 24 Feb 2010 07:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=dOTXLnKbAwETmr8S4fuM0LcHYsspskfRjiNroOgn/PQ=; b=aRNJW3uz2V/4JRs2yyCDw+9ShIQh5n7jRtuuQCYWA1S8B/wgq7jjd15TFUqMnAMUUu HaARNA40DfwNDD0GOx64hQBjlexiOg6QLMoipNS2gem0AHhLDyKsRLEHkMx6GcSUjkZU KBsw4tFIgCZ9oCKmkmm+hv8qMhQC6D8GbFH8s= 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=HSv//TUkBKX7JE7dMTvCiaGzV1XqDQ9QrhYHQvmgN+Fg+VoBAf/hQvLlGqJq2G8m8N M94da4xnoxHwp6B4AtNE1ji1/kZAFLiDjxnzH2R6I7NY3XrG4cxSlP7DRrgcmZqlzzrC yzjleg56lzn6Z5DxpkgJCyVMVB+vRY0HFQc/c= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.156.205 with SMTP id y13mr844681ibw.27.1267024714664; Wed, 24 Feb 2010 07:18:34 -0800 (PST) In-Reply-To: <20100216195440.GF50403@deviant.kiev.zoral.com.ua> References: <3bbf2fe11002151610l41526f55r5e60b5e46ce42b64@mail.gmail.com> <20100216195440.GF50403@deviant.kiev.zoral.com.ua> Date: Wed, 24 Feb 2010 16:18:34 +0100 X-Google-Sender-Auth: d8d4c1f5795fcb17 Message-ID: <3bbf2fe11002240718x5182aa93w5a00c657a0fba5f6@mail.gmail.com> From: Attilio Rao To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Arch , Ed Maste Subject: Re: [PATCH] Adding shared code support for ia32 and amd64 -- x86 sub-branch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 15:18:42 -0000 2010/2/16 Kostik Belousov : > On Tue, Feb 16, 2010 at 01:10:37AM +0100, Attilio Rao wrote: >> The following patch: >> http://www.freebsd.org/~attilio/x86.diff >> >> starts the effort for having a shared sub-tree between amd64 and ia32. >> In this initial pass I putted the low-hanging fruits (bios/cpufreq) >> and what my customer was more interested in (isa/*) in order to >> kick-off the effort and, in the future, move gradually the code there. >> With the machine/isa/* cleanup about 10 files are trimmed and I'm sure >> more can be achieved easilly. >> There are few things to discuss. One, that I had not necessity to dig >> about still, is about how to organize headers (include/). Maybe some >> replication ala pc98 may be good. >> >> The patch is big but it is mostly added and removed files (look at the >> files.X in order to understand better how files movements happened). >> >> Hope to see comments and reviews. > > IMO the diff is unreadable. I suggest to do actual svn cp (not svn mv) > operation now, without a review, and post a diff that should be applied > to x86/ directory, as well as to build glue. I think that this patch juices out all the relevant part without noise: http://www.freebsd.org/~attilio/x86-2.diff Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Wed Feb 24 15:46:43 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AFB2106564A; Wed, 24 Feb 2010 15:46:43 +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 0AC0B8FC12; Wed, 24 Feb 2010 15:46:43 +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 B67A046B03; Wed, 24 Feb 2010 10:46:42 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 562618A021; Wed, 24 Feb 2010 10:46:30 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 24 Feb 2010 10:41:56 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <3bbf2fe11002151610l41526f55r5e60b5e46ce42b64@mail.gmail.com> <20100216195440.GF50403@deviant.kiev.zoral.com.ua> <3bbf2fe11002240718x5182aa93w5a00c657a0fba5f6@mail.gmail.com> In-Reply-To: <3bbf2fe11002240718x5182aa93w5a00c657a0fba5f6@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201002241041.56118.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 24 Feb 2010 10:46:30 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Attilio Rao , Kostik Belousov , Ed Maste , FreeBSD Arch Subject: Re: [PATCH] Adding shared code support for ia32 and amd64 -- x86 sub-branch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 15:46:43 -0000 On Wednesday 24 February 2010 10:18:34 am Attilio Rao wrote: > 2010/2/16 Kostik Belousov : > > On Tue, Feb 16, 2010 at 01:10:37AM +0100, Attilio Rao wrote: > >> The following patch: > >> http://www.freebsd.org/~attilio/x86.diff > >> > >> starts the effort for having a shared sub-tree between amd64 and ia32. > >> In this initial pass I putted the low-hanging fruits (bios/cpufreq) > >> and what my customer was more interested in (isa/*) in order to > >> kick-off the effort and, in the future, move gradually the code there. > >> With the machine/isa/* cleanup about 10 files are trimmed and I'm sure > >> more can be achieved easilly. > >> There are few things to discuss. One, that I had not necessity to dig > >> about still, is about how to organize headers (include/). Maybe some > >> replication ala pc98 may be good. > >> > >> The patch is big but it is mostly added and removed files (look at the > >> files.X in order to understand better how files movements happened). > >> > >> Hope to see comments and reviews. > > > > IMO the diff is unreadable. I suggest to do actual svn cp (not svn mv) > > operation now, without a review, and post a diff that should be applied > > to x86/ directory, as well as to build glue. > > I think that this patch juices out all the relevant part without noise: > http://www.freebsd.org/~attilio/x86-2.diff I think this looks good. We should likely be unifying the approach to suspend/resume for timers across i386 and amd64 btw. pmtimer should be available for amd64 as well for example. I'm also not sure if adding a resume method for atrtc means that pmtimer needs to change to not frob the RTC in its suspend and resume methods now as well. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Feb 24 15:46:43 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AFB2106564A; Wed, 24 Feb 2010 15:46:43 +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 0AC0B8FC12; Wed, 24 Feb 2010 15:46:43 +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 B67A046B03; Wed, 24 Feb 2010 10:46:42 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 562618A021; Wed, 24 Feb 2010 10:46:30 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 24 Feb 2010 10:41:56 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <3bbf2fe11002151610l41526f55r5e60b5e46ce42b64@mail.gmail.com> <20100216195440.GF50403@deviant.kiev.zoral.com.ua> <3bbf2fe11002240718x5182aa93w5a00c657a0fba5f6@mail.gmail.com> In-Reply-To: <3bbf2fe11002240718x5182aa93w5a00c657a0fba5f6@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201002241041.56118.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 24 Feb 2010 10:46:30 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Attilio Rao , Kostik Belousov , Ed Maste , FreeBSD Arch Subject: Re: [PATCH] Adding shared code support for ia32 and amd64 -- x86 sub-branch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 15:46:43 -0000 On Wednesday 24 February 2010 10:18:34 am Attilio Rao wrote: > 2010/2/16 Kostik Belousov : > > On Tue, Feb 16, 2010 at 01:10:37AM +0100, Attilio Rao wrote: > >> The following patch: > >> http://www.freebsd.org/~attilio/x86.diff > >> > >> starts the effort for having a shared sub-tree between amd64 and ia32. > >> In this initial pass I putted the low-hanging fruits (bios/cpufreq) > >> and what my customer was more interested in (isa/*) in order to > >> kick-off the effort and, in the future, move gradually the code there. > >> With the machine/isa/* cleanup about 10 files are trimmed and I'm sure > >> more can be achieved easilly. > >> There are few things to discuss. One, that I had not necessity to dig > >> about still, is about how to organize headers (include/). Maybe some > >> replication ala pc98 may be good. > >> > >> The patch is big but it is mostly added and removed files (look at the > >> files.X in order to understand better how files movements happened). > >> > >> Hope to see comments and reviews. > > > > IMO the diff is unreadable. I suggest to do actual svn cp (not svn mv) > > operation now, without a review, and post a diff that should be applied > > to x86/ directory, as well as to build glue. > > I think that this patch juices out all the relevant part without noise: > http://www.freebsd.org/~attilio/x86-2.diff I think this looks good. We should likely be unifying the approach to suspend/resume for timers across i386 and amd64 btw. pmtimer should be available for amd64 as well for example. I'm also not sure if adding a resume method for atrtc means that pmtimer needs to change to not frob the RTC in its suspend and resume methods now as well. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Feb 24 15:50:51 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05AE3106566B; Wed, 24 Feb 2010 15:50:51 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f185.google.com (mail-iw0-f185.google.com [209.85.223.185]) by mx1.freebsd.org (Postfix) with ESMTP id 9EE348FC19; Wed, 24 Feb 2010 15:50:50 +0000 (UTC) Received: by iwn15 with SMTP id 15so4223694iwn.7 for ; Wed, 24 Feb 2010 07:50:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=oTvTtoq+sPmStOqN2jYAHxlUohjbCrngHbLQgBR8dLg=; b=uAPdgxQYRLo5zzKlm23INm451BNB4/k58dEioK/W+ehMFdqQAkvHd6ET1iyrOt2T4y ukgr53knWhsAV3CYjPVUiNwkMCXlgEKjag4KwM1BEhcw2xAuMR794WmEXbgQ3o9uG5m0 F/ZUfNikZ2aTat9Vjbi9gx4y20CDEBTNI/bIg= 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=tJjrJHhbi2Rvmu6osbdyC5KXR8MZX01enAl6xzsf2NOzHtho28sJWJfE+cXbyFNHEZ mMCK4wQCbuje4xVOfJoASh1mshh7lAw+7Y5dpsrNBhgPJMnFY6JiEmWd6wbDLNZD593N 0yFPG/J08fkNVIh9wXH3PEJNziUUxz6lmDoRg= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.148.205 with SMTP id q13mr2625ibv.47.1267026649923; Wed, 24 Feb 2010 07:50:49 -0800 (PST) In-Reply-To: <201002241041.56118.jhb@freebsd.org> References: <3bbf2fe11002151610l41526f55r5e60b5e46ce42b64@mail.gmail.com> <20100216195440.GF50403@deviant.kiev.zoral.com.ua> <3bbf2fe11002240718x5182aa93w5a00c657a0fba5f6@mail.gmail.com> <201002241041.56118.jhb@freebsd.org> Date: Wed, 24 Feb 2010 16:50:49 +0100 X-Google-Sender-Auth: 5e4c36da3a35657b Message-ID: <3bbf2fe11002240750r69779948icc6d242fce26abc8@mail.gmail.com> From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , FreeBSD Arch , Ed Maste , freebsd-arch@freebsd.org Subject: Re: [PATCH] Adding shared code support for ia32 and amd64 -- x86 sub-branch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 15:50:51 -0000 2010/2/24 John Baldwin : > On Wednesday 24 February 2010 10:18:34 am Attilio Rao wrote: >> 2010/2/16 Kostik Belousov : >> > On Tue, Feb 16, 2010 at 01:10:37AM +0100, Attilio Rao wrote: >> >> The following patch: >> >> http://www.freebsd.org/~attilio/x86.diff >> >> >> >> starts the effort for having a shared sub-tree between amd64 and ia32= . >> >> In this initial pass I putted the low-hanging fruits (bios/cpufreq) >> >> and what my customer was more interested in (isa/*) in order to >> >> kick-off the effort and, in the future, move gradually the code there= . >> >> With the machine/isa/* cleanup about 10 files are trimmed and I'm sur= e >> >> more can be achieved easilly. >> >> There are few things to discuss. One, that I had not necessity to dig >> >> about still, is about how to organize headers (include/). Maybe some >> >> replication ala pc98 may be good. >> >> >> >> The patch is big but it is mostly added and removed files (look at th= e >> >> files.X in order to understand better how files movements happened). >> >> >> >> Hope to see comments and reviews. >> > >> > IMO the diff is unreadable. I suggest to do actual svn cp (not svn mv) >> > operation now, without a review, and post a diff that should be applie= d >> > to x86/ directory, as well as to build glue. >> >> I think that this patch juices out all the relevant part without noise: >> http://www.freebsd.org/~attilio/x86-2.diff > > I think this looks good. =C2=A0We should likely be unifying the approach = to > suspend/resume for timers across i386 and amd64 btw. =C2=A0pmtimer should= be > available for amd64 as well for example. =C2=A0I'm also not sure if addin= g a resume > method for atrtc means that pmtimer needs to change to not frob the RTC i= n its > suspend and resume methods now as well. Yes, I would do this (and other simple, already compelling, unifications, like the e/rflags one) into further passes. In this case, probabilly, more mealpieces we do the better it is, IMHO. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Wed Feb 24 15:50:51 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05AE3106566B; Wed, 24 Feb 2010 15:50:51 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f185.google.com (mail-iw0-f185.google.com [209.85.223.185]) by mx1.freebsd.org (Postfix) with ESMTP id 9EE348FC19; Wed, 24 Feb 2010 15:50:50 +0000 (UTC) Received: by iwn15 with SMTP id 15so4223694iwn.7 for ; Wed, 24 Feb 2010 07:50:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=oTvTtoq+sPmStOqN2jYAHxlUohjbCrngHbLQgBR8dLg=; b=uAPdgxQYRLo5zzKlm23INm451BNB4/k58dEioK/W+ehMFdqQAkvHd6ET1iyrOt2T4y ukgr53knWhsAV3CYjPVUiNwkMCXlgEKjag4KwM1BEhcw2xAuMR794WmEXbgQ3o9uG5m0 F/ZUfNikZ2aTat9Vjbi9gx4y20CDEBTNI/bIg= 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=tJjrJHhbi2Rvmu6osbdyC5KXR8MZX01enAl6xzsf2NOzHtho28sJWJfE+cXbyFNHEZ mMCK4wQCbuje4xVOfJoASh1mshh7lAw+7Y5dpsrNBhgPJMnFY6JiEmWd6wbDLNZD593N 0yFPG/J08fkNVIh9wXH3PEJNziUUxz6lmDoRg= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.148.205 with SMTP id q13mr2625ibv.47.1267026649923; Wed, 24 Feb 2010 07:50:49 -0800 (PST) In-Reply-To: <201002241041.56118.jhb@freebsd.org> References: <3bbf2fe11002151610l41526f55r5e60b5e46ce42b64@mail.gmail.com> <20100216195440.GF50403@deviant.kiev.zoral.com.ua> <3bbf2fe11002240718x5182aa93w5a00c657a0fba5f6@mail.gmail.com> <201002241041.56118.jhb@freebsd.org> Date: Wed, 24 Feb 2010 16:50:49 +0100 X-Google-Sender-Auth: 5e4c36da3a35657b Message-ID: <3bbf2fe11002240750r69779948icc6d242fce26abc8@mail.gmail.com> From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , FreeBSD Arch , Ed Maste , freebsd-arch@freebsd.org Subject: Re: [PATCH] Adding shared code support for ia32 and amd64 -- x86 sub-branch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 15:50:51 -0000 2010/2/24 John Baldwin : > On Wednesday 24 February 2010 10:18:34 am Attilio Rao wrote: >> 2010/2/16 Kostik Belousov : >> > On Tue, Feb 16, 2010 at 01:10:37AM +0100, Attilio Rao wrote: >> >> The following patch: >> >> http://www.freebsd.org/~attilio/x86.diff >> >> >> >> starts the effort for having a shared sub-tree between amd64 and ia32= . >> >> In this initial pass I putted the low-hanging fruits (bios/cpufreq) >> >> and what my customer was more interested in (isa/*) in order to >> >> kick-off the effort and, in the future, move gradually the code there= . >> >> With the machine/isa/* cleanup about 10 files are trimmed and I'm sur= e >> >> more can be achieved easilly. >> >> There are few things to discuss. One, that I had not necessity to dig >> >> about still, is about how to organize headers (include/). Maybe some >> >> replication ala pc98 may be good. >> >> >> >> The patch is big but it is mostly added and removed files (look at th= e >> >> files.X in order to understand better how files movements happened). >> >> >> >> Hope to see comments and reviews. >> > >> > IMO the diff is unreadable. I suggest to do actual svn cp (not svn mv) >> > operation now, without a review, and post a diff that should be applie= d >> > to x86/ directory, as well as to build glue. >> >> I think that this patch juices out all the relevant part without noise: >> http://www.freebsd.org/~attilio/x86-2.diff > > I think this looks good. =C2=A0We should likely be unifying the approach = to > suspend/resume for timers across i386 and amd64 btw. =C2=A0pmtimer should= be > available for amd64 as well for example. =C2=A0I'm also not sure if addin= g a resume > method for atrtc means that pmtimer needs to change to not frob the RTC i= n its > suspend and resume methods now as well. Yes, I would do this (and other simple, already compelling, unifications, like the e/rflags one) into further passes. In this case, probabilly, more mealpieces we do the better it is, IMHO. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Wed Feb 24 16:28:58 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8234A1065670; Wed, 24 Feb 2010 16:28:58 +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 30DC48FC16; Wed, 24 Feb 2010 16:28:58 +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 DEEA046B2E; Wed, 24 Feb 2010 11:28:57 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 865758A01F; Wed, 24 Feb 2010 11:28:42 -0500 (EST) From: John Baldwin To: Attilio Rao Date: Wed, 24 Feb 2010 11:28:08 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <3bbf2fe11002151610l41526f55r5e60b5e46ce42b64@mail.gmail.com> <201002241041.56118.jhb@freebsd.org> <3bbf2fe11002240750r69779948icc6d242fce26abc8@mail.gmail.com> In-Reply-To: <3bbf2fe11002240750r69779948icc6d242fce26abc8@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201002241128.08698.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 24 Feb 2010 11:28:42 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Kostik Belousov , FreeBSD Arch , Ed Maste , freebsd-arch@freebsd.org Subject: Re: [PATCH] Adding shared code support for ia32 and amd64 -- x86 sub-branch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 16:28:58 -0000 On Wednesday 24 February 2010 10:50:49 am Attilio Rao wrote: > 2010/2/24 John Baldwin : > > On Wednesday 24 February 2010 10:18:34 am Attilio Rao wrote: > >> 2010/2/16 Kostik Belousov : > >> > On Tue, Feb 16, 2010 at 01:10:37AM +0100, Attilio Rao wrote: > >> >> The following patch: > >> >> http://www.freebsd.org/~attilio/x86.diff > >> >> > >> >> starts the effort for having a shared sub-tree between amd64 and ia32. > >> >> In this initial pass I putted the low-hanging fruits (bios/cpufreq) > >> >> and what my customer was more interested in (isa/*) in order to > >> >> kick-off the effort and, in the future, move gradually the code there. > >> >> With the machine/isa/* cleanup about 10 files are trimmed and I'm sure > >> >> more can be achieved easilly. > >> >> There are few things to discuss. One, that I had not necessity to dig > >> >> about still, is about how to organize headers (include/). Maybe some > >> >> replication ala pc98 may be good. > >> >> > >> >> The patch is big but it is mostly added and removed files (look at the > >> >> files.X in order to understand better how files movements happened). > >> >> > >> >> Hope to see comments and reviews. > >> > > >> > IMO the diff is unreadable. I suggest to do actual svn cp (not svn mv) > >> > operation now, without a review, and post a diff that should be applied > >> > to x86/ directory, as well as to build glue. > >> > >> I think that this patch juices out all the relevant part without noise: > >> http://www.freebsd.org/~attilio/x86-2.diff > > > > I think this looks good. We should likely be unifying the approach to > > suspend/resume for timers across i386 and amd64 btw. pmtimer should be > > available for amd64 as well for example. I'm also not sure if adding a resume > > method for atrtc means that pmtimer needs to change to not frob the RTC in its > > suspend and resume methods now as well. > > Yes, I would do this (and other simple, already compelling, > unifications, like the e/rflags one) into further passes. > In this case, probabilly, more mealpieces we do the better it is, IMHO. Yes, I would definitely split this up to move single "entities" (e.g. smbios or atpic) per commit. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Feb 24 16:28:58 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8234A1065670; Wed, 24 Feb 2010 16:28:58 +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 30DC48FC16; Wed, 24 Feb 2010 16:28:58 +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 DEEA046B2E; Wed, 24 Feb 2010 11:28:57 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 865758A01F; Wed, 24 Feb 2010 11:28:42 -0500 (EST) From: John Baldwin To: Attilio Rao Date: Wed, 24 Feb 2010 11:28:08 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <3bbf2fe11002151610l41526f55r5e60b5e46ce42b64@mail.gmail.com> <201002241041.56118.jhb@freebsd.org> <3bbf2fe11002240750r69779948icc6d242fce26abc8@mail.gmail.com> In-Reply-To: <3bbf2fe11002240750r69779948icc6d242fce26abc8@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201002241128.08698.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 24 Feb 2010 11:28:42 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Kostik Belousov , FreeBSD Arch , Ed Maste , freebsd-arch@freebsd.org Subject: Re: [PATCH] Adding shared code support for ia32 and amd64 -- x86 sub-branch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 16:28:58 -0000 On Wednesday 24 February 2010 10:50:49 am Attilio Rao wrote: > 2010/2/24 John Baldwin : > > On Wednesday 24 February 2010 10:18:34 am Attilio Rao wrote: > >> 2010/2/16 Kostik Belousov : > >> > On Tue, Feb 16, 2010 at 01:10:37AM +0100, Attilio Rao wrote: > >> >> The following patch: > >> >> http://www.freebsd.org/~attilio/x86.diff > >> >> > >> >> starts the effort for having a shared sub-tree between amd64 and ia32. > >> >> In this initial pass I putted the low-hanging fruits (bios/cpufreq) > >> >> and what my customer was more interested in (isa/*) in order to > >> >> kick-off the effort and, in the future, move gradually the code there. > >> >> With the machine/isa/* cleanup about 10 files are trimmed and I'm sure > >> >> more can be achieved easilly. > >> >> There are few things to discuss. One, that I had not necessity to dig > >> >> about still, is about how to organize headers (include/). Maybe some > >> >> replication ala pc98 may be good. > >> >> > >> >> The patch is big but it is mostly added and removed files (look at the > >> >> files.X in order to understand better how files movements happened). > >> >> > >> >> Hope to see comments and reviews. > >> > > >> > IMO the diff is unreadable. I suggest to do actual svn cp (not svn mv) > >> > operation now, without a review, and post a diff that should be applied > >> > to x86/ directory, as well as to build glue. > >> > >> I think that this patch juices out all the relevant part without noise: > >> http://www.freebsd.org/~attilio/x86-2.diff > > > > I think this looks good. We should likely be unifying the approach to > > suspend/resume for timers across i386 and amd64 btw. pmtimer should be > > available for amd64 as well for example. I'm also not sure if adding a resume > > method for atrtc means that pmtimer needs to change to not frob the RTC in its > > suspend and resume methods now as well. > > Yes, I would do this (and other simple, already compelling, > unifications, like the e/rflags one) into further passes. > In this case, probabilly, more mealpieces we do the better it is, IMHO. Yes, I would definitely split this up to move single "entities" (e.g. smbios or atpic) per commit. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Feb 25 01:16:43 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9A7D106564A; Thu, 25 Feb 2010 01:16:43 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id B04178FC12; Thu, 25 Feb 2010 01:16:43 +0000 (UTC) Received: from hydrogen.funkthat.com (rfi20yj7t50f7r9j@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id o1P0wgOC012002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Feb 2010 16:58:43 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id o1P0wfDi012001; Wed, 24 Feb 2010 16:58:41 -0800 (PST) (envelope-from jmg) Date: Wed, 24 Feb 2010 16:58:41 -0800 From: John-Mark Gurney To: Rajat Jain Message-ID: <20100225005841.GB58753@funkthat.com> Mail-Followup-To: Rajat Jain , Sergey Babkin , jhb@freebsd.org, freebsd-ia32@freebsd.org, freebsd-new-bus@freebsd.org, freebsd-ppc@freebsd.org, freebsd-arch@freebsd.org References: <24099271.347187.1266964555857.JavaMail.root@vms061.mailsrvcs.net> <8506939B503B404A84BBB12293FC45F606B88E55@emailbng3.jnpr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8506939B503B404A84BBB12293FC45F606B88E55@emailbng3.jnpr.net> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (hydrogen.funkthat.com [127.0.0.1]); Wed, 24 Feb 2010 16:58:43 -0800 (PST) Cc: freebsd-ia32@freebsd.org, freebsd-new-bus@freebsd.org, Sergey Babkin , freebsd-arch@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: Re: Strategy for PCI resource management (for supporting hot-plug) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 01:16:44 -0000 Rajat Jain wrote this message on Wed, Feb 24, 2010 at 10:02 +0530: > The only problem as you say is when we plug in a PCI card, which has a > HOT-PLUGGABLE SLOT on it (on which we can plug in more cards). (This is > because a bridge wants extra reserved resources only when it is hot-plug > capable). Do such devices exist? Since theoretically possible, but > practically extremely rare, I say we do not support this case. There is an ExpressCard PCI-E expansion box (I have one) which you could put a PCI-E cardbus adapter card in which would I believe be the case that you are asking about... Now how many people would do that? Not many, but more might put in multiport PCI-E cards. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Thu Feb 25 04:15:37 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5CF5106564A; Thu, 25 Feb 2010 04:15:37 +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 8C6578FC08; Thu, 25 Feb 2010 04:15:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o1P47x0k069720; Wed, 24 Feb 2010 21:07:59 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 24 Feb 2010 21:08:08 -0700 (MST) Message-Id: <20100224.210808.634347869559333650.imp@bsdimp.com> To: attilio@freebsd.org From: "M. Warner Losh" In-Reply-To: <3bbf2fe11002240718x5182aa93w5a00c657a0fba5f6@mail.gmail.com> References: <3bbf2fe11002151610l41526f55r5e60b5e46ce42b64@mail.gmail.com> <20100216195440.GF50403@deviant.kiev.zoral.com.ua> <3bbf2fe11002240718x5182aa93w5a00c657a0fba5f6@mail.gmail.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: kostikbel@gmail.com, arch@freebsd.org, emaste@sandvine.com Subject: Re: [PATCH] Adding shared code support for ia32 and amd64 -- x86 sub-branch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 04:15:37 -0000 In message: <3bbf2fe11002240718x5182aa93w5a00c657a0fba5f6@mail.gmail.com> Attilio Rao writes: : 2010/2/16 Kostik Belousov : : > On Tue, Feb 16, 2010 at 01:10:37AM +0100, Attilio Rao wrote: : >> The following patch: : >> http://www.freebsd.org/~attilio/x86.diff : >> : >> starts the effort for having a shared sub-tree between amd64 and ia32. : >> In this initial pass I putted the low-hanging fruits (bios/cpufreq) : >> and what my customer was more interested in (isa/*) in order to : >> kick-off the effort and, in the future, move gradually the code there. : >> With the machine/isa/* cleanup about 10 files are trimmed and I'm sure : >> more can be achieved easilly. : >> There are few things to discuss. One, that I had not necessity to dig : >> about still, is about how to organize headers (include/). Maybe some : >> replication ala pc98 may be good. : >> : >> The patch is big but it is mostly added and removed files (look at the : >> files.X in order to understand better how files movements happened). : >> : >> Hope to see comments and reviews. : > : > IMO the diff is unreadable. I suggest to do actual svn cp (not svn mv) : > operation now, without a review, and post a diff that should be applied : > to x86/ directory, as well as to build glue. : : I think that this patch juices out all the relevant part without noise: : http://www.freebsd.org/~attilio/x86-2.diff Looks like you didn't add the required "sys/x86" files to files.pc98. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Feb 25 13:33:56 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4F901065670 for ; Thu, 25 Feb 2010 13:33:56 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id 770BD8FC08 for ; Thu, 25 Feb 2010 13:33:56 +0000 (UTC) Received: by iwn36 with SMTP id 36so5110646iwn.28 for ; Thu, 25 Feb 2010 05:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=JKwmGkhZcByeJtlY+G68H92XgFsTiZt8FeA4jTii86g=; b=DeXHfMM00On/r9WaDchTfKaqwY31gX3bagJwCVNED6pyWJQuC7/YlHetfUPNZWGRRt FJvrA8kkbAX/4jXoShmsd0r7Sk+zdLLmDwTv2clVLHxaQLX1QoHrhBY6Xa5gW5uoXy7l Xr4IHKGASjKgucBBznXe7NbKMzmqNQjuI6ZXE= 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=aE90+noOEcw++TiacC5MBonXDkRV0/YC7nuwj2vkaeVnWk9VNTJ7FoZtvnpf/gXY2j EaZOUaYNETW+NfXHe3OBNlBYitWb8/BlBVcPvV2cmEr3pslNrlvHkuj+pZ3ymejE9P5X sMUSLwSX2Z//l9DmVoyDIhvKhoXo1LE09mTaI= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.146.134 with SMTP id h6mr610404ibv.16.1267104830304; Thu, 25 Feb 2010 05:33:50 -0800 (PST) In-Reply-To: <20100224.210808.634347869559333650.imp@bsdimp.com> References: <3bbf2fe11002151610l41526f55r5e60b5e46ce42b64@mail.gmail.com> <20100216195440.GF50403@deviant.kiev.zoral.com.ua> <3bbf2fe11002240718x5182aa93w5a00c657a0fba5f6@mail.gmail.com> <20100224.210808.634347869559333650.imp@bsdimp.com> Date: Thu, 25 Feb 2010 14:33:50 +0100 X-Google-Sender-Auth: 1cb4428e5cd25274 Message-ID: <3bbf2fe11002250533i2fe71007l9b003abb277aa22a@mail.gmail.com> From: Attilio Rao To: "M. Warner Losh" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kostikbel@gmail.com, arch@freebsd.org, emaste@sandvine.com Subject: Re: [PATCH] Adding shared code support for ia32 and amd64 -- x86 sub-branch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 13:33:56 -0000 2010/2/25 M. Warner Losh : > In message: <3bbf2fe11002240718x5182aa93w5a00c657a0fba5f6@mail.gmail.com> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Attilio Rao writes: > : 2010/2/16 Kostik Belousov : > : > On Tue, Feb 16, 2010 at 01:10:37AM +0100, Attilio Rao wrote: > : >> The following patch: > : >> http://www.freebsd.org/~attilio/x86.diff > : >> > : >> starts the effort for having a shared sub-tree between amd64 and ia3= 2. > : >> In this initial pass I putted the low-hanging fruits (bios/cpufreq) > : >> and what my customer was more interested in (isa/*) in order to > : >> kick-off the effort and, in the future, move gradually the code ther= e. > : >> With the machine/isa/* cleanup about 10 files are trimmed and I'm su= re > : >> more can be achieved easilly. > : >> There are few things to discuss. One, that I had not necessity to di= g > : >> about still, is about how to organize headers (include/). Maybe some > : >> replication ala pc98 may be good. > : >> > : >> The patch is big but it is mostly added and removed files (look at t= he > : >> files.X in order to understand better how files movements happened). > : >> > : >> Hope to see comments and reviews. > : > > : > IMO the diff is unreadable. I suggest to do actual svn cp (not svn mv= ) > : > operation now, without a review, and post a diff that should be appli= ed > : > to x86/ directory, as well as to build glue. > : > : I think that this patch juices out all the relevant part without noise: > : http://www.freebsd.org/~attilio/x86-2.diff > > Looks like you didn't add the required "sys/x86" files to files.pc98. There is still no-use for powerpc as it uses its own "isa" implementation it seems (it should be cbus). Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Thu Feb 25 15:09:18 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 628B6106566C for ; Thu, 25 Feb 2010 15:09:18 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f185.google.com (mail-iw0-f185.google.com [209.85.223.185]) by mx1.freebsd.org (Postfix) with ESMTP id 240178FC21 for ; Thu, 25 Feb 2010 15:09:17 +0000 (UTC) Received: by iwn15 with SMTP id 15so5166856iwn.7 for ; Thu, 25 Feb 2010 07:09:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=h8MDpA10idA5j3w8vNeOZKJy8nI2MPVpRf+juovL1lE=; b=X0iMly/VVn8S28Pw2MSqSSqLsTw/NUIz1fXknvGEiwDpgPXGI+r5LgCrNh6DTaYqOf VbrP0RDiQMtdBqU1w54eButToFoaP4DUQapKhrL1cLOy5Jv8AWNc/fbuuTgOxHSRwYOg dQVKY3YewG07ItPhAgO1mymMmjlhe1gvRW72k= 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=rKBicXzVRXfJpOP4uMCZV/ZzVKb2gJAGQfblMYpejnlqmlCizzYO/2h7Gyfo5jRuJN CBeFJOWAk7gy+x8rSkLeFAUOSic09DAoLzOpjQDqzthukSVw0bJx/8HW3jD2i+7DCKQ8 xrMq2fZCWGJXbwbF4nBlY/ctfiqr89oQEMdSY= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.190.137 with SMTP id di9mr113926ibb.76.1267110528887; Thu, 25 Feb 2010 07:08:48 -0800 (PST) In-Reply-To: <3bbf2fe11002250533i2fe71007l9b003abb277aa22a@mail.gmail.com> References: <3bbf2fe11002151610l41526f55r5e60b5e46ce42b64@mail.gmail.com> <20100216195440.GF50403@deviant.kiev.zoral.com.ua> <3bbf2fe11002240718x5182aa93w5a00c657a0fba5f6@mail.gmail.com> <20100224.210808.634347869559333650.imp@bsdimp.com> <3bbf2fe11002250533i2fe71007l9b003abb277aa22a@mail.gmail.com> Date: Thu, 25 Feb 2010 16:08:48 +0100 X-Google-Sender-Auth: 39e6a66214c6332d Message-ID: <3bbf2fe11002250708i1f36174am474e6f7ee4111e63@mail.gmail.com> From: Attilio Rao To: "M. Warner Losh" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kostikbel@gmail.com, arch@freebsd.org, emaste@sandvine.com Subject: Re: [PATCH] Adding shared code support for ia32 and amd64 -- x86 sub-branch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 15:09:18 -0000 2010/2/25 Attilio Rao : > 2010/2/25 M. Warner Losh : >> In message: <3bbf2fe11002240718x5182aa93w5a00c657a0fba5f6@mail.gmail.com= > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Attilio Rao writes: >> : 2010/2/16 Kostik Belousov : >> : > On Tue, Feb 16, 2010 at 01:10:37AM +0100, Attilio Rao wrote: >> : >> The following patch: >> : >> http://www.freebsd.org/~attilio/x86.diff >> : >> >> : >> starts the effort for having a shared sub-tree between amd64 and ia= 32. >> : >> In this initial pass I putted the low-hanging fruits (bios/cpufreq) >> : >> and what my customer was more interested in (isa/*) in order to >> : >> kick-off the effort and, in the future, move gradually the code the= re. >> : >> With the machine/isa/* cleanup about 10 files are trimmed and I'm s= ure >> : >> more can be achieved easilly. >> : >> There are few things to discuss. One, that I had not necessity to d= ig >> : >> about still, is about how to organize headers (include/). Maybe som= e >> : >> replication ala pc98 may be good. >> : >> >> : >> The patch is big but it is mostly added and removed files (look at = the >> : >> files.X in order to understand better how files movements happened)= . >> : >> >> : >> Hope to see comments and reviews. >> : > >> : > IMO the diff is unreadable. I suggest to do actual svn cp (not svn m= v) >> : > operation now, without a review, and post a diff that should be appl= ied >> : > to x86/ directory, as well as to build glue. >> : >> : I think that this patch juices out all the relevant part without noise= : >> : http://www.freebsd.org/~attilio/x86-2.diff >> >> Looks like you didn't add the required "sys/x86" files to files.pc98. > > There is still no-use for powerpc as it uses its own "isa" > implementation it seems (it should be cbus). s/powerpc/pc98, sorry. Attilio --=20 Peace can only be achieved by understanding - A. Einstein