gm_s86dl.h: Use __kernel_daddr_t for solaris_x86_slice.s_start

[pevik]

musl libc does not define daddr_t as it's deprecated, therefore
use __kernel_daddr_t from <linux/types.h>.

Signed-off-by: Petr Vorel petr.vorel@gmail.com

[pevik]

NOTE: I've sent similar patch to kpartx:
https://www.redhat.com/archives/dm-devel/2019-July/msg00072.html

[pevik]

Suggestion from kpartx is to use fixed size type for s_start [1]. kpartx uses long [2]. Void distro uses int [3] [4] for both projects. What would you prefer?

[1] https://www.redhat.com/archives/dm-devel/2019-July/msg00076.html
[2] https://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=kpartx/solaris.c;h=8c1a971be698675d3c99ef83a5958bc27099c73a;hb=HEAD#l14
[3] https://github.com/void-linux/void-packages/blob/master/srcpkgs/gpart/patches/musl_loff_t.patch
[4] https://github.com/void-linux/void-packages/blob/master/srcpkgs/kpartx/template#L20

[baruch]

Actually the big question is what is the size in bytes for these on-disk structures and not really the specific type I like to use. It would be nice if the code actually worked across architectures (even if only x86-32 and x86-64).

The code as it came down wasn't very good about it but it would be nice to get the changes done in a more sensible way.

[pevik]

Sorry for the delay, agree. I also agree with Christoph Hellwig [1], but I haven't find a correspond solaris source (searching at [2]). It'd be the best to find it and adjust sources according to it. Any change you having a look in solaris sources?

In a meanwhile, my patch for kpartx maintainer merged my changes to use __kernel_daddr_t, which is IMHO wrong. I wonder whether using Linux kernel definition would be correct:

struct solaris_x86_slice {
        __le16 s_tag;           /* ID tag of partition */
        __le16 s_flag;          /* permission flags */
        __le32 s_start;         /* start sector no of partition */
        __le32 s_size;          /* # of blocks in partition */
};

See also my reply [3].

[1] https://www.redhat.com/archives/dm-devel/2019-July/msg00087.html
[2] https://grok.elemental.org/source/
[3] https://www.redhat.com/archives/dm-devel/2019-October/msg00016.html