mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@steeleye.com>
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Summit support for 2.5 - now with subarch! [4/5]
Date: Tue, 15 Oct 2002 10:30:04 -0700	[thread overview]
Message-ID: <200210151730.g9FHU4f03129@localhost.localdomain> (raw)
In-Reply-To: Message from "Martin J. Bligh" <mbligh@aracnet.com>  of "Mon, 14 Oct 2002 16:35:12 PDT." <2001880782.1034613312@[10.10.2.3]>

> > This should really be in a .c file in mach-summit.  I know a single line file 
> > with just a variable in it is a bit strange, but the principle of the subarch 
> > stuff is to have anything subarch specific (which this is) in mach-<subarch>.

> That's pretty pointless for one variable. I think you're taking things
> to ridiculous extremes.

OK, I agree that a single .c file for one variable is very extreme.  I think 
you also would agree with me that if it had been ten variables and an exported 
function then it should live in a separate .c file in the summit specific code.

My concern is that there will come a day when the summit code is enhanced to 
add the extra nine variables and the function.  Since there's nowhere in 
mach-summit to add them, they get added to smpboot.c.  Now we have a go around 
on linux-kernel about why they should be in a separate .c file.

You see the issue: I code by looking at how someone else did it, so if we're 
setting a precedent then it should be done correctly rather than catching and 
correcting a mistake we expect someone will now make.

If you can promise me that summit will never need an extra variable or 
exported function as the code evolves from now until the end of the 
architecture then I can live with summit_x86 in the main line.

James



  parent reply	other threads:[~2002-10-15 17:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-14 23:11 James Bottomley
2002-10-14 23:35 ` Martin J. Bligh
2002-10-15  0:17   ` Martin J. Bligh
2002-10-15 17:30   ` James Bottomley [this message]
2002-10-15 17:32     ` Martin J. Bligh
  -- strict thread matches above, loose matches on Subject: below --
2002-10-14 22:27 Martin J. Bligh

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=200210151730.g9FHU4f03129@localhost.localdomain \
    --to=james.bottomley@steeleye.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®