Re: patch to remove random #define MIN/MAX implementations from around the kernel
On Tue, Jan 21, 2003 at 07:25:44PM -0800, Matthew Dillon wrote: This patch is going to go in on the weekend unless someone has any worthwhile nits about it. It was submitted by Hiten Pandya. Index: contrib/dev/oltr/if_oltr.c Index: contrib/ipfilter/netinet/ip_proxy.c Index: netinet6/nd6.c You shouldn't modify vendor code for minor purposes. Kris msg39348/pgp0.pgp Description: PGP signature
Re: patch to remove random #define MIN/MAX implementations from around the kernel
:On Tue, Jan 21, 2003 at 07:25:44PM -0800, Matthew Dillon wrote: : This patch is going to go in on the weekend unless someone has any : worthwhile nits about it. It was submitted by Hiten Pandya. : : Index: contrib/dev/oltr/if_oltr.c : : Index: contrib/ipfilter/netinet/ip_proxy.c : : Index: netinet6/nd6.c : :You shouldn't modify vendor code for minor purposes. : :Kris The vendor code in question has been modified *extensively* since it was imported, (and of course I would give Darren a head's up in regards to ipfilter). Unless you have a more specific reason I don't really think a general blanket statement is sufficient reason to not do the commit, at least not in this case. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: patch to remove random #define MIN/MAX implementations from around the kernel
Matthew Dillon wrote: :On Tue, Jan 21, 2003 at 07:25:44PM -0800, Matthew Dillon wrote: : This patch is going to go in on the weekend unless someone has any : worthwhile nits about it. It was submitted by Hiten Pandya. : : Index: contrib/dev/oltr/if_oltr.c : : Index: contrib/ipfilter/netinet/ip_proxy.c : : Index: netinet6/nd6.c : :You shouldn't modify vendor code for minor purposes. : :Kris The vendor code in question has been modified *extensively* since it was imported, (and of course I would give Darren a head's up in regards to ipfilter). Unless you have a more specific reason I don't really think a general blanket statement is sufficient reason to not do the commit, at least not in this case. Didn't we explicitly make it like this? ie: you'd be backing out a previous set of intentional commits by doing this... Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: patch to remove random #define MIN/MAX implementations from around the kernel
:Didn't we explicitly make it like this? ie: you'd be backing out a :previous set of intentional commits by doing this... : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] I'm not aware of anything like that. The MIN code appears to be in rev 1.1 of oltr, ipfilter, and netinet6/nd6.c. Is there a commit rev you want me to review on any of these? -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: patch to remove random #define MIN/MAX implementations from around the kernel
On Tue, Jan 21, 2003 at 08:02:59PM -0800, Matthew Dillon wrote: :You shouldn't modify vendor code for minor purposes. : :Kris The vendor code in question has been modified *extensively* since it was imported, (and of course I would give Darren a head's up in regards to ipfilter). Unless you have a more specific reason I don't really think a general blanket statement is sufficient reason to not do the commit, at least not in this case. I think you need to respect vendor code, and the FreeBSD committers who maintain it. Kris msg39355/pgp0.pgp Description: PGP signature
