Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Testing an OS
37 views
Skip to first unread message
James Harris
May 8, 2013, 10:13:59 AM5/8/13
to
Testing is boring, right? ... Right!
Testing our programs can be tedious.
As a principle
==============
I have long been a fan of the *principle* of having a suite of tests
for a given software or hardware project. The benefits of having such
a test suite include
* Verifies the effect of the unit under test
* Saves programmer time:
- the machine, not the programmer, tests the program
- a test defined once can be run repeatedly
* Helps the programmer in other ways
- checks that enhancements haven't broken something
- i.e. regression testing
- gives confidence in the initial code and in any changes
- mechanises something which is boring for a person to do
* Provides an extra level of verification
- when planning, helps to see a slightly higher level
- carries out a cross-check of test and program
- either may be faulty; checks one against the other
Downsides? Of course, tests need to be written in the first place.
That can cost a significant amount of time and the amount of testing
code can be greater than the amount of code being tested.
Nevertheless, for most projects, being able to run those tests
repeatedly has to far outweigh the cost of writing the test code in
the first place.
Writing tests is still boring (though not as much as having to carry
out all the tests by hand) but a test once written should need
relatively little maintenance.
Not only but also
=================
I recently came across or was reminded of another potential benefit of
having a test suite, namely that if the tests are written before the
code they are to test they can be used to guide the development of the
code. This is the idea of test-driven development.
http://en.wikipedia.org/wiki/Test-driven_development
In this case a complete suite of tests *define* what the product is to
do before the product is developed. This can help with development of
the idea and help us focus on what the product's effect should be.
And, of course, those tests can remain with the product for years to
come, being used to verify that changes do not break something that
once worked. That's got to be a big benefit, right!
So to the OS
============
Given the above, do any of you guys have an interest in discussing
whether such a set of ideas could be feasibly applied to development
of our OS developments?
As, I hope, illustrated above the principle has much to recommend it
but it is practical?
Even if you have an interest only in the principle I would welcome
your feedback. I have some more to add - some of it exciting, IMHO, if
you have an interest in setting up tests for your OS - but won't add
more to your reading matter just yet.
James
Testing our programs can be tedious.
As a principle
==============
I have long been a fan of the *principle* of having a suite of tests
for a given software or hardware project. The benefits of having such
a test suite include
* Verifies the effect of the unit under test
* Saves programmer time:
- the machine, not the programmer, tests the program
- a test defined once can be run repeatedly
* Helps the programmer in other ways
- checks that enhancements haven't broken something
- i.e. regression testing
- gives confidence in the initial code and in any changes
- mechanises something which is boring for a person to do
* Provides an extra level of verification
- when planning, helps to see a slightly higher level
- carries out a cross-check of test and program
- either may be faulty; checks one against the other
Downsides? Of course, tests need to be written in the first place.
That can cost a significant amount of time and the amount of testing
code can be greater than the amount of code being tested.
Nevertheless, for most projects, being able to run those tests
repeatedly has to far outweigh the cost of writing the test code in
the first place.
Writing tests is still boring (though not as much as having to carry
out all the tests by hand) but a test once written should need
relatively little maintenance.
Not only but also
=================
I recently came across or was reminded of another potential benefit of
having a test suite, namely that if the tests are written before the
code they are to test they can be used to guide the development of the
code. This is the idea of test-driven development.
http://en.wikipedia.org/wiki/Test-driven_development
In this case a complete suite of tests *define* what the product is to
do before the product is developed. This can help with development of
the idea and help us focus on what the product's effect should be.
And, of course, those tests can remain with the product for years to
come, being used to verify that changes do not break something that
once worked. That's got to be a big benefit, right!
So to the OS
============
Given the above, do any of you guys have an interest in discussing
whether such a set of ideas could be feasibly applied to development
of our OS developments?
As, I hope, illustrated above the principle has much to recommend it
but it is practical?
Even if you have an interest only in the principle I would welcome
your feedback. I have some more to add - some of it exciting, IMHO, if
you have an interest in setting up tests for your OS - but won't add
more to your reading matter just yet.
James
Rod Pemberton
May 9, 2013, 6:23:16 PM5/9/13
to
"James Harris" <james.h...@gmail.com> wrote in message
news:5edc0d2b-bca5-459f...@a6g2000vbf.googlegroups.com...
> Testing our programs can be tedious.
>
> As a principle
> ==============
>
> I have long been a fan of the *principle* of having a suite of
> tests for a given software or hardware project. The benefits
> of having such a test suite include
>
> * Verifies the effect of the unit under test
> * Saves programmer time:
> - the machine, not the programmer, tests the program
> - a test defined once can be run repeatedly
> * Helps the programmer in other ways
> - checks that enhancements haven't broken something
> - i.e. regression testing
> - gives confidence in the initial code and in any changes
> - mechanises something which is boring for a person to do
> * Provides an extra level of verification
> - when planning, helps to see a slightly higher level
> - carries out a cross-check of test and program
> - either may be faulty; checks one against the other
>
> Downsides? Of course, tests need to be written in the first
> place.
...
> That can cost a significant amount of time and the amount of
> testing code can be greater than the amount of code being
> tested.
Yes.
> Nevertheless, for most projects, being able to run those tests
> repeatedly has to far outweigh the cost of writing the test code
> in the first place.
>
Sometimes.
> Writing tests is still boring (though not as much as having to
> carry out all the tests by hand)
Yes.
> but a test once written should need
> relatively little maintenance.
Maybe.
> Not only but also
> =================
>
> I recently came across or was reminded of another potential
> benefit of having a test suite, namely that if the tests are
> written before the code they are to test they can be used to
> guide the development of the code. This is the idea of
> test-driven development.
>
> [link]
Ok. Sarcasm, "guide" vs. "constrained"...
I just skimmed the start of the article. It seems similar to
other development concepts: design-by-contract, unit testing, code
refactoring, Agile software management, object oriented
programming, etc. (all are on Wikipedia, if you're interested...)
> In this case a complete suite of tests *define* what the product
> is to do before the product is developed. This can help with
> development of the idea and help us focus on what the product's
> effect should be. And, of course, those tests can remain with
> the product for years to come, being used to verify that changes
> do not break something that once worked. That's got to be a big
> benefit, right!
>
Yes, it can be. However, it won't catch errors without a test
for it... I.e., this implies much prescience or experience or
overkill on the part of the test-suite creator.
I'm not sure that this is suitable for all products and code ...
E.g., you don't get to chose what BIOS your end-user uses. You
can't test it. You can't be sure your BIOS testsuite correctly
emulates it or your application correctly uses it. Ditto for
CD-ROM drive, motherboard chipset, audio chipset, or VESA video
BIOS, etc. I.e., you have to code to a well defined software or
hardware interface. If their equipment is not 100% compatible, it
becomes their problem, unfortunately. That even plagues MS with
their OS installs for Win9x, WinXP ,etc. They try to do too much,
use too many new hardware features, and find and install all
hardware upfront. They could just install keyboard, mouse, video,
and boot drive. Then, once Windows is running, let a Windows app
run to detect, install, reconfigure, and upgrade everything else.
Instead, you get near infinite reboots, one for every time their
installer chokes on something...
> So to the OS
> ============
>
> Given the above, do any of you guys have an interest in
> discussing whether such a set of ideas could be feasibly
> applied to development of our OS developments?
>
At the moment, I can't see where or how exactly I'd apply it...
It could be useful somewhere. I tend to do the "program it, test
it, fix it, repeat" approach. It's simple, easy, quick. I've
only seen a few instances where complications arose later on. For
a few parts of my OS, I first wrote DOS code in C that I could
test with DOS. Later, I merged and rewrote (perhaps
refactored...?) the code to fit into my OS.
What I did want, and perhaps still do, was a BIOS function tester
which tests all critical BIOS functions and hardware support for
OS needs or bootloader needs, e.g., e820h, a20, Int 13h
functionality, VGA registers available, VESA 2.0 present?, PM BIOS
interfaces (VESA, PCI), etc. Of course, I'd construct a much
larger list of function calls from the BIOS calls used by
bootloaders and installers for MS products, FreeBSD, Linux, etc.
> As, I hope, illustrated above the principle has much to
> recommend it but it is practical?
It can be done. With one company I worked for, we coded and
manually tested. After that, we ran an entire days worth of
incoming data through the system to see if there were any errant
changes in the final data. If that was fine, we ran other days
until everyone of note was reasonably confident no mistakes had
been made. The input and output data were "sufficient" to ensure
"correctness" of the system's operation. Of course, it was
important to them financially, they had many programmers, and so
they implemented such a test platform.
So far, the scope of your desire to use this (or similar)
concept(s) is unlimited. Where did you plan on using it? There
are likely places and situations where it'll work very well, and
others not so much. Things that are outside your control, or
outside your application space could be problematic. How much
uniformity or coherence or correlation do you expect between the
OSes this test-suite could test? There must be some commonality.
E.g., in DOS you can insert a small TSR to trap all calls to the
BIOS, but you can't do that with Windows or Linux. Of course,
they probably aren't using BIOS so much. But, if you wanted to do
so for them, you'd have to code a device driver or something
similar. Hypothetically, you might introduce problems with the
way the OS is supposed to function by creating such a driver,
e.g., glitch, crash, hang.
> Even if you have an interest only in the principle I would
> welcome your feedback. I have some more to add - some
> of it exciting, IMHO, if you have an interest in setting up
> tests for your OS - but won't add more to your reading matter
> just yet.
>
At this point, my stalled OS project can't execute any apps. It
could be compiled in if it's coded in C or assembly. I'm not sure
exactly what I could test though... Everything I coded for the OS
proper, was tested at some point. I know a few pieces of code are
broken for different hardware. Some OSes are likely to be
advanced and will have file I/O, hardware, graphics, etc while
others are likely to be bare-bones and incomplete, like mine.
Personally, I prefer stand-alone code that compiles/assembles and
executes under a "low-overhead" OS like DOS. Of course, that
wouldn't really test my OS... It's also good if it can be
compiled under a few OSes. Boot-up code which tests things is
good too. However, no OS is loaded yet either...
Rod Pemberton
news:5edc0d2b-bca5-459f...@a6g2000vbf.googlegroups.com...
> Testing is boring, right? ... Right!
>
Is this you volunteering? ;-)
>
> Testing our programs can be tedious.
>
> As a principle
> ==============
>
> I have long been a fan of the *principle* of having a suite of
> tests for a given software or hardware project. The benefits
> of having such a test suite include
>
> * Verifies the effect of the unit under test
> * Saves programmer time:
> - the machine, not the programmer, tests the program
> - a test defined once can be run repeatedly
> * Helps the programmer in other ways
> - checks that enhancements haven't broken something
> - i.e. regression testing
> - gives confidence in the initial code and in any changes
> - mechanises something which is boring for a person to do
> * Provides an extra level of verification
> - when planning, helps to see a slightly higher level
> - carries out a cross-check of test and program
> - either may be faulty; checks one against the other
>
> Downsides? Of course, tests need to be written in the first
> place.
> That can cost a significant amount of time and the amount of
> testing code can be greater than the amount of code being
> tested.
> Nevertheless, for most projects, being able to run those tests
> repeatedly has to far outweigh the cost of writing the test code
> in the first place.
>
> Writing tests is still boring (though not as much as having to
> carry out all the tests by hand)
> but a test once written should need
> relatively little maintenance.
> Not only but also
> =================
>
> I recently came across or was reminded of another potential
> benefit of having a test suite, namely that if the tests are
> written before the code they are to test they can be used to
> guide the development of the code. This is the idea of
> test-driven development.
>
Ok. Sarcasm, "guide" vs. "constrained"...
I just skimmed the start of the article. It seems similar to
other development concepts: design-by-contract, unit testing, code
refactoring, Agile software management, object oriented
programming, etc. (all are on Wikipedia, if you're interested...)
> In this case a complete suite of tests *define* what the product
> is to do before the product is developed. This can help with
> development of the idea and help us focus on what the product's
> effect should be. And, of course, those tests can remain with
> the product for years to come, being used to verify that changes
> do not break something that once worked. That's got to be a big
> benefit, right!
>
for it... I.e., this implies much prescience or experience or
overkill on the part of the test-suite creator.
I'm not sure that this is suitable for all products and code ...
E.g., you don't get to chose what BIOS your end-user uses. You
can't test it. You can't be sure your BIOS testsuite correctly
emulates it or your application correctly uses it. Ditto for
CD-ROM drive, motherboard chipset, audio chipset, or VESA video
BIOS, etc. I.e., you have to code to a well defined software or
hardware interface. If their equipment is not 100% compatible, it
becomes their problem, unfortunately. That even plagues MS with
their OS installs for Win9x, WinXP ,etc. They try to do too much,
use too many new hardware features, and find and install all
hardware upfront. They could just install keyboard, mouse, video,
and boot drive. Then, once Windows is running, let a Windows app
run to detect, install, reconfigure, and upgrade everything else.
Instead, you get near infinite reboots, one for every time their
installer chokes on something...
> So to the OS
> ============
>
> Given the above, do any of you guys have an interest in
> discussing whether such a set of ideas could be feasibly
> applied to development of our OS developments?
>
It could be useful somewhere. I tend to do the "program it, test
it, fix it, repeat" approach. It's simple, easy, quick. I've
only seen a few instances where complications arose later on. For
a few parts of my OS, I first wrote DOS code in C that I could
test with DOS. Later, I merged and rewrote (perhaps
refactored...?) the code to fit into my OS.
What I did want, and perhaps still do, was a BIOS function tester
which tests all critical BIOS functions and hardware support for
OS needs or bootloader needs, e.g., e820h, a20, Int 13h
functionality, VGA registers available, VESA 2.0 present?, PM BIOS
interfaces (VESA, PCI), etc. Of course, I'd construct a much
larger list of function calls from the BIOS calls used by
bootloaders and installers for MS products, FreeBSD, Linux, etc.
> As, I hope, illustrated above the principle has much to
> recommend it but it is practical?
manually tested. After that, we ran an entire days worth of
incoming data through the system to see if there were any errant
changes in the final data. If that was fine, we ran other days
until everyone of note was reasonably confident no mistakes had
been made. The input and output data were "sufficient" to ensure
"correctness" of the system's operation. Of course, it was
important to them financially, they had many programmers, and so
they implemented such a test platform.
So far, the scope of your desire to use this (or similar)
concept(s) is unlimited. Where did you plan on using it? There
are likely places and situations where it'll work very well, and
others not so much. Things that are outside your control, or
outside your application space could be problematic. How much
uniformity or coherence or correlation do you expect between the
OSes this test-suite could test? There must be some commonality.
E.g., in DOS you can insert a small TSR to trap all calls to the
BIOS, but you can't do that with Windows or Linux. Of course,
they probably aren't using BIOS so much. But, if you wanted to do
so for them, you'd have to code a device driver or something
similar. Hypothetically, you might introduce problems with the
way the OS is supposed to function by creating such a driver,
e.g., glitch, crash, hang.
> Even if you have an interest only in the principle I would
> welcome your feedback. I have some more to add - some
> of it exciting, IMHO, if you have an interest in setting up
> tests for your OS - but won't add more to your reading matter
> just yet.
>
could be compiled in if it's coded in C or assembly. I'm not sure
exactly what I could test though... Everything I coded for the OS
proper, was tested at some point. I know a few pieces of code are
broken for different hardware. Some OSes are likely to be
advanced and will have file I/O, hardware, graphics, etc while
others are likely to be bare-bones and incomplete, like mine.
Personally, I prefer stand-alone code that compiles/assembles and
executes under a "low-overhead" OS like DOS. Of course, that
wouldn't really test my OS... It's also good if it can be
compiled under a few OSes. Boot-up code which tests things is
good too. However, no OS is loaded yet either...
Rod Pemberton
James Harris
May 10, 2013, 4:17:03 AM5/10/13
to
On May 9, 11:23 pm, "Rod Pemberton" <do_not_h...@notemailnotq.cpm>
wrote:
...
> > [link] [to wikipedia article on test-driven development]
...
> I just skimmed the start of the article. It seems similar to
> other development concepts: design-by-contract, unit testing, code
> refactoring, Agile software management, object oriented
> programming, etc. (all are on Wikipedia, if you're interested...)
Yes, test-driven development (TDD) is part of agile software
development though it can stand on its own. Homebrew OS developers
rarely have the ability to work in pairs, for example. TDD is
basically unit tests which are written before the code and define what
is needed.
Unit testing is limited so let me add a related concept: Behavioural
driven development. BDD is an evolution of TDD. I'm still trying to
understand it but for now it seems to be a way to write tests in
English or other human-readable language and have them mapped to
specific tests.
Unlike the lower-level TDD, BDD focusses on higher-level outcomes.
Tests might be expressed as
given a set of preconditions
when certain events occur
then there should be certain outcomes
AIUI a program called a test runner maps these descriptions to coded
and parameterised testing code. When the unit under test fails the
report is expressed in the natural-language terms used in the form
above.
...
> > So to the OS
> > ============
>
> > Given the above, do any of you guys have an interest in
> > discussing whether such a set of ideas could be feasibly
> > applied to development of our OS developments?
>
> At the moment, I can't see where or how exactly I'd apply it...
I'm not sure either! For OS testing how about some of these (and this
is my first attempt to write in BDD terms so bear with me). Each
paragraph is a separate test and each test is an example purely to
illustrate what we might check for.
given a machine which is off
when the power button is pressed
and execution reaches 0xfc00
then the 2 bytes at 0xfdfe should be 0x55, 0xaa
given a running OS
when the keyboard generates scan code 0x01
then irq 1 should fire
and the scan code should be placed in the key buffer
and the machine should return to the interrupted code
given a running OS
when NMI is generated
and NMI is not inhibited
then the NMI handler should be invoked
The tests would really be expressed in these terms, i.e. the idea is
that the above text would be parsed and converted to actions that
carried out the testing. I am not sure how to verify the requirement
of the second test that the machine returned to the interrupted code
but the others seem like they might be doable.
...
> So far, the scope of your desire to use this (or similar)
> concept(s) is unlimited. Where did you plan on using it? There
> are likely places and situations where it'll work very well, and
> others not so much. Things that are outside your control, or
> outside your application space could be problematic. How much
> uniformity or coherence or correlation do you expect between the
> OSes this test-suite could test? There must be some commonality.
For now, at least, I am thinking that a given OS would have its own
test suite. There may be tests that could be applied to many OSes but
that wasn't what I had in mind.
The question is how to carry out such testing against an OS. Unlike
when unit testing an OS is usually self-contained.
One thing I like about the BDD concept over that of TDD is that it is
not restricted to certain types of tests. AIUI TDD's unit tests are
linked with the code they are testing. For verifying correct behaviour
of an operating system, though, we may not be able to carry out
special linking. We would need a much higher level set of controls
which operate the OS as a user would from the outside.
In other words, to check an OS the test suite should probably take the
place of the user: doing such things as operating the keyboard and
reading the screen - the puppeteer pulling the strings, if you like.
James
wrote:
...
> > [link] [to wikipedia article on test-driven development]
...
> I just skimmed the start of the article. It seems similar to
> other development concepts: design-by-contract, unit testing, code
> refactoring, Agile software management, object oriented
> programming, etc. (all are on Wikipedia, if you're interested...)
development though it can stand on its own. Homebrew OS developers
rarely have the ability to work in pairs, for example. TDD is
basically unit tests which are written before the code and define what
is needed.
Unit testing is limited so let me add a related concept: Behavioural
driven development. BDD is an evolution of TDD. I'm still trying to
understand it but for now it seems to be a way to write tests in
English or other human-readable language and have them mapped to
specific tests.
Unlike the lower-level TDD, BDD focusses on higher-level outcomes.
Tests might be expressed as
given a set of preconditions
when certain events occur
then there should be certain outcomes
AIUI a program called a test runner maps these descriptions to coded
and parameterised testing code. When the unit under test fails the
report is expressed in the natural-language terms used in the form
above.
...
> > So to the OS
> > ============
>
> > Given the above, do any of you guys have an interest in
> > discussing whether such a set of ideas could be feasibly
> > applied to development of our OS developments?
>
> At the moment, I can't see where or how exactly I'd apply it...
is my first attempt to write in BDD terms so bear with me). Each
paragraph is a separate test and each test is an example purely to
illustrate what we might check for.
given a machine which is off
when the power button is pressed
and execution reaches 0xfc00
then the 2 bytes at 0xfdfe should be 0x55, 0xaa
given a running OS
when the keyboard generates scan code 0x01
then irq 1 should fire
and the scan code should be placed in the key buffer
and the machine should return to the interrupted code
given a running OS
when NMI is generated
and NMI is not inhibited
then the NMI handler should be invoked
The tests would really be expressed in these terms, i.e. the idea is
that the above text would be parsed and converted to actions that
carried out the testing. I am not sure how to verify the requirement
of the second test that the machine returned to the interrupted code
but the others seem like they might be doable.
...
> So far, the scope of your desire to use this (or similar)
> concept(s) is unlimited. Where did you plan on using it? There
> are likely places and situations where it'll work very well, and
> others not so much. Things that are outside your control, or
> outside your application space could be problematic. How much
> uniformity or coherence or correlation do you expect between the
> OSes this test-suite could test? There must be some commonality.
test suite. There may be tests that could be applied to many OSes but
that wasn't what I had in mind.
The question is how to carry out such testing against an OS. Unlike
when unit testing an OS is usually self-contained.
One thing I like about the BDD concept over that of TDD is that it is
not restricted to certain types of tests. AIUI TDD's unit tests are
linked with the code they are testing. For verifying correct behaviour
of an operating system, though, we may not be able to carry out
special linking. We would need a much higher level set of controls
which operate the OS as a user would from the outside.
In other words, to check an OS the test suite should probably take the
place of the user: doing such things as operating the keyboard and
reading the screen - the puppeteer pulling the strings, if you like.
James
James Harris
May 10, 2013, 5:29:54 AM5/10/13
to
On May 9, 11:23 pm, "Rod Pemberton" <do_not_h...@notemailnotq.cpm>
wrote:
...
wrote:
...
> I'm not sure that this is suitable for all products and code ...
> E.g., you don't get to chose what BIOS your end-user uses. You
> can't test it. You can't be sure your BIOS testsuite correctly
> emulates it or your application correctly uses it.
I don't know there's a great deal of need for the BIOS these days.
> E.g., you don't get to chose what BIOS your end-user uses. You
> can't test it. You can't be sure your BIOS testsuite correctly
> emulates it or your application correctly uses it.
Once the base OS has been loaded it would normally control devices
directly wouldn't it?
> Ditto for
> CD-ROM drive, motherboard chipset, audio chipset, or VESA video
> BIOS, etc. I.e., you have to code to a well defined software or
> hardware interface.
approach work?
1. The OS/driver expects certain responses, as you mention, and should
report anything else.
2. The test suite verifies that the OS/driver responds properly to
hardware which behaves properly.
3. The test suite verifies that the OS/driver reports errors for other
hardware behaviour.
That way, if the OS runs on hardware which does not work properly at
least it lets the user know and deals with the bad hardware without
losing control.
> If their equipment is not 100% compatible, it
> becomes their problem, unfortunately. That even plagues MS with
> their OS installs for Win9x, WinXP ,etc. They try to do too much,
> use too many new hardware features, and find and install all
> hardware upfront. They could just install keyboard, mouse, video,
> and boot drive. Then, once Windows is running, let a Windows app
> run to detect, install, reconfigure, and upgrade everything else.
> Instead, you get near infinite reboots, one for every time their
> installer chokes on something...
though, IIRC.
...
> What I did want, and perhaps still do, was a BIOS function tester
> which tests all critical BIOS functions and hardware support for
> OS needs or bootloader needs, e.g., e820h,
> a20,
As I think you know, I found BIOS support for enabling A20 was not
consistent (so it would be better to enable it manually).
http://aodfaq.wikispaces.com/machine+characteristics
> Int 13h
> functionality,
Yes but only enough to load the base OS. Not much to test there.
> VGA registers available,
If you mean to detect the presence of minimum VGA, yes.
> VESA 2.0 present?,
Is this to enable and find the linear frame buffer?
> PM BIOS
> interfaces (VESA, PCI), etc.
> Of course, I'd construct a much
> larger list of function calls from the BIOS calls used by
> bootloaders and installers for MS products, FreeBSD, Linux, etc.
don't think any of my machines need even though some are quite old)
with a little bit of initial disk and screen but that's about it. Once
in protected mode or 64-bit mode the BIOS should be unneeded.
Having said that I've not found a good way to deal with non-VGA
display hardware.
James
wolfgang kern
May 10, 2013, 2:00:05 PM5/10/13
to
James Harris wrote:
(unquoted yet.. so I manually added "|")
...
> I'm not sure that this is suitable for all products and code ...
> E.g., you don't get to chose what BIOS your end-user uses. You
> can't test it. You can't be sure your BIOS testsuite correctly
> emulates it or your application correctly uses it.
|I don't know there's a great deal of need for the BIOS these days.
|Once the base OS has been loaded it would normally control devices
|directly wouldn't it?
Yeah, exactly this hardware-detection part could be one main point
> I'm not sure that this is suitable for all products and code ...
> E.g., you don't get to chose what BIOS your end-user uses. You
> can't test it. You can't be sure your BIOS testsuite correctly
> emulates it or your application correctly uses it.
|I don't know there's a great deal of need for the BIOS these days.
|Once the base OS has been loaded it would normally control devices
|directly wouldn't it?
for an OS-test. But the question how to emulate hardware behaviour
will still remain. It would need a total complete virtual machine
to just test if an OS can detect and handle all available hardware.
Such a tool would be really a good thing, even I got some daubt for
it could be done for all the various hardware in the field already.
Perhaps it's just enough to correct report the presence of all parts
without having 'driver-software' ready for it ...?
> Ditto for
> CD-ROM drive, motherboard chipset, audio chipset, or VESA video
> BIOS, etc. I.e., you have to code to a well defined software or
> hardware interface.
|I agree in principle. However, in practice would the following
|approach work?
|1. The OS/driver expects certain responses, as you mention, and should
|report anything else.
|2. The test suite verifies that the OS/driver responds properly to
|hardware which behaves properly.
|3. The test suite verifies that the OS/driver reports errors for other
|hardware behaviour.
|That way, if the OS runs on hardware which does not work properly at
|least it lets the user know and deals with the bad hardware without
|losing control.
KEYBD,MOUSE,HD,FD,CD,VESA,PCI-decice-detection and USB-hosts can be
part of a general test. There are just too many different brands and
versions for mainboard-extensions and audio-devices around. Let aside
nonstandard connected USB-devices yet (modems,printers,webcams,...).
> If their equipment is not 100% compatible, it
> becomes their problem, unfortunately. That even plagues MS with
> their OS installs for Win9x, WinXP ,etc. They try to do too much,
> use too many new hardware features, and find and install all
> hardware upfront. They could just install keyboard, mouse, video,
> and boot drive. Then, once Windows is running, let a Windows app
> run to detect, install, reconfigure, and upgrade everything else.
> Instead, you get near infinite reboots, one for every time their
> installer chokes on something...
|I remember this for Win95 and possibly for Win98. WinXP was better,
|though, IIRC.
because this is the price of using a HAL instead of direct hw-access.
> What I did want, and perhaps still do, was a BIOS function tester
> which tests all critical BIOS functions and hardware support for
> OS needs or bootloader needs, e.g., e820h,
|Yes, that's needed.
> a20,
|As I think you know, I found BIOS support for enabling A20 was not
|consistent (so it would be better to enable it manually).
| http://aodfaq.wikispaces.com/machine+characteristics
> Int 13h
> functionality,
yeah, int13/41 check should be in the MBR aleady.
|Yes but only enough to load the base OS. Not much to test there.
> VGA registers available,
|If you mean to detect the presence of minimum VGA, yes.
> VESA 2.0 present?,
|Is this to enable and find the linear frame buffer?
I actually read the linear frame-buffer address from the PCI-block.
> PM BIOS
> interfaces (VESA, PCI), etc.
|Is it better to use PCI BIOS than to control PCI by _HCI chipset?
> Of course, I'd construct a much
> larger list of function calls from the BIOS calls used by
> bootloaders and installers for MS products, FreeBSD, Linux, etc.
|Do you need much of the BIOS? I use e820 (and some fallbacks which I
|don't think any of my machines need even though some are quite old)
|with a little bit of initial disk and screen but that's about it. Once
|in protected mode or 64-bit mode the BIOS should be unneeded.
the VideoBIOS even a few VESA-functions are available in PM too.
|Having said that I've not found a good way to deal with non-VGA
|display hardware.
its linear address. Direct GPU-coding is still on my wish-list ...
|James
__
wolfgang
Tony
May 11, 2013, 12:55:18 AM5/11/13
to
In article <c01cd14f-3f02-4c85...@a6g2000vbf.googlegroups.com>,
james.h...@gmail.com says...
[ "stuff about various methods of testing software ]
I only skimmed your post, but the gist I got is that you may not realize all the
well-warned methods of testing software such as: unit, whitebox, blackbox, user,
acceptance, regression, etc. Blackbox and whitebox testing have degrees to them.
For example, testing of C++ can require very artificial setup of memory to
verify correct operation of a specific class, or it can check the outcome of
method calls. Both are relevant.
I've learned that there is always a method-de-jure, but that the fundamental
concepts remain pretty much stable and are much more tractable (and some of
those transcend industries). Basically, I think that those who are researching
for "a method" are at a very elementary stage of learning. In the early 1990's,
I was chomping for THE object-oriented method to use, that would "pull
everything together and blow everything else out of the water". I remember
missing opportunities while waiting for Together C++ and the Booch analysis
method tools: both ultimately and utterly useless, to me, in retrospect.
(Aside: When I hear someone spout "methodOLOGY", it sends a red flag warning to
me that they are either: A. A beginner; B. A contracting company that doesn't
have any substance.).
james.h...@gmail.com says...
[ "stuff about various methods of testing software ]
I only skimmed your post, but the gist I got is that you may not realize all the
well-warned methods of testing software such as: unit, whitebox, blackbox, user,
acceptance, regression, etc. Blackbox and whitebox testing have degrees to them.
For example, testing of C++ can require very artificial setup of memory to
verify correct operation of a specific class, or it can check the outcome of
method calls. Both are relevant.
I've learned that there is always a method-de-jure, but that the fundamental
concepts remain pretty much stable and are much more tractable (and some of
those transcend industries). Basically, I think that those who are researching
for "a method" are at a very elementary stage of learning. In the early 1990's,
I was chomping for THE object-oriented method to use, that would "pull
everything together and blow everything else out of the water". I remember
missing opportunities while waiting for Together C++ and the Booch analysis
method tools: both ultimately and utterly useless, to me, in retrospect.
(Aside: When I hear someone spout "methodOLOGY", it sends a red flag warning to
me that they are either: A. A beginner; B. A contracting company that doesn't
have any substance.).
Tony
May 11, 2013, 1:10:09 AM5/11/13
to
In article <kmjcml$dst$1...@newsreader2.utanet.at>, now...@never.at says...
> M$ still needs to reboot whenever a single bit of the hardware farts,
> because this is the price of using a HAL instead of direct hw-access.
>
That doesn't sound correct. Would you care to retract or confirm that? I'm
thinking that it has something to do with having drivers in kernal-land rather
user-land (ref: Minix message-passing kernel vs. Windows). I don't see "HAL"
being the offender. That said, IANAOSD (I am not an OS developer (or driver
developer either)).
> M$ still needs to reboot whenever a single bit of the hardware farts,
> because this is the price of using a HAL instead of direct hw-access.
>
thinking that it has something to do with having drivers in kernal-land rather
user-land (ref: Minix message-passing kernel vs. Windows). I don't see "HAL"
being the offender. That said, IANAOSD (I am not an OS developer (or driver
developer either)).
James Harris
May 11, 2013, 4:55:12 AM5/11/13
to
On May 10, 7:00 pm, "wolfgang kern" <nowh...@never.at> wrote:
> James Harris wrote:
>
> (unquoted yet.. so I manually added "|")
I'll reply separately to the bulk of your post but on the topic of
> James Harris wrote:
>
> (unquoted yet.. so I manually added "|")
quoting/indenting Usenet posts I have just the thing for you!
Rather than having to manually type indent characters when the client
omits them this is a script which types they for you. Think of it as
hotkey indent. A Google search for hkindent might bring it up (it does
for me but I have searched for it before) but if not the link is:
http://codewiki.wikispaces.com/hkindent.ahk
It can be used in any text-based program under Windows. Basically, for
as long as the hotkey combination is pressed it inserts the key
sequence
GreaterThan Space Left Left Down
Thus it indents as many lines as you want it to and I've found that
the natural or default Windows key repeat speed is about right to
allow control and/or to indent plenty in a short time, if needed.
It is very simple but does the job - such as when replying in Outlook
Express. There is also an unindent operation to delete a level of
indent if needed.
The script is documented on the web page so why do I comment on it
here? Because as a programmer talking to other programmers I found it
interesting that it was not possible to paste the above key sequence
from the clipboard - which was what I tried first. The clipboard won't
store cursor movements. So I ended up using a key insertion tool.
As an aside, the Windows clipboard API is awful! It makes something
which should or could be stateless/atomic into a cumbersome sequence
involving ownership.
Going back to the script, it is easy to change what gets inserted so
it could be used for other purposes or could be changed to add your
own favourite indent markings.
It is also easy to change the hotkeys. I chose key combinations that
are unusual enough hopefully to avoid conflicts with anything else. I
made the unindent operation the shifted version of the indent
operation so it is both easy to remember and, as it deletes
characters, slightly more difficult to type by mistake.
James
wolfgang kern
May 11, 2013, 4:55:33 AM5/11/13
to
Tony wrote:
>> M$ still needs to reboot whenever a single bit of the hardware farts,
>> because this is the price of using a HAL instead of direct hw-access.
> That doesn't sound correct. Would you care to retract or confirm that? I'm
> thinking that it has something to do with having drivers in kernal-land
> rather
> user-land (ref: Minix message-passing kernel vs. Windows). I don't see
> "HAL"
> being the offender. That said, IANAOSD (I am not an OS developer (or
> driver > developer either)).
Have you ever replaced a defective PS/2 mouse while running windoze ?
you might have seen the famous msg:
"mouse is not responding, click here to continue"
Or try to disconnect an USB-printer and later connect it to another port.
Windoze detects a 'new' hardware, asks to install drivers and reboot ...
__
wolfgang
Tony
May 11, 2013, 5:09:42 AM5/11/13
to
In article <kml15l$3hq$1...@newsreader2.utanet.at>, now...@never.at says...
What is your point? You sound like you want a job or something. Now that is fine
and all, and that you know that I don't want that does not make it bad, but I do
try to not "employ" you.
That said, wtf are you on about?
and all, and that you know that I don't want that does not make it bad, but I do
try to not "employ" you.
That said, wtf are you on about?
wolfgang kern
May 11, 2013, 5:10:19 AM5/11/13
to
James Harris replied about quote marks:
Thanks a lot James,
I'll keep this for the time when I allow JAVA-scripts on my machines :)
__
wolfgang
Lazy quoting works as well:
<q>
James Harris
May 11, 2013, 5:20:57 AM5/11/13
to
On May 11, 10:10 am, "wolfgang kern" <nowh...@never.at> wrote:
> James Harris replied about quote marks:
>
> Thanks a lot James,
> I'll keep this for the time when I allow JAVA-scripts on my machines :)
What's the Java connection - or were you just kidding? I've just
> James Harris replied about quote marks:
>
> Thanks a lot James,
> I'll keep this for the time when I allow JAVA-scripts on my machines :)
checked and the Autohotkey program comes as a Windows executable and
was written in C++. Source is available.
Do you disallow any downloaded programs on your machine?
James
wolfgang kern
May 11, 2013, 5:19:44 AM5/11/13
to
"Tony" asked:
...
> What is your point? You sound like you want a job or something.
> Now that is fine and all, and that you know that I don't want
> that does not make it bad, but I do try to not "employ" you.
> That said, wtf are you on about?
You seem to be quite new in this group. Try Google archive to see
> Now that is fine and all, and that you know that I don't want
> that does not make it bad, but I do try to not "employ" you.
> That said, wtf are you on about?
what we regular poster/reader/OS-developers are after.
__
wolfgang
James Harris
May 11, 2013, 5:26:44 AM5/11/13
to
On May 11, 10:19 am, "wolfgang kern" <nowh...@never.at> wrote:
> "Tony" asked:
> ...
>
> > What is your point? You sound like you want a job or something.
> > Now that is fine and all, and that you know that I don't want
> > that does not make it bad, but I do try to not "employ" you.
...
> "Tony" asked:
> ...
>
> > What is your point? You sound like you want a job or something.
> > Now that is fine and all, and that you know that I don't want
> > that does not make it bad, but I do try to not "employ" you.
> You seem to be quite new in this group. Try Google archive to see
> what we regular poster/reader/OS-developers are after.
quite an abrasive manner - and seems to like talking down to people.
But I might be wrong. These are just early impressions.
James
wolfgang kern
May 11, 2013, 5:28:39 AM5/11/13
to
James Harris wrote:
> I'll keep this for the time when I allow JAVA-scripts on my machines :)
|What's the Java connection - or were you just kidding? I've just
|checked and the Autohotkey program comes as a Windows executable and
|was written in C++. Source is available.
|Do you disallow any downloaded programs on your machine?
__
wolfgang
James Harris
May 11, 2013, 5:53:29 AM5/11/13
to
wolfgang kern wrote:
> James Harris wrote:
>
> > I'll keep this for the time when I allow JAVA-scripts on my machines :)
>
> |What's the Java connection - or were you just kidding? I've just
> |checked and the Autohotkey program comes as a Windows executable and
> |was written in C++. Source is available.
>
> You know, I don't use C++ nor any other text based HLL.
C++ isn't needed unless you want to compile from source. A Windows exe
> James Harris wrote:
>
> > I'll keep this for the time when I allow JAVA-scripts on my machines :)
>
> |What's the Java connection - or were you just kidding? I've just
> |checked and the Autohotkey program comes as a Windows executable and
> |was written in C++. Source is available.
>
> You know, I don't use C++ nor any other text based HLL.
is available. And it doesn't use any Javaish stuff as far as I can
see.
>
> |Do you disallow any downloaded programs on your machine?
>
> No, I just disabled active java-scripting.
just checked the wiki with the script on it. It doesn't need
Javascript (unless you want to edit its pages). With Javascript turned
off I can still read the page, copy the indent script and link to the
site where the key inserter is.
Basically it looks like I can do everything necessary to set up the
indenter on my machine without having either Java or Javascript.
So I am mystified as to what you mean. But it doesn't matter. No need
to reply. I've been puzzled about things before and learned to live
with it. ;-)
James
Rod Pemberton
May 11, 2013, 2:55:27 PM5/11/13
to
"James Harris" <james.h...@gmail.com> wrote in message
news:127d3116-d04c-4567...@b3g2000vbo.googlegroups.com...
> On May 9, 11:23 pm, "Rod Pemberton"
<do_not_h...@notemailnotq.cpm>
> wrote:
...
> > I'm not sure that this is suitable for all products and code
...
> > E.g., you don't get to chose what BIOS your end-user uses. You
> > can't test it. You can't be sure your BIOS testsuite correctly
> > emulates it or your application correctly uses it.
>
> I don't know there's a great deal of need for the BIOS these
> days. Once the base OS has been loaded it would normally
> control devices directly wouldn't it?
My OS does. But, an OS doesn't have to. It depends on the OS'
<do_not_h...@notemailnotq.cpm>
> wrote:
...
> > I'm not sure that this is suitable for all products and code
...
> > E.g., you don't get to chose what BIOS your end-user uses. You
> > can't test it. You can't be sure your BIOS testsuite correctly
> > emulates it or your application correctly uses it.
>
> I don't know there's a great deal of need for the BIOS these
> days. Once the base OS has been loaded it would normally
> control devices directly wouldn't it?
design and needs. The point of the BIOS was to implement code
specific or unique to the hardware. I.e., it's the pre-cursor to
a modern day device driver. It's also closed source code, i.e.,
might be hard to find an open specification for devices supported
by the BIOS.
> > Ditto for CD-ROM drive, motherboard chipset, audio chipset,
> > or VESA video BIOS, etc. I.e., you have to code to a well
> > defined software or hardware interface.
>
> I agree in principle. However, in practice would the following
> approach work?
>
> 1. The OS/driver expects certain responses, as you mention, and
> should report anything else.
>
Does the driver fail? stop? continue? abort?
Personally, I don't like this option. The reason is it reminds me
of old DOS where it would fail and provide a prompt. However,
there was nothing the user could do to fix the problem. All they
could do was shutdown and attempt to find another driver. I'd
prefer that a driver that attempts to continue or be as fault
tolerant or as generic as possible so that it simply works, at
least initially. What is a user supposed to do with an error?
Once the OS is functioning, then a hardware specific, high
performance driver, can be installed to replace the generic
driver.
> 2. The test suite verifies that the OS/driver responds properly
> to hardware which behaves properly.
>
prior to the OS install, or does this execute on the OS itself?
If the latter, the OS/driver, or a limited version of it, must
respond properly PRIOR TO testing for some devices in order to
boot. If the former, then you need another simpler version of the
OS or another simple OS to do testing, yes?
> 3. The test suite verifies that the OS/driver reports errors for
> other hardware behaviour.
>
errors with working hardware?
> That way, if the OS runs on hardware which does not work
> properly at least it lets the user know and deals with the bad
> hardware without losing control.
area of problems is - believe it or not - infinite loops. When
some piece of code is waiting for a response, you can easily
create an infinite loop or a secondary infinite, i.e., at a layer
once or twice removed from the code that is waiting. Another area
of problems is generating failure situations. Sometimes you can
code code which causes the failure. However, for other times, you
must hardcode a failure and recompile the OS. This is because
there is no method to create the failure on working hardware...
You definately don't want to use non-working hardware... You
could fry your entire system.
> > VGA registers available,
>
> If you mean to detect the presence of minimum VGA, yes.
historical VGA registers optional for all future video cards. I
don't recall which standard (1.2, 2.0, 3.0), but probably 2.0.
I.e., after that, video card manufacturers are allowed to make
VESA-only video cards. AFAIK, the only way to program a VESA-only
video card without VGA registers is to use BIOS calls. AIUI, VESA
can be accessed via a RM interface and partially by a PM
interface. The lack of VGA registers would be a problem for most
any OS that used 640x480 or 800x600 for setup, since they're
likely to directly program VGA instead of using VESA to set those
video modes. Fortunately, all video card manufacturers have
continued to produce VGA compatible cards, AFAIK.
> > VESA 2.0 present?,
>
> Is this to enable and find the linear frame buffer?
VESA-only video card. Or, you have some old, obsolete card, say a
CGA or Hercules, etc. Also, VESA 2.0 fixed a bunch of issues with
VESA 1.2.
> > PM BIOS
> > interfaces (VESA, PCI), etc.
>
> Is it better to use PCI BIOS than to control PCI by _HCI
> chipset?
valuable to a 32-bit PM OS, e.g., VESA.
> > Of course, I'd construct a much
> > larger list of function calls from the BIOS calls used by
> > bootloaders and installers for MS products, FreeBSD, Linux,
>
> Do you need much of the BIOS?
For my OS, so far, no. However, I was planning on using
Multiboot (via GRUB etc) to start my OS. It does appear that
bootloaders for Windows, FreeBSD, Linux, etc use quite a number
of BIOS calls to start.
> Having said that I've not found a good way to deal with
> non-VGA display hardware.
registers optional. I'd think that's a reason to check for VESA.
Rod Pemberton
Rod Pemberton
May 11, 2013, 3:01:42 PM5/11/13
to
"James Harris" <james.h...@gmail.com> wrote in message
news:c01cd14f-3f02-4c85...@a6g2000vbf.googlegroups.com...
> On May 9, 11:23 pm, "Rod Pemberton"
<do_not_h...@notemailnotq.cpm>
> wrote:
> > At the moment, I can't see where or how exactly I'd apply
> > it...
>
> I'm not sure either! For OS testing how about some of these (and
> this is my first attempt to write in BDD terms so bear with me).
> Each paragraph is a separate test and each test is an example
> purely to illustrate what we might check for.
...
<do_not_h...@notemailnotq.cpm>
> wrote:
> > At the moment, I can't see where or how exactly I'd apply
> > it...
>
> I'm not sure either! For OS testing how about some of these (and
> this is my first attempt to write in BDD terms so bear with me).
> Each paragraph is a separate test and each test is an example
> purely to illustrate what we might check for.
> given a machine which is off
> when the power button is pressed
> and execution reaches 0xfc00
> then the 2 bytes at 0xfdfe should be 0x55, 0xaa
that '7' could look like 'f' or 'F', if dyslexic... This is for a
boot code, yes? The BIOS loads the code to 0x7C00, usually with
IP=0h, CS=0x7C00. It's rumored that an IBM clone, perhaps an
early Compaq, used IP=0x7C0, CS=0x0, by mistake. That
(supposedly) crashed some boot code, e.g., DOS, CP/M. In theory,
other addresses and segments for IP and CS which result in a RM
physical address of 0x7C00 could be used also... So, I think the
addresses you want are 0x7c00 and 0x7dfe, instead of 0xfc00 and
0x7dfe. But, you probably should check for a signature at:
0x1fe + IP
It's going to be relative to CS, i.e., CS<<4+IP+0x1fe.
2) The 0x55, 0xAA signature is REQUIRED only for hard drive boot
code and installable ROMs (video, ethernet), etc. Technically,
floppy boot code DOES NOT require the signature. Floppy boot code
is supposed to be executable if the code starts with byte values
over 06h and the byte values don't repeat more than a fixed number
of times (exact number depends on the BIOS, supposedly varies from
8 to 128 or so...). If the values repeat more than a fixed number
of times, the floppy is blank. This was defined in the original
IBM technical manuals. CP/M boot code also stores other values in
the 0x1fe location. I'm not sure if the requirement to boot
floppies without the signature has changed via some modern
standard. So far, I've not found any changes listed in
standards... However, this machine requires the signature for
floppies. It also requires it for hard disks, floppy images, hard
disk images, USB sticks, USB drives, etc, basically for
everything. So far, it's the only machine I'm aware of that won't
boot a floppy without the signature. However, it's motherboard
was listed as being incompatible with Windows 9x. But, it is 100%
compatible with Windows 9x. So, at the time, everyone thought
that meant A20 issues in DOS. Maybe, it was a signature problem
in the BIOS for floppies...
> given a running OS
> when the keyboard generates scan code 0x01
> then irq 1 should fire
> and the scan code should be placed in the key buffer
> and the machine should return to the interrupted code
not reading enough data per IRQ, but I was getting mouse and
keyboard data on *both* IRQ1 and IRQ12 ...
> given a running OS
> when NMI is generated
> and NMI is not inhibited
> then the NMI handler should be invoked
AFAICT, NMI is primarily for hardware issues. Currently, I know
of no software method to trigger NMI, except hardcoding and
recompiling the OS. If there is no software method to generate an
NMI, that could be an issue for such a test.
> The tests would really be expressed in these terms,
> i.e. the idea is that the above text would be parsed
> and converted to actions that carried out the testing.
> I am not sure how to verify the requirement of the
> second test that the machine returned to the interrupted
> code but the others seem like they might be doable.
...
> > So far, the scope of your desire to use this (or similar)
> > concept(s) is unlimited. Where did you plan on using it? There
> > are likely places and situations where it'll work very well,
> > and others not so much. Things that are outside your control,
> > or outside your application space could be problematic. How
> > much uniformity or coherence or correlation do you expect
> > between the OSes this test-suite could test? There must be
> > some commonality.
>
> For now, at least, I am thinking that a given OS would have its
> own test suite. There may be tests that could be applied to many
> OSes but that wasn't what I had in mind.
>
> The question is how to carry out such testing against an OS.
> Unlike when unit testing an OS is usually self-contained.
>
>
> In other words, to check an OS the test suite should probably
> take the place of the user: doing such things as operating the
> keyboard and reading the screen - the puppeteer pulling the
> strings, if you like.
If the test suite can only take the place of the user, it can't
> In other words, to check an OS the test suite should probably
> take the place of the user: doing such things as operating the
> keyboard and reading the screen - the puppeteer pulling the
> strings, if you like.
test any of the three tests you mentioned earlier. I.e., an
emulated user can't test low-level features of the OS, but only
user features, e.g., keyboard, mouse, video, or user accessable
features, e.g., harddrive, cdrom, etc. How would you test NMI?
CMOS? boot code? A20? task switching? etc.
Rod Pemberton
James Harris
May 12, 2013, 5:36:56 PM5/12/13
to
On May 11, 8:01 pm, "Rod Pemberton" <do_not_h...@notemailnotq.cpm>
wrote:
...
> > given a machine which is off
> > when the power button is pressed
> > and execution reaches 0xfc00
> > then the 2 bytes at 0xfdfe should be 0x55, 0xaa
>
> 1) Where did you get 0xfc00 from? Was that a typo?
Yes
...
> > given a running OS
> > when NMI is generated
> > and NMI is not inhibited
> > then the NMI handler should be invoked
>
> How do you intend to trigger the NMI?
...
> If the test suite can only take the place of the user, it can't
> test any of the three tests you mentioned earlier. I.e., an
> emulated user can't test low-level features of the OS, but only
> user features, e.g., keyboard, mouse, video, or user accessable
> features, e.g., harddrive, cdrom, etc. How would you test NMI?
> CMOS? boot code? A20? task switching? etc.
*Some* tests would need to emulate a user. Others could replace
modules. Still others might load and run specific test programs, etc.
I initially thought some desirable tests would be impossible but I
found VBoxManage. It is a command-line interface to VirtualBox. When I
checked it turned out it could do even more than the emulator's GUI!
Check out
http://www.virtualbox.org/manual/ch08.html
It includes options to create virtual machines, change their settings,
start and stop them, set up and configure drive images, change
emulated hardware etc.
It is all doable from the command line which means it can be invoked
from a script.
Some of the most detailed controls are found in the debugvm command.
That allows things like generating NMI (albeit without a specfic cause
code as far as I can see) and executing the OS code with breakpoints.
Amazing though it is I don't mean it would be the only way to check an
OS against the specification but it would make some testing feasible
which would otherwise seem impossible.
How to integrate the tests? One of the things that attracted me to BDD
was the concept of automatically mapping an English-language
specification into something executable. A single specification can,
in theory, be translated in to different types of tests, some of which
could use vboxmanage.
That said, I am not convinced the BDD tools are there to support what
an OS developer would need. Most BDD testing I have seen is
pathetically limited. Am still looking in to that side of it.
James
wrote:
...
> > given a machine which is off
> > when the power button is pressed
> > and execution reaches 0xfc00
> > then the 2 bytes at 0xfdfe should be 0x55, 0xaa
>
> 1) Where did you get 0xfc00 from? Was that a typo?
...
> > given a running OS
> > when NMI is generated
> > and NMI is not inhibited
> > then the NMI handler should be invoked
>
> How do you intend to trigger the NMI?
> If the test suite can only take the place of the user, it can't
> test any of the three tests you mentioned earlier. I.e., an
> emulated user can't test low-level features of the OS, but only
> user features, e.g., keyboard, mouse, video, or user accessable
> features, e.g., harddrive, cdrom, etc. How would you test NMI?
> CMOS? boot code? A20? task switching? etc.
modules. Still others might load and run specific test programs, etc.
I initially thought some desirable tests would be impossible but I
found VBoxManage. It is a command-line interface to VirtualBox. When I
checked it turned out it could do even more than the emulator's GUI!
Check out
http://www.virtualbox.org/manual/ch08.html
It includes options to create virtual machines, change their settings,
start and stop them, set up and configure drive images, change
emulated hardware etc.
It is all doable from the command line which means it can be invoked
from a script.
Some of the most detailed controls are found in the debugvm command.
That allows things like generating NMI (albeit without a specfic cause
code as far as I can see) and executing the OS code with breakpoints.
Amazing though it is I don't mean it would be the only way to check an
OS against the specification but it would make some testing feasible
which would otherwise seem impossible.
How to integrate the tests? One of the things that attracted me to BDD
was the concept of automatically mapping an English-language
specification into something executable. A single specification can,
in theory, be translated in to different types of tests, some of which
could use vboxmanage.
That said, I am not convinced the BDD tools are there to support what
an OS developer would need. Most BDD testing I have seen is
pathetically limited. Am still looking in to that side of it.
James
James Harris
May 12, 2013, 6:26:52 PM5/12/13
to
On May 10, 7:00 pm, "wolfgang kern" <nowh...@never.at> wrote:
> James Harris wrote:
>
> (unquoted yet.. so I manually added "|")
...
>
> (unquoted yet.. so I manually added "|")
...
> |I don't know there's a great deal of need for the BIOS these days.
> |Once the base OS has been loaded it would normally control devices
> |directly wouldn't it?
>
> Yeah, exactly this hardware-detection part could be one main point
> for an OS-test. But the question how to emulate hardware behaviour
> will still remain. It would need a total complete virtual machine
> to just test if an OS can detect and handle all available hardware.
> Such a tool would be really a good thing, even I got some daubt for
> it could be done for all the various hardware in the field already.
You mean all the different device types? Surely not. But it might be
> |Once the base OS has been loaded it would normally control devices
> |directly wouldn't it?
>
> Yeah, exactly this hardware-detection part could be one main point
> for an OS-test. But the question how to emulate hardware behaviour
> will still remain. It would need a total complete virtual machine
> to just test if an OS can detect and handle all available hardware.
> Such a tool would be really a good thing, even I got some daubt for
> it could be done for all the various hardware in the field already.
possible to emulate one or two of each type of device, e.g. a couple
of different types of network cards. Have you looked at running your
OS in an emulator? They can often emulate different device types.
> Perhaps it's just enough to correct report the presence of all parts
> without having 'driver-software' ready for it ...?
level of, say, a network card but allow the OS to have selected the
driver required.
...
> > VESA 2.0 present?,
>
> |Is this to enable and find the linear frame buffer?
>
> It gives information about available screen-modes (but check monitor too!)
> I actually read the linear frame-buffer address from the PCI-block.
to tell the machine to use the LFB instead of the VGA memory?
>
> > PM BIOS
> > interfaces (VESA, PCI), etc.
>
> |Is it better to use PCI BIOS than to control PCI by _HCI chipset?
>
> PCI-configuration and device-detection are standard (ports 0cf8/0cfc).
mentioned.
...
> |Do you need much of the BIOS? I use e820 (and some fallbacks which I
> |don't think any of my machines need even though some are quite old)
> |with a little bit of initial disk and screen but that's about it. Once
> |in protected mode or 64-bit mode the BIOS should be unneeded.
>
> Me too use BIOS very rare on power-up, but there is no way to bypass
> the VideoBIOS even a few VESA-functions are available in PM too.
> |Having said that I've not found a good way to deal with non-VGA
> |display hardware.
>
> I use VESA-mode-setting and then just write direct to the screen using
> its linear address. Direct GPU-coding is still on my wish-list ...
James
wolfgang kern
May 13, 2013, 3:25:03 AM5/13/13
to
James Harris wrote:
...
>|I don't know there's a great deal of need for the BIOS these days.
>|Once the base OS has been loaded it would normally control devices
>|directly wouldn't it?
> Yeah, exactly this hardware-detection part could be one main point
> for an OS-test. But the question how to emulate hardware behaviour
> will still remain. It would need a total complete virtual machine
> to just test if an OS can detect and handle all available hardware.
> Such a tool would be really a good thing, even I got some daubt for
> it could be done for all the various hardware in the field already.
|You mean all the different device types? Surely not. But it might be
|possible to emulate one or two of each type of device, e.g. a couple
|of different types of network cards. Have you looked at running your
|OS in an emulator? They can often emulate different device types.
vital things during startup (PCI-config,APIC,MTTR,...).
> Perhaps it's just enough to correct report the presence of all parts
> without having 'driver-software' ready for it ...?
|Not sure I follow. It might be possible to have tests for the upper
|level of, say, a network card but allow the OS to have selected the
|driver required.
without enough detailed information from manufacturer.
...
>> VESA 2.0 present?,
>|Is this to enable and find the linear frame buffer?
> It gives information about available screen-modes (but check monitor too!)
> I actually read the linear frame-buffer address from the PCI-block.
Interesting. I hadn't thought about the info from PCI. Do you use PCI
to tell the machine to use the LFB instead of the VGA memory?
There is nothing to tell. Oh, I think to now understand your question,
the BIOS-default text-mode '03' isn't a VESA-mode and uses 0xB8000...
while all VESA-reported graphic modes show the LFB (same as in PCI).
And I check for presence of addon-RAM very early in the startup to
get a complete list of all available memory (by reading PCI-config).
>> PM BIOS
>> interfaces (VESA, PCI), etc.
>|Is it better to use PCI BIOS than to control PCI by _HCI chipset?
> PCI-configuration and device-detection are standard (ports 0cf8/0cfc).
|OK. So I wonder what is the value of the Pmode PCI BIOS that Rod
|mentioned.
RD/WR does nothing else than communicate with ports 0cf8 and 0cfc :)
There are a few VESA-function in the VBIOS which can be called from PM.
...
>|Having said that I've not found a good way to deal with non-VGA
>|display hardware.
> I use VESA-mode-setting and then just write direct to the screen using
> its linear address. Direct GPU-coding is still on my wish-list ...
|Access by LFB sounds plenty to me.
happy to have LFB-access today. My standard is 1024*768(8 or 32 bit).
__
wolfgang
James Harris
May 13, 2013, 4:31:17 AM5/13/13
to
On May 13, 8:25 am, "wolfgang kern" <nowh...@never.at> wrote:
...
> I never tried any emulation-tool because my OS may alter too many
> vital things during startup (PCI-config,APIC,MTTR,...).
And they need to match the hardware you have written for. Understood.
By the way, I'm quite impressed that you are altering MTRRs.
> > Perhaps it's just enough to correct report the presence of all parts
> > without having 'driver-software' ready for it ...?
>
> |Not sure I follow. It might be possible to have tests for the upper
> |level of, say, a network card but allow the OS to have selected the
> |driver required.
>
> You just hit an open wound. It was/is hard to create hardware-'drivers'
> without enough detailed information from manufacturer.
I'm surprised it was possible!
> ... Do you use PCI
...
> I remember the awful CGA/EGA 16 color 4-plane story now and I'm really
> happy to have LFB-access today. My standard is 1024*768(8 or 32 bit).
1024 * 768 at 32-bit is about 3 Mbytes. Far too much to fit in to the
128k from A0000. Hence I think of the LFB as somewhere where the
display memory has been mapped in to the address space. Presumably at
some point you tell the hardware to use the LFB in a VESA mode rather
than to use the VGA-or-similar memory.
James
...
> I never tried any emulation-tool because my OS may alter too many
> vital things during startup (PCI-config,APIC,MTTR,...).
By the way, I'm quite impressed that you are altering MTRRs.
> > Perhaps it's just enough to correct report the presence of all parts
> > without having 'driver-software' ready for it ...?
>
> |Not sure I follow. It might be possible to have tests for the upper
> |level of, say, a network card but allow the OS to have selected the
> |driver required.
>
> You just hit an open wound. It was/is hard to create hardware-'drivers'
> without enough detailed information from manufacturer.
> ... Do you use PCI
> to tell the machine to use the LFB instead of the VGA memory?
>
> You mean the range A0000...Bffff as VGA-memory ? aren't this LFB ? :)
> There is nothing to tell. Oh, I think to now understand your question,
> the BIOS-default text-mode '03' isn't a VESA-mode and uses 0xB8000...
> while all VESA-reported graphic modes show the LFB (same as in PCI).
> And I check for presence of addon-RAM very early in the startup to
> get a complete list of all available memory (by reading PCI-config).
Yes, I mean the memory from A0000 which is limited to 128k AFAIR.
>
> You mean the range A0000...Bffff as VGA-memory ? aren't this LFB ? :)
> There is nothing to tell. Oh, I think to now understand your question,
> the BIOS-default text-mode '03' isn't a VESA-mode and uses 0xB8000...
> while all VESA-reported graphic modes show the LFB (same as in PCI).
> And I check for presence of addon-RAM very early in the startup to
> get a complete list of all available memory (by reading PCI-config).
...
> I remember the awful CGA/EGA 16 color 4-plane story now and I'm really
> happy to have LFB-access today. My standard is 1024*768(8 or 32 bit).
128k from A0000. Hence I think of the LFB as somewhere where the
display memory has been mapped in to the address space. Presumably at
some point you tell the hardware to use the LFB in a VESA mode rather
than to use the VGA-or-similar memory.
James
Rod Pemberton
May 13, 2013, 5:15:00 AM5/13/13
to
"James Harris" <james.h...@gmail.com> wrote in message
news:758873cb-a046-4f59...@dl10g2000vbb.googlegroups.com...
> I initially thought some desirable tests would be impossible
> but I found VBoxManage. It is a command-line interface to
> VirtualBox. When I checked it turned out it could do even
> more than the emulator's GUI!
>
> Check out
>
>
> It includes options to create virtual machines, change their
> settings, start and stop them, set up and configure drive
> images, change emulated hardware etc.
>
> It is all doable from the command line which means it can be
> invoked from a script.
>
Scripting+Emulation. Nice find.
> It includes options to create virtual machines, change their
> settings, start and stop them, set up and configure drive
> images, change emulated hardware etc.
>
> It is all doable from the command line which means it can be
> invoked from a script.
>
I think that could/should work _very_ well for the type of testing
you're considering. The host OS and emulation should/could allow
you to "inject" all sorts of stuff into the emulated environment
that would/could be difficult to do otherwise. So, that seems
ideal to me. Of course, you're still limited to the virtual
machines' ability to correctly emulate real hardware. If it
doesn't emulate something correctly, you're still out of luck...
However, I've mostly avoided emulators so far... Alexei Frounze
pointed out some good uses a while back. On the other hand,
Benjamin Lunt pointed out some problems with a specific emulator.
So, I've kept the idea of using emulators in mind as a secondary
check, but I haven't really tested my OS much under any of them.
IIRC, I ran it under QEMU just to see if it would work. The
ability to run an OS in a virtual machine is a nice feature for
trying out an OS for those who can't/won't install an OS, but my
OS isn't anywhere near that point yet...
> Amazing though it is I don't mean it would be the only
> way to check an OS against the specification but it would
> make some testing feasible which would otherwise seem
> impossible.
What types of OSes can VirtualBox emulate? Are there any OS
limitations?
Rod Pemberton
James Harris
May 13, 2013, 5:25:24 AM5/13/13
to
On May 11, 7:55 pm, "Rod Pemberton" <do_not_h...@notemailnotq.cpm>
wrote:
...
> > I don't know there's a great deal of need for the BIOS these
> > days. Once the base OS has been loaded it would normally
> > control devices directly wouldn't it?
>
> My OS does. But, an OS doesn't have to. It depends on the OS'
> design and needs. The point of the BIOS was to implement code
> specific or unique to the hardware. I.e., it's the pre-cursor to
> a modern day device driver. It's also closed source code, i.e.,
> might be hard to find an open specification for devices supported
> by the BIOS.
Right. We need some initial interaction with the BIOS (e.g. memory
map, early disk access and possibly video mode). It seems to be more
portable to bite the bullet and do the rest ourselves without using
Like you I would not offer the user a meaningless choice but would
expect the OS to issue or log a diagnostic if it could not do
something it had been told to do.
In terms of checking, it would be enough initially to verify that the
OS behaved in one of those two ways.
> > 2. The test suite verifies that the OS/driver responds properly
> > to hardware which behaves properly.
>
> That requires a test environment.
Yes, and that's more than possible. See my previous post about a
virtual environment.
> Is this environment executed
> prior to the OS install, or does this execute on the OS itself?
The emulator you know about. Some tests should run on the OS itself
but I think they would come later, once the OS is running.
> If the latter, the OS/driver, or a limited version of it, must
> respond properly PRIOR TO testing for some devices in order to
> boot. If the former, then you need another simpler version of the
> OS or another simple OS to do testing, yes?
I'm not sure I understand your comment. Only a few devices are needed
for the OS to boot. There are many other items of hardware.
Some tests could run once an OS is ready to receive user programs.
Other tests would run to verify elements of the OS startup process.
The latter, in particular, could benefit from using a virtual
environment.
> > 3. The test suite verifies that the OS/driver reports errors for
> > other hardware behaviour.
>
> How exactly do you force hardware failures to generate the correct
> errors with working hardware?
There's probably not a lot that could be done. Some unit tests or
behavioural tests recommend "mocks" (mock-ups?) which take the place
of elements of a system. I think I would rather just tell the emulator
that a certain piece of hardware does not exist and check that the OS
issues a diagnostic when told to access it.
I know that is limited. An annoyance with Linux is that in some cases
when it gets a hardware failure it takes a very long time to recognise
it (because, I presume, of retries at multiple levels) and even then
may not log a full diagnostic of the failure. (This is not a criticism
of Linux vs. Windows. Windows generally provides even less info - by a
long way.) So although what I am suggesting is limited it should be
possible to detect that an OS responds with either success or failure
in reasonable time.
ISTM that anything the OS cannot or does not know how to deal with
should at least be logged so that a human can work out what to do. The
point is that the minimum I think we could practically test for is
that the OS does, in fact, log something on hardware failure. Paths
through the OS code should be of only two types: 1, expected response,
2, report of failure.
>
> > That way, if the OS runs on hardware which does not work
> > properly at least it lets the user know and deals with the bad
> > hardware without losing control.
>
> I've run into a couple of problems when coding for my OS. One
> area of problems is - believe it or not - infinite loops. When
> some piece of code is waiting for a response, you can easily
> create an infinite loop or a secondary infinite, i.e., at a layer
> once or twice removed from the code that is waiting.
On that topic I recently started reading "Release It!" by Michael
Nygard. He talks at one point about protecting code from failures in
called modules including late responses and lack of response. I don't
agree with what I have seen so far of his mitigation techniques but
the issue is a valid one. Without a timeout, any time we call another
routine and wait indefinitely for a response we are hostages to that
module responding or the modules it calls responding and so on.
> Another area
> of problems is generating failure situations. Sometimes you can
> code code which causes the failure. However, for other times, you
> must hardcode a failure and recompile the OS. This is because
> there is no method to create the failure on working hardware...
> You definately don't want to use non-working hardware... You
> could fry your entire system.
Yes and no. The recompilation with a module which hardcodes a failure
is what I think of as adding a mock module. Basic failure tests,
however, could be quickly and safely carried out in an emulator.
>
> > > VGA registers available,
>
> > If you mean to detect the presence of minimum VGA, yes.
>
> One of the vesa standards makes VGA compatibility via the
> historical VGA registers optional for all future video cards.
...
> As mentioned elsewhere, one of the VESA standards makes VGA
> registers optional. I'd think that's a reason to check for VESA.
I didn't know that. At the moment I am not near the stage of playing
with screen displays. I had assumed the presence of VGA or what looks
like VGA and intend to bail on anything which does not support it.
James
wrote:
...
> > I don't know there's a great deal of need for the BIOS these
> > days. Once the base OS has been loaded it would normally
> > control devices directly wouldn't it?
>
> My OS does. But, an OS doesn't have to. It depends on the OS'
> design and needs. The point of the BIOS was to implement code
> specific or unique to the hardware. I.e., it's the pre-cursor to
> a modern day device driver. It's also closed source code, i.e.,
> might be hard to find an open specification for devices supported
> by the BIOS.
map, early disk access and possibly video mode). It seems to be more
portable to bite the bullet and do the rest ourselves without using
the BIOS.
> > > Ditto for CD-ROM drive, motherboard chipset, audio chipset,
> > > or VESA video BIOS, etc. I.e., you have to code to a well
> > > defined software or hardware interface.
>
> > I agree in principle. However, in practice would the following
> > approach work?
>
> > 1. The OS/driver expects certain responses, as you mention, and
> > should report anything else.
>
> What happnes for a reported failure response?
> Does the driver fail? stop? continue? abort?
...
> > > Ditto for CD-ROM drive, motherboard chipset, audio chipset,
> > > or VESA video BIOS, etc. I.e., you have to code to a well
> > > defined software or hardware interface.
>
> > I agree in principle. However, in practice would the following
> > approach work?
>
> > 1. The OS/driver expects certain responses, as you mention, and
> > should report anything else.
>
> What happnes for a reported failure response?
> Does the driver fail? stop? continue? abort?
Like you I would not offer the user a meaningless choice but would
expect the OS to issue or log a diagnostic if it could not do
something it had been told to do.
In terms of checking, it would be enough initially to verify that the
OS behaved in one of those two ways.
> > 2. The test suite verifies that the OS/driver responds properly
> > to hardware which behaves properly.
>
> That requires a test environment.
virtual environment.
> Is this environment executed
> prior to the OS install, or does this execute on the OS itself?
but I think they would come later, once the OS is running.
> If the latter, the OS/driver, or a limited version of it, must
> respond properly PRIOR TO testing for some devices in order to
> boot. If the former, then you need another simpler version of the
> OS or another simple OS to do testing, yes?
for the OS to boot. There are many other items of hardware.
Some tests could run once an OS is ready to receive user programs.
Other tests would run to verify elements of the OS startup process.
The latter, in particular, could benefit from using a virtual
environment.
> > 3. The test suite verifies that the OS/driver reports errors for
> > other hardware behaviour.
>
> How exactly do you force hardware failures to generate the correct
> errors with working hardware?
behavioural tests recommend "mocks" (mock-ups?) which take the place
of elements of a system. I think I would rather just tell the emulator
that a certain piece of hardware does not exist and check that the OS
issues a diagnostic when told to access it.
I know that is limited. An annoyance with Linux is that in some cases
when it gets a hardware failure it takes a very long time to recognise
it (because, I presume, of retries at multiple levels) and even then
may not log a full diagnostic of the failure. (This is not a criticism
of Linux vs. Windows. Windows generally provides even less info - by a
long way.) So although what I am suggesting is limited it should be
possible to detect that an OS responds with either success or failure
in reasonable time.
ISTM that anything the OS cannot or does not know how to deal with
should at least be logged so that a human can work out what to do. The
point is that the minimum I think we could practically test for is
that the OS does, in fact, log something on hardware failure. Paths
through the OS code should be of only two types: 1, expected response,
2, report of failure.
>
> > That way, if the OS runs on hardware which does not work
> > properly at least it lets the user know and deals with the bad
> > hardware without losing control.
>
> I've run into a couple of problems when coding for my OS. One
> area of problems is - believe it or not - infinite loops. When
> some piece of code is waiting for a response, you can easily
> create an infinite loop or a secondary infinite, i.e., at a layer
> once or twice removed from the code that is waiting.
Nygard. He talks at one point about protecting code from failures in
called modules including late responses and lack of response. I don't
agree with what I have seen so far of his mitigation techniques but
the issue is a valid one. Without a timeout, any time we call another
routine and wait indefinitely for a response we are hostages to that
module responding or the modules it calls responding and so on.
> Another area
> of problems is generating failure situations. Sometimes you can
> code code which causes the failure. However, for other times, you
> must hardcode a failure and recompile the OS. This is because
> there is no method to create the failure on working hardware...
> You definately don't want to use non-working hardware... You
> could fry your entire system.
is what I think of as adding a mock module. Basic failure tests,
however, could be quickly and safely carried out in an emulator.
>
> > > VGA registers available,
>
> > If you mean to detect the presence of minimum VGA, yes.
>
> One of the vesa standards makes VGA compatibility via the
> historical VGA registers optional for all future video cards.
> As mentioned elsewhere, one of the VESA standards makes VGA
> registers optional. I'd think that's a reason to check for VESA.
with screen displays. I had assumed the presence of VGA or what looks
like VGA and intend to bail on anything which does not support it.
James
James Harris
May 13, 2013, 5:34:42 AM5/13/13
to
On May 13, 10:15 am, "Rod Pemberton" <do_not_h...@notemailnotq.cpm>
wrote:
...
> Yes, it seems to me you're on a good track with this!
Thanks for the positive responses about using an emulator. With an
admittedly vague memory that you were not keen on such things the
encouraging responses were unexpected.
> What types of OSes can VirtualBox emulate? Are there any OS
> limitations?
Well, VirtualBox emulates the hardware but given that Windows and
Linux will run on it I presume that its emulation is very good. As you
may be alluding to, VirtualBox does have settings for specific
operating systems but I presume these are for subtle enhancements. I
run most things as OS = Other, version = Unknown.
James
wrote:
...
> Yes, it seems to me you're on a good track with this!
admittedly vague memory that you were not keen on such things the
encouraging responses were unexpected.
> What types of OSes can VirtualBox emulate? Are there any OS
> limitations?
Linux will run on it I presume that its emulation is very good. As you
may be alluding to, VirtualBox does have settings for specific
operating systems but I presume these are for subtle enhancements. I
run most things as OS = Other, version = Unknown.
James
wolfgang kern
May 14, 2013, 1:25:01 PM5/14/13
to
James Harris replied:
...
> I never tried any emulation-tool because my OS may alter too many
> vital things during startup (PCI-config,APIC,MTTR,...).
|And they need to match the hardware you have written for. Understood.
|By the way, I'm quite impressed that you are altering MTRRs.
No magic behind this, it's just for reducing HW-mem-ranges where the
> I never tried any emulation-tool because my OS may alter too many
> vital things during startup (PCI-config,APIC,MTTR,...).
|And they need to match the hardware you have written for. Understood.
|By the way, I'm quite impressed that you are altering MTRRs.
BIOS often acts to optimistic and size-tolerant for devices even they
wont need 'that many' RAM-space as it usually grants.
This PCI readback MASKed-Address-pins are really a good indication of
how many address-pins are decoded from a device (ie: 4K for USB-hosts,
which BTW never need more than 512 byte), OK here we can't save a bit.
> > Perhaps it's just enough to correct report the presence of all parts
> > without having 'driver-software' ready for it ...?
>
> |Not sure I follow. It might be possible to have tests for the upper
> |level of, say, a network card but allow the OS to have selected the
> |driver required.
>
> You just hit an open wound. It was/is hard to create hardware-'drivers'
> without enough detailed information from manufacturer.
|I'm surprised it was possible!
by disassembling 'drivers' for windoze/Loonix/Mac delivered by vendors.
> ... Do you use PCI
> to tell the machine to use the LFB instead of the VGA memory?
> You mean the range A0000...Bffff as VGA-memory ? aren't this LFB ? :)
> There is nothing to tell. Oh, I think to now understand your question,
> the BIOS-default text-mode '03' isn't a VESA-mode and uses 0xB8000...
> while all VESA-reported graphic modes show the LFB (same as in PCI).
> And I check for presence of addon-RAM very early in the startup to
> get a complete list of all available memory (by reading PCI-config).
|Yes, I mean the memory from A0000 which is limited to 128k AFAIR.
...
> I remember the awful CGA/EGA 16 color 4-plane story now and I'm really
> happy to have LFB-access today. My standard is 1024*768(8 or 32 bit).
<q>
> I remember the awful CGA/EGA 16 color 4-plane story now and I'm really
> happy to have LFB-access today. My standard is 1024*768(8 or 32 bit).
1024 * 768 at 32-bit is about 3 Mbytes. Far too much to fit in to the
128k from A0000. Hence I think of the LFB as somewhere where the
display memory has been mapped in to the address space. Presumably at
some point you tell the hardware to use the LFB in a VESA mode rather
than to use the VGA-or-similar memory.
</>
128k from A0000. Hence I think of the LFB as somewhere where the
display memory has been mapped in to the address space. Presumably at
some point you tell the hardware to use the LFB in a VESA mode rather
than to use the VGA-or-similar memory.
No need to tell anything to the hardware, just access the given LFB...
This olde VGA-address mapping seem to be almost obsolete anyway today.
__
wolfgang
Rod Pemberton
May 15, 2013, 4:42:38 AM5/15/13
to
"James Harris" <james.h...@gmail.com> wrote in message
news:b5ebb95b-3a89-4276...@k5g2000vbq.googlegroups.com...
> On May 11, 7:55 pm, "Rod Pemberton"
<do_not_h...@notemailnotq.cpm>
> wrote:
> > Is this environment executed
> > prior to the OS install, or does this execute on the OS
> > itself?
>
> The emulator you know about. Some tests should run on the OS
> itself but I think they would come later, once the OS is
> running.
>
Have you pitched the idea on other OS groups or forums? E.g.,
<do_not_h...@notemailnotq.cpm>
> wrote:
> > Is this environment executed
> > prior to the OS install, or does this execute on the OS
> > itself?
>
> The emulator you know about. Some tests should run on the OS
> itself but I think they would come later, once the OS is
> running.
>
OSDev.org's forums? Last I checked there were more guys involved
in OS development there than here...
> > If the latter, the OS/driver, or a limited version of it, must
> > respond properly PRIOR TO testing for some devices in order to
> > boot. If the former, then you need another simpler version of
> > the OS or another simple OS to do testing, yes?
>
> I'm not sure I understand your comment. Only a few devices are
> needed for the OS to boot. There are many other items of
> hardware.
mentioning a virtual environment. Basically, I assumed you'd be
running under a non-virtualized OS, like Linux or Windows, or
you'd code your own test environment that ran before the
testsuite. If you coded your own test environment, then some of
the hardware drivers would actually need to function prior to the
ability to perform tests on the drivers or using them, e.g.,
keyboard, mouse, drive interface, video.
> > > 3. The test suite verifies that the OS/driver reports errors
> > > for other hardware behaviour.
> >
> > How exactly do you force hardware failures to generate the
> > correct errors with working hardware?
>
In the other post, you stated that my "encouraging responses were
unexpected" since you were aware I was "not keen on such things".
While true, this issue #3 here is why I was "excited". It's not
so easy to test certain features of real hardware or the OS.
Also, setting up a test platform requires a standardized method to
test the feature, but each OS is different. With a single
designated virtual machine, the testing support will be standard
to anyone who uses that virtual machine. With a non-virtualized
OS, you could have many different methods, none the same, just to
test one feature, i.e., a new test is required for each OS for
each feature. The virtual machine adds the "commonality" I was
asking about previously. It also adds the ability to modify and
test the OS without recompiling the OS to add hardcoded test
cases, etc. I.e., I thought you found a good solution to the
issues I recognized as problematic or difficult. Honestly, I
didn't realize scripting and testing for an emulated OS were
features available in a virtual machine... I was aware debugging
is usually available, but I have a strong preference for printf()
debugging. I've run QEMU a few times, trivially. There seemed to
be some neat features of QEMU, like built-in (16-bit to 32-bit)
binary translation (or something like that...). But, I couldn't
figure out to access it. My memory is a bit vague on that, but if
it's in there, the converted code would be good for providing
equivalent 32-bit routines for 16-bit BIOS calls. Bochs just
looked too annoying/difficult to bother with. Anyway, if I ever
get back to my OS project, I'll definately take a more in-depth
look at VirtualBox. I probably won't give up on real hardware,
but the VM could offer me another sanity check or filter.
Rod Pemberton
James Harris
May 15, 2013, 1:03:06 PM5/15/13
to
On May 15, 9:42 am, "Rod Pemberton" <do_not_h...@notemailnotq.cpm>
wrote:
> "James Harris" <james.harri...@gmail.com> wrote in message
James
wrote:
> "James Harris" <james.harri...@gmail.com> wrote in message
> news:b5ebb95b-3a89-4276...@k5g2000vbq.googlegroups.com...> On May 11, 7:55 pm, "Rod Pemberton"
> <do_not_h...@notemailnotq.cpm>
>
> > wrote:
> > > Is this environment executed
> > > prior to the OS install, or does this execute on the OS
> > > itself?
>
> > The emulator you know about. Some tests should run on the OS
> > itself but I think they would come later, once the OS is
> > running.
>
> Have you pitched the idea on other OS groups or forums?
No. Feel free....
> <do_not_h...@notemailnotq.cpm>
>
> > wrote:
> > > Is this environment executed
> > > prior to the OS install, or does this execute on the OS
> > > itself?
>
> > The emulator you know about. Some tests should run on the OS
> > itself but I think they would come later, once the OS is
> > running.
>
> Have you pitched the idea on other OS groups or forums?
James
0 new messages