Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1+some 2/3/84; site dual.UUCP Path: utzoo!watmath!clyde!floyd!harpo!ulysses!mhuxl!ihnp4!dual!mats From: mats@dual.UUCP (Mats Wichmann) Newsgroups: net.unix-wizards Subject: Re: Terminal paging in the kernel Message-ID: <334@dual.UUCP> Date: Thu, 8-Mar-84 16:49:38 EST Article-I.D.: dual.334 Posted: Thu Mar 8 16:49:38 1984 Date-Received: Sat, 10-Mar-84 07:23:20 EST References: <6841@cca.UUCP> <690@ihuxx.UUCP> <216@masscomp.UUCP> Organization: Dual Systems, Berkeley, CA Lines: 21 <> Without getting too involved in the terminal paging issue (other than to note without justification that I oppose it) I wanted to comment on the statement that we are making assumptions about the sizes of disk drives in the kernel. WE are most definitely not making any assumptions about disk sizes in the kernel - we encode this information on a reserved area on the disk. On the first access to a drive, this reserved area is read, and the number of heads-tracks-sectors, the device partitions, and the bad block map (if any) is pulled in. I think you would find that many of the micro-UNIX vendors are doing the same thing: we usually have to support too many different configurations to be able to have a different kernel for each one - massive distribution headaches would ensue (especially for bad block handling). If there were a way to obtain this information for each terminal WITHOUT hardcoding it into the kernel, this portion of the paging dispute would go away - but I don't see any way to do that..... Mats Wichmann Dual Systems Corp. ...{ucbvax,amd70,ihnp4,cbosgd,decwrl,fortune}!dual!mats