Date: Sat, 5 Oct 2002 17:12:57 -0700 (PDT) From: Hiten Pandya <hitmaster2k@yahoo.com> To: Poul-Henning Kamp <phk@freebsd.org>, current@freebsd.org Subject: Re: The official "GEOM is in the tree" speech. Message-ID: <20021006001257.18272.qmail@web21101.mail.yahoo.com> In-Reply-To: <31691.1033850343@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
PHK, I salute you! -- Hiten --- Poul-Henning Kamp <phk@freebsd.org> wrote: > > 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. __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com 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?20021006001257.18272.qmail>