Bart Smaalders wrote: > Cathy Zhou wrote: > >>> Note that I'm not suggesting the door file be packaged - it shouldn't >>> be it is a Project Private communication channel. >>> >> It it is not packaged, then there is the problem that we are not be >> able to create the door file under /etc/dladm because dlmgmtd starts >> before the root FS becomes read-write. > > You end up packaging an empty type f file; the namefs door mount happens > on top of that...
That is what we current have, except that the door file is currently in /etc (/etc/.dlmgmt_door) instead of /etc/dladm, but it caused flashinstall problem described in this case. > so Darren is right, the _door_ isn't package; the file > that is packaged > is what is the door mounts on top of w/ fattach. > > According to the fattach man page (and common sense), the file will need > to be > writable by the dlmgmtd process: > > int fattach(int fildes, const char *path); > > > DESCRIPTION > The fattach() function attaches a STREAMS- or doors-based > file descriptor to an object in the file system name space, > effectively associating a name with fildes. The fildes argu- > ment must be a valid open file descriptor representing a > STREAMS or doors file. The path argument is a path name of > an existing object and the user must have appropriate > privileges or be the owner of the file and have write per- > missions. > Hmm, that is different from my experience. If that is true, this is another reason we have to have the door file located in /etc/svc/volatile/dladm (as proposed in this case). Thanks - Cathy
