Reid McKenzie
2013-08-13 22:20:09 UTC
Hello all, my name is Reid McKenzie and I'm a dev at Calxeda on
assignment to get the thus far rejected cxoem changes reworked
and accepted to the ipmitool mainline.
After reading through the last couple discussions it seems to me
that the most major points of contention on the last round were
our use of strto* in the raw, and the fact that our code uses
IPMI lan param codes
Ours:
IPMI_LANP_TFTP_SERVER_IP=193,
IPMI_LANP_TFTP_UDP_PORT=194,
IPMI_LANP_NTP_SERVER_IP=195,
IPMI_LANP_NTP_UDP_PORT=196,
IPMI_LANP_OEM_OUID=197,
IPMI_LANP_OEM_MAC0=198,
IPMI_LANP_OEM_MAC1=199,
IPMI_LANP_OEM_MAC2=200,
IPMI_LANP_SC_OUID=201,
IPMI_LANP_SC_MODE=202,
IPMI_LANP_SC_FID=203
Yours:
IPMI_LANP_DHCP_SERVER_IP=192,
IPMI_LANP_DHCP_SERVER_MAC=193,
IPMI_LANP_DHCP_ENABLE=194,
IPMI_LANP_CHAN_ACCESS_MODE=201,
I refactored our code to use your str2* helpers today, so that's one
down but I thought I would start a conversation about what a long
term fix for the IPMI params > 192 problem.
My gut reaction reading the codebase today was that the correct
approach is to rework the way that params are handled and instead
of explicitly and sequentially addressing each param in the
monolithic functions ipmi_lan_set and ipmi_lan_print that a more
eligant solution would be to restructure the two into sets of
individual lan parameter handlers reached through an OEM first
lookup structure.
I could also see checking the OEM id first and punting the
set/print entirely to the OEM if an alternative implementation is
provided but defaulting to the current implementation.
It's your codebase, what seems best to you?
Reid "arrdem" McKenzie
- Calxeda ECME Team
assignment to get the thus far rejected cxoem changes reworked
and accepted to the ipmitool mainline.
After reading through the last couple discussions it seems to me
that the most major points of contention on the last round were
our use of strto* in the raw, and the fact that our code uses
IPMI lan param codes
Ours:
IPMI_LANP_TFTP_SERVER_IP=193,
IPMI_LANP_TFTP_UDP_PORT=194,
IPMI_LANP_NTP_SERVER_IP=195,
IPMI_LANP_NTP_UDP_PORT=196,
IPMI_LANP_OEM_OUID=197,
IPMI_LANP_OEM_MAC0=198,
IPMI_LANP_OEM_MAC1=199,
IPMI_LANP_OEM_MAC2=200,
IPMI_LANP_SC_OUID=201,
IPMI_LANP_SC_MODE=202,
IPMI_LANP_SC_FID=203
Yours:
IPMI_LANP_DHCP_SERVER_IP=192,
IPMI_LANP_DHCP_SERVER_MAC=193,
IPMI_LANP_DHCP_ENABLE=194,
IPMI_LANP_CHAN_ACCESS_MODE=201,
I refactored our code to use your str2* helpers today, so that's one
down but I thought I would start a conversation about what a long
term fix for the IPMI params > 192 problem.
My gut reaction reading the codebase today was that the correct
approach is to rework the way that params are handled and instead
of explicitly and sequentially addressing each param in the
monolithic functions ipmi_lan_set and ipmi_lan_print that a more
eligant solution would be to restructure the two into sets of
individual lan parameter handlers reached through an OEM first
lookup structure.
I could also see checking the OEM id first and punting the
set/print entirely to the OEM if an alternative implementation is
provided but defaulting to the current implementation.
It's your codebase, what seems best to you?
Reid "arrdem" McKenzie
- Calxeda ECME Team