> > While it's an alternative, I feel like going down that path is hasty > > and for my use case I will probably just patch our local fork of > > OpenvSwitch. > > > > Why so hostile towards this change? Is there a better forum I can > > explain why I believe this problem should be reconsidered? > > Including the PID allows multiple daemons of a single type to run. I also > don't > think you're solving a real problem, because reading a pidfile isn't > difficult. [Alin Gabriel Serdean: ] I think this patch will tamper with multiple datapath setups (AFAIK OVS on Linux still supports it). > > > Is there really anyone that can justify the way socket paths are > > created should contain the PID? You clearly saw the problem with it in > > the Windows code base, but yet pushed on to keep it in the Linux one. > > I simply do not see why you're not taking this patch as a way to > > encourage people to migrate towards a saner default, and somewhere > > down the line maybe even switch the default behavior. > > I think that Windows doesn't support getpid(). MSDN documents it that way, > at least. That is probably why we omit it on Windows, though I do not know > for sure. Guru, is that the reason? > > I don't understand why you want to change this so badly. It's not hard to > read a pidfile. > > I definitely don't want to fork OVS behavior here based on a configuration > flag, as I already explained. > > Basically: I see little benefit to your change, and some drawbacks.
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
