2009/200 Solaris Simlinks

[James Carlson]

Darren Reed writes:
> The horse may have bolted on this (approved at this morning's PSARC)
> but...

Actually, we're waiting on a new spec from Rishi to give the final
name for the object.  But, yes, otherwise I was headed to close the
case.

> (putting my PSARC intern hat on)
> 
> The OpenSolaris networking community needs to come up with a better
> architecture for dladm that doesn't require a new binary to be
> delivered every time new subcommands need to be added for new link
> types. Not only does this hinder development of new link types (a
> complete new dladm needs to be built and shipped), it is crowding
> the man page for dladm(1m). That is a poor architecture and needs
> to be improved. Looking at how the userland tools work with
> filesystems (/usr/lib/fs, mount_pcfs(1m), etc) is recommended.

Some refactoring would be nice to see, but it's not this project.

> The existing architecture of a monolithic dladm command needs
> improvement and while it is outside of the scope of this project
> to do that, I'd like to suggest that the ARC consider requiring
> any future projects that touches dladm to provide a better
> architecture for it that addresses the above concerns.

I think that's actually a bit out of scope, even there.

The "dladm project team" (if there could be such a thing) has not
exhausted the goodness that could be obtained by a decent factoring of
functionality between the command line utility and the supporting
library, let alone what could be done with a simple source-based
modular design for the application.

It doesn't seem quite necessary to reach yet for exotica such as
plug-ins or wrapped external executables, as with the 'fs' tools.  The
issues just aren't the same; it's not clear that the rest of the
system architecture (including kernel) is ready for non-integrated
contributions in this area.

If the design were better, I'd be inclined to agree.  Given the
current state of things, I think it's just jumping the gun.

But if a separate project team were to come forward with such a
proposal for review, I don't think I'd be opposed just because I think
simpler fixes are possible.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677