Quoth John Forte on Wed, Aug 15, 2007 at 10:00:16AM -0700: > 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.
Yes, I'm thinking of adding a way to just add values to a property, rather than rewriting it every time. This was the root cause of 6335025. We also know that not having reliable ordering makes the interface less usable than people expect. We would like to fix that, but we're not sure how or when yet. > 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. Yes, if you don't care about allocating memory during the entry_add operation, then skipping the scf_value_t would be easier. > > 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. > > 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, Yes, scf_value_t's allocate 4KiB for data, and scf_transaction_commit() alloca()'s enough data for all of the values. On my amd64 machine, an alloca() test program segfaults after about 10MiB of allocation. (I should note that the minimum amount of memory for the values is alloca()ed, not 4KiB for each.) .... > 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. Well svccfg offers the addpropvalue subcommand. Though if you expect the number of values to be large, it's probably better to deliver a command-line tool which makes the operations more usable. David
