Date: Sat, 05 Oct 2002 22:39:03 +0200 From: Poul-Henning Kamp <phk@freebsd.org> To: current@freebsd.org Subject: The official "GEOM is in the tree" speech. Message-ID: <31691.1033850343@critter.freebsd.dk>
next in thread | raw e-mail | index | archive | help
Ok, we've reached a milestone which have been on the radar for 8½ years, at least for some of us: GEOM is far from done yet, but unless I have overlooked something, it now meets and in may areas exceeds the capabilities of the previous code, and therefore the time is ripe for the change. Throughout history, there has always been a tradition for rallying the forces with a bit of pep-talk on the eve of a battle, so bear with me if this email gets to be a bit philosphical, but I have some things I want to say to you guys. Times are changing, and the world around us as well. We are no longer a tiny volunteer hobby project, we are now a player in one of the most cut-throat businesses on the planet, next only to narcotics (legal and medical) and weapons. Remember that. Just as well as the rest of the old-timers, I remember how UNIX used to run on 16 bit computers, the simplicity, the elegance and all that which we fell in love with. And I still admire the people who made that possible. Our job, and our challenge, is to continue the tradition they started, standing on their shoulders, reaching forever higher. Freezing time, sticking to traditions, or sticking to standards which try reduce diversity and thereby inovation, is not what the way to do that, neither is sailing out across the wide blue ocean without map and compas. Operating systems, just as people, are a product of their time, and if they stop innovating, fail to develop with the world around then, they will stagnate, and die. Our task is to stay alive and kicking, our challenge is to be ahead of our time and the rest of the pack. And that is the first point I would like to make: If it wasn't for the bikeshed it would produce, I would like to propose that starting right after then 5.0 branch, we rename our HEAD revision from "-current" to "-future". What goes in in current is by nature, and our release cycle, one to two years ahead of our main userbase. We should have in -current what they will be asking for 12 months down the road. Remember that. GEOM is not ahead of the curve like that, infact is is way behind. GEOM should have been put in the tree before ccd(4), before PC98, alpha and in particular before vinum(4). Just like the VFS/Vnode concept or the protocol stack, GEOM is a frame-work, or if you prefer: infrastructure component, meant to make FreeBSD much more able and flexible than it ever were before. Now that GEOM is in the tree, we can clean up the various hacks which were made due to the lack of infrastructure between VNODEs and diskdevices: ccd, vinum, disklabel, diskslice and all that. And we can start to add new functionality using the flexibility and clean architecture it offers us. And that brings me to the next point I want to make: The reason it has taken me 8 years to do it, is mostly that I wanted it done right, not just another "quick hack to get it working", and that meant taking the long way rather than a short cut, and it meant paving a couple of new roads because the old ones would not be able to carry the load. Road-construction is never a nice thing, at least not until it is done and over with, but it is a necessary part of the lifecycle. GEOM has been a long journey for me, its been a long journey for you and for all the users as well. There have been fights, there have been disagreement and there have been a lot of hard work. Most of this could probably have been avoided, one way or another, but likely as not, we will never entirely avoid it in a volounteer project spanning the globe. It worries me however, to realize how tough an ass-hole I have had to be, in order to get to stick to the principle of doing things right, rather than "just hack it in". The best way to destroy FreeBSD in the long term, is to let our infrastructure rot. Nailing a thing on it here, sticking a cute feature there, making an assumption in this place, it all slowly but surely erodes the strength of the infrastructure. We have a number of features in the kernel which have their merits but which carries a heavy cost on our infrastructure. I have probably better give you a random example here to make sure I don't get misunderstood: UFS snapshots are a cool thing, and I love background fsck as much as the next guy. But in order to be able to implement it, Kirk either had to redo the entire buffer cache/VM system to support the primitives he needed, or he could reach down and stick a wedge in between SPECFS and the disk drivers. If modernizing buf/VM wasn't easy before, this certainly wont make it any easier now. But I don't blame Kirk, he was not out to fix our infrastructure, he was out to add snapshots to UFS. But it is a good example of the price we pay for not having our infrastructure in shape: It gets circumvented, and the price for straigthening it out just increased as a result of that. Circumvent, hack around and disregard the infrastructure, if you need to, but do realize, that is what kills software. Remember that. Most people are not interested in working on infrastructure, and I don't blame them. There is little glory in doing so. In fact it's about the most irritating thing you can do to people: redo the floor under their feet. Fortunately we do have some people who care, and a few nutcases like me who really dig it. But even a dedicated handful of infrastructure people will not be able to stem the tide of the cummulative erosion from the rest of the project: You guys cannot escape thinking and caring for our infrastructure, even if you don't have to fix it yourself. So if I may propose a battle-cry as we approach -current after 5.0-R, it would be an adaptation of an sailors rule which is as old as sailing itself: "One hand for you, one hand for the ship". "One hand for your own code, and one hand for the infrastructure". We have several areas of the kernel which is in disrepair, the worst is buf/VM, but there are others as well. We also have people who are willing to look at it, attempt to make it better, and those people are as good as we were when we started, so why shouldn't we let them try ? All I ask of you, is that you don't make their task as hard as mine have been. Remember that too. Finally, on a personal note Peters commitstats say I have been committing to the kernel on average every 16 hours for the last year. It feels that way too. That would not have been possible if it wasn't for the research grant which Robert Watson and NAI Labs managed to secure for all sorts of FreeBSD work. So therefore Robert, whether you like it or not, I would like to dedicate GEOM to you: If it wasn't for your hard work, endless meetings and interminable production of presentations, we would never have gotten this bit of infrastructure straightened out. Thank you very very much! And now is the time for me to shut up, and for time and practical experience will have to judge if I delivered on the promises I made along the way. Thanks for listening, Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. 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?31691.1033850343>