by Greetings.
Seems there's a potential catch-22 situation between the open (2)
system call & the attach (9E) entry point when a driver is loaded for
the very first time and its device special file doesn't exist yet.
* open (2) requires attach (9E) to create a device file as its valid
argument.
* attach (9E) needs open (2) to initiate the process of loading the
driver.
WDD (Writing Device Driver) has a very brief mention of the "Deferred
Attach" mechanism, where the open (9E) entry point returns ENXIO to
allow attach (9E) to attempt at an unready device.
But what if we have no device number to pass to open (7E) in the first
place?
Also wonder how the user commands devfsadm (1M), drvconfig (1M) and
friends manage to resolve the issue.
For example, putting everything together, curious to see if the
followings are what happen when a new external SCSI hard disk is
attached to a Solaris box. Assume the target minor node, say c1t1d0s0,
is absent from the device tree at the time of running the drvconfig
(1M) command.
1. open (2) system call is invoked to test a range of device candidates
like c0t2d0s0, ..., c0t3d0s0, ..., c1t1d0s0, ...
2. open (7E) entry point returns ENXIO for these candidates and
attempts deferred attachment to them.
3. attach (7E) succeeds with the c1t1d0s0 instance, creates the node
and device files accordingly.
Any idea?
One more thing, can any one please post a sample truss list of the
devfsadm (1M) or drvconfig (1M) command, irrespective of the device
being added.
Pity that there's no R & D machine available to me :-(
Thanks.