someone smarter than Dave Cutler
in [Device Drivers]
|
From: Jim Stewart on 31 Mar 2010 15:48 Mark Crispin wrote: > On Tue, 30 Mar 2010, Pat Farrell posted: >> Jim Stewart wrote: >>> Setting that aside, and it's a big set-aside, I question >>> how much the PDP-10 was responsible for building the >>> internet. My understanding is that PDP-11's, Vaxen and >>> IMP's built the early internet. > > When it comes to Internet history, Jim Stewart is blowing farts out his > anus and claiming that they are facts. > > I was there in the 1970s. Yeah, but I try hard not to be an arrogant jerk. And if you'll reread my post, you'll see that it might be my understanding is incorrect, not my claim of fact. In any case, I thought about this whole thread long and hard last night. What really mattered was the people, not the processor. Was the PDP-10 itself critical to the the accomplishments that you listed, or was it clever people that had easy access to good computing hardware? Could the AI groups have done their work on a pair of 360/67's? Could they move TCP/IP packets and resolve hosts, given a proper interface? Seems like you're willing to make the researchers (and that would include yourself) subservient to the computer.
From: Charles Richmond on 31 Mar 2010 16:36 Pat Farrell wrote: > Jim Stewart wrote: >> Setting that aside, and it's a big set-aside, I question >> how much the PDP-10 was responsible for building the >> internet. My understanding is that PDP-11's, Vaxen and >> IMP's built the early internet. > > Vaxen were much later. > > Many of the early nodes on the Arparnet/Dapranet were aimed at > connecting PDP-10 and Tenex systems. The IMPs were minicomputers, or in > IBM speak, IO controllers. > > The very first IMPs were specialized, then PDP-8s, and later PDP-11. > IMP's were network controller cards with a thyroid problem... ;-) -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+
From: Charles Richmond on 31 Mar 2010 16:51 jmfbahciv wrote: > Mark Crispin wrote: >> On Tue, 30 Mar 2010, Pat Farrell posted: >>> >>> [snip...] [snip...] [snip...] >>> >>> The very first IMPs were specialized, then PDP-8s, and later PDP-11. >> >> No. >> >> PDP-8s were never used as IMPs; nor to my knowledge was a PDP-8 ever >> connected to the ARPAnet. >> >> PDP-11s were (briefly) used as Internet routers before being replaced >> by microcomputer based devices (e.g., early cisco routers). They were >> never IMPs. >> > PDP-8s were the first CPU when a user would use to get at the PDP-10. > Think about dial-ups and TTYs which were "far away" from the DC-10s. > Users didn't see the 8s but those systems were used to answer the > phones. > I remember devices called "terminal concentrators" that were attached to our IBM 370/155 at college. For our DEC-20/50, I do *not* know how the terminals were supported. Someone posted that the PDP-11 *inside* the DEC-20 handled terminal I/O for the -20. -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+
From: Jonathan de Boyne Pollard on 31 Mar 2010 16:17 > >> >> The retrospective view is useful, too. The concern that a pageable >> kernel was addressing was how much RAM PC/AT compatibles generally >> had at the time. In 2004, Raymond Chen wrote an article noting that >> the pageable kernel prevents Windows NT from booting and running from >> a USB drive, something that people didn't want to do back in the >> early days of Windows NT but certainly want to do nowadays. One >> commenter observed in response that Linux, with a non-pageable >> kernel, can be booted and run from such a drive, observing: "Looks >> like Dave's conservative engineering design sense might have been >> right after all.". >> > When NT was in public beta test, it required 32MB of ram, miminal > configuration. This was a problem, because in 1991 or so, most PC > motherboards could not directly address more than 16MB, due to > hardware constraints. The commodity PCs used a windowing scheme where > memory was read from the disk into the bottom 16MB and moved up. > Highly inefficient. Perhaps IBM's machines did it properly, but it was > rare for generic PC/AT to do it well at all. Micron did it, but they > were primarily a memory vendor making PCs to sell more memory. > Untrue. The motherboards could directly address more than 16MiB. Processors had no trouble with this at all. The problem was the third-party DMA facilities on the (E)ISA bus, which could not. Hence the double-buffering and complex ISA bus third-party DMA APIs that one can find in many PC/AT operating systems to this day. (Consider all of the hoops involved in IoMapTransfer()/MapTransfer() and related functions in Windows NT, for example.) The double-buffering is a software artifact, not a hardware one, and so is independent of motherboard manufacturer. There would have been no difference between IBM and "generic" in this regard. This is all explained in Microsoft KnowledgeBase article 101349.
From: Jonathan de Boyne Pollard on 31 Mar 2010 16:17
> >> >> 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. |