gmane.os.freebsd.architechture

Re: late suspend/early resume

Justin Hibbits — 2013-05-16T18:34:37



Here's a (very) rough cut of what I think you're getting at.  It uses the
existing pass identifier to convey the current pass number, and walks the
pass in reverse for suspend, and forwards for resume.  However, I can't
stress enough, that I only compiled it, I have no hardware here at BSDCan
to test, so I have no idea if it will work as expected.

The basic idea is to start at the last pass number, and any device can
suspend and resume if able, or can check and return EAGAIN if it's not
ready to suspend itself (it can still suspend its children if it wants).  I
could also add to bus_generic_resume() a check for the device's driver's
pass wrt bus_current_pass, as in the probe code.

Is this what you're thinking?

- Justin
_______________________________________________
freebsd-arch< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe< at >freebsd.org"

Re: late suspend/early resume

John Baldwin — 2013-05-15T10:56:04

I think you can do this by having a notion of passes with drivers having
a suspend pass level and doing passes over the tree suspending devices
at each pass level and then walking the passes back up in reverse during
resume.  You could borrow from the multipass stuff used on probe/attach
for this.

Re: Extending MADV_PROTECT

John Baldwin — 2013-05-14T21:37:00

I originally used that approach in pprotect() since that is what ktrace
uses.  I did it this way in procctl() to err on the side of reporting
errors vs not, but I can easily change it.  This is something I wasn't
sure of and very much appreciate feedback on.

Do you have any thoughts on having this be more ioctl-like ("automatic"
copyin/out and size encoded in cmd) vs ptrace-like (explicit sizes and
in/out keyed off of command)?

Re: Extending MADV_PROTECT

Jilles Tjoelker — 2013-05-14T19:21:15

I think it does not really make sense that the set of affected processes
depends on the order in &pg->pg_members.

Comparing other functions, kill() returns success if it could signal any
process (even it could not signal other processes matched by the
argument). This is also most consistent with general POSIX/Unix
philosophy that a function only fails if it committed no change (but
there are various places where this is not the case). On the other hand,
setpriority() affects all matches processes it can but returns an error
if any one fails, even if some other process was affected.

All this is not very important for process protection because it
requires root privileges anyway but future procctl commands may well be
accessible to normal users (I'm thinking of avoiding proliferation of
pd* calls in particular).

Re: late suspend/early resume

Justin Hibbits — 2013-05-14T17:14:42

You are right that the late suspend could lead to silly proliferation, and
an ordered list is much better, but another API would need to be added to
do that as well.

My north bridge is first in the top list of the tree, right under the
nexus, so to suspend it last I wrote the nexus suspend to traverse its
children in reverse. The problem comes that the clock controller is under a
later PCI bus, not even the immediate following one, and the north bridge
children are i2c devices, so suspending them after their clock head away is
problematic.  We can discuss this more at bsdcan, where it may be easier to
describe. But essentially I need the north bridge and that pesky clock
controller to be the last to suspend and the first to resume. I guess we
can take this as the starting discussion for modeling this relationship on
all platforms, since you mention it is common in embedded platforms.
On May 13, 2013 12:19 PM, "Warner Losh" <imp< at >bsdimp.com> wrote:
tree, and can't easily be.
additional proliferation of late late late early late calls.
indicating how late to be called (and correspondingly how early resume
should be called). this way the tree walking code can insert these devices
into an ordered list that can then be walked at the end of suspend and
traversed backwards at the start of resume.
ordering between clock generation blocks and power blocks that need to be
handled specially since there's no ACPI on those platforms to do things
last. We don't model them well at all (or even at all), and having some
mechanism in place to help with that would be useful.
you propose are little better than the hard-coded calls and would like to
see something a little more generic since the in-order traversal of the
device tree seems a poor fit to 'special cases' like this.
would express it. Maybe by default it would go with the device hierarchy
but with the ability to add extra dependencies.
said graph. Expressing the dependency graph would likely be a heavier lift
as well...
be
chipsets.
chain,
as the
device_suspend_late
devices.
the
_______________________________________________
freebsd-arch< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe< at >freebsd.org"

Re: Extending MADV_PROTECT

Konstantin Belousov — 2013-05-14T16:33:14

Yes, I just do not see much need in it, but this is your call, finally.

FreeBSD spinlock - compatibility layer

Orit Moskovich — 2013-05-14T10:04:21

Hi,

I read about the FreeBSD mutex implementation for spinlock in the compatibility layer.
I might be wrong, but I noticed a code section that might be problematic:

