Date: Tue, 26 May 1998 12:59:55 +0200 From: Eivind Eklund <eivind@yes.no> To: Michael Hancock <michaelh@cet.co.jp> Cc: "John S. Dyson" <toor@dyson.iquest.net>, tlambert@primenet.com, fs@FreeBSD.ORG Subject: Re: May 17th UP machine 'panic' Message-ID: <19980526125955.35385@follo.net> In-Reply-To: <Pine.SV4.3.95.980526115437.13413A-100000@parkplace.cet.co.jp>; from Michael Hancock on Tue, May 26, 1998 at 12:05:57PM %2B0900 References: <19980526035319.63753@follo.net> <Pine.SV4.3.95.980526115437.13413A-100000@parkplace.cet.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 26, 1998 at 12:05:57PM +0900, Michael Hancock wrote: > You should review and test as much as you can on your own and demonstrate > some stability before you release it for broader testing. I'm using the Linus definitions for stability of the development kernel (this is an actual quote): "If it compiles, it is good - if it boots, is it perfect" ;-) I'll give it a shakeout - presently it is very, very rough. It is only compiled, not run - and I still haven't done much to make sure that vput() has proc available from a higher level (even though that often is easy to arrange). > > Oh, and can somebody tell me if cnp->cn_proc is generally usable as a > > 'relevant process pointer', or if I should keep it to areas where it > > is already used (as I did in the rough patch)? > > You will often see ... > > struct proc *p = cnp->cn_proc; > > ... if the argument is used frequently in the function. It's usually > relevant, but being consistent is probably fine. I'm thinking more of whether the value of cnp->cn_proc will be the correct process to pass down in all cases. As it is, I haven't used it except where it already was used in the same function. > I won't have time to review it for a while. I need to finish vop_rename, > which is a doozy, and things have gotten busy at work. That's OK. I don't have any particular need for this - I'm doing it because everybody seemed to agree that it was the way to go, but nobody else seemed to want to be bothered with doing it. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980526125955.35385>