GEOM mentor request

[symbolics at gmx.com]

Hi hackers,

I have been studying the GEOM documentation and source recently. Is
anyone actively maintaining this subsystem at the moment? I would like
to give it some attention. A few example things I'd like to work on (in
no particular order):

  + Developer manual pages. Rewrite for clarity and add cover some of
    the areas not discussed yet.
  + Add a tutorial on writing GEOM classes, either in the dev handbook
    or within the manual pages.
  + Add missing manual pages so every class has a complete set.
  + Implement various helper methods to reduce code duplication across
    GEOM classes. There seems to be quite a bit of C&P currently.
  + Attack GEOM PR list. Lots of PRs have not progressed in a long time.
  + Implement a method for controlling tasting; there are some cases
    where this would be helpful. Bhyve is one, apparently iSCSI might be
    another.
     + I have a patch that adds connect/disconnect verbs to the DISK
       class. Disconnect sets a flag that disables tasting on the geom
       and withers all but the GEOM's DEV provider. This lets me use a
       raw disc with virtio-blk in Bhyve (with a few other problems).
  + Add regression tests for various classes, especially the ones that
    do not support writing metadata and are therefore more difficult to
    test, LINUX_LVM, for instance.
  + Try and resolve the various XXX comments sitting in the code.
  + Implement new things. Some ideas I have had:
    + GEOM "ERASE" - Rewrite deletes into random writes.
    + GEOM "PLUG" - Persistent version of the connect/disconnect verbs 
      where the flag sits in the class metadata. This might be a cleaner
      approach, rather than adding the verbs to all the existing
      providers.
    + GEOM "TAP" - Allow userspace processes to hook into the GEOM
      API. Intended for debugging and development.
    + GEOM "WCACHE" - Allow you to use small, fast provider as a buffer
      for a larger, slower provider.
    + GEOM DTrace provider. Provide GEOM specific probes to complement
      the IO provider.
  + Probably other bits I can't remember right now.

I need someone more experienced in kernel programming who can review my
ideas and work and guide my patches into the tree. Given that lots of
the GEOM PRs don't seem to be moving, I don't really want to do the work
for it to rot in GNATS.

Any volunteers please get in touch.

Thanks!
--sym