All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: ebiederm@xmission.com, dyoung@redhat.com, bhe@redhat.com,
	vgoyal@redhat.com
Cc: kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, catalin.marinas@arm.com,
	will.deacon@arm.com
Subject: [RFC] arm64: kexec_file_load support
Date: Fri, 1 Jul 2016 14:11:12 +0900	[thread overview]
Message-ID: <20160701051111.GL20774@linaro.org> (raw)

Hi,

I'm not sure whether there is any demand for kexec_file_load
support on arm64, but anyhow I'm working on this and now
my early prototype code does work fine.

There is, however, one essential issue:
While arm64 kernel requires a device tree blob to be set up
correctly at boot time, the current system call API doesn't
have this parameter.
    int kexec_file_load(int kernel_fd, int initrd_fd,
                        unsigned long cmdline_len, const char *cmdline_ptr,
                        unsigned long flags);

Should we invent a new system call, like kexec_file_load2,
and, if so, what kind of interface would be desired?

Thanks,
-Takahiro AKASHI

WARNING: multiple messages have this Message-ID (diff)
From: takahiro.akashi@linaro.org (AKASHI Takahiro)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] arm64: kexec_file_load support
Date: Fri, 1 Jul 2016 14:11:12 +0900	[thread overview]
Message-ID: <20160701051111.GL20774@linaro.org> (raw)

Hi,

I'm not sure whether there is any demand for kexec_file_load
support on arm64, but anyhow I'm working on this and now
my early prototype code does work fine.

There is, however, one essential issue:
While arm64 kernel requires a device tree blob to be set up
correctly at boot time, the current system call API doesn't
have this parameter.
    int kexec_file_load(int kernel_fd, int initrd_fd,
                        unsigned long cmdline_len, const char *cmdline_ptr,
                        unsigned long flags);

Should we invent a new system call, like kexec_file_load2,
and, if so, what kind of interface would be desired?

Thanks,
-Takahiro AKASHI

WARNING: multiple messages have this Message-ID (diff)
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: ebiederm@xmission.com, dyoung@redhat.com, bhe@redhat.com,
	vgoyal@redhat.com
Cc: will.deacon@arm.com, catalin.marinas@arm.com,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: [RFC] arm64: kexec_file_load support
Date: Fri, 1 Jul 2016 14:11:12 +0900	[thread overview]
Message-ID: <20160701051111.GL20774@linaro.org> (raw)

Hi,

I'm not sure whether there is any demand for kexec_file_load
support on arm64, but anyhow I'm working on this and now
my early prototype code does work fine.

There is, however, one essential issue:
While arm64 kernel requires a device tree blob to be set up
correctly at boot time, the current system call API doesn't
have this parameter.
    int kexec_file_load(int kernel_fd, int initrd_fd,
                        unsigned long cmdline_len, const char *cmdline_ptr,
                        unsigned long flags);

Should we invent a new system call, like kexec_file_load2,
and, if so, what kind of interface would be desired?

Thanks,
-Takahiro AKASHI

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

             reply	other threads:[~2016-07-01  5:06 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-01  5:11 AKASHI Takahiro [this message]
2016-07-01  5:11 ` [RFC] arm64: kexec_file_load support AKASHI Takahiro
2016-07-01  5:11 ` AKASHI Takahiro
2016-07-01 15:46 ` Thiago Jung Bauermann
2016-07-01 15:46   ` Thiago Jung Bauermann
2016-07-01 15:46   ` Thiago Jung Bauermann
2016-07-04  6:58   ` AKASHI Takahiro
2016-07-04  6:58     ` AKASHI Takahiro
2016-07-04  6:58     ` AKASHI Takahiro
2016-07-04 22:50     ` Thiago Jung Bauermann
2016-07-04 22:50       ` Thiago Jung Bauermann
2016-07-04 22:50       ` Thiago Jung Bauermann
2016-07-05  8:07       ` AKASHI Takahiro
2016-07-05  8:07         ` AKASHI Takahiro
2016-07-05  8:07         ` AKASHI Takahiro
2016-07-05  1:25     ` Dave Young
2016-07-05  1:25       ` Dave Young
2016-07-05  1:25       ` Dave Young
2016-07-05  8:03       ` AKASHI Takahiro
2016-07-05  8:03         ` AKASHI Takahiro
2016-07-05  8:03         ` AKASHI Takahiro
2016-07-07  6:12         ` Dave Young
2016-07-07  6:12           ` Dave Young
2016-07-07  6:12           ` Dave Young
2016-07-08 14:48           ` Thiago Jung Bauermann
2016-07-08 14:48             ` Thiago Jung Bauermann
2016-07-08 14:48             ` Thiago Jung Bauermann
2016-07-11  3:10             ` Dave Young
2016-07-11  3:10               ` Dave Young
2016-07-11  3:10               ` Dave Young
2016-07-11  7:19             ` AKASHI Takahiro
2016-07-11  7:19               ` AKASHI Takahiro
2016-07-11  7:19               ` AKASHI Takahiro
2016-07-11  8:14               ` Dave Young
2016-07-11  8:14                 ` Dave Young
2016-07-11  8:14                 ` Dave Young

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=20160701051111.GL20774@linaro.org \
    --to=takahiro.akashi@linaro.org \
    --cc=bhe@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=dyoung@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vgoyal@redhat.com \
    --cc=will.deacon@arm.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.