Cathy Zhou wrote: > 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. >
Correct. > 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. > I agree, this option could get a little ugly. > 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. > The Enhanced SMF profile project mentions in their design document that they plan to add the ability to create temporary profiles that will not persist across reboots. The document is at: http://www.opensolaris.org/os/project/smf-profiles/Design/ I see two problems here: We have not made the decision to use SMF to persist configuration information (though it looks likely) and I don't know when this feature will be available. I think b is the way to go. If we don't (or can't) use SMF and/or the enhanced profiles, we can find a way to record the link name/id mapping such that if devfsadmd is restarted, then we load the internal data structures with the data. If the system is rebooted, then we purge the temporary information and only load the persistent information. > any other options? > Everything I've thought of so far has been a variation on option b. If I think of anything else, I'll put it out for review. Dan > Thanks > - Cathy > > _________________________________ > clearview-discuss mailing list > clearview-discuss at opensolaris.org
