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