From owner-freebsd-arch Mon Jan 29 6:14:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id AE9CC37B69C for ; Mon, 29 Jan 2001 06:13:50 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0TEDtK21281; Mon, 29 Jan 2001 15:13:55 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: freebsd-arch@FreeBSD.org Subject: Re: Cloned open support In-Reply-To: Your message of "Mon, 29 Jan 2001 14:00:43 GMT." <200101291400.f0TE0hY61432@storm.FreeBSD.org.uk> Date: Mon, 29 Jan 2001 15:13:55 +0100 Message-ID: <21279.980777635@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101291400.f0TE0hY61432@storm.FreeBSD.org.uk>, Brian Somers writes: >Hmm, I'm not sure I like the idea of a user being able to open >things they can't see beforehand (permissions seem to be one >problem)... Permissions are controled by the driver with the make_dev() call. Later when we get a devd(8) daemon knitted together it will get the chance to set the modes before the open completes. >make_dev() is called during attach as normal. >devfs's vfs lookup routine checks if the cdevsw of the thing it >finds has D_CLONE, and if so asks the owning driver via a new >foo_isclone() cdevsw function if it'd like to change the dev_t >it's about to give back to the namei side of things. The clone function is not tied to a devsw{}, but uses an EVENTHANDLER but otherwise that is what happens already. The reason I have not tied the clone function to the devsw is that it is not strictly a function of any particular minor node, but rather a fully fledged driver method. The cdevsw-> is per device-node (or per minor if you want), the choice of EVENTHANDLER is more a matter of not reinventing the bikeshed once more than one of particular suitability. It does have the right qualities though. Look at some of the various *_clone routines to see how it works, ccd_clone(), pty_clone() and disk_clone() are all very instructive in each their own way. Is there any functionality you need which this cloning doesn't provide you ? -- 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-arch" in the body of the message