From: David Miller <davem@davemloft•net>
To: paul.moore@hp•com
Cc: redhat-lspp@redhat•com, selinux@tycho•nsa.gov,
linux-security-module@vger•kernel.org, netdev@vger•kernel.org,
sds@epoch•ncsc.mil, jmorris@redhat•com, sgrubb@redhat•com
Subject: Re: [RFC 2/7] NetLabel: core network changes
Date: Thu, 22 Jun 2006 02:07:48 -0700 (PDT) [thread overview]
Message-ID: <20060622.020748.85685000.davem@davemloft.net> (raw)
In-Reply-To: <20060621200030.880930000@flek.zko.hp.com>
From: paul.moore@hp•com
Date: Wed, 21 Jun 2006 15:42:37 -0400
> Index: linux-2.6.17.i686-quilt/net/ipv4/Makefile
> ===================================================================
> --- linux-2.6.17.i686-quilt.orig/net/ipv4/Makefile
> +++ linux-2.6.17.i686-quilt/net/ipv4/Makefile
> @@ -42,6 +42,9 @@ obj-$(CONFIG_TCP_CONG_HYBLA) += tcp_hybl
> obj-$(CONFIG_TCP_CONG_HTCP) += tcp_htcp.o
> obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o
> obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o
> +ifeq ($(CONFIG_NETLABEL_CIPSOV4),y)
> +obj-y += cipso_ipv4.o
> +endif
Why not "obj-$CONFIG_NETLABEL_CIPSOV4 += cipso_ipv4.o"?
The whole idea behind the obj-$CONFIG_OPTION technique is
to avoid conditionals all over the makefile.
> Index: linux-2.6.17.i686-quilt/net/ipv4/af_inet.c
> ===================================================================
> --- linux-2.6.17.i686-quilt.orig/net/ipv4/af_inet.c
> +++ linux-2.6.17.i686-quilt/net/ipv4/af_inet.c
> @@ -114,6 +114,7 @@
> #ifdef CONFIG_IP_MROUTE
> #include <linux/mroute.h>
> #endif
> +#include <net/netlabel.h>
>
> DEFINE_SNMP_STAT(struct linux_mib, net_statistics) __read_mostly;
>
> @@ -616,6 +617,8 @@ int inet_accept(struct socket *sock, str
>
> sock_graft(sk2, newsock);
>
> + netlbl_socket_inet_accept(sock, newsock);
> +
> newsock->state = SS_CONNECTED;
> err = 0;
> release_sock(sk2);
Neither the netlabel.h header not the implementation of
the netlbl_socket_inet_accept() function exist at this
point in your patch set.
At each patch point, the tree must build and function
properly.
This means you have to split up and order your changes
correctly, gradually building up the infrastructure and
then finally plugging it in and making use of it.
Nobody can test your work in an incremental fashion, and
thus it's not possible to determine if a bug or behavior
gets introduced at patch 2, 3 or 4, for example.
> + if (cipso_v4_validate(&optptr)) {
> + pp_ptr = optptr;
> + goto error;
> + }
> + break;
Same thing here, cipso_v4_validate() doesn't exist in the
tree at this point in the patch set, so the tree doesn't
build after applying this patch.
Please split up your submission properly.
I really can't sanely review the rest of this until you dice up your
changes properly.
next prev parent reply other threads:[~2006-06-22 9:07 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-21 19:42 [RFC 0/7] Updated NetLabel patch paul.moore
2006-06-21 19:42 ` [RFC 1/7] NetLabel: documentation paul.moore
2006-06-21 19:42 ` [RFC 2/7] NetLabel: core network changes paul.moore
2006-06-22 9:00 ` David Miller
2006-06-22 15:05 ` Steve Grubb
2006-06-22 18:58 ` James Morris
2006-06-22 21:32 ` David Miller
2006-06-22 9:07 ` David Miller [this message]
2006-06-22 13:20 ` Paul Moore
2006-06-21 19:42 ` [RFC 3/7] NetLabel: CIPSOv4 engine paul.moore
2006-06-22 9:12 ` David Miller
2006-06-22 13:43 ` Paul Moore
2006-06-22 15:57 ` Ryan Pratt
2006-06-23 18:48 ` Ted
2006-06-23 20:15 ` David Miller
2006-06-23 20:34 ` Ted
2006-06-23 23:24 ` James Morris
2006-06-23 23:45 ` Paul Moore
2006-06-26 15:32 ` James Morris
2006-06-26 23:14 ` [redhat-lspp] " Joe Nall
2006-06-27 0:33 ` James Morris
2006-06-27 2:45 ` Paul Moore
2006-06-27 19:41 ` Klaus Weidner
2006-06-21 19:42 ` [RFC 4/7] NetLabel: core NetLabel subsystem paul.moore
2006-06-21 19:42 ` [RFC 5/7] NetLabel: SELinux support paul.moore
2006-06-21 19:42 ` [RFC 6/7] NetLabel: CIPSOv4 integration paul.moore
2006-06-21 19:42 ` [RFC 7/7] NetLabel: unlabeled packet handling paul.moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060622.020748.85685000.davem@davemloft.net \
--to=davem@davemloft$(echo .)net \
--cc=jmorris@redhat$(echo .)com \
--cc=linux-security-module@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=paul.moore@hp$(echo .)com \
--cc=redhat-lspp@redhat$(echo .)com \
--cc=sds@epoch$(echo .)ncsc.mil \
--cc=selinux@tycho$(echo .)nsa.gov \
--cc=sgrubb@redhat$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox