All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Rockai <prockai@redhat.com>
To: lvm-devel@redhat.com
Subject: [PATCH 02/17] Add supporting functions for metadata areas stored in format instance.
Date: Wed, 26 Jan 2011 14:59:29 +0100	[thread overview]
Message-ID: <877hdrr9la.fsf@twilight.int.mornfall.net.> (raw)
In-Reply-To: <4D3FF9BC.9080401@redhat.com> (Peter Rajnoha's message of "Wed, 26 Jan 2011 11:38:52 +0100")

Peter Rajnoha <prajnoha@redhat.com> writes:
>>> +	void *metadata_areas_index;
>> 
>> I don't currently expect that we would need as much genericity as void *
>> offers (and that we could use a little extra safety). Would an union be
>> better here, with an explicit list of types that can go in?
>> 
>
> Well, my incentive here was to keep this for any future changes so the
> format-specific code can decide and use any type of index we can imagine.
> We have this "metadata.c" layer and then the "format-specific" layer
> underneath that. So adding any new format with a brand new indexing
> scheme that is fine-tuned and suitable for that one new format would
> require breaking the abstraction layer (so defining a new type of index
> used in new format in the "metadata.c" layer above). So my incentive was
> to make the index transparent for the "metadata.c" layer.
>
> (I know, we have these "fid_{add,remove,get}_mda" functions that work
> directly with the index in "metadata.c" now, but that may eventually
> evolve into format-specific "fid" functions later. But since we have
> only one format that actually make real use of the format instance,
> I kept it in that metadata.c layer for now...)
>
> But if we expect to use the same index scheme all the time for all
> possible formats, not changing it too much, then sure, we can use a
> union there... But I'd like to avoid too much editing in the future :)

Well, I think you are deluding yourself about that. Plenty of other such
things is hard-coded all over the place and I am fairly sure adding an
union member is going to be the least of your worries at that point.

I wouldn't say anything if this came for free, but you are obviously
trading code safety and maintainability (which are fairly concrete) for
easier extendability (which is fairly hypothetical). I would opt for the
first, if faced with this kind of a tradeoff. YAGNI (You Aren't Gonna
Need It), anyway.

Yours,
   Petr

PS: If you want to make the format instance actually opaque, you should
move it out of metadata.{h,c} completely, into format_text, and only
have an opaque pointer (void * typedef) in VG/PV.



  reply	other threads:[~2011-01-26 13:59 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-24 11:03 [PATCH 00/17] Add interface to support adding and removing metadata areas on demand (v2) Peter Rajnoha
2011-01-24 11:03 ` [PATCH 01/17] Add pvid parameter to create_instance function Peter Rajnoha
2011-01-25 12:54   ` Petr Rockai
2011-01-24 11:03 ` [PATCH 02/17] Add supporting functions for metadata areas stored in format instance Peter Rajnoha
2011-01-25 13:16   ` Petr Rockai
2011-01-26 10:38     ` Peter Rajnoha
2011-01-26 13:59       ` Petr Rockai [this message]
2011-01-26 14:06       ` Petr Rockai
2011-01-24 11:03 ` [PATCH 03/17] Add struct format_instance *fid field to struct physical_volume Peter Rajnoha
2011-01-25 13:03   ` Petr Rockai
2011-01-24 11:03 ` [PATCH 04/17] Add format_instance support for pv_read Peter Rajnoha
2011-01-25 13:30   ` Petr Rockai
2011-01-26 11:05     ` Peter Rajnoha
2011-01-26 11:12       ` Peter Rajnoha
2011-01-24 11:03 ` [PATCH 05/17] Add attach_existing_mdas parameter to create_instance fn Peter Rajnoha
2011-01-25 14:43   ` Petr Rockai
2011-01-26 13:24     ` Peter Rajnoha
2011-01-24 11:03 ` [PATCH 06/17] Remove useless mdas parameter from PV read functions Peter Rajnoha
2011-01-25 14:44   ` Petr Rockai
2011-01-24 11:03 ` [PATCH 07/17] Add pv_add_metadata_area fn to support adding metadata areas on demand Peter Rajnoha
2011-01-25 14:48   ` Petr Rockai
2011-01-24 11:03 ` [PATCH 08/17] Add pv_remove_metadata_area fn to support removing " Peter Rajnoha
2011-01-28 15:31   ` Petr Rockai
2011-01-24 11:04 ` [PATCH 09/17] Add pv_initialise fn to format_handler interface Peter Rajnoha
2011-01-28 16:31   ` Petr Rockai
2011-01-24 11:04 ` [PATCH 10/17] Add pe_start_locked parameter to pv_create fn Peter Rajnoha
2011-01-28 16:39   ` Petr Rockai
2011-01-24 11:04 ` [PATCH 11/17] Refactor pv_setup to not include the PV initialisation code Peter Rajnoha
2011-01-24 11:04 ` [PATCH 12/17] Remove unused _mda_setup code Peter Rajnoha
2011-01-24 11:04 ` [PATCH 13/17] Cleanup pv_write code to use recent changes in metadata handling interface Peter Rajnoha
2011-01-24 11:04 ` [PATCH 14/17] Use new metadata handling interface to provide better support for PV resize Peter Rajnoha
2011-01-24 11:04 ` [PATCH 15/17] Change vg_convert code to actually work with recent changes in metadata handling interface Peter Rajnoha
2011-01-24 11:04 ` [PATCH 16/17] Fix pvchange -u to " Peter Rajnoha
2011-01-24 16:04   ` Peter Rajnoha
2011-01-24 11:04 ` [PATCH 17/17] Fix pvchange --metadataignore " Peter Rajnoha
2011-01-24 11:12 ` [PATCH 00/17] Add interface to support adding and removing metadata areas on demand (v2) Peter Rajnoha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877hdrr9la.fsf@twilight.int.mornfall.net. \
    --to=prockai@redhat.com \
    --cc=lvm-devel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.