All of lore.kernel.org
 help / color / mirror / Atom feed
From: Prarit Bhargava <prarit@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH]: Prevent sn2 ptc code from executing on all ia64 subarches
Date: Tue, 13 Dec 2005 15:42:28 +0000	[thread overview]
Message-ID: <439EEBE4.5080203@sgi.com> (raw)
In-Reply-To: <20051121180016.24224.2378.sendpatchset@prarit.boston.redhat.com>

This is sort of a mini-RFC for linux-ia64 -- just to see if anyone objects to 
the solution before I implement it.  I'll throw this out onto lkml after I get 
some input here.

I spent the past day or so looking at a couple of solutions to this problem and 
the only solution that appears viable is to (as stated previously) create new 
initcalls of the form

platform_calltype_initcall(fn,platform)

ex)
	platform_device_initcall(sn_prarit_driver, "sn2");

which would check the platform type prior to loading a kernel.

As it turns out this is a little bit more tricky than I thought as the initcalls 
are placed in a list of initcalls in the .initcall section.

do_initcalls then goes through this list in order to run the various initcalls 
on the list.

Since the macro calltype_initcall is placing the specified function in the 
.initcall list we cannot do

if (ia64_platform_is(foo))
	platform_calltype_initcall(fn,platform)

So I'm modifying my original suggestion.  We will still have

platform_calltype_initcall(fn,platform)

ex)

platform_device_initcall(sn_prarit_driver, IA64_PLATFORM_SN2);

but instead of doing the above wrapper, we would create a new section called 
.platform (name of the section is open to debate) and would traverse both the 
.initcall and the .platform sections at the sametime.

Therefore the could would be something like (this is based off the existing 
do_initcalls)

for (call = __initcall_start, platform = __platform_start;
      call < __initcall_end; call++, platform++) {


	if (platform = __platform_end)
		panic(); /* BUG? size(.platform) != size(!initcall) */

	if (platform && IA64_PLATFORM)
		(*call)();

where platform would be some bitmask that represents the various flavours of 
ia64 that the initcall can run on, and IA64_PLATFORM is set very early in the init.

A few other things:

- by default the value of platform would default to all platforms.

ie)
	device_initcall(sn_prarit_driver)

resolves to

	platform_device_initcall(sn_prarit_driver, IA64_PLATFORM_ALL);

- maybe there should be a runtime warning noting that you are using initcall or 
calltype_initcall on ia64?  (Someone convince me that this is really needed)

- I passed this by an ia64 engineer from HP and he made the comment that the 
nice thing about Linux is that the initcalls on all platforms are handled in 
EXACTLY the same manner.  I sort of agree with his assessment, however, no other 
  arch in Linux can compile a generic kernel and run on all of it's subarches...

Suggestions/comments?  Anyone think this is too much bother for the original 
issue of avoiding

	if (!ia64_platform_is("sn2"))
		return -ENOSYS;

?

P.

  parent reply	other threads:[~2005-12-13 15:42 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-21 18:00 [PATCH]: Prevent sn2 ptc code from executing on all ia64 subarches Prarit Bhargava
2005-12-09 17:11 ` Robin Holt
2005-12-09 17:46 ` Bjorn Helgaas
2005-12-09 17:54 ` Luck, Tony
2005-12-09 18:22 ` Prarit Bhargava
2005-12-09 18:31 ` Prarit Bhargava
2005-12-09 18:38 ` Luck, Tony
2005-12-09 19:41 ` Andreas Schwab
2005-12-13 14:06 ` Prarit Bhargava
2005-12-13 15:10 ` Andreas Schwab
2005-12-13 15:42 ` Prarit Bhargava [this message]
2005-12-13 15:43 ` Prarit Bhargava
2005-12-13 16:03 ` Prarit Bhargava
2005-12-13 17:02 ` Christoph Hellwig
2005-12-13 17:14 ` Bjorn Helgaas
2005-12-13 17:24 ` Luck, Tony
2005-12-13 17:47 ` Bjorn Helgaas
2005-12-13 17:57 ` Luck, Tony
2005-12-13 18:26 ` Prarit Bhargava
2005-12-13 20:27 ` Bjorn Helgaas
2005-12-14 13:17 ` Prarit Bhargava
2005-12-15 14:33 ` Prarit Bhargava
2005-12-15 15:51 ` Bjorn Helgaas
2005-12-15 20:56 ` Prarit Bhargava
2005-12-15 21:08 ` Luck, Tony

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=439EEBE4.5080203@sgi.com \
    --to=prarit@sgi.com \
    --cc=linux-ia64@vger.kernel.org \
    /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.