Taken from http://svn.freebsd.org/base/release/9.1.0/sys/ofed/include/linux/spinlock.h:

static inline void
spin_lock_init(spinlock_t *lock)
{

        memset(&lock->m, 0, sizeof(lock->m));
        mtx_init(&lock->m, "lnxspin", NULL, MTX_DEF | MTX_NOWITNESS);
}

But MTX_DEF initializes mutex as a sleep mutex:

By default, MTX_DEF mutexes will context switch when they are already

     held.


There is a flag MTX_SPIN Which I think is the right one in this case .



I'd appreciate your take on this issue.



Thanks,

Orit Moskovich

_______________________________________________
freebsd-arch< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe< at >freebsd.org"

Re: Extending MADV_PROTECT

John Baldwin — 2013-05-13T20:12:04

Well, the generic-ness of ioctl() seemed useful to me.  Also, I think
with this model you could make fo_ioctl() for a process fd just do this:

proc_ioctl(..., u_long cmd, caddr_t data)
{

pid = <get pid from f_data>;
return (kern_procctl(td, P_PID, pid, cmd, data));
}

So you could reuse procctl constants as ioctls for proc descriptors.  It
is true that unlike drivers there is currently no method to provide a
"hook" to support new commands (they would just have to be added by hand
into sys_process.c for now).  Also, if we need to "thunk" structures for
compat32 support in the future it is better if the kern_procctl()
version takes a KVA rather than a UVA.

OTOH, it is more boilerplate code to put in.

In terms of a compat32 wrapper: id_t is a uint64_t, so a wrapper would
be required regardless.

Re: late suspend/early resume

Warner Losh — 2013-05-13T19:19:39

On May 13, 2013, at 1:14 PM, Julian Elischer wrote:


A numeric value would completely encapsulate the graph and avoid loops in said graph. Expressing the dependency graph would likely be a heavier lift as well...

Warner


_______________________________________________
freebsd-arch< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe< at >freebsd.org"

Re: late suspend/early resume

Julian Elischer — 2013-05-13T19:14:05

would not some dependency graph be more 'correct'?  not sure how one 
would express it. Maybe by default it would go with the device 
hierarchy but with the ability to add extra dependencies.



_______________________________________________
freebsd-arch< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe< at >freebsd.org"

Re: late suspend/early resume

Warner Losh — 2013-05-13T13:53:39

Where is the northbridge in the object tree hierarchy?

Since you are asking this, I'm guessing it isn't at the top of the tree, and can't easily be.

I don't like this idea. I think it is is silly and will lead only to additional proliferation of late late late early late calls.

Much better would be for the suspend routine to return a number indicating how late to be called (and correspondingly how early resume should be called). this way the tree walking code can insert these devices into an ordered list that can then be walked at the end of suspend and traversed backwards at the start of resume.

There are many embedded systems where there's a bit of a partial ordering between clock generation blocks and power blocks that need to be handled specially since there's no ACPI on those platforms to do things last. We don't model them well at all (or even at all), and having some mechanism in place to help with that would be useful.

So in short I understand the need, but feel that the kobj extensions you propose are little better than the hard-coded calls and would like to see something a little more generic since the in-order traversal of the device tree seems a poor fit to 'special cases' like this.

Warner


On May 13, 2013, at 1:20 AM, Justin Hibbits wrote:


_______________________________________________
freebsd-arch< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe< at >freebsd.org"

late suspend/early resume

Justin Hibbits — 2013-05-13T07:20:19

I'd like to solicit opinions on adding new kobj device API calls,
device_late_suspend and device_early_resume.

I've been working on PowerPC suspend/resume, and certain devices must be
suspended last and resumed first on Apple hardware, namely the chipsets.
It happens that one device (uninorth) appears first in the devinfo chain,
while the other (mac-io) appears off a later PCI bus.  So, rather than
special casing this to suspend the mac-io and its children, as well as the
uninorth, last with specific calls, I'd like to add a device_suspend_late
and device_resume_early, that would simply be identical to
device_suspend/device_resume, but could be called after and before,
respectively, to do last minute order suspend and first pass
initialization, to initialize things like clocks required for other devices.

It's not difficult to explicitly call suspend and resume functions on the
chipsets, but I think it's cleaner to do it through the newbus/kobj
interface, and it might be useful for other architectures as well.

Thoughts?

- Justin
_______________________________________________
freebsd-arch< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe< at >freebsd.org"

Making bmake default? (was: Re: ports/173299: [exp-run] test bmake conversion)

