Hi Jean,
On 03/02/09 18:51, Jean McCormack wrote: > jan damborsky wrote: >> Hi Jean, >> >> my apologies for the late comments, please feel to discard >> them if those came post-mortem. >> >> Thank you, >> Jan >> >> >> On 02/25/09 19:23, Jean McCormack wrote: >>> Here's what I'm planning on doing. Please speak up soon if this >>> doesn't look right. >>> This is the result of an office conversation with Ethan and Evan. >>> >>> The name of the service will be svc://system/install/server:default >> >> I am thinking if 'application' category might be more suitable >> than 'system' which is considered to be used for OpenSolaris system >> services: >> >> http://www.opensolaris.org/os/project/smf-doc/smf-dev/smf-book.html#startd-manifest-name >> >> > But does that really apply here? They say application is higher level > apps like apache. The question is, > are we more of a higher level app or an OpenSolaris system service? > Since we're definitely OpenSolaris > that tends to lead me that way. Anyone else have a thought? My feeling is that the definition there is a little bit vague. My impression obtained by taking a look at running OS was that 'system' is considered to be dedicated to the services which are really close to running instance of OpenSolaris and provide low level operating system functions (coreadm, hal, scheduler, boot-archive, ...). Looking at what is under 'application' umbrella, along with high level applications it seems to cover some system services as well (xfs, gdm, fc-cache, ...). From this it seems that boundaries are not strictly specified, so I tend to agree with you and Dave that AI installer might be considered as system service. > >> >>> >>> The method and manifest (svc-install_server and server.xml) will >>> live in usr/src/cmd/installadm. >> >> Looking at the slim_source gate, SMF stuff (methods & manifests) >> are put into separate 'svc' subdirectories - in this case: >> >> usr/src/cmd/installadm/svc >> >> That said, I am not sure this is the right solution (e.g. with respect >> to the goal to follow structure of ON gate), just wanted to point >> this out :-) > > Since my SMF experience aligns with the ON gate I picked accordingly. > I just checked and > coreadm and dumpadm leave their SMF manifest/methods in the base > directory. For ease > of ON checkin as you mentioned, I'm planning on following that > methodology. That sounds good - thanks for checking ! Jan
