fbio(7i) [netbsd man page]

fbio(7I)							  Ioctl Requests							  fbio(7I)

NAME

       fbio - frame buffer control operations

DESCRIPTION

       The frame buffers provided with this release support the same general interface that is defined by <sys/fbio.h>. Each responds to an FBIOG-
       TYPE ioctl(2) request which returns information in a fbtype structure.

       Each device has an FBTYPE which is used by higher-level software to determine how to perform graphics functions. Each  device  is  used	by
       opening	it,  doing an FBIOGTYPE ioctl() to see which frame buffer type is present, and thereby selecting the appropriate device-management
       routines.

       FBIOGINFO returns information specific to the GS accelerator.

       FBIOSVIDEO and FBIOGVIDEO are general-purpose ioctl() requests for controlling possible video features  of  frame  buffers.  These  ioctl()
       requests  either  set  or  return  the  value  of  a  flags  integer. At this point, only the FBVIDEO_ON option is available, controlled by
       FBIOSVIDEO. FBIOGVIDEO returns the current video state.

       The FBIOSATTR and FBIOGATTR ioctl() requests allow access to special features of newer frame buffers. They use  the   fbsattr  and  fbgattr
       structures.

       Some  color  frame  buffers  support  the  FBIOPUTCMAP and FBIOGETCMAP ioctl() requests, which provide access to the colormap. They use the
       fbcmap structure.

       Also, some framebuffers with multiple colormaps will either encode the colormap identifier in the high-order bits of the "index"  field	in
       the fbcmap structure, or use the FBIOPUTCMAPI and FBIOGETCMAPI ioctl() requests.

       FBIOVERTICAL is used to wait for the start of the next vertical retrace period.

       FBIOVRTOFFSET  Returns  the offset to a read-only vertical retrace page for those framebuffers that support it.	This vertical retrace page
       may be mapped into user space with mmap(2). The first word of the vertical retrace page (type unsigned int) is a  counter  that	is  incre-
       mented every time there is a vertical retrace.  The user process can use this counter in a variety of ways.

       FBIOMONINFO returns a mon_info structure which contains information about the monitor attached to the framebuffer, if available.

       FBIOSCURSOR,  FBIOGCURSOR,  FBIOSCURPOS	and FBIOGCURPOS are used to control the hardware cursor for those framebuffers that have this fea-
       ture. FBIOGCURMAX returns the maximum sized cursor supported by the framebuffer.  Attempts to create a cursor larger than this will fail.

       Finally FBIOSDEVINFO and FBIOGDEVINFO are used to transfer variable-length, device-specific information into and out of framebuffers.

SEE ALSO

       ioctl(2), mmap(2), cgsix(7D)

BUGS

       The FBIOSATTR and FBIOGATTR ioctl() requests are only supported by frame buffers which emulate older frame buffer types. If a frame  buffer
       emulates another frame buffer, FBIOGTYPE returns the emulated type. To get the real type, use FBIOGATTR.

       The  FBIOGCURPOS  ioctl	was incorrectly defined in previous operating systems, and older code running in binary compatibility mode may get
       incorrect results.

SunOS 5.10							    12 May 2003 							  fbio(7I)

TAP(4)							   BSD Kernel Interfaces Manual 						    TAP(4)

NAME

     tap -- virtual Ethernet device

SYNOPSIS

     pseudo-device tap

DESCRIPTION

     The tap driver allows the creation and use of virtual Ethernet devices.  Those interfaces appear just as any real Ethernet NIC to the kernel,
     but can also be accessed by userland through a character device node in order to read frames being sent by the system or to inject frames.

     In that respect it is very similar to what tun(4) provides, but the added Ethernet layer allows easy integration with machine emulators or
     virtual Ethernet networks through the use of bridge(4) with tunneling.

   INTERFACE CREATION
     Interfaces may be created in two different ways: using the ifconfig(8) create command with a specified device number, or its ioctl(2) equiva-
     lent, SIOCIFCREATE, or using the special cloning device /dev/tap.

     The former works the same as any other cloning network interface: the administrator can create and destroy interfaces at any time, notably at
     boot time.  This is the easiest way of combining tap and bridge(4).  Later, userland will actually access the interfaces through the specific
     device nodes /dev/tapN.

     The latter is aimed at applications that need a virtual Ethernet device for the duration of their execution.  A new interface is created at
     the opening of /dev/tap, and is later destroyed when the last process using the file descriptor closes it.

   CHARACTER DEVICES
     Whether the tap devices are accessed through the special cloning device /dev/tap or through the specific devices /dev/tapN, the possible
     actions to control the matching interface are the same.

     When using /dev/tap though, as the interface is created on-the-fly, its name is not known immediately by the application.	Therefore the
     TAPGIFNAME ioctl is provided.  It should be the first action an application using the special cloning device will do.  It takes a pointer to
     a struct ifreq as an argument.

     Ethernet frames sent out by the kernel on a tap interface can be obtained by the controlling application with read(2).  It can also inject
     frames in the kernel with write(2).  There is absolutely no validation of the content of the injected frame, it can be any data, of any
     length.

     One call of write(2) will inject a single frame in the kernel, as one call of read(2) will retrieve a single frame from the queue, to the
     extent of the provided buffer.  If the buffer is not large enough, the frame will be truncated.

     tap character devices support the FIONREAD ioctl which returns the size of the next available frame, or 0 if there is no available frame in
     the queue.

     They also support non-blocking I/O through the FIONBIO ioctl.  In that mode, EWOULDBLOCK is returned by read(2) when no data is available.

     Asynchronous I/O is supported through the FIOASYNC, FIOSETOWN, and FIOGETOWN ioctls.  The first will enable SIGIO generation, while the two
     other configure the process group that will receive the signal when data is ready.

     Synchronisation may also be achieved through the use of select(2), poll(2), or kevent(2).

   ETHERNET ADDRESS
     When a tap device is created, it is assigned an Ethernet address of the form f2:0b:a4:xx:xx:xx.  This address can later be changed using
     ifconfig(8) to add an active link layer address, or directly via the SIOCALIFADDR ioctl on a PF_LINK socket, as it is not available on the
     ioctl handler of the character device interface.

FILES

     /dev/tap	     cloning device
     /dev/tap[0-9]*  individual character device nodes

SEE ALSO

     bridge(4), etherip(4), tun(4), ifconfig(8)

HISTORY

     The tap driver first appeared in NetBSD 3.0.

BSD
								  March 10, 2009							       BSD