I don’t want to be a kill joy here, but most of what has been described
should be in the first course in a systems track.
Here’s what WPI and RPI offer as just plain old operating systems:
RPI
OPERATING SYSTEMS
Topics include analysis of multiprogramming systems, virtual memory,
computer system performance, and queuing theory. The course also discusses
tools for synchronization of parallel programs and algorithms for mutual
exclusion
WPI
CS 502. OPERATING SYSTEMS
The design and theory of multiprogrammed operating systems, concurrent
processes, process communication, input/output supervisors, memory
management, resource allocation and scheduling are studied
I’ve taken both graduate level operating systems and advanced operating
systems and having written a simple (repeat simple) general purpose
multi-programmed operating system with virtual memory and a general device
model for the former I would have been dissapointed if the latter was a
course in writing drivers. That kind of stuff really is material for a
seminar from the good people at OSR or the good people at Sun Microsystems
Educational Services or the good people who know which ever platform you
want to develop drivers for.
I don’t want to present myself as a authority on what should be in an
advanced OS class, but CMU has this to say:
18-841 Advanced Operating Systems and Distributed Systems
Fall: 12 units
This course examines the design and analysis of selected aspects of
operating systems and distributed systems. It covers topics such as
concurrency and distributed communication; fault-tolerance, availability,
and persistence; and operating system structure. Lecture focus on the
principles used in the design of operating systems and distributed systems,
and algorithms and data structures used in their implementation. Readings
include case studies, seminal papers, and recent conference and journal
articles. Note: this course is tuned and targetted for research-oriented
graduate students.
WPI’s Advanced OS class follows similar lines.
I imagine that a course could use an exercise in writing drivers to
illustrate some of these concepts, but it certainly shouldn’t be the only
focus of the course.
Todd
-----Original Message-----
From: PeterGV [mailto:xxxxx@osr.com]
Sent: Thursday, October 11, 2001 12:05 PM
To: NT Developers Interest List
Subject: [ntdev] Re: What do we need to know as far as OS
techniques go
?“Moreira, Alberto” wrote in message
> news:xxxxx@ntdev…
> >
> > What do you think they should learn as far as WDM and Kernel Mode
> > development is concerned ? What basic skills are needed for young
> > professionals to get started in our kernel and driver
> development world ?
> > How far is far enough in a 16-week two-hour-a-week lab course ?
> >
>
> Well, I can tell you what you need to know before you come to an OSR
> seminar…
>
> Michal Vodicka is right on target:
>
> > They should know about synchronization primitives, processes and
> > threads, IPC, interrupts, memory management etc. and now
> should learn how
> > theoretical concepts are implemented on different OSes.
> Compare and show
> how
> > to use them and mainly explain why.
>
> To amplify:
>
> - Wait locks versus spin locks
> - Threads and processes: What’s these are in the NT world
> versus the Unix
> world
> - What we mean by “thread safe”, fully re-entrant, and MP
> safe (thanks Jean)
> - Processor modes (man, if they don’t know that by the time
> they get to
> “advanced OS”…)
> - Memory management - User mode, versus Kernel Mode. What we mean by
> “demand paged virtual memory”
> - Multiple, Nested, Interrupt Levels
> - How user threads/processes get the system to do work for
> them: In other
> words, the flow of a system service (and hence an I/O
> request) from user
> mode down to the driver down to the device.
> - Port space versus memory space
> - SOMEthing, PLEASE, about the hardware path that data
> travels from a device
> to memory during an I/O transfer. Perhaps, oh dare I dream,
> that there is
> more than one way to connect an I/O bus to a memory bus?
> Work through a few
> block diagrams: North bridge, south bridge, etc. Show 'em
> some NON-X86
> architecture diagrams, please, where the I/O bus is NOT
> directly connected
> to the memory bus, but is rather interfaced some other way (think “map
> registers”)
> - SOMEthing about how devices work: What a device register looks like,
> why/when devices interrupt
>
> If somebody were to attend one of our seminars and know the above
> information, it would be a relative breeze to learn how to
> write a driver
> for XP.
>
> Peter
> OSR
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@greshamstorage.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com