All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Paul Burton <paul.burton@mips.com>
Cc: "Arnd Bergmann" <arnd@arndb.de>,
	"Firoz Khan" <firoz.khan@linaro.org>,
	"Hauke Mehrtens" <hauke@hauke-m.de>,
	"Rafał Miłecki" <zajec5@gmail.com>,
	"open list:RALINK MIPS ARCHITECTURE" <linux-mips@linux-mips.org>,
	"Ralf Baechle" <ralf@linux-mips.org>,
	"James Hogan" <jhogan@kernel.org>,
	gregkh <gregkh@linuxfoundation.org>,
	"Philippe Ombredanne" <pombredanne@nexb.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Kate Stewart" <kstewart@linuxfoundation.org>,
	"y2038 Mailman List" <y2038@lists.linaro.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	"Deepa Dinamani" <deepa.kernel@gmail.com>,
	"Marcin Juszkiewicz" <marcin.juszkiewicz@linaro.org>
Subject: Re: [PATCH 0/3] System call table generation support
Date: Thu, 20 Sep 2018 23:09:41 -0700	[thread overview]
Message-ID: <20180921060941.GB13865@infradead.org> (raw)
In-Reply-To: <20180920204833.gpypjjxcmxjupls6@pburton-laptop>

On Thu, Sep 20, 2018 at 08:48:37PM +0000, Paul Burton wrote:
> > Speaking of nanoMIPS, what is your plan for the syscall ABI there?
> > I can see two ways of approaching it:
> > 
> > a) keep all the MIPSisms in the data structures, and just use a subset of
> >     o32 that drops all the obsolete entry points
> > b) start over and stay as close as possible to the generic ABI, using the
> >     asm-generic versions of both the syscall table and the uapi header
> >     files instead of the traditional version.
> 
> We've taken option b in our current downstream kernel & that's what I
> hope we'll get upstream too. There's no expectation that we'll ever need
> to mix pre-nanoMIPS & nanoMIPS ISAs or their associated ABIs across the
> kernel/user boundary so it's felt like a great opportunity to clean up &
> standardise.
> 
> Getting nanoMIPS/p32 support submitted upstream is on my to-do list, but
> there's a bunch of prep work to get in first & of course that to-do list
> is forever growing. Hopefully in the next couple of cycles.

p32 is just the ABI name for nanoMIPS or yet another MIPS ABI?

Either way, І think if there is yet another ABI even on an existing port
we should always aim for the asm-generic syscall table indeed.

Especially for mips where o32 has a rather awkward ABI only explained by
odd decisions more than 20 years ago.

  reply	other threads:[~2018-09-21  6:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-14  8:38 [PATCH 0/3] System call table generation support Firoz Khan
2018-09-14  8:38 ` [PATCH 1/3] mips: Add __NR_syscalls macro in uapi/asm/unistd.h Firoz Khan
2018-09-14  8:38 ` [PATCH 2/3] mips: Add system call table generation support Firoz Khan
2018-09-14  9:58   ` Arnd Bergmann
2018-09-18 11:57     ` Firoz Khan
2018-09-14  8:38 ` [PATCH 3/3] mips: uapi header and system call table file generation Firoz Khan
2018-09-14 12:55   ` kbuild test robot
2018-09-14 12:55     ` kbuild test robot
2018-09-14 12:55     ` kbuild test robot
2018-09-17 17:17 ` [PATCH 0/3] System call table generation support Paul Burton
2018-09-18 14:13   ` Firoz Khan
2018-09-20 14:52   ` Arnd Bergmann
2018-09-20 20:48     ` Paul Burton
2018-09-21  6:09       ` Christoph Hellwig [this message]
2018-09-21 19:32         ` Paul Burton
  -- strict thread matches above, loose matches on Subject: below --
2018-09-14  8:32 Firoz Khan
2018-11-29  6:34 ` Satheesh Rajendran
2018-11-29  6:34   ` Satheesh Rajendran
2018-11-29  8:18   ` Firoz Khan
2018-11-29  8:18     ` Firoz Khan
2018-11-30  7:01     ` Satheesh Rajendran
2018-11-30  7:01       ` Satheesh Rajendran
2018-11-30  9:40       ` Firoz Khan
2018-11-30  9:40         ` Firoz Khan
2018-08-09  5:48 Firoz Khan
2018-08-09  5:36 ` Firoz Khan
2018-08-09  5:27 Firoz Khan

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=20180921060941.GB13865@infradead.org \
    --to=hch@infradead.org \
    --cc=arnd@arndb.de \
    --cc=deepa.kernel@gmail.com \
    --cc=firoz.khan@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hauke@hauke-m.de \
    --cc=jhogan@kernel.org \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=marcin.juszkiewicz@linaro.org \
    --cc=paul.burton@mips.com \
    --cc=pombredanne@nexb.com \
    --cc=ralf@linux-mips.org \
    --cc=tglx@linutronix.de \
    --cc=y2038@lists.linaro.org \
    --cc=zajec5@gmail.com \
    /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.