From owner-freebsd-arch Mon Jan 29 11:40:22 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 EF32E37B404 for ; Mon, 29 Jan 2001 11:40:03 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0TJe1K23399; Mon, 29 Jan 2001 20:40:02 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: Peter Wemm , freebsd-arch@FreeBSD.ORG Subject: Re: Cloned open support In-Reply-To: Your message of "Mon, 29 Jan 2001 18:38:24 GMT." <200101291838.f0TIcO203434@hak.lan.Awfulhak.org> Date: Mon, 29 Jan 2001 20:40:01 +0100 Message-ID: <23397.980797201@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101291838.f0TIcO203434@hak.lan.Awfulhak.org>, Brian Somers writes: >> Brian Somers wrote: >> > Hi, >> > >> > I'm considering having a crack at adding support for cloned opens. >> > Before I start, I guess I've got two questions: >> > >> > 1. Is anybody else doing this. >> > >> > 2. Given that I'll need to change the d_open prototype (and >> > thus cdevsw), I'm going to affect every device driver in the >> > tree - although only changing the first arg to a (dev_t) >> > pointer, making things pretty easy to change and not too >> > unexpected for anyone that's written sysv drivers. >> >> Not necessary. dev_t *is* a pointer. Add a flag to the device flags to > >Ach, I was thinking userland-dev_t aka udev_t :-/ Yes, the >prototypes don't need to change :-D It would have to change, it would have to be pointer to pointer to do it the way you propose. >I *guess* it's cleaner to create the new vnode so that the namei >caching side of things can do it's job on the clone device. That was my conclusion as well :-) In addition it allows cloning in some cases which would otherwise not be possible. One I know various people have been seen drooling over is media determined disk names. The driver and label/slice code could read various identifiers off the disk and allow people to do things like: mount /dev/disk/serial/234723842 /mnt -- 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