Cc'ed Nicolas.
Peter Memishian wrote:
> > > 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.
I guess we need to hear from Nicolas about this before
deciding if it is a good idea to merge the libraries.
There may be a very important design reason why liblaadm
is a separate library and we'd better follow that.
--
K. Poon.
kacheong.poon at sun.com
