In article <telecom24.427.13@telecom-digest.org>, TELECOM Digest
Editor noted:
> [TELECOM Digest Editor's Note: But I still do not understand _how_
> the network card, or PCMCIA or whatever is able to do that job without
> first itself getting installed by (for example) Windows or whatever OS
> is in the terminal/workstation. I mean, that would be great if I could
> just turn on the laptop and have its OS installed by the desktop Win
> 2000. But how? PAT]
It is *simple*. The 'minimum necessary' code for operating the
network card is included in the ROM BIOS. this is *not* much. it
includes the code to (1) do a "RARP" request to find out the ethernet
address it should use, (2) do a 'broadcast' query for a TFTP server,
(3) send a 'get IPADDRESS_IN_HEX' request to that server, and (4)
access the remote required file-system image (directory structure)
from a file-server, via some network file-sharing protocol (NFS, SMB,
etc.).
Given that the 'network card' is built in to the machine, then 'how to
talk to it' can be "hard-coded" into the BIOS -- because it *is*
"known" what kind of a network card is installed, and thus the actual
code to communicate with the card is unchanging. Thus, the amount of
code required to implement that necessary sequence of network commands
is *very* reasonable in size -- as in 'a few kbytes".
It's no different, in basic concept, from how a computer knows how to
load the O/S from a hard-disk -- *before* the hard-disk driver is
'installed' in the O/S. This _is_ why, it is known as the 'bootstrap
loader' process. It has 'just enough' smarts to talk to the boot
device (floppy, hard-disk, network card, cassette tape drive {remember
*those}, or 'whatever') to load in a bigger block of instructions that
provide the additional 'smarts' to load the next bigger piece of the
O/S in to memory. "lather, rinse, repeat" as needed, until you have
the entire O/S loaded.
".. but how?" requires setting up a machine to act as a 'boot
server'.
It has to have a table of Ethernet card _MAC_ addresses, along with
the IP address that should be assigned to that MAC address. And be
running the server program that will dispense that information when
requested.
It has to be running a TFTP server process to deliver the boot image
when requested by the client machine. this means that you also have
to have copies of the appropriate 'system' files under the appropriate
name(s) in the TFTP server's working directory.
The machine must also be running the programming that causes it to
identify itself as a boot server, when the 'broadcast' query is made.
Lastly, _some_ machine -- not necessarily the same machine as the
'boot' server -- must provide the "system" filesystem files, via a
network file- sharing protocol.
None of this is particularly 'rocket science', but it does require a
fair bit of "systems administration" and 'network administration'
knowledge, to set up all the requisite pieces, and have them play
nicely _together_. request.
UNIX and Unix-like systems have known how to do this for 20+ years.
Novell "Netware" supported the concept from the later part of the
1980's, for Netware "client" machines.
Microsoft "didn't do networks" until 'Windows for Workgroups', and
"Microsoft Networking" did not support 'booting over the network'.
I don't know *if* it is possible to boot a MS O/S from the network,
although modern MS O/S's do have the required tools for being a 'boot
server' to 'diskless' clients.
Robert Bonomi (bonomi@host122.r-bonomi.com)