Re: [zones-discuss] SXCE b130 zoneadm attach -u error
On 01/18/10 19:25, Karl Rossing wrote: I made the change as per http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6905313 What changes? As of this morning the bug has no workaround or suggested fix listed? I'm still getting the following error: bash-4.0# zoneadm -z model attach -u Getting the list of files to remove Removing 45892 files svccfg: pg_pattern is missing the target attribute in system/rmtmpfiles svccfg: pg_pattern is missing the target attribute in system/boot-config I/O error : Is a directory /a/var/svc/manifest/application/desktop-cache:1: parser error : Document is empty ^ /a/var/svc/manifest/application/desktop-cache:1: parser error : Start tag expected, '<' not found ^ I/O error : Is a directory svccfg: couldn't parse document rm: /a/var/svc/manifest/application/desktop-cache is a directory Remove 578 of 578 packages Installing 42309 files /usr/lib/brand/native/attach_update[635]: syntax error at line 644 : `"' unmatched This looks like you made some sort of incorrect edit to this file. zone 'model': 'attach_update' failed with exit code 2. could not update zone bash-4.0# zoneadm -z model attach -u zoneadm: zone 'model': zone is incomplete; uninstall required. Any suggestions on how to fix this? Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] SXCE b130 zoneadm attach -u error
I checked it again, and it seems to be ok. I'm wondering if the JIVE form is not stripping out some characters. So I grabbed the changes from the pipermail. http://mail.opensolaris.org/pipermail/zones-discuss/2009-December/005914.html It now seems to have worked. -- This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
On Mon, Jan 18, 2010 at 12:51:27PM -0700, Jerry Jelinek wrote: > Ed, > > Thanks for reviewing this, my responses are inline. > > On 01/15/10 19:26, Edward Pilatowicz wrote: > >On Thu, Jan 14, 2010 at 09:18:20AM -0700, Jerry Jelinek wrote: > >>I need a code review for my proposed fix for: > >> > >>6887823 brandz on x86 should ignore %gs and simplify brand hooks > >> > >>There is a webrev at: > >> > >>http://cr.opensolaris.org/~gjelinek/webrev.6887823/ > >> > >>This simplifies some of the handling for the %gs register, cleans up > >>the interfaces with the brand modules, and consolidates common code > >>into a single file. Although the webrev looks large, most of this is > >>because > >>of moving the common code. > >> > > > >hey jerry, > >looks good. a few comments below. > >ed > > > >-- > >usr/src/uts/i86pc/ml/syscall_asm.s > > > >- so i think the following comment is true for lcall and int syscalls on > > 32-bit kernels: > > > > * -- > > * | user's %ss | > > *|| user's %esp| > > *|| EFLAGS register| > > *|| user's %cs | > > *|| user's %eip (user return address) | > > *|| 'scratch space'| > > > > but what about sysenter syscalls? none of that stuff will be on the > > stack. (that's why BRAND_CALLBACK used to explicitly push the user > > return address onto the stack.) have you tested with sysenter > > syscalls on 32-bit kernels? > > I haven't really changed this. If you look at the original code in > syscall_asm.s, > all it was doing was re-pushing a value that was already on the stack. This > is line > 152 in the original code in syscall_asm.s. The reason this works is that the > sysenter callback doesn't use the data from the stack since the return address > is in the %edx register (see the comment on the callback in > s10_brand_asm.s or sn1_brand_asm.s). The SYSCALL_EMUL macro > expects the return address to be in a register, not on the stack. > ok. i got it this time around. man, this stuff is always confusing... > >-- > >usr/src/uts/intel/brand/*/*_brand_asm.s > > > >- you've removed all the comments that explain how the stack frame looks > > and what the assumptions are when we enter the different handlers. i > > realize this is all documented in brand_asm.h now, but now folks don't > > know how to map each of the handlers to their running conditions. it'd > > be nice if there was a comment for each handler pointing people to that > > the correct comments that apply to each handler. > > > > perhaps it would make sense to add some "tokens" to the comments in > > brand_asm.h like: > > 32-BIT INTERPOSITION STACK > > 32-BIT LCALL/INT STACK > > 64-BIT INTERPOSITION STACK > > 64-BIT LCALL/INT STACK > > > > and then in the comments for each brand callback you could refer the > > reader to the appropriate tokens in brand_asm.h. > > I added this. > could you add references to these tokens to lx_brand_asm.s as well? thanks for cleaning all this stuff up. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
On 01/19/10 14:00, Edward Pilatowicz wrote: perhaps it would make sense to add some "tokens" to the comments in brand_asm.h like: 32-BIT INTERPOSITION STACK 32-BIT LCALL/INT STACK 64-BIT INTERPOSITION STACK 64-BIT LCALL/INT STACK and then in the comments for each brand callback you could refer the reader to the appropriate tokens in brand_asm.h. I added this. could you add references to these tokens to lx_brand_asm.s as well? Ed, Will do, sorry for not adding this yesterday. Do you want to re-review it again after that comment change? Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
On Tue, Jan 19, 2010 at 02:33:15PM -0700, Jerry Jelinek wrote: > On 01/19/10 14:00, Edward Pilatowicz wrote: > >>> perhaps it would make sense to add some "tokens" to the comments in > >>> brand_asm.h like: > >>> 32-BIT INTERPOSITION STACK > >>> 32-BIT LCALL/INT STACK > >>> 64-BIT INTERPOSITION STACK > >>> 64-BIT LCALL/INT STACK > >>> > >>> and then in the comments for each brand callback you could refer the > >>> reader to the appropriate tokens in brand_asm.h. > >> > >>I added this. > >> > > > >could you add references to these tokens to lx_brand_asm.s as well? > > Ed, > > Will do, sorry for not adding this yesterday. Do you want to re-review it > again after that comment change? > not really. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
