From owner-freebsd-arch@FreeBSD.ORG Sun Jun 29 09:57:38 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1104337B401; Sun, 29 Jun 2003 09:57:38 -0700 (PDT) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21B0F44003; Sun, 29 Jun 2003 09:57:37 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by aslan.scsiguy.com (8.12.9/8.12.8) with ESMTP id h5TGvaEU049215; Sun, 29 Jun 2003 10:57:36 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Date: Sun, 29 Jun 2003 10:57:36 -0600 From: "Justin T. Gibbs" To: Scott Long Message-ID: <2947280000.1056905856@aslan.scsiguy.com> In-Reply-To: <3EFE48E8.1040700@freebsd.org> References: <3EFDC2EF.1060807@freebsd.org> <2768600000.1056836005@aslan.scsiguy.com> <3EFE48E8.1040700@freebsd.org> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: freebsd-arch@freebsd.org Subject: Re: API change for bus_dma X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2003 16:57:38 -0000 >> Again, what we want to achieve is as few lock acquires and releases >> in the common case as possible. For architectures like x86, the only >> data structure that needs to be locked for the common case of no deferral >> and no bounce page allocations is the tag (it will soon hold the S/G list >> passed to the callback). Other implementations may need to acquire other >> locks, but using the client's lock still removes one lock acquire and >> release in each invocation that is not deferred. >> >> -- >> Justin > > This is becoming wonderfully complex. What is the purpose of storing > the S/G list in the tag? Are we going to enforce a 1:1 relationship > between tags and maps? That would really suck for the aac(4) driver. No. We are going to enforce only one callback invocation at a time per tag. The S/G list is only persistent for the lifetime of the callback. The reason for the change is to avoid using the stack for large S/G lists. -- Justin From owner-freebsd-arch@FreeBSD.ORG Sun Jun 29 22:01:30 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB66537B404 for ; Sun, 29 Jun 2003 22:01:29 -0700 (PDT) Received: from HAL9000.homeunix.com (ip114.bella-vista.sfo.interquest.net [66.199.86.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E55F4400B for ; Sun, 29 Jun 2003 22:01:28 -0700 (PDT) (envelope-from dschultz@OCF.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.9) with ESMTP id h5U51OiP076690; Sun, 29 Jun 2003 22:01:24 -0700 (PDT) (envelope-from dschultz@OCF.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.9/Submit) id h5U51IbC076689; Sun, 29 Jun 2003 22:01:18 -0700 (PDT) (envelope-from dschultz@OCF.Berkeley.EDU) Date: Sun, 29 Jun 2003 22:01:18 -0700 From: David Schultz To: Bruce Evans Message-ID: <20030630050118.GA75674@HAL9000.homeunix.com> Mail-Followup-To: Bruce Evans , arch@freebsd.org References: <20030622005124.GA59673@HAL9000.homeunix.com> <20030622114150.L54976@gamplex.bde.org> <20030622035258.GB60460@HAL9000.homeunix.com> <20030622180851.K55800@gamplex.bde.org> <20030622085020.GA61926@HAL9000.homeunix.com> <20030622200641.D56263@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030622200641.D56263@gamplex.bde.org> cc: arch@freebsd.org Subject: Per-source CFLAGS revisited (was: Re: Per-source CFLAGS) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2003 05:01:30 -0000 Okay, here's another shot at it. In this version, sys.mk is untouched; I have only changed bsd.lib.mk and bsd.prog.mk. In addition, I have made the following changes over the last version: - Instead of CFLAGS_foo, I have used FILEFLAGS_foo. This is more generic and allows for better greppability. (Credit for this idea goes to Paul Richards, who suggested CFLAGSOVERRIDE.) - The name of the variable is now based on ${.TARGET} instead of ${.IMPSRC}. This makes more sense for ld, where there are multiple sources. - In addition to object files compiled from C sources, you can add flags to C++, Objective C, and even FORTRAN sources. You can pass flags to the linker on a per-target basis as well, although I expect this feature to be rarely useful. Comments? Index: share/mk/bsd.lib.mk =================================================================== RCS file: /cvs/src/share/mk/bsd.lib.mk,v retrieving revision 1.140 diff -u -u -r1.140 bsd.lib.mk --- share/mk/bsd.lib.mk 10 Jun 2003 04:47:49 -0000 1.140 +++ share/mk/bsd.lib.mk 29 Jun 2003 05:03:24 -0000 @@ -53,96 +53,117 @@ touch ${.TARGET} .c.o: - ${CC} ${CFLAGS} -c ${.IMPSRC} -o ${.TARGET} + ${CC} ${CFLAGS} ${FILEFLAGS_${.TARGET}} -c ${.IMPSRC} -o ${.TARGET} @${LD} -o ${.TARGET}.tmp -x -r ${.TARGET} @mv ${.TARGET}.tmp ${.TARGET} .c.po: - ${CC} -pg ${CFLAGS} -c ${.IMPSRC} -o ${.TARGET} + ${CC} -pg ${CFLAGS} ${FILEFLAGS_${.TARGET}} -c ${.IMPSRC} \ + -o ${.TARGET} @${LD} -o ${.TARGET}.tmp -X -r ${.TARGET} @mv ${.TARGET}.tmp ${.TARGET} .c.So: - ${CC} ${PICFLAG} -DPIC ${CFLAGS} -c ${.IMPSRC} -o ${.TARGET} - @${LD} ${LDFLAGS} -o ${.TARGET}.tmp -x -r ${.TARGET} + ${CC} ${PICFLAG} -DPIC ${CFLAGS} ${FILEFLAGS_${.TARGET}} \ + -c ${.IMPSRC} -o ${.TARGET} + @${LD} ${LDFLAGS} ${FILEFLAGS_${.TARGET}} -o ${.TARGET}.tmp \ + -x -r ${.TARGET} @mv ${.TARGET}.tmp ${.TARGET} .cc.o .C.o .cpp.o .cxx.o: - ${CXX} ${CXXFLAGS} -c ${.IMPSRC} -o ${.TARGET} + ${CXX} ${CXXFLAGS} ${FILEFLAGS_${.TARGET}} -c ${.IMPSRC} \ + -o ${.TARGET} @${LD} -o ${.TARGET}.tmp -x -r ${.TARGET} @mv ${.TARGET}.tmp ${.TARGET} .cc.po .C.po .cpp.po .cxx.po: - ${CXX} -pg ${CXXFLAGS} -c ${.IMPSRC} -o ${.TARGET} + ${CXX} -pg ${CXXFLAGS} ${FILEFLAGS_${.TARGET}} -c ${.IMPSRC} \ + -o ${.TARGET} @${LD} -o ${.TARGET}.tmp -X -r ${.TARGET} @mv ${.TARGET}.tmp ${.TARGET} .cc.So .C.So .cpp.So .cxx.So: - ${CXX} ${PICFLAG} -DPIC ${CXXFLAGS} -c ${.IMPSRC} -o ${.TARGET} - @${LD} ${LDFLAGS} -o ${.TARGET}.tmp -x -r ${.TARGET} + ${CXX} ${PICFLAG} -DPIC ${CXXFLAGS} ${FILEFLAGS_${.TARGET}} \ + -c ${.IMPSRC} -o ${.TARGET} + @${LD} ${LDFLAGS} ${FILEFLAGS_${.TARGET}} -o ${.TARGET}.tmp \ + -x -r ${.TARGET} @mv ${.TARGET}.tmp ${.TARGET} .f.o: - ${FC} ${FFLAGS} -o ${.TARGET} -c ${.IMPSRC} + ${FC} ${FFLAGS} ${FILEFLAGS_${.TARGET}} -o ${.TARGET} \ + -c ${.IMPSRC} @${LD} -o ${.TARGET}.tmp -x -r ${.TARGET} @mv ${.TARGET}.tmp ${.TARGET} .f.po: - ${FC} -pg ${FFLAGS} -o ${.TARGET} -c ${.IMPSRC} + ${FC} -pg ${FFLAGS} ${FILEFLAGS_${.TARGET}} -o ${.TARGET} \ + -c ${.IMPSRC} @${LD} -o ${.TARGET}.tmp -X -r ${.TARGET} @mv ${.TARGET}.tmp ${.TARGET} .f.So: - ${FC} ${PICFLAG} -DPIC ${FFLAGS} -o ${.TARGET} -c ${.IMPSRC} - @${LD} ${LDFLAGS} -o ${.TARGET}.tmp -x -r ${.TARGET} + ${FC} ${PICFLAG} -DPIC ${FFLAGS} ${FILEFLAGS_${.TARGET}} \ + -o ${.TARGET} -c ${.IMPSRC} + @${LD} ${LDFLAGS} ${FILEFLAGS_${.TARGET}} -o ${.TARGET}.tmp \ + -x -r ${.TARGET} @mv ${.TARGET}.tmp ${.TARGET} .m.o: - ${OBJC} ${OBJCFLAGS} -c ${.IMPSRC} -o ${.TARGET} + ${OBJC} ${OBJCFLAGS} ${FILEFLAGS_${.TARGET}} -c ${.IMPSRC} \ + -o ${.TARGET} @${LD} -o ${.TARGET}.tmp -x -r ${.TARGET} @mv ${.TARGET}.tmp ${.TARGET} .m.po: - ${OBJC} ${OBJCFLAGS} -pg -c ${.IMPSRC} -o ${.TARGET} + ${OBJC} ${OBJCFLAGS} -pg ${FILEFLAGS_${.TARGET}} -c ${.IMPSRC} \ + -o ${.TARGET} @${LD} -o ${.TARGET}.tmp -X -r ${.TARGET} @mv ${.TARGET}.tmp ${.TARGET} .m.So: - ${OBJC} ${PICFLAG} -DPIC ${OBJCFLAGS} -c ${.IMPSRC} -o ${.TARGET} - @${LD} ${LDFLAGS} -o ${.TARGET}.tmp -x -r ${.TARGET} + ${OBJC} ${PICFLAG} -DPIC ${OBJCFLAGS} ${FILEFLAGS_${.TARGET}} \ + -c ${.IMPSRC} -o ${.TARGET} + @${LD} ${LDFLAGS} ${FILEFLAGS_${.TARGET}} -o ${.TARGET}.tmp \ + -x -r ${.TARGET} @mv ${.TARGET}.tmp ${.TARGET} .s.o .asm.o: - ${CC} -x assembler-with-cpp ${CFLAGS} ${AINC} -c \ - ${.IMPSRC} -o ${.TARGET} - @${LD} ${LDFLAGS} -o ${.TARGET}.tmp -x -r ${.TARGET} + ${CC} -x assembler-with-cpp ${CFLAGS} ${FILEFLAGS_${.TARGET}} \ + ${AINC} -c ${.IMPSRC} -o ${.TARGET} + @${LD} ${LDFLAGS} ${FILEFLAGS_${.TARGET}} -o ${.TARGET}.tmp \ + -x -r ${.TARGET} @mv ${.TARGET}.tmp ${.TARGET} .s.po .asm.po: - ${CC} -x assembler-with-cpp -DPROF ${CFLAGS} ${AINC} -c \ - ${.IMPSRC} -o ${.TARGET} - @${LD} ${LDFLAGS} -o ${.TARGET}.tmp -X -r ${.TARGET} + ${CC} -x assembler-with-cpp -DPROF ${CFLAGS} \ + ${FILEFLAGS_${.TARGET}} ${AINC} -c ${.IMPSRC} -o ${.TARGET} + @${LD} ${LDFLAGS} ${FILEFLAGS_${.TARGET}} -o ${.TARGET}.tmp \ + -X -r ${.TARGET} @mv ${.TARGET}.tmp ${.TARGET} .s.So .asm.So: ${CC} -x assembler-with-cpp ${PICFLAG} -DPIC ${CFLAGS} \ - ${AINC} -c ${.IMPSRC} -o ${.TARGET} + ${FILEFLAGS_${.TARGET}} ${AINC} -c ${.IMPSRC} -o ${.TARGET} @${LD} -o ${.TARGET}.tmp -x -r ${.TARGET} @mv ${.TARGET}.tmp ${.TARGET} .S.o: - ${CC} ${CFLAGS} ${AINC} -c ${.IMPSRC} -o ${.TARGET} - @${LD} ${LDFLAGS} -o ${.TARGET}.tmp -x -r ${.TARGET} + ${CC} ${CFLAGS} ${FILEFLAGS_${.TARGET}} ${AINC} \ + -c ${.IMPSRC} -o ${.TARGET} + @${LD} ${LDFLAGS} ${FILEFLAGS_${.TARGET}} -o ${.TARGET}.tmp \ + -x -r ${.TARGET} @mv ${.TARGET}.tmp ${.TARGET} .S.po: - ${CC} -DPROF ${CFLAGS} ${AINC} -c ${.IMPSRC} -o ${.TARGET} - @${LD} ${LDFLAGS} -o ${.TARGET}.tmp -X -r ${.TARGET} + ${CC} -DPROF ${CFLAGS} ${FILEFLAGS_${.TARGET}} ${AINC} \ + -c ${.IMPSRC} -o ${.TARGET} + @${LD} ${LDFLAGS} ${FILEFLAGS_${.TARGET}} -o ${.TARGET}.tmp \ + -X -r ${.TARGET} @mv ${.TARGET}.tmp ${.TARGET} .S.So: - ${CC} ${PICFLAG} -DPIC ${CFLAGS} ${AINC} -c ${.IMPSRC} \ - -o ${.TARGET} + ${CC} ${PICFLAG} -DPIC ${CFLAGS} ${FILEFLAGS_${.TARGET}} ${AINC} \ + -c ${.IMPSRC} -o ${.TARGET} @${LD} -o ${.TARGET}.tmp -x -r ${.TARGET} @mv ${.TARGET}.tmp ${.TARGET} Index: share/mk/bsd.prog.mk =================================================================== RCS file: /cvs/src/share/mk/bsd.prog.mk,v retrieving revision 1.130 diff -u -u -r1.130 bsd.prog.mk --- share/mk/bsd.prog.mk 3 May 2003 15:48:12 -0000 1.130 +++ share/mk/bsd.prog.mk 28 Jun 2003 20:41:59 -0000 @@ -32,9 +32,11 @@ ${PROG}: ${OBJS} .if defined(PROG_CXX) - ${CXX} ${CXXFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDADD} + ${CXX} ${CXXFLAGS} ${LDFLAGS} ${FILEFLAGS_${.TARGET}} -o ${.TARGET} \ + ${OBJS} ${LDADD} .else - ${CC} ${CFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDADD} + ${CC} ${CFLAGS} ${LDFLAGS} ${FILEFLAGS_${.TARGET}} -o ${.TARGET} \ + ${OBJS} ${LDADD} .endif .else !defined(SRCS) @@ -55,9 +57,11 @@ ${PROG}: ${OBJS} .if defined(PROG_CXX) - ${CXX} ${CXXFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDADD} + ${CXX} ${CXXFLAGS} ${LDFLAGS} ${FILEFLAGS_${.TARGET}} -o ${.TARGET} \ + ${OBJS} ${LDADD} .else - ${CC} ${CFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDADD} + ${CC} ${CFLAGS} ${LDFLAGS} ${FILEFLAGS_${.TARGET}} -o ${.TARGET} \ + ${OBJS} ${LDADD} .endif .endif From owner-freebsd-arch@FreeBSD.ORG Mon Jun 30 06:51:30 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54E7837B404 for ; Mon, 30 Jun 2003 06:51:30 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id F281843FEC for ; Mon, 30 Jun 2003 06:51:28 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h5UDpSwV001596 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 30 Jun 2003 09:51:28 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h5UDpMn08416; Mon, 30 Jun 2003 09:51:22 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16128.16474.899328.333628@grasshopper.cs.duke.edu> Date: Mon, 30 Jun 2003 09:51:22 -0400 (EDT) To: Terry Lambert In-Reply-To: <3EFD574B.9419EE71@mindspring.com> References: <3EF3C12F.9060303@btc.adaptec.com> <16124.39930.142492.356163@grasshopper.cs.duke.edu> <3EFC9F2D.6020908@btc.adaptec.com> <16124.43999.333761.397624@grasshopper.cs.duke.edu> <3EFCAC7A.6060305@btc.adaptec.com> <16124.45051.919899.414795@grasshopper.cs.duke.edu> <16124.46454.595892.860118@grasshopper.cs.duke.edu> <3EFD492A.60C18556@mindspring.com> <20030628080448.GI55920@funkthat.com> <3EFD574B.9419EE71@mindspring.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-arch@freebsd.org Subject: Re: API change for bus_dma X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2003 13:51:30 -0000 Terry Lambert writes: > was attempting to address was related to whether or not the memory > in question was physically vs. logically contiguous: > No, its whether or not its cache-coherent. We do everything at a page granularity, and could care less about whether or not the memory is contiguous. Drew From owner-freebsd-arch@FreeBSD.ORG Mon Jun 30 06:59:42 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA2D837B401 for ; Mon, 30 Jun 2003 06:59:42 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECF9743FDF for ; Mon, 30 Jun 2003 06:59:41 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h5UDxfwV002179 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 30 Jun 2003 09:59:41 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h5UDxaB08432; Mon, 30 Jun 2003 09:59:36 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16128.16968.114031.709885@grasshopper.cs.duke.edu> Date: Mon, 30 Jun 2003 09:59:36 -0400 (EDT) To: "Justin T. Gibbs" In-Reply-To: <721230000.1056753126@aslan.btc.adaptec.com> References: <3EF3C12F.9060303@btc.adaptec.com> <16124.39930.142492.356163@grasshopper.cs.duke.edu> <3EFC9F2D.6020908@btc.adaptec.com> <16124.43999.333761.397624@grasshopper.cs.duke.edu> <3EFCAC7A.6060305@btc.adaptec.com> <16124.45051.919899.414795@grasshopper.cs.duke.edu> <3EFCB178.9030207@btc.adaptec.com> <16124.46454.595892.860118@grasshopper.cs.duke.edu> <3EFCB725.4060902@btc.adaptec.com> <16124.48285.343025.428957@grasshopper.cs.duke.edu> <721230000.1056753126@aslan.btc.adaptec.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-arch@freebsd.org Subject: Re: API change for bus_dma X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2003 13:59:43 -0000 Justin T. Gibbs writes: > > > As I understand it, it is possible to set the pycho bridge to use > > > a coherent address range, but FreeBSD doesn't take advantage of that > > > yet. > > > > > > > Yes, that's what solaris does.. > > We added BUS_DMA_COHERENT to the API just before shipping 5.1. It > is only a "hint", so if you need to verify that the implementation > was able to give you coherent memory, we should add an API to allow > you to know. Of course, the Sparc bus dma implementation doesn't honor > the flag yet, but I'm sure that will change shortly. > Thanks Justin! Drew From owner-freebsd-arch@FreeBSD.ORG Mon Jun 30 07:03:57 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4862C37B404 for ; Mon, 30 Jun 2003 07:03:57 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AB4643FBD for ; Mon, 30 Jun 2003 07:03:56 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h5UE3qwV002660 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 30 Jun 2003 10:03:52 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h5UE3lh08442; Mon, 30 Jun 2003 10:03:47 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16128.17218.973911.980939@grasshopper.cs.duke.edu> Date: Mon, 30 Jun 2003 10:03:46 -0400 (EDT) To: Terry Lambert In-Reply-To: <3EFD4755.49BAF150@mindspring.com> References: <3EF3C12F.9060303@btc.adaptec.com> <16124.39930.142492.356163@grasshopper.cs.duke.edu> <3EFC9F2D.6020908@btc.adaptec.com> <16124.43999.333761.397624@grasshopper.cs.duke.edu> <3EFCAC7A.6060305@btc.adaptec.com> <16124.45051.919899.414795@grasshopper.cs.duke.edu> <3EFD4755.49BAF150@mindspring.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: Scott Long cc: Andrew Gallatin cc: freebsd-arch@freebsd.org Subject: Re: API change for bus_dma X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2003 14:03:57 -0000 Terry Lambert writes: > Andrew Gallatin wrote: > > Most sparc's have 2 different sorts of DMA modes. One is cache > > coherent (aka DDI_DMA_CONSISTENT) -- this is what we all know and love > > from PC, alphas, macs, etc. > > "contiguous" > > > > The other mode (DDI_DMA_STREAMING) allows non cache coherent DMA. > > This requires you to call ddi_dma_sync() between your last touch of > > the data and you starting a DMA read from a device. And vice-versa > > for a DMA write. > > "scatter/gather" > > > The reason people use DDI_DMA_STREAMING is because coherent DMA > > bandwith tends to be abysmal on most sparcs. > The idea is that I want to establish a mapping that can be used many times without any driver or kernel attention. I don't want to do anything in terms of a system call, or interrupt, etc, to sync the cache with the state of the DMA'ed page before a DMA read or after a DMA write. For example, scatter gather mapping on alphas (if FreeBSD supported it for PCI devices) would be fine with me since its cache-coherent and doesn't require any ddi_dma_sync() operations. Drew From owner-freebsd-arch@FreeBSD.ORG Tue Jul 1 02:30:31 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA0CE37B401 for ; Tue, 1 Jul 2003 02:30:31 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5212A44011 for ; Tue, 1 Jul 2003 02:30:30 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h619U5hR023305 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 1 Jul 2003 11:30:13 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h619U2w6036386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2003 11:30:03 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.9/8.12.9) with ESMTP id h619U2gt098000; Tue, 1 Jul 2003 11:30:02 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.9/8.12.9/Submit) id h619TkbF097996; Tue, 1 Jul 2003 11:29:46 +0200 (CEST) Date: Tue, 1 Jul 2003 11:29:45 +0200 From: Bernd Walter To: Andrew Gallatin Message-ID: <20030701092944.GE90081@cicely12.cicely.de> References: <3EF3C12F.9060303@btc.adaptec.com> <16124.39930.142492.356163@grasshopper.cs.duke.edu> <3EFC9F2D.6020908@btc.adaptec.com> <16124.43999.333761.397624@grasshopper.cs.duke.edu> <3EFCAC7A.6060305@btc.adaptec.com> <16124.45051.919899.414795@grasshopper.cs.duke.edu> <3EFD4755.49BAF150@mindspring.com> <16128.17218.973911.980939@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16128.17218.973911.980939@grasshopper.cs.duke.edu> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-CURRENT alpha User-Agent: Mutt/1.5.4i cc: Scott Long cc: freebsd-arch@freebsd.org Subject: Re: API change for bus_dma X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2003 09:30:32 -0000 On Mon, Jun 30, 2003 at 10:03:46AM -0400, Andrew Gallatin wrote: > The idea is that I want to establish a mapping that can be used many > times without any driver or kernel attention. I don't want to do > anything in terms of a system call, or interrupt, etc, to sync the > cache with the state of the DMA'ed page before a DMA read or after a DMA > write. > > For example, scatter gather mapping on alphas (if FreeBSD supported it > for PCI devices) would be fine with me since its cache-coherent and > doesn't require any ddi_dma_sync() operations. What makes you shure about alpha dma to be cache-coherent? I'm not shure that the current implementation of _bus_dmamap_sync() without barriers is correct. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-arch@FreeBSD.ORG Tue Jul 1 05:22:16 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7376537B404 for ; Tue, 1 Jul 2003 05:22:16 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27CB343FF7 for ; Tue, 1 Jul 2003 05:22:13 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h61CM8wV010766 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 1 Jul 2003 08:22:08 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h61CM3H10417; Tue, 1 Jul 2003 08:22:03 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16129.31978.982920.826662@grasshopper.cs.duke.edu> Date: Tue, 1 Jul 2003 08:22:02 -0400 (EDT) To: ticso@cicely.de In-Reply-To: <20030701092944.GE90081@cicely12.cicely.de> References: <3EF3C12F.9060303@btc.adaptec.com> <16124.39930.142492.356163@grasshopper.cs.duke.edu> <3EFC9F2D.6020908@btc.adaptec.com> <16124.43999.333761.397624@grasshopper.cs.duke.edu> <3EFCAC7A.6060305@btc.adaptec.com> <16124.45051.919899.414795@grasshopper.cs.duke.edu> <3EFD4755.49BAF150@mindspring.com> <16128.17218.973911.980939@grasshopper.cs.duke.edu> <20030701092944.GE90081@cicely12.cicely.de> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: Scott Long cc: freebsd-arch@freebsd.org Subject: Re: API change for bus_dma X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2003 12:22:17 -0000 Bernd Walter writes: > On Mon, Jun 30, 2003 at 10:03:46AM -0400, Andrew Gallatin wrote: > > The idea is that I want to establish a mapping that can be used many > > times without any driver or kernel attention. I don't want to do > > anything in terms of a system call, or interrupt, etc, to sync the > > cache with the state of the DMA'ed page before a DMA read or after a DMA > > write. > > > > For example, scatter gather mapping on alphas (if FreeBSD supported it > > for PCI devices) would be fine with me since its cache-coherent and > > doesn't require any ddi_dma_sync() operations. > > What makes you shure about alpha dma to be cache-coherent? 7 years of sometimes painful experience with Myrinet on alpha ;) > I'm not shure that the current implementation of _bus_dmamap_sync() > without barriers is correct. Barriers, if present, would be used to flush write buffers in the CPU so they're seen by the cache, not to flush the cache itself. I agree they should be present. Drew From owner-freebsd-arch@FreeBSD.ORG Thu May 15 12:35:02 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 932D737B401 for ; Thu, 15 May 2003 12:35:02 -0700 (PDT) Received: from falcon.midgard.homeip.net (h76n3fls20o913.telia.com [213.67.148.76]) by mx1.FreeBSD.org (Postfix) with SMTP id 57AB143F75 for ; Thu, 15 May 2003 12:35:00 -0700 (PDT) (envelope-from ertr1013@student.uu.se) Received: (qmail 19658 invoked by uid 1001); 15 May 2003 19:34:58 -0000 From: Erik Trulsson To: Dag-Erling Smorgrav Message-ID: <20030515193457.GA19619@falcon.midgard.homeip.net> Mail-Followup-To: Dag-Erling Smorgrav , arch@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: arch@freebsd.org Subject: Re: NOCRYPT / NOSECURE X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 15 May 2003 19:35:02 -0000 X-Original-Date: Thu, 15 May 2003 21:34:57 +0200 X-List-Received-Date: Thu, 15 May 2003 19:35:02 -0000 On Thu, May 15, 2003 at 04:20:08PM +0200, Dag-Erling Smorgrav wrote: > I just tried to run a tinderbox with NOCRYPT and NOSECURE (but not > NO_OPENSSL) defined. It failed because there are Makefiles > (games/factor was the one that broke the build, but glimpse(1) tells > me there are others) which check NO_OPENSSL and / or NOCRYPT but not > NOSECURE. > > NOSECURE is a meaningless subset of NOCRYPT. It means "don't descend > into src/secure", but that's equivalent to NOCRYPT because a) we don't > descend into src/secure if NOCRYPT is set and b) the only significant > stuff which NOCRYPT disables but NOSECURE doesn't is Kerberos, which > requires OpenSSL, which isn't built in the NOSECURE case, so there's > no way we can build world with NOSECURE but not NOCRYPT. > > I would therefore like to remove NOSECURE, preferably before 5.1. > > NO_OPENSSL is also a subset of NOCRYPT. There is so little that > builds with NO_OPENSSL but not with NOCRYPT that I think it might be > worthwhile to deprecate NO_OPENSSL and change the description of > NOCRYPT from "will prevent building of crypt versions" to "do not > build crypto-related software" NO_OPENSSL would seem to be useful after doing 'make -DOPENSSL_OVERWRITE_BASE install' in the security/openssl port. I.e. NO_OPENSSL (as well as several of the other NO_xxx flags) make sure that you can replace some utilities with newer versions from ports without the next make world undoing all that. > > We also have something called libcipher which is only used by bdes(1); > the OpenSSL distribution contains a similar and AFAIK compatible > utility (src/crypto/openssl/crypto/des/des.c) which we don't currently > build. We should probably ditch both libcipher and bdes(1), and > perhaps add OpenSSL's des(1) to the build if our users really want it, > though 'ln -s /usr/bin/openssl /usr/bin/des' goes a long way. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-arch@FreeBSD.ORG Wed Jul 2 20:16:07 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBAB237B401 for ; Wed, 2 Jul 2003 20:16:07 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 749E843FD7 for ; Wed, 2 Jul 2003 20:16:05 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h633FkaQ019647; Wed, 2 Jul 2003 20:15:51 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h633FcFh019646; Wed, 2 Jul 2003 20:15:38 -0700 (PDT) Date: Wed, 2 Jul 2003 20:15:37 -0700 From: "David O'Brien" To: Ian Dowse Message-ID: <20030703031537.GD18897@dragon.nuxi.com> References: <200306282254.aa83607@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200306282254.aa83607@salmon.maths.tcd.ie> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.1-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-arch@freebsd.org Subject: Re: Unmounting by filesystem ID X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2003 03:16:08 -0000 On Sat, Jun 28, 2003 at 10:54:04PM +0100, Ian Dowse wrote: > The patch below adds a new mount flag MNT_BYFSID that can be used > to unmount a filesystem by specifying its filesystem ID instead of > a path. The umount utility is changed to use this mechanism by > default. This approach has a number of advantages: > > - It avoids any lookup operations that could potentially block > forever, so filesystems such as NFS can be reliably unmounted > even if the server is not responding but looking up the root node > would require an RPC (maybe to an underlying filesystem). VERY nice. From owner-freebsd-arch@FreeBSD.ORG Thu Jul 3 11:11:35 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B8A337B401 for ; Thu, 3 Jul 2003 11:11:35 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF76E43FDF for ; Thu, 3 Jul 2003 11:11:32 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id h63IBMM18624; Thu, 3 Jul 2003 15:11:22 -0300 Message-ID: <3F0471C9.5080003@tcoip.com.br> Date: Thu, 03 Jul 2003 15:11:21 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030702 X-Accept-Language: en-us, en, pt-br, ja MIME-Version: 1.0 To: Ian Dowse References: <200306282254.aa83607@salmon.maths.tcd.ie> In-Reply-To: <200306282254.aa83607@salmon.maths.tcd.ie> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: Unmounting by filesystem ID X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2003 18:11:35 -0000 Ian Dowse wrote: > The patch below adds a new mount flag MNT_BYFSID that can be used > to unmount a filesystem by specifying its filesystem ID instead of > a path. The umount utility is changed to use this mechanism by > default. This approach has a number of advantages: > > - It avoids any lookup operations that could potentially block > forever, so filesystems such as NFS can be reliably unmounted > even if the server is not responding but looking up the root node > would require an RPC (maybe to an underlying filesystem). > - The filesystem specification is unambiguous, so umount(8) can > be sure that it is unmounting the correct filesystem (more > work in umount(8) may be required here). > - Detached filesystems can be unmounted. If a filesystem becomes > detached from the filesystem hierarchy because the underlying > filesystem got unmounted, it does not require a reboot to unmount > it. > > Since unmounting by a path name is now only required for compatibility, > in that case unmount() now just does a string comparison to find > the correct filesystem. Also, this patch only affects unmounting; > a similar approach could be applied to MNT_UPDATE mount operations. > > I would like to commit this during the next few days. Any comments > or suggestions? Just in the unlikely case no one has said this to your face yet, man, you rule. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net One time the police stopped me for speeding. They said, "Don't you know the speed limit is fifty-five miles an hour?" I said, "Yeah, I know, but I wasn't going to be out that long." -- Steven Wright From owner-freebsd-arch@FreeBSD.ORG Fri Jul 4 17:40:00 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 084E937B401 for ; Fri, 4 Jul 2003 17:40:00 -0700 (PDT) Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6908843FE5 for ; Fri, 4 Jul 2003 17:39:59 -0700 (PDT) (envelope-from adam@blacktabby.org) Received: (qmail 6451 invoked by uid 64014); 5 Jul 2003 00:39:59 -0000 Received: from adam@blacktabby.org by mail15.speakeasy.net with AmikaGuardian-Server-2.0.0 (Processed in 0.572679 secs); 05 Jul 2003 00:39:59 -0000 X-AmikaGuardian-Id: mail15.speakeasy.net10573655982366448 X-AmikaGuardian-Category: AN:Vectored : 0.4 X-AmikaGuardian-Category: AN:Override : 0.4 X-AmikaGuardian-Category: AN:Exception : 0.4 X-AmikaGuardian-Category: AN:Forwarded Mail : 0.4 X-AmikaGuardian-Action: Do Nothing() Received: from unknown (HELO cheshire.blacktabby.org) (akranzel@[67.74.34.64]) (envelope-sender ) by mail15.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 5 Jul 2003 00:39:58 -0000 Date: Fri, 4 Jul 2003 17:39:54 -0700 From: Adam Kranzel To: freebsd-arch@freebsd.org Message-Id: <20030704173954.2a6084a7.adam@blacktabby.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: Ian Dowse Subject: Re: Unmounting by filesystem ID X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2003 00:40:00 -0000 This is *way* cool. I use an NFS server a lot here, but the silly thing has hardware problems and crashes all the time, then has to fsck its raid array, making it take forever to come back up. Being able to just unmount the FS and keep working will be *very* useful. -Adam From owner-freebsd-arch@FreeBSD.ORG Sat Jul 5 06:57:31 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D73DE37B401 for ; Sat, 5 Jul 2003 06:57:31 -0700 (PDT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F31243FE9 for ; Sat, 5 Jul 2003 06:57:31 -0700 (PDT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.20) id 19YnXz-0000Mf-Iz; Sat, 05 Jul 2003 17:57:51 +0400 From: "Vladimir B. Grebenschikov" To: Ian Dowse In-Reply-To: <200306282254.aa83607@salmon.maths.tcd.ie> References: <200306282254.aa83607@salmon.maths.tcd.ie> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Organization: SWsoft Inc. Message-Id: <1057413470.716.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 05 Jul 2003 17:57:51 +0400 Sender: Vladimir Grebenschikov cc: freebsd-arch@freebsd.org Subject: Re: Unmounting by filesystem ID X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2003 13:57:32 -0000 =F7 Sun, 29.06.2003, =D7 01:54, Ian Dowse =D0=C9=DB=C5=D4: > The patch below adds a new mount flag MNT_BYFSID that can be used > to unmount a filesystem by specifying its filesystem ID instead of > a path. The umount utility is changed to use this mechanism by > default. This approach has a number of advantages: Cool! May be you fix issue of umounting by known vnode ? problem is in mounting different devices under chroot. in list of mounts they differ only by device id, and it is rather=20 difficult to umount filesystem if I known absolute path but do not enter to chroot. --=20 Vladimir B. Grebenschikov SWsoft Inc. From owner-freebsd-arch@FreeBSD.ORG Sat Jul 5 08:05:16 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD4BD37B401 for ; Sat, 5 Jul 2003 08:05:16 -0700 (PDT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 9292C43FCB for ; Sat, 5 Jul 2003 08:05:15 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 5 Jul 2003 16:05:14 +0100 (BST) To: "Vladimir B. Grebenschikov" In-Reply-To: Your message of "05 Jul 2003 17:57:51 +0400." <1057413470.716.3.camel@localhost> Date: Sat, 05 Jul 2003 16:05:13 +0100 From: Ian Dowse Message-ID: <200307051605.aa02337@salmon.maths.tcd.ie> cc: freebsd-arch@freebsd.org Subject: Re: Unmounting by filesystem ID X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2003 15:05:17 -0000 In message <1057413470.716.3.camel@localhost>, "Vladimir B. Grebenschikov" writ es: >May be you fix issue of umounting by known vnode ? >problem is in mounting different devices under chroot. >in list of mounts they differ only by device id, and it is rather=20 >difficult to umount filesystem if I known absolute path but do not enter >to chroot. The MNT_BYFSID approach makes it always possible to indicate to the kernel which filesystem is to be unmounted, but some more work is needed in the umount(8) utility to handle unusual cases. The simplest way for umount to reliably pick the right file system would be to have it call statfs(2) on the supplied path, and then use the resulting filesystem ID to do the unmount(2) call. That would allow you to unmount a filesystem that was mounted from within a chroot by just specifying the full path to the filesystem even though it is not the path that df or mount show. Unfortunately, statfs(2) may get stuck if the path leads to (or traverses) a network filesystem that is not responding. In this case it is better for the umount utility to use getfsstat(2) with the MNT_NOWAIT flag, and pick the filesystem that has the path that was specified. This will do the wrong thing if for example you two /var filesystems listed because one was mounted from inside a chroot. There is also the problem of checking that the path points to the root of the filesystem as statfs(2) works on any file or directory. I think umount can probably be made do something reasonable in most cases by having it use extra mechanisms such as statfs(2) only when the named filesystem is not found on the mount list, or when it is found multiple times, but it may be necessary to add a new command-line argument to force it to use one of the two behaviours. Note that you can also unmount a filesystem by specifying the device name instead of the path. This works a bit better now than it used to, as umount doesn't have to translate back into a path before calling unmount(2). However it can still get a bit confused by chroots: # chroot /root0 mdmfs -s 5m md0 /mnt # chroot /root1 mdmfs -s 5m md1 /mnt # df | grep md /dev/md0 4780 4 4396 0% /mnt /dev/md1 4780 4 4396 0% /mnt # umount /dev/md0 umount: cannot umount /mnt, /dev/md1 is mounted there, umount it first # df | grep md /dev/md0 4780 4 4396 0% /mnt /dev/md1 4780 4 4396 0% /mnt # umount -f /dev/md0 # df | grep md /dev/md1 4780 4 4396 0% /mnt # umount /dev/md1 # df | grep md # Ian From owner-freebsd-arch@FreeBSD.ORG Sat Jul 5 10:26:13 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5AD537B401 for ; Sat, 5 Jul 2003 10:26:13 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 094C443FE9 for ; Sat, 5 Jul 2003 10:26:13 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.9/8.12.9) id h65HQ0NL064217; Sat, 5 Jul 2003 12:26:00 -0500 (CDT) (envelope-from dan) Date: Sat, 5 Jul 2003 12:25:59 -0500 From: Dan Nelson To: Ian Dowse Message-ID: <20030705172559.GQ24527@dan.emsphone.com> References: <1057413470.716.3.camel@localhost> <200307051605.aa02337@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307051605.aa02337@salmon.maths.tcd.ie> X-OS: FreeBSD 5.1-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.4i cc: "Vladimir B. Grebenschikov" cc: freebsd-arch@freebsd.org Subject: Re: Unmounting by filesystem ID X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2003 17:26:14 -0000 In the last episode (Jul 05), Ian Dowse said: > In message <1057413470.716.3.camel@localhost>, "Vladimir B. Grebenschikov" writes: > >May be you fix issue of umounting by known vnode ? problem is in > >mounting different devices under chroot. in list of mounts they > >differ only by device id, and it is rather=20 difficult to umount > >filesystem if I known absolute path but do not enter to chroot. > > The MNT_BYFSID approach makes it always possible to indicate to the > kernel which filesystem is to be unmounted, but some more work is > needed in the umount(8) utility to handle unusual cases. Can mount(8) be changed to print the fsid? Maybe hide it under -v if it's a long value? This seems like the only solution that can cover the case where you have stacked two identical NFS mounts, one on top of the other. I've done this occasionally to force the kernel to retry access to a server that has just come back after a reboot. amd could probably benefit from dismounting using fsid if possible, too. Although it'd have to try fsid then path for the case where root has dismounted then remounted one of its filesystems behind its back (I've done this too, to change nfsv2 mounts to v3, etc). -- Dan Nelson dnelson@allantgroup.com