As I gather, an append "mem=LESS-THAN-ALL-PHYSICALLY-AVAILABLE-RAMM" sets
aside the difference D between ALL and LESS-THAN-ALL as a RAMdisk, with
all your RAMdisk memory being contiguous.
Quite a trick. The style is "old" as opposed to the use of "scatter-gather"
DMA (or ultra-DMA?), apparently. In the "new" style you use some other
statement to set up a group of memory addresses scattered about in RAM, but
totalling the size of your new-style RAMdisk. (Reminds me of hard disk
defrag .)
In the "append" style, the addresses to read/write to are known to be the
last D ones of RAM.
Hopefully, someone more expert can tell us both exactly what the new-style
way of setting aside a RAMdisk is...? And how it to address it to read and
write to it.
Maybe they can tell us what the basis for it is. Where does the capacity for
using the "new" method come from? That is, what is the difference
physically and sofware-wise (e.g., BIOS?) that lets you use the "new"
method? How do you test for it? What is more "direct" about Direct Memory
Addressing (DMA)? And Ultra DMA?
When do you choose the append style, and when do you want the new style?
For instance, would your choice change depending on your reason for setting
up a RAMdisk? They seem to be used:
1.--To run in RAM --
The RAMdisks are often used to boot and run in RAM (sometimes without using
hard disk space; mulinux can do this starting from a floppy, see
mulinux.nevalabs.org; in Slackware linux, Zipslack boots up this way).
2.--For Data communication--
Or the RAMdisk can be used as a blackboard. For example, the RAMdisk could
serve as a blackboard to which a data-acquisition card [driver] and both
Linux and RTL can read and write: hence the Sharedness of the memory.
3.--To bridge to Flash memory or [assymmetrical] Multiple Processors--
RAMdisks can be handy in hard disk systems, and in "diskless" systems such
as flash-memory based ones, and in embedded systems for sharing information
between the main OS (or OSes!) and one embedded in a special-purpose card
that has its own CPU (e.g., see National Instruments card 7030 from their
catalog or ni.com).
Maybe they are of use for Symmetrical Multiple Processors (SMP) too -- is
that how SMP systems work?
More questions than answers,
seems to be part of the nature of our enterprise...!
SC
At 12:25 PM 20-01-2001 +0100, you wrote:
>On Wed, Jan 17, 2001 at 09:00:50PM -0800, Estabridis, Janet P wrote:
>> # mkbootdisk --device /dev/fd0 2.2.14-rtl2.3
>>
>> It has the lilo.conf in the /etc directory.
>>
>> I want to add the statement
>>
>> append="mem=125M"
>
>Hi.
>
>What does the lilo.conf look like _at the moment_?
>From what you wrote (and I was able to understand), your rtl-system
>_is_ booting alright from the floppy and only the memory-statement is
>ignored?
>
>My questions aim at a missing piece of information in your mail (or
>my mental transcription).
>I can only say, that I have never had a problem with append=... in the
>lilo.conf, i.e.:
>append="hdd=brenner floppy=daring mem=256M hdd=ide-scsi hdc=ide-scsi"
>This line is read, whichever kernel I boot, rtl or normal 2.2.16.
>
>Bye,
>
>Michael.
>--
>Michael Uplawski <[EMAIL PROTECTED]> / <[EMAIL PROTECTED]>
>PGP: RSA/IDEA 2048 Bits 0x19847a51
>Fingerprint: AC C1 2F 8F 59 9C FF 3C 6D A8 67 4A 45 3E 4C F2
>(GnuPG d/e on request)
>Es lebe H[a,e]cker!
>-- [rtl] ---
>To unsubscribe:
>echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
>echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
>---
>For more information on Real-Time Linux see:
>http://www.rtlinux.org/rtlinux/
>
>
>
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
