util-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Karel Zak <kzak@redhat.com>
To: Davidlohr Bueso <dave@gnu.org>
Cc: Petr Uzel <petr.uzel@suse.cz>, util-linux <util-linux@vger.kernel.org>
Subject: Re: [PATCH 2/3] fdisk: add GPT support
Date: Mon, 1 Oct 2012 09:25:42 +0200	[thread overview]
Message-ID: <20121001072542.GC9064@x2.net.home> (raw)
In-Reply-To: <1348782668.2541.17.camel@offbook>

On Thu, Sep 27, 2012 at 11:51:08PM +0200, Davidlohr Bueso wrote:
> >     - remove global label-specific variables (e.g. gpt ents[])
> 
> Do you mean this?
>  static struct gpt_header *pheader = NULL;
>  static struct gpt_header *bheader = NULL;
>  static struct gpt_entry *ents = NULL;

 yes, and also many others in fdisk{dos,bsd,...}.c files

> If so, the reason for it being global is that it's accessed by the
> fdisk_label struct members, which, as you know, callers/users cannot
> know of label-specific stuff (only fdisk_context).

 Think about it as about a shared library. Maybe one day we will want
 to support work with more contexts of more labels, nested partition
 tables (bsd within dos) etc. And it's also about code readability.

 We have everywhere fdisk_context, so fix this problem should not be a
 problem.

> >     - add '<something>' to fdisk menu to print details about selected
> >       partition (uuid, type uuid, type name, name, etc...)
> > 
> >     - add '<something>' to menu to print details about the partition
> >       table (header, backup header, locations, number of allocated
> >       entries, used entries, offset of entry table and offset and size
> >       of data area, etc.)
> 
> Perhaps in verify?

 Maybe. It would be nice to have a way how to get all possible
 information about PT.

> On another note, I am a bit concerned about dealing with writing changes
> on disks with hybrid MBRs and not transforming it the standard
> protective. We need to be able to do so. Any thoughts are appreciated.

 From my point of view hybrid MBRs is nonsense and it's also against
 UEFI standard (there should be protective MBR and GPT, nothing
 other). I don't see a problem to ignore hybrid MBR at all.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

  reply	other threads:[~2012-10-01  7:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-21 12:03 [PATCH 2/3] fdisk: add GPT support Davidlohr Bueso
2012-09-27 12:03 ` Karel Zak
2012-09-27 21:51   ` Davidlohr Bueso
2012-10-01  7:25     ` Karel Zak [this message]
2012-10-02  8:05       ` Petr Uzel

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=20121001072542.GC9064@x2.net.home \
    --to=kzak@redhat.com \
    --cc=dave@gnu.org \
    --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).