Date: Fri, 4 Feb 2005 14:03:24 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: ALeine <aleine@austrosearch.net> Cc: freebsd-hackers@freebsd.org Subject: Re: RFC: backporting GEOM to the 4.x branch Message-ID: <Pine.NEB.3.96L.1050204133852.34445A-100000@fledge.watson.org> In-Reply-To: <200502030208.j1328tsX070205@marlena.vvi.at>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 Feb 2005, ALeine wrote: > I would hereby like to politely request your comments on backporting > GEOM to the 4.x branch. I personally would like to see GEOM backported > to the 4.x branch and I would appreciate it if all the developers > (especially Mr. Poul-Henning Kamp) who are familiar with the inner > workings of GEOM could comment on that idea, especially in terms of > giving me a rough overview of what would need to be done and pointing me > in the right direction so I could get started with backporting GEOM > myself. I should mention that I am an experienced programmer, but my > kernel programming experience is limited, I've only done some minor work > on a couple of kernel modules. I guess the interesting question is why to do this? The level of effort would be significant -- probably at least on the order of 6 to 12 man months of work, even by someone who was intimately familiar with all of the dependencies (and that's a non-trivial experience base to have). Wouldn't that time be better invested in correcting whatever defficiency or requirement it is that prevents you from running FreeBSD 5.x? Also, I can assure you that this is not a change that could be merged into the 4.x branch: that branch has both user application and kernel ABI stability requirements, not to mention general stability requirements, which would specifically preclude the level of ABI and other instability necessary to introduce the changes. This expression of concern aside, here are some thoughts directed as much to understanding how GEOM was integrated into 5.x as how to look at backporting: You probably want to begin by reviewing the initial version of GEOM checked in around March of 2002. I'd begin by looking at the src/sys/geom/*.[ch]:1.1 revisions. The vast majority of commits made to the source tree by phk in the window of about 2001 and 2003 are relevant to GEOM in some form, so it may be worth simply skimming through them all. Here are some of the areas that may be important: You'll want to look a fair amount at the change in semantics of 'struct buf' and 'struct bio' phk introduced over a substantial period of time to separate the notion of "buffers" and "in flight I/O requests". Likewise, prior to the actual GEOM integration, there was a fair amount of repacking of the existing disklabel support, how information was shared by the file system with the storage drivers, etc. You'll want look at changes in the semantics of the disk(9) APIs, which storage services use to expose storage facilities to the OS. You'll see that each disk device driver (or, in the case of storage frameworks, the framework -- for example, CAM) was modified to export disk services using GEOM. Another thing you'll want to note is that GEOM really assumes the existence of a devfs, so that new storage facilities can be directly exposed without application intervention. While it's possible to imagine GEOM without devfs, there would need to be a moderate chunk of code that performed device node and device minor/major management for GEOM without devfs. This is because GEOM directly manages device nodes for the storage devices that register with it, so those devices will typically not directly expose device nodes anymore. More recent changes have taught the swap system, file systems, etc, to speak directly to GEOM rather than device nodes, relying on GEOM I/O primitives. This both eliminates the requirement for the Giant lock in the middle of the storage stack, and also allows file systems to speak a consistent API to storage devices to query attributes of those devices, etc. Finally, GEOM assumes the more mature synchronization model present in the 5.x and 6.x kernels, created as part of SMPng. The 4.x kernel synchronization primitives are substantially less mature, and you may find that you need to backport other synchronization work (or substantially modify GEOM) to fit the parts together. Poul-Henning (and more recently, others) have invested a significant amount of work into the development of GEOM and its integration into the OS. In looking at a backport, you'll find that you'll need to basically replay a lot of that work against a 4.x tree, but without the benefit of simultaenous cleanup and development that occurred. If you're going to become an export in GEOM, I think we'd rather you invested that effort to continue to improve and mature the current GEOM in 5.x/6.x, rather than pushing it into the older system. If there are strong reasons not to deploy 5.x in your environment, we'd rather work to fix those problems so that you can use today's GEOM. Thanks, Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1050204133852.34445A-100000>