Date: Sun, 2 Apr 2000 12:28:37 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Bruce Evans <bde@zeta.org.au>, "Justin T. Gibbs" <gibbs@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_mib.c vfs_bio.c src/sys/sys buf.h Message-ID: <200004021928.MAA50168@apollo.backplane.com> References: <15179.954700892@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:In message <200004021741.KAA49471@apollo.backplane.com>, Matthew Dillon writes:
:
:> I agree with Greg's assessment that 32 bit block numbers are starting to
:> get a bit thin, and given the choice between going to 64 bit block numbers
:> and 64 bit offsets, he (and I) would rather go to 64 bit offsets.
:
:As I said, this is not something I feel strongly about either way,
:there are pro-et-con for all three solutions, but I don't personally
:have a preference. It is also pretty much entirely irelevant to
:the stuff I'm currently doing. In fact I'm trying very hard to
:*not* change the semantics of any more fields than I absolutely
:have to.
:
:> I would also appreciate it, Poul, if you are going to be so rabid about
:> me getting my stuff reviewed,
:
:I'm not rabid about you getting your stuff reviewed, I'm rabid
:about you not committing in a frenzy where you forget to do even
:very basic testing.
Excuse me? Not do Basic testing?
Poul, I have $13,000 worth of machines that I use *ONLY* for testing.
And, frankly, you don't have a leg to stand on... Your commits tend to
break a hellofalot more in the tree then mine do, and for much longer
periods of time since it can often takes weeks for people to get you to
admit that you might have made a mistake. Not only has all my
work been reviewed in the last year, but it is often tested by many
people, not just me. I do buildworlds, often dozens of them, and
regression testing (against previously known bugs that I've fixed) on
virtually all of my patch sets.
You would be well advised, Poul, to look to your own house before you
start screaming about mine.
It is quite true that my work involves very sensitive areas of the kernel
and is more likely to have spectacular failures then someone messing
around changing structural field names in struct buf. The fact that
spectacular failures generally don't occur should tell you something
about the quality of the material I commit.
And, in anycase, this is not about me here... this is about you. *YOU*
need to put your work up for review and outside testing, especially work
done in areas that other developers are actively working on.
:part of this change and you will have all the opportunity you will
:ever want to review huge diffs on my web-page. All the stuff up
:until here have been very mechanical and not really very reviewable,
:the next step is where we get the chance to find bugs in drivers :-)
Your opinion of what is or is not reviewable is not the issue. In
a collaborative project any structural changes at all in any area that
more then one person is working on warrent at least a heads up and
quick review prior to commit. If you don't do it, you aren't playing
with the team.
:I already think I have found two bugs btw: both vn and ccd sets B_INVAL
:on buffers, I don't belive they have any business doing that.
:
:--
:Poul-Henning Kamp FreeBSD coreteam member
:phk@FreeBSD.ORG "Real hackers run -current on their laptop."
:FreeBSD -- It will take a long time before progress goes too far!
Of course they do. Setting B_INVAL is how you get rid of a buffer
(remove it from the cache). B_INVAL is set for cache consistency
control and is absolutely necessary if you don't want illegal garbage
buffers hanging around in the buffer cache.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004021928.MAA50168>