Erik Nordmark wrote:
> For IP we have a set of objects that can be created, destroyed, with
> properties (IP addresses, etc).
>
> But for the transports all we have is a set of properties.
> The latter can be handled with a "sysctl-like" approach where the name of
> the property is hiearchical e.g. tcp/tcp_wait_timer.
>
> For components other that IP which have objects which can be created and
> destroyed it might make sense to introduce a separate command to keep
> things clean; hard to predict. Do we have examples of such components?
Kacheong Poon wrote:
>
> I guess ipadm is just fine for handling IP and its
> friends in kernel. I don't think one will run TCP
> on top of network layer other than IP, right? They
> are so tightly coupled together that it makes sense
> to use the same admin command to configure them. I
> think it is more admin friendly. And doesn't this
> also make it easy for the CLI to detect possible config
> inconsistencies between IP and its friends?
>
> Apps can have their own *adm.
>
Here's a suggestion: have only one command: ipadm.
Allow a -m <transport_proto> flag (or -p or -t or -u or -favorite_alphabet)
to the relevant ipadm property commands to indicate the targetted ULP.
Thus the ipadm prop command becomes
# ipadm {set,get}-prop -p <name>=<value> \
[-m <proto>] [<interface>]
Applies the property setting <name>=<value> for [<proto>]-over-IP.
If <interface> is specified, it must exist when the above is invoked.
If no <interface> is specified, the property is set for all interfaces
including those created after the above command.
--Sowmini
