Subject: Linux-Development Digest #811
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Thu, 9 Jun 94 22:13:08 EDT

Linux-Development Digest #811, Volume #1          Thu, 9 Jun 94 22:13:08 EDT

Contents:
  port access function definition? (Kwun Han)
  Making a Boot disk for Gateway 2000  (was LI040404) (Lee J. Silverman)
  Re: Device or resource busy (repost) (Richard Whittaker)
  Re: Linux game development (Was Re: Why [DOS, W (Mark Lord)
  Re: SMP supprot for Linux???? (Josh Johnson)
  Re: Linux ext2fs vs. ufs vs. presto [was Re: Fast File System?] (Linus Torvalds)
  Re: assembly language & Linux (ATTN!) (Ken Pizzini)
  Re: Filesystem semantics protecting meta data ... and users data (Burkhard Neidecker-Lutz)
  Re: Filesystem semantics protecting meta data ... and users data (Frank Lofaro)
  WARNING: BUG in rsh?? (Pedro de las Heras)
  Re: Filesystem semantics protecting meta data ... and users data ("Alexander During")
  Re: My problem? GCC problem? Linux problem? (Ken Pizzini)
  1.1.16 on faulty hardware (Rafal Maszkowski)
  Q: making shared libs (Matthias Reineke)
  Re: Does Linux use any BIOS facilities? (Mark Evans)

----------------------------------------------------------------------------

From: kwh@cs.brown.edu (Kwun Han)
Subject: port access function definition?
Date: Thu, 9 Jun 1994 20:04:26 GMT

Hi,

        I am trying to interface to a card which need to use word
io. I saw #define of outw, etc in asm/io.h, however, I have looked
through then entire kernel source and have not found __outwc_p or any
other similar definitions. I get undefined errors when compiling the
kernel. I wonder if any god like person can tell me where they are or
what I need to do.

Thanks,
Kwun
-- 
=================================================================
kwh@cs.brown.edu (preferred)    | Box #2392, Brown University,
kwh@lems.brown.edu              | Providence, RI 02912
Kwun_Han@brown.edu              ------------------------------
GE/CS d? p c++(+++) l(++)+++ u e+ m++@ s+/- n+@ h* f(+) g+ w+ t r-
=================================================================

------------------------------

From: ljs@cs.brown.edu (Lee J. Silverman)
Crossposted-To: comp.os.linux.admin
Subject: Making a Boot disk for Gateway 2000  (was LI040404)
Date: 9 Jun 94 16:44:35


        Well, I solved my problem with creating a boot floppy to get
my Gateway 2000 going.  I thought it would be appropriate for me to
share the recipe with everyone.  If anyone else is dealing with this,
I hope this helps!

        The original problem is that Gateway's large IDE drives have
more than 1048 cylinders, which means you can't install LILO on them
easily.  The easiest solution is to boot from a floppy disk.  Here's
how to make the disk.

(This assumes that your floppy drive is device /dev/fd0 (drive A:) and
that your root partition should be /dev/hda2.  These should be easy to
fix if this doesn't apply to you.)

1)Buy an HD disk

2)Format it with the command:
%>fdformat /dev/fd0H1440   (/dev/fd0H1200 for HD 5.25's, I think)

3)Repartition it with fdisk.  type:
%>fdisk /dev/fd0
The machine will tell you that you need to give it a disk geometry.
Type "x" to get to the expert menu, then:
(h)eads=2
(c)ylinders=80
(s)sectors=18
Type "r" to return to the main menu.  If you look at the partition
table now, it's a mess.  I'm not sure I understand why.  In any case,
the next move is to delete all four partitions with the "d" option.
Just type d...1 d...2, etc.
Now make a new partition with the "n" command: it should be a primary
partition, starting at track 1 and ending at track 80 (numbers will
vary for a 5.25 disk).
Finally, write the partition table to disk with the "w" command.

4)Make a filesystem on the disk.  My favorite filesystem is ext2fs, so
I use:
%>mke2fs -c /dev/fd0

5)Now you can mount the disk:
%>mount -t ext2 /dev/fd0 /flop   (/flop must exist first!!)

