someone smarter than Dave Cutler
in [Device Drivers]
|
From: glen herrmannsfeldt on 1 Apr 2010 14:22 In alt.sys.pdp10 Patrick Scheible <kkt(a)zipcon.net> wrote: (snip) > IBMs were leased. Would IBM continue to support a computer that had > some academics' experimental hardware hooked up to it? Could new and > experimental device drivers be added to IBM's OS? These might be as > important as the machine's architecture. As I/O devices, I believe so. There are plenty of stories about adding I/O devices to S/360 systems. Once the device is connected, there isn't really any driver needed. All you need is the ability to write channel programs, and the OS to allow you to execute one for the specified device. That which is called device drivers on most systems is done by access method services for OS/360. It is done in user mode (that is, not supervisor mode) and only when the final channel program is ready is it checked (to make sure it does only what it should do) and executed. -- glen
From: alberto on 1 Apr 2010 14:25 My mistake about Sabre, my memory's gone - it's been many, many moons since I worked with that kind of stuff. And I worked in Europe at the time, hence my view of the U.S. market was a bit tilted. Still, wasn't Sabre there even before PANAMAC ? You make my point yourself, that we had production level worldwide computer communications and real-time systems quite before TCP/IP saw the light of day. As for SNA and DCA, they were quite cool, and they worked like a charm. On IBM and Univac gear. On whatever communication links we could get from the Post Offices of the time. Alberto. On Mar 31, 9:50 pm, John Levine <jo...(a)iecc.com> wrote: > >Before TCP/IP ever was, starting in the early 60's, IBM/360 systems > >ran all the airline reservations in the western world, together with > >Univac 1100 and 494 systems, and Univac 418 machines ran the SITA > >network on which worldwide computer communication was based: the Panam > >Sabre system > > Now, now, SABRE was American, Pan Am's system was PANAMAC. The > original SABER (they changed the spelling at some point) ran on 7090s > but was ported pretty quickly to 360s. > > > Even before TCP/IP became fashionable, during the seventies, people > > were working on the communications architectures of the times: SNA, > > DCA, BNA, and so on, which evolved into X25 and X21. > > Well, yeah. I gather they were using telex links before that. > > R's, > John
From: Mark Crispin on 1 Apr 2010 14:35 On Thu, 1 Apr 2010, Patrick Scheible posted: > IBM's competitive advantage was in highly reliable data processing. > Businesses going with IBM paid a premium for that reliability. This reliability was primarily in their peripherals. Nobody who ever dealt with any IBM OS would call it reliable. I still cringe at the memory of an IBM 360/67 running OS/360+HASP; and with Call-OS (shudder!), APL\360, ATS, and CourseWriter as timesharing systems each doing (SHUDDER!!) PSW stealiing. A good day was when the system would crash only once while you were using it. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote.
From: alberto on 1 Apr 2010 14:40 The simple act of running device drivers in Ring 1 instead of Ring 0 - and maybe using Ring 2 for user-side services - would have sorted things out quite nicely. We could have had a totally nonpageable Ring 0 kernel and a pageable Ring 1. It would also have made it quite hard to hack the kernel from outside. The whole of the i386 architecture was designed with that kind of operation in mind, but people instead were sort of blinded by RISC and went in the direction of not using all that cool hardware. Even today, I still believe that it would make a lot of sense to run i/ o from Ring 1, on those machines that still implement it. Alberto. On Mar 31, 4:17 pm, Jonathan de Boyne Pollard <J.deBoynePollard- newsgro...(a)NTLWorld.COM> wrote: > >> No one knew ho big NT was going to be, and no one knew what the > >> effect of paging kernel code would be. Once there was a running > >> system people could play with it and try out things like that. > > > I don't buy this argument. NT was OS/3, and designed squarely to take > > on Novel Netware. > > ... which didn't have a pageable kernel, either. So your argument isn't > sold, too. (-: > > There's a better argument earlier in this thread. I'll repeat it, > because it seems that people have skipped completely over it so that > they can stick with the same "Dave Cutler doesn't know anything." > mindset that they are comfortable with. There are a few good reasons > for not having a pageable kernel that I can see, not the least of which > is that Microsoft is writing an operating system into which third-party > device drivers are loaded. Others may not think of this as a > development concern, but it certainly is to Microsoft. One of the > things that Microsoft is, institutionally, very well aware of is the > daft things that third party programmers do. It devotes a lot of time > to accommodating daft programming practices, and at least some thought > to how to avoid creating opportunities for further such time sinks. > Making kernel mode pageable would have opened up a whole vista of new > possibilities for third party device and filesystem driver programmers > to do things wrongly. Maybe that was forseen. Certainly history has > shown that it did indeed work out that way. If one hangs out in the > various kernel-mode programming discussion fora, and reads the books, > articles, and other documentation on the subject, one realizes how often > "No, you may not do that at DISPATCH_LEVEL or higher." is the answer.
From: Don Burn on 1 Apr 2010 14:45
Having worked on Data General 32-bit OS'es that were cursed by rings, I am glad Microsoft was smarter than that. It is ironic that people still keep suggesting rings when the Multics architects who had a lot to do with rings, were running around in the late 1970's telling anyone who would listen all the horrors of rings. Don Burn (MVP, Windows DKD) Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr > -----Original Message----- > From: alberto [mailto:amoreira(a)ieee.org] > Posted At: Thursday, April 01, 2010 2:41 PM > Posted To: microsoft.public.development.device.drivers > Conversation: someone smarter than Dave Cutler > Subject: Re: someone smarter than Dave Cutler > > > The simple act of running device drivers in Ring 1 instead of Ring 0 - and > maybe using Ring 2 for user-side services - would have sorted things out quite > nicely. We could have had a totally nonpageable Ring 0 kernel and a pageable > Ring 1. It would also have made it quite hard to hack the kernel from outside. > > The whole of the i386 architecture was designed with that kind of operation in > mind, but people instead were sort of blinded by RISC and went in the > direction of not using all that cool hardware. > > Even today, I still believe that it would make a lot of sense to run i/ o from > Ring 1, on those machines that still implement it. > > > Alberto. > > > > > On Mar 31, 4:17�pm, Jonathan de Boyne Pollard <J.deBoynePollard- > newsgro...(a)NTLWorld.COM> wrote: > > >> No one knew ho big NT was going to be, and no one knew what the > > >> effect of paging kernel code would be. Once there was a running > > >> system people could play with it and try out things like that. > > > > > I don't buy this argument. NT was OS/3, and designed squarely to > > > take on Novel Netware. > > > > ... which didn't have a pageable kernel, either. �So your argument > > isn't sold, too. �(-: > > > > There's a better argument earlier in this thread. �I'll repeat it, > > because it seems that people have skipped completely over it so that > > they can stick with the same "Dave Cutler doesn't know anything." > > mindset that they are comfortable with. �There are a few good reasons > > for not having a pageable kernel that I can see, not the least of > > which is that Microsoft is writing an operating system into which > > third-party device drivers are loaded. �Others may not think of this > > as a development concern, but it certainly is to Microsoft. �One of > > the things that Microsoft is, institutionally, very well aware of is > > the daft things that third party programmers do. �It devotes a lot of > > time to accommodating daft programming practices, and at least some > > thought to how to avoid creating opportunities for further such time sinks. > > Making kernel mode pageable would have opened up a whole vista of new > > possibilities for third party device and filesystem driver programmers > > to do things wrongly. �Maybe that was forseen. �Certainly history has > > shown that it did indeed work out that way. �If one hangs out in the > > various kernel-mode programming discussion fora, and reads the books, > > articles, and other documentation on the subject, one realizes how > > often "No, you may not do that at DISPATCH_LEVEL or higher." is the answer. > > > __________ Information from ESET Smart Security, version of virus signature > database 4993 (20100401) __________ > > The message was checked by ESET Smart Security. > > http://www.eset.com > |