PE>
  > JdeBP> For another, even if the device driver *could* make
  > JdeBP> application-level API calls to perform file I/O, there's no
  > JdeBP> guarantee that the process, one of its parents, will not have
  > JdeBP> closed the file handle concerned an possibly opened another one
  > JdeBP> in its stead.  There are no "system" or
"reserved" file handles.
  > JdeBP> Each process is sovereign as far as its ope file handles are
  > JdeBP> concerned.
  >
  > But I don't agree with this.  You don't have the right to close arbitrary
  > file handles.  You're only allowed to close files that you
  > yourself have opened.  That's a bit like saying that the
  > device driver shouldn't rely on being able to access memory
  > it just malloc'ed, because "the user might have run a
  > program to go and deliberately clobber that memory".
PE>

  Wrong on both counts.

  First count :  An OS/2 process can do what it likes with *any* of the
  file handles that it has open.  There's *nothing* that stops it from
  closing any or all file handles that it has open.  As far as its file
  handle table is concerned, each process is sovereign.

  Ever written a daemon process ?  What's the first thing that a
  well-written background daemon process does ?  That's right.  It closes
  any open file handles that it may have accidentally inherited.

  Second count :  Memory allocated by a device driver is allocated from
  kernel space, using special Device Help APIs provided specifically for
  that purpose, and is "owned" by the driver itself.  The memory is not a
  application-level resource.  File handles opened by a device driver in
  its INIT processing, on the other hand, *are* application-level
  resources, are managed by application-level APIs, and belong to process
  0, not the device driver.

  So whereas a device driver can allocate and free kernel-level memory at
  any point (as long as it does it in its upper half), because that memory
  does not belong to the process that the driver code happens to be
  currently executing in, it cannot open, use, and close file handles,
  because they *do* belong to the currently executing process.

PE>
  > BTW, if you see a message from me at 5AM, it's NOT because
  > I'm an earlybird.  :-)
PE>

  Why is it then ?  (-:

  > JdeBP <
___
 X MegaMail 2.10 #0:
--- Maximus/2 3.01