David Bustos wrote: > > You are correct. The idea was that we want you to be in control of > memory allocation, so we don't want to allocate new memory in order to > copy the value over into. So you have to allocate all of the > scf_value_t's and scf_transaction_entry_t's yourself. > > This is a pain. It would be easier for you to just tell us "I'm going > to make a transaction with N values", and we allocate enough memory for > you. I'll try to fix this in the Enhanced SMF Profiles interfaces. > The problem, at least in my case, is that I don't know the length of the current list of values since N is based on what is existing + 1. I'll still need to iterate through the existing values to count what I need to specify for the allocation size. At that point, I may as well do my own allocation on the fly. In my case, I'm just trying to add to the list so it is not a 'set' operation for me. It would certainly be nice to have add/remove semantics as opposed to set. Either that or have a new property type of 'list' that is truly a list of values in which values can be added/removed as opposed to set. The 'list' that is available to me today with the existing interfaces is really just one string with the values space delimited, at least from my perspective.
Or, perhaps not force allocation for scf_entry_add_value by providing some scf_entry_add_value derivative that allows you to add the actual value, not an scf_value_t struct. Without understanding the underlying libscf implementation, I really don't know the feasibility of what I'm suggesting, obviously. >> Additionally, is there any max list length that I need be aware of? How >> about max astring/ustring size? >> > > I believe scf_value_t's are limited to 8Ki or so. I don't think there > is a limit to the number of values in the collection, inherently, but > I do believe that they all have to fit into the transaction request, > which is gathered into an alloca() block. Which I think means that if > your collection is too big, your client will segfault. > David > If that really is the case, I need to know since the collections that I have can get fairly large and I am not placing any restrictions on list length. If libscf is limiting the transaction request (with all of it's included set operations) to the stack limit, I need to know for certain and I'll switch to some other mechanism for storing this data. Granted, my library call(s) might never reach the limit, but I really don't know what the future holds for these lists that I'm creating nor do I know how much is going to be consumed by the transaction request. Even as it stands today, at least for my case, an implementation that uses one long string to maintain this list is going to be difficult for the administrator to read via svcprop, let alone set. Perhaps I should revert back to the idea of having each list entry be maintained as a separate property value. - John
