Re: harddisc device drive

[Torsten Scherer <itschere@techfak.uni-bielefeld.de>]

 Next episode from this story...

 Erling Henanger wrote:

> id>  1) Use the DEVDRV read/write calls but watch out that data is always ali
> id> to 512 byte boundaries.
> 
> I would go for this solution. Keep a 512 byte buffer in your driver, so
> read/writes not fitting 512 byte boundaries comes/goes to this buffer.
> You could look at the cdrom device in ehscsi if you ever get into a.a.
> This does the same thing for cdroms as ps0 does for floppies.
> (except that it cannot write, of course :-)

 Looks like this is the preferred way. But I'm a bit uncertain about why
keeping a buffer for non aligned read/writes: If the file is defined to be
a harddisc there isn't very much point in read/write from non 512 byte
boundaries. AHDI itself also doesn't allow you to read 67 bytes from the
374.14th sector... ;)

> What do you use to get the partition info ?
> The pun structure (from ahdi > 3.x), or do you read sector 0 on each disk ?

 Well, actually not only sector 0, but some more... :)

 I've got such a beast running now with Rwabs(), say I can do things like
"cp /dev/sd0a /dev/null" and such.

 BTW: It has always been said that AHDI doesn't give you access to partitions
which are not of type GEM or BGM. But when I changed the id of one of mine in
the XGM chain to see if my driver still gets it (it does) I noticed that AHDI
also stops following the XGM chain as soon as it meets the first illegal (in
its opinion) partition, making the following invisible. Is that also official
documented behaviour? It happened with AHDI 5.00 and results in a restriction
in the way you partition your drive if you still want to be backwards
compatible... :-(

> Email me private, and I'll send the stuff to you.
> Or try msdos.archive.u.e/mac.archive.u.e/amiga.archive.u.e....

 Thanx, I've got it in the meantime, so I'll start screwing up my HD soon... ;)

> Don't know anything about ICD though, so I'll leave that for others to
> answer.

 Er, well, obviously they seem to have thought the same... :(

 Another thing: After Nox has given the first of the reserved[] parameters
in struct dev_descr a meaning, I'd like to suggest to use the second to
supply a file mode for the to-be-installed device. This way drivers can
install S_IFBLK devices and won't need to Fchmod() directly after the install
to restrict access. Diffs are very short, but sorry, relative to plain 1.11b...

ciao,
TeSche
--
Torsten Scherer (TeSche, Schiller...), itschere@techfak.uni-bielefeld.de
Faculty of Technology, University of Bielefeld, Germany, Europe, Earth...
| Use any of "finger itschere@129.70.131.2-15" for adresses and more.	|

--- file.h.orig	Sat Sep  3 19:37:22 1994
+++ file.h	Sat Sep  3 19:38:00 1994
@@ -535,7 +535,8 @@
 	short	flags;
 	struct tty *tty;
 	long	drvsize;		/* size of DEVDRV struct */
-	long	reserved[3];
+	long	fmode;
+	long	reserved[2];
 };
 
 
--- biosfs.c.orig	Sat Sep  3 19:37:30 1994
+++ biosfs.c	Sat Sep  3 19:39:58 1994
@@ -822,6 +822,7 @@
  *	   short  flags			flags for the file (e.g. O_TTY)
  *	   struct tty *tty		tty structure, if appropriate
  *	   long   drvsize;		size of driver struct
+ *	   long   fmode			XATTR mode the device should have
  *
  * Dcntl(0xde00, "U:\DEV\BAR", n): install a new BIOS terminal device, with
  *     BIOS device number "n".
@@ -871,6 +872,8 @@
 		b->tty = d->tty;
 		b->drvsize = d->drvsize;
 		set_xattr(&(b->xattr), S_IFCHR|DEFAULT_MODE, UNK_RDEV|devindex);
+		if (d->fmode)
+			b->xattr.mode = (short)d->fmode & 0177777;
 		devindex = (devindex+1) & 0x00ff;
 		return (long)&kernelinfo;
 	    }