From owner-freebsd-arch Mon Oct 16 18:22:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with SMTP id E55F037B484 for ; Mon, 16 Oct 2000 18:22:12 -0700 (PDT) Received: by border.alcanet.com.au id <115206>; Tue, 17 Oct 2000 12:21:51 +1000 Content-return: prohibited Date: Tue, 17 Oct 2000 12:21:50 +1100 From: Peter Jeremy Subject: Re: we need atomic_t To: Terry Lambert Cc: freebsd-arch@freebsd.org Mail-followup-to: Terry Lambert , freebsd-arch@freebsd.org Message-Id: <00Oct17.122151est.115206@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Apologies if this is a duplicate, I haven't seen the first copy come back via the mailing list] On Fri, Oct 13, 2000 at 02:19:20AM +0000, Terry Lambert wrote: >[ ... atomic_t ... ] > >> My unspoken minimum precision was going to be 24 bits, for situations >> where that wasn't enough the idea was to provide a atomic64_t, but >> only if the demand was reasonable. > >How would you handle this type on 386, 486, and Pentium machines, >if somone used it in code? The Pentium and later CPUs have a compare-double-and-swap. This could be used inside a loop to produce atomic operations on 64-bit objects (much the same as the Alpha atomic routines). The basic code sequence is: atomic_op64: movl mem,%eax movl mem+4,%edx loop: op_q {%ecx:%ebx} = {%edx:%eax} op {operand} lock cmpxchg8b mem jne loop Sticking the whole thing inside di/ei reduces the load/store window, but may or may not be necessary. Adding a spin count might also be worthwhile. It isn't possible to have atomic 64-bit operations on 386 or 486, but there was a previous agreement that FreeBSD wouldn't support SMP on either of these CPU's either. Since (AFAIK) no bus-master peripherals would need atomic 64-bit operations, protecting it with a disable/enable interrupts block should be adequate. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 17 16:22:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id E30BF37B4FE; Tue, 17 Oct 2000 16:22:52 -0700 (PDT) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 13kTL2-0005wE-00; Sat, 14 Oct 2000 15:35:08 +0000 Date: Sat, 14 Oct 2000 15:35:08 +0000 From: Tony Finch To: Terry Lambert Cc: Jason Evans , Alfred Perlstein , Chuck Paterson , Mike Smith , arch@FreeBSD.ORG Subject: Re: we need atomic_t Message-ID: <20001014153508.C22336@hand.dotat.at> References: <20001012214446.H11949@canonware.com> <200010130916.CAA22883@usr09.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200010130916.CAA22883@usr09.primenet.com> Organization: Covalent Technologies, Inc Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: >> Here's one of Butenhof's example programs, which uses POSIX threads: > >[ ... technically illegal program that uses structure assignment ... ] It's structure initialization, not assignment, but your main point is right. >That's still technically illegal, since it assumes that a mutex >is merely a value in implementation, instead of potentially >something that lives on a linked list which is tracked to ensure >against deadlocks (for instance). Tony. -- en oeccget g mtcaa f.a.n.finch v spdlkishrhtewe y dot@dotat.at eatp o v eiti i d. fanf@covalent.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 18 5:44:55 2000 Delivered-To: freebsd-arch@freebsd.org Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by hub.freebsd.org (Postfix) with ESMTP id EDCC837B4CF for ; Wed, 18 Oct 2000 05:44:52 -0700 (PDT) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9ICipZ05111 for ; Wed, 18 Oct 2000 14:44:51 +0200 (MEST) Received: from uab.ericsson.se (ulinpc62 [134.138.94.22]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e9ICion06030 for ; Wed, 18 Oct 2000 14:44:51 +0200 (MET DST) Message-ID: <39ED9B42.417E88FD@uab.ericsson.se> Date: Wed, 18 Oct 2000 14:44:50 +0200 From: Anders Franzen X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@FreeBSD.ORG Subject: loadable drivers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I'm playing around with the linux pcmcia/cardbus drivers. Since I crash quite often I would like to do it with modules. The problem is that if I don't put any driver for the pcicl chip the PCI bus driver hands it over to the chip 'device/bus' and I wont see it when I attach the module to the PCI bus. Is there anyway of doing this or must certain drivers (bridges) be linked in the kernel? /Anders To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 18 22:45: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 442E337B4E5 for ; Wed, 18 Oct 2000 22:45:03 -0700 (PDT) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id OAA36513 for ; Sun, 15 Oct 2000 14:32:32 -0700 (PDT) Received: (from archie@localhost) by curve.dellroad.org (8.11.0/8.11.0) id e9FLWW109840 for freebsd-arch@freebsd.org; Sun, 15 Oct 2000 14:32:32 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200010152132.e9FLWW109840@curve.dellroad.org> Subject: Kernel, modules To: freebsd-arch@freebsd.org Date: Sun, 15 Oct 2000 14:32:31 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It's great now that we build all the KLD's at the same time that we build the kernel. The proliferation of KLD's is also good news. But essentially now we're building everything twice.. which brings up a couple of questions.. 1. Should we be only building everything once, and then construct "kernel" by linking together what are essentially "pre-loaded" KLD's? 2. What is the status of the concept of a single "kernel" that demand-loads KLD's during device probe, etc.? How far is it between here and there? Nothing new here, just curious what other people's current thoughts and/or expectations are. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 19 10: 7:25 2000 Delivered-To: freebsd-arch@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by hub.freebsd.org (Postfix) with ESMTP id B236337B4E5 for ; Thu, 19 Oct 2000 10:07:23 -0700 (PDT) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.10.1/8.10.1) with ESMTP id e9JH6rB24035; Thu, 19 Oct 2000 10:07:12 -0700 (PDT) Date: Thu, 19 Oct 2000 10:06:53 -0700 (PDT) From: Doug White To: Archie Cobbs Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Kernel, modules In-Reply-To: <200010152132.e9FLWW109840@curve.dellroad.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 15 Oct 2000, Archie Cobbs wrote: > It's great now that we build all the KLD's at the same time > that we build the kernel. The proliferation of KLD's is also > good news. > > But essentially now we're building everything twice.. which > brings up a couple of questions.. > > 1. Should we be only building everything once, and then > construct "kernel" by linking together what are essentially > "pre-loaded" KLD's? I believe this is the ultimate goal -- building a basic "kernel" module and loading the driver KLDs as defined by the hints or bus probes. Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 21 16:43: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from des.thinksec.com (isdn-25.follo.net [195.204.140.114]) by hub.freebsd.org (Postfix) with ESMTP id CF32437B4C5 for ; Sat, 21 Oct 2000 16:42:58 -0700 (PDT) Received: (from des@localhost) by des.thinksec.com (8.11.1/8.11.1) id e9LNgpX51590; Sun, 22 Oct 2000 01:42:51 +0200 (CEST) (envelope-from des@thinksec.com) X-URL: http://www.ofug.org/~des/ To: arch@freebsd.org Subject: Ideas concerning fsck From: Dag-Erling Smorgrav Date: 22 Oct 2000 01:42:50 +0200 Message-ID: Lines: 27 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What do people think about dispensing with the Pass# argument in fstab and instead using the following algorithm for 'fsck -p': 1) if the device does not begin with a slash, assume this is a pseudo-filesystem, and skip this entry. 2) if the mountpoint is "none", skip this entry. 3) if the fs type is known, run the appropriate command (which can be null, e.g. for cd9660), and skip to the next entry. 4) if the fs type is unknown, but fsck_${fstype} exists, run it and skip to the next entry. 5) print a big fat "Unknown file system type" warning and skip to the next entry. As for which order to fsck file systems in, do / first, and everything else in parallell afterwards (possibly with additional logic to try to identify file systems that are on the same device and fsck them sequentially to avoid thrashing) I'm willing to write the code if people think it's a good idea. DES --=20 Dag-Erling Sm=F8rgrav - des@thinksec.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message