gmane.os.freebsd.architechture

In this Issue: Black Cowboy Quilts, 2013 Products of the Year, Allergies Unique to Urban Areas, Big Salad Recipes

TheUrbanShopper — 2013-06-19T17:14:41

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Untitled Document</TITLE>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<STYLE type=text/css>
<!--
style2 {font-size: 10px}
style3 {
font-family: Calibri;
font-size: 12px;
color: #3333FF;
}
style4 {color: #FF0000}
-->
</STYLE>

<META name=GENERATOR content="MSHTML 10.00.9200.16618"></HEAD>
<BODY>
<DIV align=center>
<TABLE cellSpacing=1 cellPadding=5 width=650 border=1>
  <TBODY>
  <TR>
    <TD borderColor=#ffffff>
      <DIV class=style3 align=center>Having trouble reading this email?
Click<A 
      href="http://www.theurbanshopper.com"> Here</A> to go direct to 
      TheUrbanShopper.com.<BR>To ensure delivery, please add <SPAN 
      class=style4>us< at >theurbanshopper.com</SPAN> to your Safe Sender List
or 
      Address Book. </DIV></TD></TR>
  <TR>
    <TD><A href="http://theurbanshopper.com"><IMG border=0 hspace=0 alt="" 
      align=baseline
src="http://theurbanshopper.com/newsletter/2013/June/static.jpg"></A></TD></TR>
  <TR>
    <TD><SPAN class=style2>You have received this update as a subscriber to
TheUrbanShopper.com. Ensure inbox delivery by adding 
      us< at >theurbanshopper.com to your SAFE SENDER or email CONTACTS list. If
you'd like to <A href="mailto:unsubscribe< at >theurbanshopper.com">unsubscribe 
      </A>. For more information, please read our <A 
      href="http://theurbanshopper.com/doc/privacy_policy.pdf">Privacy
Policy 
      </A>. ©2013 All Rights Reserved 
</SPAN></TD></TR></TBODY></TABLE></DIV></BODY></HTML>
_______________________________________________
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"

Bus space routines

Niclas Zeising — 2013-06-18T10:20:14

This has been discussed before [1], but there seem to still be a lack of
consensus, so I'll ask again.

Should in*/out* macros or bus_space* functions be used in userland code?
The background is that the port devel/libpciaccess uses these routines
on FreeBSD.  In a first incarnation it used the bus_space* routines, see
this patch:

http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=591

This was later changed to use the in*/out* macros directly, with the
motivation that the bus_space* functions is a KPI that shouldn't be used
in userland.  See following for an updated patch:

http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=815

The problem is that the in*/out* macros differ between FreeBSD and
Debian/kFreeBSD, and Debian/kFreeBSD want to switch back to use
bus_space* again.

My question is simply, which one is correct, or should libpciaccess be
reworked in a completely different way?

I hope everything is clear in the above, otherwise poke me and I'll
explain further.
Regards!

Your Ticket Order Confirmation

Ticket Master — 2013-06-10T20:26:15

Thank you for purchasing tickets on Ticketmaster.Your order number for this purchase is 11-00480/AUS.Complete order detail is attached to this e-mail.You will receive your tickets via: International Express-Ticketmaster will mail these within 2 business days of the booking.Tickets usually arrive within 10 working days of posting.        Total Charge: AU $120.50Thank you for adding Event Ticket Insurance to your order. You will be billed AU $13.00 (AU $6.50 per ticket)separately.Please note: for any ticket-related issues, please continue to contact Ticketmaster Customer Service.                                    Thanks again for using Ticketmaster.            Return to Ticketmaster home.    You can always check your order and manage your preferences in My Ticketmaster.        __________________________________________________________________________________    The personal information collected by Ticketmaster is used to ensure that the tickets or goods you purchased are delivered to you and that the you are advised of any possible changes/cancellations that may occur in relation to the event you booked.Ticketmaster collect personal financial information to confirm the identity of users and bill customers for products and services.Ticketmaster will not share financial or unique identifier information with third parties without your prior consent.When you make a purchase through the Ticketmaster system your consent is required to provide your financial or contact information to those third parties necessary to process your transactions with us, such as credit card companies and the companies that handle shipping on our behalf. Ticketmaster may also pass your contact details on to Venues and Presenters,who abide by the National Privacy Principles, to keep you informed of future events via direct marketing.You were asked at the time of booking if you would like to receive this information.You may also change this choice in the future by contacting us with this request, although it may also be necessary to contact any other organisations(Venues &amp; Presenters) which have obtained your information to indicate your choice at this stage.Ticketmaster will not use or disclose this information in any way, other than that disclosed in this policy.        This email confirms your ticket order, so print/save it for future reference.All purchases are subject to credit card approval and billing address verification. We make every effort to be accurate, but we cannot be responsible for changes, cancellations, or postponements announced after this email is sent.        To update your information or to unsubscribe from Ticketmaster offers, click here.    Note:  This email was sent from an address that cannot accept incoming email Please do not reply to this message.If you have any questions please visit our Help Section._______________________________________________
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"

missing DTrace FBT return probes

Navdeep Parhar — 2013-06-05T21:50:43

A large number of kernel functions have an FBT entry probe but no return
probe.  I believe this is due to tail call optimization by the compiler.
Should we disable this optimization for kernel configs that have DTrace
support?  The missing return probes make it very difficult to write
DTrace scripts that want to set flags etc. at function entry and then
clean them up on return.

A quick sample from a recent HEAD shows ~4000 out of ~27000 functions
are missing return probes.  See the list of functions in these files
(the ones listed in entry-only.txt do not have return probes).

http://people.freebsd.org/~np/entry-only.txt
http://people.freebsd.org/~np/entry.txt
http://people.freebsd.org/~np/return.txt

Regards,
Navdeep


dtrace -ln fbt:::entry | sed -e 's/.*  *\(.*\) entry$/\1/g' | sort >
entry.txt
dtrace -ln fbt:::return | sed -e 's/.*  *\(.*\) return$/\1/g' | sort >
return.txt
comm -23 entry.txt return.txt > entry-only.txt
_______________________________________________
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"

Kernelspace C11 atomics for MIPS

Ed Schouten — 2013-06-03T14:04:23

Hi,

As of r251230, it should be possible to use C11 atomics in
kernelspace, by including <sys/stdatomic.h>! Even when not using Clang
(but GCC 4.2), it is possible to use quite a large portion of the API.
A couple of limitations:

- The memory order argument is simply ignored, making all the calls do
a full memory barrier.
- At least Clang allows you to do arithmetic on C11 atomics directly
(e.g. "a += 5" == "atomic_fetch_add(&a, 5)"), which is of course not
possible to mimick.
- The atomic functions only work on 1,2,4,8-byte types, which is
probably a good thing.

Amazingly, it turns out that it most of the architectures, with the
exception of ARM and MIPS. To make MIPS work, we need to implement
some of the __sync_* functions that are described here:

http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html

Some time ago I already added some of these functions to our
libcompiler-rt in userspace, to make atomics work there.
Unfortunately, these functions were quite horribly implemented, as I
tried to build them on top of <machine/atomic.h>, which is far from
trivial/efficient. It is also restricted to 4 and 8-byte types. That's
why I thought: why not spend some time learning MIPS assembly and
write some decent implementations for these functions?

The result:

http://80386.nl/pub/mips-stdatomic.txt

For now, please focus on sys/mips/mips/stdatomic.c. It implements all
the __sync_* functions called by <stdatomic.h> for 1, 2, 4 and 8 byte
types. There is some testing code in there as well, which can be
ignored. This code disassembles to the following:

http://80386.nl/pub/mips-stdatomic-disasm.txt

As I don't own a MIPS system myself, I was thinking about tinkering a
bit with qemu to see whether these functions work properly. My
questions are:

- Does anyone have any comments on the C code and/or the machine code
generated? Are there some nifty tricks I can apply to make the machine
code more efficient that I am unaware o?
- Is there anyone interested in testing this code a bit more
thoroughly on physical hardware?
- Would anyone mind if I committed this to HEAD?

Thanks,
--
Ed Schouten <ed< at >80386.nl>
_______________________________________________
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"

aio_mlock(2) system call

Gleb Smirnoff — 2013-06-03T10:06:18

  Hello!

  This patch brings a new system call - aio_mlock(2). The idea is
quite clear from its name: it performs mlock(2), which can take
a long time if pages aren't resident, under aio(4) control.

  The patch is quite simple, and non-desctructive. Here it is
for your review.

  If no one objects, I'd like to add it to FreeBSD 10.

Intel SMAP for FreeBSD-CURRENT

Oliver Pinter — 2013-06-01T23:51:25

Hi All!

(I'm sorry for re-posting, soon forgot the subject.)

As subpart of my thesis, I implemented Intel SMAP[1] support for FreeBSD.
The current stable version of patch (attached) have compile time
option to enable SMAP.*

A feature complete dynamic version is expected by the end of the
month, which patched the kernel on boot time, when the feautre
presented in CPU.

[1] http://lwn.net/Articles/517475/

patches: https://github.com/opntr/freebsd-patches-2013-tavasz
smap-test: https://github.com/opntr/freebsd-smap-tester

smap_disabled.gif:
Running smap-test without SMAP support: illegal user-space memory
address read/write from kernel-space.

smap_{read,write}.gif:
Running smap-test with SMAP: the kernel must paniced, due an illegal
read from user-space memory address.

* when you applied this patch and enabled the SMAP in kernel and your
CPU does not have SMAP support, the kernel _must_ paniced.
_______________________________________________
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"

(unknown)

Oliver Pinter — 2013-06-01T23:46:15

Hi All!

As subpart of my thesis, I implemented Intel SMAP[1] support for FreeBSD.
The current stable version of patch (attached) have compile time
option to enable SMAP.*

A feature complete dynamic version is expected by the end of the
month, which patched the kernel on boot time, when the feautre
presented in CPU.

[1] http://lwn.net/Articles/517475/

patches: https://github.com/opntr/freebsd-patches-2013-tavasz
smap-test: https://github.com/opntr/freebsd-smap-tester

smap_disabled.gif:
Running smap-test without SMAP support: illegal user-space memory
address read/write from kernel-space.

smap_{read,write}.gif:
Running smap-test with SMAP: the kernel must paniced, due an illegal
read from user-space memory address.

* when you applied this patch and enabled the SMAP in kernel and your
CPU does not have SMAP support, the kernel _must_ paniced.
_______________________________________________
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"

[PATCH] Allow atomic sets of non-overlapping CPU sets for a global cpuset

John Baldwin — 2013-05-31T16:16:56

So there's an oddity with cpuset I've run into recently at work.  Suppose I 
have created a new cpuset and want to change the set of CPUs for that set (say 
from a mask of just CPU 1 to a mask of just CPU 2).  I can't do that 
atomically.  I have to first set the mask to contain both the old set (CPU 1) 
and the new set (CPU 2) and then change it a second time to only contain the 
new set (CPU 2).  The reason is that cpuset_modify() runs cpuset_testupdate() 
on the set it is about to modify, so when I try to change it in a single 
operation the new mask doesn't overlap with the old mask and it fails with 
EDEADLK.

% cpuset -c -l 1 /bin/sh
$ cpuset -gi
pid -1 cpuset id: 2
$ cpuset -g
pid -1 mask: 1
$ cpuset -l 2 -s 2
cpuset: setaffinity: Resource deadlock avoided

I think that the correct logic here is that we should only check descendants 
of the set we are changing, but not the set we are about to change.  The patch 
does this and allows my test case above to work:

Index: kern_cpuset.c
===================================================================
--- kern_cpuset.c(revision 251132)
+++ kern_cpuset.c(working copy)
< at >< at > -303,7 +303,7 < at >< at > cpuset_create(struct cpuset **setp, struct cpuset
  * empty as well as RDONLY flags.
  */
 static int
-cpuset_testupdate(struct cpuset *set, cpuset_t *mask)
+cpuset_testupdate(struct cpuset *set, cpuset_t *mask, int check_mask)
 {
 struct cpuset *nset;
 cpuset_t newmask;
< at >< at > -312,13 +312,16 < at >< at > static int
 mtx_assert(&cpuset_lock, MA_OWNED);
 if (set->cs_flags & CPU_SET_RDONLY)
 return (EPERM);
-if (!CPU_OVERLAP(&set->cs_mask, mask))
-return (EDEADLK);
-CPU_COPY(&set->cs_mask, &newmask);
-CPU_AND(&newmask, mask);
+if (check_mask) {
+if (!CPU_OVERLAP(&set->cs_mask, mask))
+return (EDEADLK);
+CPU_COPY(&set->cs_mask, &newmask);
+CPU_AND(&newmask, mask);
+} else
+CPU_COPY(mask, &newmask);
 error = 0;
 LIST_FOREACH(nset, &set->cs_children, cs_siblings) 
-if ((error = cpuset_testupdate(nset, &newmask)) != 0)
+if ((error = cpuset_testupdate(nset, &newmask, 1)) != 0)
 break;
 return (error);
 }
< at >< at > -370,11 +373,11 < at >< at > cpuset_modify(struct cpuset *set, cpuset_t *mask)
 if (root && !CPU_SUBSET(&root->cs_mask, mask))
 return (EINVAL);
 mtx_lock_spin(&cpuset_lock);
-error = cpuset_testupdate(set, mask);
+error = cpuset_testupdate(set, mask, 0);
 if (error)
 goto out;
+CPU_COPY(mask, &set->cs_mask);
 cpuset_update(set, mask);
-CPU_COPY(mask, &set->cs_mask);
 out:
 mtx_unlock_spin(&cpuset_lock);

Sjournals Services (Open Journal Management system, Sjournals Index, ...)

Sjournals — 2013-05-29T13:32:33

   Dear Researchers

   We provide high quality services and strive to ease all steps from
   submission to publication of high quality research work.

   1.       [1]Sjournals Manager (FREE of charge)

   The [2]Sjournals Manager manages the overall publishing system. The
   [3]Sjournals Manager does the setup for the journal, and enrolls the
   Editors, Section Editors, Copyeditors, Layout Editors, Proofreaders,
   and Reviewers. The [4]Sjournals Manager cordially invites you to join
   the peer reviewed journals of the Open Journal Management system and
   help us to produce good quality research in your area of expertise.
   With Sjournals Manager you can easily start your own journal. Scholars,
   institutions, conference organizers and scientific societies can all
   propose and launch new scientific journals.

   2.       Call for Paper (Vol 2 | Issue 6 | June 2013)

   We invite you to submit your manuscript(s)
   at [5]http://www.sjournals.com  for rapid publication (via online
   submission system). Our objective is to inform author(s) of the
   decision on their manuscript (s) within one week of submission (All of
   Fields).

   Some of Indexing/Abstracting

   DOAJ, CABI Abstract, Global health, TEEAL (Cornell University), HINARI,
   CAS, ISC, Genamic JournalSeek, JournalTOCs, Academic Journals Database,
   PKP, Google scholar, SCIRUS, Index Copernicus, Academic keys,
   ResearchBib, Newjour, Electronic journals library, WorldCat, ProQuest,
   Open J-gate, library information service, GIF, Free journals act, etc.

   Submit your thesis abstract (*FREE*)

   Abstracts of all Master, Doctoral thesis will be submitted for
   inclusion in Sjournals Thesis, an online database used by researchers
   around the world. ST can be searched by author name, subject terms, and
   all words in the title and abstract.

   3.       [6]Sjournals Index (FREE of charge)

   The [7]Sjournals Index provides quantitative and qualitative tool for
   ranking, evaluating and categorizing the journals for academic
   evaluation and excellence. This factor is used for evaluating the
   prestige of journals. The evaluation is carried out by considering the
   factors like peer review originality, scientific quality, technical
   editing quality, editorial quality and regularity.

   4.       [8]Sjournals Conference Management System (FREE of charge)

   [9]Sjournals Conference Management System (SCMS) is a Web publishing
   tool that will create a complete Web presence for your scholarly
   conference.

   Don't hesitate to contact us if you have any questions.

    ---

    Kind Regards

    Sjournals Team

    Email: [10]Onlinesjournals< at >gmail.com

                 [11]Onlinesjournals< at >yahoo.com

   [12]www.sjournals.com

   [13]www.sjournals.net

   [14]http://sjournals.net/ojs/index.php/index/about (Sjournals Manager)

   [15]http://sjournals.net/onlineconferencesystem/ (Sjournals Conference
   Management System)

   [16]http://sjournals.net/sjournalsindex (Sjournals Index)

     ---------------------------------------------------------------------
   -----------------------------------
   P Think Green - don't print this email unless you really need to

References

   1. http://sjournals.net/ojs/
   2. http://sjournals.net/ojs/
   3. http://sjournals.net/ojs/
   4. http://sjournals.net/ojs/
   5. http://www.sjournals.com/
   6. http://sjournals.net/sjournalsindex/
   7. http://sjournals.net/sjournalsindex/
   8. http://sjournals.net/onlineconferencesystem
   9. http://sjournals.net/onlineconferencesystem
  10. mailto:Onlinesjournals< at >gmail.com
  11. mailto:Onlinesjournals< at >gmail.com
  12. http://www.sjournals.com/
  13. http://www.sjournals.net/
  14. http://sjournals.net/ojs/index.php/index/about
  15. http://sjournals.net/onlineconferencesystem/
  16. http://sjournals.net/sjournalsindex
_______________________________________________
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"

[RFC] add NetBSD compat macros to sys/cdefs.h

Garrett Cooper — 2013-05-28T02:21:20

Hi,
    One of the things that I've done in order to reduce unnecessary
divergence when porting NetBSD testcases to FreeBSD is I've pushed a
few macros into my sys/cdefs.h in order to facilitate compatibility
with NetBSD:

/* NetBSD compat */
/*
 * The following macro is used to remove const cast-away warnings
 * from gcc -Wcast-qual; it should be used with caution because it
 * can hide valid errors; in particular most valid uses are in
 * situations where the API requires it, not to cast away string
 * constants. We don't use *intptr_t on purpose here and we are
 * explicit about unsigned long so that we don't have additional
 * dependencies.
 */
#define __UNCONST(a)    ((void *)(unsigned long)(const void *)(a))

#define ___STRING(x)            __STRING(x)
#define __arraycount(__x)       (sizeof(__x) / sizeof(__x[0]))
/* End NetBSD compat */

To clarify...
- I know __UNCONST is basically like __DECONST on steroids as
__UNCONST doesn't have the typecasting like __DECONST does.
- I'm working at removing the need for ___STRING with upstream.
- I know that __arraycount is equivalent to nitems.

    The reason why I'm doing this is to reduce divergence and get
things going ASAP with the testing effort as I have a couple thousand
testcases ported from NetBSD which will be hooked into release images
(really soon) and will result in automated testing (not too far away,
potentially a couple months), versus the zero coverage we currently
have in FreeBSD. If _anyone_ has a better idea and is willing to pony
up the patch to make things more sane, please by all means do.
    I would prefer not to use libnetbsd as it just introduces
unnecessary churn in Makefiles and dependencies on a compat library
strictly for a couple of C macros.
    Thoughts?
Thanks!
-Garrett
_______________________________________________
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"

x86 IOMMU support (DMAR)

Konstantin Belousov — 2013-05-27T10:58:44

For the several months, I worked (and continue the work now) on the
driver for the Intel VT-d for FreeBSD.  The VT-d is sold as the I/O
Virtualization technology, but in essence it is a DMA addresses
remapping engine, i.e. it is advanced and improved I/O MMU, as also
found on other big-iron machines, e.g. PowerPC or Sparc.  See the
Intel document titled 'Intel Virtualization Technology for Directed
I/O Architecture Specification' and chipsets datasheets for the
description of the facility.

The development was greatly facilitated by Jim Harris from Intel who
provided me the access to the Sandy and Ivy Bridge north bridge
documentation.  John Baldwin patiently educated me about newbus and
helped developing required hooks for integration with the existing
code.

The core hardware element of the VT-d is DMA remap unit, referenced as
DMAR both in the documentation and in the source code.  Besides DMA
remap, VT-d also allows to do remapping of the MSI/MSI-X interrupt
messages.  FreeBSD could utilize the functionality for the interrupt
rebalancing, instead of reprogramming msi registers of the PCI
devices, but this part is not (yet) implemented.

For the FreeBSD architecture, DMAR naturally fits as busdma engine,
making it possible to eliminate bounce page copying.  Another great
benefit of the DMAR use is the reliability and security improvements,
since DMA transfers are only allowed to the memory areas explicitely
designated by the device driver as buffers.  As noted by Jim Harris,
this security angle could find a use in the NTB driver.

The existing busdma code for x86 was split into generic interface,
kept in the busdma_machdep.c, and bouncing implementation in the
busdma_bounce.c.  The DMAR-based implementation, which calls the DMAR
core, is located in the busdma_dmar.c.  There is no KPI provided to
manage DMARs, but I plan to implement the proper interface after
discussing the needs of the bhyve.

I tried to support both i386 and amd64, but for i386 the limited KVA,
together with the busdma interface structure of never sleeping from
the driver calls, make some promises of IOMMU less strict.  For
instance, to unload the map, code needs to transiently map the DMAR
page table pages, which require sleepable allocations of sf buffers.
As result, map unload on i386 is done asynchronously in the taskqueue
context, which makes it possible for the buggy device driver or
hardware to perform the transfer to freed pages for some time after
unload.  This problem is not present for amd64 port.  For the same
reason of busdma KPI, I cannot use queued invalidation both for i386
and amd64.

At the moment the code makes the 1:1 relations between device contexts
and domains, which is fine for busdma.  To support PCI pass-through
into the virtualized machines, the relations should be changed to N:1
contexts to domains, which is planned but currently is not yet done.

Overall state of the code is that I can boot multiuser over the
network from if_igb(4) or if_bce(4), and can use ahci(4) and ata(4)
attached disks without corrupting UFS volumes.  Uhci(4) has known
issues due to too late establishment of the RMRR mappings.  Extensive
testing of the already written code is not done yet.  Plans include
- providing the external KPI for the VMM consumers
- support ATS
- making it possible to select busdma_dmar or busdma_bounce for
  individual PCI functions
- the stabilization work.
Also, by converting the ISA DMA implementation to use the busdma KPI,
it is possible to make the floppies work reliably again !

It is known that IOMMU adds overhead due to the mapping and unmapping
for each I/O.  DMAR implementations usually have some erratas, as well
as PCIe devices sometime do not completely follow the specification,
causing misbehaviour with remapping enabled.  For this reason I do not
plan to enable IOMMU by default, and intend to provide a possibility
to route individual PCI devices to the bounce busdma implementation.

http://people.freebsd.org/~kib/misc/DMAR.1.patch

interrupt threads

Orit Moskovich — 2013-05-26T06:16:39

Hi,

I'm trying to understand the difference between using taskqueues defined by ithreads (taskqueue_swi, taskqueue_swi_giant, taskqueue_fast) to defer an interrupt's work, and defining an interrupt handler to give as ithread parameter to bus_setup_intr.
Is there a difference in the priority? Which of the methods is preferable when writing a network device and performance is important?

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"

binmiscctl(8) (and imgact_binmisc kernel module)

Stacey Son — 2013-05-22T22:17:29

Hi all:

I added a command-line utility called 'binmiscctl' for the imgact_binmisc kernel module that I previously proposed on this list.  As you may recall, imgact_binmisc is an image activator for miscellaneous binary file types that are executed with the help of a user-level interpreter or emulator.  It has been proposed that imgact_binmisc be added to the kernel as a module.  The main reason I created this is to support cross building packages using qemu user mode (see my dev summit slides at http://people.freebsd.org/~sson/imgact_binmisc/20130515-bsdcan-xbuild-ports.pdf) but there are a lot of other applications for this module as well.  For example, Nathan Whitehorn previously proposed on this list a similar code change (but much less general) to support transparently execute  LLVM bitcode using the 'lli' JIT compiler.  This kernel module if flexible enough that it supports that as well.

Baptiste has also added support in poudrière for cross-building mips64 packages in a "cross jail" using qemu user mode.  See his slides from BSDCan 2013 (pg. 7):

http://people.freebsd.org/~bapt/modern-package-management.pdf

Bapt mentioned that he built over 10,000 mips64 packages in about 30 hours.  Of course, this is before adding imgact_binmisc which greatly improves the cross build speed by allowing both native (amd64) cross build tools to be used along with emulated mips64 binaries in a hybrid fashion.  With my limited testing of cross building a handful of ports the overhead compared to building the port natively on a commodity amd64 host is 2x to 4x using this kernel module.  Without the module the overhead is 10x or much more.

The recently added 'binmiscctl' command-line utility allows for easy configuration and management of the image activators in this imgact_binmisc kernel module.   For example, to add an image activator for qemu-mips64 (the qemu user mode emulator for mips64):

# binmiscctl add mips64elf --interpreter "/usr/local/bin/qemu-mips64" --magic \ "\x7f\x45\x4c\x46\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08" \
--mask "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff" --size 20 --set-enabled

To disable the above without removing it from the module's activator list:

# binmiscctl disable mips64elf

To enable:

# binmiscctl enable mips64elf

To remove from the module's activator list:

# binmiscctl remove mips64elf

To lookup and print out the activator entry:

# binmiscctl lookup mips64elf

name: mips64elf
interpreter: /usr/local/bin/qemu-mips64
flags: ENABLED USE_MASK 
magic size: 20
magic offset: 0
magic: 0x7f 0x45 0x4c 0x46  0x02 0x02 0x01 0x00  0x00 0x00 0x00 0x00 
                   0x00 0x00 0x00 0x00  0x00 0x02 0x00 0x08 
mask:  0xff 0xff 0xff 0xff  0xff 0xff 0xff 0x00  0xff 0xff 0xff 0xff 
           0xff 0xff 0xff 0xff  0xff 0xfe 0xff 0xff 

To take a snapshot and list all the activators 

# binmiscctl list

name: mips64elf
[...]

To add an image activator for LLVM bitcode JIT lli(1) compiler:

# binmiscctl add llvmbc --interpreter ''/usr/bin/lli --fake-argv0=#a'' \
     --magic ''BC\xc0\xde'' --size 4 --set-enabled

Note the "#a", in the above example, is replaced with the old argv0 value so lli(1) can use it to fake the argv0 as described in the lli(1) man page.

The source code, man page, and diff to add it to the source tree can be found at:

http://people.freebsd.org/~sson/imgact_binmisc/

Of course, comments, suggestions, concerns, detailed code reviews, etc. are welcome.

Best Regards,

-stacey.
_______________________________________________
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"

compatibility layer - workqueues

Orit Moskovich — 2013-05-21T04:56:20

Hi,

I'm working on understanding the difference between Linux and FreeBSD interrupt handling.
I looked at the compatibility layer and noticed this:


*         Linux workqueues are implemented using FreeBSD taskqueues (under sys/ofed/include/linux/workqueue.h)

*         In linux, the function schedule_work() puts a job in the kernel global workqueue 'events'. This workqueue consists of worker threads - one per processor

*         The compatibility layer wraps this function to a macro, that implements the functionality using taskqueue_enqueue() and set it to work on taskqueue_thread, that executes its tasks in the context of a kernel thread

*         BUT,  taskqueue_thread is initialized in:

o   sys/kern/subr_taskqueue.c  line 536:
TASKQUEUE_DEFINE_THREAD(thread);

o   which is defined in sys/taskqueue.h line 133
and run taskqueue_start_threads() with only 1 thread, and not MAXCPU



I'll appreciate your help understanding 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"

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"

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"

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"

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

Garrett Cooper — 2013-05-07T20:05:07

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
_______________________________________________
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"

Extending MADV_PROTECT

John Baldwin — 2013-05-07T18:33:27

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 <sys/cdefs.h>
__FBSDID("$FreeBSD");

#include <sys/types.h>
#include <sys/mman.h>
#include <err.h>
#include <errno.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

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)
< 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_NULLNOPROTO{ int pprotect(int op, pid_t pid); }
Index: sys/kern/syscalls.master
===================================================================
--- sys/kern/syscalls.master(revision 251038)
+++ sys/kern/syscalls.master(working copy)
< at >< at > -938,5 +938,17 < 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 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)
< at >< at > -143,6 +143,22 < at >< at >
 #defineMINCORE_SUPER0x20 /* Page is a "super" page */
 
 /*
+ * Operations for pprotect().
+ */
+#definePPROT_OP_MASK(0xf)
+#definePPROT_SET0
+#definePPROT_CLEAR1
+#definePPROT_OP(x)((x) & PPROT_OP_MASK)/* Base operation. */
+
+/*
+ * Flags for pprotect (ORed in with operation).
+ */
+#definePPROT_FLAG_MASK(~PPROT_OP_MASK)
+#definePPROT_DESCEND0x10
+#definePPROT_INHERIT0x20
+#definePPROT_FLAGS(x)((x) & PPROT_FLAG_MASK)
+
+/*
  * Anonymous object constant for shm_open().
  */
 #defineSHM_ANON((char *)1)