6)Make directories on the disk, and copy the hooks for the devices,
the boot sector image, and the kernel to the floppy with these
commands:
%>mkdir /flop/dev ; cp -a /dev/* /flop/dev/
%>mkdir /flop/etc
%>mkdir /flop/boot
%>cp -a /boot/boot.* /flop/boot/
%>cp -a /vmlinuz /flop/vmlinuz
(The linux kernel is installed on your hard drive by Slackware 1.2.
You could use any kernel for this, though.)

7)Make the LILO configuration file: /flop/etc/lilo.conf
Here's a sample one that I used.  
====================
#Sample LILO Conf file for Gateway 2000 using 540 Meg HD
boot=/dev/fd0
delay=25
vga=normal
ramdisk=0
compact

image=/vmlinuz
        read-only
        root=/dev/hda2   # (change this if your partitioning is different)
        append = "hd=1048,16,63"    # (cyls, heads, sectors)
        label=Linux
===============================
Note that nothing in this file refers to /flop; it considers /flop to
be the root directory.  If you want to add a message, add the line
message=/etc/message and then create a file /flop/etc/message with
your message in it.

8)Install LILO on the floppy with the command:
%>lilo -C /etc/lilo.conf -v -r /flop
The -C option tells LILO what configuration file to use, -r tells it
to treat /flop as if it were the root directory /

--
Lee Silverman, Brown class of '94, Brown GeoPhysics ScM '95
Email to: Lee_Silverman@brown.edu
Phish-Net Archivist: phish-archives@phish.net
"Nonsense - you only say it's impossible because nobody's ever done it."

------------------------------

Crossposted-To: comp.os.linux.admin
From: rwhittak@orion.docwhitehorse.doc.ca (Richard Whittaker)
Subject: Re: Device or resource busy (repost)
Date: Thu, 9 Jun 94 15:25:54 GMT

Rob Janssen (rob@pe1chl.ampr.org) wrote:
: In <1994Jun8.032048.8650@clark.dgim.doc.ca> rwhittak@orion.docwhitehorse.doc.ca (Richard Whittaker) writes:

: >my SLIP connection is over one of the ports on my Digiboard.. :-(.. Does
: >anyone have a more "agressive" version of the serial driver that works with
: >1.1.18, or do they have any suggestions as to how I can "slap the existing
: >one around a bit" to make it more aggressive in asserting interrrupts.. 
: You should get the "setserial" program and use it in /etc/rc or one of
: the files called from there.

Unfortunately, using setserial rendered the same results.. I get "device or
resource busy" errors with setserial as well.. :-(.. As I said, I remember
running into the problem a while back, and the solution was to replace the
serial driver with an older "more aggressive" version, which up til now has
worked.. Unfortunately, the serial driver has been changed so extensively in
1.1.18 that this trick no longer does the job.. :-(.. Thanks muchly for the
suggestion, though!.. Onwards and sideways.. :-)

                                        Cheers,
                                        Rich W. 

--
Richard Whittaker: Snailmail: 1102 Pine St, Whitehorse YT Y1A 4E8
  Internet E-Mail: rwhittak@orion.docwhitehorse.doc.ca 
Geographic Coords: 60 Deg., 45', 53" N., 135 Deg., 7', 17" W. 
    Amateur Radio: VY1RW, VY1RW@VY1DX, VY1RW@VY1BBS, 145.010 MHz         

------------------------------

From: mlord@bnr.ca (Mark Lord)
Subject: Re: Linux game development (Was Re: Why [DOS, W
Date: 9 Jun 1994 16:46:39 GMT

In article <2t79bs$abm@styx.uwa.edu.au> luyer@tartarus.uwa.edu.au writes:
>James Ojaste (jojaste@undergrad.math.uwaterloo.ca) wrote:
..
>OK, maybe Linux will "run" in 2mb of RAM, but it must be a different
>Linux to mine.  Or at least differently installed.
>
>I tried Linux with 2mb (but fixed the problem by going to 8mb).
>
>First I got an Oops [0002] from the kernel, and then it tried to
>free up memory - it killed task 0 [swapper] and sat there crashed.
>
>This was SlackWare Linux install standard "bare" 1.44m boot disk.
>(1.2.0 and the one before)

Not suprising, since those boot disks immediately try to dedicate 1.44MB
of RAM to a ramdisk.. 
-- 
mlord@bnr.ca    Mark Lord       BNR Ottawa,Canada       613-763-7482

------------------------------

From: jdjohnso@comp..uark.edu (Josh Johnson)
Subject: Re: SMP supprot for Linux????
Date: 9 Jun 1994 16:50:26 GMT

rob@pe1chl.ampr.org (Rob Janssen) writes:

>In <2t3b5t$20k@wizard.uark.edu> jdjohnso@comp..uark.edu (Josh Johnson) writes:


>>    I was wondering if there was any development going on for symmetric
>>multi processors under Linux? I was thinking about trying thids for my
>>senior design progject. I'm no t sure if I'll be up to it by then but I think
>>I might like to try. BTW I wouldn't be working alone. Any thoughts on this
>>would be appreciated.

>I was wondering if you were reading the newsgroups before posting?
>You must be the 50th that comes up with this :-(

>Rob

  No I don't usually read this group, mainly because I don't have hours of time
to spend reading every news group I might have an interest in. Since you 
apparently know something on this subeject maybe you would be kind enough to 
provide some information. I'm sorry if I offend by not reading every post to 
this group.

Josh 


------------------------------

From: torvalds@cc.Helsinki.FI (Linus Torvalds)
Crossposted-To: comp.sys.sun.admin
Subject: Re: Linux ext2fs vs. ufs vs. presto [was Re: Fast File System?]
Date: 9 Jun 1994 18:17:19 +0300

In article <1994Jun6.073403.4235@wavehh.hanse.de>,
Martin Cracauer <cracauer@wavehh.hanse.de> wrote:
>
>SunOS-4.1.3 has a policy to have asynchronous writes for data, but
>inodes and other superinformation is always written immedeatly. So, a
>crash could only affect files that a written at that moment. I think
>Solairs 2 does this, too. Does anybody know?
>
>There was a patch for SunOS 4.1.3 to make the BSD-Filesystem writing
>inodes async, too. That speeds up writing a large number of little
>files by a factor of 2 to 3. Of course, a crash could really hurt now
>that superinformation could be damaged.
>
>I would relly like to know what the standard behaviour of Linux is. If
>someone know, please tell us.

The standard behaviour for linux is to write everything asynchronously,
as others have already pointed out. I'd just like to put in my two cents
for why this is done:

 - synchronous writes are slow.  You'll lose *lots* of performance.  I
   tend to think that you can trust the hardware, and just ignore the
   minor problems you can get with asynchronous writes - the benefits
   far outweigh the problems IMNSHO. 

 - doing synchronous writes on meta-data is broken: you'd really need to
   do synchrnonous writes on data too to be safe.  BSD does metadata
   synhronously to give you a sense of security and ignores the actual
   file data -- they too did a trade-off in efficiency and security. 
   They just did a better job at trying to fool people into thinking
   it's a good idea.. 

Remember: fsck can clean up the filesystem metadata if you crashed (and
metadata is the only thing the FFS tries to do synchronously), so why
pay the overhead of doing the same thing at runtime? Yes, you can get
such corruption that fsck gives up in horror but if you had that bad a
crash, you'd probably have been screwed anyway even with synchronous
write.  How many of you have gotten that kind of filesystem corruption
under linux without it being a device driver of hardware problem (which
a filesystem couldn't fix anyway)?

Final question: what's the use of "safe filesystems" if the hardware
itself isn't safe? Who do you think you're kidding? If the harddisk
crashes on you (or even gets just one bad sector) you won't be safe even
if you write *everything* synchronously.  So why take the performance
hit? (yes, I know about RAID etc, and I don't care.  I don't have that
kind of hardware, and I don't think most people here wanting a "safe"
filesystem do either). 

                Linus

PS.  As if you didn't notice, you pushed a button.  I think sync writes
are stupid, and find some of the FFS proponents attitudes irritating. 
Logbased filesystems at least make sense, even though I don't
particularly want to run them myself. 

------------------------------

From: ken@coho.halcyon.com (Ken Pizzini)
Subject: Re: assembly language & Linux (ATTN!)
Date: 9 Jun 1994 18:59:12 GMT

In article <2t7g2b$dq8@gradient.gradient.com>,
Phil Mucci <phil@gradient.com> wrote:
>       I would like to place a request that future Linux authors
>use as little assembly as possible in their programs. This is primarily
>due to the fact that the Atari and Amiga ports of Linux are progressing
>very rapidly. It is conceivable that someday in the future, the source
>bases will be merged. 
>
>       Us 680x0 people thank you,

For the forseeable future I will still be on a x86 based machine, but
I wholeheartedly agree: please only use assembly when you absolutely
must.  Linux may have been born on a 386, but for it to thrive it
will need to expand out into the myriad CPUs of the world.

(If you think you need assembly for performance reasons, try using
C first -- it will help you debug your algorthms, it will permit
the inefficient code to at least run on other platforms, and you can
profile the code to see where coding in assembly (or a better algorithm!)
would help most.)

                --Ken Pizzini

------------------------------

From: neideck@nestvx.enet.dec.com (Burkhard Neidecker-Lutz)
Crossposted-To: comp.benchmarks,comp.sys.sun.admin
Subject: Re: Filesystem semantics protecting meta data ... and users data
Date: 8 Jun 1994 07:09:34 GMT

In article <idletimeCr1Ao6.81w@netcom.com> idletime@netcom.com (Totally Lost) writes:
>
>Read first, then write .... one point of the posting was that ordered
>writes correct 95% of the reason programmers are forced to use O_SYNC
>to protect database updates.

My point was that most file system operations on UNIX system don't
require that much consistency and that for these the normal file
system semantics are ok as a default.

> O_SYNC was a stupid solution to the problem
>in the first place. Ordered writes with commit operations solves the
>entire problem without the huge performance penalty.

I was advocating more for fsync(2) than O_SYNC. But you are correct that
this is different from ordered writes and commits (which is in a sense
what's used inside Advfs on DEC OSF/1, though it's a more complex
transaction mechansim with write-ahead logging).

>Why is it that you can not understand the gains possible with ordered
>writes? I guess it's just because you don't take the time to think ...
>or can not ...

Err, I do, and Advfs uses an even more clever mechanism without the need
of changing applications or the file system semantics (thank you, Digital
does understand production systems). The VMS operating system has all sorts
of facilities like that in the file system, but more often than not the
performance impact of having these semantics as the *default* rather than
available only where needed is very high.

If you really want transactional safety and semantics, use a database or
transaction monitor. If you're rather into *implementing* one of those,
DEC OSF/1 has all the facilities to do asynchronous I/O and inserting 
appropriate synchronization as part of it's AIO facility (both to
raw devices as well as to file systems).

                Burkhard Neidecker-Lutz

Distributed Multimedia Group, CEC Karlsruhe 
Advanced Technology Group, Digital Equipment Corporation
neideck@nestvx.enet.dec.com


------------------------------

Crossposted-To: comp.benchmarks,comp.sys.sun.admin,comp.security.unix
From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: Re: Filesystem semantics protecting meta data ... and users data
Date: Thu, 9 Jun 94 16:51:18 GMT

In article <2t6u8dINNnhf@usenet.pa.dec.com> neideck@nestvx.enet.dec.com (Burkhard Neidecker-Lutz) writes:
>In article <DHOLLAND.94Jun8134511@husc7.harvard.edu> dholland@husc7.harvard.edu (David Holland) writes:
>>
>>This is how it happens, as the original poster presented it:
>
>NOT
>>
>>              file Y is deleted --->
>
>so blocks are being released, causing metadata to be updated *on disk*
>before any other file gets a chance of reusing that block.
>
>>                                      <--- file X is written, using
>>                                           blocks formerly from file Y
>
>Which are zero-filled at that time.
>
>>      file Y's inode is written --->
>
>Can't happen now (after all, Y was deleted and hence it's inode
>is *gone*). Even if Y was truncated by ftruncate(2), that would have
>been noted on disk *before* the blocks could be gotten at from
>X.
>
>>                                      <--- file X's inode is written
>>                                 <CRASH>
>>                                      <--- file X's data was never written
>>
>>Now, after recovery and reboot, file X contains some blocks that used
>>to be in file Y... which still contain the data from file Y.
>>
>>Security breach.
>
>Maybe on UNIX V6 15 years ago.
>
>>I don't know if this is actually possible with current filesystems;
>>I'd hope not, but...
>
>Can't speak for SUN :-), but can't happen on any modern UNIX I know.
>

What about Linux ext2fs?
Can it happen on it?

>               Burkhard Neidecker-Lutz
>
>Distributed Multimedia Group, CEC Karlsruhe 
>Advanced Technology Group, Digital Equipment Corporation
>neideck@nestvx.enet.dec.com



------------------------------

From: pheras@inf.uc3m.es (Pedro de las Heras)
Subject: WARNING: BUG in rsh??
Date: Thu, 9 Jun 1994 19:33:20 GMT

Hello to every body  


When you do:

rsh remotehost command -option

the arguments to command (-option) are processed by rsh, not by 
command on remotehost. I believe it's a bug, because it doesn't work
this way on NetBSD, SunOS and SystemV.  Isn't it?



Best regards
- Pedro de las Heras
-- 
---
Pedro de las Heras Quiros       

Internet:  pheras@tornasol.uc3m.es   //   snail-mail:

------------------------------

From: 63912i@cfi.waseda.ac.jp ("Alexander During")
Crossposted-To: comp.benchmarks,comp.sys.sun.admin
Subject: Re: Filesystem semantics protecting meta data ... and users data
Date: 9 Jun 1994 05:09:52 GMT

>>I've raised this point a dozen times, even at the usenix meeting where the
>>Berkeley guys first presented their concept of sync written meta data ...
>>and they didn't have a clue since they were one-tracked on making the
>>system clean from fsck point of view ... not from the users or data base
>>managers point of view. If the users/production data is corrupt, the
>>filesystem is corrupt!! PERIOD!!

I think it is about time to stop that silly thread. Apart from the rather
disgusting style of 'idletime's postings, the discussion is rather far-
fetched. The point is: There are circumstances under which a filesystem
can be harmed by system crashes. The likelyhood of such an event depends
on a) the typical crash frequency, which is determined by the skill of
the sysadmin and the OS, as well by the hardware, and b) the stability
of the filesystem under such crashes, which depends on the kind of crash
and the FS itself.

First and foremost, no FS is save against a head scrubbing over the HD,
so there is no perfect way out. It may be useful to argue which risks
are more worthy to protect against, but this thread is seemingly not
directed at that kind of analysis.

The main problem involved is a tradeoff between time and security. A
filesystem that writes synchronously (like DOS) forces the hardware
to read a sector, change one byte and write that sector back each time
a byte is written, which is slow. It is not perfectly safe, however,
which is something everybody who has worked under DOS will readily
agree with. So asynchronous writes have the undisputable advantage of
being faster, while aggravate the severity of crashes, that still may
well harm even completely synchronous writes.

From one of the enlightening postings of Mr. idletime, we could gain the
fact that he has experienced 3 losses of data in 19 years. This is not
something that I would call a risk. Please consider the likelyhood of
getting run over by a car in 19 years which you spend by crossing a
street 8 hours a day. I bet you'd get run over more often (nowadays
probably only once, however), and still you do it. There are just 
chances that one has to take.

In my opinion there is nothing much to discuss. idletime has raised that
point a dozen times infront of experts and they probably threw him out
and so he tries to infest this newsgroup. Just let him have his fun, but
don't waste the time of the people who read this for information by 
posting too many replies; it's getting annoying.

Just my 2 Yen.

Alex



--
As MS-DOS is very abstruse, \\it's also quite tricky to use. \\So many give in
and try typing 'win'. \\But that means completely to lose.
Alexander D\"uring, Physics Department, Waseda University, Tokyo, Japan.
Statistical Physics, Linux, Shakespeare. --- This space for rent ---

------------------------------

From: ken@chinook.halcyon.com (Ken Pizzini)
Subject: Re: My problem? GCC problem? Linux problem?
Date: 9 Jun 1994 06:41:09 GMT

In article <ablumer.771128485@hubcap>,
Aric D. Blumer <ablumer@hubcap.clemson.edu> wrote:
>Given this code:
>
>> void example(s)
>> char *s;
>> {
>>      *s = 'h';
>>      }
>> void main()
>> {
>>      example("Hello!");
>>      }
>
>Should this code cause a Segmentation fault?
>It does running Linux 1.0 and compiled with GCC 2.5.8!
>It doesn't on my Sun.

Let's put it diplomatically: it is permitted to blow up.
ANSI says that the string constant in your code may be placed
in read-only memory.  Gcc, by default, does.


>I'm porting some code that does something similar and
>it always faults.

If you absolutly must write code like that, use the
"-fwritable-strings" to gcc.  Better still, fix your code.

(Example rewrite of main():
    void main() {
      static char data[] = "Hello!";
      example(data);
    }
)

                --Ken Pizzini

------------------------------

From: rzm@oso.chalmers.se (Rafal Maszkowski)
Subject: 1.1.16 on faulty hardware
Date: Wed, 8 Jun 1994 08:16:13 GMT

My poor little thing (386DX/20, 6 MB RAM) has a hardware bug somewhere.
crashme or small assembler program posted some time ago crash it very
fast or immediately.  The sequence used in this assembler program
shouldn't happen in real compiler output but it seems that this (or
maybe another similar piece of code) happens to be in kernel. As a
result the kernel crashes typically once per day or two.

I was VERY suprized to see 1.1.16 running for ten days without problems
(only a connection to tsx-11 was hanging with 24KB in a queue for several
days) and dying finally with:
eth0: DMAing conflict in ne_block_output.[DMA stat:fffffffe][irqlock:ffffffff]
(I could make some small typing errors)

I know there is no way to deal with this hardware bug but how it was
possible that it isn't so bad with 1.1.16? Maybe there is some way to
avoid the bug, at least for 10 days... Maybe bug triggering code is not
very healthy also for normal hardware?

R.
--
Rafal Maszkowski rzm@oso.chalmers.se rzm@mat.uni.torun.pl <-finger for public
snail: Omgangen 464-82, 412-80 Goteborg, Sweden; tel: +46-31-7780831      key
Opinia publiczna powinna byc zaalarmowana swoim nieistnieniem   -  St. J. Lec

------------------------------

From: n24927@pbhrzx.uni-paderborn.de (Matthias Reineke)
Crossposted-To: comp.os.linux.help,comp.os.linux.misc
Subject: Q: making shared libs
Date: 9 Jun 94 15:43:53 GMT


Hi,

i try to make shared libraries of libtiff.a, libjpeg.a and libmagick.a.
How can i evaluate the values for the jump table size and the
Global Offset Table (GOT) size? 

Here is the output of getsize (getsize >jump.vars-new) for libtiff:

> jump.vars-new:

0000028e K _TIFFFaxWhiteCodes   libtiff        tif_fax3
0000028e K _TIFFFaxBlackCodes   libtiff        tif_fax3
00001400 K _TIFFFax2DMode       libtiff        tif_fax3
00001400 K _TIFFFax2DNextState  libtiff        tif_fax3
00001400 K _TIFFFaxUncompAction libtiff        tif_fax3
00001400 K _TIFFFaxUncompNextState libtiff        tif_fax3
0000e600 K _TIFFFax1DAction     libtiff        tif_fax3
0000e604 K _TIFFFax1DNextState  libtiff        tif_fax3
00000730 K _tiffFieldInfo       libtiff        tif_dirinfo
00000034 K _tiffDataWidth       libtiff        tif_dirinfo

> size.nm:

00000000 T _TIFFFaxWhiteCodes
0000028e T _TIFFFaxBlackCodes
0000051c T _TIFFFax2DMode
0000191c T _TIFFFax2DNextState
00002d1c T _TIFFFaxUncompAction
0000411c T _TIFFFaxUncompNextState
0000551c T _TIFFFax1DAction
00013b1c T _TIFFFax1DNextState
00022120 T _tiffFieldInfo
00022850 T _tiffDataWidth
00022884 T __done

Ciao,
  Matthias Reineke

------------------------------

From: evansmp@mb5194.aston.ac.uk (Mark Evans)
Subject: Re: Does Linux use any BIOS facilities?
Date: Thu, 9 Jun 1994 17:18:44 GMT

Rob Janssen (rob@pe1chl.ampr.org) wrote:
: In <1994Jun8.160547.10423@ll.mit.edu> kpl@ll.mit.edu (Kevin P. Lawton) writes:

: >I'm curious if Linux uses any of the ROM BIOS facilities
: >which are inherent to the PC, or if it exclusively uses
: >its own facilities which are loaded upon booting.

: Linux does not use the ROM BIOS, because it is unusable in a 32-bit
: protected mode environment.  So, it uses its own drivers that directly
: control the hardware.

However the bootstrap code does use the bios to load the kernel.
After that the BIOS is redundent.


------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************
