A generic API for all types of devices

[t-w]

The main ideas:

• make a simple, generic and unified API for all types of devices
• provide a simple way for creating other, used-implemented types of devices (one of such devices is ramdisk, proposed and implemented by @kyz, hooked so far as a "native" device)

[lclevy]

Hi, That's a good idea. But hardisk have specific structure like rigid disk block, no ? What would be the difference classes of devices, towards 'dump' ?

[t-w]

Mounting remains different for hard disks (with rigid blocks). These changes are for block-level device access only.

Some time ago, I made a change (for #17) making 2 levels of accessing ADF devices:

• opening-closing: for device block level access (only), to allow, for instance, formatting an empty device
• mounting-unmounting: available when volume information is already on the device; mounting a device is basically required to access (mount) its volumes

In 0.8.0, this was not quite properly separated (mounting was doing opening, for instance... this was in a way to preserve compatibility with earlier code). Now it is really separated, so a device has to be first opened, then mounted (mounting is an operation on an already existing and opened, or created, ADF device).

And as I wrote above - mounting devices is unchanged. (though it may be worthy to look a that also, as I am not sure yet if there is really need to distinguish "native" devices - the only place using it is adfmountDev, to do exactly MountHDFile vs MountHD; I do not quite understand the difference, yet).

[t-w]

Btw. you can have a look at the changes in the commit above.

There are still some (probably minor) things to correct (tests with autotools failed for some reason) but all the major changes are already there.

[lclevy]

This looks good! I trust your work 👍

[t-w]

So, according to this piece:

RETCODE adfDevMount ( struct AdfDevice * const dev )
{
    if ( dev == NULL )
        return RC_ERROR;

    RETCODE rc;

    switch( dev->devType ) {
[...]

    case DEVTYPE_HARDDISK: {
        uint8_t buf[512];
        rc = adfDevReadBlock ( dev, 0, 512, buf );

       /* BV ...from here*/
        if( rc != RC_OK ) {
            adfEnv.eFct ( "adfMountDev : adfReadBlockDev 0 (bootblock) failed");
            return rc;
        }

        /* a file with the first three bytes equal to 'DOS' */
        if ( ! dev->drv->isNative() &&
             strncmp ( "DOS", (char *) buf, 3 ) == 0 )
        {
            rc = adfMountHdFile ( dev );
            if ( rc != RC_OK )
                return rc;
        }
        else {
            rc = adfMountHd ( dev );
            if ( rc != RC_OK )
                return rc;                              /* BV ...to here.*/
            }
        }
        break;
[...]

the information whether a device is "native" or not is used only to prevent mounting "native" device as an unpartitioned, single volume device (like a floppy or an hdf without rigid block, so without geometry and partition information). While, if I understand well, this is not a valid case for Amiga which, I suspect, had nothing in OS to detect hard disk geometry. That is why rigid blocks are required - so that special tools could detect geometry of the device and write it on the first sectors of disk so that the OS could use it. Is that right?

If it is so - then we do not need this information in the ADFlib. If someone wants to create a single volume on the whole device (without partitioning), the library should be able to open it (like an HD file). But, of course, it is useless on real Amiga which will not be able to know device geometry...

There would be a point to have this "native" info if ADFlib was used on Amiga - but I do not think it is ever the case. It would be like carrying coals to Newcastle...

So I would remove this "native" attribute and, if the disk starts with "DOS", let it mount as any HD file, regardless if the device is "native" or not.

What do you think?

(btw - what is this "BV" acronym that appears sometimes in the comments to the code? It seems like marking something but it is not clear what it means, at least in English, en Francais ca peut etre "bien vu", n'est-ce pas? ;-)

[t-w]

The "native" attribute is kept - it will allow to know which device should have a real geometry (which should come from the hardware).

(cont. on geometry matters in t-w#4)