Date: Sun, 10 Feb 2002 14:45:44 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Julian Elischer <julian@elischer.org> Cc: John Baldwin <jhb@FreeBSD.ORG>, FreeBSD current users <current@FreeBSD.ORG> Subject: Re: cred stuff.. Message-ID: <20020210143057.D6790-100000@gamplex.bde.org> In-Reply-To: <Pine.BSF.4.21.0202091719370.8815-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. > > > 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). > > 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 prefer explicit comparisions with NULL and 0 except for booleans. > > Actually so do I though in this case I'm thinking of "if (x != NULL)" > as "if X is valid" > > which comes out of my fingers as "if (x)" (validity is a boolean) > > Sometimes I've thought about something like: > > if (ISVALID(x)) > > where ISVALID could be different on different architectures, > (e.g. ia64 actually has support for item validity) > > but it's not worth it and doesn't gain anything except bloat. It also gains obfuscation. Bruce 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?20020210143057.D6790-100000>