Hallo,

--- In os2ddprog@yahoogroups.com, "Steven Levine" <steve53@...> wrote:
>
> In <74c2acd4005f00d0d2efeaa8ab849058@...>, on 07/05/06
>    at 11:10 AM, rlalla@... <rlalla@...> said:
>
> Hi Robert,
>
> >what would be the advantage to port the usb stack from MSC to
OpenWatcom?
>
> Maintainability first and foremost, but there are a number of other
> advantages.
>
> BTW, I am proposing converting the entire DDK, not just the USB
stack.  I
> don't see any real benefit to converting just some of the drivers.
>
> One goal would be to remove the vast quantity of duplicated support
code.
> Another would be to rework the makefile structure so that the makefiles
> are not so tightly tied to the physical directory structure.  Another
> would be to refactor common code into resusable libraries.
>
> These goals need to be traded off with the requirement to get a working
> set of drivers in a reasonable time frame.  None of this will be
useful if
> it takes a year of wall clock time to happen.
>
> >Would you propose to convert portions of it to 32 bits?
>
> No.  Too much work for no real benefit for the vast majority of the
> drivers.  Once we have working builds of all the drivers that we
currently
> need, then we might want to discuss what drivers if any might
benefit from
> this.

I agree. The only thing that would really make a difference for most
drivers is to use the linear memory device helpers
(VMAlloc,VMGlobalToProcess etc.) instead of the old virtual memory
ones (PhysToVirt etc.). For once, GDT selectors are a scarce resource
and additionally, using the FLAT selector and linear addressing is
much more efficient in OS/2 2.x and above.

Lars

Hallo,

from an FSD, I want to make use of the Strat2 entry point to quickly
flush a bunch of cache sectors that are physically discontiguous in
memory.

I could specify a request list with:
A. multiple requests, 1 for each cache sector and trying to make good
use of the hint pointer in building up a chain of contiguous disk sectors

or

B. 1 request with multiple S/G entries where, by nature of the
programming interface (giving a disk starting sector and number of
disk sectors to write), the entries describe a sequence of physically
contiguous disk sectors.

For a typical BM Hardware, will A. remotely meet the performance that
I would expect from B. ? In how far does a block device driver
(OS2DASD.DMD) have to support the hint pointer ? How will A. be fed to
the underlying ADD (looks like an ADD can only make good use of B. if
at all) ?


Lars

Hi Lars!

On Fri, 08 Sep 2006 00:10:54 -0000, barf1234de wrote:

>from an FSD, I want to make use of the Strat2 entry point to quickly
>flush a bunch of cache sectors that are physically discontiguous in
>memory.
>
>I could specify a request list with:
>A. multiple requests, 1 for each cache sector and trying to make good
>use of the hint pointer in building up a chain of contiguous disk sectors
>
>or
>
>B. 1 request with multiple S/G entries where, by nature of the
>programming interface (giving a disk starting sector and number of
>disk sectors to write), the entries describe a sequence of physically
>contiguous disk sectors.
>
>For a typical BM Hardware, will A. remotely meet the performance that
>I would expect from B. ?

No way. Any IO request will ultimately translate into some hardware
port activity and one or more interrupts.

>In how far does a block device driver
>(OS2DASD.DMD) have to support the hint pointer ?

Call me ignorant, but what hint pointer are you talking about?

>How will A. be fed to
>the underlying ADD (looks like an ADD can only make good use of B. if
>at all) ?

