On Tue, 31 Dec 2002 11:09:36 +0100 (CET), Daniela Engert wrote:
>>>> Memory objects in this so called linear address
>>>>space are addressable from any context by means of
>>>>the DOS32FLATDS selector;
>>>Are you sure ? AFAIK, DOS32FLATDS requires the code to
>>>run at ring 0. I seem to remember, that I had to move some
>>>INIT code to INITCOMPLETE in order to use this approach.
>True, but why bother at all? As I said, if some weird driver *requires*
>addressability of parts of this memory at some odd instance of time it
>may use the LinToGDTSelector device helper service. Besides that,
>INITCOMPLETE is the perfect place to do initialization stuff.
No.
That's not the actual problem.
GCONFIG-API is designed to work anywhere this means even on INIT of simple DEVICE-PDDs
for e.g.
device-searching etc. And because the API is linked in as FAR CALL, I need to be able
to access the
configuration area even on Ring-3. There is no way around it. It's not a "weird driver
requirement". It's a
requirement of GCONFIG.
>Think about this stuff and get it! Linear addresses have these
>properties:
>1) the memory pointed to is *accessible* in all Ring-0 contexts by
>means of the the flat selector.
>2) the address is *valid* in all, even Ring-3 contexts. In Ring-3 it
>needs some mapping to make it *accessible*.
And searching through BASE-Block area would require me to map on every search, every
check, every PCI
Read/Write and whatever call? This would be crazy! I would need to map the whole area
anyway, so I would
have to built 3 different types of routines. Currently only 2 routine-types are
required (16-bit segmented and
32-bit linear). LinToGDT is *also* limited to 64k, so if there is no DOS32FLATDS for
Ring-3, then this is the
only way.
>>Yes I think that's right. Otherwise there would have to be 2 selectors. One for
>Ring-0, the other one for
>>Ring-3. For god-sake, I didn't start changing the APIs yet :-) This means I really
>have to do this 512
>>GDT-selectors stuff.
>Three times NO! You don't need such kind of things. And if you insist
>on a GDT selector, why don't you setup a single big one?
Because AllocGDTSel is limited to 64k by IBM :-)
Three times NO to IBM ;-)
>>>>So, instead of virtual (GDT based) pointer switch to linear (32-bit)
>>>>ones and *expose* them to clients. If a client is so stupid to require
>>>>a virtual mapping then it can do it itself.
>>>Why is this mapping necessary at all ? Wasn't the result of some
>>>ealier discussion to copy out the data ?
>You are true, copy out was the solution wee agreed on. This makes
>things even easier.
Like I said before: I'm not working with device IOCTL. Parts of the API will be also
accessible that way, but
not all of it (and that's actually meant for application Ring-3, *not* driver INIT).
Anyway generating one device
IOCTL (and switch back and forth from Ring-0 to Ring-3) for a single (!) PCI
read/write operation during INIT
would be nuts. This would be a huge overhead (speed, size and code), which is actually
completely useless.
This would also need me to define all sorts of "pass-through" buffers and much more
crap. I'm currently
working with stack based arguments and far call. This is the fastest approach there is.
Far Call is also needed, because GCONFIG-"printf" is working on Ring-0 *and* Ring-3
(!). If I switch to Ring-0
via device IOCTL, this is *not* possible. The current driver-code for using
GCONFIG-API is around 100-200
bytes (!) and it won't increase per API call. An IOCTL approach would require *much*
overhead and for every
routine "imported" from GCONFIG, there would need to be some stub-routine in the
actual driver PDD (which
would mean duplicate code every here and there).
cu, Kiewitz
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe acpi-os2
end
