From owner-freebsd-arch@FreeBSD.ORG Sun Apr 28 12:06:23 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8F3165B4; Sun, 28 Apr 2013 12:06:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id F3A5E12D1; Sun, 28 Apr 2013 12:06:22 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id r6so649845wey.31 for ; Sun, 28 Apr 2013 05:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nHBX0Ao7QhvjMdTv4z+ffF6PD5WZEjoKkGDk0Hnu94w=; b=ox2PW6GgFyZCz1g3/ywJrU3jaWJh3PGeQgVBnOS7uWwN9ElsYu+w3c2eNmbeTLpbUG tTqKDHPoq//PjRjYdRx9FY8EF67JuNmr1IsOg46mGlLcnhthXiM5tlhm+J9pYbLNUn1l pnXQ094U7DAOK73t2LL3GqxtLhbXsnteZFmFJMLjETmM2yQR3SPy3WFGVpAZ7lWdC/YR kymGq/LuAGN+CtFjGKGlhuBr6qCjGtyE9zcqAY68qpVUqytG4z25ekMW+6LMBPzuKe5s 4okW+npWDakpR7uidu3fQtDn74m9cHkzBy8V8CgaSK/fh+aTt4ODRBIVoPRn7FVGkzza xLNg== MIME-Version: 1.0 X-Received: by 10.180.87.170 with SMTP id az10mr12576854wib.3.1367150782058; Sun, 28 Apr 2013 05:06:22 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Sun, 28 Apr 2013 05:06:21 -0700 (PDT) In-Reply-To: <20130228172318.GB20864@lor.one-eyed-alien.net> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227190804.GB17489@lor.one-eyed-alien.net> <13FB8CB0-9937-4BD8-AE89-0D24494D8663@bsdimp.com> <20130227214445.GA19594@lor.one-eyed-alien.net> <1CC1DB5A-E87A-456C-AD2C-E203146BB736@bsdimp.com> <20130227221552.GC19594@lor.one-eyed-alien.net> <20130228000241.GF19594@lor.one-eyed-alien.net> <20130228172318.GB20864@lor.one-eyed-alien.net> Date: Sun, 28 Apr 2013 05:06:21 -0700 X-Google-Sender-Auth: 8VT5d0OadmSe-ZuY1H-SgFuKmAw Message-ID: Subject: Re: [RFC] external compiler support From: Adrian Chadd To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 12:06:23 -0000 Hi, On 28 February 2013 09:23, Brooks Davis wrote: >> Here's another version that addresses those comments. I decided to > rename CROSS_*_PATH to CROSS_*_PREFIX because it offended my > sensibilities to call something that may not refer to a filesystem > object a path. > So I'd like to use this with gcc-4.7 or later, specifically to use a mips24k and mips74k targeting cross compiler. Apparently the later gcc compilers generate much tighter mips assembly and I'd like to test this theory out. Since i haven't had to this manually in a long, long time, does someone have a howto/example for how to install a cross-compiler from ports, then make this patch use it for building? I think (?) that generating mips74k code requires a new set of binutils (for any added instructions) but I'm not 100% on that. Again, this is uncharted territory. I'll give this more of a whirl (and test the resulting built components!) if I can get a little hand-holding here. thanks! Adrian From owner-freebsd-arch@FreeBSD.ORG Mon Apr 29 05:02:18 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6752553E for ; Mon, 29 Apr 2013 05:02:18 +0000 (UTC) (envelope-from contact@ijtemt.org) Received: from ns96.Host1.yourdomainname.com (50.22.181.244-static.reverse.softlayer.com [50.22.181.244]) by mx1.freebsd.org (Postfix) with ESMTP id 5245514EC for ; Mon, 29 Apr 2013 05:02:18 +0000 (UTC) X-Sender: "Editor IJTEMT" X-Receiver: freebsd-arch@freebsd.org From: "Editor IJTEMT" To: freebsd-arch@freebsd.org Date: 28 Apr 2013 21:59:38 -0700 Subject: Call for Papers IJTEMT. Kindly impart in your University/Organization/College/Colleagues/Academia/Circle. Priority: urgent Importance: normal Message-Id: <20130429050218.6752553E@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Editor IJTEMT List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 05:02:18 -0000 INTERNATIONAL JOURNAL OF TRENDS IN ECONOMICS MANAGEMENT & TECHNOLOGY IJTEMT invites you to submit your research paper for publishing in Volume II, Issue II ( April 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: 30th April 2013 Review Results (Acceptance/Rejection) Notification: Within two weeks after submitting manuscript. Guidelines for submission and Review Process: IJTEMT welcomes author submission of papers concerning any branch of the economics, management and technology and their applications in business, industry and other subjects relevant. The review process goes through following phases which can take time from ten days to two months: a. Each manuscript will be initially evaluated by the editorial board / editor, who may make use of appropriate software to examine the originality of the contents of the manuscript. b. The manuscripts passed through screening at above noted level will be forwarded to two referees for blind peer review, each of whom will make a recommendation to publish the article in its present form/edit/reject. During this period referees shall treat the contents of papers under review as privileged information. c. The reviewers' recommendations determine whether a paper will be accepted / accepted subject to change / subject to resubmission with significant changes / rejected. d. For papers which require changes, the same reviewers will be used to ensure that the quality of the revised paper is acceptable. e. All papers are refereed, and the Editor-in-Chief reserves the right to refuse any typescript, whether on invitation or otherwise, and to make suggestions and/or modifications before publication. Submission of Paper will takes place in two phases: a. Initial Paper Submission: Prospective author (s) is/are encouraged to submit their manuscript including charts, tables, figures and appendixes in .pdf and .doc (both) format to e-mail: [1]submit@ijtemt.org. All submitted articles should report original, previously unpublished research results, experimental or theoretical. Articles submitted to the IJIMT should meet these criteria and must not be under consideration for publication elsewhere. b. Camera Ready Paper Submission:On the acceptance of the paper after completion of the review process the author (s) is/are has to submit camera ready full text paper in .doc and .pdf (both) format to e-mail: [2]submitfinal@ijtemt.org along with the corresponding signed copy of copyright transfer form and scanned copy of payment slip. Publication fees Each accepted paper will be charged, for publication and paper handling, 100 USD per paper (for a maximum of 8 pages, above which 10 USD will be charged for every additional page) which is to be paid as per the instructions mentioned in the letter of acceptance of the manuscript submitted. Editor International Journal of Trends in Economics Management & Technology Website: [3]www.ijtemt.org Email: [4]editor@ijtemt.org, [5]coedtech@ijtemt.org, [6]contact@ijtemt.org. Paper Submission Email: [7]submit@ijtemt.org. References 1. mailto:submit@ijtemt.org 2. mailto:submitfinal@ijtemt.org 3. http://www.ijtemt.org/ 4. mailto:editor@ijtemt.org 5. mailto:coedtech@ijtemt.org 6. mailto:contact@ijtemt.org 7. mailto:submit@ijtemt.org From owner-freebsd-arch@FreeBSD.ORG Mon Apr 29 13:34:40 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 69E236EE; Mon, 29 Apr 2013 13:34:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail28.syd.optusnet.com.au (mail28.syd.optusnet.com.au [211.29.133.169]) by mx1.freebsd.org (Postfix) with ESMTP id 079D01560; Mon, 29 Apr 2013 13:34:39 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail28.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r3TDYUD3020661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Apr 2013 23:34:31 +1000 Date: Mon, 29 Apr 2013 23:34:30 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "Kenneth D. Merry" Subject: Re: patches to add new stat(2) file flags In-Reply-To: <20130426221023.GA86767@nargothrond.kdm.org> Message-ID: <20130429231638.N1440@besplex.bde.org> References: <20130307000533.GA38950@nargothrond.kdm.org> <20130307222553.P981@besplex.bde.org> <20130308232155.GA47062@nargothrond.kdm.org> <20130310181127.D2309@besplex.bde.org> <20130409190838.GA60733@nargothrond.kdm.org> <20130418184951.GA18777@nargothrond.kdm.org> <20130419215624.L1262@besplex.bde.org> <20130426221023.GA86767@nargothrond.kdm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Tre+H0rh c=1 sm=1 a=n2O7wv11oSwA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=YOiZBDKP_E4A:10 a=wjh2EmcBLpGD4jLuB4EA:9 a=CjuIK1q_8ugA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: arch@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 13:34:40 -0000 On Fri, 26 Apr 2013, Kenneth D. Merry wrote: I haven't looked at this much. Just a quick reply since I will be away for a while. > On Fri, Apr 19, 2013 at 22:53:50 +1000, Bruce Evans wrote: >> On Thu, 18 Apr 2013, Kenneth D. Merry wrote: >> >>> On Tue, Apr 09, 2013 at 13:08:38 -0600, Kenneth D. Merry wrote: >>>> ... >>>> Okay, I think these issues should now be fixed. We now refuse to change >>>> attributes only on the root directory. And I updatd deupdat() to do the >>>> same. >>>> >>>> When a directory is created or a file is added, the archive bit is not >>>> changed on the directory. Not sure if we need to do that or not. (Simply >>>> changing msdosfs_mkdir() to set ATTR_ARCHIVE was not enough to get the >>>> archive bit set on directory creation.) >>> >>> Bruce, any comment on this? >> >> I didn't get around to looking at it closely. Just had a quick look at >> the msdosfs parts. >> >> Apparently we are already doing the same as WinXP for ATTR_ARCHIVE on >> directories. Not the right thing, but: >> - don't set it on directory creation >> - don't set it on directory modification >> - allow setting and clearing it (with your changes). Further testing showed the same behaviour for ntfs under WinXP (you can manage all the attribute bits for directories, but they don't control anything for directories, at least using Cygwin utilities). About not setting the archive bit in for modifications of directories in msdosfs: most settings of this bit are managed by the DETIMES() macro. It is set when the directory mtime is set (the denode is first marked for update of the mtime -- DE_UPDATE flag). But since modifications of directories don't change the mtime (we are bug for bug compatible with Win/DOS here), this never sets the archive bit for directories. The mtime can be changed for directories using utimes() in my version but not in -current, and using some Win/DOS syscall. I'm setting the archive bit for this, but will change to be bug for bug compatible with Win/DOS by not setting it. Then only chflags will set it for directories. >> @ *** src/lib/libc/sys/chflags.2.orig >> @ --- src/lib/libc/sys/chflags.2 >> @ *************** >> @ *** 112,137 **** >> @ ... >> @ --- 112,170 ---- >> @ ... >> @ + .It Dv UF_IMMUTABLE >> @ + The file may not be changed. >> @ + Filesystems may use this flag to maintain compatibility with the DOS, >> Windows >> @ + and CIFS FILE_ATTRIBUTE_READONLY attribute. >> >> msdosfs doesn't use this yet. It uses ATTR_READONLY, and doesn't map this >> to or from UF_IMMUTABLE. I think I want ATTR_READONLY to be a flag and >> not affect the file permissions (just like immutable flags normally don't >> affect the file permissions. > > Okay, done. The permissions are now always 755, and writeability is > controlled by ATTR_READONLY. Should be 755 by default, but there is a mount option to change this. >> Does CIFS FILE_ATTRIBUTE_READONLY have exactly the same semantics as >> IMMUTABLE? That is, does it prevent all operations on the file and the >> ... > Okay. I added a new flag, UF_READONLY that maps to ATTR_READONLY directly > instead of using an immutable flag. > ... > The other outstanding issue is the suggestion by Gordon Ross on the Illumos > developers list to make ZFS not enforce the readonly bit. It looks like it > has not yet gone into Illumos. We may not want to make the change in > FreeBSD since it hasn't gone in upstream yet. This shows that we want to not enforce the readonly bit (or other flags) even for msdosfs. msdosfs is a good place to test changing the policy since there aren't many critical file systems using it. Bruce From owner-freebsd-arch@FreeBSD.ORG Wed May 1 23:11:58 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 736EBCF6 for ; Wed, 1 May 2013 23:11:58 +0000 (UTC) (envelope-from sson@FreeBSD.org) Received: from ns1.son.org (son.org [65.48.68.179]) by mx1.freebsd.org (Postfix) with ESMTP id 3CB4E1833 for ; Wed, 1 May 2013 23:11:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ns1.son.org (Postfix) with ESMTP id 7511F1EC2351 for ; Wed, 1 May 2013 18:03:05 -0500 (CDT) Received: from ns1.son.org ([127.0.0.1]) by localhost (ns1.dev-random.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3CAZAca09Ma for ; Wed, 1 May 2013 18:03:03 -0500 (CDT) Received: from [192.168.0.12] (cpe-76-187-137-252.tx.res.rr.com [76.187.137.252]) by ns1.son.org (Postfix) with ESMTP id E94ED1EC2348 for ; Wed, 1 May 2013 18:03:02 -0500 (CDT) From: Stacey Son Subject: A General or Miscellaneous Binary Image Activator Date: Wed, 1 May 2013 18:02:49 -0500 Message-Id: <71BF89C0-13F9-41CA-9F7E-A3FDE11C2346@FreeBSD.org> To: freebsd-arch@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 23:11:58 -0000 Hi All, I have written a miscellaneous (or general) binary interpreter image = activator to support cross building mips64 ports using user mode qemu. = The source code can be found at: http://people.freebsd.org/~sson/imgact_binmisc/imgact_binmisc.h http://people.freebsd.org/~sson/imgact_binmisc/imgact_binmisc.c I just saw Nathan Whitehorn's posting 'LLVM Image Activator' on this = same list and hope we are not duplicating work. Like Nathan's this code = invokes a user-level interpreter or emulator when it recognizes the = magic bytes in a header of a binary. Unlike Nathan's it is much more = general purpose. It does this by using a magic field that may be up to = 'IBE_MAGIC_MAX' (or 256) bytes long , an offset value in the binary, = and, optionally, a bit mask field the same size as the magic field that = can mask out and ignore any of the bits in the magic. Therefore, it is = very flexible in supporting binary file types which I needed to figure = out the arch for ELF files. Of course, image activators have been a source for security issues. If = this or something like this is include in the kernel then I would = recommend it be optional. It has proven to be very useful for creating = a mixed arch cross build environment. This allows running things like = the cross compiler/toolchain and /bin/sh natively on the host system = which significantly helps performance. Using this, and the user mode = qemu port I have been working on, I have successfully cross built well = over 9000 mips64 packages from ports using an old amd64 athlon (FYI, see = https://wiki.freebsd.org/QemuUserModeHowTo for more information about = user mode qemu). It is configured from user space using sysctl(3). For example, the = following is for adding an activator that runs mips64 executables on an = amd64 host using "user mode" qemu: #include #define MIPS64_ELF_MAGIC = "\x7f\x45\x4c\x46\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\= x00\x08" #define MIPS64_ELF_MASK = "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\= xff\xff" ximgact_binmisc_entry_t xbe;=20 xbe.xbe_version =3D IBE_VERSION; xbe.xbe_command =3D IBC_ADD; xbe.xbe_flags =3D IBF_ENABLED | IBF_USE_MASK; strlcpy(xbe.xbe_name, "mips64elf", (IBE_NAME_MAX - 1)); strlcpy((xbe.xbe_interpreter, "/usr/local/bin/qemu-mips64", (MAXPATHLEN = -1)); xbe.xbe_offset =3D 0; xbe.xbe_size =3D sizeof(MIPS64_ELF_MAGIC) - 1; memcpy(xbe.xbe_magic, MIPS64_ELF_MAGIC, xbe.xbe_size); memcpy(xbe.xbe_mask, MIPS64_ELF_MASK, xbe.xbe_size); int ret =3D sysctlbyname("kern.binmisc", NULL, NULL, &xbe, = sizeof(xbe)); To disable/enable/delete the above entry in the kernel: xbe.xbe_version =3D IBE_VERSION; xbe.xbe_command =3D IBC_DISABLE; // or IBC_ENABLE or IBC_DELETE strlcpy(xbe.xbe_name, "mips64elf", (IBE_NAME_MAX - 1)); int ret =3D sysctlbyname("kern.binmisc", NULL, NULL, &xbe, sizeof(xbe)); To list all the interperter entries that are currently configured: ximagact_binmisc_list_t xbl; size_t xbe_size =3D sizeof(xbe); size_t xbl_size =3D sizeof(xbl); xbe.xbe_version =3D IBE_VERSION; xbe.xbe_command =3D IBC_LIST; sysctlbyname("kern.binmisc", &xbl, &xbl_size, &xbe, sizeof(xbe)); for(int i =3D 0; i < xbl.xbl_count; i++) { =09 xbe.xbe_version =3D IBE_VERSION; xbe.xbe_command =3D IBC_LOOKUP; =09 strlcpy(xbe.xbe_name, xbl.xbl_names[i], (IBE_NAME_MAX - 1)); =09 ret =3D sysctlbyname("kern.binmisc", &xbe, &xbe_size, &xbe, = sizeof(xbe)); =09 if (!ret) { // 'xbe' contains an interperter entry from the kernel = for=09 // the given 'xbl.xbl_name[i]' name. } } The sysctlbyname() calls above may return the following errors in = addition to the one from sysctl(3): [EINVAL] Invalid argment in the input ximgact_binmisc_entry_t = structure. [EEXIST] Interpreter entry for given name already exist in kernel = list.=20 [ENOMEM] Allocating memory in the kernel failed. [ENOENT] Interpreter entry for given name is not found. [ENOSPC] Attempted to exceed maximum number of entries = (IBE_MAX_ENTRIES). Of course, comments, questions, concerns, etc. are welcome. Best Regards, -stacey. sson@FreeBSD.org= From owner-freebsd-arch@FreeBSD.ORG Thu May 2 16:39:36 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8D3C3133; Thu, 2 May 2013 16:39:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 689261810; Thu, 2 May 2013 16:39:36 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D1A62B911; Thu, 2 May 2013 12:39:34 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: A General or Miscellaneous Binary Image Activator Date: Thu, 2 May 2013 11:38:36 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <71BF89C0-13F9-41CA-9F7E-A3FDE11C2346@FreeBSD.org> In-Reply-To: <71BF89C0-13F9-41CA-9F7E-A3FDE11C2346@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201305021138.36554.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 02 May 2013 12:39:34 -0400 (EDT) Cc: Stacey Son X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 16:39:36 -0000 On Wednesday, May 01, 2013 7:02:49 pm Stacey Son wrote: > Of course, comments, questions, concerns, etc. are welcome. Certainly the ability to cross-build ports in this way is a huge win. I just have a few comments on the kern.binmisc sysctl: It seems to be a bit overloaded and not used like a typical sysctl. A better match would seem to be a /dev/binmisc that you perform ioctl's on. A sysctl might still make better sense for enumerating the interperter entries, but the more typical way to do that would either be to have kern.binmisc. be a sysctl that returns item in the list, or to have the kern.binmisc sysctl that just returns an array of xbe entries (rather than having separate list/lookup operations) similar to how the kern.proc sysctls work. If you were to do this, I would probably prefer the second approach (one sysctl that returns a consistent snapshot). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri May 3 03:16:09 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 45B16DAD; Fri, 3 May 2013 03:16:09 +0000 (UTC) (envelope-from sson@FreeBSD.org) Received: from ns1.son.org (son.org [65.48.68.179]) by mx1.freebsd.org (Postfix) with ESMTP id 0F53912FB; Fri, 3 May 2013 03:16:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ns1.son.org (Postfix) with ESMTP id D9DE71EC942B; Thu, 2 May 2013 22:16:14 -0500 (CDT) Received: from ns1.son.org ([127.0.0.1]) by localhost (ns1.dev-random.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17iYfY77C5cW; Thu, 2 May 2013 22:16:12 -0500 (CDT) Received: from [192.168.0.12] (cpe-76-187-137-252.tx.res.rr.com [76.187.137.252]) by ns1.son.org (Postfix) with ESMTP id 1630D1EC9423; Thu, 2 May 2013 22:16:11 -0500 (CDT) Subject: Re: A General or Miscellaneous Binary Image Activator Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Stacey Son In-Reply-To: <201305021138.36554.jhb@freebsd.org> Date: Thu, 2 May 2013 22:15:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <136ADFC2-D68F-4AE3-8186-4DF680C55E3E@FreeBSD.org> References: <71BF89C0-13F9-41CA-9F7E-A3FDE11C2346@FreeBSD.org> <201305021138.36554.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1283) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 03:16:09 -0000 On May 2, 2013, at 10:38 AM, John Baldwin wrote: > On Wednesday, May 01, 2013 7:02:49 pm Stacey Son wrote: >> Of course, comments, questions, concerns, etc. are welcome. >=20 > Certainly the ability to cross-build ports in this way is a huge win. = I just=20 > have a few comments on the kern.binmisc sysctl: >=20 > It seems to be a bit overloaded and not used like a typical sysctl. A = better=20 > match would seem to be a /dev/binmisc that you perform ioctl's on. A = sysctl=20 > might still make better sense for enumerating the interperter entries, = but the=20 > more typical way to do that would either be to have kern.binmisc. = be a=20 > sysctl that returns item in the list, or to have the kern.binmisc = sysctl=20 > that just returns an array of xbe entries (rather than having separate=20= > list/lookup operations) similar to how the kern.proc sysctls work. If = you=20 > were to do this, I would probably prefer the second approach (one = sysctl that=20 > returns a consistent snapshot). I changed the code so userland gets a snapshot of the interpreter table = much like kern.proc. See: http://people.freebsd.org/~sson/imgact_binmisc/imgact_binmisc.c http://people.freebsd.org/~sson/imgact_binmisc/imgact_binmisc.h Now the sysctl() interface as follows: #include #define LLVM_MAGIC "BC\xc0\xde" #define MIPS64_ELF_MAGIC \ = "\x7f\x45\x4c\x46\x02\x02\x01\x00\x00\x00"\x00\x00\x00\x00\x00\x00\x00\x02= \x00\x08" #define MIPS64_ELF_MASK \ = "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\= xff\xff" ximgact_binmisc_entry_t xbe, *xbep; size_t size =3D 0, osize; int error, i; // Add image activator for LLVM byte code=20 bzero(&xbe, sizeof(xbe)); xbe.xbe_version =3D IBE_VERSION; xbe.xbe_flags =3D IBF_ENABLED; strlcpy(xbe.xbe_name, "llvm_bc", IBE_NAME_MAX); strlcpy(xbe.xbe_interpreter, "/usr/bin/lli", MAXPATHLEN); xbe.xbe_moffset =3D 0; xbe.xbe_msize =3D sizeof(LLVM_MAGIC) - 1; memcpy(xbe.xbe_magic, LLVM_MAGIC, xbe.xbe_msize); error =3D sysctlbyname("kern.binmisc.add", NULL, NULL, &xbe, = sizeof(xbe)); // Add image activator for mips64 ELF binaries to use qemu user mode bzero(&xbe, sizeof(xbe)); xbe.xbe_version =3D IBE_VERSION; xbe.xbe_flags =3D IBF_ENABLED | IBF_USE_MASK; strlcpy(xbe.xbe_name, "mips64elf", IBE_NAME_MAX); strlcpy(xbe.xbe_interpreter, "/usr/local/bin/qemu-mips64", MAXPATHLEN); xbe.xbe_moffset =3D 0; xbe.xbe_msize =3D sizeof(MIPS64_ELF_MAGIC) - 1; memcpy(xbe.xbe_magic, MIPS64_ELF_MAGIC, xbe.xbe_msize); memcpy(xbe.xbe_mask, MIPS64_ELF_MASK, xbe.xbe_msize); sysctlbyname("kern.binmisc.add", NULL, NULL, &xbe, sizeof(xbe)); // Disable (OR Enable OR Delete) image activator for LLVM byte code bzero(&xbe, sizeof(xbe)); xbe.xbe_version =3D IBE_VERSION; strlcpy(xbe.xbe_name, "llvm_bc", IBE_NAME_MAX); error =3D sysctlbyname("kern.binmisc.disable", NULL, NULL, &xbe, = sizeof(xbe)); // OR sysctlbyname("kern.binmisc.enable", NULL, NULL, &xbe, = sizeof(xbe)); // OR sysctlbyname("kern.binmisc.delete", NULL, NULL, &xbe, = sizeof(xbe)); // Get all the currently configured image activators and report error =3D sysctlbyname("kern.binmisc.getall", 0, &size, NULL, 0); if (0 =3D=3D error && size > 0) { xbep =3D malloc(size); while(1) { osize =3D size; error =3D sysctlbyname("kern.binmisc.getall", xbep, &size, = NULL, 0); if (-1 =3D=3D error && ENOMEM =3D=3D errno && size =3D=3D = osize) { // The buffer too small and needs to grow size +=3D sizeof(xbe);=20 xbep =3D realloc(xbep, size); } else break; } } for(i =3D 0; i < (size / sizeof(xbe)); i++, xbep++) printf("name: %s interpreter: %s flags: %s%s\n", xbep->xbe_name, xbep->xbe_interpreter, (xbep->xbe_flags & IBF_ENABLED) ?=20 "ENABLED" : "", (xbep->xbe_flags & IBF_ENABLED) ? " = USE_MASK" : ""); The sysctlbyname() calls above may return the following errors: [EINVAL] Invalid argment in the input ximgact_binmisc_entry_t = structure. [EEXIST] Interpreter entry for given name already exist in kernel = list.=20 [ENOMEM] Allocating memory in the kernel failed or, in the case of kern.binmisc.getall, the user buffer is too small. [ENOENT] Interpreter entry for given name is not found. [ENOSPC] Attempted to exceed maximum number of entries = (IBE_MAX_ENTRIES). On May 1, 2013, at 6:02 PM, Stacey Son wrote: > Of course, image activators have been a source for security issues. = If this or something like this is include in the kernel then I would = recommend it be optional. Or, better yet, just simply build as a kernel module like I have done in = the following diff: =20 = http://people.freebsd.org/~sson/imgact_binmisc/imgact_binmisc.diff -stacey. sson@ From owner-freebsd-arch@FreeBSD.ORG Sat May 4 16:42:59 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 37DE77BE for ; Sat, 4 May 2013 16:42:59 +0000 (UTC) (envelope-from bounces+612829-ba58-arch=freebsd.org@sendgrid.info) Received: from o2.b99.sendgrid.net (o2.b99.sendgrid.net [208.115.214.177]) by mx1.freebsd.org (Postfix) with SMTP id DDB1F33E for ; Sat, 4 May 2013 16:42:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.me; h=from:to :subject:mime-version:content-type; s=smtpapi; bh=2knKxG7rQLeEQi P/H4MiuD0+KTA=; b=xh4U5Bsia0V36i7JEHaevKp5/qyNZpObNmtlldT1kzyWyI FHjTDlubdYAlJE7z6DLAyGrjZwMYD/qmeLhvvtwLi/OEDCHod9eH5ugyr9Jn8BwZ FxYxRzTZJqdar9m/siGoXMxbWBNftm4dDz9Wjv/NjI+InCU1gckA0Nz6gzBcs= Received: by 10.42.80.94 with SMTP id filter-028.28287.518538B46 Sat, 04 May 2013 16:35:00 +0000 (UTC) Received: from (ool-18e491e1.dyn.optonline.net [24.228.145.225]) by mi22 (SG) with ESMTP id 518538b4.692.124e102 for ; Sat, 04 May 2013 11:35:00 -0500 (CST) From: The Urban Shopper To: Date: Sat, 04 May 2013 12:35:03 -0400 Subject: Negro League Baller Recalls the Era, You Gotta Have Balls, Entrepreneurs, Recipes, Blogs... X-Mailer: TOL Mailer MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=_0_.__.__TOL__Mailer__Part_Boundary_ Message-ID: <1367685300.63899468271351536@filter-028> X-SG-EID: PYCKI43QWrQUfl7nqliIpR4qzPlu41Kt+60rv5InnxGJIy8/1vuUlsuNLzzUhSZ8gvOK5AXJz/GCqZ5IixmtJbb73z+fkcste/JMi44trknSI4Qk1NUQGehVfnN89iOs X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 16:42:59 -0000 This is a multi-part message in MIME format. --_0_.__.__TOL__Mailer__Part_Boundary_ Content-Type: multipart/related; boundary=_1_.__.__TOL__Mailer__Part_Boundary_ --_1_.__.__TOL__Mailer__Part_Boundary_ Content-Type: text/plain Content-Transfer-Encoding: 7Bit The Urban Shopper | May 2013
Negro League Player Recalls Era

kwanzaa kitchen

COOKING CONTEST

We're calling for original recipes that celebrate the spirit of Kwanzaa

3 Category Winners
Become a Co-Publisher
Share in Book Sale

ONLINE SUBMISSIONS ONLY

FOR MORE INFO
and OfficialRules

Win $750 Sunglasses Collection
You have received this update as a subscriber to TheUrbanShopper.com. ENSURE INBOX DELIVERY by adding us@theurbanshopper.com to your SAFE SENDER or email CONTACTS.
If you'd like to unsubscribe. For more information, please read our Privacy Policy. TAG, Inc. 7 Woodcliff Avenue, Woodcliff Lake, NJ 07677. © 2013 All Rights Reserved.
--_1_.__.__TOL__Mailer__Part_Boundary_-- --_0_.__.__TOL__Mailer__Part_Boundary_--