5MP3ugmvtzvndr3Q";
er.org"; posting-account="U2FsdGVkX1/ovxAQHpGlab17k7tXpGz7"
Gecko/20101206 SUSE/3.1.7 Thunderbird/3.1.7
.os2.ecomstation:878 comp.os.os2.beta:34
From: Marty
On 03/04/2011 12:21 PM, Jonathan de Boyne Pollard wrote:
>>>> Can't we learn something from it though? There will be examples of
>>>> tapping into interfaces that our loader currently has no clue about.
>>>>
>>> Once again: It's not an operating system or an operating system
>>> loader. It's replacement firmware. There won't be any "tapping into
>>> interfaces" because it isn't a loader. It's what loaders (the
>>> so-called "payload") run on top of and use.
>>>
>> "The final mainboardinit fragment is mainboard-specific, in C, called
>> romstage.c. For non-cache-as-RAM targets, it is compiled with romcc.
>> It includes and uses other C-code fragments for: [...]"
>>
>> Really? None of that is useful?
>
> Correct. None of it is useful.
Seems at odds with your other statement: "Not without a lot of work."
> What part of "is mainboard-specific" is
> unclear here?
There is a large list of supported motherboards and chipsets on the
page. Such is the nature of low-level hardware interfacing.
>> Just because this stuff is designed to execute from ROM doesn't mean
>> we can't make use of it.
>
> No-one said anything about it executing from ROM being the problem. The
> fact that it's firmware, not an operating system loader, is what makes
> it useless for the purposes of an operating system loader. It's
> firmware. It's not an operating system loader. It's code that does a
> completely different job, at a different layer of abstraction. How many
> times does this point have to be made before it sinks in?
I understood this from the start. I'm not suggesting that someone take
a code snippet and use it directly. I'm saying there's probably some
juicy tidbits that can be learned from it. Nothing more. Maybe not for
a loader... perhaps in a kernel, perhaps for a device driver. If you
don't think so, then your opinion is noted and there's not much point in
arguing further. I'm not trying to convince YOU to use it.
>>> And what's this "our loader" business? I for one don't have any stake
>>> in the IBM OS/2 kernel loader. It isn't mine. It's IBM's, last that I
>>> looked.
>>>
>> The loader that we, who use OS/2, use. If you prefer not to be
>> included in that group, then I won't complain if you don't read
>> yourself into my statement.
>
> You clearly haven't thought that through. Merely using a loader doesn't
> make your the owner of it.
Now you're just being silly and wasting everyone's time. If you thought
I was claiming ownership in some form then you're officially never
welcome in my state of California or my home state of New York.
>>> I know of only three groups outwith IBM that have stakes in
>>> OS/2-clone kernel loaders. The OSFree people have their own loader,
>>> which is (we'retold) based upon the old FreeLDR loader from David C.
>>> Zimmerli (not to be confused with the ReactOS FreeLDR). They're the
>>> only people with an interest in "our loader", and they'll tell you as
>>> I do that firmware source code doesn't show how to *use* firmware APIs.
>>>
>> I'd be mining for data from under every rock if I were them, and
>> hopefully they are not as close-minded as you seem to assume.
>
> This isn't about close-mindedness. This is about having some degree of
> Clue
No... it's really about "I felt like making a snide comment without
honestly looking to see if this could be useful." I don't fault you for
the latter if you have no interest. It's just that there was apparently
enough interest for the former.
Yes, by its manifest, there is nothing here that is appropriate. But in
its implementation details are possibilities.
I'm done.
--
Reverse the parts of the e-mail address to reply by mail.
--- Internet Rex 2.31
* Origin: A noiseless patient Spider (1:261/20.999)
|
