From owner-freebsd-arch Fri Mar 29 13:30:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 7C8F537B419; Fri, 29 Mar 2002 13:30:11 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2TLTke7089672; Fri, 29 Mar 2002 22:29:46 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Julian Elischer Cc: Alfred Perlstein , John Baldwin , arch@FreeBSD.ORG Subject: Re: curthread vs. passing thread pointers around In-Reply-To: Your message of "Fri, 29 Mar 2002 12:41:46 PST." Date: Fri, 29 Mar 2002 22:29:46 +0100 Message-ID: <89671.1017437386@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message , Juli an Elischer writes: >> On a related note: I intend to change the open/close/ioctl interface >> to device drivers from a "struct thread *" to a "struct ucred > >That's probably ok, though I have an uneasy feeling about it.. > >I'd go further and say that you should not even pass that. >anyone needing it can do curthread->td_ucred. Yeah, well, unless you run GEOM where the request may have been queued and you're running in context of a worker thread. (The infinite stacking issue again). >I think we could make a case for CURRENT code that we need not >pass anything at all, but what are we cutting out in th epossible future? That's what I'm afraid off too. There are several things in this, one of which is locking, the other the scale of changes needed to fix up the tree. The simple solution is probably to add three new members to cdevsw{}: sopen, sclose, sioctl (s for simple or something) which doesn't have that final argument at all. Drivers can be converted gradually. Specfs can figure out which version of the method to call, and do locking as/if needed. I really wish we had a compile-time optimized version of KOBJ we could use for devsw... -- 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