< at >< at > -222,6 +238,7 < at >< at >
 intmadvise(void *, size_t, int);
 intmincore(const void *, size_t, char *);
 intminherit(void *, size_t, int);
+intpprotect(int, pid_t);
 #endif
 intmlock(const void *, size_t);
 #ifndef _MMAP_DECLARED
Index: sys/sys/syscallsubr.h
===================================================================
--- sys/sys/syscallsubr.h(revision 251038)
+++ sys/sys/syscallsubr.h(working copy)
< at >< at > -154,6 +154,7 < at >< at >
     int advice);
 intkern_posix_fallocate(struct thread *td, int fd, off_t offset,
     off_t len);
+intkern_pprotect(struct thread *td, int op, pid_t pid);
 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/vm/vm_mmap.c
===================================================================
--- sys/vm/vm_mmap.c(revision 251038)
+++ sys/vm/vm_mmap.c(working copy)
< at >< at > -63,6 +63,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 +669,13 < at >< at >
 {
 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
  */
< at >< at > -1102,6 +1093,154 < at >< at >
 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)
< at >< at > -366,6 +366,7 < at >< at >
 
 FBSD_1.3 {
 posix_fadvise;
+pprotect;
 };
 
 FBSDprivate_1.0 {

Building library that depends on another library.

Pawel Jakub Dawidek — 2013-05-05T20:14:36

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=${LIBNV}
LDADD=-lnv

(LIBNV was added to bsd.libnames.mk, in case you wonder.)

From conversation with kan< at > (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 <OBJDIR>/lib/libnv/,
but of course not in <OBJDIR>/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=${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?