struct IOFileSys

[Einstein]

Hello, I've written a test code sending FSA_IS_FILESYSTEM message to some filesystem handlers.

I receive correct replies from filesystem-like handlers like ram.handler and pipefs.handler, I receive no replies from non-filesystem-like handlers like zero.handler etc. and on real filesystems like afs sfs and fat the system just crashes.

I wonder if there's something wrong with my code (I assume so, I have almost zero experience with doing exec IO, and I have not programmed for a while).
One special thing I wonder about is when I perform:

Code: [Select]

struct IOFileSys * fsRequest;
..
fsRequest = (stuct IOFileSys *) CreateIORequest( fsReplyPort, sizeof( struct IOFileSys) );

Doing that obviously only initializes the embedded IORequest, question is do the non-IORequest members of IOFileSys (fsRequest) also need to be initialized somehow ?

Anyway here's the code:

Code: [Select]

#include
#include
#include
#include

int main( int argc, char * argv[] )
{
    struct MsgPort * fsReplyPort;
    struct IOFileSys * fsRequest;

    if( argc == 2 )
    {
        fsReplyPort = CreateMsgPort();
        fsRequest = (struct IOFileSys *) CreateIORequest( fsReplyPort, sizeof( struct IOFileSys ) );
    OpenDevice( argv[ 1 ], 0, (struct IORequest *) fsRequest, 0 );

    fsRequest->IOFS.io_Command = FSA_IS_FILESYSTEM;

    DoIO( (struct IORequest *) fsRequest );

    /* After DoIO() above, the boolean fsRequest->io_Union.io_IS_FILESYSTEM.io_IsFilesystem
    will hold TRUE if handler is a real filesystem , FALSE otherwise */

        if( ! fsRequest->io_DosError )
        {
            if( fsRequest->io_Union.io_IS_FILESYSTEM.io_IsFilesystem == TRUE )
            {
                printf( "Handler is a filesystem!\n" );
            }
            else
            {
                printf( "Handler is NOT a filesystem!\n" );
            }
        }
        else
        {
            printf( "Error occured while performing IO\n" );
        }

    CloseDevice( (struct IORequest *) fsRequest );
    DeleteIORequest( (struct IORequest *) fsRequest );
    DeleteMsgPort( fsReplyPort );
    }
    else
    {
        printf( "wrong number of argmuments\n" );
    }

    return 0;
}

[Mazze]

I'm suggesting that you post your question on AROS-Exec or join the Developer Mailing List.

[Piru]

Errorchecking would be nice.

ATM you can't tell if it crashes due to not being able to open the device for example.

[Einstein]

@Mazze

Would be nice if there were some activity here though, but sure, how and where do I get into the dev ml ?

@Piru

You're right, I'd better do that.


By the way I didnt realize that the device name and unit number i give to OpenDevice() are placed in fsRequest->io_Union.io_OpenDevice.io_DeviceName and fsRequest->io_Union.io_OpenDevice.io_Unit respectively ?!

What's going on, I thought OpenDevice() only knew of an IORequest and nothing more, does it check what the handler is and then understands what structure to use, or does it send a message (struct IOFileSys) to dos.librarys message port ? (which means its dos.library that actually goes about opening the device ?) I know this is most probably also the same in AmigaOS, so what's happening ?

*EDIT*

If it's dos.library that gets a message (struct IOFileSys *) from Exec (OpenDevice()) then I assume it's quite similiar to other oprating systems that have servers for different services, like filesystems.

[Mazze]

Einstein wrote:
@Mazze

Would be nice if there were some activity here though, but sure, how and where do I get into the dev ml ?

Read "Subscribing to AROS-Dev" at the link I've given above.

[Einstein]

Pardon, my eyes must be in vacation  :crazy:

[Einstein]

I use Opera 9.10 as my primary browser, this is the message I get from Opera when trying to subscibe:

- The server's name "mail.aros.org" does not match the certificate's name "www.hepe.com;www.mutschler.de;www.hepe.com". Somebody may be trying to eavesdrop on you.
- The certificate for "www.hepe.com" is signed by the unknown Certificate Authority "CA Cert Signing Authority". It is not possible to verify that this is a valid certificate

