Hi, Please see comments inline.
Ellard Edward Pilatowicz wrote: > On Fri, Nov 21, 2008 at 01:02:14PM +0100, Maciej Browarski wrote: >> >> Jerry Jelinek pisze: >>> Maciej Browarski wrote: >>>> Hello, >>>> Is there any consolidate documentation about build of config.xml and >>>> platform.xml files ? >>>> Because information about content are in many documents, but I can't >>>> find exactly what options are correct and possible in this two files. >>> There is no docs because those are project private >>> interfaces. I assume you are trying to create >>> your own brand? Perhaps you can tell us more about >>> what you are trying to do. >>> >>> Thanks, >>> Jerry >> Yes,I try to understand, how Zones works, and how we can configure it. :) > > well, you shouldn't be modifying any of the parameters in platform.xml, > config.xml, or any of the zone xml files. > > once again, what are you trying to do? > >> So I have below question: >> - what are different between privileges set default, prohibited and >> required in config.xml ? > > well, the default privs are the privs that all zones get. > the prohibited privs are ones that can't be added to zones by zonecfg. > the requires pivs are ones that can't be removed from zones by zonecfg. > >> - is this privileges are only information for zoneadm how to configure >> zones or have any impact to create and running zones?(so is this list of >> privileges also are hard coded in kernel and config.xml only inform >> about privileges ?) > > zone privs are not hardcoded into the kernle. > >> - if I change only brand name in config.xml I see this name later in >> zoneadm list -iv, so is this has only impact to zoneadm list or also in >> kernel performance ? (to be more clear, is there any "native" brand hard >> coded in kernel, that native zone is more privileges and faster than >> other names and brand? what exactly information are carry in struct >> brand p_brand and p_brand_data in proc_t structure). > > you will break things if you randomly change zone brand names. > > there is special handling for the "native" brand in the kernel. > if a zone is of type "native", the kernel doesn't invoke any of > the optional brandz interposition callbacks. that said, i don't > think you'd be able to see any observable performance differences. > Please note that there is a "cluster" Brand zone. From the perspective of packaging/patching/updating the "cluster" Brand zone is identical to the "native" brand. If the "native" Brand zone ever gets any other kind of special treatment, the "cluster" Brand zone will need the same treatment. The "cluster" Brand zone is really a "native" Brand zone with cluster hooks. > the p_brand and p_brand_data structures are used to keep track > of process brand specific data. > >> - which options determinate that packages are also installed/updated >> from global zone (so if I like to have old packages, not updated in >> zones but without -G options). I aware that I can break depend >> between packages. > > the packaging tools ignore all non-native (ie, branded) zones. > there is no "brand" flag that tells the packaging system to keep > a branded zone in sync with the global zone. > No. The "cluster" brand zone is treated just like a "native" brand zone by the packaging tools. We have a PSARC contract on this point. The Solaris software should NEVER assume that a brand zone is Always different from the "native" brand zone type. The "cluster" brand zone needs the same support as the "native" brand zone. >> - if I clear attach and detach options packages, will be not checked in >> zoneadm attach and attached will be successful ? >> > > i don't really understand this question. > > ed > _______________________________________________ > zones-discuss mailing list > firstname.lastname@example.org _______________________________________________ zones-discuss mailing list email@example.com