Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Aug 2000 11:53:53 -0500
From:      seebs@plethora.net (Peter Seebach)
To:        bliss-s@excite.com
Cc:        hackers@freebsd.org
Subject:   Re: Advanced OS Questions only you can answer... 
Message-ID:  <200008221653.LAA11615@guild.plethora.net>

next in thread | raw e-mail | index | archive | help
>1.  How does this OS manage process scheduling, interprocess communication,
>process synchronization, and of handling deadlocks.

These are four totally unrelated questions.  For most OS's, I'd suggest
you start with the same question, without the "how", because most don't
really do much with this.  BSD-derived systems have a variety of IPC
mechanisms, and at least a couple of algorithms that control scheduling.
As to "handling deadlocks", the OS may not handle them at all; you're welcome
to write a pair of programs that deadlock and just sit there forever.

>2.  How does the OS manage main memory and does it manage secondary storage
>to back up main memory.  I need on algorithm and one structure to show this
>management...along with how they relate to the management.

The OS manages main memory by breaking it up into 8 1/2 by 11 sections of bits
called "pages".  (The 1/2 is used for parity.)  Secondary storage is not
generally used to back up main memory; instead, the OS uses tertiary storage
to back up main memory, since this is generally more reliable.

An algorithm might be
	while (no-free-memory) {
		kill(rand(), 9);
	}

A structure could be
	struct {
		int yes;
		char *no;
	};

>3.  I need the key characteristics of the OS supporting file structures and
>access methods in regards to types of access methods, directory structures,
>data protection, and file consistency.

It's very good at all of these, across the board.  File loss is less than
300ppm, directory structures are roughly half the size of typical files, and
most common access methods are supported.

>4.  How does the OS control peripheral devices and the input/output need for
>applications regarding input/output design, interfaces, internal system
>structures.

If the peripheral devices misbehave, the OS stops providing power to them.
Your question implies that applications are "designed"; this is incorrect.
Applications are thrown together over a weekend before the release date.
The time before that is spent getting wildly drunk.

Internal system structures:  They're internal, you don't need to know.

>5.  how does the OS provide for a collection of processors including:
>  a.  processors that do not share a memory

It doesn't.

>  b.  processor that do not share a clock

It doesn't.

>  c.  storage devices dispersed among various sites

It doesn't.

>  d.  distributed file system

NFS.

>  e.  process synchoronization

It doesn't.

>  f.  process communication

It doesn't.

>  g.  failures recovery

It doesn't.

>6.  And finally, how does the OS ensure the protection and security of
>files, memory, segments, and CPU for data and code in the following
>situations:  
>  a.  Unauthorized access

It says "ERROR ERROR ERROR" in a monotone.

>  b.  mailicious destruction,

It doesn't.  No OS does.  If your data is destroyed, *it is destroyed*.

>  c.  alteration

Ditto.  If you want to make backups, go ahead.

>  d.  accidental introduction of inconsistency

Mostly this is left to hardware.

>I CAN'T THANK YOU ENOUGH FOR TAKING THE TIME TO HELP ME OUT.

But you can't be bothered to take the time to learn *ANYTHING* about the
field.  There is no way you can be experienced enough for it to make sense
for you to be assigned to research these questions, yet so inexperienced as
to make the obvious gaffes you did throughout this procedure.

The answers above, if you have any business seeking the real answers, will
help you on your way.  If they don't seem helpful, *you are not ready to
understand these questions*.

Your questions came out like someone coming to an AIDS conference and asking
why letting blood isn't helping, and whether anyone knows which humors are
affected by AIDS.

You need to learn the basics before you can get into OS internals.

-s


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008221653.LAA11615>