Is this normal ? (I'm such a noob :-D )

[Mazze]

Einstein wrote:

- The server's name "mail.aros.org" does not match the certificate's name "www.hepe.com;www.mutschler.de;www.hepe.com". Somebody may be trying to eavesdrop on you.
- The certificate for "www.hepe.com" is signed by the unknown Certificate Authority "CA Cert Signing Authority". It is not possible to verify that this is a valid certificate

Is this normal ? (I'm such a noob :-D )

I'm getting a similar message with Firefox when I try to read the archive. After clicking "OK" I can continue.

BTW: subscriptions are handled manually, so it will take some days.

[Einstein]

Ok, I've subscibed now..

*EDIT*

By the way, one of us is an imposter, there can be only one!  :lol:

[Thomas]

What's going on, I thought OpenDevice() only knew of an IORequest and nothing more

OpenDevice does not even know of an IORequest. It just loads the code into memory and then calls its open vector. Everything else is done by the device itself.

Bye,
Thomas

[Einstein]

Thomas wrote:

OpenDevice does not even know of an IORequest. It just loads the code into memory and then calls its open vector. Everything else is done by the device itself.

Ok, this this raises alot of questions I didnt properly think about before, I would really like to have this made clear to me.

There are Devices and there are Handlers.
Handlers (usually) operate a level above the devices and implement the DOS device abstraction.
Devices, are a level beneath the handlers. They implement the raw communication with the physical devices, and only figure as a backend to handlers that that need the service of a a device (driver).

Some handlers (non-filesystem-like ones) like nil.handler zero.handler (an maybe con.handler, I wouldnt know) etc obviously do not need a device (driver).

A second type of handlers (filesystem-like ones) like ram.handler, pipefs.handler etc would not (should not, but there is ramdisk.device! ) either need a device driver.

A third type of handlers (real filesystems) obvioulsy would need the devices to perform the raw IO.

So here I am, trying to fit some pieces of the the puzzle together to have a more clear view of how the system operates and what I'd need to perform to do what i'd want to do,

I know I could hack myself to some answers and read the source for others, the latter I'll avoid for now since some of the sources of minor components are very unclean to say the least.

First and foremost, OpenDevice loads, say, afs.handler, then you say it calls its open vector ? what does this "open" do ? obviously the handler is loaded already, I assume it "opens" the IORequest ?! or rather, the eventual low level device name, in io_Union.io_OpenDevice.io_DeviceName (read below paragraph) it would need if it was a real filesystem ?
What about the unit I send to OpenDevice() ? does it get passed along with IOrequest ? that is, does the handlers "open" routine take the unit and itself place it into fsRequest->io_Union.io_OpenDevice.io_Unit ? this would be useless as the union would be overwritten,
What about fsRequest->io_Union.io_OpenDevice.io_DeviceName ? this simply cannot contain the name I pass to OpenDevice(), what would be the point ?

So, the only conclusion I make for now is that the members of io_Union.io_OpenDevice, if filled, will instruct the handlers "open" routine to load and use io_Union.io_OpenDevice.io_DeviceName as its raw device driver backend with io_Union.io_OpenDevice.io_Unit as the unit.

Am I making somewhat correct assumptions or am I drunk ?

[Thomas]

then you say it calls its open vector ? what does this "open" do ?

This is too basic and would be too much to explain here. Read the RKRM chapters about how to write a library and then how to write a device. Devices are similar to libraries.

OpenDevice loads, say, afs.handler

Well, it's not supposed to do this. In AmigaOS there is a clean distinction between an exec.library device and a dos.library handler/filesystem. I am really surprised that AROS has added functionality to exec.library to work with dos.library internals.

What about the unit I send to OpenDevice() ? does it get passed along with IOrequest ?

Yes, it does. But as I already said, read the RKRM about libraries and devices. You need to know how a device works if you want to use internal functionality of one.

that is, does the handlers "open" routine take the unit and itself place it into fsRequest->io_Union.io_OpenDevice.io_Unit ?

Yes, the io_Unit field is for the device's own purpose. Exec.library does not use it.

this would be useless as the union would be overwritten,

There is no union in a real IORequest. This is a misusage of the AROS people.

However, a handler/filesystem has no use for a unit number. So in order to return information about itself it can as well use the unit field in the IORequest.

IMHO this is really strange thing of AROS. AROS claims to be source compatible to AmigaOS. But imagine if the authors of PFS3 wake up and try to recompile their filesystem for AROS, they will have major difficulties. All programs which try to OpenDevice() PFS3 will crash. They first will have to turn their software into a library. AFAIK handlers/filesystems on AmigaOS aren't libraries but simple executables. And they have to add functionality for the above scenario.

Bye,
Thomas

[Piru]

@Thomas

Indeed, this design is quite puzzling.

If FSA_IS_FILESYSTEM is going to crash some handlers, it's useless as identification system anyway...

[Einstein]

@Thomas, I do have the RKRM: Libraries and RKRM: Devices, but I dont bother with them since they are in AmigaGuide format (I've hardly read anything in them, its a mess clicking around in a labyrint), now I'd like to have them in PDF format..

[Einstein]

@Mazze

What happened ? It's almost two weeks ago I subscribed now.