http://permalink.gmane.org/gmane.os.freebsd.architechture hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.os.freebsd.architechture/17254 <pre> 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&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe&lt; at &gt;freebsd.org"</pre> Justin Hibbits 2013-05-16T18:34:37 http://permalink.gmane.org/gmane.os.freebsd.architechture/17253 <pre> 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. </pre> John Baldwin 2013-05-15T10:56:04 http://permalink.gmane.org/gmane.os.freebsd.architechture/17252 <pre> 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)? </pre> John Baldwin 2013-05-14T21:37:00 http://permalink.gmane.org/gmane.os.freebsd.architechture/17251 <pre> I think it does not really make sense that the set of affected processes depends on the order in &amp;pg-&gt;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). </pre> Jilles Tjoelker 2013-05-14T19:21:15 http://permalink.gmane.org/gmane.os.freebsd.architechture/17250 <pre>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" &lt;imp&lt; at &gt;bsdimp.com&gt; wrote: tree, and can't easily be. additional proliferation of late l</pre> Justin Hibbits 2013-05-14T17:14:42 http://permalink.gmane.org/gmane.os.freebsd.architechture/17249 <pre>Yes, I just do not see much need in it, but this is your call, finally. </pre> Konstantin Belousov 2013-05-14T16:33:14 http://permalink.gmane.org/gmane.os.freebsd.architechture/17248 <pre>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(&amp;lock-&gt;m, 0, sizeof(lock-&gt;m)); mtx_init(&amp;lock-&gt;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&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe&lt; at &gt;freebsd.org" </pre> Orit Moskovich 2013-05-14T10:04:21 http://permalink.gmane.org/gmane.os.freebsd.architechture/17247 <pre> 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 = &lt;get pid from f_data&gt;; 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. </pre> John Baldwin 2013-05-13T20:12:04 http://permalink.gmane.org/gmane.os.freebsd.architechture/17246 <pre> 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&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe&lt; at &gt;freebsd.org" </pre> Warner Losh 2013-05-13T19:19:39 http://permalink.gmane.org/gmane.os.freebsd.architechture/17245 <pre> 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&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe&lt; at &gt;freebsd.org" </pre> Julian Elischer 2013-05-13T19:14:05 http://permalink.gmane.org/gmane.os.freebsd.architechture/17244 <pre>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 prop</pre> Warner Losh 2013-05-13T13:53:39 http://permalink.gmane.org/gmane.os.freebsd.architechture/17243 <pre>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 we</pre> Justin Hibbits 2013-05-13T07:20:19 http://permalink.gmane.org/gmane.os.freebsd.architechture/17242 <pre> 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) &lt; at &gt;&lt; at &gt; -254,6 +254,7 &lt; at &gt;&lt; at &gt; __DEFAULT_YES_OPTIONS = \ BIND_UTILS \ BINUTILS \ BLUETOOTH \ + BMAKE \ BOOT \ BSD_CPIO \ BSNMP \ &lt; at &gt;&lt; at &gt; -361,7 +362,6 &lt; at &gt;&lt; at &gt; __DEFAULT_NO_OPTIONS = \ BIND_LIBS \ BIND_SIGCHASE \ BIND_XML \ - BMAKE \ BSDCONFIG \ BSD_GREP \ CLANG_EXTRAS \ _______________________________________________ freebsd-arch&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe&lt; at &gt;freebsd.org" </pre> Simon J. Gerraty 2013-05-11T05:45:36 http://permalink.gmane.org/gmane.os.freebsd.architechture/17241 <pre> 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. </pre> Konstantin Belousov 2013-05-11T04:36:06 http://permalink.gmane.org/gmane.os.freebsd.architechture/17240 <pre> 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) &lt; at &gt;&lt; at &gt; -51,6 +51,7 &lt; at &gt;&lt; at &gt; #defineP_INITUID0 #defineP_INITPGID0 +#ifndef _IDTYPE_T_DECLARED /* *The following defines the values for an identifier type. It &lt; at &gt;&lt; at &gt; -81,7 +82,10 &lt; at &gt;&lt; at &gt; 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</pre> John Baldwin 2013-05-10T19:35:50 http://permalink.gmane.org/gmane.os.freebsd.architechture/17239 <pre> INTERNATIONAL JOURNAL OF TRENDS IN ECONOMICS MANAGEMENT &amp; 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 </pre> Editor IJTEMT 2013-05-10T03:37:33 http://permalink.gmane.org/gmane.os.freebsd.architechture/17238 <pre> Yes, this is exactly what I mean. </pre> Konstantin Belousov 2013-05-09T12:31:47 http://permalink.gmane.org/gmane.os.freebsd.architechture/17237 <pre> 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). </pre> John Baldwin 2013-05-09T12:14:52 http://permalink.gmane.org/gmane.os.freebsd.architechture/17236 <pre>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. </pre> Konstantin Belousov 2013-05-09T08:25:38 http://permalink.gmane.org/gmane.os.freebsd.architechture/17235 <pre> 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&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe&lt; at &gt;freebsd.org" </pre> Simon J. Gerraty 2013-05-09T04:58:34 http://permalink.gmane.org/gmane.os.freebsd.architechture/17234 <pre> 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 &amp; dirty builds and of course for buildworld and such. What trick? MAKEOBJDIRPREFIX has al</pre> Simon J. Gerraty 2013-05-08T22:53:02 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.freebsd.architechture