• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

DASD Interface

Started by mobybrick, 2009.07.20, 00:25:55

Previous topic - Next topic

mobybrick

Hi all,

Trying to do some research into the current 512Gb boot limitations.

- Look at http://www.warpdoctor.org/walter/articles/2001/bldisknotes02b.html  talks about the 32-bit strat 3 interface to OS2DASD

- Browsing the source code to the DANI driver (DANIS506, svn.netlabs.org/acpi)  it seems that it is only using the strat 2 (not 3) interface. This assumption is based on the source referencing the include file strat2.h

Questions: Would not the re-compiling of the code to use the strat3 interface improve performance, and would the using the newer API help with the 512Gb limits?

Of course, this may be well of course and I've made a lot of assumptions here... just trying to piece things together. Comments?

Thanks,
Moby

Radek

I don't think so. The pure recompiling gives you nothing.

The strat3 interface is intended for basedevs which initialize at PL 0. It contains special INIT call which runs at PL 0 and a the INIT_COMPLETE call which informs basedevs that all drivers from the config.sys are already loaded and that they can establish IPC. It itself does not bring any improvement in efficiency of the driver. Note also, that simple setting the flags to type 3 will cause that the driver will not get the standard INIT call at CPL3 but the new one at CPL0. The driver will not initialize at all - in the better case.

The 512 GB limit has a similar nature as the 8 GB limit for LBA. You cannot address more by the standard addressing using the standard interface. Bigger disks use a different addressing scheme. The driver needs adapting to this new addressing scheme.

mobybrick

But isn't strat2 16:16? Surely the 32-bit address and data interface of strat3 gives other advantages?

rudi

#3
@Radek:

I think you are confusing the device level and capability bit strip bits with
the strategy3 interface to OS2DASD. However I agree on the fact, that
it doesn't make any sense to "recompile" DANIS506.

@mobybrick:

At least from what I see in the latest DDK sources, an adapter driver will
never get any strategy3 calls. This is completely handled within (the 32bit
version) of OS2DASD, which will translate the requests into strategy2 before
passing on to the adapter driver. Maybe if IBM had supported OS/2 for a few
years more, they would have thought about implementing strategy3 for ADDs,
however to me it looks like a small step on the never completed transition to
a true 32bit IFS / disk driver model. So the advantages today are basically:

- Some more code can be executed in parallel on SMP systems (see the location
  of the spinlock in the picture on the URL which IMHO is wrong, because for
  strategy3 it's between OS2DASD and the device specific driver and not between
  OS2LVM and OS2DASD, but that's even better).

- It simplifies writing 32bit file systems. However, since relying completely on
  strategy3 will break compatibility with old versions of OS2DASD, it's probably
  not the best idea...

So it's all about the interface between a file system and OS2DASD. Even though
the calling convention is different (0:32 vs. 16:16) the data structures that get
passed along are basically the same. And so are the limits. As for performance:
A fully 32bit data path down to the adapter driver would probably increase it a
little bit, but I don't think that much.


abwillis

Quote from: mobybrick on 2009.07.20, 00:25:55
- Browsing the source code to the DANI driver (DANIS506, svn.netlabs.org/acpi)  it seems that it is only using the strat 2 (not 3) interface. This assumption is based on the source referencing the include file strat2.h

Checking the DDK I don't find a strat3.h, but in one or two of the strat2.h files (there are 5 of them all with different sizes) there is a reference to Strategy3 which is part of a structure to pass an entry point.