From owner-freebsd-arch@FreeBSD.ORG Sun May 5 20:12:32 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9EDD0FC5 for ; Sun, 5 May 2013 20:12:32 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 6D35BC48 for ; Sun, 5 May 2013 20:12:31 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id AB9602FB for ; Sun, 5 May 2013 22:08:30 +0200 (CEST) Date: Sun, 5 May 2013 22:14:36 +0200 From: Pawel Jakub Dawidek To: freebsd-arch@FreeBSD.org Subject: Building library that depends on another library. Message-ID: <20130505201436.GJ1374@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6iqOn7HZPWKXx18" Content-Disposition: inline X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 20:12:32 -0000 --d6iqOn7HZPWKXx18 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I'm trying to connect two libraries to the build without hacks and it doesn't work... My two libraries are libcapsicum and libnv. libcapsicum depends on libnv. I want to specify this dependency explicitely in libcapsicum's Makefile: DPADD=3D ${LIBNV} LDADD=3D -lnv (LIBNV was added to bsd.libnames.mk, in case you wonder.) =46rom conversation with kan@ (Alexander Kabaev) declaring dependency directly in library's Makefile is required for symbol versioning to work. It just sounds right, too. If this is done, libcapsicum doesn't compile: =3D=3D=3D> lib/libcapsicum (all) cc [...] cc [...] building static capsicum library ranlib libcapsicum.a cc [...] cc [...] make: don't know how to make /usr/home/pjd/obj/usr/home/pjd/p4/capsicum/tmp/usr/lib/libnv.a. Stop *** [all] Error code 2 Stop in /usr/home/pjd/p4/capsicum/lib. *** [lib__L] Error code 1 Note that when build fails libnv.{a,so} exist in /lib/libnv/, but of course not in /tmp/usr/lib/. It looks like to make such dependency work one HAS TO add libnv to _prebuild_libs in src/Makefile.inc1, which seems wrong. Libraries specified there from my understanding are just used by build tools: LD_LIBRARY_PATH=3D${INSTALLTMP} # This is from src/Makefile.inc1. My understanding was that all I need to do is to add my two libraries in proper order to SUBDIR_ORDERED variable in src/lib/Makefile. This means that currently SUBDIR_ORDERED is totally useless. No matter how libraries are ordered there, to compile, they need libraries they depend on in Makefile.inc1's _prebuild_libs. I can of course just add libnv to _prebuild_libs and make it compile twice for no reason, but maybe there is a better way or maybe I'm just missing something? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --d6iqOn7HZPWKXx18 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlGGvawACgkQForvXbEpPzRsWgCg8nPMvZGjbs2JBIcTS9nq9WNH zAAAoIikolVH5v0UMCN5bwzG62GPyc+M =Z+C5 -----END PGP SIGNATURE----- --d6iqOn7HZPWKXx18-- From owner-freebsd-arch@FreeBSD.ORG Sun May 5 20:30:02 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B267A323 for ; Sun, 5 May 2013 20:30:02 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 7FED7D23 for ; Sun, 5 May 2013 20:30:01 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 6F659307 for ; Sun, 5 May 2013 22:26:06 +0200 (CEST) Date: Sun, 5 May 2013 22:32:13 +0200 From: Pawel Jakub Dawidek To: freebsd-arch@FreeBSD.org Subject: Re: Building library that depends on another library. Message-ID: <20130505203212.GK1374@garage.freebsd.pl> References: <20130505201436.GJ1374@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sU4rRG038CsJurvk" Content-Disposition: inline In-Reply-To: <20130505201436.GJ1374@garage.freebsd.pl> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 20:30:02 -0000 --sU4rRG038CsJurvk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 05, 2013 at 10:14:36PM +0200, Pawel Jakub Dawidek wrote: > It looks like to make such dependency work one HAS TO add libnv to > _prebuild_libs in src/Makefile.inc1, which seems wrong. Libraries > specified there from my understanding are just used by build tools: >=20 > LD_LIBRARY_PATH=3D${INSTALLTMP} # This is from src/Makefile.inc1. This is wrong. INSTALLTMP is not /tmp/usr/lib/. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --sU4rRG038CsJurvk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlGGwcwACgkQForvXbEpPzTyWACcC2H5Ths6Z+S9iMm8UgZIBsLw pa8AoNEK5pWPzByOLhkXG86Vmr/UIwMj =+FI9 -----END PGP SIGNATURE----- --sU4rRG038CsJurvk-- From owner-freebsd-arch@FreeBSD.ORG Sun May 5 21:58:42 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 757A4541; Sun, 5 May 2013 21:58:42 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 3579AEEC; Sun, 5 May 2013 21:58:42 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 3DB8C359306; Sun, 5 May 2013 23:58:40 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 228CF28493; Sun, 5 May 2013 23:58:40 +0200 (CEST) Date: Sun, 5 May 2013 23:58:40 +0200 From: Jilles Tjoelker To: Pawel Jakub Dawidek Subject: Re: Building library that depends on another library. Message-ID: <20130505215839.GA85274@stack.nl> References: <20130505201436.GJ1374@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130505201436.GJ1374@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 21:58:42 -0000 On Sun, May 05, 2013 at 10:14:36PM +0200, Pawel Jakub Dawidek wrote: > I'm trying to connect two libraries to the build without hacks and it > doesn't work... > My two libraries are libcapsicum and libnv. libcapsicum depends on libnv. > I want to specify this dependency explicitely in libcapsicum's Makefile: > DPADD= ${LIBNV} > LDADD= -lnv > (LIBNV was added to bsd.libnames.mk, in case you wonder.) > From conversation with kan@ (Alexander Kabaev) declaring dependency > directly in library's Makefile is required for symbol versioning to > work. It just sounds right, too. > If this is done, libcapsicum doesn't compile: > ===> lib/libcapsicum (all) > cc [...] > cc [...] > building static capsicum library > ranlib libcapsicum.a > cc [...] > cc [...] > make: don't know how to make > /usr/home/pjd/obj/usr/home/pjd/p4/capsicum/tmp/usr/lib/libnv.a. Stop > *** [all] Error code 2 > > Stop in /usr/home/pjd/p4/capsicum/lib. > *** [lib__L] Error code 1 > Note that when build fails libnv.{a,so} exist in /lib/libnv/, > but of course not in /tmp/usr/lib/. > It looks like to make such dependency work one HAS TO add libnv to > _prebuild_libs in src/Makefile.inc1, which seems wrong. [removing incorrect sentence about LD_LIBRARY_PATH here] > My understanding was that all I need to do is to add my two libraries in > proper order to SUBDIR_ORDERED variable in src/lib/Makefile. > This means that currently SUBDIR_ORDERED is totally useless. > No matter how libraries are ordered there, to compile, they need > libraries they depend on in Makefile.inc1's _prebuild_libs. This analysis seems correct. The order in SUBDIR_ORDERED in src/lib/Makefile is useless because it first makes obj in all directories, then depend, then all, then install; therefore, libraries are not installed to ${WORLDTMP}/usr/lib to be picked up in time by libraries depending on them. Instead, the directories in _prebuild_libs first get obj/depend/all/install for the first directory so that libraries are installed in time. As noted in the comment in src/Makefile.inc1, the script src/tools/make_libdeps.sh can be helpful in determining what to put in _prebuild_libs. > I can of course just add libnv to _prebuild_libs and make it compile > twice for no reason, but maybe there is a better way or maybe I'm just > missing something? It just runs make through it twice. The second time, it does not compile anything. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Mon May 6 18:49:15 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 58C4933E; Mon, 6 May 2013 18:49:15 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 209F7ACC; Mon, 6 May 2013 18:49:15 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 679FFDF01; Mon, 6 May 2013 18:49:14 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 2B05F35C4F; Mon, 6 May 2013 20:49:15 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Pawel Jakub Dawidek Subject: Re: Building library that depends on another library. References: <20130505201436.GJ1374@garage.freebsd.pl> Date: Mon, 06 May 2013 20:49:15 +0200 In-Reply-To: <20130505201436.GJ1374@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Sun, 5 May 2013 22:14:36 +0200") Message-ID: <86r4hkgd04.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 18:49:15 -0000 Pawel Jakub Dawidek writes: > It looks like to make such dependency work one HAS TO add libnv to > _prebuild_libs in src/Makefile.inc1, which seems wrong. It may seem wrong, but it is correct, cf the following comment in Makefile.inc1: # The list of libraries with dependents (${_prebuild_libs}) and their # interdependencies (__L) are built automatically by the # ${.CURDIR}/tools/make_libdeps.sh script. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue May 7 18:33:42 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C3C09C57 for ; Tue, 7 May 2013 18:33:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4EB9DA8D for ; Tue, 7 May 2013 18:33:42 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B3CE8B91E for ; Tue, 7 May 2013 14:33:40 -0400 (EDT) From: John Baldwin To: arch@freebsd.org Subject: Extending MADV_PROTECT Date: Tue, 7 May 2013 14:33:27 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201305071433.27993.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 07 May 2013 14:33:40 -0400 (EDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 18:33:42 -0000 One of the issues I have with our current MADV_PROTECT is that it isn't very administrative-friendly. That is, as a sysadmin I can't easily protect arbitrary processes from the OOM killer. Instead, the binary has to be changed to invoke madvise(). Furthermore, once the protection is granted it can't be revoked. Also, any binaries that want this have to be run as root. Instead, I would like to be able to both set and revoke this for existing processes and possibly even allow it to be inherited (so I can tag a top-level daemon that forks and have all its future children be protected for example). To that end I've whipped up a simple patch (against 8, but should port to HEAD easily if folks think it is a good idea) to add a new pprotect() system call and userland program (protect) that can be used similar to ktrace(1) either as a modifier when running a new program or as a tool for setting or clearing protection for existing processes. The inherit feature isn't implemented yet, but it should be simple to do. One would simply need a new flag that PPROT_INHERIT sets that is checked on fork and propagates P_PROTECTED if it is set. Also, one other thought I had is that at some point we might want to make P_PROTECTED more fine-grained, e.g. by allowing for OOM "priorities". To that end, it may make sense to add a new argument to protect, though you could also reserve part of the 'op' parameter to encode a priority. The manpage for the proposed protect command is below, then the source of the command, then the patch to add pprotect(): PROTECT(1) FreeBSD General Commands Manual PROTECT(1) NAME protect -- protect processes from being killed when swap space is exhausted SYNOPSIS protect [-i] command protect [-cdi] -g pgrp | -p pid DESCRIPTION The protect command is used to mark processes as protected. The kernel does not kill protected processes when swap space is exhausted. Note that this protected state is not inherited by child processes. The options are: -c Remove protection from the specified processes. -d Apply the operation to all current children of the specified pro- cesses. -i Apply the operation to all future children of the specified pro- cesses. -g pgrp Apply the operation to all processes in the specified process group. -p pid Apply the operation to the specified process. command Execute command as a protected process. Note that only one of the -p or -g flags may be specified when adjusting the state of existing processes. EXIT STATUS The protect utility exits 0 on success, and >0 if an error occurs. EXAMPLES Mark the Xorg server as protected: pgrep Xorg | xargs protect -p Protect all ssh sessions and their child processes: pgrep sshd | xargs protect -dip Remove protection from all current and future processes: protect -cdi -p 1 SEE ALSO pprotect(2) BUGS If you protect a runaway process that allocates all memory the system will deadlock. Inheritance of the protected state is not yet implemented. FreeBSD 8.2 May 7, 2013 FreeBSD 8.2 #include __FBSDID("$FreeBSD"); #include #include #include #include #include #include #include #include static void usage(void) { fprintf(stderr, "usage: protect [-i] command\n"); fprintf(stderr, " protect [-cdi] -g pgrp | -p pid\n"); exit(1); } static pid_t parse_pid(char *id) { static bool first = true; long value; char *ch; if (!first) { warnx("only one -g or -p flag is permitted"); usage(); } value = strtol(id, &ch, 0); if (*ch != '\0') { warnx("invalid process id"); usage(); } return (value); } int main(int argc, char *argv[]) { pid_t pid; int ch, op; bool descend, inherit, pidset; pid = getpid(); op = PPROT_SET; descend = inherit = pidset = false; while ((ch = getopt(argc, argv, "cdig:p:")) != -1) switch (ch) { case 'c': op = PPROT_CLEAR; break; case 'd': descend = true; break; case 'i': inherit = true; break; case 'g': pid = -parse_pid(optarg); pidset = true; break; case 'p': pid = parse_pid(optarg); pidset = true; break; } argc -= optind; argv += optind; if ((pidset && argc != 0) || (!pidset && (argc == 0 || descend))) usage(); if (descend) op |= PPROT_DESCEND; if (inherit) op |= PPROT_INHERIT; if (pprotect(op, pid) == -1) err(1, "request failed"); if (argc != 0) { errno = 0; execvp(*argv, argv); err(errno == ENOENT ? 127 : 126, "%s", *argv); } return (0); } Index: sys/compat/freebsd32/syscalls.master =================================================================== --- sys/compat/freebsd32/syscalls.master (revision 251038) +++ sys/compat/freebsd32/syscalls.master (working copy) @@ -977,3 +977,15 @@ uint32_t offset1, uint32_t offset2,\ uint32_t len1, uint32_t len2, \ int advice); } +532 AUE_NULL UNIMPL wait6 +533 AUE_NULL UNIMPL cap_rights_limit +534 AUE_NULL UNIMPL cap_ioctls_limit +535 AUE_NULL UNIMPL cap_ioctls_get +536 AUE_NULL UNIMPL cap_fcntls_limit +537 AUE_NULL UNIMPL cap_fcntls_get +538 AUE_NULL UNIMPL bindat +539 AUE_NULL UNIMPL connectat +540 AUE_NULL UNIMPL chflagsat +541 AUE_NULL UNIMPL accept4 +542 AUE_NULL UNIMPL pipe2 +543 AUE_NULL NOPROTO { int pprotect(int op, pid_t pid); } Index: sys/kern/syscalls.master =================================================================== --- sys/kern/syscalls.master (revision 251038) +++ sys/kern/syscalls.master (working copy) @@ -938,5 +938,17 @@ off_t offset, off_t len); } 531 AUE_NULL STD { int posix_fadvise(int fd, off_t offset, \ off_t len, int advice); } +532 AUE_NULL UNIMPL wait6 +533 AUE_NULL UNIMPL cap_rights_limit +534 AUE_NULL UNIMPL cap_ioctls_limit +535 AUE_NULL UNIMPL cap_ioctls_get +536 AUE_NULL UNIMPL cap_fcntls_limit +537 AUE_NULL UNIMPL cap_fcntls_get +538 AUE_NULL UNIMPL bindat +539 AUE_NULL UNIMPL connectat +540 AUE_NULL UNIMPL chflagsat +541 AUE_NULL UNIMPL accept4 +542 AUE_NULL UNIMPL pipe2 +543 AUE_NULL STD { int pprotect(int op, pid_t pid); } ; Please copy any additions and changes to the following compatability tables: ; sys/compat/freebsd32/syscalls.master Index: sys/sys/mman.h =================================================================== --- sys/sys/mman.h (revision 251038) +++ sys/sys/mman.h (working copy) @@ -143,6 +143,22 @@ #define MINCORE_SUPER 0x20 /* Page is a "super" page */ /* + * Operations for pprotect(). + */ +#define PPROT_OP_MASK (0xf) +#define PPROT_SET 0 +#define PPROT_CLEAR 1 +#define PPROT_OP(x) ((x) & PPROT_OP_MASK) /* Base operation. */ + +/* + * Flags for pprotect (ORed in with operation). + */ +#define PPROT_FLAG_MASK (~PPROT_OP_MASK) +#define PPROT_DESCEND 0x10 +#define PPROT_INHERIT 0x20 +#define PPROT_FLAGS(x) ((x) & PPROT_FLAG_MASK) + +/* * Anonymous object constant for shm_open(). */ #define SHM_ANON ((char *)1) @@ -222,6 +238,7 @@ int madvise(void *, size_t, int); int mincore(const void *, size_t, char *); int minherit(void *, size_t, int); +int pprotect(int, pid_t); #endif int mlock(const void *, size_t); #ifndef _MMAP_DECLARED Index: sys/sys/syscallsubr.h =================================================================== --- sys/sys/syscallsubr.h (revision 251038) +++ sys/sys/syscallsubr.h (working copy) @@ -154,6 +154,7 @@ int advice); int kern_posix_fallocate(struct thread *td, int fd, off_t offset, off_t len); +int kern_pprotect(struct thread *td, int op, pid_t pid); int kern_preadv(struct thread *td, int fd, struct uio *auio, off_t offset); int kern_pselect(struct thread *td, int nd, fd_set *in, fd_set *ou, fd_set *ex, struct timeval *tvp, sigset_t *uset, int abi_nfdbits); Index: sys/vm/vm_mmap.c =================================================================== --- sys/vm/vm_mmap.c (revision 251038) +++ sys/vm/vm_mmap.c (working copy) @@ -63,6 +63,7 @@ #include #include #include +#include #include #include @@ -668,23 +669,13 @@ { vm_offset_t start, end; vm_map_t map; - struct proc *p; - int error; /* * Check for our special case, advising the swap pager we are * "immortal." */ - if (uap->behav == MADV_PROTECT) { - error = priv_check(td, PRIV_VM_MADV_PROTECT); - if (error == 0) { - p = td->td_proc; - PROC_LOCK(p); - p->p_flag |= P_PROTECTED; - PROC_UNLOCK(p); - } - return (error); - } + if (uap->behav == MADV_PROTECT) + return (kern_pprotect(td, PPROT_SET, td->td_proc->p_pid)); /* * Check for illegal behavior */ @@ -1102,6 +1093,154 @@ return (error == KERN_SUCCESS ? 0 : ENOMEM); } +#ifndef _SYS_SYSPROTO_H_ +struct pprotect_args { + int op; + pid_t pid; +}; +#endif +int +pprotect(td, uap) + struct thread *td; + struct pprotect_args *uap; +{ + + return (kern_pprotect(td, uap->op, uap->pid)); +} + +static int +pprot_setchild(struct thread *td, struct proc *p, int op) +{ + PROC_LOCK(p); + if (p->p_flag & P_SYSTEM || p_cansee(td, p) != 0) { + PROC_UNLOCK(p); + return (0); + } + + switch (PPROT_OP(op)) { + case PPROT_SET: + p->p_flag |= P_PROTECTED; + break; + case PPROT_CLEAR: + p->p_flag &= ~P_PROTECTED; + break; + default: + PROC_UNLOCK(p); + return (0); + } + PROC_UNLOCK(p); + return (1); +} + +static int +pprot_setchildren(struct thread *td, struct proc *top, int op) +{ + struct proc *p; + int ret; + + p = top; + ret = 0; + sx_assert(&proctree_lock, SX_LOCKED); + for (;;) { + ret |= pprot_setchild(td, p, op); + /* + * If this process has children, descend to them next, + * otherwise do any siblings, and if done with this level, + * follow back up the tree (but not past top). + */ + if (!LIST_EMPTY(&p->p_children)) + p = LIST_FIRST(&p->p_children); + else for (;;) { + if (p == top) + return (ret); + if (LIST_NEXT(p, p_sibling)) { + p = LIST_NEXT(p, p_sibling); + break; + } + p = p->p_pptr; + } + } +} + +int +kern_pprotect(struct thread *td, int op, pid_t pid) +{ + struct pgrp *pg; + struct proc *p; + int error, nfound, ret; + + switch (PPROT_OP(op)) { + case PPROT_SET: + case PPROT_CLEAR: + break; + default: + return (EINVAL); + } + if ((PPROT_FLAGS(op) & ~(PPROT_DESCEND | PPROT_INHERIT)) != 0) + return (EINVAL); + if (op & PPROT_INHERIT) + return (EOPNOTSUPP); + + error = priv_check(td, PRIV_VM_MADV_PROTECT); + if (error) + return (error); + + ret = 0; + sx_slock(&proctree_lock); + if (pid < 0) { + /* By process group. */ + pg = pgfind(-pid); + if (pg == NULL) { + sx_sunlock(&proctree_lock); + return (ESRCH); + } + PGRP_UNLOCK(pg); + nfound = 0; + LIST_FOREACH(p, &pg->pg_members, p_pglist) { + PROC_LOCK(p); + if (p->p_state == PRS_NEW || + p_cansee(td, p) != 0) { + PROC_UNLOCK(p); + continue; + } + PROC_UNLOCK(p); + nfound++; + if (op & PPROT_DESCEND) + ret |= pprot_setchildren(td, p, op); + else + ret |= pprot_setchild(td, p, op); + } + if (nfound == 0) { + sx_sunlock(&proctree_lock); + return (ESRCH); + } + } else { + /* By pid. */ + p = pfind(pid); + if (p == NULL) { + sx_sunlock(&proctree_lock); + return (ESRCH); + } + if (p->p_state == PRS_NEW) + error = ESRCH; + else + error = p_cansee(td, p); + PROC_UNLOCK(p); + if (error) { + sx_sunlock(&proctree_lock); + return (error); + } + if (op & PPROT_DESCEND) + ret |= pprot_setchildren(td, p, op); + else + ret |= pprot_setchild(td, p, op); + } + sx_sunlock(&proctree_lock); + if (ret == 0) + error = EPERM; + return (error); +} + /* * vm_mmap_vnode() * Index: lib/libc/sys/Symbol.map =================================================================== --- lib/libc/sys/Symbol.map (revision 251033) +++ lib/libc/sys/Symbol.map (working copy) @@ -366,6 +366,7 @@ FBSD_1.3 { posix_fadvise; + pprotect; }; FBSDprivate_1.0 { -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue May 7 18:39:30 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A203ED73; Tue, 7 May 2013 18:39:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 6069BAC1; Tue, 7 May 2013 18:39:30 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r47IdSwE053387 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 7 May 2013 11:39:29 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51894A5B.7060101@freebsd.org> Date: Tue, 07 May 2013 11:39:23 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: John Baldwin Subject: Re: Extending MADV_PROTECT References: <201305071433.27993.jhb@freebsd.org> In-Reply-To: <201305071433.27993.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 18:39:30 -0000 On 5/7/13 11:33 AM, John Baldwin wrote: > One of the issues I have with our current MADV_PROTECT is that it isn't very > administrative-friendly. That is, as a sysadmin I can't easily protect > arbitrary processes from the OOM killer. Instead, the binary has to be > changed to invoke madvise(). Furthermore, once the protection is granted it > can't be revoked. Also, any binaries that want this have to be run as root. > Instead, I would like to be able to both set and revoke this for existing > processes and possibly even allow it to be inherited (so I can tag a top-level > daemon that forks and have all its future children be protected for example). > To that end I've whipped up a simple patch (against 8, but should port to HEAD > easily if folks think it is a good idea) to add a new pprotect() system call > and userland program (protect) that can be used similar to ktrace(1) either as > a modifier when running a new program or as a tool for setting or clearing > protection for existing processes. > > The inherit feature isn't implemented yet, but it should be simple to do. One > would simply need a new flag that PPROT_INHERIT sets that is checked on fork > and propagates P_PROTECTED if it is set. Also, one other thought I had is > that at some point we might want to make P_PROTECTED more fine-grained, e.g. > by allowing for OOM "priorities". To that end, it may make sense to add a new > argument to protect, though you could also reserve part of the 'op' parameter > to encode a priority. > > The manpage for the proposed protect command is below, then the source of the > command, then the patch to add pprotect(): > > PROTECT(1) FreeBSD General Commands Manual PROTECT(1) > > NAME > protect -- protect processes from being killed when swap space is > exhausted > > SYNOPSIS > protect [-i] command > protect [-cdi] -g pgrp | -p pid > > I like it but it does make it very easy to abuse.. (try protect everything) what kinds of limits can there be? From owner-freebsd-arch@FreeBSD.ORG Tue May 7 18:47:37 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7450318F for ; Tue, 7 May 2013 18:47:37 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 1B394B11 for ; Tue, 7 May 2013 18:47:36 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 9C81F95C; Tue, 7 May 2013 20:43:39 +0200 (CEST) Date: Tue, 7 May 2013 20:50:05 +0200 From: Pawel Jakub Dawidek To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Subject: Re: Building library that depends on another library. Message-ID: <20130507185005.GB1888@garage.freebsd.pl> References: <20130505201436.GJ1374@garage.freebsd.pl> <86r4hkgd04.fsf@nine.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rS8CxjVDS/+yyDmU" Content-Disposition: inline In-Reply-To: <86r4hkgd04.fsf@nine.des.no> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 18:47:37 -0000 --rS8CxjVDS/+yyDmU Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 06, 2013 at 08:49:15PM +0200, Dag-Erling Sm=F8rgrav wrote: > Pawel Jakub Dawidek writes: > > It looks like to make such dependency work one HAS TO add libnv to > > _prebuild_libs in src/Makefile.inc1, which seems wrong. >=20 > It may seem wrong, but it is correct, cf the following comment in > Makefile.inc1: >=20 > # The list of libraries with dependents (${_prebuild_libs}) and their > # interdependencies (__L) are built automatically by the > # ${.CURDIR}/tools/make_libdeps.sh script. Yes, this also means SUBDIR_ORDERED in lib/Makefile doesn't make sense. All in all I really don't like to add libraries to Makefile.inc1, it doesn't sound right. I'd like this to be self-contained. For bsd.prog.mk it is enough to specify DPADD/LDADD in program's Makefile instead of hacking some central Makefile. I came up with something like the following. Instead of: DPADD=3D ${LIBNV} LDADD=3D -lnv (plus modifying src/Makefile.inc1) I only add: LDADD=3D -L${.OBJDIR}/../libnv -lnv What do people think? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --rS8CxjVDS/+yyDmU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlGJTN0ACgkQForvXbEpPzQynACdG9bsv2qpBsUu+9fEk1IzDc6T CJYAoNVWNy5l+DKFJVIaHC8m2gHQM80p =IZ85 -----END PGP SIGNATURE----- --rS8CxjVDS/+yyDmU-- From owner-freebsd-arch@FreeBSD.ORG Tue May 7 19:21:03 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 15B91B37; Tue, 7 May 2013 19:21:03 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by mx1.freebsd.org (Postfix) with ESMTP id BE4ACD65; Tue, 7 May 2013 19:21:02 +0000 (UTC) Received: by mail-qe0-f45.google.com with SMTP id a11so561100qen.4 for ; Tue, 07 May 2013 12:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=o5rSyfeyvMAYBtBwOmVj4yhYrDW8m479QM2MLMQRxi8=; b=RmVHVrMAhvQCRw2aeW89TISz9sPdUqA1TORMh1VMxCGNoFhWSR5j2nolZbyDrSTERA QUdbfyx22l6UBR8/3uYsIP3q2tz0ahP1gfAsHiI+WQCV+77M4Y67x2pOZ0iICLx1sd2w uJYP/K5/SrGq8x7gHjSi8OkesDaU+45h51LKpAs2bR9nLLdL7VJ2G7Q2+nSbsqADQrbY 0s/wEVhHd0Pm9m1ZH1P+UPmRpz7W7mrfdCKahBqEykNJtsdt8EJdO/xp7Pe8X2t+rISV kTVfYiSWzBHACkBmcUgGhskaj47IkGvB3cY/qYXkaEpR4+X5cNIUGwEVgWclop+UKzCU vwhg== MIME-Version: 1.0 X-Received: by 10.229.141.129 with SMTP id m1mr1028190qcu.29.1367954456153; Tue, 07 May 2013 12:20:56 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.229.127.152 with HTTP; Tue, 7 May 2013 12:20:56 -0700 (PDT) In-Reply-To: <20130507185005.GB1888@garage.freebsd.pl> References: <20130505201436.GJ1374@garage.freebsd.pl> <86r4hkgd04.fsf@nine.des.no> <20130507185005.GB1888@garage.freebsd.pl> Date: Tue, 7 May 2013 12:20:56 -0700 X-Google-Sender-Auth: M9CAud1o1heyAtUJCfJRFKGDEHQ Message-ID: Subject: Re: Building library that depends on another library. From: mdf@FreeBSD.org To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= , FreeBSD Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 19:21:03 -0000 On Tue, May 7, 2013 at 11:50 AM, Pawel Jakub Dawidek wrote= : > On Mon, May 06, 2013 at 08:49:15PM +0200, Dag-Erling Sm=F8rgrav wrote: > > Pawel Jakub Dawidek writes: > > > It looks like to make such dependency work one HAS TO add libnv to > > > _prebuild_libs in src/Makefile.inc1, which seems wrong. > > > > It may seem wrong, but it is correct, cf the following comment in > > Makefile.inc1: > > > > # The list of libraries with dependents (${_prebuild_libs}) and their > > # interdependencies (__L) are built automatically by the > > # ${.CURDIR}/tools/make_libdeps.sh script. > > Yes, this also means SUBDIR_ORDERED in lib/Makefile doesn't make sense. > > All in all I really don't like to add libraries to Makefile.inc1, it > doesn't sound right. I'd like this to be self-contained. For bsd.prog.mk > it is enough to specify DPADD/LDADD in program's Makefile instead of > hacking some central Makefile. > > I came up with something like the following. Instead of: > > DPADD=3D ${LIBNV} > LDADD=3D -lnv > (plus modifying src/Makefile.inc1) > > I only add: > > LDADD=3D -L${.OBJDIR}/../libnv -lnv > > What do people think? > I won't claim any knowledge of various Makefile variables, but at work we use this. (I think gcooper is changing this to have the -L in LDFLAGS so the LDADD stays pure; I suppose it is better but it's even more verbose). We also use rcorder on our makefiles so they're built in the right order, which AFAICT serves the same purpose as DPADD but perhaps less annoyingly (no need to define LIBNV somewhere). However, it still requires over-specification (and a mis-spelling will break it). So for our libraries, each Makefile should have a # PROIVIDE: line as well as potentially some # REQUIRE: lines. Using rcorder has the advantage that it will detect circular dependencies. It would be nice if the existence of an LDADD in the Makefile would automatically also mean the ordering of build was determined; DPADD/LDADD should be in parallel already. And for our use of rcorder, it's redundant to have both a REQUIRE line and an LDADD line. But I think quickly we're getting past what make(1) can do and into the realms of "build systems are hard". Cheers, matthew From owner-freebsd-arch@FreeBSD.ORG Tue May 7 19:27:39 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A1304E87 for ; Tue, 7 May 2013 19:27:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by mx1.freebsd.org (Postfix) with ESMTP id 62882DB9 for ; Tue, 7 May 2013 19:27:39 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id ib11so903314vcb.21 for ; Tue, 07 May 2013 12:27:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=hi0/SiDKekiiOXDNZVcVec0DXgRHqrLp414lpZ+vb2o=; b=pfs7I0Ptd3TvV88Cfn/PfDWJyAZedHp4aH1Q4WZMV7sXub9EuM5l/qkW+mbJubcTFO 5jmeV0yfMa/1GlAKJZLMUU+r4VZiY9r1qeGKJZBGYRHvczdvQcjWYP1QcNi9TUhg9RoQ i48vwTwb02B/89827Jq2AgUhUPgC/A55+DteZCE2GH075F4CuOTfzoJGKiLn5pl7xwof VG3p7UdcAziTrS6ZlTORYkPEJcyUFNUaihkRNvijqSkCBX/s3HSNkIOXjkgj+6k8pIHB ih+O5ffcHbfoNKJu1Bb1ESuswx2/lMHPoT8wY2tI4VJMjQFWwgHAWKkIlTIouWo+XPiC PzwQ== X-Received: by 10.52.93.179 with SMTP id cv19mr1970005vdb.20.1367954858659; Tue, 07 May 2013 12:27:38 -0700 (PDT) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id s14sm7411198vdg.6.2013.05.07.12.27.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 12:27:38 -0700 (PDT) Sender: Warner Losh Subject: Re: Building library that depends on another library. Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Warner Losh In-Reply-To: <20130507185005.GB1888@garage.freebsd.pl> Date: Tue, 7 May 2013 13:27:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130505201436.GJ1374@garage.freebsd.pl> <86r4hkgd04.fsf@nine.des.no> <20130507185005.GB1888@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmYLm/5ceAMXy+VXCVN349+p28dX6PAwDs72d2pvrTjbwllUUN424+U/VpdeEcm5qlxitYI Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 19:27:39 -0000 On May 7, 2013, at 12:50 PM, Pawel Jakub Dawidek wrote: > On Mon, May 06, 2013 at 08:49:15PM +0200, Dag-Erling Sm=F8rgrav wrote: >> Pawel Jakub Dawidek writes: >>> It looks like to make such dependency work one HAS TO add libnv to >>> _prebuild_libs in src/Makefile.inc1, which seems wrong. >>=20 >> It may seem wrong, but it is correct, cf the following comment in >> Makefile.inc1: >>=20 >> # The list of libraries with dependents (${_prebuild_libs}) and their >> # interdependencies (__L) are built automatically by the >> # ${.CURDIR}/tools/make_libdeps.sh script. >=20 > Yes, this also means SUBDIR_ORDERED in lib/Makefile doesn't make = sense. >=20 > All in all I really don't like to add libraries to Makefile.inc1, it > doesn't sound right. I'd like this to be self-contained. For = bsd.prog.mk > it is enough to specify DPADD/LDADD in program's Makefile instead of > hacking some central Makefile. >=20 > I came up with something like the following. Instead of: >=20 > DPADD=3D ${LIBNV} > LDADD=3D -lnv > (plus modifying src/Makefile.inc1) >=20 > I only add: >=20 > LDADD=3D -L${.OBJDIR}/../libnv -lnv >=20 > What do people think? Still won't work. It won't ensure that libnv is built, leading to = cross-threading on upgrade issues. Better would be a 'plus modifying src/Makefile.inc1' would instead be = 'have Makefile.inc1 figure it out fast.' We have to get the order right, = there's no way around that. Warner= From owner-freebsd-arch@FreeBSD.ORG Tue May 7 19:29:24 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5981CF3D for ; Tue, 7 May 2013 19:29:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id 19B72DC8 for ; Tue, 7 May 2013 19:29:24 +0000 (UTC) Received: by mail-ve0-f178.google.com with SMTP id jy13so992038veb.9 for ; Tue, 07 May 2013 12:29:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=d8g0uPZKT2TZq5XkBG81CdruQ+YgkSemwjWjB9CqSe8=; b=O3AdIkSui83mKk1bMZvLtFxIbJqYbBQiUY/dnfVqcJOHFKQYwYAKxpzUUzpI+9b2SZ H1U1cV3FOOW4wblVldaIpaZX4z3/CukCbty3aqgaLoYdXhcRcsY1X3xBuj7c8QAVyN2I sNYZrR5ZR4Kh0Y6CINMQV9teF+i66fLGHOpllxdvQjLecpKdgMwTKQjDFzVhF3jkL2mq OcylvQD6VSWlr9lsJcQe05tvd3SJGhLDHOxy+SLmttZ4RJx1Q64+gmVQ9Zix4Y6XRzEv Lvd7MNsCxgI+qMAlZIcnC5+Smwvq303rGxxhPosPACi9dTscZbDBnxpz36nn2h80RTra /lAg== X-Received: by 10.52.98.161 with SMTP id ej1mr1973124vdb.72.1367954963522; Tue, 07 May 2013 12:29:23 -0700 (PDT) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id b7sm23606346veq.7.2013.05.07.12.29.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 12:29:22 -0700 (PDT) Sender: Warner Losh Subject: Re: Building library that depends on another library. Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Warner Losh In-Reply-To: Date: Tue, 7 May 2013 13:29:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130505201436.GJ1374@garage.freebsd.pl> <86r4hkgd04.fsf@nine.des.no> <20130507185005.GB1888@garage.freebsd.pl> To: mdf@FreeBSD.org X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmXm7YptY5HD7C47HDPodHIOE9I5JzW6kQzQN15icVy9l+hp5vtfaS8PVvGmrZXz/yRIZeA Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , FreeBSD Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 19:29:24 -0000 On May 7, 2013, at 1:20 PM, mdf@FreeBSD.org wrote: > On Tue, May 7, 2013 at 11:50 AM, Pawel Jakub Dawidek = wrote: >=20 >> On Mon, May 06, 2013 at 08:49:15PM +0200, Dag-Erling Sm=F8rgrav = wrote: >>> Pawel Jakub Dawidek writes: >>>> It looks like to make such dependency work one HAS TO add libnv to >>>> _prebuild_libs in src/Makefile.inc1, which seems wrong. >>>=20 >>> It may seem wrong, but it is correct, cf the following comment in >>> Makefile.inc1: >>>=20 >>> # The list of libraries with dependents (${_prebuild_libs}) and = their >>> # interdependencies (__L) are built automatically by the >>> # ${.CURDIR}/tools/make_libdeps.sh script. >>=20 >> Yes, this also means SUBDIR_ORDERED in lib/Makefile doesn't make = sense. >>=20 >> All in all I really don't like to add libraries to Makefile.inc1, it >> doesn't sound right. I'd like this to be self-contained. For = bsd.prog.mk >> it is enough to specify DPADD/LDADD in program's Makefile instead of >> hacking some central Makefile. >>=20 >> I came up with something like the following. Instead of: >>=20 >> DPADD=3D ${LIBNV} >> LDADD=3D -lnv >> (plus modifying src/Makefile.inc1) >>=20 >> I only add: >>=20 >> LDADD=3D -L${.OBJDIR}/../libnv -lnv >>=20 >> What do people think? >>=20 >=20 > I won't claim any knowledge of various Makefile variables, but at work = we > use this. (I think gcooper is changing this to have the -L in LDFLAGS = so > the LDADD stays pure; I suppose it is better but it's even more = verbose). >=20 > We also use rcorder on our makefiles so they're built in the right = order, > which AFAICT serves the same purpose as DPADD but perhaps less = annoyingly > (no need to define LIBNV somewhere). However, it still requires > over-specification (and a mis-spelling will break it). So for our > libraries, each Makefile should have a # PROIVIDE: line as well as > potentially some # REQUIRE: lines. Using rcorder has the advantage = that it > will detect circular dependencies. >=20 > It would be nice if the existence of an LDADD in the Makefile would > automatically also mean the ordering of build was determined; = DPADD/LDADD > should be in parallel already. And for our use of rcorder, it's = redundant > to have both a REQUIRE line and an LDADD line. But I think quickly = we're > getting past what make(1) can do and into the realms of "build systems = are > hard". DPADD should be sufficient to get the ordering right. Warner= From owner-freebsd-arch@FreeBSD.ORG Tue May 7 19:37:12 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 36F914CF for ; Tue, 7 May 2013 19:37:12 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 01C36E38 for ; Tue, 7 May 2013 19:37:11 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id D7A7F988; Tue, 7 May 2013 21:33:14 +0200 (CEST) Date: Tue, 7 May 2013 21:39:40 +0200 From: Pawel Jakub Dawidek To: Warner Losh Subject: Re: Building library that depends on another library. Message-ID: <20130507193940.GC1888@garage.freebsd.pl> References: <20130505201436.GJ1374@garage.freebsd.pl> <86r4hkgd04.fsf@nine.des.no> <20130507185005.GB1888@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DSayHWYpDlRfCAAQ" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 19:37:12 -0000 --DSayHWYpDlRfCAAQ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 07, 2013 at 01:27:34PM -0600, Warner Losh wrote: >=20 > On May 7, 2013, at 12:50 PM, Pawel Jakub Dawidek wrote: >=20 > > On Mon, May 06, 2013 at 08:49:15PM +0200, Dag-Erling Sm=F8rgrav wrote: > >> Pawel Jakub Dawidek writes: > >>> It looks like to make such dependency work one HAS TO add libnv to > >>> _prebuild_libs in src/Makefile.inc1, which seems wrong. > >>=20 > >> It may seem wrong, but it is correct, cf the following comment in > >> Makefile.inc1: > >>=20 > >> # The list of libraries with dependents (${_prebuild_libs}) and their > >> # interdependencies (__L) are built automatically by the > >> # ${.CURDIR}/tools/make_libdeps.sh script. > >=20 > > Yes, this also means SUBDIR_ORDERED in lib/Makefile doesn't make sense. > >=20 > > All in all I really don't like to add libraries to Makefile.inc1, it > > doesn't sound right. I'd like this to be self-contained. For bsd.prog.mk > > it is enough to specify DPADD/LDADD in program's Makefile instead of > > hacking some central Makefile. > >=20 > > I came up with something like the following. Instead of: > >=20 > > DPADD=3D ${LIBNV} > > LDADD=3D -lnv > > (plus modifying src/Makefile.inc1) > >=20 > > I only add: > >=20 > > LDADD=3D -L${.OBJDIR}/../libnv -lnv > >=20 > > What do people think? >=20 > Still won't work. It won't ensure that libnv is built, leading to cross-t= hreading on upgrade issues. >=20 > Better would be a 'plus modifying src/Makefile.inc1' would instead be 'ha= ve Makefile.inc1 figure it out fast.' We have to get the order right, there= 's no way around that. I forgot to mention. The way I'm proposing makes SUBDIR_ORDERED relevant again. So we should either remove SUBDIR_ORDERED fro lib/Makefile and keep adding to _prebuild_libs or adopt what I'm proposing. One argument against my method was that my library without DPADD won't be relinked after libnv change, which may affect symbol versioning. My libraries don't use symbol versioning yet, but I'm after general solution here. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --DSayHWYpDlRfCAAQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlGJWHwACgkQForvXbEpPzTp0wCgqgK9lNTPOxzvPlExqSAW3Zfh 19IAoMl/ibO1jY+71/ip6+9h+bFn7MKO =P/nh -----END PGP SIGNATURE----- --DSayHWYpDlRfCAAQ-- From owner-freebsd-arch@FreeBSD.ORG Tue May 7 19:39:46 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3B6FD58C; Tue, 7 May 2013 19:39:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 19461E4B; Tue, 7 May 2013 19:39:46 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 64899B94A; Tue, 7 May 2013 15:39:45 -0400 (EDT) From: John Baldwin To: Julian Elischer Subject: Re: Extending MADV_PROTECT Date: Tue, 7 May 2013 15:39:24 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201305071433.27993.jhb@freebsd.org> <51894A5B.7060101@freebsd.org> In-Reply-To: <51894A5B.7060101@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201305071539.24900.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 07 May 2013 15:39:45 -0400 (EDT) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 19:39:46 -0000 On Tuesday, May 07, 2013 2:39:23 pm Julian Elischer wrote: > On 5/7/13 11:33 AM, John Baldwin wrote: > > One of the issues I have with our current MADV_PROTECT is that it isn't very > > administrative-friendly. That is, as a sysadmin I can't easily protect > > arbitrary processes from the OOM killer. Instead, the binary has to be > > changed to invoke madvise(). Furthermore, once the protection is granted it > > can't be revoked. Also, any binaries that want this have to be run as root. > > Instead, I would like to be able to both set and revoke this for existing > > processes and possibly even allow it to be inherited (so I can tag a top-level > > daemon that forks and have all its future children be protected for example). > > To that end I've whipped up a simple patch (against 8, but should port to HEAD > > easily if folks think it is a good idea) to add a new pprotect() system call > > and userland program (protect) that can be used similar to ktrace(1) either as > > a modifier when running a new program or as a tool for setting or clearing > > protection for existing processes. > > > > The inherit feature isn't implemented yet, but it should be simple to do. One > > would simply need a new flag that PPROT_INHERIT sets that is checked on fork > > and propagates P_PROTECTED if it is set. Also, one other thought I had is > > that at some point we might want to make P_PROTECTED more fine-grained, e.g. > > by allowing for OOM "priorities". To that end, it may make sense to add a new > > argument to protect, though you could also reserve part of the 'op' parameter > > to encode a priority. > > > > The manpage for the proposed protect command is below, then the source of the > > command, then the patch to add pprotect(): > > > > PROTECT(1) FreeBSD General Commands Manual PROTECT(1) > > > > NAME > > protect -- protect processes from being killed when swap space is > > exhausted > > > > SYNOPSIS > > protect [-i] command > > protect [-cdi] -g pgrp | -p pid > > > > > > I like it but it does make it very easy to abuse.. (try protect > everything) > what kinds of limits can there be? Well, only root can do it. Even now MADV_PROTECT is a similar foot shooting device (though not quite as easy to do). You can also get yourself into a heap of trouble with other things like rtprio, etc., so I sort of think that is up to the user/administrator to manage. I do think that the more fine-grained priority approach may be a good way to mitigate that if it really becomes an issue at some point. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue May 7 20:05:09 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 81992D9D; Tue, 7 May 2013 20:05:09 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by mx1.freebsd.org (Postfix) with ESMTP id E4316F1B; Tue, 7 May 2013 20:05:08 +0000 (UTC) Received: by mail-bk0-f44.google.com with SMTP id jk13so506121bkc.17 for ; Tue, 07 May 2013 13:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=QBGzN5fFjOOX55XtoubzVGxSa13CrKBuemTbsXRlK8s=; b=BRD5Gk84VRFJJQOt2b2kw52FJrzK3ZCBagMJKccxfpszihITTsLUiDX02Ho4cjMNhP dqNPFP97/kIdNXcbGVR6tZTjfojHZ2G4g3e56R4UVKffsZ4nSgrr4qw2CPW4SpJ+7+cm DVIVSb4/mMtKeiDFtjUjpwTDPnNnaBL9RWJvIskCw2bkXjdluwUCcIkjaYdzDAovLWko DJMBLCbX9N+znCUNRH5AnOy6Q604PaR2RT7MJWjxlcWp1swMCLT1EhjOLU1cZp1aYHlO mTIQHKvXhP+ZKnLr0M+FAztqFikzzfdzy22gcaGEs+EZZ1Eu9XwHCufOlyGA5Cb0tsOH Fuhg== MIME-Version: 1.0 X-Received: by 10.205.36.138 with SMTP id ta10mr1022195bkb.4.1367957108077; Tue, 07 May 2013 13:05:08 -0700 (PDT) Received: by 10.204.225.206 with HTTP; Tue, 7 May 2013 13:05:07 -0700 (PDT) Date: Tue, 7 May 2013 13:05:07 -0700 Message-ID: Subject: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree From: Garrett Cooper To: freebsd-toolchain@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Simon J. Gerraty" , "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 20:05:09 -0000 Hi, A common pattern that I've seen at Isilon and something else that I've wanted to have for a while is the ability to designate where the top of a source tree was. This is important and helpful when dealing with source files that build upon each other or depend on sources located in other sections of the tree; contrib stuff needs to set .PATH appropriately to point to sources at the top of the tree, sys stuff is riddled with S= in order to point to where /sys, etc lives, we build upon FreeBSD within an expected directory structure as well. I haven't come up with a name, but was wondering if this was a good idea, and if so does anyone have any outstanding patches for this that can be pushed into FreeBSD? Thanks! -Garrett From owner-freebsd-arch@FreeBSD.ORG Tue May 7 20:12:21 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6B494F9F; Tue, 7 May 2013 20:12:21 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 500D9F78; Tue, 7 May 2013 20:12:21 +0000 (UTC) Received: from zeta.ixsystems.com (c-67-188-85-47.hsd1.ca.comcast.net [67.188.85.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 0564611E45; Tue, 7 May 2013 13:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1367957541; bh=qDuVicUWCd11p953GIcNX2kSFkG9NhingWFgQAIj+ps=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=0p/WZWpFjnjy5bVeFJ8fOqGXUNBXEw8ylJbqZAjsKHxHjwTTdTyhxaaq0hKxLAcgf K0wvGFR0XqTsMiveqfAI6/AS7EIEWfHobAlNI11oR10RAesDjzN2kWd4QFgmEQRZNO p51kqC4zhw23iWiPtA9jB26pL9k1QzKHMPC7coeo= Message-ID: <51896021.6010900@delphij.net> Date: Tue, 07 May 2013 13:12:17 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Garrett Cooper Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-arch@FreeBSD.org Arch" , freebsd-toolchain@freebsd.org, "Simon J. Gerraty" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 20:12:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/07/13 13:05, Garrett Cooper wrote: > Hi, A common pattern that I've seen at Isilon and something else > that I've wanted to have for a while is the ability to designate > where the top of a source tree was. This is important and helpful > when dealing with source files that build upon each other or depend > on sources located in other sections of the tree; contrib stuff > needs to set .PATH appropriately to point to sources at the top of > the tree, sys stuff is riddled with S= in order to point to where > /sys, etc lives, we build upon FreeBSD within an expected directory > structure as well. I haven't come up with a name, but was wondering > if this was a good idea, and if so does anyone have any outstanding > patches for this that can be pushed into FreeBSD? Is there anything wrong with the current '../../' approach? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJRiWAhAAoJEG80Jeu8UPuzEJcH/2t8EwktBcuka5r2guXD8ft5 ZFFRH/9/12cxU6L17WRgugL8NPfw37c5qszkIXVqW+WK8ojn/o50Oe4qG48cAbdY rUPQJ3jTxpssm7SRHECu+6z/p5wbNV1xW5Vr1KXn2VYJUQ6BGgfg1NzZAibu0Zp7 gcRxiHAyBI+7CaRDrx91XCf+0AdUYnol3BLrHauSRX/m6ZeSh5NIc3z+aFnIG4Jt Qv25ekPBFtXG/zjzY8x8kIYD/lyMxmXSyW2+OoNMbYEH6JQY/D/dvtm41dbDVw2J 0ZfhQETqogpYybrc/4iro99w4gIfoUpYVf4LE65Q3ZhQmaE+suSPr1C5tdc2tF4= =Q5Hr -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Tue May 7 20:27:25 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8CF7E327; Tue, 7 May 2013 20:27:25 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id EC2A8FF0; Tue, 7 May 2013 20:27:24 +0000 (UTC) Received: by mail-bk0-f52.google.com with SMTP id q16so518978bkw.11 for ; Tue, 07 May 2013 13:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=732HaSfgza7QxyvrcoFufnMsPM4m+AZAieBu7XGT3e0=; b=xMpMqrfn77AN/0JVUjnrlaB2MIFU0t1aJpv2P4zI20jxgF5pMXF35QrgyHBs7+IS89 XKJiV0bNdGhYAX8o3mO+0LxRWR7Q8GvF9wJpXOi4K++LBvN2NaXL+BW89PoEPnyB8hMu AyQm0IAYEBrXUF9ItrqSTANcDaFszqpEEKxkxZiEjSz7iz2+kyUre881Xh8RNFKsLTCF WIpxmqOK8hgf5AoFYUiNPwbtpKBvexGODgTlcTnNC7vsnYWB5JQULmcgyTxiXx3kUkMD o/6AzfbVNb4GARHVnq5rbW3y+Lz1F/s2r7gDbysR2vUwaJRYl1lfRL6eG0Q/OFx3f9fc 5Yqg== MIME-Version: 1.0 X-Received: by 10.204.244.198 with SMTP id lr6mr1038392bkb.1.1367958444071; Tue, 07 May 2013 13:27:24 -0700 (PDT) Received: by 10.204.225.206 with HTTP; Tue, 7 May 2013 13:27:24 -0700 (PDT) In-Reply-To: <51896021.6010900@delphij.net> References: <51896021.6010900@delphij.net> Date: Tue, 7 May 2013 13:27:24 -0700 Message-ID: Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree From: Garrett Cooper To: Xin LI Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arch@FreeBSD.org Arch" , freebsd-toolchain@freebsd.org, "Simon J. Gerraty" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 20:27:25 -0000 On Tue, May 7, 2013 at 1:12 PM, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 05/07/13 13:05, Garrett Cooper wrote: > > Hi, A common pattern that I've seen at Isilon and something else > > that I've wanted to have for a while is the ability to designate > > where the top of a source tree was. This is important and helpful > > when dealing with source files that build upon each other or depend > > on sources located in other sections of the tree; contrib stuff > > needs to set .PATH appropriately to point to sources at the top of > > the tree, sys stuff is riddled with S= in order to point to where > > /sys, etc lives, we build upon FreeBSD within an expected directory > > structure as well. I haven't come up with a name, but was wondering > > if this was a good idea, and if so does anyone have any outstanding > > patches for this that can be pushed into FreeBSD? > > Is there anything wrong with the current '../../' approach? > Not in particular, other than our variable (ISI_TOP) is used in referencing ${.CURDIR} and ${.OBJDIR}, and it's easy to make mistakes if you goof up the dot-dots. With a properly defined directory like that it makes things unambiguous in my mind and with a proper name it makes pathing more intuitive than it currently is. Besides, it would make some other things cleaner, like the dot-dot magic that config(8), etc does. Thanks! -Garrett From owner-freebsd-arch@FreeBSD.ORG Tue May 7 20:39:08 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 63F2D729; Tue, 7 May 2013 20:39:08 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id A561EC7; Tue, 7 May 2013 20:39:07 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r47Kd6fd058035; Tue, 7 May 2013 15:39:06 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r47Kd6nM058034; Tue, 7 May 2013 15:39:06 -0500 (CDT) (envelope-from brooks) Date: Tue, 7 May 2013 15:39:06 -0500 From: Brooks Davis To: Garrett Cooper Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree Message-ID: <20130507203906.GB40460@lor.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rS8CxjVDS/+yyDmU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-arch@FreeBSD.org Arch" , freebsd-toolchain@freebsd.org, "Simon J. Gerraty" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 20:39:08 -0000 --rS8CxjVDS/+yyDmU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, May 07, 2013 at 01:05:07PM -0700, Garrett Cooper wrote: > Hi, > A common pattern that I've seen at Isilon and something else that I've > wanted to have for a while is the ability to designate where the top of a > source tree was. This is important and helpful when dealing with source > files that build upon each other or depend on sources located in other > sections of the tree; contrib stuff needs to set .PATH appropriately to > point to sources at the top of the tree, sys stuff is riddled with S= in > order to point to where /sys, etc lives, we build upon FreeBSD within an > expected directory structure as well. > I haven't come up with a name, but was wondering if this was a good > idea, and if so does anyone have any outstanding patches for this that can > be pushed into FreeBSD? I'd like to see this. There's a variable for this in NetBSD and I've wanted to do this because it makes code easier to relocate within the tree. -- Brooks --rS8CxjVDS/+yyDmU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRiWZpXY6L6fI4GtQRAi8HAJ0fOeFrOZQuxZ7XIDQrZcpufMRVPgCff47g CxnMzuy2Rf0RdQhOTFWH0Tw= =zNT2 -----END PGP SIGNATURE----- --rS8CxjVDS/+yyDmU-- From owner-freebsd-arch@FreeBSD.ORG Tue May 7 20:46:40 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 845C6946; Tue, 7 May 2013 20:46:40 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by mx1.freebsd.org (Postfix) with ESMTP id 54E20128; Tue, 7 May 2013 20:46:40 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id 10so697706pdi.1 for ; Tue, 07 May 2013 13:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=8OUq4e37wdvhYb3hEQxBfGARm7P1YixLzowWlb9ecnI=; b=Zib7s+PC8atxzjjw69geZ8hBD/w8DCoTFgCIK4ZtGSfdXc4L4iCo6YZbRQ7hsBbdte pQDLvSn5VbvP4EhlN2UfASpi19A07Gnyc+ISXCIvI4PIPtteDXNT5JWqv2TLFRbsC6/z bNnbH7AkxEgNIxidLpQfCvNaDaO8nXPZT5RJLAjrdIL+Op9zeBKWIerjmUmaGx/KU7sT Xg2lgOoppOYFySdDzj57s/0KTeuRm/yLH7qR1J3IAql9O2faRnbcENsEoUrT14hINbFW AFI+OZaP1mGcJ/Hrt2kZ1Gex5LXI606aJBEhkytIkk43REtAnw/1hOHwW1MX6D6IMiAc RnEg== X-Received: by 10.66.121.202 with SMTP id lm10mr4679081pab.138.1367959599760; Tue, 07 May 2013 13:46:39 -0700 (PDT) Received: from [192.168.242.58] (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPSA id sa6sm29509099pbb.26.2013.05.07.13.46.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 13:46:38 -0700 (PDT) Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Garrett Cooper In-Reply-To: <20130507203906.GB40460@lor.one-eyed-alien.net> Date: Tue, 7 May 2013 13:46:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2E2C2F74-A25B-4B9F-84C4-0A434B8C7EE6@gmail.com> References: <20130507203906.GB40460@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1283) Cc: "freebsd-arch@FreeBSD.org Arch" , freebsd-toolchain@freebsd.org, "Simon J. Gerraty" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 20:46:40 -0000 On May 7, 2013, at 1:39 PM, Brooks Davis wrote: > On Tue, May 07, 2013 at 01:05:07PM -0700, Garrett Cooper wrote: >> Hi, >> A common pattern that I've seen at Isilon and something else that = I've >> wanted to have for a while is the ability to designate where the top = of a >> source tree was. This is important and helpful when dealing with = source >> files that build upon each other or depend on sources located in = other >> sections of the tree; contrib stuff needs to set .PATH appropriately = to >> point to sources at the top of the tree, sys stuff is riddled with S=3D= in >> order to point to where /sys, etc lives, we build upon FreeBSD within = an >> expected directory structure as well. >> I haven't come up with a name, but was wondering if this was a = good >> idea, and if so does anyone have any outstanding patches for this = that can >> be pushed into FreeBSD? >=20 > I'd like to see this. There's a variable for this in NetBSD and I've > wanted to do this because it makes code easier to relocate within the > tree. This is another good reason. It would make porting code to/from = NetBSD a LOT easier=85 especially because I plan on pulling a lot of = test/test infrastructure code from NetBSD and I really don't want to = commit too many local changes to the Makefiles. Less divergence -> = better cross-pollination -> less work for all -> win for the BSDs. Thanks for the reminder.. I'll base it off what NetBSD did :). Thanks, -Garrett= From owner-freebsd-arch@FreeBSD.ORG Tue May 7 21:00:35 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AD025C39 for ; Tue, 7 May 2013 21:00:35 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by mx1.freebsd.org (Postfix) with ESMTP id 774151C1 for ; Tue, 7 May 2013 21:00:35 +0000 (UTC) Received: by mail-oa0-f45.google.com with SMTP id j6so190763oag.18 for ; Tue, 07 May 2013 14:00:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=HbSdVVDEi0maLv0LJ3SVwF6VrfDkJ4a96aFR7vYrcH0=; b=kIm3mVlaTWuOTaIyxQGRpVDp6M2FibhCX+61ZbB+JBmIZaWr6uC96hGeeBtLtkUMc6 ZExcMlwQIB0qmBj5L7jERTxwZMPYFSf3vfPpasQmyxhcZVzmqrrMJF+EDJXQ+mgX0w5O 6jj2FmMyebEgvGO9ETHoN65HEfa6Netp4CN3QPjlL625mGwNdHKcqfX1iFkPEWweNZFc ZB9foHq4fWw9eLIWAPN1ySaraorbEnAwERO3lP/ENakrmtZ00RjhCnc7LKnTWbFH7bvg /yZXegFyGmE78l6EWEkIev0gTJzbF3/oar0AZPSV/LzOE0PXYFhfnrJmNIvemVaEQARH nVHw== X-Received: by 10.60.133.242 with SMTP id pf18mr1051688oeb.80.1367960429409; Tue, 07 May 2013 14:00:29 -0700 (PDT) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id ns4sm6685388obc.2.2013.05.07.14.00.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 14:00:28 -0700 (PDT) Sender: Warner Losh Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: <2E2C2F74-A25B-4B9F-84C4-0A434B8C7EE6@gmail.com> Date: Tue, 7 May 2013 15:00:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130507203906.GB40460@lor.one-eyed-alien.net> <2E2C2F74-A25B-4B9F-84C4-0A434B8C7EE6@gmail.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnHWoPJrE00uDvrsuQ/LsCchCqkEFa9KBsXAXpirIX9oWPYmDHInxZ/tiLjjiXo9CPDV89c Cc: "Simon J. Gerraty" , freebsd-toolchain@freebsd.org, Brooks Davis , "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 21:00:35 -0000 On May 7, 2013, at 2:46 PM, Garrett Cooper wrote: > On May 7, 2013, at 1:39 PM, Brooks Davis wrote: >=20 >> On Tue, May 07, 2013 at 01:05:07PM -0700, Garrett Cooper wrote: >>> Hi, >>> A common pattern that I've seen at Isilon and something else that = I've >>> wanted to have for a while is the ability to designate where the top = of a >>> source tree was. This is important and helpful when dealing with = source >>> files that build upon each other or depend on sources located in = other >>> sections of the tree; contrib stuff needs to set .PATH appropriately = to >>> point to sources at the top of the tree, sys stuff is riddled with = S=3D in >>> order to point to where /sys, etc lives, we build upon FreeBSD = within an >>> expected directory structure as well. >>> I haven't come up with a name, but was wondering if this was a = good >>> idea, and if so does anyone have any outstanding patches for this = that can >>> be pushed into FreeBSD? >>=20 >> I'd like to see this. There's a variable for this in NetBSD and I've >> wanted to do this because it makes code easier to relocate within the >> tree. >=20 > This is another good reason. It would make porting code to/from = NetBSD a LOT easier=85 especially because I plan on pulling a lot of = test/test infrastructure code from NetBSD and I really don't want to = commit too many local changes to the Makefiles. Less divergence -> = better cross-pollination -> less work for all -> win for the BSDs. > Thanks for the reminder.. I'll base it off what NetBSD did :). SRCDIR Once upon a time, this *HAD* to be set, and wasn't inferred from the = current top of the tree. Please, for the love of god, make sure that we = don't lose the infer from top of tree ability, or I will hurt you. = Often. Through all the minions that owe me minor favors. Warner From owner-freebsd-arch@FreeBSD.ORG Tue May 7 21:26:17 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5B751EAE; Tue, 7 May 2013 21:26:17 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id 8E77C26D; Tue, 7 May 2013 21:26:16 +0000 (UTC) Received: by mail-bk0-f53.google.com with SMTP id i18so539727bkv.40 for ; Tue, 07 May 2013 14:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=YJriwf6hpu47VfHM4lgfIOvQ0JbuMWLQSk/niRU5zAI=; b=HyTh7rs9OKKd9aYMiZYFsXXM0YH63FQ7RmnveRlRzLowkgkBF1+uFE+cQCx7j6Uqj2 nn5uoCib9t8rRSoRhzLLNd3zwFkYah2RAfWemvIuVC2uWtt2Re0/geK2TbHZiOZkdeNK A9UB1BW/IqlO77hsxuWb/uCe3j9Pp9vyIl4QeHydK9ubD34U/UN2CAhTAHv5nLRsbMkD Yk0ozuCKxKV35Bvw5NMuNEHIoSoDqKxjN/QA8lW9+MKVx+16o6NfaA1tB2dfWboWo4tj s8JA2zwMIJnccfPJwmUQ744ncril3Rzf4NllQf1qLRnHX4YnW0SWHcalz9/v/37hAifi wfaQ== MIME-Version: 1.0 X-Received: by 10.204.226.80 with SMTP id iv16mr1076112bkb.48.1367961975281; Tue, 07 May 2013 14:26:15 -0700 (PDT) Received: by 10.204.225.206 with HTTP; Tue, 7 May 2013 14:26:15 -0700 (PDT) In-Reply-To: References: <20130507203906.GB40460@lor.one-eyed-alien.net> <2E2C2F74-A25B-4B9F-84C4-0A434B8C7EE6@gmail.com> Date: Tue, 7 May 2013 14:26:15 -0700 Message-ID: Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree From: Garrett Cooper To: Warner Losh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Simon J. Gerraty" , freebsd-toolchain@freebsd.org, Brooks Davis , "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 21:26:17 -0000 On Tue, May 7, 2013 at 2:00 PM, Warner Losh wrote: > > On May 7, 2013, at 2:46 PM, Garrett Cooper wrote: > > > On May 7, 2013, at 1:39 PM, Brooks Davis wrote: > > > >> On Tue, May 07, 2013 at 01:05:07PM -0700, Garrett Cooper wrote: > >>> Hi, > >>> A common pattern that I've seen at Isilon and something else that > I've > >>> wanted to have for a while is the ability to designate where the top > of a > >>> source tree was. This is important and helpful when dealing with sour= ce > >>> files that build upon each other or depend on sources located in othe= r > >>> sections of the tree; contrib stuff needs to set .PATH appropriately = to > >>> point to sources at the top of the tree, sys stuff is riddled with S= =3D > in > >>> order to point to where /sys, etc lives, we build upon FreeBSD within > an > >>> expected directory structure as well. > >>> I haven't come up with a name, but was wondering if this was a good > >>> idea, and if so does anyone have any outstanding patches for this tha= t > can > >>> be pushed into FreeBSD? > >> > >> I'd like to see this. There's a variable for this in NetBSD and I've > >> wanted to do this because it makes code easier to relocate within the > >> tree. > > > > This is another good reason. It would make porting code to/from > NetBSD a LOT easier=85 especially because I plan on pulling a lot of > test/test infrastructure code from NetBSD and I really don't want to comm= it > too many local changes to the Makefiles. Less divergence -> better > cross-pollination -> less work for all -> win for the BSDs. > > Thanks for the reminder.. I'll base it off what NetBSD did :). > > SRCDIR > EVARINUSE? share/mk/bsd.doc.mk:# SRCDIR Directory where source files live. [${.CURDIR}] share/mk/bsd.doc.mk:TRFLAGS+=3D -I${SRCDIR} share/mk/bsd.doc.mk:.PATH: ${.CURDIR} ${SRCDIR} share/mk/bsd.doc.mk: cd ${SRCDIR}; \ share/mk/bsd.doc.mk:SRCDIR?=3D ${.CURDIR} share/mk/bsd.doc.mk: cd ${SRCDIR}; ${UNROFF} ${MACROS} ${UNROFFFLAGS} \ share/mk/bsd.doc.mk: cd ${SRCDIR}; ${UNROFF} -ms ${UNROFFFLAGS} \ share/mk/bsd.info.mk:SRCDIR?=3D ${.CURDIR} ... share/doc/llvm/Makefile:SRCDIR=3D ${.CURDIR}/../../../contrib/llvm share/doc/llvm/Makefile:.PATH: ${SRCDIR} ${SRCDIR}/lib/Support share/doc/llvm/clang/Makefile:SRCDIR=3D ${.CURDIR}/../../../../contrib/llvm/tools/clang share/doc/llvm/clang/Makefile:.PATH: ${SRCDIR} > Once upon a time, this *HAD* to be set, and wasn't inferred from the > current top of the tree. Please, for the love of god, make sure that we > don't lose the infer from top of tree ability, or I will hurt you. Often. > Through all the minions that owe me minor favors. > I don't want to break that ever; it's a fantastic feature. If you could point me to where that magic awesomeness lives (make?), I'll be more than happy to address it in my branch where I'm going to do this. I really don't like how NetBSD turned their top-level build command into a shell script [in part because it needs to bootstrap a bunch of tools]. It makes things painful when doing iterative builds.. So all in all, I completely and wholeheartedly agree with your concerns. Thanks! -Garrett From owner-freebsd-arch@FreeBSD.ORG Tue May 7 21:29:33 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2B217F9B; Tue, 7 May 2013 21:29:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 6CC7D28B; Tue, 7 May 2013 21:29:32 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id u54so1055028wes.15 for ; Tue, 07 May 2013 14:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8VlCRQg4jefI5b+C8xleX6T5bgerynm8ncO4oKWCOLw=; b=Az+ikq0gkGTXw1uPwiW+IXcvl2bxaOv/WZCZB4l0lAJz7eu8cZ8bhk7FUgNupxRjve MaKqjt+jxCNbDbnmX5j6bdnv24O/y/NT4+O3m/I1SOWioGPEQ/FHlH2QAO3a8czHjYUR XtrUEVOVFiPQmA/wbPpWg+IElbcWY8UV3uOZaJpDLGV4P7klVqJXCEZfsSYnsH0gGTkx OcJPTr2hD8TGkzk+3h/8hEhpK2R9j1jHxVIzIobiBl3AG62MPj/n6yn3NMok1b779BYd wq3qn254K7IaDPoDBl+Wq853aWyj1inJ3dDAZt5o5a4oQbbyv+4FwzJr7n4HF9b77JrP aQiQ== MIME-Version: 1.0 X-Received: by 10.180.88.162 with SMTP id bh2mr6045591wib.3.1367962171057; Tue, 07 May 2013 14:29:31 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Tue, 7 May 2013 14:29:30 -0700 (PDT) In-Reply-To: <201305071539.24900.jhb@freebsd.org> References: <201305071433.27993.jhb@freebsd.org> <51894A5B.7060101@freebsd.org> <201305071539.24900.jhb@freebsd.org> Date: Tue, 7 May 2013 14:29:30 -0700 X-Google-Sender-Auth: FTfb0qvRhjWvX4vkvEpv5FJeV6E Message-ID: Subject: Re: Extending MADV_PROTECT From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 21:29:33 -0000 On 7 May 2013 12:39, John Baldwin wrote: > Well, only root can do it. Even now MADV_PROTECT is a similar foot shooting > device (though not quite as easy to do). You can also get yourself into a heap > of trouble with other things like rtprio, etc., so I sort of think that is up to > the user/administrator to manage. I do think that the more fine-grained priority > approach may be a good way to mitigate that if it really becomes an issue at some > point. This is the kind of thing that begs for a capability. And I'm surprised Robert hasn't chimed in and said just that. However, I think we still lack the ability to do useful capability work from user-space. God I'd like to be wrong on this one. Adrian From owner-freebsd-arch@FreeBSD.ORG Tue May 7 21:56:03 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C96A2365; Tue, 7 May 2013 21:56:03 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by mx1.freebsd.org (Postfix) with ESMTP id 8F112369; Tue, 7 May 2013 21:56:03 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUYl4bIyd/dlF2UjbXe53MXGPnvrltLcO@postini.com; Tue, 07 May 2013 14:56:03 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 7 May 2013 14:31:22 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r47LVIL03572; Tue, 7 May 2013 14:31:20 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 5277F58097; Tue, 7 May 2013 14:31:18 -0700 (PDT) To: Garrett Cooper Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree In-Reply-To: References: Comments: In-reply-to: Garrett Cooper message dated "Tue, 07 May 2013 13:05:07 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Tue, 7 May 2013 14:31:18 -0700 Message-ID: <20130507213118.5277F58097@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-toolchain@freebsd.org, "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 21:56:03 -0000 On Tue, 7 May 2013 13:05:07 -0700, Garrett Cooper writes: > A common pattern that I've seen at Isilon and something else that I've >wanted to have for a while is the ability to designate where the top of a >source tree was. This is important and helpful when dealing with source >files that build upon each other or depend on sources located in other FWIW I've done this in the projects/bmake branch. SRCTOP is the top of the src tree OBJTOP is the top of the corresponding obj tree OBJROOT is a common prefix (allows one to deduce where objects for a different value of $MACHINE will be). $ make -V '${SRCTOP OBJROOT OBJTOP .CURDIR .OBJDIR:L:@v@$v=${$v}@:ts\n}' SRCTOP=/b/sjg/work/FreeBSD/projects-bmake/src OBJROOT=/var/obj/projects-bmake/ OBJTOP=/var/obj/projects-bmake/amd64 .CURDIR=/b/sjg/work/FreeBSD/projects-bmake/src/bin/cat .OBJDIR=/var/obj/projects-bmake/amd64/bin/cat $ SRCTOP is simple to derrive from where sys.mk is found and the others can be deduced from that SRCTOP:= ${.PARSEDIR:H:H:tA} OBJROOT?= ${SRCTOP:H}/obj/ OBJTOP?= ${OBJROOT}${MACHINE} though since FreeBSD builds more than one MACHINE_ARCH per MACHINE (in some cases), OBJTOP?= ${OBJROOT}${MACHINE_ARCH} might make sense. For Junos we had the opposite - multiple MACHINEs with same MACHINE_ARCH. I'm currently teaking projects-bmake so it can do the equivalent of universe so if more than one MACHINE_ARCH is possiblem the OBJTOP ends up being OBJTOP= ${OBJROOT}${MACHINE}-${MACHINE_ARCH} but for cases like i386, amd64 you just get OBJTOP= ${OBJROOT}${MACHINE} as above. From owner-freebsd-arch@FreeBSD.ORG Wed May 8 03:25:48 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DD6CDC3A for ; Wed, 8 May 2013 03:25:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by mx1.freebsd.org (Postfix) with ESMTP id B81B8149 for ; Wed, 8 May 2013 03:25:47 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id lj1so996481pab.4 for ; Tue, 07 May 2013 20:25:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=8l1Y6gXpDuldXt0SA8mQTDGl6WOG1V/aapviw8igWUs=; b=LSGIHsLfHPziKS93aCPrMYfRITHirNT9sm93Lu2jQVH4N2UiHhaFMDzGoWsOXfSSYO isdNrt2pYDzBZS/6tkv0DY36R0/PMewUtiO+u7Q28LAbv5oM7eDahJSuCVZ4UhgBoraz Ksc9ljbW6iLG8SzzbSfrRjBckmGBsssG7FMTpc5xkjBmeVREDg0uq0gcDAb4iUwziyqW X7GQw8F1zipZn2eEJ6f/b2xOEVd+FIEnmYGwX8oZnk5Ce74J5GScUg6KolL26wF1clUU xzrrjaDs2JULzFufJpiZ0PGHFTlaKr9LMxG+zO39qrFQ69v3ryQ1YlTksv8+AbNuwNIV JF6w== X-Received: by 10.66.160.162 with SMTP id xl2mr5780001pab.215.1367983541499; Tue, 07 May 2013 20:25:41 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ya4sm30679591pbb.24.2013.05.07.20.25.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 20:25:40 -0700 (PDT) Sender: Warner Losh Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130507213118.5277F58097@chaos.jnpr.net> Date: Tue, 7 May 2013 21:25:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130507213118.5277F58097@chaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkzp1cy1dqQBnLY38HWXAZXsMe8/DidOQzUESv9+eyoVvHJzk9Q3ii3OU6djLYJG1WrY7m7 Cc: Garrett Cooper , freebsd-toolchain@freebsd.org, "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 03:25:48 -0000 On May 7, 2013, at 3:31 PM, Simon J. Gerraty wrote: >=20 > On Tue, 7 May 2013 13:05:07 -0700, Garrett Cooper writes: >> A common pattern that I've seen at Isilon and something else that = I've >> wanted to have for a while is the ability to designate where the top = of a >> source tree was. This is important and helpful when dealing with = source >> files that build upon each other or depend on sources located in = other >=20 > FWIW I've done this in the projects/bmake branch. >=20 > SRCTOP is the top of the src tree > OBJTOP is the top of the corresponding obj tree > OBJROOT is a common prefix (allows one to deduce where objects for a > different value of $MACHINE will be). where does MAKEOBJDIRPREFIX come into play? > $ make -V '${SRCTOP OBJROOT OBJTOP .CURDIR = .OBJDIR:L:@v@$v=3D${$v}@:ts\n}' > SRCTOP=3D/b/sjg/work/FreeBSD/projects-bmake/src > OBJROOT=3D/var/obj/projects-bmake/ > OBJTOP=3D/var/obj/projects-bmake/amd64 > .CURDIR=3D/b/sjg/work/FreeBSD/projects-bmake/src/bin/cat > .OBJDIR=3D/var/obj/projects-bmake/amd64/bin/cat > $ >=20 > SRCTOP is simple to derrive from where sys.mk is found > and the others can be deduced from that >=20 > SRCTOP:=3D ${.PARSEDIR:H:H:tA} > OBJROOT?=3D ${SRCTOP:H}/obj/ > OBJTOP?=3D ${OBJROOT}${MACHINE} >=20 > though since FreeBSD builds more than one MACHINE_ARCH per MACHINE (in > some cases),=20 >=20 > OBJTOP?=3D ${OBJROOT}${MACHINE_ARCH} >=20 > might make sense. We do it both ways: on some architectures we have multiple = MACHINE_ARCHes per MACHINE (like mips and arm) and on others we have one = MACHINE_ARCH and mutliple machines (like i386 and pc98). We currently use ${MACHINE}.${MACHINE_ARCH} for cross builds, which = works out nicely. For historical reasons that turn out to be = inconvenient, we don't do this for native builds. > For Junos we had the opposite - multiple MACHINEs with same > MACHINE_ARCH. >=20 > I'm currently teaking projects-bmake so it can do the equivalent of > universe so if more than one MACHINE_ARCH is possiblem the OBJTOP ends > up being >=20 > OBJTOP=3D ${OBJROOT}${MACHINE}-${MACHINE_ARCH} >=20 > but for cases like i386, amd64 you just get=20 >=20 > OBJTOP=3D ${OBJROOT}${MACHINE} >=20 > as above. Why is this gratuitously different than the current scheme? Also, how = would I build a pc98 build with this? And why have it be different for = different architectures? The differences like these (although maybe not = this one) make things harder to script for things like nanobsd that = reach into the object tree, though the OBJTOP might be enough to solve = that. Warner From owner-freebsd-arch@FreeBSD.ORG Wed May 8 03:42:39 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A0729E6C; Wed, 8 May 2013 03:42:39 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by mx1.freebsd.org (Postfix) with ESMTP id 3C4451D7; Wed, 8 May 2013 03:42:38 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id kw10so1257739vcb.23 for ; Tue, 07 May 2013 20:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hiepuPno0za4+Yvm3t1p81TvkM5cnBxVi8LVK8ni0SU=; b=pxF4lvSjNSyFGjaeE05WLwfsqkM+e0SxWl45BwJrayQ8xOhErdXeNoJfLibc/XjnUE bwRCeBjmaXEm0noV32awG/dgX84q5oJot41tsk3pR8Bsjk/2s9kHYDeXbQmOa6Tg6NbB iUGHFIij64t4Gmea5H9UEtdhd3/do6T4lMF7aua7DKzez6HevYRKtleN6NuciiCRCkTd qxiohcfIdTpD6pvZ8lo10beL4H2/XGH5gfdJi3i7iUGdQtP/09k7DLoVoXUq5vnd0ZZX Qo+EEuwQpbhYILhH4CHHgNItjQ0V87+4C23KWMOEBqIx2RCRg0+pmRytZKufk9UDrWtS ykwA== MIME-Version: 1.0 X-Received: by 10.52.68.205 with SMTP id y13mr2710454vdt.33.1367984558233; Tue, 07 May 2013 20:42:38 -0700 (PDT) Received: by 10.52.31.194 with HTTP; Tue, 7 May 2013 20:42:38 -0700 (PDT) In-Reply-To: References: <20130507203906.GB40460@lor.one-eyed-alien.net> <2E2C2F74-A25B-4B9F-84C4-0A434B8C7EE6@gmail.com> Date: Tue, 7 May 2013 20:42:38 -0700 Message-ID: Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree From: Garrett Cooper To: Warner Losh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Simon J. Gerraty" , freebsd-toolchain@freebsd.org, Brooks Davis , "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 03:42:39 -0000 On Tue, May 7, 2013 at 2:26 PM, Garrett Cooper wrote: > > On Tue, May 7, 2013 at 2:00 PM, Warner Losh wrote: > >> >> On May 7, 2013, at 2:46 PM, Garrett Cooper wrote: >> >> > On May 7, 2013, at 1:39 PM, Brooks Davis wrote: >> > >> >> On Tue, May 07, 2013 at 01:05:07PM -0700, Garrett Cooper wrote: >> >>> Hi, >> >>> A common pattern that I've seen at Isilon and something else that >> I've >> >>> wanted to have for a while is the ability to designate where the top >> of a >> >>> source tree was. This is important and helpful when dealing with >> source >> >>> files that build upon each other or depend on sources located in oth= er >> >>> sections of the tree; contrib stuff needs to set .PATH appropriately >> to >> >>> point to sources at the top of the tree, sys stuff is riddled with S= =3D >> in >> >>> order to point to where /sys, etc lives, we build upon FreeBSD withi= n >> an >> >>> expected directory structure as well. >> >>> I haven't come up with a name, but was wondering if this was a goo= d >> >>> idea, and if so does anyone have any outstanding patches for this >> that can >> >>> be pushed into FreeBSD? >> >> >> >> I'd like to see this. There's a variable for this in NetBSD and I've >> >> wanted to do this because it makes code easier to relocate within the >> >> tree. >> > >> > This is another good reason. It would make porting code to/from >> NetBSD a LOT easier=85 especially because I plan on pulling a lot of >> test/test infrastructure code from NetBSD and I really don't want to com= mit >> too many local changes to the Makefiles. Less divergence -> better >> cross-pollination -> less work for all -> win for the BSDs. >> > Thanks for the reminder.. I'll base it off what NetBSD did :). >> >> SRCDIR >> > > EVARINUSE? > > share/mk/bsd.doc.mk:# SRCDIR Directory where source files live. > [${.CURDIR}] > share/mk/bsd.doc.mk:TRFLAGS+=3D -I${SRCDIR} > share/mk/bsd.doc.mk:.PATH: ${.CURDIR} ${SRCDIR} > share/mk/bsd.doc.mk: cd ${SRCDIR}; \ > share/mk/bsd.doc.mk:SRCDIR?=3D ${.CURDIR} > share/mk/bsd.doc.mk: cd ${SRCDIR}; ${UNROFF} ${MACROS} ${UNROFFFLAGS} = \ > share/mk/bsd.doc.mk: cd ${SRCDIR}; ${UNROFF} -ms ${UNROFFFLAGS} \ > share/mk/bsd.info.mk:SRCDIR?=3D ${.CURDIR} > ... > share/doc/llvm/Makefile:SRCDIR=3D ${.CURDIR}/../../../contrib/llv= m > share/doc/llvm/Makefile:.PATH: ${SRCDIR} ${SRCDIR}/lib/Support > share/doc/llvm/clang/Makefile:SRCDIR=3D > ${.CURDIR}/../../../../contrib/llvm/tools/clang > share/doc/llvm/clang/Makefile:.PATH: ${SRCDIR} > > >> Once upon a time, this *HAD* to be set, and wasn't inferred from the >> current top of the tree. Please, for the love of god, make sure that we >> don't lose the infer from top of tree ability, or I will hurt you. Often= . >> Through all the minions that owe me minor favors. >> > > I don't want to break that ever; it's a fantastic feature. If you could > point me to where that magic awesomeness lives (make?), I'll be more than > happy to address it in my branch where I'm going to do this. > > I really don't like how NetBSD turned their top-level build command into = a > shell script [in part because it needs to bootstrap a bunch of tools]. It > makes things painful when doing iterative builds.. > > So all in all, I completely and wholeheartedly agree with your concerns. > Oh sweet.. this is something to keep in mind too (from bsd.port.mk)... # SRC_BASE - The root of the src tree. (Some ports require this to ge= t # kernel sources). Default: /usr/src All else fails, ports has done it first -_-... Not the first var I've seen this done with... Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Wed May 8 05:10:01 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3A56359F for ; Wed, 8 May 2013 05:10:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 092A264E for ; Wed, 8 May 2013 05:10:00 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id ar20so2435257iec.39 for ; Tue, 07 May 2013 22:10:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=OXknUKNVllS4utD+8w86MevQgXt7z9VVaio/2rKtqMo=; b=SewzOYcLdTGrjwyXK2OSnVenVf2sjmjAfz9NZWATUmOou9QHicQ3P8FYy1Vbb5dRBN uCYOMMBVCeJHnSS7NJ4rgcS/mCrfirf6CxbgAENaaamTuGzKfZOHzPIf7No5YelwXQWJ Ulg+qxhFnx6HaPuNmJ7sm9XuWokTOjou2SR7DkX9w7oeMDE5EoVlU7f6HfrKm8tEjOKJ P7q30xD4CqP6WIZQ2HdjioFyqg03Gg6AsJVYhaaDz2WCpPHjY4MwUeIFf/ryB6nL4uul byEmPOoyUMW9MRd6TDQzQZKz5uloGz8dWN5yAqx1IkjGg3M1JFYONH+ni+b+8xRDFJV7 +nlg== X-Received: by 10.42.21.206 with SMTP id l14mr1277124icb.31.1367989800587; Tue, 07 May 2013 22:10:00 -0700 (PDT) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id wn10sm1858194igb.2.2013.05.07.22.09.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 22:09:59 -0700 (PDT) Sender: Warner Losh Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: Date: Tue, 7 May 2013 23:09:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130507203906.GB40460@lor.one-eyed-alien.net> <2E2C2F74-A25B-4B9F-84C4-0A434B8C7EE6@gmail.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmZM7qZDGSTdgC6coxLPl6ulWQsLjcwtSwOJMi6Jah+31ktPvBc9PdKA12+T2Be7O5mngEN Cc: "Simon J. Gerraty" , freebsd-toolchain@freebsd.org, Brooks Davis , "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 05:10:01 -0000 On May 7, 2013, at 9:42 PM, Garrett Cooper wrote: > On Tue, May 7, 2013 at 2:26 PM, Garrett Cooper = wrote: >=20 > On Tue, May 7, 2013 at 2:00 PM, Warner Losh wrote: >=20 > On May 7, 2013, at 2:46 PM, Garrett Cooper wrote: >=20 > > On May 7, 2013, at 1:39 PM, Brooks Davis wrote: > > > >> On Tue, May 07, 2013 at 01:05:07PM -0700, Garrett Cooper wrote: > >>> Hi, > >>> A common pattern that I've seen at Isilon and something else = that I've > >>> wanted to have for a while is the ability to designate where the = top of a > >>> source tree was. This is important and helpful when dealing with = source > >>> files that build upon each other or depend on sources located in = other > >>> sections of the tree; contrib stuff needs to set .PATH = appropriately to > >>> point to sources at the top of the tree, sys stuff is riddled with = S=3D in > >>> order to point to where /sys, etc lives, we build upon FreeBSD = within an > >>> expected directory structure as well. > >>> I haven't come up with a name, but was wondering if this was a = good > >>> idea, and if so does anyone have any outstanding patches for this = that can > >>> be pushed into FreeBSD? > >> > >> I'd like to see this. There's a variable for this in NetBSD and = I've > >> wanted to do this because it makes code easier to relocate within = the > >> tree. > > > > This is another good reason. It would make porting code = to/from NetBSD a LOT easier=85 especially because I plan on pulling a = lot of test/test infrastructure code from NetBSD and I really don't want = to commit too many local changes to the Makefiles. Less divergence -> = better cross-pollination -> less work for all -> win for the BSDs. > > Thanks for the reminder.. I'll base it off what NetBSD did :). >=20 > SRCDIR >=20 > EVARINUSE? >=20 > share/mk/bsd.doc.mk:# SRCDIR Directory where source files live. = [${.CURDIR}] > share/mk/bsd.doc.mk:TRFLAGS+=3D -I${SRCDIR} > share/mk/bsd.doc.mk:.PATH: ${.CURDIR} ${SRCDIR} > share/mk/bsd.doc.mk: cd ${SRCDIR}; \ > share/mk/bsd.doc.mk:SRCDIR?=3D ${.CURDIR} > share/mk/bsd.doc.mk: cd ${SRCDIR}; ${UNROFF} ${MACROS} = ${UNROFFFLAGS} \ > share/mk/bsd.doc.mk: cd ${SRCDIR}; ${UNROFF} -ms ${UNROFFFLAGS} \ > share/mk/bsd.info.mk:SRCDIR?=3D ${.CURDIR} > ... > share/doc/llvm/Makefile:SRCDIR=3D = ${.CURDIR}/../../../contrib/llvm > share/doc/llvm/Makefile:.PATH: ${SRCDIR} ${SRCDIR}/lib/Support > share/doc/llvm/clang/Makefile:SRCDIR=3D = ${.CURDIR}/../../../../contrib/llvm/tools/clang > share/doc/llvm/clang/Makefile:.PATH: ${SRCDIR} > =20 > Once upon a time, this *HAD* to be set, and wasn't inferred from the = current top of the tree. Please, for the love of god, make sure that we = don't lose the infer from top of tree ability, or I will hurt you. = Often. Through all the minions that owe me minor favors. >=20 > I don't want to break that ever; it's a fantastic feature. If you = could point me to where that magic awesomeness lives (make?), I'll be = more than happy to address it in my branch where I'm going to do this. >=20 > I really don't like how NetBSD turned their top-level build command = into a shell script [in part because it needs to bootstrap a bunch of = tools]. It makes things painful when doing iterative builds.. >=20 > So all in all, I completely and wholeheartedly agree with your = concerns. >=20 > Oh sweet.. this is something to keep in mind too (from bsd.port.mk)... >=20 > # SRC_BASE - The root of the src tree. (Some ports require this = to get > # kernel sources). Default: /usr/src >=20 > All else fails, ports has done it first -_-... >=20 > Not the first var I've seen this done with... I thought ports specifically named things differently to avoid = conflicts. Warner From owner-freebsd-arch@FreeBSD.ORG Wed May 8 05:39:25 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6A559909; Wed, 8 May 2013 05:39:25 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id 37BD0767; Wed, 8 May 2013 05:39:24 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id u10so978651pdi.19 for ; Tue, 07 May 2013 22:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=q2C7KXQ3T0dp2XgrMIGs8XhntdW+quIsMai3Veu8RlY=; b=jsmnUpB0pWfY5zFAWsNlkmmoeFLxYV/KJx6Q55O4dD7FH47CbjbhN2g+lX1vfdmv7e yOFW/x4nOoVcefWJuC0nKbhz9mQg1jrp0X1CEVH2mdBJZiq+woedS3ziu1vIw2p5TRZP PvH4vnAxHZlTrXw2PpmG20LsMHxE1400ia/9R7xTWExTsMfugErcbSC7CkUhABgB2vYA PPXAUDNrAD6Qz+4BkQb+6fBzM786z1qedwtzGZjn0TIogfHuHr1LuPmzKrFsxdl5sBLM gXo9JUnmpjTFlbTAnVSAlj3+ElzcLYQuSHOhfgSyqwwP3tWC/DarTBT/bg8xtfJgV5ZI Z8Nw== X-Received: by 10.66.154.167 with SMTP id vp7mr6428824pab.7.1367991564549; Tue, 07 May 2013 22:39:24 -0700 (PDT) Received: from [192.168.0.139] (174-24-222-208.tukw.qwest.net. [174.24.222.208]) by mx.google.com with ESMTPSA id aj2sm31191034pbc.1.2013.05.07.22.39.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 22:39:23 -0700 (PDT) References: <20130507203906.GB40460@lor.one-eyed-alien.net> <2E2C2F74-A25B-4B9F-84C4-0A434B8C7EE6@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=cp932 Content-Transfer-Encoding: quoted-printable Message-Id: <6700AD11-D97D-42D0-9355-0D928CF0E103@gmail.com> X-Mailer: iPhone Mail (10B329) From: Garrett Cooper Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree Date: Tue, 7 May 2013 22:39:22 -0700 To: Warner Losh Cc: "Simon J. Gerraty" , "freebsd-toolchain@freebsd.org" , Brooks Davis , "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 05:39:25 -0000 On May 7, 2013, at 10:09 PM, Warner Losh wrote: >=20 > On May 7, 2013, at 9:42 PM, Garrett Cooper wrote: >=20 >> On Tue, May 7, 2013 at 2:26 PM, Garrett Cooper wrote= : >>=20 >> On Tue, May 7, 2013 at 2:00 PM, Warner Losh wrote: >>=20 >> On May 7, 2013, at 2:46 PM, Garrett Cooper wrote: >>=20 >>> On May 7, 2013, at 1:39 PM, Brooks Davis wrote: >>>=20 >>>> On Tue, May 07, 2013 at 01:05:07PM -0700, Garrett Cooper wrote: >>>>> Hi, >>>>> A common pattern that I've seen at Isilon and something else that I'v= e >>>>> wanted to have for a while is the ability to designate where the top o= f a >>>>> source tree was. This is important and helpful when dealing with sourc= e >>>>> files that build upon each other or depend on sources located in other= >>>>> sections of the tree; contrib stuff needs to set .PATH appropriately t= o >>>>> point to sources at the top of the tree, sys stuff is riddled with S=3D= in >>>>> order to point to where /sys, etc lives, we build upon FreeBSD within a= n >>>>> expected directory structure as well. >>>>> I haven't come up with a name, but was wondering if this was a good >>>>> idea, and if so does anyone have any outstanding patches for this that= can >>>>> be pushed into FreeBSD? >>>>=20 >>>> I'd like to see this. There's a variable for this in NetBSD and I've >>>> wanted to do this because it makes code easier to relocate within the >>>> tree. >>>=20 >>> This is another good reason. It would make porting code to/from Net= BSD a LOT easier=81c especially because I plan on pulling a lot of test/test= infrastructure code from NetBSD and I really don't want to commit too many l= ocal changes to the Makefiles. Less divergence -> better cross-pollination -= > less work for all -> win for the BSDs. >>> Thanks for the reminder.. I'll base it off what NetBSD did :). >>=20 >> SRCDIR >>=20 >> EVARINUSE? >>=20 >> share/mk/bsd.doc.mk:# SRCDIR Directory where source files live. [${.C= URDIR}] >> share/mk/bsd.doc.mk:TRFLAGS+=3D -I${SRCDIR} >> share/mk/bsd.doc.mk:.PATH: ${.CURDIR} ${SRCDIR} >> share/mk/bsd.doc.mk: cd ${SRCDIR}; \ >> share/mk/bsd.doc.mk:SRCDIR?=3D ${.CURDIR} >> share/mk/bsd.doc.mk: cd ${SRCDIR}; ${UNROFF} ${MACROS} ${UNROFFFLAGS} \= >> share/mk/bsd.doc.mk: cd ${SRCDIR}; ${UNROFF} -ms ${UNROFFFLAGS} \ >> share/mk/bsd.info.mk:SRCDIR?=3D ${.CURDIR} >> ... >> share/doc/llvm/Makefile:SRCDIR=3D ${.CURDIR}/../../../contrib/llv= m >> share/doc/llvm/Makefile:.PATH: ${SRCDIR} ${SRCDIR}/lib/Support >> share/doc/llvm/clang/Makefile:SRCDIR=3D ${.CURDIR}/../../../../= contrib/llvm/tools/clang >> share/doc/llvm/clang/Makefile:.PATH: ${SRCDIR} >>=20 >> Once upon a time, this *HAD* to be set, and wasn't inferred from the curr= ent top of the tree. Please, for the love of god, make sure that we don't lo= se the infer from top of tree ability, or I will hurt you. Often. Through al= l the minions that owe me minor favors. >>=20 >> I don't want to break that ever; it's a fantastic feature. If you could p= oint me to where that magic awesomeness lives (make?), I'll be more than hap= py to address it in my branch where I'm going to do this. >>=20 >> I really don't like how NetBSD turned their top-level build command into a= shell script [in part because it needs to bootstrap a bunch of tools]. It m= akes things painful when doing iterative builds.. >>=20 >> So all in all, I completely and wholeheartedly agree with your concerns. >>=20 >> Oh sweet.. this is something to keep in mind too (from bsd.port.mk)... >>=20 >> # SRC_BASE - The root of the src tree. (Some ports require this to g= et >> # kernel sources). Default: /usr/src >>=20 >> All else fails, ports has done it first -_-... >>=20 >> Not the first var I've seen this done with... >=20 > I thought ports specifically named things differently to avoid conflicts. Perhaps. It matches autoconf too. It's just a pain when there isn't consiste= ncy, but oh well... Thanks! -Garrett= From owner-freebsd-arch@FreeBSD.ORG Wed May 8 05:47:20 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 06583A35; Wed, 8 May 2013 05:47:20 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by mx1.freebsd.org (Postfix) with ESMTP id 83E73796; Wed, 8 May 2013 05:47:17 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUYnm33E1UeIBfmGKPpNSfFv2pUVLpde8@postini.com; Tue, 07 May 2013 22:47:19 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 7 May 2013 22:41:22 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r485fML77620; Tue, 7 May 2013 22:41:22 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id DCA7258097; Tue, 7 May 2013 22:41:21 -0700 (PDT) To: Warner Losh Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree In-Reply-To: References: <20130507213118.5277F58097@chaos.jnpr.net> Comments: In-reply-to: Warner Losh message dated "Tue, 07 May 2013 21:25:37 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Tue, 7 May 2013 22:41:21 -0700 Message-ID: <20130508054121.DCA7258097@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Cc: Garrett Cooper , freebsd-toolchain@freebsd.org, "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 05:47:20 -0000 On Tue, 7 May 2013 21:25:37 -0600, Warner Losh writes: >where does MAKEOBJDIRPREFIX come into play? I don't normally use it, it is a handy but rather crude implement. I normally use MAKEOBJDIR='${.CURDIR:S,${SRCTOP},${OBJTOP},}' which gives you a similar - but much neater result than MAKEOBJDIRPREFIX. >We do it both ways: on some architectures we have multiple = >MACHINE_ARCHes per MACHINE (like mips and arm) and on others we have one = >MACHINE_ARCH and mutliple machines (like i386 and pc98). Yes, which is why I'm adjusting accordingly. >We currently use ${MACHINE}.${MACHINE_ARCH} for cross builds, which = >works out nicely. For historical reasons that turn out to be = >inconvenient, we don't do this for native builds. >Why is this gratuitously different than the current scheme? Do you mean why not simply use ${MACHINE}.${MACHINE_ARCH} always? Encoding both MACHINE and MACHINE_ARCH always is doable, but I avoid '.' because it prevents being able to use modifiers like :R and :E to separate the directory component from the target machine spec. The projects/bmake branch is about showing how freebsd can be built in meta mode. The tree dependencies are represented as dir.target_spec >would I build a pc98 build with this? And why have it be different for = it would just get pc98 since there's no ambiguity. But as noted above, if you wanted to always be explicit that wouldn't be a problem (assuming '.' is avoided). From owner-freebsd-arch@FreeBSD.ORG Wed May 8 09:34:26 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8EEA1173; Wed, 8 May 2013 09:34:26 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 55ADA142; Wed, 8 May 2013 09:34:26 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 5FDC0D908; Wed, 8 May 2013 09:34:19 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id ECE2435E72; Wed, 8 May 2013 11:34:20 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Pawel Jakub Dawidek Subject: Re: Building library that depends on another library. References: <20130505201436.GJ1374@garage.freebsd.pl> <86r4hkgd04.fsf@nine.des.no> <20130507185005.GB1888@garage.freebsd.pl> Date: Wed, 08 May 2013 11:34:20 +0200 In-Reply-To: <20130507185005.GB1888@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Tue, 7 May 2013 20:50:05 +0200") Message-ID: <86wqr9zug3.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 09:34:26 -0000 Pawel Jakub Dawidek writes: > I came up with something like the following. Instead of: > > DPADD=3D ${LIBNV} > LDADD=3D -lnv > (plus modifying src/Makefile.inc1) > > I only add: > > LDADD=3D -L${.OBJDIR}/../libnv -lnv That breaks the non-world build. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Wed May 8 09:58:35 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8B376A43; Wed, 8 May 2013 09:58:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1062A5; Wed, 8 May 2013 09:58:35 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r489wROI031503; Wed, 8 May 2013 12:58:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r489wROI031503 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r489wRX5031502; Wed, 8 May 2013 12:58:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 8 May 2013 12:58:27 +0300 From: Konstantin Belousov To: John Baldwin Subject: Re: Extending MADV_PROTECT Message-ID: <20130508095827.GK3047@kib.kiev.ua> References: <201305071433.27993.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NeRnyCbrXmug+DvV" Content-Disposition: inline In-Reply-To: <201305071433.27993.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 09:58:35 -0000 --NeRnyCbrXmug+DvV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, May 07, 2013 at 02:33:27PM -0400, John Baldwin wrote: > One of the issues I have with our current MADV_PROTECT is that it > isn't very administrative-friendly. That is, as a sysadmin I can't > easily protect arbitrary processes from the OOM killer. Instead, the > binary has to be changed to invoke madvise(). Furthermore, once the > protection is granted it can't be revoked. Also, any binaries that > want this have to be run as root. Instead, I would like to be able > to both set and revoke this for existing processes and possibly even > allow it to be inherited (so I can tag a top-level daemon that forks > and have all its future children be protected for example). To that > end I've whipped up a simple patch (against 8, but should port to > HEAD easily if folks think it is a good idea) to add a new pprotect() > system call and userland program (protect) that can be used similar to > ktrace(1) either as a modifier when running a new program or as a tool > for setting or clearing protection for existing processes. > > The inherit feature isn't implemented yet, but it should be simple > to do. One would simply need a new flag that PPROT_INHERIT sets that > is checked on fork and propagates P_PROTECTED if it is set. Also, > one other thought I had is that at some point we might want to make > P_PROTECTED more fine-grained, e.g. by allowing for OOM "priorities". > To that end, it may make sense to add a new argument to protect, > though you could also reserve part of the 'op' parameter to encode a > priority. Wouldn't the pprot_setchildren() miss a child for which the new pid and struct proc are already allocated in the do_fork(), but which is not yet linked into the process tree ? If true, I think this does not fulfill the promise of the PPROT_DESCEND. It seems that the patch posted missed the chunk for sys/proc.h. For HEAD, you probably need e.g. p_flag2 and P2_PROTECTED instead. Since the syscall is mean to be extended in the future, would it make more sense to add a multiplexer, e.g. procctl(2), one operation of which would be PROCCTL_PROTECT ? --NeRnyCbrXmug+DvV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRiiHCAAoJEJDCuSvBvK1BULQQAKEe9JA9Ypl2ovMbLPqMU99k K4/zwadyQdjvTx2PBX7LL/mgcE6TkswR/WCqPqZMkxpA01zeQbK9U1MQ8juNCTS3 f6hYtQiB9IlMii/y1DJN0ho1hE+wLhB3oJNi+s/0vf7IoxFfXoZpy0TBOLeH8lRN c9bXSfxw+26+koWbc+YuvcNV9dwbuhp8LYW3fed/33b2b0viEXdfFy0UAVdFMDgW DfZKy6LDKxv7WNbTx60hWX5GyJaIERDUvmfiPn4rMnS1ddbYZIZi4t221PVshAzE wdV4zO4iJbl2ejtipzv4fsTe9YhOFeHqZ4khCBDySD/6GM/hLEeTEJKwLAlq4cNJ pXDfg6rvxLJQFkqkVbbhq+BtgR4Ub+8kZvjZY72fDWr16BTivMXkherXyhQkY/2B EbrEl2FVJwmvILEEHJhVyHaOyyKflP9JZ0j4HPWRd+2IAUXprRd3zJTuEZi+4XVG AlrTtnOt4gx5KHj/RtU5zVvmuvqtc5vWlocdonDK88nc8E8GO1Ydu4HGSglZTv30 kpnHIEoVXFFC7/c88d/D/WoOTS3oJzkKQzBMSsQICrnkm2dcG/GomgJm0RhhKvFR AQwF52xSa1O++UMhUZLP0WmJqRzjFclIMOS1qyrgJ0Xys14fbnSDjVSG/omLm35h LmQ8v8+o4e/niFBWk45r =BPTh -----END PGP SIGNATURE----- --NeRnyCbrXmug+DvV-- From owner-freebsd-arch@FreeBSD.ORG Wed May 8 13:06:09 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A05BA1FB for ; Wed, 8 May 2013 13:06:09 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 6C542DFC for ; Wed, 8 May 2013 13:06:08 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 5B003C50; Wed, 8 May 2013 15:02:05 +0200 (CEST) Date: Wed, 8 May 2013 15:08:31 +0200 From: Pawel Jakub Dawidek To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Subject: Re: Building library that depends on another library. Message-ID: <20130508130831.GA1417@garage.freebsd.pl> References: <20130505201436.GJ1374@garage.freebsd.pl> <86r4hkgd04.fsf@nine.des.no> <20130507185005.GB1888@garage.freebsd.pl> <86wqr9zug3.fsf@nine.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: <86wqr9zug3.fsf@nine.des.no> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 13:06:09 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 08, 2013 at 11:34:20AM +0200, Dag-Erling Sm=F8rgrav wrote: > Pawel Jakub Dawidek writes: > > I came up with something like the following. Instead of: > > > > DPADD=3D ${LIBNV} > > LDADD=3D -lnv > > (plus modifying src/Makefile.inc1) > > > > I only add: > > > > LDADD=3D -L${.OBJDIR}/../libnv -lnv >=20 > That breaks the non-world build. Could you provide example? Do you mean building individual libraries =66rom 'make buildenv' shell? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlGKTk8ACgkQForvXbEpPzQ7DQCgvgBvi9sMofe1mPNDIxMwnfwJ ly4An1f70Qopvq21O0bCUrAuWlAdbP8N =WmrN -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- From owner-freebsd-arch@FreeBSD.ORG Wed May 8 14:42:48 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 80687838 for ; Wed, 8 May 2013 14:42:48 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id 4EE2A2C8 for ; Wed, 8 May 2013 14:42:48 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id u16so3408580iet.28 for ; Wed, 08 May 2013 07:42:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=GCJ1H6kmge+EXXGWw5TZ6hKyC5+SZoGsQQDIBoBgjZM=; b=jQzxgIXEOPec9ced3Y4mtnEFEntTyk5DWpSFIq7pLFqWtrWX11+RMzobE9o3NLBT3q rpwZxQJc/2zmf/md1SdJtobt2FVvLhpw4pJE+ZOAC6HQl9oAITn41DY1fk80Qkj9XNAI 2BPkBRN3Qi2QUB+/qtnEGoNIrnbOO+6cPQwB4pLTF/pPTU6qXzSGtpHVRKsxTyJFbiCk GJPCVWqiZFCJhTGzRls55aoSOJpSBfJ4WifBJv3j6qr/AqdCM3cSIDQd/+bAZygLAB3g zpWe85pWVvWhbcKFMYWojf5wq7vfPdkdvTNIA14zMFIC87tc2LcajSgHmvTCH6U0NkEW N/2Q== X-Received: by 10.50.109.166 with SMTP id ht6mr5904697igb.26.1368024167954; Wed, 08 May 2013 07:42:47 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id j7sm882718igt.1.2013.05.08.07.42.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 07:42:47 -0700 (PDT) Sender: Warner Losh Subject: Re: Building library that depends on another library. Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Warner Losh In-Reply-To: <20130508130831.GA1417@garage.freebsd.pl> Date: Wed, 8 May 2013 08:42:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130505201436.GJ1374@garage.freebsd.pl> <86r4hkgd04.fsf@nine.des.no> <20130507185005.GB1888@garage.freebsd.pl> <86wqr9zug3.fsf@nine.des.no> <20130508130831.GA1417@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkMv6HUGUfvULzXrkmoMglqAb3bGoRWrmz0tQdj4oPJFrgudxY2u+dcgZ1wUzRM3obJ9W9E Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 14:42:48 -0000 On May 8, 2013, at 7:08 AM, Pawel Jakub Dawidek wrote: > On Wed, May 08, 2013 at 11:34:20AM +0200, Dag-Erling Sm=F8rgrav wrote: >> Pawel Jakub Dawidek writes: >>> I came up with something like the following. Instead of: >>>=20 >>> DPADD=3D ${LIBNV} >>> LDADD=3D -lnv >>> (plus modifying src/Makefile.inc1) >>>=20 >>> I only add: >>>=20 >>> LDADD=3D -L${.OBJDIR}/../libnv -lnv >>=20 >> That breaks the non-world build. >=20 > Could you provide example? Do you mean building individual libraries > from 'make buildenv' shell? It won't relink the library if libnv is changed too. Warner From owner-freebsd-arch@FreeBSD.ORG Wed May 8 16:26:45 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2A72CABF; Wed, 8 May 2013 16:26:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0798AD9C; Wed, 8 May 2013 16:26:45 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 689E1B960; Wed, 8 May 2013 12:26:44 -0400 (EDT) From: John Baldwin To: Adrian Chadd Subject: Re: Extending MADV_PROTECT Date: Wed, 8 May 2013 12:05:20 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201305071433.27993.jhb@freebsd.org> <201305071539.24900.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201305081205.20910.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 May 2013 12:26:44 -0400 (EDT) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 16:26:45 -0000 On Tuesday, May 07, 2013 5:29:30 pm Adrian Chadd wrote: > On 7 May 2013 12:39, John Baldwin wrote: > > > Well, only root can do it. Even now MADV_PROTECT is a similar foot shooting > > device (though not quite as easy to do). You can also get yourself into a heap > > of trouble with other things like rtprio, etc., so I sort of think that is up to > > the user/administrator to manage. I do think that the more fine-grained priority > > approach may be a good way to mitigate that if it really becomes an issue at some > > point. > > This is the kind of thing that begs for a capability. And I'm > surprised Robert hasn't chimed in and said just that. There is an existing PRIV_* already that this still respects. > However, I think we still lack the ability to do useful capability > work from user-space. God I'd like to be wrong on this one. You should talk to Robert. I think you can write a MAC module that hooks into priv_check() and can establish arbitrary rules for granting privileges. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed May 8 16:26:46 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 35A1BAC4 for ; Wed, 8 May 2013 16:26:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0EAE9D9E for ; Wed, 8 May 2013 16:26:46 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6A57BB917; Wed, 8 May 2013 12:26:45 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Subject: Re: Extending MADV_PROTECT Date: Wed, 8 May 2013 12:09:49 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201305071433.27993.jhb@freebsd.org> <20130508095827.GK3047@kib.kiev.ua> In-Reply-To: <20130508095827.GK3047@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201305081209.49429.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 May 2013 12:26:45 -0400 (EDT) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 16:26:46 -0000 On Wednesday, May 08, 2013 5:58:27 am Konstantin Belousov wrote: > On Tue, May 07, 2013 at 02:33:27PM -0400, John Baldwin wrote: > > One of the issues I have with our current MADV_PROTECT is that it > > isn't very administrative-friendly. That is, as a sysadmin I can't > > easily protect arbitrary processes from the OOM killer. Instead, the > > binary has to be changed to invoke madvise(). Furthermore, once the > > protection is granted it can't be revoked. Also, any binaries that > > want this have to be run as root. Instead, I would like to be able > > to both set and revoke this for existing processes and possibly even > > allow it to be inherited (so I can tag a top-level daemon that forks > > and have all its future children be protected for example). To that > > end I've whipped up a simple patch (against 8, but should port to > > HEAD easily if folks think it is a good idea) to add a new pprotect() > > system call and userland program (protect) that can be used similar to > > ktrace(1) either as a modifier when running a new program or as a tool > > for setting or clearing protection for existing processes. > > > > The inherit feature isn't implemented yet, but it should be simple > > to do. One would simply need a new flag that PPROT_INHERIT sets that > > is checked on fork and propagates P_PROTECTED if it is set. Also, > > one other thought I had is that at some point we might want to make > > P_PROTECTED more fine-grained, e.g. by allowing for OOM "priorities". > > To that end, it may make sense to add a new argument to protect, > > though you could also reserve part of the 'op' parameter to encode a > > priority. > > Wouldn't the pprot_setchildren() miss a child for which the new pid and > struct proc are already allocated in the do_fork(), but which is not yet > linked into the process tree ? If true, I think this does not > fulfill the promise of the PPROT_DESCEND. ktrace has the same issue, and really, this is just a race. If the user had run the command a few nanoseconds earlier the proc wouldn't be allocated at all, and I doubt a user would notice the difference in those two cases. If you are doing this programmatically then that is a race that the program can handle. It isn't any different from having a new process begin its fork() a few nanoseconds after this returns either. This is why if you want that behavior you would use -di (and applies equally to ktrace). > It seems that the patch posted missed the chunk for sys/proc.h. > For HEAD, you probably need e.g. p_flag2 and P2_PROTECTED instead. P_PROTECTED already exists on both HEAD and 8.x (the MADV_PROTECT it is extending is quite old). What we would need a p_flag2 for would be to add a new P_PROTECTED_INHERIT if we decided we wanted to support that. > Since the syscall is mean to be extended in the future, would it make > more sense to add a multiplexer, e.g. procctl(2), one operation of which > would be PROCCTL_PROTECT ? Do we expect it to do more than adjust protection? We already have a few other process-control system calls (e.g. ptrace()). It's hard to ensure it is sufficiently generic when only abstracting from one use case. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed May 8 21:49:23 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BEC82D4A for ; Wed, 8 May 2013 21:49:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by mx1.freebsd.org (Postfix) with ESMTP id 7DC23F1A for ; Wed, 8 May 2013 21:49:23 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id m16so2159683vca.2 for ; Wed, 08 May 2013 14:49:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=YCU817UR/UuUTScGScD/DjFfy08hdlHgttd/1y9LJgk=; b=bM2uZNB3Nv7PWW4PQUpwzo2aotapALgiwK3XUKqW5u8aPW9pKb2V+ILf8hTWQ7xzWO kLW+DD/8RbU810DQISxjkcdwYc/y7Xt918BEwR/782wqMLfxycwk6pv69MgBZWf/AOpw D+Aq63YkWHC5H96LOdFXgGBHp7/49cKOseB9u3EkST5FFOhRFQJwahX15byNEHtSzIsi HQs6f6vQBopok6hj3aRZNECEcuDdzgnk4G9TPS7tJkJ9eR/Pz2JZaMMNYKjj9GmfCONC GTzPI695BsbL9MqWW4xx0Qa+0XMlyhY/4g1NR4zrNpxA5wz2GNqxkepHJcAb5y08M1WK Qdmg== X-Received: by 10.220.103.138 with SMTP id k10mr5578432vco.74.1368049756770; Wed, 08 May 2013 14:49:16 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id xe6sm613137vec.6.2013.05.08.14.49.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 14:49:15 -0700 (PDT) Sender: Warner Losh Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130508054121.DCA7258097@chaos.jnpr.net> Date: Wed, 8 May 2013 15:49:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9CD1CE3E-C17C-4C63-BA03-190531185D7A@bsdimp.com> References: <20130507213118.5277F58097@chaos.jnpr.net> <20130508054121.DCA7258097@chaos.jnpr.net> To: Simon J. Gerraty X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkJfXr1BAjq7UNlTB5Iz4uoh7USTw5X1HmdxO6l6ASVzrDHhLU6/ACRtZzL9JnRpG2Z5Quo Cc: Garrett Cooper , freebsd-toolchain@freebsd.org, "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 21:49:23 -0000 On May 7, 2013, at 11:41 PM, Simon J. Gerraty wrote: >=20 > On Tue, 7 May 2013 21:25:37 -0600, Warner Losh writes: >> where does MAKEOBJDIRPREFIX come into play? >=20 > I don't normally use it, it is a handy but rather crude implement. > I normally use=20 >=20 > MAKEOBJDIR=3D'${.CURDIR:S,${SRCTOP},${OBJTOP},}' >=20 > which gives you a similar - but much neater result than > MAKEOBJDIRPREFIX. Isn't that backwards. MAKEOBJDIRPREFIX in today's FreeBSD is much more = like OBJTOP than what you've quoted here. That's how I set the top of = the tree today, usually with a 'setenv MAKEOBJDIRPREFIX $HOME/obj' in my = .cshrc so it is always active. That way I can just buildworld or = buildkernel without having to worry where things will wind up, or having = problems with /usr/obj being unwritable... I know this trick doesn't = work for netbsd's make (or didn't years ago when I was building it on a = regular basis), so I assume it is FreeBSD make centric. >> We do it both ways: on some architectures we have multiple =3D >> MACHINE_ARCHes per MACHINE (like mips and arm) and on others we have = one =3D >> MACHINE_ARCH and mutliple machines (like i386 and pc98). >=20 > Yes, which is why I'm adjusting accordingly. >=20 >> We currently use ${MACHINE}.${MACHINE_ARCH} for cross builds, which =3D= >> works out nicely. For historical reasons that turn out to be =3D >> inconvenient, we don't do this for native builds. >=20 >> Why is this gratuitously different than the current scheme?=20 >=20 > Do you mean why not simply use ${MACHINE}.${MACHINE_ARCH} always? > Encoding both MACHINE and MACHINE_ARCH always is doable, but I avoid = '.' > because it prevents being able to use modifiers like :R and :E > to separate the directory component from the target machine spec. The project currently uses dots without issue. Not quite sure why you'd = need to generate things that way. Sure it sounds useful, but it seems = rather a backwards way to work out MACHINE and MACHINE_ARCH (or I'm = misunderstanding what you are saying). > The projects/bmake branch is about showing how freebsd can be built in > meta mode. The tree dependencies are represented as dir.target_spec >=20 >> would I build a pc98 build with this? And why have it be different = for =3D >=20 > it would just get pc98 since there's no ambiguity. > But as noted above, if you wanted to always be explicit that wouldn't = be > a problem (assuming '.' is avoided). >=20 From owner-freebsd-arch@FreeBSD.ORG Wed May 8 23:01:33 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 81120289; Wed, 8 May 2013 23:01:33 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by mx1.freebsd.org (Postfix) with ESMTP id 19D111CC; Wed, 8 May 2013 23:01:30 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUYrZSlgTrgeHWUWN4bxmccz3Iv9a+Jyz@postini.com; Wed, 08 May 2013 16:01:33 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 8 May 2013 15:53:03 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r48Mr3L23585; Wed, 8 May 2013 15:53:03 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id DF7AE58097; Wed, 8 May 2013 15:53:02 -0700 (PDT) To: Warner Losh Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree In-Reply-To: <9CD1CE3E-C17C-4C63-BA03-190531185D7A@bsdimp.com> References: <20130507213118.5277F58097@chaos.jnpr.net> <20130508054121.DCA7258097@chaos.jnpr.net> <9CD1CE3E-C17C-4C63-BA03-190531185D7A@bsdimp.com> Comments: In-reply-to: Warner Losh message dated "Wed, 08 May 2013 15:49:12 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Wed, 8 May 2013 15:53:02 -0700 Message-ID: <20130508225302.DF7AE58097@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Cc: Garrett Cooper , freebsd-toolchain@freebsd.org, "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 23:01:33 -0000 On Wed, 8 May 2013 15:49:12 -0600, Warner Losh writes: >> MAKEOBJDIR=3D'${.CURDIR:S,${SRCTOP},${OBJTOP},}' >>=20 >> which gives you a similar - but much neater result than >> MAKEOBJDIRPREFIX. > >Isn't that backwards. MAKEOBJDIRPREFIX in today's FreeBSD is much more = >like OBJTOP than what you've quoted here. That's how I set the top of = No. MAKEOBJDIRPREFIX gives you an objdir by simply doing ${MAKEOBJDIRPREFIX}${.CURDIR} this is very quick and handy, but the paths can be very long and ugly if you happen to be on automounted nfs. For the sake of discussion assume I am in /.amd/server/b/sjg/work/FreeBSD/current/src/bin/cat MAKEOBJDIRPREFIX=/var/obj/current/$MACHINE make -V .OBJDIR /var/obj/current/amd64/.amd/server/b/sjg/work/FreeBSD/current/src/bin/cat MAKEOBJDIR='${.CURDIR:S,${SRCTOP},${OBJTOP},}' make -V .OBJDIR /var/obj/current/amd64/bin/cat (assuming of course that OBJTOP='${OBJROOT}${MACHINE}' as previously mentioned). The ability to do the above is something I added to NetBSD's make ages ago because we found that MAKEOBJDIRPREFIX resulted in pathnames that were blowing the command line limits on FreeBSD 2.x >the tree today, usually with a 'setenv MAKEOBJDIRPREFIX $HOME/obj' in my = >.cshrc so it is always active. That way I can just buildworld or = Yes, MAKEOBJDIRPREFIX is certainly very handy - and I use it for quick & dirty builds and of course for buildworld and such. >problems with /usr/obj being unwritable... I know this trick doesn't = >work for netbsd's make (or didn't years ago when I was building it on a = What trick? MAKEOBJDIRPREFIX has always worked as you describe. Don't confuse limitations imposed by makefiles as being limitations of the tool ;-) >The project currently uses dots without issue. Not quite sure why you'd = The project doesn't currently do anything close to what dirdeps.mk allows. From owner-freebsd-arch@FreeBSD.ORG Thu May 9 05:13:39 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E4A998DF; Thu, 9 May 2013 05:13:39 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by mx1.freebsd.org (Postfix) with ESMTP id A49841D93; Thu, 9 May 2013 05:13:39 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUYswg0wwq4joRc0PhASxdYIEe6Mk3MsU@postini.com; Wed, 08 May 2013 22:13:39 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 8 May 2013 21:58:34 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r494wYL13752; Wed, 8 May 2013 21:58:34 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 2E67058097; Wed, 8 May 2013 21:58:34 -0700 (PDT) To: Warner Losh Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree In-Reply-To: <9CD1CE3E-C17C-4C63-BA03-190531185D7A@bsdimp.com> References: <20130507213118.5277F58097@chaos.jnpr.net> <20130508054121.DCA7258097@chaos.jnpr.net> <9CD1CE3E-C17C-4C63-BA03-190531185D7A@bsdimp.com> Comments: In-reply-to: Warner Losh message dated "Wed, 08 May 2013 15:49:12 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Wed, 8 May 2013 21:58:34 -0700 Message-ID: <20130509045834.2E67058097@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Cc: Garrett Cooper , freebsd-toolchain@freebsd.org, "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 05:13:40 -0000 >> Do you mean why not simply use ${MACHINE}.${MACHINE_ARCH} always? >> Encoding both MACHINE and MACHINE_ARCH always is doable, but I avoid = >'.' Actually I only avoid '.' in the captured dirdeps. So ${MACHINE}.${MACHINE_ARCH} in objdir may be ok - will take a look. Dealing with ${MACHINE}.${MACHINE_ARCH} is actually easy it just gets stripped from the captured dirdeps, it is references to other machine and arch's that need to be captured but cannot be dealt with as neatly. The vast majority of such cases though are for pseudo machines like "host" and "common" (for generated files which are machine independent) where the issue shouldn't arise anyway. From owner-freebsd-arch@FreeBSD.ORG Thu May 9 08:25:43 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8AB9B6BD; Thu, 9 May 2013 08:25:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id F37D7854; Thu, 9 May 2013 08:25:42 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r498PcLE024000; Thu, 9 May 2013 11:25:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r498PcLE024000 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r498PcM0023999; Thu, 9 May 2013 11:25:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 May 2013 11:25:38 +0300 From: Konstantin Belousov To: John Baldwin Subject: Re: Extending MADV_PROTECT Message-ID: <20130509082538.GQ3047@kib.kiev.ua> References: <201305071433.27993.jhb@freebsd.org> <20130508095827.GK3047@kib.kiev.ua> <201305081209.49429.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cw81t83UHTonwpSu" Content-Disposition: inline In-Reply-To: <201305081209.49429.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 08:25:43 -0000 --cw81t83UHTonwpSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 08, 2013 at 12:09:49PM -0400, John Baldwin wrote: > On Wednesday, May 08, 2013 5:58:27 am Konstantin Belousov wrote: > > On Tue, May 07, 2013 at 02:33:27PM -0400, John Baldwin wrote: > > > One of the issues I have with our current MADV_PROTECT is that it > > > isn't very administrative-friendly. That is, as a sysadmin I can't > > > easily protect arbitrary processes from the OOM killer. Instead, the > > > binary has to be changed to invoke madvise(). Furthermore, once the > > > protection is granted it can't be revoked. Also, any binaries that > > > want this have to be run as root. Instead, I would like to be able > > > to both set and revoke this for existing processes and possibly even > > > allow it to be inherited (so I can tag a top-level daemon that forks > > > and have all its future children be protected for example). To that > > > end I've whipped up a simple patch (against 8, but should port to > > > HEAD easily if folks think it is a good idea) to add a new pprotect() > > > system call and userland program (protect) that can be used similar to > > > ktrace(1) either as a modifier when running a new program or as a tool > > > for setting or clearing protection for existing processes. > > > > > > The inherit feature isn't implemented yet, but it should be simple > > > to do. One would simply need a new flag that PPROT_INHERIT sets that > > > is checked on fork and propagates P_PROTECTED if it is set. Also, > > > one other thought I had is that at some point we might want to make > > > P_PROTECTED more fine-grained, e.g. by allowing for OOM "priorities". > > > To that end, it may make sense to add a new argument to protect, > > > though you could also reserve part of the 'op' parameter to encode a > > > priority. > >=20 > > Wouldn't the pprot_setchildren() miss a child for which the new pid and > > struct proc are already allocated in the do_fork(), but which is not yet > > linked into the process tree ? If true, I think this does not > > fulfill the promise of the PPROT_DESCEND. >=20 > ktrace has the same issue, and really, this is just a race. If the user > had run the command a few nanoseconds earlier the proc wouldn't be alloca= ted > at all, and I doubt a user would notice the difference in those two cases. > If you are doing this programmatically then that is a race that the progr= am > can handle. It isn't any different from having a new process begin its > fork() a few nanoseconds after this returns either. This is why if you > want that behavior you would use -di (and applies equally to ktrace). So to get this correct, a person first should enable inheritance, and only then turn on the protection on the subtree ? This sounds somewhat sloppy, but fine. >=20 > > It seems that the patch posted missed the chunk for sys/proc.h. > > For HEAD, you probably need e.g. p_flag2 and P2_PROTECTED instead. >=20 > P_PROTECTED already exists on both HEAD and 8.x (the MADV_PROTECT it is > extending is quite old). What we would need a p_flag2 for would be to > add a new P_PROTECTED_INHERIT if we decided we wanted to support that. >=20 > > Since the syscall is mean to be extended in the future, would it make > > more sense to add a multiplexer, e.g. procctl(2), one operation of which > > would be PROCCTL_PROTECT ? >=20 > Do we expect it to do more than adjust protection? We already have a few > other process-control system calls (e.g. ptrace()). It's hard to ensure > it is sufficiently generic when only abstracting from one use case. You mentioned a priority, and I think ability to pass a structure to the sub-function of the syscall is better then carving bits in the int argument, or introducing a new syscall. --cw81t83UHTonwpSu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRi12BAAoJEJDCuSvBvK1B2tsQAKgeRYX3QS2qPKjCNSmXpHJS ZueorZhQus7sbHU5gj4ur3Q0dC2KxH6/Zg7HeVBYnIZ7Re02RNifTENoUOfY3h6D WGrdCubKBh0ME/QlLfdQ4GGX86JmzG7UOAvgAAH267h9T8Ly7tQexEPTIZwxRwcj MYJdSPWS6D4EIfHxdT/Ao8ZMZ5eF3MLYwpTPBiALEj/Dm8xA7xLEGshJdKCVhDtY jbTh61LeGuNKyZXoVuR2S25vwxac5RSLrZhlxiKNRsy6XuAJLzM7EIDZHfQ50n+K xPSTIXZ9bMVMn8CYuGv11Xi6lLX2ipb5cGh7aGXtvRjF7ii3x0CrwuWL2FPKmJof W7Hro4U2hJaOFtks566RPzcfNPfEfjonuhJGwJSCXV1zSESHCYulVAKGJb8KJ7wj K5kj2DeBfm+bp23iCEFUEnabfXCJibYrbFh9mRuMYbQTJIK4XM7k4Rmkh7Iu2QqM XhPvFFSU0wBWoBbzc26Ngkr/OLjQgTktj6oS/nqKN47fc9RLOORCszefJwGJ2JXd VczjAQSP7jJB4qkeHrgNK0ZVUzt6HDArRnNK8DIltZDLZFiVwoxLkg9UvRpHsJma Gp0OkqpIj8sOquSoIdZ6GA4tsQzE4d4//A3444JtX6hpKdkjBRedGO2ai+Gk1MR5 wXJgyd5AwstbbgGNJ2X5 =pKFU -----END PGP SIGNATURE----- --cw81t83UHTonwpSu-- From owner-freebsd-arch@FreeBSD.ORG Thu May 9 12:16:31 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 38EBE165 for ; Thu, 9 May 2013 12:16:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0BAE32C1 for ; Thu, 9 May 2013 12:16:31 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 61D3BB953; Thu, 9 May 2013 08:16:30 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Subject: Re: Extending MADV_PROTECT Date: Thu, 9 May 2013 08:14:52 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201305071433.27993.jhb@freebsd.org> <201305081209.49429.jhb@freebsd.org> <20130509082538.GQ3047@kib.kiev.ua> In-Reply-To: <20130509082538.GQ3047@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201305090814.52166.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 09 May 2013 08:16:30 -0400 (EDT) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 12:16:31 -0000 On Thursday, May 09, 2013 4:25:38 am Konstantin Belousov wrote: > On Wed, May 08, 2013 at 12:09:49PM -0400, John Baldwin wrote: > > On Wednesday, May 08, 2013 5:58:27 am Konstantin Belousov wrote: > > > On Tue, May 07, 2013 at 02:33:27PM -0400, John Baldwin wrote: > > > > One of the issues I have with our current MADV_PROTECT is that it > > > > isn't very administrative-friendly. That is, as a sysadmin I can't > > > > easily protect arbitrary processes from the OOM killer. Instead, the > > > > binary has to be changed to invoke madvise(). Furthermore, once the > > > > protection is granted it can't be revoked. Also, any binaries that > > > > want this have to be run as root. Instead, I would like to be able > > > > to both set and revoke this for existing processes and possibly even > > > > allow it to be inherited (so I can tag a top-level daemon that forks > > > > and have all its future children be protected for example). To that > > > > end I've whipped up a simple patch (against 8, but should port to > > > > HEAD easily if folks think it is a good idea) to add a new pprotect() > > > > system call and userland program (protect) that can be used similar to > > > > ktrace(1) either as a modifier when running a new program or as a tool > > > > for setting or clearing protection for existing processes. > > > > > > > > The inherit feature isn't implemented yet, but it should be simple > > > > to do. One would simply need a new flag that PPROT_INHERIT sets that > > > > is checked on fork and propagates P_PROTECTED if it is set. Also, > > > > one other thought I had is that at some point we might want to make > > > > P_PROTECTED more fine-grained, e.g. by allowing for OOM "priorities". > > > > To that end, it may make sense to add a new argument to protect, > > > > though you could also reserve part of the 'op' parameter to encode a > > > > priority. > > > > > > Wouldn't the pprot_setchildren() miss a child for which the new pid and > > > struct proc are already allocated in the do_fork(), but which is not yet > > > linked into the process tree ? If true, I think this does not > > > fulfill the promise of the PPROT_DESCEND. > > > > ktrace has the same issue, and really, this is just a race. If the user > > had run the command a few nanoseconds earlier the proc wouldn't be allocated > > at all, and I doubt a user would notice the difference in those two cases. > > If you are doing this programmatically then that is a race that the program > > can handle. It isn't any different from having a new process begin its > > fork() a few nanoseconds after this returns either. This is why if you > > want that behavior you would use -di (and applies equally to ktrace). > So to get this correct, a person first should enable inheritance, and only > then turn on the protection on the subtree ? This sounds somewhat sloppy, > but fine. Yes, ktrace works the same way. In practice however, if you know your process isn't actively forking (e.g. a daemon that forks a child at startup but then doesn't fork again), you can use -d just fine. > > > Since the syscall is mean to be extended in the future, would it make > > > more sense to add a multiplexer, e.g. procctl(2), one operation of which > > > would be PROCCTL_PROTECT ? > > > > Do we expect it to do more than adjust protection? We already have a few > > other process-control system calls (e.g. ptrace()). It's hard to ensure > > it is sufficiently generic when only abstracting from one use case. > > You mentioned a priority, and I think ability to pass a structure to the > sub-function of the syscall is better then carving bits in the int argument, > or introducing a new syscall. I think the priority would still be a pprotect operation. In some ways it would be nice to be able to do ioctls on processes and maybe this could be structured similarly? int procctl(int pid, unsigned long cmd, ...) (So it's basically ioctl but with the 'fd' replaced with 'pid'. This would also mean that in the future with Robert's pdfork() you could perhaps have ioctl on a process fd just foward the request to procctl). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu May 9 12:31:51 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5C3D9873; Thu, 9 May 2013 12:31:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id C9CDC3C7; Thu, 9 May 2013 12:31:50 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r49CVl1E074095; Thu, 9 May 2013 15:31:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r49CVl1E074095 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r49CVlAp074094; Thu, 9 May 2013 15:31:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 May 2013 15:31:47 +0300 From: Konstantin Belousov To: John Baldwin Subject: Re: Extending MADV_PROTECT Message-ID: <20130509123147.GT3047@kib.kiev.ua> References: <201305071433.27993.jhb@freebsd.org> <201305081209.49429.jhb@freebsd.org> <20130509082538.GQ3047@kib.kiev.ua> <201305090814.52166.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="quHH9trqkXa1YO4R" Content-Disposition: inline In-Reply-To: <201305090814.52166.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 12:31:51 -0000 --quHH9trqkXa1YO4R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 09, 2013 at 08:14:52AM -0400, John Baldwin wrote: > > You mentioned a priority, and I think ability to pass a structure to the > > sub-function of the syscall is better then carving bits in the int argu= ment, > > or introducing a new syscall. >=20 > I think the priority would still be a pprotect operation. In some ways i= t would > be nice to be able to do ioctls on processes and maybe this could be stru= ctured > similarly? >=20 > int procctl(int pid, unsigned long cmd, ...) >=20 > (So it's basically ioctl but with the 'fd' replaced with 'pid'. This wou= ld also > mean that in the future with Robert's pdfork() you could perhaps have ioc= tl on > a process fd just foward the request to procctl). Yes, this is exactly what I mean. --quHH9trqkXa1YO4R Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRi5cyAAoJEJDCuSvBvK1BQpoP/Rc2ohWJqqLGUmVelsS0tWAs SkXFMb3OHtoHBaNpWsdMgwFRlcGd5kI13KHTUNemqpx7iQC7oIbAFBvHcLL67bCL TWF8w6gYKAFxcCjFwLDhjU4nPR/FJu0CYEjDKh+gpoHDpdVXLcTDKyNSgwr/dFqK VUaaK6DfQVQPyoN/45u+iawDuHtjfMsnXpwMAP2goTcehI/oghTMjbgvVE3tNhrN MJcduwE4j5aLuGW8vKBxgtIn7v6lXMwjtdPs1QBHX3YTps6uy28kb71mzp+XpzDi 0o7xHwWI0g5ceuflM9vMFq0zWu88ychz2v+/EyMckTPGdGSj7tw4eOAxHZwop3RI TL7o3HFMcRmolrhRUq0NAAQWplNYXjufUc4yi9voUYdAlH4V91zuuoCS/zzvuzGd kRLBy/KVl9zZu9iDQo1Br7w7QXSFgpx7LhqOonNAp57OPsyXQ/QtsLrKbZJVkrY6 8uwq1O1eKQdJc8Bipa/Et4dvXbBX+vfZYAN6Pmdpt2XJwMvmh9VmhfPn5/Hnm0NC 70mvUTTO8Sr7y9nYWGkb1HGQYye7p5AMPWysDy5Vzka9RmLRWjG2y/V/ID6M4XGS +QnieKdKjtkxjbscUtJGxvn4lsB503w0Uv1VdJAwKxQ/19dfovHcxsz5pml6XTWY 87ZP/a0XQSNKQDbgirlN =Vy/V -----END PGP SIGNATURE----- --quHH9trqkXa1YO4R-- From owner-freebsd-arch@FreeBSD.ORG Fri May 10 03:39:27 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CAAA3B53 for ; Fri, 10 May 2013 03:39:27 +0000 (UTC) (envelope-from contact@ijtemt.org) Received: from Host1.yourdomainname.com (50.22.181.244-static.reverse.softlayer.com [50.22.181.244]) by mx1.freebsd.org (Postfix) with ESMTP id B07A5915 for ; Fri, 10 May 2013 03:39:27 +0000 (UTC) X-Sender: "Editor IJTEMT" X-Receiver: freebsd-arch@freebsd.org From: "Editor IJTEMT" To: freebsd-arch@freebsd.org Date: 9 May 2013 20:37:33 -0700 Subject: Call for Papers IJTEMT. Kindly impart in your University/Organization/College/Colleagues/Academia/Circle. Priority: normal Importance: High Message-Id: <20130510033927.CAAA3B53@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Editor IJTEMT List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 03:39:27 -0000 INTERNATIONAL JOURNAL OF TRENDS IN ECONOMICS MANAGEMENT & TECHNOLOGY IJTEMT invites you to submit your research paper for publishing in Volume II, Issue II ( June 2013). CALL FOR PAPERS VOLUME II, ISSUE II www.ijtemt.org About IJTEMT International Journal of Trends in Economics Management and Technology (IJTEMT) in an International Academic Journal e-published bimonthly in India and open to the world. In this present interdisciplinary era, here at IJTEMT, a group of intellectual came together to find a common platform for three major components of any economy i.e., Economics, Management and Technology. Here we provide a forum to bridge the gap between the brushed-up professional in their respective fields and the new researcher which will results in better understanding and fruitful outcomes. The focus of this journal is to publish paper on economics management and technology. Submitted papers are reviewed by a full double blind manner by the technical committee of the journal. The audience for the journal is professionals from related fields, academicians and new students & research scholars. All submitted articles should report original, previously unpublished research results, experimental or theoretical, and will be peer-reviewed. Articles submitted to the journal should meet these criteria and must not be under consideration for publication elsewhere. Manuscripts should follow the style of the journal and are subject to both review and editing. Why Select IJTEMT Journal IJTEMT Provides E-Certificates to Author's if Needed.IJTEMT is Globally Approved International Journal having Strong Editorial Board. This is Online Open Journal .Author's can Download Paper from Library of Journal at any Time from Anywhere.IJTEMT is a Association of Eminent Scientist, Researchers and Experienced Members of More than 20 Countries.IJTEMT Publishes High Quality Papers which are Peer Reviewed by International/National Reviewers. Author's Query can be solved within 18 Hours. Subject Category: ECONOMICS, MANAGEMENT & TECHNOLOGY. Important Dates: Paper Submission: 15th May 2013 Review Results (Acceptance/Rejection) Notification: Within two weeks after submitting manuscript. Guidelines for submission and Review Process: IJTEMT welcomes author submission of papers concerning any branch of the economics, management and technology and their applications in business, industry and other subjects relevant. The review process goes through following phases which can take time from ten days to two months: a.. Each manuscript will be initially evaluated by the editorial board / editor, who may make use of appropriate software to examine the originality of the contents of the manuscript. b. The manuscripts passed through screening at above noted level will be forwarded to two referees for blind peer review, each of whom will make a recommendation to publish the article in its present form/edit/reject. During this period referees shall treat the contents of papers under review as privileged information. c. The reviewers' recommendations determine whether a paper will be accepted / accepted subject to change / subject to resubmission with significant changes / rejected. d. For papers which require changes, the same reviewers will be used to ensure that the quality of the revised paper is acceptable. e. All papers are refereed, and the Editor-in-Chief reserves the right to refuse any typescript, whether on invitation or otherwise, and to make suggestions and/or modifications before publication. Submission of Paper will takes place in two phases: a. Initial Paper Submission: Prospective author (s) is/are encouraged to submit their manuscript including charts, tables, figures and appendixes in ..pdf and .doc (both) format to e-mail: [1]submit@ijtemt.org. All submitted articles should report original, previously unpublished research results, experimental or theoretical. Articles submitted to the IJIMT should meet these criteria and must not be under consideration for publication elsewhere. b. Camera Ready Paper Submission:On the acceptance of the paper after completion of the review process the author (s) is/are has to submit camera ready full text paper in .doc and .pdf (both) format to e-mail: [2]submitfinal@ijtemt.org along with the corresponding signed copy of copyright transfer form and scanned copy of payment slip. Publication fees Each accepted paper will be charged, for publication and paper handling, 100 USD per paper (for a maximum of 8 pages, above which 10 USD will be charged for every additional page) which is to be paid as per the instructions mentioned in the letter of acceptance of the manuscript submitted. Editor International Journal of Trends in Economics Management & Technology Website: [3]www.ijtemt.org Email: [4]editor@ijtemt.org, [5]coedtech@ijtemt.org, [6]contact@ijtemt.org. Paper Submission Email: [7]submit@ijtemt.org. References 1. mailto:submit@ijtemt.org 2. mailto:submitfinal@ijtemt.org 3. http://www.ijtemt.org/ 4. mailto:editor@ijtemt.org 5. mailto:coedtech@ijtemt.org 6. mailto:contact@ijtemt.org 7. mailto:submit@ijtemt.org From owner-freebsd-arch@FreeBSD.ORG Fri May 10 20:02:33 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 920B1422 for ; Fri, 10 May 2013 20:02:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2794D3EF for ; Fri, 10 May 2013 20:02:32 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3C59FB953; Fri, 10 May 2013 16:02:30 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Subject: Re: Extending MADV_PROTECT Date: Fri, 10 May 2013 15:35:50 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201305071433.27993.jhb@freebsd.org> <201305090814.52166.jhb@freebsd.org> <20130509123147.GT3047@kib.kiev.ua> In-Reply-To: <20130509123147.GT3047@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201305101535.50633.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 10 May 2013 16:02:30 -0400 (EDT) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 20:02:33 -0000 On Thursday, May 09, 2013 8:31:47 am Konstantin Belousov wrote: > On Thu, May 09, 2013 at 08:14:52AM -0400, John Baldwin wrote: > > > You mentioned a priority, and I think ability to pass a structure to the > > > sub-function of the syscall is better then carving bits in the int argument, > > > or introducing a new syscall. > > > > I think the priority would still be a pprotect operation. In some ways it would > > be nice to be able to do ioctls on processes and maybe this could be structured > > similarly? > > > > int procctl(int pid, unsigned long cmd, ...) > > > > (So it's basically ioctl but with the 'fd' replaced with 'pid'. This would also > > mean that in the future with Robert's pdfork() you could perhaps have ioctl on > > a process fd just foward the request to procctl). > > Yes, this is exactly what I mean. Ok, here is a patch for 8 that reworks this to use a procctl(). If this looks reasonable I will port this to HEAD as two pieces: the first to add procctl() and the second to add PROCSPROTECT. Index: sys/cddl/contrib/opensolaris/uts/common/sys/procset.h =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/sys/procset.h (revision 251038) +++ sys/cddl/contrib/opensolaris/uts/common/sys/procset.h (working copy) @@ -51,6 +51,7 @@ #define P_INITUID 0 #define P_INITPGID 0 +#ifndef _IDTYPE_T_DECLARED /* * The following defines the values for an identifier type. It @@ -81,7 +82,10 @@ P_PSETID /* Processor set identifier */ } idtype_t; +#define _IDTYPE_T_DECLARED +#endif + /* * The following defines the operations which can be performed to * combine two simple sets of processes to form another set of Index: sys/compat/freebsd32/syscalls.master =================================================================== --- sys/compat/freebsd32/syscalls.master (revision 251038) +++ sys/compat/freebsd32/syscalls.master (working copy) @@ -977,3 +977,15 @@ uint32_t offset1, uint32_t offset2,\ uint32_t len1, uint32_t len2, \ int advice); } +532 AUE_NULL UNIMPL wait6 +533 AUE_NULL UNIMPL cap_rights_limit +534 AUE_NULL UNIMPL cap_ioctls_limit +535 AUE_NULL UNIMPL cap_ioctls_get +536 AUE_NULL UNIMPL cap_fcntls_limit +537 AUE_NULL UNIMPL cap_fcntls_get +538 AUE_NULL UNIMPL bindat +539 AUE_NULL UNIMPL connectat +540 AUE_NULL UNIMPL chflagsat +541 AUE_NULL UNIMPL accept4 +542 AUE_NULL UNIMPL pipe2 +543 AUE_NULL UNIMPL procctl Index: sys/kern/makesyscalls.sh =================================================================== --- sys/kern/makesyscalls.sh (revision 251038) +++ sys/kern/makesyscalls.sh (working copy) @@ -143,7 +143,8 @@ printf "#include \n" > sysarg printf "#include \n" > sysarg printf "#include \n" > sysarg - printf "#include \n\n" > sysarg + printf "#include \n" > sysarg + printf "#include \n\n" > sysarg printf "#include \n\n" > sysarg printf "struct proc;\n\n" > sysarg printf "struct thread;\n\n" > sysarg Index: sys/kern/sys_process.c =================================================================== --- sys/kern/sys_process.c (revision 251038) +++ sys/kern/sys_process.c (working copy) @@ -36,12 +36,17 @@ #include #include +#include +#include #include +#include #include #include #include #include +#include #include +#include #include #include #include @@ -98,6 +103,8 @@ #endif +static MALLOC_DEFINE(M_PROCCTLOPS, "procctlops", "procctl data buffer"); + /* * Functions implemented using PROC_ACTION(): * @@ -1281,3 +1288,217 @@ msleep(&p->p_step, &p->p_mtx, PWAIT, "stopevent", 0); } while (p->p_step); } + +static int +protect_setchild(struct thread *td, struct proc *p, int flags) +{ + + PROC_LOCK_ASSERT(p, MA_OWNED); + if (p->p_flag & P_SYSTEM || p_cansee(td, p) != 0) + return (0); + if (flags & PPROT_SET) + p->p_flag |= P_PROTECTED; + else + p->p_flag &= ~P_PROTECTED; + return (1); +} + +static int +protect_setchildren(struct thread *td, struct proc *top, int flags) +{ + struct proc *p; + int ret; + + p = top; + ret = 0; + sx_assert(&proctree_lock, SX_LOCKED); + for (;;) { + ret |= protect_setchild(td, p, flags); + PROC_UNLOCK(p); + /* + * If this process has children, descend to them next, + * otherwise do any siblings, and if done with this level, + * follow back up the tree (but not past top). + */ + if (!LIST_EMPTY(&p->p_children)) + p = LIST_FIRST(&p->p_children); + else for (;;) { + if (p == top) { + PROC_LOCK(p); + return (ret); + } + if (LIST_NEXT(p, p_sibling)) { + p = LIST_NEXT(p, p_sibling); + break; + } + p = p->p_pptr; + } + PROC_LOCK(p); + } +} + +static int +protect_set(struct thread *td, struct proc *p, int flags) +{ + int error, ret; + + if ((flags & ~(PPROT_SET | PPROT_CLEAR | PPROT_DESCEND | + PPROT_INHERIT)) != 0) + return (EINVAL); + if (flags & PPROT_INHERIT) + return (EOPNOTSUPP); + + error = priv_check(td, PRIV_VM_MADV_PROTECT); + if (error) + return (error); + + if (flags & PPROT_DESCEND) + ret = protect_setchildren(td, p, flags); + else + ret = protect_setchild(td, p, flags); + if (ret == 0) + return (EPERM); + return (0); +} + +#ifndef _SYS_SYSPROTO_H_ +struct procctl_args { + idtype_t idtype; + id_t id; + u_long com; + void *data; +}; +#endif +/* ARGSUSED */ +int +procctl(struct thread *td, struct procctl_args *uap) +{ + u_long com; + int arg, error; + u_int size; + void *data; + + if (uap->com > 0xffffffff) { + printf( + "WARNING pid %d (%s): procctl sign-extension procctl %lx\n", + td->td_proc->p_pid, td->td_name, uap->com); + uap->com &= 0xffffffff; + } + com = uap->com; + + /* + * Interpret high order word to find amount of data to be + * copied to/from the user's address space. + */ + size = IOCPARM_LEN(com); + if ((size > IOCPARM_MAX) || + ((com & (IOC_VOID | IOC_IN | IOC_OUT)) == 0) || + ((com & (IOC_IN | IOC_OUT)) && size == 0) || + ((com & IOC_VOID) && size > 0 && size != sizeof(int))) + return (ENOTTY); + + if (size > 0) { + if (com & IOC_VOID) { + /* Integer argument. */ + arg = (intptr_t)uap->data; + data = (void *)&arg; + size = 0; + } else + data = malloc((u_long)size, M_PROCCTLOPS, M_WAITOK); + } else + data = (void *)&uap->data; + if (com & IOC_IN) { + error = copyin(uap->data, data, (u_int)size); + if (error) { + if (size > 0) + free(data, M_PROCCTLOPS); + return (error); + } + } else if (com & IOC_OUT) { + /* + * Zero the buffer so the user always + * gets back something deterministic. + */ + bzero(data, size); + } + + error = kern_procctl(td, uap->idtype, uap->id, com, data); + + if (error == 0 && (com & IOC_OUT)) + error = copyout(data, uap->data, (u_int)size); + + if (size > 0) + free(data, M_PROCCTLOPS); + return (error); +} + +static int +kern_procctl_single(struct thread *td, struct proc *p, u_long com, void *data) +{ + + PROC_LOCK_ASSERT(p, MA_OWNED); + switch (com) { + case PROCSPROTECT: + return (protect_set(td, p, *(int *)data)); + default: + return (ENOTTY); + } +} + +int +kern_procctl(struct thread *td, idtype_t idtype, id_t id, u_long com, + void *data) +{ + struct pgrp *pg; + struct proc *p; + int error; + + sx_slock(&proctree_lock); + switch (idtype) { + case P_PID: + p = pfind(id); + if (p == NULL) { + error = ESRCH; + break; + } + if (p->p_state == PRS_NEW) + error = ESRCH; + else + error = p_cansee(td, p); + if (error == 0) + error = kern_procctl_single(td, p, com, data); + PROC_UNLOCK(p); + break; + case P_PGID: + /* + * Attempt to apply the operation to all members of the + * group. Ignore processes in the group that can't be + * seen. Stop on the first error encountered. + */ + pg = pgfind(id); + if (pg == NULL) { + error = ESRCH; + break; + } + PGRP_UNLOCK(pg); + error = ESRCH; + LIST_FOREACH(p, &pg->pg_members, p_pglist) { + PROC_LOCK(p); + if (p->p_state == PRS_NEW || + p_cansee(td, p) != 0) { + PROC_UNLOCK(p); + continue; + } + error = kern_procctl_single(td, p, com, data); + PROC_UNLOCK(p); + if (error) + break; + } + break; + default: + error = EINVAL; + break; + } + sx_sunlock(&proctree_lock); + return (error); +} Index: sys/kern/syscalls.master =================================================================== --- sys/kern/syscalls.master (revision 251038) +++ sys/kern/syscalls.master (working copy) @@ -938,5 +938,18 @@ off_t offset, off_t len); } 531 AUE_NULL STD { int posix_fadvise(int fd, off_t offset, \ off_t len, int advice); } +532 AUE_NULL UNIMPL wait6 +533 AUE_NULL UNIMPL cap_rights_limit +534 AUE_NULL UNIMPL cap_ioctls_limit +535 AUE_NULL UNIMPL cap_ioctls_get +536 AUE_NULL UNIMPL cap_fcntls_limit +537 AUE_NULL UNIMPL cap_fcntls_get +538 AUE_NULL UNIMPL bindat +539 AUE_NULL UNIMPL connectat +540 AUE_NULL UNIMPL chflagsat +541 AUE_NULL UNIMPL accept4 +542 AUE_NULL UNIMPL pipe2 +543 AUE_NULL STD { int procctl(idtype_t idtype, id_t id, \ + u_long com, void *data); } ; Please copy any additions and changes to the following compatability tables: ; sys/compat/freebsd32/syscalls.master Index: sys/sys/procctl.h =================================================================== --- sys/sys/procctl.h (revision 0) +++ sys/sys/procctl.h (working copy) @@ -0,0 +1,29 @@ +/*- + * XXX: License + * + * $FreeBSD$ + */ + +#ifndef _SYS_PROCCTL_H_ +#define _SYS_PROCCTL_H_ + +#define PROCSPROTECT _IOW('p', 1, int) /* set protected state */ + +/* Flags for PROCSPROTECT (passed in integer arg). */ +#define PPROT_SET 0x1 +#define PPROT_CLEAR 0x0 +#define PPROT_DESCEND 0x2 +#define PPROT_INHERIT 0x4 + +#ifndef _KERNEL +#include +#include +#include + +__BEGIN_DECLS +int procctl(idtype_t, id_t, unsigned long, void *); +__END_DECLS + +#endif + +#endif /* !_SYS_PROCCTL_H_ */ Property changes on: sys/sys/procctl.h ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: sys/sys/syscallsubr.h =================================================================== --- sys/sys/syscallsubr.h (revision 251038) +++ sys/sys/syscallsubr.h (working copy) @@ -33,6 +33,7 @@ #include #include #include +#include struct file; struct itimerval; @@ -154,6 +155,8 @@ int advice); int kern_posix_fallocate(struct thread *td, int fd, off_t offset, off_t len); +int kern_procctl(struct thread *td, idtype_t idtype, id_t id, u_long com, + void *data); int kern_preadv(struct thread *td, int fd, struct uio *auio, off_t offset); int kern_pselect(struct thread *td, int nd, fd_set *in, fd_set *ou, fd_set *ex, struct timeval *tvp, sigset_t *uset, int abi_nfdbits); Index: sys/sys/wait.h =================================================================== --- sys/sys/wait.h (revision 251038) +++ sys/sys/wait.h (working copy) @@ -85,6 +85,46 @@ #define WLINUXCLONE 0x80000000 /* Wait for kthread spawned from linux_clone. */ #endif +#ifndef _IDTYPE_T_DECLARED +typedef enum +#if __BSD_VISIBLE + idtype /* pollutes XPG4.2 namespace */ +#endif + { + /* + * These names were mostly lifted from Solaris source code and + * still use Solaris style naming to avoid breaking any + * OpenSolaris code which has been ported to FreeBSD. There + * is no clear FreeBSD counterpart for all of the names, but + * some have a clear correspondence to FreeBSD entities. + * + * The numerical values are kept synchronized with the Solaris + * values. + */ + P_PID, /* A process identifier. */ + P_PPID, /* A parent process identifier. */ + P_PGID, /* A process group identifier. */ + P_SID, /* A session identifier. */ + P_CID, /* A scheduling class identifier. */ + P_UID, /* A user identifier. */ + P_GID, /* A group identifier. */ + P_ALL, /* All processes. */ + P_LWPID, /* An LWP identifier. */ + P_TASKID, /* A task identifier. */ + P_PROJID, /* A project identifier. */ + P_POOLID, /* A pool identifier. */ + P_JAILID, /* A zone identifier. */ + P_CTID, /* A (process) contract identifier. */ + P_CPUID, /* CPU identifier. */ + P_PSETID /* Processor set identifier. */ +} idtype_t; /* The type of id_t we are using. */ + +#if __BSD_VISIBLE +#define P_ZONEID P_JAILID +#endif +#define _IDTYPE_T_DECLARED +#endif + /* * Tokens for special values of the "pid" parameter to wait4. */ Index: sys/vm/vm_mmap.c =================================================================== --- sys/vm/vm_mmap.c (revision 251038) +++ sys/vm/vm_mmap.c (working copy) @@ -48,12 +48,14 @@ #include #include +#include #include #include #include #include #include #include +#include #include #include #include @@ -63,6 +65,7 @@ #include #include #include +#include #include #include @@ -668,23 +671,18 @@ { vm_offset_t start, end; vm_map_t map; - struct proc *p; - int error; + int flags; /* * Check for our special case, advising the swap pager we are * "immortal." */ if (uap->behav == MADV_PROTECT) { - error = priv_check(td, PRIV_VM_MADV_PROTECT); - if (error == 0) { - p = td->td_proc; - PROC_LOCK(p); - p->p_flag |= P_PROTECTED; - PROC_UNLOCK(p); - } - return (error); + flags = PPROT_SET; + return (kern_procctl(td, P_PID, td->td_proc->p_pid, + PROCSPROTECT, &flags)); } + /* * Check for illegal behavior */ -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Sat May 11 04:36:15 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6CE58FA5; Sat, 11 May 2013 04:36:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id C97D486E; Sat, 11 May 2013 04:36:14 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r4B4a6C1089973; Sat, 11 May 2013 07:36:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r4B4a6C1089973 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r4B4a6ag089972; Sat, 11 May 2013 07:36:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 11 May 2013 07:36:06 +0300 From: Konstantin Belousov To: John Baldwin Subject: Re: Extending MADV_PROTECT Message-ID: <20130511043606.GE3047@kib.kiev.ua> References: <201305071433.27993.jhb@freebsd.org> <201305090814.52166.jhb@freebsd.org> <20130509123147.GT3047@kib.kiev.ua> <201305101535.50633.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZhyQ46P6+PZKtzF3" Content-Disposition: inline In-Reply-To: <201305101535.50633.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 04:36:15 -0000 --ZhyQ46P6+PZKtzF3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, May 10, 2013 at 03:35:50PM -0400, John Baldwin wrote: > Ok, here is a patch for 8 that reworks this to use a procctl(). If this looks > reasonable I will port this to HEAD as two pieces: the first to add > procctl() and the second to add PROCSPROTECT. This looks fine. Do we need the genericity of the ioctl for procctl ? Ptrace(2) does not need the size encoded. I mean, the call is never marshalled to some unknown driver which needs a size of parameters unknown to the generic layer. I suppose that all additions to procctl() would have the size of the control structures pre-defined. Then, you could just do copyin and, if needed, copyout discrimating on the command code, and not on the encoding of the size in the command. Also, command could be int and not long then, eliminating the need for compat32 wrapper. --ZhyQ46P6+PZKtzF3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRjcq1AAoJEJDCuSvBvK1Ba/sP/i4BkyaYfh0CDfy0jNscG3Eh RDp8SOWgQkowHZP6hUNJWvcnJKcyuggXszesKKSQYvcBqeQ5Y/FqVEbNhDMV7URt qFBqMyQyCShLkzecpl7ylGOYEqhaFjtdTJp6RewXj1nCrCIna53jxSA6Z4nXbIVI VZgaPmNhd8OwyJJyVY2nGj+PYj4/9rou6qdnhqMdwoziYePSlT1RhB6mWkXqXwn1 N100Z808I9norcWjpl19SGPt+rUQvmRSCWFLkWi9KByfkZS1d6TGnNA4krqGqKuY FaamswCi09nF7nsD8KHe+U8HinSXbaOMJkkL5i6pvNATkcFkAja4wU8V267i8Koo QdeiSFOFul8urwSPjyLCXia1PS6PaTwUFLhquVK1ew3uc0X/m8uh1L1oYxg2fDUS V378U3MhMfSPUlWvKdFXTWmjE0/UeEZoGFtQtvWn6+x4N939c4ZtDKf7zpnxv1aR wwNHaOgADLOJRQmaJNSVv7QVYQPMal4AmMKoZp/q+YiXVcy0FQFCof2TEkkOuORJ fMQ1CtY2i3J9GZhdvjIu2fKmwVTpGkOnNn64R91OZ58HkEnuGf3snOMwU17JQbRA fXwrtNpfGCU1ZUiLXTAuxHDkhpptNHl7JQiQrW4Ohm+v82SqxFf4P/oq1pHPtv9l DoXly/fKRlQfnTShxaVr =A8n/ -----END PGP SIGNATURE----- --ZhyQ46P6+PZKtzF3-- From owner-freebsd-arch@FreeBSD.ORG Sat May 11 05:47:06 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AB5A8417; Sat, 11 May 2013 05:47:06 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 41AB895C; Sat, 11 May 2013 05:47:06 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUY3bWXKIIAJB9Hv1nV0YLkQY0KBsc0D/@postini.com; Fri, 10 May 2013 22:47:06 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 10 May 2013 22:45:36 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r4B5jaL66346; Fri, 10 May 2013 22:45:36 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 7707958097; Fri, 10 May 2013 22:45:36 -0700 (PDT) To: Baptiste Daroussin Subject: Making bmake default? (was: Re: ports/173299: [exp-run] test bmake conversion) In-Reply-To: References: Comments: In-reply-to: Baptiste Daroussin message dated "Mon, 06 May 2013 00:11:51 +0200." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Fri, 10 May 2013 22:45:36 -0700 Message-ID: <20130511054536.7707958097@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 05:47:06 -0000 On Mon, 6 May 2013 00:11:51 +0200, Baptiste Daroussin writes: >The ports tree on current is still in very bad shape but I don't see >anymore errors due to bmake specifically. > >You have my approval as portmgr to switch base make to bmake. As an interim step, I would propose the change below. Index: share/mk/bsd.own.mk =================================================================== --- share/mk/bsd.own.mk (revision 249461) +++ share/mk/bsd.own.mk (working copy) @@ -254,6 +254,7 @@ __DEFAULT_YES_OPTIONS = \ BIND_UTILS \ BINUTILS \ BLUETOOTH \ + BMAKE \ BOOT \ BSD_CPIO \ BSNMP \ @@ -361,7 +362,6 @@ __DEFAULT_NO_OPTIONS = \ BIND_LIBS \ BIND_SIGCHASE \ BIND_XML \ - BMAKE \ BSDCONFIG \ BSD_GREP \ CLANG_EXTRAS \