From owner-svn-src-head@FreeBSD.ORG Mon Apr 30 12:19:07 2012 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED7DA106566B; Mon, 30 Apr 2012 12:19:07 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7EBCA8FC12; Mon, 30 Apr 2012 12:19:07 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1SOpZR-0002ZB-FE; Mon, 30 Apr 2012 16:19:13 +0400 Message-ID: <4F9E82DA.4030406@FreeBSD.org> Date: Mon, 30 Apr 2012 16:17:30 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: Gleb Smirnoff References: <201204301022.q3UAMNcq060049@svn.freebsd.org> <20120430114836.GA62284@onelab2.iet.unipi.it> <20120430113610.GC18777@FreeBSD.org> In-Reply-To: <20120430113610.GC18777@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, ae@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Luigi Rizzo Subject: Re: svn commit: r234834 - in head/sys: contrib/pf/net net netinet netinet/ipfw ofed/drivers/infiniband/ulp/ipoib X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 12:19:08 -0000 On 30.04.2012 15:36, Gleb Smirnoff wrote: > On Mon, Apr 30, 2012 at 01:48:36PM +0200, Luigi Rizzo wrote: > L> On Mon, Apr 30, 2012 at 10:22:23AM +0000, Alexander V. Chernikov wrote: > L> > Author: melifaro > L> > Date: Mon Apr 30 10:22:23 2012 > L> > New Revision: 234834 > L> > URL: http://svn.freebsd.org/changeset/base/234834 > L> > > L> > Log: > L> > Move several enums and structures required for L2 filtering from ip_fw_private.h to ip_fw.h. > L> > L> I would be really grateful if you could revert this back and discuss > L> what you wanted to achieve with this change other than saving one > L> entry in the list of includes. Changing something inside ip_fw_private.h (for example, locking change) requires changes in several totally unrelated subsystems, which is clearly bad. > L> > L> As clearly mentioned in the commit logs > L> > L> http://svnweb.freebsd.org/base?view=revision&revision=200580 Maybe there are some other possibilities documenting preferred layout other than commit log? Searching 2+yrs commit history is not the best way of finding information. > L> > L> when i did the last revision of the ipfw+dummynet code i tried > L> to put a strong separation between what is visible in userland > L> (ip_fw.h and ip_dummynet.h) and kernel specific stuff. > L> This way changes in the kernel code do not need to affect userland, > L> modify installed headers and so on. > L> > L> This is why kernel-specific definitions were put in private files. Unfortunately, it is not so obvious (at least for me "ip_fw_ _private__.h" looks much like "ipfw private headers, used by ipfw subsystem only", not "kernel ipfw specific stuff"). > L> We may discuss on the filename, ip_fw_kernel.h may be a better fit, Personally I prefer glebius@ suggestion with ip_fw_var.h for such common headers. > L> but merging back kernel and userland defs is a bad design decision. So should style(9) be updated with "_KERNEL define is bad" line to make newcomers aware of this "easy" way ? :) > L> > L> 20-30 years ago there were good reasons to use a single header > L> for all sorts of definitions: user-only, kernel-only, and kernel-userland API. > L> Machines were slow, disks were small, portability was not a big deal. > L> > L> These days none of these conditions apply and keeping things > L> separate helps maintainance and avoid accidental pollution of > L> definitions and their misuse. > L> > L> Besides, keep in mind that ipfw and dummynet are meant to work > L> on multiple platforms so this change is causing portability troubles. > > Can we split ip_fw_private.h to ip_fw_private.h, and ip_fw_var.h? The > former is really private, and the latter is for other kernel modules.