From owner-freebsd-hackers Thu May 10 4:53:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (fxp0.halvsten.ip.cybercity.dk [212.242.40.114]) by hub.freebsd.org (Postfix) with ESMTP id F060E37B422 for ; Thu, 10 May 2001 04:53:27 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f4A8H0p75406; Thu, 10 May 2001 10:17:00 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Dima Dorfman Cc: hackers@freebsd.org Subject: Re: Who's cleaning up after disk_clone? In-Reply-To: Your message of "Thu, 10 May 2001 00:40:28 PDT." <20010510074028.847EE3E28@bazooka.unixfreak.org> Date: Thu, 10 May 2001 10:17:00 +0200 Message-ID: <75404.989482620@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010510074028.847EE3E28@bazooka.unixfreak.org>, Dima Dorfman write s: >disk_clone is set as the dev_clone handler by the disk minilayer to >create /dev/disk0sXY devices; however, as far as I can tell, those >devices are never destroyed. For example (/dev is devfs here): This is a subset of a larger problem: How to modules clean up properly. In this case it is slightly more complicated by the fact that the disk minilayer is involved. >So, my questions are: > > - is this a bug? At least the page fault is; and Yes. > - what should be destroying /dev/md0c? The disk-minilayer. We need some to keep track of cloned dev_t's so we can nuke them at various strategic points, havn't gotten to that yet. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message