From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 24 03:23:15 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 777191065674; Sun, 24 Jul 2011 03:23:15 +0000 (UTC) (envelope-from jakub.klama@uj.edu.pl) Received: from mail.uj.edu.pl (mail.uj.edu.pl [149.156.89.147]) by mx1.freebsd.org (Postfix) with ESMTP id 378108FC1B; Sun, 24 Jul 2011 03:23:14 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from mbox.uj.edu.pl ([unknown] [149.156.89.248]) by mta.uoks.uj.edu.pl (Sun Java(tm) System Messaging Server 7u3-12.01 64bit (built Oct 15 2009)) with ESMTP id <0LOT007ISFQB7A40@mta.uoks.uj.edu.pl>; Sun, 24 Jul 2011 04:18:11 +0200 (CEST) Date: Sun, 24 Jul 2011 04:18:11 +0200 From: jakub.klama@uj.edu.pl To: freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org, andrew@fubar.geek.nz Message-id: X-Sender: jakub.klama@uj.edu.pl User-Agent: Roundcube Webmail/0.5 Cc: Subject: LPC32x0 MMC/SD and DMA interface issues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 03:23:15 -0000 Hi, During my GSoC work on LPC32x0 port, I've discovered that ARM PL180 MMC/SD controller present in SoC has completely useless PIO mode. That is, controller can't stop card clock when Rx FIFO buffer is full. This leads to permanent Rx overrun errors when CPU doesn't react to arriving data as fast as it should. Any other interrupt arriving between reading two blocks of data from SD card will make whole transfer fail. In practice, to make it work reasonably reliable in PIO mode, card clock speed should be lowered to less than 1MHz (while current SDHC cards can go with clocks of about 30MHz). I think that only possibility to make this controller working reasonable is to use DMA. On LPC32x0, there is central general-purpose DMA controller. And there is my central question: how to interface DMA controller driver with MMC/SD driver? Using direct function calls between drivers? My work from previous GSoC, Generic DMA Framework isn't ready to integrate right now, at least not that fast to do this in current GSoC timeline. Bearing in mind that it will be more or less temporary solution, will direct function calls between two drivers sufficient? Or maybe incorporate whole DMA-dealing code in MMC/SD driver? Regards, Jakub Klama From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 24 08:40:33 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AADE1065674 for ; Sun, 24 Jul 2011 08:40:33 +0000 (UTC) (envelope-from exorcistkiller@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 0A2318FC15 for ; Sun, 24 Jul 2011 08:40:32 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1QkuEi-0005ZB-7E for freebsd-hackers@freebsd.org; Sun, 24 Jul 2011 01:40:32 -0700 Date: Sun, 24 Jul 2011 01:40:32 -0700 (PDT) From: exorcistkiller To: freebsd-hackers@freebsd.org Message-ID: <1311496832217-4627557.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Add setacl system call? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 08:40:33 -0000 Hi, I'm working on a course project in which I need to add 3 system calls. One of which is setacl(char *name, int type, int idnum, int perms), which set acl for a file specified by name. I used newfs as in ftp://ftp.tw.freebsd.org/pub/FreeBSD/FreeBSD-current/src/sbin/newfs/ to make this new filesystem, named myfs (which really is UFS2) and mounted it. My question is: 1) where to start with? 2) Is this filesystem actually a userland UFS and I can use functions in libufs(3)? 3) What about functions in ufs_acl.c? Should the acls be stored on the extended attributes blocks? Does FreeBSD 8.2 support it? I know I'm asking stupid questions, but a small hint might help me a lot. Thank you so much.. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Add-setacl-system-call-tp4627557p4627557.html Sent from the freebsd-hackers mailing list archive at Nabble.com. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 24 11:40:21 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86C36106564A for ; Sun, 24 Jul 2011 11:40:21 +0000 (UTC) (envelope-from etnapierala@googlemail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 156F68FC12 for ; Sun, 24 Jul 2011 11:40:20 +0000 (UTC) Received: by fxe6 with SMTP id 6so5682655fxe.17 for ; Sun, 24 Jul 2011 04:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Qb35ls7El1/d8laF92luLeKnY/n1KxPjysNwOf31B7k=; b=UIFAtobrFK1Kir5JCiCFBQ3e2U8a9MNsCZwiK3TAvQ7VG05qPhkgvrhVOqevNHtilE lxU4SqMD2fjMYlZqED1aizlbH1+WJF92dYeb8pn1Sk443/hk9qhvXx1aaIrYOMn86vlb BFXxWfnApf7xFUinwQDxEiS7LfZOe6L859tZY= Received: by 10.204.30.202 with SMTP id v10mr1019888bkc.268.1311507619988; Sun, 24 Jul 2011 04:40:19 -0700 (PDT) Received: from [192.168.119.14] (gate19.robnet.pl [194.105.132.219]) by mx.google.com with ESMTPS id q1sm750843faa.3.2011.07.24.04.40.17 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jul 2011 04:40:18 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <86hb6e1bau.fsf@gmail.com> Date: Sun, 24 Jul 2011 13:40:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <589EB85A-1902-4643-A1FD-3C98445127DB@freebsd.org> References: <0CEA161B-6767-4379-B923-585B3D4EA74E@freebsd.org> <86hb6e1bau.fsf@gmail.com> To: Test Rat X-Mailer: Apple Mail (2.1244.3) Cc: freebsd-hackers@freebsd.org Subject: Re: Autosizing column widths in ps(1). X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 11:40:21 -0000 Wiadomo=B6=E6 napisana przez Test Rat w dniu 22 lip 2011, o godz. 19:21: > Edward Tomasz Napiera=B3a writes: >=20 >> Patch below changes ps(1) to automatically size column widths = according to their >> contents. =46rom the user point of view, it prevents breaking layout = with too wide values >> and in most cases makes output narrower. =46rom the developer point = of view, it removes >> the need to specify widths. Testing is welcome - the patch shouldn't = change ps(1) >> behaviour except slightly changing the widths, but the code changes = are pretty large >> and it's quite possible I've missed something. >=20 > STAT column seems to be right-aligned when it was previously = left-aligned. > This makes sorting it harder, e.g. >=20 > $ ps ax | (IFS=3D; read h; echo $h; sort -k3) | less Good catch, thanks! Updated patch, which also fixes two issues = affecting TTY column, is at http://people.freebsd.org/~trasz/ps-9.diff. -- If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 24 14:22:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4886106566B for ; Sun, 24 Jul 2011 14:22:57 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 93AFB8FC15 for ; Sun, 24 Jul 2011 14:22:57 +0000 (UTC) Received: by iyb11 with SMTP id 11so4975814iyb.13 for ; Sun, 24 Jul 2011 07:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=p/c5PJhrsEGKOgj1VYrFt+75E2cVFUVkXYrag7/0buM=; b=RH8bcCJ8XNx3ifseyCwMZi6QifLof1qzc+TausGZlLQYL1zoV3W+NEzDEcPJsTT7+v qOKV/lDTO+D67H9dBScuGpeVhFdf2Hh7+S0w8+KU1ZyW90LoZCvHCwuQ5AYwwKZUADlP bzUchUdXOsBwb94d6xbiEPm9kycI0DRWHOlnk= MIME-Version: 1.0 Received: by 10.142.49.19 with SMTP id w19mr2128037wfw.346.1311517376763; Sun, 24 Jul 2011 07:22:56 -0700 (PDT) Received: by 10.142.199.13 with HTTP; Sun, 24 Jul 2011 07:22:56 -0700 (PDT) In-Reply-To: References: Date: Sun, 24 Jul 2011 16:22:56 +0200 Message-ID: From: Davide Italiano To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: UMA large allocations issues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 14:22:57 -0000 oh, sorry I noticed that there's a typo. In mtx_init(&uma_mtx, "Bitmap Lock", NULL, MTX_DEF); you should replace uma_mtx with bitmap_mtx. Davide From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 24 14:34:25 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 391ED106566C for ; Sun, 24 Jul 2011 14:34:25 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 1FAF78FC15 for ; Sun, 24 Jul 2011 14:34:24 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta13.emeryville.ca.mail.comcast.net with comcast id BqL31h0011HpZEsADqMC1A; Sun, 24 Jul 2011 14:21:12 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta14.emeryville.ca.mail.comcast.net with comcast id BqMC1h0044NgCEG8aqMC1P; Sun, 24 Jul 2011 14:21:16 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id p6OEL7WT056341; Sun, 24 Jul 2011 08:21:08 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: jakub.klama@uj.edu.pl In-Reply-To: References: Content-Type: text/plain Date: Sun, 24 Jul 2011 08:21:07 -0600 Message-Id: <1311517267.1589.7.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 24 Jul 2011 14:57:13 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org, andrew@fubar.geek.nz Subject: Re: LPC32x0 MMC/SD and DMA interface issues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 14:34:25 -0000 Have a look at the Atmel driver in sys/arm/at91/at91_mci.c. It interfaces to the mmc/sd driver code in sys/dev, and uses DMA. The driver in -current does only single-block transfers; if you add my patches from http://www.freebsd.org/cgi/query-pr.cgi?pr=155214 it will do multiblock transfers as well. The controller in the first generation Atmel SoC also doesn't stop the data clock on a receive overrun even in DMA mode, which prevents using 4-bit transfers when other memory-intensive devices are active (such as the USB host) or when interrupt latency is high. I've read that the more recent Atmel chips can do so (but I haven't gotten to work with one yet). -- Ian On Sun, 2011-07-24 at 04:18 +0200, jakub.klama@uj.edu.pl wrote: > Hi, > > During my GSoC work on LPC32x0 port, I've discovered that > ARM PL180 MMC/SD controller present in SoC has completely > useless PIO mode. That is, controller can't stop card clock > when Rx FIFO buffer is full. This leads to permanent Rx > overrun errors when CPU doesn't react to arriving data as > fast as it should. Any other interrupt arriving between > reading two blocks of data from SD card will make whole > transfer fail. In practice, to make it work reasonably > reliable in PIO mode, card clock speed should be lowered > to less than 1MHz (while current SDHC cards can go with > clocks of about 30MHz). > > I think that only possibility to make this controller > working reasonable is to use DMA. On LPC32x0, there is > central general-purpose DMA controller. > > And there is my central question: how to interface DMA > controller driver with MMC/SD driver? Using direct > function calls between drivers? My work from previous > GSoC, Generic DMA Framework isn't ready to integrate > right now, at least not that fast to do this in current > GSoC timeline. Bearing in mind that it will be more or > less temporary solution, will direct function calls > between two drivers sufficient? Or maybe incorporate > whole DMA-dealing code in MMC/SD driver? > > Regards, > Jakub Klama > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 24 22:22:24 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 5A48D1065675; Sun, 24 Jul 2011 22:22:24 +0000 (UTC) Date: Sun, 24 Jul 2011 22:22:24 +0000 From: Alexander Best To: Edward Tomasz Napiera?a Message-ID: <20110724222224.GA64487@freebsd.org> References: <0CEA161B-6767-4379-B923-585B3D4EA74E@freebsd.org> <86hb6e1bau.fsf@gmail.com> <589EB85A-1902-4643-A1FD-3C98445127DB@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <589EB85A-1902-4643-A1FD-3C98445127DB@freebsd.org> Cc: Test Rat , freebsd-hackers@freebsd.org Subject: Re: Autosizing column widths in ps(1). X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 22:22:24 -0000 On Sun Jul 24 11, Edward Tomasz Napiera?a wrote: > Wiadomo?? napisana przez Test Rat w dniu 22 lip 2011, o godz. 19:21: > > Edward Tomasz Napiera?a writes: > > > >> Patch below changes ps(1) to automatically size column widths according to their > >> contents. From the user point of view, it prevents breaking layout with too wide values > >> and in most cases makes output narrower. From the developer point of view, it removes > >> the need to specify widths. Testing is welcome - the patch shouldn't change ps(1) > >> behaviour except slightly changing the widths, but the code changes are pretty large > >> and it's quite possible I've missed something. > > > > STAT column seems to be right-aligned when it was previously left-aligned. > > This makes sorting it harder, e.g. > > > > $ ps ax | (IFS=; read h; echo $h; sort -k3) | less > > Good catch, thanks! Updated patch, which also fixes two issues affecting TTY column, > is at http://people.freebsd.org/~trasz/ps-9.diff. working great here. have you experienced any performance issues, due to ps having to iterate through all columns before constructing the output in comparison to the previous design? cheers. alex P.S.: one utility which would also benefit from auto column sizing is top, for sure! ;) > > -- > If you cut off my head, what would I say? Me and my head, or me and my body? > From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 24 23:06:17 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 36ECB1065670; Sun, 24 Jul 2011 23:06:17 +0000 (UTC) Date: Sun, 24 Jul 2011 23:06:17 +0000 From: Alexander Best To: Edward Tomasz Napiera?a Message-ID: <20110724230617.GA69612@freebsd.org> References: <0CEA161B-6767-4379-B923-585B3D4EA74E@freebsd.org> <86hb6e1bau.fsf@gmail.com> <589EB85A-1902-4643-A1FD-3C98445127DB@freebsd.org> <20110724222224.GA64487@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110724222224.GA64487@freebsd.org> Cc: Test Rat , freebsd-hackers@freebsd.org Subject: Re: Autosizing column widths in ps(1). X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 23:06:17 -0000 On Sun Jul 24 11, Alexander Best wrote: > On Sun Jul 24 11, Edward Tomasz Napiera?a wrote: > > Wiadomo?? napisana przez Test Rat w dniu 22 lip 2011, o godz. 19:21: > > > Edward Tomasz Napiera?a writes: > > > > > >> Patch below changes ps(1) to automatically size column widths according to their > > >> contents. From the user point of view, it prevents breaking layout with too wide values > > >> and in most cases makes output narrower. From the developer point of view, it removes > > >> the need to specify widths. Testing is welcome - the patch shouldn't change ps(1) > > >> behaviour except slightly changing the widths, but the code changes are pretty large > > >> and it's quite possible I've missed something. > > > > > > STAT column seems to be right-aligned when it was previously left-aligned. > > > This makes sorting it harder, e.g. > > > > > > $ ps ax | (IFS=; read h; echo $h; sort -k3) | less > > > > Good catch, thanks! Updated patch, which also fixes two issues affecting TTY column, > > is at http://people.freebsd.org/~trasz/ps-9.diff. any reason there are always a minimum of 2 spaces between the "TT" and the "TIME" column and not a single space? > > working great here. have you experienced any performance issues, due to ps > having to iterate through all columns before constructing the output in > comparison to the previous design? > > cheers. > alex > > P.S.: one utility which would also benefit from auto column sizing is top, for > sure! ;) > > > > > -- > > If you cut off my head, what would I say? Me and my head, or me and my body? > > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 02:02:07 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 317A3106566B for ; Mon, 25 Jul 2011 02:02:07 +0000 (UTC) (envelope-from stephen.hocking@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id BE9F58FC0C for ; Mon, 25 Jul 2011 02:02:06 +0000 (UTC) Received: by wwe6 with SMTP id 6so3523489wwe.31 for ; Sun, 24 Jul 2011 19:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Po1NkbI1uGxgMkBv2GgSJADhGS2blLOElcOr5dzb9kQ=; b=b/ZI7HteVlphce4zPo/ruI+K+DbE3Rp7kteenoq3LaImUNcSgGNgsWh2dCY/D+iGn2 mzsdCwtFIEWJI8wqGpNZHyGptOTV5kq4aFUac+57tvpX2kfAo6ckYhxARR4kOt1cPy2a lCCra7PLeSBVgQSOnilH3RgsUkFUIwbB3Hyq0= MIME-Version: 1.0 Received: by 10.216.163.203 with SMTP id a53mr20381wel.8.1311557592319; Sun, 24 Jul 2011 18:33:12 -0700 (PDT) Received: by 10.216.86.133 with HTTP; Sun, 24 Jul 2011 18:33:12 -0700 (PDT) Date: Mon, 25 Jul 2011 11:33:12 +1000 Message-ID: From: Stephen Hocking To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Mapping /dev/gptid numbers to /dev/adXpY X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 02:02:07 -0000 Hi all, After shuffling some disks around in a ZFS array (moving them to a hot-swap cabinet) I am now seeing gptid numbers when doing a zpool status: zpool status schtuff pool: schtuff state: ONLINE scan: scrub repaired 0 in 5h57m with 0 errors on Wed Jul 20 17:05:29 2011 config: NAME STATE READ WRITE CKSUM schtuff ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 ad8p1 ONLINE 0 0 0 gptid/13aed7e6-9ca8-11e0-99f1-001a4d9c179c ONLINE 0 0 0 gptid/15c300de-9ca8-11e0-99f1-001a4d9c179c ONLINE 0 0 0 errors: No known data errors Now this is all very interesting, but I would like to be able to map that back to a /dev/adXpY device entry, so when I offline them I can then go to the appropriate physical disk. I thought that gpart show -r might help, but the numbers emitted from that don't match up. Looking at the major/minor numbers of the devices don't help either. Does anyone have an idea? Stephen From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 04:24:06 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0169D106566C for ; Mon, 25 Jul 2011 04:24:06 +0000 (UTC) (envelope-from stephen.hocking@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 900EC8FC13 for ; Mon, 25 Jul 2011 04:24:05 +0000 (UTC) Received: by wwe6 with SMTP id 6so3568549wwe.31 for ; Sun, 24 Jul 2011 21:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZEqX1XBkJynkUjh6nsbqu8c3dFqrUZle++vgoatLO5E=; b=vK8qJv2G2TWSAJTV4JYbNWZcSVmb/uwehHiXj18Ttf6PBfzfY+5m2ya9v2jTwvmr7j /e7G/qrY4R+dPKO3mQoLmgvfvvXBJ6R2WRsjum3/yMbN8tPVA/wQ72UeTRnSEozgbIZL cHy3mLQdnORFJLRoetCsWg9fxcn1yUKxvQiqs= MIME-Version: 1.0 Received: by 10.216.137.4 with SMTP id x4mr105629wei.53.1311567844379; Sun, 24 Jul 2011 21:24:04 -0700 (PDT) Received: by 10.216.86.133 with HTTP; Sun, 24 Jul 2011 21:24:04 -0700 (PDT) In-Reply-To: <29AAE187-42EB-4478-985B-DF7DB3EDE67F@gsoft.com.au> References: <29AAE187-42EB-4478-985B-DF7DB3EDE67F@gsoft.com.au> Date: Mon, 25 Jul 2011 14:24:04 +1000 Message-ID: From: Stephen Hocking To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 Cc: hackers@freebsd.org Subject: Re: Mapping /dev/gptid numbers to /dev/adXpY X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 04:24:06 -0000 On Mon, Jul 25, 2011 at 2:15 PM, Daniel O'Connor wrote: > > On 25/07/2011, at 11:03, Stephen Hocking wrote: >> Now this is all very interesting, but I would like to be able to map >> that back to a /dev/adXpY device entry, so when I offline them I can >> then go to the appropriate physical disk. I thought that gpart show -r >> might help, but the numbers emitted from that don't match up. Looking >> at the major/minor numbers of the devices don't help either. Does >> anyone have an idea? > > > If you run 'gpart list' you will see a list of device names and UUIDs. > > Mapping it by hand is a bit tedious though.. > Both Test Rat & Daniel pointed me towards gpart list. The gpart man page doesn't seem to mention the list command, which is probably why I missed it. Anyways, now all I have to do is label my hotswap drawers properly.... Stephen From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 04:28:19 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C77581065672 for ; Mon, 25 Jul 2011 04:28:19 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3466E8FC08 for ; Mon, 25 Jul 2011 04:28:18 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p6P4Fd37098541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Jul 2011 13:45:45 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: Date: Mon, 25 Jul 2011 13:45:39 +0930 Content-Transfer-Encoding: 7bit Message-Id: <29AAE187-42EB-4478-985B-DF7DB3EDE67F@gsoft.com.au> References: To: Stephen Hocking X-Mailer: Apple Mail (2.1244.3) X-Spam-Score: -3.899 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: hackers@freebsd.org Subject: Re: Mapping /dev/gptid numbers to /dev/adXpY X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 04:28:19 -0000 On 25/07/2011, at 11:03, Stephen Hocking wrote: > Now this is all very interesting, but I would like to be able to map > that back to a /dev/adXpY device entry, so when I offline them I can > then go to the appropriate physical disk. I thought that gpart show -r > might help, but the numbers emitted from that don't match up. Looking > at the major/minor numbers of the devices don't help either. Does > anyone have an idea? If you run 'gpart list' you will see a list of device names and UUIDs. Mapping it by hand is a bit tedious though.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 04:29:42 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F07E106566B for ; Mon, 25 Jul 2011 04:29:42 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 185AC8FC08 for ; Mon, 25 Jul 2011 04:29:41 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p6P4TZrJ099029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Jul 2011 13:59:40 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: "Daniel O'Connor" In-Reply-To: Date: Mon, 25 Jul 2011 13:59:35 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: References: <29AAE187-42EB-4478-985B-DF7DB3EDE67F@gsoft.com.au> To: Stephen Hocking X-Mailer: Apple Mail (2.1244.3) X-Spam-Score: -3.899 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: hackers@freebsd.org Subject: Re: Mapping /dev/gptid numbers to /dev/adXpY X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 04:29:42 -0000 On 25/07/2011, at 13:54, Stephen Hocking wrote: >> If you run 'gpart list' you will see a list of device names and = UUIDs. >>=20 >> Mapping it by hand is a bit tedious though.. >>=20 >=20 >=20 > Both Test Rat & Daniel pointed me towards gpart list. The gpart man > page doesn't seem to mention the list command, which is probably why I > missed it. Anyways, now all I have to do is label my hotswap drawers > properly=85. Yes, unfortunately(?) 'list' is a standard GEOM command so the part man = page doesn't explicitly mention it.. IMO it would be nice if it did. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 04:59:35 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2ED0106566B for ; Mon, 25 Jul 2011 04:59:35 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id A0E0A8FC1A for ; Mon, 25 Jul 2011 04:59:35 +0000 (UTC) Received: by gyf3 with SMTP id 3so2431025gyf.13 for ; Sun, 24 Jul 2011 21:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VWpCuH4sABo3ykA1PcxKmNvV2/MGVfRqEJ7VPt4+tz0=; b=EHD5NyP7ukHI3ZEvoCso3Cs5WhkDQPTqvE8bHcnsbliNi/12hnU1iSZ+KXkwo3CNJM LGuZwbDDH639h8t80UgtzZJjUO6DdMoOENQPVY5XKNQlWHD+Q3tdttcinxyX+g/tzBEd vHLvUcvy/vePP0fEFwlQtcaSvkt3YVqE7cm/8= MIME-Version: 1.0 Received: by 10.91.204.23 with SMTP id g23mr3970988agq.94.1311568494814; Sun, 24 Jul 2011 21:34:54 -0700 (PDT) Received: by 10.90.209.12 with HTTP; Sun, 24 Jul 2011 21:34:54 -0700 (PDT) In-Reply-To: References: <29AAE187-42EB-4478-985B-DF7DB3EDE67F@gsoft.com.au> Date: Sun, 24 Jul 2011 21:34:54 -0700 Message-ID: From: Freddie Cash To: Stephen Hocking Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "hackers@freebsd.org" Subject: Re: Mapping /dev/gptid numbers to /dev/adXpY X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 04:59:36 -0000 If you disable gptid labels in /boot/loader.conf and reboot, it should display the device nodes again. Alternatively, since you are using gpt, you can just label the partitions, and 'zfs replace' each disk with the /dev/gpt/labelname node. On Sunday, July 24, 2011, Stephen Hocking wrote: > On Mon, Jul 25, 2011 at 2:15 PM, Daniel O'Connor wrote: >> >> On 25/07/2011, at 11:03, Stephen Hocking wrote: >>> Now this is all very interesting, but I would like to be able to map >>> that back to a /dev/adXpY device entry, so when I offline them I can >>> then go to the appropriate physical disk. I thought that gpart show -r >>> might help, but the numbers emitted from that don't match up. Looking >>> at the major/minor numbers of the devices don't help either. Does >>> anyone have an idea? >> >> >> If you run 'gpart list' you will see a list of device names and UUIDs. >> >> Mapping it by hand is a bit tedious though.. >> > > > Both Test Rat & Daniel pointed me towards gpart list. The gpart man > page doesn't seem to mention the list command, which is probably why I > missed it. Anyways, now all I have to do is label my hotswap drawers > properly.... > > > Stephen > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Freddie Cash fjwcash@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 07:08:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4F86106566B for ; Mon, 25 Jul 2011 07:08:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 921438FC08 for ; Mon, 25 Jul 2011 07:08:57 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 468A646B2D; Mon, 25 Jul 2011 03:08:57 -0400 (EDT) Date: Mon, 25 Jul 2011 08:08:57 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: exorcistkiller In-Reply-To: <1311496832217-4627557.post@n5.nabble.com> Message-ID: References: <1311496832217-4627557.post@n5.nabble.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: Add setacl system call? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 07:08:57 -0000 On Sun, 24 Jul 2011, exorcistkiller wrote: > Hi, I'm working on a course project in which I need to add 3 system calls. > One of which is setacl(char *name, int type, int idnum, int perms), which > set acl for a file specified by name. I used newfs as in > ftp://ftp.tw.freebsd.org/pub/FreeBSD/FreeBSD-current/src/sbin/newfs/ to make > this new filesystem, named myfs (which really is UFS2) and mounted it. > > My question is: > 1) where to start with? > 2) Is this filesystem actually a userland UFS and I can use functions in > libufs(3)? > 3) What about functions in ufs_acl.c? Should the acls be stored on the > extended attributes blocks? Does FreeBSD 8.2 support it? > > I know I'm asking stupid questions, but a small hint might help me a lot. > Thank you so much.. Hi... er.. exorcistkiller... (*) This being FreeBSD, you may want to start with the existing programmer documentation, which should prove quite useful given your goals. Try acl(3) for userspace, and acl(9) for the kernel. You are doing this in the context of a course, so the constraints may be somewhat artificial. However, normally my advice to someone wanting to add a new ACL implementation to FreeBSD would be to start with our existing implementation, which supports both POSIX.1e and NFSv4 ACLs (and is extensible to new ACL types without changing the current APIs (much)). For example, if I were going to teach our native system call API about AFS ACLs, I'd start by perusing the above man pages and code, including: src/bin/*acl* # Commands for manipulating ACLs src/lib/libc/posix1e # Library routines src/sys/kern/*acl* # File system-independent code src/sys/sys/acl.h # File system-independent header As you've already found, ufs_acl.c contains the implementation for UFS; ZFS, NFS, etc, have similar-looking files with markedly different contents. In general, if something looks file system-independent, we try to put it in the centralised files in kern, rather than replicate the code across file systems. Roughly half the code in the kern directory has to do with calls *into* the file system, and the other half is a library of routines called *by* the file system. Robert From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 09:42:54 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 291DA1065670 for ; Mon, 25 Jul 2011 09:42:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 06D968FC1C for ; Mon, 25 Jul 2011 09:42:54 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 76F3446B03; Mon, 25 Jul 2011 05:42:53 -0400 (EDT) Date: Mon, 25 Jul 2011 10:42:53 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: s In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: Finding symlink information in MAC Framework X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 09:42:54 -0000 On Fri, 15 Jul 2011, s wrote: > I am trying to get some information related to the symlink which is being > accessed by the user in MAC Framework. Currently I managed to get the > uid/gid of the owner of the symlink that is being read, but now I need to > get the same information about the target, that the symlink points to. > > static int samplemac_vnode_check_link (struct ucred *cred, struct vnode *vp, > struct label *vplabel) > { > > int error; > struct vattr vap; > > error = VOP_GETATTR(vp, &vap, cred); > if (error) > return (1); > > if(vap.va_uid != 0) { > log(LOG_NOTICE, "stub_vnode_check_readlink: %i, gid: %i\n", > vap.va_uid, vap.va_gid); > return (0); > } > > return (0); > } > > And I have no idea how could I do that. Where should I look for that info? > And what way would be the fastest? Hi Jakub: Could you say a bit more about what you're trying to accomplish? The reason it's hard to express what you're trying to do (inspect the target of a symlink during a read of the symlink) is that it's not really a coherent concept in terms of kernel implementation. At the point where the access control check on readlink is occuring, the string hasn't yet been read from the link, and even if it had, you couldn't look up the target object as you're already holding locks relating to lookup and read of the symlink itself. Even if you could, there's also a risk of recursion: the symlink could point straight back to where you are, etc. The readlink check is mid-lookup and triggering an entirely fresh lookup from there might be quite awkward for a number of such reasons. In general, however, this is not an issue for the policies we've encountered thus far: they almost all care only about authorising path segment lookups (in which case readlink is just another segment in evaluation), or absolute paths to objects reconstructed during the actual operation on the target object, etc. Hence my wondering what you're trying to accomplish -- the first question, really, is "is what you're trying to express actually safely expressible in a fine-grained, multiprocessing kernel?" Robert From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 09:47:04 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7842106564A; Mon, 25 Jul 2011 09:47:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A9C428FC0A; Mon, 25 Jul 2011 09:47:04 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 1176446B03; Mon, 25 Jul 2011 05:47:04 -0400 (EDT) Date: Mon, 25 Jul 2011 10:47:03 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andriy Gapon In-Reply-To: <4E244EE1.40604@FreeBSD.org> Message-ID: References: <4E2448D1.6020504@gamozo.org> <4E244EE1.40604@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@FreeBSD.org, jonathan@FreeBSD.org, Brandon Falk Subject: Re: Issue with 'Unknown Error: -512' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 09:47:04 -0000 On Mon, 18 Jul 2011, Andriy Gapon wrote: >> In recent branches (confirmed with 224119) builds compiled with clang >> happen to throw 'Unknown error: -512' in a lot of places, making the system >> unusable. (Untested on gcc compiled systems). Originally I thought the >> problem was with specific programs, then I narrowed it down to file I/O, >> and now I've narrowed it down to open() with O_TRUNC. Without O_TRUNC there >> seems to be no issues whatsoever. With O_TRUNC on open() it fails with that >> 'Unknown error: -512' every other time you run the program. Common issues, >> portsnap is affected, making it impossible to fetch/extract ports. As well >> as redirecting output in shells eg `echo 'hi' > test` fails every other >> try. You have the same issue with text editors like `edit` where it fails >> every other save. There are no issues with `echo 'hi' >> test` as there is >> no O_TRUNC, it only seems to be an O_TRUNC error. >> >> Any tips? Otherwise I'll be looking into this today myself. > > Just a hint that you could try using DTrace syscall and fbt providers to see > where in kernel (if in kernel) that -512 return value originates. Jon Anderson spotted that here during some Capsicum work -- initially we were concerned it was a local patch, but it sounds like it might be less local. I think he saw it on calls to open(2) as well, and I couldn't help but wonder (given its recent arrival) if it was an outcome of the change to break falloc into two parts, leading to some or another problematic handling of file descriptor numbers. I.e., it's not so much that -512 is being returned, as a number that's a bad file descriptor. (Although now having seen 512 twice on two different machines, that particular explanation seems less credible). Perhaps this is indeed unrelated to Capsicum, and triggered by a clang bug or something else. I've CC'd Jon, maybe he has gained further insight since we chatted. Robert From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 14:40:40 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42932106564A for ; Mon, 25 Jul 2011 14:40:40 +0000 (UTC) (envelope-from filippo.sironi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id CCA1B8FC15 for ; Mon, 25 Jul 2011 14:40:39 +0000 (UTC) Received: by wyg24 with SMTP id 24so3702134wyg.13 for ; Mon, 25 Jul 2011 07:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=IzN7NgumfseyNdQed24r5gcfVwxvRUQtr74Aj5I1f5g=; b=VUD9jUXJAYoxFxjHv9Sz+X9v83iIDZ8FcnUna0D4Z6oWAHxCpOjkAu0CawHzRCWGoB IDNCsywhcJN1BtheS0ZnowCMuvjZ9BOxO1XO9YVK6BsJ01U6Tyh4DWAutRnY6et+SyQy 71TXK5U11VD0055RYcYgKfv0snxF8VYKCbSYI= Received: by 10.227.202.19 with SMTP id fc19mr1424458wbb.61.1311603202677; Mon, 25 Jul 2011 07:13:22 -0700 (PDT) Received: from filippo.sironi.dynamic.micro.elet.polimi.it (micro.elet.polimi.it [131.175.127.118]) by mx.google.com with ESMTPS id b13sm4354050wbh.58.2011.07.25.07.13.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jul 2011 07:13:22 -0700 (PDT) From: Filippo Sironi Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jul 2011 16:13:19 +0200 Message-Id: <3AD5705F-0C4E-43CB-8A9C-3416171AEA30@gmail.com> To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: Kernel timers infrastructure X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 14:40:40 -0000 Hi everyone, I'm working on a university project that's based on FreeBSD and I'm = currently hacking the kernel... but I'm a complete newbie. My question is: what if I have to call a certain function 10 times per = second? I've seen a bit of code regarding callout_* functions but I can't get = through them. Is there anyone who can help me? Thanks, Filippo From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 15:26:51 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E225F106564A for ; Mon, 25 Jul 2011 15:26:51 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BE4278FC08 for ; Mon, 25 Jul 2011 15:26:51 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 4767846B39; Mon, 25 Jul 2011 11:26:51 -0400 (EDT) Date: Mon, 25 Jul 2011 16:26:51 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Filippo Sironi In-Reply-To: <3AD5705F-0C4E-43CB-8A9C-3416171AEA30@gmail.com> Message-ID: References: <3AD5705F-0C4E-43CB-8A9C-3416171AEA30@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel timers infrastructure X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 15:26:52 -0000 On Mon, 25 Jul 2011, Filippo Sironi wrote: > I'm working on a university project that's based on FreeBSD and I'm > currently hacking the kernel... but I'm a complete newbie. My question is: > what if I have to call a certain function 10 times per second? I've seen a > bit of code regarding callout_* functions but I can't get through them. Is > there anyone who can help me? Hi Filippo: I'm not sure if you've found the callout(9) man page yet, but it talks about the KPI in some detail. The basic idea, though, is that you describe a regular "callout" using a function pointer, an opaque data pointer, and how long until it should be invoked. In its more complex incantations, you can also specify locks for it to acquire, etc. The key aspect of the API that some people find confusing is that the time interval is described in ticks of length 1/hz seconds. Unless software really wants one invocation per tick (generally unlikely), you will want to pass in some constant times/divided by hz so that it's appropriately scaled. You can find two fairly straight-forward examples in kern/uipc_domain.c, which are respectively the "fast" and "slow" timers Robert From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 16:02:55 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDD88106564A; Mon, 25 Jul 2011 16:02:55 +0000 (UTC) (envelope-from falkman@gamozo.org) Received: from mta11.charter.net (mta11.charter.net [216.33.127.80]) by mx1.freebsd.org (Postfix) with ESMTP id 588988FC2B; Mon, 25 Jul 2011 16:02:55 +0000 (UTC) Received: from imp10 ([10.20.200.15]) by mta11.charter.net (InterMail vM.7.09.02.04 201-2219-117-106-20090629) with ESMTP id <20110725160254.TQTZ4091.mta11.charter.net@imp10>; Mon, 25 Jul 2011 12:02:54 -0400 Received: from [192.168.1.12] ([75.135.75.204]) by imp10 with smtp.charter.net id CG2t1h00Q4QU3rf05G2td8; Mon, 25 Jul 2011 12:02:54 -0400 X-Authority-Analysis: v=1.1 cv=G6Q69DB3AUoJKS2BpLRaz8MQ2NORN7h5HRzrJMPOhRw= c=1 sm=1 a=7Da5kHvgTEoA:10 a=YzQM1Zd3q-sA:10 a=EZ1XIdwCItEA:10 a=8nJEP1OIZ-IA:10 a=HEs2YkztZRVyeANDsLw8Eg==:17 a=0ba4Quu-sbMiyhfFzusA:9 a=PRLA-718_G6QWoxCTdsA:7 a=wPNLvfGTeEIA:10 a=HEs2YkztZRVyeANDsLw8Eg==:117 Message-ID: <4E2D93AD.4000103@gamozo.org> Date: Mon, 25 Jul 2011 11:02:53 -0500 From: Brandon Falk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Robert Watson References: <4E2448D1.6020504@gamozo.org> <4E244EE1.40604@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, jonathan@FreeBSD.org, Andriy Gapon Subject: Re: Issue with 'Unknown Error: -512' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:02:56 -0000 On 7/25/2011 4:47 AM, Robert Watson wrote: > > On Mon, 18 Jul 2011, Andriy Gapon wrote: > >>> In recent branches (confirmed with 224119) builds compiled with >>> clang happen to throw 'Unknown error: -512' in a lot of places, >>> making the system unusable. (Untested on gcc compiled systems). >>> Originally I thought the problem was with specific programs, then I >>> narrowed it down to file I/O, and now I've narrowed it down to >>> open() with O_TRUNC. Without O_TRUNC there seems to be no issues >>> whatsoever. With O_TRUNC on open() it fails with that 'Unknown >>> error: -512' every other time you run the program. Common issues, >>> portsnap is affected, making it impossible to fetch/extract ports. >>> As well as redirecting output in shells eg `echo 'hi' > test` fails >>> every other try. You have the same issue with text editors like >>> `edit` where it fails every other save. There are no issues with >>> `echo 'hi' >> test` as there is no O_TRUNC, it only seems to be an >>> O_TRUNC error. >>> >>> Any tips? Otherwise I'll be looking into this today myself. >> >> Just a hint that you could try using DTrace syscall and fbt providers >> to see where in kernel (if in kernel) that -512 return value originates. > > Jon Anderson spotted that here during some Capsicum work -- initially > we were concerned it was a local patch, but it sounds like it might be > less local. I think he saw it on calls to open(2) as well, and I > couldn't help but wonder (given its recent arrival) if it was an > outcome of the change to break falloc into two parts, leading to some > or another problematic handling of file descriptor numbers. I.e., > it's not so much that -512 is being returned, as a number that's a bad > file descriptor. (Although now having seen 512 twice on two different > machines, that particular explanation seems less credible). Perhaps > this is indeed unrelated to Capsicum, and triggered by a clang bug or > something else. > > I've CC'd Jon, maybe he has gained further insight since we chatted. > > Robert > I've been building head every single day to check for the disappearance of this bug, and it seems to be gone as of 224302 (maybe before, but 224302 is what I built). I wrote a program to do tons of open()s and truncate()s to try to get the error, where initially I'd get an error every other attempt, then it was every 100 or so iterations it would fail, now I've tested 500,000 opens and truncates and there have been no issues. -Brandon Falk From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 18:54:20 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC7E31065673 for ; Mon, 25 Jul 2011 18:54:20 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 4A1C98FC23 for ; Mon, 25 Jul 2011 18:54:19 +0000 (UTC) Received: by fxe6 with SMTP id 6so7098394fxe.17 for ; Mon, 25 Jul 2011 11:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=nLiPIWkscpfKRnqBNxPLlxFxJCG7/c1Yc4F5fvTT/kc=; b=BeMjcGivNrl7ivKMx8mXvMPLxHQX8yuZiGhmGOQRKqh2pIVkqv13+L+v8bW6HLzdZa HcmjFF/gtxGFZNeKNiJJ8gGGS6nAy8+vWZfMQhG4bZZ0hfydtT/Xqy+YDOR9hHdF1ffB FeTqXsydE4PPA8lIrXt42FmUolojOMZKxewik= Received: by 10.223.61.133 with SMTP id t5mr350854fah.130.1311618441146; Mon, 25 Jul 2011 11:27:21 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id n18sm2913760fam.31.2011.07.25.11.27.19 (version=SSLv3 cipher=OTHER); Mon, 25 Jul 2011 11:27:20 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E2DB579.7030804@FreeBSD.org> Date: Mon, 25 Jul 2011 21:27:05 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110709 Thunderbird/5.0 MIME-Version: 1.0 To: Filippo Sironi References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel timers infrastructure X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 18:54:20 -0000 Hi. On 25.07.2011 17:13, Filippo Sironi wrote: > I'm working on a university project that's based on FreeBSD and I'm currently hacking the kernel... but I'm a complete newbie. > My question is: what if I have to call a certain function 10 times per second? > I've seen a bit of code regarding callout_* functions but I can't get through them. Is there anyone who can help me? Have you read callout(9) manual page? That API is right if you need to call some function. Also in some cases (if you need to make your kernel thread wait for something) you may use sleep(9) API. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 00:09:40 2011 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C440E1065678; Tue, 26 Jul 2011 00:09:40 +0000 (UTC) (envelope-from vadim@nuclight.avtf.net) Received: from nuclight.avtf.net (208.88.188.90.adsl.tomsknet.ru [90.188.88.208]) by mx1.freebsd.org (Postfix) with ESMTP id BEAC58FC1D; Tue, 26 Jul 2011 00:09:39 +0000 (UTC) Received: from kernblitz.nuclight.avtf.net (vadim@localhost [127.0.0.1]) by nuclight.avtf.net (8.14.4/8.14.4) with ESMTP id p6PNg7WW076229; Tue, 26 Jul 2011 06:42:08 +0700 (NOVST) (envelope-from vadim@kernblitz.nuclight.avtf.net) Received: (from vadim@localhost) by kernblitz.nuclight.avtf.net (8.14.4/8.14.4/Submit) id p6PNg6Pn076226; Tue, 26 Jul 2011 06:42:06 +0700 (NOVST) (envelope-from vadim) Message-Id: <201107252342.p6PNg6Pn076226@kernblitz.nuclight.avtf.net> To: Daniel Gerzo From: Vadim Goncharov In-Reply-To: <4E0B0299.2020205@FreeBSD.org> References: <4E0B0299.2020205@FreeBSD.org> X-Comment-To: Daniel Gerzo Date: Tue, 26 Jul 2011 06:42:05 +0700 User-Agent: slrn/0.9.9p1 (FreeBSD) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: hackers@FreeBSD.org, current@FreeBSD.org Subject: Re: HEADSUP: Call for FreeBSD Status Reports - 2Q/2011 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 00:09:40 -0000 Hi Daniel Gerzo! On Wed, 29 Jun 2011 12:46:49 +0200; Daniel Gerzo wrote: > Do not hesitate and write us a few lines; a short description about > what you are working on, what your plans and goals are, or any other > information that you consider interested is always welcome. This way > we can inform our community about your great work! > Check out the reports from the past to get some inspiration of what > your submission should look like. [...] > Note that the submissions are accepted from anyone involved within the > FreeBSD community, you do not have to be a FreeBSD committer. Anything > related to FreeBSD can be covered. > Please email us the filled-in XML template which can be found at > http://www.freebsd.org/news/status/report-sample.xml to > monthly@FreeBSD.org, or alternatively use our web based form located at > http://www.freebsd.org/cgi/monthly.cgi. A note for the future: you will tend to receive more submissions if you will make life a lot easier for submitter. The most natural way of using the aforementioned Web form - as, surprise, a Web form (BTW, the field to type in is too small and thus uncomfortable). That is, result of clicking "Submit" button must be immediately sending info to central base, requiring no further work from submitter to cut-n-paste the thing to e-mail. This is just frightening to everyone who is not a FreeBSD committer, with regard to needing to send this info to another e-mail which it suggests! (I was told that in IRC, and fro where has the Joe Random Contributor to know this?) We will have more docs when a contributor is not forced to efforts which are unneeded. Having to do such things which could be easily done on server-side looks just too unpolite for those who came in - and some of them will turn away from sending. P.S. This is general principle, not only for docs - forcing user to do something which could be already done by maintainer turns away from the system many of them. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 05:27:25 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8CF5106566B for ; Tue, 26 Jul 2011 05:27:25 +0000 (UTC) (envelope-from exorcistkiller@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id A44878FC0A for ; Tue, 26 Jul 2011 05:27:25 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1QlaAu-0002fc-Uv for freebsd-hackers@freebsd.org; Mon, 25 Jul 2011 22:27:24 -0700 Date: Mon, 25 Jul 2011 22:27:24 -0700 (PDT) From: exorcistkiller To: freebsd-hackers@freebsd.org Message-ID: <1311658044945-4633662.post@n5.nabble.com> In-Reply-To: References: <1311496832217-4627557.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Add setacl system call? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 05:27:25 -0000 Thank you Robert! Another question while I'm reading the code. In ufs_acl.c, in static int ufs_getacl_posix1e(struct vop_getacl_args *ap), you commented: As part of the ACL is stored in the inode, and the rest in an EA, assemble both into a final ACL product. From what I learned from Kirk's book, ACLs are supposed be stored in extended attributes blocks. So what do you mean by "part of the ACL is stores in the inode"? I know extended attributes blocks data can be addressed by inode, but how to get ACL directly from the inode? -- View this message in context: http://freebsd.1045724.n5.nabble.com/Add-setacl-system-call-tp4627557p4633662.html Sent from the freebsd-hackers mailing list archive at Nabble.com. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 07:16:34 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60477106564A for ; Tue, 26 Jul 2011 07:16:34 +0000 (UTC) (envelope-from etnapierala@googlemail.com) Received: from mail-ey0-f176.google.com (mail-ey0-f176.google.com [209.85.215.176]) by mx1.freebsd.org (Postfix) with ESMTP id E12B68FC0A for ; Tue, 26 Jul 2011 07:16:33 +0000 (UTC) Received: by eya28 with SMTP id 28so243042eya.21 for ; Tue, 26 Jul 2011 00:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=yQniMGF+bFXuet75Y+K2jUDM7ouCzpSOZF8W952hwok=; b=BiOijBp86lAcTepvTDfsRTtX85j8E08xXSF+5EtlLz4lIA4vjhwvcxyc9iYARzMFii N+NsZ3kGB4cSkNUiUO4l/jSMtM4NZES/IHWaXlapBDAu2+SvqZfuoDJhnGcYfn6QRPya a8lMtX914JxJ2bZJF/gYHQAXPSvajNjvVOzvE= Received: by 10.213.22.18 with SMTP id l18mr641484ebb.119.1311664592423; Tue, 26 Jul 2011 00:16:32 -0700 (PDT) Received: from enapierala.whl (58.wheelsystems.com [83.12.187.58]) by mx.google.com with ESMTPS id p49sm135740eef.24.2011.07.26.00.16.30 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jul 2011 00:16:31 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <20110724230617.GA69612@freebsd.org> Date: Tue, 26 Jul 2011 09:16:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8D7CEA8F-AF55-4509-9C90-74FC42A9A020@freebsd.org> References: <0CEA161B-6767-4379-B923-585B3D4EA74E@freebsd.org> <86hb6e1bau.fsf@gmail.com> <589EB85A-1902-4643-A1FD-3C98445127DB@freebsd.org> <20110724222224.GA64487@freebsd.org> <20110724230617.GA69612@freebsd.org> To: Alexander Best X-Mailer: Apple Mail (2.1244.3) Cc: Test Rat , freebsd-hackers@freebsd.org Subject: Re: Autosizing column widths in ps(1). X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 07:16:34 -0000 Wiadomo=B6=E6 napisana przez Alexander Best w dniu 25 lip 2011, o godz. = 01:06: > On Sun Jul 24 11, Alexander Best wrote: >> On Sun Jul 24 11, Edward Tomasz Napiera?a wrote: >>> Wiadomo?? napisana przez Test Rat w dniu 22 lip 2011, o godz. 19:21: >>>> Edward Tomasz Napiera?a writes: >>>>=20 >>>>> Patch below changes ps(1) to automatically size column widths = according to their >>>>> contents. =46rom the user point of view, it prevents breaking = layout with too wide values >>>>> and in most cases makes output narrower. =46rom the developer = point of view, it removes >>>>> the need to specify widths. Testing is welcome - the patch = shouldn't change ps(1) >>>>> behaviour except slightly changing the widths, but the code = changes are pretty large >>>>> and it's quite possible I've missed something. >>>>=20 >>>> STAT column seems to be right-aligned when it was previously = left-aligned. >>>> This makes sorting it harder, e.g. >>>>=20 >>>> $ ps ax | (IFS=3D; read h; echo $h; sort -k3) | less >>>=20 >>> Good catch, thanks! Updated patch, which also fixes two issues = affecting TTY column, >>> is at http://people.freebsd.org/~trasz/ps-9.diff. >=20 > any reason there are always a minimum of 2 spaces between the "TT" and = the > "TIME" column and not a single space? The 'TT' column ends with either a space, or a '-'. As you've noticed, = in the common case there will be no hyphens there; I'll see if I can remove the extra = spacing. -- If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 14:55:09 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D24A410656FE; Tue, 26 Jul 2011 14:55:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id F0C838FC19; Tue, 26 Jul 2011 14:55:04 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA12665; Tue, 26 Jul 2011 17:55:03 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E2ED546.2080401@FreeBSD.org> Date: Tue, 26 Jul 2011 17:55:02 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: FreeBSD Hackers X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: HTT vs SMT in x86 SMP topology reporting X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 14:55:09 -0000 Can anybody explain to me why our _x86_ SMP topology discovery and reporting code sometimes reports "HTT" and sometimes "SMT"? As in FreeBSD/SMP: %d package(s) x %d core(s) x %d HTT threads vs FreeBSD/SMP: %d package(s) x %d core(s) x %d SMT threads As I understand, and quoting Wikipedia (I know, I know), SMT stands for simultaneous multithreading and is a generic term for a particular kind of hardware multithreading: http://en.wikipedia.org/wiki/Simultaneous_multithreading The only known (to me) implementation of SMT for x86 is Intel's Hyper-Threading Technology aka HTT aka HT Technology aka hyperthreading: http://en.wikipedia.org/wiki/Hyper-threading http://software.intel.com/en-us/articles/intel-hyper-threading-technology-your-questions-answered/?wapkw=%28Intel+Hyper-Threading+Technology%29 I understand that HTT implementation has evolved over time and there could be some reasons to distinguish HTT as implemented in e.g. Pentium 4 from HTT as implemented in the recent architectures like Nehalem and Sandy Bridge. But I still do not understand why we have to call the latter SMT when Intel calls it HTT. Also, right now things like machdep.hyperthreading_allowed act only on old hyperthreads (what we report as "HTT") but completely ignore the new ones (what we report as "SMT"). I am not sure that this is correct either... Perhaps there are no good reasons to disable HTT on modern CPUs, but the current behavior can definitely be confusing. In the end I would like to propose that we always report Intel HTT as HTT. Or even drop HTT/SMT from "x %d threads" altogether. Whether we should internally distinguish old HTT from new HTT is not clear to me. E.g. I see that for old HTT we bind interrupts only to one processing unit (aka logical processor aka hardware thread) from each hyperthreading pair. Not sure if new HTT is so much better that we shouldn't be doing the same for it. P.S. Also currently distinction between old/new HTT technologies is made based on availability of CPUID leaf 0xB. Not sure if this is entirely accurate for e.g. Atom processors, which we seem to detect as old HTT. A lengthy quote from volume 3A as an illustration: 8.7.7 Performance Monitoring Counters Performance counters and their companion control MSRs are shared between the logical processors within a processor core for processors based on Intel NetBurst microarchitecture. As a result, software must manage the use of these resources. The performance counter interrupts, events, and precise event monitoring support can be set up and allocated on a per thread (per logical processor) basis. See Section 19.19, “Performance Monitoring and Intel Hyper-Threading Technology in Processors Based on Intel NetBurst Microarchitecture,” for a discussion of performance monitoring in the Intel Xeon processor MP. In Intel Atom processor family that support Intel Hyper-Threading Technology, the performance counters (general-purpose and fixed-function counters) and their companion control MSRs are duplicated for each logical processor. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 15:57:21 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 423E81065673; Tue, 26 Jul 2011 15:57:21 +0000 (UTC) (envelope-from redcrash@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 95DFB8FC16; Tue, 26 Jul 2011 15:57:20 +0000 (UTC) Received: by wyg24 with SMTP id 24so361281wyg.13 for ; Tue, 26 Jul 2011 08:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/HvtLulwzvBW5Ye9aEN3XHQ88g4nkUUd0WLOuOFEme8=; b=gi4MycjvYqG+GEafaNisADOdIQBJfK2Q5XZbzQWsG43Cijih1I+HFVYL958QcIs4V7 qZmuFgUdjCDmIT+b8TSzYeyaN3k4COqQgSO7RHwVsF/4GYvvRC+NaOKLcLfKleftqZX3 mD25gY+rW/2yhRiDOgLaZOIfcmNLxKVkssNxU= MIME-Version: 1.0 Received: by 10.227.197.196 with SMTP id el4mr5259638wbb.103.1311694493857; Tue, 26 Jul 2011 08:34:53 -0700 (PDT) Received: by 10.227.128.12 with HTTP; Tue, 26 Jul 2011 08:34:53 -0700 (PDT) In-Reply-To: <4E2ED546.2080401@FreeBSD.org> References: <4E2ED546.2080401@FreeBSD.org> Date: Tue, 26 Jul 2011 17:34:53 +0200 Message-ID: From: Harald Servat To: Andriy Gapon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Hackers Subject: Re: HTT vs SMT in x86 SMP topology reporting X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 15:57:21 -0000 2011/7/26 Andriy Gapon > > Can anybody explain to me why our _x86_ SMP topology discovery and > reporting code > sometimes reports "HTT" and sometimes "SMT"? > As in > FreeBSD/SMP: %d package(s) x %d core(s) x %d HTT threads > vs > FreeBSD/SMP: %d package(s) x %d core(s) x %d SMT threads > > As I understand, and quoting Wikipedia (I know, I know), SMT stands for > simultaneous multithreading and is a generic term for a particular kind o= f > hardware multithreading: > http://en.wikipedia.org/wiki/Simultaneous_multithreading > > The only known (to me) implementation of SMT for x86 is Intel's > Hyper-Threading > Technology aka HTT aka HT Technology aka hyperthreading: > http://en.wikipedia.org/wiki/Hyper-threading > > http://software.intel.com/en-us/articles/intel-hyper-threading-technology= -your-questions-answered/?wapkw=3D%28Intel+Hyper-Threading+Technology%29 > > I understand that HTT implementation has evolved over time and there coul= d > be some > reasons to distinguish HTT as implemented in e.g. Pentium 4 from HTT as > implemented in the recent architectures like Nehalem and Sandy Bridge. > > But I still do not understand why we have to call the latter SMT when Int= el > calls > it HTT. > > Also, right now things like machdep.hyperthreading_allowed act only on ol= d > hyperthreads (what we report as "HTT") but completely ignore the new ones > (what we > report as "SMT"). I am not sure that this is correct either... > Perhaps there are no good reasons to disable HTT on modern CPUs, but the > current > behavior can definitely be confusing. > > In the end I would like to propose that we always report Intel HTT as HTT= . > Or even drop HTT/SMT from "x %d threads" altogether. > > Whether we should internally distinguish old HTT from new HTT is not clea= r > to me. > E.g. I see that for old HTT we bind interrupts only to one processing uni= t > (aka > logical processor aka hardware thread) from each hyperthreading pair. No= t > sure if > new HTT is so much better that we shouldn't be doing the same for it. > > P.S. Also currently distinction between old/new HTT technologies is made > based on > availability of CPUID leaf 0xB. Not sure if this is entirely accurate fo= r > e.g. > Atom processors, which we seem to detect as old HTT. > > A lengthy quote from volume 3A as an illustration: > 8.7.7 > Performance Monitoring Counters > Performance counters and their companion control MSRs are shared between > the > logical processors within a processor core for processors based on Intel > NetBurst > microarchitecture. As a result, software must manage the use of these > resources. > The performance counter interrupts, events, and precise event monitoring > support > can be set up and allocated on a per thread (per logical processor) basis= . > See Section 19.19, =93Performance Monitoring and Intel Hyper-Threading > Technology > in Processors Based on Intel NetBurst Microarchitecture,=94 for a discuss= ion > of > performance monitoring in the Intel Xeon processor MP. > In Intel Atom processor family that support Intel Hyper-Threading > Technology, the > performance counters (general-purpose and fixed-function counters) and > their > companion control MSRs are duplicated for each logical processor. > > -- > Andriy Gapon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > Andriy, regarding the nomenclature, IIRC, the IBM Power5 processors already had SMT back in 2004. However, I don't know if FreeBSD supports (or plans to support) this microprocessor. Whatever the name (or the string chosen) it looks that a single name should be given instead two in order to simplify things. With best regards. --=20 Fry: You can see how I lived before I met you. Bender: You lived before you met me?! Fry: Yeah, lots of people did. Bender: Really?! From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 18:19:38 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAA58106564A for ; Tue, 26 Jul 2011 18:19:38 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id A8A2E8FC17 for ; Tue, 26 Jul 2011 18:19:38 +0000 (UTC) Received: by gwb15 with SMTP id 15so589572gwb.13 for ; Tue, 26 Jul 2011 11:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=xT7N7xgqMLV8eKsqk7oFXy4K4rMg+jhflwfpDkm/PdI=; b=mP98+0a1M7Qsz9W9SMcebAvONwkfcn/uHMP6Uvuo4LrPYdQ6KBcFJDHdL3QU04N1BL jJampUf7JThT6FIquuA6OwPp/nooIvixY+Zikx2ZS0d4udIJiWzQvDajPoWRJIpxppzU fWLxeOVD5PHD1FKXTzW5bNb+BxLPz0C8Ob2fc= MIME-Version: 1.0 Received: by 10.142.140.13 with SMTP id n13mr1872604wfd.289.1311704377508; Tue, 26 Jul 2011 11:19:37 -0700 (PDT) Received: by 10.142.199.13 with HTTP; Tue, 26 Jul 2011 11:19:37 -0700 (PDT) In-Reply-To: References: <4E2D2FE7.4070907@rice.edu> <4E2DC07F.9070701@rice.edu> <4E2DCF02.4060009@rice.edu> Date: Tue, 26 Jul 2011 20:19:37 +0200 Message-ID: From: Davide Italiano To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: UMA large allocations issues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 18:19:39 -0000 It seems that today I've some good news. I've done some job. Before I tried stuffs userspace http://davit.altervista.org/malloc_new.c , then I improved my patch a bit http://davit.altervista.org/uma_large_allocations.patch ) So, the situation is follow. System starts (before it doesn't), but I've a fatal trap 9, hmm, that's not great, and I guess that's not fault of mine, it's caused from buf_hash_find() in arc.c I've taken a look at arc.c code but doesn't seems that that function performs large allocations. What I've done is taking two shots (one about the panic the other one about the bt http://dl.dropbox.com/u/3530969/zfs_fail.png http://dl.dropbox.com/u/3530969/zfs_fail2.png ) I thought in a first phase that the trouble was related to the fact that there weren't enough chunks, so I increased CHUNKS_SIZE variable (now it's set to 200), but the issue remains the same. Ideas? Cheers Davide From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 21:22:38 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33A86106566C; Tue, 26 Jul 2011 21:22:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id C53DC8FC12; Tue, 26 Jul 2011 21:22:37 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p6QLMY2k067067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jul 2011 00:22:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p6QLMYLu092585; Wed, 27 Jul 2011 00:22:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p6QLMYgE092583; Wed, 27 Jul 2011 00:22:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Jul 2011 00:22:34 +0300 From: Kostik Belousov To: Juergen Lock Message-ID: <20110726212234.GP17489@deviant.kiev.zoral.com.ua> References: <1311574719.49706.YahooMailClassic@web122313.mail.ne1.yahoo.com> <4E2D1275.8000305@yandex.ru> <20110726180335.GA82849@triton8.kn-bremen.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AfN0ITkBdUBwMG9P" Content-Disposition: inline In-Reply-To: <20110726180335.GA82849@triton8.kn-bremen.de> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Brandon Gooch , freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: wdrain vs. fuse/ggate (was: Re: mount vdi) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 21:22:38 -0000 --AfN0ITkBdUBwMG9P Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 26, 2011 at 08:03:35PM +0200, Juergen Lock wrote: > On Mon, Jul 25, 2011 at 06:31:36PM -0500, Brandon Gooch wrote: > > 2011/7/25 Andrey V. Elsukov : > > > On 25.07.2011 10:18, Joe Sciulli wrote: > > >> Is it possible to mount virtualbox vdi file on the FreeBSD host? =9A= This appears to be doable on > > >> windows and linux hosts, which basically is done in two steps: 1. fi= nd offset in the image. 2. > > >> mount the image with that offset. > > >> > > >> I'm trying to do the same thing on FreeBSD, and found the undocument= ed and deprecated command > > >> still works: > > >> > > >> VBoxManage internalcommands dumphdinfo freebsd_home.vdi > > >> > > >> I got the following for the virtual disk image holding the /home (no= root hence no MBR) disk for > > >> a FreeBSD guest: > > >> > > >> Header: offBlocks=3D4096 offData=3D28672 > > >> > > >> Then attempt to mount it: > > >> > > >> mdconfig -a -t vnode -f /tmp/freebsd_home_56.vdi -u 0 mount /dev/md0= /tmp/aaa/ mount -t cd9660 > > >> /dev/md0 /tmp/aaa/ > > >> > > >> unfortunately both the above two mount commands failed with "Invalid= argument". =9AI tried > > >> skip=3D28672 to no avail as well. =9AAnything did I do wrong? > > > > > > I have not any Vbox images with fixed size, but i tried this: > > > # mdconfig -f 10G_GPT_UFS.vdi > > > # gnop create -v -o 41472 /dev/md0 > > > > > > where 41472 is offData value. After that md0.nop was tasted and repor= ts about invalid GPT. > > > So, i think if your image is fixed size disk yout can try this method= and mount UFS (not cd9660). > > > > > > -- > > > WBR, Andrey V. Elsukov > >=20 > > There was a CFT sent out a while back about a fuse module for mounting > > vdi images: > >=20 > > http://lists.freebsd.org/pipermail/freebsd-emulation/2010-September/007= 964.html > >=20 > > Not sure about the state of this now though... >=20 > Yeah sorry I never got back to this after getting reports that > writes are stuck in wdrain... [1] I guess what happens is the > vdfuse process wants to write many(?) more blocks than the number > that got queued by the original fuse request and/or too many writes > get queued up at once before the vdfuse process gets to handle them > (trying to increase runningbufspace even more), and thus there is > deadlock. :( So my question for -hackers is, does anyone have a > clever idea how to fix this? Should the fuse requests for this be > exempted from the wdrain bookkeeping so that only the actual writes > by the vdfuse process get counted, and if yes, how would I best > accomplish this? >=20 > Thanx! :) > Juergen Excluding any buffers from runningbufspace is absolutely wrong. You will get another deadlock due to excessive pressure on the buffer space. --AfN0ITkBdUBwMG9P Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4vMBkACgkQC3+MBN1Mb4iB9ACgl7uXmuUfe1mmSVbQcAeWKwgd VPoAoLtD8YeHUQKqbJBWJP1fvywI8v0i =/Bak -----END PGP SIGNATURE----- --AfN0ITkBdUBwMG9P-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 22:06:09 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 404F41065674 for ; Tue, 26 Jul 2011 22:06:09 +0000 (UTC) (envelope-from s@samu.pl) Received: from samu.pl (samu.pl [IPv6:2001:41d0:1:f0cf::1]) by mx1.freebsd.org (Postfix) with ESMTP id 08D9C8FC17 for ; Tue, 26 Jul 2011 22:06:09 +0000 (UTC) Received: by samu.pl (Postfix, from userid 1001) id 3E6BDCD667; Wed, 27 Jul 2011 00:06:08 +0200 (CEST) To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 27 Jul 2011 00:06:08 +0200 From: s Message-ID: X-Sender: s@samu.pl User-Agent: RoundCube Webmail/0.5.1 Subject: Re: Finding symlink information in MAC Framework X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 22:06:09 -0000 On Mon, 25 Jul 2011 10:42:53 +0100 (BST), Robert Watson wrote: > On Fri, 15 Jul 2011, s wrote: > >> I am trying to get some information related to the symlink which is >> being accessed by the user in MAC Framework. Currently I managed to >> get the uid/gid of the owner of the symlink that is being read, but >> now I need to get the same information about the target, that the >> symlink points to. >> >> static int samplemac_vnode_check_link (struct ucred *cred, struct >> vnode *vp, >> struct label *vplabel) >> { >> >> int error; >> struct vattr vap; >> >> error = VOP_GETATTR(vp, &vap, cred); >> if (error) >> return (1); >> >> if(vap.va_uid != 0) { >> log(LOG_NOTICE, "stub_vnode_check_readlink: %i, gid: %i\n", >> vap.va_uid, vap.va_gid); >> return (0); >> } >> >> return (0); >> } >> >> And I have no idea how could I do that. Where should I look for that >> info? And what way would be the fastest? > > Hi Jakub: > > Could you say a bit more about what you're trying to accomplish? The > reason it's hard to express what you're trying to do (inspect the > target of a symlink during a read of the symlink) is that it's not > really a coherent concept in terms of kernel implementation. At the > point where the access control check on readlink is occuring, the > string hasn't yet been read from the link, and even if it had, you > couldn't look up the target object as you're already holding locks > relating to lookup and read of the symlink itself. Even if you > could, > there's also a risk of recursion: the symlink could point straight > back to where you are, etc. The readlink check is mid-lookup and > triggering an entirely fresh lookup from there might be quite awkward > for a number of such reasons. > > In general, however, this is not an issue for the policies we've > encountered thus far: they almost all care only about authorising > path > segment lookups (in which case readlink is just another segment in > evaluation), or absolute paths to objects reconstructed during the > actual operation on the target object, etc. Hence my wondering what > you're trying to accomplish -- the first question, really, is "is > what > you're trying to express actually safely expressible in a > fine-grained, multiprocessing kernel?" > > Robert Hello, In general, I am trying to compare the owner of the symlink to the owner of what the symlink points to, and then do some actions and return appropriate value, depending on how it will be configured to act. At first I was trying to check wheter some user is trying to create such a symlink, but I couldn't find such entry point in MAC Framework. -- Pozdrawiam, Jakub 'samu' Szafrański From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 22:16:15 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BE38106566B; Tue, 26 Jul 2011 22:16:15 +0000 (UTC) (envelope-from s@samu.pl) Received: from samu.pl (samu.pl [IPv6:2001:41d0:1:f0cf::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3010C8FC08; Tue, 26 Jul 2011 22:16:15 +0000 (UTC) Received: by samu.pl (Postfix, from userid 1001) id 5DEB6CD667; Wed, 27 Jul 2011 00:16:14 +0200 (CEST) To: Robert Watson MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 27 Jul 2011 00:16:14 +0200 From: s In-Reply-To: References: Message-ID: X-Sender: s@samu.pl User-Agent: RoundCube Webmail/0.5.1 Cc: freebsd-hackers@freebsd.org Subject: Re: Finding symlink information in MAC Framework X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 22:16:15 -0000 On Mon, 25 Jul 2011 10:42:53 +0100 (BST), Robert Watson wrote: > On Fri, 15 Jul 2011, s wrote: > >> I am trying to get some information related to the symlink which is >> being accessed by the user in MAC Framework. Currently I managed to >> get the uid/gid of the owner of the symlink that is being read, but >> now I need to get the same information about the target, that the >> symlink points to. >> >> static int samplemac_vnode_check_link (struct ucred *cred, struct >> vnode *vp, >> struct label *vplabel) >> { >> >> int error; >> struct vattr vap; >> >> error = VOP_GETATTR(vp, &vap, cred); >> if (error) >> return (1); >> >> if(vap.va_uid != 0) { >> log(LOG_NOTICE, "stub_vnode_check_readlink: %i, gid: %i\n", >> vap.va_uid, vap.va_gid); >> return (0); >> } >> >> return (0); >> } >> >> And I have no idea how could I do that. Where should I look for that >> info? And what way would be the fastest? > > Hi Jakub: > > Could you say a bit more about what you're trying to accomplish? The > reason it's hard to express what you're trying to do (inspect the > target of a symlink during a read of the symlink) is that it's not > really a coherent concept in terms of kernel implementation. At the > point where the access control check on readlink is occuring, the > string hasn't yet been read from the link, and even if it had, you > couldn't look up the target object as you're already holding locks > relating to lookup and read of the symlink itself. Even if you > could, > there's also a risk of recursion: the symlink could point straight > back to where you are, etc. The readlink check is mid-lookup and > triggering an entirely fresh lookup from there might be quite awkward > for a number of such reasons. > > In general, however, this is not an issue for the policies we've > encountered thus far: they almost all care only about authorising > path > segment lookups (in which case readlink is just another segment in > evaluation), or absolute paths to objects reconstructed during the > actual operation on the target object, etc. Hence my wondering what > you're trying to accomplish -- the first question, really, is "is > what > you're trying to express actually safely expressible in a > fine-grained, multiprocessing kernel?" > > Robert Hello, In general, I am trying to compare the owner of the symlink to the owner of what the symlink points to, and then do some actions and return appropriate value, depending on how it will be configured to act. At first I was trying to check wheter some user is trying to create such a symlink, but I couldn't find such entry point in MAC Framework. P.S My mail client did something messy and sent this reply to a wrong place, and I would like to apologize for that. I hope that THIS time, it will be sent to the right place. -- Pozdrawiam, Jakub 'samu' Szafrański From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 22:20:34 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8F531065670; Tue, 26 Jul 2011 22:20:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 46B8B8FC0C; Tue, 26 Jul 2011 22:20:33 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p6QMKRvO070558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jul 2011 01:20:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p6QMKRUI094612; Wed, 27 Jul 2011 01:20:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p6QMKRa9094611; Wed, 27 Jul 2011 01:20:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Jul 2011 01:20:27 +0300 From: Kostik Belousov To: Juergen Lock Message-ID: <20110726222027.GQ17489@deviant.kiev.zoral.com.ua> References: <1311574719.49706.YahooMailClassic@web122313.mail.ne1.yahoo.com> <4E2D1275.8000305@yandex.ru> <20110726180335.GA82849@triton8.kn-bremen.de> <20110726212234.GP17489@deviant.kiev.zoral.com.ua> <20110726213544.GA91944@triton8.kn-bremen.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tTJutuQz30oL/uz7" Content-Disposition: inline In-Reply-To: <20110726213544.GA91944@triton8.kn-bremen.de> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: wdrain vs. fuse/ggate (was: Re: mount vdi) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 22:20:34 -0000 --tTJutuQz30oL/uz7 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 26, 2011 at 11:35:44PM +0200, Juergen Lock wrote: > On Wed, Jul 27, 2011 at 12:22:34AM +0300, Kostik Belousov wrote: > > On Tue, Jul 26, 2011 at 08:03:35PM +0200, Juergen Lock wrote: > > > On Mon, Jul 25, 2011 at 06:31:36PM -0500, Brandon Gooch wrote: > > > > 2011/7/25 Andrey V. Elsukov : > > > > > On 25.07.2011 10:18, Joe Sciulli wrote: > > > > >> Is it possible to mount virtualbox vdi file on the FreeBSD host?= =9AThis appears to be doable on > > > > >> windows and linux hosts, which basically is done in two steps: 1= . find offset in the image. 2. > > > > >> mount the image with that offset. > > > > >> > > > > >> I'm trying to do the same thing on FreeBSD, and found the undocu= mented and deprecated command > > > > >> still works: > > > > >> > > > > >> VBoxManage internalcommands dumphdinfo freebsd_home.vdi > > > > >> > > > > >> I got the following for the virtual disk image holding the /home= (no root hence no MBR) disk for > > > > >> a FreeBSD guest: > > > > >> > > > > >> Header: offBlocks=3D4096 offData=3D28672 > > > > >> > > > > >> Then attempt to mount it: > > > > >> > > > > >> mdconfig -a -t vnode -f /tmp/freebsd_home_56.vdi -u 0 mount /dev= /md0 /tmp/aaa/ mount -t cd9660 > > > > >> /dev/md0 /tmp/aaa/ > > > > >> > > > > >> unfortunately both the above two mount commands failed with "Inv= alid argument". =9AI tried > > > > >> skip=3D28672 to no avail as well. =9AAnything did I do wrong? > > > > > > > > > > I have not any Vbox images with fixed size, but i tried this: > > > > > # mdconfig -f 10G_GPT_UFS.vdi > > > > > # gnop create -v -o 41472 /dev/md0 > > > > > > > > > > where 41472 is offData value. After that md0.nop was tasted and r= eports about invalid GPT. > > > > > So, i think if your image is fixed size disk yout can try this me= thod and mount UFS (not cd9660). > > > > > > > > > > -- > > > > > WBR, Andrey V. Elsukov > > > >=20 > > > > There was a CFT sent out a while back about a fuse module for mount= ing > > > > vdi images: > > > >=20 > > > > http://lists.freebsd.org/pipermail/freebsd-emulation/2010-September= /007964.html > > > >=20 > > > > Not sure about the state of this now though... > > >=20 > > > Yeah sorry I never got back to this after getting reports that > > > writes are stuck in wdrain... [1] I guess what happens is the > > > vdfuse process wants to write many(?) more blocks than the number > > > that got queued by the original fuse request and/or too many writes > > > get queued up at once before the vdfuse process gets to handle them > > > (trying to increase runningbufspace even more), and thus there is > > > deadlock. :( So my question for -hackers is, does anyone have a > > > clever idea how to fix this? Should the fuse requests for this be > > > exempted from the wdrain bookkeeping so that only the actual writes > > > by the vdfuse process get counted, and if yes, how would I best > > > accomplish this? > > >=20 > > > Thanx! :) > > > Juergen > >=20 > > Excluding any buffers from runningbufspace is absolutely wrong. > > You will get another deadlock due to excessive pressure on the buffer > > space. >=20 > Alright, so how to fix the deadlocks then? :) In general, you cannot, without rearchitecturing the buffer deadlock avoidance code. md(4) is in similar situation, but there the i/o does not leave kernel. You can look for VV_MD and similar hacks spreaded in sys/. --tTJutuQz30oL/uz7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4vPaoACgkQC3+MBN1Mb4gBUQCfTKTfOF1Tz8bn6WKZlvPSDlif /tgAnisKwFzEGgNnD6Q1w8ndavuC/NYI =GXuv -----END PGP SIGNATURE----- --tTJutuQz30oL/uz7-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 18:23:40 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A51EE106566B; Tue, 26 Jul 2011 18:23:40 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 5DAD68FC0A; Tue, 26 Jul 2011 18:23:40 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 19CCD1E000D3; Tue, 26 Jul 2011 20:05:49 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id p6QI3Z4a083587; Tue, 26 Jul 2011 20:03:35 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id p6QI3ZCb083586; Tue, 26 Jul 2011 20:03:35 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Tue, 26 Jul 2011 20:03:35 +0200 To: Brandon Gooch Message-ID: <20110726180335.GA82849@triton8.kn-bremen.de> References: <1311574719.49706.YahooMailClassic@web122313.mail.ne1.yahoo.com> <4E2D1275.8000305@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 26 Jul 2011 23:04:17 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, "Andrey V. Elsukov" , Joe Sciulli , nox@jelal.kn-bremen.de Subject: wdrain vs. fuse/ggate (was: Re: mount vdi) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 18:23:40 -0000 On Mon, Jul 25, 2011 at 06:31:36PM -0500, Brandon Gooch wrote: > 2011/7/25 Andrey V. Elsukov : > > On 25.07.2011 10:18, Joe Sciulli wrote: > >> Is it possible to mount virtualbox vdi file on the FreeBSD host? �This appears to be doable on > >> windows and linux hosts, which basically is done in two steps: 1. find offset in the image. 2. > >> mount the image with that offset. > >> > >> I'm trying to do the same thing on FreeBSD, and found the undocumented and deprecated command > >> still works: > >> > >> VBoxManage internalcommands dumphdinfo freebsd_home.vdi > >> > >> I got the following for the virtual disk image holding the /home (no root hence no MBR) disk for > >> a FreeBSD guest: > >> > >> Header: offBlocks=4096 offData=28672 > >> > >> Then attempt to mount it: > >> > >> mdconfig -a -t vnode -f /tmp/freebsd_home_56.vdi -u 0 mount /dev/md0 /tmp/aaa/ mount -t cd9660 > >> /dev/md0 /tmp/aaa/ > >> > >> unfortunately both the above two mount commands failed with "Invalid argument". �I tried > >> skip=28672 to no avail as well. �Anything did I do wrong? > > > > I have not any Vbox images with fixed size, but i tried this: > > # mdconfig -f 10G_GPT_UFS.vdi > > # gnop create -v -o 41472 /dev/md0 > > > > where 41472 is offData value. After that md0.nop was tasted and reports about invalid GPT. > > So, i think if your image is fixed size disk yout can try this method and mount UFS (not cd9660). > > > > -- > > WBR, Andrey V. Elsukov > > There was a CFT sent out a while back about a fuse module for mounting > vdi images: > > http://lists.freebsd.org/pipermail/freebsd-emulation/2010-September/007964.html > > Not sure about the state of this now though... Yeah sorry I never got back to this after getting reports that writes are stuck in wdrain... [1] I guess what happens is the vdfuse process wants to write many(?) more blocks than the number that got queued by the original fuse request and/or too many writes get queued up at once before the vdfuse process gets to handle them (trying to increase runningbufspace even more), and thus there is deadlock. :( So my question for -hackers is, does anyone have a clever idea how to fix this? Should the fuse requests for this be exempted from the wdrain bookkeeping so that only the actual writes by the vdfuse process get counted, and if yes, how would I best accomplish this? Thanx! :) Juergen [1] http://fxr.watson.org/fxr/source/kern/vfs_bio.c?im=excerpts#L417 From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 21:36:46 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA2581065715; Tue, 26 Jul 2011 21:36:41 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id A2E288FC0C; Tue, 26 Jul 2011 21:36:40 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 5FA7A1E000D3; Tue, 26 Jul 2011 23:36:39 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id p6QLZiu3091957; Tue, 26 Jul 2011 23:35:44 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id p6QLZiW5091956; Tue, 26 Jul 2011 23:35:44 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Tue, 26 Jul 2011 23:35:44 +0200 To: Kostik Belousov Message-ID: <20110726213544.GA91944@triton8.kn-bremen.de> References: <1311574719.49706.YahooMailClassic@web122313.mail.ne1.yahoo.com> <4E2D1275.8000305@yandex.ru> <20110726180335.GA82849@triton8.kn-bremen.de> <20110726212234.GP17489@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110726212234.GP17489@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 26 Jul 2011 23:04:29 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: wdrain vs. fuse/ggate (was: Re: mount vdi) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 21:36:46 -0000 On Wed, Jul 27, 2011 at 12:22:34AM +0300, Kostik Belousov wrote: > On Tue, Jul 26, 2011 at 08:03:35PM +0200, Juergen Lock wrote: > > On Mon, Jul 25, 2011 at 06:31:36PM -0500, Brandon Gooch wrote: > > > 2011/7/25 Andrey V. Elsukov : > > > > On 25.07.2011 10:18, Joe Sciulli wrote: > > > >> Is it possible to mount virtualbox vdi file on the FreeBSD host? �This appears to be doable on > > > >> windows and linux hosts, which basically is done in two steps: 1. find offset in the image. 2. > > > >> mount the image with that offset. > > > >> > > > >> I'm trying to do the same thing on FreeBSD, and found the undocumented and deprecated command > > > >> still works: > > > >> > > > >> VBoxManage internalcommands dumphdinfo freebsd_home.vdi > > > >> > > > >> I got the following for the virtual disk image holding the /home (no root hence no MBR) disk for > > > >> a FreeBSD guest: > > > >> > > > >> Header: offBlocks=4096 offData=28672 > > > >> > > > >> Then attempt to mount it: > > > >> > > > >> mdconfig -a -t vnode -f /tmp/freebsd_home_56.vdi -u 0 mount /dev/md0 /tmp/aaa/ mount -t cd9660 > > > >> /dev/md0 /tmp/aaa/ > > > >> > > > >> unfortunately both the above two mount commands failed with "Invalid argument". �I tried > > > >> skip=28672 to no avail as well. �Anything did I do wrong? > > > > > > > > I have not any Vbox images with fixed size, but i tried this: > > > > # mdconfig -f 10G_GPT_UFS.vdi > > > > # gnop create -v -o 41472 /dev/md0 > > > > > > > > where 41472 is offData value. After that md0.nop was tasted and reports about invalid GPT. > > > > So, i think if your image is fixed size disk yout can try this method and mount UFS (not cd9660). > > > > > > > > -- > > > > WBR, Andrey V. Elsukov > > > > > > There was a CFT sent out a while back about a fuse module for mounting > > > vdi images: > > > > > > http://lists.freebsd.org/pipermail/freebsd-emulation/2010-September/007964.html > > > > > > Not sure about the state of this now though... > > > > Yeah sorry I never got back to this after getting reports that > > writes are stuck in wdrain... [1] I guess what happens is the > > vdfuse process wants to write many(?) more blocks than the number > > that got queued by the original fuse request and/or too many writes > > get queued up at once before the vdfuse process gets to handle them > > (trying to increase runningbufspace even more), and thus there is > > deadlock. :( So my question for -hackers is, does anyone have a > > clever idea how to fix this? Should the fuse requests for this be > > exempted from the wdrain bookkeeping so that only the actual writes > > by the vdfuse process get counted, and if yes, how would I best > > accomplish this? > > > > Thanx! :) > > Juergen > > Excluding any buffers from runningbufspace is absolutely wrong. > You will get another deadlock due to excessive pressure on the buffer > space. Alright, so how to fix the deadlocks then? :) Wondering... Juergen From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 07:40:11 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AFD9106566B; Wed, 27 Jul 2011 07:40:11 +0000 (UTC) (envelope-from etnapierala@googlemail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id DA1CE8FC08; Wed, 27 Jul 2011 07:40:10 +0000 (UTC) Received: by fxe6 with SMTP id 6so12231fxe.17 for ; Wed, 27 Jul 2011 00:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=NGWMyM9T4zHOUSEB4fOeh1SNjQ26JsS59QTz/vfWUy0=; b=UwnhNBhAoPS80jw6jRF88u18L7s79tjcHh4JbuqUN6MUcEzEfu57Wz7IzLVo9iFO/F 9vDh5Xy8/jDMDQtaGOIj2p5zFyhLWdwd0/34LiFPamVHn7FIDboGC8kgFpe/M/xNQ511 r1rReI1DGxsp8hC3dKio3d/V3rhY+FmIBmaJE= Received: by 10.223.160.65 with SMTP id m1mr7912586fax.28.1311752409081; Wed, 27 Jul 2011 00:40:09 -0700 (PDT) Received: from enapierala.whl (58.wheelsystems.com [83.12.187.58]) by mx.google.com with ESMTPS id o17sm189934fal.2.2011.07.27.00.40.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 00:40:08 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <20110724222224.GA64487@freebsd.org> Date: Wed, 27 Jul 2011 09:40:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0CEA161B-6767-4379-B923-585B3D4EA74E@freebsd.org> <86hb6e1bau.fsf@gmail.com> <589EB85A-1902-4643-A1FD-3C98445127DB@freebsd.org> <20110724222224.GA64487@freebsd.org> To: Alexander Best X-Mailer: Apple Mail (2.1244.3) Cc: Test Rat , freebsd-hackers@freebsd.org Subject: Re: Autosizing column widths in ps(1). X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 07:40:11 -0000 Wiadomo=B6=E6 napisana przez Alexander Best w dniu 25 lip 2011, o godz. = 00:22: > On Sun Jul 24 11, Edward Tomasz Napiera?a wrote: >> Wiadomo?? napisana przez Test Rat w dniu 22 lip 2011, o godz. 19:21: >>> Edward Tomasz Napiera?a writes: >>>=20 >>>> Patch below changes ps(1) to automatically size column widths = according to their >>>> contents. =46rom the user point of view, it prevents breaking = layout with too wide values >>>> and in most cases makes output narrower. =46rom the developer = point of view, it removes >>>> the need to specify widths. Testing is welcome - the patch = shouldn't change ps(1) >>>> behaviour except slightly changing the widths, but the code changes = are pretty large >>>> and it's quite possible I've missed something. >>>=20 >>> STAT column seems to be right-aligned when it was previously = left-aligned. >>> This makes sorting it harder, e.g. >>>=20 >>> $ ps ax | (IFS=3D; read h; echo $h; sort -k3) | less >>=20 >> Good catch, thanks! Updated patch, which also fixes two issues = affecting TTY column, >> is at http://people.freebsd.org/~trasz/ps-9.diff. >=20 > working great here. have you experienced any performance issues, due = to ps > having to iterate through all columns before constructing the output = in > comparison to the previous design? It had to iterate through them before; what has changed is that now it = stores the strings before printing them out. This means increased memory usage - if you = have thousands of processes, the new ps(1) will use tens of kilobytes of memory. = Hardly a showstopper, imho. > P.S.: one utility which would also benefit from auto column sizing is = top, for > sure! ;) The problem with top(1) is that you don't want your column widths to = change at every refresh. This is somewhat similar to the situation with = vmstat(8). -- If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 09:01:21 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D5CC106564A; Wed, 27 Jul 2011 09:01:21 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id C7C7D8FC15; Wed, 27 Jul 2011 09:01:20 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p6R91J1O019653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Jul 2011 02:01:20 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p6R91Jgn019652; Wed, 27 Jul 2011 02:01:19 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA00517; Wed, 27 Jul 11 01:57:18 PDT Date: Wed, 27 Jul 2011 08:57:27 -0700 From: perryh@pluto.rain.com To: s@samu.pl Message-Id: <4e303567.2SHj2vERr0n8Op6Q%perryh@pluto.rain.com> References: In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, rwatson@freebsd.org Subject: Re: Finding symlink information in MAC Framework X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 09:01:21 -0000 s wrote: > ... I am trying to compare the owner of the symlink to the owner > of what the symlink points to ... At first I was trying to check > wheter some user is trying to create such a symlink ... I've always considered the "ownership" and "permissions" of a symlink to be an artifact of the implementation, rather than having any real significance. Symlinks did not exist in Bell Labs Unix, at least as of 6th edition. IIUC they were invented at UCB to get around the limitation that a hard link could not cross a physical filesystem boundary (i.e. a mount point); symlinks would not have been needed had the entire logical filesystem been contained on a single, unpartitioned physical device because hard links could have been used instead. A hard link has no ownership or permissions of its own: it is just an additional directory entry pointing to the same inode as the target's original directory entry. (The permissions are stored in the inode, not in the directory entry.) Because the target of a symlink is (in the general case) not in the same physical filesystem as the symlink itself, the symlink has to be stored in its own inode -- and that inode, like any other, has "ownership" and "permission" fields which will inevitably contain some pattern of bits -- but it's not clear to me that anything is gained by assigning a meaning to those patterns. Getting back to the original problem, suppose you had no mounted filesystems (other than special cases like devfs or /proc), the entire logical filesystem tree being stored on a single device, so that any file on the system could be hard-linked into any directory on the system. How would you detect that "some user" had created a _hard_ link to some arbitrary file? From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 09:14:17 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB793106564A for ; Wed, 27 Jul 2011 09:14:17 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 950338FC1B for ; Wed, 27 Jul 2011 09:14:17 +0000 (UTC) Received: from [192.168.2.112] (host86-148-225-194.range86-148.btcentralplus.com [86.148.225.194]) by cyrus.watson.org (Postfix) with ESMTPSA id 9271E46B1A; Wed, 27 Jul 2011 05:14:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <4e303567.2SHj2vERr0n8Op6Q%perryh@pluto.rain.com> Date: Wed, 27 Jul 2011 10:14:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4e303567.2SHj2vERr0n8Op6Q%perryh@pluto.rain.com> To: perryh@pluto.rain.com X-Mailer: Apple Mail (2.1084) Cc: freebsd-hackers@freebsd.org, s@samu.pl Subject: Re: Finding symlink information in MAC Framework X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 09:14:17 -0000 On 27 Jul 2011, at 16:57, perryh@pluto.rain.com wrote: > s wrote: >=20 >> ... I am trying to compare the owner of the symlink to the owner >> of what the symlink points to ... At first I was trying to check >> wheter some user is trying to create such a symlink ... >=20 > I've always considered the "ownership" and "permissions" of a > symlink to be an artifact of the implementation, rather than > having any real significance. > ... > Because the target of a symlink is (in the general case) not > in the same physical filesystem as the symlink itself, the > symlink has to be stored in its own inode -- and that inode, > like any other, has "ownership" and "permission" fields which > will inevitably contain some pattern of bits -- but it's not > clear to me that anything is gained by assigning a meaning to > those patterns. One valid (but historically "after") reason to have owners on symlinks = is the sticky bit on directories: if you want to usefully authorise = deletions of symbolic links in /tmp, you really want an owner for them. > Getting back to the original problem, suppose you had no mounted > filesystems (other than special cases like devfs or /proc), the > entire logical filesystem tree being stored on a single device, so > that any file on the system could be hard-linked into any directory > on the system. How would you detect that "some user" had created a > _hard_ link to some arbitrary file? Right -- I'm not convinced that the suggested design is really coherent = in an underlying sense -- which is one reason it doesn't lend itself to = implementation. Creating a symlink doesn't involve actual access to the = target object at all, since it's really just an object with a string in = it that might point at something else. There's also no "atomic" moment = during today's lookup has all the information it needs to check the = suggested policy. The closest you could get would be to gather ownership = information at the time of readlink, caching it (perhaps in the process = label), and later checking it at the time of the later operation. = However, as many symlinks can be followed on the way to an underlying = object, it sounds like it would require a stack of owners, each of which = would have to be compared at the end. Robert= From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 18:48:40 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44C43106566B for ; Wed, 27 Jul 2011 18:48:40 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 3509D8FC12 for ; Wed, 27 Jul 2011 18:48:39 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p6RImdqQ046727 for ; Wed, 27 Jul 2011 11:48:39 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4E305D86.8080403@rawbw.com> Date: Wed, 27 Jul 2011 11:48:38 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110716 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: dhclient fails: DHCPNACK rejected X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:48:40 -0000 My dhclient session looks like this: # dhclient re0 DHCPREQUEST on re0 to 255.255.255.255 port 67 DHCPNACK from 192.168.0.1 rejected. DHCPREQUEST on re0 to 255.255.255.255 port 67 DHCPNACK from 192.168.0.1 rejected. DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 8 DHCPOFFER from 192.168.0.1 rejected. DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 17 DHCPOFFER from 192.168.0.1 rejected. DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 18 DHCPOFFER from 192.168.0.1 rejected. DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 9 DHCPOFFER from 192.168.0.1 rejected. No static lease files present: /var/db/dhclient.leases.*. dhcpcd has no problem setting up re0 on thisn host. This happens on the router DLink DIR-601 with the latest firmware. 8.2-STABLE amd64 Yuri From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 19:15:51 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D9151065670 for ; Wed, 27 Jul 2011 19:15:51 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id E58948FC16 for ; Wed, 27 Jul 2011 19:15:50 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p6RJFoe2052389; Wed, 27 Jul 2011 12:15:50 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4E3063E5.7010405@rawbw.com> Date: Wed, 27 Jul 2011 12:15:49 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110716 Thunderbird/5.0 MIME-Version: 1.0 To: Adam Vande More References: <4E305D86.8080403@rawbw.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: dhclient fails: DHCPNACK rejected X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 19:15:51 -0000 On 07/27/2011 12:06, Adam Vande More wrote: > Do you have a /etc/dhclient.conf on the box? > Reject statement was there. Sorry, forgot about this file, it was there for 5 years for unknown reason. Thank you, Yuri From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 19:32:21 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 211461065700 for ; Wed, 27 Jul 2011 19:32:21 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id A6DBA8FC17 for ; Wed, 27 Jul 2011 19:32:20 +0000 (UTC) Received: by fxe4 with SMTP id 4so611129fxe.13 for ; Wed, 27 Jul 2011 12:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SodC2f/fvdtonwt+is2S7z1qjjFvbvKLW7bg0UQPfPw=; b=XRCf2w697VoLipniaVCJK6s6q/cZFo/dzf1nXcISLyG0cynLL3TRMEXWcWIMVF4DTB 4yZE2fJQWnmpR6FgLa5bhnVCipHF+cHRxroJXkJ27/KrDKHZ8jg276KtIFLaItgzkLh3 t6+rewqO1pYyRt5x12hg6MJEBOT/90cXv6U6o= MIME-Version: 1.0 Received: by 10.223.144.136 with SMTP id z8mr58432fau.31.1311793611382; Wed, 27 Jul 2011 12:06:51 -0700 (PDT) Received: by 10.223.110.133 with HTTP; Wed, 27 Jul 2011 12:06:51 -0700 (PDT) In-Reply-To: <4E305D86.8080403@rawbw.com> References: <4E305D86.8080403@rawbw.com> Date: Wed, 27 Jul 2011 14:06:51 -0500 Message-ID: From: Adam Vande More To: Yuri Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: dhclient fails: DHCPNACK rejected X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 19:32:21 -0000 On Wed, Jul 27, 2011 at 1:48 PM, Yuri wrote: > DHCPOFFER from 192.168.0.1 rejected. > > No static lease files present: /var/db/dhclient.leases.*. > dhcpcd has no problem setting up re0 on thisn host. > This happens on the router DLink DIR-601 with the latest firmware. > Do you have a /etc/dhclient.conf on the box? -- Adam Vande More From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 04:36:12 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11AE5106564A for ; Thu, 28 Jul 2011 04:36:12 +0000 (UTC) (envelope-from ambrosehua@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id BEB7E8FC0A for ; Thu, 28 Jul 2011 04:36:11 +0000 (UTC) Received: by qyk38 with SMTP id 38so1608837qyk.13 for ; Wed, 27 Jul 2011 21:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tXTHX+CpaZDJwGDdGgPBsNRo6zDFX22flMRImNiby04=; b=oksEZ0YA4yAufAKHQBL4kNd4CfjqEmBwRft6DvWR2sD/9OwDDE6B+6qfqaM61eaABu IqdDUCH22BtL3+v3ZyJSJ+Kt0037jf2T4d2vmfZHRhWniVmvU1UwUkiV8vX7eeO1Tvm9 VIdFDl4pPRIbYGjW2A9gBO3YJ4B0Y71hNclKg= MIME-Version: 1.0 Received: by 10.229.215.68 with SMTP id hd4mr447954qcb.177.1311826212970; Wed, 27 Jul 2011 21:10:12 -0700 (PDT) Received: by 10.229.43.101 with HTTP; Wed, 27 Jul 2011 21:10:12 -0700 (PDT) In-Reply-To: <20110723135655.4479d190@fabiankeil.de> References: <20110722202811.17302hol2s3ar084@newwebmail.rawbw.com> <20110723135655.4479d190@fabiankeil.de> Date: Thu, 28 Jul 2011 12:10:12 +0800 Message-ID: From: ambrosehuang ambrose To: Fabian Keil Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Yuri , freebsd-hackers@freebsd.org Subject: Re: DTrace script asserts and kills the other process X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 04:36:12 -0000 > Yuri wrote: > > > I am trying to run this dtrace script: > > > > #!/usr/sbin/dtrace -s > > pid123:libc::entry > > { > > self->timestmp[probefunc] = timestmp; > > } > > pid123:libc::return > > /self->timestmp[probefunc] != 0/ > > { > > @function_duration[probefunc] = sum(timestmp - > > self->timestmp[probefunc]); timestmp[probefunc] = 0; > > } > > > > which I got from here: > > http://www.princeton.edu/~unix/Solaris/troubleshoot/dtrace.html > > replacing 123 with the pid of some running process. > > > > Result: dtrace utility asserts: > > Assertion failed: (dpr != NULL), file > > > /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c, > > line 751. > > Abort trap: 6 > > > > Also the target process is killed too: > > Killed: 9 > > > > 8.2-STABLE amd64 > > This is a known issue. You may be able to work around it by > letting dtrace start the traced process. > > There's already a PR about it: > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/158431 > but the limitation isn't mentioned in the wiki: > http://wiki.freebsd.org/DTrace/userland > > It's not clear to me if this has worked in the past or if it > works for other architectures (the reporter and I are both using > amd64, too). > > Fabian > I came across the same problem in 8.2-stable , it seemed the problem had been there since 8.2-release with userland dtrace integrated. I followed the PR185431 and found when dtrace started, it indeed attached to the traced process( dpr != NULL), but the traced process died soon, and according to the PR, this is "error in error" since the dtrace came accross error in dfatal .................................................................................................................................................... #3 0x0000000808d8af2d in dt_proc_lookup (dtp=0x80b841000, P=0x80d7ffb40, remove=0) at /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:751 #4 0x0000000808d8af92 in dt_proc_destroy (dtp=0x80b841000, P=0x80d7ffb40) at /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:763 #5 0x0000000808d8bc6e in dt_proc_hash_destroy (dtp=0x80b841000) at /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:1162 #6 0x0000000808daa4b5 in dtrace_close (dtp=0x80b841000) at /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_open.c:1554 #7 0x0000000000402775 in dfatal (fmt=0x408572 "no probes %s\n") at /usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:236 #8 0x0000000000406b2c in main (argc=3, argv=0x7ffffffed9c0) at /usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:1825 ..................................................................................................................................................... From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 09:46:40 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32D091065676 for ; Thu, 28 Jul 2011 09:46:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A16A18FC08 for ; Thu, 28 Jul 2011 09:46:38 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 50B8446B46; Thu, 28 Jul 2011 05:46:38 -0400 (EDT) Date: Thu, 28 Jul 2011 10:46:37 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: exorcistkiller In-Reply-To: <1311658044945-4633662.post@n5.nabble.com> Message-ID: References: <1311496832217-4627557.post@n5.nabble.com> <1311658044945-4633662.post@n5.nabble.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: Add setacl system call? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 09:46:40 -0000 On Mon, 25 Jul 2011, exorcistkiller wrote: > Another question while I'm reading the code. In ufs_acl.c, in static int > ufs_getacl_posix1e(struct vop_getacl_args *ap), you commented: As part of > the ACL is stored in the inode, and the rest in an EA, assemble both into a > final ACL product. From what I learned from Kirk's book, ACLs are supposed > be stored in extended attributes blocks. So what do you mean by "part of the > ACL is stores in the inode"? I know extended attributes blocks data can be > addressed by inode, but how to get ACL directly from the inode? POSIX.1e ACLs are defined as an extension to permissions: additional user entries, group entries, and a mask entry supplement the existing owner, group and other permission bits. Both the APIs and command line tools allow the portions of the ACL representing permission bits to be directly manipulated. For the purpose of the UFS implementation (and I suspect this to be common in other implementations as well), we keep the owner/group/other bits (or sometimes the mask bits) in the existing inode permissions field. All additional entries are stored in the extended attribute. This has some nice properties, not least: (1) stat(2) on the file still only needs look at the inode, not the extended attributes, making it faster. (2) chmod(2) can be implemented by writing out only the inode, also faster. (3) Files without extended ACLs don't need extended attributes stored. The inclusion of a "mask" field in POSIX.1e is motivated similarly: it is what allows stat(2) and chmod(2) to not touch extended ACL fields. This is what the commend means by part of the ACL being stored in the inode, and part in the extended attribute: any areas of an ACL that are actually permission mask entries go in the existing mode bits in the inode for efficiency reasons. Robert From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 09:49:55 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69E8F106564A; Thu, 28 Jul 2011 09:49:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 485788FC16; Thu, 28 Jul 2011 09:49:55 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id EE10E46B1A; Thu, 28 Jul 2011 05:49:54 -0400 (EDT) Date: Thu, 28 Jul 2011 10:49:54 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andriy Gapon In-Reply-To: <4E2ED546.2080401@FreeBSD.org> Message-ID: References: <4E2ED546.2080401@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Hackers Subject: Re: HTT vs SMT in x86 SMP topology reporting X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 09:49:55 -0000 On Tue, 26 Jul 2011, Andriy Gapon wrote: > Can anybody explain to me why our _x86_ SMP topology discovery and reporting > code sometimes reports "HTT" and sometimes "SMT"? As in FreeBSD/SMP: %d > package(s) x %d core(s) x %d HTT threads vs FreeBSD/SMP: %d package(s) x %d > core(s) x %d SMT threads > > As I understand, and quoting Wikipedia (I know, I know), SMT stands for > simultaneous multithreading and is a generic term for a particular kind of > hardware multithreading: > http://en.wikipedia.org/wiki/Simultaneous_multithreading > > The only known (to me) implementation of SMT for x86 is Intel's > Hyper-Threading Technology aka HTT aka HT Technology aka hyperthreading: > http://en.wikipedia.org/wiki/Hyper-threading > http://software.intel.com/en-us/articles/intel-hyper-threading-technology-your-questions-answered/?wapkw=%28Intel+Hyper-Threading+Technology%29 Several MIPS platforms we run on support SMT. Typically this means a set of "weaker" threads sharing a single core, usually context switching as a result of memory access stalls in other threads, and perhaps sharing particularly expensive CPU features, such as a TLB. They sometimes come with high-performance message-passing facilities between threads, or even between cores, to supplement shared memory and IPIs. It may be that HTT is, among other things, a trademark of Intel. Robert From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 15:55:50 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FF861065670; Thu, 28 Jul 2011 15:55:50 +0000 (UTC) (envelope-from jan.grant@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 5BE1B8FC08; Thu, 28 Jul 2011 15:55:50 +0000 (UTC) Received: from mail.ilrt.bris.ac.uk ([137.222.16.62]) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1QmSeH-0003Bf-P1; Thu, 28 Jul 2011 16:37:49 +0100 Received: from cse-jg.cse.bris.ac.uk ([137.222.12.37]:37563) by mail.ilrt.bris.ac.uk with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1QmSdS-0003bP-Ql; Thu, 28 Jul 2011 16:36:30 +0100 Date: Thu, 28 Jul 2011 16:36:30 +0100 (BST) From: jan.grant@bristol.ac.uk X-X-Sender: cmjg@tribble.ilrt.bris.ac.uk To: perryh@pluto.rain.com In-Reply-To: <4e303567.2SHj2vERr0n8Op6Q%perryh@pluto.rain.com> Message-ID: References: <4e303567.2SHj2vERr0n8Op6Q%perryh@pluto.rain.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ILRT-MailScanner-ID: 1QmSdS-0003bP-Ql X-ILRT-MailScanner: Found to be clean X-ILRT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.651, required 5, autolearn=not spam, ALL_TRUSTED -1.00, AWL 0.17, BAYES_00 -1.90, TW_EV 0.08) X-ILRT-MailScanner-From: jan.grant@bristol.ac.uk X-Spam-Status: No X-Spam-Score: -2.8 X-Spam-Level: -- Cc: freebsd-hackers@freebsd.org, rwatson@freebsd.org, s@samu.pl Subject: Re: Finding symlink information in MAC Framework X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:55:50 -0000 On Wed, 27 Jul 2011, perryh@pluto.rain.com wrote: > s wrote: > > > ... I am trying to compare the owner of the symlink to the owner > > of what the symlink points to ... At first I was trying to check > > wheter some user is trying to create such a symlink ... > > I've always considered the "ownership" and "permissions" of a > symlink to be an artifact of the implementation, rather than > having any real significance. > > Symlinks did not exist in Bell Labs Unix, at least as of > 6th edition. IIUC they were invented at UCB to get around > the limitation that a hard link could not cross a physical > filesystem boundary (i.e. a mount point); symlinks would > not have been needed had the entire logical filesystem been > contained on a single, unpartitioned physical device because > hard links could have been used instead. One additional thing that symlinks manage to do is to refer to directories as well as files; hard links to directories spawn problems such as requiring garbage collection and smarter filesystem descent algorithms, which is another reason they're typically prohibited except in the case where they're created by "mkdir". > Getting back to the original problem, suppose you had no mounted > filesystems (other than special cases like devfs or /proc), the > entire logical filesystem tree being stored on a single device, so > that any file on the system could be hard-linked into any directory > on the system. How would you detect that "some user" had created a > _hard_ link to some arbitrary file? FWIW one of the early unix systems I was exposed to permitted the creation of hard links by arbitrary users. This led to a denial of service situation whereby the original creators of files could be deprived of inodes in the quota system, and blocks too if they removed one of their files without checking if anyone else had it linked first. It was a multiuser system that hosted undergraduates, so obviously this wasn't just a theoretical problem. -- jan grant, University of Bristol. But not for much longer! Update your address books: jang@ioctl.org http://ioctl.org/jan/ Q: What's yellow and equivalent to the axiom of choice? A: Zorn's lemon. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 19:26:16 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D64BC106564A for ; Thu, 28 Jul 2011 19:26:16 +0000 (UTC) (envelope-from s@samu.pl) Received: from samu.pl (samu.pl [IPv6:2001:41d0:1:f0cf::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7501F8FC1A for ; Thu, 28 Jul 2011 19:26:16 +0000 (UTC) Received: by samu.pl (Postfix, from userid 1001) id 02B7ECD665; Thu, 28 Jul 2011 21:26:15 +0200 (CEST) To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 28 Jul 2011 21:26:14 +0200 From: s Message-ID: <86304693fe3634eeb038db14bdee8779@samu.pl> X-Sender: s@samu.pl User-Agent: RoundCube Webmail/0.5.1 Subject: MAC Framework, Socket information X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 19:26:16 -0000 Hi, I need to get some info about the socket being created by the user. What I want to do is log all TCP/UDP outgoing connections that are being made. I *need* to get the local and remote address, as well as the local and remote port. I managed to get all of the remote data, but this is useless to me, if I haven't got the local port. Here is what I have already written: static int slog_socket_check_connect(struct ucred *cred, struct socket *socket, struct label *socketlabel, struct sockaddr *sockaddr) { if(sockaddr->sa_family == AF_INET) { struct sockaddr_in sa; log(LOG_SECURITY | LOG_DEBUG, "Somebody made a socket: %d:%d (%d)\n", cred->cr_ruid, ntohs(((struct sockaddr_in*)sockaddr)->sin_port), ntohs(((struct in_endpoints*)sockaddr)->ie_lport) ); } return 0; } -- Pozdrawiam, Jakub 'samu' Szafrański From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 19:17:23 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C6FB106566C for ; Thu, 28 Jul 2011 19:17:23 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id BEEC78FC12 for ; Thu, 28 Jul 2011 19:17:21 +0000 (UTC) Received: from mr16.lnh.mail.rcn.net ([207.172.157.36]) by smtp02.lnh.mail.rcn.net with ESMTP; 28 Jul 2011 14:47:55 -0400 Received: from smtp04.lnh.mail.rcn.net (smtp04.lnh.mail.rcn.net [207.172.157.104]) by mr16.lnh.mail.rcn.net (MOS 4.2.3-GA) with ESMTP id BFG85272; Thu, 28 Jul 2011 14:47:54 -0400 X-Auth-ID: anat Received: from 209-6-61-133.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com (HELO utka.zajac) ([209.6.61.133]) by smtp04.lnh.mail.rcn.net with ESMTP; 28 Jul 2011 14:47:53 -0400 Message-ID: <4E31AED9.4000105@aldan.algebra.com> Date: Thu, 28 Jul 2011 14:47:53 -0400 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:5.0) Gecko/20110714 Thunderbird/5.0 MIME-Version: 1.0 To: hackers@FreeBSD.org X-Mailman-Approved-At: Thu, 28 Jul 2011 19:30:46 +0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: A style proposal for referring to upper-level directories in Makefiles X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 19:17:23 -0000 The most common method to refer to the upper directory in Makefile is as ${.CURDIR}/.. I'd like to propose we begin using ${.CURDIR:H} instead. For one this speeds up the filesystem-traversal for the invoked tool. And, perhaps more importantly, it makes the various build-logs look nicer (and be smaller). The lines in Makefiles will also be shorter (two characters per level instead of three). For example: --- secure/Makefile.inc 3 Aug 2009 08:13:06 -0000 1.25.10.1 +++ secure/Makefile.inc 28 Jul 2011 18:45:52 -0000 @@ -3,8 +3,8 @@ .include -.if exists(${.CURDIR}/../../lib/libcrypt/obj) -CRYPTOBJDIR= ${.CURDIR}/../../lib/libcrypt/obj +.if exists(${.CURDIR:H:H}/lib/libcrypt/obj) +CRYPTOBJDIR= ${.CURDIR:H:H}/lib/libcrypt/obj .else -CRYPTOBJDIR= ${.CURDIR}/../../lib/libcrypt +CRYPTOBJDIR= ${.CURDIR:H:H}/lib/libcrypt .endif @@ -14,4 +14,4 @@ .if ${MK_OPENSSH} != "no" -SSHDIR= ${.CURDIR}/../../../crypto/openssh +SSHDIR= ${.CURDIR:H:H:H}/crypto/openssh .endif The new method is functionally equivalent to the old and I see no drawbacks to it, do you? -mi From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 20:55:31 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18784106564A for ; Thu, 28 Jul 2011 20:55:31 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id DA8B88FC16 for ; Thu, 28 Jul 2011 20:55:30 +0000 (UTC) Received: by iyb11 with SMTP id 11so4401537iyb.13 for ; Thu, 28 Jul 2011 13:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=x1Huh7XG1UL8XpQPfMK4LA/YaRXIV+nlNMV31CN5ZU8=; b=gMF68KmvvKoDI3T4sppfuyDwwZEJLJSnxKxyjFuGjArbjEdyBariA73n+VL4PLd5o+ yGXsPe/7ama06KIoePsYn2o9e9LU4hfo6LNDbGvjCq8OKwxxRtIfoyVRAZDE0aWQlZpc ltUV2Gv2lTDGKevrkTxhYBqpZfSYDQ4D89F1g= Received: by 10.231.92.196 with SMTP id s4mr371811ibm.10.1311886530078; Thu, 28 Jul 2011 13:55:30 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.231.67.211 with HTTP; Thu, 28 Jul 2011 13:55:00 -0700 (PDT) In-Reply-To: <4E31AED9.4000105@aldan.algebra.com> References: <4E31AED9.4000105@aldan.algebra.com> From: Chris Rees Date: Thu, 28 Jul 2011 21:55:00 +0100 X-Google-Sender-Auth: ygOgD6Bnkg0AtLEvgVFgz-qXnHk Message-ID: To: "Mikhail T." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: A style proposal for referring to upper-level directories in Makefiles X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 20:55:31 -0000 On 28 July 2011 19:47, Mikhail T. wrote: > The most common method to refer to the upper directory in Makefile is as > ${.CURDIR}/.. > > I'd like to propose we begin using ${.CURDIR:H} instead. For one this spe= eds > up the filesystem-traversal for the invoked tool. And, perhaps more > importantly, it makes the various build-logs look nicer (and be smaller). > The lines in Makefiles will also be shorter (two characters per level > instead of three). For example: > > =A0 --- secure/Makefile.inc 3 Aug 2009 08:13:06 -0000 =A0 =A0 =A0 1.25.10= .1 > =A0 +++ secure/Makefile.inc 28 Jul 2011 18:45:52 -0000 > =A0 @@ -3,8 +3,8 @@ > =A0 =A0 .include > > =A0 -.if exists(${.CURDIR}/../../lib/libcrypt/obj) > =A0 -CRYPTOBJDIR=3D =A0 ${.CURDIR}/../../lib/libcrypt/obj > =A0 +.if exists(${.CURDIR:H:H}/lib/libcrypt/obj) > =A0 +CRYPTOBJDIR=3D =A0 ${.CURDIR:H:H}/lib/libcrypt/obj > =A0 =A0 .else > =A0 -CRYPTOBJDIR=3D =A0 ${.CURDIR}/../../lib/libcrypt > =A0 +CRYPTOBJDIR=3D =A0 ${.CURDIR:H:H}/lib/libcrypt > =A0 =A0 .endif > > =A0 @@ -14,4 +14,4 @@ > > =A0 =A0 .if ${MK_OPENSSH} !=3D "no" > =A0 -SSHDIR=3D =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0${.CURDIR}/../../../crypto/= openssh > =A0 +SSHDIR=3D =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0${.CURDIR:H:H:H}/crypto/ope= nssh > =A0 =A0 .endif > > The new method is functionally equivalent to the old and I see no drawbac= ks > to it, do you? > > =A0 -mi Not too convinced I'm afraid-- in the logs I can at least see at a glance where ${CURDIR} is, and how many directories it's traversing etc etc. Chris From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 22:30:14 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44C4F106566C for ; Thu, 28 Jul 2011 22:30:14 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 01F0A8FC08 for ; Thu, 28 Jul 2011 22:30:13 +0000 (UTC) Received: by vxg33 with SMTP id 33so3191727vxg.13 for ; Thu, 28 Jul 2011 15:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=d8gmuEshbjYP5mIzWWwKWREN5SaskN3XAi4/QAZ+pHw=; b=iO03kMsMGknp+5eh3J030cRvKyvC5HH+G0XgTlib36iVmQ76WX7K5oGHxfU7FF0FO6 ZLZtm3HU/2r5ye12fXQFJ8PHRuW04+s/oCqtqXcWIEkjVLehBrbKKyQNstV9HBpqMCTO oWlDU33lcMBVzwgtMss8Iz8HGIR5fQEF2WW1o= MIME-Version: 1.0 Received: by 10.220.150.2 with SMTP id w2mr167649vcv.19.1311890712629; Thu, 28 Jul 2011 15:05:12 -0700 (PDT) Received: by 10.220.176.2 with HTTP; Thu, 28 Jul 2011 15:05:12 -0700 (PDT) In-Reply-To: <4E31AED9.4000105@aldan.algebra.com> References: <4E31AED9.4000105@aldan.algebra.com> Date: Thu, 28 Jul 2011 15:05:12 -0700 Message-ID: From: Garrett Cooper To: "Mikhail T." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: A style proposal for referring to upper-level directories in Makefiles X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 22:30:14 -0000 On Thu, Jul 28, 2011 at 11:47 AM, Mikhail T. wr= ote: > The most common method to refer to the upper directory in Makefile is as > ${.CURDIR}/.. > > I'd like to propose we begin using ${.CURDIR:H} instead. For one this spe= eds > up the filesystem-traversal for the invoked tool. And, perhaps more > importantly, it makes the various build-logs look nicer (and be smaller). > The lines in Makefiles will also be shorter (two characters per level > instead of three). For example: > > =A0 --- secure/Makefile.inc 3 Aug 2009 08:13:06 -0000 =A0 =A0 =A0 1.25.10= .1 > =A0 +++ secure/Makefile.inc 28 Jul 2011 18:45:52 -0000 > =A0 @@ -3,8 +3,8 @@ > =A0 =A0 .include > > =A0 -.if exists(${.CURDIR}/../../lib/libcrypt/obj) > =A0 -CRYPTOBJDIR=3D =A0 ${.CURDIR}/../../lib/libcrypt/obj > =A0 +.if exists(${.CURDIR:H:H}/lib/libcrypt/obj) > =A0 +CRYPTOBJDIR=3D =A0 ${.CURDIR:H:H}/lib/libcrypt/obj > =A0 =A0 .else > =A0 -CRYPTOBJDIR=3D =A0 ${.CURDIR}/../../lib/libcrypt > =A0 +CRYPTOBJDIR=3D =A0 ${.CURDIR:H:H}/lib/libcrypt > =A0 =A0 .endif > > =A0 @@ -14,4 +14,4 @@ > > =A0 =A0 .if ${MK_OPENSSH} !=3D "no" > =A0 -SSHDIR=3D =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0${.CURDIR}/../../../crypto/= openssh > =A0 +SSHDIR=3D =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0${.CURDIR:H:H:H}/crypto/ope= nssh > =A0 =A0 .endif > > The new method is functionally equivalent to the old and I see no drawbac= ks > to it, do you? This might cause issues with symlink traversal (it's the one thing that came to mind). It wouldn't be a standard way to do things, but it could cause problems if this change was made. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 23:16:00 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C3151065674; Thu, 28 Jul 2011 23:16:00 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 37C1F8FC14; Thu, 28 Jul 2011 23:16:00 +0000 (UTC) Received: by gwb15 with SMTP id 15so3010081gwb.13 for ; Thu, 28 Jul 2011 16:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=hSTwwM525OOj8P/W2ykHzRAcvld2tL0GB2Qv/x15kDU=; b=v/5bPFFiwFsliHXa3mQxb3FkZnXJhUzCGuo1Xl5LgLefjJs4nKVDZOC9XjH8uileLR aiRinQZkYgsfKGKM3WbXtAlIr9LD/Z2it4mqXitvwDusQwAFmHunTure71oUC/28pA6M NqfT59pQ2mzxrgwt7JnYQ9gfYsIsnX7OTYzuo= MIME-Version: 1.0 Received: by 10.42.204.3 with SMTP id fk3mr447891icb.515.1311894959380; Thu, 28 Jul 2011 16:15:59 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.224.70 with HTTP; Thu, 28 Jul 2011 16:15:59 -0700 (PDT) Date: Fri, 29 Jul 2011 01:15:59 +0200 X-Google-Sender-Auth: T2-b-LZ6wLi-R0Bfa3XSv2fOyaA Message-ID: From: Robert Millan To: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, Ed Maste Content-Type: multipart/mixed; boundary=20cf303dd906095a4404a92959de Cc: Subject: [PATCH] Linux-like /proc/swaps for linprocfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 23:16:00 -0000 --20cf303dd906095a4404a92959de Content-Type: text/plain; charset=UTF-8 Please consider this patch, it implements Linux-like /proc/swaps for linprocfs. E.g. $ cat /proc/swaps Filename Type Size Used Priority /dev/zvol/dimoni/swap unknown 2097152 0 -1 -- Robert Millan --20cf303dd906095a4404a92959de Content-Type: text/x-patch; charset=US-ASCII; name="linprocfs_swaps.diff" Content-Disposition: attachment; filename="linprocfs_swaps.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gqocd3wm0 LS0tIGEvc3lzL2NvbXBhdC9saW5wcm9jZnMvbGlucHJvY2ZzLmMKKysrIGIvc3lzL2NvbXBhdC9s aW5wcm9jZnMvbGlucHJvY2ZzLmMKQEAgLTQ5OCw2ICs0OTgsNDQgQEAKIAlyZXR1cm4gKDApOwog fQogCitzdGF0aWMgaW50CitsaW5wcm9jZnNfZG9zd2FwcyhQRlNfRklMTF9BUkdTKQoreworCXN0 cnVjdCB4c3dkZXYgeHN3OworCWludCBtaWJbM10sIG1pYnNpemU7CisJc2l6ZV90IHNpemU7CisJ aW50IG47CisJbG9uZyBsb25nIHRvdGFsLCB1c2VkOworCWNoYXIgZGV2bmFtZVtTUEVDTkFNRUxF TiArIDFdOworCisJc2J1Zl9wcmludGYoc2IsICJGaWxlbmFtZVx0XHRcdFx0VHlwZVx0XHRTaXpl XHRVc2VkXHRQcmlvcml0eVxuIik7CisKKwltaWJzaXplID0gc2l6ZW9mIG1pYiAvIHNpemVvZiBt aWJbMF07CisKKwltaWJbMF0gPSBDVExfVk07CisJbWliWzFdID0gVk1fU1dBUF9JTkZPOworCisJ Zm9yIChuID0gMDsgOyBuKyspIHsKKwkJbWliWzJdID0gbjsKKwkJc2l6ZSA9IHNpemVvZih4c3cp OworCQlpZiAoa2VybmVsX3N5c2N0bCh0ZCwgbWliLCBtaWJzaXplLCAmeHN3LCAmc2l6ZSwgTlVM TCwgMCwKKwkJCU5VTEwsIDApICE9IDApCisJCQlicmVhazsKKworCQlzaXplID0gc2l6ZW9mKGRl dm5hbWUpOworCQlpZiAoa2VybmVsX3N5c2N0bGJ5bmFtZSh0ZCwgImtlcm4uZGV2bmFtZSIsIGRl dm5hbWUsICZzaXplLAorCQkJJnhzdy54c3dfZGV2LCBzaXplb2YgKHhzdy54c3dfZGV2KSwgTlVM TCwgMCkgIT0gMCkKKwkJCWJyZWFrOworCisJCXRvdGFsID0gKGxvbmcgbG9uZyl4c3cueHN3X25i bGtzICogUEFHRV9TSVpFIC8gMTAyNDsKKwkJdXNlZCAgPSAobG9uZyBsb25nKXhzdy54c3dfdXNl ZCAqIFBBR0VfU0laRSAvIDEwMjQ7CisKKwkJc2J1Zl9wcmludGYoc2IsICIvZGV2LyUtMzRzIHVu a25vd25cdFx0JXVcdCV1XHQtMVxuIiwgZGV2bmFtZSwgdG90YWwsIHVzZWQpOworCX0KKworCXJl dHVybiAoMCk7Cit9CisKIC8qCiAgKiBGaWxsZXIgZnVuY3Rpb24gZm9yIHByb2MvdXB0aW1lCiAg Ki8KQEAgLTE0ODYsNiArMTUyNCw4IEBACiAJICAgIE5VTEwsIE5VTEwsIE5VTEwsIDApOwogCXBm c19jcmVhdGVfZmlsZShyb290LCAic3RhdCIsICZsaW5wcm9jZnNfZG9zdGF0LAogCSAgICBOVUxM LCBOVUxMLCBOVUxMLCBQRlNfUkQpOworCXBmc19jcmVhdGVfZmlsZShyb290LCAic3dhcHMiLCAm bGlucHJvY2ZzX2Rvc3dhcHMsCisJICAgIE5VTEwsIE5VTEwsIE5VTEwsIFBGU19SRCk7CiAJcGZz X2NyZWF0ZV9maWxlKHJvb3QsICJ1cHRpbWUiLCAmbGlucHJvY2ZzX2RvdXB0aW1lLAogCSAgICBO VUxMLCBOVUxMLCBOVUxMLCBQRlNfUkQpOwogCXBmc19jcmVhdGVfZmlsZShyb290LCAidmVyc2lv biIsICZsaW5wcm9jZnNfZG92ZXJzaW9uLAotLS0gYS9zeXMvdm0vc3dhcF9wYWdlci5jCisrKyBi L3N5cy92bS9zd2FwX3BhZ2VyLmMKQEAgLTIzOTgsNyArMjM5OCw3IEBACiAKIFNZU0NUTF9JTlQo X3ZtLCBPSURfQVVUTywgbnN3YXBkZXYsIENUTEZMQUdfUkQsICZuc3dhcGRldiwgMCwKICAgICAi TnVtYmVyIG9mIHN3YXAgZGV2aWNlcyIpOwotU1lTQ1RMX05PREUoX3ZtLCBPSURfQVVUTywgc3dh cF9pbmZvLCBDVExGTEFHX1JELCBzeXNjdGxfdm1fc3dhcF9pbmZvLAorU1lTQ1RMX05PREUoX3Zt LCBWTV9TV0FQX0lORk8sIHN3YXBfaW5mbywgQ1RMRkxBR19SRCwgc3lzY3RsX3ZtX3N3YXBfaW5m bywKICAgICAiU3dhcCBzdGF0aXN0aWNzIGJ5IGRldmljZSIpOwogCiAvKgotLS0gYS9zeXMvdm0v dm1fcGFyYW0uaAorKysgYi9zeXMvdm0vdm1fcGFyYW0uaApAQCAtODQsNyArODQsOCBAQAogI2Rl ZmluZSBWTV9WX1BBR0VPVVRfRlJFRV9NSU4JOQkvKiBjbnQudl9wYWdlb3V0X2ZyZWVfbWluICov CiAjZGVmaW5lCVZNX1BBR0VPVVRfQUxHT1JJVEhNCTEwCS8qIHBhZ2VvdXQgYWxnb3JpdGhtICov CiAjZGVmaW5lIFZNX1NXQVBQSU5HX0VOQUJMRUQJMTEJLyogc3dhcHBpbmcgZW5hYmxlZCAqLwot I2RlZmluZQlWTV9NQVhJRAkJMTIJLyogbnVtYmVyIG9mIHZhbGlkIHZtIGlkcyAqLworI2RlZmlu ZQlWTV9TV0FQX0lORk8JCTEyCS8qIHN3YXBfaW5mbyAqLworI2RlZmluZQlWTV9NQVhJRAkJMTMJ LyogbnVtYmVyIG9mIHZhbGlkIHZtIGlkcyAqLwogCiAjZGVmaW5lIENUTF9WTV9OQU1FUyB7IFwK IAl7IDAsIDAgfSwgXApAQCAtOTksNiArMTAwLDcgQEAKIAl7ICJ2X3BhZ2VvdXRfZnJlZV9taW4i LCBDVExUWVBFX1VJTlR9LCBcCiAJeyAicGFnZW91dF9hbGdvcml0aG0iLCBDVExUWVBFX0lOVH0s IFwKIAl7ICJzd2FwX2VuYWJsZWQiLCBDVExUWVBFX0lOVH0sXAorCXsgInN3YXBfaW5mbyIsIENU TFRZUEVfU1RSVUNUfSxcCiB9CiAKIC8qCg== --20cf303dd906095a4404a92959de-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 23:32:56 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8812106564A; Thu, 28 Jul 2011 23:32:56 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 991AD8FC13; Thu, 28 Jul 2011 23:32:56 +0000 (UTC) Received: by iyb11 with SMTP id 11so4565740iyb.13 for ; Thu, 28 Jul 2011 16:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=EGVrSZYFPSBa12FJ7TlQ8DoajsuRgMKxQF+1N1/Yntc=; b=O4C/FBa3G9mchhf5jEdYUFHtpy77F9UxW8IS5IB7J03sV8P+PrAhQSaTAE/oG3dCsZ CxHz3DFt/dquI4Na4mz5Ov0U0Hj8xAf4u6fjLoQJGw2Fwl+4YgvLlUpO1Dck5ualGYkd ioQmYxml+BIwZ9C3/Q14cvVssgD1cJIMLpcMs= MIME-Version: 1.0 Received: by 10.42.73.9 with SMTP id q9mr472737icj.314.1311895975975; Thu, 28 Jul 2011 16:32:55 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.224.70 with HTTP; Thu, 28 Jul 2011 16:32:55 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Jul 2011 01:32:55 +0200 X-Google-Sender-Auth: DKRKZuG0of2JNQ-ndaWvcJcoEgU Message-ID: From: Robert Millan To: freebsd-hackers@freebsd.org, Ed Maste Content-Type: text/plain; charset=UTF-8 Cc: Subject: Re: [PATCH] FreeBSD compiler extensions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 23:32:56 -0000 Submitted as PR so that it's not forgotten: http://www.freebsd.org/cgi/query-pr.cgi?pr=159278 -- Robert Millan From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 23:33:39 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3EAF1065670; Thu, 28 Jul 2011 23:33:39 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 74BD08FC24; Thu, 28 Jul 2011 23:33:39 +0000 (UTC) Received: by gwb15 with SMTP id 15so3018688gwb.13 for ; Thu, 28 Jul 2011 16:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=0ixJxQVWQ/k2VCg8T1yg7ldRsA3FKM/acpt4UHyP/yg=; b=Jczxk1rNuF67hEt1wjivVq+F7vpLpAhndbf1XRsc6s6oN6kp9c2wK2gEy15YFZF5O+ M9m2syzNkNLmdpovlZRAhD3db8vc3SdDOf+MOtben5L+qAayM+WWciTMuFwmkigkNNID POxACEtbW+MCx4MlYjqIvx2nk5i9FXNcimexs= MIME-Version: 1.0 Received: by 10.42.146.133 with SMTP id j5mr458191icv.180.1311896017344; Thu, 28 Jul 2011 16:33:37 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.224.70 with HTTP; Thu, 28 Jul 2011 16:33:37 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Jul 2011 01:33:37 +0200 X-Google-Sender-Auth: g_HqYKKsQ3sCrOnZmUGYz5FEpAY Message-ID: From: Robert Millan To: freebsd-hackers@freebsd.org, Ed Maste Content-Type: text/plain; charset=UTF-8 Cc: Subject: Re: [PATCH] __FreeBSD_cc_version in X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 23:33:39 -0000 Submitted as PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=159279 -- Robert Millan From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 23:34:08 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 776AA1065677; Thu, 28 Jul 2011 23:34:08 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 36C8A8FC12; Thu, 28 Jul 2011 23:34:07 +0000 (UTC) Received: by iyb11 with SMTP id 11so4566966iyb.13 for ; Thu, 28 Jul 2011 16:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=wlgKzlKOYkgfj3WY/KcZmk2IsB1F+FmuKuYjzMus1PE=; b=Kem2zfX6mYpiYZ4LMUSbjKM0jQohEMYnrHz96gaecHxzcqQLQ+Pw7Lp56j+ZBizLUF dthr/1MXRy7PgCts/KTvTZ6KhCMWQ8Ri5+oBezla0HemrucEj4mSquk5eNEuhGVGydLx qsfV4HzrCJjjzA1uxxiDsAkL1W5QDhHDVtI2o= MIME-Version: 1.0 Received: by 10.42.133.201 with SMTP id i9mr466539ict.247.1311896047565; Thu, 28 Jul 2011 16:34:07 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.224.70 with HTTP; Thu, 28 Jul 2011 16:34:07 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Jul 2011 01:34:07 +0200 X-Google-Sender-Auth: Z8iFCWUcNchrrld8YZU0kvdPc2I Message-ID: From: Robert Millan To: freebsd-hackers@freebsd.org, Ed Maste Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: [PATCH] Improve utf-8 -> cp437 console map X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 23:34:08 -0000 Submitted as PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D159280 2011/7/10 Robert Millan : > This patch adds a few improvements to utf-8 -> cp436 console map > (mostly with Catalan characters in mind, but it probably benefits > other languages). > > The new mappings are as follows: > > =E2=96=AE -> =E2=96=88 > =C3=80=C3=88=C3=8D=C3=8F=C3=93=C3=92=C3=9A -> AEIIOOU > =C5=80 / =C4=BF -> l / L > > -- > Robert Millan > --=20 Robert Millan From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 23:35:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2456A106566B; Thu, 28 Jul 2011 23:35:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 913E58FC12; Thu, 28 Jul 2011 23:35:46 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p6SNZYnY060205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jul 2011 02:35:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p6SNZX7a028798; Fri, 29 Jul 2011 02:35:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p6SNZXVJ028797; Fri, 29 Jul 2011 02:35:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 29 Jul 2011 02:35:33 +0300 From: Kostik Belousov To: Robert Millan Message-ID: <20110728233533.GB17489@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DVQ8A37yL26ZH/UD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, Ed Maste Subject: Re: [PATCH] Linux-like /proc/swaps for linprocfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 23:35:47 -0000 --DVQ8A37yL26ZH/UD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 29, 2011 at 01:15:59AM +0200, Robert Millan wrote: > Please consider this patch, it implements Linux-like /proc/swaps for linp= rocfs. >=20 > E.g. >=20 > $ cat /proc/swaps > Filename Type Size Used P= riority > /dev/zvol/dimoni/swap unknown 2097152 0 -1 >=20 > --=20 > Robert Millan The patch is too hackish, IMHO. I would prefer to have an exported kernel function that fills xswdev by index, used both by vm_swap_info and linprocfs. For the device name, you would use sw_vp->v_rdev->si_name, see, for instance, the following fragment in the swapoff_all(): if (vn_isdisk(sp->sw_vp, NULL)) devname =3D sp->sw_vp->v_rdev->si_name; else devname =3D "[file]"; This could be another function that returns swap information by index. --DVQ8A37yL26ZH/UD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4x8kUACgkQC3+MBN1Mb4hLSQCfaZs58R1WxyV3tmZ59T0N6Z+k DeIAn22z6GLMtJGi3qP6zXo3Op4iL1Wz =Kq/Y -----END PGP SIGNATURE----- --DVQ8A37yL26ZH/UD-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 08:21:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95E721065674; Fri, 29 Jul 2011 08:21:47 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 597238FC13; Fri, 29 Jul 2011 08:21:47 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p6T8LQAQ019793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jul 2011 01:21:27 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p6T8LQ5m019792; Fri, 29 Jul 2011 01:21:26 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA09513; Fri, 29 Jul 11 01:17:14 PDT Date: Fri, 29 Jul 2011 08:17:21 -0700 From: perryh@pluto.rain.com To: jang@ioctl.org, jan.grant@bristol.ac.uk Message-Id: <4e32cf01.R6F64Wsxhnb+t0xb%perryh@pluto.rain.com> References: <4e303567.2SHj2vERr0n8Op6Q%perryh@pluto.rain.com> In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, rwatson@freebsd.org, s@samu.pl Subject: Re: Finding symlink information in MAC Framework X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 08:21:47 -0000 jan.grant@bristol.ac.uk wrote: > On Wed, 27 Jul 2011, perryh@pluto.rain.com wrote: ... > One additional thing that symlinks manage to do is to refer to > directories as well as files Yes; I left that aspect out by way of simplification since it did not seem pertinent to the OP's situation. > hard links to directories spawn problems such as requiring garbage > collection and smarter filesystem descent algorithms, which is > another reason they're typically prohibited except in the case > where they're created by "mkdir". or by "mv", when moving a directory within the same physical filesystem. The two biggest problems I'm aware of are: * They create the possibility that the filesystem is no longer a tree but a more general directed graph which may even be cyclic. The possibility of a cyclic graph would indeed require handling in utilities such as find(1) and "ls -R", but the only case I've thought of that would need garbage collection -- as opposed to some minor extension of the current reference-counting scheme -- would be detection of cycles that have become disconnected (unreachable from either the root or any currently-open directory). However, I think prohibition of hard-links to directories is not sufficient to prevent the creation of isolated cycles. Consider: $ mkdir -p /tmp/a/b/c/d/e/f/g $ cd /tmp/a/b/c/d/e $ mv /tmp/a/b f/g Unless either mv or the kernel goes to some trouble to detect the subterfuge, this will create an isolated cycle f/g/b/c/d/e/f/... * Where should my .. entry point, if links to me (other than my . entry and my subdirectories' .. entries) appear in more than one directory? > FWIW one of the early unix systems I was exposed to permitted the > creation of hard links by arbitrary users. Just _one_? I've never heard of any that did _not_ permit that! (AFAIK Posix requires it.) From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 07:42:32 2011 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DA31106564A for ; Fri, 29 Jul 2011 07:42:32 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 25E028FC16 for ; Fri, 29 Jul 2011 07:42:31 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id B6C985E45; Fri, 29 Jul 2011 07:27:06 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id p6T7R6Eq005605; Fri, 29 Jul 2011 07:27:06 GMT (envelope-from phk@phk.freebsd.dk) To: "Mikhail T." From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 28 Jul 2011 14:47:53 -0400." <4E31AED9.4000105@aldan.algebra.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 29 Jul 2011 07:27:06 +0000 Message-ID: <5604.1311924426@critter.freebsd.dk> X-Mailman-Approved-At: Fri, 29 Jul 2011 11:06:06 +0000 Cc: hackers@FreeBSD.org Subject: Re: A style proposal for referring to upper-level directories in Makefiles X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 07:42:32 -0000 In message <4E31AED9.4000105@aldan.algebra.com>, "Mikhail T." writes: >The most common method to refer to the upper directory in Makefile is as >${.CURDIR}/.. > >I'd like to propose we begin using ${.CURDIR:H} instead. This will make it even harder for people who try to compile our bits on alien systems without bmake. I am not sure if that is a concern we should care about. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 11:22:13 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B910106564A for ; Fri, 29 Jul 2011 11:22:13 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 683998FC15 for ; Fri, 29 Jul 2011 11:22:13 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id E12DB46B03; Fri, 29 Jul 2011 07:22:12 -0400 (EDT) Date: Fri, 29 Jul 2011 12:22:12 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: s In-Reply-To: <86304693fe3634eeb038db14bdee8779@samu.pl> Message-ID: References: <86304693fe3634eeb038db14bdee8779@samu.pl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1332473671-1311938532=:99726" Cc: freebsd-hackers@freebsd.org Subject: Re: MAC Framework, Socket information X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 11:22:13 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-1332473671-1311938532=:99726 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 28 Jul 2011, s wrote: > I need to get some info about the socket being created by the user. What I > want to do is log all TCP/UDP outgoing connections that are being made. I > *need* to get the local and remote address, as well as the local and remote > port. I managed to get all of the remote data, but this is useless to me, if > I haven't got the local port. Here is what I have already written: Most MAC Framework entry points are invoked before operations of interest, rather than after, because they are intended to perform access control on operations. I think the closest you may be able to get given current entry points is logging when the first operation is performed on the connected socket: i.e., read, write, sendfile, etc, since it will be established at that point (some caution required: you can invoke system calls on sockets before and during connect()). However, I can't help but wonder: would you be better-served by using the kernel's audit facilities to track events like socket connection? Are you blending access control and logging in your module, or is this really just about logging? Robert > > static int slog_socket_check_connect(struct ucred *cred, > struct socket *socket, struct label *socketlabel, > struct sockaddr *sockaddr) > { > if(sockaddr->sa_family == AF_INET) { > struct sockaddr_in sa; > log(LOG_SECURITY | LOG_DEBUG, "Somebody made a socket: %d:%d > (%d)\n", > cred->cr_ruid, > ntohs(((struct sockaddr_in*)sockaddr)->sin_port), > ntohs(((struct in_endpoints*)sockaddr)->ie_lport) > ); > } > return 0; > } > > -- > Pozdrawiam, > Jakub 'samu' Szafrański > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > --621616949-1332473671-1311938532=:99726-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 13:17:53 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14E2D1065675 for ; Fri, 29 Jul 2011 13:17:53 +0000 (UTC) (envelope-from eng.mufic@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id E5EAF8FC0A for ; Fri, 29 Jul 2011 13:17:52 +0000 (UTC) Received: by pzk5 with SMTP id 5so18641757pzk.17 for ; Fri, 29 Jul 2011 06:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=TqzTppvWs9QCbP7/ButW+B0LceTHSHjlOd5V5cjkYww=; b=TLmuzaMFX/vJIBZfBRQCWYZOO0+CR6QV9LBuFeGuwL6q78pdk3PbHMKd9rQaMQBMDN I6mUcw7f9NrFX2kJ3HydXm+flqhfqeKu37znWbRakljfEJWgDX0rlY1Wiz9nxI6SjSTt THnU1ig++4amy7OOiGgL0oJVBM5BOFOb9jjoA= MIME-Version: 1.0 Received: by 10.68.17.5 with SMTP id k5mr2178921pbd.92.1311945472293; Fri, 29 Jul 2011 06:17:52 -0700 (PDT) Sender: eng.mufic@gmail.com Received: by 10.68.55.132 with HTTP; Fri, 29 Jul 2011 06:17:52 -0700 (PDT) Date: Fri, 29 Jul 2011 16:17:52 +0300 X-Google-Sender-Auth: 9rfuIrOIIDQHb4-lTeDmrxMRGjM Message-ID: From: Mohammed Farrag To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD Summer Course X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 13:17:53 -0000 Hello FreeBSDers, I have uploaded the FreeBSD summer course materials. It's good course for beginners. You can check it and I will be glad to receive your comments and suggestions for future courses. https://sites.google.com/site/arabbsd/freebsd-summer-course Regards, -- *Mohammed Farrag* * * From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 13:22:46 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83258106564A for ; Fri, 29 Jul 2011 13:22:46 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm25.bullet.mail.sp2.yahoo.com (nm25.bullet.mail.sp2.yahoo.com [98.139.91.95]) by mx1.freebsd.org (Postfix) with SMTP id 68D888FC0A for ; Fri, 29 Jul 2011 13:22:46 +0000 (UTC) Received: from [98.139.91.68] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 29 Jul 2011 13:10:29 -0000 Received: from [208.71.42.204] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 29 Jul 2011 13:10:29 -0000 Received: from [127.0.0.1] by smtp215.mail.gq1.yahoo.com with NNFMP; 29 Jul 2011 13:10:28 -0000 X-Yahoo-Newman-Id: 603486.69553.bm@smtp215.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: nx3UDjQVM1nUxpXtb1JlViSRKEOMi0UqlaweJ0aNxHkelSd SNEFL2N_Qo1vqrTW6MTcb_13IR33mlJ4ULYKdASqXvhZfu_zYbU43v7fAn4y zv_VJXsLYXtz8hivM4LVedzz6I9U2qVX8vdADYcg7Hgg9hYN3J46QjnBOrB2 gxxbHN21C2cXqFpsJCtR90EJLbpK9tpnmnKuFSIBcHVCmbF1Ukmy.dzkXBI7 kYxJh_EFI_HiNkuY09QRJc_j6HDojl7KMzZW_TklDOYdObHRM4ChOGOlnqO6 XpbrVnK0F1FPatRbt7GlSTxcoPJN.a0ar_kbsg3t.pgFTNN7z5PuH1cGy_M. Xqnk2KHqrPGhCR_6FA7LYUeWKEw-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.146.76 with plain) by smtp215.mail.gq1.yahoo.com with SMTP; 29 Jul 2011 06:10:24 -0700 PDT Message-ID: <4E32B139.8030807@freebsd.org> Date: Fri, 29 Jul 2011 15:10:17 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: installworld fails with /usr/bin and /usr/sbin on separate file systems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 13:22:46 -0000 Installworld fails in "usr.sbin/chown" with a cross-device link error, if /usr/bin and /usr/sbin are not on the same partition due to the following line in Makefile: LINKS= ${BINDIR}/chown /usr/bin/chgrp In this case, ${BINDIR} is /usr/sbin and while both are subdirectories of /usr (and thus typically within the /usr file system), there is no reason /usr/bin and /usr/sbin could not be individual and independent file systems. (I ran into this problem when I played with ZFS file system tuning and happened to create separate file systems for the above directories.) I could not find any other place, where a hard link is used for files in different subdirectories (typically ${BINDIR}/x -> ${BINDIR}/y or ${LIBDIR}/x -> ${LIBDIR}/y). Installworld succeeds, if a symlink is used instead: SYMLINKS= ${BINDIR}/chown /usr/bin/chgrp Alternatively, the file could be copied, if the hard link can not be created. I'm not sure, whether this is an actual problem, since it does not appear to have been reported before, but I think that "LINK=..." should generally not be used between different directories. Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 14:57:44 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F48D1065672 for ; Fri, 29 Jul 2011 14:57:44 +0000 (UTC) (envelope-from bsdlisten@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D21EB8FC13 for ; Fri, 29 Jul 2011 14:57:43 +0000 (UTC) Received: by fxe4 with SMTP id 4so3235035fxe.13 for ; Fri, 29 Jul 2011 07:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=IisRNY0LAyvUs6LWuSPMt4u/Pe1QAhUIpxFSgxNQJUo=; b=hlqSPR5751/xpXnN6BljKDZFbihdHJJiUMS3FXHM6mDtG/TMwkt8/4AXwIareEo3ex yzUVKJRn5zsRhWFOTQQHHF5kvG4bm9z2ydPtZXCGOQIdvZao3QUF5qzesp4le1Rjm/ct Q+q1tDPtnnPlYAs/EnwV+NYiLHaQvc37QzYxg= Received: by 10.223.18.25 with SMTP id u25mr1881223faa.69.1311950106151; Fri, 29 Jul 2011 07:35:06 -0700 (PDT) Received: from [192.168.0.105] ([89.47.83.116]) by mx.google.com with ESMTPS id y15sm1102728fah.35.2011.07.29.07.35.03 (version=SSLv3 cipher=OTHER); Fri, 29 Jul 2011 07:35:04 -0700 (PDT) Message-ID: <4E32C516.3000206@gmail.com> Date: Fri, 29 Jul 2011 17:35:02 +0300 From: Rares Aioanei User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Icedove/3.1.11 MIME-Version: 1.0 To: hackers@FreeBSD.org Content-Type: multipart/mixed; boundary="------------070208050506080506030206" Cc: Subject: Small fetch(1) patch to improve xfer stats readability X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 14:57:44 -0000 This is a multi-part message in MIME format. --------------070208050506080506030206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit While fetch, (as invoked by portsnap, in my case) displays the completion percentage just fine, when it reaches 100% the output becomes a little messy : - of Now, when it gets to 100%, the string "100%" gets stuck by the hashnumber, e.g. '98727300a76bn062f901100% completed of 65 MB 500KBps 00:00 This little patch fixes the problem. Since this is my first attempt at sending a patch, please bare with me. :-) --------------070208050506080506030206 Content-Type: text/x-patch; name="fetch.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="fetch.patch" 213c213 < fprintf(stderr, " %3d%% of %s", --- > fprintf(stderr, "%3d%% of %s", --------------070208050506080506030206-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 15:08:32 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFDDE106564A for ; Fri, 29 Jul 2011 15:08:32 +0000 (UTC) (envelope-from bsdlisten@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6CC4B8FC0C for ; Fri, 29 Jul 2011 15:08:31 +0000 (UTC) Received: by fxe4 with SMTP id 4so3246436fxe.13 for ; Fri, 29 Jul 2011 08:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=U5MBIhqJvmUQ3MdoHPKth+VLbfqvuiz3Pb2KWAGH/9o=; b=u/hLUR+CoMbx8qlQgJtJZ8e5V8RGxieNsplvWz+Wm8MBEzdU2U6YjcO3VPrqux6lh2 onTfpdEYLmV/TFFCbSQ4e+WK+IRf25rHZd/h+yOimxzUQpa8RVaLkhjpSTz1PKHUO6Ca 5H9z3kauCJiwcuCJ3aH6Q8vJsNHO4BS7F0SvI= Received: by 10.223.54.90 with SMTP id p26mr1951261fag.44.1311950347828; Fri, 29 Jul 2011 07:39:07 -0700 (PDT) Received: from [192.168.0.105] ([89.47.83.116]) by mx.google.com with ESMTPS id e10sm1129869fak.18.2011.07.29.07.39.06 (version=SSLv3 cipher=OTHER); Fri, 29 Jul 2011 07:39:06 -0700 (PDT) Message-ID: <4E32C609.3030108@gmail.com> Date: Fri, 29 Jul 2011 17:39:05 +0300 From: Rares Aioanei User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Icedove/3.1.11 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary="------------030903060605040705020900" Subject: Small fetch(1) patch to improve xfer stats readability X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 15:08:33 -0000 This is a multi-part message in MIME format. --------------030903060605040705020900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit While fetch, (as invoked by portsnap, in my case) displays the completion percentage just fine, when it reaches 100% the output becomes a little messy : - of Now, when it gets to 100%, the string "100%" gets stuck by the hashnumber, e.g. '98727300a76bn062f901100% completed of 65 MB 500KBps 00:00 This little patch fixes the problem. Since this is my first attempt at sending a patch, please bare with me. :-) --------------030903060605040705020900 Content-Type: text/x-patch; name="fetch.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="fetch.patch" 213c213 < fprintf(stderr, " %3d%% of %s", --- > fprintf(stderr, "%3d%% of %s", --------------030903060605040705020900-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 15:12:41 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF1AB106566B for ; Fri, 29 Jul 2011 15:12:41 +0000 (UTC) (envelope-from james@freedomnet.co.nz) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 6C4E88FC12 for ; Fri, 29 Jul 2011 15:12:41 +0000 (UTC) Received: by qyk30 with SMTP id 30so3999601qyk.13 for ; Fri, 29 Jul 2011 08:12:40 -0700 (PDT) Received: by 10.52.89.100 with SMTP id bn4mr1496927vdb.280.1311952360642; Fri, 29 Jul 2011 08:12:40 -0700 (PDT) Received: from [192.168.15.127] (westford-nat.juniper.net [66.129.232.2]) by mx.google.com with ESMTPS id cy1sm1043655vdc.14.2011.07.29.08.12.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jul 2011 08:12:39 -0700 (PDT) From: James Jones Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (9A5220p) Message-Id: <565C98BA-9B92-4F07-A747-DDA5DC3D7703@freedomnet.co.nz> Date: Fri, 29 Jul 2011 11:12:35 -0400 To: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: MIPS toolchain X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 15:12:41 -0000 Does anyone have a prebuilt MIPS tool chain? Sent from my iPhone From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 15:15:40 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59755106564A for ; Fri, 29 Jul 2011 15:15:40 +0000 (UTC) (envelope-from cbergstrom@pathscale.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 3624B8FC08 for ; Fri, 29 Jul 2011 15:15:39 +0000 (UTC) Received: by pzk5 with SMTP id 5so19078595pzk.17 for ; Fri, 29 Jul 2011 08:15:39 -0700 (PDT) Received: by 10.68.5.3 with SMTP id o3mr2659583pbo.344.1311952539510; Fri, 29 Jul 2011 08:15:39 -0700 (PDT) Received: from [192.168.1.33] (ppp-61-90-24-15.revip.asianet.co.th [61.90.24.15]) by mx.google.com with ESMTPS id k3sm669581pbj.13.2011.07.29.08.15.36 (version=SSLv3 cipher=OTHER); Fri, 29 Jul 2011 08:15:37 -0700 (PDT) Message-ID: <4E32CE7A.8070708@pathscale.com> Date: Fri, 29 Jul 2011 22:15:06 +0700 From: =?ISO-8859-1?Q?=22C=2E_Bergstr=F6m=22?= User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.7) Gecko/20101031 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: James Jones References: <565C98BA-9B92-4F07-A747-DDA5DC3D7703@freedomnet.co.nz> In-Reply-To: <565C98BA-9B92-4F07-A747-DDA5DC3D7703@freedomnet.co.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" Subject: Re: MIPS toolchain X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 15:15:40 -0000 On 07/29/11 10:12 PM, James Jones wrote: > Does anyone have a prebuilt MIPS tool chain? If you need MIPS64 then maybe I could get some binaries built or a cross compiler. (Can't help with MIPS32 though) From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 15:59:35 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2988E106564A for ; Fri, 29 Jul 2011 15:59:35 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id D81428FC13 for ; Fri, 29 Jul 2011 15:59:34 +0000 (UTC) Received: by qwc9 with SMTP id 9so2679665qwc.13 for ; Fri, 29 Jul 2011 08:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=dNoQl7UKQd+MBq0/Lj5XH7AGJGYeuiqUH3agqS6tPfQ=; b=d6niVBZ6d1s0iJ6sgl9+T17ZFiG00HXYk6Pnq2V2kyXSLX3QtWkBwyl342UBS07jKR idG6V7sYXjyIQa+n7640Mm+Wc9MInS13xLSagJuh1U3IBIvZua3k7TW92hyd4Ga0Qvp3 Vv8E2vZmKnwTq28A2WQy6Ra+jFiDRllRI4NE8= Received: by 10.229.2.89 with SMTP id 25mr1148797qci.39.1311955174280; Fri, 29 Jul 2011 08:59:34 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id e10sm1460879qcq.16.2011.07.29.08.59.31 (version=SSLv3 cipher=OTHER); Fri, 29 Jul 2011 08:59:32 -0700 (PDT) Date: Fri, 29 Jul 2011 11:59:26 -0400 From: Alexander Kabaev To: James Jones Message-ID: <20110729115926.6648f64f@kan.dnsalias.net> In-Reply-To: <565C98BA-9B92-4F07-A747-DDA5DC3D7703@freedomnet.co.nz> References: <565C98BA-9B92-4F07-A747-DDA5DC3D7703@freedomnet.co.nz> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/TXULIkFV1LY1JFKH3ar_URL"; protocol="application/pgp-signature" Cc: freebsd-hackers@freebsd.org Subject: Re: MIPS toolchain X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 15:59:35 -0000 --Sig_/TXULIkFV1LY1JFKH3ar_URL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 29 Jul 2011 11:12:35 -0400 James Jones wrote: > Does anyone have a prebuilt MIPS tool chain? >=20 There's so many unanswered details in this loaded question one cannot possibly hope to answer it correctly. Are you asking for what mips ISA and ABIs? What is to be used as a host? In general, toolchain is generally quite easy to build as cross-tool, assuming FreeBSD supports the target. --=20 Alexander Kabaev --Sig_/TXULIkFV1LY1JFKH3ar_URL Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iD8DBQFOMtjiQ6z1jMm+XZYRAn7LAJ0cz2DbFHMnXbN/rw4vUY7im+QVdQCeLCgp qNGY8mersKSy9JYJO+8ivog= =vhVt -----END PGP SIGNATURE----- --Sig_/TXULIkFV1LY1JFKH3ar_URL-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 14:00:54 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B00D71065670 for ; Fri, 29 Jul 2011 14:00:54 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 62DE88FC0A for ; Fri, 29 Jul 2011 14:00:54 +0000 (UTC) Received: from mr16.lnh.mail.rcn.net ([207.172.157.36]) by smtp02.lnh.mail.rcn.net with ESMTP; 29 Jul 2011 10:00:53 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr16.lnh.mail.rcn.net (MOS 4.2.3-GA) with ESMTP id BFH78659; Fri, 29 Jul 2011 10:00:52 -0400 Received-SPF: None identity=pra; client-ip=209.6.61.133; receiver=smtp01.lnh.mail.rcn.net; envelope-from="mi+thun@aldan.algebra.com"; x-sender="mi+thun@aldan.algebra.com"; x-conformance=sidf_compatible Received-SPF: None identity=mailfrom; client-ip=209.6.61.133; receiver=smtp01.lnh.mail.rcn.net; envelope-from="mi+thun@aldan.algebra.com"; x-sender="mi+thun@aldan.algebra.com"; x-conformance=sidf_compatible Received-SPF: None identity=helo; client-ip=209.6.61.133; receiver=smtp01.lnh.mail.rcn.net; envelope-from="mi+thun@aldan.algebra.com"; x-sender="postmaster@utka.zajac"; x-conformance=sidf_compatible X-Auth-ID: anat Received: from 209-6-61-133.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com (HELO utka.zajac) ([209.6.61.133]) by smtp01.lnh.mail.rcn.net with ESMTP; 29 Jul 2011 10:00:51 -0400 Message-ID: <4E32BD0D.2000907@aldan.algebra.com> Date: Fri, 29 Jul 2011 10:00:45 -0400 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:5.0) Gecko/20110714 Thunderbird/5.0 MIME-Version: 1.0 To: hackers@FreeBSD.org References: <5604.1311924426@critter.freebsd.dk> In-Reply-To: <5604.1311924426@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 29 Jul 2011 16:28:12 +0000 Cc: Subject: Re: A style proposal for referring to upper-level directories in Makefiles X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 14:00:54 -0000 On 29.07.2011 03:27, Poul-Henning Kamp wrote: > This will make it even harder for people who try to compile our > bits on alien systems without bmake. Bits referring to multiple directories at once? Using a make flavor, that already supports .CURDIR, but not .CURDIR:H? Do such things even exist? Personally, when I need to build a sizable BSD program on another system, I begin with building bmake (NetBSD's pkgsrc project helps with that). Or, if it is not a big program, I just create a GNUmakefile from scratch -- gmake is omnipresent these days. > I am not sure if that is a concern we should care about. I don't think, we should either... -mi From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 19:14:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D0401065672; Fri, 29 Jul 2011 19:14:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 3AFAE8FC12; Fri, 29 Jul 2011 19:14:46 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p6TJEdKa048641 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 29 Jul 2011 12:14:43 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E330699.9000002@freebsd.org> Date: Fri, 29 Jul 2011 12:14:33 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Alexander V. Chernikov" References: <20110717.004248.48765964696292481.hrs@allbsd.org> <4E21BA0B.6080800@ipfw.ru> In-Reply-To: <4E21BA0B.6080800@ipfw.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, "Bjoern A. Zeeb" , dudu@dudu.ro, freebsd-net@freebsd.org Subject: Re: FIB separation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 19:14:47 -0000 On 7/16/11 9:19 AM, Alexander V. Chernikov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hiroki Sato wrote: >> Vlad Galu wrote >> in: >> >> du> Hello, >> du> >> du> A couple of years ago, Stef Walter proposed a patch[1] that enforced >> du> the scope of routing messages. The general consesus was that the best >> du> approach would be the OpenBSD way - transporting the FIB number in the >> du> message and letting the user applications filter out unwanted >> du> messages. >> du> >> du> Are there any plans to tackle this before 9.0? >> >> I am looking into this and investigating other possible extensions in >> rtsock messages such as addition of a fib member to rt_msghdr. I am >> not sure it can be done before 9.0, though... > Actually there were an off-list discussion with bz@ and julian@ about > interface fibs and rtsock changes several weeks ago. > > Initial messages: > http://lists.freebsd.org/pipermail/freebsd-net/2011-June/029040.html > > I've got 3 different patches: > 1) straight forwarded kern/134931 fix (no fib in rtsock, no breaking > ABI, send to bz@) just got back from vacation in hungary so catching up...: Didn't he commit it? bz?? > 2) adding fib in rtsock with rtsock versioning and other ABI keeping tricks > 3) adding special RTA which can contain TLV pairs, with single defined > TLV with routing socket > > As a result of discussion, first patch was sent to bz@. Since patches > from kern/134931 are outdated attaching it here. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 20:59:14 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BE21106566B for ; Fri, 29 Jul 2011 20:59:14 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 4CCF58FC16 for ; Fri, 29 Jul 2011 20:59:14 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id A3F005615B; Fri, 29 Jul 2011 15:41:57 -0500 (CDT) Date: Fri, 29 Jul 2011 15:41:57 -0500 From: Mark Linimon To: Garrett Cooper Message-ID: <20110729204157.GA21217@lonesome.com> References: <4E31AED9.4000105@aldan.algebra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Fri, 29 Jul 2011 21:15:40 +0000 Cc: "Mikhail T." , hackers@freebsd.org Subject: Re: A style proposal for referring to upper-level directories in Makefiles X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 20:59:14 -0000 To me, it just makes things less readable. mcl From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 23:06:50 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A6F7106564A; Fri, 29 Jul 2011 23:06:50 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 01D3B8FC0A; Fri, 29 Jul 2011 23:06:49 +0000 (UTC) Received: by gyf3 with SMTP id 3so3647496gyf.13 for ; Fri, 29 Jul 2011 16:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=crIB1YtFeyTU1UVBqMAssHWXHqBrvs+ZkDCKsYlh4lc=; b=jcrHPX0CmZexVuPaWeIfbwFLJUXR551p7M2R+dvACpP4f6BXHpRNa42jngCmer5XbL 10A4npjO3LIP7m2amZinsfjvqRIc55BRqVlRYxhXwsBCQsaRPWlk2CQykRleBRRdLp4q JiMmXNDaRyrcz0gP6wf3k+ven5Br9mJC2Hhco= MIME-Version: 1.0 Received: by 10.42.100.72 with SMTP id z8mr1439039icn.448.1311980809034; Fri, 29 Jul 2011 16:06:49 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.224.70 with HTTP; Fri, 29 Jul 2011 16:06:48 -0700 (PDT) Date: Sat, 30 Jul 2011 01:06:48 +0200 X-Google-Sender-Auth: 3drzq0i8rkhNUPRI31X-irylzMc Message-ID: From: Robert Millan To: Kostik Belousov Content-Type: multipart/mixed; boundary=90e6ba613be8131d7804a93d56e9 Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, Ed Maste Subject: Re: kern/159281: [PATCH] Linux-like /proc/swaps for linprocfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 23:06:50 -0000 --90e6ba613be8131d7804a93d56e9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Kostik, 2011/7/29 Kostik Belousov : > The patch is too hackish, IMHO. > I would prefer to have an exported kernel function that fills xswdev > by index, used both by vm_swap_info and linprocfs. > > For the device name, you would use sw_vp->v_rdev->si_name, see, for > instance, the following fragment in the swapoff_all(): > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (vn_isdisk(sp->= sw_vp, NULL)) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0devname =3D sp->sw_vp->v_rdev->si_name; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0else > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0devname =3D "[file]"; > This could be another function that returns swap information by index. Here's a patch with the changes you requested. --=20 Robert Millan --90e6ba613be8131d7804a93d56e9 Content-Type: text/x-patch; charset=US-ASCII; name="006_proc_swaps.diff" Content-Disposition: attachment; filename="006_proc_swaps.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gqprh89i1 LS0tIGEvc3lzL2NvbXBhdC9saW5wcm9jZnMvbGlucHJvY2ZzLmMKKysrIGIvc3lzL2NvbXBhdC9s aW5wcm9jZnMvbGlucHJvY2ZzLmMKQEAgLTUwMiw2ICs1MDIsMzIgQEAKIAlyZXR1cm4gKDApOwog fQogCitzdGF0aWMgaW50CitsaW5wcm9jZnNfZG9zd2FwcyhQRlNfRklMTF9BUkdTKQoreworCXN0 cnVjdCB4c3dkZXYgeHN3OworCWludCBuOworCWxvbmcgbG9uZyB0b3RhbCwgdXNlZDsKKwljaGFy IGRldm5hbWVbU1BFQ05BTUVMRU4gKyAxXTsKKworCXNidWZfcHJpbnRmKHNiLCAiRmlsZW5hbWVc dFx0XHRcdFR5cGVcdFx0U2l6ZVx0VXNlZFx0UHJpb3JpdHlcbiIpOworCisJZm9yIChuID0gMDsg OyBuKyspIHsKKwkJaWYgKHN3YXBfaW5mbyhuLCAmeHN3KSAhPSAwKQorCQkJYnJlYWs7CisKKwkJ aWYgKHN3YXBfZGV2bmFtZShuLCBkZXZuYW1lLCBzaXplb2YoZGV2bmFtZSkpICE9IDApCisJCQli cmVhazsKKworCQl0b3RhbCA9IChsb25nIGxvbmcpeHN3Lnhzd19uYmxrcyAqIFBBR0VfU0laRSAv IDEwMjQ7CisJCXVzZWQgID0gKGxvbmcgbG9uZyl4c3cueHN3X3VzZWQgKiBQQUdFX1NJWkUgLyAx MDI0OworCisJCXNidWZfcHJpbnRmKHNiLCAiL2Rldi8lLTM0cyB1bmtub3duXHRcdCVsbGRcdCVs bGRcdC0xXG4iLCBkZXZuYW1lLCB0b3RhbCwgdXNlZCk7CisJfQorCisJcmV0dXJuICgwKTsKK30K KwogLyoKICAqIEZpbGxlciBmdW5jdGlvbiBmb3IgcHJvYy91cHRpbWUKICAqLwpAQCAtMTQ5MCw2 ICsxNTE2LDggQEAKIAkgICAgTlVMTCwgTlVMTCwgTlVMTCwgMCk7CiAJcGZzX2NyZWF0ZV9maWxl KHJvb3QsICJzdGF0IiwgJmxpbnByb2Nmc19kb3N0YXQsCiAJICAgIE5VTEwsIE5VTEwsIE5VTEws IFBGU19SRCk7CisJcGZzX2NyZWF0ZV9maWxlKHJvb3QsICJzd2FwcyIsICZsaW5wcm9jZnNfZG9z d2FwcywKKwkgICAgTlVMTCwgTlVMTCwgTlVMTCwgUEZTX1JEKTsKIAlwZnNfY3JlYXRlX2ZpbGUo cm9vdCwgInVwdGltZSIsICZsaW5wcm9jZnNfZG91cHRpbWUsCiAJICAgIE5VTEwsIE5VTEwsIE5V TEwsIFBGU19SRCk7CiAJcGZzX2NyZWF0ZV9maWxlKHJvb3QsICJ2ZXJzaW9uIiwgJmxpbnByb2Nm c19kb3ZlcnNpb24sCi0tLSBhL3N5cy92bS9zd2FwX3BhZ2VyLmMKKysrIGIvc3lzL3ZtL3N3YXBf cGFnZXIuYwpAQCAtMjMxNSw2ICsyMzE1LDMxIEBACiAJcmV0dXJuICgwKTsKIH0KIAoraW50Citz d2FwX2Rldm5hbWUoaW50IG5hbWUsIGNoYXIgKmRldm5hbWUsIHNpemVfdCBsZW4pCit7CisJaW50 CW47CisJc3RydWN0IHN3ZGV2dCAqc3A7CisJY2hhcgkqdG1wX2Rldm5hbWU7CisKKwluID0gMDsK KwltdHhfbG9jaygmc3dfZGV2X210eCk7CisJVEFJTFFfRk9SRUFDSChzcCwgJnN3dGFpbHEsIHN3 X2xpc3QpIHsKKwkJaWYgKG4gPT0gbmFtZSkgeworCQkJaWYgKHZuX2lzZGlzayhzcC0+c3dfdnAs IE5VTEwpKQorCQkJCXRtcF9kZXZuYW1lID0gc3AtPnN3X3ZwLT52X3JkZXYtPnNpX25hbWU7CisJ CQllbHNlCisJCQkJdG1wX2Rldm5hbWUgPSAiW2ZpbGVdIjsKKwkJCXN0cm5jcHkoZGV2bmFtZSwg dG1wX2Rldm5hbWUsIGxlbik7CisJCQltdHhfdW5sb2NrKCZzd19kZXZfbXR4KTsKKwkJCXJldHVy biAoMCk7CisJCX0KKwkJbisrOworCX0KKwltdHhfdW5sb2NrKCZzd19kZXZfbXR4KTsKKwlyZXR1 cm4gKEVOT0VOVCk7Cit9CisKIHZvaWQKIHN3YXBvZmZfYWxsKHZvaWQpCiB7CkBAIC0yMzY1LDMw ICsyMzkwLDI0IEBACiAJbXR4X3VubG9jaygmc3dfZGV2X210eCk7CiB9CiAKLXN0YXRpYyBpbnQK LXN5c2N0bF92bV9zd2FwX2luZm8oU1lTQ1RMX0hBTkRMRVJfQVJHUykKK2ludAorc3dhcF9pbmZv KGludCBuYW1lLCBzdHJ1Y3QgeHN3ZGV2ICp4cykKIHsKLQlpbnQJKm5hbWUgPSAoaW50ICopYXJn MTsKIAlpbnQJZXJyb3IsIG47Ci0Jc3RydWN0IHhzd2RldiB4czsKIAlzdHJ1Y3Qgc3dkZXZ0ICpz cDsKIAotCWlmIChhcmcyICE9IDEpIC8qIG5hbWUgbGVuZ3RoICovCi0JCXJldHVybiAoRUlOVkFM KTsKLQogCW4gPSAwOwogCW10eF9sb2NrKCZzd19kZXZfbXR4KTsKIAlUQUlMUV9GT1JFQUNIKHNw LCAmc3d0YWlscSwgc3dfbGlzdCkgewotCQlpZiAobiA9PSAqbmFtZSkgeworCQlpZiAobiA9PSBu YW1lKSB7CiAJCQltdHhfdW5sb2NrKCZzd19kZXZfbXR4KTsKLQkJCXhzLnhzd192ZXJzaW9uID0g WFNXREVWX1ZFUlNJT047Ci0JCQl4cy54c3dfZGV2ID0gc3AtPnN3X2RldjsKLQkJCXhzLnhzd19m bGFncyA9IHNwLT5zd19mbGFnczsKLQkJCXhzLnhzd19uYmxrcyA9IHNwLT5zd19uYmxrczsKLQkJ CXhzLnhzd191c2VkID0gc3AtPnN3X3VzZWQ7CisJCQl4cy0+eHN3X3ZlcnNpb24gPSBYU1dERVZf VkVSU0lPTjsKKwkJCXhzLT54c3dfZGV2ID0gc3AtPnN3X2RldjsKKwkJCXhzLT54c3dfZmxhZ3Mg PSBzcC0+c3dfZmxhZ3M7CisJCQl4cy0+eHN3X25ibGtzID0gc3AtPnN3X25ibGtzOworCQkJeHMt Pnhzd191c2VkID0gc3AtPnN3X3VzZWQ7CiAKLQkJCWVycm9yID0gU1lTQ1RMX09VVChyZXEsICZ4 cywgc2l6ZW9mKHhzKSk7Ci0JCQlyZXR1cm4gKGVycm9yKTsKKwkJCXJldHVybiAoMCk7CiAJCX0K IAkJbisrOwogCX0KQEAgLTIzOTYsNiArMjQxNSwyNCBAQAogCXJldHVybiAoRU5PRU5UKTsKIH0K IAorc3RhdGljIGludAorc3lzY3RsX3ZtX3N3YXBfaW5mbyhTWVNDVExfSEFORExFUl9BUkdTKQor eworCWludAkqbmFtZSA9IChpbnQgKilhcmcxOworCWludAllcnJvcjsKKwlzdHJ1Y3QgeHN3ZGV2 IHhzOworCisJaWYgKGFyZzIgIT0gMSkgLyogbmFtZSBsZW5ndGggKi8KKwkJcmV0dXJuIChFSU5W QUwpOworCisJZXJyb3IgPSBzd2FwX2luZm8oKm5hbWUsICZ4cyk7CisJaWYgKGVycm9yICE9IDAp CisJCXJldHVybiAoZXJyb3IpOworCisJZXJyb3IgPSBTWVNDVExfT1VUKHJlcSwgJnhzLCBzaXpl b2YoeHMpKTsKKwlyZXR1cm4gKGVycm9yKTsKK30KKwogU1lTQ1RMX0lOVChfdm0sIE9JRF9BVVRP LCBuc3dhcGRldiwgQ1RMRkxBR19SRCwgJm5zd2FwZGV2LCAwLAogICAgICJOdW1iZXIgb2Ygc3dh cCBkZXZpY2VzIik7CiBTWVNDVExfTk9ERShfdm0sIE9JRF9BVVRPLCBzd2FwX2luZm8sIENUTEZM QUdfUkQsIHN5c2N0bF92bV9zd2FwX2luZm8sCi0tLSBhL3N5cy92bS9zd2FwX3BhZ2VyLmgKKysr IGIvc3lzL3ZtL3N3YXBfcGFnZXIuaApAQCAtODMsNiArODMsOCBAQAogaW50IHN3YXBfcGFnZXJf cmVzZXJ2ZSh2bV9vYmplY3RfdCwgdm1fcGluZGV4X3QsIHZtX3NpemVfdCk7CiB2b2lkIHN3YXBf cGFnZXJfc3RhdHVzKGludCAqdG90YWwsIGludCAqdXNlZCk7CiB2b2lkIHN3YXBvZmZfYWxsKHZv aWQpOworaW50IHN3YXBfaW5mbyhpbnQgbmFtZSwgc3RydWN0IHhzd2RldiAqeHMpOworaW50IHN3 YXBfZGV2bmFtZShpbnQgbmFtZSwgY2hhciAqZGV2bmFtZSwgc2l6ZV90IGxlbik7CiAKICNlbmRp ZgkJCQkvKiBfS0VSTkVMICovCiAjZW5kaWYJCQkJLyogX1ZNX1NXQVBfUEFHRVJfSF8gKi8K --90e6ba613be8131d7804a93d56e9-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 30 12:52:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 106C0106564A; Sat, 30 Jul 2011 12:52:57 +0000 (UTC) (envelope-from guillemj@ono.com) Received: from resmaa14.ono.com (smtp14.ono.com [62.42.230.176]) by mx1.freebsd.org (Postfix) with ESMTP id BEFC18FC0A; Sat, 30 Jul 2011 12:52:56 +0000 (UTC) Received: from gaara.hadrons.org (85.136.146.198) by resmaa14.ono.com (8.5.113) (authenticated as guillemj@ono.com) id 4D7F86D501BDD83D; Sat, 30 Jul 2011 14:40:31 +0200 Received: from guillem by gaara.hadrons.org with local (Exim 4.76) (envelope-from ) id 1Qn8qE-0001z2-18; Sat, 30 Jul 2011 14:40:30 +0200 Date: Sat, 30 Jul 2011 14:40:29 +0200 From: Guillem Jover To: Robert Millan Message-ID: <20110730124029.GA2817@gaara.hadrons.org> Mail-Followup-To: Robert Millan , Ed Schouten , freebsd-hackers@freebsd.org, Ed Maste , debian-hurd@lists.debian.org References: <20110707100123.GF71453@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: debian-hurd@lists.debian.org, Ed Schouten , Ed Maste , freebsd-hackers@freebsd.org Subject: Re: [PATCH] avoid assuming MAXPATHLEN in config(8) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 12:52:57 -0000 Hi! On Thu, 2011-07-07 at 13:12:03 +0200, Robert Millan wrote: > 2011/7/7 Ed Schouten : > > Even though it is good to make our code conform to standards as much as > > possible, do keep in mind that your patch also causes a lot of > > regressions in that area. The code now uses asprintf(), which is not > > part of POSIX. I also think the use of __GLIBC__ is frowned upon. > > Uhm... you're right. Actually I knew asprintf() is not part of POSIX, > it just didn't occur to me that this contradicted my point about > MAXPATHLEN [1]. > [1] Btw, POSIX itself is quite contradictory too: it doesn't let you > assume MAXPATHLEN, but it doesn't give you the facilities you need in > case it isn't present (e.g. asprintf and canonicalize_file_name but > gethostname and getline / fgetln come to mind too). Well, canonicalize_file_name() has been standardized in POSIX.1-2008 as realpath(path, NULL), which GNU/* and FreeBSD have supported for a long time. getline() is also part of POSIX.1-2008. regards, guillem From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 30 17:32:48 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8D2E1065675; Sat, 30 Jul 2011 17:32:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id ED33E8FC08; Sat, 30 Jul 2011 17:32:47 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p6UHWen2064517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Jul 2011 20:32:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p6UHWewZ028869; Sat, 30 Jul 2011 20:32:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p6UHWdfe028868; Sat, 30 Jul 2011 20:32:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 30 Jul 2011 20:32:39 +0300 From: Kostik Belousov To: Robert Millan Message-ID: <20110730173239.GA17489@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwb68Uo94/+7gMfP" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, Ed Maste Subject: Re: kern/159281: [PATCH] Linux-like /proc/swaps for linprocfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 17:32:48 -0000 --rwb68Uo94/+7gMfP Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 30, 2011 at 01:06:48AM +0200, Robert Millan wrote: > Hi Kostik, >=20 > 2011/7/29 Kostik Belousov : > > The patch is too hackish, IMHO. > > I would prefer to have an exported kernel function that fills xswdev > > by index, used both by vm_swap_info and linprocfs. > > > > For the device name, you would use sw_vp->v_rdev->si_name, see, for > > instance, the following fragment in the swapoff_all(): > > =9A =9A =9A =9A =9A =9A =9A =9Aif (vn_isdisk(sp->sw_vp, NULL)) > > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Adevname =3D sp->sw_vp->v= _rdev->si_name; > > =9A =9A =9A =9A =9A =9A =9A =9Aelse > > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Adevname =3D "[file]"; > > This could be another function that returns swap information by index. >=20 > Here's a patch with the changes you requested. >=20 There are several issues in the patch that I see, not counting minor stylistic bugs. First, the sw_dev_mtx should be kept until all the data is read from the xs. The locking there is somewhat vague, the original code was probably correct because sysctl handler is not marked mpsafe, and all functions changing the swtailq hold Giant. Second, my proposal contains a flaw. Namely, if some swap device was removed between calls to swap_info and swap_devname calls, we get mangled list. The third problem, which is not fixed, and which I do not want to handle, is that the swap devices list can be changed between calls to swap_devname(= ), changing device indexes and thus making the output mangled. Should the swap device name be separated from 'unknown' word by space or by tab ? I updated your patch, hopefully fixing the issues. Do you have comments or objections ? diff --git a/sys/compat/linprocfs/linprocfs.c b/sys/compat/linprocfs/linpro= cfs.c index 692c5a3..0733913 100644 --- a/sys/compat/linprocfs/linprocfs.c +++ b/sys/compat/linprocfs/linprocfs.c @@ -502,6 +502,30 @@ linprocfs_dostat(PFS_FILL_ARGS) return (0); } =20 +static int +linprocfs_doswaps(PFS_FILL_ARGS) +{ + struct xswdev xsw; + int n; + long long total, used; + char devname[SPECNAMELEN + 1]; + + sbuf_printf(sb, "Filename\t\t\t\tType\t\tSize\tUsed\tPriority\n"); + + for (n =3D 0; ; n++) { + if (swap_dev_info(n, &xsw, devname, sizeof(devname)) !=3D 0) + break; + + total =3D (long long)xsw.xsw_nblks * PAGE_SIZE / 1024; + used =3D (long long)xsw.xsw_used * PAGE_SIZE / 1024; + + sbuf_printf(sb, "/dev/%-34s unknown\t\t%lld\t%lld\t-1\n", + devname, total, used); + } + + return (0); +} + /* * Filler function for proc/uptime */ @@ -1490,6 +1514,8 @@ linprocfs_init(PFS_INIT_ARGS) NULL, NULL, NULL, 0); pfs_create_file(root, "stat", &linprocfs_dostat, NULL, NULL, NULL, PFS_RD); + pfs_create_file(root, "swaps", &linprocfs_doswaps, + NULL, NULL, NULL, PFS_RD); pfs_create_file(root, "uptime", &linprocfs_douptime, NULL, NULL, NULL, PFS_RD); pfs_create_file(root, "version", &linprocfs_doversion, diff --git a/sys/vm/swap_pager.c b/sys/vm/swap_pager.c index f421e4f..5929871 100644 --- a/sys/vm/swap_pager.c +++ b/sys/vm/swap_pager.c @@ -2365,35 +2365,58 @@ swap_pager_status(int *total, int *used) mtx_unlock(&sw_dev_mtx); } =20 -static int -sysctl_vm_swap_info(SYSCTL_HANDLER_ARGS) +int +swap_dev_info(int name, struct xswdev *xs, char *devname, size_t len) { - int *name =3D (int *)arg1; - int error, n; - struct xswdev xs; struct swdevt *sp; - - if (arg2 !=3D 1) /* name length */ - return (EINVAL); + char *tmp_devname; + int error, n; =20 n =3D 0; + error =3D ENOENT; mtx_lock(&sw_dev_mtx); TAILQ_FOREACH(sp, &swtailq, sw_list) { - if (n =3D=3D *name) { - mtx_unlock(&sw_dev_mtx); - xs.xsw_version =3D XSWDEV_VERSION; - xs.xsw_dev =3D sp->sw_dev; - xs.xsw_flags =3D sp->sw_flags; - xs.xsw_nblks =3D sp->sw_nblks; - xs.xsw_used =3D sp->sw_used; - - error =3D SYSCTL_OUT(req, &xs, sizeof(xs)); - return (error); + if (n !=3D name) { + n++; + continue; } - n++; + + xs->xsw_version =3D XSWDEV_VERSION; + xs->xsw_dev =3D sp->sw_dev; + xs->xsw_flags =3D sp->sw_flags; + xs->xsw_nblks =3D sp->sw_nblks; + xs->xsw_used =3D sp->sw_used; + if (devname !=3D NULL) { + if (vn_isdisk(sp->sw_vp, NULL)) { + tmp_devname =3D + sp->sw_vp->v_rdev->si_name; + } else + tmp_devname =3D "[file]"; + strncpy(devname, tmp_devname, len); + } + error =3D 0; + break; } mtx_unlock(&sw_dev_mtx); - return (ENOENT); + return (error); +} + +static int +sysctl_vm_swap_info(SYSCTL_HANDLER_ARGS) +{ + int *name =3D (int *)arg1; + int error; + struct xswdev xs; + + if (arg2 !=3D 1) /* name length */ + return (EINVAL); + + error =3D swap_dev_info(*name, &xs, NULL, 0); + if (error !=3D 0) + return (error); + + error =3D SYSCTL_OUT(req, &xs, sizeof(xs)); + return (error); } =20 SYSCTL_INT(_vm, OID_AUTO, nswapdev, CTLFLAG_RD, &nswapdev, 0, diff --git a/sys/vm/swap_pager.h b/sys/vm/swap_pager.h index c3366e8..d7b0f5e 100644 --- a/sys/vm/swap_pager.h +++ b/sys/vm/swap_pager.h @@ -76,6 +76,8 @@ extern int swap_pager_full; extern int swap_pager_avail; =20 struct swdevt; +struct xswdev; +int swap_dev_info(int name, struct xswdev *xs, char *devname, size_t len); void swap_pager_copy(vm_object_t, vm_object_t, vm_pindex_t, int); void swap_pager_freespace(vm_object_t, vm_pindex_t, vm_size_t); void swap_pager_swap_init(void); --rwb68Uo94/+7gMfP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk40QDcACgkQC3+MBN1Mb4iLaQCfVGDRkZXlUAA4Jq1qbfbpnYtR cmgAoNiAxP0/hLGsVJomShY6io1TEDYS =HiWn -----END PGP SIGNATURE----- --rwb68Uo94/+7gMfP--