I can only advise to look up the source of the DMD in question.
Regarding B.: SFF8038i compliant PCI busmaster capable ATA hosts (i.e.
99.999% of today's and past hardware) handle at least 256 sectors worth
of data in a single transaction; DaniS506 supports this, too.

Ciao,
   Dani

--- In os2ddprog@yahoogroups.com, "Daniela Engert" <dani@...> wrote:
>
> Hi Lars!
>
> On Fri, 08 Sep 2006 00:10:54 -0000, barf1234de wrote:
>
> >from an FSD, I want to make use of the Strat2 entry point to
quickly
> >flush a bunch of cache sectors that are physically discontiguous in
> >memory.
> >
> >I could specify a request list with:
> >A. multiple requests, 1 for each cache sector and trying to make
good
> >use of the hint pointer in building up a chain of contiguous disk
sectors
> >
> >or
> >
> >B. 1 request with multiple S/G entries where, by nature of the
> >programming interface (giving a disk starting sector and number of
> >disk sectors to write), the entries describe a sequence of
physically
> >contiguous disk sectors.
> >
> >For a typical BM Hardware, will A. remotely meet the performance
that
> >I would expect from B. ?
>
> No way. Any IO request will ultimately translate into some hardware
> port activity and one or more interrupts.
>
> >In how far does a block device driver
> >(OS2DASD.DMD) have to support the hint pointer ?
>
> Call me ignorant, but what hint pointer are you talking about?

It's described in the "Storage Device Driver Reference" (storage.inf)
in the Strat2 description:
Every request header can contain a hint pointer. That pointer can
point to another request packet and serves as a proposition to the
DMD /ADD what requests packets are bested grouped together. But it's
not mandatory for a DMD /ADD to support this as far as I understand
(that's why it's called "hint").


"Hint Pointer A 16:16 pointer to a request packet in a Request List.
This field can be used when the kernel or the client FSD determines
that this request might be best grouped with another request it has
already submitted to the physical device driver. The request might
have already completed, so the physical device driver must validate
that the pointer points to a request on its internal queues. This
field is FFFF:FFFFH if it is unused ( that is, if a hint is not being
passed). "

Lars

Hallo,

I am unclear about Resource Manager. As far as I understand:
1.) a Snooper Driver (.SNP) uses RMCreateDriver just like any other driver
2.) it searches for devices it is intended to detect
2.) it uses RMAllocResource for each detected device and resource
4.) finally, for each detected device, uses RMCreateDetected with the
Snooper Driver Handle and all the Resource Handles for that detected
device

Questions:
a.) who is calling RMSaveDetectedData ? Is it RESOURCE.SYS ? Or does
each Snooper Driver have to call it ?
b.) if a RM-aware device driver wants to finally claim resources and
assign them to adapters or devices, does it call RMAllocResource again
or does is search the node tree via RMDevIDToHandleList/RMGetNodeInfo
and "reuses" the resource handles that RMGetNodeInfo eventually
returns ? Or is it free to do either one or the other ?
(are the resource allocations for the detected nodes kept separately
from the resource allocations for driver/adapter/device and therefore
can be either "reused" or created anew ?)

Lars

Lars wrote:

>Questions:
>a.) who is calling RMSaveDetectedData ? Is it RESOURCE.SYS ? Or does
>each Snooper Driver have to call it ?

A library (pnp.dll) at PM startup. No. No.

>b.) if a RM-aware device driver wants to finally claim resources and
>assign them to adapters or devices, does it call RMAllocResource again
>or does is search the node tree via RMDevIDToHandleList/RMGetNodeInfo
>and "reuses" the resource handles that RMGetNodeInfo eventually
>returns ? Or is it free to do either one or the other ?
>(are the resource allocations for the detected nodes kept separately
>from the resource allocations for driver/adapter/device and therefore
>can be either "reused" or created anew ?)

It would try to allocate this or a different resource, using
RMAllocResource. Example: A snooper may block a different I/O range
than the driver(s) that use (parts of) the resource.
They are stored in different 'trees'.

Maybe you should tell more what you want to do..

--
Veit Kannegieser

It all started off when someone asked how to determine the base
address of a parallel port.
First shot was to read it from BIOS area (real mode segment 40h).
Then it was suggested to ask Resource Manager.
Then I wondered what tree to search for the base address, detected
tree or physical tree (adapter/device).
Then I struck Daniela Engert's example of how she suggests a driver
should query the detected tree to get the resource list detected by
the snoopers (in the detected tree).
Now, looking at driver code samples, I see that they always use
RMAllocResource to actually allocate resources. Then Daniela's
example would imply that instead of querying the resources in PCI
config space yourself, that it is better to read them from the
detected tree but then reallocate the very same values via
RMAllocResource and add them to the physical tree (adapter/device).

That somehow confused me.

