From owner-freebsd-arch Sun Oct 7 15:17:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 7582637B407 for ; Sun, 7 Oct 2001 15:17:06 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f97MH6M70796 for ; Sun, 7 Oct 2001 15:17:06 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 1ABAE3809; Sun, 7 Oct 2001 15:17:06 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Poul-Henning Kamp Cc: Brian Somers , freebsd-arch@FreeBSD.ORG Subject: Re: Cloned open support In-Reply-To: <1359.1002473810@critter.freebsd.dk> Date: Sun, 07 Oct 2001 15:17:05 -0700 From: Peter Wemm Message-Id: <20011007221706.1ABAE3809@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > Uhm, Brian... > > We have cloned devices already... > > What exactly is it that you want to implement ? > > Poul-Henning Devfs name cloning feels hackish to me. Having a seperate EVENTHANDLER() for doing it feels .. just nasty. I'd much rather that we had a d_clone devsw entry and/or a D_CLONE d_flags entry. There are two types of cloning. One is to map some name "/dev/fd0135ds18h" into a device node without having to flood /dev with all possible permutations. The other is to support per-device "select next unit" style opens. Presently these are both kludged into the EVENTHANDLER interface. I think Brian wants to move the second part directly into the open handler like it is done on most other OS's that support cloning. Personally, I would be quite happy if we could do that. I realize why it is done the way it is done now though. VOP_LOOKUP() having to return a unique vnode for the device is a pain. (which is why the clone is done during lookup, so that the correct vnode is found and available). But understanding why doesn't mean that I dont wish that it could be different. :-) Doug mentions the hack in dev/streams/streams.c: td->td_dupfd = fd; return ENXIO; .. this is nasty. :-) I think the SVR4 clone driver uses something like this. It causes the original namei / open attempt to fail (thus releasing the "common" vnode) and then switching over to the *real* file/vnode at the last minute. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message