public inbox for linux-m68k@lists.linux-m68k.org
 help / color / mirror / Atom feed
From: Michael Schmitz <schmitzmic@gmail.com>
To: Finn Thain <fthain@telegraphics.com.au>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	"linux-m68k@vger.kernel.org >> Linux/m68k"
	<linux-m68k@vger.kernel.org>
Subject: Re: [RFC 1/2] nubus: Remove slot zero probe
Date: Sun, 30 Apr 2017 19:45:40 +1200	[thread overview]
Message-ID: <1fe7389e-d574-24ae-b0b2-737320ac5aff@gmail.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1704251427450.1686@nippy.intranet>

Hi Finn,

I don't think anyone would want to replace the macintosh_config struct
with something based on the mainboard ROM data (or ROM data plus
hardcoded model info) at this time. So this code can truly go. Thanks
for making the effort to clean up this code.

Reviewed-by: Michael Schmitz <schmitzmic@gmail.com>

Am 25.04.2017 um 17:19 schrieb Finn Thain:
> 
> On Tue, 25 Apr 2017, Michael Schmitz wrote:
> 
>> Hi Finn,
>>
>> what would the onboard ROM resources be potentially used for? Something 
>> that's not in the config struct or can't be added there because no one 
>> remembers how to build the Penguin booter?
>>
> 
> The hardware specs in the Mac bootinfo data are basically ignored by the 
> kernel. So I think the issue is stuff that's not in the config struct and 
> can't be inferred from the gestalt ID at all. (The macintosh_config struct 
> hinges on the gestalt ID.)
> 
> The bootinfo data should offer a normal gestalt ID... assuming the 
> bootloader can obtain one. Theoretically EMILE could be used with a Mac 
> ROM so old that the _Gestalt trap gives the wrong answer, or is simply 
> not available...
> https://www.fenestrated.net/mac/mirrors/Apple Technotes (As of 2002)/ov/ov_16.html
> 
> I strongly suspect that such machines have no slot zero ROM anyway. And 
> this doesn't apply to Penguin at all, since it can assume System 7.1 and 
> therefore it can get a correct gestalt ID.
> 
> The real problem is, even if the slot zero ROM tells you (say) the VRAM 
> size on one model, a different model might not put that information there. 
> And if we want to handle both cases, why bother with the slot zero ROMs at 
> all?
> 
>> Seeing as the original code (that this patch reverts to) was used while 
>> the Mac port was more widely in use and tested argues strongly in favour 
>> of accepting this patch.
> 
> Right.
> 
> Another strong argument stems from all of the hacks (see below) around the 
> various flaws in the various ROMs. If a large number of Mac models need 
> special workarounds for flaws in their ROMs, you might as well just 
> describe the various exceptions in an array of structs, indexed by gestalt 
> ID number ... which is to reinvent the macintosh_config struct.
> 
>> Whoever wants to ever revive this code will find it in the git 
>> history...
>>
> 
> Or the CVS history, since the decision to remove this code was made there 
> too (many years ago).
> 

  reply	other threads:[~2017-04-30  7:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-23  1:24 [RFC 0/2] mac68k: NuBus fixes Finn Thain
2017-04-23  1:24 ` [RFC 1/2] nubus: Remove slot zero probe David Huggins-Daines
2017-04-25  0:20   ` Finn Thain
2017-04-25  4:11   ` Michael Schmitz
2017-04-25  5:19     ` Finn Thain
2017-04-30  7:45       ` Michael Schmitz [this message]
2017-04-23  1:24 ` [RFC 2/2] nubus: Fix pointer validation Finn Thain
2017-04-25  4:03   ` Michael Schmitz
2017-05-14 20:57 ` [RFC 0/2] mac68k: NuBus fixes Geert Uytterhoeven

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=1fe7389e-d574-24ae-b0b2-737320ac5aff@gmail.com \
    --to=schmitzmic@gmail.com \
    --cc=fthain@telegraphics.com.au \
    --cc=geert@linux-m68k.org \
    --cc=linux-m68k@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox