From owner-freebsd-hackers Tue Aug 22 9:54: 5 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from herd.plethora.net (herd.plethora.net [205.166.146.1]) by hub.freebsd.org (Postfix) with ESMTP id 47E6F37B422 for ; Tue, 22 Aug 2000 09:54:01 -0700 (PDT) Received: from guild.plethora.net (root@guild.plethora.net [205.166.146.8]) by herd.plethora.net (8.9.0/8.9.0) with ESMTP id LAA09193; Tue, 22 Aug 2000 11:53:55 -0500 (CDT) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.9.3/8.9.0) with ESMTP id LAA11615; Tue, 22 Aug 2000 11:53:53 -0500 (CDT) Message-Id: <200008221653.LAA11615@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: bliss-s@excite.com Cc: hackers@freebsd.org Subject: Re: Advanced OS Questions only you can answer... Date: Tue, 22 Aug 2000 11:53:53 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >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