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