Simon J. Gerraty — 2013-05-11T05:45:36

On Mon, 6 May 2013 00:11:51 +0200, Baptiste Daroussin writes:

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)
< at >< at > -254,6 +254,7 < at >< at > __DEFAULT_YES_OPTIONS = \
     BIND_UTILS \
     BINUTILS \
     BLUETOOTH \
+    BMAKE \
     BOOT \
     BSD_CPIO \
     BSNMP \
< at >< at > -361,7 +362,6 < at >< at > __DEFAULT_NO_OPTIONS = \
     BIND_LIBS \
     BIND_SIGCHASE \
     BIND_XML \
-    BMAKE \
     BSDCONFIG \
     BSD_GREP \
     CLANG_EXTRAS \
_______________________________________________
freebsd-arch< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe< at >freebsd.org"

Re: Extending MADV_PROTECT

Konstantin Belousov — 2013-05-11T04:36:06

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.

Re: Extending MADV_PROTECT

John Baldwin — 2013-05-10T19:35:50

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)
< at >< at > -51,6 +51,7 < at >< at >
 #defineP_INITUID0
 #defineP_INITPGID0
 
+#ifndef _IDTYPE_T_DECLARED
 
 /*
  *The following defines the values for an identifier type.  It
< at >< at > -81,7 +82,10 < at >< at >
 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)
< at >< at > -977,3 +977,15 < at >< at >
     uint32_t offset1, uint32_t offset2,\
     uint32_t len1, uint32_t len2, \
     int advice); }
+532AUE_NULLUNIMPLwait6
+533AUE_NULLUNIMPLcap_rights_limit
+534AUE_NULLUNIMPLcap_ioctls_limit
+535AUE_NULLUNIMPLcap_ioctls_get
+536AUE_NULLUNIMPLcap_fcntls_limit
+537AUE_NULLUNIMPLcap_fcntls_get
+538AUE_NULLUNIMPLbindat
+539AUE_NULLUNIMPLconnectat
+540AUE_NULLUNIMPLchflagsat
+541AUE_NULLUNIMPLaccept4
+542AUE_NULLUNIMPLpipe2
+543AUE_NULLUNIMPLprocctl
Index: sys/kern/makesyscalls.sh
===================================================================
--- sys/kern/makesyscalls.sh(revision 251038)
+++ sys/kern/makesyscalls.sh(working copy)
< at >< at > -143,7 +143,8 < at >< at >
 printf "#include <sys/acl.h>\n" > sysarg
 printf "#include <sys/cpuset.h>\n" > sysarg
 printf "#include <sys/_semaphore.h>\n" > sysarg
-printf "#include <sys/ucontext.h>\n\n" > sysarg
+printf "#include <sys/ucontext.h>\n" > sysarg
+printf "#include <sys/wait.h>\n\n" > sysarg
 printf "#include <bsm/audit_kevents.h>\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)
< at >< at > -36,12 +36,17 < at >< at >
 
 #include <sys/param.h>
 #include <sys/systm.h>
+#include <sys/ioccom.h>
+#include <sys/kernel.h>
 #include <sys/lock.h>
+#include <sys/malloc.h>
 #include <sys/mutex.h>
 #include <sys/syscallsubr.h>
 #include <sys/sysent.h>
 #include <sys/sysproto.h>
+#include <sys/priv.h>
 #include <sys/proc.h>
+#include <sys/procctl.h>
 #include <sys/vnode.h>
 #include <sys/ptrace.h>
 #include <sys/sx.h>
< at >< at > -98,6 +103,8 < at >< at >
 
 #endif
 
+static MALLOC_DEFINE(M_PROCCTLOPS, "procctlops", "procctl data buffer");
+
 /*
  * Functions implemented using PROC_ACTION():
  *
< at >< at > -1281,3 +1288,217 < at >< at >
 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_tid;
+u_longcom;
+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)
< at >< at > -938,5 +938,18 < at >< at >
     off_t offset, off_t len); }
 531AUE_NULLSTD{ int posix_fadvise(int fd, off_t offset, \
     off_t len, int advice); }
+532AUE_NULLUNIMPLwait6
+533AUE_NULLUNIMPLcap_rights_limit
+534AUE_NULLUNIMPLcap_ioctls_limit
+535AUE_NULLUNIMPLcap_ioctls_get
+536AUE_NULLUNIMPLcap_fcntls_limit
+537AUE_NULLUNIMPLcap_fcntls_get
+538AUE_NULLUNIMPLbindat
+539AUE_NULLUNIMPLconnectat
+540AUE_NULLUNIMPLchflagsat
+541AUE_NULLUNIMPLaccept4
+542AUE_NULLUNIMPLpipe2
+543AUE_NULLSTD{ 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)
< at >< at > -0,0 +1,29 < at >< at >
+/*-
+ * XXX: License
+ *
+ * $FreeBSD$
+ */
+
+#ifndef_SYS_PROCCTL_H_
+#define_SYS_PROCCTL_H_
+
+#definePROCSPROTECT_IOW('p', 1, int)/* set protected state */
+
+/* Flags for PROCSPROTECT (passed in integer arg). */
+#definePPROT_SET0x1
+#definePPROT_CLEAR0x0
+#definePPROT_DESCEND0x2
+#definePPROT_INHERIT0x4
+
+#ifndef _KERNEL
+#include <sys/types.h>
+#include <sys/ioccom.h>
+#include <sys/wait.h>
+
+__BEGIN_DECLS
+intprocctl(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)
< at >< at > -33,6 +33,7 < at >< at >
 #include <sys/socket.h>
 #include <sys/mac.h>
 #include <sys/mount.h>
