From owner-freebsd-arch@FreeBSD.ORG Mon Aug 18 09:34:42 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3886C1065679; Mon, 18 Aug 2008 09:34:42 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 08A018FC26; Mon, 18 Aug 2008 09:34:42 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 2B4A91CDFB; Mon, 18 Aug 2008 11:34:41 +0200 (CEST) Date: Mon, 18 Aug 2008 11:34:41 +0200 From: Ed Schouten To: FreeBSD Current , FreeBSD Arch Message-ID: <20080818093441.GO99951@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J40Vvg1kvFCV4Ndf" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: HEADS UP: MPSAFE TTY integration on August 20 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 09:34:42 -0000 --J40Vvg1kvFCV4Ndf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, As I informed everyone a couple of weeks ago: I'm going to integrate the MPSAFE TTY layer on August 20. The original plan was to do this on August 10: * Ed Schouten wrote: > August 10 2008: > Commit the new MPSAFE TTY driver in several commits (first > commit the layer itself, then commit changes to drivers one by > one). We decided to delay the integration 10 more days, to give interested people some more time to work on remaining drivers. I am going to integrate the following patchset: http://people.FreeBSD.org/~ed/mpsafetty/ The patchset also contains some changes to the Xen console driver and si(4), but I'm not going to commit those, because they are not yet fully ported/tested. Yours, --=20 Ed Schouten WWW: http://80386.nl/ --J40Vvg1kvFCV4Ndf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkipQjEACgkQ52SDGA2eCwXp2wCeM0HW1xdcU/Mby5Xqtd6B2r+1 zTIAni5WevOv/XpXKCSZyKuucInkyO8b =j+Cz -----END PGP SIGNATURE----- --J40Vvg1kvFCV4Ndf-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 18 10:05:30 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D917E1065679 for ; Mon, 18 Aug 2008 10:05:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id A4A158FC19 for ; Mon, 18 Aug 2008 10:05:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 99A1846B06; Mon, 18 Aug 2008 05:47:12 -0400 (EDT) Date: Mon, 18 Aug 2008 10:47:12 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kostik Belousov In-Reply-To: <20080816121049.GU1803@deviant.kiev.zoral.com.ua> Message-ID: References: <20080816111824.GL99951@hoeg.nl> <20080816121049.GU1803@deviant.kiev.zoral.com.ua> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Schouten , Jille Timmermans , FreeBSD Arch Subject: Re: [Reviews requested] kern/121073: chroot for non-root users X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 10:05:30 -0000 On Sat, 16 Aug 2008, Kostik Belousov wrote: >> It would be great to get many reviews on this before we'd land it in the >> source tree. I've attached the patch to this email as well. Thanks! > > I think that the patch gives instant root. FreeBSD provides a rfork(2) > system call. This call allows the processes to share filedesc table, that, > among other information, contains the root of the filesystem namespace for > the process. > > So, the scenario is to rfork() a process without RFFDG flag, and then for > one of the resulting processes to perform a chroot. Now, second one has > chrooted root, but no P_NOSUGID flag set. There is a long and sordid history of vulnerability associated with the use of the chroot(2) system call in well-meaning attempts to allow users to employ it in order to improve security. Most of the lessons center on the high level of trust placed in the file system name space by UNIX applications *and* the kernel, and the unexpected implications of allowing that namespace to be manipulated by untrusted processes. I think I would generally be very conservative about making any change to behavior here, even optional change, simply because it will lead to future security advisories. More generally, I'm a bit worried by the increasing number of minor security policy variations controlled by sysctls and kernel options -- often they serve the function of optionally exposing kernel behavior not reviewed or hardened against untrusted users to use. These minor variations risk coming into conflict with application and kernel assumptions about the security model, so I think we should be very careful about adding too many. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Mon Aug 18 11:06:47 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BFB0106568A for ; Mon, 18 Aug 2008 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5A9AB8FC2C for ; Mon, 18 Aug 2008 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7IB6lHp079750 for ; Mon, 18 Aug 2008 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7IB6kxU079746 for freebsd-arch@FreeBSD.org; Mon, 18 Aug 2008 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Aug 2008 11:06:46 GMT Message-Id: <200808181106.m7IB6kxU079746@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 11:06:47 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Tue Aug 19 05:08:01 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 534B11065672 for ; Tue, 19 Aug 2008 05:08:01 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwqsrv02p.mx.bigpond.com (nschwqsrv02p.mx.bigpond.com [61.9.189.234]) by mx1.freebsd.org (Postfix) with ESMTP id E86568FC15 for ; Tue, 19 Aug 2008 05:08:00 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwotgx02p.mx.bigpond.com ([124.188.162.219]) by nschwmtas04p.mx.bigpond.com with ESMTP id <20080819025020.WWQM19703.nschwmtas04p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com> for ; Tue, 19 Aug 2008 02:50:20 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20080819025019.UJAS11844.nschwotgx02p.mx.bigpond.com@areilly.bpa.nu> for ; Tue, 19 Aug 2008 02:50:19 +0000 Received: (qmail 31503 invoked by uid 501); 19 Aug 2008 02:50:19 -0000 Date: Tue, 19 Aug 2008 12:50:19 +1000 From: Andrew Reilly To: freebsd-arch@freebsd.org, freebsd-multimedia@freebsd.org Message-ID: <20080819025019.GA27997@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150202.48AA34EC.000F,ss=1,fgs=0 Cc: Subject: SCHED_ULE problem: slow single processor, realtime prio vs network stack X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2008 05:08:01 -0000 Hi all, Let me tell you a story, and perhaps someone can suggest a different course of action than the one that I've taken, which has been to switch back to SCHED_4BSD: I've got an old P3-500 machine that I use for audio processing experiments and also music playback. It's got an M-Audio Delta1010 card in it, which (in its most native mode) has ten channels in and twelve out, all 24/32-bit. I use the 4front-tech driver, because the native one doesn't do multi-channel (yet). I recently "upgraded" the OS on that box from 6-stable to 7-stable, since I've had such good experiences with 7 (and SCHED_ULE) on my desktop and server systems (and 4front now supports 7). Unfortunatly, for this application, this was a seriously retrograde step, at first: no matter how I fiddled the blocking factors and IO sizes, I couldn't stop the system from glitching (audio buffer underruns). It seemed that any (unrelated) network activity would take priority over the audio, even though I had the audio task set to rtprio=10. Loging in to the box with ssh was a guaranteed sound glitcher. It probably doesn't help that that box has a dagy old 100baseTX RealTek ethernet card, that I have to use with -r=1024 on my NFS mounts to avoid fragmentation problems. I'm pleased to report that switching back to SCHED_4BSD has retrieved the situation, and my audio task is now rock solid and stable again. I've been thinking about writing up a PR about the issue, but I haven't figured out how to generate a minimally failing example that anyone else would be able to verify. Maybe I'll just go ahead and post this message, to see if anyone has any suggestions. Given the emphasis of _ULE on multi-processor scalability and total system throughput (at which it seems to rock), I suspect that the answer may well be: "use a more suitable operating system". I hope not. I would expect that the same mechanisms that enable good multi-processor scalability would also have good real-time characteristics: the same asynchronous events and preemption are at work in both cases. So, here's the question: can I do something to my code, or the way I set its priority, to get something equivalent to the reliable real-time scheduling that I can get in _4BSD under _ULE? Cheers, Andrew From owner-freebsd-arch@FreeBSD.ORG Tue Aug 19 08:29:18 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57863106568A for ; Tue, 19 Aug 2008 08:29:18 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by mx1.freebsd.org (Postfix) with ESMTP id 369238FC13 for ; Tue, 19 Aug 2008 08:29:18 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by rv-out-0506.google.com with SMTP id b25so3892267rvf.43 for ; Tue, 19 Aug 2008 01:29:17 -0700 (PDT) Received: by 10.141.85.13 with SMTP id n13mr3892378rvl.250.1219132877990; Tue, 19 Aug 2008 01:01:17 -0700 (PDT) Received: from ?10.0.1.199? ( [24.94.72.120]) by mx.google.com with ESMTPS id l31sm8804090rvb.2.2008.08.19.01.01.15 (version=SSLv3 cipher=RC4-MD5); Tue, 19 Aug 2008 01:01:16 -0700 (PDT) Date: Mon, 18 Aug 2008 22:00:12 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Andrew Reilly In-Reply-To: <20080819025019.GA27997@duncan.reilly.home> Message-ID: <20080818215813.H952@desktop> References: <20080819025019.GA27997@duncan.reilly.home> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-multimedia@freebsd.org, freebsd-arch@freebsd.org Subject: Re: SCHED_ULE problem: slow single processor, realtime prio vs network stack X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2008 08:29:18 -0000 On Tue, 19 Aug 2008, Andrew Reilly wrote: > Hi all, > > Let me tell you a story, and perhaps someone can suggest a > different course of action than the one that I've taken, which > has been to switch back to SCHED_4BSD: > > I've got an old P3-500 machine that I use for audio processing > experiments and also music playback. It's got an M-Audio > Delta1010 card in it, which (in its most native mode) has > ten channels in and twelve out, all 24/32-bit. I use the > 4front-tech driver, because the native one doesn't do > multi-channel (yet). I recently "upgraded" the OS on that box > from 6-stable to 7-stable, since I've had such good experiences > with 7 (and SCHED_ULE) on my desktop and server systems (and > 4front now supports 7). Unfortunatly, for this application, > this was a seriously retrograde step, at first: no matter how > I fiddled the blocking factors and IO sizes, I couldn't stop > the system from glitching (audio buffer underruns). It seemed > that any (unrelated) network activity would take priority over > the audio, even though I had the audio task set to rtprio=10. > Loging in to the box with ssh was a guaranteed sound glitcher. Can you tell me what % cpu the audio application uses while running? Have you tried nice -20 instead of rtprio? Thanks, Jeff > > It probably doesn't help that that box has a dagy old 100baseTX > RealTek ethernet card, that I have to use with -r=1024 on my NFS > mounts to avoid fragmentation problems. > > I'm pleased to report that switching back to SCHED_4BSD has > retrieved the situation, and my audio task is now rock solid and > stable again. > > I've been thinking about writing up a PR about the issue, but I > haven't figured out how to generate a minimally failing example > that anyone else would be able to verify. Maybe I'll just > go ahead and post this message, to see if anyone has any > suggestions. > > Given the emphasis of _ULE on multi-processor scalability and > total system throughput (at which it seems to rock), I suspect > that the answer may well be: "use a more suitable operating > system". I hope not. I would expect that the same mechanisms > that enable good multi-processor scalability would also have > good real-time characteristics: the same asynchronous events and > preemption are at work in both cases. > > So, here's the question: can I do something to my code, or the > way I set its priority, to get something equivalent to the > reliable real-time scheduling that I can get in _4BSD under > _ULE? > > Cheers, > > Andrew > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Tue Aug 19 13:40:17 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFEFD106566C for ; Tue, 19 Aug 2008 13:40:17 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntmtas02p.mx.bigpond.com (nskntmtas02p.mx.bigpond.com [61.9.168.140]) by mx1.freebsd.org (Postfix) with ESMTP id 630B88FC36 for ; Tue, 19 Aug 2008 13:40:16 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntotgx03p.mx.bigpond.com ([124.188.162.219]) by nskntmtas02p.mx.bigpond.com with ESMTP id <20080819134015.LJCF26374.nskntmtas02p.mx.bigpond.com@nskntotgx03p.mx.bigpond.com> for ; Tue, 19 Aug 2008 13:40:15 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nskntotgx03p.mx.bigpond.com with ESMTP id <20080819134013.BVON29987.nskntotgx03p.mx.bigpond.com@areilly.bpa.nu> for ; Tue, 19 Aug 2008 13:40:13 +0000 Received: (qmail 86251 invoked by uid 501); 19 Aug 2008 13:40:05 -0000 Date: Tue, 19 Aug 2008 23:40:05 +1000 From: Andrew Reilly To: Jeff Roberson Message-ID: <20080819134005.GA85664@duncan.reilly.home> References: <20080819025019.GA27997@duncan.reilly.home> <20080818215813.H952@desktop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080818215813.H952@desktop> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150205.48AACD3D.0061,ss=1,fgs=0 Cc: freebsd-multimedia@freebsd.org, freebsd-arch@freebsd.org Subject: Re: SCHED_ULE problem: slow single processor, realtime prio vs network stack X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2008 13:40:17 -0000 On Mon, Aug 18, 2008 at 10:00:12PM -1000, Jeff Roberson wrote: > Can you tell me what % cpu the audio application uses while running? Have > you tried nice -20 instead of rtprio? It's currently using about 10%, maybe a bit more. I expect it to get heavier as I add more to it. I have hopes of it continuing to work even at 60 to 80% of CPU. I haven't tried nice -20 because I don't want the priority to drift or change, which is something that I thought the normal levels did. I'll give it a go though, and report back. Cheers, Andrew From owner-freebsd-arch@FreeBSD.ORG Tue Aug 19 16:38:34 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30613106566B for ; Tue, 19 Aug 2008 16:38:34 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from parsely.rain.com (parsely.rain.com [199.26.172.196]) by mx1.freebsd.org (Postfix) with ESMTP id E906A8FC1C for ; Tue, 19 Aug 2008 16:38:31 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from sopwith.solgatos.com (uucp@localhost) by parsely.rain.com (8.11.4/8.11.4) with UUCP id m7JG0lg54193; Tue, 19 Aug 2008 09:00:47 -0700 (PDT) (envelope-from freebsd@sopwith.solgatos.com) Received: from localhost by sopwith.solgatos.com (8.8.8/6.24) id PAA05091; Tue, 19 Aug 2008 15:57:50 GMT Message-Id: <200808191557.PAA05091@sopwith.solgatos.com> To: Andrew Reilly In-reply-to: Your message of "Tue, 19 Aug 2008 12:50:19 +1000." <20080819025019.GA27997@duncan.reilly.home> Date: Tue, 19 Aug 2008 08:57:50 +0100 From: Dieter Cc: freebsd-multimedia@freebsd.org, freebsd-arch@freebsd.org Subject: Re: SCHED_ULE problem: slow single processor, realtime prio vs network stack X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2008 16:38:34 -0000 > I'm pleased to report that switching back to SCHED_4BSD has > retrieved the situation, and my audio task is now rock solid and > stable again. This is very interesting. Rtprio does not work, but switching schedulers does. Is there something that the scheduler affects that rtprio doesn't? > Given the emphasis of _ULE on multi-processor scalability and > total system throughput (at which it seems to rock), I suspect > that the answer may well be: "use a more suitable operating > system". I hope not. If you've only tried changing the priority and buffer sizes of the audio process, you could try nicing the network down, and changing the network's buffer sizes up/down. But I wouldn't count on that helping much, if any. I suspect that the answer, at least in your case, is use _4BSD. The goal of total system throughput, and the goal of real time are somewhat at odds. For example giving processes longer time slices would reduce the number of context switches and should increase total system throughput, but would hurt real time response. I've been battling similar real time problems. I'm already using _4BSD, so it doesn't solve everything. From what I can figure out, some device drivers simply hog the CPU for long periods of time. Hopefully that can be fixed. And the schedulers are concerned with allocating CPU, but ignore allocating I/O resources fairly. Nice/rtprio has very little affect on I/O if the process doesn't use much CPU. We really need a way to nice I/O up/down. From owner-freebsd-arch@FreeBSD.ORG Tue Aug 19 16:41:49 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D522D1065677 for ; Tue, 19 Aug 2008 16:41:49 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id BEA2D8FC32 for ; Tue, 19 Aug 2008 16:41:44 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.2/8.14.2) with ESMTP id m7JGBoig018738; Tue, 19 Aug 2008 09:11:50 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.2/Submit) id m7JGBoSN018737; Tue, 19 Aug 2008 09:11:50 -0700 (PDT) (envelope-from obrien) Date: Tue, 19 Aug 2008 09:11:50 -0700 From: "David O'Brien" To: Ed Schouten Message-ID: <20080819161150.GA18621@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Ed Schouten , FreeBSD Arch References: <20080818093441.GO99951@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080818093441.GO99951@hoeg.nl> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD Arch Subject: Re: HEADS UP: MPSAFE TTY integration on August 20 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2008 16:41:49 -0000 On Mon, Aug 18, 2008 at 11:34:41AM +0200, Ed Schouten wrote: > As I informed everyone a couple of weeks ago: I'm going to integrate the > MPSAFE TTY layer on August 20. The original plan was to do this on > August 10: > > * Ed Schouten wrote: > > August 10 2008: > > Commit the new MPSAFE TTY driver in several commits (first > > commit the layer itself, then commit changes to drivers one by > > one). > > We decided to delay the integration 10 more days, to give interested > people some more time to work on remaining drivers. Ed, Before the first checkin, please lay down a tag. Given there are some drivers issues at the point of commit, folks might need to hang at the last point before MPSAFE-TTY to wait for late coming drivers. Now that SVN tags are ultra cheep, we should come up with a convention. Say svn+ssh://svn.freebsd.org/base/tag/_[(PRE|POST)-] $ svn copy --parents svn+ssh://svn.freebsd.org/base/head svn+ssh://svn.freebsd.org/base/tag/HEAD_PRE_MPSAFE_TTY thanks, -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 09:16:53 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 127B410656D9; Wed, 20 Aug 2008 09:16:53 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 8B84D8FC1A; Wed, 20 Aug 2008 09:16:52 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id DFBB21CCC6; Wed, 20 Aug 2008 11:16:51 +0200 (CEST) Date: Wed, 20 Aug 2008 11:16:51 +0200 From: Ed Schouten To: FreeBSD Current , FreeBSD Arch Message-ID: <20080820091651.GV99951@hoeg.nl> References: <20080818093441.GO99951@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DdPkZxlGw/CxoNTG" Content-Disposition: inline In-Reply-To: <20080818093441.GO99951@hoeg.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: HEADS DOWN: MPSAFE TTY layer integrated X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2008 09:16:53 -0000 --DdPkZxlGw/CxoNTG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, I'm pleased to announce that the MPSAFE TTY layer has just been integrated to our source tree. Below is the commit message: ----- Forwarded message from Ed Schouten ----- > Date: Wed, 20 Aug 2008 08:31:58 +0000 (UTC) > From: Ed Schouten > To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org > Subject: cvs commit: src ObsoleteFiles.inc UPDATING src/bin/sh miscbltin.c > src/etc login.conf src/etc/defaults devfs.rules > src/lib/libc/stdlib Makefile.inc Symbol.map grantpt.3 ptsname.3 > ptsname.c src/lib/libc/sys Makefile.inc Symbol.map getrlimit.2 ... >=20 > ed 2008-08-20 08:31:58 UTC >=20 > FreeBSD src repository >=20 > >=20 > Log: > SVN rev 181905 on 2008-08-20 08:31:58Z by ed > =20 > Integrate the new MPSAFE TTY layer to the FreeBSD operating system. > =20 > The last half year I've been working on a replacement TTY layer for the > FreeBSD kernel. The new TTY layer was designed to improve the following: > =20 > - Improved driver model: > =20 > The old TTY layer has a driver model that is not abstract enough to > make it friendly to use. A good example is the output path, where the > device drivers directly access the output buffers. This means that an > in-kernel PPP implementation must always convert network buffers into > TTY buffers. > =20 > If a PPP implementation would be built on top of the new TTY layer > (still needs a hooks layer, though), it would allow the PPP > implementation to directly hand the data to the TTY driver. > =20 > - Improved hotplugging: > =20 > With the old TTY layer, it isn't entirely safe to destroy TTY's from > the system. This implementation has a two-step destructing design, > where the driver first abandons the TTY. After all threads have left > the TTY, the TTY layer calls a routine in the driver, which can be > used to free resources (unit numbers, etc). > =20 > The pts(4) driver also implements this feature, which means > posix_openpt() will now return PTY's that are created on the fly. > =20 > - Improved performance: > =20 > One of the major improvements is the per-TTY mutex, which is expected > to improve scalability when compared to the old Giant locking. > Another change is the unbuffered copying to userspace, which is both > used on TTY device nodes and PTY masters. > =20 > Upgrading should be quite straightforward. Unlike previous versions, > existing kernel configuration files do not need to be changed, except > when they reference device drivers that are listed in UPDATING. > =20 > Obtained from: //depot/projects/mpsafetty/... > Approved by: philip (ex-mentor) > Discussed: on the lists, at BSDCan, at the DevSummit > Sponsored by: Snow B.V., the Netherlands > dcons(4) fixed by: kan > =20 > >=20 ----- End forwarded message ----- Some people asked me if I could tag the tree before importing the MPSAFE TTY bits, to make sure people can easily stick to older source revisions when they want to do comparisons with the old TTY implementation, which may be useful when porting drivers, isolating bugs, etc. After discussing with people on IRC, I've decided not to create the tag. If you want to switch to pre-MPSAFE TTY, please check out revision r181904. Well, that's all I've got to say for now, I guess. Be sure to update your systems and give my code some extensive testing. Thanks! --=20 Ed Schouten WWW: http://80386.nl/ --DdPkZxlGw/CxoNTG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkir4QMACgkQ52SDGA2eCwU/qQCfenSchz3I/K6t1/L9K0KiyZvs m/8An0mEL8Miv/mjov7TUJo+0pKMoVuo =CdIc -----END PGP SIGNATURE----- --DdPkZxlGw/CxoNTG-- From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 22:10:39 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 047B2106567C; Wed, 20 Aug 2008 22:10:39 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7685E8FC20; Wed, 20 Aug 2008 22:10:38 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl12-130.kln.forthnet.gr [77.49.139.130]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id m7KM9uEq030681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Aug 2008 01:10:02 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m7KM9ttb005482; Thu, 21 Aug 2008 01:09:55 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m7KM9s1N005361; Thu, 21 Aug 2008 01:09:54 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Ed Schouten In-Reply-To: <20080820091651.GV99951@hoeg.nl> (Ed Schouten's message of "Wed, 20 Aug 2008 11:16:51 +0200") Date: Wed, 20 Aug 2008 21:51:51 +0300 Message-ID: <87pro3pliw.fsf@kobe.laptop> References: <20080818093441.GO99951@hoeg.nl> <20080820091651.GV99951@hoeg.nl> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m7KM9uEq030681 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.809, required 5, ALL_TRUSTED -1.80, AWL 0.55, BAYES_00 -2.60, DATE_IN_PAST_03_06 0.04) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: FreeBSD Arch , FreeBSD Current Subject: Re: HEADS DOWN: MPSAFE TTY layer integrated X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2008 22:10:39 -0000 On Wed, 20 Aug 2008 11:16:51 +0200, Ed Schouten wrote: > Hello everyone, > > I'm pleased to announce that the MPSAFE TTY layer has just been > integrated to our source tree. Below is the commit message: Thank you! :-) >> Log: >> SVN rev 181905 on 2008-08-20 08:31:58Z by ed >> >> Integrate the new MPSAFE TTY layer to the FreeBSD operating system. >> [...] > > ----- End forwarded message ----- > > Some people asked me if I could tag the tree before importing the > MPSAFE TTY bits, to make sure people can easily stick to older source > revisions when they want to do comparisons with the old TTY > implementation, which may be useful when porting drivers, isolating > bugs, etc. > > After discussing with people on IRC, I've decided not to create the > tag. If you want to switch to pre-MPSAFE TTY, please check out > revision r181904. Fair enough. If the need arises, it's easy to lay down a tag after the fact, by copying: svn copy svn+ssh://svn.freebsd.org/base/head@181904 \ svn+ssh://svn.freebsd.org/base/tags/pre-mpsafetty But since the initial commit was pushed to svn in one changeset, the need for that is a bit small I guess. Doing it later should also be ok too. From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 23:41:54 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C9CE1065689; Wed, 20 Aug 2008 23:41:54 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (ice.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 651D38FC1D; Wed, 20 Aug 2008 23:41:54 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id A167186CB1; Wed, 20 Aug 2008 18:41:53 -0500 (CDT) Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (ice.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 10079-04; Wed, 20 Aug 2008 18:41:51 -0500 (CDT) Received: from wanderer.tachypleus.net (adsl-75-37-4-190.dsl.pltn13.sbcglobal.net [75.37.4.190]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 88BE586B19; Wed, 20 Aug 2008 18:41:50 -0500 (CDT) Message-ID: <48ACABBF.3070705@freebsd.org> Date: Wed, 20 Aug 2008 16:41:51 -0700 From: Nathan Whitehorn User-Agent: Thunderbird 2.0.0.16 (X11/20080804) MIME-Version: 1.0 To: John Baldwin References: <48981C19.8060009@freebsd.org> <200808051024.27043.jhb@freebsd.org> <48A2E62A.9060604@freebsd.org> <200808131214.43326.jhb@freebsd.org> In-Reply-To: <200808131214.43326.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at ice.icecube.wisc.edu Cc: freebsd-arch@freebsd.org Subject: Re: UMA MD Small Allocator Runtime Switching X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2008 23:41:54 -0000 John Baldwin wrote: > [snip] >> I thought about it, but we can only use 4K pages on the G5 so this would >> put a large amount of pressure on the page table. IBM removed the block >> translation mechanism from the G5 and the CPU's superpage support is not >> available in the 32-bit compatibility mode under which we currently run. >> > > Hmm, I didn't know you weren't running in full 64-bit mode. Is that a > property of the G5 CPU that it only supports the 32-bit compat mode with > 64-bit extensions? > (see other email about the properties of the G5) I think the following one-line patch provides a reasonable solution to this problem. Is there any reason this is a bad idea? -Nathan Index: uma_core.c =================================================================== --- uma_core.c (revision 181929) +++ uma_core.c (working copy) @@ -1667,7 +1667,7 @@ bucket_init(); -#ifdef UMA_MD_SMALL_ALLOC +#if defined(UMA_MD_SMALL_ALLOC) && !defined(UMA_MD_SMALL_ALLOC_NEEDS_VM) booted = 1; #endif From owner-freebsd-arch@FreeBSD.ORG Thu Aug 21 07:47:56 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1E031065678 for ; Thu, 21 Aug 2008 07:47:56 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.235]) by mx1.freebsd.org (Postfix) with ESMTP id B0DC78FC1A for ; Thu, 21 Aug 2008 07:47:56 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by qb-out-0506.google.com with SMTP id e34so1359499qbe.35 for ; Thu, 21 Aug 2008 00:47:56 -0700 (PDT) Received: by 10.114.182.15 with SMTP id e15mr1100382waf.186.1219304875440; Thu, 21 Aug 2008 00:47:55 -0700 (PDT) Received: from ?10.0.1.199? ( [24.94.72.120]) by mx.google.com with ESMTPS id j34sm375106waf.48.2008.08.21.00.47.52 (version=SSLv3 cipher=RC4-MD5); Thu, 21 Aug 2008 00:47:54 -0700 (PDT) Date: Wed, 20 Aug 2008 21:47:01 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Andrew Reilly In-Reply-To: <20080819134005.GA85664@duncan.reilly.home> Message-ID: <20080820214627.C30593@desktop> References: <20080819025019.GA27997@duncan.reilly.home> <20080818215813.H952@desktop> <20080819134005.GA85664@duncan.reilly.home> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-multimedia@freebsd.org, freebsd-arch@freebsd.org Subject: Re: SCHED_ULE problem: slow single processor, realtime prio vs network stack X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2008 07:47:57 -0000 On Tue, 19 Aug 2008, Andrew Reilly wrote: > On Mon, Aug 18, 2008 at 10:00:12PM -1000, Jeff Roberson wrote: >> Can you tell me what % cpu the audio application uses while running? Have >> you tried nice -20 instead of rtprio? > > It's currently using about 10%, maybe a bit more. I expect > it to get heavier as I add more to it. I have hopes of it > continuing to work even at 60 to 80% of CPU. > > I haven't tried nice -20 because I don't want the priority to > drift or change, which is something that I thought the normal > levels did. I'll give it a go though, and report back. With such a low cpu utilization I wouldn't expect it's the scheduling algorithm. It may be a difference in preemption settings. Is preemption enabled in both kernels? Jeff > > Cheers, > > Andrew > From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 00:32:30 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A65251065674 for ; Fri, 22 Aug 2008 00:32:30 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 599568FC16 for ; Fri, 22 Aug 2008 00:32:30 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KWJzT-0006AA-Bj for freebsd-arch@freebsd.org; Thu, 21 Aug 2008 23:54:56 +0000 Received: from 78-1-109-78.adsl.net.t-com.hr ([78.1.109.78]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Aug 2008 23:54:55 +0000 Received: from ivoras by 78-1-109-78.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Aug 2008 23:54:55 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Fri, 22 Aug 2008 01:54:29 +0200 Lines: 39 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig606CF2509034CF55F2FFDB2E" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-109-78.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) X-Enigmail-Version: 0.95.6 Sender: news Subject: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 00:32:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig606CF2509034CF55F2FFDB2E Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable I was reading about new things in NetBSD, and one thing caught my=20 attention: per-user /tmp. See=20 http://www.feyrer.de/NetBSD/bx/blosxom.cgi/nb_20080714_0251.html for=20 example. Google says that a discussion about magic symlinks happens every now and = then in FreeBSD but nothing really gets done. I found this=20 implementation which looks like it's for 7.0: http://butcher.heavennet.ru/patches/kernel/magiclinks/ As far as I understand the VFS (which isn't much...) this looks like an=20 trivial patch, and it's compatible with NetBSD. Since I'm interested in=20 this (specifically for the per-user /tmp and maybe similar gadgetry),=20 I'd like to nurse this patch into the tree, if there are no objections=20 (of course, I'll bug anyone I can find who knows VFS to review it :) ). --------------enig606CF2509034CF55F2FFDB2E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIrgA8ldnAQVacBcgRAnxjAKD68KZw200LgjRsXrc0YEdNNx3tCACg3auP TJVXvNQGWGe3HG9Tl8/jmTo= =Kv6b -----END PGP SIGNATURE----- --------------enig606CF2509034CF55F2FFDB2E-- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 09:21:59 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9890B1065688; Fri, 22 Aug 2008 09:21:59 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 5C7D68FC16; Fri, 22 Aug 2008 09:21:59 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 055937308B; Fri, 22 Aug 2008 11:04:49 +0200 (CEST) Date: Fri, 22 Aug 2008 11:04:49 +0200 From: Luigi Rizzo To: Ivan Voras Message-ID: <20080822090448.GB57441@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 09:21:59 -0000 On Fri, Aug 22, 2008 at 01:54:29AM +0200, Ivan Voras wrote: > I was reading about new things in NetBSD, and one thing caught my > attention: per-user /tmp. See > http://www.feyrer.de/NetBSD/bx/blosxom.cgi/nb_20080714_0251.html for > example. > > Google says that a discussion about magic symlinks happens every now and > then in FreeBSD but nothing really gets done. I found this > implementation which looks like it's for 7.0: > > http://butcher.heavennet.ru/patches/kernel/magiclinks/ interestingly simple. Question - is the process' ENV easily available in this part of the kernel, so one could in principle use environment variables as replacement strings ? Some comments on the code in the above patch: + readability it might be improved a bit: e.g. I don't see why uma_{zalloc|zfree} are hidden behind macros, nor why symlynk_magic() isn't simply called as if (vfs_magiclinks) symlink_magic(td, cp, &linklen); as it cannot fail as implemented; also, the whole MATCH/SUBSTITUTE macros are not particularly readable -- i understand one needs macros to implement sizeof("somestring") correctly, but apart from a wrapper I believe the core of these two blocks should be implemented by functions (possibly inline) with MATCH() returning the match length so one doesn't need to replicate the string parameter in SUBSTITUTE(); + correctness -- 1. termchar is not reset to '/' if a match is not found 2. what is the intended behaviour when the replacement string overflows the buffer ? + efficiency of symlink_magic() might be improved too: e.g. the function could do a quick check for the presence of @ and return without allocation/deallocation if not found; getcredhostname() (and similar routines) could be called so that they write directly to tmp, without the need for allocating an in-stack buffer cheers luigi From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 09:59:17 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B2BB1065676 for ; Fri, 22 Aug 2008 09:59:17 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 107988FC3A for ; Fri, 22 Aug 2008 09:59:17 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KWTQJ-0004Ao-PJ for freebsd-arch@freebsd.org; Fri, 22 Aug 2008 09:59:15 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Aug 2008 09:59:15 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Aug 2008 09:59:15 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Fri, 22 Aug 2008 11:59:07 +0200 Lines: 68 Message-ID: References: <20080822090448.GB57441@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.16 (X11/20080724) In-Reply-To: <20080822090448.GB57441@onelab2.iet.unipi.it> Sender: news Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 09:59:17 -0000 Luigi Rizzo wrote: > On Fri, Aug 22, 2008 at 01:54:29AM +0200, Ivan Voras wrote: >> I was reading about new things in NetBSD, and one thing caught my >> attention: per-user /tmp. See >> http://www.feyrer.de/NetBSD/bx/blosxom.cgi/nb_20080714_0251.html for >> example. >> >> Google says that a discussion about magic symlinks happens every now and >> then in FreeBSD but nothing really gets done. I found this >> implementation which looks like it's for 7.0: >> >> http://butcher.heavennet.ru/patches/kernel/magiclinks/ > > interestingly simple. Yes, that's a big part of the attractiveness of this patch :) > Question - is the process' ENV easily available in this part > of the kernel, so one could in principle use environment variables > as replacement strings ? > > Some comments on the code in the above patch: > > + readability it might be improved a bit: > e.g. I don't see why uma_{zalloc|zfree} are hidden behind macros, > nor why symlynk_magic() isn't simply called as > > if (vfs_magiclinks) > symlink_magic(td, cp, &linklen); > > as it cannot fail as implemented; Ok. > also, the whole MATCH/SUBSTITUTE macros are not particularly > readable -- i understand one needs macros to implement sizeof("somestring") > correctly, but apart from a wrapper I believe the core of these two > blocks should be implemented by functions (possibly inline) with > MATCH() returning the match length so one doesn't need to replicate > the string parameter in SUBSTITUTE(); Yes, I intended to remove the code macros into static inline functions, possibly with some macro glue for sizeof. > + correctness -- > 1. termchar is not reset to '/' if a match is not found > 2. what is the intended behaviour when the replacement string overflows > the buffer ? I'll check those later, when I make an updated patch. > + efficiency of symlink_magic() might be improved too: > e.g. the function could do a quick check for the presence of @ and return > without allocation/deallocation if not found; I think it's because the author wanted a single pass over the string (in case of the "extended" @{...} syntax we can't just check if cp[0] == '@'). The first few lines of the symlink_magic loop ("if (cp[i] != '@')") effectively do what strchr() does. > getcredhostname() (and similar routines) could be called so that > they write directly to tmp, without the need for > allocating an in-stack buffer I think this is for consistency in calling SUBSTITUTE. It could be broken into two variants of the code but is it worth it? I'd rather modify getcredhostname() in kern/kern_jail.c to return the length of the created string and avoid a strlen(). From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 10:09:35 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E9F91065672; Fri, 22 Aug 2008 10:09:35 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp13.yandex.ru (smtp13.yandex.ru [77.88.32.83]) by mx1.freebsd.org (Postfix) with ESMTP id 304938FC17; Fri, 22 Aug 2008 10:09:31 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mail.kirov.so-cdu.ru ([77.72.136.145]:55528 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S1820100AbYHVJlw (ORCPT + 1 other); Fri, 22 Aug 2008 13:41:52 +0400 X-Yandex-Spam: 1 X-Yandex-Front: smtp13 X-Yandex-TimeMark: 1219398112 X-MsgDayCount: 4 X-Comment: RFC 2476 MSA function at smtp13.yandex.ru logged sender identity as: bu7cher Message-ID: <48AE89DC.9080408@yandex.ru> Date: Fri, 22 Aug 2008 13:41:48 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Luigi Rizzo References: <20080822090448.GB57441@onelab2.iet.unipi.it> In-Reply-To: <20080822090448.GB57441@onelab2.iet.unipi.it> Content-Type: multipart/mixed; boundary="------------010404020304060805040407" Cc: David Quattlebaum , Ivan Voras , freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 10:09:35 -0000 This is a multi-part message in MIME format. --------------010404020304060805040407 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Luigi Rizzo wrote: > interestingly simple. > > Question - is the process' ENV easily available in this part > of the kernel, so one could in principle use environment variables > as replacement strings ? > > Some comments on the code in the above patch: > > + readability it might be improved a bit: > e.g. I don't see why uma_{zalloc|zfree} are hidden behind macros, > nor why symlynk_magic() isn't simply called as > > if (vfs_magiclinks) > symlink_magic(td, cp, &linklen); > > as it cannot fail as implemented; > also, the whole MATCH/SUBSTITUTE macros are not particularly > readable -- i understand one needs macros to implement sizeof("somestring") > correctly, but apart from a wrapper I believe the core of these two > blocks should be implemented by functions (possibly inline) with > MATCH() returning the match length so one doesn't need to replicate > the string parameter in SUBSTITUTE(); > > + correctness -- > 1. termchar is not reset to '/' if a match is not found > 2. what is the intended behaviour when the replacement string overflows > the buffer ? > > + efficiency of symlink_magic() might be improved too: > e.g. the function could do a quick check for the presence of @ and return > without allocation/deallocation if not found; > getcredhostname() (and similar routines) could be called so that > they write directly to tmp, without the need for > allocating an in-stack buffer This was so long ago.. As i remember this patch is a quick port of NetBSD's implementation and uses the same code. Also there was another implementation ported from DragonFlyBSD. David Quattlebaum is working on varsyms implementation and he sent fresh patch to me in this April. I attached patch. And sorry, i am not working on this today.. -- WBR, Andrey V. Elsukov --------------010404020304060805040407 Content-Type: application/octet-stream; name="varsym.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="varsym.patch" ZGlmZiAtVTMgLU4gc3JjL3N5cy9rZXJuL2tlcm5fdmFyc3ltLmMgc3JjL3N5cy9rZXJuL2tl cm5fdmFyc3ltLmMKLS0tIHNyYy9zeXMva2Vybi9rZXJuX3ZhcnN5bS5jCVdlZCBEZWMgMzEg MTk6MDA6MDAgMTk2OQorKysgc3JjL3N5cy9rZXJuL2tlcm5fdmFyc3ltLmMJVGh1IEZlYiAx NiAwOTozMTowOCAyMDA2CkBAIC0wLDAgKzEsNTYyIEBACisvKgorICogQ29weXJpZ2h0IChj KSAyMDAzLDIwMDQgVGhlIERyYWdvbkZseSBQcm9qZWN0LiAgQWxsIHJpZ2h0cyByZXNlcnZl ZC4KKyAqIAorICogVGhpcyBjb2RlIGlzIGRlcml2ZWQgZnJvbSBzb2Z0d2FyZSBjb250cmli dXRlZCB0byBUaGUgRHJhZ29uRmx5IFByb2plY3QKKyAqIGJ5IE1hdHRoZXcgRGlsbG9uIDxk aWxsb25AYmFja3BsYW5lLmNvbT4KKyAqIAorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBp biBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmlj YXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRp dGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3Vy Y2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2Us IHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIu CisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2Ug dGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0 aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluCisgKiAgICB0aGUgZG9jdW1l bnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlCisgKiAg ICBkaXN0cmlidXRpb24uCisgKiAzLiBOZWl0aGVyIHRoZSBuYW1lIG9mIFRoZSBEcmFnb25G bHkgUHJvamVjdCBub3IgdGhlIG5hbWVzIG9mIGl0cworICogICAgY29udHJpYnV0b3JzIG1h eSBiZSB1c2VkIHRvIGVuZG9yc2Ugb3IgcHJvbW90ZSBwcm9kdWN0cyBkZXJpdmVkCisgKiAg ICBmcm9tIHRoaXMgc29mdHdhcmUgd2l0aG91dCBzcGVjaWZpYywgcHJpb3Igd3JpdHRlbiBw ZXJtaXNzaW9uLgorICogCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBD T1BZUklHSFQgSE9MREVSUyBBTkQgQ09OVFJJQlVUT1JTCisgKiBgYEFTIElTJycgQU5EIEFO WSBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UCisg KiBMSU1JVEVEIFRPLCBUSEUgSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElU WSBBTkQgRklUTkVTUworICogRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFIEFSRSBESVNDTEFJ TUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFCisgKiBDT1BZUklHSFQgSE9MREVSUyBPUiBD T05UUklCVVRPUlMgQkUgTElBQkxFIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwKKyAqIElO Q0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSBPUiBDT05TRVFVRU5USUFMIERBTUFHRVMg KElOQ0xVRElORywKKyAqIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VC U1RJVFVURSBHT09EUyBPUiBTRVJWSUNFUzsKKyAqIExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQ Uk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pIEhPV0VWRVIgQ0FVU0VECisgKiBB TkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNU UklDVCBMSUFCSUxJVFksCisgKiBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBP VEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWSBPVVQKKyAqIE9GIFRIRSBVU0UgT0YgVEhJ UyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRgorICog U1VDSCBEQU1BR0UuCisgKiAKKyAqICRGcmVlQlNEJAorICogJERyYWdvbkZseTogc3JjL3N5 cy9rZXJuL2tlcm5fdmFyc3ltLmMsdiAxLjYgMjAwNS8wMS8xNCAwMjoyNTowOCBqb2VyZyBF eHAgJAorICovCisKKy8qCisgKiBUaGlzIG1vZHVsZSBpbXBsZW1lbnRzIHZhcmlhYmxlIHN0 b3JhZ2UgYW5kIG1hbmFnZW1lbnQgZm9yIHZhcmlhbnQKKyAqIHN5bWxpbmtzLiAgVGhlc2Ug dmFyaWFibGVzIG1heSBhbHNvIGJlIHVzZWQgZm9yIGdlbmVyYWwgcHVycG9zZXMuCisgKi8K KworI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9zeXN0bS5oPgorI2lu Y2x1ZGUgPHN5cy9rZXJuZWwuaD4KKyNpbmNsdWRlIDxzeXMvdWNyZWQuaD4KKyNpbmNsdWRl IDxzeXMvcmVzb3VyY2V2YXIuaD4KKyNpbmNsdWRlIDxzeXMvcHJpdi5oPgorI2luY2x1ZGUg PHN5cy9wcm9jLmg+CisjaW5jbHVkZSA8c3lzL2phaWwuaD4KKyNpbmNsdWRlIDxzeXMvcXVl dWUuaD4KKyNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CisjaW5jbHVkZSA8c3lzL21hbGxvYy5o PgorI2luY2x1ZGUgPHN5cy92YXJzeW0uaD4KKyNpbmNsdWRlIDxzeXMvc3lzcHJvdG8uaD4K KworTUFMTE9DX0RFRklORShNX1ZBUlNZTSwgInZhcnN5bSIsICJ2YXJpYWJsZSBzZXRzIGZv ciB2YXJpYW50IHN5bWxpbmtzIik7CisKK3N0cnVjdCB2YXJzeW1zZXQJdmFyc3ltc2V0X3N5 czsKKworc3RhdGljIGludAkJdmFyc3ltbWFrZShpbnQgbGV2ZWwsIGNvbnN0IGNoYXIgKm5h bWUsIGNvbnN0IGNoYXIgKmRhdGEpOworc3RhdGljIHZvaWQJCXZhcnN5bWRyb3AodmFyc3lt X3QgdmFyKTsKK3N0YXRpYyBzdHJ1Y3QgdmFyc3ltZW50ICoKKwkJCXZhcnN5bWxvb2t1cChz dHJ1Y3QgdmFyc3ltc2V0ICp2c3MsIGNvbnN0IGNoYXIgKm5hbWUsIGludCBuYW1lbGVuKTsK K3N0YXRpYyB2YXJzeW1fdAkJdmFyc3ltZmluZChpbnQgbWFzaywgY29uc3QgY2hhciAqbmFt ZSwgaW50IG5hbWVsZW4pOworCitpbnQgdmFyc3ltX2NvbDFvbmx5ID0gMDsKK1NZU0NUTF9J TlQoX3ZmcywgT0lEX0FVVE8sIHZhcnN5bV9jb2wxb25seSwgQ1RMRkxBR19SVywgJnZhcnN5 bV9jb2wxb25seSwgMCwKKyAgICAiVmFyc3ltIHZhcmlhYmxlcyBzdGFydCBpbiBjb2x1bW4g MSBvbmx5Iik7CisKKy8qCisgKiBJbml0aWFsaXplIHRoZSB2YXJpYW50IHN5bWxpbmsgc3Vi c3lzdGVtCisgKi8KK3N0YXRpYyB2b2lkCit2YXJzeW1fc3lzaW5pdCh2b2lkICpkdW1teSkK K3sKKyAgICB2YXJzeW1zZXRfaW5pdCgmdmFyc3ltc2V0X3N5cywgTlVMTCk7Cit9CitTWVNJ TklUKGFubm91bmNlLCBTSV9TVUJfSU5UUklOU0lDLCBTSV9PUkRFUl9GSVJTVCwgdmFyc3lt X3N5c2luaXQsIE5VTEwpOworCisvKgorICogSW5pdGlhbGl6ZSB0aGUgdmFyc3ltc2V0IGZv ciBwcm9jMAorICovCitzdGF0aWMgdm9pZAordmFyc3ltX3AwaW5pdCh2b2lkICpkdW1teSkK K3sKKwl2YXJzeW1zZXRfaW5pdCgmcHJvYzAucF92YXJzeW1zZXQsIE5VTEwpOworfQorU1lT SU5JVChwMGluaXQsIFNJX1NVQl9JTlRSSU5TSUMsIFNJX09SREVSX1NFQ09ORCwgdmFyc3lt X3AwaW5pdCwgTlVMTCk7CisKKy8qCisgKiB2YXJzeW1yZXBsYWNlKCkgLSBjYWxsZWQgZnJv bSBuYW1laQorICoKKyAqCURvIHZhcmlhbnQgc3ltbGluayB2YXJpYWJsZSBzdWJzdGl0dXRp b24KKyAqLworaW50Cit2YXJzeW1yZXBsYWNlKGNoYXIgKmNwLCBpbnQgbGlua2xlbiwgaW50 IG1heGxlbikKK3sKKyAgICBpbnQgcmxlbjsKKyAgICBpbnQgeGxlbjsKKyAgICBpbnQgbmxl bjsKKyAgICBpbnQgaTsKKyAgICB2YXJzeW1fdCB2YXI7CisKKyAgICBybGVuID0gbGlua2xl bjsKKyAgICB3aGlsZSAobGlua2xlbiA+IDEpIHsKKwlpZiAoY3BbMF0gPT0gJyQnICYmIGNw WzFdID09ICd7JykgeworCQlmb3IgKGkgPSAyOyBpIDwgbGlua2xlbjsgKytpKSB7CisJCQlp ZiAoY3BbaV0gPT0gJ30nKQorCQkgICAgCWJyZWFrOworCQl9CisJCS8qCisJCSAqIEluIGph aWwgd2Ugc2hvdWxkIHJlc2V0IFZBUlNZTV9VU0VSX01BU0ssIHdlIGNoZWNrIGl0CisJCSAq IGludG8gdmFyc3ltZmluZC4KKwkJICovCisJICAgIGlmIChpIDwgbGlua2xlbiAmJiAoCisJ CQl2YXIgPSB2YXJzeW1maW5kKFZBUlNZTV9BTExfTUFTSywgY3AgKyAyLCBpIC0gMikpICE9 IE5VTEwpIAorCQl7CisJCQl4bGVuID0gaSArIDE7CQkJLyogYnl0ZXMgdG8gc3RyaWtlICov CisJCQlubGVuID0gc3RybGVuKHZhci0+dnNfZGF0YSk7CS8qIGJ5dGVzIHRvIGFkZCAqLwor CQkJaWYgKGxpbmtsZW4gKyBubGVuIC0geGxlbiA+PSBtYXhsZW4pIAorCQkJeworCQkgICAg CXZhcnN5bWRyb3AodmFyKTsKKwkJICAgIAlyZXR1cm4oLTEpOworCQkJfQorCQkJS0FTU0VS VChsaW5rbGVuID49IHhsZW4sICgiJXM6IGxpbmtsZW4gPCB4bGVuIixfX2Z1bmNfXykpOwor CQkJaWYgKGxpbmtsZW4gIT0geGxlbikKKwkJCQliY29weShjcCArIHhsZW4sIGNwICsgbmxl biwgbGlua2xlbiAtIHhsZW4pOworCQkJYmNvcHkodmFyLT52c19kYXRhLCBjcCwgbmxlbik7 CisJCQlsaW5rbGVuICs9IG5sZW4gLSB4bGVuOwkvKiBuZXcgcmVsYXRpdmUgbGVuZ3RoICov CisJCQlybGVuICs9IG5sZW4gLSB4bGVuOwkvKiByZXR1cm5lZCB0b3RhbCBsZW5ndGggKi8K KwkJCWNwICs9IG5sZW47CQkvKiBhZGp1c3QgcGFzdCByZXBsYWNlbWVudCAqLworCQkJbGlu a2xlbiAtPSBubGVuOwkvKiBhZGp1c3QgcGFzdCByZXBsYWNlbWVudCAqLworCQkJbWF4bGVu IC09IG5sZW47CQkvKiBhZGp1c3QgcGFzdCByZXBsYWNlbWVudCAqLworCSAgICB9IGVsc2Ug eworCQkJLyoKKwkJCSAqIEl0J3Mgb2sgaWYgaSBwb2ludHMgdG8gdGhlICd9JywgaXQgd2ls bCBzaW1wbHkgYmUKKwkJCSAqIHNraXBwZWQuICBpIGNvdWxkIGFsc28gaGF2ZSBoaXQgbGlu a2xlbi4KKwkJCSAqLworCQkJY3AgKz0gaTsKKwkJCWxpbmtsZW4gLT0gaTsKKwkJCW1heGxl biAtPSBpOworCSAgICB9CisJfSBlbHNlIHsKKwkgICAgLyoKKwkgICAgICogQnJlYWsgaWYg d2UgZGlkbid0IGhpdCBhICQgaW4gY29sLiAxIGlmIHZhcnN5bV9jb2wxb25seSAhPSAwCisJ ICAgICAqLworCSAgICBpZiAodmFyc3ltX2NvbDFvbmx5ICE9IDApCisJCWJyZWFrOworCSAg ICArK2NwOworCSAgICAtLWxpbmtsZW47CisJICAgIC0tbWF4bGVuOworCX0KKyAgICB9Cisg ICAgcmV0dXJuKHJsZW4pOworfQorCisvKgorICogdmFyc3ltX3NldCgpIHN5c3RlbSBjYWxs CisgKgorICogKGludCBsZXZlbCwgY29uc3QgY2hhciAqbmFtZSwgY29uc3QgY2hhciAqZGF0 YSkKKyAqLworaW50Cit2YXJzeW1fc2V0KHN0cnVjdCB0aHJlYWQgKnRkLCBzdHJ1Y3QgdmFy c3ltX3NldF9hcmdzICp1YXApCit7CisgICAgY2hhciBuYW1lW01BWFZBUlNZTV9OQU1FXTsK KyAgICBjaGFyICpidWY7CisgICAgaW50IGVycm9yOworCisgICAgaWYgKChlcnJvciA9IGNv cHlpbnN0cih1YXAtPm5hbWUsIG5hbWUsIHNpemVvZihuYW1lKSwgTlVMTCkpICE9IDApCisJ CWdvdG8gZG9uZTI7CisgICAgCisJYnVmID0gbWFsbG9jKE1BWFZBUlNZTV9EQVRBLCBNX1RF TVAsIE1fV0FJVE9LKTsKKyAgICBpZiAodWFwLT5kYXRhICYmIAorCShlcnJvciA9IGNvcHlp bnN0cih1YXAtPmRhdGEsIGJ1ZiwgTUFYVkFSU1lNX0RBVEEsIE5VTEwpKSAhPSAwKQorICAg IHsKKwkJZ290byBkb25lMTsKKyAgICB9CisgICAgCisJc3dpdGNoKHVhcC0+bGV2ZWwpIHsK KwljYXNlIFZBUlNZTV9TWVM6CisJCWlmICh0ZC0+dGRfcHJvYyAhPSBOVUxMKSAKKwkJewor CQkJLyogCisJCSAJICogT25seSByb290IGNhbiBjaGFuZ2UgU1lTVEVNJ3MgdmFyc3ltcy4g CisJCQkgKiBQcmlzb24ncyByb290IGNhbiBjaGFuZ2Ugb25seSBTWVNURU0ncyB2YXJzeW1z CisJCQkgKiBmb3Igb3duIHByaXNvbi4KKwkJCSAqLworCQkJZXJyb3IgPSBwcml2X2NoZWNr X2NyZWQodGQtPnRkX3Byb2MtPnBfdWNyZWQsIFBSSVZfQ1JFRF9TRVRVSUQsIDApOworCQkJ aWYgKGVycm9yICE9IDApCisJCQkJYnJlYWs7IC8qIGVycm9yID0gRVBFUk0gKi8KKwkJCWlm IChqYWlsZWQodGQtPnRkX3Byb2MtPnBfdWNyZWQpKQorCQkJCXVhcC0+bGV2ZWwgPSBWQVJT WU1fUFJJU09OOworCQl9IAorCQkvKiBmYWxsIHRocm91Z2ggKi8KKwljYXNlIFZBUlNZTV9V U0VSOgorCQkvKiBYWFggaW1wbGVtZW50IHBlci1qYWlsIHVzZXIgKi8KKwkJaWYgKHRkLT50 ZF9wcm9jICE9IE5VTEwgJiYgCisJCQl1YXAtPmxldmVsID09IFZBUlNZTV9VU0VSICYmCisJ CQlqYWlsZWQodGQtPnRkX3Byb2MtPnBfdWNyZWQpKSAKKwkJeworCQkJLyogCisJCQkgKiBE ZW55IGNoYW5nZSB1c2VycyB2YXJzeW1zIGZvciBqYWlsZWQgcHJvY2VzZXMuIAorCQkJICog KHdlIGRvbid0IGhhdmUgYSBwZXItamFpbGVkdXNlciB1aWRpbmZvKQorCQkJICovCisJCQll cnJvciA9IEVQRVJNOworCQkJYnJlYWs7CisJCX0KKwkJLyogZmFsbCB0aHJvdWdoICovCisJ Y2FzZSBWQVJTWU1fUFBST0M6CisJY2FzZSBWQVJTWU1fUFJPQzoKKwkJZXJyb3IgPSB2YXJz eW1tYWtlKHVhcC0+bGV2ZWwsIG5hbWUsIE5VTEwpOworCQlpZiAodWFwLT5kYXRhKSAKKwkJ CWVycm9yID0gdmFyc3ltbWFrZSh1YXAtPmxldmVsLCBuYW1lLCBidWYpOworCQlicmVhazsK KwlkZWZhdWx0OgorCQllcnJvciA9IEVJTlZBTDsKKyAgICB9Citkb25lMToKKwlmcmVlKGJ1 ZiwgTV9URU1QKTsKK2RvbmUyOgorICAgIHJldHVybihlcnJvcik7Cit9CisKKy8qCisgKiB2 YXJzeW1fZ2V0KCkgc3lzdGVtIGNhbGwKKyAqCisgKiAoaW50IG1hc2ssIGNvbnN0IGNoYXIg KndpbGQsIGNoYXIgKmJ1ZiwgaW50ICpzaXplKQorICovCitpbnQKK3ZhcnN5bV9nZXQoc3Ry dWN0IHRocmVhZCAqdGQsIHN0cnVjdCB2YXJzeW1fZ2V0X2FyZ3MgKnVhcCkKK3sKKyAgICBj aGFyIHdpbGRbTUFYVkFSU1lNX05BTUVdOworICAgIHZhcnN5bV90IHN5bTsKKyAgICBpbnQg ZXJyb3I7CisgICAgaW50IGRsZW4sIGJ1ZnNpemU7CisKKyAgICBpZiAoKGVycm9yID0gY29w eWluc3RyKHVhcC0+d2lsZCwgd2lsZCwgc2l6ZW9mKHdpbGQpLCBOVUxMKSkgIT0gMCkKKwkJ Z290byBkb25lOworICAgIGlmICgoZXJyb3IgPSBjb3B5aW4odWFwLT5zaXplLCAmYnVmc2l6 ZSwgc2l6ZW9mKGJ1ZnNpemUpKSkgIT0gMCkKKwkJZ290byBkb25lOworCWlmICh1YXAtPm1h c2sgJiAoflZBUlNZTV9BTExfTUFTSykpIHsKKwkJZXJyb3IgPSBFSU5WQUw7CisJCWdvdG8g ZG9uZTsKKwl9CisgICAgc3ltID0gdmFyc3ltZmluZCh1YXAtPm1hc2ssIHdpbGQsIHN0cmxl bih3aWxkKSk7CisgICAgaWYgKHN5bSA9PSBOVUxMKSB7CisJCWVycm9yID0gRU5PRU5UOwor CQlnb3RvIGRvbmU7CisgICAgfQorICAgIGRsZW4gPSBzdHJsZW4oc3ltLT52c19kYXRhKTsK KyAgICBpZiAoZGxlbiA8IGJ1ZnNpemUpIHsKKwkJZXJyb3IgPSBjb3B5b3V0KHN5bS0+dnNf ZGF0YSwgdWFwLT5idWYsIGRsZW4gKyAxKTsKKyAgICB9IGVsc2UgCisJCWVycm9yID0gRU9W RVJGTE9XOyAvKiBidWZmZXIgdG9vIHNtYWxsICovCisJaWYgKGVycm9yID09IDApIHsKKwkg ICAgZGxlbisrOworCQllcnJvciA9IGNvcHlvdXQoJmRsZW4sIHVhcC0+c2l6ZSwgc2l6ZW9m KGRsZW4pKTsKKwl9CisgICAgdmFyc3ltZHJvcChzeW0pOworZG9uZToKKyAgICByZXR1cm4o ZXJyb3IpOworfQorCisvKgorICogdmFyc3ltX2xpc3QoKSBzeXN0ZW0gY2FsbAorICoKKyAq IChpbnQgbGV2ZWwsIGNoYXIgKmJ1ZiwgaW50ICpzaXplLCBpbnQgKm1hcmtlcikKKyAqLwor aW50Cit2YXJzeW1fbGlzdChzdHJ1Y3QgdGhyZWFkICp0ZCwgc3RydWN0IHZhcnN5bV9saXN0 X2FyZ3MgKnVhcCkKK3sKKwlzdHJ1Y3QgdmFyc3ltc2V0ICp2c3M7CisJc3RydWN0IHZhcnN5 bWVudCAqdmU7CisJc3RydWN0IHByb2MgKnA7CisJaW50IGk7CisJaW50IGVycm9yOworCWlu dCBieXRlczsKKwlpbnQgZWFybHl0ZXJtOworCWludCBtYXJrZXI7CisJaW50IG1heHNpemU7 CisKKwkvKgorCSAqIEdldCB0aGUgbWFya2VyIGFuZCBtYXhzaXplIGZyb20gdXNlcnNwYWNl LgorCSAqLworCWlmICgoZXJyb3IgPSBjb3B5aW4odWFwLT5tYXJrZXIsICZtYXJrZXIsIHNp emVvZihtYXJrZXIpKSkgIT0gMCkKKwkJZ290byBkb25lOworCWlmICgoZXJyb3IgPSBjb3B5 aW4odWFwLT5zaXplLCAmbWF4c2l6ZSwgc2l6ZW9mKG1heHNpemUpKSkgIT0gMCkKKwkJZ290 byBkb25lOworCQorCS8qCisJICogRmlndXJlIG91dCB0aGUgdmFyc3ltIHNldC4KKwkgKi8K KwlwID0gdGQtPnRkX3Byb2M7CisJdnNzID0gTlVMTDsKKworCXN3aXRjaCAodWFwLT5sZXZl bCkgeworCWNhc2UgVkFSU1lNX1BQUk9DOgorCQlpZiAocCAmJiBwLT5wX3BwdHIpCisJCQl2 c3MgPSAmcC0+cF9wcHRyLT5wX3ZhcnN5bXNldDsKKwkJYnJlYWs7CisJY2FzZSBWQVJTWU1f UFJPQzoKKwkJaWYgKHApCisJCQl2c3MgPSAmcC0+cF92YXJzeW1zZXQ7CisJCWJyZWFrOwor CWNhc2UgVkFSU1lNX1VTRVI6CisJCWlmIChwKSB7CisJCQkvKgorCQkJICogWFhYOiBKYWls ZWQgdXNlcnMgY3VycmVudGx5IG5vdCBzdXBwb3J0ZWQuCisJCQkgKi8KKwkJCWlmIChqYWls ZWQocC0+cF91Y3JlZCkpIHsKKwkJCQllcnJvciA9IEVQRVJNOworCQkJCWdvdG8gZG9uZTsK KwkJCX0KKwkJCXZzcyA9ICZwLT5wX3VjcmVkLT5jcl91aWRpbmZvLT51aV92YXJzeW1zZXQ7 CisJCX0KKwkJYnJlYWs7CisJY2FzZSBWQVJTWU1fU1lTOgorCQlpZiAocCAhPSBOVUxMICYm IGphaWxlZChwLT5wX3VjcmVkKSkKKwkJCXZzcyA9ICZwLT5wX3VjcmVkLT5jcl9wcmlzb24t PnByX3ZhcnN5bXNldDsKKwkJZWxzZQorCQkJdnNzID0gJnZhcnN5bXNldF9zeXM7CisJfQor CWlmICh2c3MgPT0gTlVMTCkgeworCQllcnJvciA9IEVJTlZBTDsKKwkJZ290byBkb25lOwor CX0KKworCS8qCisJICogTG9vcCB0aHJvdWdoIHRoZSB2YXJpYWJsZXMgYW5kIGR1bXAgdGhl bSB0byB1YXAtPmJ1ZgorCSAqLworCWkgPSAwOworCWJ5dGVzID0gMDsKKwllYXJseXRlcm0g PSAwOworCisJVEFJTFFfRk9SRUFDSCh2ZSwgJnZzcy0+dnhfcXVldWUsIHZlX2VudHJ5KSB7 CisJCXZhcnN5bV90IHN5bSA9IHZlLT52ZV9zeW07CisJCWludCBuYW1lbGVuID0gc3RybGVu KHN5bS0+dnNfbmFtZSk7CisJCWludCBkYXRhbGVuID0gc3RybGVuKHN5bS0+dnNfZGF0YSk7 CisJCWludCB0b3RsZW4gPSBuYW1lbGVuICsgZGF0YWxlbiArIDI7CisKKwkJLyoKKwkJICog U2tpcCB0byBvdXIgaW5kZXggcG9pbnQKKwkJICovCisJCWlmIChpIDwgbWFya2VyKSB7CisJ CQkrK2k7CisJCQljb250aW51ZTsKKwkJfQorCisJCS8qCisJCSAqIFN0b3AgaWYgdGhlcmUg aXMgaW5zdWZmaWNpZW50IHNwYWNlIGluIHRoZSB1c2VyIGJ1ZmZlci4KKwkJICogSWYgd2Ug aGF2ZW4ndCBzdG9yZWQgYW55dGhpbmcgeWV0IHJldHVybiBFT1ZFUkZMT1cuIAorCQkgKiBO b3RlIHRoYXQgdGhlIG1hcmtlciBpbmRleCAoaSkgZG9lcyBub3QgY2hhbmdlLgorCQkgKi8K KwkJaWYgKGJ5dGVzICsgdG90bGVuID4gbWF4c2l6ZSkgeworCQkJaWYgKGJ5dGVzID09IDAp CisJCQkJZXJyb3IgPSBFT1ZFUkZMT1c7CisJCQllYXJseXRlcm0gPSAxOworCQkJYnJlYWs7 CisJCX0KKworCQllcnJvciA9IGNvcHlvdXQoc3ltLT52c19uYW1lLCB1YXAtPmJ1ZiArIGJ5 dGVzLCBuYW1lbGVuICsgMSk7CisJCWlmIChlcnJvciA9PSAwKSB7CisJCQlieXRlcyArPSBu YW1lbGVuICsgMTsKKwkJCWVycm9yID0gY29weW91dChzeW0tPnZzX2RhdGEsIHVhcC0+YnVm ICsgYnl0ZXMsIGRhdGFsZW4gKyAxKTsKKwkJCWlmIChlcnJvciA9PSAwKQorCQkJCWJ5dGVz ICs9IGRhdGFsZW4gKyAxOworCQkJZWxzZQorCQkJCWJ5dGVzIC09IG5hbWVsZW4gKyAxOwkv KiByZXZlcnQgaWYgZXJyb3IgKi8KKwkJfQorCQlpZiAoZXJyb3IpIHsKKwkJCWVhcmx5dGVy bSA9IDE7CisJCQlicmVhazsKKwkJfQorCQkrK2k7CisJfQorCisJLyoKKwkgKiBTYXZlIHRo ZSBtYXJrZXIgYmFjay4gIElmIG5vIGVycm9yIG9jY3VyZWQgYW5kIGVhcmx5dGVybSBpcyBj bGVhcgorCSAqIHRoZSBtYXJrZXIgaXMgc2V0IHRvIC0xIGluZGljYXRpbmcgdGhhdCB0aGUg dmFyaWFibGUgbGlzdCBoYXMgYmVlbgorCSAqIGV4aGF1c3RlZC4gIElmIG5vIGVycm9yIG9j Y3VyZWQgdGhlIG51bWJlciBvZiBieXRlcyBsb2FkZWQgaW50bworCSAqIHRoZSBidWZmZXIg d2lsbCBiZSByZXR1cm5lZCwgb3RoZXJ3aXNlIHRoZSBzeXNjYWxsIGNvZGUgcmV0dXJucyAt MS4KKwkgKi8KKwlpZiAoZXJyb3IgPT0gMCAmJiBlYXJseXRlcm0gPT0gMCkKKwkJbWFya2Vy ID0gLTE7CisJZWxzZQorCQltYXJrZXIgPSBpOworCWlmIChlcnJvciA9PSAwKQorCQllcnJv ciA9IGNvcHlvdXQoJm1hcmtlciwgdWFwLT5tYXJrZXIsIHNpemVvZihtYXJrZXIpKTsKKwlp ZiAoZXJyb3IgPT0gMCkKKwkJZXJyb3IgPSBjb3B5b3V0KCZieXRlcywgdWFwLT5zaXplLCBz aXplb2YoYnl0ZXMpKTsKK2RvbmU6CisJcmV0dXJuKGVycm9yKTsKK30KKworLyoKKyAqIExv b2t1cCBhIHZhcmlhbnQgc3ltbGluay4gIFhYWCB1c2UgYSBoYXNoIHRhYmxlLgorICovCitz dGF0aWMKK3N0cnVjdCB2YXJzeW1lbnQgKgordmFyc3ltbG9va3VwKHN0cnVjdCB2YXJzeW1z ZXQgKnZzcywgY29uc3QgY2hhciAqbmFtZSwgaW50IG5hbWVsZW4pCit7CisgICAgc3RydWN0 IHZhcnN5bWVudCAqdmU7CisKKyAgICBUQUlMUV9GT1JFQUNIKHZlLCAmdnNzLT52eF9xdWV1 ZSwgdmVfZW50cnkpIHsKKwkJdmFyc3ltX3QgdmFyID0gdmUtPnZlX3N5bTsKKwkJaWYgKHZh ci0+dnNfbmFtZWxlbiA9PSBuYW1lbGVuICYmIAorCSAgICAJYmNtcChuYW1lLCB2YXItPnZz X25hbWUsIG5hbWVsZW4pID09IDApIAorCQl7CisJICAgIAlyZXR1cm4odmUpOworCQl9Cisg ICAgfQorICAgIHJldHVybihOVUxMKTsKK30KKworc3RhdGljIHZhcnN5bV90Cit2YXJzeW1m aW5kKGludCBtYXNrLCBjb25zdCBjaGFyICpuYW1lLCBpbnQgbmFtZWxlbikKK3sKKyAgICBz dHJ1Y3QgcHJvYyAqcCA9IGN1cnByb2M7CisgICAgc3RydWN0IHZhcnN5bWVudCAqdmUgPSBO VUxMOworICAgIHZhcnN5bV90IHN5bTsKKworCS8qCisJICogcGVyLXByb2Nlc3MgdmFyaWFi bGVzIG92ZXJyaWRlIHBlci11c2VyIHZhcmlhYmxlcywKKyAgICAgICAgICogcGVyLXByb2Nl c3MgdmFyaWFibGVzIG92ZXJyaWRlIHBhcmVudCBwcm9jZXNzIHZhcmlhYmxlcywKKwkgKiBw ZXItdXNlciB2YXJpYWJsZXMgb3ZlcnJpZGUgc3lzdGVtLXdpZGUgdmFyaWFibGVzLgorCSAq IFhYWDogcGVyLXVzZXIgdmFyaWFibGVzIGN1cnJlbnRseSBub3QgYWxsb3dlZCBpbiBqYWls LgorCSAqLworICAgIGlmICgobWFzayAmIChWQVJTWU1fUFJPQ19NQVNLfFZBUlNZTV9QUFJP Q19NQVNLfFZBUlNZTV9VU0VSX01BU0spKSAmJiBwICE9IE5VTEwpIHsKKwkJaWYgKG1hc2sg JiBWQVJTWU1fUFJPQ19NQVNLKQorCQkJdmUgPSB2YXJzeW1sb29rdXAoJnAtPnBfdmFyc3lt c2V0LCBuYW1lLCBuYW1lbGVuKTsKKwkJaWYgKHZlID09IE5VTEwgJiYgbWFzayAmIFZBUlNZ TV9QUFJPQ19NQVNLKQorCQkJdmUgPSB2YXJzeW1sb29rdXAoJnAtPnBfcHB0ci0+cF92YXJz eW1zZXQsIG5hbWUsIG5hbWVsZW4pOworCQlpZiAodmUgPT0gTlVMTCAmJiAobWFzayAmIFZB UlNZTV9VU0VSX01BU0spICYmICghamFpbGVkKHAtPnBfdWNyZWQpKSkKKwkgICAJCXZlID0g dmFyc3ltbG9va3VwKCZwLT5wX3VjcmVkLT5jcl91aWRpbmZvLT51aV92YXJzeW1zZXQsIAor CQkJCQkJCW5hbWUsIG5hbWVsZW4pOworICAgIH0KKyAgICBpZiAodmUgPT0gTlVMTCAmJiAo bWFzayAmIFZBUlNZTV9TWVNfTUFTSykpIHsKKwkJaWYgKHAgIT0gTlVMTCAmJiBqYWlsZWQo cC0+cF91Y3JlZCkpIAorCSAgICAJdmUgPSB2YXJzeW1sb29rdXAoJnAtPnBfdWNyZWQtPmNy X3ByaXNvbi0+cHJfdmFyc3ltc2V0LCAKKwkJCQkJCQluYW1lLCBuYW1lbGVuKTsKKwkJZWxz ZQorCSAgICAJdmUgPSB2YXJzeW1sb29rdXAoJnZhcnN5bXNldF9zeXMsIG5hbWUsIG5hbWVs ZW4pOworICAgIH0KKyAgICBpZiAodmUpIHsKKwkJc3ltID0gdmUtPnZlX3N5bTsKKwkJKytz eW0tPnZzX3JlZnM7CisJCXJldHVybihzeW0pOworICAgIH0gCisJcmV0dXJuKE5VTEwpOwor fQorCitzdGF0aWMgaW50Cit2YXJzeW1tYWtlKGludCBsZXZlbCwgY29uc3QgY2hhciAqbmFt ZSwgY29uc3QgY2hhciAqZGF0YSkKK3sKKyAgICB2YXJzeW1fdCBzeW07CisgICAgc3RydWN0 IHZhcnN5bXNldCAqdnNzID0gTlVMTDsKKyAgICBzdHJ1Y3QgdmFyc3ltZW50ICp2ZTsKKyAg ICBzdHJ1Y3QgcHJvYyAqcCA9IGN1cnByb2M7CisgICAgaW50IG5hbWVsZW4gPSBzdHJsZW4o bmFtZSk7CisgICAgaW50IGRhdGFsZW47CisgICAgaW50IGVycm9yOworCisJc3dpdGNoKGxl dmVsKSB7CisJY2FzZSBWQVJTWU1fUFBST0M6CisJCWlmIChwICYmIHAtPnBfcHB0cikKKwkJ dnNzID0gJnAtPnBfcHB0ci0+cF92YXJzeW1zZXQ7CisJCWJyZWFrOworCWNhc2UgVkFSU1lN X1BST0M6CisJCWlmIChwKQorCSAJdnNzID0gJnAtPnBfdmFyc3ltc2V0OworCQlicmVhazsK KwljYXNlIFZBUlNZTV9VU0VSOgorCQlpZiAocCkKKwkgICAgCXZzcyA9ICZwLT5wX3VjcmVk LT5jcl91aWRpbmZvLT51aV92YXJzeW1zZXQ7CisJCWJyZWFrOworCWNhc2UgVkFSU1lNX1NZ UzoKKwkJdnNzID0gJnZhcnN5bXNldF9zeXM7CisJCWJyZWFrOworCWNhc2UgVkFSU1lNX1BS SVNPTjoKKwkJaWYgKHApCisJICAgIAl2c3MgPSAmcC0+cF91Y3JlZC0+Y3JfcHJpc29uLT5w cl92YXJzeW1zZXQ7CisJCWJyZWFrOworICAgIH0KKyAgICBpZiAodnNzID09IE5VTEwpIHsK KwkJZXJyb3IgPSBFSU5WQUw7CisgICAgfSBlbHNlIGlmIChkYXRhICYmIHZzcy0+dnhfc2V0 c2l6ZSA+PSBNQVhWQVJTWU1fU0VUKSB7CisJCWVycm9yID0gRTJCSUc7CisgICAgfSBlbHNl IGlmIChkYXRhKSB7CisJCWRhdGFsZW4gPSBzdHJsZW4oZGF0YSk7CisJCXZlID0gbWFsbG9j KHNpemVvZihzdHJ1Y3QgdmFyc3ltZW50KSwgTV9WQVJTWU0sIE1fV0FJVE9LfE1fWkVSTyk7 CisJCXN5bSA9IG1hbGxvYyhzaXplb2Yoc3RydWN0IHZhcnN5bSkgKyBuYW1lbGVuICsgZGF0 YWxlbiArIDIsCisJCQkJCSAgIAlNX1ZBUlNZTSwgTV9XQUlUT0spOworCQl2ZS0+dmVfc3lt ID0gc3ltOworCQlzeW0tPnZzX3JlZnMgPSAxOworCQlzeW0tPnZzX25hbWVsZW4gPSBuYW1l bGVuOworCQlzeW0tPnZzX25hbWUgPSAoY2hhciAqKShzeW0gKyAxKTsKKwkJc3ltLT52c19k YXRhID0gc3ltLT52c19uYW1lICsgbmFtZWxlbiArIDE7CisJCXN0cmNweShzeW0tPnZzX25h bWUsIG5hbWUpOworCQlzdHJjcHkoc3ltLT52c19kYXRhLCBkYXRhKTsKKwkJCisJCVRBSUxR X0lOU0VSVF9UQUlMKCZ2c3MtPnZ4X3F1ZXVlLCB2ZSwgdmVfZW50cnkpOworCQl2c3MtPnZ4 X3NldHNpemUgKz0gc2l6ZW9mKHN0cnVjdCB2YXJzeW1lbnQpICsgCisJCQkJc2l6ZW9mKHN0 cnVjdCB2YXJzeW0pICsgbmFtZWxlbiArIGRhdGFsZW4gKyA4OyAvKiBYWFggKi8KKworCQll cnJvciA9IDA7CisgICAgfSBlbHNlIHsKKwkJaWYgKCh2ZSA9IHZhcnN5bWxvb2t1cCh2c3Ms IG5hbWUsIG5hbWVsZW4pKSAhPSBOVUxMKSB7CisJICAgIAlUQUlMUV9SRU1PVkUoJnZzcy0+ dnhfcXVldWUsIHZlLCB2ZV9lbnRyeSk7CisJCSAgICB2c3MtPnZ4X3NldHNpemUgLT0gc2l6 ZW9mKHN0cnVjdCB2YXJzeW1lbnQpICsgCisJCQkJCQkJICAgc2l6ZW9mKHN0cnVjdCB2YXJz eW0pICsgbmFtZWxlbiArIAorCQkJCQkJCSAgIHN0cmxlbih2ZS0+dmVfc3ltLT52c19kYXRh KSArIDg7IC8qIFhYWCAqLworCQkgICAgdmFyc3ltZHJvcCh2ZS0+dmVfc3ltKTsKKwkJICAg IGZyZWUodmUsIE1fVkFSU1lNKTsKKwkgICAgCWVycm9yID0gMDsKKwkJfSBlbHNlIHsKKwkg ICAgCWVycm9yID0gRU5PRU5UOworCQl9CisgICAgfQorICAgIHJldHVybihlcnJvcik7Cit9 CisKK3N0YXRpYyB2b2lkCit2YXJzeW1kcm9wKHZhcnN5bV90IHN5bSkKK3sKKyAgICBLQVNT RVJUKHN5bS0+dnNfcmVmcyA+IDAsICgiJXM6IHN5bS0+dnNfcmVmcyA8PSAwIiwgX19mdW5j X18pKTsKKyAgICBpZiAoLS1zeW0tPnZzX3JlZnMgPT0gMCkgeworCQlmcmVlKHN5bSwgTV9W QVJTWU0pOworICAgIH0KK30KKwordm9pZAordmFyc3ltc2V0X2luaXQoc3RydWN0IHZhcnN5 bXNldCAqdnNzLCBzdHJ1Y3QgdmFyc3ltc2V0ICpjb3B5KQoreworICAgIHN0cnVjdCB2YXJz eW1lbnQgKnZlLCAqbnZlOworCisgICAgVEFJTFFfSU5JVCgmdnNzLT52eF9xdWV1ZSk7CisJ CisgICAgaWYgKGNvcHkpIHsKKwkJVEFJTFFfRk9SRUFDSCh2ZSwgJmNvcHktPnZ4X3F1ZXVl LCB2ZV9lbnRyeSkgeworCQkJbnZlID0gbWFsbG9jKHNpemVvZihzdHJ1Y3QgdmFyc3ltZW50 KSwgTV9WQVJTWU0sIE1fV0FJVE9LfE1fWkVSTyk7CisJCQludmUtPnZlX3N5bSA9IHZlLT52 ZV9zeW07CisJCQkrK252ZS0+dmVfc3ltLT52c19yZWZzOworCQkJVEFJTFFfSU5TRVJUX1RB SUwoJnZzcy0+dnhfcXVldWUsIG52ZSwgdmVfZW50cnkpOworCQl9CisJCXZzcy0+dnhfc2V0 c2l6ZSA9IGNvcHktPnZ4X3NldHNpemU7CisgICAgfQorfQorCit2b2lkCit2YXJzeW1zZXRf Y2xlYW4oc3RydWN0IHZhcnN5bXNldCAqdnNzKQoreworICAgIHN0cnVjdCB2YXJzeW1lbnQg KnZlOworCisgICAgd2hpbGUgKCh2ZSA9IFRBSUxRX0ZJUlNUKCZ2c3MtPnZ4X3F1ZXVlKSkg IT0gTlVMTCkgeworCQlUQUlMUV9SRU1PVkUoJnZzcy0+dnhfcXVldWUsIHZlLCB2ZV9lbnRy eSk7CisJCXZhcnN5bWRyb3AodmUtPnZlX3N5bSk7CisJCWZyZWUodmUsIE1fVkFSU1lNKTsK KyAgICB9CisgICAgdnNzLT52eF9zZXRzaXplID0gMDsKK30KKwpJbmRleDogc3JjL2Jpbi9s bi9sbi4xCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9uY3ZzL3NyYy9iaW4vbG4vbG4uMSx2 CnJldHJpZXZpbmcgcmV2aXNpb24gMS4zMApkaWZmIC11IC1iIC1yMS4zMCBsbi4xCi0tLSBz cmMvYmluL2xuL2xuLjEJMTYgSmFuIDIwMDUgMTY6NDE6NTcgLTAwMDAJMS4zMAorKysgc3Jj L2Jpbi9sbi9sbi4xCTIyIEphbiAyMDA2IDIyOjU5OjM5IC0wMDAwCkBAIC0xODYsNiArMTg2 LDQ3IEBACiB3aGljaCBwZXJmb3JtcyBhCiAuWHIgbGluayAyCiBvcGVyYXRpb24gdXNpbmcg dGhlIHR3byBwYXNzZWQgYXJndW1lbnRzLgorLlNoIFZBUklBTlQgU1lNTElOS1MKKy5EeAor c3VwcG9ydHMgYSBzcGVjaWFsIGtpbmQgb2YgZHluYW1pYworc3ltYm9saWMgbGluayBjYWxs ZWQgYQorLkVtIHZhcmlhbnQgc3ltbGluayAuCitUaGUKKy5BciBzb3VyY2VfZmlsZQorb2Yg YSB2YXJpYW50IHN5bWxpbmsgbWF5IGNvbnRhaW4gb25lIG9yIG1vcmUKK3ZhcmlhYmxlIG5h bWVzLiAgRWFjaCBvZiB0aGVzZSB2YXJpYWJsZQorbmFtZXMgaXMgZW5jbG9zZWQgaW4gYnJh Y2VzIGFuZCBwcmVjZWRlZCBieSBhCitkb2xsYXIgc2lnbiBpbiB0aGUgc3R5bGUgb2YgdmFy aWFibGUgcmVmZXJlbmNlcyBpbgorLlhyIHNoIDEKK2FuZAorLlhyIGNzaCAxIC4KKy5QcAor V2hlbmV2ZXIgYSB2YXJpYW50IHN5bWxpbmsgaXMgZm9sbG93ZWQsIGVhY2gKK3ZhcmlhYmxl IGZvdW5kIGluCisuQXIgc291cmNlX2ZpbGUKK2lzIHJlcGxhY2VkIGJ5IGl0cyBhc3NvY2lh dGVkIHZhbHVlLgorSW4gdGhpcyBtYW5uZXIsIGEgdmFyaWFudCBzeW1saW5rIG1heSByZXNv bHZlIHRvIGRpZmZlcmVudAorcGF0aHMgYmFzZWQgb24gY29udGV4dC4gIFRoZSBmYWNpbGl0 eQorc3VwcG9ydHMgcGVyLXByb2Nlc3MsIHBlci11c2VyLCBhbmQgc3lzdGVtLXdpZGUgdmFy c3ltcy4KKy5QcAorVmFyc3ltIHZhcmlhYmxlcyBjYW4gYmUgc2V0IHdpdGggdGhlCisuWHIg dmFyc3ltIDEKK3V0aWxpdHkuICBSZWd1bGFyCisuWHIgZW52aXJvbiA3CitlbnZpcm9ubWVu dCB2YXJpYWJsZXMgYXJlCitub3QgdXNlZCB0byByZXNvbHZlIHZhcmlhbnQgc3ltbGlua3Mu CisuU3MgRVhBTVBMRQorLkJkIC1saXRlcmFsIC1vZmZzZXQgaW5kZW50CitzeXNjdGwgLXcg dmZzLnZhcnN5bV9lbmFibGU9MQorCitsbiAtcyAnYSR7ZnViYXJ9YicgdGVzdAorCitlY2hv ICdIZWxsbycgPiBheHhiCitlY2hvICdHb29kYnllJyA+IGF5eWIKKwordmFyc3ltIGZ1YmFy PXh4OyBjYXQgdGVzdAordmFyc3ltIGZ1YmFyPXl5OyBjYXQgdGVzdAorLkVkCiAuU2ggQ09N UEFUSUJJTElUWQogVGhlCiAuRmwgaCAsCkBAIC0yMDksNyArMjUwLDggQEAKIC5YciByZWFk bGluayAyICwKIC5YciBzdGF0IDIgLAogLlhyIHN5bWxpbmsgMiAsCi0uWHIgc3ltbGluayA3 CisuWHIgc3ltbGluayA3ICwKKy5YciB2YXJzeW0gMQogLlNoIFNUQU5EQVJEUwogVGhlCiAu Tm0KQEAgLTIyNCw0ICsyNjYsNCBAQAogQW4KIC5ObQogY29tbWFuZCBhcHBlYXJlZCBpbgot LkF0IHYxIC4KKy5BdCB2MSAuIFZhcmlhbnQgU3ltbGlua3MgYXBwZWFyZWQgaW4gRHJhZ29u Rmx5IEJTRCAuCkluZGV4OiBzcmMvaW5jbHVkZS91bmlzdGQuaAo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJD UyBmaWxlOiAvbmN2cy9zcmMvaW5jbHVkZS91bmlzdGQuaCx2CnJldHJpZXZpbmcgcmV2aXNp b24gMS43OApkaWZmIC11IC1iIC1yMS43OCB1bmlzdGQuaAotLS0gc3JjL2luY2x1ZGUvdW5p c3RkLmgJMTMgTWF5IDIwMDUgMTY6Mjc6MzAgLTAwMDAJMS43OAorKysgc3JjL2luY2x1ZGUv dW5pc3RkLmgJMjIgSmFuIDIwMDYgMjI6NTk6MzkgLTAwMDAKQEAgLTU1MCw2ICs1NTAsMTAg QEAKIGludAkgdW53aGl0ZW91dChjb25zdCBjaGFyICopOwogdm9pZAkqdmFsbG9jKHNpemVf dCk7CQkJLyogb2Jzb2xldGVkIGJ5IG1hbGxvYygpICovCiAKK2ludAkgdmFyc3ltX3NldChp bnQsIGNvbnN0IGNoYXIqLCBjb25zdCBjaGFyKik7CitpbnQJIHZhcnN5bV9nZXQoaW50LCBj b25zdCBjaGFyKiwgY2hhciosIGludCopOworaW50CSB2YXJzeW1fbGlzdChpbnQsIGNoYXIq LCBpbnQqLCBpbnQqKTsKKwogI2lmbmRlZiBfT1BUUkVTRVRfREVDTEFSRUQKICNkZWZpbmUJ X09QVFJFU0VUX0RFQ0xBUkVECiBleHRlcm4gaW50IG9wdHJlc2V0OwkJCS8qIGdldG9wdCgz KSBleHRlcm5hbCB2YXJpYWJsZSAqLwpJbmRleDogc3JjL3N5cy9jb25mL2ZpbGVzCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KUkNTIGZpbGU6IC9uY3ZzL3NyYy9zeXMvY29uZi9maWxlcyx2CnJldHJpZXZp bmcgcmV2aXNpb24gMS4xMDMxLjIuMTYKZGlmZiAtdSAtYiAtcjEuMTAzMS4yLjE2IGZpbGVz Ci0tLSBzcmMvc3lzL2NvbmYvZmlsZXMJMTMgSmFuIDIwMDYgMTQ6NTU6MTYgLTAwMDAJMS4x MDMxLjIuMTYKKysrIHNyYy9zeXMvY29uZi9maWxlcwkyMiBKYW4gMjAwNiAyMjo1OTozOSAt MDAwMApAQCAtMTI0Myw2ICsxMjQzLDcgQEAKIGtlcm4va2Vybl90aW1lb3V0LmMJCXN0YW5k YXJkCiBrZXJuL2tlcm5fdW10eC5jCQlzdGFuZGFyZAoga2Vybi9rZXJuX3V1aWQuYwkJc3Rh bmRhcmQKK2tlcm4va2Vybl92YXJzeW0uYwkJc3RhbmRhcmQKIGtlcm4va2Vybl94eHguYwkJ CXN0YW5kYXJkCiBrZXJuL2xpbmtfZWxmLmMJCQlzdGFuZGFyZAoga2Vybi9saW5rZXJfaWYu bQkJc3RhbmRhcmQKSW5kZXg6IHNyYy9zeXMvY29tcGF0L2ZyZWVic2QzMi9zeXNjYWxscy5t YXN0ZXIKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL25jdnMvc3JjL3N5cy9jb21wYXQvZnJl ZWJzZDMyL3N5c2NhbGxzLm1hc3Rlcix2CnJldHJpZXZpbmcgcmV2aXNpb24gMS41MC4yLjMK ZGlmZiAtdSAtYiAtcjEuNTAuMi4zIHN5c2NhbGxzLm1hc3RlcgotLS0gc3JjL3N5cy9jb21w YXQvZnJlZWJzZDMyL3N5c2NhbGxzLm1hc3Rlci5vcmlnCVNhdCBPY3QgMjggMTk6NDk6MDUg MjAwNgorKysgc3JjL3N5cy9jb21wYXQvZnJlZWJzZDMyL3N5c2NhbGxzLm1hc3RlcglNb24g QXVnIDI3IDIxOjA0OjE5IDIwMDcKQEAgLTc5NiwzICs3OTYsMTEgQEAKIDQ4MAlBVUVfRlRS VU5DQVRFCVNURAl7IGludCBmcmVlYnNkMzJfZnRydW5jYXRlKGludCBmZCwgXAogCQkJCSAg ICB1X2ludDMyX3QgbGVuZ3RobG8sIHVfaW50MzJfdCBsZW5ndGhoaSk7IH0KIDQ4MQlBVUVf S0lMTAlOT1BST1RPCXsgaW50IHRocl9raWxsMihwaWRfdCBwaWQsIGxvbmcgaWQsIGludCBz aWcpOyB9Cis0ODIJQVVFX05VTEwJTk9QUk9UTwl7IGludCB2YXJzeW1fc2V0KGludCBsZXZl bCwgXAorCQkJCSAgICBjb25zdCBjaGFyICpuYW1lLCBcCisJCQkJICAgIGNvbnN0IGNoYXIg KmRhdGEpOyB9Cis0ODMJQVVFX05VTEwJTk9QUk9UTwl7IGludCB2YXJzeW1fZ2V0KGludCBt YXNrLCBcCisJCQkJICAgIGNvbnN0IGNoYXIgKndpbGQsIFwKKwkJCQkgICAgY2hhciAqYnVm LCBpbnQgKnNpemUpOyB9Cis0ODQJQVVFX05VTEwJTk9QUk9UTwl7IGludCB2YXJzeW1fbGlz dChpbnQgbGV2ZWwsIFwKKwkJCQkgICAgY2hhciAqYnVmLCBpbnQgKnNpemUsIGludCAqbWFy a2VyKTsgfQpJbmRleDogc3JjL3N5cy9rZXJuL3N5c2NhbGxzLm1hc3Rlcgo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09ClJDUyBmaWxlOiAvbmN2cy9zcmMvc3lzL2tlcm4vc3lzY2FsbHMubWFzdGVyLHYKcmV0 cmlldmluZyByZXZpc2lvbiAxLjE5OC4yLjEKZGlmZiAtdSAtYiAtcjEuMTk4LjIuMSBzeXNj YWxscy5tYXN0ZXIKLS0tIHNyYy9zeXMva2Vybi9zeXNjYWxscy5tYXN0ZXIJMjEgTm92IDIw MDUgMDE6MTI6MzcgLTAwMDAJMS4xOTguMi4xCisrKyBzcmMvc3lzL2tlcm4vc3lzY2FsbHMu bWFzdGVyCTIyIEphbiAyMDA2IDIyOjU5OjQwIC0wMDAwCkBAIC04NDcsNSArODQ3LDEzIEBA CiA0NzkJQVVFX1RSVU5DQVRFCVNURAl7IGludCB0cnVuY2F0ZShjaGFyICpwYXRoLCBvZmZf dCBsZW5ndGgpOyB9CiA0ODAJQVVFX0ZUUlVOQ0FURQlTVEQJeyBpbnQgZnRydW5jYXRlKGlu dCBmZCwgb2ZmX3QgbGVuZ3RoKTsgfQogNDgxCUFVRV9LSUxMCVNURAl7IGludCB0aHJfa2ls bDIocGlkX3QgcGlkLCBsb25nIGlkLCBpbnQgc2lnKTsgfQorNDgyICAgICBBVUVfTlVMTCAg ICAgICAgU1RECXsgaW50IHZhcnN5bV9zZXQoaW50IGxldmVsLCBcCisJCQkJICAgICBjb25z dCBjaGFyICpuYW1lLCBcCisJCQkJICAgICBjb25zdCBjaGFyICpkYXRhKTsgfQorNDgzICAg ICBBVUVfTlVMTCAgICAgICAgU1RECXsgaW50IHZhcnN5bV9nZXQoaW50IG1hc2ssIFwKKwkJ CQkgICAgIGNvbnN0IGNoYXIgKndpbGQsIFwKKwkJCQkgICAgIGNoYXIgKmJ1ZiwgaW50ICpz aXplKTsgfQorNDg0ICAgICBBVUVfTlVMTCAgICAgICAgU1RECXsgaW50IHZhcnN5bV9saXN0 KGludCBsZXZlbCwgXAorCQkJCSAgICAgY2hhciAqYnVmLCBpbnQgKnNpemUsIGludCAqbWFy a2VyKTsgfQogOyBQbGVhc2UgY29weSBhbnkgYWRkaXRpb25zIGFuZCBjaGFuZ2VzIHRvIHRo ZSBmb2xsb3dpbmcgY29tcGF0YWJpbGl0eSB0YWJsZXM6CiA7IHN5cy9jb21wYXQvZnJlZWJz ZDMyL3N5c2NhbGxzLm1hc3RlcgpJbmRleDogc3JjL3N5cy9rZXJuL2tlcm5fZXhlYy5jCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KUkNTIGZpbGU6IC9uY3ZzL3NyYy9zeXMva2Vybi9rZXJuX2V4ZWMuYyx2 CnJldHJpZXZpbmcgcmV2aXNpb24gMS4yNzUuMi4zCmRpZmYgLXUgLWIgLXIxLjI3NS4yLjMg a2Vybl9leGVjLmMKLS0tIHNyYy9zeXMva2Vybi9rZXJuX2V4ZWMuYwkyNiBEZWMgMjAwNSAx Mzo0NzoxOSAtMDAwMAkxLjI3NS4yLjMKKysrIHNyYy9zeXMva2Vybi9rZXJuX2V4ZWMuYwky MiBKYW4gMjAwNiAyMjo1OTo0MCAtMDAwMApAQCAtNjE3LDYgKzYxNywxMSBAQAogCQljaGFu Z2Vfc3ZnaWQobmV3Y3JlZCwgbmV3Y3JlZC0+Y3JfZ2lkKTsKIAkJcC0+cF91Y3JlZCA9IG5l d2NyZWQ7CiAJCW5ld2NyZWQgPSBOVUxMOworCisJCS8qCisJCSAqIENsZWFyIGxvY2FsIHZh cnN5bSB2YXJpYWJsZXMKKwkJICovCisJCXZhcnN5bXNldF9jbGVhbigmcC0+cF92YXJzeW1z ZXQpOwogCX0gZWxzZSB7CiAJCWlmIChvbGRjcmVkLT5jcl91aWQgPT0gb2xkY3JlZC0+Y3Jf cnVpZCAmJgogCQkgICAgb2xkY3JlZC0+Y3JfZ2lkID09IG9sZGNyZWQtPmNyX3JnaWQpCklu ZGV4OiBzcmMvc3lzL2tlcm4va2Vybl9mb3JrLmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTog L25jdnMvc3JjL3N5cy9rZXJuL2tlcm5fZm9yay5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAx LjI1MgpkaWZmIC11IC1iIC1yMS4yNTIga2Vybl9mb3JrLmMKLS0tIHNyYy9zeXMva2Vybi9r ZXJuX2ZvcmsuYwkxIEp1bCAyMDA1IDE2OjI4OjMwIC0wMDAwCTEuMjUyCisrKyBzcmMvc3lz L2tlcm4va2Vybl9mb3JrLmMJMjIgSmFuIDIwMDYgMjI6NTk6NDEgLTAwMDAKQEAgLTU5Niw3 ICs1OTYsNyBAQAogCUxJU1RfSU5TRVJUX0FGVEVSKHAxLCBwMiwgcF9wZ2xpc3QpOwogCVBH UlBfVU5MT0NLKHAxLT5wX3BncnApOwogCUxJU1RfSU5JVCgmcDItPnBfY2hpbGRyZW4pOwot CisJdmFyc3ltc2V0X2luaXQoJnAyLT5wX3ZhcnN5bXNldCwgJnAxLT5wX3ZhcnN5bXNldCk7 CiAJY2FsbG91dF9pbml0KCZwMi0+cF9pdGNhbGxvdXQsIENBTExPVVRfTVBTQUZFKTsKIAog I2lmZGVmIEtUUkFDRQpJbmRleDogc3JjL3N5cy9rZXJuL2tlcm5famFpbC5jCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KUkNTIGZpbGU6IC9uY3ZzL3NyYy9zeXMva2Vybi9rZXJuX2phaWwuYyx2CnJldHJp ZXZpbmcgcmV2aXNpb24gMS41MC4yLjEKZGlmZiAtdSAtYiAtcjEuNTAuMi4xIGtlcm5famFp bC5jCi0tLSBzcmMvc3lzL2tlcm4va2Vybl9qYWlsLmMJMTMgTm92IDIwMDUgMDM6MTI6MzIg LTAwMDAJMS41MC4yLjEKKysrIHNyYy9zeXMva2Vybi9rZXJuX2phaWwuYwkyMiBKYW4gMjAw NiAyMjo1OTo0MSAtMDAwMApAQCAtMTYzLDYgKzE2Myw3IEBACiAJCXByLT5wcl9zbG90cyA9 IG1hbGxvYyhzaXplb2YoKnByLT5wcl9zbG90cykgKiBwcmlzb25fc2VydmljZV9zbG90cywK IAkJICAgIE1fUFJJU09OLCBNX1pFUk8gfCBNX1dBSVRPSyk7CiAJfQorCXZhcnN5bXNldF9p bml0KCZwci0+cHJfdmFyc3ltc2V0LCBOVUxMKTsKIAogCS8qIERldGVybWluZSBuZXh0IHBy X2lkIGFuZCBhZGQgcHJpc29uIHRvIGFsbHByaXNvbiBsaXN0LiAqLwogCXN4X3hsb2NrKCZh bGxwcmlzb25fbG9jayk7CkBAIC0xNzYsNyArMTc3LDcgQEAKIAkJCWlmICh0cnlwcmlkID09 IEpBSUxfTUFYKSB7CiAJCQkJc3hfeHVubG9jaygmYWxscHJpc29uX2xvY2spOwogCQkJCWVy cm9yID0gRUFHQUlOOwotCQkJCWdvdG8gZV9kcm9wdm5yZWY7CisJCQkJZ290byBlX2NsZWFu dmFyc3ltOwogCQkJfQogCQkJZ290byBuZXh0OwogCQl9CkBAIC0yMDcsNiArMjA4LDggQEAK IAkJcHNydi0+cHNfZGVzdHJveShwc3J2LCBwcik7CiAJfQogCXN4X3N1bmxvY2soJmFsbHBy aXNvbl9sb2NrKTsKK2VfY2xlYW52YXJzeW06CisJdmFyc3ltc2V0X2NsZWFuKCZwci0+cHJf dmFyc3ltc2V0KTsKIGVfZHJvcHZucmVmOgogCXZmc2xvY2tlZCA9IFZGU19MT0NLX0dJQU5U KHByLT5wcl9yb290LT52X21vdW50KTsKIAl2cmVsZShwci0+cHJfcm9vdCk7CkBAIC0zNDMs NiArMzQ2LDcgQEAKIAl2cmVsZShwci0+cHJfcm9vdCk7CiAJVkZTX1VOTE9DS19HSUFOVCh2 ZnNsb2NrZWQpOwogCisJdmFyc3ltc2V0X2NsZWFuKCZwci0+cHJfdmFyc3ltc2V0KTsKIAlt dHhfZGVzdHJveSgmcHItPnByX210eCk7CiAJaWYgKHByLT5wcl9saW51eCAhPSBOVUxMKQog CQlGUkVFKHByLT5wcl9saW51eCwgTV9QUklTT04pOwpJbmRleDogc3JjL3N5cy9rZXJuL2tl cm5fcmVzb3VyY2UuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvbmN2cy9zcmMvc3lzL2tl cm4va2Vybl9yZXNvdXJjZS5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjE0OC4yLjEKZGlm ZiAtdSAtYiAtcjEuMTQ4LjIuMSBrZXJuX3Jlc291cmNlLmMKLS0tIHNyYy9zeXMva2Vybi9r ZXJuX3Jlc291cmNlLmMJMjggRGVjIDIwMDUgMTc6MzU6NTUgLTAwMDAJMS4xNDguMi4xCisr KyBzcmMvc3lzL2tlcm4va2Vybl9yZXNvdXJjZS5jCTIyIEphbiAyMDA2IDIyOjU5OjQxIC0w MDAwCkBAIC0xMDU1LDYgKzEwNTUsNyBAQAogCQl9IGVsc2UgewogCQkJdWlwLT51aV9tdHhw ID0gbXR4X3Bvb2xfYWxsb2MobXR4cG9vbF9zbGVlcCk7CiAJCQl1aXAtPnVpX3VpZCA9IHVp ZDsKKwkJCXZhcnN5bXNldF9pbml0KCZ1aXAtPnVpX3ZhcnN5bXNldCwgTlVMTCk7CiAJCQlM SVNUX0lOU0VSVF9IRUFEKFVJSEFTSCh1aWQpLCB1aXAsIHVpX2hhc2gpOwogCQl9CiAJfQpA QCAtMTEyNSw2ICsxMTI2LDcgQEAKIAkJaWYgKHVpcC0+dWlfcHJvY2NudCAhPSAwKQogCQkJ cHJpbnRmKCJmcmVlaW5nIHVpZGluZm86IHVpZCA9ICVkLCBwcm9jY250ID0gJWxkXG4iLAog CQkJICAgIHVpcC0+dWlfdWlkLCB1aXAtPnVpX3Byb2NjbnQpOworCQl2YXJzeW1zZXRfY2xl YW4oJnVpcC0+dWlfdmFyc3ltc2V0KTsKIAkJVUlESU5GT19VTkxPQ0sodWlwKTsKIAkJRlJF RSh1aXAsIE1fVUlESU5GTyk7CiAJCXJldHVybjsKSW5kZXg6IHNyYy9zeXMva2Vybi92ZnNf bG9va3VwLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL25jdnMvc3JjL3N5cy9rZXJuL3Zm c19sb29rdXAuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS44MC4yLjMKZGlmZiAtdSAtYiAt cjEuODAuMi4zIHZmc19sb29rdXAuYwotLS0gc3JjL3N5cy9rZXJuL3Zmc19sb29rdXAuYwky OSBTZXAgMjAwNSAxODo1MzoxMCAtMDAwMAkxLjgwLjIuMworKysgc3JjL3N5cy9rZXJuL3Zm c19sb29rdXAuYwkyMiBKYW4gMjAwNiAyMjo1OTo0MSAtMDAwMApAQCAtNjMsNiArNjMsMTAg QEAKICNkZWZpbmUJTkFNRUlfRElBR05PU1RJQyAxCiAjdW5kZWYgTkFNRUlfRElBR05PU1RJ QwogCitpbnQgdmFyc3ltX2VuYWJsZSA9IDA7CitTWVNDVExfSU5UKF92ZnMsIE9JRF9BVVRP LCB2YXJzeW1fZW5hYmxlLCBDVExGTEFHX1JXLCAmdmFyc3ltX2VuYWJsZSwgMCwKKyAgICAi RW5hYmxlIFZhcmlhbnQgU3ltbGlua3MiKTsKKwogLyoKICAqIEFsbG9jYXRpb24gem9uZSBm b3IgbmFtZWkKICAqLwpAQCAtMjYyLDYgKzI2Niw4IEBACiAJCQlicmVhazsKIAkJfQogCQls aW5rbGVuID0gTUFYUEFUSExFTiAtIGF1aW8udWlvX3Jlc2lkOworCQlpZiAodmFyc3ltX2Vu YWJsZSkKKwkJCWxpbmtsZW4gPSB2YXJzeW1yZXBsYWNlKGNwLCBsaW5rbGVuLCBNQVhQQVRI TEVOKTsKIAkJaWYgKGxpbmtsZW4gPT0gMCkgewogCQkJaWYgKG5kcC0+bmlfcGF0aGxlbiA+ IDEpCiAJCQkJdW1hX3pmcmVlKG5hbWVpX3pvbmUsIGNwKTsKSW5kZXg6IHNyYy9zeXMvc3lz L2phaWwuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvbmN2cy9zcmMvc3lzL3N5cy9qYWls LmgsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjYKZGlmZiAtdSAtYiAtcjEuMjYgamFpbC5o Ci0tLSBzcmMvc3lzL3N5cy9qYWlsLmgJOSBKdW4gMjAwNSAxODo0OToxOSAtMDAwMAkxLjI2 CisrKyBzcmMvc3lzL3N5cy9qYWlsLmgJMjIgSmFuIDIwMDYgMjI6NTk6NDIgLTAwMDAKQEAg LTYxLDYgKzYxLDcgQEAKICAqICAgKGQpIHNldCBvbmx5IGR1cmluZyBkZXN0cnVjdGlvbiBv ZiBqYWlsLCBubyBtdXRleCBuZWVkZWQKICAqLwogI2lmIGRlZmluZWQoX0tFUk5FTCkgfHwg ZGVmaW5lZChfV0FOVF9QUklTT04pCisjaW5jbHVkZSA8c3lzL3ZhcnN5bS5oPgogc3RydWN0 IHByaXNvbiB7CiAJTElTVF9FTlRSWShwcmlzb24pIHByX2xpc3Q7CQkJLyogKGEpIGFsbCBw cmlzb25zICovCiAJaW50CQkgcHJfaWQ7CQkJCS8qIChjKSBwcmlzb24gaWQgKi8KQEAgLTcy LDYgKzczLDcgQEAKIAl2b2lkCQkqcHJfbGludXg7CQkJLyogKHApIGxpbnV4IGFiaSAqLwog CWludAkJIHByX3NlY3VyZWxldmVsOwkJLyogKHApIHNlY3VyZWxldmVsICovCiAJc3RydWN0 IHRhc2sJIHByX3Rhc2s7CQkJLyogKGQpIGRlc3Ryb3kgdGFzayAqLworCXN0cnVjdCB2YXJz eW1zZXQgcHJfdmFyc3ltc2V0OwkJCS8qIChwKSBwcmlzb24gdmFyc3ltcyAqLwogCXN0cnVj dCBtdHgJIHByX210eDsKIH07CiAjZW5kaWYgLyogX0tFUk5FTCB8fCBfV0FOVF9QUklTT04g Ki8KSW5kZXg6IHNyYy9zeXMvc3lzL25hbWVpLmgKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTog L25jdnMvc3JjL3N5cy9zeXMvbmFtZWkuaCx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS40Nwpk aWZmIC11IC1iIC1yMS40NyBuYW1laS5oCi0tLSBzcmMvc3lzL3N5cy9uYW1laS5oCTI3IEFw ciAyMDA1IDA5OjAwOjQ3IC0wMDAwCTEuNDcKKysrIHNyYy9zeXMvc3lzL25hbWVpLmgJMjIg SmFuIDIwMDYgMjI6NTk6NDIgLTAwMDAKQEAgLTE3NCw2ICsxNzQsOCBAQAogCiB2b2lkIE5E RlJFRShzdHJ1Y3QgbmFtZWlkYXRhICosIGNvbnN0IHVfaW50KTsKIAorZXh0ZXJuIGludCB2 YXJzeW1fZW5hYmxlOworCiBpbnQJbmFtZWkoc3RydWN0IG5hbWVpZGF0YSAqbmRwKTsKIGlu dAlsb29rdXAoc3RydWN0IG5hbWVpZGF0YSAqbmRwKTsKIGludAlyZWxvb2t1cChzdHJ1Y3Qg dm5vZGUgKmR2cCwgc3RydWN0IHZub2RlICoqdnBwLApJbmRleDogc3JjL3N5cy9zeXMvcHJv Yy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9uY3ZzL3NyYy9zeXMvc3lzL3Byb2MuaCx2 CnJldHJpZXZpbmcgcmV2aXNpb24gMS40MzIuMi4yCmRpZmYgLXUgLWIgLXIxLjQzMi4yLjIg cHJvYy5oCi0tLSBzcmMvc3lzL3N5cy9wcm9jLmgJNCBPY3QgMjAwNSAwNDo0MToyNiAtMDAw MAkxLjQzMi4yLjIKKysrIHNyYy9zeXMvc3lzL3Byb2MuaAkyMiBKYW4gMjAwNiAyMjo1OTo0 MiAtMDAwMApAQCAtNjAsNiArNjAsNyBAQAogI2VuZGlmCiAjaW5jbHVkZSA8c3lzL3Vjb250 ZXh0Lmg+CiAjaW5jbHVkZSA8c3lzL3VjcmVkLmg+CisjaW5jbHVkZSA8c3lzL3ZhcnN5bS5o PgogI2luY2x1ZGUgPG1hY2hpbmUvcHJvYy5oPgkJLyogTWFjaGluZS1kZXBlbmRlbnQgcHJv YyBzdWJzdHJ1Y3QuICovCiAKIC8qCkBAIC01MTIsNiArNTEzLDcgQEAKIAlMSVNUX0VOVFJZ KHByb2MpIHBfc2libGluZzsJLyogKGUpIExpc3Qgb2Ygc2libGluZyBwcm9jZXNzZXMuICov CiAJTElTVF9IRUFEKCwgcHJvYykgcF9jaGlsZHJlbjsJLyogKGUpIFBvaW50ZXIgdG8gbGlz dCBvZiBjaGlsZHJlbi4gKi8KIAlzdHJ1Y3QgbXR4CXBfbXR4OwkJLyogKG4pIExvY2sgZm9y IHRoaXMgc3RydWN0LiAqLworCXN0cnVjdCB2YXJzeW1zZXQgcF92YXJzeW1zZXQ7CS8qIChj KSBwcm9jZXNzIHZhcnN5bXNldCAqLwogCXN0cnVjdCBrc2lnaW5mbyAqcF9rc2k7CS8qIExv Y2tlZCBieSBwYXJlbnQgcHJvYyBsb2NrICovCiAJc2lncXVldWVfdAlwX3NpZ3F1ZXVlOwkv KiAoYykgU2lncyBub3QgZGVsaXZlcmVkIHRvIGEgdGQuICovCiAjZGVmaW5lIHBfc2lnbGlz dAlwX3NpZ3F1ZXVlLnNxX3NpZ25hbHMKSW5kZXg6IHNyYy9zeXMvc3lzL3Jlc291cmNldmFy LmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL25jdnMvc3JjL3N5cy9zeXMvcmVzb3VyY2V2 YXIuaCx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS40NwpkaWZmIC11IC1iIC1yMS40NyByZXNv dXJjZXZhci5oCi0tLSBzcmMvc3lzL3N5cy9yZXNvdXJjZXZhci5oCTcgSmFuIDIwMDUgMDI6 Mjk6MjMgLTAwMDAJMS40NworKysgc3JjL3N5cy9zeXMvcmVzb3VyY2V2YXIuaAkyMiBKYW4g MjAwNiAyMjo1OTo0MiAtMDAwMApAQCAtMzgsNiArMzgsNyBAQAogI2lmZGVmIF9LRVJORUwK ICNpbmNsdWRlIDxzeXMvX2xvY2suaD4KICNpbmNsdWRlIDxzeXMvX211dGV4Lmg+CisjaW5j bHVkZSA8c3lzL3ZhcnN5bS5oPgogI2VuZGlmCiAKIC8qCkBAIC05OSw2ICsxMDAsNyBAQAog CWxvbmcJdWlfcHJvY2NudDsJCS8qIChiKSBudW1iZXIgb2YgcHJvY2Vzc2VzICovCiAJdWlk X3QJdWlfdWlkOwkJCS8qIChhKSB1aWQgKi8KIAl1X2ludAl1aV9yZWY7CQkJLyogKGIpIHJl ZmVyZW5jZSBjb3VudCAqLworCXN0cnVjdCB2YXJzeW1zZXQgdWlfdmFyc3ltc2V0OwkvKiAo YikgcGVyLXVzZXIgdmFyc3ltcyAqLwogCXN0cnVjdCBtdHggKnVpX210eHA7CQkvKiBwcm90 ZWN0IGFsbCBjb3VudHMvbGltaXRzICovCiB9OwoKSW5kZXg6IHNyYy9iaW4vTWFrZWZpbGUK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQpSQ1MgZmlsZTogL25jdnMvc3JjL2Jpbi9NYWtlZmlsZSx2CnJldHJp ZXZpbmcgcmV2aXNpb24gMS4yNQpkaWZmIC11IC1iIC1yMS4yNSBNYWtlZmlsZQotLS0gc3Jj L2Jpbi9NYWtlZmlsZSAgICAyIE1hciAyMDA1IDExOjUzOjIxIC0wMDAwICAgICAgIDEuMjUK KysrIHNyYy9iaW4vTWFrZWZpbGUgICAgMjYgSmFuIDIwMDYgMjA6NDM6NTAgLTAwMDAKQEAg LTM1LDcgKzM1LDggQEAKCXNsZWVwIFwKCXN0dHkgXAoJc3luYyBcCi0JdGVzdAorCXRlc3Qg XAorCXZhcnN5bQoKIC5pZiAhZGVmaW5lZChOT19SQ01EUykKIF9yY3A9CXJjcAoKZGlmZiAt VTMgLU4gc3JjL3N5cy9zeXMvdmFyc3ltLmggc3JjL3N5cy9zeXMvdmFyc3ltLmgKLS0tIHNy Yy9zeXMvc3lzL3ZhcnN5bS5oCVdlZCBEZWMgMzEgMTk6MDA6MDAgMTk2OQorKysgc3JjL3N5 cy9zeXMvdmFyc3ltLmgJVGh1IEZlYiAxNiAwOTozMToxNCAyMDA2CkBAIC0wLDAgKzEsNTYg QEAKKy8qCisgKiBTWVMvVkFSU1lNLkgKKyAqCisgKglJbXBsZW1lbnRzIHN0cnVjdHVyZXMg dXNlZCBmb3IgdmFyaWFudCBzeW1saW5rIHN1cHBvcnQuCisgKiAKKyAqICRGcmVlQlNEJAor ICogJERyYWdvbkZseTogc3JjL3N5cy9zeXMvdmFyc3ltLmgsdiAxLjMgMjAwNS8wMS8xNCAw MjoyNTowOCBqb2VyZyBFeHAgJAorICovCisKKyNpZm5kZWYgX1NZU19WQVJTWU1fSF8KKyNk ZWZpbmUgX1NZU19WQVJTWU1fSF8KKyNpbmNsdWRlIDxzeXMvcXVldWUuaD4JCS8qIFRBSUxR XyogbWFjcm9zICovCisKK3N0cnVjdCB2YXJzeW0geworICAgIGludAkJdnNfcmVmczsJLyog YSBsb3Qgb2Ygc2hhcmluZyBvY2N1cnMgKi8KKyAgICBpbnQJCXZzX25hbWVsZW47CisgICAg Y2hhcgkqdnNfbmFtZTsJLyogdmFyaWFibGUgbmFtZSAqLworICAgIGNoYXIJKnZzX2RhdGE7 CS8qIHZhcmlhYmxlIGNvbnRlbnRzICovCit9OwordHlwZWRlZiBzdHJ1Y3QgdmFyc3ltCSp2 YXJzeW1fdDsKKworc3RydWN0IHZhcnN5bWVudCB7CisgICAgVEFJTFFfRU5UUlkodmFyc3lt ZW50KSB2ZV9lbnRyeTsKKyAgICB2YXJzeW1fdAl2ZV9zeW07Cit9OworCitzdHJ1Y3QgdmFy c3ltc2V0IHsKKyAgICBUQUlMUV9IRUFEKCwgdmFyc3ltZW50KSB2eF9xdWV1ZTsKKyAgICBp bnQJCXZ4X3NldHNpemU7Cit9OworCisjZGVmaW5lIFZBUlNZTV9QUk9DCTEKKyNkZWZpbmUg VkFSU1lNX1VTRVIJMgorI2RlZmluZSBWQVJTWU1fU1lTCTMKKyNkZWZpbmUgVkFSU1lNX1BS SVNPTgk0CS8qIHVzZWQgaW50ZXJuYWxseSAqLworI2RlZmluZSBWQVJTWU1fUFBST0MJNQkv KiBzZXQvZ2V0IHZhcnMgaW4gcGFyZW50IHByb2Nlc3MgKi8KKworI2RlZmluZSBWQVJTWU1f UFJPQ19NQVNLCSgxIDw8IFZBUlNZTV9QUk9DKQorI2RlZmluZSBWQVJTWU1fVVNFUl9NQVNL CSgxIDw8IFZBUlNZTV9VU0VSKQorI2RlZmluZSBWQVJTWU1fU1lTX01BU0sJCSgxIDw8IFZB UlNZTV9TWVMpCisjZGVmaW5lIFZBUlNZTV9QUFJPQ19NQVNLCSgxIDw8IFZBUlNZTV9QUFJP QykKKyNkZWZpbmUgVkFSU1lNX0FMTF9NQVNLCQkoVkFSU1lNX1BST0NfTUFTS3xWQVJTWU1f VVNFUl9NQVNLfFZBUlNZTV9TWVNfTUFTS3xWQVJTWU1fUFBST0NfTUFTSykKKworI2RlZmlu ZSBNQVhWQVJTWU1fTkFNRQk2NAorI2RlZmluZSBNQVhWQVJTWU1fREFUQQkyNTYKKyNkZWZp bmUgTUFYVkFSU1lNX1NFVAk4MTkyCisKKyNpZmRlZiBfS0VSTkVMCisKK3ZvaWQJdmFyc3lt c2V0X2luaXQoc3RydWN0IHZhcnN5bXNldCAqdmFyc3ltc2V0LCBzdHJ1Y3QgdmFyc3ltc2V0 ICpjb3B5KTsKK3ZvaWQJdmFyc3ltc2V0X2NsZWFuKHN0cnVjdCB2YXJzeW1zZXQgKnZhcnN5 bXNldCk7CitpbnQJdmFyc3ltcmVwbGFjZShjaGFyICpjcCwgaW50IGxpbmtsZW4sIGludCBt YXhsZW4pOworCisjZW5kaWYJLyogX0tFUk5FTCAqLworCisjZW5kaWYKZGlmZiAtVTMgLU4g c3JjL2Jpbi92YXJzeW0vTWFrZWZpbGUgc3JjL2Jpbi92YXJzeW0vTWFrZWZpbGUKLS0tIHNy Yy9iaW4vdmFyc3ltL01ha2VmaWxlCVdlZCBEZWMgMzEgMTk6MDA6MDAgMTk2OQorKysgc3Jj L2Jpbi92YXJzeW0vTWFrZWZpbGUJRnJpIEZlYiAgMyAxMzowNTo0NCAyMDA2CkBAIC0wLDAg KzEsNiBAQAorIyAkRnJlZUJTRCQKKyMgJERyYWdvbkZseTogc3JjL2Jpbi92YXJzeW0vTWFr ZWZpbGUsdiAxLjQgMjAwNS8wMi8wNiAwNjoxNjo0MCBva3Vtb3RvIEV4cCAkCisKK1BST0c9 CXZhcnN5bQorCisuaW5jbHVkZSA8YnNkLnByb2cubWs+CmRpZmYgLVUzIC1OIHNyYy9iaW4v dmFyc3ltL3ZhcnN5bS4xIHNyYy9iaW4vdmFyc3ltL3ZhcnN5bS4xCi0tLSBzcmMvYmluL3Zh cnN5bS92YXJzeW0uMQlXZWQgRGVjIDMxIDE5OjAwOjAwIDE5NjkKKysrIHNyYy9iaW4vdmFy c3ltL3ZhcnN5bS4xCUZyaSBGZWIgIDMgMTM6MTM6MTAgMjAwNgpAQCAtMCwwICsxLDEzMCBA QAorLlwiIENvcHlyaWdodCAoYykgMjAwMyBNYXR0aGV3IERpbGxvbiA8ZGlsbG9uQGJhY2tw bGFuZS5jb20+CisuXCIgQWxsIHJpZ2h0cyByZXNlcnZlZC4KKy5cIgorLlwiIE1vZGlmaWVk IGJ5IEFuZHJleSBWLiBFbHN1a292IDxidTdjaGVyQHlhbmRleC5ydT4KKy5cIgorLlwiIFJl ZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGgg b3Igd2l0aG91dAorLlwiIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0 aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworLlwiIGFyZSBtZXQ6CisuXCIgMS4gUmVk aXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5 cmlnaHQKKy5cIiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUg Zm9sbG93aW5nIGRpc2NsYWltZXIuCisuXCIgMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFy eSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKy5cIiAgICBub3Rp Y2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWlt ZXIgaW4gdGhlCisuXCIgICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxz IHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKy5cIgorLlwiIFRISVMgU09GVFdB UkUgSVMgUFJPVklERUQgQlkgVEhFIEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JTIGBgQVMgSVMn JyBBTkQKKy5cIiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElO RywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKy5cIiBJTVBMSUVEIFdBUlJBTlRJRVMgT0Yg TUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQor LlwiIEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhPUiBPUiBD T05UUklCVVRPUlMgQkUgTElBQkxFCisuXCIgRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJ TkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwKKy5cIiBE QU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0Yg U1VCU1RJVFVURSBHT09EUworLlwiIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwg T1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQorLlwiIEhPV0VWRVIgQ0FV U0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFD VCwgU1RSSUNUCisuXCIgTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5D RSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQorLlwiIE9VVCBPRiBUSEUgVVNF IE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkg T0YKKy5cIiBTVUNIIERBTUFHRS4KKy5cIgorLlwiICRGcmVlQlNEJAorLlwiICREcmFnb25G bHk6IHNyYy9iaW4vdmFyc3ltL3ZhcnN5bS4xLHYgMS40IDIwMDUvMDgvMDEgMDE6NDk6MTYg c3dpbGRuZXIgRXhwICQKKy5cIgorLkRkIE5vdiA1LCAyMDAzCisuRHQgVkFSU1lNIDEKKy5P cworLlNoIE5BTUUKKy5ObSB2YXJzeW0KKy5OZCBnZXQgYW5kIHNldCB1c2VyIGFuZCBzeXN0 ZW0td2lkZSB2YXJpYWJsZXMgZm9yIHZhcmlhbnQgc3ltbGlua3MKKy5TaCBTWU5PUFNJUwor Lk5tCisuT3AgRmwgQWFkUHBxc3YKKy5PcCBGbCBqIEFyIHByaXNvbl9pZAorLk9wIEZsIHUg QXIgdXNlcl9uYW1lIHwgdXNlcl9pZAorLkFyIHZhcls9ZGF0YV0KKy5TaCBERVNDUklQVElP TgorVGhlCisuTm0KK3Byb2dyYW0gbWFuYWdlcyB1c2VyIGFuZCBzeXN0ZW0td2lkZSB2YXJp YWJsZXMuICBUaGVzZSB2YXJpYWJsZXMgYXJlIHR5cGljYWxseQordXNlZCBieSB0aGUgc3lz dGVtIHRvIHJlc29sdmUgdmFyaWFudCBzeW1saW5rcyBidXQgbWF5IGFsc28gYmUgdXNlZCBn ZW5lcmFsbHkuCisuUHAKK0ZvciBlYWNoIG9wZXJhbmQgc2V0LCBtb2RpZnksIHJldHJpZXZl LCBvciBkZWxldGUgdGhlIHNwZWNpZmllZCB2YXJpYWJsZS4KK0J5IGRlZmF1bHQgdmFyaWFi bGVzIHNwZWNpZmllZCB3aXRob3V0IGRhdGEgYXJlIHJldHJpZXZlZCBhbmQgdmFyaWFibGVz CitzcGVjaWZpZWQgd2l0aCBkYXRhIGFyZSBzZXQuICBWYXJpYWJsZXMgbWF5IGJlIHNldCB0 byBlbXB0eS4KKy5CbCAtdGFnIC13aWR0aCBBcgorLkl0IEZsIGEKK0xpc3QgYWxsIHZhcmlh YmxlcyBhdCB0aGUgc3BlY2lmaWVkIGxldmVsLiAgTm90ZSB0aGF0IHBlci11c2VyIHZhcmlh Ymxlcworb3ZlcnJpZGUgc3lzdGVtLXdpZGUgdmFyaWFibGVzLiAgQnkgZGVmYXVsdCwgcGVy LXVzZXIgdmFyaWFibGVzIGFyZSBsaXN0ZWQuIAorSW4gdGhlIGphaWwgb25seSBzeXN0ZW0t d2lkZSB2YXJpYWJsZXMgYXJlIGxpc3RlZC4KKy5JdCBGbCBBCitMaXN0IGFsbCB2YXJpYWJs ZXMgYXQgYWxsIGxldmVscyBpbiB0aGUgb3JkZXIgdGhleSB3b3VsZCBiZSBmb3VuZC4gVGhl CisuRmwgdgorb3B0aW9uIHdpbGwgc2hvdyB0aGUgbGV2ZWwgZnJvbSB3aGljaCBlYWNoIHZh cmlhYmxlIGNhbWUgdXNpbmcgdGhlCitQLCBwLCBzIG9yIHUgcHJlZml4IGNoYXJhY3RlcnMu CisuSXQgRmwgZAorRGVsZXRlIG1vZGUuICBUaGUgc3BlY2lmaWVkIHZhcmlhYmxlcyBhcmUg ZGVsZXRlZC4gIEFueSBzcGVjaWZpZWQgZGF0YSBpcworaWdub3JlZC4KKy5JdCBGbCBqIEFy IHByaXNvbl9pZAorVGhpcyBvcHRpb24gY2F1c2VzIHZhcmlhYmxlcyB0byBiZSBzZXQgc3lz dGV0bS13aWRlIGFuZCByZXN0cmljdHMgcmV0cmlldmFscwordG8gc3lzdGVtLXNwZWNpZmlj IHZhcmlhYmxlcyBmb3IgamFpbGVkIGVudmlyb25tZW50IHdpdGggaWQgCisuQ20gcHJpc29u X2lkIE5zIC4KK05vdGUgdGhhdCAKKy5GbCBqCitvcHRpb24gaXMgbXV0dWFsbHkgZXhjbHVz aXZlIHdpdGgKKy5GbCB1CitvcHRpb24uCisuSXQgRmwgcAorVGhpcyBvcHRpb24gY2F1c2Vz IHZhcmlhYmxlcyB0byBiZSBzZXQgb24gYSBwZXItcHJvY2VzcyBiYXNpcyBhbmQgcmVzdHJp Y3RzCityZXRyaWV2YWxzIHRvIHByb2Nlc3Mtc3BlY2lmaWMgdmFyaWFibGVzLiAgTm90ZSB0 aGF0IHNpbmNlCisuTm0KK2lzIHJ1biBhcyBpdHMgb3duIHByb2Nlc3MsIHVzaW5nIHRoaXMg b3B0aW9uIHRvIHNldCBhIHZhcmlhYmxlIHdpbGwgbm90CithZmZlY3QgeW91ciBzaGVsbCdz IG5hbWVzcGFjZS4KKy5JdCBGbCBQCitUaGlzIG9wdGlvbiBjYXVzZXMgdmFyaWFibGVzIHRv IGJlIHNldCBpbiB0aGUgcGFyZW50IHByb2Nlc3MgKGkuZS4gc2hlbGwpCisuSXQgRmwgcQor UXVpZXQgbW9kZS4gIFdoZW4gcmV0cmlldmluZyBhIHZhcmlhYmxlIG9ubHkgaXRzIGRhdGEg aXMgcHJpbnRlZC4KKy5JdCBGbCBzCitUaGlzIG9wdGlvbiBjYXVzZXMgdmFyaWFibGVzIHRv IGJlIHNldCBzeXN0ZW0td2lkZSBhbmQgcmVzdHJpY3RzIHJldHJpZXZhbHMKK3RvIHN5c3Rl bS1zcGVjaWZpYyB2YXJpYWJsZXMuIEVhY2ggamFpbCBoYXZlIG93biBgYGxvY2FsJycgc3lz dGVtLXdpZGUgCit2YXJpYWJsZXMuCisuSXQgRmwgdSBBciB1c2VyX25hbWUgfCB1c2VyX2lk CitUaGlzIG9wdGlvbiBjYXVzZXMgdmFyaWFibGVzIHRvIGJlIHNldCBvbiBhIHBlci11c2Vy LWlkIGJhc2lzIGFuZCByZXN0cmljdHMKK3JldHJpZXZhbHMgdG8gdXNlci1zcGVjaWZpYyB2 YXJpYWJsZXMgZm9yIHVzZXIgc3BlY2lmaWVkIGFzCisuQ20gdXNlcl9uYW1lIE5zIAorIG9y CisuQ20gdXNlcl9pZCBOcyAuICBVbnByaXZpbGVnZWQgdXNlciBjYW4gc2V0IG9yIHJlYWQg b25seSBvd24gdmFyaWFibGVzLCBhbmQKK2Nhbid0IHVzZSB0aGlzIG9wdGlvbi4gCisuRWwK Ky5TaCBSRVRVUk4gVkFMVUVTCitUaGUKKy5ObQordXRpbGl0eSBleGl0cyB3aXRoIG9uZSBv ZiB0aGUgZm9sbG93aW5nIHZhbHVlczoKKy5CbCAtdGFnIC13aWR0aCBEcworLkl0IDAKK05v IGVycm9ycyBvY2N1cmVkLgorLkl0IDEKK0EgcmVxdWVzdGVkIHZhcmlhYmxlIGNvdWxkIG5v dCBiZSBmb3VuZAorLkl0IDIKK0EgcmVxdWVzdGVkIHZhcmlhYmxlIGNvdWxkIG5vdCBiZSBz ZXQKKy5FbAorLlNoIEVYQU1QTEVTCisuUHAKK0NyZWF0ZSBhIHBhcmVudCB2YXJpYWJsZSBm dWJhci4gVGhpcyB2YXJpYWJsZSB3aWxsIHRoZW4gYmUgaW5oZXJpdGVkIGJ5IAorYW55IGZ1 dHVyZSBleGVjdXRpb25zIGluIHRoaXMgc2hlbGwuCisuUHAKKy5EMSBMaSAidmFyc3ltIC1Q IGZ1YmFyPXh4IgorLlBwCitDcmVhdGUgYSB1c2VyIHZhcmlhYmxlIGZ1YmFyLgorLlBwCisu RDEgTGkgInZhcnN5bSBmdWJhcj14eCIKKy5QcAorTGlzdCBhbGwgdXNlciB2YXJpYWJsZXMg ZGVmaW5lZAorLlBwCisuRDEgTGkgInZhcnN5bSAtYSIKKy5QcAorTGlzdCBhbGwgdmFyaWFi bGVzIGRlZmluZWQgYW55d2hlcmUKKy5QcAorLkQxIExpICJ2YXJzeW0gLUEiCisuUHAKK0xp c3QgdW5pcXVlIHZhcmlhYmxlcyBkZWZpbmVkCisuUHAKKy5EMSBMaSAidmFyc3ltIC1BfHNv cnQgLXUgLXQ9IC1rMSwxIgorLlNoIFNFRSBBTFNPCisuWHIgbG4gMSAsCmRpZmYgLVUzIC1O IHNyYy9iaW4vdmFyc3ltL3ZhcnN5bS5jIHNyYy9iaW4vdmFyc3ltL3ZhcnN5bS5jCi0tLSBz cmMvYmluL3ZhcnN5bS92YXJzeW0uYwlXZWQgRGVjIDMxIDE5OjAwOjAwIDE5NjkKKysrIHNy Yy9iaW4vdmFyc3ltL3ZhcnN5bS5jCUZyaSBGZWIgIDMgMTM6MDU6NDQgMjAwNgpAQCAtMCww ICsxLDI2MSBAQAorLyoKKyAqIENvcHlyaWdodCAoYykgMjAwMyBNYXR0aGV3IERpbGxvbiA8 ZGlsbG9uQGJhY2twbGFuZS5jb20+CisgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAq IE1vZGlmaWVkIGJ5IEFuZHJleSBWLiBFbHN1a292IDxidTdjaGVyQHlhbmRleC5ydT4KKyAq CisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1z LCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92 aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICogYXJlIG1ldDoKKyAqIDEu IFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUg Y29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0 aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmlu YXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90 aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFp bWVyIGluIHRoZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxz IHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJF IElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycg QU5ECisgKiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywg QlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJD SEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBB UkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJ QlVUT1JTIEJFIExJQUJMRQorICogRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVO VEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwKKyAqIERBTUFHRVMg KElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElU VVRFIEdPT0RTCisgKiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJ VFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKKyAqIEhPV0VWRVIgQ0FVU0VEIEFORCBP TiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNU CisgKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVS V0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNP RlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCisgKiBTVUNI IERBTUFHRS4KKyAqCisgKiAkRnJlZUJTRCQKKyAqICREcmFnb25GbHk6IHNyYy9iaW4vdmFy c3ltL3ZhcnN5bS5jLHYgMS40IDIwMDMvMTIvMTEgMjA6MzM6NDkgZGlsbG9uIEV4cCAkCisg Ki8KKworI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9qYWlsLmg+Cisj aW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5jbHVkZSA8c3lzL3N5c2N0bC5oPgorI2luY2x1 ZGUgPHN5cy92YXJzeW0uaD4KKyNpbmNsdWRlIDxzdGRpby5oPgorI2luY2x1ZGUgPHN0ZGxp Yi5oPgorI2luY2x1ZGUgPHN0cmluZy5oPgorI2luY2x1ZGUgPGVyci5oPgorI2luY2x1ZGUg PHVuaXN0ZC5oPgorI2luY2x1ZGUgPHB3ZC5oPgorCitzdGF0aWMgdm9pZAl1c2FnZSh2b2lk KTsKK3N0YXRpYyB2b2lkCWR1bXB2YXJzKGNoYXIgKmJ1ZiwgaW50IGJ5dGVzLCBjb25zdCBj aGFyICpwcmVmaXgpOworc3RhdGljIGludAlsaXN0dmFycyhpbnQgbGV2ZWwsIGNvbnN0IGNo YXIgKnByZWZpeCk7CitzdGF0aWMgaW50CWphaWxlZCh2b2lkKTsKKworaW50IGlzX3Jvb3Qg PSAwOworaW50IGlzX2phaWwgPSAwOworCitpbnQKK21haW4oaW50IGFjLCBjaGFyICoqYXYp Cit7CisJaW50IGksIGVycm9yOworCXNpemVfdCBzaXplOworCWNvbnN0IGNoYXIqIG9wczsK KwlpbnQgbWFzayA9ICBWQVJTWU1fQUxMX01BU0s7CisJaW50IGxldmVsID0gVkFSU1lNX1VT RVI7CisJaW50IGRlbGV0ZU9wdCA9IDA7CisJaW50IHZlcmJvc2VPcHQgPSAwOworCWludCBh bGxPcHQgPSAwOworCWludCBqaWQgPSAwOworCisJaXNfcm9vdCA9IChnZXR1aWQoKSA9PSAw KTsKKwlpc19qYWlsID0gamFpbGVkKCk7CisKKwlpZiAoaXNfamFpbCkgeworCQkvKiAKKwkJ ICogcGVyLXVzZXIgdmFyc3ltcyBub3QgYWxsb3dlZCBpbiBqYWlsCisJCSAqIFNvIHdlIHJl bW92ZSBmcm9tIG1hc2sgVkFSU1lNX1VTRVJfTUFTSworCQkgKiBhbmQgc2V0IFZBUlNZTV9T WVMgbGV2ZWwgYXMgZGVmYXVsdC4KKwkJICovCisJCW1hc2sgJj0gflZBUlNZTV9VU0VSX01B U0s7CisJCWxldmVsID0gVkFSU1lNX1NZUzsKKwl9CisJaWYgKGlzX2phaWwgfHwgIWlzX3Jv b3QpCisJCW9wcyA9ICJBYWRoUHBxc3YiOworCWVsc2UKKwkJb3BzID0gIkFhZGhqOlBwcXN1 OnYiOworCXdoaWxlICgoaSA9IGdldG9wdChhYywgYXYsIG9wcykpICE9IC0xKSB7CisJCXN3 aXRjaCAoaSkgeworCQljYXNlICdhJzoKKwkJCWFsbE9wdCA9IDE7CisJCQlicmVhazsKKwkJ Y2FzZSAnQSc6CisJCQlhbGxPcHQgPSAyOworCQkJYnJlYWs7CisJCWNhc2UgJ2QnOgorCQkJ ZGVsZXRlT3B0ID0gMTsKKwkJCWJyZWFrOworCQljYXNlICdxJzoKKwkJCXZlcmJvc2VPcHQg PSAwOworCQkJYnJlYWs7CisJCWNhc2UgJ2onOgorCQkJamlkID0gKGludClzdHJ0b2wob3B0 YXJnLCBOVUxMLCAxMCk7CisJCQllcnJvciA9IGphaWxfYXR0YWNoKGppZCk7CisJCQlpZiAo ZXJyb3IpCisJCQkJZXJyKDIsICJqYWlsX2F0dGFjaCgpOiAlZCIsIGppZCk7CisJCWNhc2Ug J1AnOgorCQkJbGV2ZWwgPSBWQVJTWU1fUFBST0M7CisJCQltYXNrID0gVkFSU1lNX1BQUk9D X01BU0s7CisJCQlicmVhazsKKwkJY2FzZSAncCc6CisJCQlsZXZlbCA9IFZBUlNZTV9QUk9D OworCQkJbWFzayA9IFZBUlNZTV9QUk9DX01BU0s7CisJCQlicmVhazsKKwkJY2FzZSAncyc6 CisJCQltYXNrID0gVkFSU1lNX1NZU19NQVNLOworCQkJbGV2ZWwgPSBWQVJTWU1fU1lTOwor CQkJYnJlYWs7CisJCWNhc2UgJ3UnOiB7CisJCQkJdWlkX3QJdWlkOworCQkJCXN0cnVjdAlw YXNzd2QJKnB3OworCQkJCWlmIChqaWQpIHsKKwkJCQkJdXNhZ2UoKTsKKwkJCQkJcmV0dXJu KDEpOworCQkJCX0KKwkJCQlwdyA9IGdldHB3bmFtKG9wdGFyZyk7CisJCQkJaWYgKHB3ID09 IE5VTEwpCisJCQkJCXVpZCA9ICh1aWRfdClzdHJ0b2wob3B0YXJnLCBOVUxMLCAxMCk7CisJ CQkJZWxzZQorCQkJCQl1aWQgPSBwdy0+cHdfdWlkOworCQkJCWVycm9yID0gc2V0dWlkKHVp ZCk7CisJCQkJaWYgKGVycm9yKQorCQkJCQllcnIoMSwgInNldHVpZCgpIik7CisJCQkJbWFz ayA9IFZBUlNZTV9VU0VSX01BU0s7CisJCQkJbGV2ZWwgPSBWQVJTWU1fVVNFUjsKKwkJCX0K KwkJCWJyZWFrOworCQljYXNlICd2JzoKKwkJCXZlcmJvc2VPcHQgPSAxOworCQkJYnJlYWs7 CisJCWNhc2UgJ2gnOgorCQlkZWZhdWx0OgorCQkJdXNhZ2UoKTsKKwkJCXJldHVybigxKTsK KwkJfQorCX0KKwlhYyAtPSBvcHRpbmQ7CisJYXYgKz0gb3B0aW5kOworCisJaWYgKGFsbE9w dCkgeworCQlpZiAoYWxsT3B0ID4gMSkgeworCQkJLyogcHJvY2VzcyB2YXJpYWJsZXMgaW4g b3JkZXIgdGhleSBhcmUgc2VhcmNoZWQgKi8KKwkJCWVycm9yID0gbGlzdHZhcnMoVkFSU1lN X1BST0MsIHZlcmJvc2VPcHQ/InAiOiIiKTsKKwkJCWVycm9yID0gbGlzdHZhcnMoVkFSU1lN X1BQUk9DLCB2ZXJib3NlT3B0PyJQIjoiIik7CisJCQllcnJvciA9IGxpc3R2YXJzKFZBUlNZ TV9VU0VSLCB2ZXJib3NlT3B0PyJ1IjoiIik7CisJCQllcnJvciA9IGxpc3R2YXJzKFZBUlNZ TV9TWVMsIHZlcmJvc2VPcHQ/InMiOiIiKTsKKwkJfQorCQllbHNlIHsKKwkJCWVycm9yID0g bGlzdHZhcnMobGV2ZWwsICIiKTsKKwkJfQorCQlpZiAoZXJyb3IgPCAwKQorCQkJd2Fybigi dmFyc3ltX2xpc3QoKSIpOworCX0gZWxzZSBpZiAoYWMgPT0gMCkgeworCQl1c2FnZSgpOwor CQlyZXR1cm4oMSk7CisJfQorCisJd2hpbGUgKGFjID4gMCkgeworCQljaGFyICpuYW1lID0g YXZbMF07CisJCWNoYXIgKmRhdGEgPSBzdHJjaHIobmFtZSwgJz0nKTsKKwkJY2hhciBidWZb TUFYVkFSU1lNX0RBVEFdOworCisJCWlmIChkYXRhKQorCQkJKmRhdGErKyA9IDA7CisKKwkJ aWYgKGRlbGV0ZU9wdCkgeworCQkJZXJyb3IgPSB2YXJzeW1fc2V0KGxldmVsLCBuYW1lLCBO VUxMKTsKKwkJfQorCQllbHNlIGlmIChkYXRhKSB7CisJCQllcnJvciA9IHZhcnN5bV9zZXQo bGV2ZWwsIG5hbWUsIGRhdGEpOworCQl9CisJCWVsc2UgeworCQkJc2l6ZSA9IHNpemVvZihi dWYpOworCQkJZXJyb3IgPSB2YXJzeW1fZ2V0KG1hc2ssIG5hbWUsIGJ1ZiwgKGludCAqKSZz aXplKTsKKwkJCWlmIChlcnJvciA9PSAwICYmIHNpemUgPD0gKGludClzaXplb2YoYnVmKSkg eworCQkJCWlmICh2ZXJib3NlT3B0KQorCQkJCQlwcmludGYoIiVzPSIsIG5hbWUpOworCQkJ CXByaW50ZigiJXNcbiIsIGJ1Zik7CisJCQl9CisJCX0KKwkJaWYgKGVycm9yICE9IDAgJiYg dmVyYm9zZU9wdCkKKwkJCXdhcm4oIiVzIiwgbmFtZSk7CisJCWF2Kys7IGFjLS07CisJfQor CisJcmV0dXJuKDApOworfQorCitzdGF0aWMgdm9pZAorZHVtcHZhcnMoY2hhciAqYnVmLCBp bnQgYnl0ZXMsIGNvbnN0IGNoYXIgKnByZWZpeCkKK3sKKyAgICBpbnQgYjsKKyAgICBpbnQg aTsKKyAgICBjaGFyICp2bmFtZSA9IE5VTEw7CisgICAgY2hhciAqdmRhdGEgPSBOVUxMOwor CisgICAgZm9yIChiID0gaSA9IDA7IGkgPCBieXRlczsgKytpKSB7CisJaWYgKGJ1ZltpXSA9 PSAwKSB7CisJICAgIGlmICh2bmFtZSA9PSBOVUxMKSB7CisJCQl2bmFtZSA9IGJ1ZiArIGI7 CisJICAgIH0gZWxzZSB7CisJCQl2ZGF0YSA9IGJ1ZiArIGI7CisJCQlpZiAocHJlZml4ICYm ICpwcmVmaXgpCisJCQkJcHJpbnRmKCIlczolcz0lc1xuIiwgcHJlZml4LCB2bmFtZSwgdmRh dGEpOworCQkJZWxzZQorCQkJCXByaW50ZigiJXM9JXNcbiIsIHZuYW1lLCB2ZGF0YSk7CisJ CQl2bmFtZSA9IHZkYXRhID0gTlVMTDsKKwkgICAgfQorCSAgICBiID0gaSArIDE7CisJfQor ICAgIH0KK30KKworc3RhdGljIGludAorbGlzdHZhcnMoaW50IGxldmVsLCBjb25zdCBjaGFy ICpwcmVmaXgpCit7CisgICAgaW50IG1hcmtlciA9IDA7CisgICAgY2hhciBidWZbMTAyNF07 CisgICAgaW50IHNpemUgPSBzaXplb2YoYnVmKTsKKyAgICBpbnQgZXJyb3I9MDsKKworICAg IGZvciAoOzspIHsKKwlzaXplID0gc2l6ZW9mKGJ1Zik7CQorCWVycm9yID0gdmFyc3ltX2xp c3QobGV2ZWwsIGJ1ZiwgKGludCAqKSZzaXplLAorCQkmbWFya2VyKTsKKwlpZiAoZXJyb3Ig PCAwKQkJLyogZXJyb3Igb2NjdXJlZCAqLworCQlicmVhazsKKwlkdW1wdmFycyhidWYsIHNp emUsIHByZWZpeCk7CisJaWYgKG1hcmtlciA8IDApCQkvKiBubyBtb3JlIHZhcnMgKi8KKwkJ YnJlYWs7CisgICAgfQorICAgIHJldHVybihlcnJvcik7Cit9CisKK3N0YXRpYyB2b2lkCit1 c2FnZSh2b2lkKQoreworCWNvbnN0IGNoYXIgKnN0cjsKKwlpZiAoaXNfamFpbCB8fCAhaXNf cm9vdCkKKwkJc3RyID0gIlVzYWdlOiB2YXJzeW06IFstYUFwUHFkc10gdmFyWz1kYXRhXVxu IjsKKwllbHNlCisJCXN0ciA9ICJVc2FnZTogdmFyc3ltOiBbLWFBcFBxZHNdIFstdSB1c2Vy X2lkIHwgdXNlcl9uYW1lXVxuIiAKKwkJCSAgIiAgICAgICBbLWogcHJpc29uX2lkXSB2YXJb PWRhdGFdXG4iCisJCQkgICJOb3RlOiAtaiBhbmQgLXUgb3B0aW9ucyBpcyBtdXR1YWxseSBl eGNsdXNpdmVcbiI7CQorCWZwcmludGYoc3RkZXJyLCBzdHIpOworfQorCitzdGF0aWMgaW50 CQoramFpbGVkKHZvaWQpCit7CisJaW50CWosIGVycm9yOworCXNpemVfdCBzaXplID0gc2l6 ZW9mKGopOworCWVycm9yID0gc3lzY3RsYnluYW1lKCJzZWN1cml0eS5qYWlsLmphaWxlZCIs IAorCQkJCQkmaiwgJnNpemUsIE5VTEwsIDApOworCWlmIChlcnJvcikKKwkJZXJyKDIsICJz eXNjdGxieW5hbWUoKSIpOworCXJldHVybihqKTsKK30KZGlmZiAtVTMgc3JjL2V0Yy9kZWZh dWx0cy9yYy5jb25mIHNyYy9ldGMvZGVmYXVsdHMvcmMuY29uZgotLS0gc3JjL2V0Yy9kZWZh dWx0cy9yYy5jb25mCVN1biBPY3QgMTUgMTQ6MjI6MTcgMjAwNgorKysgc3JjL2V0Yy9kZWZh dWx0cy9yYy5jb25mCVRodSBBdWcgMzAgMTg6NTk6MDMgMjAwNwpAQCAtNTU5LDYgKzU1OSw4 IEBACiBuZXdzeXNsb2dfZW5hYmxlPSJZRVMiCSMgUnVuIG5ld3N5c2xvZyBhdCBzdGFydHVw LgogbmV3c3lzbG9nX2ZsYWdzPSItQ04iCSMgTmV3c3lzbG9nIGZsYWdzIHRvIGNyZWF0ZSBt YXJrZWQgZmlsZXMKIAordmFyc3ltX2VuYWJsZT0iTk8iICAgICAgIyB2YXJpYW50IHN5bWxp bmtzIGlzIGRpc2FibGVkIGJ5IGRlZmF1bHQKKwogIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKICMjIyBKYWlsIENvbmZp Z3VyYXRpb24gIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCiAjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIwpkaWZmIC1VMyAtTiBzcmMvZXRjL3JjLmQvdmFyc3ltIHNyYy9ldGMvcmMuZC92YXJz eW0KLS0tIHNyYy9ldGMvcmMuZC92YXJzeW0JV2VkIERlYyAzMSAxOTowMDowMCAxOTY5Cisr KyBzcmMvZXRjL3JjLmQvdmFyc3ltCVRodSBBdWcgMzAgMTg6NTk6MDMgMjAwNwpAQCAtMCww ICsxLDMzIEBACisjIS9iaW4vc2gKKyMKKworIyBQUk9WSURFOiB2YXJzeW0KKworLiAvZXRj L3JjLnN1YnIKKworbmFtZT0idmFyc3ltIgorcmN2YXI9YHNldF9yY3ZhcmAKK29pZD0idmZz LnZhcnN5bV9lbmFibGUiCisKK3N0YXJ0X2NtZD0iL3NiaW4vc3lzY3RsICRvaWQ9MSIKK3N0 b3BfY21kPSIvc2Jpbi9zeXNjdGwgJG9pZD0wIgorCisjCisjIGhhbmRsZSBzdGF0dXMgaGVy ZSBzaW5jZSByYy5zdWJyIGRvZXNuJ3QgYWxsb3cgaXQKKyMKK2Nhc2UgJDEgaW4KK3N0YXR1 cykKKyAgIGNhc2UgYC9zYmluL3N5c2N0bCAtbiAkb2lkYCBpbgorICAgMSkKKyAgICAgIGVj aG8gJG5hbWUgaXMgZW5hYmxlZC4KKyAgICAgIHJldHVybiAwCisgICAgICA7OworICAgMCkK KyAgICAgIGVjaG8gJG5hbWUgaXMgZGlzYWJsZWQuCisgICBlc2FjCisgICByZXR1cm4gMQor ICAgOzsKK2VzYWMKKworbG9hZF9yY19jb25maWcgJG5hbWUKK3J1bl9yY19jb21tYW5kICIk MSIKZGlmZiAtVTMgLU4gc3JjL2V0Yy9yYy5kL01ha2VmaWxlIHNyYy9ldGMvcmMuZC9NYWtl ZmlsZQotLS0gc3JjL2V0Yy9yYy5kL01ha2VmaWxlCTIwMDgtMDQtMjQgMTc6MjY6MzMuMDAw MDAwMDAwICswMDAwCisrKyBzcmMvZXRjL3JjLmQvTWFrZWZpbGUJMjAwOC0wNC0yNCAxNzoy Njo0MS4wMDAwMDAwMDAgKzAwMDAKQEAgLTM2LDcgKzM2LDcgQEAKIAlzeXNjb25zIHN5c2N0 bCBzeXNsb2dkIFwKIAl0aW1lZCB0bXAgXAogCXVnaWRmdyBcCi0JdmFyIHZpcmVjb3ZlciBc CisJdmFyIHZhcnN5bSB2aXJlY292ZXIgXAogCXdhdGNoZG9nZCB3cGFfc3VwcGxpY2FudCBc CiAJeXBiaW5kIHlwcGFzc3dkZCB5cHNlcnYgXAogCXlwc2V0IHlwdXBkYXRlZCB5cHhmcmQg XApkaWZmIC1VMyAtTiBzcmMvbGliL2xpYmMvc3lzL1N5bWJvbC5tYXAub3JpZyBzcmMvbGli L2xpYmMvc3lzL1N5bWJvbC5tYXAKLS0tIHNyYy9saWIvbGliYy9zeXMvU3ltYm9sLm1hcC5v cmlnCTIwMDgtMDQtMjQgMTg6NDk6MTQuMDAwMDAwMDAwICswMDAwCisrKyBzcmMvbGliL2xp YmMvc3lzL1N5bWJvbC5tYXAJMjAwOC0wNC0yNCAxODo1MTo0Ni4wMDAwMDAwMDAgKzAwMDAK QEAgLTMyMiw2ICszMjIsOSBAQAogCXV0cmFjZTsKIAl1dWlkZ2VuOwogCXZhZHZpc2U7CisJ dmFyc3ltX3NldDsKKwl2YXJzeW1fZ2V0OworCXZhcnN5bV9saXN0OwogCXdhaXQ0OwogCXdy aXRlOwogCXdyaXRldjsKQEAgLTk1Niw2ICs5NTksMTIgQEAKIAlfX3N5c191dWlkZ2VuOwog CV92YWR2aXNlOwogCV9fc3lzX3ZhZHZpc2U7CisJX3ZhcnN5bV9zZXQ7CisJX19zeXNfdmFy c3ltX3NldDsKKwlfdmFyc3ltX2dldDsKKwlfX3N5c192YXJzeW1fZ2V0OworCV92YXJzeW1f bGlzdDsKKwlfX3N5c192YXJzeW1fbGlzdDsKIAlfd2FpdDQ7CiAJX19zeXNfd2FpdDQ7CiAJ X3dyaXRlOwo= --------------010404020304060805040407 Content-Type: application/octet-stream; name="Makefile" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Makefile" IyAkSWQ6IE1ha2VmaWxlLHYgMS4xIDIwMDgvMDMvMDEgMDI6MDk6MzUgc2FzZHJxIEV4cCAk CiMKIyAKCiMgYSBsaXN0IG9mIHBhdGNoIGZpbGVzIGZvciAvdXNyIHNvdXJjZSB0cmVlClBB VENIRVMgICE9IGVjaG8gKi5wYXRjaAoKIyB3ZXJlIHdlIG5lZWQgdG8gYmUgdG8gcnVuIHRo aXMKSU5TVERJUiA9IC91c3IKQ1VSRElSICE9IHB3ZAoKbGlzdDoKCUBlY2hvICJtYWtlIHBh dGNoIiAtIHRvIHBhdGNoIHNvdXJjZSBhbmQgdXBkYXRlIHN5c2N0bC5jb25mCgpwYXRjaDog IHBhdGNoZXMgc3lzZW50CgojIHVzZSB0aGUgLXAgb3B0aW9uIG9mIHBhdGNoIHRvIGNhdXNl IGFueSBuZXcgZGlyZWN0b3JpZXMgdG8gYmUgY3JlYXRlZApwYXRjaGVzOgoJQGNkICR7SU5T VERJUn07IGxpc3Q9IiR7UEFUQ0hFU30iOyBmb3IgcGF0Y2ggaW4gJCRsaXN0OyBkbyBcCgkg ICBmaWxlPSR7Q1VSRElSfS8kJHBhdGNoOyAgICAgICAgXAoJICAgaWYgdGVzdCAtZiAkJGZp bGU7IHRoZW4gICAgICAgIFwKCSAgICAgIC91c3IvYmluL3BhdGNoIC1wIDwgJCRmaWxlOyBc CgkgICBlbHNlIDo7IGZpOyAgICAgICAgICAgICAgICAgICAgXAoJZG9uZQoKc3lzZW50OgoJ Y2QgL3Vzci9zcmMvc3lzL2tlcm4gJiYgbWFrZSBzeXNlbnQKCWNkIC91c3Ivc3JjL3N5cy9j b21wYXQvZnJlZWJzZDMyICYmIG1ha2Ugc3lzZW50Cgo= --------------010404020304060805040407-- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 10:14:06 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A7D6106567B; Fri, 22 Aug 2008 10:14:06 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id C2B038FC46; Fri, 22 Aug 2008 10:14:05 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3202E7309C; Fri, 22 Aug 2008 12:16:39 +0200 (CEST) Date: Fri, 22 Aug 2008 12:16:39 +0200 From: Luigi Rizzo To: Ivan Voras Message-ID: <20080822101639.GA58256@onelab2.iet.unipi.it> References: <20080822090448.GB57441@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 10:14:06 -0000 On Fri, Aug 22, 2008 at 11:59:07AM +0200, Ivan Voras wrote: ... > >+ efficiency of symlink_magic() might be improved too: > > e.g. the function could do a quick check for the presence of @ and return > > without allocation/deallocation if not found; > > I think it's because the author wanted a single pass over the string (in > case of the "extended" @{...} syntax we can't just check if cp[0] == > '@'). The first few lines of the symlink_magic loop ("if (cp[i] != > '@')") effectively do what strchr() does. right, but doing the check upfront might save the uma_zalloc/zfree call in the common case. cheers luigi From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 10:16:29 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 310741065673 for ; Fri, 22 Aug 2008 10:16:29 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id E12388FC21 for ; Fri, 22 Aug 2008 10:16:28 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KWTgw-0004t7-SI for freebsd-arch@freebsd.org; Fri, 22 Aug 2008 10:16:26 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Aug 2008 10:16:26 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Aug 2008 10:16:26 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Fri, 22 Aug 2008 12:16:16 +0200 Lines: 15 Message-ID: References: <20080822090448.GB57441@onelab2.iet.unipi.it> <20080822101639.GA58256@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.16 (X11/20080724) In-Reply-To: <20080822101639.GA58256@onelab2.iet.unipi.it> Sender: news Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 10:16:29 -0000 Luigi Rizzo wrote: > On Fri, Aug 22, 2008 at 11:59:07AM +0200, Ivan Voras wrote: > ... >>> + efficiency of symlink_magic() might be improved too: >>> e.g. the function could do a quick check for the presence of @ and return >>> without allocation/deallocation if not found; >> I think it's because the author wanted a single pass over the string (in >> case of the "extended" @{...} syntax we can't just check if cp[0] == >> '@'). The first few lines of the symlink_magic loop ("if (cp[i] != >> '@')") effectively do what strchr() does. > > right, but doing the check upfront might save the uma_zalloc/zfree call > in the common case. Ok. The strings are so short that it's trivial to check them early. From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 10:24:58 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5745106566C for ; Fri, 22 Aug 2008 10:24:58 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 829688FC14 for ; Fri, 22 Aug 2008 10:24:58 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KWTp5-0005Hr-EJ for freebsd-arch@freebsd.org; Fri, 22 Aug 2008 10:24:51 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Aug 2008 10:24:51 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Aug 2008 10:24:51 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Fri, 22 Aug 2008 12:24:41 +0200 Lines: 30 Message-ID: References: <20080822090448.GB57441@onelab2.iet.unipi.it> <48AE89DC.9080408@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.16 (X11/20080724) In-Reply-To: <48AE89DC.9080408@yandex.ru> Sender: news Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 10:24:58 -0000 Andrey V. Elsukov wrote: > Luigi Rizzo wrote: >> interestingly simple. >> >> Question - is the process' ENV easily available in this part >> of the kernel, so one could in principle use environment variables >> as replacement strings ? > This was so long ago.. As i remember this patch is a quick port of > NetBSD's implementation and uses the same code. > > Also there was another implementation ported from DragonFlyBSD. > David Quattlebaum is working on varsyms implementation and he sent > fresh patch to me in this April. I attached patch. > And sorry, i am not working on this today.. This patch is huge. As far as I can tell DragonflyBSD has a whole framework dedicated to varsyms, spread across a fair part of the kernel and with at least one special userland utility. It allows the operator to define his own variables that can be used in the substitutions, and I don't see that it predefines "special" variables like "uid" and "hostname". It's not necessarily a bad solution but I consider it overkill. Anyway, the syntax of DFBSD's varsyms is similar but sufficiently different from NetBSD's magicsyms implementation that both can coexist. DFBSD uses ${var} and NetBSD uses @var or @{var} so there's no ambiguity between them. Unless a kernel developer is interested in working the DFBSD's implementation in, I'll push the NetBSD's variant. From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 11:27:06 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 997201065695; Fri, 22 Aug 2008 11:27:06 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 5B6C68FC28; Fri, 22 Aug 2008 11:27:06 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 2963F7308B; Fri, 22 Aug 2008 13:29:39 +0200 (CEST) Date: Fri, 22 Aug 2008 13:29:39 +0200 From: Luigi Rizzo To: Ivan Voras Message-ID: <20080822112939.GA58579@onelab2.iet.unipi.it> References: <20080822090448.GB57441@onelab2.iet.unipi.it> <48AE89DC.9080408@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 11:27:06 -0000 On Fri, Aug 22, 2008 at 12:24:41PM +0200, Ivan Voras wrote: > Andrey V. Elsukov wrote: ... > > >This was so long ago.. As i remember this patch is a quick port of > >NetBSD's implementation and uses the same code. > > > >Also there was another implementation ported from DragonFlyBSD. ... > This patch is huge. As far as I can tell DragonflyBSD has a whole > framework dedicated to varsyms, spread across a fair part of the kernel > and with at least one special userland utility. It allows the operator > to define his own variables that can be used in the substitutions, and I > don't see that it predefines "special" variables like "uid" and > "hostname". It's not necessarily a bad solution but I consider it overkill. > > Anyway, the syntax of DFBSD's varsyms is similar but sufficiently > different from NetBSD's magicsyms implementation that both can coexist. > DFBSD uses ${var} and NetBSD uses @var or @{var} so there's no > ambiguity between them. > > Unless a kernel developer is interested in working the DFBSD's > implementation in, I'll push the NetBSD's variant. i also believe the simple solution is much more interesting. However i believe a crucial issue (in terms of implementation) is to define exactly the behaviour in error or corner cases, namely: + what to do if we try to expand @{nonexistentkeyword} ? i suppose leave the string as-is is the right thing. + what to do if, as a result of the expansion, we exceed MAXPATHLEN ? here it is really unclear whether returning the original is ok, or there is a way to report some kind of error. Also what is the exact syntax for @var ? From the code it seems to be allowed only as the last component of a pathname i.e. /foo/@bar is valid /foo/@bar/ is not valid and this makes me wonder why one should support this syntax at all, rather than just using /foo/@{bar} which achieves the same thing, is legal in all contexts, has a lower chance of conflicting with existing pathnames and makes the code simpler! cheers luigi From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 12:35:29 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 460D3106566B; Fri, 22 Aug 2008 12:35:29 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by mx1.freebsd.org (Postfix) with ESMTP id E749A8FC1D; Fri, 22 Aug 2008 12:35:28 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.3.59]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6000JBS49211D0@mta-1.ms.rz.RWTH-Aachen.de>; Fri, 22 Aug 2008 14:05:26 +0200 (CEST) Received: from smarthost-1.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.89]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Fri, 22 Aug 2008 14:05:26 +0200 Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id m7MC5Qcc029413; Fri, 22 Aug 2008 14:05:26 +0200 (CEST) Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KWVOQ-00084w-Hn; Fri, 22 Aug 2008 14:05:26 +0200 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 3625B3F433; Fri, 22 Aug 2008 14:05:26 +0200 (CEST) Date: Fri, 22 Aug 2008 14:05:26 +0200 From: Christian Brueffer In-reply-to: To: Ivan Voras Message-id: <20080822120525.GA1366@haakonia.hitnet.RWTH-Aachen.DE> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=rwEMma7ioTxnRzrJ Content-disposition: inline X-IronPort-AV: E=Sophos;i="4.32,251,1217800800"; d="scan'208";a="52607504" X-Operating-System: FreeBSD 6.3-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <20080822090448.GB57441@onelab2.iet.unipi.it> <48AE89DC.9080408@yandex.ru> User-Agent: Mutt/1.5.11 Cc: brooks@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 12:35:29 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 22, 2008 at 12:24:41PM +0200, Ivan Voras wrote: > Andrey V. Elsukov wrote: > >Luigi Rizzo wrote: > >>interestingly simple. > >> > >>Question - is the process' ENV easily available in this part > >>of the kernel, so one could in principle use environment variables > >>as replacement strings ? >=20 > >This was so long ago.. As i remember this patch is a quick port of > >NetBSD's implementation and uses the same code. > > > >Also there was another implementation ported from DragonFlyBSD. > >David Quattlebaum is working on varsyms implementation and he sent > >fresh patch to me in this April. I attached patch. > >And sorry, i am not working on this today.. >=20 > This patch is huge. As far as I can tell DragonflyBSD has a whole=20 > framework dedicated to varsyms, spread across a fair part of the kernel= =20 > and with at least one special userland utility. It allows the operator=20 > to define his own variables that can be used in the substitutions, and I= =20 > don't see that it predefines "special" variables like "uid" and=20 > "hostname". It's not necessarily a bad solution but I consider it overkil= l. >=20 > Anyway, the syntax of DFBSD's varsyms is similar but sufficiently=20 > different from NetBSD's magicsyms implementation that both can coexist.= =20 > DFBSD uses ${var} and NetBSD uses @var or @{var} so there's no=20 > ambiguity between them. >=20 > Unless a kernel developer is interested in working the DFBSD's=20 > implementation in, I'll push the NetBSD's variant. >=20 > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >=20 Brooks has a varsym port in p4, see //depot/user/brooks/varsym/ - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFIrquFbHYXjKDtmC0RAnpFAJ0Se8HImQR98Ysp/ZwByDZxih1/IACg89s3 FxDpDeN6B2tFikg/JeedWbg= =aWFR -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 14:53:42 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95D8D1065672; Fri, 22 Aug 2008 14:53:42 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 38CC98FC1E; Fri, 22 Aug 2008 14:53:41 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 5072673098; Fri, 22 Aug 2008 16:56:16 +0200 (CEST) Date: Fri, 22 Aug 2008 16:56:16 +0200 From: Luigi Rizzo To: Christian Brueffer Message-ID: <20080822145616.GA61094@onelab2.iet.unipi.it> References: <20080822090448.GB57441@onelab2.iet.unipi.it> <48AE89DC.9080408@yandex.ru> <20080822120525.GA1366@haakonia.hitnet.RWTH-Aachen.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080822120525.GA1366@haakonia.hitnet.RWTH-Aachen.DE> User-Agent: Mutt/1.4.2.3i Cc: brooks@freebsd.org, Ivan Voras , freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 14:53:42 -0000 On Fri, Aug 22, 2008 at 02:05:26PM +0200, Christian Brueffer wrote: > On Fri, Aug 22, 2008 at 12:24:41PM +0200, Ivan Voras wrote: ... > > This patch is huge. As far as I can tell DragonflyBSD has a whole > > framework dedicated to varsyms, spread across a fair part of the kernel > > and with at least one special userland utility. It allows the operator > > to define his own variables that can be used in the substitutions, and I > > don't see that it predefines "special" variables like "uid" and > > "hostname". It's not necessarily a bad solution but I consider it overkill. ... > Brooks has a varsym port in p4, see //depot/user/brooks/varsym/ this also seems to be based on Dragonfly's code, quite intrusive. I am playing with a rewrite (attached below) of the original patch, which fixes at least one memory leak and addresses some of the issues that i mentioned in this thread (abuse of macros, performance, behaviour on errors, etc.). (i haven't looked up yet the original copyright but i guess it is from netbsd...) cheers luigi Index: src/sys/kern/vfs_lookup.c =================================================================== --- src/sys/kern/vfs_lookup.c (revision 181995) +++ src/sys/kern/vfs_lookup.c (working copy) @@ -46,6 +46,7 @@ #include #include #include +#include // XXX symlinks #include #include #include @@ -88,6 +89,123 @@ } SYSINIT(vfs, SI_SUB_VFS, SI_ORDER_SECOND, nameiinit, NULL); +#ifdef MAGICLINKS +static int vfs_magiclinks = 1; +#else +static int vfs_magiclinks = 1; +#endif +SYSCTL_INT(_vfs, OID_AUTO, magiclinks, CTLFLAG_RW, &vfs_magiclinks, 0, + "Whether \"magic\" symlinks are expanded"); + +/* looks up a string returns the match len or 0 */ +static int +s_match(const char *key, int keylen, const char *haystack, const char *end) +{ + if (haystack + keylen >= end || haystack[keylen] != '}') + return 0; + if (strncmp(key, haystack, keylen)) + return 0; + return keylen; +} +#define MATCH(str) s_match(str, sizeof(str) - 1, src, end) + +static char * +s_subst(char *dst, const char *max, const char *value, int len) +{ + if (value == dst) { /* already copied, locate end of string */ + while (*dst) + dst++; + return dst; + } + /* check size, copy and replace */ + if (dst + len > max) /* overflow */ + return NULL; + bcopy(value, dst, len); + dst += len; + return dst; +} + +/* + * Substitute replacement text for 'magic' strings in symlinks. + * Looks for "@{string}", where is a + * recognized 'magic' string. Replaces the original with the + * appropriate replacement text. (Note that in some cases the + * replacement text may have zero length.) + * Assume *len is at least 3. + */ +static void +symlink_magic(struct thread *td, char *cp, int *len) +{ + char *src, *dst, *tmp, *end = cp + *len, *max; + int change = 0; + + /* quick return if nothing to replace */ + for (src = cp; src < end - 1; src++) { + if (src[0] == '@' && src[1] == '{') + break; + } + if (src == end - 1) /* no replacement */ + return; + + /* allocate a buffer for the replacement */ + dst = tmp = uma_zalloc(namei_zone, M_WAITOK); + if (dst == NULL) { /* no space for replacement */ + printf("zalloc fail in %s\n", __FUNCTION__); + return; + } + max = dst + MAXPATHLEN - 1; + for (src = cp; src < end - 1 && dst < max - 1;) { + int l; + if (src[0] != '@' || src[1] != '{') { + *dst++ = *src++; /* copy current char */ + continue; + } + src += 2; /* skip @{ */ + +printf("replace magic at %s\n", src); + /* + * The following checks should be ordered according + * to frequency of use. + */ + if ( (l = MATCH("machine_arch")) ) { + dst = s_subst(dst, max, MACHINE_ARCH, sizeof(MACHINE_ARCH) - 1); + } else if ( (l= MATCH("machine")) ) { + dst = s_subst(dst, max, MACHINE_ARCH, sizeof(MACHINE_ARCH) - 1); + } else if ( (l= MATCH("hostname")) ) { + getcredhostname(td->td_ucred, dst, max - dst); + dst = s_subst(dst, max, dst, 0); + } else if ( (l= MATCH("osrelease")) ) { + dst = s_subst(dst, max, osrelease, strlen(osrelease)); + } else if ( (l= MATCH("kernel_ident")) ) { + dst = s_subst(dst, max, kern_ident, strlen(kern_ident)); + } else if ( (l= MATCH("domainname")) ) { + dst = s_subst(dst, max, domainname, strlen(domainname)); + } else if ( (l= MATCH("ostype")) ) { + dst = s_subst(dst, max, ostype, strlen(ostype)); + } + if (dst == NULL) /* overflow */ + break; + if (l == 0) { /* no match, restore original */ + *dst++ = '@'; + *dst++ = '{'; + continue; + } + /* otherwise skip original name and } */ + src += l + 1; + change = 1; + } + if (change && dst) { + if (src < end) /* copy last char */ + *dst++ = *src; + *dst = '\0'; + printf("translating into %s\n", tmp); + *len = dst - tmp; + bcopy(tmp, cp, *len); + } + uma_zfree(namei_zone, tmp); +} +#undef MATCH + #ifdef LOOKUP_SHARED static int lookup_shared = 1; #else @@ -284,6 +402,8 @@ error = ENOENT; break; } + if (vfs_magiclinks && linklen >3) /* at least @{} in the symlink */ + symlink_magic(td, cp, &linklen); if (linklen + ndp->ni_pathlen >= MAXPATHLEN) { if (ndp->ni_pathlen > 1) uma_zfree(namei_zone, cp); From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 14:59:44 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 117701065672; Fri, 22 Aug 2008 14:59:44 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 88E618FC34; Fri, 22 Aug 2008 14:59:43 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.2/8.14.2) with ESMTP id m7MF0LlH058447; Fri, 22 Aug 2008 10:00:21 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.2/8.14.2/Submit) id m7MF0LSk058446; Fri, 22 Aug 2008 10:00:21 -0500 (CDT) (envelope-from brooks) Date: Fri, 22 Aug 2008 10:00:21 -0500 From: Brooks Davis To: Ivan Voras Message-ID: <20080822150020.GA57443@lor.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 14:59:44 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 22, 2008 at 01:54:29AM +0200, Ivan Voras wrote: > I was reading about new things in NetBSD, and one thing caught my=20 > attention: per-user /tmp. See=20 > http://www.feyrer.de/NetBSD/bx/blosxom.cgi/nb_20080714_0251.html for=20 > example. >=20 > Google says that a discussion about magic symlinks happens every now and= =20 > then in FreeBSD but nothing really gets done. I found this implementation= =20 > which looks like it's for 7.0: >=20 > http://butcher.heavennet.ru/patches/kernel/magiclinks/ >=20 > As far as I understand the VFS (which isn't much...) this looks like an= =20 > trivial patch, and it's compatible with NetBSD. Since I'm interested in= =20 > this (specifically for the per-user /tmp and maybe similar gadgetry), I'd= =20 > like to nurse this patch into the tree, if there are no objections (of=20 > course, I'll bug anyone I can find who knows VFS to review it :) ). I have an implementation derived from Andrey's port of the DragonFly implementation which will be committed in the next month or two. We discussed it in detail at the dev summit and subject to a few more changes and cleanup, it's ready to go. It allows significantly more flexibility than the NetBSD approach while avoiding many of the pitfalls involved in variant symlinks. -- Brooks --jRHKVT23PllUwdXP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFIrtSEXY6L6fI4GtQRAhW/AKC9QsRNlTI7GOYRiNk1qj6dcfd/hwCffNK2 cxXon+HubEaMQQBnDu/fPxc= =Vnoi -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 15:06:52 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B88D1065679; Fri, 22 Aug 2008 15:06:52 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 05BE18FC2F; Fri, 22 Aug 2008 15:06:51 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.2/8.14.2) with ESMTP id m7MF7Tdg058578; Fri, 22 Aug 2008 10:07:29 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.2/8.14.2/Submit) id m7MF7TDS058577; Fri, 22 Aug 2008 10:07:29 -0500 (CDT) (envelope-from brooks) Date: Fri, 22 Aug 2008 10:07:29 -0500 From: Brooks Davis To: Luigi Rizzo Message-ID: <20080822150728.GB57443@lor.one-eyed-alien.net> References: <20080822090448.GB57441@onelab2.iet.unipi.it> <48AE89DC.9080408@yandex.ru> <20080822120525.GA1366@haakonia.hitnet.RWTH-Aachen.DE> <20080822145616.GA61094@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4SFOXa2GPu3tIq4H" Content-Disposition: inline In-Reply-To: <20080822145616.GA61094@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Ivan Voras , Christian Brueffer , freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 15:06:52 -0000 --4SFOXa2GPu3tIq4H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 22, 2008 at 04:56:16PM +0200, Luigi Rizzo wrote: > On Fri, Aug 22, 2008 at 02:05:26PM +0200, Christian Brueffer wrote: > > On Fri, Aug 22, 2008 at 12:24:41PM +0200, Ivan Voras wrote: > ... > > > This patch is huge. As far as I can tell DragonflyBSD has a whole=20 > > > framework dedicated to varsyms, spread across a fair part of the kern= el=20 > > > and with at least one special userland utility. It allows the operato= r=20 > > > to define his own variables that can be used in the substitutions, an= d I=20 > > > don't see that it predefines "special" variables like "uid" and=20 > > > "hostname". It's not necessarily a bad solution but I consider it ove= rkill. > ... > > Brooks has a varsym port in p4, see //depot/user/brooks/varsym/ >=20 > this also seems to be based on Dragonfly's code, quite intrusive. This code adds one global symbol, one function call in the vfs code, and two pointers to struct proc. For that we get a system which is significantly more flexible than the NetBSD code. While the simplicity of the NetBSD code is somewhat attractive, the fact that variables can not be defined renders it useless for my purposes which are providing partial file system virtulization for computing job/sessions where I need to key off of externally derived job IDs or job specific temporary paths. -- Brooks > I am playing with a rewrite (attached below) of the original patch, > which fixes at least one memory leak and addresses some of the > issues that i mentioned in this thread (abuse of macros, performance, > behaviour on errors, etc.). >=20 > (i haven't looked up yet the original copyright but i guess it > is from netbsd...) >=20 > cheers > luigi >=20 > Index: src/sys/kern/vfs_lookup.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- src/sys/kern/vfs_lookup.c (revision 181995) > +++ src/sys/kern/vfs_lookup.c (working copy) > @@ -46,6 +46,7 @@ > #include > #include > #include > +#include // XXX symlinks > #include > #include > #include > @@ -88,6 +89,123 @@ > } > SYSINIT(vfs, SI_SUB_VFS, SI_ORDER_SECOND, nameiinit, NULL); > =20 > +#ifdef MAGICLINKS > +static int vfs_magiclinks =3D 1; > +#else > +static int vfs_magiclinks =3D 1; > +#endif > +SYSCTL_INT(_vfs, OID_AUTO, magiclinks, CTLFLAG_RW, &vfs_magiclinks, 0, > + "Whether \"magic\" symlinks are expanded"); > + > +/* looks up a string returns the match len or 0 */ > +static int > +s_match(const char *key, int keylen, const char *haystack, const char *e= nd) > +{ > + if (haystack + keylen >=3D end || haystack[keylen] !=3D '}') > + return 0; > + if (strncmp(key, haystack, keylen)) > + return 0; > + return keylen; > +} > +#define MATCH(str) s_match(str, sizeof(str) - 1, src, end) > + > +static char * > +s_subst(char *dst, const char *max, const char *value, int len) > +{ > + if (value =3D=3D dst) { /* already copied, locate end of string */ > + while (*dst) > + dst++; > + return dst; > + } > + /* check size, copy and replace */ > + if (dst + len > max) /* overflow */ > + return NULL; > + bcopy(value, dst, len); > + dst +=3D len; > + return dst; > +} > + > +/* > + * Substitute replacement text for 'magic' strings in symlinks. > + * Looks for "@{string}", where is a > + * recognized 'magic' string. Replaces the original with the > + * appropriate replacement text. (Note that in some cases the > + * replacement text may have zero length.) > + * Assume *len is at least 3. > + */ > +static void > +symlink_magic(struct thread *td, char *cp, int *len) > +{ > + char *src, *dst, *tmp, *end =3D cp + *len, *max; > + int change =3D 0; > + > + /* quick return if nothing to replace */ > + for (src =3D cp; src < end - 1; src++) { > + if (src[0] =3D=3D '@' && src[1] =3D=3D '{') > + break; > + } > + if (src =3D=3D end - 1) /* no replacement */ > + return; > + > + /* allocate a buffer for the replacement */ > + dst =3D tmp =3D uma_zalloc(namei_zone, M_WAITOK); > + if (dst =3D=3D NULL) { /* no space for replacement */ > + printf("zalloc fail in %s\n", __FUNCTION__); > + return; > + } > + max =3D dst + MAXPATHLEN - 1; > + for (src =3D cp; src < end - 1 && dst < max - 1;) { > + int l; > + if (src[0] !=3D '@' || src[1] !=3D '{') { > + *dst++ =3D *src++; /* copy current char */ > + continue; > + } > + src +=3D 2; /* skip @{ */ > + > +printf("replace magic at %s\n", src); > + /* > + * The following checks should be ordered according > + * to frequency of use. > + */ > + if ( (l =3D MATCH("machine_arch")) ) { > + dst =3D s_subst(dst, max, MACHINE_ARCH, sizeof(MACHINE_ARCH) - 1); > + } else if ( (l=3D MATCH("machine")) ) { > + dst =3D s_subst(dst, max, MACHINE_ARCH, sizeof(MACHINE_ARCH) - 1); > + } else if ( (l=3D MATCH("hostname")) ) { > + getcredhostname(td->td_ucred, dst, max - dst); > + dst =3D s_subst(dst, max, dst, 0); > + } else if ( (l=3D MATCH("osrelease")) ) { > + dst =3D s_subst(dst, max, osrelease, strlen(osrelease)); > + } else if ( (l=3D MATCH("kernel_ident")) ) { > + dst =3D s_subst(dst, max, kern_ident, strlen(kern_ident)); > + } else if ( (l=3D MATCH("domainname")) ) { > + dst =3D s_subst(dst, max, domainname, strlen(domainname)); > + } else if ( (l=3D MATCH("ostype")) ) { > + dst =3D s_subst(dst, max, ostype, strlen(ostype)); > + } > + if (dst =3D=3D NULL) /* overflow */ > + break; > + if (l =3D=3D 0) { /* no match, restore original */ > + *dst++ =3D '@'; > + *dst++ =3D '{'; > + continue; > + } > + /* otherwise skip original name and } */ > + src +=3D l + 1; > + change =3D 1; > + } > + if (change && dst) { > + if (src < end) /* copy last char */ > + *dst++ =3D *src; > + *dst =3D '\0'; > + printf("translating into %s\n", tmp); > + *len =3D dst - tmp; > + bcopy(tmp, cp, *len); > + } > + uma_zfree(namei_zone, tmp); > +} > +#undef MATCH > + > #ifdef LOOKUP_SHARED > static int lookup_shared =3D 1; > #else > @@ -284,6 +402,8 @@ > error =3D ENOENT; > break; > } > + if (vfs_magiclinks && linklen >3) /* at least @{} in the symlink */ > + symlink_magic(td, cp, &linklen); > if (linklen + ndp->ni_pathlen >=3D MAXPATHLEN) { > if (ndp->ni_pathlen > 1) > uma_zfree(namei_zone, cp); > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >=20 --4SFOXa2GPu3tIq4H Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFIrtYwXY6L6fI4GtQRAq1GAJ94/aYauKaXMGLbgbdCgyDNskzHqQCaAtgx EQOySBn1LVkKImSSH0Pd318= =ez0s -----END PGP SIGNATURE----- --4SFOXa2GPu3tIq4H-- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 15:29:47 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08307106567E for ; Fri, 22 Aug 2008 15:29:47 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id CFB448FC16 for ; Fri, 22 Aug 2008 15:29:46 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so854175rvf.43 for ; Fri, 22 Aug 2008 08:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=Hf6g0S0fCu6z6/qyDEzklplD8Wy83XKs20yQd3/0z7o=; b=O8Mo6GtIiiDq/N8RDRwkP5k4dWUqr/lcdLw1IB0J8IlYn6VSQaMQ74NpypT3j5M0L3 Y3Z0nWRhHnaHPS/5vwXfaih27uCkqzOh+oG7rYXf9mCXe+vdSTBV5X92RTnvxy1SUY6d 740GMfK2j+PLtHXPggOgXc1/+5YJgi9MZp8Hg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Gy1P8aaQ90ytQggrS/Py2f1eouZXife8mRXwZNERhIYp/r+fIm1z65zG/8UyX2/cXt p8RnOFCVQBF5yu4ctgWMZ5eabMus8RM1tl/xY3dBb2n80AxLyalmr/U11YebGSCDx0GC CIH3x3JgydjaR2vzZhVMSO5T1OjwsliPmrCBw= Received: by 10.141.113.6 with SMTP id q6mr585774rvm.135.1219417351285; Fri, 22 Aug 2008 08:02:31 -0700 (PDT) Received: by 10.141.153.13 with HTTP; Fri, 22 Aug 2008 08:02:31 -0700 (PDT) Message-ID: <9bbcef730808220802pa84b597u457100a23b03a80c@mail.gmail.com> Date: Fri, 22 Aug 2008 17:02:31 +0200 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Brooks Davis" In-Reply-To: <20080822150020.GA57443@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080822150020.GA57443@lor.one-eyed-alien.net> X-Google-Sender-Auth: 9e2f17f926945b57 Cc: freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 15:29:47 -0000 2008/8/22 Brooks Davis : > I have an implementation derived from Andrey's port of the DragonFly > implementation which will be committed in the next month or two. We > discussed it in detail at the dev summit and subject to a few more > changes and cleanup, it's ready to go. It allows significantly more > flexibility than the NetBSD approach while avoiding many of the pitfalls > involved in variant symlinks. Does it also support special automatic variables like uid, hostname? From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 15:39:08 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B48A21065678; Fri, 22 Aug 2008 15:39:08 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 362EF8FC17; Fri, 22 Aug 2008 15:39:08 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.2/8.14.2) with ESMTP id m7MFdjJC058829; Fri, 22 Aug 2008 10:39:45 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.2/8.14.2/Submit) id m7MFdjej058828; Fri, 22 Aug 2008 10:39:45 -0500 (CDT) (envelope-from brooks) Date: Fri, 22 Aug 2008 10:39:45 -0500 From: Brooks Davis To: Ivan Voras Message-ID: <20080822153945.GC57443@lor.one-eyed-alien.net> References: <20080822150020.GA57443@lor.one-eyed-alien.net> <9bbcef730808220802pa84b597u457100a23b03a80c@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wxDdMuZNg1r63Hyj" Content-Disposition: inline In-Reply-To: <9bbcef730808220802pa84b597u457100a23b03a80c@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 15:39:08 -0000 --wxDdMuZNg1r63Hyj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 22, 2008 at 05:02:31PM +0200, Ivan Voras wrote: > 2008/8/22 Brooks Davis : >=20 > > I have an implementation derived from Andrey's port of the DragonFly > > implementation which will be committed in the next month or two. We > > discussed it in detail at the dev summit and subject to a few more > > changes and cleanup, it's ready to go. It allows significantly more > > flexibility than the NetBSD approach while avoiding many of the pitfalls > > involved in variant symlinks. >=20 > Does it also support special automatic variables like uid, hostname? No it does not. There are two reasons for this. First, it's basically pointless since you can set system wide variables for things like hostname and I have login_conf support to set things like uid or uname variables. Second, consider all the implications of @uid in the context of setuid binaries. This is hard to reason about and easy to get wrong. As a result, I feel a model where variables are set per process and follow fork is much less prone to error. -- Brooks --wxDdMuZNg1r63Hyj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFIrt3BXY6L6fI4GtQRAs4hAJ9MQ7S8swL8VxEGpKc5YEF87xaf4QCghK97 QGx4kS4JfZm1hqtOTlNLEYM= =hULY -----END PGP SIGNATURE----- --wxDdMuZNg1r63Hyj-- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 15:43:56 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93317106566C; Fri, 22 Aug 2008 15:43:56 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 503108FC1E; Fri, 22 Aug 2008 15:43:56 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 6EE9373098; Fri, 22 Aug 2008 17:46:31 +0200 (CEST) Date: Fri, 22 Aug 2008 17:46:31 +0200 From: Luigi Rizzo To: Brooks Davis Message-ID: <20080822154631.GA61495@onelab2.iet.unipi.it> References: <20080822090448.GB57441@onelab2.iet.unipi.it> <48AE89DC.9080408@yandex.ru> <20080822120525.GA1366@haakonia.hitnet.RWTH-Aachen.DE> <20080822145616.GA61094@onelab2.iet.unipi.it> <20080822150728.GB57443@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080822150728.GB57443@lor.one-eyed-alien.net> User-Agent: Mutt/1.4.2.3i Cc: Ivan Voras , Christian Brueffer , freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 15:43:56 -0000 On Fri, Aug 22, 2008 at 10:07:29AM -0500, Brooks Davis wrote: > On Fri, Aug 22, 2008 at 04:56:16PM +0200, Luigi Rizzo wrote: > > On Fri, Aug 22, 2008 at 02:05:26PM +0200, Christian Brueffer wrote: > > > On Fri, Aug 22, 2008 at 12:24:41PM +0200, Ivan Voras wrote: > > ... > > > > This patch is huge. As far as I can tell DragonflyBSD has a whole > > > > framework dedicated to varsyms, spread across a fair part of the kernel > > > > and with at least one special userland utility. It allows the operator > > > > to define his own variables that can be used in the substitutions, and I > > > > don't see that it predefines "special" variables like "uid" and > > > > "hostname". It's not necessarily a bad solution but I consider it overkill. > > ... > > > Brooks has a varsym port in p4, see //depot/user/brooks/varsym/ > > > > this also seems to be based on Dragonfly's code, quite intrusive. > > This code adds one global symbol, one function call in the vfs code, > and two pointers to struct proc. For that we get a system which is > significantly more flexible than the NetBSD code. > > While the simplicity of the NetBSD code is somewhat attractive, the > fact that variables can not be defined renders it useless for my > purposes which are providing partial file system virtulization for > computing job/sessions where I need to key off of externally derived job > IDs or job specific temporary paths. understood -- it's just that the difference in code size is impressive. Do you know how much of it is used to implement the "varsym" subsystem (user- or system-wide variables) and how much is the core name translation ? cheers luigi From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 15:50:50 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F249D106566C; Fri, 22 Aug 2008 15:50:49 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 85C368FC20; Fri, 22 Aug 2008 15:50:49 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.2/8.14.2) with ESMTP id m7MFpRJU058984; Fri, 22 Aug 2008 10:51:27 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.2/8.14.2/Submit) id m7MFpRJp058983; Fri, 22 Aug 2008 10:51:27 -0500 (CDT) (envelope-from brooks) Date: Fri, 22 Aug 2008 10:51:27 -0500 From: Brooks Davis To: Luigi Rizzo Message-ID: <20080822155126.GD57443@lor.one-eyed-alien.net> References: <20080822090448.GB57441@onelab2.iet.unipi.it> <48AE89DC.9080408@yandex.ru> <20080822120525.GA1366@haakonia.hitnet.RWTH-Aachen.DE> <20080822145616.GA61094@onelab2.iet.unipi.it> <20080822150728.GB57443@lor.one-eyed-alien.net> <20080822154631.GA61495@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q0rSlbzrZN6k9QnT" Content-Disposition: inline In-Reply-To: <20080822154631.GA61495@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Ivan Voras , Christian Brueffer , freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 15:50:50 -0000 --Q0rSlbzrZN6k9QnT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 22, 2008 at 05:46:31PM +0200, Luigi Rizzo wrote: > On Fri, Aug 22, 2008 at 10:07:29AM -0500, Brooks Davis wrote: > > On Fri, Aug 22, 2008 at 04:56:16PM +0200, Luigi Rizzo wrote: > > > On Fri, Aug 22, 2008 at 02:05:26PM +0200, Christian Brueffer wrote: > > > > On Fri, Aug 22, 2008 at 12:24:41PM +0200, Ivan Voras wrote: > > > ... > > > > > This patch is huge. As far as I can tell DragonflyBSD has a whole= =20 > > > > > framework dedicated to varsyms, spread across a fair part of the = kernel=20 > > > > > and with at least one special userland utility. It allows the ope= rator=20 > > > > > to define his own variables that can be used in the substitutions= , and I=20 > > > > > don't see that it predefines "special" variables like "uid" and= =20 > > > > > "hostname". It's not necessarily a bad solution but I consider it= overkill. > > > ... > > > > Brooks has a varsym port in p4, see //depot/user/brooks/varsym/ > > >=20 > > > this also seems to be based on Dragonfly's code, quite intrusive. > >=20 > > This code adds one global symbol, one function call in the vfs code, > > and two pointers to struct proc. For that we get a system which is > > significantly more flexible than the NetBSD code. > >=20 > > While the simplicity of the NetBSD code is somewhat attractive, the > > fact that variables can not be defined renders it useless for my > > purposes which are providing partial file system virtulization for > > computing job/sessions where I need to key off of externally derived job > > IDs or job specific temporary paths. >=20 > understood -- it's just that the difference in code size is impressive. >=20 > Do you know how much of it is used to implement the "varsym" > subsystem (user- or system-wide variables) and how much is the > core name translation ? Most of it is maintaining the lists of variables, handling the system calls to read and write them, and doing the lookup with the correct locking context. The basic match routine is about the same size, though if you get a hit it's somewhat more expensive since you have to walk up to three lists (two in what's in p4 at the moment, but I'm currently splitting the per-proc code into privileged and un-privileged sets to the administrator can add values to processes that later owners can't modify) to resolve the variable name. -- Brooks --Q0rSlbzrZN6k9QnT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFIruB+XY6L6fI4GtQRAkFwAKCXdi0z1ZoNaplqAMidj6TE1krRpACfdvMj /qNldEeHGeZFrUbfRr7hWKs= =ZEOx -----END PGP SIGNATURE----- --Q0rSlbzrZN6k9QnT-- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 15:53:59 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3E18106567E for ; Fri, 22 Aug 2008 15:53:58 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by mx1.freebsd.org (Postfix) with ESMTP id C505C8FC1A for ; Fri, 22 Aug 2008 15:53:58 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so870552rvf.43 for ; Fri, 22 Aug 2008 08:53:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=AE4ubnFEfdhaiN4P47ZgzIhuXbckzcfALMoDPl8AB30=; b=RUmN36dan1wSPSCJcK+BH9/Re6GPUyO1eqLyN0g8DMHlkKW/7rR4cSdOZ7zfDCbQqc hTFcikcOnUTnFit38ulkiJYFHmIBikKJSbRiPQO+cD/QF4WTOYw7z8yE+yOciYrS0lpZ mlQsTLT1lvHHUusQVPZoZRYrotduGNXhlSvaM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=iJIxPM5adOm6QmdhThb9nS6dH85OlE/3FL2wPLHpUPcc6kiLyuIsAUFKnjG9ISp8wU jAOWUeSEM/+bZRn6Y9mGV6S1MSXCSrR+Lt/34COK2BKH1jvJHBYlQWwaj+s/IqlfhdYi wCpNtE/X+GkW18V8vAup6VQ6slwSRjt4bQcLA= Received: by 10.141.70.18 with SMTP id x18mr595534rvk.284.1219420438135; Fri, 22 Aug 2008 08:53:58 -0700 (PDT) Received: by 10.141.153.13 with HTTP; Fri, 22 Aug 2008 08:53:58 -0700 (PDT) Message-ID: <9bbcef730808220853q22666b44n5ca2b7add991191f@mail.gmail.com> Date: Fri, 22 Aug 2008 17:53:58 +0200 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Brooks Davis" In-Reply-To: <20080822153945.GC57443@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080822150020.GA57443@lor.one-eyed-alien.net> <9bbcef730808220802pa84b597u457100a23b03a80c@mail.gmail.com> <20080822153945.GC57443@lor.one-eyed-alien.net> X-Google-Sender-Auth: 77a7530c46fc1b24 Cc: freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 15:53:59 -0000 2008/8/22 Brooks Davis : > On Fri, Aug 22, 2008 at 05:02:31PM +0200, Ivan Voras wrote: >> 2008/8/22 Brooks Davis : >> >> > I have an implementation derived from Andrey's port of the DragonFly >> > implementation which will be committed in the next month or two. We >> > discussed it in detail at the dev summit and subject to a few more >> > changes and cleanup, it's ready to go. It allows significantly more >> > flexibility than the NetBSD approach while avoiding many of the pitfalls >> > involved in variant symlinks. >> >> Does it also support special automatic variables like uid, hostname? > > No it does not. There are two reasons for this. First, it's basically > pointless since you can set system wide variables for things like > hostname and I have login_conf support to set things like uid or uname > variables. Second, consider all the implications of @uid in the context > of setuid binaries. This is hard to reason about and easy to get wrong. > As a result, I feel a model where variables are set per process and > follow fork is much less prone to error. Firstly, it might be useless for your purpose but there are others. If you read the NetBSD's documentation about magiclinks, you'll see this set of supported variables: @domainname Expands to the machine's domain name, as set by setdomainname(3). @hostname Expands to the machine's host name, as set by sethostname(3). @emul Expands to the name of the current process's emulation. @kernel_ident Expands to the name of the config(1) file used to generate the running kernel. @machine Expands to the value of MACHINE for the system (equivalent to the output of ``uname -m''). @machine_arch Expands to the value of MACHINE_ARCH for the system (equivalent to the output of ``uname -p''). @osrelease Expands to the operating system release of the running kernel (equivalent to the output of ``uname -r''). @ostype Expands to the operating system type of the running kernel (equivalent to the output of ``uname -s''). This will always be ``NetBSD'' on NetBSD systems. @ruid Exapnds to the real user-id of the process. @uid Expands to the effective user-id of the process. Many of those are static and can be set on boot, but not all of them - for example machine and machine_arch may be different when running 32-bit processes on 64-bit machines. Domainname and hostname are different in jails. Your example with uid is solved just like in userland (though the names are messed up) and reflect getuid() and geteuid(). Anyway, if the DFBSD framework is properly implemented, it shouldn't be hard to add these variables. If you don't want to, I volunteer. (I don't care about the syntax: @{something} vs ${something}, though I think NetBSD made the better choice since these variables are not accessing the process environment). From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 16:12:37 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AE051065674; Fri, 22 Aug 2008 16:12:37 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id DE3E08FC1C; Fri, 22 Aug 2008 16:12:36 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.2/8.14.2) with ESMTP id m7MGDERv059228; Fri, 22 Aug 2008 11:13:14 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.2/8.14.2/Submit) id m7MGDE6P059227; Fri, 22 Aug 2008 11:13:14 -0500 (CDT) (envelope-from brooks) Date: Fri, 22 Aug 2008 11:13:14 -0500 From: Brooks Davis To: Ivan Voras Message-ID: <20080822161314.GE57443@lor.one-eyed-alien.net> References: <20080822150020.GA57443@lor.one-eyed-alien.net> <9bbcef730808220802pa84b597u457100a23b03a80c@mail.gmail.com> <20080822153945.GC57443@lor.one-eyed-alien.net> <9bbcef730808220853q22666b44n5ca2b7add991191f@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="//IivP0gvsAy3Can" Content-Disposition: inline In-Reply-To: <9bbcef730808220853q22666b44n5ca2b7add991191f@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 16:12:37 -0000 --//IivP0gvsAy3Can Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 22, 2008 at 05:53:58PM +0200, Ivan Voras wrote: > 2008/8/22 Brooks Davis : > > On Fri, Aug 22, 2008 at 05:02:31PM +0200, Ivan Voras wrote: > >> 2008/8/22 Brooks Davis : > >> > >> > I have an implementation derived from Andrey's port of the DragonFly > >> > implementation which will be committed in the next month or two. We > >> > discussed it in detail at the dev summit and subject to a few more > >> > changes and cleanup, it's ready to go. It allows significantly more > >> > flexibility than the NetBSD approach while avoiding many of the pitf= alls > >> > involved in variant symlinks. > >> > >> Does it also support special automatic variables like uid, hostname? > > > > No it does not. There are two reasons for this. First, it's basically > > pointless since you can set system wide variables for things like > > hostname and I have login_conf support to set things like uid or uname > > variables. Second, consider all the implications of @uid in the context > > of setuid binaries. This is hard to reason about and easy to get wrong. > > As a result, I feel a model where variables are set per process and > > follow fork is much less prone to error. >=20 > Firstly, it might be useless for your purpose but there are others. >=20 > If you read the NetBSD's documentation about magiclinks, you'll see > this set of supported variables: >=20 > @domainname Expands to the machine's domain name, as set by > setdomainname(3). >=20 > @hostname Expands to the machine's host name, as set by > sethostname(3). >=20 > @emul Expands to the name of the current process's emulatio= n. >=20 > @kernel_ident Expands to the name of the config(1) file used to gen= erate > the running kernel. >=20 > @machine Expands to the value of MACHINE for the system (equiv= alent > to the output of ``uname -m''). >=20 > @machine_arch Expands to the value of MACHINE_ARCH for the system > (equivalent to the output of ``uname -p''). >=20 > @osrelease Expands to the operating system release of the running > kernel (equivalent to the output of ``uname -r''). >=20 > @ostype Expands to the operating system type of the running k= ernel > (equivalent to the output of ``uname -s''). This will > always be ``NetBSD'' on NetBSD systems. >=20 > @ruid Exapnds to the real user-id of the process. >=20 > @uid Expands to the effective user-id of the process. >=20 > Many of those are static and can be set on boot, but not all of them - > for example machine and machine_arch may be different when running > 32-bit processes on 64-bit machines. Domainname and hostname are > different in jails. >=20 > Your example with uid is solved just like in userland (though the > names are messed up) and reflect getuid() and geteuid(). Small changes to the file system namespace can easily lead to security issues when applications assume the namespace is static. This is particularly true for setuid binaries. > Anyway, if the DFBSD framework is properly implemented, it shouldn't > be hard to add these variables. If you don't want to, I volunteer. I'm not completely opposed to adding a static namespace for system wide variables. I'm not at all keen on the @ruid and @uid variables because I think they are risky. My current feeling is that I'd like to move ahead with my current implementation and then either add another namespace or add this off to the side mostly as is. > (I don't care about the syntax: @{something} vs ${something}, though I > think NetBSD made the better choice since these variables are not > accessing the process environment). This is something I've been debating. I've been leading toward something o= ther than ${something}. Either @{} or %{} or else going all the way to something like %%something%%. I don't like the unanchored components netbsd uses. One other option we discussed at the devsummit was requiring that the first character of a variant symlink be special to reduce parsing overhead. I.e. requiring that variant symlinks start with @ or % or something. -- Brooks --//IivP0gvsAy3Can Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFIruWaXY6L6fI4GtQRAoMkAJ0RcwxQ35a0rIQy+CeJbgDq1NRJ7wCg1mtc ub3iAR2X5hkA/HbQ60/kn+U= =8aCL -----END PGP SIGNATURE----- --//IivP0gvsAy3Can-- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 16:20:25 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E8B91065672; Fri, 22 Aug 2008 16:20:25 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id DF3AC8FC23; Fri, 22 Aug 2008 16:20:24 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id EEB3C73098; Fri, 22 Aug 2008 18:22:59 +0200 (CEST) Date: Fri, 22 Aug 2008 18:22:59 +0200 From: Luigi Rizzo To: Brooks Davis Message-ID: <20080822162259.GA61694@onelab2.iet.unipi.it> References: <20080822090448.GB57441@onelab2.iet.unipi.it> <48AE89DC.9080408@yandex.ru> <20080822120525.GA1366@haakonia.hitnet.RWTH-Aachen.DE> <20080822145616.GA61094@onelab2.iet.unipi.it> <20080822150728.GB57443@lor.one-eyed-alien.net> <20080822154631.GA61495@onelab2.iet.unipi.it> <20080822155126.GD57443@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080822155126.GD57443@lor.one-eyed-alien.net> User-Agent: Mutt/1.4.2.3i Cc: Ivan Voras , Christian Brueffer , freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 16:20:25 -0000 On Fri, Aug 22, 2008 at 10:51:27AM -0500, Brooks Davis wrote: > On Fri, Aug 22, 2008 at 05:46:31PM +0200, Luigi Rizzo wrote: ... > > Do you know how much of it is used to implement the "varsym" > > subsystem (user- or system-wide variables) and how much is the > > core name translation ? > > Most of it is maintaining the lists of variables, handling the system > calls to read and write them, and doing the lookup with the correct > locking context. The basic match routine is about the same size, though > if you get a hit it's somewhat more expensive since you have to walk up > to three lists (two in what's in p4 at the moment, but I'm currently > splitting the per-proc code into privileged and un-privileged sets to > the administrator can add values to processes that later owners can't > modify) to resolve the variable name. so if i understand it well it could be committed as two separate pieces: one for the lookup and translation itself, and one for the variable management. The split would be very interesting for at least two reasons: 1. ease of porting/backporting/modularization e.g. think of the embedded case where one might want a limited or even no form of symlinks to save memory 2. maybe the code in charge of variable management can be replaced with some simpler instances (again for the embedded case, or e.g. to implement the NetBSD version of variant symlinks), reused for other purposes, or perhaps also integrated with other existing implementations. In fact i wonder about the following: we already have code to deal with kenv and sysctl, this would be a third mechanism that does a very similar thing, isn't there anything we can recycle from the existing ones ? Also, we do have a need to push tables of info in the kernel (e.g. list of PCI/USB ids, quirks tables and the like), maybe we can take this chance to make the varsym subsystem useful also within device drivers ? cheers luigi From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 18:41:55 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07AB310656C6; Fri, 22 Aug 2008 18:41:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A5EFF8FC21; Fri, 22 Aug 2008 18:41:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7MIdmMP076148; Fri, 22 Aug 2008 12:39:51 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 22 Aug 2008 12:40:19 -0600 (MDT) Message-Id: <20080822.124019.-692152321.imp@bsdimp.com> To: rizzo@iet.unipi.it From: "M. Warner Losh" In-Reply-To: <20080822162259.GA61694@onelab2.iet.unipi.it> References: <20080822154631.GA61495@onelab2.iet.unipi.it> <20080822155126.GD57443@lor.one-eyed-alien.net> <20080822162259.GA61694@onelab2.iet.unipi.it> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: brooks@freebsd.org, ivoras@freebsd.org, brueffer@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 18:41:55 -0000 In message: <20080822162259.GA61694@onelab2.iet.unipi.it> Luigi Rizzo writes: : Also, we do have a need to push tables of info in the kernel : (e.g. list of PCI/USB ids, quirks tables and the like), : maybe we can take this chance to make the varsym subsystem useful : also within device drivers ? No. what problem would this solve? Warner From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 19:34:22 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D318A106566C; Fri, 22 Aug 2008 19:34:22 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 921398FC12; Fri, 22 Aug 2008 19:34:22 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 240D47309C; Fri, 22 Aug 2008 21:36:57 +0200 (CEST) Date: Fri, 22 Aug 2008 21:36:57 +0200 From: Luigi Rizzo To: "M. Warner Losh" Message-ID: <20080822193657.GB63527@onelab2.iet.unipi.it> References: <20080822154631.GA61495@onelab2.iet.unipi.it> <20080822155126.GD57443@lor.one-eyed-alien.net> <20080822162259.GA61694@onelab2.iet.unipi.it> <20080822.124019.-692152321.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080822.124019.-692152321.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: brooks@freebsd.org, ivoras@freebsd.org, brueffer@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 19:34:22 -0000 On Fri, Aug 22, 2008 at 12:40:19PM -0600, M. Warner Losh wrote: > In message: <20080822162259.GA61694@onelab2.iet.unipi.it> > Luigi Rizzo writes: > : Also, we do have a need to push tables of info in the kernel > : (e.g. list of PCI/USB ids, quirks tables and the like), > : maybe we can take this chance to make the varsym subsystem useful > : also within device drivers ? > > No. what problem would this solve? take e.g. uscanner (or several other devices, e.g. if_rl) where the only way to tell whether a device is supported or not is looking up a table of usb vendor/id (the same happens for many pci devices). in the simple cases you just need the id - a more complex one would use linux has a way (forget what the command name is) to add entries to the table at runtime, whereas on freebsd we need to patch&rebuild the module. if make this 'object store' thing (varsym) able to store arrays we could have device drivers scan the arrays (e.g. uscanner_id or if_rl_pciids etc.) to find out if it has a suitable string. one objection that is frequently raised is that randomly adding ids to a kernel table is a potential source of panics, but in the end, to do this you need root access so you could as well rm -rf / and make a similar if not worse damage. cheers luigi From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 20:14:11 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 849BD1065671; Fri, 22 Aug 2008 20:14:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1930A8FC26; Fri, 22 Aug 2008 20:14:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7MKCfCM077768; Fri, 22 Aug 2008 14:12:41 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 22 Aug 2008 14:13:12 -0600 (MDT) Message-Id: <20080822.141312.732640662.imp@bsdimp.com> To: rizzo@iet.unipi.it From: "M. Warner Losh" In-Reply-To: <20080822193657.GB63527@onelab2.iet.unipi.it> References: <20080822162259.GA61694@onelab2.iet.unipi.it> <20080822.124019.-692152321.imp@bsdimp.com> <20080822193657.GB63527@onelab2.iet.unipi.it> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: brooks@FreeBSD.org, ivoras@FreeBSD.org, brueffer@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 20:14:11 -0000 In message: <20080822193657.GB63527@onelab2.iet.unipi.it> Luigi Rizzo writes: : On Fri, Aug 22, 2008 at 12:40:19PM -0600, M. Warner Losh wrote: : > In message: <20080822162259.GA61694@onelab2.iet.unipi.it> : > Luigi Rizzo writes: : > : Also, we do have a need to push tables of info in the kernel : > : (e.g. list of PCI/USB ids, quirks tables and the like), : > : maybe we can take this chance to make the varsym subsystem useful : > : also within device drivers ? : > : > No. what problem would this solve? : : take e.g. uscanner (or several other devices, e.g. if_rl) : where the only way to tell whether a device : is supported or not is looking up a table of usb vendor/id : (the same happens for many pci devices). in the simple cases : you just need the id - a more complex one would use How is this related? I guess was my question. Also, this problem isn't just replacing a table in the kernel. The problem is "map this ID to that ID" because many drivers do special things for different IDs, and you have to specify the ID that it is compatible with. : linux has a way (forget what the command name is) to add entries : to the table at runtime, whereas on freebsd : we need to patch&rebuild the module. : : if make this 'object store' thing (varsym) able to store arrays we : could have device drivers scan the arrays (e.g. uscanner_id or : if_rl_pciids etc.) to find out if it has a suitable string. That's the wrong way to solve the problem. In FreeBSD there's no universal table on any bus except for PC Card. Until we have that, this solution can't happen. Each driver has its own ad-hoc way of doing this. Even in PC Card land, the size of the table isn't exported. The way that drivers are written today in FreeBSD, the bus has to provide this translation layer. There's really no other viable solution. If someone goes through and fixes all the important busses, then maybe this would be a needed service. : one objection that is frequently raised is that randomly adding ids : to a kernel table is a potential source of panics, but in the end, : to do this you need root access so you could as well rm -rf / and : make a similar if not worse damage. Panic! Well, I'm sold. Warner From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 21:38:44 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F987106564A; Fri, 22 Aug 2008 21:38:44 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 2E3708FC17; Fri, 22 Aug 2008 21:38:44 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 7CA5A73098; Fri, 22 Aug 2008 23:41:18 +0200 (CEST) Date: Fri, 22 Aug 2008 23:41:18 +0200 From: Luigi Rizzo To: "M. Warner Losh" Message-ID: <20080822214118.GA64725@onelab2.iet.unipi.it> References: <20080822162259.GA61694@onelab2.iet.unipi.it> <20080822.124019.-692152321.imp@bsdimp.com> <20080822193657.GB63527@onelab2.iet.unipi.it> <20080822.141312.732640662.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080822.141312.732640662.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: brooks@FreeBSD.org, ivoras@FreeBSD.org, brueffer@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 21:38:44 -0000 On Fri, Aug 22, 2008 at 02:13:12PM -0600, M. Warner Losh wrote: > In message: <20080822193657.GB63527@onelab2.iet.unipi.it> > Luigi Rizzo writes: > : On Fri, Aug 22, 2008 at 12:40:19PM -0600, M. Warner Losh wrote: > : > In message: <20080822162259.GA61694@onelab2.iet.unipi.it> > : > Luigi Rizzo writes: > : > : Also, we do have a need to push tables of info in the kernel > : > : (e.g. list of PCI/USB ids, quirks tables and the like), > : > : maybe we can take this chance to make the varsym subsystem useful > : > : also within device drivers ? > : > > : > No. what problem would this solve? > : > : take e.g. uscanner (or several other devices, e.g. if_rl) > : where the only way to tell whether a device > : is supported or not is looking up a table of usb vendor/id > : (the same happens for many pci devices). in the simple cases > : you just need the id - a more complex one would use > > How is this related? I guess was my question. background: the initial topic was variant symlinks, for which is desirable to have system- or user-definable variables that can be used during the translation -- so one could play tricks such as setting /tmp -> /tmpdir/${uid} and have private temp directories, and the like. To implement those variables you need a storage subsystem that is accessible from kernel, outside the process space, and supports multiple instances (per-user or per-process or perhaps both; the 'multiple instance' thing can be easily implemented with something with a hierarchical structure). It probably needs to be support very fast reads as it is accessed every time we need to translate a pathname involving variant symlinks. It doesn't need to be persistent. Dragonfly has implemented this storage subsystem with the 'varsym' command/subsystem. the connection: At least as i understand it, we already have plenty of storage subsystems in the OS that fit most of the above requirements (except perhaps the read cost) including the sysctl tree, the kenv tree, the /proc filesystem -- so i think it would be great to have a unified solution [at least as a backend] for all these purposes. I haven't looked at the internals of /proc or varsym so i don't know how suitable are them for our purposes. > Also, this problem isn't just replacing a table in the kernel. The > problem is "map this ID to that ID" because many drivers do special > things for different IDs, and you have to specify the ID that it is > compatible with. what's wrong with something like this driverparms.if_re.devid.0x11864300 = "0x04000000 D-Link DGE-528(T) Gigabit Ethernet Adapter" driverparms.if_re.devid.0x11868139 = "0x74800000 RealTek 8139c..." ... The subtree under if_re only needs to be known to the device, though some standardization would help of course -- e.g. we could have generic code to parse device ids of variable size using wildcards, and for the value field we could use xml encoding (if something more trivial does not fit -- but a barebone xml parser such as the one we need here fits in 5-10k of object code, i did that a few months ago , see http://info.iet.unipi.it/~luigi/FreeBSD/minixmlrpc/ Hooking a write callback on a node, e.g. to driverparms. if_re.devid would allow the driver to update its own internal table of descriptors upon a change, and retain the current match code (and speed) essentially unchanged in all drivers. > : linux has a way (forget what the command name is) to add entries > : to the table at runtime, whereas on freebsd > : we need to patch&rebuild the module. > : > : if make this 'object store' thing (varsym) able to store arrays we > : could have device drivers scan the arrays (e.g. uscanner_id or > : if_rl_pciids etc.) to find out if it has a suitable string. > > That's the wrong way to solve the problem. In FreeBSD there's no > universal table on any bus except for PC Card. Until we have that, > this solution can't happen. Each driver has its own ad-hoc way of > doing this. Even in PC Card land, the size of the table isn't > exported. > > The way that drivers are written today in FreeBSD, the bus has to > provide this translation layer. There's really no other viable > solution. If someone goes through and fixes all the important busses, > then maybe this would be a needed service. perhaps you are pointing to an ideal solution, which however would still require significant work on each driver to adapt the current, ad-hoc tables to the solution supplied by the bus. The approach i suggest above allows incremental deployment and i believe it still scales well. cheers luigi From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 22:01:47 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DE28106567E; Fri, 22 Aug 2008 22:01:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id EFDD68FC15; Fri, 22 Aug 2008 22:01:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7MM0auW079721; Fri, 22 Aug 2008 16:00:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 22 Aug 2008 16:01:07 -0600 (MDT) Message-Id: <20080822.160107.511563083.imp@bsdimp.com> To: rizzo@iet.unipi.it From: "M. Warner Losh" In-Reply-To: <20080822214118.GA64725@onelab2.iet.unipi.it> References: <20080822193657.GB63527@onelab2.iet.unipi.it> <20080822.141312.732640662.imp@bsdimp.com> <20080822214118.GA64725@onelab2.iet.unipi.it> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: brooks@FreeBSD.org, ivoras@FreeBSD.org, brueffer@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 22:01:47 -0000 In message: <20080822214118.GA64725@onelab2.iet.unipi.it> Luigi Rizzo writes: : > Also, this problem isn't just replacing a table in the kernel. The : > problem is "map this ID to that ID" because many drivers do special : > things for different IDs, and you have to specify the ID that it is : > compatible with. : : : what's wrong with something like this : : driverparms.if_re.devid.0x11864300 = "0x04000000 D-Link DGE-528(T) Gigabit Ethernet Adapter" : driverparms.if_re.devid.0x11868139 = "0x74800000 RealTek 8139c..." : ... : : The subtree under if_re only needs to be known to the device, though : some standardization would help of course -- e.g. we could have generic : code to parse device ids of variable size using wildcards, and for : the value field we could use xml encoding (if something more trivial : does not fit -- but a barebone xml parser such as the one we need here : fits in 5-10k of object code, i did that a few months ago , see : : http://info.iet.unipi.it/~luigi/FreeBSD/minixmlrpc/ : : Hooking a write callback on a node, e.g. to driverparms. : if_re.devid would allow the driver to update its own internal : table of descriptors upon a change, and retain the current match : code (and speed) essentially unchanged in all drivers. You're going to have to give me a much more detailed description than this, because the driver getting a callback to update its information is very handwavy. And drivers wishing to do this would need to do a lot of work to make sure that their tables are dynamic. Today, they are static, or in code (eg, switch statements). this sounds like a very complex solution to the problem, without really a clear vision for how it would draw together different devices. : > : linux has a way (forget what the command name is) to add entries : > : to the table at runtime, whereas on freebsd : > : we need to patch&rebuild the module. : > : : > : if make this 'object store' thing (varsym) able to store arrays we : > : could have device drivers scan the arrays (e.g. uscanner_id or : > : if_rl_pciids etc.) to find out if it has a suitable string. : > : > That's the wrong way to solve the problem. In FreeBSD there's no : > universal table on any bus except for PC Card. Until we have that, : > this solution can't happen. Each driver has its own ad-hoc way of : > doing this. Even in PC Card land, the size of the table isn't : > exported. : > : > The way that drivers are written today in FreeBSD, the bus has to : > provide this translation layer. There's really no other viable : > solution. If someone goes through and fixes all the important busses, : > then maybe this would be a needed service. : : perhaps you are pointing to an ideal solution, which however would : still require significant work on each driver to adapt the current, : ad-hoc tables to the solution supplied by the bus. : : The approach i suggest above allows incremental deployment and i believe : it still scales well. Actually, the solution that I propose requires *NO* changes to any leaf drivers. None. It only requires changes in the bus level code to do the lookup and substitution. They are totally ignorant of the changes that are going on behind the scenes and can treat a new card just like a card they already support without even knowing that they are doing this. Since I don't understand your suggestion at all, I can't comment about how well it scales. From what I see, it is a disaster in that area as every driver that wants to participate in this would need to change. Warner From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 22:14:45 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A8AB1065675; Fri, 22 Aug 2008 22:14:45 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 9C00B8FC0C; Fri, 22 Aug 2008 22:14:44 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m7M9bXPK000489; Fri, 22 Aug 2008 19:37:33 +1000 Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m7M9bPqK003626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2008 19:37:29 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m7M9bPQ9034121; Fri, 22 Aug 2008 19:37:25 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m7M9bNLf034120; Fri, 22 Aug 2008 19:37:23 +1000 (EST) (envelope-from peter) Date: Fri, 22 Aug 2008 19:37:23 +1000 From: Peter Jeremy To: Luigi Rizzo Message-ID: <20080822093723.GY32539@server.vk2pj.dyndns.org> References: <20080822090448.GB57441@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HLsZ5Z1opAQvdr2J" Content-Disposition: inline In-Reply-To: <20080822090448.GB57441@onelab2.iet.unipi.it> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Ivan Voras , freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 22:14:45 -0000 --HLsZ5Z1opAQvdr2J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Aug-22 11:04:49 +0200, Luigi Rizzo wrote: >Question - is the process' ENV easily available in this part >of the kernel, so one could in principle use environment variables >as replacement strings ? No. The original environment is in a known location but a process is free to reorganise its environment to be based in a different location. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --HLsZ5Z1opAQvdr2J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkiuiNMACgkQ/opHv/APuIcxLACdGsgnyqar8EjCjZTpY53mHld9 mwsAn0z56XMyvvziHIBJTx5JvPmPfHMQ =dkKl -----END PGP SIGNATURE----- --HLsZ5Z1opAQvdr2J-- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 22:48:45 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81B351065674; Fri, 22 Aug 2008 22:48:45 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 081718FC0C; Fri, 22 Aug 2008 22:48:44 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 7139273098; Sat, 23 Aug 2008 00:51:19 +0200 (CEST) Date: Sat, 23 Aug 2008 00:51:19 +0200 From: Luigi Rizzo To: "M. Warner Losh" Message-ID: <20080822225119.GA65119@onelab2.iet.unipi.it> References: <20080822193657.GB63527@onelab2.iet.unipi.it> <20080822.141312.732640662.imp@bsdimp.com> <20080822214118.GA64725@onelab2.iet.unipi.it> <20080822.160107.511563083.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080822.160107.511563083.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: brooks@FreeBSD.org, ivoras@FreeBSD.org, brueffer@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 22:48:45 -0000 On Fri, Aug 22, 2008 at 04:01:07PM -0600, M. Warner Losh wrote: > In message: <20080822214118.GA64725@onelab2.iet.unipi.it> > Luigi Rizzo writes: ... > : Hooking a write callback on a node, e.g. to driverparms. > : if_re.devid would allow the driver to update its own internal > : table of descriptors upon a change, and retain the current match > : code (and speed) essentially unchanged in all drivers. > > You're going to have to give me a much more detailed description than > this, because the driver getting a callback to update its information > is very handwavy. take if_re as an example. When if_re loads, it would call object_store_register("driverparms.if_re.devids", if_re_update_devid_table, if_re_devid_table_root); which in turn puts the string-function-arg tuple in a hash table using the string as a search key. Optionally, it could also call a routine to pre-fill the object store subtree with static content supplied by if_re.c or so. When (from the upper part of the kernel, so it can sleep etc.) the subtree is written to, the object store calls if_re_update_devid_table(if_re_devid_table_root) which in turn would scan the subtree using the api supplied by the object store itself, and rebuilds the table, quirks, whatever used by if_re for its own purposes. Clearly, this is specific for if_re. umass will likely have a more complex structure with quirks etc, uscanner is just a table of device ids, etc. > lot of work to make sure that their tables are dynamic. Today, they > are static, or in code (eg, switch statements). this sounds like a > very complex solution to the problem, without really a clear vision > for how it would draw together different devices. ... > : perhaps you are pointing to an ideal solution, which however would > : still require significant work on each driver to adapt the current, > : ad-hoc tables to the solution supplied by the bus. > : > : The approach i suggest above allows incremental deployment and i believe > : it still scales well. > > Actually, the solution that I propose requires *NO* changes to any > leaf drivers. None. It only requires changes in the bus level code > to do the lookup and substitution. They are totally ignorant of the > changes that are going on behind the scenes and can treat a new card > just like a card they already support without even knowing that they > are doing this. sorry but now i am the one who doesn't understand how you can move, with *NO* changes to the leaf drivers, from a bunch of drivers using ad-hoc solutions (static tables with variable number of fields, or lookups hardwired in the code, which don't use just the vendor/device fields but also other info e.g. subdevice as in if_re) to one that relies on the bus code for the matching. At the very least you need to replace the part of the *_probe routines with something that uses the bus routines -- and implement something that lets you manipulate the mapping/quirks table at runtime so that if a compatible device with different IDs comes out you don't have to recompile and reload a module. That's the same kind of changes that I expect to be necessary with the way I have in mind. i am sorry i cannot expand this more as i am about to leave for holidays, but will try to come up with some proof-of-concept code when i am back. cheers luigi From owner-freebsd-arch@FreeBSD.ORG Sat Aug 23 01:54:20 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A40D21065687; Sat, 23 Aug 2008 01:54:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 609BA8FC14; Sat, 23 Aug 2008 01:54:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7N1nkdY083192; Fri, 22 Aug 2008 19:49:46 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 22 Aug 2008 19:50:18 -0600 (MDT) Message-Id: <20080822.195018.1129789600.imp@bsdimp.com> To: rpaulo@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20080823013912.GA19588@epsilon.local> References: <20080822.160107.511563083.imp@bsdimp.com> <20080822225119.GA65119@onelab2.iet.unipi.it> <20080823013912.GA19588@epsilon.local> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: brooks@FreeBSD.org, ivoras@FreeBSD.org, brueffer@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 01:54:20 -0000 In message: <20080823013912.GA19588@epsilon.local> Rui Paulo writes: : On Sat, Aug 23, 2008 at 12:51:19AM +0200, Luigi Rizzo wrote: : > sorry but now i am the one who doesn't understand how you can move, : : [snip] : : I think what Warner was saying was that the BUS code can do a mapping of : device IDs from something not known to the driver to something know by the : driver. : : Take, for example, if_re. if_re knows how to support devid 0x1234. : A new device comes out that works exactly the same way as device 0x1234, but : the the device ID is 0x4567. If we change the BUS code to map devid 0x4567 to : 0x1234, we don't need to change anything in the if_re driver. We just changed : the BUS code with no change to the leaf driver. : : If there is a new device with ID 0x9912 that needs modifications in if_re, we : are basically busted and need to change if_re itself. In this scenario, : we don't change anything in the BUS code because that would be pointless. : : I hope this is what Warner was trying to say. Yes. The bus code would have a mapping table. If you have to do more than just say 'treat this like this other thing' you'll need to hack the driver anyway, so you'd save nothing with a fancier solution that might allow this... In the above example, the pci code would read the device id. It would see it is 0x4567 and lie to the driver saying it is really 0x1234. The driver then matches this, and treats it exactly as if it were a 0x1234, since that's what it thinks the card is. Most of the drivers in the tree support a variety of cards, so some way of telling it which one to use is needed.... There are some complicated drivers that know all the errata for this or that rev of the chip. I'm not sure how those would work out in practice. However, those drivers almost always need tweaks for new parts... Warner From owner-freebsd-arch@FreeBSD.ORG Sat Aug 23 02:06:21 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B7071065675 for ; Sat, 23 Aug 2008 02:06:21 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id E81258FC1A for ; Sat, 23 Aug 2008 02:06:20 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so55790eyi.7 for ; Fri, 22 Aug 2008 19:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent:sender; bh=4RVGdV7l5SpbT6U69TjWETEZJo4kGjjsUuCP7SGq52I=; b=VQcmRHQwEsCkLYQ5Ioyde1dvrNGovZ5ChUWIvXnZxWNzf/r6l2Y/4KvRToExfAI8x1 +s9e0p9L14JzBc6OlBaIGJXEQAfBBRkInAXuudDQ9IQMZJ1mtlPyfBfKZ3H/XiPjWoef P2FnmEfsTR7BQ6Qk0nXtNuqNfnd57ny/B6/rw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent:sender; b=EH4tYiEPs28bh3k2ETVpKCRkr/LsyRpkU3wWQ7dfyuCddZzN6s2okFCJr0CvCN5wju pe5jKgReyOrxrQJ4SY+mgFU1Wpo7USWXArmJv/OFr+/6OFMTC/dxakk4JEgcbWOCJ5Tt 2/llQOiYac7uTcHuvDOiqkEHpj1XqaUav0sKg= Received: by 10.210.28.4 with SMTP id b4mr2406671ebb.138.1219455563653; Fri, 22 Aug 2008 18:39:23 -0700 (PDT) Received: from epsilon.local ( [89.214.82.7]) by mx.google.com with ESMTPS id p10sm8035939gvf.7.2008.08.22.18.39.20 (version=SSLv3 cipher=RC4-MD5); Fri, 22 Aug 2008 18:39:22 -0700 (PDT) Date: Sat, 23 Aug 2008 02:39:12 +0100 From: Rui Paulo To: Luigi Rizzo Message-ID: <20080823013912.GA19588@epsilon.local> References: <20080822193657.GB63527@onelab2.iet.unipi.it> <20080822.141312.732640662.imp@bsdimp.com> <20080822214118.GA64725@onelab2.iet.unipi.it> <20080822.160107.511563083.imp@bsdimp.com> <20080822225119.GA65119@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080822225119.GA65119@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: Rui Paulo Cc: freebsd-arch@FreeBSD.org, brooks@FreeBSD.org, ivoras@FreeBSD.org, brueffer@FreeBSD.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 02:06:21 -0000 On Sat, Aug 23, 2008 at 12:51:19AM +0200, Luigi Rizzo wrote: > sorry but now i am the one who doesn't understand how you can move, [snip] I think what Warner was saying was that the BUS code can do a mapping of device IDs from something not known to the driver to something know by the driver. Take, for example, if_re. if_re knows how to support devid 0x1234. A new device comes out that works exactly the same way as device 0x1234, but the the device ID is 0x4567. If we change the BUS code to map devid 0x4567 to 0x1234, we don't need to change anything in the if_re driver. We just changed the BUS code with no change to the leaf driver. If there is a new device with ID 0x9912 that needs modifications in if_re, we are basically busted and need to change if_re itself. In this scenario, we don't change anything in the BUS code because that would be pointless. I hope this is what Warner was trying to say. Regards, -- Rui Paulo From owner-freebsd-arch@FreeBSD.ORG Sat Aug 23 02:06:39 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF256106564A for ; Sat, 23 Aug 2008 02:06:39 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230]) by mx1.freebsd.org (Postfix) with ESMTP id 71A9B8FC16 for ; Sat, 23 Aug 2008 02:06:39 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by wx-out-0506.google.com with SMTP id h27so296920wxd.7 for ; Fri, 22 Aug 2008 19:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=NaDmxiKtwE9BfdlBWr49Vt2J4gB6LSypWpXDVuXOVss=; b=dxLKePNMtqva3bVKiz0x/uEgM/rmp4m2bUJYeF8tcAJIZ0LLdt31h4B4B9vjUwJv2S lx5wYpryCBbVHNDIVGXjUhr8NQi5xOyFE2d+A2pDeTRXB39/0X1X679jnv/xih1s7g+8 Y1DMjfnEdeGjy2Idcd8hQkZvpTJAbbyZ1HMFQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=SUuVdxNTV8hN35RRcWpR5ggM/dcNQwtxHSaUhWipjLd+sei24aF0JGVO/qQvBB5BeA YAz7pqjOwrCNHcfGSS4Zos0K2joL8ViExpnsfWN9KLOHtUyEk90/RVQQdCJBLZ3GfjvO d5h2GMw3k3fzMR3Az/8PYubNhT8Vbab5gi4q0= Received: by 10.70.62.14 with SMTP id k14mr2183772wxa.33.1219455323554; Fri, 22 Aug 2008 18:35:23 -0700 (PDT) Received: from kan.dnsalias.net ( [24.63.237.22]) by mx.google.com with ESMTPS id 5sm3314676wrh.24.2008.08.22.18.35.21 (version=SSLv3 cipher=RC4-MD5); Fri, 22 Aug 2008 18:35:22 -0700 (PDT) Date: Fri, 22 Aug 2008 21:35:05 -0400 From: Alexander Kabaev To: arch@freebsd.org Message-ID: <20080822213505.1993beda@kan.dnsalias.net> In-Reply-To: <20080729.161303.709402272.imp@bsdimp.com> References: <20080729.161303.709402272.imp@bsdimp.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/LY35jMM_18gg9vFRUyS.xIL"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: kan@freebsd.org Subject: Re: Need a code review X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 02:06:39 -0000 --Sig_/LY35jMM_18gg9vFRUyS.xIL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 29 Jul 2008 16:13:03 -0600 (MDT) "M. Warner Losh" wrote: > Greetings, >=20 > The FreeBSD/mips efforts are getting close. We're down to 4 patches > against the main tree, divided up among different programs: cc, > binutils, libpam and the CDDL stuff for zfs. >=20 > http://people.freebsd.org/~gonzo/mips2/binutils.diff > http://people.freebsd.org/~gonzo/mips2/cc.diff > http://people.freebsd.org/~gonzo/mips2/cddl.diff > http://people.freebsd.org/~gonzo/mips2/libpam.diff >=20 > If you have an interest in any of these area, or would like to provide > feedback on the patches, now would be a good time to do so. :-) >=20 > We'd like to commit these patches to the tree by the end of next week, > if at all possible. If you are a maintainer of this software, we'd > especially like to get feedback from you on these patches. If we > don't hear back from you, we'll assume that you are fine with them :-) >=20 > Warner cc.diff part is OK, except that files we copy from vendor intact should be marked as such. Ideally, by putting their pristine versions in /vendor and branching into head/src/contrib/gcc. Some comments in new FreeBSD files still claim they are for NetBSD/mips. +#ifdef HANDLE_PRAGMA_PACK_PUSH_POP +#undef HANDLE_PRAGMA_PACK_PUSH_POP +#endif #define HANDLE_PRAGMA_PACK_PUSH_POP 1 Can this be rewritten as #ifndef HANDLE_PRAGMA_PACK_PUSH_POP #define HANDLE_PRAGMA_PACK_PUSH_POP 1 #endif ? --=20 Alexander Kabaev --Sig_/LY35jMM_18gg9vFRUyS.xIL Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFIr2lJQ6z1jMm+XZYRAjj4AJ9wl3y3m6hIaGDn7mvE1B3cW6zp6ACdERA4 cyoxTf9gZ7qWJq/+vlx3KSE= =1cSI -----END PGP SIGNATURE----- --Sig_/LY35jMM_18gg9vFRUyS.xIL-- From owner-freebsd-arch@FreeBSD.ORG Sat Aug 23 02:07:43 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF7051065672; Sat, 23 Aug 2008 02:07:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6CFC88FC16; Sat, 23 Aug 2008 02:07:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7N24d8S083859; Fri, 22 Aug 2008 20:04:39 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 22 Aug 2008 20:05:11 -0600 (MDT) Message-Id: <20080822.200511.1137957320.imp@bsdimp.com> To: rpaulo@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20080823013912.GA19588@epsilon.local> References: <20080822.160107.511563083.imp@bsdimp.com> <20080822225119.GA65119@onelab2.iet.unipi.it> <20080823013912.GA19588@epsilon.local> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: brooks@FreeBSD.org, ivoras@FreeBSD.org, brueffer@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 02:07:43 -0000 In message: <20080823013912.GA19588@epsilon.local> : I hope this is what Warner was trying to say. More or less the following, with a less lame way of getting the table into the kernel, and maybe more fields than vendor/device.... The reason this works is that the pci_get_vendor and pci_get_device read out of the area pointed to by cfg. Warner Index: pci.c =================================================================== --- pci.c (revision 182024) +++ pci.c (working copy) @@ -419,6 +419,33 @@ #undef REG } +static struct pci_remap_entry +{ + uint16_t vendor; + uint16_t device; + uint16_t mapped_vendor; + uint16_t mapped_device; +} pci_remap[] = +{ + { 0x1039, 0x0901, 0x1039, 0x0900 } /* Map sis 901 to sis 900 */ +}; +static int pci_remap_entries = 1; + +static void +pci_apply_remap_table(pcicfgregs *cfg) +{ + int i; + + for (i = 0; i < pci_remap_entries; i++) { + if (cfg->vendor == pci_remap[i].vendor && + cfg->device == pci_remap[i].device) { + cfg->vendor = pci_remap[i].mapped_vendor; + cfg->device = pci_remap[i].mapped_device; + return; + } + } +} + /* read configuration header into pcicfgregs structure */ struct pci_devinfo * pci_read_device(device_t pcib, int d, int b, int s, int f, size_t size) @@ -465,6 +492,7 @@ pci_fixancient(cfg); pci_hdrtypedata(pcib, b, s, f, cfg); + pci_apply_remap_table(cfg); if (REG(PCIR_STATUS, 2) & PCIM_STATUS_CAPPRESENT) pci_read_extcap(pcib, cfg); From owner-freebsd-arch@FreeBSD.ORG Sat Aug 23 03:32:24 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B49131065677; Sat, 23 Aug 2008 03:32:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2DF568FC1B; Sat, 23 Aug 2008 03:32:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [IPv6:2001:470:1f11:75:2a0:d2ff:fe18:8b38]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7N3WFuu010991; Fri, 22 Aug 2008 23:32:15 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Fri, 22 Aug 2008 22:41:51 -0400 User-Agent: KMail/1.9.7 References: <20080822.160107.511563083.imp@bsdimp.com> <20080823013912.GA19588@epsilon.local> <20080822.200511.1137957320.imp@bsdimp.com> In-Reply-To: <20080822.200511.1137957320.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808222241.52325.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:2001:470:1f11:75::1]); Fri, 22 Aug 2008 23:32:15 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8076/Fri Aug 22 18:15:54 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: brueffer@freebsd.org, brooks@freebsd.org, rpaulo@freebsd.org, ivoras@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 03:32:24 -0000 On Friday 22 August 2008 10:05:11 pm M. Warner Losh wrote: > In message: <20080823013912.GA19588@epsilon.local> > > : I hope this is what Warner was trying to say. > > More or less the following, with a less lame way of getting the table > into the kernel, and maybe more fields than vendor/device.... > > The reason this works is that the pci_get_vendor and pci_get_device > read out of the area pointed to by cfg. > > Warner > > Index: pci.c > =================================================================== > --- pci.c (revision 182024) > +++ pci.c (working copy) > @@ -419,6 +419,33 @@ > #undef REG > } > > +static struct pci_remap_entry > +{ > + uint16_t vendor; > + uint16_t device; > + uint16_t mapped_vendor; > + uint16_t mapped_device; > +} pci_remap[] = > +{ > + { 0x1039, 0x0901, 0x1039, 0x0900 } /* Map sis 901 to sis 900 */ > +}; > +static int pci_remap_entries = 1; > + > +static void > +pci_apply_remap_table(pcicfgregs *cfg) > +{ > + int i; > + > + for (i = 0; i < pci_remap_entries; i++) { > + if (cfg->vendor == pci_remap[i].vendor && > + cfg->device == pci_remap[i].device) { > + cfg->vendor = pci_remap[i].mapped_vendor; > + cfg->device = pci_remap[i].mapped_device; > + return; > + } > + } > +} > + > /* read configuration header into pcicfgregs structure */ > struct pci_devinfo * > pci_read_device(device_t pcib, int d, int b, int s, int f, size_t size) > @@ -465,6 +492,7 @@ > > pci_fixancient(cfg); > pci_hdrtypedata(pcib, b, s, f, cfg); > + pci_apply_remap_table(cfg); > > if (REG(PCIR_STATUS, 2) & PCIM_STATUS_CAPPRESENT) > pci_read_extcap(pcib, cfg); It might be nice to drive it by hints so users can tweak it on the fly. Maybe something like: hint.pci0...vendor=XXXXX Then users can simply add entries to /boot/loader.conf w/o needing any recompiles for new device IDs that the driver can handle using an existing device id. The lookup table you have still requires patching source somewhere which probably defeats the purpose. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Sat Aug 23 03:36:05 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB4521065689; Sat, 23 Aug 2008 03:36:05 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id AC8708FC16; Sat, 23 Aug 2008 03:36:05 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id m7N2QQOf006090; Fri, 22 Aug 2008 22:26:27 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20080822161314.GE57443@lor.one-eyed-alien.net> References: <20080822150020.GA57443@lor.one-eyed-alien.net> <9bbcef730808220802pa84b597u457100a23b03a80c@mail.gmail.com> <20080822153945.GC57443@lor.one-eyed-alien.net> <9bbcef730808220853q22666b44n5ca2b7add991191f@mail.gmail.com> <20080822161314.GE57443@lor.one-eyed-alien.net> Date: Fri, 22 Aug 2008 22:26:25 -0400 To: Brooks Davis , Ivan Voras From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 0.10 () [Hold at 20.00] COMBINED_FROM X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.226 Cc: freebsd-arch@FreeBSD.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 03:36:06 -0000 At 11:13 AM -0500 8/22/08, Brooks Davis wrote: >On Fri, Aug 22, 2008 at 05:53:58PM +0200, Ivan Voras wrote: > > > If you read the NetBSD's documentation about magiclinks, you'll > > see this set of supported variables: > > > > @domainname Expands to the machine's domain name, ... > > @hostname Expands to the machine's host name, ... > > @kernel_ident Expands to the name of the config(1) file ... > > @machine Expands to the value of MACHINE > > (equivalent to the output of ``uname -m''). > > @machine_arch Expands to the value of MACHINE_ARCH for > > the system (equivalent to the output of > > ``uname -p''). > > @osrelease Expands to the operating system release > > of the running kernel (equivalent to the > > output of ``uname -r''). > > @ostype Expands to the operating system type of > > the running kernel (equivalent to the > > output of ``uname -s''). This will > > always be ``NetBSD'' on NetBSD systems. > > > Many of those are static and can be set on boot, but not all > > of them - for example machine and machine_arch may be different > > when running 32-bit processes on 64-bit machines. Domainname > > and hostname are different in jails. I like the idea of having some of these mostly-static values, although (as you note), we should to think about how these might be effected within jails. I have jails (really chroot areas) which have different @osreleases than the running kernel, for instance. FWIW, I'd prefer to see the dragonfly-ish implementation over the netbsd-ish implementation. > > Your example with uid is solved just like in userland (though > > the names are messed up) and reflect getuid() and geteuid(). > >Small changes to the file system namespace can easily lead to security >issues when applications assume the namespace is static. This is >particularly true for setuid binaries. I am extremely uneasy about adding anything related to uid's or gid's, or similar dynamic values. I can't help but think tbat any case where this would be useful, it would also be very risky with-respect-to setuid() binaries. > > (I don't care about the syntax: @{something} vs ${something}, > > though I think NetBSD made the better choice since these > > variables are not accessing the process environment). > >This is something I've been debating. I've been leading toward >something other than ${something}. Either @{} or %{} or else >going all the way to something like %%something%%. I don't like >the unanchored components netbsd uses. This could easily degenerate into a bikeshed issue, but let me at least say that I think we should avoid "@varname". That's the syntax which AFS/OpenAFS/ARLA uses for their equivalent of variant filename paths, and I think it would be good if we avoid any confusion with that. >One other option we discussed at the devsummit was requiring that >the first character of a variant symlink be special to reduce >parsing overhead. I.e. requiring that variant symlinks start >with @ or % or something. I'd like something with both a right and left delimiter, both required. Something where the two delimiters are different, and easy to distinguish, and easy to "stack" (if for some reason we wanted to allow that). Stack in the sense of %{name1%{name2%}%}, where we can tell we would have to substitute the value for "name2" before doing anything with the "name1"-ish part. I don't know that we need to actually support that ability, but if we do (someday) want to support it, then I want delimiters where it would be obvious what order the substitutions should occur in. As far as the specific delimiters to pick, well, I'm sure anyone's paint is as good as mine. It will be nice to have this ability. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-arch@FreeBSD.ORG Sat Aug 23 04:47:05 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF2FB1065673; Sat, 23 Aug 2008 04:47:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8CF948FC14; Sat, 23 Aug 2008 04:47:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7N4hWSG085365; Fri, 22 Aug 2008 22:43:32 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 22 Aug 2008 22:44:04 -0600 (MDT) Message-Id: <20080822.224404.691670281.imp@bsdimp.com> To: jhb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <200808222241.52325.jhb@freebsd.org> References: <20080823013912.GA19588@epsilon.local> <20080822.200511.1137957320.imp@bsdimp.com> <200808222241.52325.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: brooks@FreeBSD.org, rpaulo@FreeBSD.org, ivoras@FreeBSD.org, brueffer@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 04:47:05 -0000 In message: <200808222241.52325.jhb@freebsd.org> John Baldwin writes: : On Friday 22 August 2008 10:05:11 pm M. Warner Losh wrote: : > In message: <20080823013912.GA19588@epsilon.local> : > : > : I hope this is what Warner was trying to say. : > : > More or less the following, with a less lame way of getting the table : > into the kernel, and maybe more fields than vendor/device.... : > : > The reason this works is that the pci_get_vendor and pci_get_device : > read out of the area pointed to by cfg. ... : It might be nice to drive it by hints so users can tweak it on the fly. Maybe : something like: : : hint.pci0...vendor=XXXXX : : Then users can simply add entries to /boot/loader.conf w/o needing any : recompiles for new device IDs that the driver can handle using an existing : device id. : : The lookup table you have still requires patching source somewhere which : probably defeats the purpose. That's the whole "less lame of getting data into the kernel" I was talking about. The above was to show the concept, not an actual implementation of the data. I don't like the hint idea so much, but was looking for some other way to get the data into the kernel. Warner From owner-freebsd-arch@FreeBSD.ORG Sat Aug 23 06:59:07 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E08CF106566C; Sat, 23 Aug 2008 06:59:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 9ED168FC16; Sat, 23 Aug 2008 06:59:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7N6uOTX087502; Sat, 23 Aug 2008 00:56:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 23 Aug 2008 00:56:56 -0600 (MDT) Message-Id: <20080823.005656.1543769327.imp@bsdimp.com> To: kabaev@gmail.com From: "M. Warner Losh" In-Reply-To: <20080822213505.1993beda@kan.dnsalias.net> References: <20080729.161303.709402272.imp@bsdimp.com> <20080822213505.1993beda@kan.dnsalias.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: kan@FreeBSD.org, arch@FreeBSD.org, obrien@FreeBSD.org Subject: Re: Need a code review X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 06:59:08 -0000 In message: <20080822213505.1993beda@kan.dnsalias.net> Alexander Kabaev writes: : On Tue, 29 Jul 2008 16:13:03 -0600 (MDT) : "M. Warner Losh" wrote: : : > Greetings, : > : > The FreeBSD/mips efforts are getting close. We're down to 4 patches : > against the main tree, divided up among different programs: cc, : > binutils, libpam and the CDDL stuff for zfs. : > : > http://people.freebsd.org/~gonzo/mips2/binutils.diff : > http://people.freebsd.org/~gonzo/mips2/cc.diff : > http://people.freebsd.org/~gonzo/mips2/cddl.diff : > http://people.freebsd.org/~gonzo/mips2/libpam.diff : > : > If you have an interest in any of these area, or would like to provide : > feedback on the patches, now would be a good time to do so. :-) : > : > We'd like to commit these patches to the tree by the end of next week, : > if at all possible. If you are a maintainer of this software, we'd : > especially like to get feedback from you on these patches. If we : > don't hear back from you, we'll assume that you are fine with them :-) : > : > Warner : : cc.diff part is OK, except that files we copy from vendor intact should : be marked as such. Ideally, by putting their pristine versions : in /vendor and branching into head/src/contrib/gcc. Good idea. Now, if only I can figure out how to do that... : Some comments in new FreeBSD files still claim they are for NetBSD/mips. We can fix that :-) Good catch. : +#ifdef HANDLE_PRAGMA_PACK_PUSH_POP : +#undef HANDLE_PRAGMA_PACK_PUSH_POP : +#endif : #define HANDLE_PRAGMA_PACK_PUSH_POP 1 : : Can this be rewritten as : #ifndef HANDLE_PRAGMA_PACK_PUSH_POP : #define HANDLE_PRAGMA_PACK_PUSH_POP 1 : #endif No. The whole reason those changes were introduced was to quiet warnings that HANDLE_PRAGMA_PACK_PUSH_POP was redefined... We can omit them if they will cause problems. I wasn't real concerned about the warnings, but Randal Stewart fixed them since they bugged him. Maybe there's a better way? Any suggestions? Warner From owner-freebsd-arch@FreeBSD.ORG Sat Aug 23 08:16:16 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3D3E106567D for ; Sat, 23 Aug 2008 08:16:16 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 38D3F8FC26 for ; Sat, 23 Aug 2008 08:16:15 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KWoI6-0001KL-V8 for freebsd-arch@freebsd.org; Sat, 23 Aug 2008 08:16:10 +0000 Received: from 89-172-34-84.adsl.net.t-com.hr ([89.172.34.84]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Aug 2008 08:16:10 +0000 Received: from ivoras by 89-172-34-84.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Aug 2008 08:16:10 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Sat, 23 Aug 2008 10:15:59 +0200 Lines: 78 Message-ID: References: <20080822150020.GA57443@lor.one-eyed-alien.net> <9bbcef730808220802pa84b597u457100a23b03a80c@mail.gmail.com> <20080822153945.GC57443@lor.one-eyed-alien.net> <9bbcef730808220853q22666b44n5ca2b7add991191f@mail.gmail.com> <20080822161314.GE57443@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig55EF31693237FD6088C8CCA6" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-34-84.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) In-Reply-To: <20080822161314.GE57443@lor.one-eyed-alien.net> X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 08:16:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig55EF31693237FD6088C8CCA6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Brooks Davis wrote: > On Fri, Aug 22, 2008 at 05:53:58PM +0200, Ivan Voras wrote: >> Your example with uid is solved just like in userland (though the >> names are messed up) and reflect getuid() and geteuid(). >=20 > Small changes to the file system namespace can easily lead to security > issues when applications assume the namespace is static. This is > particularly true for setuid binaries. >=20 >> Anyway, if the DFBSD framework is properly implemented, it shouldn't >> be hard to add these variables. If you don't want to, I volunteer. >=20 > I'm not completely opposed to adding a static namespace for system > wide variables. I'm not at all keen on the @ruid and @uid variables > because I think they are risky. My current feeling is that I'd like to= > move ahead with my current implementation and then either add another > namespace or add this off to the side mostly as is. Ok, how about adding another sysctl enabling ruid and uid (perhaps=20 change their name to uid and euid since NetBSD compatibility isn't=20 maintained) which will be off by default? >> (I don't care about the syntax: @{something} vs ${something}, though I= >> think NetBSD made the better choice since these variables are not >> accessing the process environment). >=20 > This is something I've been debating. I've been leading toward somethi= ng other > than ${something}. Either @{} or %{} or else going all the way to some= thing > like %%something%%. =20 Someone mentioned "@" clashes with AFS :( > I don't like the unanchored components netbsd uses. They could have an use case - see below: > One other option we discussed at the devsummit was requiring that the f= irst > character of a variant symlink be special to reduce parsing overhead. = I.e. > requiring that variant symlinks start with @ or % or something. I agree with this - it's elegant on the implementation side and=20 performance hit would be minimal. I'd also be happy with abandoning the=20 free form links and mandating that the entire component be one var=20 symlink (i.e. "/path1/@var/path2" is ok but "/path1/@{path2}.@{path3}"=20 isn't). If you'd implement that special starting character, how would the=20 end-result look like? Something like "#path@{var}"? (for various values=20 of "#")? --------------enig55EF31693237FD6088C8CCA6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIr8c/ldnAQVacBcgRAvCvAJ4kFbQGH7Dx6ThQD6VgVdBnckeJiQCfQjF2 1es8XF9twRJQCjgyevXXHAg= =B76u -----END PGP SIGNATURE----- --------------enig55EF31693237FD6088C8CCA6-- From owner-freebsd-arch@FreeBSD.ORG Sat Aug 23 08:22:40 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BA321065686 for ; Sat, 23 Aug 2008 08:22:40 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id C40F08FC15 for ; Sat, 23 Aug 2008 08:22:39 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KWoOH-0001aM-Tg for freebsd-arch@freebsd.org; Sat, 23 Aug 2008 08:22:33 +0000 Received: from 89-172-34-84.adsl.net.t-com.hr ([89.172.34.84]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Aug 2008 08:22:33 +0000 Received: from ivoras by 89-172-34-84.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Aug 2008 08:22:33 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Sat, 23 Aug 2008 10:22:19 +0200 Lines: 82 Message-ID: References: <20080822150020.GA57443@lor.one-eyed-alien.net> <9bbcef730808220802pa84b597u457100a23b03a80c@mail.gmail.com> <20080822153945.GC57443@lor.one-eyed-alien.net> <9bbcef730808220853q22666b44n5ca2b7add991191f@mail.gmail.com> <20080822161314.GE57443@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD9B0C8D32B67DA3D530210C6" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-34-84.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) In-Reply-To: X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 08:22:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD9B0C8D32B67DA3D530210C6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Garance A Drosehn wrote: > I like the idea of having some of these mostly-static values, > although (as you note), we should to think about how these might > be effected within jails. I have jails (really chroot areas) > which have different @osreleases than the running kernel, for > instance. This last case would be problematic since symlinks are resolved in=20 kernel and the kernel can't really see the different userland releases.=20 64-bit call vs 32-bit is ok. > FWIW, I'd prefer to see the dragonfly-ish implementation over > the netbsd-ish implementation. >=20 >> > Your example with uid is solved just like in userland (though >> > the names are messed up) and reflect getuid() and geteuid(). >> >> Small changes to the file system namespace can easily lead to security= >> issues when applications assume the namespace is static. This is >> particularly true for setuid binaries. >=20 > I am extremely uneasy about adding anything related to uid's or > gid's, or similar dynamic values.=20 This argument pops up often without explanation. The only thing I can=20 think of is applications using ".." on a dynamic symlink and ending up=20 somewhere where it doesn't want to, but this can also be said for normal = symlinks. Can anyone explain more possible security problems with having @uid in=20 varsymlinks? > I can't help but think tbat > any case where this would be useful, it would also be very risky > with-respect-to setuid() binaries. I posted a nice use-case at the first post: per-user /tmp like in=20 http://www.feyrer.de/NetBSD/bx/blosxom.cgi/nb_20080714_0251.html . Of=20 course it's a "nice to have", not a critical feature. >> > (I don't care about the syntax: @{something} vs ${something}, >> > though I think NetBSD made the better choice since these >> > variables are not accessing the process environment). >> >> This is something I've been debating. I've been leading toward >> something other than ${something}. Either @{} or %{} or else >> going all the way to something like %%something%%. I don't like >> the unanchored components netbsd uses. >=20 > This could easily degenerate into a bikeshed issue, but let me > at least say that I think we should avoid "@varname". That's > the syntax which AFS/OpenAFS/ARLA uses for their equivalent of > variant filename paths, and I think it would be good if we avoid > any confusion with that. How about "@{varname}" ? --------------enigD9B0C8D32B67DA3D530210C6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIr8i7ldnAQVacBcgRAkopAJ9blmSklcKUKFGfC87DgSdmBt4kNwCgsawj QTLS4s+KkFWkw1PWL17zDc0= =6bf8 -----END PGP SIGNATURE----- --------------enigD9B0C8D32B67DA3D530210C6-- From owner-freebsd-arch@FreeBSD.ORG Sat Aug 23 09:27:41 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88B5E106567E; Sat, 23 Aug 2008 09:27:41 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3E9138FC13; Sat, 23 Aug 2008 09:27:41 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 43E2A207E; Sat, 23 Aug 2008 11:27:40 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 1F153844AB; Sat, 23 Aug 2008 11:27:40 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Brooks Davis References: <20080822150020.GA57443@lor.one-eyed-alien.net> <9bbcef730808220802pa84b597u457100a23b03a80c@mail.gmail.com> <20080822153945.GC57443@lor.one-eyed-alien.net> <9bbcef730808220853q22666b44n5ca2b7add991191f@mail.gmail.com> <20080822161314.GE57443@lor.one-eyed-alien.net> Date: Sat, 23 Aug 2008 11:27:40 +0200 In-Reply-To: <20080822161314.GE57443@lor.one-eyed-alien.net> (Brooks Davis's message of "Fri, 22 Aug 2008 11:13:14 -0500") Message-ID: <86ljyof5df.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Ivan Voras , freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 09:27:41 -0000 Brooks Davis writes: > One other option we discussed at the devsummit was requiring that the fir= st > character of a variant symlink be special to reduce parsing overhead. I.= e. > requiring that variant symlinks start with @ or % or something. A much tidier option (which was also discussed) is to set a bit on the cnp if the symlink is found to be variant when it first enters the cache. This way, we don't penalize non-variant symlinks that begin with a @ or %. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sat Aug 23 12:25:21 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1E7D106567B for ; Sat, 23 Aug 2008 12:25:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 2B1348FC12 for ; Sat, 23 Aug 2008 12:25:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KWsBD-000G7E-Dn; Sat, 23 Aug 2008 15:25:19 +0300 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 m7NCPFmG036290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Aug 2008 15:25:16 +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.2/8.14.2) with ESMTP id m7NCPFdr024747; Sat, 23 Aug 2008 15:25:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m7NCPFwk024746; Sat, 23 Aug 2008 15:25:15 +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, 23 Aug 2008 15:25:15 +0300 From: Kostik Belousov To: Ivan Voras Message-ID: <20080823122515.GS1803@deviant.kiev.zoral.com.ua> References: <20080822150020.GA57443@lor.one-eyed-alien.net> <9bbcef730808220802pa84b597u457100a23b03a80c@mail.gmail.com> <20080822153945.GC57443@lor.one-eyed-alien.net> <9bbcef730808220853q22666b44n5ca2b7add991191f@mail.gmail.com> <20080822161314.GE57443@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SuSGaIqs99hP22V3" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KWsBD-000G7E-Dn dcd74ceafa4481d8b075874e01050217 X-Terabit: YES Cc: freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 12:25:21 -0000 --SuSGaIqs99hP22V3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 23, 2008 at 10:22:19AM +0200, Ivan Voras wrote: > Garance A Drosehn wrote: >=20 > >I like the idea of having some of these mostly-static values, > >although (as you note), we should to think about how these might > >be effected within jails. I have jails (really chroot areas) > >which have different @osreleases than the running kernel, for > >instance. >=20 > This last case would be problematic since symlinks are resolved in=20 > kernel and the kernel can't really see the different userland releases.= =20 > 64-bit call vs 32-bit is ok. Not exactly true. There is p_osrel member of struct proc, that may be interpreted as osrelease where binary where intended to run. At least, it reflects the crt1.o origin. I am not sure whether such dynamic data naturally maps into varsyms concept. At least, some fallback shall be provided for "other" values of osrel. The fact that Solaris and Linux do not provide variant symlinks may be explained by keyword support in their rtld. --SuSGaIqs99hP22V3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiwAasACgkQC3+MBN1Mb4hkDwCgz9vdErzxRLhafOP+gt8Oo1a7 exQAoKThjlAJkXBLw5N2ZbrLnJVRrcQo =jgX9 -----END PGP SIGNATURE----- --SuSGaIqs99hP22V3-- From owner-freebsd-arch@FreeBSD.ORG Sat Aug 23 12:27:01 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0E041065677 for ; Sat, 23 Aug 2008 12:27:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6FA3A8FC17 for ; Sat, 23 Aug 2008 12:27:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 2D97246B2E; Sat, 23 Aug 2008 08:27:01 -0400 (EDT) Date: Sat, 23 Aug 2008 13:27:01 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ivan Voras In-Reply-To: Message-ID: References: <20080822150020.GA57443@lor.one-eyed-alien.net> <9bbcef730808220802pa84b597u457100a23b03a80c@mail.gmail.com> <20080822153945.GC57443@lor.one-eyed-alien.net> <9bbcef730808220853q22666b44n5ca2b7add991191f@mail.gmail.com> <20080822161314.GE57443@lor.one-eyed-alien.net> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 12:27:01 -0000 On Sat, 23 Aug 2008, Ivan Voras wrote: >> I am extremely uneasy about adding anything related to uid's or gid's, or >> similar dynamic values. > > This argument pops up often without explanation. The only thing I can think > of is applications using ".." on a dynamic symlink and ending up somewhere > where it doesn't want to, but this can also be said for normal symlinks. > > Can anyone explain more possible security problems with having @uid in > varsymlinks? The issues I'm aware of revolve more about usability than security, although frequently security relies on determinism. Consider setuid tools, such as lpr or sudo, which currently behave deterministically when a path is passed, and the effect of having "@uid" present in a symlink evaluated in the lookup to /tmp: lpr /tmp/my.txt sudo mv /tmp/group.tmp /etc/group While I see arguments going many different ways on this, I think POLA reasonably demands that we not significant disrupt the semantics of /tmp or other situations where, on face value, a uid-based symlink might be used. And, from a general security perspective, maintaining the assumptions of current users, applications, etc, is quite important for avoiding vulnerabilities that stem from changing underlying execution model assumptions. I think Brooks's reimplementation of the DFBSD approach addresses most of my concerns with respect to classic name space manipulation attacks, but even then I would advise extreme caution. Robert N M Watson Computer Laboratory University of Cambridge