Hi Dan and the team, Currently I am working on the door upcalls between the kernel and the devfsadm daemon. A question came up when I am doing the prototype, which is particularly related to the datalink management API implementation.
As I understand, we were planing to have devfsadmd to keep the information of both the active and persistent links. We thought this is especially important because linkid and linkname must be unique across both spaces. But a question comes up when I tried to think how to deal with the case if the daemon exits unexpectedly, for example, devfsadmd is killed by someone: Specifically, devfsadmd manages the table of links, that can be looked up and updated by the kernel (through door upcalls) and by the libdladm (thought door calls). If we find that the daemon exits when we place a door call, the best we can do is to restart the daemon. Here, I can think of two options: a. we could let the daemon manages both persistent and active link configuration. Then when the daemon starts, it needs to reinitialize the link table based on both the persistent configuration and kernel state. The things I am not comfortable with this option is that then the call will cross the boundary between the kernel and the user land for several time. b. the daemon only keep the persistent configuration. Any time, one need the active configuration will need to lookup from the kernel. But somehow, the daemon needs to know the link names and linkids in both space in order to assign unique linkid and link name for a new link. This could be archived by persist link names and linkids for temporary links as well, but those information need to be purged across system reboot. any other options? Thanks - Cathy
