iop man page on NetBSD

Man page or keyword search:  
man Server   9087 pages
apropos Keyword Search (all sections)
Output format
NetBSD logo
[printable version]

IOP(4)			 BSD Kernel Interfaces Manual			IOP(4)

NAME
     iop — I2O adapter driver

SYNOPSIS
     iop* at pci? dev ? function ?
     iopsp* at iop? tid ?
     ld* at iop? tid ?
     dpti* at iop? tid 0

DESCRIPTION
     The iop driver provides support for PCI I/O processors conforming to the
     I2O specification, revision 1.5 and above.

     I2O is a specification that defines a software interface for communicat‐
     ing with a number of device types.	 In its basic form, I2O provides the
     following:

     ·	 A vendor-neutral interface for communicating with an I/O processor
	 (IOP) and a number of types of peripherals.  In order to achieve
	 this, hardware-specific device drivers run on the IOP, and hardware-
	 neutral device drivers run on the host.

     ·	 Reduced I/O overhead for the host.  All communication between the
	 host and the IOP is performed using a high level protocol.  The spec‐
	 ification also provides for batching of requests and replies between
	 the host and IOP.

     ·	 An optional vendor-neutral configuration interface.  Data from HTTP
	 GET and POST operations can be channeled to individual devices, and
	 HTML pages returned.

     Five types of devices are well defined by the specification.  These are:

     ·	 Random block storage devices (disks).
     ·	 Sequential storage devices (tapes).
     ·	 LAN interfaces, including Ethernet, FDDI, and Token Ring.
     ·	 Bus ports (SCSI).
     ·	 SCSI peripherals.

     The iop driver's role is to initialize and monitor the IOP, provide a
     conduit for messages and replies to and from devices, and provide other
     common services for peripheral drivers, such as DMA mapping.

IOCTL INTERFACE
     The following structures and constants are defined in dev/i2o/iopio.h.
     Note that the headers sys/types.h, sys/device.h and dev/i2o/i2o.h are
     prerequisites and must therefore be included beforehand.

     IOPIOCPT (struct ioppt)
	   Submit a message to the IOP and return the reply.  Note that the
	   return value of this ioctl is not affected by completion status as
	   indicated by the reply.

	   struct ioppt {
		   void	   *pt_msg;	   /* pointer to message buffer */
		   size_t  pt_msglen;	   /* message buffer size in bytes */
		   void	   *pt_reply;	   /* pointer to reply buffer */
		   size_t  pt_replylen;	   /* reply buffer size in bytes */
		   int	   pt_timo;	   /* completion timeout in ms */
		   int	   pt_nbufs;	   /* number of transfers */
		   struct  ioppt_buf pt_bufs[IOP_MAX_MSG_XFERS]; /* transfers */
	   };

	   struct ioppt_buf {
		   void	   *ptb_data;	   /* pointer to buffer */
		   size_t  ptb_datalen;	   /* buffer size in bytes */
		   int	   ptb_out;	   /* non-zero if transfer is to IOP */
	   };

	   The minimum timeout value that may be specified is 1000ms.  All
	   other values must not exceed the iop driver's operational limits.

	   The initiator context and transaction context fields in the message
	   frame will be filled by the iop driver.  As such, this ioctl may
	   not be used to send messages without a transaction context payload.

     IOPIOCGSTATUS (struct iovec)
	   Request the latest available status record from the IOP.  This spe‐
	   cial-case ioctl is provided as the I2O_EXEC_STATUS_GET message does
	   not post replies, and can therefore not be safely issued using the
	   IOPIOCPT ioctl.

     The following ioctls may block while attempting to acquire the iop
     driver's configuration lock, and may fail if the acquisition times out.

     IOPIOCGLCT (struct iovec)
	   Retrieve the iop driver's copy of the logical configuration table.
	   This copy of the LCT matches the current device configuration, but
	   is not necessarily the latest available version of the LCT.

     IOPIOCRECONFIG
	   Request that the iop driver scan all bus ports, retrieve the latest
	   version of the LCT, and attach or detach devices as necessary.
	   Note that higher-level reconfiguration tasks (such as logically re-
	   scanning SCSI busses) will not be performed by this ioctl.

     IOPIOCGTIDMAP (struct iovec)
	   Retrieve the TID to device map.  This map indicates which targets
	   are configured, and what the corresponding device name for each is.
	   Although at any given point it contains the same number of entries
	   as the LCT, the number of entries should be determined using the
	   iov_len field from the returned iovec.

	   struct iop_tidmap {
		   u_short it_tid;
		   u_short it_flags;
		   char	   it_dvname[sizeof(((struct device *)NULL)->dv_xname)];
	   };
	   #define IT_CONFIGURED   0x02	   /* target configured */

FILES
     /dev/iopu	control device for IOP unit u

SEE ALSO
     dpti(4), intro(4), iopsp(4), ld(4), iopctl(8)

     http://www.intelligent-io.com/

HISTORY
     The iop driver first appeared in NetBSD 1.5.3.

BSD			       December 2, 2007				   BSD
[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server NetBSD

List of man pages available for NetBSD

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net