util-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Davidlohr Bueso <dave@gnu.org>
To: Karel Zak <kzak@redhat.com>
Cc: Petr Uzel <petr.uzel@suse.cz>, util-linux <util-linux@vger.kernel.org>
Subject: Re: [PATCH 3/3] fdisk: dos: always write mbr
Date: Sun, 25 Nov 2012 20:23:34 -0800	[thread overview]
Message-ID: <1353903814.2945.13.camel@offbook> (raw)
In-Reply-To: <20121114094358.GB1835@x2.net.home>

On Wed, 2012-11-14 at 10:43 +0100, Karel Zak wrote:
> On Wed, Nov 14, 2012 at 12:04:52AM -0800, Davidlohr Bueso wrote:
> > There's no harm when writing the MBR, changed or not. This also
> 

Sorry about the long delay, life has been crazy busy - trying to squeeze
in some util-linux time :-)

> it's harm -- kernel has to parse the new PT, udev has to scan all the
> stuff etc. ... many event and every event is painful if you have
> complicated setup (DM, multipath, udisks, ...).

good point.

> 
> > allows us to get rid of the 'MBRbuffer_changed' global variable.
> 
> It would be nice to add to fdisk_context
> 
>     void *labeldata;
> 
>  and define in fdiskdos.h
> 
>  struct fdisk_dosdata {
>     int write_status;             /* FDISKDOS_WRITE_* flags */
>     ...
>  }
> 
>  enum {
>     FDISKDOS_WRITE_HDR     = (1 << 1)  /* header buffer modified (e.g. ID change) */
>     FDISKDOS_WRITE_PT      = (1 << 2)  /* partition table modified */
>     FDISKDOS_WRITE_EPT     = (1 << 3)  /* any extended partition table modified */
>  };
> 
> (maybe you found better names for the macros and variables :-)
> 
> 
>  than we can add fdisk_is_modified() and is_modified() to fdisk_label
>  driver and remove all label specific junk from fdisk.c.

Yeah, a generic pointer to label-specific data is something that we have
to do. I will take a look at this option for a v2.

Thanks,
Davidlohr



      reply	other threads:[~2012-11-26  4:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-14  8:04 [PATCH 3/3] fdisk: dos: always write mbr Davidlohr Bueso
2012-11-14  9:43 ` Karel Zak
2012-11-26  4:23   ` Davidlohr Bueso [this message]

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=1353903814.2945.13.camel@offbook \
    --to=dave@gnu.org \
    --cc=kzak@redhat.com \
    --cc=petr.uzel@suse.cz \
    --cc=util-linux@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).