> It is more future proofing. How about I do something like: > > dladm_create_conf(const char *name, const char *class, dladm_linkid_t > id, dladm_conf_t *conf, void *args); > > Where args is marked for future growth?
I could see the need if we plan to make this API public now. Is that the plan? If not, I'd defer adding `args' until such a time. > We could do this. This does make renaming a little more complicated > since there's a particular order things have to happen. If we went this > route I would want to add Cathy's suggested conf_rename function, and we > might also want to make name a read only field of the configuration. That sounds fine to me. > > This is certainly something worth some thought, but my gut reaction is > > that recovery of temporary state across it crashing is no more a > > requirement than recovery of temporary state across a kernel crash. > > I think we might have situations where we would have undesirable > behavior. I'd need to think about this. Do you think this problem > should be solved before we continue? I think what we have is pretty > high level, and we can begin work on the internals. I think it's OK to proceed with what we have. > > That said, I *think* we'd need to make some changes to the API to satisfy > > the first notion of safety. Specifically, since some changes require > > atomically applying changes to several links (e.g., creating an > > aggregation with two links), I think read_conf()/write_conf() would need > > to operate on the entire persistent configuration, rather than just a > > given link. With that approach, I think it would also be possible to > > detect/prevent update collisions -- e.g., you could store a generation > > number associated with the configuration that is returned when it is read, > > and then bump that number when it's written out. If the number doesn't > > match across the read()/write(), then the writer is forced to go re-read > > to pull in the latest changes (and generation number), and then retry the > > write() if appropriate. > > I see what you're saying. I think it would work, and I think we could > hide the details of how it worked, and the only API change would be a > new error value. Let me think about that. Yes, I think this could (and ideally should) be completely hidden from the API user other than an "update collision" error code. -- meem
