> > OK. Another design we should seriously consider is merging liblaadm, > > libwladm and libdladm into a single library. If there is no longer a > > clear boundary between the layers (which seems to be the case if things > > frequently need to call into one another), then merging into a common > > library may be the simplest approach. Alternatively, it may make sense to > > merge just certain parts -- e.g., APIs that deal with persistent > > configuration (since we now have a single persistent configuration). > > Just wondering, what is the original design rationale those > link layer manipulation libraries should be separated?
You probably need to ask Nicolas Droux about the justification for liblaadm. As with most WiFi architecture, the split between libwladm and libdladm is covered in PSARC/2006/623's materials (lib-wifi.txt). In short, we were following existing precedent with liblaadm, and we thought we might want to make libwladm a public API (since other Unix variants have them) apart from libdladm. Of course, that latter part could be implemented as a filter library over libdladm. -- meem
