On Fri, Jan 16, 2026 at 01:18:28AM +0900, Hyeonggeun Oh wrote: > Subject: Re: [PATCH v2] MINOR: cfgparse: Refactor "peers" to print it in > -dKall operation > Hello William. > Thanks for your kind reply and comments. > > I'll divide one big patch into 2~3 patches for review. > I apologize for that point, as I'm still unfamiliar with contributing to > HAProxy. > I'll try to get used to it quickly.
No problem! > > The reason I wrote the list_for_each_entry() function twice in the patch > was because I believed peers_kw_list structure contains code related to the > actual peers implementation logic, > while cfg_kw_list was written for configuration parsing. > > Additionally, I was worried about the side effects when merging > peers_kw_list to cfg_kw_list. > Regarding this, please let me know if there are any anticipated side > effects related to the role of peers_kw_list or its integration. Looking at both peers_register_keywords and peers_kw_list, it does not seem that they are used inside haproxy, so I believe they were made so one could integrate keywords from EXTRA_OBJS linked within HAProxy. What you could do is modify the "peers_keywords.list" in the iteration and use the cfg_kw_list insted, but keep the rc < 0 and rc > 0 part handling the print of the message, so people using the previous registering system would just have to change the registration, but would keep their existing parsing functions with the same return value. > I'll verify the feasibility of integration through additional debugging of > the peers-related logic and proceed with the integration. > > Thanks, > Hyeonggeun. > Regards, -- William Lallemand
