Dear List, I''m trying to issue: "xenstore-chmod PATH r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14 r15 r16 r17 r18" it failed at error report "Too many permissions specified. Maximum per invocation is 16." I changed MAX_PERMS to 18 for testing, it turns to be OK to run above command. I don''t know why there is "MAX_PERMS=16" limitation and couldn''t find useful info about that. Does anyone know that? Thanks! Chunyan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Dear List, I''m trying to issue: "xenstore-chmod PATH r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14 r15 r16 r17 r18" it failed at error report "Too many permissions specified. Maximum per invocation is 16." I changed MAX_PERMS to 18 for testing, it turns to be OK to run above command. I don''t know why there is "MAX_PERMS=16" limitation and couldn''t find useful info about that. Does anyone know that? Thanks! Chunyan _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
Dropping users list, please don''t cross post. On Mon, 2012-11-12 at 08:35 +0000, Chunyan Liu wrote:> Dear List, > > I''m trying to issue: > "xenstore-chmod PATH r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14 > r15 r16 r17 r18" > it failed at error report "Too many permissions specified. Maximum > per invocation is 16." > > I changed MAX_PERMS to 18 for testing, it turns to be OK to run above > command. > I don''t know why there is "MAX_PERMS=16" limitation and couldn''t find > useful info about that. Does anyone know that?It seems like an obvious case of an arbitrary constant to me. Do you actually have a practical requirement to be able to set > 16 perms via the command line tool? I can''t see anything obvious in the underlying library which would prevent it handling essentially arbitrary length lists of perms. If you want to change the client to increase the number supported I think you should make it likewise handle arbitrary numbers rather than just increasing MAX_PERMS. Ian.
2012/11/12 Ian Campbell <Ian.Campbell@citrix.com>> Dropping users list, please don''t cross post. >Sorry. Thanks for reminding.> On Mon, 2012-11-12 at 08:35 +0000, Chunyan Liu wrote: > > Dear List, > > > > I''m trying to issue: > > "xenstore-chmod PATH r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14 > > r15 r16 r17 r18" > > it failed at error report "Too many permissions specified. Maximum > > per invocation is 16." > > > > I changed MAX_PERMS to 18 for testing, it turns to be OK to run above > > command. > > I don''t know why there is "MAX_PERMS=16" limitation and couldn''t find > > useful info about that. Does anyone know that? > > It seems like an obvious case of an arbitrary constant to me. > > Do you actually have a practical requirement to be able to set > 16 > perms via the command line tool? > > Yes. Our customer plans to have some hypervisor running above 32 domUs andneeds to share common information between xen domU. He uses xenstore capabilities: i.e. xenstore-write /local/domain/0/foo "8 CPU" Then he gives read access to domU with: xenstore-chmod /local/domain/0/foo r0 r2 r3 r4 r5 r6 r7 r9 r10 r11 r12 r13 r17 r18 r19 r20 r21 r22 With current MAX_PERM limitation, xenstore-chmod will report "Too many permissions specified. Maximum per invocation is 16". And serial commands: xenstore-chmod /local/domain/0/foo r0 xenstore-chmod /local/domain/0/foo r1 ... couldn''t achieve that either. (result will be only the last command).> I can''t see anything obvious in the underlying library which would > prevent it handling essentially arbitrary length lists of perms. If you > want to change the client to increase the number supported I think you > should make it likewise handle arbitrary numbers rather than just > increasing MAX_PERMS. > > Sure, if there is nothing that prevents handling an arbitrary number ofperms, it''s better to handle it like arbitrary numbers rather than increasing MAX_PERMS. I was just not sure if there was some consideration to set a limitation. I''ll modify code and test. Ian.> > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
2012/11/13 Chunyan Liu <cyliu@suse.com>> > > 2012/11/12 Ian Campbell <Ian.Campbell@citrix.com> > >> Dropping users list, please don''t cross post. >> > Sorry. Thanks for reminding. > > >> On Mon, 2012-11-12 at 08:35 +0000, Chunyan Liu wrote: >> > Dear List, >> > >> > I''m trying to issue: >> > "xenstore-chmod PATH r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14 >> > r15 r16 r17 r18" >> > it failed at error report "Too many permissions specified. Maximum >> > per invocation is 16." >> > >> > I changed MAX_PERMS to 18 for testing, it turns to be OK to run above >> > command. >> > I don''t know why there is "MAX_PERMS=16" limitation and couldn''t find >> > useful info about that. Does anyone know that? >> >> It seems like an obvious case of an arbitrary constant to me. >> >> Do you actually have a practical requirement to be able to set > 16 >> perms via the command line tool? >> >> Yes. Our customer plans to have some hypervisor running above 32 domUs > and needs to share common information between xen domU. He uses xenstore > capabilities: > i.e. xenstore-write /local/domain/0/foo "8 CPU" > Then he gives read access to domU with: > xenstore-chmod /local/domain/0/foo r0 r2 r3 r4 r5 r6 r7 r9 r10 r11 r12 r13 > r17 r18 r19 r20 r21 r22 > With current MAX_PERM limitation, xenstore-chmod will report "Too many > permissions specified. Maximum per invocation is 16". > And serial commands: > xenstore-chmod /local/domain/0/foo r0 > xenstore-chmod /local/domain/0/foo r1 > ... > couldn''t achieve that either. (result will be only the last command). > > >> I can''t see anything obvious in the underlying library which would >> prevent it handling essentially arbitrary length lists of perms. If you >> want to change the client to increase the number supported I think you >> should make it likewise handle arbitrary numbers rather than just >> increasing MAX_PERMS. >> >In addition: there is a check for msg.len <= XENSTORE_PAYLOAD_MAX (which is 4096). For chmod, the msg.len = path len + mode len. In current environments, there won''t be so many perms that could exceed the value. But it IS a limitation. Sure, if there is nothing that prevents handling an arbitrary number of> perms, it''s better to handle it like arbitrary numbers rather than > increasing MAX_PERMS. I was just not sure if there was some consideration > to set a limitation. > I''ll modify code and test. > > Ian. >> >> >> >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Thu, 2012-11-15 at 01:51 +0000, Chunyan Liu wrote:> > I can''t see anything obvious in the underlying library > which would > prevent it handling essentially arbitrary length lists > of perms. If you > want to change the client to increase the number > supported I think you > should make it likewise handle arbitrary numbers > rather than just > increasing MAX_PERMS. > > In addition: there is a check for msg.len <= XENSTORE_PAYLOAD_MAX > (which is 4096). > For chmod, the msg.len = path len + mode len. In current environments, > there won''t be so many perms that could exceed the value. But it IS a > limitation.Do you know what it works out as? If atomicity matters you could do it as batches within a transaction, otherwise simple batching would do? Ian.
2012/11/15 Ian Campbell <Ian.Campbell@citrix.com>> On Thu, 2012-11-15 at 01:51 +0000, Chunyan Liu wrote: > > > > I can''t see anything obvious in the underlying library > > which would > > prevent it handling essentially arbitrary length lists > > of perms. If you > > want to change the client to increase the number > > supported I think you > > should make it likewise handle arbitrary numbers > > rather than just > > increasing MAX_PERMS. > > > > In addition: there is a check for msg.len <= XENSTORE_PAYLOAD_MAX > > (which is 4096). > > For chmod, the msg.len = path len + mode len. In current environments, > > there won''t be so many perms that could exceed the value. But it IS a > > limitation. > > Do you know what it works out as? > > If atomicity matters you could do it as batches within a transaction, >Yeah. If exceeding 4096 happens, batches within a transaction is the way out. Same to other commands. But this is purely from coding''s point, in current environments it''s almost impossible to happen :-)> otherwise simple batching would do? > > Ian. > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel