OpenSolaris

Discussions Communities Projects Download Source Browser

Home » OpenSolaris Forums » device drivers » discuss

Thread: How do nexus drivers work?

Welcome, Guest Help
Login Login
Guest Settings Guest Settings
Reply to this Thread Reply to this Thread Search Forum Search Forum Back to Thread List Back to Thread List

Permlink Replies: 2 - Last Post: Oct 30, 2006 10:19 AM by: gdamore
d3atiq

Posts: 211
From: BR

Registered: 6/16/05
How do nexus drivers work?
Posted: Oct 26, 2006 8:11 AM
To: Communities » device drivers » discuss
  Click to reply to this thread Reply

Hi,
I am curious about nexus drivers. There seems to be not much information about what they are, how they work and how to create one of them. Is there any introductory article to them? Which kinds of devices they are used for and which standard interfaces are used to program them, how they are different of leaf character and block drivers, among other information, would be desirable.

-- Douglas

mrym

Posts: 178
From: JP

Registered: 3/19/06
Re: How do nexus drivers work?
Posted: Oct 27, 2006 6:20 PM   in response to: d3atiq
To: Communities » device drivers » discuss
  Click to reply to this thread Reply

The nexus driver are private, that means they are *NOT* in DDI/DDI interface
and there are no detailed documentation for them, as long as I know.
The only information on them are their source code.

The nexus drivers are responsible for mapping between parent buses and
the child buses, i.e. between the system bus and IO buses.

For example, device drivers for PCI devices manipulate the devices
in notation of PCI address space, not of system bus. Therefore, when it
maps a register in the device into kernel virtual space by calling ddi_regs_map_setup(), it specifies the address of the register in PCI
address space. But to achieve that, corresponding physical address in
the system bus must be set in hardware MMU page table. Who convert the
address in pci address space to that in system bus? The answer is the
parent nexus driver of the device. ddi_regs_map_setup() implies to
call some methods in the parent nexus driver.

In generally, mapping-register operations, dma mapping related operations
and interrupt related operations in device drivers with DDI/DKI functions
may imply to invoke methods in the parent nexus driver.

In addition, the nexus drivers are responsible to detect and to create
child driver nodes.

-masa

gdamore

Posts: 1,321
From: US

Registered: 4/27/05
Re: How do nexus drivers work?
Posted: Oct 30, 2006 10:19 AM   in response to: d3atiq

  Click to reply to this thread Reply

Douglas Atique wrote:
> Hi,
> I am curious about nexus drivers. There seems to be not much information about what they are, how they work and how to create one of them. Is there any introductory article to them? Which kinds of devices they are used for and which standard interfaces are used to program them, how they are different of leaf character and block drivers, among other information, would be desirable.
>
> -- Douglas
>

The nexus driver interfaces are one area where Solaris sadly lacks any
documentation. (With the special exception of SCSA used for host bus
adapters.)

A quick synopsis of driver types:

Nexus drivers are drivers for busses (e.g. PCI, Cardbus, USB, etc.)
and such. They are characterized by having children in the device
tree. Nexus drivers also have a bus_ops declared. Some nexus drivers
can also be leaf drivers. There is no documented way to create a nexus
device (except for SCSI and similar host bus adapters that can use the
SCSA framework.)

Leaf drivers are devices that do not have children. They are
characterized by defining a cb_ops. Leaf drivers can further be broken
down:

Character devices typically operate on single characters or ioctls
at a time, and declare the appropriate entry points in cb_ops (open,
close, write, read, ioctl, etc.) A driver that supports character
devices may also support block devices. (The distinction is usually
based on the minor node.)

Block devices declare at least strategy() in cb_ops, as well as
open/close, and may also provide dump and ioctl. Other routines (such
as read/write) are typically defined in terms of "strategy" (using
physio), and must operate on a block (typically 512 bytes) at a time.
Again, a driver may support both character and block devices on the same
physical device, using different minor nodes.

STREAMs devices operate on messages (mblks), and are characterized
by having a non-NULL cb_str member of cb_ops. STREAMs devices are most
often associated with serial ports, input devices (keyboards/mice) and
network devices. A device that is a STREAMS device cannot also be a
character or block device, due to limitations in the DDI device framework.

Hope that helps.

-- Garrett
>
>
> This message posted from opensolaris.org
> _______________________________________________
> driver-discuss mailing list
> driver-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/driver-discuss
>


--
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134 Fax: 951 325-2191

_______________________________________________
driver-discuss mailing list
driver-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss






Terms of Use | Privacy | Trademarks | Copyright Policy | Site Guidelines
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Use.
Copyright © 1995-2005 Sun Microsystems, Inc.