All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jes Sorensen <jes@wildopensource.com>
To: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
Cc: "Christoph Hellwig" <hch@infradead.org>,
	"Andrew Morton" <akpm@osdl.org>,
	"Linus Torvalds" <torvalds@osdl.org>,
	<linux-kernel@vger.kernel.org>,
	"Nakajima, Jun" <jun.nakajima@intel.com>,
	"Mallick, Asit K" <asit.k.mallick@intel.com>
Subject: Re: [Patch] asm workarounds in generic header files
Date: 09 Sep 2003 15:51:05 -0400	[thread overview]
Message-ID: <m3llsxivva.fsf@trained-monkey.org> (raw)
In-Reply-To: <A609E6D693908E4697BF8BB87E76A07A022114C0@fmsmsx408.fm.intel.com>

>>>>> "Suresh" == Siddha, Suresh B <suresh.b.siddha@intel.com> writes:

Suresh> We believe that we are trying to improve the code by
Suresh> localizing the compiler issues (including the ones for gcc3
Suresh> and Intel complier) and by introducing use of compiler
Suresh> intrinsics (e.g. for barrier()).

Hi Suresh,

I actually think this is degrading the code rather then improving
it. Right now the various macros are located in the include/asm-<foo>
directory next to the items where they are used. Moving it all into
one big catch-all assembly file makes it a lot harder to read things
and debug the code. I already took a look at the changes that went
into the ia64 part of the tree and I really think that was a step
backwards.

In terms of compiling the Linux kernel, I will argue that the Intel
compiler is broken if it cannot handle inline assembly. Inline
assembly is just too fundamental a feature for the kernel. This is
totally ignoring the question of whether one should be compiling the
kernel with non-GCC in the first place.

Regards,
Jes

  reply	other threads:[~2003-09-09 19:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-09 19:34 [Patch] asm workarounds in generic header files Siddha, Suresh B
2003-09-09 19:51 ` Jes Sorensen [this message]
2003-09-09 20:25   ` David Mosberger
2003-09-09 20:33     ` Linus Torvalds
2003-09-09 21:16       ` Sam Ravnborg
2003-09-09 23:44       ` David Mosberger
2003-09-10 16:22     ` Jes Sorensen
2003-09-10 17:02       ` David Mosberger
  -- strict thread matches above, loose matches on Subject: below --
2003-09-10  5:51 Nakajima, Jun
2003-09-10  4:50 Siddha, Suresh B
2003-09-10  5:08 ` Andrew Morton
2003-09-09  1:04 Siddha, Suresh B
2003-09-09  2:27 ` Jes Sorensen
2003-09-09  6:40 ` Christoph Hellwig

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=m3llsxivva.fsf@trained-monkey.org \
    --to=jes@wildopensource.com \
    --cc=akpm@osdl.org \
    --cc=asit.k.mallick@intel.com \
    --cc=hch@infradead.org \
    --cc=jun.nakajima@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=suresh.b.siddha@intel.com \
    --cc=torvalds@osdl.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.