James Carlson wrote:
> Using the same interface in many places means that code using this
> stuff becomes simpler and more uniform. I think that's generally a
> good thing.
In the particular case in this thread, does embedding
a sockaddr_storage (not a pointer to sockaddr_*) in the
vrrp_vr_t struct actually make the code handling simpler?
I think it only makes the struct bigger without making
anything simpler. Regardless what the "outer" container
is, the code only needs to extract the addres...
> If there were consensus in the industry that using sockaddr for
> addresses alone was wrong and that there needed to be a new interface,
> then I could see inventing something new and starting a transition.
>
> As it is, I don't see what would drive that transition (I don't think
> it'd be _us_), and thus it looks like fracture without real gain.
> It'd just not be that substantial an innovation to me.
I guess we are not talking about innovation here. We are
talking about writing new code which wants to pass an IP
address around. The question is why it is preferred to
use sockaddr_storage. Why does it look like a "fracture"
in the code base here if sockaddr_storage is not used?
> I'd use an array of specific type entries, not sockaddr_storage, just
> like sctp_bindx. There's some waste, as you don't need all those
> sin_port entries for plain addresses but you do need them for binding,
> but it's not a great deal.
Actually, people had complained about exactly this. In
some platforms, it is a big deal for doing that in crossing
the user/kernel boundary. Then people said exactly what
Jim mentioned above...
Anyway, I think forcing new code which needs to pass an IP
address around to use sockaddr_storage seems inappropriate
to me.
--
K. Poon.
[EMAIL PROTECTED]
_______________________________________________
networking-discuss mailing list
[email protected]
