This chapter gives an overview of Solaris device drivers. The chapter provides information on the following subjects:Device Driver Basics Device Driver Entry Points Considerations in Device Driver Design This section introduces you to device drivers and their entry points on the Solaris platform.device driversdefinitionpseudo device driverA device driver is a kernel module that is responsible for managing the low-level I/O operations of a hardware device. Device drivers are written with standard interfaces that the kernel can call to interface with a device. Device drivers can also be software-only, emulating a device that exists only in software, such as RAM disks, buses, and pseudo-terminals.A device driver contains all the device-specific code necessary to communicate with a device. This code includes a standard set of interfaces to the rest of the system. This interface shields the kernel from device specifics just as the system call interface protects application programs from platform specifics. Application programs and the rest of the kernel need little, if any, device-specific code to address the device. In this way, device drivers make the system more portable and easier to maintain.When the Solaris operating system (Solaris OS) is initialized, devices identify themselves and are organized into the device tree, a hierarchy of devices. In effect, the device tree is a hardware model for the kernel. An individual device driver is represented as a node in the tree with no children. This type of node is referred to as a leaf driver. A driver that provides services to other drivers is called a bus nexus driver and is shown as a node with children. As part of the boot process, physical devices are mapped to drivers in the tree so that the drivers can be located when needed. For more information on how the Solaris OS accommodates devices, see Chapter 2, Solaris Kernel and Device Tree.Device drivers are classified by how they handle I/O. Device drivers fall into three broad categories:Block device drivers – For cases where handling I/O data as asynchronous chunks is appropriate. Typically, block drivers are used to manage devices with physically addressable storage media, such as disks. Character device drivers – For devices that perform I/O on a continuous flow of bytes.A driver can be both block and character at the same time if you set up two different interfaces to the file system. See Devices as Special Files. Included in the character category are drivers that use the STREAMS model (see below), programmed I/O, direct memory access, SCSI buses, USB, and other network I/O. STREAMS device drivers – Subset of character drivers that uses the streamio7I set of routines for character I/O within the kernel. driver module entry pointsentry pointsentry pointsdefinitiondevice driversentry pointsAn entry point is a function within a device driver that can be called by an external entity to get access to some driver functionality or to operate a device. Each device driver provides a standard set of functions as entry points. For the complete list of entry points for all driver types, see the Intro9E man page. The Solaris kernel uses entry points for these general task areas:Loading and unloading the driver Autoconfiguring the device – Autoconfiguration is the process of loading a device driver's code and static data into memory so that the driver is registered with the system. Providing I/O services for the driver Drivers for different types of devices have different sets of entry points according to the kinds of operations the devices perform. A driver for a memory-mapped character-oriented device, for example, supports a devmap9E entry point, while a block driver does not support this entry.namingunique prefix for driver symbolsprefixunique prefix for driver symbolsUse a prefix based on the name of your driver to give driver functions unique names. Typically, this prefix is the name of the driver, such as xx_open for the open9E routine of driver xx. See Use a Unique Prefix to Avoid Kernel Symbol Collisions for more information. In subsequent examples in this book, xx is used as the driver prefix. This section provides lists of entry points for the following categories:Entry Points Common to All Drivers Entry Points for Block Device Drivers Entry Points for Character Device Drivers Entry Points for STREAMS Device Drivers Entry Points for Memory Mapped Devices Entry Points for the Generic LAN Device (GLD) Driver Entry Points for SCSI HBA Drivers Entry Points for PC Card Drivers Some operations can be performed by any type of driver, such as the functions that are required for module loading and for the required autoconfiguration entry points. This section discusses types of entry points that are common to all drivers. The common entry points are listed in Summary of Common Entry Points with links to man pages and other relevant discussions.Drivers for character and block devices export the cb_ops9S structure, which defines the driver entry points for block device access and character device access. Both types of drivers are required to support the open9E and close9E entry points. Block drivers are required to support strategy9E, while character drivers can choose to implement whatever mix of read9E, write9E, ioctl9E, mmap9E, or devmap9E entry points is appropriate for the type of device. Character drivers can also support a polling interface through chpoll9E. Asynchronous I/O is supported through aread9E and awrite9E for block drivers and those drivers that can use both block and character file systems. _init entry pointrequired implementation_fini entry pointrequired implementation_info entry pointrequired implementationloading modulesAll drivers are required to implement the loadable module entry points _init9E, _fini9E, and _info9E to load, unload, and report information about the driver module.Drivers should allocate and initialize any global resources in _init9E. Drivers should release their resources in _fini9E.In the Solaris OS, only the loadable module routines must be visible outside the driver object module. Other routines can have the storage class static. autoconfigurationroutines Drivers are required to implement the attach9E, detach9E, and getinfo9E entry points for device autoconfiguration. Drivers can also implement the optional entry point probe9E in cases where devices do not identify themselves during boot-up, such as SCSI target devices. See Chapter 6, Driver Autoconfiguration for more information on these routines. The Solaris platform provides a rich set of interfaces to maintain and export kernel-level statistics, also known as kstats. Drivers are free to use these interfaces to export driver and device statistics that can be used by user applications to observe the internal state of the driver. Two entry points are provided for working with kernel statistics:ks_snapshot9E captures kstats at a specific time. ks_update9E can be used to update kstat data at will. ks_update is useful in situations where a device is set up to track kernel data but extracting that data is time-consuming. For further information, see the kstat_create9F and kstat9S man pages. See also Kernel Statistics. Drivers for hardware devices that provide Power Management functionality can support the optional power9E entry point. See Chapter 12, Power Management for details about this entry point. The following table lists entry points that can be used by all types of drivers.Category / Entry Point Usage Description cb_ops Entry Points open9E Required Gets access to a device. Additional information:open() Entry Point (Character Drivers) open() Entry Point (Block Drivers) close9E Required Gives up access to a device. The version of close for STREAMS drivers has a different signature than character and block drivers. Additional information:close() Entry Point (Character Drivers) close() Entry Point (Block Drivers) Loadable Module Entry Points _init9E Required Initializes a loadable module. Additional information: Loadable Driver Interfaces _fini9E Required Prepares a loadable module for unloading. Required for all driver types. Additional information: Loadable Driver Interfaces _info9E Required Returns information about a loadable module. Additional information: Loadable Driver Interfaces Autoconfiguration Entry Points attach9E Required Adds a device to the system as part of initialization. Also used to resume a system that has been suspended. Additional information: attach() Entry Point detach9E Required Detaches a device from the system. Also, used to suspend a device temporarily. Additional information: detach() Entry Point getinfo9E Required Gets device information that is specific to the driver, such as the mapping between a device number and the corresponding instance. Additional information:getinfo() Entry Point getinfo() Entry Point (SCSI Target Drivers). probe9E See Description Determines if a non-self-identifying device is present. Required for a device that cannot identify itself. Additional information:probe() Entry Point probe() Entry Point (SCSI Target Drivers) Kernel Statistics Entry Points ks_snapshot9E Optional Takes a snapshot of kstat9S data. Additional information: Kernel Statistics ks_update9E Optional Updates kstat9S data dynamically. Additional information: Kernel Statistics Power Management Entry Points power9E Required Sets the power level of a device. If not used, set to NULL. Additional information: power() Entry Point Miscellaneous Entry Points prop_op9E See Description Reports driver property information. Required unless ddi_prop_op9F is substituted. Additional information:Creating and Updating Properties prop_op() Entry Point dump9E See Description Dumps memory to a device during system failure. Required for any device that is to be used as the dump device during a panic. Additional information:dump() Entry Point (Block Drivers) Dump Handling identify(9E) Obsolete Do not use this entry point. Assign nulldev9F to this entry point in the dev_ops structure. block driveroverviewdevice driversblock driverDevices that support a file system are known as block devices. Drivers written for these devices are known as block device drivers. Block device drivers take a file system request, in the form of a buf9S structure, and issue the I/O operations to the disk to transfer the specified block. The main interface to the file system is the strategy9E routine. See Chapter 16, Drivers for Block Devices for more information.A block device driver can also provide a character driver interface to enable utility programs to bypass the file system and to access the device directly. This device access is commonly referred to as the raw interface to a block device.The following table lists additional entry points that can be used by block device drivers. See also Entry Points Common to All Drivers.Entry Point Usage Description aread9E Optional Performs an asynchronous read. Drivers that do not support an aread entry point should use the nodev9F error return function. Additional information:Differences Between Synchronous and Asynchronous I/O DMA Transfers (Asynchronous) awrite9E Optional Performs an asynchronous write. Drivers that do not support an awrite entry point should use the nodev9F error return function. Additional information:Differences Between Synchronous and Asynchronous I/O DMA Transfers (Asynchronous) print9E Required Displays a driver message on the system console. Additional information: print() Entry Point (Block Drivers) strategy9E Required Perform block I/O. Additional information:Canceling DMA Callbacks DMA Transfers (Synchronous) strategy() Entry Point DMA Transfers (Asynchronous) General Flow of Control x86 Target Driver Configuration Properties device driversstandard character driver character device driveroverview Character device drivers normally perform I/O in a byte stream. Examples of devices that use character drivers include tape drives and serial ports. Character device drivers can also provide additional interfaces not present in block drivers, such as I/O control (ioctl) commands, memory mapping, and device polling. See Chapter 15, Drivers for Character Devices for more information.I/Obyte streamThe main task of any device driver is to perform I/O, and many character device drivers do what is called byte-stream or character I/O. The driver transfers data to and from the device without using a specific device address. This type of transfer is in contrast to block device drivers, where part of the file system request identifies a specific location on the device.The read9E and write9E entry points handle byte-stream I/O for standard character drivers. See I/O Request Handling for more information.The following table lists additional entry points that can be used by character device drivers. For other entry points, see Entry Points Common to All Drivers.Entry Point Usage Description chpoll9E Optional Polls events for a non-STREAMS character driver. Additional information: Multiplexing I/O on File Descriptors ioctl9E Optional Performs a range of I/O commands for character drivers. ioctl routines must make sure that user data is copied into or out of the kernel address space explicitly using copyin9F, copyout9F, ddi_copyin9F, and ddi_copyout9F, as appropriate. Additional information:ioctl() Entry Point (Character Drivers) Implemented ioctl Functions Well Known ioctl Interfaces read9E Required Reads data from a device. Additional information:Vectored I/O Differences Between Synchronous and Asynchronous I/O Programmed I/O Transfers DMA Transfers (Synchronous) General Flow of Control segmap9E Optional Maps device memory into user space. Additional information:Exporting the Mapping Allocating Kernel Memory for User Access Associating User Mappings With Driver Notifications write9E Required Writes data to a device. Additional information:Device Access Functions Vectored I/O Differences Between Synchronous and Asynchronous I/O Programmed I/O Transfers DMA Transfers (Synchronous) General Flow of Control STREAMSdriversSTREAMS is a separate programming model for writing a character driver. Devices that receive data asynchronously, such as terminal and network devices, are suited to a STREAMS implementation. STREAMS device drivers must provide the loading and autoconfiguration support described in Chapter 6, Driver Autoconfiguration. See the STREAMS Programming Guide for additional information on how to write STREAMS drivers.The following table lists additional entry points that can be used by STREAMS device drivers. For other entry points, see Entry Points Common to All Drivers and Entry Points for Character Device Drivers.Entry Point Usage Description put9E See Description Coordinates the passing of messages from one queue to the next queue in a stream. Required, except for the side of the driver that reads data. Additional information: STREAMS Programming Guide srv9E Required Manipulate messages in a queue. Additional information: STREAMS Programming Guide device memorymappingmemory mappingdevice memory managementFor certain devices, such as frame buffers, providing application programs with direct access to device memory is more efficient than byte-stream I/O. Applications can map device memory into their address spaces using the mmap2 system call. To support memory mapping, device drivers implement segmap9E and devmap9E entry points. For information on devmap9E, see Chapter 10, Mapping Device and Kernel Memory. For information on segmap9E, see Chapter 15, Drivers for Character Devices.Drivers that define the devmap9E entry point usually do not define read9E and write9E entry points, because application programs perform I/O directly to the devices after calling mmap2.The following table lists additional entry points that can be used by character device drivers that use the devmap framework to perform memory mapping. For other entry points, see Entry Points Common to All Drivers and Entry Points for Character Device Drivers.Entry Point Usage Description devmap9E Required Validates and translates virtual mapping for a memory-mapped device. Additional information: Exporting the Mapping devmap_access9E Optional Notifies drivers when an access is made to a mapping with validation or protection problems. Additional information: devmap_access() Entry Point devmap_contextmgt9E Required Performs device context switching on a mapping. Additional information: devmap_contextmgt() Entry Point devmap_dup9E Optional Duplicates a device mapping. Additional information: devmap_dup() Entry Point devmap_map9E Optional Creates a device mapping. Additional information: devmap_map() Entry Point devmap_unmap9E Optional Cancels a device mapping. Additional information: devmap_unmap() Entry Point The following table lists additional entry points that can be used by the general LAN driver (GLD). For more information on GLD drivers, see the gld9E, gld7D, and gld_mac_info9S man pages. For other entry points, see Entry Points Common to All Drivers and Entry Points for Character Device Drivers.Entry Point Usage Description gldm_get_stats9E Optional Gathers statistics from private counters in a generic LAN driver. Updates the gld_stats9S structure. Additional information: gldm_get_stats() Entry Point gldm_intr9E See Description Receives calls for potential interrupts to a generic LAN driver (GLD). Required if gld_intr9F is used as interrupt handler. Additional information: gldm_intr() Entry Point gldm_ioctl9E Optional Implements device-specific commands for a generic LAN driver (GLD). Additional information: gldm_ioctl() Entry Point gldm_reset9E Required Resets a generic LAN driver (GLD) to the initial state. Additional information: gldm_reset() Entry Point gldm_send9E Required Queues a packet to a generic LAN driver (GLD) for transmission. Additional information: gldm_send() Entry Point gldm_set_mac_addr9E Required Sets the physical address that the generic LAN driver (GLD) uses to receive data. Additional information: gldm_set_mac_addr() Entry Point gldm_set_multicast9E Optional Enables and disables device-level reception of specific multicast addresses for generic LAN driver (GLD). Additional information: gldm_set_multicast() Entry Point gldm_set_promiscuous9E Required Enables and disables promiscuous mode for a generic LAN driver (GLD) to receive packets on the medium. Additional information: gldm_set_promiscuous() Entry Point gldm_start9E Required Enables a generic LAN driver (GLD) to generate interrupts. Prepares the driver to call gld_recv9F to deliver received data packets. Additional information: gldm_start() Entry Point gldm_stop9E Required Disables a generic LAN driver (GLD) from generating interrupts and from calling gld_recv9F. Additional information: gldm_stop() Entry Point The following table lists additional entry points that can be used by SCSI HBA device drivers. For information on the SCSI HBA transport structure, see scsi_hba_tran9S. For other entry points, see Entry Points Common to All Drivers and Entry Points for Character Device Drivers.Entry Point Usage Description tran_abort9E Required Aborts a specified SCSI command that has been transported to a SCSI Host Bus Adapter (HBA) driver. Additional information: tran_abort() Entry Point tran_bus_reset9E Optional Resets a SCSI bus. Additional information: tran_bus_reset() Entry Point tran_destroy_pkt9E Required Frees resources that are allocated for a SCSI packet. Additional information: tran_destroy_pkt() Entry Point tran_dmafree9E Required Frees DMA resources that have been allocated for a SCSI packet. Additional information: tran_dmafree() Entry Point tran_getcap9E Required Gets the current value of a specific capability that is provided by the HBA driver. Additional information: tran_getcap() Entry Point tran_init_pkt9E Required Allocate and initialize resources for a SCSI packet. Additional information: Resource Allocation tran_quiesce9E Optional Stop all activity on a SCSI bus, typically for dynamic reconfiguration. Additional information: Dynamic Reconfiguration tran_reset9E Required Resets a SCSI bus or target device. Additional information: tran_reset() Entry Point tran_reset_notify9E Optional Requests notification of a SCSI target device for a bus reset. Additional information: tran_reset_notify() Entry Point tran_setcap9E Required Sets the value of a specific capability that is provided by the SCSI HBA driver. Additional information: tran_setcap() Entry Point tran_start9E Required Requests the transport of a SCSI command. Additional information: tran_start() Entry Point tran_sync_pkt9E Required Synchronizes the view of data by an HBA driver or device. Additional information: tran_sync_pkt() Entry Point tran_tgt_free9E Optional Requests allocated SCSI HBA resources to be freed on behalf of a target device. Additional information:tran_tgt_free() Entry Point Transport Structure Cloning tran_tgt_init9E Optional Requests SCSI HBA resources to be initialized on behalf of a target device. Additional information:tran_tgt_init() Entry Point scsi_device Structure tran_tgt_probe9E Optional Probes a specified target on a SCSI bus. Additional information: tran_tgt_probe() Entry Point tran_unquiesce9E Optional Resumes I/O activity on a SCSI bus after tran_quiesce9E has been called, typically for dynamic reconfiguration. Additional information: Dynamic Reconfiguration The following table lists additional entry points that can be used by PC Card device drivers. For other entry points, see Entry Points Common to All Drivers and Entry Points for Character Device Drivers.Entry Point Usage Description csx_event_handler9E Required Handles events for a PC Card driver. The driver must call the csx_RegisterClient9F function explicitly to set the entry point instead of using a structure field like cb_ops. A device driver must be compatible with the Solaris OS, both as a consumer and provider of services. This section discusses the following issues, which should be considered in device driver design:DDI/DKI Facilities Driver Context Returning Errors Dynamic Memory Allocation Hotplugging DDI/DKIdesign considerationsThe Solaris DDI/DKI interfaces are provided for driver portability. With DDI/DKI, developers can write driver code in a standard fashion without having to worry about hardware or platform differences. This section describes aspects of the DDI/DKI interfaces.The DDI interfaces enable drivers to provide a persistent, unique identifier for a device. The device ID can be used to identify or locate a device. The ID is independent of the device's name or number (dev_t). Applications can use the functions defined in libdevid3LIB to read and manipulate the device IDs registered by the drivers. propertiesoverview The attributes of a device or device driver are specified by properties. A property is a name-value pair. The name is a string that identifies the property with an associated value. Properties can be defined by the FCode of a self-identifying device, by a hardware configuration file (see the driver.conf4 man page), or by the driver itself using the ddi_prop_update9F family of routines. interrupt handlingoverview The DDI/DKI addresses the following aspects of device interrupt handling:Registering device interrupts with the system Removing device interrupts Dispatching interrupts to interrupt handlers interrupt propertydefinitionDevice interrupt sources are contained in a property called interrupt, which is either provided by the PROM of a self-identifying device, in a hardware configuration file, or by the booting system on the x86 platform. Certain DDI mechanisms provide a callback mechanism. DDI functions provide a mechanism for scheduling a callback when a condition is met. Callback functions can be used for the following typical conditions:A transfer has completed A resource has become available A time-out period has expired callback functionsdescription ofCallback functions are somewhat similar to entry points, for example, interrupt handlers. DDI functions that allow callbacks expect the callback function to perform certain tasks. In the case of DMA routines, a callback function must return a value indicating whether the callback function needs to be rescheduled in case of a failure.Callback functions execute as a separate interrupt thread. Callbacks must handle all the usual multithreading issues.A driver must cancel all scheduled callback functions before detaching a device. state structureTo assist device driver writers in allocating state structures, the DDI/DKI provides a set of memory management routines called the software state management routines, also known as the soft-state routines. These routines dynamically allocate, retrieve, and destroy memory items of a specified size, and hide the details of list management. An instance number is used to identify the desired memory item. This number is typically the instance number assigned by the system.Routines are provided for the following tasks:Initialize a driver's soft-state list Allocate space for an instance of a driver's soft state Retrieve a pointer to an instance of a driver's soft state Free the memory for an instance of a driver's soft state Finish using a driver's soft-state list See Loadable Driver Interfaces for an example of how to use these routines. Programmed I/O device access is the act of reading and writing of device registers or device memory by the host CPU. The Solaris DDI provides interfaces for mapping a device's registers or memory by the kernel as well as interfaces for reading and writing to device memory from the driver. These interfaces enable drivers to be developed that are platform and bus independent, by automatically managing any difference in device and host endianness as well as by enforcing any memory-store sequence requirements imposed by the device. The Solaris platform defines a high-level, architecture-independent model for supporting DMA-capable devices. The Solaris DDI shields drivers from platform-specific details. This concept enables a common driver to run on multiple platforms and architectures. The DDI/DKI provides a group of interfaces referred to as layered device interfaces (LDI). These interfaces enable a device to be accessed from within the Solaris kernel. This capability enables developers to write applications that observe kernel device usage. For example, both the prtconf1M and fuser1M commands use LDI to enable system administrators to track aspects of device usage. The LDI is covered in more detail in Chapter 14, Layered Driver Interface (LDI). context of device driverdevice driverscontextThe driver context refers to the condition under which a driver is currently operating. The context limits the operations that a driver can perform. The driver context depends on the executing code that is invoked. Driver code executes in four contexts:User context. A driver entry point has user context when invoked by a user thread in a synchronous fashion. That is, the user thread waits for the system to return from the entry point that was invoked. For example, the read9E entry point of the driver has user context when invoked by a read2 system call. In this case, the driver has access to the user area for copying data into and out of the user thread. Kernel context. A driver function has kernel context when invoked by some part of the kernel. In a block device driver, the strategy9E entry point can be called by the pageout daemon to write pages to the device. Because the page daemon has no relation to the current user thread, strategy9E has kernel context in this case. Interrupt context.Interrupt context is a more restrictive form of kernel context. Interrupt context is invoked as a result of the servicing of an interrupt. Driver interrupt routines operate in interrupt context with an associated interrupt level. Callback routines also operate in an interrupt context. See Chapter 8, Interrupt Handlers for more information. High-level interrupt context.High-level interrupt context is a more restricted form of interrupt context. If ddi_intr_hilevel9F indicates that an interrupt is high level, the driver interrupt handler runs in high-level interrupt context. See Chapter 8, Interrupt Handlers for more information. The manual pages in section 9F document the allowable contexts for each function. For example, in kernel context the driver must not call copyin9F. device driversprinting messageserror messages, printingprinting messagescmn_err functiondescription ofDevice drivers do not usually print messages, except for unexpected errors such as data corruption. Instead, the driver entry points should return error codes so that the application can determine how to handle the error. Use the cmn_err9F function to write messages to a system log that can then be displayed on the console.The format string specifier interpreted by cmn_err9F is similar to the printf3C format string specifier, with the addition of the format %b, which prints bit fields. The first character of the format string can have a special meaning. Calls to cmn_err9F also specify the message level, which indicates the severity label to be printed. See the cmn_err9F man page for more details.The level CE_PANIC has the side effect of crashing the system. This level should be used only if the system is in such an unstable state that to continue would cause more problems. The level can also be used to get a system core dump when debugging. CE_PANIC should not be used in production device drivers. kernelmemoryallocationDevice drivers must be prepared to simultaneously handle all attached devices that the drivers claim to drive. The number of devices that the driver handles should not be limited. All per-device information must be dynamically allocated. void *kmem_alloc(size_t size, int flag);dynamic memory allocationkmem_alloc functionmemory allocationdescription ofThe standard kernel memory allocation routine is kmem_alloc9F. kmem_alloc is similar to the C library routine malloc3C, with the addition of the flag argument. The flag argument can be either KM_SLEEP or KM_NOSLEEP, indicating whether the caller is willing to block if the requested size is not available. If KM_NOSLEEP is set and memory is not available, kmem_alloc9F returns NULL. kmem_zalloc9F is similar to kmem_alloc9F, but also clears the contents of the allocated memory.Kernel memory is a limited resource, not pageable, and competes with user applications and the rest of the kernel for physical memory. Drivers that allocate a large amount of kernel memory can cause system performance to degrade. void kmem_free(void *cp, size_t size);Memory allocated by kmem_alloc9F or by kmem_zalloc9F is returned to the system with kmem_free9F. kmem_free is similar to the C library routine free3C, with the addition of the size argument. Drivers must keep track of the size of each allocated object in order to call kmem_free9F later. hotplugging hot-plughotplugging hotpluggable drivershotplugging SCSI HBA driverand hotplugginghotpluggingand SCSI HBA driverThis manual does not highlight hotplugging information. If you follow the rules and suggestions for writing device drivers given in this book, your driver should be able to handle hotplugging. In particular, make sure that both autoconfiguration (see Chapter 6, Driver Autoconfiguration) and detach9E work correctly in your driver. In addition, if you are designing a driver that uses power management, you should follow the information given in Chapter 12, Power Management. SCSI HBA drivers might need to add a cb_ops structure to their dev_ops structure (see Chapter 18, SCSI Host Bus Adapter Drivers) to take advantage of hotplugging capabilities.Previous versions of the Solaris OS required hotpluggable drivers to include a DT_HOTPLUG property, but this property is no longer required. Driver writers are free, however, to include and use the DT_HOTPLUG property as they see fit.