Date: Mon, 29 Jan 2001 15:13:55 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Brian Somers <brian@Awfulhak.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: Cloned open support Message-ID: <21279.980777635@critter> In-Reply-To: Your message of "Mon, 29 Jan 2001 14:00:43 GMT." <200101291400.f0TE0hY61432@storm.FreeBSD.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?21279.980777635>