From owner-freebsd-arch@FreeBSD.ORG Tue Aug 17 12:32:33 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 A059C10656A4; Tue, 17 Aug 2010 12:32:33 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1D58D8FC16; Tue, 17 Aug 2010 12:32:32 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o7HCWFPs069170; Tue, 17 Aug 2010 14:32:31 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o7HCWF7p069169; Tue, 17 Aug 2010 14:32:15 +0200 (CEST) (envelope-from olli) Date: Tue, 17 Aug 2010 14:32:15 +0200 (CEST) Message-Id: <201008171232.o7HCWF7p069169@lurza.secnetix.de> From: Oliver Fromme To: freebsd-arch@FreeBSD.ORG, jhb@FreeBSD.ORG, mdf@FreeBSD.ORG In-Reply-To: <201008161601.04203.jhb@freebsd.org> X-Newsgroups: list.freebsd-arch User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.4 (lurza.secnetix.de [127.0.0.1]); Tue, 17 Aug 2010 14:32:31 +0200 (CEST) Cc: Subject: Re: RFC: replace vm_offset_t with uintptr_t and vm_size_t with ?size_t X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-arch@FreeBSD.ORG, jhb@FreeBSD.ORG, mdf@FreeBSD.ORG List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 12:32:33 -0000 John Baldwin wrote: > The cpuid type thing is quite a sordid affair at the moment. The canonical > type for CPU IDs is actually a u_char (see td_oncpu) with a NOCPU constant > (0xff) used to denote an out-of-band value. Some newer APIs use 'int' > instead I think due to making room for larger CPU ID values than fit in a > u_char. I would probably settle on 'int' myself and not bother with a > 'short'. Just an observation: Machines that could -- in theory -- run FreeBSD are already quickly approaching that u_char limit for the CPU ID. For example, the Sun Fire X4800 (quite common in larger data centers) supports eight Xeon 7500 packages which have eight cores plus hyperthreading, which gives a 128-way SMP system. Solaris, Linux and Windows support them, FreeBSD doesn't. (This is not related to u_char CPU ID, though, but rather to cpumask_t.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered." -- Guido van Rossum