On 7/8/19 7:14 AM, Mike Snitzer wrote:
On Fri, Jul 05 2019 at 4:24pm -0400,
Junxiao Bi wrote:
Hi Mike,
Do i make sense on this?
No, you haven't made your chase for this change. Sorry.
Please refine the patch header to _not_ get into context you have from
a vendor kernel. I know you say
> -//typedef int daddr_t; /* or long - check */
> -
> struct solaris_x86_slice {
> unsigned short s_tag; /* ID tag of partition */
> unsigned short s_flag; /* permission flags */
> - longs_start;/* start sector no of partition
On Mon, Jul 08 2019 at 7:54pm -0400,
Junxiao Bi wrote:
> On 7/8/19 7:14 AM, Mike Snitzer wrote:
>
> >On Fri, Jul 05 2019 at 4:24pm -0400,
> >Junxiao Bi wrote:
> >
> >>Hi Mike,
> >>
> >>Do i make sense on this?
> >No, you haven't made your chase for this change. Sorry.
> >
> >Please refine
It was meant to be used daddr_t (which is mostly int, only sparc and
mips have it defined as int), but instead used long.
But musl libc does not define daddr_t as it's deprecated, therefore
use __kernel_daddr_t from .
Signed-off-by: Petr Vorel
---
kpartx/solaris.c | 6 ++
1 file changed, 2
Thanks for the review.
Martin, can you post a rebased version of this patch ?
Thanks,
Christophe
On Mon, Jul 8, 2019 at 4:27 PM Benjamin Marzinski
wrote:
> On Fri, Jun 28, 2019 at 07:29:41PM +, Martin Wilck wrote:
> > From: Martin Wilck
> >
> > Since 4d57b868, DASD partition tables are
On Fri, Jun 28, 2019 at 07:29:41PM +, Martin Wilck wrote:
> From: Martin Wilck
>
> Since 4d57b868, DASD partition tables are only recognized on
> DASD hardware. This turns out to break certain software that works
> e.g. with DASD partition tables on loop devices. The problem that
> 4d57b868
On Fri, Jul 05 2019 at 4:24pm -0400,
Junxiao Bi wrote:
> Hi Mike,
>
> Do i make sense on this?
No, you haven't made your chase for this change. Sorry.
Please refine the patch header to _not_ get into context you have from
a vendor kernel. I know you say this is hard to reproduce, etc. But
