Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!samsung!aplcen!haven!udel!mmdf From: postmaster@att-in.att.com Newsgroups: comp.os.minix Subject: (none) Message-ID: <8382@nigel.udel.EDU> Date: 16 Jan 90 17:10:19 GMT Sender: mmdf@udel.EDU Lines: 69 Mail to `att.att.com!attmail!mhs!envoy!ics.test/pn=_test_group' alias `att!attmail!mhs!envoy!ics.test/pn=_test_group' from 'VM1.NoDak.EDU!INFO-MINIX%UDEL.EDU' failed. The error message was: destination unknown or forwarding disallowed The message began: Received: from NDSUVM1.BITNET by VM1.NoDak.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 0592; Tue, 16 Jan 90 06:52:58 CST Received: from NDSUVM1.BITNET by NDSUVM1.BITNET (Mailer R2.03B) with BSMTP id 0581; Tue, 16 Jan 90 06:52:57 CST Date: Mon, 15 Jan 90 16:51:38 GMT Reply-To: INFO-MINIX%UDEL.EDU@VM1.NoDak.EDU Sender: Minix operating system Comments: Warning -- original Sender: tag was info-minix-request@UDEL.EDU From: Bruce Evans Subject: Re: Booting Minix from 1.44m floppies Comments: To: info-minix@udel.edu To: Multiple recipients of list MINIX-L In article <7961@nigel.udel.EDU> Peter_Van_Epp@cc.sfu.ca writes: [Aubrey McIntosh writes] >>Why not just seek to track 40? >[...] >Because some 5.25s will get to track 41, and because the floppy >controller doesn't know how many tracks the drive has (and in >at least some cases neither does the drive except via a mechanical >stop!) This is one reason I don't much like the idea of a "media sensitive" floppy device. Even the floppy driver itself can only guess! Paul Allen suggested detecting the media type in the dev_open routine for the floppy device. This routine lives in FS and would have a hard time getting the necessary information from the existing floppy driver. It should be just a stub which asks the floppy driver to decide. The driver would return mainly the size of the device (which can be stored into the inode field so existing code works). My changes to FS in 1.5 would be better if they knew how many blocks per track are on the device. The floppy driver can do a better job than now, without bashing the heads. I added code to the 1.5 driver to read the sector ids off the disk. This can be used used to count the number of sectors by reading track 0. (I once use the ids to handle a couple of ancient weird formats with track 0 special.) If the wrong rate or steps_per_cyl is tried, I think there will be an error between tracks 0 and 1. So looking at tracks 0 and 1 gives a lot of info, enough to determine the index 'd' into the tables in the floppy driver, except for types 0 and 2 (360K and 720K). This is slow, and too much work for a guess. Yet the DOS method of relying on the parameter block is no good. If there is no parameter block, DOS has to give up. I prefer the other idea of encoding the device type in the minor number. We should also consider encoding the type in the device name, e.g. /dev/fd2s80t10s (360K disks formatted to 800K in an AT drive!). The advantage is that the driver need not be changed to handle minor variations - 80t10s looks like 80t9s and ancient 40t8s looks like 40t9s. To provide for both cases, dev_open could build a message containing the minor number and the device name, and rely on the floppy driver to decide the size and other useful info. There is little need to keep the media-sensitive device. For booting, a DOS-style parameter table can be used. Earl Chew's "shoelace" boot program already does this. In 1.5, FS knows which device contains the root image (e.g. 1.5 can boot from /dev/at0, then read the root file system off /dev/at1) and will have no trouble with the encoding. Now the default is in and this can be changed at boot time. Shoelace is more flexible. The default is in a text file /etc/config and it will be easy to convert the DOS parameter block to a device number, so everything will be automatic. -- Bruce Evans evans@ditsyda.oz.au