Lars
--- In os2ddprog@yahoogroups.com, "Veit Kannegieser" <veit@...> wrote:
>
> Lars wrote:
>
> >Questions:
> >a.) who is calling RMSaveDetectedData ? Is it RESOURCE.SYS ? Or
does
> >each Snooper Driver have to call it ?
>
> A library (pnp.dll) at PM startup. No. No.
>
> >b.) if a RM-aware device driver wants to finally claim resources
and
> >assign them to adapters or devices, does it call RMAllocResource
again
> >or does is search the node tree via
RMDevIDToHandleList/RMGetNodeInfo
> >and "reuses" the resource handles that RMGetNodeInfo eventually
> >returns ? Or is it free to do either one or the other ?
> >(are the resource allocations for the detected nodes kept
separately
> >from the resource allocations for driver/adapter/device and
therefore
> >can be either "reused" or created anew ?)
>
> It would try to allocate this or a different resource, using
> RMAllocResource. Example: A snooper may block a different I/O range
> than the driver(s) that use (parts of) the resource.
> They are stored in different 'trees'.
>
> Maybe you should tell more what you want to do..
>
> --
> Veit Kannegieser
>

The Detected tree says what the snoopers detected, and should be present in the
system as a total pool.  In the detected tree NONE of the resources are USED
(allocated) by any driver.

No driver can put things into the detected tree.. Snoopers can.

Resource manager is a gentleman's agreement arbitrator.. You AGREE to
access only the resources you Allocate. There is nothing in the system to stop
you from from allocating one resource and using another. Just play fair.

So, if you look in the detected pool and find a resource you would LIKE to use,
then you use the ALLOCATE api to request access to that resource..

Note that for the Parallel ports this is MULTIPLEX, not exclusive OR shared.
you agree to access/release before each actual access to allow others exclusive
access for their read/writes too.. (the Trantor parallel scsi drivers for
example)..

with PCI and MCA before it, you could discover the hardware without actually
affecting it (poking values into ports).. but on ISA with the unregistered I/O
space, one had to peek/poke and that changed the state of the hardware..
so the strategy should be to go to the place that as already done this once if
you can, the detected pool in RM, rather than wacking at the ports again, and
this carries over into the PCI space model as well.

Sam Detweiler
RM PnP architect, I did all the proprietary SCSI and CD snoopers.
and the RM save/restore function


On Sat, 14 Oct 2006 13:21:52 -0000, barf1234de wrote:

>It all started off when someone asked how to determine the base
>address of a parallel port.
>First shot was to read it from BIOS area (real mode segment 40h).
>Then it was suggested to ask Resource Manager.
>Then I wondered what tree to search for the base address, detected
>tree or physical tree (adapter/device).
>Then I struck Daniela Engert's example of how she suggests a driver
>should query the detected tree to get the resource list detected by
>the snoopers (in the detected tree).
>Now, looking at driver code samples, I see that they always use
>RMAllocResource to actually allocate resources. Then Daniela's
>example would imply that instead of querying the resources in PCI
>config space yourself, that it is better to read them from the
>detected tree but then reallocate the very same values via
>RMAllocResource and add them to the physical tree (adapter/device).

>That somehow confused me.

Hi Sam ,

>RM PnP architect, I did all the proprietary SCSI and CD snoopers.
>and the RM save/restore function

When we just have you here: I'm also interrested in some insight
about RESOURCE.SYS as well. Especially:

How does loading of the snoopers work ? Does RESOURCE.SYS
report the content of SNOOP.LST back to the kernel and the kernel
then processes it or does RESOURCE.SYS somehow manage to
load the snoopers itself ? If the first is true: is the interaction with the
the kernel documented somewhere ?

RESOURCE.SYS seems to load PNP.SYS and ISAPNP.SYS without
them being mentioned in SNOOP.LST. Why is that so ? Are these two
loaded always (i.e. independent from the hardware detection level) ?

I have heard rumours, that RESOURCE.SYS does some other nasty
stuff (like microcode updates for certain CPUs). Is that true ?  Is there
even more functionality not directly related to resource managment
hidden in RESOURCE.SYS ?



Cheers !


