All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Greg Ungerer <gerg@linux-m68k.org>
Cc: "moderated list:H8/300 ARCHITECTURE"
	<uclinux-h8-devel@lists.sourceforge.jp>,
	linux-xtensa@linux-xtensa.org, Michal Simek <monstr@monstr.eu>,
	linux-c6x-dev@linux-c6x.org,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-riscv@lists.infradead.org, Christoph Hellwig <hch@lst.de>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 08/17] binfmt_flat: consolidate two version of flat_v2_reloc_t
Date: Wed, 26 Jun 2019 08:18:02 +0000	[thread overview]
Message-ID: <CAMuHMdXkMh+pOqPNavmYAhKXTVT12nC5gKc10CJj_CXME+uhWQ@mail.gmail.com> (raw)
In-Reply-To: <f8a61a8e-0469-a9d6-e0a1-01a4619d7363@linux-m68k.org>

Hi Greg,

On Wed, Jun 26, 2019 at 9:23 AM Greg Ungerer <gerg@linux-m68k.org> wrote:
> On 26/6/19 8:29 am, Al Viro wrote:
> > On Thu, Jun 13, 2019 at 09:08:54AM +0200, Christoph Hellwig wrote:
> >> Two branches of the ifdef maze actually have the same content, so merge
> >> them.
> >>
> >> Signed-off-by: Christoph Hellwig <hch@lst.de>
> >> ---
> >>   include/linux/flat.h | 6 ++----
> >>   1 file changed, 2 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/include/linux/flat.h b/include/linux/flat.h
> >> index 2b7cda6e9c1b..19c586b74b99 100644
> >> --- a/include/linux/flat.h
> >> +++ b/include/linux/flat.h
> >> @@ -69,15 +69,13 @@ struct flat_hdr {
> >>   typedef union {
> >>      unsigned long   value;
> >>      struct {
> >> -# if defined(mc68000) && !defined(CONFIG_COLDFIRE)
> >> +#if defined(__LITTLE_ENDIAN_BITFIELD) || \
> >> +    (defined(mc68000) && !defined(CONFIG_COLDFIRE))
> >>              signed long offset : 30;
> >>              unsigned long type : 2;
> >>   # elif defined(__BIG_ENDIAN_BITFIELD)
> >>              unsigned long type : 2;
> >>              signed long offset : 30;
> >> -# elif defined(__LITTLE_ENDIAN_BITFIELD)
> >> -            signed long offset : 30;
> >> -            unsigned long type : 2;
> >>   # else
> >>   #          error "Unknown bitfield order for flat files."
> >>   # endif
> >> --
> >> 2.20.1
> >>
> >
> > FWIW, I wonder if keeping that type is worth bothering.
> > Something like
> > old_reloc(__be32 reloc)
> > {
> >       u32 v = be32_to_cpu(reloc);
> >       int offset, type;
> >
> > #if (defined(mc68000) && !defined(CONFIG_COLDFIRE))
> >       /* old m68k uses unusual format - type is in lower bits of octet 3 */
> >       type = v % 4;
> >       offset = (int)v / 4;
> > #else
> >       /* everything else (including coldfire) has it in upper bits of octet 0 */
> >       type = v >> 30;
> >       offset = (int)(v << 2) >> 2; /* or (v & 0x1fffffff) - (v & 0x20000000) * 4 */
> > #endif
> >       ...
> >
> > and to hell with bitfields, aliasing unions, etc.  Unless I'm misreading
> > the whole thing, that is...  Greg?
>
> I think you are right. This is much better.
> The old mc6800 is the odd one out, the rest have it in network order,
> and this makes that much clearer.

Is that correct for Microblaze, which can be big or little endian?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Greg Ungerer <gerg@linux-m68k.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>, Christoph Hellwig <hch@lst.de>,
	Michal Simek <monstr@monstr.eu>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-c6x-dev@linux-c6x.org,
	"moderated list:H8/300 ARCHITECTURE" 
	<uclinux-h8-devel@lists.sourceforge.jp>,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	linux-riscv@lists.infradead.org,
	Linux-sh list <linux-sh@vger.kernel.org>,
	linux-xtensa@linux-xtensa.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 08/17] binfmt_flat: consolidate two version of flat_v2_reloc_t
Date: Wed, 26 Jun 2019 10:18:02 +0200	[thread overview]
Message-ID: <CAMuHMdXkMh+pOqPNavmYAhKXTVT12nC5gKc10CJj_CXME+uhWQ@mail.gmail.com> (raw)
In-Reply-To: <f8a61a8e-0469-a9d6-e0a1-01a4619d7363@linux-m68k.org>

Hi Greg,

On Wed, Jun 26, 2019 at 9:23 AM Greg Ungerer <gerg@linux-m68k.org> wrote:
> On 26/6/19 8:29 am, Al Viro wrote:
> > On Thu, Jun 13, 2019 at 09:08:54AM +0200, Christoph Hellwig wrote:
> >> Two branches of the ifdef maze actually have the same content, so merge
> >> them.
> >>
> >> Signed-off-by: Christoph Hellwig <hch@lst.de>
> >> ---
> >>   include/linux/flat.h | 6 ++----
> >>   1 file changed, 2 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/include/linux/flat.h b/include/linux/flat.h
> >> index 2b7cda6e9c1b..19c586b74b99 100644
> >> --- a/include/linux/flat.h
> >> +++ b/include/linux/flat.h
> >> @@ -69,15 +69,13 @@ struct flat_hdr {
> >>   typedef union {
> >>      unsigned long   value;
> >>      struct {
> >> -# if defined(mc68000) && !defined(CONFIG_COLDFIRE)
> >> +#if defined(__LITTLE_ENDIAN_BITFIELD) || \
> >> +    (defined(mc68000) && !defined(CONFIG_COLDFIRE))
> >>              signed long offset : 30;
> >>              unsigned long type : 2;
> >>   # elif defined(__BIG_ENDIAN_BITFIELD)
> >>              unsigned long type : 2;
> >>              signed long offset : 30;
> >> -# elif defined(__LITTLE_ENDIAN_BITFIELD)
> >> -            signed long offset : 30;
> >> -            unsigned long type : 2;
> >>   # else
> >>   #          error "Unknown bitfield order for flat files."
> >>   # endif
> >> --
> >> 2.20.1
> >>
> >
> > FWIW, I wonder if keeping that type is worth bothering.
> > Something like
> > old_reloc(__be32 reloc)
> > {
> >       u32 v = be32_to_cpu(reloc);
> >       int offset, type;
> >
> > #if (defined(mc68000) && !defined(CONFIG_COLDFIRE))
> >       /* old m68k uses unusual format - type is in lower bits of octet 3 */
> >       type = v % 4;
> >       offset = (int)v / 4;
> > #else
> >       /* everything else (including coldfire) has it in upper bits of octet 0 */
> >       type = v >> 30;
> >       offset = (int)(v << 2) >> 2; /* or (v & 0x1fffffff) - (v & 0x20000000) * 4 */
> > #endif
> >       ...
> >
> > and to hell with bitfields, aliasing unions, etc.  Unless I'm misreading
> > the whole thing, that is...  Greg?
>
> I think you are right. This is much better.
> The old mc6800 is the odd one out, the rest have it in network order,
> and this makes that much clearer.

Is that correct for Microblaze, which can be big or little endian?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Greg Ungerer <gerg@linux-m68k.org>
Cc: "moderated list:H8/300 ARCHITECTURE"
	<uclinux-h8-devel@lists.sourceforge.jp>,
	linux-xtensa@linux-xtensa.org, Michal Simek <monstr@monstr.eu>,
	linux-c6x-dev@linux-c6x.org,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-riscv@lists.infradead.org, Christoph Hellwig <hch@lst.de>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 08/17] binfmt_flat: consolidate two version of flat_v2_reloc_t
Date: Wed, 26 Jun 2019 10:18:02 +0200	[thread overview]
Message-ID: <CAMuHMdXkMh+pOqPNavmYAhKXTVT12nC5gKc10CJj_CXME+uhWQ@mail.gmail.com> (raw)
In-Reply-To: <f8a61a8e-0469-a9d6-e0a1-01a4619d7363@linux-m68k.org>

Hi Greg,

On Wed, Jun 26, 2019 at 9:23 AM Greg Ungerer <gerg@linux-m68k.org> wrote:
> On 26/6/19 8:29 am, Al Viro wrote:
> > On Thu, Jun 13, 2019 at 09:08:54AM +0200, Christoph Hellwig wrote:
> >> Two branches of the ifdef maze actually have the same content, so merge
> >> them.
> >>
> >> Signed-off-by: Christoph Hellwig <hch@lst.de>
> >> ---
> >>   include/linux/flat.h | 6 ++----
> >>   1 file changed, 2 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/include/linux/flat.h b/include/linux/flat.h
> >> index 2b7cda6e9c1b..19c586b74b99 100644
> >> --- a/include/linux/flat.h
> >> +++ b/include/linux/flat.h
> >> @@ -69,15 +69,13 @@ struct flat_hdr {
> >>   typedef union {
> >>      unsigned long   value;
> >>      struct {
> >> -# if defined(mc68000) && !defined(CONFIG_COLDFIRE)
> >> +#if defined(__LITTLE_ENDIAN_BITFIELD) || \
> >> +    (defined(mc68000) && !defined(CONFIG_COLDFIRE))
> >>              signed long offset : 30;
> >>              unsigned long type : 2;
> >>   # elif defined(__BIG_ENDIAN_BITFIELD)
> >>              unsigned long type : 2;
> >>              signed long offset : 30;
> >> -# elif defined(__LITTLE_ENDIAN_BITFIELD)
> >> -            signed long offset : 30;
> >> -            unsigned long type : 2;
> >>   # else
> >>   #          error "Unknown bitfield order for flat files."
> >>   # endif
> >> --
> >> 2.20.1
> >>
> >
> > FWIW, I wonder if keeping that type is worth bothering.
> > Something like
> > old_reloc(__be32 reloc)
> > {
> >       u32 v = be32_to_cpu(reloc);
> >       int offset, type;
> >
> > #if (defined(mc68000) && !defined(CONFIG_COLDFIRE))
> >       /* old m68k uses unusual format - type is in lower bits of octet 3 */
> >       type = v % 4;
> >       offset = (int)v / 4;
> > #else
> >       /* everything else (including coldfire) has it in upper bits of octet 0 */
> >       type = v >> 30;
> >       offset = (int)(v << 2) >> 2; /* or (v & 0x1fffffff) - (v & 0x20000000) * 4 */
> > #endif
> >       ...
> >
> > and to hell with bitfields, aliasing unions, etc.  Unless I'm misreading
> > the whole thing, that is...  Greg?
>
> I think you are right. This is much better.
> The old mc6800 is the odd one out, the rest have it in network order,
> and this makes that much clearer.

Is that correct for Microblaze, which can be big or little endian?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Greg Ungerer <gerg@linux-m68k.org>
Cc: "moderated list:H8/300 ARCHITECTURE"
	<uclinux-h8-devel@lists.sourceforge.jp>,
	linux-xtensa@linux-xtensa.org, Michal Simek <monstr@monstr.eu>,
	linux-c6x-dev@linux-c6x.org,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-riscv@lists.infradead.org, Christoph Hellwig <hch@lst.de>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 08/17] binfmt_flat: consolidate two version of flat_v2_reloc_t
Date: Wed, 26 Jun 2019 10:18:02 +0200	[thread overview]
Message-ID: <CAMuHMdXkMh+pOqPNavmYAhKXTVT12nC5gKc10CJj_CXME+uhWQ@mail.gmail.com> (raw)
In-Reply-To: <f8a61a8e-0469-a9d6-e0a1-01a4619d7363@linux-m68k.org>

Hi Greg,

On Wed, Jun 26, 2019 at 9:23 AM Greg Ungerer <gerg@linux-m68k.org> wrote:
> On 26/6/19 8:29 am, Al Viro wrote:
> > On Thu, Jun 13, 2019 at 09:08:54AM +0200, Christoph Hellwig wrote:
> >> Two branches of the ifdef maze actually have the same content, so merge
> >> them.
> >>
> >> Signed-off-by: Christoph Hellwig <hch@lst.de>
> >> ---
> >>   include/linux/flat.h | 6 ++----
> >>   1 file changed, 2 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/include/linux/flat.h b/include/linux/flat.h
> >> index 2b7cda6e9c1b..19c586b74b99 100644
> >> --- a/include/linux/flat.h
> >> +++ b/include/linux/flat.h
> >> @@ -69,15 +69,13 @@ struct flat_hdr {
> >>   typedef union {
> >>      unsigned long   value;
> >>      struct {
> >> -# if defined(mc68000) && !defined(CONFIG_COLDFIRE)
> >> +#if defined(__LITTLE_ENDIAN_BITFIELD) || \
> >> +    (defined(mc68000) && !defined(CONFIG_COLDFIRE))
> >>              signed long offset : 30;
> >>              unsigned long type : 2;
> >>   # elif defined(__BIG_ENDIAN_BITFIELD)
> >>              unsigned long type : 2;
> >>              signed long offset : 30;
> >> -# elif defined(__LITTLE_ENDIAN_BITFIELD)
> >> -            signed long offset : 30;
> >> -            unsigned long type : 2;
> >>   # else
> >>   #          error "Unknown bitfield order for flat files."
> >>   # endif
> >> --
> >> 2.20.1
> >>
> >
> > FWIW, I wonder if keeping that type is worth bothering.
> > Something like
> > old_reloc(__be32 reloc)
> > {
> >       u32 v = be32_to_cpu(reloc);
> >       int offset, type;
> >
> > #if (defined(mc68000) && !defined(CONFIG_COLDFIRE))
> >       /* old m68k uses unusual format - type is in lower bits of octet 3 */
> >       type = v % 4;
> >       offset = (int)v / 4;
> > #else
> >       /* everything else (including coldfire) has it in upper bits of octet 0 */
> >       type = v >> 30;
> >       offset = (int)(v << 2) >> 2; /* or (v & 0x1fffffff) - (v & 0x20000000) * 4 */
> > #endif
> >       ...
> >
> > and to hell with bitfields, aliasing unions, etc.  Unless I'm misreading
> > the whole thing, that is...  Greg?
>
> I think you are right. This is much better.
> The old mc6800 is the odd one out, the rest have it in network order,
> and this makes that much clearer.

Is that correct for Microblaze, which can be big or little endian?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-06-26  8:18 UTC|newest]

Thread overview: 96+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-13  7:08 binfmt_flat cleanups and RISC-V support v2 Christoph Hellwig
2019-06-13  7:08 ` Christoph Hellwig
2019-06-13  7:08 ` Christoph Hellwig
2019-06-13  7:08 ` Christoph Hellwig
2019-06-13  7:08 ` [PATCH 01/17] binfmt_flat: remove flat_reloc_valid Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08 ` [PATCH 02/17] binfmt_flat: remove flat_set_persistent Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08 ` [PATCH 03/17] binfmt_flat: provide a default version of flat_get_relocate_addr Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08 ` [PATCH 04/17] binfmt_flat: remove flat_old_ram_flag Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08 ` [PATCH 05/17] binfmt_flat: replace flat_argvp_envp_on_stack with a Kconfig variable Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08 ` [PATCH 06/17] binfmt_flat: remove the uapi <linux/flat.h> header Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08 ` [PATCH 07/17] binfmt_flat: remove the unused OLD_FLAT_FLAG_RAM definition Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08 ` [PATCH 08/17] binfmt_flat: consolidate two version of flat_v2_reloc_t Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-25 22:29   ` Al Viro
2019-06-25 22:29     ` Al Viro
2019-06-25 22:29     ` Al Viro
2019-06-25 22:29     ` Al Viro
2019-06-26  7:23     ` Greg Ungerer
2019-06-26  7:23       ` Greg Ungerer
2019-06-26  7:23       ` Greg Ungerer
2019-06-26  7:23       ` Greg Ungerer
2019-06-26  8:18       ` Geert Uytterhoeven [this message]
2019-06-26  8:18         ` Geert Uytterhoeven
2019-06-26  8:18         ` Geert Uytterhoeven
2019-06-26  8:18         ` Geert Uytterhoeven
2019-06-26 12:14         ` Greg Ungerer
2019-06-26 12:14           ` Greg Ungerer
2019-06-26 12:14           ` Greg Ungerer
2019-06-26 12:14           ` Greg Ungerer
2019-06-13  7:08 ` [PATCH 09/17] binfmt_flat: use fixed size type for the on-disk format Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08 ` [PATCH 10/17] binfmt_flat: add endianess annotations Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08 ` [PATCH 11/17] binfmt_flat: add a ARCH_HAS_BINFMT_FLAT option Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08 ` [PATCH 12/17] binfmt_flat: make support for old format binaries optional Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08 ` [PATCH 13/17] binfmt_flat: provide an asm-generic/flat.h Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:08   ` Christoph Hellwig
2019-06-13  7:09 ` [PATCH 14/17] binfmt_flat: remove the persistent argument from flat_get_addr_from_rp Christoph Hellwig
2019-06-13  7:09   ` Christoph Hellwig
2019-06-13  7:09   ` Christoph Hellwig
2019-06-13  7:09   ` Christoph Hellwig
2019-06-13  7:09 ` [PATCH 15/17] binfmt_flat: move the MAX_SHARED_LIBS definition to binfmt_flat.c Christoph Hellwig
2019-06-13  7:09   ` Christoph Hellwig
2019-06-13  7:09   ` Christoph Hellwig
2019-06-13  7:09   ` Christoph Hellwig
2019-06-14  8:35   ` Sergei Shtylyov
2019-06-14  8:35     ` Sergei Shtylyov
2019-06-14  8:35     ` Sergei Shtylyov
2019-06-14  8:35     ` Sergei Shtylyov
2019-06-13  7:09 ` [PATCH 16/17] binfmt_flat: don't offset the data start Christoph Hellwig
2019-06-13  7:09   ` Christoph Hellwig
2019-06-13  7:09   ` Christoph Hellwig
2019-06-13  7:09   ` Christoph Hellwig
2019-06-13  7:09 ` [PATCH 17/17] riscv: add binfmt_flat support Christoph Hellwig
2019-06-13  7:09   ` Christoph Hellwig
2019-06-13  7:09   ` Christoph Hellwig
2019-06-13  7:09   ` Christoph Hellwig
2019-06-13 23:38 ` binfmt_flat cleanups and RISC-V support v2 Greg Ungerer
2019-06-13 23:38   ` Greg Ungerer
2019-06-13 23:38   ` Greg Ungerer
2019-06-13 23:38   ` Greg Ungerer

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=CAMuHMdXkMh+pOqPNavmYAhKXTVT12nC5gKc10CJj_CXME+uhWQ@mail.gmail.com \
    --to=geert@linux-m68k.org \
    --cc=gerg@linux-m68k.org \
    --cc=hch@lst.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-c6x-dev@linux-c6x.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=monstr@monstr.eu \
    --cc=uclinux-h8-devel@lists.sourceforge.jp \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.