Re: SHOW DEVICE: what should it show?





hoff@xxxxxxxxx (Hoff Hoffman) wrote on 12/12/2005 05:55:43 PM:

> In article <1134425458.095982.235660@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
> "Allosaur" <ALLOSAUR@xxxxxxxxxxxxxxxxx> writes:
> :I note BG (TCP/IP) devices also do not appear, nor do MB mailboxes. It
> :must be that these virtual devices with no real hardware were not
> :considered important for the "SHOW DEVICE" command.
>
> It was considered that there are usually a gazillion of these devices,
> and the display of these wasn't something that (most) users wanted to
> see. (SHOW DEVICE also uses direct access into kernel mode, and it
> passes a buffer back down to user mode for display, so there is also
> a preference to fit the data within this buffer -- likely due to its
> sheer age, SHOW DEVICE does not work the way you might expect; it's
> not a loop of $device_scan[w] and $getdvi[w] system service calls.)
>
> Devices with the MBX bit set within the UCB are among those filtered
> by the kernel-mode code, and this accounts for most of (all of?) the
> devices cited.
>
> Adding /SELECT, maybe, with a default of the current behaviour, and
> some set of keywords to allow different selection criteria to be
> requested, might well be a reasonable enhancement suggestion, for
> those that wanted to see a list of every device name. (Folks writing
> DCL command procedures seeking devices should be using the available
> DCL lexical functions of course, and these can and do allow access to
> the names of all of the devices present.)
>
> (I thought about SHOW DEVICE/ALL here, but that would tend to collide
> with the existing /ALLOCATED qualifier.)

Perhaps SHOW
DEVICE/INCLUDE=(ALL|comma-separated-list)/EXCL=(comma-separated-list)
or minuses allowed in the /INCLUDE list as in the ACCOUNTING utility?

>
>
> ---------------------------- #include <rtfaq.h>
-----------------------------
> For additional, please see the OpenVMS FAQ --
www.hp.com/go/openvms/faq
> --------------------------- pure personal opinion
---------------------------
> Hoff (Stephen) Hoffman OpenVMS Engineering hoff[\0100]hp.com
>

.



Relevant Pages

  • Re: SHOW DEVICE: what should it show?
    ... (SHOW DEVICE also uses direct access into kernel mode, ... passes a buffer back down to user mode for display, ... DCL command procedures seeking devices should be using the available ...
    (comp.os.vms)
  • Re: Highly responsive serial port
    ... My problem consists of reading from a serial COM port as fluent as possible. ... If my reader only reads the input buffer after 50ms I'm too late to reply but I don't know it. ... Would a driver(in kernel mode) have enough priority to process such requests in time? ... a general rule of thumb in thread synchronization is to stay away from depending on "sleep" and loop designs in a vain attempt to synchronize I/O. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Getting Kernel Shared section object name in Appln
    ... To use data buffer between application and driver you can either allocate ... I need to allocate memory in kernel mode, fill it and then user mode ...
    (microsoft.public.development.device.drivers)
  • Re: CeAllocAsynchronousBuffer functionality and VirtualAllocCopyEx
    ... This function re-marshals a buffer that was already marshaled by ... allocating the buffer in kernel mode and then I am trying to map it to user ... I need to map the buffer to the user because the user will use the command ... Does CeFreeAsynchronousBuffer do this. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Share a buffer allocated in user mode
    ... i/o control. ... > buffer you define for the IOCTL transport simply passes a pointer to the ... Send a Deallocate IOCTL to tear down the shared ... >> also the kernel mode pointer to be the same and accessible at any time ...
    (microsoft.public.development.device.drivers)