Date: Sat, 9 Feb 2002 22:20:22 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Bruce Evans <bde@zeta.org.au> Cc: John Baldwin <jhb@FreeBSD.ORG>, FreeBSD current users <current@FreeBSD.ORG> Subject: Re: cred stuff.. Message-ID: <Pine.BSF.4.21.0202091952570.8815-100000@InterJet.elischer.org> In-Reply-To: <20020210143057.D6790-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 10 Feb 2002, Bruce Evans wrote: > On Sat, 9 Feb 2002, Julian Elischer wrote: > > > On Sun, 10 Feb 2002, Bruce Evans wrote: > > > > > On Sat, 9 Feb 2002, Julian Elischer wrote: > > > > AST is not always called > > > > and userret is always called, but unfortunatly sometimes multiple times > > > > > > userret() isn't always called either in my version :-). When I'm > > > finished, it will never be called (but I might rename ast() to userret() > > > since it is essenttially the unusual case for the original userret()). > > > > Any chance you could break that bit of your patch out and make it an > > independently committable bit? (and commit it) ? > > It's not really ready. The trouble is that it's a moving target so unless you bit ethe bullet and commit something, you are never ready to commit. > > > I'd like to see SOMETHING always called because I need somewhere to plug > > in the code that the KSE kernel needs to run on KSE processes at the user > > boundary. > > Uh, running it on every crossing of the user boundary would be a > pessimization. How often will it do more than check and find that there > is nothing to do? Just put it in userret() for now, but leave the code > that is already outside of userret still outside. I'd like the OPTION to force an upcall on any traps and syscalls. hardware interrupts are not so interresting but they are at the present time still moments when signals can be delivered and I'd like to have access to all those moments to 'alter' them for KSE purposes should it be a KSE process. > > > > > if someone were to clean up AST/userret > > > > it would be easier, but I am not sure I understand all the issues.. > > > > > > > > Particularly the interraction between ast() and userret() and the various > > > > possible ASTs > > > > > > Logically, it belongs at the end of userret(), > > > > Logically WHAT does? > > The above [context deleted] code (free the ucred on return to user mode). ah. > > > > but I would prefer it > > > to be immediately after all calls to userret() like it almost is now > > > so that I don't have to change it. ast() is not special here, modulo > > > optimizations -- it is just one caller of userret(). Think of it as > > > just an optimization of one case of trap(). > > > > but AST is called (potentially) from all users of doreti() > > which you say includes fast interrupts. > > It currently never has a ucred there. It checks for this, and always > allocates one, and always frees this ucred after it calls userret(). > Your version couldn't do things much differently (if ucreds are freed > at all) without doing some very messy optimizations to keep the ucred > until ast() is called but not keep it when ast() will not be called. I am happy to keep the ucred all teh way into userspace and back so I would never need any such optimisations. Just always keep it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0202091952570.8815-100000>