From owner-freebsd-arch@FreeBSD.ORG Sun Jul 4 15:51:17 2004 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 D068916A4CF; Sun, 4 Jul 2004 15:51:17 +0000 (GMT) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2374B43D1F; Sun, 4 Jul 2004 15:51:17 +0000 (GMT) (envelope-from tim@kientzle.com) Received: from kientzle.com (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id i64For90027387; Sun, 4 Jul 2004 08:50:53 -0700 (PDT) (envelope-from tim@kientzle.com) Message-ID: <40E8275B.1090008@kientzle.com> Date: Sun, 04 Jul 2004 08:50:51 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Oliver Eikemeier References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: Tim Kientzle cc: re@freebsd.org cc: audit@freebsd.org Subject: Re: RFC: bsdtar in 5.3 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, 04 Jul 2004 15:51:18 -0000 Oliver Eikemeier wrote: > > Are there any plans to do an security audit of bsdtar? This may be an > important issue, since tar is often used running as root to unpack > downloaded archives. This is an excellent idea. Obviously, someone other than me should lead this: any volunteers? Tim From owner-freebsd-arch@FreeBSD.ORG Mon Jul 5 07:31:40 2004 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 8A7EC16A4CE; Mon, 5 Jul 2004 07:31:40 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D94EC43D39; Mon, 5 Jul 2004 07:31:39 +0000 (GMT) (envelope-from ilmar@watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i657V7Vw049583; Mon, 5 Jul 2004 03:31:07 -0400 (EDT) (envelope-from ilmar@watson.org) Received: from localhost (ilmar@localhost)i657V7hK049580; Mon, 5 Jul 2004 03:31:07 -0400 (EDT) (envelope-from ilmar@watson.org) X-Authentication-Warning: fledge.watson.org: ilmar owned process doing -bs Date: Mon, 5 Jul 2004 03:31:07 -0400 (EDT) From: "Ilmar S. Habibulin" To: arch@freebsd.org In-Reply-To: <40E8275B.1090008@kientzle.com> Message-ID: <20040705032952.G49485@fledge.watson.org> References: <40E8275B.1090008@kientzle.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: re@freebsd.org cc: audit@freebsd.org Subject: Re: RFC: bsdtar in 5.3 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, 05 Jul 2004 07:31:40 -0000 Does bsdtar support storing and extracting extended attributes, such as ACLs and MAC labels? From owner-freebsd-arch@FreeBSD.ORG Tue Jul 6 05:33:53 2004 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 1191716A4CE for ; Tue, 6 Jul 2004 05:33:53 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74AD443D2F for ; Tue, 6 Jul 2004 05:33:52 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from dhcp50.pn.xcllnt.net (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i665Xqw9054805 for ; Mon, 5 Jul 2004 22:33:52 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp50.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp50.pn.xcllnt.net (8.12.11/8.12.11) with ESMTP id i665XpMn062096 for ; Mon, 5 Jul 2004 22:33:52 -0700 (PDT) (envelope-from marcel@dhcp50.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp50.pn.xcllnt.net (8.12.11/8.12.11/Submit) id i665XpkB062095 for arch@FreeBSD.org; Mon, 5 Jul 2004 22:33:51 -0700 (PDT) (envelope-from marcel) Date: Mon, 5 Jul 2004 22:33:51 -0700 From: Marcel Moolenaar To: arch@FreeBSD.org Message-ID: <20040706053351.GA62046@dhcp50.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Please review: revamp of kernel debugging code 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, 06 Jul 2004 05:33:53 -0000 Gang, I reworked the kernel debugging support to achieve the following: 1. Allow any device to be used as debug port, not just sio(4). This is required on platforms that don't support sio(4). Such as ia64. 2. Unify the remote GDB stubs and improve remote debugging. This applies to sparc64 and ia64. 3. Improve speed of remote GDB by implementing compression. This is pretty much required on ia64, where the register context is 9KB. 3. Add thread awareness to both remote GDB and DDB. This includes the ability to switch the active thread and provide backtraces for them. 4. Remove the NO_SIO option added on alpha to work around console braindeadness. Alpha now looks like a normal platform :-) 5. Detangle remote GDB support from DDB code to allow only remote GDB to be configured, but not DDB (and obviously vice versa). This also allows other debugger implementations to be added. 6. Improve symbol handling in DDB, especially for the pre-linker case. I probably forgot some items, but you get the gist. The patch applies to alpha, amd64, i386, ia64 and sparc64. amd64 is known to compile but I can't test this stuff yet due to lack of hardware. Typically you'll see that #ifdef DDB is being replaced with #ifdef KDB. This is because DDB indicates whether you want the DDB debugger, but not having DDB doesn't mean that there isn't any debugger at all. So a new option KDB as been added to indicate that certain debugging code should be compiled in. Please apply the patch and try it out. Note that the patch is quite large (~363KB), so http://people.freebsd.org/~marcel/gdb.diff I'll probably commit it in about a week or so if there aren't any showshopper issues. FYI, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Tue Jul 6 08:39:54 2004 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 CA1CD16A4CE for ; Tue, 6 Jul 2004 08:39:54 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07A2743D55 for ; Tue, 6 Jul 2004 08:39:54 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i668doZZ010632; Tue, 6 Jul 2004 10:39:50 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 05 Jul 2004 22:33:51 PDT." <20040706053351.GA62046@dhcp50.pn.xcllnt.net> Date: Tue, 06 Jul 2004 10:39:50 +0200 Message-ID: <10631.1089103190@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: Please review: revamp of kernel debugging code 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, 06 Jul 2004 08:39:54 -0000 In message <20040706053351.GA62046@dhcp50.pn.xcllnt.net>, Marcel Moolenaar writ es: >Gang, > >I reworked the kernel debugging support to achieve the following: Thankyou! I'll stick it in my tree here ASAP. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Jul 8 20:12:31 2004 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 E1FEA16A4CE for ; Thu, 8 Jul 2004 20:12:31 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33DF643D48 for ; Thu, 8 Jul 2004 20:12:31 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i68KCSnO006596 for ; Thu, 8 Jul 2004 22:12:29 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org From: Poul-Henning Kamp Date: Thu, 08 Jul 2004 22:12:28 +0200 Message-ID: <6595.1089317548@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: [RFC] kldunload -f argument. 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, 08 Jul 2004 20:12:32 -0000 In an ideal situation, unmount(8) will fail to unload if the filesystem is in use but the administrator has the option of applying the -f(orce) option which tells the kernel: "umount at any cost" [3]. We do not have the same flexibility with kldunload(8), and this is leading to a minor spot of trouble for modules which autoattach to things, like for instance GEOM classes where it can be very hard if not impossible to get the module idle from userland so it can be unloaded. The society of archtecturally confused kernel hackers had a brief discussion about this on that IRC channel tonight (UTC) and the following proposal was what came out of it. Kldunload today sends only one event to the modules: MOD_UNLOAD and if the module returns non-zero, it gives up. Most modules will return non-zero for any minor or major bump in the road. In the new world order, a new event is introduced MOD_QUIESCE[1]. A normal kldunload will send a MOD_QUIESCE and if it returns non-zero the kldunload fails. If MOD_QUIESCE succeeds, MOD_UNLOAD is sent. If MOD_UNLOAD comes back non-zero, the kldunload fails. A forced kldunload is the same, except the return value from MOD_QUIESCE is ignored. The "in-use" checks in the module should happen in the MOD_QUIESCE event and if the module decides to return success it should refuse any new service [4] knowing that MOD_UNLOAD will be following. Modules should now only veto MOD_UNLOAD if there is no way to unload the module without the unload endangering the kernel[2]. Reasons could be memory in the module used by bits of the kernel where it can't be reclaimed. Root filesystem mounted using filesystem in module etc. Today most modules will return EOPNOTSUPP or zero for an unknown MOD_FOO event, so backwards compatibility is a minor issue. Comments ? Poul-Henning [1] I hate that name, I can't spell it without looking it up. Better suggestions are very welcome. [2] Note that this does not include secondary effects: The fact that filesystem with insufficient error checks explode if its disk driver is unloaded is NOT a valid reason for the disk driver to refuse unloading: the filesystem should be fixed instead. [3] We are not at this point interested in discussing how many bugs there are in this and related code and how many ways you can explode your system using unmount -f. We know. We'll get to it. Eventually. [4] This is necessary to close the obvious race wher a MOD_UNLOAD preventing auto attachment happened between MOD_QUIESCE and MOD_UNLOAD. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Jul 8 20:50:35 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C32AE16A4CE; Thu, 8 Jul 2004 20:50:34 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i68KoY7a003570; Thu, 8 Jul 2004 16:50:34 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i68KoXKL003569; Thu, 8 Jul 2004 16:50:33 -0400 (EDT) (envelope-from green) Date: Thu, 8 Jul 2004 16:50:33 -0400 From: Brian Fundakowski Feldman To: Poul-Henning Kamp Message-ID: <20040708205032.GA1626@green.homeunix.org> References: <6595.1089317548@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6595.1089317548@critter.freebsd.dk> User-Agent: Mutt/1.5.6i cc: arch@freebsd.org Subject: Re: [RFC] kldunload -f argument. 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, 08 Jul 2004 20:50:35 -0000 On Thu, Jul 08, 2004 at 10:12:28PM +0200, Poul-Henning Kamp wrote: > [...] > [1] I hate that name, I can't spell it without looking it up. Better > suggestions are very welcome. I like the implementation; it'll just be a bit of churn adding it to every module handler in the system. How about just name it MOD_DRAIN? -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-arch@FreeBSD.ORG Thu Jul 8 20:52:36 2004 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 D676616A4CE for ; Thu, 8 Jul 2004 20:52:36 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3586343D31 for ; Thu, 8 Jul 2004 20:52:36 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 4445B5310; Thu, 8 Jul 2004 22:52:35 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 0A3CD5309; Thu, 8 Jul 2004 22:52:27 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 9D444B860; Thu, 8 Jul 2004 22:52:27 +0200 (CEST) To: Poul-Henning Kamp References: <6595.1089317548@critter.freebsd.dk> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Thu, 08 Jul 2004 22:52:27 +0200 In-Reply-To: <6595.1089317548@critter.freebsd.dk> (Poul-Henning Kamp's message of "Thu, 08 Jul 2004 22:12:28 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: arch@freebsd.org Subject: Re: [RFC] kldunload -f argument. 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, 08 Jul 2004 20:52:36 -0000 Poul-Henning Kamp writes: > Comments ? Sounds like a good idea to me. > [1] I hate that name, I can't spell it without looking it up. Better > suggestions are very welcome. MOD_SHUTDOWN perhaps? DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Jul 8 20:54:48 2004 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 1027116A4CE for ; Thu, 8 Jul 2004 20:54:48 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54FD743D48 for ; Thu, 8 Jul 2004 20:54:47 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i68KsjBh007274; Thu, 8 Jul 2004 22:54:45 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 08 Jul 2004 22:52:27 +0200." Date: Thu, 08 Jul 2004 22:54:45 +0200 Message-ID: <7273.1089320085@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: [RFC] kldunload -f argument. 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, 08 Jul 2004 20:54:48 -0000 In message , =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= writes: >Poul-Henning Kamp writes: >> Comments ? > >Sounds like a good idea to me. > >> [1] I hate that name, I can't spell it without looking it up. Better >> suggestions are very welcome. > >MOD_SHUTDOWN perhaps? We already have that one unfortunately :-( -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Jul 8 21:04:26 2004 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 A3C5816A4CF for ; Thu, 8 Jul 2004 21:04:26 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A18243D2F for ; Thu, 8 Jul 2004 21:04:26 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 8F7045310; Thu, 8 Jul 2004 23:04:25 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id D703B5309; Thu, 8 Jul 2004 23:04:18 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 81DFDB860; Thu, 8 Jul 2004 23:04:18 +0200 (CEST) To: "Poul-Henning Kamp" References: <7273.1089320085@critter.freebsd.dk> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Thu, 08 Jul 2004 23:04:18 +0200 In-Reply-To: <7273.1089320085@critter.freebsd.dk> (Poul-Henning Kamp's message of "Thu, 08 Jul 2004 22:54:45 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: arch@freebsd.org Subject: Re: [RFC] kldunload -f argument. 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, 08 Jul 2004 21:04:26 -0000 "Poul-Henning Kamp" writes: > "Dag-Erling_Sm=F8rgrav" writes: > > MOD_SHUTDOWN perhaps? > We already have that one unfortunately :-( Ah, silly me. Well, how about MOD_STOP? DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Jul 8 21:10:30 2004 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 7348216A4CE for ; Thu, 8 Jul 2004 21:10:30 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA86E43D1D for ; Thu, 8 Jul 2004 21:10:29 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i68LASBw007552; Thu, 8 Jul 2004 23:10:28 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 08 Jul 2004 23:04:18 +0200." Date: Thu, 08 Jul 2004 23:10:28 +0200 Message-ID: <7551.1089321028@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: [RFC] kldunload -f argument. 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, 08 Jul 2004 21:10:30 -0000 In message , =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= writes: >"Poul-Henning Kamp" writes: >> "Dag-Erling_Smørgrav" writes: >> > MOD_SHUTDOWN perhaps? >> We already have that one unfortunately :-( > >Ah, silly me. Well, how about MOD_STOP? Better, but still not perfect. The problem is that this is the kind request, not the direct order: We're looking for a sensible version of: MOD_PREPARE_YOURSELF_TO_BE_UNLOADED_BUT_FAIL_IF_YOU_ARE_IN_USE_PLEASE :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Jul 8 21:20:40 2004 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 43B5216A4CF for ; Thu, 8 Jul 2004 21:20:40 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id B03A643D1F for ; Thu, 8 Jul 2004 21:20:39 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 1022665218; Thu, 8 Jul 2004 22:20:38 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 57224-02-4; Thu, 8 Jul 2004 22:20:37 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 76E7A65216; Thu, 8 Jul 2004 22:20:37 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id E969C613D; Thu, 8 Jul 2004 22:20:35 +0100 (BST) Date: Thu, 8 Jul 2004 22:20:35 +0100 From: Bruce M Simpson To: Poul-Henning Kamp Message-ID: <20040708212035.GK15368@empiric.dek.spc.org> References: <7551.1089321028@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7551.1089321028@critter.freebsd.dk> cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= cc: arch@freebsd.org Subject: Re: [RFC] kldunload -f argument. 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, 08 Jul 2004 21:20:40 -0000 On Thu, Jul 08, 2004 at 11:10:28PM +0200, Poul-Henning Kamp wrote: > MOD_PREPARE_YOURSELF_TO_BE_UNLOADED_BUT_FAIL_IF_YOU_ARE_IN_USE_PLEASE MOD_PREUNLOAD ? BMS From owner-freebsd-arch@FreeBSD.ORG Thu Jul 8 21:32:02 2004 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 2D38D16A4CE; Thu, 8 Jul 2004 21:32:02 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0850643D1D; Thu, 8 Jul 2004 21:32:02 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i68LVvWi035563 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 8 Jul 2004 14:31:58 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: freebsd-arch@freebsd.org Date: Thu, 8 Jul 2004 14:34:23 -0700 User-Agent: KMail/1.6.1 References: <7551.1089321028@critter.freebsd.dk> In-Reply-To: <7551.1089321028@critter.freebsd.dk> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200407081434.23671.sam@errno.com> cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= cc: Poul-Henning Kamp cc: arch@freebsd.org Subject: Re: [RFC] kldunload -f argument. 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, 08 Jul 2004 21:32:02 -0000 On Thursday 08 July 2004 02:10 pm, Poul-Henning Kamp wrote: > In message , > =3D?iso-8859-1?q?Dag-Erling_Sm=3DF8rgrav?=3D > > writes: > >"Poul-Henning Kamp" writes: > >> "Dag-Erling_Sm=F8rgrav" writes: > >> > MOD_SHUTDOWN perhaps? > >> > >> We already have that one unfortunately :-( > > > >Ah, silly me. Well, how about MOD_STOP? > > Better, but still not perfect. The problem is that this is the > kind request, not the direct order: We're looking for a sensible > version of: > > MOD_PREPARE_YOURSELF_TO_BE_UNLOADED_BUT_FAIL_IF_YOU_ARE_IN_USE_PLEASE > > :-) MOD_BIKESHED From owner-freebsd-arch@FreeBSD.ORG Thu Jul 8 21:32:02 2004 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 2D38D16A4CE; Thu, 8 Jul 2004 21:32:02 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0850643D1D; Thu, 8 Jul 2004 21:32:02 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i68LVvWi035563 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 8 Jul 2004 14:31:58 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: freebsd-arch@freebsd.org Date: Thu, 8 Jul 2004 14:34:23 -0700 User-Agent: KMail/1.6.1 References: <7551.1089321028@critter.freebsd.dk> In-Reply-To: <7551.1089321028@critter.freebsd.dk> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200407081434.23671.sam@errno.com> cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= cc: Poul-Henning Kamp cc: arch@freebsd.org Subject: Re: [RFC] kldunload -f argument. 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, 08 Jul 2004 21:32:02 -0000 On Thursday 08 July 2004 02:10 pm, Poul-Henning Kamp wrote: > In message , > =3D?iso-8859-1?q?Dag-Erling_Sm=3DF8rgrav?=3D > > writes: > >"Poul-Henning Kamp" writes: > >> "Dag-Erling_Sm=F8rgrav" writes: > >> > MOD_SHUTDOWN perhaps? > >> > >> We already have that one unfortunately :-( > > > >Ah, silly me. Well, how about MOD_STOP? > > Better, but still not perfect. The problem is that this is the > kind request, not the direct order: We're looking for a sensible > version of: > > MOD_PREPARE_YOURSELF_TO_BE_UNLOADED_BUT_FAIL_IF_YOU_ARE_IN_USE_PLEASE > > :-) MOD_BIKESHED From owner-freebsd-arch@FreeBSD.ORG Thu Jul 8 21:43:45 2004 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 B627916A4CE for ; Thu, 8 Jul 2004 21:43:45 +0000 (GMT) Received: from imap.univie.ac.at (mail.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A44F43D2F for ; Thu, 8 Jul 2004 21:43:45 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from wireless (adslle.cc.univie.ac.at [131.130.102.11]) by imap.univie.ac.at (8.12.10/8.12.10) with ESMTP id i68LhMWN1007320; Thu, 8 Jul 2004 23:43:25 +0200 Date: Thu, 8 Jul 2004 23:43:21 +0200 (CEST) From: Lukas Ertl To: Sam Leffler In-Reply-To: <200407081434.23671.sam@errno.com> Message-ID: <20040708234257.O548@korben.in.tern> References: <7551.1089321028@critter.freebsd.dk> <200407081434.23671.sam@errno.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-204855266-1089323001=:548" X-DCC-ZID-Univie-Metrics: mx7.univie.ac.at 4248; Body=5 Fuz1=5 Fuz2=5 cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= cc: Poul-Henning Kamp cc: arch@FreeBSD.org cc: freebsd-arch@FreeBSD.org Subject: Re: [RFC] kldunload -f argument. 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, 08 Jul 2004 21:43:45 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-204855266-1089323001=:548 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 8 Jul 2004, Sam Leffler wrote: > On Thursday 08 July 2004 02:10 pm, Poul-Henning Kamp wrote: >> In message , >> =3D?iso-8859-1?q?Dag-Erling_Sm=3DF8rgrav?=3D >> >> writes: >>> "Poul-Henning Kamp" writes: >>>> "Dag-Erling_Sm=F8rgrav" writes: >>>>> MOD_SHUTDOWN perhaps? >>>> >>>> We already have that one unfortunately :-( >>> >>> Ah, silly me. Well, how about MOD_STOP? >> >> MOD_PREPARE_YOURSELF_TO_BE_UNLOADED_BUT_FAIL_IF_YOU_ARE_IN_USE_PLEASE >> > MOD_BIKESHED MOD_SHUTUP. cheers, le --=20 Lukas Ertl http://homepage.univie.ac.at/l.ertl/ le@FreeBSD.org http://people.freebsd.org/~le/ --0-204855266-1089323001=:548-- From owner-freebsd-arch@FreeBSD.ORG Thu Jul 8 21:44:08 2004 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 11F7D16A4CF for ; Thu, 8 Jul 2004 21:44:08 +0000 (GMT) Received: from imap.univie.ac.at (mail.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AC0943D55 for ; Thu, 8 Jul 2004 21:44:07 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from wireless (adslle.cc.univie.ac.at [131.130.102.11]) by imap.univie.ac.at (8.12.10/8.12.10) with ESMTP id i68LhMWN1007320; Thu, 8 Jul 2004 23:43:25 +0200 Date: Thu, 8 Jul 2004 23:43:21 +0200 (CEST) From: Lukas Ertl To: Sam Leffler In-Reply-To: <200407081434.23671.sam@errno.com> Message-ID: <20040708234257.O548@korben.in.tern> References: <7551.1089321028@critter.freebsd.dk> <200407081434.23671.sam@errno.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-204855266-1089323001=:548" X-DCC-ZID-Univie-Metrics: mx7.univie.ac.at 4248; Body=5 Fuz1=5 Fuz2=5 cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= cc: Poul-Henning Kamp cc: arch@FreeBSD.org cc: freebsd-arch@FreeBSD.org Subject: Re: [RFC] kldunload -f argument. 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, 08 Jul 2004 21:44:08 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-204855266-1089323001=:548 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 8 Jul 2004, Sam Leffler wrote: > On Thursday 08 July 2004 02:10 pm, Poul-Henning Kamp wrote: >> In message , >> =3D?iso-8859-1?q?Dag-Erling_Sm=3DF8rgrav?=3D >> >> writes: >>> "Poul-Henning Kamp" writes: >>>> "Dag-Erling_Sm=F8rgrav" writes: >>>>> MOD_SHUTDOWN perhaps? >>>> >>>> We already have that one unfortunately :-( >>> >>> Ah, silly me. Well, how about MOD_STOP? >> >> MOD_PREPARE_YOURSELF_TO_BE_UNLOADED_BUT_FAIL_IF_YOU_ARE_IN_USE_PLEASE >> > MOD_BIKESHED MOD_SHUTUP. cheers, le --=20 Lukas Ertl http://homepage.univie.ac.at/l.ertl/ le@FreeBSD.org http://people.freebsd.org/~le/ --0-204855266-1089323001=:548-- From owner-freebsd-arch@FreeBSD.ORG Fri Jul 9 09:54:27 2004 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 8B04F16A4CE for ; Fri, 9 Jul 2004 09:54:27 +0000 (GMT) Received: from anubis.medic.chalmers.se (anubis.medic.chalmers.se [129.16.30.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFCAD43D3F for ; Fri, 9 Jul 2004 09:54:26 +0000 (GMT) (envelope-from b@etek.chalmers.se) Received: from artemis.medic.chalmers.se (artemis.medic.chalmers.se [129.16.30.227]) by anubis.medic.chalmers.se (Postfix) with ESMTP id 74EDE1572; Fri, 9 Jul 2004 11:54:25 +0200 (MEST) Received: by artemis.medic.chalmers.se (Postfix, from userid 4304) id 5F4BC9DA75; Fri, 9 Jul 2004 11:54:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by artemis.medic.chalmers.se (Postfix) with ESMTP id 4901D9DA73; Fri, 9 Jul 2004 11:54:25 +0200 (CEST) Date: Fri, 9 Jul 2004 11:54:25 +0200 (CEST) From: Magnus B{ckstr|m X-X-Sender: b@artemis.medic.chalmers.se To: Poul-Henning Kamp In-Reply-To: <7551.1089321028@critter.freebsd.dk> Message-ID: References: <7551.1089321028@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT cc: arch@freebsd.org Subject: Re: [RFC] kldunload -f argument. 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: Fri, 09 Jul 2004 09:54:27 -0000 On Thu, 8 Jul 2004, Poul-Henning Kamp wrote: >Ä...Å > Better, but still not perfect. The problem is that this is the > kind request, not the direct order: We're looking for a sensible > version of: > > MOD_PREPARE_YOURSELF_TO_BE_UNLOADED_BUT_FAIL_IF_YOU_ARE_IN_USE_PLEASE MOD_QUIESCE -- B From owner-freebsd-arch@FreeBSD.ORG Fri Jul 9 10:37:41 2004 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 AF36616A4CE for ; Fri, 9 Jul 2004 10:37:41 +0000 (GMT) Received: from gw.Awfulhak.org (awfulhak.demon.co.uk [80.177.173.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id E52A343D3F for ; Fri, 9 Jul 2004 10:37:32 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from mail.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.12.11/8.12.11) with SMTP id i69AaC4N021506; Fri, 9 Jul 2004 11:36:23 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Fri, 9 Jul 2004 11:36:12 +0100 From: Brian Somers To: Poul-Henning Kamp Message-Id: <20040709113612.40e3a5c8@dev.lan.Awfulhak.org> In-Reply-To: <6595.1089317548@critter.freebsd.dk> References: <6595.1089317548@critter.freebsd.dk> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on gw.lan.Awfulhak.org cc: arch@freebsd.org Subject: Re: [RFC] kldunload -f argument. 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: Fri, 09 Jul 2004 10:37:41 -0000 On Thu, 08 Jul 2004 22:12:28 +0200, Poul-Henning Kamp wrote: > In the new world order, a new event is introduced MOD_QUIESCE[1]. [.....] > Comments ? I would have thought a MOD_UNQUIESCE would be required too - maybe called MOD_ACTIVATE (but I don't care much about the name). It'd make things more orthogonal. When a module is loaded, it would be in a quiescent state allowing only a MOD_UNLOAD or a MOD_ACTIVATE. It's open for business between MOD_ACTIVATE and MOD_QUIESCE. The idea is that the user can be more active in getting rid of the active module by QUIESCEing it, then running around murdering processes before unloading it. A couple of new flags could be added: kldload -a module don't activate it kldunload -q module only quiesce the module kldstat would need to have a column to show whether a module was quiescent. I'm not sure if kldunload should MOD_ACTIVATE if the MOD_QUIESCE succeeds and the MOD_UNLOAD fails.... just an implementation detail I guess. -- Brian Don't _EVER_ lose your sense of humour ! From owner-freebsd-arch@FreeBSD.ORG Fri Jul 9 10:42:51 2004 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 9043E16A4CE for ; Fri, 9 Jul 2004 10:42:51 +0000 (GMT) Received: from anubis.medic.chalmers.se (anubis.medic.chalmers.se [129.16.30.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0050043D53 for ; Fri, 9 Jul 2004 10:42:51 +0000 (GMT) (envelope-from b@etek.chalmers.se) Received: from artemis.medic.chalmers.se (artemis.medic.chalmers.se [129.16.30.227]) by anubis.medic.chalmers.se (Postfix) with ESMTP id 1FD3816F2 for ; Fri, 9 Jul 2004 12:42:50 +0200 (MEST) Received: by artemis.medic.chalmers.se (Postfix, from userid 4304) id 0B3769DA75; Fri, 9 Jul 2004 12:42:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by artemis.medic.chalmers.se (Postfix) with ESMTP id F30419DA73 for ; Fri, 9 Jul 2004 12:42:49 +0200 (CEST) Date: Fri, 9 Jul 2004 12:42:49 +0200 (CEST) From: Magnus B{ckstr|m X-X-Sender: b@artemis.medic.chalmers.se To: arch@freebsd.org In-Reply-To: Message-ID: References: <7551.1089321028@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [RFC] kldunload -f argument. 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: Fri, 09 Jul 2004 10:42:51 -0000 On Fri, 9 Jul 2004, Magnus B{ckstr|m wrote: > MOD_QUIESCE Duh >:-) // B From owner-freebsd-arch@FreeBSD.ORG Fri Jul 9 10:43:17 2004 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 4412F16A4CE for ; Fri, 9 Jul 2004 10:43:17 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id A70CA43D2F for ; Fri, 9 Jul 2004 10:43:16 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i69AgR8h019894; Fri, 9 Jul 2004 12:42:27 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Somers From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 09 Jul 2004 11:36:12 BST." <20040709113612.40e3a5c8@dev.lan.Awfulhak.org> Date: Fri, 09 Jul 2004 12:42:27 +0200 Message-ID: <19893.1089369747@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: [RFC] kldunload -f argument. 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: Fri, 09 Jul 2004 10:43:17 -0000 In message <20040709113612.40e3a5c8@dev.lan.Awfulhak.org>, Brian Somers writes: >> Comments ? > >I would have thought a MOD_UNQUIESCE would be required too - maybe called >MOD_ACTIVATE (but I don't care much about the name). It'd make things >more orthogonal. > >When a module is loaded, it would be in a quiescent state allowing only a >MOD_UNLOAD or a MOD_ACTIVATE. It's open for business between MOD_ACTIVATE >and MOD_QUIESCE. I'm not sure I see any real-world application for this ? Can you give an example ? Why would you load a module and not use it ? >The idea is that the user can be more active in getting rid of the active >module by QUIESCEing it, then running around murdering processes before >unloading it. I could maybe see a point in this but I cannot remember one single instance where I would have actually done this myself. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Jul 9 11:00:41 2004 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 872B416A4CF for ; Fri, 9 Jul 2004 11:00:41 +0000 (GMT) Received: from gw.Awfulhak.org (awfulhak.demon.co.uk [80.177.173.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 084E543D1F for ; Fri, 9 Jul 2004 11:00:32 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from mail.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.12.11/8.12.11) with SMTP id i69Awwxn021616; Fri, 9 Jul 2004 11:59:12 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Fri, 9 Jul 2004 11:58:58 +0100 From: Brian Somers To: "Poul-Henning Kamp" Message-Id: <20040709115858.47efb729@dev.lan.Awfulhak.org> In-Reply-To: <19893.1089369747@critter.freebsd.dk> References: <20040709113612.40e3a5c8@dev.lan.Awfulhak.org> <19893.1089369747@critter.freebsd.dk> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on gw.lan.Awfulhak.org cc: Brian Somers cc: arch@freebsd.org Subject: Re: [RFC] kldunload -f argument. 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: Fri, 09 Jul 2004 11:00:41 -0000 On Fri, 09 Jul 2004 12:42:27 +0200, "Poul-Henning Kamp" wrote: > In message <20040709113612.40e3a5c8@dev.lan.Awfulhak.org>, Brian Somers writes: > > >> Comments ? > > > >I would have thought a MOD_UNQUIESCE would be required too - maybe called > >MOD_ACTIVATE (but I don't care much about the name). It'd make things > >more orthogonal. > > > >When a module is loaded, it would be in a quiescent state allowing only a > >MOD_UNLOAD or a MOD_ACTIVATE. It's open for business between MOD_ACTIVATE > >and MOD_QUIESCE. > > I'm not sure I see any real-world application for this ? Can you give an > example ? Why would you load a module and not use it ? I can't think of any non-development-environment reasons unless there's room for modules being loaded early to be able to make assumptions about their environment at ACTIVATE time (such as a root filesystem being available). > >The idea is that the user can be more active in getting rid of the active > >module by QUIESCEing it, then running around murdering processes before > >unloading it. > > I could maybe see a point in this but I cannot remember one single instance > where I would have actually done this myself. I guess if_tun.ko springs to mind. I can reliably unload it if I quiesce it, kill all the ``Opened by PID N'' processes, then unload it. The MOD_ACTIVATE becomes more useful when a module ends up in a quiescent state for a long time - the user might want to change their mind instead of only being allowed to [try to] unload the now useless driver. Unless anyone's inspired to make any more pragmatic suggestions along these lines though, it's probably sensible to just skip the ACTIVATE idea :*) -- Brian Don't _EVER_ lose your sense of humour ! From owner-freebsd-arch@FreeBSD.ORG Fri Jul 9 11:11:37 2004 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 3BF5916A4CE for ; Fri, 9 Jul 2004 11:11:37 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D4DB43D1F for ; Fri, 9 Jul 2004 11:11:36 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i69BAeW6020537; Fri, 9 Jul 2004 13:10:40 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Somers From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 09 Jul 2004 11:58:58 BST." <20040709115858.47efb729@dev.lan.Awfulhak.org> Date: Fri, 09 Jul 2004 13:10:40 +0200 Message-ID: <20536.1089371440@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: [RFC] kldunload -f argument. 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: Fri, 09 Jul 2004 11:11:37 -0000 In message <20040709115858.47efb729@dev.lan.Awfulhak.org>, Brian Somers writes: >> >The idea is that the user can be more active in getting rid of the active >> >module by QUIESCEing it, then running around murdering processes before >> >unloading it. >> >> I could maybe see a point in this but I cannot remember one single instance >> where I would have actually done this myself. > >I guess if_tun.ko springs to mind. I can reliably unload it if I quiesce it, >kill all the ``Opened by PID N'' processes, then unload it. Yeah, that would be somewhat similar to the geom case I guess. I'll give kldunload a -q option too. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Jul 9 12:07:00 2004 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 0509C16A4CF for ; Fri, 9 Jul 2004 12:07:00 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61DEB43D4C for ; Fri, 9 Jul 2004 12:06:59 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i69C6vTF021508 for ; Fri, 9 Jul 2004 14:06:57 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 08 Jul 2004 22:12:28 +0200." <6595.1089317548@critter.freebsd.dk> Date: Fri, 09 Jul 2004 14:06:56 +0200 Message-ID: <21507.1089374816@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: [RFC] kldunload -f argument. 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: Fri, 09 Jul 2004 12:07:00 -0000 In message <6595.1089317548@critter.freebsd.dk>, Poul-Henning Kamp writes: > >In an ideal situation, unmount(8) will fail to unload if the >filesystem is in use but the administrator has the option of applying >the -f(orce) option which tells the kernel: "umount at any cost" [3]. > > >We do not have the same flexibility with kldunload(8), and this is >leading to a minor spot of trouble for modules which autoattach to >things, like for instance GEOM classes where it can be very hard if >not impossible to get the module idle from userland so it can be >unloaded. Here is a patch which does this: http://phk.freebsd.dk/patch/kldunload.patch Tests, comments etc welcome! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Jul 9 14:32:35 2004 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 689E116A4CE for ; Fri, 9 Jul 2004 14:32:35 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF85143D49 for ; Fri, 9 Jul 2004 14:32:34 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i69EWGuo032091; Fri, 9 Jul 2004 10:32:16 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i69EWF5c032088; Fri, 9 Jul 2004 10:32:15 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 9 Jul 2004 10:32:15 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Brian Somers In-Reply-To: <20040709115858.47efb729@dev.lan.Awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: Poul-Henning Kamp Subject: Re: [RFC] kldunload -f argument. 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: Fri, 09 Jul 2004 14:32:35 -0000 On Fri, 9 Jul 2004, Brian Somers wrote: > > I'm not sure I see any real-world application for this ? Can you give an > > example ? Why would you load a module and not use it ? > > I can't think of any non-development-environment reasons unless there's > room for modules being loaded early to be able to make assumptions about > their environment at ACTIVATE time (such as a root filesystem being > available). We actually have an example in the form of snd_driver, which forces all the sound modules to load, with the intent that when you unload, the attached ones are left running. We also have a lot of functionality compiled into GENERIC that many people don't use or use only infrequently -- when that functionality is compiled into modules, we frequently automatically load modules during a file system mount, netgraph pieces, etc. When they're no longer in use, they hang around. In a world where we consistently load modules on demand, and those modules remain idle after use, it would be somewhat nice to be able to simply say "Ok, modules no longer needed, please unload yourselves". Note that other systems do this also -- Darwin loads a lot of hardware device drivers early in the boot so that they can detect any devices required for the boot. They then unload the unreferenced ones and allow the user space device pieces to reload them as needed for dynamic hardware arrival. > I guess if_tun.ko springs to mind. I can reliably unload it if I > quiesce it, kill all the ``Opened by PID N'' processes, then unload it. Note that "Opened by PID N" is actually unreliable if the process that opened the tunnel does anything tricky, including fork and exit after opening the tunnel. > The MOD_ACTIVATE becomes more useful when a module ends up in a > quiescent state for a long time - the user might want to change their > mind instead of only being allowed to [try to] unload the now useless > driver. > > Unless anyone's inspired to make any more pragmatic suggestions along > these lines though, it's probably sensible to just skip the ACTIVATE > idea :*) Well, I think it's important to think of all this as a state machine. During a clean and happy module unload, quiesce->unload may be a short jump, but in a less happy unload, it may not be. If we live in a world of auto-loading modules on demand, we can't assume that the loading will happen at a convenient time, so we need to assume it's possible for it to happen while the module is already transitioning from the fully functional state towards the unloaded state. We either need to wait for it to finish, then load the module again, or some other transition scheme that results in the process loading the module not being told "Take a hike". Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-arch@FreeBSD.ORG Fri Jul 9 14:36:16 2004 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 3AE8616A4CE; Fri, 9 Jul 2004 14:36:16 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9488443D39; Fri, 9 Jul 2004 14:36:15 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i69Ea6B6023762; Fri, 9 Jul 2004 16:36:06 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Robert Watson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 09 Jul 2004 10:32:15 EDT." Date: Fri, 09 Jul 2004 16:36:05 +0200 Message-ID: <23761.1089383765@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: Brian Somers cc: arch@freebsd.org Subject: Re: [RFC] kldunload -f argument. 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: Fri, 09 Jul 2004 14:36:16 -0000 In message , Robert Watson writes: > >On Fri, 9 Jul 2004, Brian Somers wrote: > >> > I'm not sure I see any real-world application for this ? Can you give an >> > example ? Why would you load a module and not use it ? >> >> I can't think of any non-development-environment reasons unless there's >> room for modules being loaded early to be able to make assumptions about >> their environment at ACTIVATE time (such as a root filesystem being >> available). > >We actually have an example in the form of snd_driver, which forces all >the sound modules to load, with the intent that when you unload, the >attached ones are left running. We also have a lot of functionality >compiled into GENERIC that many people don't use or use only infrequently >-- when that functionality is compiled into modules, we frequently >automatically load modules during a file system mount, netgraph pieces, >etc. When they're no longer in use, they hang around. In a world where >we consistently load modules on demand, and those modules remain idle >after use, it would be somewhat nice to be able to simply say "Ok, modules >no longer needed, please unload yourselves". Yes, but I found out why this is troublesome: Modules != KLD. One KLD may contain multiple modules. I think that if we need activate/quiesce on a per module interface then we should not do it with KLD granularity. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Jul 9 14:51:57 2004 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 6E0B716A4CE for ; Fri, 9 Jul 2004 14:51:57 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1905043D45 for ; Fri, 9 Jul 2004 14:51:57 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id E2B51ACAFB; Fri, 9 Jul 2004 16:51:54 +0200 (CEST) Date: Fri, 9 Jul 2004 16:51:54 +0200 From: Pawel Jakub Dawidek To: Poul-Henning Kamp Message-ID: <20040709145154.GV12007@darkness.comp.waw.pl> References: <6595.1089317548@critter.freebsd.dk> <21507.1089374816@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xNMMsVvlV1B6vaKr" Content-Disposition: inline In-Reply-To: <21507.1089374816@critter.freebsd.dk> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: arch@freebsd.org Subject: Re: [RFC] kldunload -f argument. 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: Fri, 09 Jul 2004 14:51:57 -0000 --xNMMsVvlV1B6vaKr Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 09, 2004 at 02:06:56PM +0200, Poul-Henning Kamp wrote: +> In message <6595.1089317548@critter.freebsd.dk>, Poul-Henning Kamp write= s: +> > +> >In an ideal situation, unmount(8) will fail to unload if the +> >filesystem is in use but the administrator has the option of applying +> >the -f(orce) option which tells the kernel: "umount at any cost" [3]. +> > +> > +> >We do not have the same flexibility with kldunload(8), and this is +> >leading to a minor spot of trouble for modules which autoattach to +> >things, like for instance GEOM classes where it can be very hard if +> >not impossible to get the module idle from userland so it can be +> >unloaded. +>=20 +> Here is a patch which does this: +>=20 +> http://phk.freebsd.dk/patch/kldunload.patch +>=20 +> Tests, comments etc welcome! Could we implement those new flags as a flags, i.e: #define LINKER_UNLOAD_FORCE 0x01 (only this) So we don't have to create another syscall when we want to add something in the future. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --xNMMsVvlV1B6vaKr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA7rEKForvXbEpPzQRApS7AKDSQ9UNa0jD4ZmZeME2keWuMohJggCg3hY2 orZ/CK86mH3tuRuScG013tM= =3nnK -----END PGP SIGNATURE----- --xNMMsVvlV1B6vaKr-- From owner-freebsd-arch@FreeBSD.ORG Fri Jul 9 15:11:04 2004 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 EE6F816A4CE for ; Fri, 9 Jul 2004 15:11:03 +0000 (GMT) Received: from imap.univie.ac.at (mail.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24A1143D2D for ; Fri, 9 Jul 2004 15:11:03 +0000 (GMT) (envelope-from l.ertl@univie.ac.at) Received: from wireless (adslle.cc.univie.ac.at [131.130.102.11]) by imap.univie.ac.at (8.12.10/8.12.10) with ESMTP id i69FAttT1024662 for ; Fri, 9 Jul 2004 17:10:58 +0200 Date: Fri, 9 Jul 2004 17:10:55 +0200 (CEST) From: Lukas Ertl To: arch@freebsd.org Message-ID: <20040709170834.U581@korben.in.tern> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-DCC-ZID-Univie-Metrics: mail 4249; Body=1 Fuz1=1 Fuz2=1 Subject: USB locking 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: Fri, 09 Jul 2004 15:11:04 -0000 Hello, I've prepared a patch that adds some basic locking primitives to parts of the USB stack (usb.c, uhci.c, ehci.c). Mainly, I've added some mutexes and applied them instead of calls to spl*, wrapped into #ifdef's to stay somewhat compatible with NetBSD. I'd be happy if I could get some review. thanks, le -- Lukas Ertl eMail: l.ertl@univie.ac.at UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://homepage.univie.ac.at/l.ertl/ From owner-freebsd-arch@FreeBSD.ORG Fri Jul 9 21:18:55 2004 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 6E3B216A4CE for ; Fri, 9 Jul 2004 21:18:55 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA36843D48 for ; Fri, 9 Jul 2004 21:18:54 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) i69LIoaI070613 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 9 Jul 2004 23:18:52 +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.10/8.12.10) with ESMTP id i69LILUi029544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jul 2004 23:18:22 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id i69LILxC038097; Fri, 9 Jul 2004 23:18:21 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id i69LIKWR038096; Fri, 9 Jul 2004 23:18:20 +0200 (CEST) (envelope-from ticso) Date: Fri, 9 Jul 2004 23:18:20 +0200 From: Bernd Walter To: Lukas Ertl Message-ID: <20040709211819.GC35892@cicely12.cicely.de> References: <20040709170834.U581@korben.in.tern> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040709170834.U581@korben.in.tern> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.61 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on cicely5.cicely.de cc: arch@freebsd.org Subject: Re: USB locking 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: Fri, 09 Jul 2004 21:18:55 -0000 On Fri, Jul 09, 2004 at 05:10:55PM +0200, Lukas Ertl wrote: > Hello, > > I've prepared a patch that adds some basic locking primitives to parts of > the USB stack (usb.c, uhci.c, ehci.c). Mainly, I've added some mutexes > and applied them instead of calls to spl*, wrapped into #ifdef's to stay > somewhat compatible with NetBSD. I'd be happy if I could get some review. > > Just replacing spl* with locks is not enough to protect code. spls were only required to protect from interrupts, but whithout GIANT we need to protect from multiple userland calls as well. One point that I noticed was that you call usb_transfer_complete with a lock held - this function will run the upcall function of the xfer issuer, which is code you don't know anything about. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-arch@FreeBSD.ORG Fri Jul 9 23:24:00 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D8A9A16A4CE for ; Fri, 9 Jul 2004 23:23:59 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i69NNvNc013379 for ; Fri, 9 Jul 2004 19:23:57 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i69NNucp013378 for arch@FreeBSD.org; Fri, 9 Jul 2004 19:23:56 -0400 (EDT) (envelope-from green) Date: Fri, 9 Jul 2004 19:23:56 -0400 From: Brian Fundakowski Feldman To: arch@FreeBSD.org Message-ID: <20040709232355.GB1626@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: userland firmware loader? 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: Fri, 09 Jul 2004 23:24:00 -0000 I'm writing a driver that uses a 100KB firmware file and could need to read it again, after initialization, to reset the device (or to load more). Since this device is primarily found in CardBus form, I think it makes a lot of sense to be able to get the firmware file at any time but without specific user intervention. Is this something devd should be doing? It wouldn't be very hard to provide an API with somewhat sysctl-like semantics via a device_*() function to return data to userland, and a new newbus device method to recieve data. Does this seem like something that should be done so that many drivers don't waste space in the kernel with firmware images, and don't need firmware via a separate kld module, without having to reimplement it separately in each driver that could use this functionality? Alternately, I could just not be seeing where this kind of functionality already exists. The usio driver in /etc/usbd.conf does something a little like what I want to do, but it's not generic and only does it based on a "load" event instead of a "give me firmware" event. Thanks, -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-arch@FreeBSD.ORG Sat Jul 10 08:38:40 2004 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 6A7A316A4CE; Sat, 10 Jul 2004 08:38:40 +0000 (GMT) Received: from pfepc.post.tele.dk (pfepc.post.tele.dk [195.41.46.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8071343D1F; Sat, 10 Jul 2004 08:38:39 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (0x50c7990f.naenxx7.adsl-dhcp.tele.dk [80.199.153.15]) by pfepc.post.tele.dk (Postfix) with ESMTP id C313C26284E; Sat, 10 Jul 2004 10:38:37 +0200 (CEST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i6A8ca35001421; Sat, 10 Jul 2004 10:38:37 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Fundakowski Feldman From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 09 Jul 2004 19:23:56 EDT." <20040709232355.GB1626@green.homeunix.org> Date: Sat, 10 Jul 2004 10:38:36 +0200 Message-ID: <1420.1089448716@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: userland firmware loader? 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, 10 Jul 2004 08:38:40 -0000 In message <20040709232355.GB1626@green.homeunix.org>, Brian Fundakowski Feldma n writes: >I'm writing a driver that uses a 100KB firmware file and could need to >read it again, after initialization, to reset the device (or to load >more). Since this device is primarily found in CardBus form, I think >it makes a lot of sense to be able to get the firmware file at any time >but without specific user intervention. > >Is this something devd should be doing? I would advocate a generic interface for retrieving firmware from userland. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sat Jul 10 15:16:56 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A7EAC16A4CE; Sat, 10 Jul 2004 15:16:55 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i6AFGrNM018805; Sat, 10 Jul 2004 11:16:53 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i6AFGm80018804; Sat, 10 Jul 2004 11:16:48 -0400 (EDT) (envelope-from green) Date: Sat, 10 Jul 2004 11:16:47 -0400 From: Brian Fundakowski Feldman To: Poul-Henning Kamp Message-ID: <20040710151647.GI1626@green.homeunix.org> References: <20040709232355.GB1626@green.homeunix.org> <1420.1089448716@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1420.1089448716@critter.freebsd.dk> User-Agent: Mutt/1.5.6i cc: arch@freebsd.org Subject: Re: userland firmware loader? 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, 10 Jul 2004 15:16:57 -0000 On Sat, Jul 10, 2004 at 10:38:36AM +0200, Poul-Henning Kamp wrote: > In message <20040709232355.GB1626@green.homeunix.org>, Brian Fundakowski Feldma > n writes: > > >I'm writing a driver that uses a 100KB firmware file and could need to > >read it again, after initialization, to reset the device (or to load > >more). Since this device is primarily found in CardBus form, I think > >it makes a lot of sense to be able to get the firmware file at any time > >but without specific user intervention. > > > >Is this something devd should be doing? > > I would advocate a generic interface for retrieving firmware from userland. What do you think about using the normal devctl_notify(9) for pushing out firmware requests, and having a new device method that receives just a user data pointer and length for it to copyin(9)? It wouldn't be a very symmetrical API, but it seems like a way that might fit it into the current structure the easiest, devd and devctl and newbus. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\