Alan Maguire wrote:
responses to Dave's code review comments follow...
trimmed down to just a couple:
in.rdisc.c: this file shouldn't have been changed at all.
it was just moved, i updated the copyright info since wx pbchk was complaining.
maybe this is wx ignorance on my part - it still needs to be in the active list
due to the move, right?
Interesting question - Teamware putbacks unassisted by wx will handle
the rename without any other change just fine. Additionally, suggested
copyright update policy is to only update on significant changes, and a
rename without any other change doesn't seem to qualify. Thus I think
wx is in error for complaining here.
routing.xml: could you add comments as to the reason for each dependency?
sure.
svc-routeadm:
44: this whole nawk script is sufficient evidence that routeadm -p ought
to be enhanced. At the very least please file an RFE to add
functionality sufficient to eliminate this, if you don't have the
ability to add it in this project.
good idea - how about supporting:
# routeadm -p current/option_name
# routeadm -p default/option_name
# routeadm -p option_name (default gives current option value)
in addition to routeadm -p with no arguments? this may require
a PSARC fasttrack, i'll look into it.
Yes, I'm sure it will. Your basic idea seems sound.
net-loopback:
52: I don't get why the service enables that are done in net-routing
based on this aren't just put here.
if i can remember i was trying to keep all routing-related configuration
in network/routing, though introducing another /etc file is a pretty
lame way of doing it. also, thinking about it i suspect that on first boot,
since manifest-import might not have run at this point, these service state
changes would fail (whether they were made by an in-seed network/routing
service or by network/loopback). maybe the right answer here is adding
an initialize_routing property to network/loopback that network/routing
(no longer in the seed as you suggest below) can pick up after manifest-import
runs?
A property seems reasonable. There may be a reason to prefer putting it
on one service or the other, but I don't have an offhand thought as to
which one.
Dave
_______________________________________________
networking-discuss mailing list
[email protected]
