Date: Mon, 20 Mar 2000 01:20:19 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Poul-Henning Kamp <phk@FreeBSD.ORG> Cc: current@FreeBSD.ORG Subject: Re: patches for test / review Message-ID: <200003200920.BAA65798@apollo.backplane.com> References: <5701.953319823@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
:I have two patches up for test at http://phk.freebsd.dk/misc : :I'm looking for reviews and tests, in particular vinum testing :would be nice since Grog is quasi-offline at the moment. : :Poul-Henning : :20000317 BWRITE-STRATEGY.patch : : This patch is machine generated except for the ccd.c and buf.h : parts. : : Rename existing BUF_STRATEGY to DEV_STRATEGY : substitute BUF_WRITE(foo) for VOP_BWRITE(foo->b_vp, foo); : substitute BUF_STRATEGY(foo) for VOP_STRATEGY(foo->b_vp, foo); : : Please test & review. : : :20000317 b_iocmd.patch : : This patch removes B_READ, B_WRITE and B_FREEBUF and replaces : them with a new field in struct buf: b_iocmd. : : B_WRITE was bogusly defined as zero giving rise to obvious : coding mistakes and a lot of code implicitly knew this. : : This patch also eliminates the redundant flag B_CALL, it can : just as efficiently be done by comparing b_iodone to NULL. : : Should you get a panic or drop into the debugger, complaining about : "b_iocmd", don't continue, it is likely to write where it should : have read. : : Please test & review. Kirk and I have already mapped out a plan to drastically update the buffer cache API which will encapsulate much of the state within the buffer cache module. I don't think it makes much sense to make these relatively complex but ultimately not-significantly-improving changes to the buffer cache code at this time. Specifically, I don't think renaming the BUF_WRITE/VOP_BWRITE or BUF_STRATEGY/DEV_STRATEGY stuff is worth doing at all, and while I agree that the idea of separting out the IO command (b_iocmd patch) is a good one, it will be much more effective to do it *AFTER* Kirk and I have separated out the functional interfaces because it will be mostly encapsulated in a single source module. At the current time the extensive nature of the changes have too high a potential for introducing new bugs in a system that has undergone significant debugging and testing and is pretty much known to work properly. -Matt Matthew Dillon <dillon@backplane.com> : :-- :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! : : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-current" in the body of the message : 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?200003200920.BAA65798>