steve@wlbreng1.UUCP (Steve Childress) (01/08/87)
..
I have written a disk driver for my 1.2 system. Works OK, uses my
own bus-to-Western Digital controller hardware interface. The drives
are a 5MB Syquest cartridge and an ATASI 40MB, 30Msec drive. Works
nicely, however I too dislike the slow program-load times arising
from the computation done by the loader for address fixup. I much
preferred OS9's position independent code strategy.
I have a question or two:
1. DISKED doesn't like the drive name "HD0:" which is what I chose
to put in mountlist. Do I have to have a "resource" of that name?
I find no discussion of this in the RKM.
2. DISKDOCTOR, when run on a healthy hard disk, seems to corrupt things.
I don't trust it for other than floppies.
3. I have not found an easy way for my driver to find the in-memory
instances of the information in the /devs/mountlist, eg., no. cylinders,
etc. The driver guide incompletely discusses the convention of passing
something like this in a register in the I/O call to OPEN device.
Anyone know? Or do I have to search the lists myself?
4. To partition a hard disk, you merely make two entries in /devs/mountlist
and issue two mount commands in your startup file. (this question arose
in other discussions here.)
Regards,
Steve Childress
(818) 706-5247 (days)
{trwrb, scgvaxd, ihnp4, voder, jplgodo} !wlbr!wlbreng1!stevefnf@mcdsun.UUCP (Fred Fish) (01/09/87)
In article <159@wlbreng1.UUCP> steve@wlbreng1.UUCP (Steve Childress) writes: >1. DISKED doesn't like the drive name "HD0:" which is what I chose I noticed this too. Try using "DH0:" instead. That worked for me. Perhaps it only likes names that begin with D. -Fred -- =========================================================================== Fred Fish Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282 USA {seismo!noao!mcdsun,hplabs!well}!fnf (602) 438-5976 ===========================================================================
cmcmanis@sun.uucp (Chuck McManis) (01/09/87)
In article <159@wlbreng1.UUCP>, steve@wlbreng1.UUCP (Steve Childress) writes: > I have a question or two: > 1. DISKED doesn't like the drive name "HD0:" which is what I chose > to put in mountlist. Do I have to have a "resource" of that name? > I find no discussion of this in the RKM. As far as I am able to determine, DISKED should work on anything in the DeviceList with a FileSystem startup message. Did you try using DH0: to see if it was the 'H' throwing it off? It shouldn't be but you can never tell. > 2. DISKDOCTOR, when run on a healthy hard disk, seems to corrupt things. > I don't trust it for other than floppies. I have seen similar problems with DiskDoctor. It may not be able to deal with larger file systems. > 3. I have not found an easy way for my driver to find the in-memory > instances of the information in the /devs/mountlist, eg., no. cylinders, > etc. The driver guide incompletely discusses the convention of passing > something like this in a register in the I/O call to OPEN device. > Anyone know? Or do I have to search the lists myself? Good question, when you search the DeviceList do you find the correct data in the DISKENV array? You should be able cache the pointer to the Device Node since it doesn't move after the disk gets installed as a driver. > 4. To partition a hard disk, you merely make two entries in /devs/mountlist > and issue two mount commands in your startup file. (this question arose > in other discussions here.) > Steve Childress This is indeed what is required, however the driver has to know that you will be partitioning it and thus add the Offset it finds in the DISKENV array to the blocknumber passed. -- --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
farren@hoptoad.uucp (Mike Farren) (01/10/87)
In article <159@wlbreng1.UUCP> steve@wlbreng1.UUCP (Steve Childress) writes: >.. >I have written a disk driver for my 1.2 system. Works OK, uses my >own bus-to-Western Digital controller hardware interface. Are you willing to provide further info, like listings and schematics? Sounds like something I'd LOVE to have, being a long-time believer in doing it yourself... -- ---------------- "... if the church put in half the time on covetousness Mike Farren that it does on lust, this would be a better world ..." hoptoad!farren Garrison Keillor, "Lake Wobegon Days"
louie@sayshell.umd.edu (Louis A. Mamakos) (01/10/87)
I've been hacking around with Disk Device drivers lateley, so... In article <11186@sun.uucp> cmcmanis@sun.uucp (Chuck McManis) writes: >In article <159@wlbreng1.UUCP>, steve@wlbreng1.UUCP (Steve Childress) writes: >> I have a question or two: >> 1. DISKED doesn't like the drive name "HD0:" which is what I chose >> to put in mountlist. Do I have to have a "resource" of that name? >> I find no discussion of this in the RKM. I created a disk drive called "DS0:", and DiskED seemed to work just fine on it. >> 4. To partition a hard disk, you merely make two entries in /devs/mountlist >> and issue two mount commands in your startup file. (this question arose >> in other discussions here.) >> Steve Childress > >This is indeed what is required, however the driver has to know that you >will be partitioning it and thus add the Offset it finds in the DISKENV >array to the blocknumber passed. This is incorrect. The file system driver passes the absolute block number on the disk to the disk device driver. In the MountList file (or when using AddDosNode()), you specifiy the starting track number for the disk. Thus, the disk driver can be completely ignorant of disk partitions. I claim, however, that the partition information should be ON the disk. The disk device driver can read it at initialization time and create the logical disks at that time, rather than doing a Mount command. What if I pick up my SCSI disk drive and carry it to my friend's machine? I'd sure like it to work there too without hacking up any files. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
steve@wlbreng1.UUCP (01/15/87)
Could someone explain what is meant by "DISKENV"? As far as I have read
and understand, to find the in-memory rendition of the data found for
mounted disks, I must write a routine to chase the list of devices looking
for those associated with my driver (using my driver's ASCII name) and
the look for the desired sub unit by somehow knowing its ASCII name too.
I don't know how to do the latter. Sure would like to add code to my
driver so's it could automatically discover the extents of the disk
partition for any arbitrary subunit. Also-- still looking to learn what
is passed in D0 to the driver OPENDEVICE routine.
Regards,
Steve Childress
(818) 706-5247 (days)
{trwrb, scgvaxd, ihnp4, voder, jplgodo} !wlbr!wlbreng1!steveerickson@cbmvax.UUCP (01/17/87)
The current version of DiskED works fine with partition names of:
"res0:"
"TSCSI:"
"P1:"
"P2:".
I've just had to repair a problem in my partition called "P1". The older,
V1.1 era DiskED WON'T work with partitions.
Lee
--
Lee Erickson - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!erickson
but no way officially representing arpa: cbmvax!erickson@seismo.css.GOV
Commodore, Engineering Departmentcmcmanis@sun.uucp (Chuck McManis) (01/19/87)
In article <163@wlbreng1.UUCP>, steve@wlbreng1.UUCP (Steve Childress) writes:
*> Could someone explain what is meant by "DISKENV"? As far as I have read
*> and understand, to find the in-memory rendition of the data found for
*> mounted disks, I must write a routine to chase the list of devices looking
*> for those associated with my driver (using my driver's ASCII name) and
*> the look for the desired sub unit by somehow knowing its ASCII name too.
*>
*> I don't know how to do the latter. Sure would like to add code to my
*> driver so's it could automatically discover the extents of the disk
*> partition for any arbitrary subunit. Also-- still looking to learn what
*> is passed in D0 to the driver OPENDEVICE routine.
*>
*> Steve Childress
DISKENV is an array of longwords that describes your disk layout. It
contains such interesting things as the number of sectors per track,
the starting cylinder number, the ending cylinder number, the number
of heads, etc. All of the entries are documented in the include
file "libraries/filehandler.h". As it turns out the handler task that
is talking to your device automatically adds in the offset to the
first cylinder when you try to read or write file data, however if
you are using the Exec I/O calls (DoIO, SendIO, etc) then you will
have to add in this offset yourself. Chasing the device names is
fairly simple, although it might be easier to store a pointer to
your device node at startup time (when you are loaded). Currently,
as far as I can tell the default behaviour of ADOS is to insert
new devices at the head of the DeviceList, thus when you are
started your device node will be pointed to by the DeviceList pointers
in the RootNode (I think it is called DevInfo) Also the AddDevice
calls requires an address to a DeviceNode structure so assuming
your driver built its device node structure then it knows where
it is.
As it turns out there is also a Unit subfield in the DISKENV array
and that is what I pass to the OpenDevice call in D0.
Final comment is why does your driver care how the disk is partitioned?
Since the file handler takes care of that stuff for you?
--
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.steve@wlbreng1.UUCP (Steve Childress) (01/22/87)
In article <11655@sun.uucp> cmcmanis@sun.uucp (Chuck McManis) writes: >In article <163@wlbreng1.UUCP>, steve@wlbreng1.UUCP (Steve Childress) writes: >*> Could someone explain what is meant by "DISKENV"? As far as I have read >*> and understand, to find the in-memory rendition of the data found for >*> mounted disks, I must write a routine to chase the list of devices looking >*> for those associated with my driver (using my driver's ASCII name) and >*> the look for the desired sub unit by somehow knowing its ASCII name too. >*> >*> I don't know how to do the latter. Sure would like to add code to my >*> driver so's it could automatically discover the extents of the disk >*> partition for any arbitrary subunit. Also-- still looking to learn what >*> is passed in D0 to the driver OPENDEVICE routine. >*> >*> Steve Childress > >DISKENV is an array of longwords that describes your disk layout. It >contains such interesting things as the number of sectors per track, >the starting cylinder number, the ending cylinder number, the number >of heads, etc. All of the entries are documented in the include >file "libraries/filehandler.h". As it turns out the handler task that >is talking to your device automatically adds in the offset to the >first cylinder when you try to read or write file data, however if >you are using the Exec I/O calls (DoIO, SendIO, etc) then you will >have to add in this offset yourself. Chasing the device names is >fairly simple, although it might be easier to store a pointer to >your device node at startup time (when you are loaded). Currently, >as far as I can tell the default behaviour of ADOS is to insert >new devices at the head of the DeviceList, thus when you are >started your device node will be pointed to by the DeviceList pointers >in the RootNode (I think it is called DevInfo) Also the AddDevice >calls requires an address to a DeviceNode structure so assuming >your driver built its device node structure then it knows where >it is. > >As it turns out there is also a Unit subfield in the DISKENV array >and that is what I pass to the OpenDevice call in D0. > >Final comment is why does your driver care how the disk is partitioned? >Since the file handler takes care of that stuff for you? > >-- >--Chuck McManis >uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com In my driver, I want to access the info in mountlist so I can decide which physical drive is being opened. My system, like many, has multiple hard disks, and sometimes they differ in I/O techniques, e.g., stepping rate on the head positioner. My old Tandon lacks buffered seek so whenever I change drives I have to do a seek with a different stepping rate. Also, there is a driver call "tell number of cylinders" or some such which requires access to this sort of data, and it should not be hard coded. I'll study that .h file -- thanx.