+#include <sys/wait.h>
 
 struct file;
 struct itimerval;
< at >< at > -154,6 +155,8 < at >< at >
     int advice);
 intkern_posix_fallocate(struct thread *td, int fd, off_t offset,
     off_t len);
+intkern_procctl(struct thread *td, idtype_t idtype, id_t id, u_long com,
+    void *data);
 intkern_preadv(struct thread *td, int fd, struct uio *auio, off_t offset);
 intkern_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)
< at >< at > -85,6 +85,46 < at >< at >
 #defineWLINUXCLONE 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
+#defineP_ZONEIDP_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)
< at >< at > -48,12 +48,14 < at >< at >
 
 #include <sys/param.h>
 #include <sys/systm.h>
+#include <sys/ioccom.h>
 #include <sys/lock.h>
 #include <sys/mutex.h>
 #include <sys/sysproto.h>
 #include <sys/filedesc.h>
 #include <sys/priv.h>
 #include <sys/proc.h>
+#include <sys/procctl.h>
 #include <sys/resource.h>
 #include <sys/resourcevar.h>
 #include <sys/vnode.h>
< at >< at > -63,6 +65,7 < at >< at >
 #include <sys/mount.h>
 #include <sys/conf.h>
 #include <sys/stat.h>
+#include <sys/syscallsubr.h>
 #include <sys/sysent.h>
 #include <sys/vmmeter.h>
 
< at >< at > -668,23 +671,18 < at >< at >
 {
 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
  */

Call for Papers IJTEMT. Kindly impart in your University/Organization/College/Colleagues/Academia/Circle.

Editor IJTEMT — 2013-05-10T03:37:33

    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< at >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< at >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< at >ijtemt.org,
   [5]coedtech< at >ijtemt.org,  [6]contact< at >ijtemt.org. Paper Submission Email:
   [7]submit< at >ijtemt.org.

References

   1. mailto:submit< at >ijtemt.org
   2. mailto:submitfinal< at >ijtemt.org
   3. http://www.ijtemt.org/
   4. mailto:editor< at >ijtemt.org
   5. mailto:coedtech< at >ijtemt.org
   6. mailto:contact< at >ijtemt.org
   7. mailto:submit< at >ijtemt.org
_______________________________________________
freebsd-arch< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe< at >freebsd.org"

Re: Extending MADV_PROTECT

Konstantin Belousov — 2013-05-09T12:31:47

Yes, this is exactly what I mean.

Re: Extending MADV_PROTECT

John Baldwin — 2013-05-09T12:14:52

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.


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).

Re: Extending MADV_PROTECT

Konstantin Belousov — 2013-05-09T08:25:38

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.


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.

Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree

Simon J. Gerraty — 2013-05-09T04:58:34


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.
_______________________________________________
freebsd-arch< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe< at >freebsd.org"

Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree

Simon J. Gerraty — 2013-05-08T22:53:02

On Wed, 8 May 2013 15:49:12 -0600, Warner Losh writes:

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


Yes, MAKEOBJDIRPREFIX is certainly very handy - and I use it for quick &
dirty builds and of course for buildworld and such.


What trick?  MAKEOBJDIRPREFIX has always worked as you describe.
Don't confuse limitations imposed by makefiles as being limitations of
the tool ;-)


The project doesn't currently do anything close to what dirdeps.mk
allows.
_______________________________________________
freebsd-arch< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe< at >freebsd.org"