RFC: backporting GEOM to the 4.x branch

[Robert Watson]

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