Re: [PATCH] libfdisk: (gpt) fix attributes endianess

[Ruediger Meier <sweet_f_a@gmx.de>]

On Wednesday 13 May 2015, Karel Zak wrote:
> On Tue, May 12, 2015 at 08:47:40AM +0200, Ruediger Meier wrote:
> > On Monday 11 May 2015, Karel Zak wrote:
> > > On Fri, May 08, 2015 at 01:39:53PM +0200, Ruediger Meier wrote:
> > > > The new libfdisk/gpt test (4a4a0927) discovered that we read
> > > > and write partition attributes wrongly on BE systems.
> > >
> > > It was pretty hidden bug (as the problem was in the both set/get
> > > functions).
> >
> > BTW maybe we could add the new raw attributes interface to sfdisk
> > too. Like
> > $ ./sfdisk --part-attrs img 1 "0x0000000000000001"
> > (and also for stdin text input)
> >
> > This would make sfdisk forward compatible (in case they invent new
> > attributes) and we could remove test_fdisk_gpt helper again.
>
>  Send patch :-)

Ok, but still two questions.

1.
Like the example above I'd like to simply interprete hex numbers as 
bitsets. But because of strtol() hex numbers are working already now. 
This does the same:
$ ./sfdisk --part-attrs img 1 "56"
$ ./sfdisk --part-attrs img 1 "0x38"

I guess nobody ever used hexnumbers for GUID so far but the dumps from 
the future sfdisk would behave strange with sfdisk-2.26. So should we 
use a new prefix "bitset:0x..." or "raw:0x..."? 

2.
Rather than suporting whole bitsets only we could simply allow "any bit" 
to let this just work:
$ ./sfdisk --part-attrs img 1 "23"
unsupported GPT attribute bit '23'

cu,
Rudi