From owner-freebsd-arch@FreeBSD.ORG Mon Feb 1 06:38: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 61215106566C; Mon, 1 Feb 2010 06:38:19 +0000 (UTC) (envelope-from rajatjain@juniper.net) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by mx1.freebsd.org (Postfix) with ESMTP id C05238FC13; Mon, 1 Feb 2010 06:38:18 +0000 (UTC) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKS2Z22lu7BcDKgCNj5sQohlOJ57a+0J/F@postini.com; Sun, 31 Jan 2010 22:38:18 PST Received: from gaugeboson.jnpr.net (10.209.194.17) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Sun, 31 Jan 2010 22:26:04 -0800 Received: from emailbng3.jnpr.net ([10.209.194.27]) by gaugeboson.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 11:56:01 +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: Mon, 1 Feb 2010 11:56:00 +0530 Message-ID: <8506939B503B404A84BBB12293FC45F60681AA1B@emailbng3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: About hot-plugging support in FreeBSD Thread-Index: AcqjB2wYr4V2eolETBattuBEzcaY7Q== From: Rajat Jain To: X-OriginalArrivalTime: 01 Feb 2010 06:26:01.0658 (UTC) FILETIME=[6CA8C9A0:01CAA307] Cc: freebsd-ia32@freebsd.org, freebsd-ppc@freebsd.org Subject: About hot-plugging support in FreeBSD 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, 01 Feb 2010 06:38:19 -0000 Hi, I'm a newbie to the FreeBSD and have come from Linux background, hence please pardon me if this is not the right list for my questions, and please point me to the correct list:=20 1) Does FreeBSD support PCI-Express hot-plugging? I could not even find any instances in the source code that suggest that even PCI hot-plugging is supported. Is it supported? Can you please point me to appropriate references in the code? >From the links below it seems, that the PCI hot-plug is definitely in the roadmap, but it seems that it is a distant target? http://wiki.freebsd.org/PCIHotplug http://www.freebsd.org/projects/ideas/ideas.html#p-pcihotplug Is work already being done on this? Is some limited support available? 2) How and WHERE in the code is the "PCI Enumeration" and the "PCI resource allocation" done?: 2a) Does FreeBSD does its own PCI resource allocation / PCI bus numbering, or does it simply use the one already done by the BIOS / bootloader? 2b) In case it does its own PCI resource management, is the PCI Enumeration done only at the boot time, or devices can be detected and added later at run-time as well? [Please note that for adding at run time, we'll need certain PCI resource pre-reserved in anticipation of any new devices] I'd appreciate if you could provide me any pointers... Thanks, Rajat From owner-freebsd-arch@FreeBSD.ORG Mon Feb 1 11:06: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 CE7381065670 for ; Mon, 1 Feb 2010 11:06:50 +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 A30578FC21 for ; Mon, 1 Feb 2010 11:06:50 +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 o11B6oFl062723 for ; Mon, 1 Feb 2010 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o11B6oCq062721 for freebsd-arch@FreeBSD.org; Mon, 1 Feb 2010 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Feb 2010 11:06:50 GMT Message-Id: <201002011106.o11B6oCq062721@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, 01 Feb 2010 11:06:50 -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 Mon Feb 1 14:49: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 376271065697; Mon, 1 Feb 2010 14:49:53 +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 0929E8FC14; Mon, 1 Feb 2010 14:49:53 +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 B812F46B2C; Mon, 1 Feb 2010 09:49:52 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id E643A8A021; Mon, 1 Feb 2010 09:49:51 -0500 (EST) From: John Baldwin To: freebsd-ia32@freebsd.org Date: Mon, 1 Feb 2010 09:35:38 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <8506939B503B404A84BBB12293FC45F60681AA1B@emailbng3.jnpr.net> In-Reply-To: <8506939B503B404A84BBB12293FC45F60681AA1B@emailbng3.jnpr.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002010935.38861.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 01 Feb 2010 09:49:51 -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-ppc@freebsd.org, freebsd-arch@freebsd.org Subject: Re: About hot-plugging support in FreeBSD 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, 01 Feb 2010 14:49:53 -0000 On Monday 01 February 2010 1:26:00 am Rajat Jain wrote: > Hi, > > I'm a newbie to the FreeBSD and have come from Linux background, hence > please pardon me if this is not the right list for my questions, and > please point me to the correct list: > > 1) Does FreeBSD support PCI-Express hot-plugging? I could not even find > any instances in the source code that suggest that even PCI hot-plugging > is supported. Is it supported? Can you please point me to appropriate > references in the code? No, not currently. > 2) How and WHERE in the code is the "PCI Enumeration" and the "PCI > resource allocation" done?: Enumeration is done in 'pci_add_children()' in sys/dev/pci/pci.c. Resource allocation is done in the same file in a few different places. > 2a) Does FreeBSD does its own PCI resource allocation / PCI bus > numbering, or does it simply use the one already done by the BIOS / > bootloader? It reuses the firmware allocations and can only handle simple cases to allocate resources for a BAR that the firmware did not initialize. > 2b) In case it does its own PCI resource management, is the PCI > Enumeration done only at the boot time, or devices can be detected and > added later at run-time as well? [Please note that for adding at run > time, we'll need certain PCI resource pre-reserved in anticipation of > any new devices] It shouldn't be too hard to support hot-plug. Note that the cardbus(4) code already does a form of PCI hot-plug, so some of the infrastructure for PCI hot-plug is already in place. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Feb 3 23:08:14 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 8C206106566B; Wed, 3 Feb 2010 23:08: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 50E2E8FC15; Wed, 3 Feb 2010 23:08:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o13N6JmQ078222; Wed, 3 Feb 2010 16:06:19 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 03 Feb 2010 16:07:15 -0700 (MST) Message-Id: <20100203.160715.750582998416482087.imp@bsdimp.com> To: nwhitehorn@freebsd.org, arch@freebsd.org From: "M. Warner Losh" In-Reply-To: <4B69FA08.2070308@freebsd.org> References: <201002032129.o13LT7kZ013039@svn.freebsd.org> <4B69FA08.2070308@freebsd.org> 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: Subject: Re: svn commit: r203446 - in user/imp/tbemd: . bin/pax cddl/lib/libdtrace cddl/lib/libzpool contrib/smbfs etc games/morse gnu/lib/csu gnu/lib/libgcc gnu/lib/libgomp gnu/lib/libstdc++ gnu/usr.bin gnu/us... 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, 03 Feb 2010 23:08:14 -0000 [[ Moved to arch@ ]] In message: <4B69FA08.2070308@freebsd.org> Nathan Whitehorn writes: : Warner Losh wrote: : > Author: imp : > Date: Wed Feb 3 21:29:06 2010 : > New Revision: 203446 : > URL: http://svn.freebsd.org/changeset/base/203446 : > : > Log: : > Introduce MACHINE_CPUARCH. : > MACHINE is the specific kernel architecture for this machine. : > MACHINE_ARCH is the specific CPU type (abi, word size, etc). : > MACHINE_CPUARCH is the family of CPUs that's supported. : > Most of the tree conflates MACHINE_ARCH and MACHINE_CPUARCH since : > historically they have been identical. However, there's now a reason : > to to split the two concepts. NetBSD calls this MACHINE_CPU, but : > that's already used for something else in FreeBSD, so MACHINE_CPUARCH : > was selected instead. : > However, the sources in the tree have had a KLUDGE in the tree called : > TARGET_BIG_ENDIAN to select which endian to compile the code for. : > However, this is a cumbersome and awkward solution. MACHINE_ARCH : > really does need to be different for different endian because users : > use it for things like their path. Yet, the source tree also used : > MACHINE_ARCH to figure out the MD code to use. This source often : > supports multiple MACHINE_ARCHs. 'mips' supports 32 (and soon 64) bit : > word sizes as well as big and little endian. 'arm' support both : > endians. powerpc will soon support both 32-bit and 64-bit. : > These patches start to unwind this confusion. It implements : > MACHINE_ARCH of mipsel, mipseb for the two endians of MIPS, as well as : > arm and armeb for ARM. The names for ARM are historical accidents : > (ARM was primarily little endian until relatively recently). These : > names follow the NetBSD convetions. : > With these changes, "make buildworld TARGET=mips TARGET_ARCH=mipsel" : > finishes. armeb and mipseb should work, but haven't been tested yet. : > Committed as one big chunk so that people can comment on the patches : > as a whole and suggest improvements. : > : > : Thanks for this! : : How does this work for ABIs? For big vs. little endian, most if not : all of the userland support code is invariant. But in the 64/32 bit : case, 32 and 64-bit PowerPC have wildly differing ABIs, to the point : that there is extremely little overlap in the support code for things : like libc and RTLD, and it doesn't make much sense to point them at : the same directories. Should MACHINE_CPUARCH be different here, or is : it worth introducing something like MACHINE_ABI as well? I suppose : there are also individual hacks in Makefiles... First let me address the powerpc 32-bit vs 64-bit issue. If the support files really are radically different, then it makes sense in this case to treat them as two separate MACHINE_CPUARCH instances. We do this today with x86 and x86_64 (only we call them i386 and amd64). I anticipate that MIPS will be able to have the same files because mips64 and mips32 are very similar. The binaries will necessarily be different, but the sources will be the same with just a few conditionals and/or clever macros sprinkled through. This leads us to the orthogonal question of ABI. I like the idea of a MACHINE_ABI that is the default ABI to compile to. The default ABI is the one that the programs in the base are built against and that you get without special magic from the tools. Many ABIs can, on some systems, live together in peace and harmony. The multilib functionality allows for the development side of things to flourish, and there are conventions on where to put o32 vs n32 vs n64 shared libraries so the system can execute them at any time. I think multilib could even support multiple endian/word sizes as well, but to be honest, I've only just skimmed the surface of it. MACHINE_ABI will be used either to select different directories; used to instruction the compilers what code to generate (and what defines to use; etc. In the MIPS case, different ABI support is trivial in 'C' and doable in assembler (we need more pieces of the puzzle than we have in place for MIPS, but work is progressing there). It would also mean that for the looming ARM problem we have a solution. The looming ARM problem is that newer versions of the ARM ISA are more efficient with newer ABIs than the one we currently use. In an ideal world, we'd be able to build the tree for either (or both) and deploy whichever one makes sense for the underlying ARM hardware. The big trick here is to do this without exploding the testing matrix that committers will need to run through for their commits. Does this make sense? Warner P.S. This discussion started based on the svn tree I created to eliminate TARGET_BIG_ENDIAN from the tree, since the limitations of that were long known, and recently as the number of users has ballooned, has become painfully obvious... svn://svn.freebsd.org/base/user/imp/tbemd (tbemd - TARGET_BIG_ENDIAN Must Die)