Date: Mon, 27 Dec 1999 19:55:49 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: dg@root.com, freebsd-current@FreeBSD.ORG Subject: Re: Proposed patch to fix VN device (again) Message-ID: <199912280355.TAA36310@apollo.backplane.com> References: <17615.946352895@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
It makes no sense whatsoever to spend hours or days reworking a major subsystem *just* so the swap device can do without a dev_t. I don't really give a damn about /dev/drum -- I said before and I will say again that we can leave it out. But we need to give the swap device its's dev_t back to fix VN because no matter what you believe the *right* thing is to do, (A) nobody has time to rework a major subsystem at this time, and (B) VN was broken when the dev_t was removed, the dev_t should be added back in until someone comes up with a better overall solution. I also strongly believe that polluting *OTHER* subsystems (the buffer chaining code) just to avoid creating a dev_t for SWAP makes even less sense. I do not have the inclination to spend huge amounts of my time reworking the VOP or filesystem buffer subsystem because someone isn't willing to spend a tiny amount of code to partially back out a patch that broke something (VN) in the system, that someone also not themselves willing to spend the time required to rework the system properly. It's that simple. It makes no sense to impose such a requirement on someone else to fix a problem that they did not create. Now I would like to make a clarification: The commit we are talking about was actually one Peter did with the approval of everyone, including me. At the end of November. However, nobody including me realized that the second part of his commit, which was an optimization to remove the 'cruft' of the SWAP device, broke VN. If we had known then that this optimization would break VN it would *NOT* have gone in until the VN problem was fixed. -Matt 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?199912280355.TAA36310>