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 -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