--
Ruediger "Rudi" Ihle  [S&T Systemtechnik GmbH, Germany, http://www.s-t.de]

Hi Rudi!

Ruediger Ihle wrote:
> I have heard rumours, that RESOURCE.SYS does some other nasty
> stuff (like microcode updates for certain CPUs). Is that true ?  Is there
> even more functionality not directly related to resource managment
> hidden in RESOURCE.SYS ?

Microcode updates for CPUs are as far as I know done by the Motherboard BIOS.
I've never heard that the OS is responsible for the update but this doesn't
exclude that this may happen.

Juergen

On Sun, 15 Oct 2006 20:37:59 +0000, Ruediger Ihle wrote:

>I have heard rumours, that RESOURCE.SYS does some other nasty
>stuff (like microcode updates for certain CPUs). Is that true ?  Is there
>even more functionality not directly related to resource managment
>hidden in RESOURCE.SYS ?

Indeed, there was a hack in RESOURCE.SYS around 1998 to update CPU
microcode, perhaps because it seemed the right place for the job (as one
of the first non-kernel components in the boot sequence). AFAIK it was
never updated and covers only PPro CPUs of that age.

On Sun, 15 Oct 2006 20:37:59 +0000, Ruediger Ihle wrote:

>How does loading of the snoopers work ? Does RESOURCE.SYS
>report the content of SNOOP.LST back to the kernel and the kernel
>then processes it or does RESOURCE.SYS somehow manage to
>load the snoopers itself ? If the first is true: is the interaction with the
>the kernel documented somewhere ?

The kernel was modified to make a call to Resource.sys to get the 'next'
snooper, NOT the list. SO it keeps calling and adds these to the ordered list
of drivers to load. Once the total snooper list is supplied, resource.sys says
done, and then the normal loading takes place.
Unlikely it is documented. There was no need to expose it.


>RESOURCE.SYS seems to load PNP.SYS and ISAPNP.SYS without
>them being mentioned in SNOOP.LST. Why is that so ? Are these two
>loaded always (i.e. independent from the hardware detection level) ?

because these MUST be first and last respectively, and we didn't want the user
to be able to muck it up. They are ALWAYS loaded.


>I have heard rumours, that RESOURCE.SYS does some other nasty
>stuff (like microcode updates for certain CPUs). Is that true ?  Is there
>even more functionality not directly related to resource managment
>hidden in RESOURCE.SYS ?

I can't think of anything in this area, BUT, if we did, then it was because we
needed a guaranteed spot to do the programming to fix some specific problem
before the OS is all the way up.


Sam

Ok, I understand. How does a snooper add resources to the detected
tree (if I wanted to write one myself) ? Does it also use
RMAllocResource (and then RMCreateDetected to actually add the node
to the tree) ?
Yes I was aware of MULTIPLEX. I guess each replacement of
PRINT01.SYS/PRINT02.SYS has to support the IDC interface to
request/release exlusive access to the parallel port with the exact
same IDC interface (register interface) as PRINT01.SYS/PRINT02.SYS,
right ?
By the way: in the I/O device driver reference it is stated that the
printer drivers support the deinstall request. So why do I have to
remove PRINT01.SYS from config.sys if I add PAR1284.SYS to
config.sys ?
Is it because they both are BASEDEV= drivers while the deinstall only
works for DEVICE= drivers ?

Lars

--- In os2ddprog@yahoogroups.com, "Sam Detweiler" <sam@...> wrote:
>
> The Detected tree says what the snoopers detected, and should be
present in the
> system as a total pool.  In the detected tree NONE of the resources
are USED
> (allocated) by any driver.
>
> No driver can put things into the detected tree.. Snoopers can.
>
> Resource manager is a gentleman's agreement arbitrator.. You AGREE
to
> access only the resources you Allocate. There is nothing in the
system to stop
> you from from allocating one resource and using another. Just play
fair.
>
> So, if you look in the detected pool and find a resource you would
LIKE to use,
> then you use the ALLOCATE api to request access to that resource..
>
> Note that for the Parallel ports this is MULTIPLEX, not exclusive
OR shared.
> you agree to access/release before each actual access to allow
others exclusive
> access for their read/writes too.. (the Trantor parallel scsi
drivers for
> example)..
>
> with PCI and MCA before it, you could discover the hardware without
actually
> affecting it (poking values into ports).. but on ISA with the
unregistered I/O
> space, one had to peek/poke and that changed the state of the
hardware..
> so the strategy should be to go to the place that as already done
this once if
> you can, the detected pool in RM, rather than wacking at the ports
again, and
> this carries over into the PCI space model as well.
>
> Sam Detweiler
> RM PnP architect, I did all the proprietary SCSI and CD snoopers.
> and the RM save/restore function

On 15 Oct 2006 21:54:57 UT, Sam Detweiler wrote:

>because these MUST be first and last respectively,

I understand, that ISAPNP.SYS must be loaded first in order to
activate ISA PnP hardware. But what does PNP.SYS do ?


> BUT, if we did, then it was because we needed a guaranteed
> spot to do the programming to fix some specific problem before
> the OS is all the way up.

This is one of the reasons, why the ACPI people are currently
discussing the possibility of rewriting RESOURCE.SYS...

Thanks


--
Ruediger "Rudi" Ihle  [S&T Systemtechnik GmbH, Germany, http://www.s-t.de]

ISAPNP.SYS collects the resources lists from all the ISAPnP devices.
Some are not adjustable.

the rest of the snoopers run, collecting fixed resources.

then the PNP.SYS runs to actually program the ISAPnP devices that need
additional configuration, now that we know the rest of the fixed resource pool
and can resolve any conflicts..


On Mon, 16 Oct 2006 18:55:54 +0000, Ruediger Ihle wrote:

>>because these MUST be first and last respectively,

>I understand, that ISAPNP.SYS must be loaded first in order to
>activate ISA PnP hardware. But what does PNP.SYS do ?


Sam

Where do I find info on this file and the data it contains?
I trying to connect a sound card.

Thomas

It is in the \MMOS2 directory. If it isn't there, chances are the
MultiMedia subsystem was not installed.

Information on its contents can be found here.

http://www.warpspeed.com.au/cgi-bin/inf2html.cmd?..%5Chtml%5Cbook%
5CToolkt40%5CMMSSPG.INF+137

Google on "MMPM2.INI Guide" for other links

== Glen


--- In os2ddprog@yahoogroups.com, "warp4dennis" <tdennis@...> wrote:
>
> Where do I find info on this file and the data it contains?
> I trying to connect a sound card.
>
> Thomas
>

It appears that I am no longer allowed to access IBM's DDP source
repritory, does anyone hre know if they ever released the USB Audio
source and if so what file date or version no that was

Thanks in advance

reiknir wrote:
> It appears that I am no longer allowed to access IBM's DDP source
> repritory, does anyone hre know if they ever released the USB Audio
> source and if so what file date or version no that was
I have it in the "inout.zip" which is dated 2004-02-11.

Robert

reiknir wrote:

> It appears that I am no longer allowed to access IBM's DDP source
> repritory, does anyone hre know if they ever released the USB Audio
> source and if so what file date or version no that was

USB audio source can be found in the "physical device drivers source"
part of DDK (INOUT.ZIP). Lot of peoples mirrored DDK site before it was
closed so I think you can easily find this file on Internet or contact
privately.

Files in this directory have timestamp of 07 Nov 2003. No idea which
version it corresponds to.

Roman

--- In os2ddprog@yahoogroups.com, Robert Henschel <os2info@...> wrote:
>
> reiknir wrote:
> > It appears that I am no longer allowed to access IBM's DDP source
> > repritory, does anyone hre know if they ever released the USB Audio
> > source and if so what file date or version no that was
> I have it in the "inout.zip" which is dated 2004-02-11.
>
> Robert
>
Thanks

Appreciated

Hallo,

I am investigating the effort to make FAT32.IFS provide the extensions
necessary for files > 2 GB.
Since the new IFS extensions are not documented anywhere (the API is
but the changes in the IFS interface are not) I had a look at the
OPENJFS sourcecode. By mere foresight, I unlxlited OS2KRNL to find the
names of the IFS entry points. Now this struck my eye (where otherwise
everything matched perfectly):

OS2KRNL             OPENJFS.IFS         REMARKS
FS_CHGFILEPTR       FS_CHGFILEPTR       old 16-bit EP, LONG offsets
FS32_CHGFILEPTRL    FS32_CHGFILEPTRL    new 32-bit EP, LONGLONG offsets
FS_CHGFILEPTRL      FS32_CHGFILEPTR     ?

Now what is right and what is wrong ? For FSx_NEWSIZEy it looks like this:
OS2KRNL             OPENJFS.IFS
FS_NEWSIZE          FS_NEWSIZE          old 16-bit EP, ULONG length
FS_NEWSIZEL         FS_NEWSIZEL         new 16-bit EP, ULONGLONG length

My feeling is that FS_CHGFILEPTRL (analogy) would be a 16-bit EP with
LONGLONG offset (and therefore FS32_CHGFILEPTR would be unnecessary).

jfs.ifs lists FS32_CHGFILEPTR while udf.ifs lists neither
FS_CHGFILEPTRL nor FS32_CHGFILEPTR.

Can someone enlighten me ? Or is the combination of
FS_CHGFILEPTR/FS_CHGFILEPTRL (both being 16-bit entry points) as valid
as FS_CHGFILEPTR/FS32_CHGFILEPTRL (16-bit and 32-bit entry point) ?

Lars

On Wed, 03 Jan 2007 23:51:51 -0000, barf1234de wrote:

>OS2KRNL             OPENJFS.IFS         REMARKS
>FS_CHGFILEPTR       FS_CHGFILEPTR       old 16-bit EP, LONG offsets
>FS32_CHGFILEPTRL    FS32_CHGFILEPTRL    new 32-bit EP, LONGLONG offsets
>FS_CHGFILEPTRL      FS32_CHGFILEPTR     ?

I would guess "?" is "new 16 bit EP, LONGLONG offsets".

--- In os2ddprog@yahoogroups.com, "Paul Ratcliffe" <paul@...> wrote:
>
> On Wed, 03 Jan 2007 23:51:51 -0000, barf1234de wrote:
>
> >OS2KRNL             OPENJFS.IFS         REMARKS
> >FS_CHGFILEPTR       FS_CHGFILEPTR       old 16-bit EP, LONG offsets
> >FS32_CHGFILEPTRL    FS32_CHGFILEPTRL    new 32-bit EP, LONGLONG offsets
> >FS_CHGFILEPTRL      FS32_CHGFILEPTR     ?
>
> I would guess "?" is "new 16 bit EP, LONGLONG offsets".
>

Yes, but have a look at the two different names:
FS_CHGFILEPTRL and FS32_CHGFILEPTR. Furthermore, FS32_CHGFILEPTRL is
the new 32-bit EP with LONGLONG offset. Why would I then need an
additional 16-bit EP with LONGLONG offset (analogous, FS_NEWSIZE is
the 16-bit EP with ULONG filelength and FS_NEWSIZEL is the 16-bit EP
with ULONGLONG filelength. And there is no 32-bit EP for NEWSIZE).

Lars

On Thu, 04 Jan 2007 20:11:42 -0000, barf1234de wrote:

>FS_CHGFILEPTRL and FS32_CHGFILEPTR. Furthermore, FS32_CHGFILEPTRL is
>the new 32-bit EP with LONGLONG offset. Why would I then need an
>additional 16-bit EP with LONGLONG offset (analogous, FS_NEWSIZE is
>the 16-bit EP with ULONG filelength and FS_NEWSIZEL is the 16-bit EP
>with ULONGLONG filelength. And there is no 32-bit EP for NEWSIZE).

Yes, it is inconsistent and yes, there appears to be some duplication
in the CHGFILEPTR entrypoints, but why worry? Just go with the flow and
implement it as OpenJFS does.
There may or may not be a good reason for it, but if you really want to
know, I guess you'll have to email Scott.

--- In os2ddprog@yahoogroups.com, "Paul Ratcliffe" <paul@...> wrote:
>
> On Thu, 04 Jan 2007 20:11:42 -0000, barf1234de wrote:
>
> >FS_CHGFILEPTRL and FS32_CHGFILEPTR. Furthermore, FS32_CHGFILEPTRL is
> >the new 32-bit EP with LONGLONG offset. Why would I then need an
> >additional 16-bit EP with LONGLONG offset (analogous, FS_NEWSIZE is
> >the 16-bit EP with ULONG filelength and FS_NEWSIZEL is the 16-bit EP
> >with ULONGLONG filelength. And there is no 32-bit EP for NEWSIZE).
>
> Yes, it is inconsistent and yes, there appears to be some duplication
> in the CHGFILEPTR entrypoints, but why worry? Just go with the flow and
> implement it as OpenJFS does.

Considering the fact that UDF.IFS again does it differently makes me
feel a little uncomfortable but maybe I implement all four of them :-)

> There may or may not be a good reason for it, but if you really want to
> know, I guess you'll have to email Scott.

Do you have his current email address ? You could email it to me
privately, I have a valid email address here in Yahoo ...

Lars

Hi/2, Lars.

First of all, thanks a lot for your efforts to enhace FAT32.IFS.

But I have a question. FAT32 is a 32 bits file system, i.e. it
supports up to just 32 bits file size, that is 4GB but generally
2GB. So I think it is not necessary to implement extention entry
points.

Why would you implement extension entry points ? a just for
experiment ? Or, is there any other reason ?

KO Myung-Hun

--- In os2ddprog@yahoogroups.com, "barf1234de" <lars.erdmann@...>
wrote:
>
> Hallo,
>
> I am investigating the effort to make FAT32.IFS provide the
extensions
> necessary for files > 2 GB.
> Since the new IFS extensions are not documented anywhere (the API
is
> but the changes in the IFS interface are not) I had a look at the
> OPENJFS sourcecode. By mere foresight, I unlxlited OS2KRNL to find
the
> names of the IFS entry points. Now this struck my eye (where
otherwise
> everything matched perfectly):
>
> OS2KRNL             OPENJFS.IFS         REMARKS
> FS_CHGFILEPTR       FS_CHGFILEPTR       old 16-bit EP, LONG offsets
> FS32_CHGFILEPTRL    FS32_CHGFILEPTRL    new 32-bit EP, LONGLONG
offsets
> FS_CHGFILEPTRL      FS32_CHGFILEPTR     ?
>
> Now what is right and what is wrong ? For FSx_NEWSIZEy it looks
like this:
> OS2KRNL             OPENJFS.IFS
> FS_NEWSIZE          FS_NEWSIZE          old 16-bit EP, ULONG length
> FS_NEWSIZEL         FS_NEWSIZEL         new 16-bit EP, ULONGLONG
length
>
> My feeling is that FS_CHGFILEPTRL (analogy) would be a 16-bit EP
with
> LONGLONG offset (and therefore FS32_CHGFILEPTR would be
unnecessary).
>
> jfs.ifs lists FS32_CHGFILEPTR while udf.ifs lists neither
> FS_CHGFILEPTRL nor FS32_CHGFILEPTR.
>
> Can someone enlighten me ? Or is the combination of
> FS_CHGFILEPTR/FS_CHGFILEPTRL (both being 16-bit entry points) as
valid
> as FS_CHGFILEPTR/FS32_CHGFILEPTRL (16-bit and 32-bit entry point) ?
>
> Lars
>

Hello,

What is the technical reasons, why BASEDEVs can't be loaded at run
time (i.e. after PMSHELL starts up)?
The idea is to call kernel's BaseDevLoad function from another PDD to
load some BASEDEV driver.

On Sat, 13 Jan 2007 11:36:38 -0000, gaynullin wrote:

>What is the technical reasons, why BASEDEVs can't be loaded at run
>time (i.e. after PMSHELL starts up)?
>The idea is to call kernel's BaseDevLoad function from another PDD to
>load some BASEDEV driver.

In general this should be possible.
But depending what your basedev actually does, there are some pitfalls:
- The original basedev loader code has been discarded, so you would have
to write your own loader.
- Certain devhelp functions (like AllocGDTSelector) are available only
in "init" mode, not in "kernel" mode, according to PDDREF.INF.
- IDC interaction with other device drivers might be limited,
in case they expect some kind of registering before or at
initcomplete time.

Robert Lalla wrote:
>
>
> On Sat, 13 Jan 2007 11:36:38 -0000, gaynullin wrote:
>
>  >What is the technical reasons, why BASEDEVs can't be loaded at run
>  >time (i.e. after PMSHELL starts up)?
>  >The idea is to call kernel's BaseDevLoad function from another PDD to
>  >load some BASEDEV driver.
>
> In general this should be possible.
> But depending what your basedev actually does, there are some pitfalls:
> - The original basedev loader code has been discarded, so you would have
> to write your own loader.

Is it really true? As far as I can see, basedevs are loaded by same
code, as any other modules.


> - Certain devhelp functions (like AllocGDTSelector) are available only
> in "init" mode, not in "kernel" mode, according to PDDREF.INF.

Yes, but who care about selectors now? ;)

> - IDC interaction with other device drivers might be limited,
> in case they expect some kind of registering before or at
> initcomplete time.

There is an inter-driver dependency anyway. The idea to load main driver
(say USBD.SYS) as usual and load another driver (say USBMSD.SYS) at the
time, when device physically attached.

Valery