From owner-freebsd-arch@FreeBSD.ORG Sun Nov 30 03:30:50 2008 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 16A631065672 for ; Sun, 30 Nov 2008 03:30:50 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout012.mac.com (asmtpout012.mac.com [17.148.16.87]) by mx1.freebsd.org (Postfix) with ESMTP id F1F998FC0A for ; Sun, 30 Nov 2008 03:30:49 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.96] (209-128-86-226.BAYAREA.NET [209.128.86.226]) by asmtp012.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KB400AJZN2UXB40@asmtp012.mac.com> for arch@freebsd.org; Sat, 29 Nov 2008 19:30:32 -0800 (PST) Message-id: <68B9D78C-C0CF-4D64-AF53-C3736EEC8D23@mac.com> From: Marcel Moolenaar To: Peter Wemm In-reply-to: Date: Sat, 29 Nov 2008 19:30:29 -0800 References: <57809A37-B81C-4F50-A418-CD9303F06B72@mac.com> <0F1745AA-611F-40B2-85F3-32FD78BC4B58@mac.com> X-Mailer: Apple Mail (2.929.2) Cc: FreeBSD Arch Subject: Re: RFC: making gpart default 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, 30 Nov 2008 03:30:50 -0000 On Nov 29, 2008, at 1:56 PM, Peter Wemm wrote: > On Sat, Nov 29, 2008 at 1:32 PM, Marcel Moolenaar > wrote: >> On Nov 28, 2008, at 8:07 PM, Peter Wemm wrote: >> >>> First, the 'gpart create' man page doesn't say what "scheme" is. >> >> Yes, the manpage needs some work. >> >>> After guessing, I tried: >>> >>> overcee# gpart create -s gpt /dev/twed1 >>> gpart: 22 scheme 'gpt' >>> >>> What does that mean? It turns out that I didn't have GEOM_PART_GPT >>> compiled in. >> >> Oops, forgot about parsing the error string... >> I just fixed it (rev 185454). >> >> The background: geom(8) simply prints the error that >> the kernel creates. This then requires that the kernel >> creates a user-friendly error message. This is not a >> good idea, because it side-steps things like i18n >> completely. >> >> So, for gpart I chose a different approach. The kernel >> uses a certain form for the error messages, which is: >> [ 'value'] >> The intend is to have user-space interpret what is >> meant and print something the user understands. This >> I forgot to do. >> >> For now, the translation is straight-forward, but it >> should not be too hard to improve upon it further. >> >> In general, geom(8) needs to do a bit more pre- and post- >> processing. It mostly just converts the command line into >> a gctl request and as such forces the user to do all the >> work. I'll work on that... > > For the record, I like the idea of having a consistent control > interface. I switched my machine to use GEOM_PART_MBR/BSD as well. > > A couple of thoughts.. > > * Can gpart enumerate the list of schemes that the kernel supports? > If so, it could avoid the problem of having to interpret the kernel's > reaction to avoidable errors. Not yet, but can be added fairly easily. The kernel has a list of supported schemes, which it just needs to export in the XML. In that case, and with each scheme a kernel module, gpart(8) can also try to load the kernel module on demand... > * The same goes for the list of 'geoms'. 'geom disk list' (among > other things) can find the providers list. gpart could avoid passing > bogus provider names into the kernel in the first place. True. The list of GEOMs is already in the XML, so it can be checked up-front by gpart(8). This also aligns well with stripping /dev/ from the provider and geom name. > * A couple of DWIM concessions would go along way. Humanized number > suffixes, the ability to search for start addresses automatically, > find next free partition index etc. Yup. I considered this already and just haven't gotten around to work on it. > * There should be some guidance or hints on laying out disks. For > example, a gpart create -s gpt on a raid volume ends up with a start > sector of 34 for the free space. There should be a documentation hint > to round up start sectors to a power of 2 and/or block size on a raid. > eg: if you have a raid with 64K stripes, then move the start sector > from 34 to 128. Otherwise we end up with file systems issuing > transactions that can split across multiple raid stripes. FWIW, I > conveniently filled this hole with boot code. Hmmm... gpart(8) typically can't store this kind of information on-disk, but other than that it supports alignment/padding already. We just need a way to tell gpart about it. Maybe this should come from the provider (i.e. underlying geom)... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Mon Dec 1 11:06:52 2008 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 879B4106567B for ; Mon, 1 Dec 2008 11:06:52 +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 5A2EB8FC0C for ; Mon, 1 Dec 2008 11:06:52 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB1B6qGB052483 for ; Mon, 1 Dec 2008 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB1B6pFH052479 for freebsd-arch@FreeBSD.org; Mon, 1 Dec 2008 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Dec 2008 11:06:51 GMT Message-Id: <200812011106.mB1B6pFH052479@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 Dec 2008 11:06:52 -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 Dec 1 11:59:52 2008 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 538EC1065670 for ; Mon, 1 Dec 2008 11:59:52 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 11A6F8FC16 for ; Mon, 1 Dec 2008 11:59:52 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 757656D449; Mon, 1 Dec 2008 11:40:17 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 54987844A0; Mon, 1 Dec 2008 12:40:17 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Peter Wemm" References: <57809A37-B81C-4F50-A418-CD9303F06B72@mac.com> Date: Mon, 01 Dec 2008 12:40:17 +0100 In-Reply-To: (Peter Wemm's message of "Fri, 28 Nov 2008 20:07:50 -0800") Message-ID: <86vdu4qg2m.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Arch , Marcel Moolenaar Subject: Re: RFC: making gpart default 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 Dec 2008 11:59:52 -0000 "Peter Wemm" writes: > After continuing the guessing game: > > overcee# gpart create -s gpt /dev/twed1 > gpart: 22 provider '/dev/twed1' > > That was useful. Out other tools generally allow /dev prefixes to be opt= ional. In this case, twed1 is the name of a GEOM provider, not a device. I'm not sure all GEOM providers necessarily have device nodes - at least, the GEOM framework doesn't enforce it - and for those that do, the device name might not match the GEOM name. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Dec 2 00:05:40 2008 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 A5D511065672 for ; Tue, 2 Dec 2008 00:05:40 +0000 (UTC) (envelope-from peter@wemm.org) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.freebsd.org (Postfix) with ESMTP id 8B6D38FC08 for ; Tue, 2 Dec 2008 00:05:40 +0000 (UTC) (envelope-from peter@wemm.org) Received: by wf-out-1314.google.com with SMTP id 24so2933802wfg.7 for ; Mon, 01 Dec 2008 16:05:39 -0800 (PST) Received: by 10.142.84.3 with SMTP id h3mr4695379wfb.149.1228176339603; Mon, 01 Dec 2008 16:05:39 -0800 (PST) Received: by 10.142.255.21 with HTTP; Mon, 1 Dec 2008 16:05:39 -0800 (PST) Message-ID: Date: Mon, 1 Dec 2008 16:05:39 -0800 From: "Peter Wemm" To: "Marcel Moolenaar" In-Reply-To: <68B9D78C-C0CF-4D64-AF53-C3736EEC8D23@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <57809A37-B81C-4F50-A418-CD9303F06B72@mac.com> <0F1745AA-611F-40B2-85F3-32FD78BC4B58@mac.com> <68B9D78C-C0CF-4D64-AF53-C3736EEC8D23@mac.com> Cc: FreeBSD Arch Subject: Re: RFC: making gpart default 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, 02 Dec 2008 00:05:40 -0000 On Sat, Nov 29, 2008 at 7:30 PM, Marcel Moolenaar wrote: > > On Nov 29, 2008, at 1:56 PM, Peter Wemm wrote: [..] >> * There should be some guidance or hints on laying out disks. For >> example, a gpart create -s gpt on a raid volume ends up with a start >> sector of 34 for the free space. There should be a documentation hint >> to round up start sectors to a power of 2 and/or block size on a raid. >> eg: if you have a raid with 64K stripes, then move the start sector >> from 34 to 128. Otherwise we end up with file systems issuing >> transactions that can split across multiple raid stripes. FWIW, I >> conveniently filled this hole with boot code. > > Hmmm... gpart(8) typically can't store this kind > of information on-disk, but other than that it > supports alignment/padding already. We just need > a way to tell gpart about it. Maybe this should > come from the provider (i.e. underlying geom)... I was more thinking of a man page note to warn of the issue. Also, in the gpt case, it might make sense in gpt partition table case to round up the initial size to a power of 2. Right now we lose 34 sectors from the beginning. Rounding it to 64 total at least gets us to an even power of 2. UFS's frequent block size of 16K shouldn't cross any underlying stripe boundaries in the usual case. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Tue Dec 2 22:32:57 2008 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 0AB70106564A; Tue, 2 Dec 2008 22:32:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8E5D78FC13; Tue, 2 Dec 2008 22:32:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mB2MWoEF011992; Tue, 2 Dec 2008 17:32:50 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Lawrence Stewart Date: Tue, 2 Dec 2008 17:07:41 -0500 User-Agent: KMail/1.9.7 References: <492412E8.3060700@freebsd.org> <200811211348.41536.jhb@freebsd.org> <4929F90B.1040502@freebsd.org> In-Reply-To: <4929F90B.1040502@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812021707.41545.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 02 Dec 2008 17:32:50 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8713/Tue Dec 2 14:59:31 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: kthread_exit(9) unexpectedness 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, 02 Dec 2008 22:32:57 -0000 On Sunday 23 November 2008 07:44:59 pm Lawrence Stewart wrote: > John Baldwin wrote: > > On Thursday 20 November 2008 05:22:03 pm Lawrence Stewart wrote: > >> John Baldwin wrote: > >>> On Wednesday 19 November 2008 08:21:44 am Lawrence Stewart wrote: > >>>> Hi all, > >>>> > >>>> I tracked down a deadlock in some of my code today to some weird > >>>> behaviour in the kthread(9) KPI. The executive summary is that > >>>> kthread_exit() thread termination notification using wakeup() behaves as > >>>> expected intuitively in 8.x, but not in 7.x. > >>> In 5.x/6.x/7.x kthreads are still processes and it has always been a > > wakeup on > >>> the proc pointer. kthread_create() in 7.x returns a proc pointer, not a > >>> thread pointer for example. In 8.x kthreads are actual threads and > >> Yep, but the processes have a *thread in them right? The API naming is > >> obviously slightly misleading, but it essentially creates a new single > >> threaded process prior to 8.x. > > > > Yes, but you have to go explicitly use FIRST_THREAD_IN_PROC(). Most of the > > kernel modules I've written that use kthread's in < 8 do this: > > > > static struct proc *foo_thread; > > > > /* Called for MOD_LOAD. */ > > static void > > load(...) > > { > > > > error = kthread_create(..., &foo_thread); > > } > > > > static void > > unload(...) > > { > > > > /* set flag */ > > msleep(foo_thread, ...); > > } > > > > And never actually use the thread at all. However, if you write the code for > > 8.x, now you _do_ get a kthread and sleep on the thread so it becomes: > > > > static struct thread *foo_thread; > > > > static void > > load(...) > > { > > > > error = kproc_kthread_add(..., proc0, &foo_thread); > > } > > > > static void > > unload(...) > > { > > > > /* set flag */ > > msleep(foo_thread, ...); > > } > > > > > Sure, but to write the code in this way means you are exercising > undocumented knowledge of the KPI. I suspect the average developer > completely unfamiliar with the KPI would (and should!) use the man page > to learn about the functionality it provides. > > With that basis in mind, it seems unreasonable to expect the developer > to come to the conclusion that "...will initiate a call to wakeup(9) on > the thread handle." refers to sleeping on the *proc passed in to > kthread_create. Perhaps I'm not as switched on as the average developer, > but when I read it I certainly did not understand that the KPI created > processes and that the man page used the term thread to really mean a > single threaded process. I also did no equate "thread handle" with the > *proc returned by kthread_create. This is why the API in 8 is better, it is far less confusing. > Apart from the discussion thus far, you haven't actually commented yet > on my proposed single line change to kthread_exit() in 7.x to call > wakeup on the *thread as well as the *proc. Do you have any specific > thoughts on or objection to that idea? I would rather fix the docs first and not encourage folks to use FIRST_THREAD_IN_PROC (a). My only worry about the additional wakeup is other places that may be sleeping on the thread pointer for another reason. It might even be better to add a dedicated condvar to 'struct thread' in 8.x that is used for the wakeup and do the wakeup on that rather than the thread pointer to be honest. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Dec 3 02:02:34 2008 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 24554106564A; Wed, 3 Dec 2008 02:02:34 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id BC8118FC08; Wed, 3 Dec 2008 02:02:33 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id mB31jk3U018359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Dec 2008 12:45:47 +1100 (EST) (envelope-from lstewart@freebsd.org) Message-ID: <4935E4B5.6090204@freebsd.org> Date: Wed, 03 Dec 2008 12:45:25 +1100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: John Baldwin References: <492412E8.3060700@freebsd.org> <200811211348.41536.jhb@freebsd.org> <4929F90B.1040502@freebsd.org> <200812021707.41545.jhb@freebsd.org> In-Reply-To: <200812021707.41545.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Cc: freebsd-arch@freebsd.org Subject: Re: kthread_exit(9) unexpectedness 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 Dec 2008 02:02:34 -0000 John Baldwin wrote: > On Sunday 23 November 2008 07:44:59 pm Lawrence Stewart wrote: >> John Baldwin wrote: >>> On Thursday 20 November 2008 05:22:03 pm Lawrence Stewart wrote: >>>> John Baldwin wrote: >>>>> On Wednesday 19 November 2008 08:21:44 am Lawrence Stewart wrote: >>>>>> Hi all, >>>>>> >>>>>> I tracked down a deadlock in some of my code today to some weird >>>>>> behaviour in the kthread(9) KPI. The executive summary is that >>>>>> kthread_exit() thread termination notification using wakeup() behaves > as >>>>>> expected intuitively in 8.x, but not in 7.x. >>>>> In 5.x/6.x/7.x kthreads are still processes and it has always been a >>> wakeup on >>>>> the proc pointer. kthread_create() in 7.x returns a proc pointer, not a >>>>> thread pointer for example. In 8.x kthreads are actual threads and >>>> Yep, but the processes have a *thread in them right? The API naming is >>>> obviously slightly misleading, but it essentially creates a new single >>>> threaded process prior to 8.x. >>> Yes, but you have to go explicitly use FIRST_THREAD_IN_PROC(). Most of > the >>> kernel modules I've written that use kthread's in < 8 do this: >>> >>> static struct proc *foo_thread; >>> >>> /* Called for MOD_LOAD. */ >>> static void >>> load(...) >>> { >>> >>> error = kthread_create(..., &foo_thread); >>> } >>> >>> static void >>> unload(...) >>> { >>> >>> /* set flag */ >>> msleep(foo_thread, ...); >>> } >>> >>> And never actually use the thread at all. However, if you write the code > for >>> 8.x, now you _do_ get a kthread and sleep on the thread so it becomes: >>> >>> static struct thread *foo_thread; >>> >>> static void >>> load(...) >>> { >>> >>> error = kproc_kthread_add(..., proc0, &foo_thread); >>> } >>> >>> static void >>> unload(...) >>> { >>> >>> /* set flag */ >>> msleep(foo_thread, ...); >>> } >>> >> >> Sure, but to write the code in this way means you are exercising >> undocumented knowledge of the KPI. I suspect the average developer >> completely unfamiliar with the KPI would (and should!) use the man page >> to learn about the functionality it provides. >> >> With that basis in mind, it seems unreasonable to expect the developer >> to come to the conclusion that "...will initiate a call to wakeup(9) on >> the thread handle." refers to sleeping on the *proc passed in to >> kthread_create. Perhaps I'm not as switched on as the average developer, >> but when I read it I certainly did not understand that the KPI created >> processes and that the man page used the term thread to really mean a >> single threaded process. I also did no equate "thread handle" with the >> *proc returned by kthread_create. > > This is why the API in 8 is better, it is far less confusing. > >> Apart from the discussion thus far, you haven't actually commented yet >> on my proposed single line change to kthread_exit() in 7.x to call >> wakeup on the *thread as well as the *proc. Do you have any specific >> thoughts on or objection to that idea? > > I would rather fix the docs first and not encourage folks to use > FIRST_THREAD_IN_PROC (a). My only worry about the additional wakeup is other > places that may be sleeping on the thread pointer for another reason. It Ok, I'll start by having a go at rejigging the 7.x and 8.x kthread(9) man pages to be more informational and draw out the subtle differences we've been discussing in this thread. I'll post man page patches for review when they're ready. > might even be better to add a dedicated condvar to 'struct thread' in 8.x > that is used for the wakeup and do the wakeup on that rather than the thread > pointer to be honest. > What are the pros/cons of using mtx_sleep/wakeup vs cv_wait/cv_broadcast? Cheers, Lawrence From owner-freebsd-arch@FreeBSD.ORG Wed Dec 3 22:52:33 2008 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 A4963106564A; Wed, 3 Dec 2008 22:52:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3AAEC8FC16; Wed, 3 Dec 2008 22:52:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mB3MqPKL023152; Wed, 3 Dec 2008 17:52:26 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Lawrence Stewart Date: Wed, 3 Dec 2008 15:02:41 -0500 User-Agent: KMail/1.9.7 References: <492412E8.3060700@freebsd.org> <200812021707.41545.jhb@freebsd.org> <4935E4B5.6090204@freebsd.org> In-Reply-To: <4935E4B5.6090204@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812031502.42218.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 03 Dec 2008 17:52:26 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8718/Wed Dec 3 08:29:03 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: kthread_exit(9) unexpectedness 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 Dec 2008 22:52:33 -0000 On Tuesday 02 December 2008 08:45:25 pm Lawrence Stewart wrote: > > might even be better to add a dedicated condvar to 'struct thread' in 8.x > > that is used for the wakeup and do the wakeup on that rather than the thread > > pointer to be honest. > > > > What are the pros/cons of using mtx_sleep/wakeup vs cv_wait/cv_broadcast? Forces you to use explicit wait channels as opposed to some of the problems we have now with 3-4 places sleeping on proc pointers for example. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Dec 4 02:39:07 2008 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 96B441065670 for ; Thu, 4 Dec 2008 02:39:07 +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 559988FC12 for ; Thu, 4 Dec 2008 02:39:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mB42b7Vs077892; Wed, 3 Dec 2008 19:37:07 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 03 Dec 2008 19:37:14 -0700 (MST) Message-Id: <20081203.193714.693830802.imp@bsdimp.com> To: peter@wemm.org From: "M. Warner Losh" In-Reply-To: References: <68B9D78C-C0CF-4D64-AF53-C3736EEC8D23@mac.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, xcllnt@mac.com Subject: Re: RFC: making gpart default 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, 04 Dec 2008 02:39:07 -0000 In message: "Peter Wemm" writes: : On Sat, Nov 29, 2008 at 7:30 PM, Marcel Moolenaar wrote: : > : > On Nov 29, 2008, at 1:56 PM, Peter Wemm wrote: : [..] : >> * There should be some guidance or hints on laying out disks. For : >> example, a gpart create -s gpt on a raid volume ends up with a start : >> sector of 34 for the free space. There should be a documentation hint : >> to round up start sectors to a power of 2 and/or block size on a raid. : >> eg: if you have a raid with 64K stripes, then move the start sector : >> from 34 to 128. Otherwise we end up with file systems issuing : >> transactions that can split across multiple raid stripes. FWIW, I : >> conveniently filled this hole with boot code. : > : > Hmmm... gpart(8) typically can't store this kind : > of information on-disk, but other than that it : > supports alignment/padding already. We just need : > a way to tell gpart about it. Maybe this should : > come from the provider (i.e. underlying geom)... : : I was more thinking of a man page note to warn of the issue. : : Also, in the gpt case, it might make sense in gpt partition table case : to round up the initial size to a power of 2. Right now we lose 34 : sectors from the beginning. Rounding it to 64 total at least gets us : to an even power of 2. UFS's frequent block size of 16K shouldn't : cross any underlying stripe boundaries in the usual case. This likely is a hang over from the MBR code that puts the first partition at one cylendar offset from the beginning to conform with the MBR conventions of (some?) Bioses that use that to get the parameters for the disk... Warner From owner-freebsd-arch@FreeBSD.ORG Thu Dec 4 18:24:10 2008 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 30FC71065672 for ; Thu, 4 Dec 2008 18:24:10 +0000 (UTC) (envelope-from flo@kasimir.com) Received: from mail.solomo.de (mail.solomo.de [85.214.49.72]) by mx1.freebsd.org (Postfix) with ESMTP id E38D68FC19 for ; Thu, 4 Dec 2008 18:24:09 +0000 (UTC) (envelope-from flo@kasimir.com) Received: from localhost (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id 6AB763F48C for ; Thu, 4 Dec 2008 19:13:43 +0100 (CET) X-Virus-Scanned: amavisd-new at vistream.de Received: from mail.solomo.de ([127.0.0.1]) by localhost (mail.solomo.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hWXFDHWVrZa8 for ; Thu, 4 Dec 2008 19:13:40 +0100 (CET) Received: from nibbler.lan (i53876182.versanet.de [83.135.97.130]) by mail.solomo.de (Postfix) with ESMTPA id A25613F40A for ; Thu, 4 Dec 2008 19:13:40 +0100 (CET) Message-ID: <49381DD4.2000506@kasimir.com> Date: Thu, 04 Dec 2008 19:13:40 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081204 Shredder/3.0b2pre MIME-Version: 1.0 To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Adding strndup(3) to libc viable/useful? 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, 04 Dec 2008 18:24:10 -0000 Hi, first of all i hope arch is the correct place to discuss this. While porting an application to FreeBSD i found that FreeBSDs libc does not have strndup. NetBSD added this about 2 years ago. A port of this to FreeBSD was very easy. There are 13 ports in the ports tree right now that patch in strndup via a patch in the files/ dir, well actually 12 bring there own version of strndup and one replaces it with a call to malloc/strncpy. Would it make sense to add this to our libc? A patch which does this is available here at http://webmail.solomo.de/~flo/strndup.patch I don't know if there is such a thing as minimum number of ports to require a function so that it can be added to the base system... Any feedback appreciated. Cheers, Florian From owner-freebsd-arch@FreeBSD.ORG Thu Dec 4 18:44:37 2008 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 0E7131065670 for ; Thu, 4 Dec 2008 18:44:37 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id AA8668FC1F for ; Thu, 4 Dec 2008 18:44:36 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id DF7E828448 for ; Fri, 5 Dec 2008 02:44:35 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 825C0EB9E54; Fri, 5 Dec 2008 02:44:35 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id 5WEjYgpDbbYh; Fri, 5 Dec 2008 02:44:30 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 8324BEB9E3C; Fri, 5 Dec 2008 02:44:29 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=epaD02h7TA+jrOiiGsIAGuWsF++RjqFusR/2nQR+LxzFGjNNtH9u6+pYqN/jw1t3k dvd8kXtSebiXkvUbXTqvg== Message-ID: <49382502.1040403@delphij.net> Date: Thu, 04 Dec 2008 10:44:18 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: Florian Smeets References: <49381DD4.2000506@kasimir.com> In-Reply-To: <49381DD4.2000506@kasimir.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Adding strndup(3) to libc viable/useful? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2008 18:44:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Florian, Florian Smeets wrote: > Hi, > > first of all i hope arch is the correct place to discuss this. > > While porting an application to FreeBSD i found that FreeBSDs libc does > not have strndup. NetBSD added this about 2 years ago. A port of this to > FreeBSD was very easy. > > There are 13 ports in the ports tree right now that patch in strndup via > a patch in the files/ dir, well actually 12 bring there own version of > strndup and one replaces it with a call to malloc/strncpy. > > Would it make sense to add this to our libc? A patch which does this is > available here at http://webmail.solomo.de/~flo/strndup.patch > > I don't know if there is such a thing as minimum number of ports to > require a function so that it can be added to the base system... > > Any feedback appreciated. I think whether or not to add it really depends on how popular it is :) We included strdup() because it is a very common extension. Your patch looks fine but perhaps it would be a good idea to explicitly mention that this is not a commonly implemented GNU extension (inheritedly, this could reduce portability). Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk4JQEACgkQi+vbBBjt66BNKwCgtLMQccFG6VvPv2xLjsmZr7I5 VuEAnjiCRzKtuhmMHHzuwrBibKGluidX =Y4XX -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Thu Dec 4 18:46:54 2008 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 215F01065672 for ; Thu, 4 Dec 2008 18:46:54 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id D915E8FC0C for ; Thu, 4 Dec 2008 18:46:53 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id B67636D43F; Thu, 4 Dec 2008 18:46:52 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 940C98448C; Thu, 4 Dec 2008 19:46:52 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Florian Smeets References: <49381DD4.2000506@kasimir.com> Date: Thu, 04 Dec 2008 19:46:52 +0100 In-Reply-To: <49381DD4.2000506@kasimir.com> (Florian Smeets's message of "Thu, 04 Dec 2008 19:13:40 +0100") Message-ID: <86r64nwzfn.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (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: Adding strndup(3) to libc viable/useful? 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, 04 Dec 2008 18:46:54 -0000 Florian Smeets writes: > There are 13 ports in the ports tree right now that patch in strndup > via a patch in the files/ dir, well actually 12 bring there own > version of strndup and one replaces it with a call to malloc/strncpy. > > Would it make sense to add this to our libc? A patch which does this > is available here at http://webmail.solomo.de/~flo/strndup.patch Not a bad idea, but those ports patches would still be required for compatibility with existing releases. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Dec 4 19:27:03 2008 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 C7AFB106564A for ; Thu, 4 Dec 2008 19:27:03 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-qy0-f18.google.com (mail-qy0-f18.google.com [209.85.221.18]) by mx1.freebsd.org (Postfix) with ESMTP id 77FEE8FC20 for ; Thu, 4 Dec 2008 19:27:03 +0000 (UTC) (envelope-from peter@wemm.org) Received: by qyk11 with SMTP id 11so5275982qyk.19 for ; Thu, 04 Dec 2008 11:27:02 -0800 (PST) Received: by 10.142.48.3 with SMTP id v3mr6049693wfv.0.1228418821714; Thu, 04 Dec 2008 11:27:01 -0800 (PST) Received: by 10.142.255.21 with HTTP; Thu, 4 Dec 2008 11:27:01 -0800 (PST) Message-ID: Date: Thu, 4 Dec 2008 11:27:01 -0800 From: "Peter Wemm" To: d@delphij.net In-Reply-To: <49382502.1040403@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49381DD4.2000506@kasimir.com> <49382502.1040403@delphij.net> Cc: Florian Smeets , freebsd-arch@freebsd.org Subject: Re: Adding strndup(3) to libc viable/useful? 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, 04 Dec 2008 19:27:03 -0000 On Thu, Dec 4, 2008 at 10:44 AM, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Florian, > > Florian Smeets wrote: >> Hi, >> >> first of all i hope arch is the correct place to discuss this. >> >> While porting an application to FreeBSD i found that FreeBSDs libc does >> not have strndup. NetBSD added this about 2 years ago. A port of this to >> FreeBSD was very easy. >> >> There are 13 ports in the ports tree right now that patch in strndup via >> a patch in the files/ dir, well actually 12 bring there own version of >> strndup and one replaces it with a call to malloc/strncpy. >> >> Would it make sense to add this to our libc? A patch which does this is >> available here at http://webmail.solomo.de/~flo/strndup.patch >> >> I don't know if there is such a thing as minimum number of ports to >> require a function so that it can be added to the base system... >> >> Any feedback appreciated. > > I think whether or not to add it really depends on how popular it is :) > We included strdup() because it is a very common extension. > > Your patch looks fine but perhaps it would be a good idea to explicitly > mention that this is not a commonly implemented GNU extension > (inheritedly, this could reduce portability). glibc has had this for a long time and the trend for this function seems to be gaining ground. I think solaris is the last remaining major holdout. str*() namespace belongs to the implementation (us). There are lots of places where I've seen strndup() implemented as compatability shims. Everything from Asterisk to Varnish. I wouldn't be suprised if there were ports that had this knowledge hard coded. FWIW, there are a bunch of other useful utility str*() and mem*() functions that glibc has that we do not. I've run into the lack of fmemopen() in the past. I found an implementation from rwatson. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Thu Dec 4 19:54:43 2008 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 31B891065676 for ; Thu, 4 Dec 2008 19:54:43 +0000 (UTC) (envelope-from max@love2party.net) Received: from mout-bounce.kundenserver.de (mout-bounce.kundenserver.de [212.227.17.2]) by mx1.freebsd.org (Postfix) with ESMTP id B6FCB8FC0C for ; Thu, 4 Dec 2008 19:54:42 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-028-001.pools.arcor-ip.net [88.66.28.1]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1L8K5P0IfO-0007WA; Thu, 04 Dec 2008 20:42:07 +0100 Received: (qmail 86542 invoked from network); 4 Dec 2008 19:42:06 -0000 Received: from unknown (HELO fbsd8.laiers.local) (192.168.4.151) by router.laiers.local with SMTP; 4 Dec 2008 19:42:06 -0000 From: Max Laier Organization: FreeBSD To: freebsd-arch@freebsd.org Date: Thu, 4 Dec 2008 20:42:05 +0100 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: <49381DD4.2000506@kasimir.com> <49382502.1040403@delphij.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812042042.06181.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18GI/MQvPvYjdmfbXaSBrkGz3WJnQe3riJRLTl hYq9SzBgyhG3NMRtLyuQc39+ftnkwnInSm+WXFJqfdH1KOMiKm Gc7WFc4R+8OoddD/xSBXQ== Cc: Florian Smeets , d@delphij.net Subject: Re: Adding strndup(3) to libc viable/useful? 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, 04 Dec 2008 19:54:43 -0000 On Thursday 04 December 2008 20:27:01 Peter Wemm wrote: > On Thu, Dec 4, 2008 at 10:44 AM, Xin LI wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi, Florian, > > > > Florian Smeets wrote: > >> Hi, > >> > >> first of all i hope arch is the correct place to discuss this. > >> > >> While porting an application to FreeBSD i found that FreeBSDs libc does > >> not have strndup. NetBSD added this about 2 years ago. A port of this to > >> FreeBSD was very easy. > >> > >> There are 13 ports in the ports tree right now that patch in strndup via > >> a patch in the files/ dir, well actually 12 bring there own version of > >> strndup and one replaces it with a call to malloc/strncpy. > >> > >> Would it make sense to add this to our libc? A patch which does this is > >> available here at http://webmail.solomo.de/~flo/strndup.patch > >> > >> I don't know if there is such a thing as minimum number of ports to > >> require a function so that it can be added to the base system... > >> > >> Any feedback appreciated. > > > > I think whether or not to add it really depends on how popular it is :) > > We included strdup() because it is a very common extension. > > > > Your patch looks fine but perhaps it would be a good idea to explicitly > > mention that this is not a commonly implemented GNU extension > > (inheritedly, this could reduce portability). > > glibc has had this for a long time and the trend for this function > seems to be gaining ground. I think solaris is the last remaining > major holdout. > > str*() namespace belongs to the implementation (us). > > There are lots of places where I've seen strndup() implemented as > compatability shims. Everything from Asterisk to Varnish. I wouldn't > be suprised if there were ports that had this knowledge hard coded. > > FWIW, there are a bunch of other useful utility str*() and mem*() > functions that glibc has that we do not. strnvis! (from OpenBSD) > I've run into the lack of fmemopen() in the past. I found an > implementation from rwatson. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-arch@FreeBSD.ORG Thu Dec 4 21:24:38 2008 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 14D121065673; Thu, 4 Dec 2008 21:24:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 848328FC17; Thu, 4 Dec 2008 21:24:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mB4LOIOh033364; Thu, 4 Dec 2008 16:24:24 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 4 Dec 2008 13:13:34 -0500 User-Agent: KMail/1.9.7 References: <20081203.193714.693830802.imp@bsdimp.com> In-Reply-To: <20081203.193714.693830802.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812041313.34565.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Thu, 04 Dec 2008 16:24:29 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8721/Thu Dec 4 08:26:10 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arch@freebsd.org, xcllnt@mac.com Subject: Re: RFC: making gpart default 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, 04 Dec 2008 21:24:38 -0000 On Wednesday 03 December 2008 09:37:14 pm M. Warner Losh wrote: > In message: > "Peter Wemm" writes: > : On Sat, Nov 29, 2008 at 7:30 PM, Marcel Moolenaar wrote: > : > > : > On Nov 29, 2008, at 1:56 PM, Peter Wemm wrote: > : [..] > : >> * There should be some guidance or hints on laying out disks. For > : >> example, a gpart create -s gpt on a raid volume ends up with a start > : >> sector of 34 for the free space. There should be a documentation hint > : >> to round up start sectors to a power of 2 and/or block size on a raid. > : >> eg: if you have a raid with 64K stripes, then move the start sector > : >> from 34 to 128. Otherwise we end up with file systems issuing > : >> transactions that can split across multiple raid stripes. FWIW, I > : >> conveniently filled this hole with boot code. > : > > : > Hmmm... gpart(8) typically can't store this kind > : > of information on-disk, but other than that it > : > supports alignment/padding already. We just need > : > a way to tell gpart about it. Maybe this should > : > come from the provider (i.e. underlying geom)... > : > : I was more thinking of a man page note to warn of the issue. > : > : Also, in the gpt case, it might make sense in gpt partition table case > : to round up the initial size to a power of 2. Right now we lose 34 > : sectors from the beginning. Rounding it to 64 total at least gets us > : to an even power of 2. UFS's frequent block size of 16K shouldn't > : cross any underlying stripe boundaries in the usual case. > > This likely is a hang over from the MBR code that puts the first > partition at one cylendar offset from the beginning to conform with > the MBR conventions of (some?) Bioses that use that to get the > parameters for the disk... No, the way GPT works, you have a PMBR at sector 0, then immediately following that you have the Primary partition table in the next N sectors (the first sector in the table has a header that contains the size of the table). Then you have a backup Secondary partition table in the last N sectors of the disk as well. At least with the old gpt(8) tool you could actually tell it how big of a table to make when you created a GPT, and I imagine gpart probably can do the same. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Dec 4 21:24:38 2008 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 14D121065673; Thu, 4 Dec 2008 21:24:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 848328FC17; Thu, 4 Dec 2008 21:24:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mB4LOIOh033364; Thu, 4 Dec 2008 16:24:24 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 4 Dec 2008 13:13:34 -0500 User-Agent: KMail/1.9.7 References: <20081203.193714.693830802.imp@bsdimp.com> In-Reply-To: <20081203.193714.693830802.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812041313.34565.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Thu, 04 Dec 2008 16:24:29 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8721/Thu Dec 4 08:26:10 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arch@freebsd.org, xcllnt@mac.com Subject: Re: RFC: making gpart default 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, 04 Dec 2008 21:24:38 -0000 On Wednesday 03 December 2008 09:37:14 pm M. Warner Losh wrote: > In message: > "Peter Wemm" writes: > : On Sat, Nov 29, 2008 at 7:30 PM, Marcel Moolenaar wrote: > : > > : > On Nov 29, 2008, at 1:56 PM, Peter Wemm wrote: > : [..] > : >> * There should be some guidance or hints on laying out disks. For > : >> example, a gpart create -s gpt on a raid volume ends up with a start > : >> sector of 34 for the free space. There should be a documentation hint > : >> to round up start sectors to a power of 2 and/or block size on a raid. > : >> eg: if you have a raid with 64K stripes, then move the start sector > : >> from 34 to 128. Otherwise we end up with file systems issuing > : >> transactions that can split across multiple raid stripes. FWIW, I > : >> conveniently filled this hole with boot code. > : > > : > Hmmm... gpart(8) typically can't store this kind > : > of information on-disk, but other than that it > : > supports alignment/padding already. We just need > : > a way to tell gpart about it. Maybe this should > : > come from the provider (i.e. underlying geom)... > : > : I was more thinking of a man page note to warn of the issue. > : > : Also, in the gpt case, it might make sense in gpt partition table case > : to round up the initial size to a power of 2. Right now we lose 34 > : sectors from the beginning. Rounding it to 64 total at least gets us > : to an even power of 2. UFS's frequent block size of 16K shouldn't > : cross any underlying stripe boundaries in the usual case. > > This likely is a hang over from the MBR code that puts the first > partition at one cylendar offset from the beginning to conform with > the MBR conventions of (some?) Bioses that use that to get the > parameters for the disk... No, the way GPT works, you have a PMBR at sector 0, then immediately following that you have the Primary partition table in the next N sectors (the first sector in the table has a header that contains the size of the table). Then you have a backup Secondary partition table in the last N sectors of the disk as well. At least with the old gpt(8) tool you could actually tell it how big of a table to make when you created a GPT, and I imagine gpart probably can do the same. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Dec 4 23:08:21 2008 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 770301065673; Thu, 4 Dec 2008 23:08:21 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout016.mac.com (asmtpout016.mac.com [17.148.16.91]) by mx1.freebsd.org (Postfix) with ESMTP id 628D18FC0C; Thu, 4 Dec 2008 23:08:21 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from mdenny-t60.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KBD000ZSK9QUS30@asmtp016.mac.com>; Thu, 04 Dec 2008 15:08:15 -0800 (PST) Message-id: <5783CEB0-6163-429E-8B28-2F9D6FBCF4A8@mac.com> From: Marcel Moolenaar To: John Baldwin In-reply-to: <200812041313.34565.jhb@freebsd.org> Date: Thu, 04 Dec 2008 15:08:14 -0800 References: <20081203.193714.693830802.imp@bsdimp.com> <200812041313.34565.jhb@freebsd.org> X-Mailer: Apple Mail (2.929.2) Cc: FreeBSD Arch Subject: Re: RFC: making gpart default 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, 04 Dec 2008 23:08:21 -0000 On Dec 4, 2008, at 10:13 AM, John Baldwin wrote: > No, the way GPT works, you have a PMBR at sector 0, then immediately > following > that you have the Primary partition table in the next N sectors (the > first > sector in the table has a header that contains the size of the > table). Then > you have a backup Secondary partition table in the last N sectors of > the disk > as well. At least with the old gpt(8) tool you could actually tell > it how > big of a table to make when you created a GPT, and I imagine gpart > probably > can do the same. Yes. For schemes that support it, you can specify how many entries to allocate. The 34 corresponds to 128 entries for GPT (4 entries per sector)... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Thu Dec 4 23:51:59 2008 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 BDA7D106564A for ; Thu, 4 Dec 2008 23:51:59 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (hergotha.csail.mit.edu [66.92.79.170]) by mx1.freebsd.org (Postfix) with ESMTP id 5C3888FC12 for ; Thu, 4 Dec 2008 23:51:59 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.2/8.14.2) with ESMTP id mB4NDAdT045335; Thu, 4 Dec 2008 18:13:10 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.2/8.13.8/Submit) id mB4NDA6j045334; Thu, 4 Dec 2008 18:13:10 -0500 (EST) (envelope-from wollman) Date: Thu, 4 Dec 2008 18:13:10 -0500 (EST) From: Garrett Wollman Message-Id: <200812042313.mB4NDA6j045334@hergotha.csail.mit.edu> To: peter@wemm.org In-Reply-To: References: <49381DD4.2000506@kasimir.com> <49382502.1040403@delphij.net> Organization: None X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (hergotha.csail.mit.edu [127.0.0.1]); Thu, 04 Dec 2008 18:13:10 -0500 (EST) X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hergotha.csail.mit.edu Cc: arch@freebsd.org Subject: Re: Adding strndup(3) to libc viable/useful? 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, 04 Dec 2008 23:51:59 -0000 In article , Peter Wemm writes: >glibc has had this for a long time and the trend for this function >seems to be gaining ground. I think solaris is the last remaining >major holdout. Many formerly glibc-only functions have been adopted in the current (IEEE Std.1003.1-2008, ISO/IEC 9945:2009) POSIX revision. >FWIW, there are a bunch of other useful utility str*() and mem*() >functions that glibc has that we do not. Any of the functions that POSIX has adopted should definitely be added. >I've run into the lack of fmemopen() in the past. I found an >implementation from rwatson. fmemopen() is one of them. -GAWollman From owner-freebsd-arch@FreeBSD.ORG Sat Dec 6 21:29:45 2008 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 9057F1065672 for ; Sat, 6 Dec 2008 21:29:45 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 33F3A8FC1A for ; Sat, 6 Dec 2008 21:29:45 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 6E1D128448 for ; Sun, 7 Dec 2008 05:29:44 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 1AD46EBB0D2; Sun, 7 Dec 2008 05:29:44 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id mnUysHWq7lDR; Sun, 7 Dec 2008 05:29:39 +0800 (CST) Received: from charlie.delphij.net (c-67-180-38-12.hsd1.ca.comcast.net [67.180.38.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id EFAC1EBA837; Sun, 7 Dec 2008 05:29:37 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=O6EQBUygy5zmwfub1G7MI7hZ2T6sWPH03bujFqeqjto5XCKptfydjR+9ihpAvHFca 23vSb3i7IUsZf3d5RZ4uQ== Message-ID: <493AEEBD.9050101@delphij.net> Date: Sat, 06 Dec 2008 13:29:33 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: Garrett Wollman References: <49381DD4.2000506@kasimir.com> <49382502.1040403@delphij.net> <200812042313.mB4NDA6j045334@hergotha.csail.mit.edu> In-Reply-To: <200812042313.mB4NDA6j045334@hergotha.csail.mit.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: Adding strndup(3) to libc viable/useful? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2008 21:29:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Garrett Wollman wrote: > In article , > Peter Wemm writes: > >> glibc has had this for a long time and the trend for this function >> seems to be gaining ground. I think solaris is the last remaining >> major holdout. > > Many formerly glibc-only functions have been adopted in the current > (IEEE Std.1003.1-2008, ISO/IEC 9945:2009) POSIX revision. Is there a public available version on the Internet? Google turns out only an approval notice on Austin group... >> FWIW, there are a bunch of other useful utility str*() and mem*() >> functions that glibc has that we do not. > > Any of the functions that POSIX has adopted should definitely be > added. > >> I've run into the lack of fmemopen() in the past. I found an >> implementation from rwatson. > > fmemopen() is one of them. > > -GAWollman > > _______________________________________________ > 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" - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk67r0ACgkQi+vbBBjt66CNxQCfVT7AqvP5wzYcZ11HS1icuDno XBYAnj4l/AGiuxUf+PhzRaH3Skt9XEzc =n9ZK -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Sat Dec 6 22:10:40 2008 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 8214B106564A for ; Sat, 6 Dec 2008 22:10:40 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (hergotha.csail.mit.edu [66.92.79.170]) by mx1.freebsd.org (Postfix) with ESMTP id 2FF848FC14 for ; Sat, 6 Dec 2008 22:10:39 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.2/8.14.2) with ESMTP id mB6M8XXX095739; Sat, 6 Dec 2008 17:08:33 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.2/8.13.8/Submit) id mB6M8WHn095736; Sat, 6 Dec 2008 17:08:32 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18746.63456.941134.552539@hergotha.csail.mit.edu> Date: Sat, 6 Dec 2008 17:08:32 -0500 From: Garrett Wollman To: d@delphij.net In-Reply-To: <493AEEBD.9050101@delphij.net> References: <49381DD4.2000506@kasimir.com> <49382502.1040403@delphij.net> <200812042313.mB4NDA6j045334@hergotha.csail.mit.edu> <493AEEBD.9050101@delphij.net> X-Mailer: VM 7.17 under 21.4 (patch 21) "Educational Television" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (hergotha.csail.mit.edu [127.0.0.1]); Sat, 06 Dec 2008 17:08:33 -0500 (EST) X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hergotha.csail.mit.edu Cc: arch@freebsd.org Subject: Re: Adding strndup(3) to libc viable/useful? 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: Sat, 06 Dec 2008 22:10:40 -0000 < said: > Is there a public available version on the Internet? Google turns out > only an approval notice on Austin group... The public HTML version is being worked on right now and should be avilable soon. The official PDF is available to Austin Group members and I think for sale from the Open Group catalogue. (Note that the ISO/IEC version of the standard has not yet been approved; I believe it's still being balloted. When it is approved, the PDF with updated front matter will be available from the ISO bookstore.) -GAWollman From owner-freebsd-arch@FreeBSD.ORG Sat Dec 6 23:27:23 2008 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 582EE1065672 for ; Sat, 6 Dec 2008 23:27:23 +0000 (UTC) (envelope-from peter@wemm.org) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by mx1.freebsd.org (Postfix) with ESMTP id 35D868FC1C for ; Sat, 6 Dec 2008 23:27:23 +0000 (UTC) (envelope-from peter@wemm.org) Received: by wf-out-1314.google.com with SMTP id 24so620944wfg.7 for ; Sat, 06 Dec 2008 15:27:22 -0800 (PST) Received: by 10.142.245.6 with SMTP id s6mr710110wfh.302.1228606042703; Sat, 06 Dec 2008 15:27:22 -0800 (PST) Received: by 10.142.255.21 with HTTP; Sat, 6 Dec 2008 15:27:22 -0800 (PST) Message-ID: Date: Sat, 6 Dec 2008 15:27:22 -0800 From: "Peter Wemm" To: "M. Warner Losh" In-Reply-To: <20081203.193714.693830802.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <68B9D78C-C0CF-4D64-AF53-C3736EEC8D23@mac.com> <20081203.193714.693830802.imp@bsdimp.com> Cc: arch@freebsd.org, xcllnt@mac.com Subject: Re: RFC: making gpart default 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: Sat, 06 Dec 2008 23:27:23 -0000 On Wed, Dec 3, 2008 at 6:37 PM, M. Warner Losh wrote: > In message: > "Peter Wemm" writes: > : On Sat, Nov 29, 2008 at 7:30 PM, Marcel Moolenaar wrote: > : > > : > On Nov 29, 2008, at 1:56 PM, Peter Wemm wrote: > : [..] > : >> * There should be some guidance or hints on laying out disks. For > : >> example, a gpart create -s gpt on a raid volume ends up with a start > : >> sector of 34 for the free space. There should be a documentation hint > : >> to round up start sectors to a power of 2 and/or block size on a raid. > : >> eg: if you have a raid with 64K stripes, then move the start sector > : >> from 34 to 128. Otherwise we end up with file systems issuing > : >> transactions that can split across multiple raid stripes. FWIW, I > : >> conveniently filled this hole with boot code. > : > > : > Hmmm... gpart(8) typically can't store this kind > : > of information on-disk, but other than that it > : > supports alignment/padding already. We just need > : > a way to tell gpart about it. Maybe this should > : > come from the provider (i.e. underlying geom)... > : > : I was more thinking of a man page note to warn of the issue. > : > : Also, in the gpt case, it might make sense in gpt partition table case > : to round up the initial size to a power of 2. Right now we lose 34 > : sectors from the beginning. Rounding it to 64 total at least gets us > : to an even power of 2. UFS's frequent block size of 16K shouldn't > : cross any underlying stripe boundaries in the usual case. > > This likely is a hang over from the MBR code that puts the first > partition at one cylendar offset from the beginning to conform with > the MBR conventions of (some?) Bioses that use that to get the > parameters for the disk... I don't recall what happens for "small" partitions, but I know from experience that bioses care far more about the end sector geometry than the start. eg: typically we used to set start: lba = 63, cyl 0, head 1, sector 1. All that implies is that there are 63 sectors per track. It gives no hints to the bios about number of heads. When we set end: lba = 1234567, cyl 1023, head 254, sector 63 then that implies number of heads and number of sectors. Cyl = 1023 means "rest of disk". No bioses that I've come across in the last 8 years gave a damn about the start info, just the end info. It was effectively required that you "end" on a cylinder boundary. We have not been "start"ing on a cylinder boundary - just a track/head boundary. Linux (and windows, I think) do start on full cylinder boundaries for partitions >= 8GB. head boundary start: cyl 0, head 1, sec 1 cylinder boundary start: cyl 1, head 0, sec 1. Anyway.. the important thing is that we do actually have a choice. Typically we'd have: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 160086465 (78167 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 But this is faster: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 512, size 285458473 (139384 Meg), flag 80 (active) beg: cyl 0/ head 8/ sector 9; end: cyl 1023/ head 254/ sector 63 -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Sat Dec 6 23:31:50 2008 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 29BC5106564A for ; Sat, 6 Dec 2008 23:31:50 +0000 (UTC) (envelope-from peter@wemm.org) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by mx1.freebsd.org (Postfix) with ESMTP id 067BF8FC13 for ; Sat, 6 Dec 2008 23:31:49 +0000 (UTC) (envelope-from peter@wemm.org) Received: by wf-out-1314.google.com with SMTP id 24so622168wfg.7 for ; Sat, 06 Dec 2008 15:31:49 -0800 (PST) Received: by 10.142.246.19 with SMTP id t19mr708601wfh.332.1228606309515; Sat, 06 Dec 2008 15:31:49 -0800 (PST) Received: by 10.142.255.21 with HTTP; Sat, 6 Dec 2008 15:31:49 -0800 (PST) Message-ID: Date: Sat, 6 Dec 2008 15:31:49 -0800 From: "Peter Wemm" To: "Marcel Moolenaar" In-Reply-To: <5783CEB0-6163-429E-8B28-2F9D6FBCF4A8@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081203.193714.693830802.imp@bsdimp.com> <200812041313.34565.jhb@freebsd.org> <5783CEB0-6163-429E-8B28-2F9D6FBCF4A8@mac.com> Cc: FreeBSD Arch Subject: Re: RFC: making gpart default 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: Sat, 06 Dec 2008 23:31:50 -0000 On Thu, Dec 4, 2008 at 3:08 PM, Marcel Moolenaar wrote: > > On Dec 4, 2008, at 10:13 AM, John Baldwin wrote: > >> No, the way GPT works, you have a PMBR at sector 0, then immediately >> following >> that you have the Primary partition table in the next N sectors (the first >> sector in the table has a header that contains the size of the table). >> Then >> you have a backup Secondary partition table in the last N sectors of the >> disk >> as well. At least with the old gpt(8) tool you could actually tell it how >> big of a table to make when you created a GPT, and I imagine gpart >> probably >> can do the same. > > Yes. For schemes that support it, you can specify how many entries > to allocate. The 34 corresponds to 128 entries for GPT (4 entries > per sector)... Yes. 1 sector (pmbr) 1 sector (header) 32 sectors (128 partitions) = 34 sectors. Or we could have 1 sector (pmbr) 1 sector (header) 62 sectors (248 partitions) = 64 sectors. At least it is a power of two, even if only 32K. I'd love it if the man page told users to reserve another 32K for "boot code", so that the start address becomes sector 128, or 64K. This is a commonly used stripe size. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell