From owner-freebsd-hackers@FreeBSD.ORG Sun May 12 17:54:58 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 63234802; Sun, 12 May 2013 17:54:58 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by mx1.freebsd.org (Postfix) with ESMTP id 6558067D; Sun, 12 May 2013 17:54:56 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id e49so1173774eek.5 for ; Sun, 12 May 2013 10:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:organization :x-mailer:mime-version:content-type:content-transfer-encoding; bh=eULesjOb39sJd/mJ0denfWWGMB8KfGMdpy/4x27l1Ew=; b=z6zg4xAouE04VXCoJM1e8hqP/Wnww+f6xosQwKSvxQeUV5plNkqe69mIGH5uhu6BnJ jcKF0I8sza6uBAs2S4DfxwQXtP5jjmyyFfYJdtT8EAH3kWGUiPZD2IahDhANtZkFB/T0 1YyQ1nPeQO/lxvRz+OEBFeqC3nKzzqnDri63tx95T5P5UeybTa48SikVwcXiY/dT/oTa uLzepYjMeCWEOtZqHIKJcMGV0fsGqzSJQ2NxoQ1s/GMaNVzACAKSzbKRmvsJHL30GDwa Z2v6TIq4ILM1VrRCbdKAyfE7LcyDreMLJ2RN1a5F82k9FdymxYvW8+49VPg9h8KkjuMC vLNQ== X-Received: by 10.14.0.129 with SMTP id 1mr68418742eeb.43.1368381289883; Sun, 12 May 2013 10:54:49 -0700 (PDT) Received: from funktor (catv-80-98-246-83.catv.broadband.hu. [80.98.246.83]) by mx.google.com with ESMTPSA id i2sm6674817eeg.2.2013.05.12.10.54.48 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sun, 12 May 2013 10:54:49 -0700 (PDT) Sender: =?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?= Date: Sun, 12 May 2013 19:54:05 +0200 From: Gabor Pali To: hackers@freebsd.org Subject: FreeBSD Quarterly Status Report, January-March 2013 Message-ID: <20130512195405.04653b64@funktor> Organization: The FreeBSD Project X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; i386-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 17:54:58 -0000 FreeBSD Quarterly Status Report, January-March 2013 Introduction This report covers FreeBSD-related projects between January and March 2013. This is the first of four reports planned for 2013. Highlights from this status report include the busy preparations of 8.4-RELEASE, restoration of binary package building, steady progress of several porting efforts, like work on the FreeBSD ports of xorg, GNOME, KDE, and Xfce, bringing FreeBSD to Cubieboard and Hackberry boards, development of ARM and AMD GPU support, improving performance of UFS/FFS and callouts, and introducing a multipath TCP implementation for the network stack. Thanks to all the reporters for the excellent work! This report contains 31 entries and we hope you enjoy reading it. The deadline for submissions covering the period between April and June 2013 is July 7th, 2013. __________________________________________________________________ Projects * FreeNAS * Kernel Information in Process Core Dumps * Native iSCSI Stack FreeBSD Team Reports * FreeBSD Bugmeister Team * FreeBSD Core Team * FreeBSD Port Managers * FreeBSD Postmaster Team * FreeBSD Release Engineering Team Kernel * AMD GPU Kernel Mode-Setting (KMS) Support * Atomic "close-on-exec" * callout(9) Improvements * Multipath TCP (MPTCP) for FreeBSD * racct: Block IO Accounting * Read-only Port of NetBSD's UDF File System * TCP-AO Authentication Option * UFS/FFS Performance Work Documentation * Improving the Documentation Project Infrastructre * The entities Documentation Branch * The FreeBSD Japanese Documentation Project Architectures * FreeBSD on Cubieboard * FreeBSD/arm Superpages for ARMv7 * FreeBSD/ARM Toolchain Improvements Ports * FreeBSD Haskell Ports * GNOME/FreeBSD * KDE/FreeBSD * PyPy * Wine32 on FreeBSD/amd64 * Xfce/FreeBSD * xorg on FreeBSD Miscellaneous * BXR.SU -- Super User's BSD Cross Reference * mdoc.su -- Short Manual Page URLs __________________________________________________________________ AMD GPU Kernel Mode-Setting (KMS) Support URL: https://wiki.freebsd.org/AMD_GPU Contact: Jean-S=C3=A9bastien P=C3=A9dron Contact: J.R. Oldroyd Contact: Konstantin Belousov The project progressed well since February: * Konstantin committed is TTM port to 10-CURRENT. * With the help of John Baldwin (jhb) and Andriy Gapon (avg), the Video BIOS situation greatly improved: the radeonkms driver reads the BIOS shadow copy if the video card is the primary one, or query the PCI expansion ROM otherwise. In the end, this code will be probably committed to the PCI driver so that other video drivers benefit from it. * Andriy also reported several problems with the I2C code. Now that they are fixed, the monitors plugged into DVI and HDMI connectors are detected and their EDID is read correctly. VGA connector is not tested so far. * There is a locking problem in either TTM or the Radeon driver which prevents OpenGL from working properly. Jean-S=C3=A9bastien is curren= tly tracking this down. * J.R. Oldroyd started to work on a 9-STABLE backport of the driver which is now working quite well. He had to backport some features from the VM which may need further refinement by the VM folks. Yakaz lended Jean-S=C3=A9bastien a computer which allows him to test a RV630-based discrete card and, in the future, other PCIe cards. Several users already kindly tested the driver. Big thanks to all those contributors! In its current state, the driver allows to have a simple X session (no OpenGL), run common applications, watch movies, change the resolution and enable additional monitors with xrandr(1). The most blocking issue now is the OpenGL deadlock which prevents to run modern compositors/desktop environment, games and WebGL demos. We are not ready for a "Call For Testers" yet. Open tasks: 1. Test multiple cards configurations for Video BIOS issues, especially Intel integrated card + Radeon discrete card, and AMD integrated card (IGP) + Radeon discrete card. No need to check configurations with one shared connector though, it is not supported right now. __________________________________________________________________ Atomic "close-on-exec" URL: https://wiki.freebsd.org/AtomicCloseOnExec Contact: Jilles Tjoelker If threads or signal handlers call fork() and exec(), file descriptors may be passed undesirably to child processes, which may lead to hangs (if a pipe is not closed), exceeding the file descriptor limit and security problems (if the child process has lower privilege). One solution is various new APIs that set the "close-on-exec" flag atomically with allocating a file descriptor. Some existing software will use the new features if present or will even refuse to compile without them. Various parts have been present for some time. In first quarter of 2013, extensions to recvmsg(), socket(), socketpair() and posix_openpt() have been added. __________________________________________________________________ BXR.SU -- Super User's BSD Cross Reference URL: http://bxr.su/ URL: http://lists.freebsd.org/pipermail/freebsd-hackers/2013-April/04233= 4.html Contact: Constantine A. Murenin Super User's BSD Cross Reference (BXR.SU) is a new source-code search engine that covers the complete kernel and non-GNU userland source trees of FreeBSD, NetBSD, OpenBSD, and DragonFly BSD. BXR.SU is optimised to be very fast, has daily updates of all the trees, and also acts as a deterministic URL shortener. BXR.SU is based on an OpenGrok fork, but it is more than just OpenGrok. We have fixed a number of annoyances, eliminated features that just never worked right from the outright, and provided integration with tools like CVSweb (including great mirrors like allbsd.org), FreeBSD's ViewVC (SVN), as well as GitHub and Gitweb from git.freebsd.your.org, plus a tad of other improvements, including a complete rewrite of an mdoc parser. Last, but definitely not least, is an extensive set of nginx rewrite rules that makes it a breeze to use BXR.SU as a deterministic URL compactor for referencing BSD source code. For example, the http://bxr.su/f/kern/sched_ule.c URL will automatically redirect to http://bxr.su/FreeBSD/sys/kern/sched_ule.c through nginx. Note that according to the release schedule of BXR.SU, there is no IPv4 glue until 2013-04-24; otherwise, the service is available via both IPv4 and IPv6. See the 2013-04-01 announcement on the freebsd-hackers mailing list for more details. Open tasks: 1. Find up-to-date git repositories (served with Gitweb) of NetBSD and OpenBSD. 2. Find a Gitweb mirror of FreeBSD that is faster than GitHub and Gitorious. __________________________________________________________________ callout(9) Improvements URL: http://people.freebsd.org/~davide/asia/callout_paper.pdf URL: http://people.freebsd.org/~davide/asia/calloutng.pdf URL: http://svnweb.freebsd.org/base?view=3Drevision&revision=3D247777 Contact: Davide Italiano Contact: Alexander Motin In FreeBSD, timers are provided by the callout facility, which allows to register a function with an argument to be called at specified future time. The subsystem suffered of some problems, such as the impossibility of handling high-resolution events or its inherent periodic structure, which may lead to spurious wakeups and higher power consumption. Some consumers, such as high-speed networking, VoIP and other real-time applications need a better precision than the one currently allowed. Also, especially with the ubiquity of laptops in the last years, the energy wasted by interrupts waking CPUs from sleep may be a sensitive factor. Recent changes in the subsystem addressed those long-standing issues as well as introduced a new programming interface to take advantage of the new features. Open tasks: 1. Evaluating if it is worth to migrate any of the other callout(9) consumers to the new interface. 2. Move callout consumers still using the legacy timeout()/untimeout() interface to callout_*() in order to get rid of redundant code and clean up KPI. __________________________________________________________________ FreeBSD Bugmeister Team Contact: Eitan Adler Contact: Gavin Atkinson Contact: Oleksandr Tymoshenko The FreeBSD Bugmeister Team are continuing to evaluate options for alternate bug trackers and have narrowed their choices to two possibilities: Bugzilla and roundup. The number of non-ports PRs have remained relatively static over the last three months, with as many coming in as being closed. The number of ports PRs have increased recently, largely due to the ports freeze for the upcoming 8.4-RELEASE. The Bugmeister team continue work on trying to make the contents of the GNATS PR database cleaner, more accessible and easier for committers to find and resolve PRs, by tagging PRs to indicate the areas involved, and by ensuring that there is sufficient info within each PR to resolve each issue. As always, anybody interested in helping out with the PR queue is welcome to join us in #freebsd-bugbusters on EFnet. We are always looking for additional help, whether your interests lie in triaging incoming PRs, generating patches to resolve existing problems, or simply helping with the database housekeeping (identifying duplicate PRs, ones that have already been resolved, etc). This is a great way of getting more involved with FreeBSD! Open tasks: 1. Finalize the decision of which new bug tracker to use. 2. Get more users involved with triaging PRs as they come in. 3. Assist committers with closing PRs. __________________________________________________________________ FreeBSD Core Team Contact: Core Team At the end of 2012, the Core Team approved using Google Analytics on the Project web site to enable the Documentation Engineering Team to collect statistics on its usage for better profiling. In the first quarter of 2013, the Core Team worked with the Documentation Engineering Team to finalize the associated policies. Due to some debates around the political correctness of quotes added for the fortune(6) utility, the corresponding data file has been removed from the base system in -CURRENT. In light of the security incident, the liaison role between the Core Team and the Security Team has been restored, with Gavin Atkinson assuming this role. The Core Team work hard on resolving the current situation of the binary package building cluster and the associated security problems in tight cooperation with the Ports Management Team, Cluster Administators, and the FreeBSD Foundation Board. The compromise page is kept updated on the results. The FreeBSD Project submitted an application for Google Summer of Code this year again. There was access granted for 2 new committers and 1 commit bit was taken for safekeeping in this quarter. __________________________________________________________________ FreeBSD Haskell Ports URL: http://wiki.freebsd.org/Haskell URL: https://github.com/freebsd-haskell/freebsd-haskell/ Contact: G=C3=A1bor P=C3=A1li Contact: Ashish Shukla We are proud to announce FreeBSD Haskell Team has updated existing ports to their latest stable versions. We also added number of new ports, which brings the count of Haskell ports in FreeBSD ports tree to more than 400, featuring many popular software, e.g. xmonad, git-annex, pandoc or various web framework implementations. All of these updates will be available as part of the upcoming 8.4-RELEASE. We also came to know that Haskell ports are also being used successfully on DragonFlyBSD's dports tree. In our development repository, there was some optional support added for LLVM-based code generation using the GHC LLVM backend. This works mostly on FreeBSD too, though some of the ports would need fixing so it is still considered experimental. Open tasks: 1. Try to build GHC with clang (as system compiler). 2. Commit pending Haskell ports to the FreeBSD ports tree. 3. Add more ports to the Ports Collection. __________________________________________________________________ FreeBSD on Cubieboard Contact: Ganbold Tsagaankhuu Contact: Oleksandr Tymoshenko Initial support of Allwinner A10 SoC is committed to -CURRENT. FreeBSD is now running on boards such as Cubieboard, Hackberry and it supports following peripherals: * USB EHCI * GPIO Open tasks: 1. Get EMAC Ethernet driver working. Need more help from network driver experts. 2. Implement more drivers. __________________________________________________________________ FreeBSD Port Managers URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en/articles/contributing-ports/ URL: http://portsmon.freebsd.org/ URL: http://www.freebsd.org/portmgr/ URL: http://blogs.freebsdish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr Contact: Thomas Abthorpe Contact: Port Management Team The ports tree contains approximately 24,300 ports, while the PR count still is close to 1600. In the first quarter we added 4 new committers, took in 1 commit bit for safe keeping, and re-instated 1 commit bit. In February, Mark Linimon (linimon) stepped down from his duties in the team. Mark had been the longest serving member of the team. Mark had spent many long hours refactoring and documenting the portbuild software to ensure that pointyhat services could be restored. After a security review, redports.org was turned back on, restoring Tinderbox services to contributors, along with post commit QATs. In addition, pointyhat infrastructure had also undergone a review and work begain on restoring the package build system. Erwin Lansing (erwin) and Martin Wilke (miwi) took on the principle roles of getting the portbuild software installed and running on pointyhat. As a result of all their hard work, portmgr@ was finally able to resume doing -exp runs, preparing packages for the upcoming 8.4 release, as well as getting a set of 9.1 packages retroactively prepared. After many long years of being the defacto standard for the Project, CVS support for the ports tree officially ended on February 28. The ports tree was tagged with RELEASE_7_EOL, to coincide with the end of life for FreeBSD 7.X. Beat Gaetzi (beat) stepped down from his duties on portmgr@ in March. Among his notable contributions, was the task of migrating the Ports Tree from the old CVS repo to Subversion. Bryan Drewery (bdrewery) joined the Ports Management team in March, bringing with him his wealth of knowledge and skill from maintaining portupgrade, portmaster, assisting with pkgng, as well as co-developing poudriere. Open tasks: 1. Most ports PRs are assigned, we now need to focus on testing, committing and closing. __________________________________________________________________ FreeBSD Postmaster Team Contact: David Wolfskill In the first quarter of 2013, the FreeBSD Postmaster Team has implemented the following items that may be interest of the general public: * Changes in configuration of Mailman-managed lists: allow to accept the application/pkcs7-signature MIME type (in addition to the application/x-pkcs7-signature MIME type), thus permitting S/MIME signatures on list mail. * New lists: freebsd-ops-announce -- announcements of infrastructure issues, and freebsd-pkg -- discussion of binary package management and package tools. __________________________________________________________________ FreeBSD Release Engineering Team URL: http://www.freebsd.org/releases/8.4R/schedule.html Contact: FreeBSD Release Engineering Team FreeBSD 8.4-RC1 just got out the door and we are planning RC2. A couple of critical fixes have come in that will be included in RC2. The schedule has slipped about 10 days so far. We are expecting the final release by the end of April. Packages for 8.4 have been provided by a fully operational package building cluster. __________________________________________________________________ FreeBSD/arm Superpages for ARMv7 URL: http://static.usenix.org/events/osdi02/tech/full_papers/navarro/nav= arro.pdf URL: https://wiki.freebsd.org/ARMSuperpages URL: https://github.com/semihalf-bodek-zbigniew/freebsd-arm-superpages.g= it Contact: Zbigniew Bodek Contact: Grzegorz Bernacki Contact: Rafa=C5=82 Jaworowski ARM architecture is more and more prevailing, not only in the mobile and embedded space. Among the more interesting industry trends emerging in the recent months has been the "ARM server" concept. Some top-tier companies started developing systems like this already (Dell, HP). Key to FreeBSD success in these new areas are sophisticated features, among them are superpages. The objective of this project is to provide FreeBSD/arm with the superpages support, which will allow for efficient use of TLB translations (enlarge TLB coverage), leading to improved performance in many applications and scalability. Indicated functionality is intended to work on ARMv7-based processors, however compatibility with ARMv6 will be preserved. Current support status: * Port of the pv_entry allocator. * Switch to "AP[2:1]" access permissions model. * PTE-based, page-referenced/modified emulation. * Fixes regarding page replacement strategy. * Code optimizations and bug fixes. Next steps: * Dirty pages management. * Gradual integration to FreeBSD -CURRENT. * Further pmap optimizations. * Fragmentation control management. * Testing and benchmarking. Open tasks: 1. Support for multiple page sizes. 2. Implementation of page promotion, demotion and eviction mechanisms. __________________________________________________________________ FreeBSD/ARM Toolchain Improvements Contact: Andrew Turner Clang has been made the default compiler on ARM. A number of issues with LLVM and clang have been found, reported, and fixed upstream. An issue where some ARM EABI applications compiled with clang crash has been reported upstream with a patch and will be brought into the FreeBSD tree when it is accepted. The only other issue blocking moving to the ARM EABI is C++ exceptions fail to work correctly with shared objects. This will need us to either import libunwind or implement the functions libgcc_s requires to find the correct unwind table. Open tasks: 1. Fix exception handling for EABI. __________________________________________________________________ FreeNAS URL: http://www.FreeNAS.org/ Contact: Alfred Perlstein Contact: Josh Paetzel FreeNAS 8.3.1-RELEASE-p2 will hit Sourceforge the second week of April, and should end up as the last FreeNAS release based on FreeBSD 8.X It's currently the only Free Open Source NAS product available with any form of ZFS encryption (provided by GELI). Open tasks: 1. The team is hard at work on getting a FreeBSD 9.X-based release of FreeNAS ready. Currently there are several nightly snapshots available. 2. Add HAST to the webinterface. 3. Migrate to NFSv4. 4. Integrate foundation sponsored kernel iSCSI target. __________________________________________________________________ GNOME/FreeBSD URL: http://www.freebsd.org/gnome URL: http://www.freebsd.org/gnome/docs/develfaq.html URL: http://www.marcuscom.com:8080/viewvc/viewvc.cgi/marcuscom URL: https://github.com/jlmess77/mate-ports Contact: FreeBSD GNOME team The GNOME/FreeBSD Team has recently merged Glib 2.34, Gtk+ 2.24.17 and Gtk+ 3.6.4 into ports, the C++ bindings also have got updates. In additional "low-level" GNOME ports received updates, like libsoup, gobject-introspection, atk and vala for example. The telepathy stack and empathy where also updated. The USE_GNOME macro has received support for :run and :build targets thanks to Jeremy Messenger (mezz). Currently only libxml2 and libxslt support these targets. USE_GNOME=3Dpkgconfig is being deprecated in favor of USE_PKGCONFIG=3Dbuild. The former also adds a run dependency on pkg-config, which is not required. A first pass was done to get rid of this in the Glib update to 2.34. In cooperation with the X11 Team, the usage of USE_GNOME=3Dpkgconfig in X components will be removed. After the fallout from this is handled and stranglers are converted, the USE_GNOME option will be removed. In addition USE_GNOME=3Dgnomehack is deprecated and should not be used. Please replace it with USES=3Dpathfix. The GNOME development repository has switched from CVS to SVN. CVS will not get any more updates. Uses can get a new version of the marcusmerge script that supports SVN from its home page, and should remove the old CVS checkout "ports" dir. * SVN anonymous root: svn://creme-brulee.marcuscom.com/ or svn://sushi.marcuscom.com/ (IPv6) * ViewVC: http://www.marcuscom.com:8080/viewvc/viewvc.cgi/marcuscom On-going efforts: * glib 2.36, pango 1.34.0, gtk 3.8.0 and gobject-introspection 1.36.0 where updated in the GNOME development repository. * Gustau Perez i Querol stepped up and started work on updating the old GNOME 3.4 ports to 3.6. At the moment of writing these are not available in the GNOME development repository just yet. For his efforts, he was awarded a FreeBSD GNOME team membership. * Jeremy Messenger (mezz) has completed Mate 1.6 which will be arriving in ports near you when deemed stable enough. If you want to help with keeping the documentation updated or helping out in other ways, even if it only parts for the Glib/Gtk/GNOME stack you are interested in, please contact us! Open tasks: 1. Update the FreeBSD.org/gnome website, in particular the developer information about USE_GNOME, maybe put that section in the Porter's Handbook instead. 2. Merge more updated ports from MC to ports. 3. Testing latest Glib/Gtk releases with existing ports, and import it into ports when it is ready. 4. After porting GNOME 3.6 run tests and fix bugs. __________________________________________________________________ Improving the Documentation Project Infrastructre URL: http://svnweb.freebsd.org/doc/projects/xml-tools/ Contact: G=C3=A1bor K=C3=B6vesd=C3=A1n There is an on-going work to improve the documentation infrastructure and modernize our documentation toolchain. The work can be found in the xml-tools branch and is very near to completion. The improvements include the following: * Upgrade to DocBook 4.5. * Use XSLT instead of DSSSL to render XHTML-based output. * Generate PDF from PS and simplify image processing. * Fix make lint and validate the whole documentation set. * Fix rendering of TOC elements. * Fix misused link elements that resulted in a corrupt rendering. * Use more human-friendly publication data and release info rendering. * Add support for XInclude in DocBook documents. * Add support for profiling with attributes. * Add support for Schematron constraints. * Add experimental epub support. * Add experimental support for XSL-FO-based printed output. * Clean up obsolete SGML constructs. * Clean up catalogs. * Drop HTML Tidy since it is not needed any more. The changes eliminate some dependencies and switch the doc repository to a real XML toolchain with proper validation and more advanced rendering tools. The only exceptions are Jade and the DSSSL stylesheets, which are still needed for printed output. Open tasks: 1. Fix rendering problems with images in printed formats. 2. Update the Documentation Primer to reflect changes. __________________________________________________________________ KDE/FreeBSD URL: http://FreeBSD.kde.org URL: http://FreeBSD.kde.org/area51.php Contact: KDE FreeBSD The KDE/FreeBSD Team is very proud to have Schaich Alonso (aschai) joining the team. Welcome! The KDE/FreeBSD Team have continued to improve the experience of KDE software and Qt under FreeBSD. The latest round of improvements include: * Fix problems establishing UDP connections. The Team have also made many releases and upstreamed many fixes and patches. The latest round of releases include: * KDE SC: 4.9.5, 4.10.1 (ports) * Qt: 5.0.0 (area51) and 4.8.4 (ports) * PyQt: 4.9.6 (ports); QScintilla 2.7 (ports); SIP: 4.14.2 (area51) and 4.14.3 (ports) * KDevelop: 4.4.1 (ports); KDevPlatform: 1.4.1 (ports) * Calligra: 2.5.5, 2.6.2 (ports) * Amarok: 2.7.0 * CMake: 2.8.10.2 * Digikam (and KIPI-plugins): 3.1.0 (area51) * QtCreator: 4.6.1 (ports) * KDE Telepathy 0.6.0 (area51) * many smaller ports As a result -- according to PortScout -- we have 431 ports, of which 93.5% (from 91%) are up-to-date. The Team are always looking for more testers and porters so please contact us and visit our home page. Open tasks: 1. Updating out-of-date ports, see PortScout for a list. __________________________________________________________________ Kernel Information in Process Core Dumps Contact: Mikolaj Golub When doing postmortem analysis of a crashed process it is sometimes very useful to have kernel information about the process at the moment of the crash, like open file descriptors or resource limits. For a live process this information can be obtained via sysctl(3) interface e.g. using procstat(1). The aim of the project is to add additional notes to a process core dump, which include process information from the kernel at the moment of the process crash, teach libprocstat(3) to extract this information and make procstat(1) use this functionality. At the moment all necessary code changes are committed to HEAD and are going to be merge to stable/9 in 1 month. __________________________________________________________________ mdoc.su -- Short Manual Page URLs URL: http://mdoc.su/ URL: http://nginx.conf.mdoc.su/mdoc.su.nginx.conf URL: https://github.com/cnst/mdoc.su URL: http://lists.freebsd.org/pipermail/freebsd-doc/2013-February/021465= .html Contact: Constantine A. Murenin mdoc.su is a deterministic URL shortener for BSD manual pages, written entirely in nginx.conf. Since the original announcement, OS version support has been added (e.g. /f91/ and /FreeBSD-9.1/ etc.), as well as dynamic multi-flavour web-pages with multiple links (e.g. http://mdoc.su/f,d/ifnet.9 and http://mdoc.su/-/mdoc), which even let you specify the versions too (e.g. http://mdoc.su/f91,n60,o52,d/mdoc). The source code for the whole site is available under a BSD licence. Open tasks: 1. Fork it on GitHub (see links)! __________________________________________________________________ Multipath TCP (MPTCP) for FreeBSD URL: http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html URL: http://caia.swin.edu.au/newtcp/mptcp/ URL: http://caia.swin.edu.au/reports/130424A/CAIA-TR-130424A.pdf URL: https://pub.allbsd.org/FreeBSD-snapshots/ Contact: Nigel Williams Contact: Lawrence Stewart Contact: Grenville Armitage We have been working to create a BSD-licensed implementation of Multipath TCP -- a set of TCP extensions that allow for transparent multipath operation with multiple IP addresses as specified in experimental RFC6824. We made our first v0.1 public release on 2013-03-11 and recently released v0.3 on 2013-04-16. The code is currently considered to be of alpha quality. We are working towards pushing the code into a FreeBSD Subversion repository project branch to continue the on-going development effort in a more publicly accessible location. As part of this move, we hope to begin releasing regular snapshot installer ISOs of the MPTCP project branch courtesy of Hiroki Sato and the allbsd.org daily snapshot infrastructure. We are about to release a CAIA technical report 130424A entitled "Design Overview of Multipath TCP version 0.3 for FreeBSD 10" on 2013-04-24 which provides a high-level design and architecture overview of the v0.3 code release. Going forward, we expect to continue development and release additional technical reports and academic papers covering topics such as performance analysis and multipath congestion control/scheduling. Open tasks: 1. The code is currently of alpha quality so we welcome all testing feedback, but please familiarize yourself with the README file and "Known Limitations" section in particular before jumping in. __________________________________________________________________ Native iSCSI Stack URL: https://wiki.freebsd.org/Native%20iSCSI%20target Contact: Edward Tomasz Napieral/a Focus of the project was extended to also include a new iSCSI initiator. Compared to the old one, it is more reliable, much more user-friendly, and somewhat faster. It uses exactly the same configuration file format as the old one to make migration easier. As for the target side, it was verified to work properly against major initiators (FreeBSD, Linux, Solaris, Windows and VMWare ESX). This project is being sponsored by FreeBSD Foundation. Open tasks: 1. RDMA support, for both the target and the initiator. 2. Performance optimization. __________________________________________________________________ PyPy URL: http://wiki.FreeBSD.org/PyPy Contact: David Naylor PyPy has been successfully updated to 2.0-beta1 with 2.0-beta2 finishing translating and other tests. Many major changes were made to the PyPy port fr the 2.0-beta1 release, these include: * Reworking the build script. * Optionally use pypy (when available) for self-translating. * Refine memory checks. * Fix the test target. Although the port is in a healthy state; PyPy on FreeBSD has some rough edges (see make test for examples of roughness). Open tasks: 1. Fix failed unit tests. 2. Integrate PyPy into bsd.python.mk. 3. See the project page for more items. __________________________________________________________________ racct: Block IO Accounting URL: https://wiki.freebsd.org/RudolfTomori/IOLimits Contact: Rudolf Tomori This project adds the block IO access accounting to the racct/rctl resource limiting framework, a working prototype implementation is available. __________________________________________________________________ Read-only Port of NetBSD's UDF File System URL: https://github.com/williamdevries/UDF Contact: Will DeVries An initial read-only port of NetBSD's UDF file system has been largely completed. (The UDF file system is often used on CD, DVD and Blu-Ray discs.) This port provides a number of advantages over FreeBSD's current UDF implementation, which include: * Support for version 2.60 of the UDF file system specification. FreeBSD's current implementation only partially supports version 1.5 of the standard, which was released in 1997. Since Windows and other systems support newer version of this file system, our users are left without the ability to read some media written by these systems. In addition, Blu-Ray discs are commonly written using version 2.50 or 2.60. * The ability to override the owner and group for all the files and directories on a UDF volume using mount options. * The ability to set the owner and group for files and directories that lack defined owner or group information using mount options. (The UDF specification allows for files and directories without owners or groups.) * The ability to override the mode for all directories and files on a volume using mount options. * Support for mounting previous versions of incrementally recorded media, like CD-Rs. __________________________________________________________________ TCP-AO Authentication Option URL: http://svnweb.freebsd.org/base/user/andre/tcp-ao/ Contact: Andr=C3=A9 Oppermann Work is under way to implement TCP-AO (TCP Authentication Option) according to RFC5925 and RFC5926. TCP-AO is an extension to TCP-MD5 signatures commonly used in routers to secure BGP routing protocol sessions against spoofing attacks. The work is under contract and sponsored by Juniper Networks. __________________________________________________________________ The entities Documentation Branch URL: http://svnweb.freebsd.org/doc/projects/entities/ Contact: Ren=C3=A9 Ladan The entities branch was created to reduce duplication of committer entities. Currently there is one in authors.ent (with email addresses) and another one in developers.ent (without email addresses). This seems to be a leftover from the doc/www split in earlier times. To remedy this, developers.ent is merged into authors.ent and entities with email addresses are postfixed as such. Apart from the instructions for the initial commit, there should be little user-visible changes. Some related cleanups, like cleaning up team definitions, replacing literal names by entities from authors.ent, and adding missing names to authors.ent are also made. Open tasks: 1. Finish processing of the tag. 2. Send out a CFT. 3. Merge back into head branch. __________________________________________________________________ The FreeBSD Japanese Documentation Project URL: http://www.FreeBSD.org/ja/ URL: http://www.jp.FreeBSD.org/doc-jp/ Contact: Hiroki Sato Contact: Ryusuke Suzuki Web page (htdocs): Newsflash and some other updates in the English version have been translated to keep them up-to-date. Specifically, the release related contents were updated in this period. Books: FreeBSD Handbook has constantly been updated since the last report; particularly, "ports", "desktop" section were largely updated. Some progress has been made in the "advanced-networking" section, contributed by a new translator. "Writing FreeBSD Problem Reports" article is now in sync with the English version. Open tasks: 1. Further translation work of outdated documents in ja_JP.eucJP subtree. __________________________________________________________________ UFS/FFS Performance Work URL: http://www.mckusick.com/publications/faster_fsck.pdf Contact: Kirk McKusick Some work on the performance of UFS/FFS has been recently committed to HEAD. The purpose of the corresponding change to the FFS layout policy is to reduce the running time for a full file system check. It also reduces the random access time for large files and speeds up the traversal time for directory tree walks. The key idea is to reserve a small area in each cylinder group immediately following the inode blocks for the use of metadata, specifically indirect blocks and directory contents. The new policy is to preferentially place metadata in the metadata area and everything else in the blocks that follow the metadata area. The size of this area can be set when creating a filesystem using newfs(8) or changed in an existing filesystem using tunefs(8). Both utilities use the -k held-for-metadata-blocks option to specify the amount of space to be held for metadata blocks in each cylinder group. By default, newfs(8) sets this area to half of minfree (typically 4% of the data area). As with all layout policies, it only affect layouts of things allocated after it is put in place. So these changes will primarily be noticable on newly created file systems. File system checks have been sped up by caching the cylinder group maps in pass1 so that they do not need to be read again in pass5. As this nearly doubles the memory requirement for fsck(8), the cache is thrown away if other memory needs in fsck(8) would otherwise fail. Thus, the memory footprint of fsck(8) remains unchanged in memory constrained environments. This optimization will be evident on all UFS/FFS filesystems. This work was inspired by a paper presented at Usenix's FAST '13. Open tasks: 1. MFC to 9-STABLE and possibly 8-STABLE should happen by May unless problems arise with these changes in HEAD. __________________________________________________________________ Wine32 on FreeBSD/amd64 URL: http://wiki.freebsd.org/i386-Wine Contact: David Naylor The i386-wine port (formally wine-fbsd64) has been added to the ports collection (as emulators/i386-wine-devel). Although the port can only be compiled under a x86 32-bit system the resulting package can be installed on a x86 64-bit system and enable running of 32-bit Microsoft Windows programs. Packages for the port are in development and should be announced shortly on the freebsd-questions and freebsd-emulation mailing lists. There are some issues with Wine32 on FreeBSD/amd64 -- possibly related to FreeBSD32_COMPACT, or other general 32/64-bit issues -- that could do with some focus. Open tasks: 1. Port wine64 to FreeBSD. 2. Port WoW64 (wine32 and wine64 together) to FreeBSD. 3. Fix 32- and 64-bit issues (such as Intel graphics not accelerating). __________________________________________________________________ Xfce/FreeBSD URL: https://wiki.FreeBSD.org/Xfce URL: http://people.freebsd.org/~olivierd/patches/midori-0.4.9_0.5.0.diff Contact: FreeBSD Xfce Team The Xfce FreeBSD Team has updated many ports, especially: * tumbler: 0.1.27 (add new option, COVER) * Parole: 0.5.0 * xfdesktop: 4.10.2 * Midori: 0.4.9 (full compatible with Vala 0.18), 0.5.0 is available (see links) * Orage: 4.8.4 * xfce4-terminal: 0.6.1 (renamed by upstream, previous name was Terminal) This last application contains drop-down functionality, new window slides down from the top of the screen when key (we can define keyboard shortcut) is pressed. Open tasks: 1. Replace libxfce4gui (deprecated and not maintained by upstream) by libxfce4ui in order to enhance support panel plugins for Xfce >=3D 4.10. 2. Work on Midori Gtk3 port. 3. Fix gtk-xfce-engine with Gtk+ >=3D3.6. __________________________________________________________________ xorg on FreeBSD URL: http://wiki.freebsd.org/Xorg URL: http://people.freebsd.org/~zeising/xorg-7.7.diff URL: http://trillian.chruetertee.ch/ports/browser/trunk URL: http://trillian.chruetertee.ch/ports/browser/branches/xorg-7.7 Contact: FreeBSD X11 Team Contact: Niclas Zeising Contact: Koop Mast Most of the work during this period has been in updating, testing and stabilizing the development repository. A number of xorg applications and various other leaf ports has been committed as part of this effort. After this a CFT was sent out asking for help in testing the remaining bits in development, including updates to all major libraries and xorg-server. Currently, the CFT patch has been submitted for an exp-run to iron out any final bugs. The plan is to merge it sometime after FreeBSD 8.4 is released and the ports tree is reopened for commits. Work is also on-going to port new versions of MESA and OpenGL, as well as a new version of xorg-server, and perhaps in the future, Wayland. These are considered more long-term goals and are not targeted for the current update. Open tasks: 1. Decide how to handle the new and old xorg distributions. In recent xorg, a lot of legacy driver support has been dropped, therefore we need to maintain two xorg distributions to not lose a lot of hardware drivers. Currently, this is done by setting the flag WITH_NEW_XORG in /etc/make.conf, but a more practical solution is needed. This is especially important since the flag is not very user-friendly, and since there currently will be no official packages for the new distribution. 2. Continue to test and update xorg related ports. There are new versions of xserver, as well as MESA and related OpenGL libraries which needs to be ported and eventually integrated into the ports tree. 3. Port Wayland. The future of graphical environments in open source operating systems seems to be Wayland. This needs to be ported to FreeBSD so that a wider audience can test it, and so that it eventually can be integrated into the ports tree, perhaps as a replacement for the current xorg. 4. Look into replacements for HAL. HAL is used for hot-plugging of devices, but it has been long abandoned by Linux. A replacement, perhaps build on top of devd would be nice to have. This work should be coordinated with the FreeBSD GNOME and KDE teams. __________________________________________________________________ From owner-freebsd-hackers@FreeBSD.ORG Sun May 12 18:56:54 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DF566554; Sun, 12 May 2013 18:56:54 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 89F9C98F; Sun, 12 May 2013 18:56:54 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id un3so794108obb.5 for ; Sun, 12 May 2013 11:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=AlYy3tO43JYaan/9H2V4y2UM9PgQQ+RI/HNMFRv1Go0=; b=WP2COk1Zx6lNZYtI2e939viqdSZtgbJGDEKEAUjq9gQUBQ49d+I0U2fjmu56Z3D9sJ Tm61zTOPhZWvP0C1SPLfme42w/HKcYOumdGOcjK2hqyT22/pxH1++O55pKRaE+kCPwiU 8m28TmVJn7+gMTmGlCWu2rqidquFSPpCdTX7XhCzwJvelAywZjw7BHTjoUMqypgfd91p 3cVz0nZTjheVPz6DxzDmm6aqAGHEiAoJpgNkIfz6PJXoz8hG/xATvL1RgAzSFCrnGD79 Wgv8KBe1OD4KRZWrg5vz+G1Fmls2ivlPdfaKRncj9I5BsF3FIJEJOevetyZdwtDLtkDc /Owg== MIME-Version: 1.0 X-Received: by 10.60.56.132 with SMTP id a4mr2534426oeq.113.1368385013793; Sun, 12 May 2013 11:56:53 -0700 (PDT) Received: by 10.76.96.49 with HTTP; Sun, 12 May 2013 11:56:53 -0700 (PDT) In-Reply-To: <20130512195405.04653b64@funktor> References: <20130512195405.04653b64@funktor> Date: Sun, 12 May 2013 14:56:53 -0400 Message-ID: Subject: Re: FreeBSD Quarterly Status Report, January-March 2013 From: Outback Dingo To: Gabor Pali Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: stable@freebsd.org, hackers@freebsd.org, current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 18:56:55 -0000 __________________________________________________________________ > > FreeNAS > > URL: http://www.FreeNAS.org/ > > Contact: Alfred Perlstein > Contact: Josh Paetzel > > FreeNAS 8.3.1-RELEASE-p2 will hit Sourceforge the second week of April, > and should end up as the last FreeNAS release based on FreeBSD 8.X It's > currently the only Free Open Source NAS product available with any form > of ZFS encryption (provided by GELI). > > Open tasks: > > 1. The team is hard at work on getting a FreeBSD 9.X-based release of > FreeNAS ready. Currently there are several nightly snapshots > available. > 2. Add HAST to the webinterface. > 3. Migrate to NFSv4. > 4. Integrate foundation sponsored kernel iSCSI target. > Uhmmmmmm WHAT??? FreeNAS is not the only Free Open Source NAS product available with any form of ZFS encryption (provided by GELI). NAS4Free has been doing it. From owner-freebsd-hackers@FreeBSD.ORG Mon May 13 06:37:20 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7B82FD84 for ; Mon, 13 May 2013 06:37:20 +0000 (UTC) (envelope-from comnetboy@gmail.com) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by mx1.freebsd.org (Postfix) with ESMTP id 4E81B930 for ; Mon, 13 May 2013 06:37:20 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id xn12so6106558obc.24 for ; Sun, 12 May 2013 23:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=oTknTs9rbKGYEkGn4cUvtCMabBzhbqtSsxYrr8l5EEM=; b=zElTAtFxlEq7qhbCnftOEnQ5OCGNvb2Lc2hjRp4yUI5hPIZT5MH8ZdGar3L4pFXhDq jibnQ13E8ODRFKYJTaRqt+6w8C5RBaq55jl7bNWzT+GdjooKNfEuAaIcUhe5AvM3kXYB rpl5edWQ6Pp8fu1rS4oYEUDTIjC6c/2tfQTJ5iWCWHRkyrlCn8QjhQt77i9c3FDN057X SujuJ+AgHBKWfx+KaAg7snXeaI/65U5tHId6lZqKJkIz2RO317WztvCO4rIoN+7ny9M1 Mxsr7TVUVvWaAlCi59OkzPuVFDsxrZv66/OG1lS2vK7a8WwZEIl/+ov6cvUk37cqptI+ KueQ== MIME-Version: 1.0 X-Received: by 10.60.115.73 with SMTP id jm9mr4661178oeb.126.1368427039856; Sun, 12 May 2013 23:37:19 -0700 (PDT) Received: by 10.182.103.5 with HTTP; Sun, 12 May 2013 23:37:19 -0700 (PDT) Date: Mon, 13 May 2013 11:07:19 +0430 Message-ID: Subject: A problem with alq module! From: Computer Network Man To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Mon, 13 May 2013 11:38:04 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 06:37:20 -0000 Dear Guys; In a fresh FreeBSD 9 or 9.1 Release if you just run these commands: # kldload alq # kldunload alq # init 0 or shutdown -p now it will panic! maybe it's a bug. We have a module which uses alq API's. MODULE_DEPEND(mymodule, alq, 1, 1, 1) when our module starts, loads alq. and when it stops, unloads alq. So after starting and stoping our module and shutdown, we have panic. any opinion in this regard would be appreciated. From owner-freebsd-hackers@FreeBSD.ORG Mon May 13 15:19:53 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 69313DF6 for ; Mon, 13 May 2013 15:19:53 +0000 (UTC) (envelope-from shiretu@gmail.com) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by mx1.freebsd.org (Postfix) with ESMTP id F3745EE0 for ; Mon, 13 May 2013 15:19:52 +0000 (UTC) Received: by mail-ee0-f47.google.com with SMTP id t10so1048611eei.6 for ; Mon, 13 May 2013 08:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:date:subject:to:message-id :mime-version:x-mailer; bh=jip9gP9EbwpLUtrFxxYwDihKGvICKPdmKd7Uq9+HQK0=; b=ERtwyiELxCfgYq9OcplF6ipgDCyVYmL1aM1WhSjNsQ5kI10z+ORyNnX3x0cGQ1Xn5p Vp5vwCpOStqC6OxQhyud0+bNx1mYi2mN5omXT9Xsm3nwz3qFyekt7EqHPb/f2Ld/6yFm nFMMa8f/4lbsLdjT1JEVb22e4v0SeITSFj6NCtmgMKW+CnN/iPnnvMQbdKzSR76215Yk RI3vw/J8ziOm0Nlj6R32NV+67zzvbEes5ESBftquZh2B2LpTSEdaeQM6+fhJ34zSj1ZZ 4IXeMYMcEBBAsFV4rxwNz48QdiIlNaCMS8xMnyziw0ocBuVhp+myQ2q3E7LezhlO17pq Sikg== X-Received: by 10.14.109.131 with SMTP id s3mr79432767eeg.26.1368458386315; Mon, 13 May 2013 08:19:46 -0700 (PDT) Received: from [10.0.1.4] ([188.26.136.91]) by mx.google.com with ESMTPSA id e50sm23564160eev.13.2013.05.13.08.19.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 May 2013 08:19:45 -0700 (PDT) From: Eugen-Andrei Gavriloaie Content-Type: multipart/signed; boundary="Apple-Mail=_DEAB8EC6-1EB6-4F18-8B38-E783ED902DC7"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 13 May 2013 18:19:43 +0300 Subject: Managing userland data pointers in kqueue/kevent To: freebsd-hackers@freebsd.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 15:19:53 -0000 --Apple-Mail=_DEAB8EC6-1EB6-4F18-8B38-E783ED902DC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello to all, I'm trying to reply to this thread: = http://lists.freebsd.org/pipermail/freebsd-hackers/2010-November/033565.ht= ml I also faced this very difficult task of tracking down the user data = registered into kq. I end up having some "Tokens" instances which I never deallocate but = always re-use them or create new ones if necessary. This tokens are used = as user data for kq. They are keeping the actual pointers inside them, = and the pointer itself has a reference to the Token. When the pointer = dies, I reset the guts of the token. When the time comes to use the = token, I have the guarantee is not the corpse of a token (never = deallocate them, remember?) and I can see that the actual pointer was = gone, everyone is happy. At the application shutdown, I cleanup the mess = (the tokens). However, I just want to say that Paul has a valid point = when he is wondering why EV_FREEWATCH was not provisioned/implemented.=20= The moment we throw multi-threading into equation, this becomes a = extremely hard thing to manage (close to impossible), including my = "proven-to-work" Token trick. It renders the user data pointer = completely useless because in the end we need to keep an association map = inside user space. That is forcing user space code to do a lookup before = use, instead of straightforward use. Not to mention the fact that we = need to perform a lock before searching it. That brings havoc on kernel = side on 1000+ active connections (a multi-threaded streaming server for = example).=20 I'm pretty sure this user data pointer is also breaking a well known = pointer management paradigm, but I just can't remember which. = Regardless, it has all the ingredients for memory leaks and/or, the = worst one, use of corpse pointers which are bound to crash the app. I = agree, C/C++ is not for the faint of heart, but with little or close to = no efforts, his EV_FREEWATCH can be put to very good use, and user space = code not only becomes less prone to mem issues, but also cleaner. To summarise, +1 for the EV_FREEWATCH. I simply love the idea! Clean and = very very efficient. Best regards, Andrei ------ Eugen-Andrei Gavriloaie Web: http://www.rtmpd.com --Apple-Mail=_DEAB8EC6-1EB6-4F18-8B38-E783ED902DC7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO5jCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFIzCCBAugAwIBAgIQY7lP +MJT4QzHh5dD4LWVRzANBgkqhkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdy ZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExp bWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQTAeFw0xMjA4MjEwMDAwMDBaFw0xMzA4MjEyMzU5NTlaMCIxIDAeBgkqhkiG9w0BCQEW EXNoaXJldHVAZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAziBH0E99 6jx0UrKapQcbxgWLgux1j9/Ec7K3QkkFtzCgxtF9ohpfsiAVOkYuCzVxoxoC0eNKO4qbZPYNbsN6 gtVZMrQnphgG3Wzmf28azn60TtCEQNoFXdW4On+cZgcvUxZS09DaPuTrHB5BuOmYG7b93ZjvJuov KCYAjYNrg0S9TKTQdRJAu95E2OuoVzin+QwIfEVwOA+PSRTPbNnjHvHUMg2G98CXFKIYPy9Pz8Kk rd54q7eSanjNiQK4Z9UYFjjNokx0nhymUAlnzWDAPj8jlh5i6gPrWsr9mYmQ6Y9wm2RHyf7QA6nM BIO43JNPklqjUT5LnB47rxVnLKnYmQIDAQABo4IB4TCCAd0wHwYDVR0jBBgwFoAUehNOAHRbxnhj ZCfBL+KgW7x5xXswHQYDVR0OBBYEFFoYqkq01lUdSiemIAjKHTuJiRj9MA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9D T01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHAYDVR0RBBUwE4ERc2hpcmV0dUBnbWFpbC5jb20w DQYJKoZIhvcNAQEFBQADggEBAHOQHTMzyiauVSuvCNgN2laY11tdDegdalfDK8UIFpdv08TE1viQ Q9gQfJpGNiO4wxpK8NeB8Qkh+AlL9ygq3jNwuAhk+TXMJ4Jr/I7LkTyJFnW45ADLZs/ufAbc+gdK lxdIxRJBOHmEpA51h0beSlfgHZcvvGshESzwLF290LuEdmLWncIWbhuO4vOJRK/7wJ/KXD8bZdx5 LGvA/QPPi5u95zFoQPRLSDl7lqJailBJZe6YFs7zBK2lm3u0w7exJw/rYeXFjMR0g5BPQCiihMq5 77k2T7uKmQqzapeCqLcd0sFNi94lzgSJxaQDyiDZYeYjWX0lSNVEG0z/fCIVJj4xggOrMIIDpwIB ATCBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQY7lP+MJT4QzHh5dD4LWV RzAJBgUrDgMCGgUAoIIB1zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA1MTMxNTE5NDRaMCMGCSqGSIb3DQEJBDEWBBRhiQeKFB9pcKDGPvguNmPQOfgTKzCBuQYJ KwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UE AxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBjuU/4 wlPhDMeHl0PgtZVHMIG7BgsqhkiG9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNV BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNl Y3VyZSBFbWFpbCBDQQIQY7lP+MJT4QzHh5dD4LWVRzANBgkqhkiG9w0BAQEFAASCAQCuNbVD8rRC kCMiQgc5D1T2wkyqUCMfxpa/xr2k8FRz8EpWq4vCGklqIozJJorph3nDG8iwmlC5jH10TpEAWPQ+ dNk7MSmuwX4Lf7E230T17B3HiQAgwBv/5uwTLnebVv2U2ShbaEmhaD6se9GkAgCZzmNO6kBVUTuD MwnzsDUAl+iyZ8r0rKknblA9bSM6hkvnxAwyc1vCaiodnH4LpBEfipmHfxiRQSiOc9De1FhFuf+Y aJst5mipFhj5PXVsiincjXx4xbMVGIMbn6tNxUOVoQjar6dH7sxq5zJ4Xk6a4mfGREPEBoLNJexs qKpctLIJ0s4PCA0qKJhTaxNdc8UVAAAAAAAA --Apple-Mail=_DEAB8EC6-1EB6-4F18-8B38-E783ED902DC7-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 13 15:25:18 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1631120E for ; Mon, 13 May 2013 15:25:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id A571EF97 for ; Mon, 13 May 2013 15:25:17 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id x53so6347414wes.5 for ; Mon, 13 May 2013 08:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iaR8TxE59O/dVqdQUM0kUIdQt/CaeOeLj8dJF67ZLOo=; b=bnfsnxe3DFSi+22/BNDxu5dbGMsYCpnP9YVH1+tfDcPCFvsmFO/33zkodGQh11T8Mw MR/fCaUZILTS8LehJHRd8W19sgTjx13eBcXWgKcphmnNhYsKlIPzreHn8g0aLKMAU2qJ i+ExFiyusTe0rsgZN1pfJAG+33jj0RFJGcGCXB53xlcSyrxoAsaZ5s5W91zyVf7k7IfX p+Kl9eBhYNpZioYGb1UOwpuLtP9cB++I62tYIW2aIN0D9+7I8QJiuKQsM7G9R7oRYszX 1uDyxJ2y31fG18A/YgP9SQDjGbYlVvtmxZgEQPodK8K3nBkS4bB/D7yfZwBX8SusOoZR kc4A== MIME-Version: 1.0 X-Received: by 10.180.88.162 with SMTP id bh2mr19927105wib.3.1368458716714; Mon, 13 May 2013 08:25:16 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Mon, 13 May 2013 08:25:16 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 May 2013 08:25:16 -0700 X-Google-Sender-Auth: KoqulNAlwCyN8vdLl98Pfp3yinU Message-ID: Subject: Re: Managing userland data pointers in kqueue/kevent From: Adrian Chadd To: Eugen-Andrei Gavriloaie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 15:25:18 -0000 ... or you could just track the per-descriptor / per-object stuff in userland, and use the FD/signal as an index into the state you need. adding thread happiness on top of that is trivial. Done/done. Adrian On 13 May 2013 08:19, Eugen-Andrei Gavriloaie wrote: > Hello to all, > > I'm trying to reply to this thread: > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-November/033565.h= tml > > I also faced this very difficult task of tracking down the user data regi= stered into kq. > I end up having some "Tokens" instances which I never deallocate but alwa= ys re-use them or create new ones if necessary. This tokens are used as use= r data for kq. They are keeping the actual pointers inside them, and the po= inter itself has a reference to the Token. When the pointer dies, I reset t= he guts of the token. When the time comes to use the token, I have the guar= antee is not the corpse of a token (never deallocate them, remember?) and I= can see that the actual pointer was gone, everyone is happy. At the applic= ation shutdown, I cleanup the mess (the tokens). However, I just want to sa= y that Paul has a valid point when he is wondering why EV_FREEWATCH was not= provisioned/implemented. > > The moment we throw multi-threading into equation, this becomes a extreme= ly hard thing to manage (close to impossible), including my "proven-to-work= " Token trick. It renders the user data pointer completely useless because= in the end we need to keep an association map inside user space. That is f= orcing user space code to do a lookup before use, instead of straightforwar= d use. Not to mention the fact that we need to perform a lock before search= ing it. That brings havoc on kernel side on 1000+ active connections (a mul= ti-threaded streaming server for example). > > I'm pretty sure this user data pointer is also breaking a well known poin= ter management paradigm, but I just can't remember which. Regardless, it ha= s all the ingredients for memory leaks and/or, the worst one, use of corpse= pointers which are bound to crash the app. I agree, C/C++ is not for the f= aint of heart, but with little or close to no efforts, his EV_FREEWATCH can= be put to very good use, and user space code not only becomes less prone t= o mem issues, but also cleaner. > > To summarise, +1 for the EV_FREEWATCH. I simply love the idea! Clean and = very very efficient. > > Best regards, > Andrei > > ------ > Eugen-Andrei Gavriloaie > Web: http://www.rtmpd.com > From owner-freebsd-hackers@FreeBSD.ORG Mon May 13 15:37:18 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 23529AF1; Mon, 13 May 2013 15:37:18 +0000 (UTC) (envelope-from shiretu@gmail.com) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 74763110; Mon, 13 May 2013 15:37:17 +0000 (UTC) Received: by mail-ea0-f170.google.com with SMTP id f15so2319364eak.29 for ; Mon, 13 May 2013 08:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=9uRQsIQKkfBSQHvmyJNxI3q6nNKIQ+ry6tKFgk4aDQ4=; b=LJv1qtS4Rp6xDXukIcpbFnNn8krbkrFr+Y8W1+atgQ6/AO8BKIy+pR20ogy6/F/SoY Uf6PhCWTHkBHXs/kz3IDWpWkCyyMYoAcO7yjTViY7oAjyF36NmSaHbIA/mZJr5GwiJi/ vSyIdSDOYLy+pmIjT7kpeWOjdyIIz65IgmURH+rOQ62OfeWqUPNH3JKgON+xkRBDM8b1 sJiTAf8L64wgf6HPodiEMgrFii/RSoa3n/msckadQADbKXG6H9AIU3MdkyTNNReU0Dkn Siw3PWSdEfGhfy7jid3QMMLDXWKM3vk8s4WNiy4LnFL6T+nT7/3pSd1nCKoSlHIp3rZQ +Idw== X-Received: by 10.14.1.7 with SMTP id 7mr37131488eec.41.1368459436633; Mon, 13 May 2013 08:37:16 -0700 (PDT) Received: from [10.0.1.4] ([188.26.136.91]) by mx.google.com with ESMTPSA id s8sm23681226eeo.4.2013.05.13.08.37.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 May 2013 08:37:15 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C994B0A1-66E0-4EED-9E81-396CBD4C9EA8"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Managing userland data pointers in kqueue/kevent From: Eugen-Andrei Gavriloaie In-Reply-To: Date: Mon, 13 May 2013 18:37:13 +0300 Message-Id: <84DCA050-99D4-4B22-A031-35E0928709E0@gmail.com> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1503) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 15:37:18 -0000 --Apple-Mail=_C994B0A1-66E0-4EED-9E81-396CBD4C9EA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Well, Paul already asked this question like 3-4 times now. Even = insisting on it. I will also ask it again: If user code is responsible of tracking down the data associated with = the signalled entity, what is the point of having user data? Is rendered completely useless=85 Not to mention, that your suggestion with FD index is a definite no-go. = The FD values are re-used. Especially in MT environments. Imagine one = kqueue call taking place in thread A and another one in thread B. Both = threads waiting for events. When A does his magic, because of internal business rules, it decides to = close FD number 123. It closes it and it connects somewhere else by = opening a new one. Surprise, we MAY get the value 123 again as a new = socket, we put it on our index, etc. Now, thread B comes in and it has = stale/old events for the old 123 FD. Somethings bad like EOF for the OLD = version of FD number 123 (the one we just closed anyway). Guess what=85 = thread B will deallocate the perfectly good thingy inside the index = associated with 123. And regarding the "thread happiness", that is not happiness at all IMHO=85= Best regards, Andrei ------ Eugen-Andrei Gavriloaie Web: http://www.rtmpd.com On May 13, 2013, at 6:25 PM, Adrian Chadd wrote: > ... or you could just track the per-descriptor / per-object stuff in > userland, and use the FD/signal as an index into the state you need. >=20 > adding thread happiness on top of that is trivial. >=20 > Done/done. >=20 >=20 >=20 >=20 > Adrian >=20 > On 13 May 2013 08:19, Eugen-Andrei Gavriloaie = wrote: >> Hello to all, >>=20 >> I'm trying to reply to this thread: >> = http://lists.freebsd.org/pipermail/freebsd-hackers/2010-November/033565.ht= ml >>=20 >> I also faced this very difficult task of tracking down the user data = registered into kq. >> I end up having some "Tokens" instances which I never deallocate but = always re-use them or create new ones if necessary. This tokens are used = as user data for kq. They are keeping the actual pointers inside them, = and the pointer itself has a reference to the Token. When the pointer = dies, I reset the guts of the token. When the time comes to use the = token, I have the guarantee is not the corpse of a token (never = deallocate them, remember?) and I can see that the actual pointer was = gone, everyone is happy. At the application shutdown, I cleanup the mess = (the tokens). However, I just want to say that Paul has a valid point = when he is wondering why EV_FREEWATCH was not provisioned/implemented. >>=20 >> The moment we throw multi-threading into equation, this becomes a = extremely hard thing to manage (close to impossible), including my = "proven-to-work" Token trick. It renders the user data pointer = completely useless because in the end we need to keep an association map = inside user space. That is forcing user space code to do a lookup before = use, instead of straightforward use. Not to mention the fact that we = need to perform a lock before searching it. That brings havoc on kernel = side on 1000+ active connections (a multi-threaded streaming server for = example). >>=20 >> I'm pretty sure this user data pointer is also breaking a well known = pointer management paradigm, but I just can't remember which. = Regardless, it has all the ingredients for memory leaks and/or, the = worst one, use of corpse pointers which are bound to crash the app. I = agree, C/C++ is not for the faint of heart, but with little or close to = no efforts, his EV_FREEWATCH can be put to very good use, and user space = code not only becomes less prone to mem issues, but also cleaner. >>=20 >> To summarise, +1 for the EV_FREEWATCH. I simply love the idea! Clean = and very very efficient. >>=20 >> Best regards, >> Andrei >>=20 >> ------ >> Eugen-Andrei Gavriloaie >> Web: http://www.rtmpd.com >>=20 --Apple-Mail=_C994B0A1-66E0-4EED-9E81-396CBD4C9EA8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO5jCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFIzCCBAugAwIBAgIQY7lP +MJT4QzHh5dD4LWVRzANBgkqhkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdy ZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExp bWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQTAeFw0xMjA4MjEwMDAwMDBaFw0xMzA4MjEyMzU5NTlaMCIxIDAeBgkqhkiG9w0BCQEW EXNoaXJldHVAZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAziBH0E99 6jx0UrKapQcbxgWLgux1j9/Ec7K3QkkFtzCgxtF9ohpfsiAVOkYuCzVxoxoC0eNKO4qbZPYNbsN6 gtVZMrQnphgG3Wzmf28azn60TtCEQNoFXdW4On+cZgcvUxZS09DaPuTrHB5BuOmYG7b93ZjvJuov KCYAjYNrg0S9TKTQdRJAu95E2OuoVzin+QwIfEVwOA+PSRTPbNnjHvHUMg2G98CXFKIYPy9Pz8Kk rd54q7eSanjNiQK4Z9UYFjjNokx0nhymUAlnzWDAPj8jlh5i6gPrWsr9mYmQ6Y9wm2RHyf7QA6nM BIO43JNPklqjUT5LnB47rxVnLKnYmQIDAQABo4IB4TCCAd0wHwYDVR0jBBgwFoAUehNOAHRbxnhj ZCfBL+KgW7x5xXswHQYDVR0OBBYEFFoYqkq01lUdSiemIAjKHTuJiRj9MA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9D T01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHAYDVR0RBBUwE4ERc2hpcmV0dUBnbWFpbC5jb20w DQYJKoZIhvcNAQEFBQADggEBAHOQHTMzyiauVSuvCNgN2laY11tdDegdalfDK8UIFpdv08TE1viQ Q9gQfJpGNiO4wxpK8NeB8Qkh+AlL9ygq3jNwuAhk+TXMJ4Jr/I7LkTyJFnW45ADLZs/ufAbc+gdK lxdIxRJBOHmEpA51h0beSlfgHZcvvGshESzwLF290LuEdmLWncIWbhuO4vOJRK/7wJ/KXD8bZdx5 LGvA/QPPi5u95zFoQPRLSDl7lqJailBJZe6YFs7zBK2lm3u0w7exJw/rYeXFjMR0g5BPQCiihMq5 77k2T7uKmQqzapeCqLcd0sFNi94lzgSJxaQDyiDZYeYjWX0lSNVEG0z/fCIVJj4xggOrMIIDpwIB ATCBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQY7lP+MJT4QzHh5dD4LWV RzAJBgUrDgMCGgUAoIIB1zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA1MTMxNTM3MTRaMCMGCSqGSIb3DQEJBDEWBBRlygkOdFbH71GuCSolNN2/AEc3wDCBuQYJ KwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UE AxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBjuU/4 wlPhDMeHl0PgtZVHMIG7BgsqhkiG9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNV BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNl Y3VyZSBFbWFpbCBDQQIQY7lP+MJT4QzHh5dD4LWVRzANBgkqhkiG9w0BAQEFAASCAQAt2uMcUqu8 ud3CnJfnlwKW+F28jHGLidDrUj4xagK2h02c8Z9ACSql2w80i05ef5yvgmEdzAgNrs/4App52FaF k+JFHzI2ImfrGGGHRUXHPdEUquSsPuul9xTUtn9OD/YJAv7O3eamaYcqgAxA70+l1gvkixtfri5k QBwYvax0jOn1qWJFS514KkXZZNp7SciFG5Yoy+mRB3lwgSJ1EVPqystTN5FBDlK5SlCeups1/Pns svACNarmK1UOHtpdYr4glcQh5uFhrC0LpGwyR5VLRikHtYI5Rn5aSgOlOpqxds/ZC6Dy0abmzpdO KEfOXkKuEga6Ls+0D3Z6mDQAkDxOAAAAAAAA --Apple-Mail=_C994B0A1-66E0-4EED-9E81-396CBD4C9EA8-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 13 15:47:58 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A78956FB for ; Mon, 13 May 2013 15:47:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by mx1.freebsd.org (Postfix) with ESMTP id 404181DB for ; Mon, 13 May 2013 15:47:58 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id hn14so784775wib.4 for ; Mon, 13 May 2013 08:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PseOvFDHnkt9Jp+m0maI6c7/prY+PAsDr0IQkjSrEQA=; b=QT53A+amYQYyCtlwTTRUNA0OssmDvaRABtwye8fVDXcYrSoIJznFwfv83d3BAxcrnd GE2xeCZn1KORHA6+q6aJJwD4MkI/l+A9y+RZuLKJLwrrbs8kQIZjyXHt76mXJGrkhYOL e3WZWxB7+RywEidtBfh6CVWYmt5KLkD1UXJ31f7r/fg/fQ29wI8CbLrJi9QRow6KKRBL lWW/wlQ8wjw+i6UWo91ySirt7j0WylwJ6dmQv2i1YBL6OEvGx5jyaYTUOMBsZ+ZaQuDH sph7wMiSqbP5ieyw9NThtXcYfd6qWjVoCyuyw7L6aBj/pM+Eta/Uvvr9ZZPuGNL8M4Tp xASQ== MIME-Version: 1.0 X-Received: by 10.180.37.229 with SMTP id b5mr6288895wik.29.1368460077380; Mon, 13 May 2013 08:47:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Mon, 13 May 2013 08:47:57 -0700 (PDT) In-Reply-To: <84DCA050-99D4-4B22-A031-35E0928709E0@gmail.com> References: <84DCA050-99D4-4B22-A031-35E0928709E0@gmail.com> Date: Mon, 13 May 2013 08:47:57 -0700 X-Google-Sender-Auth: t9TIpntiDRPtceO6j6CK3sKEfac Message-ID: Subject: Re: Managing userland data pointers in kqueue/kevent From: Adrian Chadd To: Eugen-Andrei Gavriloaie Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 15:47:58 -0000 ... holy crap. On 13 May 2013 08:37, Eugen-Andrei Gavriloaie wrote: > Hi, > > Well, Paul already asked this question like 3-4 times now. Even insisting= on it. I will also ask it again: > If user code is responsible of tracking down the data associated with the= signalled entity, what is the point of having user data? > Is rendered completely useless=85 .. why does everything have to have a well defined purpose that is also suited for use in _all_ situations? > Not to mention, that your suggestion with FD index is a definite no-go. T= he FD values are re-used. Especially in MT environments. Imagine one kqueue= call taking place in thread A and another one in thread B. Both threads wa= iting for events. .. so don't do that. I mean, you're already having to write your code to _not_ touch FDs in other threads. I've done this before, it isn't that hard and it doesn't hurt performance. > When A does his magic, because of internal business rules, it decides to = close FD number 123. It closes it and it connects somewhere else by opening= a new one. Surprise, we MAY get the value 123 again as a new socket, we p= ut it on our index, etc. Now, thread B comes in and it has stale/old events= for the old 123 FD. Somethings bad like EOF for the OLD version of FD numb= er 123 (the one we just closed anyway). Guess what=85 thread B will dealloc= ate the perfectly good thingy inside the index associated with 123. So you just ensure that nothing at all calls a close(123); but calls fd_close(123) which will in turn close(123) and free all the state associated with it. You have fd_close() either grab a lock, or you ensure that only the owning thread can call fd_close(123) and if any other thread calls it, the behaviour is undefined. > And regarding the "thread happiness", that is not happiness at all IMHO= =85 Unless you're writing a high connection throughput web server, the overhead of grabbing a lock in userland during the fd shutdown process is trivial. Yes, I've written those. It doesn't hurt you that much. I'm confused as to why this is still an issue. Sure, fix the kqueue semantics and do it in a way that doesn't break backwards compatibility. But please don't claim that it's stopping you from getting real work done. I've written network apps with kqueue that scales to 8+ cores and (back in mid-2000's) gigabit + of small HTTP transactions. This stuff isn't at all problematic. Adrian From owner-freebsd-hackers@FreeBSD.ORG Mon May 13 16:37:00 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 03864C3A; Mon, 13 May 2013 16:37:00 +0000 (UTC) (envelope-from shiretu@gmail.com) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5511A77F; Mon, 13 May 2013 16:36:59 +0000 (UTC) Received: by mail-ee0-f44.google.com with SMTP id b57so1757331eek.3 for ; Mon, 13 May 2013 09:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=Rp01K8KJrZM66YfozKoxaAV2g/LTygIKYJetFLsH0wM=; b=t14xEuRT+ojHrFvucp/FpBPtvW1TMCnd4DGifdoRKv+9KKcu1qQlFZh5/zBAU7xzSi PEaWIFO+pW13fQAOhhleR26lQDiydjmlbG/+qnHEQOhgJ8Hw8nkFdcf+qBkNNe71US5W pY/vWydkVLDYEeTjtAsewGgaXWIZ8Tatb8VxrwJKMtMq4lUIbATeBRojsdMG+8Ua/Riu ZQhXmrqyOUngjpKeHrY/dW0K+V+iUzP9ldRdP9FbxWjBW7/RB/09QMp8x28J9i+537mM 3ZXfXu6tVuBeJPKBsqv5LO4bwWrUHpc8++pFd2SlZzj9Udd7IW7VBCPdlDnetWtpl0BJ coYA== X-Received: by 10.14.5.5 with SMTP id 5mr80783535eek.21.1368463012218; Mon, 13 May 2013 09:36:52 -0700 (PDT) Received: from [10.0.1.4] ([188.26.136.91]) by mx.google.com with ESMTPSA id bn53sm24059036eeb.7.2013.05.13.09.36.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 May 2013 09:36:50 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_59961354-6B33-4E9C-87D4-EB3B97A86EC0"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Managing userland data pointers in kqueue/kevent From: Eugen-Andrei Gavriloaie In-Reply-To: Date: Mon, 13 May 2013 19:36:49 +0300 Message-Id: <985C1C3F-3F70-47D2-8F43-F3D6CCA4482C@gmail.com> References: <84DCA050-99D4-4B22-A031-35E0928709E0@gmail.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1503) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 16:37:00 -0000 --Apple-Mail=_59961354-6B33-4E9C-87D4-EB3B97A86EC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Adrian, All the tricks, work arounds, paradigms suggested/implemented by us, the = kq users, are greatly simplified by simply adding that thing that Paul = is suggesting. What you are saying here is to basically do = not-so-natural things to overcome a real problem which can be very easy = and non-intrusivly solved at lower levels. Seriously, if you truly = believe that you can put the equal sign between the complexity of the = user space code and the wanted patch in kqueue kernel side, than I = simply shut up. Besides, one of the important points in kq philosophy is simplifying = things. I underline the "one of". It is not the goal, of course. Complex = things are complex things no matter how hard you try to simplify them. = But this is definitely (should) not falling into that category. ------ Eugen-Andrei Gavriloaie Web: http://www.rtmpd.com On May 13, 2013, at 6:47 PM, Adrian Chadd wrote: > ... holy crap. >=20 > On 13 May 2013 08:37, Eugen-Andrei Gavriloaie = wrote: >> Hi, >>=20 >> Well, Paul already asked this question like 3-4 times now. Even = insisting on it. I will also ask it again: >> If user code is responsible of tracking down the data associated with = the signalled entity, what is the point of having user data? >> Is rendered completely useless=85 >=20 > .. why does everything have to have a well defined purpose that is > also suited for use in _all_ situations? That is called perfection. I know we can't achieve it, but I like to = walk in that direction at least. >=20 >> Not to mention, that your suggestion with FD index is a definite = no-go. The FD values are re-used. Especially in MT environments. Imagine = one kqueue call taking place in thread A and another one in thread B. = Both threads waiting for events. >=20 > .. so don't do that. I mean, you're already having to write your code > to _not_ touch FDs in other threads. I've done this before, it isn't > that hard and it doesn't hurt performance. Why not? This is how you achieve natural load balancing for multiple = kevent() calls from multiple threads over the same kq fd. Otherwise, = again, you have to write complex code to manually balance the threads. = That brings locking again=85. Why people always think that locking is cheap? Excessive locking hurts. = A lot! >=20 >> When A does his magic, because of internal business rules, it decides = to close FD number 123. It closes it and it connects somewhere else by = opening a new one. Surprise, we MAY get the value 123 again as a new = socket, we put it on our index, etc. Now, thread B comes in and it has = stale/old events for the old 123 FD. Somethings bad like EOF for the OLD = version of FD number 123 (the one we just closed anyway). Guess what=85 = thread B will deallocate the perfectly good thingy inside the index = associated with 123. >=20 > So you just ensure that nothing at all calls a close(123); but calls > fd_close(123) which will in turn close(123) and free all the state > associated with it. Once threads A and B returned from their kevent() calls, all bets are = off. In between, you get the the behaviour I just described from threads = A and B racing towards FD123 to either close it or create a new one. How = is wrapping close() going to help? Is not like you have any control over = what the socket() function is going to return. (That gave me another = token idea btw=85 I will explain in another email, perhaps you care to = comment) Mathematically speaking, the fd-to-data association is not bijective.=20 >=20 > You have fd_close() either grab a lock, or you ensure that only the > owning thread can call fd_close(123) and if any other thread calls it, > the behaviour is undefined. As I said, that adds up to the user-space code complexity. Just don't = forget that Paul's suggestion solves all this problems in a ridiculously = simple manner. All our ideas of keeping track who is owning who and = indexes are going to be put to rest. kq will notify us when the udata is = out of scope from kq perspective. That is all we ask. >=20 >> And regarding the "thread happiness", that is not happiness at all = IMHO=85 >=20 > Unless you're writing a high connection throughput web server, the > overhead of grabbing a lock in userland during the fd shutdown process > is trivial. Yes, I've written those. It doesn't hurt you that much. That "that much" is subjective. And a streaming server is a few orders = of magnitude more complex than a web server. Remember, a web server is = bound to request/response paradigm. While a streaming server is a full = duplex (not request/response based) animal for most of connections. I = strongly believe that becomes a real problem. (I would love to be wrong = on this one!) >=20 > I'm confused as to why this is still an issue. Sure, fix the kqueue > semantics and do it in a way that doesn't break backwards > compatibility. Than, if someone has time and pleasure, it would be nice to have it. Is = a neat solution. Is one thing saying, hey, we don't have time, do it = yourself. And another thing in trying to offer "better" solutions by = defending such an obvious caveat.=20 > But please don't claim that it's stopping you from > getting real work done. I didn't and I won't. I promise! > I've written network apps with kqueue that > scales to 8+ cores and (back in mid-2000's) gigabit + of small HTTP > transactions. Good for you. How is this relevant to or discussion of simplifying = things? Of course is possible. But let's make things simpler and more = efficient. It really pays off in the long run. Hell, this is how kq was = born in the first place: getting rid of all garbage that one was = supposed to do to achieve what kq does with a few lines of code. Let's = make that even better than it currently is. > This stuff isn't at all problematic. >=20 >=20 > Adrian --Apple-Mail=_59961354-6B33-4E9C-87D4-EB3B97A86EC0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO5jCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFIzCCBAugAwIBAgIQY7lP +MJT4QzHh5dD4LWVRzANBgkqhkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdy ZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExp bWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQTAeFw0xMjA4MjEwMDAwMDBaFw0xMzA4MjEyMzU5NTlaMCIxIDAeBgkqhkiG9w0BCQEW EXNoaXJldHVAZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAziBH0E99 6jx0UrKapQcbxgWLgux1j9/Ec7K3QkkFtzCgxtF9ohpfsiAVOkYuCzVxoxoC0eNKO4qbZPYNbsN6 gtVZMrQnphgG3Wzmf28azn60TtCEQNoFXdW4On+cZgcvUxZS09DaPuTrHB5BuOmYG7b93ZjvJuov KCYAjYNrg0S9TKTQdRJAu95E2OuoVzin+QwIfEVwOA+PSRTPbNnjHvHUMg2G98CXFKIYPy9Pz8Kk rd54q7eSanjNiQK4Z9UYFjjNokx0nhymUAlnzWDAPj8jlh5i6gPrWsr9mYmQ6Y9wm2RHyf7QA6nM BIO43JNPklqjUT5LnB47rxVnLKnYmQIDAQABo4IB4TCCAd0wHwYDVR0jBBgwFoAUehNOAHRbxnhj ZCfBL+KgW7x5xXswHQYDVR0OBBYEFFoYqkq01lUdSiemIAjKHTuJiRj9MA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9D T01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHAYDVR0RBBUwE4ERc2hpcmV0dUBnbWFpbC5jb20w DQYJKoZIhvcNAQEFBQADggEBAHOQHTMzyiauVSuvCNgN2laY11tdDegdalfDK8UIFpdv08TE1viQ Q9gQfJpGNiO4wxpK8NeB8Qkh+AlL9ygq3jNwuAhk+TXMJ4Jr/I7LkTyJFnW45ADLZs/ufAbc+gdK lxdIxRJBOHmEpA51h0beSlfgHZcvvGshESzwLF290LuEdmLWncIWbhuO4vOJRK/7wJ/KXD8bZdx5 LGvA/QPPi5u95zFoQPRLSDl7lqJailBJZe6YFs7zBK2lm3u0w7exJw/rYeXFjMR0g5BPQCiihMq5 77k2T7uKmQqzapeCqLcd0sFNi94lzgSJxaQDyiDZYeYjWX0lSNVEG0z/fCIVJj4xggOrMIIDpwIB ATCBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQY7lP+MJT4QzHh5dD4LWV RzAJBgUrDgMCGgUAoIIB1zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA1MTMxNjM2NDlaMCMGCSqGSIb3DQEJBDEWBBRO5jGaJQbNYkk8pNooWNSHbx4X2TCBuQYJ KwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UE AxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBjuU/4 wlPhDMeHl0PgtZVHMIG7BgsqhkiG9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNV BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNl Y3VyZSBFbWFpbCBDQQIQY7lP+MJT4QzHh5dD4LWVRzANBgkqhkiG9w0BAQEFAASCAQCXWkLqmsoD aA6yV9K71t5DJEumwSMWvWs/hxDnb8d19rEBymsXphKLOYSZqM8mPFMKSUlOeHqWVIYeX2frC9sz BiiET7TtG4DUo1q34Tv3IXM9wP+VnYzeFE8I+L2iE8T0d/YAPR282O0ZUxGtFAfSXmin9T15wAXr cY5mnaQv6NoaBXtpPSVe0unY9MiI3yO1KK8embLiAOvv1oQFWbCGBYoD19606IceHeOa0P8hWymA r0coO0uRoAG9eZKNp11z5Bvx31rtMahmrWMbxaxaS+PE4EPmiqFOdnxZjTv4FTdtg82vtxo0urrs +UBOBEfTiZOiM2cCe2ruMOLNg5z0AAAAAAAA --Apple-Mail=_59961354-6B33-4E9C-87D4-EB3B97A86EC0-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 13 17:06:40 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D31C3976 for ; Mon, 13 May 2013 17:06:40 +0000 (UTC) (envelope-from leonerd@leonerd.org.uk) Received: from cel.leonerd.org.uk (cel.leonerd.org.uk [IPv6:2001:8b0:3f7::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9BF36988 for ; Mon, 13 May 2013 17:06:40 +0000 (UTC) Received: from shy.leonerd.org.uk (8.9.7.8.3.c.e.f.f.f.2.8.9.a.e.8.3.4.0.0.7.f.3.0.0.b.8.0.1.0.0.2.ip6.arpa [IPv6:2001:8b0:3f7:43:8ea9:82ff:fec3:8798]) by cel.leonerd.org.uk (Postfix) with ESMTPSA id F207B1BDF9; Mon, 13 May 2013 18:06:38 +0100 (BST) Date: Mon, 13 May 2013 18:06:37 +0100 From: Paul "LeoNerd" Evans To: Eugen-Andrei Gavriloaie Subject: Re: Managing userland data pointers in kqueue/kevent Message-ID: <20130513180637.6ff6b7d6@shy.leonerd.org.uk> In-Reply-To: References: X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/QkKqArvT/PY+r3oxcIAmFBv"; protocol="application/pgp-signature" X-Mailman-Approved-At: Mon, 13 May 2013 17:28:06 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 17:06:40 -0000 --Sig_/QkKqArvT/PY+r3oxcIAmFBv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 13 May 2013 18:19:43 +0300 Eugen-Andrei Gavriloaie wrote: > I'm pretty sure this user data pointer is also breaking a well known > pointer management paradigm, but I just can't remember which. > Regardless, it has all the ingredients for memory leaks and/or, the > worst one, use of corpse pointers which are bound to crash the app. I > agree, C/C++ is not for the faint of heart, but with little or close > to no efforts, his EV_FREEWATCH can be put to very good use, and user > space code not only becomes less prone to mem issues, but also > cleaner. >=20 > To summarise, +1 for the EV_FREEWATCH. I simply love the idea! Clean > and very very efficient. I actually developed the idea a little further and put some notes on implementation/etc here in this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D153254 I don't think anyone has looked at it though. If anyone were to just say "yes" and explain how to start developing a kernel feature, I'm sure I'd be happy to look into it. --=20 Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ --Sig_/QkKqArvT/PY+r3oxcIAmFBv Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlGRHZ0ACgkQvLS2TC8cBo2uugCfdivAovpEzmx4Lb9cFzOkycFC XGQAoPwS4/JFhOn8ktJhU8Z5jVaqUKm6 =Meuq -----END PGP SIGNATURE----- --Sig_/QkKqArvT/PY+r3oxcIAmFBv-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 13 17:53:59 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 167156A5; Mon, 13 May 2013 17:53:59 +0000 (UTC) (envelope-from leonerd@leonerd.org.uk) Received: from cel.leonerd.org.uk (cel.leonerd.org.uk [IPv6:2001:8b0:3f7::2]) by mx1.freebsd.org (Postfix) with ESMTP id D3032D7B; Mon, 13 May 2013 17:53:58 +0000 (UTC) Received: from shy.leonerd.org.uk (8.9.7.8.3.c.e.f.f.f.2.8.9.a.e.8.3.4.0.0.7.f.3.0.0.b.8.0.1.0.0.2.ip6.arpa [IPv6:2001:8b0:3f7:43:8ea9:82ff:fec3:8798]) by cel.leonerd.org.uk (Postfix) with ESMTPSA id 350671BDF9; Mon, 13 May 2013 18:53:58 +0100 (BST) Date: Mon, 13 May 2013 18:53:57 +0100 From: Paul "LeoNerd" Evans To: freebsd-hackers@freebsd.org, adrian@freebsd.org Subject: Re: Managing userland data pointers in kqueue/kevent Message-ID: <20130513185357.1c552be5@shy.leonerd.org.uk> In-Reply-To: References: X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/6Q8zy2xciqc2jDxe2EbUEQn"; protocol="application/pgp-signature" X-Mailman-Approved-At: Mon, 13 May 2013 18:02:49 +0000 Cc: Eugen-Andrei Gavriloaie X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 17:53:59 -0000 --Sig_/6Q8zy2xciqc2jDxe2EbUEQn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable [I'm not currently on the list so please forgive the manually-crafted reply] > I'm confused as to why this is still an issue. Sure, fix the kqueue > semantics and do it in a way that doesn't break backwards > compatibility. I suggested that. Add a user->kernel flag EV_DROPWATCH which, if present, causes kernel to send back to userland events with the kernel->user flag EV_DROPPING any time it drops the pointer. Then trivially userland just has to set that flag on all its events to the kernel, and remember to send those events back to userland when it does in fact drop them. These events can be trivially created from the knote_drop() function: http://fxr.watson.org/fxr/source/kern/kern_event.c#L2127 because that's called everywhere in the kernel that actually drops the watch. Which brings me onto the main reason why: It becomes a lot simpler to write userland code. When I wrote the original idea 3 years ago, it was after some research into what reasons would drop these watches in the kernel. By having the kernel tell userland, that future-proofs it a lot better. To further answer the threading questions: Having the locking point decided by the kernel and the event reflected back up to userland still with the pointer that kernel had simplifies all this locking. Now, userland doesn't have to contend on a Big Structure Lock around whatever data structure it uses to store all this information. It allows less userland contention. It's fully back-compatible, because all it does is adds a new user->kernel flag, that if the userland didn't know about, wouldn't set, and no behaviour is changed. If the flag -is- set then userland simply starts receiving a few extra events, or has another bit flag set on the events it was already receiving. Finally: I feel quite sure this feature is implementable in ballpark-50 lines of kernel-side code. I'd half-bet the documentation would be longer than that. It is truely a tiny addition of behaviour to export information the kernel already knows (namely: that it is calling knote_drop()). I can't see any objection to it. I'm quite sure more words and objection have been spent arguing it back and forth than it would have taken just to implement it initially. --=20 Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ --Sig_/6Q8zy2xciqc2jDxe2EbUEQn Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlGRKLUACgkQvLS2TC8cBo1S7QCgpMos/w4W9caVZ9ThV4g+ZLAE BIUAoNjeTpokLjZu2v9wuSVxSEUreljc =TYPs -----END PGP SIGNATURE----- --Sig_/6Q8zy2xciqc2jDxe2EbUEQn-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 13 18:02:51 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 44CF699C for ; Mon, 13 May 2013 18:02:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id D0970DFA for ; Mon, 13 May 2013 18:02:50 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id u54so6860239wes.1 for ; Mon, 13 May 2013 11:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JC8ymxN4pV3ep9diBXA88ebRohte7G+X4aVt7hpzwwg=; b=PXt9P4He4+9lNbgZ/sgzyDALjUsxiFQun9FYnkiujqOLHRoGntHTt2/b4aiKLKURFv gqxAI7piza+Rt06IcBrAXdlKaXQ/A8XHuAPaNE95Fyu8Z8OgmopRO2com8JG8ki6GkTd BTaMWq8NkrRazCQN6fh12Pd9UVYMg5aAvQI6Zk53OHcXVQAoSqd6+H2VXX4z866XOxNi bWJrF4CNSmA0MlcRZ6m55uBMVdMc8NHLUnARP73BtsQzvdzNZYYxZm5IyMEQ2//SwdlY 72aG/Ag4y9sgMiUNntxAY6jOLHorWfxu08wmHDbFVd//xzX//+nVzCepRb10t1WL1+8h oglw== MIME-Version: 1.0 X-Received: by 10.180.185.179 with SMTP id fd19mr20915496wic.1.1368468168053; Mon, 13 May 2013 11:02:48 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Mon, 13 May 2013 11:02:47 -0700 (PDT) In-Reply-To: <985C1C3F-3F70-47D2-8F43-F3D6CCA4482C@gmail.com> References: <84DCA050-99D4-4B22-A031-35E0928709E0@gmail.com> <985C1C3F-3F70-47D2-8F43-F3D6CCA4482C@gmail.com> Date: Mon, 13 May 2013 11:02:47 -0700 X-Google-Sender-Auth: IC3sRV8Uu0N5I0PYWpwdLnQuVpI Message-ID: Subject: Re: Managing userland data pointers in kqueue/kevent From: Adrian Chadd To: Eugen-Andrei Gavriloaie Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 18:02:51 -0000 Hi, The reason I tend to suggest this is for portability and debugging reasons. (Before and even since libevent came into existence.) If you do it right, you can stub / inline out all of the wrapper functions in userland and translate them to straight system or library calls. Anyway. I'm all for making kqueue better. I just worry that adding little hacks here and there isn't the right way to do it. If you want to guarantee specific behaviours with kqueue, you should likely define how it should work in its entirety and see if it will cause architectural difficulties down the track. Until that is done, I think you have no excuse to get your code working as needed. Don't blame kqueue because what (iirc) is not defined behaviour isn't defined in a way that makes you happy :) Adrian On 13 May 2013 09:36, Eugen-Andrei Gavriloaie wrote: > Hi Adrian, > > All the tricks, work arounds, paradigms suggested/implemented by us, the = kq users, are greatly simplified by simply adding that thing that Paul is s= uggesting. What you are saying here is to basically do not-so-natural thing= s to overcome a real problem which can be very easy and non-intrusivly solv= ed at lower levels. Seriously, if you truly believe that you can put the eq= ual sign between the complexity of the user space code and the wanted patch= in kqueue kernel side, than I simply shut up. > > Besides, one of the important points in kq philosophy is simplifying thin= gs. I underline the "one of". It is not the goal, of course. Complex things= are complex things no matter how hard you try to simplify them. But this i= s definitely (should) not falling into that category. > > ------ > Eugen-Andrei Gavriloaie > Web: http://www.rtmpd.com > > On May 13, 2013, at 6:47 PM, Adrian Chadd wrote: > >> ... holy crap. >> >> On 13 May 2013 08:37, Eugen-Andrei Gavriloaie wrote: >>> Hi, >>> >>> Well, Paul already asked this question like 3-4 times now. Even insisti= ng on it. I will also ask it again: >>> If user code is responsible of tracking down the data associated with t= he signalled entity, what is the point of having user data? >>> Is rendered completely useless=85 >> >> .. why does everything have to have a well defined purpose that is >> also suited for use in _all_ situations? > That is called perfection. I know we can't achieve it, but I like to walk= in that direction at least. > >> >>> Not to mention, that your suggestion with FD index is a definite no-go.= The FD values are re-used. Especially in MT environments. Imagine one kque= ue call taking place in thread A and another one in thread B. Both threads = waiting for events. >> >> .. so don't do that. I mean, you're already having to write your code >> to _not_ touch FDs in other threads. I've done this before, it isn't >> that hard and it doesn't hurt performance. > Why not? This is how you achieve natural load balancing for multiple keve= nt() calls from multiple threads over the same kq fd. Otherwise, again, you= have to write complex code to manually balance the threads. That brings lo= cking again=85. > Why people always think that locking is cheap? Excessive locking hurts. A= lot! > >> >>> When A does his magic, because of internal business rules, it decides t= o close FD number 123. It closes it and it connects somewhere else by openi= ng a new one. Surprise, we MAY get the value 123 again as a new socket, we= put it on our index, etc. Now, thread B comes in and it has stale/old even= ts for the old 123 FD. Somethings bad like EOF for the OLD version of FD nu= mber 123 (the one we just closed anyway). Guess what=85 thread B will deall= ocate the perfectly good thingy inside the index associated with 123. >> >> So you just ensure that nothing at all calls a close(123); but calls >> fd_close(123) which will in turn close(123) and free all the state >> associated with it. > Once threads A and B returned from their kevent() calls, all bets are off= . In between, you get the the behaviour I just described from threads A and= B racing towards FD123 to either close it or create a new one. How is wrap= ping close() going to help? Is not like you have any control over what the = socket() function is going to return. (That gave me another token idea btw= =85 I will explain in another email, perhaps you care to comment) > Mathematically speaking, the fd-to-data association is not bijective. > > >> >> You have fd_close() either grab a lock, or you ensure that only the >> owning thread can call fd_close(123) and if any other thread calls it, >> the behaviour is undefined. > As I said, that adds up to the user-space code complexity. Just don't for= get that Paul's suggestion solves all this problems in a ridiculously simpl= e manner. All our ideas of keeping track who is owning who and indexes are = going to be put to rest. kq will notify us when the udata is out of scope f= rom kq perspective. That is all we ask. > >> >>> And regarding the "thread happiness", that is not happiness at all IMHO= =85 >> >> Unless you're writing a high connection throughput web server, the >> overhead of grabbing a lock in userland during the fd shutdown process >> is trivial. Yes, I've written those. It doesn't hurt you that much. > That "that much" is subjective. And a streaming server is a few orders of= magnitude more complex than a web server. Remember, a web server is bound = to request/response paradigm. While a streaming server is a full duplex (no= t request/response based) animal for most of connections. I strongly believ= e that becomes a real problem. (I would love to be wrong on this one!) > >> >> I'm confused as to why this is still an issue. Sure, fix the kqueue >> semantics and do it in a way that doesn't break backwards >> compatibility. > Than, if someone has time and pleasure, it would be nice to have it. Is a= neat solution. Is one thing saying, hey, we don't have time, do it yoursel= f. And another thing in trying to offer "better" solutions by defending suc= h an obvious caveat. > >> But please don't claim that it's stopping you from >> getting real work done. > I didn't and I won't. I promise! > >> I've written network apps with kqueue that >> scales to 8+ cores and (back in mid-2000's) gigabit + of small HTTP >> transactions. > Good for you. How is this relevant to or discussion of simplifying things= ? Of course is possible. But let's make things simpler and more efficient. = It really pays off in the long run. Hell, this is how kq was born in the fi= rst place: getting rid of all garbage that one was supposed to do to achiev= e what kq does with a few lines of code. Let's make that even better than i= t currently is. > >> This stuff isn't at all problematic. >> >> >> Adrian > From owner-freebsd-hackers@FreeBSD.ORG Mon May 13 18:09:55 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 28DD0B4B for ; Mon, 13 May 2013 18:09:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by mx1.freebsd.org (Postfix) with ESMTP id B94CAE54 for ; Mon, 13 May 2013 18:09:54 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id k13so6746013wgh.7 for ; Mon, 13 May 2013 11:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OUfDumtgsWyLb1xuQm7uJnCjvYfKUChlDAf97ClWkMo=; b=lmPooSK4Sb9gJnUaih83DJ0sCb6D0s7da8fLuESeeHM6DGtjeqLSbtMxF5TL5M+YnE kr7zT9fEPxjpY/cgekLQnAftrdsA+9G74rnUdLBl2GXqAdfGUOwmtxTML1B2RJeTcjpP Kvvr0MTVjvbrXh9D4vWkB1qsWmMQaDEZ6IW+el/SGpe07GpfS4zcLFa3nvCB8H9+RH9U 638r+Soqrzwr2EYQosodmgx3wpCtxa48RWRbCzi8r2370zl6abd3RUBBMVP9kHpuahPz WJQxqbYflvQfMIYuOXwTjsEIz/YQWs5PVcroc/DRD5md/PiHFHufNR5uEm6YliznaXdE TsBw== MIME-Version: 1.0 X-Received: by 10.180.37.229 with SMTP id b5mr7471978wik.29.1368468593877; Mon, 13 May 2013 11:09:53 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Mon, 13 May 2013 11:09:53 -0700 (PDT) In-Reply-To: <20130513185357.1c552be5@shy.leonerd.org.uk> References: <20130513185357.1c552be5@shy.leonerd.org.uk> Date: Mon, 13 May 2013 11:09:53 -0700 X-Google-Sender-Auth: 3hMIm7dg1fcjbdKidqCK9gyU4HE Message-ID: Subject: Re: Managing userland data pointers in kqueue/kevent From: Adrian Chadd To: Paul LeoNerd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Eugen-Andrei Gavriloaie X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 18:09:55 -0000 On 13 May 2013 10:53, Paul LeoNerd wrote: > [I'm not currently on the list so please forgive the manually-crafted > reply] > >> I'm confused as to why this is still an issue. Sure, fix the kqueue >> semantics and do it in a way that doesn't break backwards >> compatibility. > > I suggested that. Add a user->kernel flag > > EV_DROPWATCH > > which, if present, causes kernel to send back to userland events with > the kernel->user flag > > EV_DROPPING > > any time it drops the pointer. Then trivially userland just has to set > that flag on all its events to the kernel, and remember to send those > events back to userland when it does in fact drop them. Cool! Ok. I'll go bring this up at bsdcan and see what people think. I haven't been knee deep in this stuff for a few years (but am about to again, damned HTTP proxies!) and I would love to have better semantics here. I just want to make sure it doesn't cause weird things for the non-socket case - ie, files (local, NFS) and signals. Adrian From owner-freebsd-hackers@FreeBSD.ORG Mon May 13 18:10:45 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6C580E0D for ; Mon, 13 May 2013 18:10:45 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by mx1.freebsd.org (Postfix) with ESMTP id 081C5ED3 for ; Mon, 13 May 2013 18:10:44 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id f11so6425129wgh.15 for ; Mon, 13 May 2013 11:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FfwLMpK/GRYh2WFli/Guq/bBCaG6IPh9NQZjgEkMg6A=; b=ioiBuoYHNzwP9/PDopsRTEfpMJV8E9FQsyXT54JrfV1xRbClAtrN0JMPHWEEsa8W16 qWCwKNsdFR/2KFt2rdIhWetsfhTJuwWKDTYFAABI8U0wSI6G4WiLlsEmrm5ySXfYBCTP tJ5Y53OICzT8qQX1HLkJQi+VfBXZdLt4IKNPtz82cIZemKAFLdustR5Td1gBb3iSHElk AIPd4W+tfPEjjBf9b5ydXVtomWnTe4TYzoT4saPRV5TyzDbX/apk0svV8WAxdJw7EKiN wFLeokOzAlTDIlYyukvUfatEFu45J6FNU+GwTp/hhktV8744xuKzNEjDZEU86YrICLV3 ruug== MIME-Version: 1.0 X-Received: by 10.181.13.169 with SMTP id ez9mr6174820wid.8.1368468644232; Mon, 13 May 2013 11:10:44 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Mon, 13 May 2013 11:10:44 -0700 (PDT) In-Reply-To: References: <20130513185357.1c552be5@shy.leonerd.org.uk> Date: Mon, 13 May 2013 11:10:44 -0700 X-Google-Sender-Auth: jrwz1O6Eer0lB1pC99hT3sOoUpg Message-ID: Subject: Re: Managing userland data pointers in kqueue/kevent From: Adrian Chadd To: Paul LeoNerd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Eugen-Andrei Gavriloaie X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 18:10:45 -0000 ... also, want to code up a test implementation? And some stress testing cases to throw in the regression tree? I'll help shephard this in if this all works out. thanks, Adrian From owner-freebsd-hackers@FreeBSD.ORG Mon May 13 18:14:35 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9D9BC871; Mon, 13 May 2013 18:14:35 +0000 (UTC) (envelope-from shiretu@gmail.com) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by mx1.freebsd.org (Postfix) with ESMTP id EA62FF66; Mon, 13 May 2013 18:14:34 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id d49so3772445eek.26 for ; Mon, 13 May 2013 11:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=k8tx5A06U2gIZa9Knmf9cmbNtAEu0K7OPbPq98DkXww=; b=IoyOjUC5Gxg9Zkpks5fOyGPgmjHMLLeXJhhwtuL7Uoy1dQcGSjV+LygcLX6YIBky7T nQkNlKU/18CrRG8yE94owPKVHvfpSsThk5uppYmAwDKvOytCVTfniV79HfCb4oGlzPZX aN7RBrtxIg/kPvrtgOeadZPLKgIEr4rsuUt9WNAxaKmPOVwvO95harsOSVQiuLyMGaL1 5pkDN2tfKVqNG9Ukzsfs/qJAunWpjBcXDwZ+U/Uc6L7YNUr1zwMGj/lCh2lJVhy0JBqq WUWpiakYuB4rw11rtMlRngR9V3wr5LAGGOgKeDthGPOhsMXScsYOmIlI7Zy+RJBhHe8F SA7A== X-Received: by 10.15.73.197 with SMTP id h45mr40816926eey.46.1368468868257; Mon, 13 May 2013 11:14:28 -0700 (PDT) Received: from [10.0.1.4] ([188.26.136.91]) by mx.google.com with ESMTPSA id e50sm24560681eev.13.2013.05.13.11.14.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 May 2013 11:14:26 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_5AA28570-F534-489B-94D6-2357ED428192"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Managing userland data pointers in kqueue/kevent From: Eugen-Andrei Gavriloaie In-Reply-To: Date: Mon, 13 May 2013 21:14:24 +0300 Message-Id: References: <84DCA050-99D4-4B22-A031-35E0928709E0@gmail.com> <985C1C3F-3F70-47D2-8F43-F3D6CCA4482C@gmail.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1503) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 18:14:35 -0000 --Apple-Mail=_5AA28570-F534-489B-94D6-2357ED428192 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 ------ Eugen-Andrei Gavriloaie Web: http://www.rtmpd.com On May 13, 2013, at 9:02 PM, Adrian Chadd wrote: > Hi, >=20 > The reason I tend to suggest this is for portability and debugging > reasons. (Before and even since libevent came into existence.) >=20 > If you do it right, you can stub / inline out all of the wrapper > functions in userland and translate them to straight system or library > calls. >=20 > Anyway. I'm all for making kqueue better. I just worry that adding > little hacks here and there isn't the right way to do it. If you want > to guarantee specific behaviours with kqueue, you should likely define > how it should work in its entirety and see if it will cause > architectural difficulties down the track. And it caused some so far. We have workarounds for it, no problem. > Until that is done, I think > you have no excuse to get your code working as needed. Yes. I agree. But when I look at the user space code without that = feature, and when thinking how it would have been with that feature, it = kinda makes me cry. A little more pain and I will make that patch = myself. I'm just hoping that kq kernel side code will be handled by more = capable hands before me. Ideally, by the creators. >=20 > Don't blame kqueue because what (iirc) is not defined behaviour isn't > defined in a way that makes you happy :) Nobody blamed kqueue. I'm just saying that it would be better for me = (and I'm not the only one) who could use a liiiitle more help from it. = It was born from needs, it evolved because of needs, why stop now? I = dare to say it will become a standard on linux and other OSs very soon. = It is the best fd reactor. Hands down! Best regards, Andrei >=20 >=20 >=20 > Adrian >=20 > On 13 May 2013 09:36, Eugen-Andrei Gavriloaie = wrote: >> Hi Adrian, >>=20 >> All the tricks, work arounds, paradigms suggested/implemented by us, = the kq users, are greatly simplified by simply adding that thing that = Paul is suggesting. What you are saying here is to basically do = not-so-natural things to overcome a real problem which can be very easy = and non-intrusivly solved at lower levels. Seriously, if you truly = believe that you can put the equal sign between the complexity of the = user space code and the wanted patch in kqueue kernel side, than I = simply shut up. >>=20 >> Besides, one of the important points in kq philosophy is simplifying = things. I underline the "one of". It is not the goal, of course. Complex = things are complex things no matter how hard you try to simplify them. = But this is definitely (should) not falling into that category. >>=20 >> ------ >> Eugen-Andrei Gavriloaie >> Web: http://www.rtmpd.com >>=20 >> On May 13, 2013, at 6:47 PM, Adrian Chadd wrote: >>=20 >>> ... holy crap. >>>=20 >>> On 13 May 2013 08:37, Eugen-Andrei Gavriloaie = wrote: >>>> Hi, >>>>=20 >>>> Well, Paul already asked this question like 3-4 times now. Even = insisting on it. I will also ask it again: >>>> If user code is responsible of tracking down the data associated = with the signalled entity, what is the point of having user data? >>>> Is rendered completely useless=85 >>>=20 >>> .. why does everything have to have a well defined purpose that is >>> also suited for use in _all_ situations? >> That is called perfection. I know we can't achieve it, but I like to = walk in that direction at least. >>=20 >>>=20 >>>> Not to mention, that your suggestion with FD index is a definite = no-go. The FD values are re-used. Especially in MT environments. Imagine = one kqueue call taking place in thread A and another one in thread B. = Both threads waiting for events. >>>=20 >>> .. so don't do that. I mean, you're already having to write your = code >>> to _not_ touch FDs in other threads. I've done this before, it isn't >>> that hard and it doesn't hurt performance. >> Why not? This is how you achieve natural load balancing for multiple = kevent() calls from multiple threads over the same kq fd. Otherwise, = again, you have to write complex code to manually balance the threads. = That brings locking again=85. >> Why people always think that locking is cheap? Excessive locking = hurts. A lot! >>=20 >>>=20 >>>> When A does his magic, because of internal business rules, it = decides to close FD number 123. It closes it and it connects somewhere = else by opening a new one. Surprise, we MAY get the value 123 again as = a new socket, we put it on our index, etc. Now, thread B comes in and it = has stale/old events for the old 123 FD. Somethings bad like EOF for the = OLD version of FD number 123 (the one we just closed anyway). Guess = what=85 thread B will deallocate the perfectly good thingy inside the = index associated with 123. >>>=20 >>> So you just ensure that nothing at all calls a close(123); but calls >>> fd_close(123) which will in turn close(123) and free all the state >>> associated with it. >> Once threads A and B returned from their kevent() calls, all bets are = off. In between, you get the the behaviour I just described from threads = A and B racing towards FD123 to either close it or create a new one. How = is wrapping close() going to help? Is not like you have any control over = what the socket() function is going to return. (That gave me another = token idea btw=85 I will explain in another email, perhaps you care to = comment) >> Mathematically speaking, the fd-to-data association is not bijective. >>=20 >>=20 >>>=20 >>> You have fd_close() either grab a lock, or you ensure that only the >>> owning thread can call fd_close(123) and if any other thread calls = it, >>> the behaviour is undefined. >> As I said, that adds up to the user-space code complexity. Just don't = forget that Paul's suggestion solves all this problems in a ridiculously = simple manner. All our ideas of keeping track who is owning who and = indexes are going to be put to rest. kq will notify us when the udata is = out of scope from kq perspective. That is all we ask. >>=20 >>>=20 >>>> And regarding the "thread happiness", that is not happiness at all = IMHO=85 >>>=20 >>> Unless you're writing a high connection throughput web server, the >>> overhead of grabbing a lock in userland during the fd shutdown = process >>> is trivial. Yes, I've written those. It doesn't hurt you that much. >> That "that much" is subjective. And a streaming server is a few = orders of magnitude more complex than a web server. Remember, a web = server is bound to request/response paradigm. While a streaming server = is a full duplex (not request/response based) animal for most of = connections. I strongly believe that becomes a real problem. (I would = love to be wrong on this one!) >>=20 >>>=20 >>> I'm confused as to why this is still an issue. Sure, fix the kqueue >>> semantics and do it in a way that doesn't break backwards >>> compatibility. >> Than, if someone has time and pleasure, it would be nice to have it. = Is a neat solution. Is one thing saying, hey, we don't have time, do it = yourself. And another thing in trying to offer "better" solutions by = defending such an obvious caveat. >>=20 >>> But please don't claim that it's stopping you from >>> getting real work done. >> I didn't and I won't. I promise! >>=20 >>> I've written network apps with kqueue that >>> scales to 8+ cores and (back in mid-2000's) gigabit + of small HTTP >>> transactions. >> Good for you. How is this relevant to or discussion of simplifying = things? Of course is possible. But let's make things simpler and more = efficient. It really pays off in the long run. Hell, this is how kq was = born in the first place: getting rid of all garbage that one was = supposed to do to achieve what kq does with a few lines of code. Let's = make that even better than it currently is. >>=20 >>> This stuff isn't at all problematic. >>>=20 >>>=20 >>> Adrian >>=20 --Apple-Mail=_5AA28570-F534-489B-94D6-2357ED428192 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO5jCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFIzCCBAugAwIBAgIQY7lP +MJT4QzHh5dD4LWVRzANBgkqhkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdy ZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExp bWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQTAeFw0xMjA4MjEwMDAwMDBaFw0xMzA4MjEyMzU5NTlaMCIxIDAeBgkqhkiG9w0BCQEW EXNoaXJldHVAZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAziBH0E99 6jx0UrKapQcbxgWLgux1j9/Ec7K3QkkFtzCgxtF9ohpfsiAVOkYuCzVxoxoC0eNKO4qbZPYNbsN6 gtVZMrQnphgG3Wzmf28azn60TtCEQNoFXdW4On+cZgcvUxZS09DaPuTrHB5BuOmYG7b93ZjvJuov KCYAjYNrg0S9TKTQdRJAu95E2OuoVzin+QwIfEVwOA+PSRTPbNnjHvHUMg2G98CXFKIYPy9Pz8Kk rd54q7eSanjNiQK4Z9UYFjjNokx0nhymUAlnzWDAPj8jlh5i6gPrWsr9mYmQ6Y9wm2RHyf7QA6nM BIO43JNPklqjUT5LnB47rxVnLKnYmQIDAQABo4IB4TCCAd0wHwYDVR0jBBgwFoAUehNOAHRbxnhj ZCfBL+KgW7x5xXswHQYDVR0OBBYEFFoYqkq01lUdSiemIAjKHTuJiRj9MA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9D T01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHAYDVR0RBBUwE4ERc2hpcmV0dUBnbWFpbC5jb20w DQYJKoZIhvcNAQEFBQADggEBAHOQHTMzyiauVSuvCNgN2laY11tdDegdalfDK8UIFpdv08TE1viQ Q9gQfJpGNiO4wxpK8NeB8Qkh+AlL9ygq3jNwuAhk+TXMJ4Jr/I7LkTyJFnW45ADLZs/ufAbc+gdK lxdIxRJBOHmEpA51h0beSlfgHZcvvGshESzwLF290LuEdmLWncIWbhuO4vOJRK/7wJ/KXD8bZdx5 LGvA/QPPi5u95zFoQPRLSDl7lqJailBJZe6YFs7zBK2lm3u0w7exJw/rYeXFjMR0g5BPQCiihMq5 77k2T7uKmQqzapeCqLcd0sFNi94lzgSJxaQDyiDZYeYjWX0lSNVEG0z/fCIVJj4xggOrMIIDpwIB ATCBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQY7lP+MJT4QzHh5dD4LWV RzAJBgUrDgMCGgUAoIIB1zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA1MTMxODE0MjVaMCMGCSqGSIb3DQEJBDEWBBRxCr3wVIjYpCFf4PcmEN+KnQ2DOzCBuQYJ KwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UE AxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBjuU/4 wlPhDMeHl0PgtZVHMIG7BgsqhkiG9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNV BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNl Y3VyZSBFbWFpbCBDQQIQY7lP+MJT4QzHh5dD4LWVRzANBgkqhkiG9w0BAQEFAASCAQAIGSIxfpvu 44gzMPwF+m5sexjox5N4wiBhtfnAXi/UxEiRGmLipGM8cqHD9PckQeI4UIOf3G5HTMJdbB6pCSde AYLWdWsTopHDAXXYImqJzWzR7vwpHXAnzRw+9YnjPtUDG3Y2a0M9K5ZGIl47Bt1P7YaScKPGXP1x nC4sWaPAFr3iN3ldAdKP9i9mmH4HtEYgdxqep+oA3S4pFGi68aqRrgxwSY1HISc8p1F6Vlqw65R0 TiHPW/6Ntc+sjSxI1VMGDAVfyyebRlhlB6Mcr/BRHjg2+6ZKCMZPrxOQ0YFJhhg5y/yDieXJOKtX HsNFWJM0VVTzCBMAtq3bRSaFNMEtAAAAAAAA --Apple-Mail=_5AA28570-F534-489B-94D6-2357ED428192-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 13 18:17:39 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7AA4AD9A; Mon, 13 May 2013 18:17:39 +0000 (UTC) (envelope-from shiretu@gmail.com) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id DB737FB6; Mon, 13 May 2013 18:17:38 +0000 (UTC) Received: by mail-ea0-f181.google.com with SMTP id a11so1475956eae.26 for ; Mon, 13 May 2013 11:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=VdjkGYCd5o4Ufu9MfEL7BE4f12Ta9cse1FW+pKfpeFk=; b=gCUMCou/sGFlqH5ftve7wPT9RRmfJQV9vf6Bj22OXuHhO88BE6qYe6DRfR0E4Zxy74 0aJ7UzaZIqHnp1HaOZHf8MGWUqRPZLhiRZqrWA8BYw0/RPXAimjQRadUkRn3h1w+QI7u FLmA/au1m9NRrj1659JNBNdKJG8szWJCRlZG72UaqItimpxhFQJSk3iZ/y5EiqojqQhP hKsZa63af9Zgh0QWAnQlm9wHEdY64o7EnW7TgSfKZf0gRkQdXszuQWeqJw7wMMKWMUUc ljI4Fgp15ngbcmx66ERGCKvgS3sJLz7rikFfUjt0dK12fXTgWNJ0GGBnBo27aUw7sAsf WJUw== X-Received: by 10.14.109.131 with SMTP id s3mr81123327eeg.26.1368469057515; Mon, 13 May 2013 11:17:37 -0700 (PDT) Received: from [10.0.1.4] ([188.26.136.91]) by mx.google.com with ESMTPSA id l6sm24594313eem.9.2013.05.13.11.17.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 May 2013 11:17:36 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_03F76616-3142-4A2B-81D4-269959FF0997"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Managing userland data pointers in kqueue/kevent From: Eugen-Andrei Gavriloaie In-Reply-To: <20130513191513.786f4f02@shy.leonerd.org.uk> Date: Mon, 13 May 2013 21:17:34 +0300 Message-Id: <8A02C28F-89CB-4AE3-A91A-89565F041FDE@gmail.com> References: <20130513185357.1c552be5@shy.leonerd.org.uk> <20130513191513.786f4f02@shy.leonerd.org.uk> To: Paul "LeoNerd" Evans X-Mailer: Apple Mail (2.1503) Cc: freebsd-hackers@freebsd.org, Adrian Chadd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 18:17:39 -0000 --Apple-Mail=_03F76616-3142-4A2B-81D4-269959FF0997 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I also have a large project (crtmpserver) which makes heavy use of = socket FDs (with my little Token workaround) and timers. Currently, can = handle 2k streaming connections simultaneously, all of them full duplex.=20= I would gladly patch it to use this new feature!!! ------ Eugen-Andrei Gavriloaie Web: http://www.rtmpd.com On May 13, 2013, at 9:15 PM, Paul "LeoNerd" Evans = wrote: > On Mon, 13 May 2013 11:10:44 -0700 > Adrian Chadd wrote: >=20 >> ... also, want to code up a test implementation? >>=20 >> And some stress testing cases to throw in the regression tree? >=20 > I already mostly fixed Perl's IO::KQueue wrapper to use this > hypothetical feature, I can easily provide that somewhere for someone > to test it against. I actually wrote that bit first, before I found > such a feature did not exist. >=20 > That would allow some highly-parallel Perl code to use it. All the = main > Perl event systems can use IO::KQueue so that easily provides a lot of > good test cases. >=20 > --=20 > Paul "LeoNerd" Evans >=20 > leonerd@leonerd.org.uk > ICQ# 4135350 | Registered Linux# 179460 > http://www.leonerd.org.uk/ --Apple-Mail=_03F76616-3142-4A2B-81D4-269959FF0997 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO5jCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFIzCCBAugAwIBAgIQY7lP +MJT4QzHh5dD4LWVRzANBgkqhkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdy ZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExp bWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQTAeFw0xMjA4MjEwMDAwMDBaFw0xMzA4MjEyMzU5NTlaMCIxIDAeBgkqhkiG9w0BCQEW EXNoaXJldHVAZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAziBH0E99 6jx0UrKapQcbxgWLgux1j9/Ec7K3QkkFtzCgxtF9ohpfsiAVOkYuCzVxoxoC0eNKO4qbZPYNbsN6 gtVZMrQnphgG3Wzmf28azn60TtCEQNoFXdW4On+cZgcvUxZS09DaPuTrHB5BuOmYG7b93ZjvJuov KCYAjYNrg0S9TKTQdRJAu95E2OuoVzin+QwIfEVwOA+PSRTPbNnjHvHUMg2G98CXFKIYPy9Pz8Kk rd54q7eSanjNiQK4Z9UYFjjNokx0nhymUAlnzWDAPj8jlh5i6gPrWsr9mYmQ6Y9wm2RHyf7QA6nM BIO43JNPklqjUT5LnB47rxVnLKnYmQIDAQABo4IB4TCCAd0wHwYDVR0jBBgwFoAUehNOAHRbxnhj ZCfBL+KgW7x5xXswHQYDVR0OBBYEFFoYqkq01lUdSiemIAjKHTuJiRj9MA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9D T01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHAYDVR0RBBUwE4ERc2hpcmV0dUBnbWFpbC5jb20w DQYJKoZIhvcNAQEFBQADggEBAHOQHTMzyiauVSuvCNgN2laY11tdDegdalfDK8UIFpdv08TE1viQ Q9gQfJpGNiO4wxpK8NeB8Qkh+AlL9ygq3jNwuAhk+TXMJ4Jr/I7LkTyJFnW45ADLZs/ufAbc+gdK lxdIxRJBOHmEpA51h0beSlfgHZcvvGshESzwLF290LuEdmLWncIWbhuO4vOJRK/7wJ/KXD8bZdx5 LGvA/QPPi5u95zFoQPRLSDl7lqJailBJZe6YFs7zBK2lm3u0w7exJw/rYeXFjMR0g5BPQCiihMq5 77k2T7uKmQqzapeCqLcd0sFNi94lzgSJxaQDyiDZYeYjWX0lSNVEG0z/fCIVJj4xggOrMIIDpwIB ATCBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQY7lP+MJT4QzHh5dD4LWV RzAJBgUrDgMCGgUAoIIB1zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA1MTMxODE3MzRaMCMGCSqGSIb3DQEJBDEWBBRxZC0HuVy0yNyqXri3Xd1QtHn+7zCBuQYJ KwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UE AxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBjuU/4 wlPhDMeHl0PgtZVHMIG7BgsqhkiG9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNV BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNl Y3VyZSBFbWFpbCBDQQIQY7lP+MJT4QzHh5dD4LWVRzANBgkqhkiG9w0BAQEFAASCAQBLnylBnDoz fN3WcguZaSJ+Un6W3kJXuC2ZVhy/GGoAH0OhGTp08gx+14HZ2ITSoTUca96f3IoxDRvQ5JjqmQlF y0Vd+RDfhMhI4/O5tncpejAYw/Wi6bxrjgogKB8vQOTRT0Atj68hM+9Mv6ndt3+yqJsYjUebfi2t jbGj0L4zcfvLVJkXTMCmNUpIAK9OCcbVg1ZF/e0U2BdkTzUkAO8WenskS1YE+Y4CbevRW0l6dXWX O70bVX/Vatby4CeK6n8CUOV/UAuchcxokDSqafBsLMjzh2lS+avtHzptyVRB/vmKaVSzTBinI1K8 M/UeS9kmofUhjSfnf0f76NMsTkYjAAAAAAAA --Apple-Mail=_03F76616-3142-4A2B-81D4-269959FF0997-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 13 18:23:46 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B60142A7 for ; Mon, 13 May 2013 18:23:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by mx1.freebsd.org (Postfix) with ESMTP id 4FA2168 for ; Mon, 13 May 2013 18:23:46 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id j13so6437992wgh.4 for ; Mon, 13 May 2013 11:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+/W1Gl9zK8BaJfjd3DuSccNMfA84K+G0HjCXp/M1HzI=; b=0v6Sl+Ny0miPfhdb7LOMroI9Ah9Wpx6D6OUdnf3GPoUM/JUuihDH4FLqDaxFw8haqJ /zAEMaCc/Lw1pKaUgobGIovikb3ld7+D1V6EmotgYSI4X+nGzY35X0DSGAHAjvb2hQGp LwuJQ3jBmXhwBcP6P9K8iUdT9WAjK0LKpc1m248hM9egVX07kpC23GGJorIJT2TEDcwr BGO7gGu3Xj+ZWkuiWwFVS0tsecPkHUMLday0qdeh6yen1+i3KgHUyYPuEOi8ykgiR3v9 3sI1KjO9OO1QhHTxYleDshwe2ReTvlPX6b7WebFFVFlSDmr6+VjYpoKIraZB+86ernID TWTg== MIME-Version: 1.0 X-Received: by 10.180.149.200 with SMTP id uc8mr21410018wib.3.1368469425543; Mon, 13 May 2013 11:23:45 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Mon, 13 May 2013 11:23:45 -0700 (PDT) In-Reply-To: <8A02C28F-89CB-4AE3-A91A-89565F041FDE@gmail.com> References: <20130513185357.1c552be5@shy.leonerd.org.uk> <20130513191513.786f4f02@shy.leonerd.org.uk> <8A02C28F-89CB-4AE3-A91A-89565F041FDE@gmail.com> Date: Mon, 13 May 2013 11:23:45 -0700 X-Google-Sender-Auth: e9YpTj3BVnad6tUGRw_ORR-vTcI Message-ID: Subject: Re: Managing userland data pointers in kqueue/kevent From: Adrian Chadd To: Eugen-Andrei Gavriloaie Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Paul LeoNerd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 18:23:46 -0000 Just as a data point, I managed 50,000 + connections, at 5,000 + a second, doing a gigabit + of traffic, mid-2000s, with the userland management of all of the socket/disk FD stuff. The biggest overhead at the time was actually the read/write copyin/copyout, NOT the locking overhead of managing this stuff. Why? Because I architected the HTTP side of things to specifically pin FDs to threads, and not allow arbitrary threads to deal with arbitrary FDs. This removed the need for almost all of the state locking that people are concerned about here. Adrian From owner-freebsd-hackers@FreeBSD.ORG Mon May 13 18:15:23 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 97A06B26; Mon, 13 May 2013 18:15:23 +0000 (UTC) (envelope-from leonerd@leonerd.org.uk) Received: from cel.leonerd.org.uk (cel.leonerd.org.uk [IPv6:2001:8b0:3f7::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4AB20F86; Mon, 13 May 2013 18:15:23 +0000 (UTC) Received: from shy.leonerd.org.uk (8.9.7.8.3.c.e.f.f.f.2.8.9.a.e.8.3.4.0.0.7.f.3.0.0.b.8.0.1.0.0.2.ip6.arpa [IPv6:2001:8b0:3f7:43:8ea9:82ff:fec3:8798]) by cel.leonerd.org.uk (Postfix) with ESMTPSA id 8C0DF1BDF9; Mon, 13 May 2013 19:15:14 +0100 (BST) Date: Mon, 13 May 2013 19:15:13 +0100 From: Paul "LeoNerd" Evans To: Adrian Chadd Subject: Re: Managing userland data pointers in kqueue/kevent Message-ID: <20130513191513.786f4f02@shy.leonerd.org.uk> In-Reply-To: References: <20130513185357.1c552be5@shy.leonerd.org.uk> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/+xJ_yq+.nuQAkHL.G19x=a_"; protocol="application/pgp-signature" X-Mailman-Approved-At: Mon, 13 May 2013 18:37:54 +0000 Cc: freebsd-hackers@freebsd.org, Eugen-Andrei Gavriloaie X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 18:15:23 -0000 --Sig_/+xJ_yq+.nuQAkHL.G19x=a_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 13 May 2013 11:10:44 -0700 Adrian Chadd wrote: > ... also, want to code up a test implementation? >=20 > And some stress testing cases to throw in the regression tree? I already mostly fixed Perl's IO::KQueue wrapper to use this hypothetical feature, I can easily provide that somewhere for someone to test it against. I actually wrote that bit first, before I found such a feature did not exist. That would allow some highly-parallel Perl code to use it. All the main Perl event systems can use IO::KQueue so that easily provides a lot of good test cases. --=20 Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ --Sig_/+xJ_yq+.nuQAkHL.G19x=a_ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlGRLbEACgkQvLS2TC8cBo1TZACgxfzpYITfB0hcezRAFe8btaeg CZkAn30/DaAANfe/l3mj5Cy6e79HiVe+ =21Ed -----END PGP SIGNATURE----- --Sig_/+xJ_yq+.nuQAkHL.G19x=a_-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 13 18:44:15 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 216A9B18; Mon, 13 May 2013 18:44:15 +0000 (UTC) (envelope-from leonerd@leonerd.org.uk) Received: from cel.leonerd.org.uk (cel.leonerd.org.uk [81.187.167.226]) by mx1.freebsd.org (Postfix) with ESMTP id BEDC016A; Mon, 13 May 2013 18:44:14 +0000 (UTC) Received: from shy.leonerd.org.uk (8.9.7.8.3.c.e.f.f.f.2.8.9.a.e.8.3.4.0.0.7.f.3.0.0.b.8.0.1.0.0.2.ip6.arpa [IPv6:2001:8b0:3f7:43:8ea9:82ff:fec3:8798]) by cel.leonerd.org.uk (Postfix) with ESMTPSA id 1513A1BDF9; Mon, 13 May 2013 19:44:13 +0100 (BST) Date: Mon, 13 May 2013 19:44:11 +0100 From: Paul "LeoNerd" Evans To: Adrian Chadd Subject: Re: Managing userland data pointers in kqueue/kevent Message-ID: <20130513194411.5a2dfa2e@shy.leonerd.org.uk> In-Reply-To: References: <20130513185357.1c552be5@shy.leonerd.org.uk> <20130513191513.786f4f02@shy.leonerd.org.uk> <8A02C28F-89CB-4AE3-A91A-89565F041FDE@gmail.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/DY4oum+taxoYivj5kXTwjRm"; protocol="application/pgp-signature" Cc: freebsd-hackers@freebsd.org, Eugen-Andrei Gavriloaie X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 18:44:15 -0000 --Sig_/DY4oum+taxoYivj5kXTwjRm Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 13 May 2013 11:23:45 -0700 Adrian Chadd wrote: > Just as a data point, I managed 50,000 + connections, at 5,000 + a > second, doing a gigabit + of traffic, mid-2000s, with the userland > management of all of the socket/disk FD stuff. >=20 > The biggest overhead at the time was actually the read/write > copyin/copyout, NOT the locking overhead of managing this stuff. Why? > Because I architected the HTTP side of things to specifically pin FDs > to threads, and not allow arbitrary threads to deal with arbitrary > FDs. This removed the need for almost all of the state locking that > people are concerned about here. I think then this comes from different experiences. I'm guessing this application was: a) Written in C b) Entirely filled with identically-typed identical-purpose file descriptors c) Didn't really use any EV_ONESHOT events d) Didn't close sockets apart from when it received EOF and perhaps most importantly e) Was entirely self-contained - did everything from one unified block of source code. I.e. a very simple set of semantics. I'll explain the situation that I had. The reason I ran into the problem needing EV_DROPWATCH/EV_DROPPED was because I was trying to fix Perl's IO::KQueue. IO::KQueue tries to wrap kqueue/kevent for Perl, allowing the userland Perl code to store an arbitrary Perl data pointer in the udata field. This data is reference-counted. Userland might let the kernel store the only copy of that data, because it comes back in event notifications anyway. Because of this, the reference count has to be artificially incremented to account for the extra pointer in the kernel. Without knowing when the kernel will decide to drop that pointer, I never know when I should decrement the refcount myself. It has no knowledge of what userland is doing with this. It can't know when userland might be EV_ONESHOT'ing. It doesn't really know what events will be oneshot anyway (such as the process exit watches). Finally, it has no idea what other modules are going to call close() on it. This final problem was the real killer - while the first two -could- be worked around with more complex code structures, not knowing what other CPAN modules will ever call close() makes it impossible to handle. Simply asking every CPAN module to "please just call fd_close() instead of close()" doesn't work here. As compared: having the kernel tell userland when it calls knote_drop() is much simpler. It knows exactly when it is doing this, so simply pushing an event up to userland to tell it it did so is simple. If any more cases than the three known (EV_ONESHOT or other single-shot events; EV_DELETE, close()) are added, userland - and in particular, the IO::KQueue module, will not need updating. It will continue to decrement refcounts and free data perfectly happily when kernel has dropped the watch. I've used this pattern before in C libraries + higher-level language wrappers, and found it to be nicely simple to both implement and use. Because it follows the -same- event notification path that userland is already using, it manages to avoid quite a number of the race-conditions that a secondary, separate data structure and locking often runs into; e.g. if userland is trying to add a new thing into it just at the time there's a notification "in-flight" from the kernel about an old thing that it used to have. Principly - the fact that kernel tells -userland- about the delete, means that it can atomically *guarantee* that this *will* be the last event about this particular item. Userland must not delete its own data structure about it until this notification happens. If it does this, lots of semantics become a lot simpler. --=20 Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ --Sig_/DY4oum+taxoYivj5kXTwjRm Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlGRNHsACgkQvLS2TC8cBo1jYACbBS6dal7hCHHhjdD380VV/d+f FsoAoLmO/1K334Fn4N23BpDjy1U4HzP3 =lksG -----END PGP SIGNATURE----- --Sig_/DY4oum+taxoYivj5kXTwjRm-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 13 19:09:27 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B58FC9D4 for ; Mon, 13 May 2013 19:09:27 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8D6E92B0 for ; Mon, 13 May 2013 19:09:27 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r4DJ9Q3P088239 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 13 May 2013 12:09:26 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51913A61.1030701@freebsd.org> Date: Mon, 13 May 2013 12:09:21 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Computer Network Man Subject: Re: A problem with alq module! References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 19:09:27 -0000 On 5/12/13 11:37 PM, Computer Network Man wrote: > Dear Guys; > In a fresh FreeBSD 9 or 9.1 Release if you just run these commands: > # kldload alq > # kldunload alq > # init 0 or shutdown -p now > it will panic! > maybe it's a bug. > We have a module which uses alq API's. > MODULE_DEPEND(mymodule, alq, 1, 1, 1) > when our module starts, loads alq. and when it stops, unloads alq. So after > starting and stoping our module and shutdown, we have panic. > any opinion in this regard would be appreciated. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > without looking at it, I am guessing that the alq module may mis-register for shutdown notification... (and not undo it).. UTSL please register a bug and include some debugging information.... From owner-freebsd-hackers@FreeBSD.ORG Tue May 14 08:00:27 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DDFAC71B for ; Tue, 14 May 2013 08:00:27 +0000 (UTC) (envelope-from mikemandarine@gmail.com) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by mx1.freebsd.org (Postfix) with ESMTP id A617D8B1 for ; Tue, 14 May 2013 08:00:27 +0000 (UTC) Received: by mail-vc0-f174.google.com with SMTP id hr11so198806vcb.5 for ; Tue, 14 May 2013 01:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=W8GAAtpX1dP6YPCWGoEP5ngcboZHxZRKPdmp6AQMZGw=; b=gcCI7IbO7dl+/PPj3X9S+4kIGok7xxgvz1JcNnGGFPabh/XeigxbMH5+3bmb/zZXhx N1tZa70503xB/xRe0grSjO8fCrMrwbNciDfTwIm4navbmAnsMK1bCM063k6qBO2uSzZZ +UDQVP74iJHhw4SMJ2LWiwphfz2MELajZALHX/gdC4C0QWNlXBJlkgPHA6f+W/chQJ5i is6mYBuhjpAct7W4xP+Qs0Gg11cxVxL5GwkMlENE8UX6t7ifl7AUT2XMqc8FhqnpB5SJ zgqF/SYCOub2EuBs7PPw8GJGucQLjPiWYLu6DZWX2GhE0A/0p59qh2DYYNtr3fdoKIUr Gzjg== MIME-Version: 1.0 X-Received: by 10.52.240.211 with SMTP id wc19mr17850657vdc.12.1368518421101; Tue, 14 May 2013 01:00:21 -0700 (PDT) Received: by 10.220.248.72 with HTTP; Tue, 14 May 2013 01:00:21 -0700 (PDT) Date: Tue, 14 May 2013 10:00:21 +0200 Message-ID: Subject: How to get ucred/xucred in user space? From: Mike Ma To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 08:00:27 -0000 Hi folks, Can I ask if there's any way to get ucred/xucred of a process in user space? As I'm trying to port glustertfs and it's a userland filesystem, I need to get secondary groups of a process. AFAIK, Linux gets them in /proc and NetBSD gets them in this way: int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_PID, frame->root->pid }; size_t namelen = sizeof name / sizeof name[0]; struct kinfo_proc kp; size_t kplen = sizeof(kp); int i, ngroups; if (sysctl(name, namelen, &kp, &kplen, NULL, 0) != 0) return; ngroups = MIN(kp.kp_eproc.e_ucred.cr_ngroups, GF_REQUEST_MAXGROUPS); I realized none of them would work in FreeBSD. I'm wondering if there's any alternative way to get group information? -- Cheers, Mike From owner-freebsd-hackers@FreeBSD.ORG Tue May 14 11:13:23 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5E50BA6D for ; Tue, 14 May 2013 11:13:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id CB7C0222 for ; Tue, 14 May 2013 11:13:22 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r4EBDIvb064291; Tue, 14 May 2013 14:13:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r4EBDIvb064291 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r4EBDIas064290; Tue, 14 May 2013 14:13:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 14 May 2013 14:13:18 +0300 From: Konstantin Belousov To: Mike Ma Subject: Re: How to get ucred/xucred in user space? Message-ID: <20130514111318.GP3047@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gl32Q9cg1UYx5OVO" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 11:13:23 -0000 --gl32Q9cg1UYx5OVO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 14, 2013 at 10:00:21AM +0200, Mike Ma wrote: > Hi folks, >=20 > Can I ask if there's any way to get ucred/xucred of a process in user spa= ce? > As I'm trying to port glustertfs and it's a userland filesystem, I need to > get secondary groups of a process. >=20 > AFAIK, Linux gets them in /proc and NetBSD gets them in this way: > int name[] =3D { CTL_KERN, KERN_PROC, KERN_PROC_PID, frame->root-= >pid > }; > size_t namelen =3D sizeof name / sizeof name[0]; > struct kinfo_proc kp; > size_t kplen =3D sizeof(kp); > int i, ngroups; > if (sysctl(name, namelen, &kp, &kplen, NULL, 0) !=3D 0) > return; > ngroups =3D MIN(kp.kp_eproc.e_ucred.cr_ngroups, GF_REQUEST_MAXGRO= UPS); >=20 > I realized none of them would work in FreeBSD. > I'm wondering if there's any alternative way to get group information? The sysctl to retrieve the list of the groups the process belongs to is CTL_KERN/KERN_PROC/KERN_PROC_GROUPS. On HEAD, the libprocstat(3) contains the helper procstat_getgroups() which would be more conventient to use, or you could borrow a code from it. --gl32Q9cg1UYx5OVO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRkhxOAAoJEJDCuSvBvK1BizsP/2dpRVnQkTE9iydzPVc7oydc chirm8uggZ2+5hPh/Yahy04fmqSYo7UHZPAYYjCXnI8y6M2ObQJAshtJkAHDfQ5A AasUhCcR9XITIOqo4YQWIbHrMhRndYW+U4Ou8uGE68pbd9S7CWW/5GtE8e0zGRoj S8ONbgwDnsZn44sDuzzxssKLqT2qMZM/q/l4K4F8I39rZwRk0PsonvvUeBqIl5Wt IgeOaYIddNOhZ+1FKJu9L4NEAZeCgVR2DLqVnmwBQYudskalECRtu9izFtkMoQuU QwUVDFNhi3B4TiWvjSi2GDdMExkTBGJZIK0DgmPHG6PrPxHA4RGGsxkFMhxkUAVk 332JJ4Cd9CkA9bf68uHJWklwK1uD2EI9KPrQzJdSus4KOJEZb2+2wGL2QrMoxGZd HYUFpMKRiaktd0BHxa47OcLZk6kiVQLliwbnYiCa167bKlm2le5Ae/RHNaoaGsU7 0soJrkutixWh4qqpZIspK1lGpGWdnf2ROTYnkpdjQBHp9AZAABoNyUtOI7y8b3CN BbPQUjlWVeF5AqAdLW4ybVtle2YZBa16AyWceCHTBMC9Fu3sRB9gMHvUrlGygtxH wNERwJCxhyDYBGG7dIbVH1QTHO9ZtXD3d3WZbgkfOrLCdDvbnZ8ygotZjMKRLrMh SMPnPfepcJmt4J5MFYVV =qQox -----END PGP SIGNATURE----- --gl32Q9cg1UYx5OVO-- From owner-freebsd-hackers@FreeBSD.ORG Wed May 15 05:00:41 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CD8B877A; Wed, 15 May 2013 05:00:41 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail1.ozon.ru (mx4.ozon.ru [194.186.179.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5F33294B; Wed, 15 May 2013 05:00:41 +0000 (UTC) Received: from intmail03msk.ozon (intmail03msk.ozon [10.18.18.171]) by mail1.ozon.ru (Postfix) with ESMTP id A17E9719E76; Wed, 15 May 2013 09:00:40 +0400 (MSK) Received: from mail pickup service by intmail03msk.ozon with Microsoft SMTPSVC; Wed, 15 May 2013 08:56:06 +0400 Received: from intmail03msk.ozon ([10.18.18.171]) by intmail02msk.ozon with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 May 2013 22:57:11 +0400 Received: from mail1.ozon.ru ([194.186.179.140]) by intmail03msk.ozon with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 May 2013 22:57:11 +0400 Received: from localhost (localhost [127.0.0.1]) by mail1.ozon.ru (Postfix) with ESMTP id 85BE97195DF for ; Sun, 12 May 2013 22:57:11 +0400 (MSK) X-Virus-Scanned: amavisd-new at ozon.ru Received: from mail1.ozon.ru ([127.0.0.1]) by localhost (mx4.ozon.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAtM0g6zg-Ca for ; Sun, 12 May 2013 22:57:04 +0400 (MSK) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received-SPF: pass (freebsd.org: 8.8.178.116 is authorized to use 'owner-freebsd-current@freebsd.org' in 'mfrom' identity (mechanism 'ip4:8.8.178.116' matched)) receiver=mx4.ozon.ru; identity=mfrom; envelope-from="owner-freebsd-current@freebsd.org"; helo=mx2.freebsd.org; client-ip=8.8.178.116 Received: from mx2.freebsd.org (mx2.FreeBSD.org [8.8.178.116]) by mail1.ozon.ru (Postfix) with ESMTP id 7B57871965E for ; Sun, 12 May 2013 22:57:03 +0400 (MSK) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 53E5823DA; Sun, 12 May 2013 18:56:58 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by hub.freebsd.org (Postfix) with ESMTP id 29FB2641; Sun, 12 May 2013 18:56:58 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DF566554; Sun, 12 May 2013 18:56:54 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 89F9C98F; Sun, 12 May 2013 18:56:54 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id un3so794108obb.5 for ; Sun, 12 May 2013 11:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=AlYy3tO43JYaan/9H2V4y2UM9PgQQ+RI/HNMFRv1Go0=; b=WP2COk1Zx6lNZYtI2e939viqdSZtgbJGDEKEAUjq9gQUBQ49d+I0U2fjmu56Z3D9sJ Tm61zTOPhZWvP0C1SPLfme42w/HKcYOumdGOcjK2hqyT22/pxH1++O55pKRaE+kCPwiU 8m28TmVJn7+gMTmGlCWu2rqidquFSPpCdTX7XhCzwJvelAywZjw7BHTjoUMqypgfd91p 3cVz0nZTjheVPz6DxzDmm6aqAGHEiAoJpgNkIfz6PJXoz8hG/xATvL1RgAzSFCrnGD79 Wgv8KBe1OD4KRZWrg5vz+G1Fmls2ivlPdfaKRncj9I5BsF3FIJEJOevetyZdwtDLtkDc /Owg== MIME-Version: 1.0 X-Received: by 10.60.56.132 with SMTP id a4mr2534426oeq.113.1368385013793; Sun, 12 May 2013 11:56:53 -0700 (PDT) Received: by 10.76.96.49 with HTTP; Sun, 12 May 2013 11:56:53 -0700 (PDT) In-Reply-To: <20130512195405.04653b64@funktor> References: <20130512195405.04653b64@funktor> Date: Sun, 12 May 2013 14:56:53 -0400 Message-ID: Subject: Re: FreeBSD Quarterly Status Report, January-March 2013 From: Outback Dingo To: Gabor Pali X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-current@freebsd.org Sender: owner-freebsd-current@freebsd.org X-OriginalArrivalTime: 12 May 2013 18:57:11.0416 (UTC) FILETIME=[82611780:01CE4F42] Cc: stable@freebsd.org, hackers@freebsd.org, current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 05:00:41 -0000 __________________________________________________________________ > > FreeNAS > > URL: http://www.FreeNAS.org/ > > Contact: Alfred Perlstein > Contact: Josh Paetzel > > FreeNAS 8.3.1-RELEASE-p2 will hit Sourceforge the second week of April, > and should end up as the last FreeNAS release based on FreeBSD 8.X It's > currently the only Free Open Source NAS product available with any form > of ZFS encryption (provided by GELI). > > Open tasks: > > 1. The team is hard at work on getting a FreeBSD 9.X-based release of > FreeNAS ready. Currently there are several nightly snapshots > available. > 2. Add HAST to the webinterface. > 3. Migrate to NFSv4. > 4. Integrate foundation sponsored kernel iSCSI target. > Uhmmmmmm WHAT??? FreeNAS is not the only Free Open Source NAS product available with any form of ZFS encryption (provided by GELI). NAS4Free has been doing it. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed May 15 05:35:55 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8DF231D5; Wed, 15 May 2013 05:35:55 +0000 (UTC) (envelope-from pgj@freebsd.org) Received: from mail1.ozon.ru (mx4.ozon.ru [194.186.179.140]) by mx1.freebsd.org (Postfix) with ESMTP id 50231E4C; Wed, 15 May 2013 05:35:53 +0000 (UTC) Received: from intmail03msk.ozon (intmail03msk.ozon [10.18.18.171]) by mail1.ozon.ru (Postfix) with ESMTP id B606F71A545; Wed, 15 May 2013 09:35:51 +0400 (MSK) Received: from mail pickup service by intmail03msk.ozon with Microsoft SMTPSVC; Wed, 15 May 2013 09:34:19 +0400 Received: from intmail03msk.ozon ([10.18.18.171]) by intmail02msk.ozon with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 May 2013 21:55:32 +0400 Received: from mail1.ozon.ru ([194.186.179.140]) by intmail03msk.ozon with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 May 2013 21:55:31 +0400 Received: from localhost (localhost [127.0.0.1]) by mail1.ozon.ru (Postfix) with ESMTP id 16E9D7195A8 for ; Sun, 12 May 2013 21:55:32 +0400 (MSK) X-Virus-Scanned: amavisd-new at ozon.ru Received: from mail1.ozon.ru ([127.0.0.1]) by localhost (mx4.ozon.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzTOTlfqpX-i for ; Sun, 12 May 2013 21:55:23 +0400 (MSK) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received-SPF: pass (freebsd.org: 8.8.178.116 is authorized to use 'owner-freebsd-current@freebsd.org' in 'mfrom' identity (mechanism 'ip4:8.8.178.116' matched)) receiver=mx4.ozon.ru; identity=mfrom; envelope-from="owner-freebsd-current@freebsd.org"; helo=mx2.freebsd.org; client-ip=8.8.178.116 Received: from mx2.freebsd.org (mx2.FreeBSD.org [8.8.178.116]) by mail1.ozon.ru (Postfix) with ESMTP id 4DA817196C3 for ; Sun, 12 May 2013 21:55:23 +0400 (MSK) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 545CC9F0; Sun, 12 May 2013 17:55:11 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by hub.freebsd.org (Postfix) with ESMTP id 51A429CC; Sun, 12 May 2013 17:55:11 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 63234802; Sun, 12 May 2013 17:54:58 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by mx1.freebsd.org (Postfix) with ESMTP id 6558067D; Sun, 12 May 2013 17:54:56 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id e49so1173774eek.5 for ; Sun, 12 May 2013 10:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:organization :x-mailer:mime-version:content-type:content-transfer-encoding; bh=eULesjOb39sJd/mJ0denfWWGMB8KfGMdpy/4x27l1Ew=; b=z6zg4xAouE04VXCoJM1e8hqP/Wnww+f6xosQwKSvxQeUV5plNkqe69mIGH5uhu6BnJ jcKF0I8sza6uBAs2S4DfxwQXtP5jjmyyFfYJdtT8EAH3kWGUiPZD2IahDhANtZkFB/T0 1YyQ1nPeQO/lxvRz+OEBFeqC3nKzzqnDri63tx95T5P5UeybTa48SikVwcXiY/dT/oTa uLzepYjMeCWEOtZqHIKJcMGV0fsGqzSJQ2NxoQ1s/GMaNVzACAKSzbKRmvsJHL30GDwa Z2v6TIq4ILM1VrRCbdKAyfE7LcyDreMLJ2RN1a5F82k9FdymxYvW8+49VPg9h8KkjuMC vLNQ== X-Received: by 10.14.0.129 with SMTP id 1mr68418742eeb.43.1368381289883; Sun, 12 May 2013 10:54:49 -0700 (PDT) Received: from funktor (catv-80-98-246-83.catv.broadband.hu. [80.98.246.83]) by mx.google.com with ESMTPSA id i2sm6674817eeg.2.2013.05.12.10.54.48 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sun, 12 May 2013 10:54:49 -0700 (PDT) Date: Sun, 12 May 2013 19:54:05 +0200 From: Gabor Pali To: hackers@freebsd.org Subject: FreeBSD Quarterly Status Report, January-March 2013 Message-ID: <20130512195405.04653b64@funktor> Organization: The FreeBSD Project X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; i386-portbld-freebsd9.1) Mime-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: owner-freebsd-current@freebsd.org Sender: owner-freebsd-current@freebsd.org X-OriginalArrivalTime: 12 May 2013 17:55:32.0002 (UTC) FILETIME=[E55B5020:01CE4F39] Cc: stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 05:35:55 -0000 RnJlZUJTRCBRdWFydGVybHkgU3RhdHVzIFJlcG9ydCwgSmFudWFyeS1NYXJjaCAyMDEzCgpJbnRy b2R1Y3Rpb24KCiAgIFRoaXMgcmVwb3J0IGNvdmVycyBGcmVlQlNELXJlbGF0ZWQgcHJvamVjdHMg YmV0d2VlbiBKYW51YXJ5IGFuZCBNYXJjaAogICAyMDEzLiBUaGlzIGlzIHRoZSBmaXJzdCBvZiBm b3VyIHJlcG9ydHMgcGxhbm5lZCBmb3IgMjAxMy4KCiAgIEhpZ2hsaWdodHMgZnJvbSB0aGlzIHN0 YXR1cyByZXBvcnQgaW5jbHVkZSB0aGUgYnVzeSBwcmVwYXJhdGlvbnMgb2YKICAgOC40LVJFTEVB U0UsIHJlc3RvcmF0aW9uIG9mIGJpbmFyeSBwYWNrYWdlIGJ1aWxkaW5nLCBzdGVhZHkgcHJvZ3Jl c3Mgb2YKICAgc2V2ZXJhbCBwb3J0aW5nIGVmZm9ydHMsIGxpa2Ugd29yayBvbiB0aGUgRnJlZUJT RCBwb3J0cyBvZiB4b3JnLCBHTk9NRSwKICAgS0RFLCBhbmQgWGZjZSwgYnJpbmdpbmcgRnJlZUJT RCB0byBDdWJpZWJvYXJkIGFuZCBIYWNrYmVycnkgYm9hcmRzLAogICBkZXZlbG9wbWVudCBvZiBB Uk0gYW5kIEFNRCBHUFUgc3VwcG9ydCwgaW1wcm92aW5nIHBlcmZvcm1hbmNlIG9mCiAgIFVGUy9G RlMgYW5kIGNhbGxvdXRzLCBhbmQgaW50cm9kdWNpbmcgYSBtdWx0aXBhdGggVENQIGltcGxlbWVu dGF0aW9uCiAgIGZvciB0aGUgbmV0d29yayBzdGFjay4KCiAgIFRoYW5rcyB0byBhbGwgdGhlIHJl cG9ydGVycyBmb3IgdGhlIGV4Y2VsbGVudCB3b3JrISBUaGlzIHJlcG9ydAogICBjb250YWlucyAz MSBlbnRyaWVzIGFuZCB3ZSBob3BlIHlvdSBlbmpveSByZWFkaW5nIGl0LgoKICAgVGhlIGRlYWRs aW5lIGZvciBzdWJtaXNzaW9ucyBjb3ZlcmluZyB0aGUgcGVyaW9kIGJldHdlZW4gQXByaWwgYW5k IEp1bmUKICAgMjAxMyBpcyBKdWx5IDd0aCwgMjAxMy4KICAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KClByb2plY3Rz CgogICAgICogRnJlZU5BUwogICAgICogS2VybmVsIEluZm9ybWF0aW9uIGluIFByb2Nlc3MgQ29y ZSBEdW1wcwogICAgICogTmF0aXZlIGlTQ1NJIFN0YWNrCgpGcmVlQlNEIFRlYW0gUmVwb3J0cwoK ICAgICAqIEZyZWVCU0QgQnVnbWVpc3RlciBUZWFtCiAgICAgKiBGcmVlQlNEIENvcmUgVGVhbQog ICAgICogRnJlZUJTRCBQb3J0IE1hbmFnZXJzCiAgICAgKiBGcmVlQlNEIFBvc3RtYXN0ZXIgVGVh bQogICAgICogRnJlZUJTRCBSZWxlYXNlIEVuZ2luZWVyaW5nIFRlYW0KCktlcm5lbAoKICAgICAq IEFNRCBHUFUgS2VybmVsIE1vZGUtU2V0dGluZyAoS01TKSBTdXBwb3J0CiAgICAgKiBBdG9taWMg ImNsb3NlLW9uLWV4ZWMiCiAgICAgKiBjYWxsb3V0KDkpIEltcHJvdmVtZW50cwogICAgICogTXVs dGlwYXRoIFRDUCAoTVBUQ1ApIGZvciBGcmVlQlNECiAgICAgKiByYWNjdDogQmxvY2sgSU8gQWNj b3VudGluZwogICAgICogUmVhZC1vbmx5IFBvcnQgb2YgTmV0QlNEJ3MgVURGIEZpbGUgU3lzdGVt CiAgICAgKiBUQ1AtQU8gQXV0aGVudGljYXRpb24gT3B0aW9uCiAgICAgKiBVRlMvRkZTIFBlcmZv cm1hbmNlIFdvcmsKCkRvY3VtZW50YXRpb24KCiAgICAgKiBJbXByb3ZpbmcgdGhlIERvY3VtZW50 YXRpb24gUHJvamVjdCBJbmZyYXN0cnVjdHJlCiAgICAgKiBUaGUgZW50aXRpZXMgRG9jdW1lbnRh dGlvbiBCcmFuY2gKICAgICAqIFRoZSBGcmVlQlNEIEphcGFuZXNlIERvY3VtZW50YXRpb24gUHJv amVjdAoKQXJjaGl0ZWN0dXJlcwoKICAgICAqIEZyZWVCU0Qgb24gQ3ViaWVib2FyZAogICAgICog RnJlZUJTRC9hcm0gU3VwZXJwYWdlcyBmb3IgQVJNdjcKICAgICAqIEZyZWVCU0QvQVJNIFRvb2xj aGFpbiBJbXByb3ZlbWVudHMKClBvcnRzCgogICAgICogRnJlZUJTRCBIYXNrZWxsIFBvcnRzCiAg ICAgKiBHTk9NRS9GcmVlQlNECiAgICAgKiBLREUvRnJlZUJTRAogICAgICogUHlQeQogICAgICog V2luZTMyIG9uIEZyZWVCU0QvYW1kNjQKICAgICAqIFhmY2UvRnJlZUJTRAogICAgICogeG9yZyBv biBGcmVlQlNECgpNaXNjZWxsYW5lb3VzCgogICAgICogQlhSLlNVIC0tIFN1cGVyIFVzZXIncyBC U0QgQ3Jvc3MgUmVmZXJlbmNlCiAgICAgKiBtZG9jLnN1IC0tIFNob3J0IE1hbnVhbCBQYWdlIFVS THMKICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KCkFNRCBHUFUgS2VybmVsIE1vZGUtU2V0dGluZyAoS01TKSBTdXBw b3J0CgogICBVUkw6IGh0dHBzOi8vd2lraS5mcmVlYnNkLm9yZy9BTURfR1BVCgogICBDb250YWN0 OiBKZWFuLVPDqWJhc3RpZW4gUMOpZHJvbiA8ZHVtYmJlbGxARnJlZUJTRC5vcmc+CiAgIENvbnRh Y3Q6IEouUi4gT2xkcm95ZCA8anJAb3BhbC5jb20+CiAgIENvbnRhY3Q6IEtvbnN0YW50aW4gQmVs b3Vzb3YgPGtpYkBGcmVlQlNELm9yZz4KCiAgIFRoZSBwcm9qZWN0IHByb2dyZXNzZWQgd2VsbCBz aW5jZSBGZWJydWFyeToKCiAgICAgKiBLb25zdGFudGluIGNvbW1pdHRlZCBpcyBUVE0gcG9ydCB0 byAxMC1DVVJSRU5ULgogICAgICogV2l0aCB0aGUgaGVscCBvZiBKb2huIEJhbGR3aW4gKGpoYikg YW5kIEFuZHJpeSBHYXBvbiAoYXZnKSwgdGhlCiAgICAgICBWaWRlbyBCSU9TIHNpdHVhdGlvbiBn cmVhdGx5IGltcHJvdmVkOiB0aGUgcmFkZW9ua21zIGRyaXZlciByZWFkcwogICAgICAgdGhlIEJJ T1Mgc2hhZG93IGNvcHkgaWYgdGhlIHZpZGVvIGNhcmQgaXMgdGhlIHByaW1hcnkgb25lLCBvciBx dWVyeQogICAgICAgdGhlIFBDSSBleHBhbnNpb24gUk9NIG90aGVyd2lzZS4gSW4gdGhlIGVuZCwg dGhpcyBjb2RlIHdpbGwgYmUKICAgICAgIHByb2JhYmx5IGNvbW1pdHRlZCB0byB0aGUgUENJIGRy aXZlciBzbyB0aGF0IG90aGVyIHZpZGVvIGRyaXZlcnMKICAgICAgIGJlbmVmaXQgZnJvbSBpdC4K ICAgICAqIEFuZHJpeSBhbHNvIHJlcG9ydGVkIHNldmVyYWwgcHJvYmxlbXMgd2l0aCB0aGUgSTJD IGNvZGUuIE5vdyB0aGF0CiAgICAgICB0aGV5IGFyZSBmaXhlZCwgdGhlIG1vbml0b3JzIHBsdWdn ZWQgaW50byBEVkkgYW5kIEhETUkgY29ubmVjdG9ycwogICAgICAgYXJlIGRldGVjdGVkIGFuZCB0 aGVpciBFRElEIGlzIHJlYWQgY29ycmVjdGx5LiBWR0EgY29ubmVjdG9yIGlzIG5vdAogICAgICAg dGVzdGVkIHNvIGZhci4KICAgICAqIFRoZXJlIGlzIGEgbG9ja2luZyBwcm9ibGVtIGluIGVpdGhl ciBUVE0gb3IgdGhlIFJhZGVvbiBkcml2ZXIgd2hpY2gKICAgICAgIHByZXZlbnRzIE9wZW5HTCBm cm9tIHdvcmtpbmcgcHJvcGVybHkuIEplYW4tU8OpYmFzdGllbiBpcyBjdXJyZW50bHkKICAgICAg IHRyYWNraW5nIHRoaXMgZG93bi4KICAgICAqIEouUi4gT2xkcm95ZCBzdGFydGVkIHRvIHdvcmsg b24gYSA5LVNUQUJMRSBiYWNrcG9ydCBvZiB0aGUgZHJpdmVyCiAgICAgICB3aGljaCBpcyBub3cg d29ya2luZyBxdWl0ZSB3ZWxsLiBIZSBoYWQgdG8gYmFja3BvcnQgc29tZSBmZWF0dXJlcwogICAg ICAgZnJvbSB0aGUgVk0gd2hpY2ggbWF5IG5lZWQgZnVydGhlciByZWZpbmVtZW50IGJ5IHRoZSBW TSBmb2xrcy4KCiAgIFlha2F6IGxlbmRlZCBKZWFuLVPDqWJhc3RpZW4gYSBjb21wdXRlciB3aGlj aCBhbGxvd3MgaGltIHRvIHRlc3QgYQogICBSVjYzMC1iYXNlZCBkaXNjcmV0ZSBjYXJkIGFuZCwg aW4gdGhlIGZ1dHVyZSwgb3RoZXIgUENJZSBjYXJkcy4gU2V2ZXJhbAogICB1c2VycyBhbHJlYWR5 IGtpbmRseSB0ZXN0ZWQgdGhlIGRyaXZlci4gQmlnIHRoYW5rcyB0byBhbGwgdGhvc2UKICAgY29u dHJpYnV0b3JzIQoKICAgSW4gaXRzIGN1cnJlbnQgc3RhdGUsIHRoZSBkcml2ZXIgYWxsb3dzIHRv IGhhdmUgYSBzaW1wbGUgWCBzZXNzaW9uIChubwogICBPcGVuR0wpLCBydW4gY29tbW9uIGFwcGxp Y2F0aW9ucywgd2F0Y2ggbW92aWVzLCBjaGFuZ2UgdGhlIHJlc29sdXRpb24KICAgYW5kIGVuYWJs ZSBhZGRpdGlvbmFsIG1vbml0b3JzIHdpdGggeHJhbmRyKDEpLiBUaGUgbW9zdCBibG9ja2luZyBp c3N1ZQogICBub3cgaXMgdGhlIE9wZW5HTCBkZWFkbG9jayB3aGljaCBwcmV2ZW50cyB0byBydW4g bW9kZXJuCiAgIGNvbXBvc2l0b3JzL2Rlc2t0b3AgZW52aXJvbm1lbnQsIGdhbWVzIGFuZCBXZWJH TCBkZW1vcy4gV2UgYXJlIG5vdAogICByZWFkeSBmb3IgYSAiQ2FsbCBGb3IgVGVzdGVycyIgeWV0 LgoKT3BlbiB0YXNrczoKCiAgICAxLiBUZXN0IG11bHRpcGxlIGNhcmRzIGNvbmZpZ3VyYXRpb25z IGZvciBWaWRlbyBCSU9TIGlzc3VlcywKICAgICAgIGVzcGVjaWFsbHkgSW50ZWwgaW50ZWdyYXRl ZCBjYXJkICsgUmFkZW9uIGRpc2NyZXRlIGNhcmQsIGFuZCBBTUQKICAgICAgIGludGVncmF0ZWQg Y2FyZCAoSUdQKSArIFJhZGVvbiBkaXNjcmV0ZSBjYXJkLiBObyBuZWVkIHRvIGNoZWNrCiAgICAg ICBjb25maWd1cmF0aW9ucyB3aXRoIG9uZSBzaGFyZWQgY29ubmVjdG9yIHRob3VnaCwgaXQgaXMg bm90CiAgICAgICBzdXBwb3J0ZWQgcmlnaHQgbm93LgogICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQXRvbWljICJj bG9zZS1vbi1leGVjIgoKICAgVVJMOiBodHRwczovL3dpa2kuZnJlZWJzZC5vcmcvQXRvbWljQ2xv c2VPbkV4ZWMKCiAgIENvbnRhY3Q6IEppbGxlcyBUam9lbGtlciA8amlsbGVzQEZyZWVCU0Qub3Jn PgoKICAgSWYgdGhyZWFkcyBvciBzaWduYWwgaGFuZGxlcnMgY2FsbCBmb3JrKCkgYW5kIGV4ZWMo KSwgZmlsZSBkZXNjcmlwdG9ycwogICBtYXkgYmUgcGFzc2VkIHVuZGVzaXJhYmx5IHRvIGNoaWxk IHByb2Nlc3Nlcywgd2hpY2ggbWF5IGxlYWQgdG8gaGFuZ3MKICAgKGlmIGEgcGlwZSBpcyBub3Qg Y2xvc2VkKSwgZXhjZWVkaW5nIHRoZSBmaWxlIGRlc2NyaXB0b3IgbGltaXQgYW5kCiAgIHNlY3Vy aXR5IHByb2JsZW1zIChpZiB0aGUgY2hpbGQgcHJvY2VzcyBoYXMgbG93ZXIgcHJpdmlsZWdlKS4g T25lCiAgIHNvbHV0aW9uIGlzIHZhcmlvdXMgbmV3IEFQSXMgdGhhdCBzZXQgdGhlICJjbG9zZS1v bi1leGVjIiBmbGFnCiAgIGF0b21pY2FsbHkgd2l0aCBhbGxvY2F0aW5nIGEgZmlsZSBkZXNjcmlw dG9yLiBTb21lIGV4aXN0aW5nIHNvZnR3YXJlCiAgIHdpbGwgdXNlIHRoZSBuZXcgZmVhdHVyZXMg aWYgcHJlc2VudCBvciB3aWxsIGV2ZW4gcmVmdXNlIHRvIGNvbXBpbGUKICAgd2l0aG91dCB0aGVt LgoKICAgVmFyaW91cyBwYXJ0cyBoYXZlIGJlZW4gcHJlc2VudCBmb3Igc29tZSB0aW1lLgoKICAg SW4gZmlyc3QgcXVhcnRlciBvZiAyMDEzLCBleHRlbnNpb25zIHRvIHJlY3Ztc2coKSwgc29ja2V0 KCksCiAgIHNvY2tldHBhaXIoKSBhbmQgcG9zaXhfb3BlbnB0KCkgaGF2ZSBiZWVuIGFkZGVkLgog ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwoKQlhSLlNVIC0tIFN1cGVyIFVzZXIncyBCU0QgQ3Jvc3MgUmVmZXJlbmNl CgogICBVUkw6IGh0dHA6Ly9ieHIuc3UvCiAgIFVSTDogaHR0cDovL2xpc3RzLmZyZWVic2Qub3Jn L3BpcGVybWFpbC9mcmVlYnNkLWhhY2tlcnMvMjAxMy1BcHJpbC8wNDIzMzQuaHRtbAoKICAgQ29u dGFjdDogQ29uc3RhbnRpbmUgQS4gTXVyZW5pbiA8Y25zdCsrQEZyZWVCU0Qub3JnPgoKICAgU3Vw ZXIgVXNlcidzIEJTRCBDcm9zcyBSZWZlcmVuY2UgKEJYUi5TVSkgaXMgYSBuZXcgc291cmNlLWNv ZGUgc2VhcmNoCiAgIGVuZ2luZSB0aGF0IGNvdmVycyB0aGUgY29tcGxldGUga2VybmVsIGFuZCBu b24tR05VIHVzZXJsYW5kIHNvdXJjZQogICB0cmVlcyBvZiBGcmVlQlNELCBOZXRCU0QsIE9wZW5C U0QsIGFuZCBEcmFnb25GbHkgQlNELgoKICAgQlhSLlNVIGlzIG9wdGltaXNlZCB0byBiZSB2ZXJ5 IGZhc3QsIGhhcyBkYWlseSB1cGRhdGVzIG9mIGFsbCB0aGUKICAgdHJlZXMsIGFuZCBhbHNvIGFj dHMgYXMgYSBkZXRlcm1pbmlzdGljIFVSTCBzaG9ydGVuZXIuCgogICBCWFIuU1UgaXMgYmFzZWQg b24gYW4gT3Blbkdyb2sgZm9yaywgYnV0IGl0IGlzIG1vcmUgdGhhbiBqdXN0IE9wZW5Hcm9rLgog ICBXZSBoYXZlIGZpeGVkIGEgbnVtYmVyIG9mIGFubm95YW5jZXMsIGVsaW1pbmF0ZWQgZmVhdHVy ZXMgdGhhdCBqdXN0CiAgIG5ldmVyIHdvcmtlZCByaWdodCBmcm9tIHRoZSBvdXRyaWdodCwgYW5k IHByb3ZpZGVkIGludGVncmF0aW9uIHdpdGgKICAgdG9vbHMgbGlrZSBDVlN3ZWIgKGluY2x1ZGlu ZyBncmVhdCBtaXJyb3JzIGxpa2UgYWxsYnNkLm9yZyksIEZyZWVCU0QncwogICBWaWV3VkMgKFNW TiksIGFzIHdlbGwgYXMgR2l0SHViIGFuZCBHaXR3ZWIgZnJvbSBnaXQuZnJlZWJzZC55b3VyLm9y ZywKICAgcGx1cyBhIHRhZCBvZiBvdGhlciBpbXByb3ZlbWVudHMsIGluY2x1ZGluZyBhIGNvbXBs ZXRlIHJld3JpdGUgb2YgYW4KICAgbWRvYyBwYXJzZXIuIExhc3QsIGJ1dCBkZWZpbml0ZWx5IG5v dCBsZWFzdCwgaXMgYW4gZXh0ZW5zaXZlIHNldCBvZgogICBuZ2lueCByZXdyaXRlIHJ1bGVzIHRo YXQgbWFrZXMgaXQgYSBicmVlemUgdG8gdXNlIEJYUi5TVSBhcyBhCiAgIGRldGVybWluaXN0aWMg VVJMIGNvbXBhY3RvciBmb3IgcmVmZXJlbmNpbmcgQlNEIHNvdXJjZSBjb2RlLiBGb3IKICAgZXhh bXBsZSwgdGhlIGh0dHA6Ly9ieHIuc3UvZi9rZXJuL3NjaGVkX3VsZS5jIFVSTCB3aWxsIGF1dG9t YXRpY2FsbHkKICAgcmVkaXJlY3QgdG8gaHR0cDovL2J4ci5zdS9GcmVlQlNEL3N5cy9rZXJuL3Nj aGVkX3VsZS5jIHRocm91Z2ggbmdpbnguCgogICBOb3RlIHRoYXQgYWNjb3JkaW5nIHRvIHRoZSBy ZWxlYXNlIHNjaGVkdWxlIG9mIEJYUi5TVSwgdGhlcmUgaXMgbm8gSVB2NAogICBnbHVlIHVudGls IDIwMTMtMDQtMjQ7IG90aGVyd2lzZSwgdGhlIHNlcnZpY2UgaXMgYXZhaWxhYmxlIHZpYSBib3Ro CiAgIElQdjQgYW5kIElQdjYuIFNlZSB0aGUgMjAxMy0wNC0wMSBhbm5vdW5jZW1lbnQgb24gdGhl IGZyZWVic2QtaGFja2VycwogICBtYWlsaW5nIGxpc3QgZm9yIG1vcmUgZGV0YWlscy4KCk9wZW4g dGFza3M6CgogICAgMS4gRmluZCB1cC10by1kYXRlIGdpdCByZXBvc2l0b3JpZXMgKHNlcnZlZCB3 aXRoIEdpdHdlYikgb2YgTmV0QlNEIGFuZAogICAgICAgT3BlbkJTRC4KICAgIDIuIEZpbmQgYSBH aXR3ZWIgbWlycm9yIG9mIEZyZWVCU0QgdGhhdCBpcyBmYXN0ZXIgdGhhbiBHaXRIdWIgYW5kCiAg ICAgICBHaXRvcmlvdXMuCiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpjYWxsb3V0KDkpIEltcHJvdmVtZW50cwoK ICAgVVJMOiBodHRwOi8vcGVvcGxlLmZyZWVic2Qub3JnL35kYXZpZGUvYXNpYS9jYWxsb3V0X3Bh cGVyLnBkZgogICBVUkw6IGh0dHA6Ly9wZW9wbGUuZnJlZWJzZC5vcmcvfmRhdmlkZS9hc2lhL2Nh bGxvdXRuZy5wZGYKICAgVVJMOiBodHRwOi8vc3Zud2ViLmZyZWVic2Qub3JnL2Jhc2U/dmlldz1y ZXZpc2lvbiZyZXZpc2lvbj0yNDc3NzcKCiAgIENvbnRhY3Q6IERhdmlkZSBJdGFsaWFubyA8ZGF2 aWRlQEZyZWVCU0Qub3JnPgogICBDb250YWN0OiBBbGV4YW5kZXIgTW90aW4gPG1hdkBGcmVlQlNE Lm9yZz4KCiAgIEluIEZyZWVCU0QsIHRpbWVycyBhcmUgcHJvdmlkZWQgYnkgdGhlIGNhbGxvdXQg ZmFjaWxpdHksIHdoaWNoIGFsbG93cwogICB0byByZWdpc3RlciBhIGZ1bmN0aW9uIHdpdGggYW4g YXJndW1lbnQgdG8gYmUgY2FsbGVkIGF0IHNwZWNpZmllZAogICBmdXR1cmUgdGltZS4gVGhlIHN1 YnN5c3RlbSBzdWZmZXJlZCBvZiBzb21lIHByb2JsZW1zLCBzdWNoIGFzIHRoZQogICBpbXBvc3Np YmlsaXR5IG9mIGhhbmRsaW5nIGhpZ2gtcmVzb2x1dGlvbiBldmVudHMgb3IgaXRzIGluaGVyZW50 CiAgIHBlcmlvZGljIHN0cnVjdHVyZSwgd2hpY2ggbWF5IGxlYWQgdG8gc3B1cmlvdXMgd2FrZXVw cyBhbmQgaGlnaGVyIHBvd2VyCiAgIGNvbnN1bXB0aW9uLiBTb21lIGNvbnN1bWVycywgc3VjaCBh cyBoaWdoLXNwZWVkIG5ldHdvcmtpbmcsIFZvSVAgYW5kCiAgIG90aGVyIHJlYWwtdGltZSBhcHBs aWNhdGlvbnMgbmVlZCBhIGJldHRlciBwcmVjaXNpb24gdGhhbiB0aGUgb25lCiAgIGN1cnJlbnRs eSBhbGxvd2VkLiBBbHNvLCBlc3BlY2lhbGx5IHdpdGggdGhlIHViaXF1aXR5IG9mIGxhcHRvcHMg aW4gdGhlCiAgIGxhc3QgeWVhcnMsIHRoZSBlbmVyZ3kgd2FzdGVkIGJ5IGludGVycnVwdHMgd2Fr aW5nIENQVXMgZnJvbSBzbGVlcCBtYXkKICAgYmUgYSBzZW5zaXRpdmUgZmFjdG9yLiBSZWNlbnQg Y2hhbmdlcyBpbiB0aGUgc3Vic3lzdGVtIGFkZHJlc3NlZCB0aG9zZQogICBsb25nLXN0YW5kaW5n IGlzc3VlcyBhcyB3ZWxsIGFzIGludHJvZHVjZWQgYSBuZXcgcHJvZ3JhbW1pbmcgaW50ZXJmYWNl CiAgIHRvIHRha2UgYWR2YW50YWdlIG9mIHRoZSBuZXcgZmVhdHVyZXMuCgpPcGVuIHRhc2tzOgoK ICAgIDEuIEV2YWx1YXRpbmcgaWYgaXQgaXMgd29ydGggdG8gbWlncmF0ZSBhbnkgb2YgdGhlIG90 aGVyIGNhbGxvdXQoOSkKICAgICAgIGNvbnN1bWVycyB0byB0aGUgbmV3IGludGVyZmFjZS4KICAg IDIuIE1vdmUgY2FsbG91dCBjb25zdW1lcnMgc3RpbGwgdXNpbmcgdGhlIGxlZ2FjeSB0aW1lb3V0 KCkvdW50aW1lb3V0KCkKICAgICAgIGludGVyZmFjZSB0byBjYWxsb3V0XyooKSBpbiBvcmRlciB0 byBnZXQgcmlkIG9mIHJlZHVuZGFudCBjb2RlIGFuZAogICAgICAgY2xlYW4gdXAgS1BJLgogICAg IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwoKRnJlZUJTRCBCdWdtZWlzdGVyIFRlYW0KCiAgIENvbnRhY3Q6IEVpdGFuIEFk bGVyIDxlYWRsZXJARnJlZUJTRC5vcmc+CiAgIENvbnRhY3Q6IEdhdmluIEF0a2luc29uIDxnYXZp bkBGcmVlQlNELm9yZz4KICAgQ29udGFjdDogT2xla3NhbmRyIFR5bW9zaGVua28gPGdvbnpvQEZy ZWVCU0Qub3JnPgoKICAgVGhlIEZyZWVCU0QgQnVnbWVpc3RlciBUZWFtIGFyZSBjb250aW51aW5n IHRvIGV2YWx1YXRlIG9wdGlvbnMgZm9yCiAgIGFsdGVybmF0ZSBidWcgdHJhY2tlcnMgYW5kIGhh dmUgbmFycm93ZWQgdGhlaXIgY2hvaWNlcyB0byB0d28KICAgcG9zc2liaWxpdGllczogQnVnemls bGEgYW5kIHJvdW5kdXAuCgogICBUaGUgbnVtYmVyIG9mIG5vbi1wb3J0cyBQUnMgaGF2ZSByZW1h aW5lZCByZWxhdGl2ZWx5IHN0YXRpYyBvdmVyIHRoZQogICBsYXN0IHRocmVlIG1vbnRocywgd2l0 aCBhcyBtYW55IGNvbWluZyBpbiBhcyBiZWluZyBjbG9zZWQuIFRoZSBudW1iZXIKICAgb2YgcG9y dHMgUFJzIGhhdmUgaW5jcmVhc2VkIHJlY2VudGx5LCBsYXJnZWx5IGR1ZSB0byB0aGUgcG9ydHMg ZnJlZXplCiAgIGZvciB0aGUgdXBjb21pbmcgOC40LVJFTEVBU0UuCgogICBUaGUgQnVnbWVpc3Rl ciB0ZWFtIGNvbnRpbnVlIHdvcmsgb24gdHJ5aW5nIHRvIG1ha2UgdGhlIGNvbnRlbnRzIG9mIHRo ZQogICBHTkFUUyBQUiBkYXRhYmFzZSBjbGVhbmVyLCBtb3JlIGFjY2Vzc2libGUgYW5kIGVhc2ll ciBmb3IgY29tbWl0dGVycyB0bwogICBmaW5kIGFuZCByZXNvbHZlIFBScywgYnkgdGFnZ2luZyBQ UnMgdG8gaW5kaWNhdGUgdGhlIGFyZWFzIGludm9sdmVkLAogICBhbmQgYnkgZW5zdXJpbmcgdGhh dCB0aGVyZSBpcyBzdWZmaWNpZW50IGluZm8gd2l0aGluIGVhY2ggUFIgdG8gcmVzb2x2ZQogICBl YWNoIGlzc3VlLgoKICAgQXMgYWx3YXlzLCBhbnlib2R5IGludGVyZXN0ZWQgaW4gaGVscGluZyBv dXQgd2l0aCB0aGUgUFIgcXVldWUgaXMKICAgd2VsY29tZSB0byBqb2luIHVzIGluICNmcmVlYnNk LWJ1Z2J1c3RlcnMgb24gRUZuZXQuIFdlIGFyZSBhbHdheXMKICAgbG9va2luZyBmb3IgYWRkaXRp b25hbCBoZWxwLCB3aGV0aGVyIHlvdXIgaW50ZXJlc3RzIGxpZSBpbiB0cmlhZ2luZwogICBpbmNv bWluZyBQUnMsIGdlbmVyYXRpbmcgcGF0Y2hlcyB0byByZXNvbHZlIGV4aXN0aW5nIHByb2JsZW1z LCBvcgogICBzaW1wbHkgaGVscGluZyB3aXRoIHRoZSBkYXRhYmFzZSBob3VzZWtlZXBpbmcgKGlk ZW50aWZ5aW5nIGR1cGxpY2F0ZQogICBQUnMsIG9uZXMgdGhhdCBoYXZlIGFscmVhZHkgYmVlbiBy ZXNvbHZlZCwgZXRjKS4gVGhpcyBpcyBhIGdyZWF0IHdheSBvZgogICBnZXR0aW5nIG1vcmUgaW52 b2x2ZWQgd2l0aCBGcmVlQlNEIQoKT3BlbiB0YXNrczoKCiAgICAxLiBGaW5hbGl6ZSB0aGUgZGVj aXNpb24gb2Ygd2hpY2ggbmV3IGJ1ZyB0cmFja2VyIHRvIHVzZS4KICAgIDIuIEdldCBtb3JlIHVz ZXJzIGludm9sdmVkIHdpdGggdHJpYWdpbmcgUFJzIGFzIHRoZXkgY29tZSBpbi4KICAgIDMuIEFz c2lzdCBjb21taXR0ZXJzIHdpdGggY2xvc2luZyBQUnMuCiAgICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpGcmVlQlNE IENvcmUgVGVhbQoKICAgQ29udGFjdDogQ29yZSBUZWFtIDxjb3JlQEZyZWVCU0Qub3JnPgoKICAg QXQgdGhlIGVuZCBvZiAyMDEyLCB0aGUgQ29yZSBUZWFtIGFwcHJvdmVkIHVzaW5nIEdvb2dsZSBB bmFseXRpY3Mgb24KICAgdGhlIFByb2plY3Qgd2ViIHNpdGUgdG8gZW5hYmxlIHRoZSBEb2N1bWVu dGF0aW9uIEVuZ2luZWVyaW5nIFRlYW0gdG8KICAgY29sbGVjdCBzdGF0aXN0aWNzIG9uIGl0cyB1 c2FnZSBmb3IgYmV0dGVyIHByb2ZpbGluZy4gSW4gdGhlIGZpcnN0CiAgIHF1YXJ0ZXIgb2YgMjAx MywgdGhlIENvcmUgVGVhbSB3b3JrZWQgd2l0aCB0aGUgRG9jdW1lbnRhdGlvbgogICBFbmdpbmVl cmluZyBUZWFtIHRvIGZpbmFsaXplIHRoZSBhc3NvY2lhdGVkIHBvbGljaWVzLgoKICAgRHVlIHRv IHNvbWUgZGViYXRlcyBhcm91bmQgdGhlIHBvbGl0aWNhbCBjb3JyZWN0bmVzcyBvZiBxdW90ZXMg YWRkZWQKICAgZm9yIHRoZSBmb3J0dW5lKDYpIHV0aWxpdHksIHRoZSBjb3JyZXNwb25kaW5nIGRh dGEgZmlsZSBoYXMgYmVlbgogICByZW1vdmVkIGZyb20gdGhlIGJhc2Ugc3lzdGVtIGluIC1DVVJS RU5ULgoKICAgSW4gbGlnaHQgb2YgdGhlIHNlY3VyaXR5IGluY2lkZW50LCB0aGUgbGlhaXNvbiBy b2xlIGJldHdlZW4gdGhlIENvcmUKICAgVGVhbSBhbmQgdGhlIFNlY3VyaXR5IFRlYW0gaGFzIGJl ZW4gcmVzdG9yZWQsIHdpdGggR2F2aW4gQXRraW5zb24KICAgYXNzdW1pbmcgdGhpcyByb2xlLiBU aGUgQ29yZSBUZWFtIHdvcmsgaGFyZCBvbiByZXNvbHZpbmcgdGhlIGN1cnJlbnQKICAgc2l0dWF0 aW9uIG9mIHRoZSBiaW5hcnkgcGFja2FnZSBidWlsZGluZyBjbHVzdGVyIGFuZCB0aGUgYXNzb2Np YXRlZAogICBzZWN1cml0eSBwcm9ibGVtcyBpbiB0aWdodCBjb29wZXJhdGlvbiB3aXRoIHRoZSBQ b3J0cyBNYW5hZ2VtZW50IFRlYW0sCiAgIENsdXN0ZXIgQWRtaW5pc3RhdG9ycywgYW5kIHRoZSBG cmVlQlNEIEZvdW5kYXRpb24gQm9hcmQuIFRoZSBjb21wcm9taXNlCiAgIHBhZ2UgaXMga2VwdCB1 cGRhdGVkIG9uIHRoZSByZXN1bHRzLgoKICAgVGhlIEZyZWVCU0QgUHJvamVjdCBzdWJtaXR0ZWQg YW4gYXBwbGljYXRpb24gZm9yIEdvb2dsZSBTdW1tZXIgb2YgQ29kZQogICB0aGlzIHllYXIgYWdh aW4uCgogICBUaGVyZSB3YXMgYWNjZXNzIGdyYW50ZWQgZm9yIDIgbmV3IGNvbW1pdHRlcnMgYW5k IDEgY29tbWl0IGJpdCB3YXMKICAgdGFrZW4gZm9yIHNhZmVrZWVwaW5nIGluIHRoaXMgcXVhcnRl ci4KICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KCkZyZWVCU0QgSGFza2VsbCBQb3J0cwoKICAgVVJMOiBodHRwOi8v d2lraS5mcmVlYnNkLm9yZy9IYXNrZWxsCiAgIFVSTDogaHR0cHM6Ly9naXRodWIuY29tL2ZyZWVi c2QtaGFza2VsbC9mcmVlYnNkLWhhc2tlbGwvCgogICBDb250YWN0OiBHw6Fib3IgUMOhbGkgPHBn akBGcmVlQlNELm9yZz4KICAgQ29udGFjdDogQXNoaXNoIFNodWtsYSA8YXNoaXNoQEZyZWVCU0Qu b3JnPgoKICAgV2UgYXJlIHByb3VkIHRvIGFubm91bmNlIEZyZWVCU0QgSGFza2VsbCBUZWFtIGhh cyB1cGRhdGVkIGV4aXN0aW5nCiAgIHBvcnRzIHRvIHRoZWlyIGxhdGVzdCBzdGFibGUgdmVyc2lv bnMuIFdlIGFsc28gYWRkZWQgbnVtYmVyIG9mIG5ldwogICBwb3J0cywgd2hpY2ggYnJpbmdzIHRo ZSBjb3VudCBvZiBIYXNrZWxsIHBvcnRzIGluIEZyZWVCU0QgcG9ydHMgdHJlZSB0bwogICBtb3Jl IHRoYW4gNDAwLCBmZWF0dXJpbmcgbWFueSBwb3B1bGFyIHNvZnR3YXJlLCBlLmcuIHhtb25hZCwg Z2l0LWFubmV4LAogICBwYW5kb2Mgb3IgdmFyaW91cyB3ZWIgZnJhbWV3b3JrIGltcGxlbWVudGF0 aW9ucy4gQWxsIG9mIHRoZXNlIHVwZGF0ZXMKICAgd2lsbCBiZSBhdmFpbGFibGUgYXMgcGFydCBv ZiB0aGUgdXBjb21pbmcgOC40LVJFTEVBU0UuIFdlIGFsc28gY2FtZSB0bwogICBrbm93IHRoYXQg SGFza2VsbCBwb3J0cyBhcmUgYWxzbyBiZWluZyB1c2VkIHN1Y2Nlc3NmdWxseSBvbgogICBEcmFn b25GbHlCU0QncyBkcG9ydHMgdHJlZS4KCiAgIEluIG91ciBkZXZlbG9wbWVudCByZXBvc2l0b3J5 LCB0aGVyZSB3YXMgc29tZSBvcHRpb25hbCBzdXBwb3J0IGFkZGVkCiAgIGZvciBMTFZNLWJhc2Vk IGNvZGUgZ2VuZXJhdGlvbiB1c2luZyB0aGUgR0hDIExMVk0gYmFja2VuZC4gVGhpcyB3b3Jrcwog ICBtb3N0bHkgb24gRnJlZUJTRCB0b28sIHRob3VnaCBzb21lIG9mIHRoZSBwb3J0cyB3b3VsZCBu ZWVkIGZpeGluZyBzbyBpdAogICBpcyBzdGlsbCBjb25zaWRlcmVkIGV4cGVyaW1lbnRhbC4KCk9w ZW4gdGFza3M6CgogICAgMS4gVHJ5IHRvIGJ1aWxkIEdIQyB3aXRoIGNsYW5nIChhcyBzeXN0ZW0g Y29tcGlsZXIpLgogICAgMi4gQ29tbWl0IHBlbmRpbmcgSGFza2VsbCBwb3J0cyB0byB0aGUgRnJl ZUJTRCBwb3J0cyB0cmVlLgogICAgMy4gQWRkIG1vcmUgcG9ydHMgdG8gdGhlIFBvcnRzIENvbGxl Y3Rpb24uCiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCgpGcmVlQlNEIG9uIEN1YmllYm9hcmQKCiAgIENvbnRhY3Q6 IEdhbmJvbGQgVHNhZ2FhbmtodXUgPGdhbmJvbGRARnJlZUJTRC5vcmc+CiAgIENvbnRhY3Q6IE9s ZWtzYW5kciBUeW1vc2hlbmtvIDxnb256b0BGcmVlQlNELm9yZz4KCiAgIEluaXRpYWwgc3VwcG9y dCBvZiBBbGx3aW5uZXIgQTEwIFNvQyBpcyBjb21taXR0ZWQgdG8gLUNVUlJFTlQuIEZyZWVCU0QK ICAgaXMgbm93IHJ1bm5pbmcgb24gYm9hcmRzIHN1Y2ggYXMgQ3ViaWVib2FyZCwgSGFja2JlcnJ5 IGFuZCBpdCBzdXBwb3J0cwogICBmb2xsb3dpbmcgcGVyaXBoZXJhbHM6CiAgICAgKiBVU0IgRUhD SQogICAgICogR1BJTwoKT3BlbiB0YXNrczoKCiAgICAxLiBHZXQgRU1BQyBFdGhlcm5ldCBkcml2 ZXIgd29ya2luZy4gTmVlZCBtb3JlIGhlbHAgZnJvbSBuZXR3b3JrCiAgICAgICBkcml2ZXIgZXhw ZXJ0cy4KICAgIDIuIEltcGxlbWVudCBtb3JlIGRyaXZlcnMuCiAgICAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpGcmVl QlNEIFBvcnQgTWFuYWdlcnMKCiAgIFVSTDogaHR0cDovL3d3dy5GcmVlQlNELm9yZy9wb3J0cy8K ICAgVVJMOiBodHRwOi8vd3d3LmZyZWVic2Qub3JnL2RvYy9lbi9hcnRpY2xlcy9jb250cmlidXRp bmctcG9ydHMvCiAgIFVSTDogaHR0cDovL3BvcnRzbW9uLmZyZWVic2Qub3JnLwogICBVUkw6IGh0 dHA6Ly93d3cuZnJlZWJzZC5vcmcvcG9ydG1nci8KICAgVVJMOiBodHRwOi8vYmxvZ3MuZnJlZWJz ZGlzaC5vcmcvcG9ydG1nci8KICAgVVJMOiBodHRwOi8vd3d3LnR3aXR0ZXIuY29tL2ZyZWVic2Rf cG9ydG1nci8KICAgVVJMOiBodHRwOi8vd3d3LmZhY2Vib29rLmNvbS9wb3J0bWdyCgogICBDb250 YWN0OiBUaG9tYXMgQWJ0aG9ycGUgPHBvcnRtZ3Itc2VjcmV0YXJ5QEZyZWVCU0Qub3JnPgogICBD b250YWN0OiBQb3J0IE1hbmFnZW1lbnQgVGVhbSA8cG9ydG1nckBGcmVlQlNELm9yZz4KCiAgIFRo ZSBwb3J0cyB0cmVlIGNvbnRhaW5zIGFwcHJveGltYXRlbHkgMjQsMzAwIHBvcnRzLCB3aGlsZSB0 aGUgUFIgY291bnQKICAgc3RpbGwgaXMgY2xvc2UgdG8gMTYwMC4KCiAgIEluIHRoZSBmaXJzdCBx dWFydGVyIHdlIGFkZGVkIDQgbmV3IGNvbW1pdHRlcnMsIHRvb2sgaW4gMSBjb21taXQgYml0CiAg IGZvciBzYWZlIGtlZXBpbmcsIGFuZCByZS1pbnN0YXRlZCAxIGNvbW1pdCBiaXQuCgogICBJbiBG ZWJydWFyeSwgTWFyayBMaW5pbW9uIChsaW5pbW9uKSBzdGVwcGVkIGRvd24gZnJvbSBoaXMgZHV0 aWVzIGluIHRoZQogICB0ZWFtLiBNYXJrIGhhZCBiZWVuIHRoZSBsb25nZXN0IHNlcnZpbmcgbWVt YmVyIG9mIHRoZSB0ZWFtLiBNYXJrIGhhZAogICBzcGVudCBtYW55IGxvbmcgaG91cnMgcmVmYWN0 b3JpbmcgYW5kIGRvY3VtZW50aW5nIHRoZSBwb3J0YnVpbGQKICAgc29mdHdhcmUgdG8gZW5zdXJl IHRoYXQgcG9pbnR5aGF0IHNlcnZpY2VzIGNvdWxkIGJlIHJlc3RvcmVkLgoKICAgQWZ0ZXIgYSBz ZWN1cml0eSByZXZpZXcsIHJlZHBvcnRzLm9yZyB3YXMgdHVybmVkIGJhY2sgb24sIHJlc3Rvcmlu ZwogICBUaW5kZXJib3ggc2VydmljZXMgdG8gY29udHJpYnV0b3JzLCBhbG9uZyB3aXRoIHBvc3Qg Y29tbWl0IFFBVHMuIEluCiAgIGFkZGl0aW9uLCBwb2ludHloYXQgaW5mcmFzdHJ1Y3R1cmUgaGFk IGFsc28gdW5kZXJnb25lIGEgcmV2aWV3IGFuZCB3b3JrCiAgIGJlZ2FpbiBvbiByZXN0b3Jpbmcg dGhlIHBhY2thZ2UgYnVpbGQgc3lzdGVtLgoKICAgRXJ3aW4gTGFuc2luZyAoZXJ3aW4pIGFuZCBN YXJ0aW4gV2lsa2UgKG1pd2kpIHRvb2sgb24gdGhlIHByaW5jaXBsZQogICByb2xlcyBvZiBnZXR0 aW5nIHRoZSBwb3J0YnVpbGQgc29mdHdhcmUgaW5zdGFsbGVkIGFuZCBydW5uaW5nIG9uCiAgIHBv aW50eWhhdC4gQXMgYSByZXN1bHQgb2YgYWxsIHRoZWlyIGhhcmQgd29yaywgcG9ydG1nckAgd2Fz IGZpbmFsbHkKICAgYWJsZSB0byByZXN1bWUgZG9pbmcgLWV4cCBydW5zLCBwcmVwYXJpbmcgcGFj a2FnZXMgZm9yIHRoZSB1cGNvbWluZyA4LjQKICAgcmVsZWFzZSwgYXMgd2VsbCBhcyBnZXR0aW5n IGEgc2V0IG9mIDkuMSBwYWNrYWdlcyByZXRyb2FjdGl2ZWx5CiAgIHByZXBhcmVkLgoKICAgQWZ0 ZXIgbWFueSBsb25nIHllYXJzIG9mIGJlaW5nIHRoZSBkZWZhY3RvIHN0YW5kYXJkIGZvciB0aGUg UHJvamVjdCwKICAgQ1ZTIHN1cHBvcnQgZm9yIHRoZSBwb3J0cyB0cmVlIG9mZmljaWFsbHkgZW5k ZWQgb24gRmVicnVhcnkgMjguCgogICBUaGUgcG9ydHMgdHJlZSB3YXMgdGFnZ2VkIHdpdGggUkVM RUFTRV83X0VPTCwgdG8gY29pbmNpZGUgd2l0aCB0aGUgZW5kCiAgIG9mIGxpZmUgZm9yIEZyZWVC U0QgNy5YLgoKICAgQmVhdCBHYWV0emkgKGJlYXQpIHN0ZXBwZWQgZG93biBmcm9tIGhpcyBkdXRp ZXMgb24gcG9ydG1nckAgaW4gTWFyY2guCiAgIEFtb25nIGhpcyBub3RhYmxlIGNvbnRyaWJ1dGlv bnMsIHdhcyB0aGUgdGFzayBvZiBtaWdyYXRpbmcgdGhlIFBvcnRzCiAgIFRyZWUgZnJvbSB0aGUg b2xkIENWUyByZXBvIHRvIFN1YnZlcnNpb24uCgogICBCcnlhbiBEcmV3ZXJ5IChiZHJld2VyeSkg am9pbmVkIHRoZSBQb3J0cyBNYW5hZ2VtZW50IHRlYW0gaW4gTWFyY2gsCiAgIGJyaW5naW5nIHdp dGggaGltIGhpcyB3ZWFsdGggb2Yga25vd2xlZGdlIGFuZCBza2lsbCBmcm9tIG1haW50YWluaW5n CiAgIHBvcnR1cGdyYWRlLCBwb3J0bWFzdGVyLCBhc3Npc3Rpbmcgd2l0aCBwa2duZywgYXMgd2Vs bCBhcyBjby1kZXZlbG9waW5nCiAgIHBvdWRyaWVyZS4KCk9wZW4gdGFza3M6CgogICAgMS4gTW9z dCBwb3J0cyBQUnMgYXJlIGFzc2lnbmVkLCB3ZSBub3cgbmVlZCB0byBmb2N1cyBvbiB0ZXN0aW5n LAogICAgICAgY29tbWl0dGluZyBhbmQgY2xvc2luZy4KICAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkZyZWVCU0Qg UG9zdG1hc3RlciBUZWFtCgogICBDb250YWN0OiBEYXZpZCBXb2xmc2tpbGwgPHBvc3RtYXN0ZXJA RnJlZUJTRC5vcmc+CgogICBJbiB0aGUgZmlyc3QgcXVhcnRlciBvZiAyMDEzLCB0aGUgRnJlZUJT RCBQb3N0bWFzdGVyIFRlYW0gaGFzCiAgIGltcGxlbWVudGVkIHRoZSBmb2xsb3dpbmcgaXRlbXMg dGhhdCBtYXkgYmUgaW50ZXJlc3Qgb2YgdGhlIGdlbmVyYWwKICAgcHVibGljOgoKICAgICAqIENo YW5nZXMgaW4gY29uZmlndXJhdGlvbiBvZiBNYWlsbWFuLW1hbmFnZWQgbGlzdHM6IGFsbG93IHRv IGFjY2VwdAogICAgICAgdGhlIGFwcGxpY2F0aW9uL3BrY3M3LXNpZ25hdHVyZSBNSU1FIHR5cGUg KGluIGFkZGl0aW9uIHRvIHRoZQogICAgICAgYXBwbGljYXRpb24veC1wa2NzNy1zaWduYXR1cmUg TUlNRSB0eXBlKSwgdGh1cyBwZXJtaXR0aW5nIFMvTUlNRQogICAgICAgc2lnbmF0dXJlcyBvbiBs aXN0IG1haWwuCiAgICAgKiBOZXcgbGlzdHM6IGZyZWVic2Qtb3BzLWFubm91bmNlIC0tIGFubm91 bmNlbWVudHMgb2YgaW5mcmFzdHJ1Y3R1cmUKICAgICAgIGlzc3VlcywgYW5kIGZyZWVic2QtcGtn IC0tIGRpc2N1c3Npb24gb2YgYmluYXJ5IHBhY2thZ2UgbWFuYWdlbWVudAogICAgICAgYW5kIHBh Y2thZ2UgdG9vbHMuCiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCgpGcmVlQlNEIFJlbGVhc2UgRW5naW5lZXJpbmcg VGVhbQoKICAgVVJMOiBodHRwOi8vd3d3LmZyZWVic2Qub3JnL3JlbGVhc2VzLzguNFIvc2NoZWR1 bGUuaHRtbAoKICAgQ29udGFjdDogRnJlZUJTRCBSZWxlYXNlIEVuZ2luZWVyaW5nIFRlYW0gPHJl QEZyZWVCU0Qub3JnPgoKICAgRnJlZUJTRCA4LjQtUkMxIGp1c3QgZ290IG91dCB0aGUgZG9vciBh bmQgd2UgYXJlIHBsYW5uaW5nIFJDMi4gQSBjb3VwbGUKICAgb2YgY3JpdGljYWwgZml4ZXMgaGF2 ZSBjb21lIGluIHRoYXQgd2lsbCBiZSBpbmNsdWRlZCBpbiBSQzIuIFRoZQogICBzY2hlZHVsZSBo YXMgc2xpcHBlZCBhYm91dCAxMCBkYXlzIHNvIGZhci4gV2UgYXJlIGV4cGVjdGluZyB0aGUgZmlu YWwKICAgcmVsZWFzZSBieSB0aGUgZW5kIG9mIEFwcmlsLiBQYWNrYWdlcyBmb3IgOC40IGhhdmUg YmVlbiBwcm92aWRlZCBieSBhCiAgIGZ1bGx5IG9wZXJhdGlvbmFsIHBhY2thZ2UgYnVpbGRpbmcg Y2x1c3Rlci4KICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KCkZyZWVCU0QvYXJtIFN1cGVycGFnZXMgZm9yIEFSTXY3 CgogICBVUkw6IGh0dHA6Ly9zdGF0aWMudXNlbml4Lm9yZy9ldmVudHMvb3NkaTAyL3RlY2gvZnVs bF9wYXBlcnMvbmF2YXJyby9uYXZhcnJvLnBkZgogICBVUkw6IGh0dHBzOi8vd2lraS5mcmVlYnNk Lm9yZy9BUk1TdXBlcnBhZ2VzCiAgIFVSTDogaHR0cHM6Ly9naXRodWIuY29tL3NlbWloYWxmLWJv ZGVrLXpiaWduaWV3L2ZyZWVic2QtYXJtLXN1cGVycGFnZXMuZ2l0CgogICBDb250YWN0OiBaYmln bmlldyBCb2RlayA8emJiQHNlbWloYWxmLmNvbT4KICAgQ29udGFjdDogR3J6ZWdvcnogQmVybmFj a2kgPGdqYkBzZW1paGFsZi5jb20+CiAgIENvbnRhY3Q6IFJhZmHFgiBKYXdvcm93c2tpIDxyYWpA c2VtaWhhbGYuY29tPgoKICAgQVJNIGFyY2hpdGVjdHVyZSBpcyBtb3JlIGFuZCBtb3JlIHByZXZh aWxpbmcsIG5vdCBvbmx5IGluIHRoZSBtb2JpbGUKICAgYW5kIGVtYmVkZGVkIHNwYWNlLiBBbW9u ZyB0aGUgbW9yZSBpbnRlcmVzdGluZyBpbmR1c3RyeSB0cmVuZHMgZW1lcmdpbmcKICAgaW4gdGhl IHJlY2VudCBtb250aHMgaGFzIGJlZW4gdGhlICJBUk0gc2VydmVyIiBjb25jZXB0LiBTb21lIHRv cC10aWVyCiAgIGNvbXBhbmllcyBzdGFydGVkIGRldmVsb3Bpbmcgc3lzdGVtcyBsaWtlIHRoaXMg YWxyZWFkeSAoRGVsbCwgSFApLgoKICAgS2V5IHRvIEZyZWVCU0Qgc3VjY2VzcyBpbiB0aGVzZSBu ZXcgYXJlYXMgYXJlIHNvcGhpc3RpY2F0ZWQgZmVhdHVyZXMsCiAgIGFtb25nIHRoZW0gYXJlIHN1 cGVycGFnZXMuCgogICBUaGUgb2JqZWN0aXZlIG9mIHRoaXMgcHJvamVjdCBpcyB0byBwcm92aWRl IEZyZWVCU0QvYXJtIHdpdGggdGhlCiAgIHN1cGVycGFnZXMgc3VwcG9ydCwgd2hpY2ggd2lsbCBh bGxvdyBmb3IgZWZmaWNpZW50IHVzZSBvZiBUTEIKICAgdHJhbnNsYXRpb25zIChlbmxhcmdlIFRM QiBjb3ZlcmFnZSksIGxlYWRpbmcgdG8gaW1wcm92ZWQgcGVyZm9ybWFuY2UgaW4KICAgbWFueSBh cHBsaWNhdGlvbnMgYW5kIHNjYWxhYmlsaXR5LiBJbmRpY2F0ZWQgZnVuY3Rpb25hbGl0eSBpcyBp bnRlbmRlZAogICB0byB3b3JrIG9uIEFSTXY3LWJhc2VkIHByb2Nlc3NvcnMsIGhvd2V2ZXIgY29t cGF0aWJpbGl0eSB3aXRoIEFSTXY2CiAgIHdpbGwgYmUgcHJlc2VydmVkLgoKICAgQ3VycmVudCBz dXBwb3J0IHN0YXR1czoKICAgICAqIFBvcnQgb2YgdGhlIHB2X2VudHJ5IGFsbG9jYXRvci4KICAg ICAqIFN3aXRjaCB0byAiQVBbMjoxXSIgYWNjZXNzIHBlcm1pc3Npb25zIG1vZGVsLgogICAgICog UFRFLWJhc2VkLCBwYWdlLXJlZmVyZW5jZWQvbW9kaWZpZWQgZW11bGF0aW9uLgogICAgICogRml4 ZXMgcmVnYXJkaW5nIHBhZ2UgcmVwbGFjZW1lbnQgc3RyYXRlZ3kuCiAgICAgKiBDb2RlIG9wdGlt aXphdGlvbnMgYW5kIGJ1ZyBmaXhlcy4KCiAgIE5leHQgc3RlcHM6CiAgICAgKiBEaXJ0eSBwYWdl cyBtYW5hZ2VtZW50LgogICAgICogR3JhZHVhbCBpbnRlZ3JhdGlvbiB0byBGcmVlQlNEIC1DVVJS RU5ULgogICAgICogRnVydGhlciBwbWFwIG9wdGltaXphdGlvbnMuCiAgICAgKiBGcmFnbWVudGF0 aW9uIGNvbnRyb2wgbWFuYWdlbWVudC4KICAgICAqIFRlc3RpbmcgYW5kIGJlbmNobWFya2luZy4K Ck9wZW4gdGFza3M6CgogICAgMS4gU3VwcG9ydCBmb3IgbXVsdGlwbGUgcGFnZSBzaXplcy4KICAg IDIuIEltcGxlbWVudGF0aW9uIG9mIHBhZ2UgcHJvbW90aW9uLCBkZW1vdGlvbiBhbmQgZXZpY3Rp b24gbWVjaGFuaXNtcy4KICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkZyZWVCU0QvQVJNIFRvb2xjaGFpbiBJbXBy b3ZlbWVudHMKCiAgIENvbnRhY3Q6IEFuZHJldyBUdXJuZXIgPGFuZHJld0BGcmVlQlNELm9yZz4K CiAgIENsYW5nIGhhcyBiZWVuIG1hZGUgdGhlIGRlZmF1bHQgY29tcGlsZXIgb24gQVJNLiBBIG51 bWJlciBvZiBpc3N1ZXMKICAgd2l0aCBMTFZNIGFuZCBjbGFuZyBoYXZlIGJlZW4gZm91bmQsIHJl cG9ydGVkLCBhbmQgZml4ZWQgdXBzdHJlYW0uCgogICBBbiBpc3N1ZSB3aGVyZSBzb21lIEFSTSBF QUJJIGFwcGxpY2F0aW9ucyBjb21waWxlZCB3aXRoIGNsYW5nIGNyYXNoIGhhcwogICBiZWVuIHJl cG9ydGVkIHVwc3RyZWFtIHdpdGggYSBwYXRjaCBhbmQgd2lsbCBiZSBicm91Z2h0IGludG8gdGhl CiAgIEZyZWVCU0QgdHJlZSB3aGVuIGl0IGlzIGFjY2VwdGVkLiBUaGUgb25seSBvdGhlciBpc3N1 ZSBibG9ja2luZyBtb3ZpbmcKICAgdG8gdGhlIEFSTSBFQUJJIGlzIEMrKyBleGNlcHRpb25zIGZh aWwgdG8gd29yayBjb3JyZWN0bHkgd2l0aCBzaGFyZWQKICAgb2JqZWN0cy4gVGhpcyB3aWxsIG5l ZWQgdXMgdG8gZWl0aGVyIGltcG9ydCBsaWJ1bndpbmQgb3IgaW1wbGVtZW50IHRoZQogICBmdW5j dGlvbnMgbGliZ2NjX3MgcmVxdWlyZXMgdG8gZmluZCB0aGUgY29ycmVjdCB1bndpbmQgdGFibGUu CgpPcGVuIHRhc2tzOgoKICAgIDEuIEZpeCBleGNlcHRpb24gaGFuZGxpbmcgZm9yIEVBQkkuCiAg ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCgpGcmVlTkFTCgogICBVUkw6IGh0dHA6Ly93d3cuRnJlZU5BUy5vcmcvCgog ICBDb250YWN0OiBBbGZyZWQgUGVybHN0ZWluIDxhbGZyZWRARnJlZUJTRC5vcmc+CiAgIENvbnRh Y3Q6IEpvc2ggUGFldHplbCA8anBhZXR6ZWxARnJlZUJTRC5vcmc+CgogICBGcmVlTkFTIDguMy4x LVJFTEVBU0UtcDIgd2lsbCBoaXQgU291cmNlZm9yZ2UgdGhlIHNlY29uZCB3ZWVrIG9mIEFwcmls LAogICBhbmQgc2hvdWxkIGVuZCB1cCBhcyB0aGUgbGFzdCBGcmVlTkFTIHJlbGVhc2UgYmFzZWQg b24gRnJlZUJTRCA4LlggSXQncwogICBjdXJyZW50bHkgdGhlIG9ubHkgRnJlZSBPcGVuIFNvdXJj ZSBOQVMgcHJvZHVjdCBhdmFpbGFibGUgd2l0aCBhbnkgZm9ybQogICBvZiBaRlMgZW5jcnlwdGlv biAocHJvdmlkZWQgYnkgR0VMSSkuCgpPcGVuIHRhc2tzOgoKICAgIDEuIFRoZSB0ZWFtIGlzIGhh cmQgYXQgd29yayBvbiBnZXR0aW5nIGEgRnJlZUJTRCA5LlgtYmFzZWQgcmVsZWFzZSBvZgogICAg ICAgRnJlZU5BUyByZWFkeS4gQ3VycmVudGx5IHRoZXJlIGFyZSBzZXZlcmFsIG5pZ2h0bHkgc25h cHNob3RzCiAgICAgICBhdmFpbGFibGUuCiAgICAyLiBBZGQgSEFTVCB0byB0aGUgd2ViaW50ZXJm YWNlLgogICAgMy4gTWlncmF0ZSB0byBORlN2NC4KICAgIDQuIEludGVncmF0ZSBmb3VuZGF0aW9u IHNwb25zb3JlZCBrZXJuZWwgaVNDU0kgdGFyZ2V0LgogICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKR05PTUUvRnJl ZUJTRAoKICAgVVJMOiBodHRwOi8vd3d3LmZyZWVic2Qub3JnL2dub21lCiAgIFVSTDogaHR0cDov L3d3dy5mcmVlYnNkLm9yZy9nbm9tZS9kb2NzL2RldmVsZmFxLmh0bWwKICAgVVJMOiBodHRwOi8v d3d3Lm1hcmN1c2NvbS5jb206ODA4MC92aWV3dmMvdmlld3ZjLmNnaS9tYXJjdXNjb20KICAgVVJM OiBodHRwczovL2dpdGh1Yi5jb20vamxtZXNzNzcvbWF0ZS1wb3J0cwoKICAgQ29udGFjdDogRnJl ZUJTRCBHTk9NRSB0ZWFtIDxnbm9tZUBGcmVlQlNELm9yZz4KCiAgIFRoZSBHTk9NRS9GcmVlQlNE IFRlYW0gaGFzIHJlY2VudGx5IG1lcmdlZCBHbGliIDIuMzQsIEd0aysgMi4yNC4xNyBhbmQKICAg R3RrKyAzLjYuNCBpbnRvIHBvcnRzLCB0aGUgQysrIGJpbmRpbmdzIGFsc28gaGF2ZSBnb3QgdXBk YXRlcy4gSW4KICAgYWRkaXRpb25hbCAibG93LWxldmVsIiBHTk9NRSBwb3J0cyByZWNlaXZlZCB1 cGRhdGVzLCBsaWtlIGxpYnNvdXAsCiAgIGdvYmplY3QtaW50cm9zcGVjdGlvbiwgYXRrIGFuZCB2 YWxhIGZvciBleGFtcGxlLiBUaGUgdGVsZXBhdGh5IHN0YWNrCiAgIGFuZCBlbXBhdGh5IHdoZXJl IGFsc28gdXBkYXRlZC4KCiAgIFRoZSBVU0VfR05PTUUgbWFjcm8gaGFzIHJlY2VpdmVkIHN1cHBv cnQgZm9yIDpydW4gYW5kIDpidWlsZCB0YXJnZXRzCiAgIHRoYW5rcyB0byBKZXJlbXkgTWVzc2Vu Z2VyIChtZXp6KS4gQ3VycmVudGx5IG9ubHkgbGlieG1sMiBhbmQgbGlieHNsdAogICBzdXBwb3J0 IHRoZXNlIHRhcmdldHMuCgogICBVU0VfR05PTUU9cGtnY29uZmlnIGlzIGJlaW5nIGRlcHJlY2F0 ZWQgaW4gZmF2b3Igb2YKICAgVVNFX1BLR0NPTkZJRz1idWlsZC4gVGhlIGZvcm1lciBhbHNvIGFk ZHMgYSBydW4gZGVwZW5kZW5jeSBvbgogICBwa2ctY29uZmlnLCB3aGljaCBpcyBub3QgcmVxdWly ZWQuIEEgZmlyc3QgcGFzcyB3YXMgZG9uZSB0byBnZXQgcmlkIG9mCiAgIHRoaXMgaW4gdGhlIEds aWIgdXBkYXRlIHRvIDIuMzQuIEluIGNvb3BlcmF0aW9uIHdpdGggdGhlIFgxMSBUZWFtLCB0aGUK ICAgdXNhZ2Ugb2YgVVNFX0dOT01FPXBrZ2NvbmZpZyBpbiBYIGNvbXBvbmVudHMgd2lsbCBiZSBy ZW1vdmVkLiBBZnRlciB0aGUKICAgZmFsbG91dCBmcm9tIHRoaXMgaXMgaGFuZGxlZCBhbmQgc3Ry YW5nbGVycyBhcmUgY29udmVydGVkLCB0aGUKICAgVVNFX0dOT01FIG9wdGlvbiB3aWxsIGJlIHJl bW92ZWQuCgogICBJbiBhZGRpdGlvbiBVU0VfR05PTUU9Z25vbWVoYWNrIGlzIGRlcHJlY2F0ZWQg YW5kIHNob3VsZCBub3QgYmUgdXNlZC4KICAgUGxlYXNlIHJlcGxhY2UgaXQgd2l0aCBVU0VTPXBh dGhmaXguCgogICBUaGUgR05PTUUgZGV2ZWxvcG1lbnQgcmVwb3NpdG9yeSBoYXMgc3dpdGNoZWQg ZnJvbSBDVlMgdG8gU1ZOLiBDVlMgd2lsbAogICBub3QgZ2V0IGFueSBtb3JlIHVwZGF0ZXMuIFVz ZXMgY2FuIGdldCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBtYXJjdXNtZXJnZQogICBzY3JpcHQgdGhh dCBzdXBwb3J0cyBTVk4gZnJvbSBpdHMgaG9tZSBwYWdlLCBhbmQgc2hvdWxkIHJlbW92ZSB0aGUg b2xkCiAgIENWUyBjaGVja291dCAicG9ydHMiIGRpci4KCiAgICAgKiBTVk4gYW5vbnltb3VzIHJv b3Q6IHN2bjovL2NyZW1lLWJydWxlZS5tYXJjdXNjb20uY29tLyBvcgogICAgICAgc3ZuOi8vc3Vz aGkubWFyY3VzY29tLmNvbS8gKElQdjYpCiAgICAgKiBWaWV3VkM6IGh0dHA6Ly93d3cubWFyY3Vz Y29tLmNvbTo4MDgwL3ZpZXd2Yy92aWV3dmMuY2dpL21hcmN1c2NvbQoKICAgT24tZ29pbmcgZWZm b3J0czoKCiAgICAgKiBnbGliIDIuMzYsIHBhbmdvIDEuMzQuMCwgZ3RrIDMuOC4wIGFuZCBnb2Jq ZWN0LWludHJvc3BlY3Rpb24gMS4zNi4wCiAgICAgICB3aGVyZSB1cGRhdGVkIGluIHRoZSBHTk9N RSBkZXZlbG9wbWVudCByZXBvc2l0b3J5LgogICAgICogR3VzdGF1IFBlcmV6IGkgUXVlcm9sIHN0 ZXBwZWQgdXAgYW5kIHN0YXJ0ZWQgd29yayBvbiB1cGRhdGluZyB0aGUKICAgICAgIG9sZCBHTk9N RSAzLjQgcG9ydHMgdG8gMy42LiBBdCB0aGUgbW9tZW50IG9mIHdyaXRpbmcgdGhlc2UgYXJlIG5v dAogICAgICAgYXZhaWxhYmxlIGluIHRoZSBHTk9NRSBkZXZlbG9wbWVudCByZXBvc2l0b3J5IGp1 c3QgeWV0LiBGb3IgaGlzCiAgICAgICBlZmZvcnRzLCBoZSB3YXMgYXdhcmRlZCBhIEZyZWVCU0Qg R05PTUUgdGVhbSBtZW1iZXJzaGlwLgogICAgICogSmVyZW15IE1lc3NlbmdlciAobWV6eikgaGFz IGNvbXBsZXRlZCBNYXRlIDEuNiB3aGljaCB3aWxsIGJlCiAgICAgICBhcnJpdmluZyBpbiBwb3J0 cyBuZWFyIHlvdSB3aGVuIGRlZW1lZCBzdGFibGUgZW5vdWdoLgoKICAgSWYgeW91IHdhbnQgdG8g aGVscCB3aXRoIGtlZXBpbmcgdGhlIGRvY3VtZW50YXRpb24gdXBkYXRlZCBvciBoZWxwaW5nCiAg IG91dCBpbiBvdGhlciB3YXlzLCBldmVuIGlmIGl0IG9ubHkgcGFydHMgZm9yIHRoZSBHbGliL0d0 ay9HTk9NRSBzdGFjawogICB5b3UgYXJlIGludGVyZXN0ZWQgaW4sIHBsZWFzZSBjb250YWN0IHVz IQoKT3BlbiB0YXNrczoKCiAgICAxLiBVcGRhdGUgdGhlIEZyZWVCU0Qub3JnL2dub21lIHdlYnNp dGUsIGluIHBhcnRpY3VsYXIgdGhlIGRldmVsb3BlcgogICAgICAgaW5mb3JtYXRpb24gYWJvdXQg VVNFX0dOT01FLCBtYXliZSBwdXQgdGhhdCBzZWN0aW9uIGluIHRoZSBQb3J0ZXIncwogICAgICAg SGFuZGJvb2sgaW5zdGVhZC4KICAgIDIuIE1lcmdlIG1vcmUgdXBkYXRlZCBwb3J0cyBmcm9tIE1D IHRvIHBvcnRzLgogICAgMy4gVGVzdGluZyBsYXRlc3QgR2xpYi9HdGsgcmVsZWFzZXMgd2l0aCBl eGlzdGluZyBwb3J0cywgYW5kIGltcG9ydCBpdAogICAgICAgaW50byBwb3J0cyB3aGVuIGl0IGlz IHJlYWR5LgogICAgNC4gQWZ0ZXIgcG9ydGluZyBHTk9NRSAzLjYgcnVuIHRlc3RzIGFuZCBmaXgg YnVncy4KICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KCkltcHJvdmluZyB0aGUgRG9jdW1lbnRhdGlvbiBQcm9qZWN0 IEluZnJhc3RydWN0cmUKCiAgIFVSTDogaHR0cDovL3N2bndlYi5mcmVlYnNkLm9yZy9kb2MvcHJv amVjdHMveG1sLXRvb2xzLwoKICAgQ29udGFjdDogR8OhYm9yIEvDtnZlc2TDoW4gPGdhYm9yQEZy ZWVCU0Qub3JnPgoKICAgVGhlcmUgaXMgYW4gb24tZ29pbmcgd29yayB0byBpbXByb3ZlIHRoZSBk b2N1bWVudGF0aW9uIGluZnJhc3RydWN0dXJlCiAgIGFuZCBtb2Rlcm5pemUgb3VyIGRvY3VtZW50 YXRpb24gdG9vbGNoYWluLiBUaGUgd29yayBjYW4gYmUgZm91bmQgaW4gdGhlCiAgIHhtbC10b29s cyBicmFuY2ggYW5kIGlzIHZlcnkgbmVhciB0byBjb21wbGV0aW9uLiBUaGUgaW1wcm92ZW1lbnRz CiAgIGluY2x1ZGUgdGhlIGZvbGxvd2luZzoKCiAgICAgKiBVcGdyYWRlIHRvIERvY0Jvb2sgNC41 LgogICAgICogVXNlIFhTTFQgaW5zdGVhZCBvZiBEU1NTTCB0byByZW5kZXIgWEhUTUwtYmFzZWQg b3V0cHV0LgogICAgICogR2VuZXJhdGUgUERGIGZyb20gUFMgYW5kIHNpbXBsaWZ5IGltYWdlIHBy b2Nlc3NpbmcuCiAgICAgKiBGaXggbWFrZSBsaW50IGFuZCB2YWxpZGF0ZSB0aGUgd2hvbGUgZG9j dW1lbnRhdGlvbiBzZXQuCiAgICAgKiBGaXggcmVuZGVyaW5nIG9mIFRPQyBlbGVtZW50cy4KICAg ICAqIEZpeCBtaXN1c2VkIGxpbmsgZWxlbWVudHMgdGhhdCByZXN1bHRlZCBpbiBhIGNvcnJ1cHQg cmVuZGVyaW5nLgogICAgICogVXNlIG1vcmUgaHVtYW4tZnJpZW5kbHkgcHVibGljYXRpb24gZGF0 YSBhbmQgcmVsZWFzZSBpbmZvCiAgICAgICByZW5kZXJpbmcuCiAgICAgKiBBZGQgc3VwcG9ydCBm b3IgWEluY2x1ZGUgaW4gRG9jQm9vayBkb2N1bWVudHMuCiAgICAgKiBBZGQgc3VwcG9ydCBmb3Ig cHJvZmlsaW5nIHdpdGggYXR0cmlidXRlcy4KICAgICAqIEFkZCBzdXBwb3J0IGZvciBTY2hlbWF0 cm9uIGNvbnN0cmFpbnRzLgogICAgICogQWRkIGV4cGVyaW1lbnRhbCBlcHViIHN1cHBvcnQuCiAg ICAgKiBBZGQgZXhwZXJpbWVudGFsIHN1cHBvcnQgZm9yIFhTTC1GTy1iYXNlZCBwcmludGVkIG91 dHB1dC4KICAgICAqIENsZWFuIHVwIG9ic29sZXRlIFNHTUwgY29uc3RydWN0cy4KICAgICAqIENs ZWFuIHVwIGNhdGFsb2dzLgogICAgICogRHJvcCBIVE1MIFRpZHkgc2luY2UgaXQgaXMgbm90IG5l ZWRlZCBhbnkgbW9yZS4KCiAgIFRoZSBjaGFuZ2VzIGVsaW1pbmF0ZSBzb21lIGRlcGVuZGVuY2ll cyBhbmQgc3dpdGNoIHRoZSBkb2MgcmVwb3NpdG9yeQogICB0byBhIHJlYWwgWE1MIHRvb2xjaGFp biB3aXRoIHByb3BlciB2YWxpZGF0aW9uIGFuZCBtb3JlIGFkdmFuY2VkCiAgIHJlbmRlcmluZyB0 b29scy4gVGhlIG9ubHkgZXhjZXB0aW9ucyBhcmUgSmFkZSBhbmQgdGhlIERTU1NMCiAgIHN0eWxl c2hlZXRzLCB3aGljaCBhcmUgc3RpbGwgbmVlZGVkIGZvciBwcmludGVkIG91dHB1dC4KCk9wZW4g dGFza3M6CgogICAgMS4gRml4IHJlbmRlcmluZyBwcm9ibGVtcyB3aXRoIGltYWdlcyBpbiBwcmlu dGVkIGZvcm1hdHMuCiAgICAyLiBVcGRhdGUgdGhlIERvY3VtZW50YXRpb24gUHJpbWVyIHRvIHJl ZmxlY3QgY2hhbmdlcy4KICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCktERS9GcmVlQlNECgogICBVUkw6IGh0dHA6 Ly9GcmVlQlNELmtkZS5vcmcKICAgVVJMOiBodHRwOi8vRnJlZUJTRC5rZGUub3JnL2FyZWE1MS5w aHAKCiAgIENvbnRhY3Q6IEtERSBGcmVlQlNEIDxrZGVARnJlZUJTRC5vcmc+CgogICBUaGUgS0RF L0ZyZWVCU0QgVGVhbSBpcyB2ZXJ5IHByb3VkIHRvIGhhdmUgU2NoYWljaCBBbG9uc28gKGFzY2hh aSkKICAgam9pbmluZyB0aGUgdGVhbS4gV2VsY29tZSEKCiAgIFRoZSBLREUvRnJlZUJTRCBUZWFt IGhhdmUgY29udGludWVkIHRvIGltcHJvdmUgdGhlIGV4cGVyaWVuY2Ugb2YgS0RFCiAgIHNvZnR3 YXJlIGFuZCBRdCB1bmRlciBGcmVlQlNELiBUaGUgbGF0ZXN0IHJvdW5kIG9mIGltcHJvdmVtZW50 cwogICBpbmNsdWRlOgoKICAgICAqIEZpeCBwcm9ibGVtcyBlc3RhYmxpc2hpbmcgVURQIGNvbm5l Y3Rpb25zLgoKICAgVGhlIFRlYW0gaGF2ZSBhbHNvIG1hZGUgbWFueSByZWxlYXNlcyBhbmQgdXBz dHJlYW1lZCBtYW55IGZpeGVzIGFuZAogICBwYXRjaGVzLiBUaGUgbGF0ZXN0IHJvdW5kIG9mIHJl bGVhc2VzIGluY2x1ZGU6CgogICAgICogS0RFIFNDOiA0LjkuNSwgNC4xMC4xIChwb3J0cykKICAg ICAqIFF0OiA1LjAuMCAoYXJlYTUxKSBhbmQgNC44LjQgKHBvcnRzKQogICAgICogUHlRdDogNC45 LjYgKHBvcnRzKTsgUVNjaW50aWxsYSAyLjcgKHBvcnRzKTsgU0lQOiA0LjE0LjIgKGFyZWE1MSkK ICAgICAgIGFuZCA0LjE0LjMgKHBvcnRzKQogICAgICogS0RldmVsb3A6IDQuNC4xIChwb3J0cyk7 IEtEZXZQbGF0Zm9ybTogMS40LjEgKHBvcnRzKQogICAgICogQ2FsbGlncmE6IDIuNS41LCAyLjYu MiAocG9ydHMpCiAgICAgKiBBbWFyb2s6IDIuNy4wCiAgICAgKiBDTWFrZTogMi44LjEwLjIKICAg ICAqIERpZ2lrYW0gKGFuZCBLSVBJLXBsdWdpbnMpOiAzLjEuMCAoYXJlYTUxKQogICAgICogUXRD cmVhdG9yOiA0LjYuMSAocG9ydHMpCiAgICAgKiBLREUgVGVsZXBhdGh5IDAuNi4wIChhcmVhNTEp CiAgICAgKiBtYW55IHNtYWxsZXIgcG9ydHMKCiAgIEFzIGEgcmVzdWx0IC0tIGFjY29yZGluZyB0 byBQb3J0U2NvdXQgLS0gd2UgaGF2ZSA0MzEgcG9ydHMsIG9mIHdoaWNoCiAgIDkzLjUlIChmcm9t IDkxJSkgYXJlIHVwLXRvLWRhdGUuCgogICBUaGUgVGVhbSBhcmUgYWx3YXlzIGxvb2tpbmcgZm9y IG1vcmUgdGVzdGVycyBhbmQgcG9ydGVycyBzbyBwbGVhc2UKICAgY29udGFjdCB1cyBhbmQgdmlz aXQgb3VyIGhvbWUgcGFnZS4KCk9wZW4gdGFza3M6CgogICAgMS4gVXBkYXRpbmcgb3V0LW9mLWRh dGUgcG9ydHMsIHNlZSBQb3J0U2NvdXQgZm9yIGEgbGlzdC4KICAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCktlcm5l bCBJbmZvcm1hdGlvbiBpbiBQcm9jZXNzIENvcmUgRHVtcHMKCiAgIENvbnRhY3Q6IE1pa29sYWog R29sdWIgPHRyb2NpbnlAZnJlZWJzZC5vcmc+CgogICBXaGVuIGRvaW5nIHBvc3Rtb3J0ZW0gYW5h bHlzaXMgb2YgYSBjcmFzaGVkIHByb2Nlc3MgaXQgaXMgc29tZXRpbWVzCiAgIHZlcnkgdXNlZnVs IHRvIGhhdmUga2VybmVsIGluZm9ybWF0aW9uIGFib3V0IHRoZSBwcm9jZXNzIGF0IHRoZSBtb21l bnQKICAgb2YgdGhlIGNyYXNoLCBsaWtlIG9wZW4gZmlsZSBkZXNjcmlwdG9ycyBvciByZXNvdXJj ZSBsaW1pdHMuIEZvciBhIGxpdmUKICAgcHJvY2VzcyB0aGlzIGluZm9ybWF0aW9uIGNhbiBiZSBv YnRhaW5lZCB2aWEgc3lzY3RsKDMpIGludGVyZmFjZSBlLmcuCiAgIHVzaW5nIHByb2NzdGF0KDEp LgoKICAgVGhlIGFpbSBvZiB0aGUgcHJvamVjdCBpcyB0byBhZGQgYWRkaXRpb25hbCBub3RlcyB0 byBhIHByb2Nlc3MgY29yZQogICBkdW1wLCB3aGljaCBpbmNsdWRlIHByb2Nlc3MgaW5mb3JtYXRp b24gZnJvbSB0aGUga2VybmVsIGF0IHRoZSBtb21lbnQKICAgb2YgdGhlIHByb2Nlc3MgY3Jhc2gs IHRlYWNoIGxpYnByb2NzdGF0KDMpIHRvIGV4dHJhY3QgdGhpcyBpbmZvcm1hdGlvbgogICBhbmQg bWFrZSBwcm9jc3RhdCgxKSB1c2UgdGhpcyBmdW5jdGlvbmFsaXR5LgoKICAgQXQgdGhlIG1vbWVu dCBhbGwgbmVjZXNzYXJ5IGNvZGUgY2hhbmdlcyBhcmUgY29tbWl0dGVkIHRvIEhFQUQgYW5kIGFy ZQogICBnb2luZyB0byBiZSBtZXJnZSB0byBzdGFibGUvOSBpbiAxIG1vbnRoLgogICAgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwoKbWRvYy5zdSAtLSBTaG9ydCBNYW51YWwgUGFnZSBVUkxzCgogICBVUkw6IGh0dHA6Ly9t ZG9jLnN1LwogICBVUkw6IGh0dHA6Ly9uZ2lueC5jb25mLm1kb2Muc3UvbWRvYy5zdS5uZ2lueC5j b25mCiAgIFVSTDogaHR0cHM6Ly9naXRodWIuY29tL2Nuc3QvbWRvYy5zdQogICBVUkw6IGh0dHA6 Ly9saXN0cy5mcmVlYnNkLm9yZy9waXBlcm1haWwvZnJlZWJzZC1kb2MvMjAxMy1GZWJydWFyeS8w MjE0NjUuaHRtbAoKICAgQ29udGFjdDogQ29uc3RhbnRpbmUgQS4gTXVyZW5pbiA8Y25zdCsrQEZy ZWVCU0Qub3JnPgoKICAgbWRvYy5zdSBpcyBhIGRldGVybWluaXN0aWMgVVJMIHNob3J0ZW5lciBm b3IgQlNEIG1hbnVhbCBwYWdlcywgd3JpdHRlbgogICBlbnRpcmVseSBpbiBuZ2lueC5jb25mLgoK ICAgU2luY2UgdGhlIG9yaWdpbmFsIGFubm91bmNlbWVudCwgT1MgdmVyc2lvbiBzdXBwb3J0IGhh cyBiZWVuIGFkZGVkCiAgIChlLmcuIC9mOTEvIGFuZCAvRnJlZUJTRC05LjEvIGV0Yy4pLCBhcyB3 ZWxsIGFzIGR5bmFtaWMgbXVsdGktZmxhdm91cgogICB3ZWItcGFnZXMgd2l0aCBtdWx0aXBsZSBs aW5rcyAoZS5nLiBodHRwOi8vbWRvYy5zdS9mLGQvaWZuZXQuOSBhbmQKICAgaHR0cDovL21kb2Mu c3UvLS9tZG9jKSwgd2hpY2ggZXZlbiBsZXQgeW91IHNwZWNpZnkgdGhlIHZlcnNpb25zIHRvbwog ICAoZS5nLiBodHRwOi8vbWRvYy5zdS9mOTEsbjYwLG81MixkL21kb2MpLgoKICAgVGhlIHNvdXJj ZSBjb2RlIGZvciB0aGUgd2hvbGUgc2l0ZSBpcyBhdmFpbGFibGUgdW5kZXIgYSBCU0QgbGljZW5j ZS4KCk9wZW4gdGFza3M6CgogICAgMS4gRm9yayBpdCBvbiBHaXRIdWIgKHNlZSBsaW5rcykhCiAg ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCgpNdWx0aXBhdGggVENQIChNUFRDUCkgZm9yIEZyZWVCU0QKCiAgIFVSTDog aHR0cDovL2NhaWEuc3dpbi5lZHUuYXUvdXJwL25ld3RjcC9tcHRjcC90b29scy5odG1sCiAgIFVS TDogaHR0cDovL2NhaWEuc3dpbi5lZHUuYXUvbmV3dGNwL21wdGNwLwogICBVUkw6IGh0dHA6Ly9j YWlhLnN3aW4uZWR1LmF1L3JlcG9ydHMvMTMwNDI0QS9DQUlBLVRSLTEzMDQyNEEucGRmCiAgIFVS TDogaHR0cHM6Ly9wdWIuYWxsYnNkLm9yZy9GcmVlQlNELXNuYXBzaG90cy8KCiAgIENvbnRhY3Q6 IE5pZ2VsIFdpbGxpYW1zIDxuandpbGxpYW1zQHN3aW4uZWR1LmF1PgogICBDb250YWN0OiBMYXdy ZW5jZSBTdGV3YXJ0IDxsYXN0ZXdhcnRAc3dpbi5lZHUuYXU+CiAgIENvbnRhY3Q6IEdyZW52aWxs ZSBBcm1pdGFnZSA8Z2FybWl0YWdlQHN3aW4uZWR1LmF1PgoKICAgV2UgaGF2ZSBiZWVuIHdvcmtp bmcgdG8gY3JlYXRlIGEgQlNELWxpY2Vuc2VkIGltcGxlbWVudGF0aW9uIG9mCiAgIE11bHRpcGF0 aCBUQ1AgLS0gYSBzZXQgb2YgVENQIGV4dGVuc2lvbnMgdGhhdCBhbGxvdyBmb3IgdHJhbnNwYXJl bnQKICAgbXVsdGlwYXRoIG9wZXJhdGlvbiB3aXRoIG11bHRpcGxlIElQIGFkZHJlc3NlcyBhcyBz cGVjaWZpZWQgaW4KICAgZXhwZXJpbWVudGFsIFJGQzY4MjQuCgogICBXZSBtYWRlIG91ciBmaXJz dCB2MC4xIHB1YmxpYyByZWxlYXNlIG9uIDIwMTMtMDMtMTEgYW5kIHJlY2VudGx5CiAgIHJlbGVh c2VkIHYwLjMgb24gMjAxMy0wNC0xNi4gVGhlIGNvZGUgaXMgY3VycmVudGx5IGNvbnNpZGVyZWQg dG8gYmUgb2YKICAgYWxwaGEgcXVhbGl0eS4gV2UgYXJlIHdvcmtpbmcgdG93YXJkcyBwdXNoaW5n IHRoZSBjb2RlIGludG8gYSBGcmVlQlNECiAgIFN1YnZlcnNpb24gcmVwb3NpdG9yeSBwcm9qZWN0 IGJyYW5jaCB0byBjb250aW51ZSB0aGUgb24tZ29pbmcKICAgZGV2ZWxvcG1lbnQgZWZmb3J0IGlu IGEgbW9yZSBwdWJsaWNseSBhY2Nlc3NpYmxlIGxvY2F0aW9uLiBBcyBwYXJ0IG9mCiAgIHRoaXMg bW92ZSwgd2UgaG9wZSB0byBiZWdpbiByZWxlYXNpbmcgcmVndWxhciBzbmFwc2hvdCBpbnN0YWxs ZXIgSVNPcwogICBvZiB0aGUgTVBUQ1AgcHJvamVjdCBicmFuY2ggY291cnRlc3kgb2YgSGlyb2tp IFNhdG8gYW5kIHRoZSBhbGxic2Qub3JnCiAgIGRhaWx5IHNuYXBzaG90IGluZnJhc3RydWN0dXJl LgoKICAgV2UgYXJlIGFib3V0IHRvIHJlbGVhc2UgYSBDQUlBIHRlY2huaWNhbCByZXBvcnQgMTMw NDI0QSBlbnRpdGxlZAogICAiRGVzaWduIE92ZXJ2aWV3IG9mIE11bHRpcGF0aCBUQ1AgdmVyc2lv biAwLjMgZm9yIEZyZWVCU0QgMTAiIG9uCiAgIDIwMTMtMDQtMjQgd2hpY2ggcHJvdmlkZXMgYSBo aWdoLWxldmVsIGRlc2lnbiBhbmQgYXJjaGl0ZWN0dXJlIG92ZXJ2aWV3CiAgIG9mIHRoZSB2MC4z IGNvZGUgcmVsZWFzZS4KCiAgIEdvaW5nIGZvcndhcmQsIHdlIGV4cGVjdCB0byBjb250aW51ZSBk ZXZlbG9wbWVudCBhbmQgcmVsZWFzZSBhZGRpdGlvbmFsCiAgIHRlY2huaWNhbCByZXBvcnRzIGFu ZCBhY2FkZW1pYyBwYXBlcnMgY292ZXJpbmcgdG9waWNzIHN1Y2ggYXMKICAgcGVyZm9ybWFuY2Ug YW5hbHlzaXMgYW5kIG11bHRpcGF0aCBjb25nZXN0aW9uIGNvbnRyb2wvc2NoZWR1bGluZy4KCk9w ZW4gdGFza3M6CgogICAgMS4gVGhlIGNvZGUgaXMgY3VycmVudGx5IG9mIGFscGhhIHF1YWxpdHkg c28gd2Ugd2VsY29tZSBhbGwgdGVzdGluZwogICAgICAgZmVlZGJhY2ssIGJ1dCBwbGVhc2UgZmFt aWxpYXJpemUgeW91cnNlbGYgd2l0aCB0aGUgUkVBRE1FIGZpbGUgYW5kCiAgICAgICAiS25vd24g TGltaXRhdGlvbnMiIHNlY3Rpb24gaW4gcGFydGljdWxhciBiZWZvcmUganVtcGluZyBpbi4KICAg ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KCk5hdGl2ZSBpU0NTSSBTdGFjawoKICAgVVJMOiBodHRwczovL3dpa2kuZnJl ZWJzZC5vcmcvTmF0aXZlJTIwaVNDU0klMjB0YXJnZXQKCiAgIENvbnRhY3Q6IEVkd2FyZCBUb21h c3ogTmFwaWVyYWwvYSA8dHJhc3pARnJlZUJTRC5vcmc+CgogICBGb2N1cyBvZiB0aGUgcHJvamVj dCB3YXMgZXh0ZW5kZWQgdG8gYWxzbyBpbmNsdWRlIGEgbmV3IGlTQ1NJCiAgIGluaXRpYXRvci4g Q29tcGFyZWQgdG8gdGhlIG9sZCBvbmUsIGl0IGlzIG1vcmUgcmVsaWFibGUsIG11Y2ggbW9yZQog ICB1c2VyLWZyaWVuZGx5LCBhbmQgc29tZXdoYXQgZmFzdGVyLiBJdCB1c2VzIGV4YWN0bHkgdGhl IHNhbWUKICAgY29uZmlndXJhdGlvbiBmaWxlIGZvcm1hdCBhcyB0aGUgb2xkIG9uZSB0byBtYWtl IG1pZ3JhdGlvbiBlYXNpZXIuCgogICBBcyBmb3IgdGhlIHRhcmdldCBzaWRlLCBpdCB3YXMgdmVy aWZpZWQgdG8gd29yayBwcm9wZXJseSBhZ2FpbnN0IG1ham9yCiAgIGluaXRpYXRvcnMgKEZyZWVC U0QsIExpbnV4LCBTb2xhcmlzLCBXaW5kb3dzIGFuZCBWTVdhcmUgRVNYKS4KCiAgIFRoaXMgcHJv amVjdCBpcyBiZWluZyBzcG9uc29yZWQgYnkgRnJlZUJTRCBGb3VuZGF0aW9uLgoKT3BlbiB0YXNr czoKCiAgICAxLiBSRE1BIHN1cHBvcnQsIGZvciBib3RoIHRoZSB0YXJnZXQgYW5kIHRoZSBpbml0 aWF0b3IuCiAgICAyLiBQZXJmb3JtYW5jZSBvcHRpbWl6YXRpb24uCiAgICAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpQ eVB5CgogICBVUkw6IGh0dHA6Ly93aWtpLkZyZWVCU0Qub3JnL1B5UHkKCiAgIENvbnRhY3Q6IERh dmlkIE5heWxvciA8ZGJuQEZyZWVCU0Qub3JnPgoKICAgUHlQeSBoYXMgYmVlbiBzdWNjZXNzZnVs bHkgdXBkYXRlZCB0byAyLjAtYmV0YTEgd2l0aCAyLjAtYmV0YTIKICAgZmluaXNoaW5nIHRyYW5z bGF0aW5nIGFuZCBvdGhlciB0ZXN0cy4gTWFueSBtYWpvciBjaGFuZ2VzIHdlcmUgbWFkZSB0bwog ICB0aGUgUHlQeSBwb3J0IGZyIHRoZSAyLjAtYmV0YTEgcmVsZWFzZSwgdGhlc2UgaW5jbHVkZToK CiAgICAgKiBSZXdvcmtpbmcgdGhlIGJ1aWxkIHNjcmlwdC4KICAgICAqIE9wdGlvbmFsbHkgdXNl IHB5cHkgKHdoZW4gYXZhaWxhYmxlKSBmb3Igc2VsZi10cmFuc2xhdGluZy4KICAgICAqIFJlZmlu ZSBtZW1vcnkgY2hlY2tzLgogICAgICogRml4IHRoZSB0ZXN0IHRhcmdldC4KCiAgIEFsdGhvdWdo IHRoZSBwb3J0IGlzIGluIGEgaGVhbHRoeSBzdGF0ZTsgUHlQeSBvbiBGcmVlQlNEIGhhcyBzb21l IHJvdWdoCiAgIGVkZ2VzIChzZWUgbWFrZSB0ZXN0IGZvciBleGFtcGxlcyBvZiByb3VnaG5lc3Mp LgoKT3BlbiB0YXNrczoKCiAgICAxLiBGaXggZmFpbGVkIHVuaXQgdGVzdHMuCiAgICAyLiBJbnRl Z3JhdGUgUHlQeSBpbnRvIGJzZC5weXRob24ubWsuCiAgICAzLiBTZWUgdGhlIHByb2plY3QgcGFn ZSBmb3IgbW9yZSBpdGVtcy4KICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCnJhY2N0OiBCbG9jayBJTyBBY2NvdW50 aW5nCgogICBVUkw6IGh0dHBzOi8vd2lraS5mcmVlYnNkLm9yZy9SdWRvbGZUb21vcmkvSU9MaW1p dHMKCiAgIENvbnRhY3Q6IFJ1ZG9sZiBUb21vcmkgPHJ1ZG90QEZyZWVCU0Qub3JnPgoKICAgVGhp cyBwcm9qZWN0IGFkZHMgdGhlIGJsb2NrIElPIGFjY2VzcyBhY2NvdW50aW5nIHRvIHRoZSByYWNj dC9yY3RsCiAgIHJlc291cmNlIGxpbWl0aW5nIGZyYW1ld29yaywgYSB3b3JraW5nIHByb3RvdHlw ZSBpbXBsZW1lbnRhdGlvbiBpcwogICBhdmFpbGFibGUuCiAgICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpSZWFkLW9u bHkgUG9ydCBvZiBOZXRCU0QncyBVREYgRmlsZSBTeXN0ZW0KCiAgIFVSTDogaHR0cHM6Ly9naXRo dWIuY29tL3dpbGxpYW1kZXZyaWVzL1VERgoKICAgQ29udGFjdDogV2lsbCBEZVZyaWVzIDx3aWxs aWFtLmRldnJpZXNAZ21haWwuY29tPgoKICAgQW4gaW5pdGlhbCByZWFkLW9ubHkgcG9ydCBvZiBO ZXRCU0QncyBVREYgZmlsZSBzeXN0ZW0gaGFzIGJlZW4gbGFyZ2VseQogICBjb21wbGV0ZWQuIChU aGUgVURGIGZpbGUgc3lzdGVtIGlzIG9mdGVuIHVzZWQgb24gQ0QsIERWRCBhbmQgQmx1LVJheQog ICBkaXNjcy4pIFRoaXMgcG9ydCBwcm92aWRlcyBhIG51bWJlciBvZiBhZHZhbnRhZ2VzIG92ZXIg RnJlZUJTRCdzCiAgIGN1cnJlbnQgVURGIGltcGxlbWVudGF0aW9uLCB3aGljaCBpbmNsdWRlOgoK ICAgICAqIFN1cHBvcnQgZm9yIHZlcnNpb24gMi42MCBvZiB0aGUgVURGIGZpbGUgc3lzdGVtIHNw ZWNpZmljYXRpb24uCiAgICAgICBGcmVlQlNEJ3MgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBvbmx5 IHBhcnRpYWxseSBzdXBwb3J0cyB2ZXJzaW9uCiAgICAgICAxLjUgb2YgdGhlIHN0YW5kYXJkLCB3 aGljaCB3YXMgcmVsZWFzZWQgaW4gMTk5Ny4gU2luY2UgV2luZG93cyBhbmQKICAgICAgIG90aGVy IHN5c3RlbXMgc3VwcG9ydCBuZXdlciB2ZXJzaW9uIG9mIHRoaXMgZmlsZSBzeXN0ZW0sIG91ciB1 c2VycwogICAgICAgYXJlIGxlZnQgd2l0aG91dCB0aGUgYWJpbGl0eSB0byByZWFkIHNvbWUgbWVk aWEgd3JpdHRlbiBieSB0aGVzZQogICAgICAgc3lzdGVtcy4gSW4gYWRkaXRpb24sIEJsdS1SYXkg ZGlzY3MgYXJlIGNvbW1vbmx5IHdyaXR0ZW4gdXNpbmcKICAgICAgIHZlcnNpb24gMi41MCBvciAy LjYwLgogICAgICogVGhlIGFiaWxpdHkgdG8gb3ZlcnJpZGUgdGhlIG93bmVyIGFuZCBncm91cCBm b3IgYWxsIHRoZSBmaWxlcyBhbmQKICAgICAgIGRpcmVjdG9yaWVzIG9uIGEgVURGIHZvbHVtZSB1 c2luZyBtb3VudCBvcHRpb25zLgogICAgICogVGhlIGFiaWxpdHkgdG8gc2V0IHRoZSBvd25lciBh bmQgZ3JvdXAgZm9yIGZpbGVzIGFuZCBkaXJlY3RvcmllcwogICAgICAgdGhhdCBsYWNrIGRlZmlu ZWQgb3duZXIgb3IgZ3JvdXAgaW5mb3JtYXRpb24gdXNpbmcgbW91bnQgb3B0aW9ucy4KICAgICAg IChUaGUgVURGIHNwZWNpZmljYXRpb24gYWxsb3dzIGZvciBmaWxlcyBhbmQgZGlyZWN0b3JpZXMg d2l0aG91dAogICAgICAgb3duZXJzIG9yIGdyb3Vwcy4pCiAgICAgKiBUaGUgYWJpbGl0eSB0byBv dmVycmlkZSB0aGUgbW9kZSBmb3IgYWxsIGRpcmVjdG9yaWVzIGFuZCBmaWxlcyBvbiBhCiAgICAg ICB2b2x1bWUgdXNpbmcgbW91bnQgb3B0aW9ucy4KICAgICAqIFN1cHBvcnQgZm9yIG1vdW50aW5n IHByZXZpb3VzIHZlcnNpb25zIG9mIGluY3JlbWVudGFsbHkgcmVjb3JkZWQKICAgICAgIG1lZGlh LCBsaWtlIENELVJzLgogICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKVENQLUFPIEF1dGhlbnRpY2F0aW9uIE9wdGlv bgoKICAgVVJMOiBodHRwOi8vc3Zud2ViLmZyZWVic2Qub3JnL2Jhc2UvdXNlci9hbmRyZS90Y3At YW8vCgogICBDb250YWN0OiBBbmRyw6kgT3BwZXJtYW5uIDxhbmRyZUBGcmVlQlNELm9yZz4KCiAg IFdvcmsgaXMgdW5kZXIgd2F5IHRvIGltcGxlbWVudCBUQ1AtQU8gKFRDUCBBdXRoZW50aWNhdGlv biBPcHRpb24pCiAgIGFjY29yZGluZyB0byBSRkM1OTI1IGFuZCBSRkM1OTI2LiBUQ1AtQU8gaXMg YW4gZXh0ZW5zaW9uIHRvIFRDUC1NRDUKICAgc2lnbmF0dXJlcyBjb21tb25seSB1c2VkIGluIHJv dXRlcnMgdG8gc2VjdXJlIEJHUCByb3V0aW5nIHByb3RvY29sCiAgIHNlc3Npb25zIGFnYWluc3Qg c3Bvb2ZpbmcgYXR0YWNrcy4gVGhlIHdvcmsgaXMgdW5kZXIgY29udHJhY3QgYW5kCiAgIHNwb25z b3JlZCBieSBKdW5pcGVyIE5ldHdvcmtzLgogICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKVGhlIGVudGl0aWVzIERv Y3VtZW50YXRpb24gQnJhbmNoCgogICBVUkw6IGh0dHA6Ly9zdm53ZWIuZnJlZWJzZC5vcmcvZG9j L3Byb2plY3RzL2VudGl0aWVzLwoKICAgQ29udGFjdDogUmVuw6kgTGFkYW4gPHJlbmVARnJlZUJT RC5vcmc+CgogICBUaGUgZW50aXRpZXMgYnJhbmNoIHdhcyBjcmVhdGVkIHRvIHJlZHVjZSBkdXBs aWNhdGlvbiBvZiBjb21taXR0ZXIKICAgZW50aXRpZXMuIEN1cnJlbnRseSB0aGVyZSBpcyBvbmUg aW4gYXV0aG9ycy5lbnQgKHdpdGggZW1haWwgYWRkcmVzc2VzKQogICBhbmQgYW5vdGhlciBvbmUg aW4gZGV2ZWxvcGVycy5lbnQgKHdpdGhvdXQgZW1haWwgYWRkcmVzc2VzKS4gVGhpcyBzZWVtcwog ICB0byBiZSBhIGxlZnRvdmVyIGZyb20gdGhlIGRvYy93d3cgc3BsaXQgaW4gZWFybGllciB0aW1l cy4gVG8gcmVtZWR5CiAgIHRoaXMsIGRldmVsb3BlcnMuZW50IGlzIG1lcmdlZCBpbnRvIGF1dGhv cnMuZW50IGFuZCBlbnRpdGllcyB3aXRoIGVtYWlsCiAgIGFkZHJlc3NlcyBhcmUgcG9zdGZpeGVk IGFzIHN1Y2guIEFwYXJ0IGZyb20gdGhlIGluc3RydWN0aW9ucyBmb3IgdGhlCiAgIGluaXRpYWwg Y29tbWl0LCB0aGVyZSBzaG91bGQgYmUgbGl0dGxlIHVzZXItdmlzaWJsZSBjaGFuZ2VzLiBTb21l CiAgIHJlbGF0ZWQgY2xlYW51cHMsIGxpa2UgY2xlYW5pbmcgdXAgdGVhbSBkZWZpbml0aW9ucywg cmVwbGFjaW5nIGxpdGVyYWwKICAgbmFtZXMgYnkgZW50aXRpZXMgZnJvbSBhdXRob3JzLmVudCwg YW5kIGFkZGluZyBtaXNzaW5nIG5hbWVzIHRvCiAgIGF1dGhvcnMuZW50IGFyZSBhbHNvIG1hZGUu CgpPcGVuIHRhc2tzOgoKICAgIDEuIEZpbmlzaCBwcm9jZXNzaW5nIG9mIHRoZSA8ZW1haWw+IHRh Zy4KICAgIDIuIFNlbmQgb3V0IGEgQ0ZULgogICAgMy4gTWVyZ2UgYmFjayBpbnRvIGhlYWQgYnJh bmNoLgogICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwoKVGhlIEZyZWVCU0QgSmFwYW5lc2UgRG9jdW1lbnRhdGlvbiBQ cm9qZWN0CgogICBVUkw6IGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcvamEvCiAgIFVSTDogaHR0cDov L3d3dy5qcC5GcmVlQlNELm9yZy9kb2MtanAvCgogICBDb250YWN0OiBIaXJva2kgU2F0byA8aHJz QEZyZWVCU0Qub3JnPgogICBDb250YWN0OiBSeXVzdWtlIFN1enVraSA8cnl1c3VrZUBGcmVlQlNE Lm9yZz4KCiAgIFdlYiBwYWdlIChodGRvY3MpOiBOZXdzZmxhc2ggYW5kIHNvbWUgb3RoZXIgdXBk YXRlcyBpbiB0aGUgRW5nbGlzaAogICB2ZXJzaW9uIGhhdmUgYmVlbiB0cmFuc2xhdGVkIHRvIGtl ZXAgdGhlbSB1cC10by1kYXRlLiBTcGVjaWZpY2FsbHksIHRoZQogICByZWxlYXNlIHJlbGF0ZWQg Y29udGVudHMgd2VyZSB1cGRhdGVkIGluIHRoaXMgcGVyaW9kLgoKICAgQm9va3M6IEZyZWVCU0Qg SGFuZGJvb2sgaGFzIGNvbnN0YW50bHkgYmVlbiB1cGRhdGVkIHNpbmNlIHRoZSBsYXN0CiAgIHJl cG9ydDsgcGFydGljdWxhcmx5LCAicG9ydHMiLCAiZGVza3RvcCIgc2VjdGlvbiB3ZXJlIGxhcmdl bHkgdXBkYXRlZC4KICAgU29tZSBwcm9ncmVzcyBoYXMgYmVlbiBtYWRlIGluIHRoZSAiYWR2YW5j ZWQtbmV0d29ya2luZyIgc2VjdGlvbiwKICAgY29udHJpYnV0ZWQgYnkgYSBuZXcgdHJhbnNsYXRv ci4KCiAgICJXcml0aW5nIEZyZWVCU0QgUHJvYmxlbSBSZXBvcnRzIiBhcnRpY2xlIGlzIG5vdyBp biBzeW5jIHdpdGggdGhlCiAgIEVuZ2xpc2ggdmVyc2lvbi4KCk9wZW4gdGFza3M6CgogICAgMS4g RnVydGhlciB0cmFuc2xhdGlvbiB3b3JrIG9mIG91dGRhdGVkIGRvY3VtZW50cyBpbiBqYV9KUC5l dWNKUAogICAgICAgc3VidHJlZS4KICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KClVGUy9GRlMgUGVyZm9ybWFuY2Ug V29yawoKICAgVVJMOiBodHRwOi8vd3d3Lm1ja3VzaWNrLmNvbS9wdWJsaWNhdGlvbnMvZmFzdGVy X2ZzY2sucGRmCgogICBDb250YWN0OiBLaXJrIE1jS3VzaWNrIDxtY2t1c2lja0BtY2t1c2ljay5j b20+CgogICBTb21lIHdvcmsgb24gdGhlIHBlcmZvcm1hbmNlIG9mIFVGUy9GRlMgaGFzIGJlZW4g cmVjZW50bHkgY29tbWl0dGVkIHRvCiAgIEhFQUQuIFRoZSBwdXJwb3NlIG9mIHRoZSBjb3JyZXNw b25kaW5nIGNoYW5nZSB0byB0aGUgRkZTIGxheW91dCBwb2xpY3kKICAgaXMgdG8gcmVkdWNlIHRo ZSBydW5uaW5nIHRpbWUgZm9yIGEgZnVsbCBmaWxlIHN5c3RlbSBjaGVjay4gSXQgYWxzbwogICBy ZWR1Y2VzIHRoZSByYW5kb20gYWNjZXNzIHRpbWUgZm9yIGxhcmdlIGZpbGVzIGFuZCBzcGVlZHMg dXAgdGhlCiAgIHRyYXZlcnNhbCB0aW1lIGZvciBkaXJlY3RvcnkgdHJlZSB3YWxrcy4KCiAgIFRo ZSBrZXkgaWRlYSBpcyB0byByZXNlcnZlIGEgc21hbGwgYXJlYSBpbiBlYWNoIGN5bGluZGVyIGdy b3VwCiAgIGltbWVkaWF0ZWx5IGZvbGxvd2luZyB0aGUgaW5vZGUgYmxvY2tzIGZvciB0aGUgdXNl IG9mIG1ldGFkYXRhLAogICBzcGVjaWZpY2FsbHkgaW5kaXJlY3QgYmxvY2tzIGFuZCBkaXJlY3Rv cnkgY29udGVudHMuIFRoZSBuZXcgcG9saWN5IGlzCiAgIHRvIHByZWZlcmVudGlhbGx5IHBsYWNl IG1ldGFkYXRhIGluIHRoZSBtZXRhZGF0YSBhcmVhIGFuZCBldmVyeXRoaW5nCiAgIGVsc2UgaW4g dGhlIGJsb2NrcyB0aGF0IGZvbGxvdyB0aGUgbWV0YWRhdGEgYXJlYS4KCiAgIFRoZSBzaXplIG9m IHRoaXMgYXJlYSBjYW4gYmUgc2V0IHdoZW4gY3JlYXRpbmcgYSBmaWxlc3lzdGVtIHVzaW5nCiAg IG5ld2ZzKDgpIG9yIGNoYW5nZWQgaW4gYW4gZXhpc3RpbmcgZmlsZXN5c3RlbSB1c2luZyB0dW5l ZnMoOCkuIEJvdGgKICAgdXRpbGl0aWVzIHVzZSB0aGUgLWsgaGVsZC1mb3ItbWV0YWRhdGEtYmxv Y2tzIG9wdGlvbiB0byBzcGVjaWZ5IHRoZQogICBhbW91bnQgb2Ygc3BhY2UgdG8gYmUgaGVsZCBm b3IgbWV0YWRhdGEgYmxvY2tzIGluIGVhY2ggY3lsaW5kZXIgZ3JvdXAuCiAgIEJ5IGRlZmF1bHQs IG5ld2ZzKDgpIHNldHMgdGhpcyBhcmVhIHRvIGhhbGYgb2YgbWluZnJlZSAodHlwaWNhbGx5IDQl IG9mCiAgIHRoZSBkYXRhIGFyZWEpLgoKICAgQXMgd2l0aCBhbGwgbGF5b3V0IHBvbGljaWVzLCBp dCBvbmx5IGFmZmVjdCBsYXlvdXRzIG9mIHRoaW5ncyBhbGxvY2F0ZWQKICAgYWZ0ZXIgaXQgaXMg cHV0IGluIHBsYWNlLiBTbyB0aGVzZSBjaGFuZ2VzIHdpbGwgcHJpbWFyaWx5IGJlIG5vdGljYWJs ZQogICBvbiBuZXdseSBjcmVhdGVkIGZpbGUgc3lzdGVtcy4KCiAgIEZpbGUgc3lzdGVtIGNoZWNr cyBoYXZlIGJlZW4gc3BlZCB1cCBieSBjYWNoaW5nIHRoZSBjeWxpbmRlciBncm91cCBtYXBzCiAg IGluIHBhc3MxIHNvIHRoYXQgdGhleSBkbyBub3QgbmVlZCB0byBiZSByZWFkIGFnYWluIGluIHBh c3M1LiBBcyB0aGlzCiAgIG5lYXJseSBkb3VibGVzIHRoZSBtZW1vcnkgcmVxdWlyZW1lbnQgZm9y IGZzY2soOCksIHRoZSBjYWNoZSBpcyB0aHJvd24KICAgYXdheSBpZiBvdGhlciBtZW1vcnkgbmVl ZHMgaW4gZnNjayg4KSB3b3VsZCBvdGhlcndpc2UgZmFpbC4gVGh1cywgdGhlCiAgIG1lbW9yeSBm b290cHJpbnQgb2YgZnNjayg4KSByZW1haW5zIHVuY2hhbmdlZCBpbiBtZW1vcnkgY29uc3RyYWlu ZWQKICAgZW52aXJvbm1lbnRzLiBUaGlzIG9wdGltaXphdGlvbiB3aWxsIGJlIGV2aWRlbnQgb24g YWxsIFVGUy9GRlMKICAgZmlsZXN5c3RlbXMuCgogICBUaGlzIHdvcmsgd2FzIGluc3BpcmVkIGJ5 IGEgcGFwZXIgcHJlc2VudGVkIGF0IFVzZW5peCdzIEZBU1QgJzEzLgoKT3BlbiB0YXNrczoKCiAg ICAxLiBNRkMgdG8gOS1TVEFCTEUgYW5kIHBvc3NpYmx5IDgtU1RBQkxFIHNob3VsZCBoYXBwZW4g YnkgTWF5IHVubGVzcwogICAgICAgcHJvYmxlbXMgYXJpc2Ugd2l0aCB0aGVzZSBjaGFuZ2VzIGlu IEhFQUQuCiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCgpXaW5lMzIgb24gRnJlZUJTRC9hbWQ2NAoKICAgVVJMOiBo dHRwOi8vd2lraS5mcmVlYnNkLm9yZy9pMzg2LVdpbmUKCiAgIENvbnRhY3Q6IERhdmlkIE5heWxv ciA8ZGJuQEZyZWVCU0Qub3JnPgoKICAgVGhlIGkzODYtd2luZSBwb3J0IChmb3JtYWxseSB3aW5l LWZic2Q2NCkgaGFzIGJlZW4gYWRkZWQgdG8gdGhlIHBvcnRzCiAgIGNvbGxlY3Rpb24gKGFzIGVt dWxhdG9ycy9pMzg2LXdpbmUtZGV2ZWwpLiBBbHRob3VnaCB0aGUgcG9ydCBjYW4gb25seQogICBi ZSBjb21waWxlZCB1bmRlciBhIHg4NiAzMi1iaXQgc3lzdGVtIHRoZSByZXN1bHRpbmcgcGFja2Fn ZSBjYW4gYmUKICAgaW5zdGFsbGVkIG9uIGEgeDg2IDY0LWJpdCBzeXN0ZW0gYW5kIGVuYWJsZSBy dW5uaW5nIG9mIDMyLWJpdCBNaWNyb3NvZnQKICAgV2luZG93cyBwcm9ncmFtcy4KCiAgIFBhY2th Z2VzIGZvciB0aGUgcG9ydCBhcmUgaW4gZGV2ZWxvcG1lbnQgYW5kIHNob3VsZCBiZSBhbm5vdW5j ZWQKICAgc2hvcnRseSBvbiB0aGUgZnJlZWJzZC1xdWVzdGlvbnMgYW5kIGZyZWVic2QtZW11bGF0 aW9uIG1haWxpbmcgbGlzdHMuCgogICBUaGVyZSBhcmUgc29tZSBpc3N1ZXMgd2l0aCBXaW5lMzIg b24gRnJlZUJTRC9hbWQ2NCAtLSBwb3NzaWJseSByZWxhdGVkCiAgIHRvIEZyZWVCU0QzMl9DT01Q QUNULCBvciBvdGhlciBnZW5lcmFsIDMyLzY0LWJpdCBpc3N1ZXMgLS0gdGhhdCBjb3VsZAogICBk byB3aXRoIHNvbWUgZm9jdXMuCgpPcGVuIHRhc2tzOgoKICAgIDEuIFBvcnQgd2luZTY0IHRvIEZy ZWVCU0QuCiAgICAyLiBQb3J0IFdvVzY0ICh3aW5lMzIgYW5kIHdpbmU2NCB0b2dldGhlcikgdG8g RnJlZUJTRC4KICAgIDMuIEZpeCAzMi0gYW5kIDY0LWJpdCBpc3N1ZXMgKHN1Y2ggYXMgSW50ZWwg Z3JhcGhpY3Mgbm90CiAgICAgICBhY2NlbGVyYXRpbmcpLgogICAgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKWGZjZS9G cmVlQlNECgogICBVUkw6IGh0dHBzOi8vd2lraS5GcmVlQlNELm9yZy9YZmNlCiAgIFVSTDogaHR0 cDovL3Blb3BsZS5mcmVlYnNkLm9yZy9+b2xpdmllcmQvcGF0Y2hlcy9taWRvcmktMC40LjlfMC41 LjAuZGlmZgoKICAgQ29udGFjdDogRnJlZUJTRCBYZmNlIFRlYW0gPHhmY2VARnJlZUJTRC5vcmc+ CgogICBUaGUgWGZjZSBGcmVlQlNEIFRlYW0gaGFzIHVwZGF0ZWQgbWFueSBwb3J0cywgZXNwZWNp YWxseToKCiAgICAgKiB0dW1ibGVyOiAwLjEuMjcgKGFkZCBuZXcgb3B0aW9uLCBDT1ZFUikKICAg ICAqIFBhcm9sZTogMC41LjAKICAgICAqIHhmZGVza3RvcDogNC4xMC4yCiAgICAgKiBNaWRvcmk6 IDAuNC45IChmdWxsIGNvbXBhdGlibGUgd2l0aCBWYWxhIDAuMTgpLCAwLjUuMCBpcyBhdmFpbGFi bGUKICAgICAgIChzZWUgbGlua3MpCiAgICAgKiBPcmFnZTogNC44LjQKICAgICAqIHhmY2U0LXRl cm1pbmFsOiAwLjYuMSAocmVuYW1lZCBieSB1cHN0cmVhbSwgcHJldmlvdXMgbmFtZSB3YXMKICAg ICAgIFRlcm1pbmFsKQoKICAgVGhpcyBsYXN0IGFwcGxpY2F0aW9uIGNvbnRhaW5zIGRyb3AtZG93 biBmdW5jdGlvbmFsaXR5LCBuZXcgd2luZG93CiAgIHNsaWRlcyBkb3duIGZyb20gdGhlIHRvcCBv ZiB0aGUgc2NyZWVuIHdoZW4ga2V5ICh3ZSBjYW4gZGVmaW5lIGtleWJvYXJkCiAgIHNob3J0Y3V0 KSBpcyBwcmVzc2VkLgoKT3BlbiB0YXNrczoKCiAgICAxLiBSZXBsYWNlIGxpYnhmY2U0Z3VpIChk ZXByZWNhdGVkIGFuZCBub3QgbWFpbnRhaW5lZCBieSB1cHN0cmVhbSkgYnkKICAgICAgIGxpYnhm Y2U0dWkgaW4gb3JkZXIgdG8gZW5oYW5jZSBzdXBwb3J0IHBhbmVsIHBsdWdpbnMgZm9yIFhmY2Ug Pj0KICAgICAgIDQuMTAuCiAgICAyLiBXb3JrIG9uIE1pZG9yaSBHdGszIHBvcnQuCiAgICAzLiBG aXggZ3RrLXhmY2UtZW5naW5lIHdpdGggR3RrKyA+PTMuNi4KICAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCnhvcmcg b24gRnJlZUJTRAoKICAgVVJMOiBodHRwOi8vd2lraS5mcmVlYnNkLm9yZy9Yb3JnCiAgIFVSTDog aHR0cDovL3Blb3BsZS5mcmVlYnNkLm9yZy9+emVpc2luZy94b3JnLTcuNy5kaWZmCiAgIFVSTDog aHR0cDovL3RyaWxsaWFuLmNocnVldGVydGVlLmNoL3BvcnRzL2Jyb3dzZXIvdHJ1bmsKICAgVVJM OiBodHRwOi8vdHJpbGxpYW4uY2hydWV0ZXJ0ZWUuY2gvcG9ydHMvYnJvd3Nlci9icmFuY2hlcy94 b3JnLTcuNwoKICAgQ29udGFjdDogRnJlZUJTRCBYMTEgVGVhbSA8eDExQEZyZWVCU0Qub3JnPgog ICBDb250YWN0OiBOaWNsYXMgWmVpc2luZyA8emVpc2luZ0BGcmVlQlNELm9yZz4KICAgQ29udGFj dDogS29vcCBNYXN0IDxrd21ARnJlZUJTRC5vcmc+CgogICBNb3N0IG9mIHRoZSB3b3JrIGR1cmlu ZyB0aGlzIHBlcmlvZCBoYXMgYmVlbiBpbiB1cGRhdGluZywgdGVzdGluZyBhbmQKICAgc3RhYmls aXppbmcgdGhlIGRldmVsb3BtZW50IHJlcG9zaXRvcnkuIEEgbnVtYmVyIG9mIHhvcmcgYXBwbGlj YXRpb25zCiAgIGFuZCB2YXJpb3VzIG90aGVyIGxlYWYgcG9ydHMgaGFzIGJlZW4gY29tbWl0dGVk IGFzIHBhcnQgb2YgdGhpcyBlZmZvcnQuCiAgIEFmdGVyIHRoaXMgYSBDRlQgd2FzIHNlbnQgb3V0 IGFza2luZyBmb3IgaGVscCBpbiB0ZXN0aW5nIHRoZSByZW1haW5pbmcKICAgYml0cyBpbiBkZXZl bG9wbWVudCwgaW5jbHVkaW5nIHVwZGF0ZXMgdG8gYWxsIG1ham9yIGxpYnJhcmllcyBhbmQKICAg eG9yZy1zZXJ2ZXIuCgogICBDdXJyZW50bHksIHRoZSBDRlQgcGF0Y2ggaGFzIGJlZW4gc3VibWl0 dGVkIGZvciBhbiBleHAtcnVuIHRvIGlyb24gb3V0CiAgIGFueSBmaW5hbCBidWdzLiBUaGUgcGxh biBpcyB0byBtZXJnZSBpdCBzb21ldGltZSBhZnRlciBGcmVlQlNEIDguNCBpcwogICByZWxlYXNl ZCBhbmQgdGhlIHBvcnRzIHRyZWUgaXMgcmVvcGVuZWQgZm9yIGNvbW1pdHMuCgogICBXb3JrIGlz IGFsc28gb24tZ29pbmcgdG8gcG9ydCBuZXcgdmVyc2lvbnMgb2YgTUVTQSBhbmQgT3BlbkdMLCBh cyB3ZWxsCiAgIGFzIGEgbmV3IHZlcnNpb24gb2YgeG9yZy1zZXJ2ZXIsIGFuZCBwZXJoYXBzIGlu IHRoZSBmdXR1cmUsIFdheWxhbmQuCiAgIFRoZXNlIGFyZSBjb25zaWRlcmVkIG1vcmUgbG9uZy10 ZXJtIGdvYWxzIGFuZCBhcmUgbm90IHRhcmdldGVkIGZvciB0aGUKICAgY3VycmVudCB1cGRhdGUu CgpPcGVuIHRhc2tzOgoKICAgIDEuIERlY2lkZSBob3cgdG8gaGFuZGxlIHRoZSBuZXcgYW5kIG9s ZCB4b3JnIGRpc3RyaWJ1dGlvbnMuIEluIHJlY2VudAogICAgICAgeG9yZywgYSBsb3Qgb2YgbGVn YWN5IGRyaXZlciBzdXBwb3J0IGhhcyBiZWVuIGRyb3BwZWQsIHRoZXJlZm9yZSB3ZQogICAgICAg bmVlZCB0byBtYWludGFpbiB0d28geG9yZyBkaXN0cmlidXRpb25zIHRvIG5vdCBsb3NlIGEgbG90 IG9mCiAgICAgICBoYXJkd2FyZSBkcml2ZXJzLiBDdXJyZW50bHksIHRoaXMgaXMgZG9uZSBieSBz ZXR0aW5nIHRoZSBmbGFnCiAgICAgICBXSVRIX05FV19YT1JHIGluIC9ldGMvbWFrZS5jb25mLCBi dXQgYSBtb3JlIHByYWN0aWNhbCBzb2x1dGlvbiBpcwogICAgICAgbmVlZGVkLiBUaGlzIGlzIGVz cGVjaWFsbHkgaW1wb3J0YW50IHNpbmNlIHRoZSBmbGFnIGlzIG5vdCB2ZXJ5CiAgICAgICB1c2Vy LWZyaWVuZGx5LCBhbmQgc2luY2UgdGhlcmUgY3VycmVudGx5IHdpbGwgYmUgbm8gb2ZmaWNpYWwK ICAgICAgIHBhY2thZ2VzIGZvciB0aGUgbmV3IGRpc3RyaWJ1dGlvbi4KICAgIDIuIENvbnRpbnVl IHRvIHRlc3QgYW5kIHVwZGF0ZSB4b3JnIHJlbGF0ZWQgcG9ydHMuIFRoZXJlIGFyZSBuZXcKICAg ICAgIHZlcnNpb25zIG9mIHhzZXJ2ZXIsIGFzIHdlbGwgYXMgTUVTQSBhbmQgcmVsYXRlZCBPcGVu R0wgbGlicmFyaWVzCiAgICAgICB3aGljaCBuZWVkcyB0byBiZSBwb3J0ZWQgYW5kIGV2ZW50dWFs bHkgaW50ZWdyYXRlZCBpbnRvIHRoZSBwb3J0cwogICAgICAgdHJlZS4KICAgIDMuIFBvcnQgV2F5 bGFuZC4gVGhlIGZ1dHVyZSBvZiBncmFwaGljYWwgZW52aXJvbm1lbnRzIGluIG9wZW4gc291cmNl CiAgICAgICBvcGVyYXRpbmcgc3lzdGVtcyBzZWVtcyB0byBiZSBXYXlsYW5kLiBUaGlzIG5lZWRz IHRvIGJlIHBvcnRlZCB0bwogICAgICAgRnJlZUJTRCBzbyB0aGF0IGEgd2lkZXIgYXVkaWVuY2Ug Y2FuIHRlc3QgaXQsIGFuZCBzbyB0aGF0IGl0CiAgICAgICBldmVudHVhbGx5IGNhbiBiZSBpbnRl Z3JhdGVkIGludG8gdGhlIHBvcnRzIHRyZWUsIHBlcmhhcHMgYXMgYQogICAgICAgcmVwbGFjZW1l bnQgZm9yIHRoZSBjdXJyZW50IHhvcmcuCiAgICA0LiBMb29rIGludG8gcmVwbGFjZW1lbnRzIGZv ciBIQUwuIEhBTCBpcyB1c2VkIGZvciBob3QtcGx1Z2dpbmcgb2YKICAgICAgIGRldmljZXMsIGJ1 dCBpdCBoYXMgYmVlbiBsb25nIGFiYW5kb25lZCBieSBMaW51eC4gQSByZXBsYWNlbWVudCwKICAg ICAgIHBlcmhhcHMgYnVpbGQgb24gdG9wIG9mIGRldmQgd291bGQgYmUgbmljZSB0byBoYXZlLiBU aGlzIHdvcmsKICAgICAgIHNob3VsZCBiZSBjb29yZGluYXRlZCB3aXRoIHRoZSBGcmVlQlNEIEdO T01FIGFuZCBLREUgdGVhbXMuCiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCmZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZyBtYWls aW5nIGxpc3QKaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJz ZC1jdXJyZW50ClRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLWN1cnJl bnQtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmci From owner-freebsd-hackers@FreeBSD.ORG Wed May 15 06:15:04 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3BDE2630; Wed, 15 May 2013 06:15:04 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 12262FB; Wed, 15 May 2013 06:15:03 +0000 (UTC) Received: from Julian-MBP3.local ([24.114.252.233]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r4F6EtsM095305 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 14 May 2013 23:14:56 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <519327DF.6060002@freebsd.org> Date: Wed, 15 May 2013 02:14:55 -0400 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Paul \"LeoNerd\" Evans" Subject: Re: Managing userland data pointers in kqueue/kevent References: <20130513185357.1c552be5@shy.leonerd.org.uk> <20130513191513.786f4f02@shy.leonerd.org.uk> <8A02C28F-89CB-4AE3-A91A-89565F041FDE@gmail.com> <20130513194411.5a2dfa2e@shy.leonerd.org.uk> In-Reply-To: <20130513194411.5a2dfa2e@shy.leonerd.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Adrian Chadd , Eugen-Andrei Gavriloaie X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 06:15:04 -0000 On 5/13/13 2:44 PM, Paul LeoNerd Evans wrote: > On Mon, 13 May 2013 11:23:45 -0700 > Adrian Chadd wrote: > >> Just as a data point, I managed 50,000 + connections, at 5,000 + a >> second, doing a gigabit + of traffic, mid-2000s, with the userland >> management of all of the socket/disk FD stuff. >> >> The biggest overhead at the time was actually the read/write >> copyin/copyout, NOT the locking overhead of managing this stuff. Why? >> Because I architected the HTTP side of things to specifically pin FDs >> to threads, and not allow arbitrary threads to deal with arbitrary >> FDs. This removed the need for almost all of the state locking that >> people are concerned about here. > I think then this comes from different experiences. > > I'm guessing this application was: > > a) Written in C > b) Entirely filled with identically-typed identical-purpose file > descriptors > c) Didn't really use any EV_ONESHOT events > d) Didn't close sockets apart from when it received EOF > and perhaps most importantly > e) Was entirely self-contained - did everything from one unified > block of source code. > > I.e. a very simple set of semantics. I'll explain the situation that I > had. > > The reason I ran into the problem needing EV_DROPWATCH/EV_DROPPED was > because I was trying to fix Perl's IO::KQueue. > > IO::KQueue tries to wrap kqueue/kevent for Perl, allowing the userland > Perl code to store an arbitrary Perl data pointer in the udata field. > This data is reference-counted. Userland might let the kernel store the > only copy of that data, because it comes back in event notifications > anyway. Because of this, the reference count has to be artificially > incremented to account for the extra pointer in the kernel. Without > knowing when the kernel will decide to drop that pointer, I never know > when I should decrement the refcount myself. > > It has no knowledge of what userland is doing with this. It can't know > when userland might be EV_ONESHOT'ing. It doesn't really know what > events will be oneshot anyway (such as the process exit watches). > Finally, it has no idea what other modules are going to call close() on > it. This final problem was the real killer - while the first two > -could- be worked around with more complex code structures, not knowing > what other CPAN modules will ever call close() makes it impossible to > handle. Simply asking every CPAN module to "please just call fd_close() > instead of close()" doesn't work here. > > As compared: having the kernel tell userland when it calls knote_drop() > is much simpler. It knows exactly when it is doing this, so simply > pushing an event up to userland to tell it it did so is simple. If any > more cases than the three known (EV_ONESHOT or other single-shot events; > EV_DELETE, close()) are added, userland - and in particular, the > IO::KQueue module, will not need updating. It will continue to > decrement refcounts and free data perfectly happily when kernel has > dropped the watch. > > I've used this pattern before in C libraries + higher-level language > wrappers, and found it to be nicely simple to both implement and use. > Because it follows the -same- event notification path that userland is > already using, it manages to avoid quite a number of the > race-conditions that a secondary, separate data structure and locking > often runs into; e.g. if userland is trying to add a new thing into it > just at the time there's a notification "in-flight" from the kernel > about an old thing that it used to have. > > Principly - the fact that kernel tells -userland- about the delete, > means that it can atomically *guarantee* that this *will* be the last > event about this particular item. Userland must not delete its own data > structure about it until this notification happens. If it does this, > lots of semantics become a lot simpler. I was responsible for the u_data field. It was not in the original design that was proposed and I suggested it to Jonathan. I was thinking purely of a simple way for an event to supply added information to its handler that would obviate the need for the app to keep complicated tracking structures. I was not thinking in terms of "badly behaved" (sic) third party high level ops using it through a language binding. I admit that I did not think about the close issue at that time. Your suggested changes are not unreasonable however we could do with more discussion. The point about tracking objects that may be arbitrarily destroyed without the framework being notified is valid and aligns well with general robustness principals. I would suggest that one answer would be to create an extension to register a kevent to catch these events.. (the knote_drop()) The returned event could have all the appropriate information for the event being dropped.. > From owner-freebsd-hackers@FreeBSD.ORG Wed May 15 09:11:57 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6267D587 for ; Wed, 15 May 2013 09:11:57 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 2AC6FAA6 for ; Wed, 15 May 2013 09:11:56 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 63B757E81E; Wed, 15 May 2013 19:11:48 +1000 (EST) Message-ID: <51935154.8090305@freebsd.org> Date: Wed, 15 May 2013 19:11:48 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130314 Thunderbird/17.0.4 MIME-Version: 1.0 To: Computer Network Man Subject: Re: A problem with alq module! References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 09:11:57 -0000 On 05/13/13 16:37, Computer Network Man wrote: > Dear Guys; > In a fresh FreeBSD 9 or 9.1 Release if you just run these commands: > # kldload alq > # kldunload alq > # init 0 or shutdown -p now > it will panic! > maybe it's a bug. > We have a module which uses alq API's. > MODULE_DEPEND(mymodule, alq, 1, 1, 1) > when our module starts, loads alq. and when it stops, unloads alq. So after > starting and stoping our module and shutdown, we have panic. > any opinion in this regard would be appreciated. Please test this patch: http://people.freebsd.org/~lstewart/patches/misc/alq_deregister_eventhandler_10.x.r250136.diff Cheers, Lawrence From owner-freebsd-hackers@FreeBSD.ORG Wed May 15 12:30:09 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3502ADB4; Wed, 15 May 2013 12:30:09 +0000 (UTC) (envelope-from leonerd@leonerd.org.uk) Received: from cel.leonerd.org.uk (cel.leonerd.org.uk [81.187.167.226]) by mx1.freebsd.org (Postfix) with ESMTP id B7FF191B; Wed, 15 May 2013 12:30:08 +0000 (UTC) Received: from shy.leonerd.org.uk (8.9.7.8.3.c.e.f.f.f.2.8.9.a.e.8.3.4.0.0.7.f.3.0.0.b.8.0.1.0.0.2.ip6.arpa [IPv6:2001:8b0:3f7:43:8ea9:82ff:fec3:8798]) by cel.leonerd.org.uk (Postfix) with ESMTPSA id E49DE1BDE0; Wed, 15 May 2013 13:29:59 +0100 (BST) Date: Wed, 15 May 2013 13:29:59 +0100 From: Paul "LeoNerd" Evans To: Julian Elischer Subject: Re: Managing userland data pointers in kqueue/kevent Message-ID: <20130515132959.7f113255@shy.leonerd.org.uk> In-Reply-To: <519327DF.6060002@freebsd.org> References: <20130513185357.1c552be5@shy.leonerd.org.uk> <20130513191513.786f4f02@shy.leonerd.org.uk> <8A02C28F-89CB-4AE3-A91A-89565F041FDE@gmail.com> <20130513194411.5a2dfa2e@shy.leonerd.org.uk> <519327DF.6060002@freebsd.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/CKQQMiQkN6/R.MPnz=gbgjQ"; protocol="application/pgp-signature" Cc: freebsd-hackers@freebsd.org, Adrian Chadd , Eugen-Andrei Gavriloaie X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 12:30:09 -0000 --Sig_/CKQQMiQkN6/R.MPnz=gbgjQ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 15 May 2013 02:14:55 -0400 Julian Elischer wrote: > I would suggest that one answer would be to create an extension to=20 > register a > kevent to catch these events.. >=20 > (the knote_drop()) >=20 > The returned event could have all the appropriate information for the > event being dropped.. Is that not the exact thing I suggested? The "extension to create register a kevent to catch these events" is that you put the EV_DROPWATCH bit flag in the event at the time you register it. The "returned event [that] could have all the appropriate informaiton for the event being dropped" is that you receive an event with EV_DROPPED set on it. It being a real event includes of course the udata pointer, so you can handle it. It's really simple to use: When you register, ev->flags |=3D EV_DROPWATCH When you receive an event, process it in the normal way, then if(ev->flags & EV_DROPPED) free(ev->udata); and that is all there is to it. --=20 Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ --Sig_/CKQQMiQkN6/R.MPnz=gbgjQ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlGTf8cACgkQvLS2TC8cBo26iACeO3k1s+4/mOJQYzRE+KMzWT/J g4wAn1+2c2EUPU58ULQ8IgnRwsgN1TIh =dAAY -----END PGP SIGNATURE----- --Sig_/CKQQMiQkN6/R.MPnz=gbgjQ-- From owner-freebsd-hackers@FreeBSD.ORG Wed May 15 12:35:01 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7745910A; Wed, 15 May 2013 12:35:01 +0000 (UTC) (envelope-from leonerd@leonerd.org.uk) Received: from cel.leonerd.org.uk (cel.leonerd.org.uk [IPv6:2001:8b0:3f7::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3696D96E; Wed, 15 May 2013 12:35:01 +0000 (UTC) Received: from shy.leonerd.org.uk (8.9.7.8.3.c.e.f.f.f.2.8.9.a.e.8.3.4.0.0.7.f.3.0.0.b.8.0.1.0.0.2.ip6.arpa [IPv6:2001:8b0:3f7:43:8ea9:82ff:fec3:8798]) by cel.leonerd.org.uk (Postfix) with ESMTPSA id 11BD41BDE0; Wed, 15 May 2013 13:34:59 +0100 (BST) Date: Wed, 15 May 2013 13:34:58 +0100 From: Paul "LeoNerd" Evans To: Paul "LeoNerd" Evans Subject: Re: Managing userland data pointers in kqueue/kevent Message-ID: <20130515133458.41f980e9@shy.leonerd.org.uk> In-Reply-To: <20130515132959.7f113255@shy.leonerd.org.uk> References: <20130513185357.1c552be5@shy.leonerd.org.uk> <20130513191513.786f4f02@shy.leonerd.org.uk> <8A02C28F-89CB-4AE3-A91A-89565F041FDE@gmail.com> <20130513194411.5a2dfa2e@shy.leonerd.org.uk> <519327DF.6060002@freebsd.org> <20130515132959.7f113255@shy.leonerd.org.uk> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/UsH7B7tp18EnNh7FXvjnxO9"; protocol="application/pgp-signature" Cc: freebsd-hackers@freebsd.org, Adrian Chadd , Eugen-Andrei Gavriloaie X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 12:35:01 -0000 --Sig_/UsH7B7tp18EnNh7FXvjnxO9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 15 May 2013 13:29:59 +0100 Paul "LeoNerd" Evans wrote: > Is that not the exact thing I suggested? >=20 > The "extension to create register a kevent to catch these events" is > that you put the EV_DROPWATCH bit flag in the event at the time you > register it. >=20 > The "returned event [that] could have all the appropriate informaiton > for the event being dropped" is that you receive an event with > EV_DROPPED set on it. It being a real event includes of course the > udata pointer, so you can handle it. In fact, to requote the original PR I wrote[1] on the subject: --- I propose the addition of a new flag applicable to any kevent watch structure, documented thusly: The flags field can contain the following values: .. EV_DROPWATCH Requests that the kernel will send an EV_DROPPED event on this watch when it has finished watching it for any reason, including EV_DELETE, expiry because of EV_ONESHOT, or because the filehandle was closed by close(2). EV_DROPPED This flag is returned by the kernel if it is now about to drop the watch. After this flag has been received, no further events will occur on this watch. This flag then makes it trivial to build a generic wrapper for kqueue that can always manage its memory correctly. a) at EV_ADD time, simply set flags |=3D EV_DROPWATCH b) after an event has been processed that included the EV_DROPPED flag, free() the pointer given in the udata field. It is not required that these two flags have distinct values; since one is userland->kernel and the other kernel->userland, they could for neatness reuse the same bit field. --- [1]: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D153254 --=20 Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ --Sig_/UsH7B7tp18EnNh7FXvjnxO9 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlGTgPIACgkQvLS2TC8cBo0TCQCfc9fKd4ZmWUPbB47cuVU2ZTa7 kl0AniFkCNluZde1HWjJs+/DC+oouKX+ =YiE5 -----END PGP SIGNATURE----- --Sig_/UsH7B7tp18EnNh7FXvjnxO9-- From owner-freebsd-hackers@FreeBSD.ORG Wed May 15 22:48:15 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 913504CA for ; Wed, 15 May 2013 22:48:15 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) by mx1.freebsd.org (Postfix) with ESMTP id 3F998F6E for ; Wed, 15 May 2013 22:48:14 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r4FMm8Mm064930 for ; Wed, 15 May 2013 18:48:08 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.9]); Wed, 15 May 2013 18:48:08 -0400 (EDT) Date: Wed, 15 May 2013 18:48:08 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: freebsd-hackers@freebsd.org Subject: Logging natd translations Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 22:48:15 -0000 We need to log all translations from internal IP addresses to external addresses. It's good enough to have IPv4 to Ipv4 translations for TCP streams, just one log for the start of each stream. We're using FreeBSD-9.1-stable and IPFW with userland natd. The -log option of natd just seems to log statistics, not any translation information. I can't see any easy way to do this with ipfw's rule log option either. Any ideas? -- DE From owner-freebsd-hackers@FreeBSD.ORG Thu May 16 01:52:32 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ED066FB9 for ; Thu, 16 May 2013 01:52:32 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) by mx1.freebsd.org (Postfix) with ESMTP id B7A20824 for ; Thu, 16 May 2013 01:52:32 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r4G1qVMf020932 for ; Wed, 15 May 2013 21:52:31 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.9]); Wed, 15 May 2013 21:52:31 -0400 (EDT) Date: Wed, 15 May 2013 21:52:31 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: freebsd-hackers@freebsd.org Subject: Re: Logging natd translations In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 01:52:33 -0000 On Wed, 15 May 2013, Daniel Eischen wrote: > We need to log all translations from internal IP addresses to > external addresses. It's good enough to have IPv4 to Ipv4 > translations for TCP streams, just one log for the start of > each stream. > > We're using FreeBSD-9.1-stable and IPFW with userland natd. > The -log option of natd just seems to log statistics, not > any translation information. I can't see any easy way to > do this with ipfw's rule log option either. > > Any ideas? To answer my own question, it looks like I can add an ipfw rule such as: divert natd log tcp from INSIDE_NET to any OUTSIDE_NET setup and that basically gives me what I want. -- DE From owner-freebsd-hackers@FreeBSD.ORG Thu May 16 20:51:35 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2579DB48 for ; Thu, 16 May 2013 20:51:35 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by mx1.freebsd.org (Postfix) with ESMTP id E15A0E8 for ; Thu, 16 May 2013 20:51:34 +0000 (UTC) Received: by mail-vb0-f53.google.com with SMTP id i3so1712658vbh.26 for ; Thu, 16 May 2013 13:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=BJ0iD6tG6x6XNheCzbaAv0CglNN1yvUzm7UHQpDM7UE=; b=hxTiby0eVp3UaSOz5jP6Jly0EetTfrhepYq6CkeI1h5jj9Od13CNUKtDzDMcHJtLGk NoNmDzdB0abvLucZEdYByF72a6lcUX7BaZ/IMasLefpMJbcAOxqiSMTTb9OcpXb+mlXH svh10sxNuQ9RIYNFJhXFn0KgfpBKwINc0Glh1nwp4nUHe9YkMA8+FnZvS9ZlgF9Cws7a m97zsfPwTIlywIZN1b/aTWZnIb8cMnSXF6wHDzgJiQKie+qjTwWCMiWa+FgW8RtqvfjJ rOAamWKSzWemlwgAYyMgfXXQVIV5slruhTvBXgkcfrGiG5G6ufaSQZp6cQJoE+OizMiB XGFQ== MIME-Version: 1.0 X-Received: by 10.52.183.170 with SMTP id en10mr24582987vdc.5.1368737494394; Thu, 16 May 2013 13:51:34 -0700 (PDT) Received: by 10.220.23.143 with HTTP; Thu, 16 May 2013 13:51:34 -0700 (PDT) Date: Thu, 16 May 2013 16:51:34 -0400 Message-ID: Subject: tape (sa0) on sparc64 ? From: Zaphod Beeblebrox To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 20:51:35 -0000 I have to retrieve some very old backups. They were made on FreeBSD and are on tape... specifically DDS4. I have a DDS4 drive and I ordered cables that hook it up to my sparc64. For fun and giggles I have both the motherboard controller... sym0: <1010-66> port 0x900-0x9ff mem 0x100000-0x1003ff,0x102000-0x103fff at device 2.0 on pci2 sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking sym1: <1010-66> port 0xa00-0xaff mem 0x104000-0x1043ff,0x106000-0x107fff at device 2.1 on pci2 sym1: No NVRAM, ID 7, Fast-80, LVD, parity checking and an adaptec controller ahc0: port 0x300-0x3ff mem 0x100000-0x100fff at device 1.0 on pci3 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: port 0x400-0x4ff mem 0x102000-0x102fff at device 1.1 on pci3 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs in the box. The tape drive is terminated with an external terminator (which seems proper since I found it in my collection with that terminator still attached). I have tried the tape connected to both the internal and adaptec controllers. Right now it shows up as: sa0 at sym1 bus 0 scbus3 target 2 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit) [1:24:324]root@run:/home/foo> mt stat Mode Density Blocksize bpi Compression Current: 0x26:DDS-4 variable 97000 DCLZ ---------available modes--------- 0: 0x26:DDS-4 variable 97000 DCLZ 1: 0x26:DDS-4 variable 97000 DCLZ 2: 0x26:DDS-4 variable 97000 DCLZ 3: 0x26:DDS-4 variable 97000 DCLZ --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 0 Record Number: 0 Residual Count 0 However, attached to either controller (after a reboot of the machine and a powercycle of the drive), I get: [1:25:325]root@run:/home/foo> dd if=/dev/sa0 of=tape5 dd: /dev/sa0: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 0.002930 secs (0 bytes/sec) ... which is a return code of '1' and no messages on the console... I have, before you ask, tried "bs=10k" and 20k ... but I believe this command should run by itself fetching the first 512 bytes of each block --- narrowing down the block size logically comes after making the tape go. (in case it matters, the machine is FreeBSD run.dclg.ca 9.1-STABLE FreeBSD 9.1-STABLE #1 r250082: Mon Apr 29 20:54:58 EDT 2013 root@run.dclg.ca:/usr/obj/usr/src/sys/GENERIC sparc64 From owner-freebsd-hackers@FreeBSD.ORG Thu May 16 21:22:17 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 44D071AC for ; Thu, 16 May 2013 21:22:17 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id E8291792 for ; Thu, 16 May 2013 21:22:16 +0000 (UTC) Received: from [194.32.164.30] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id r4GL9kd5018761; Thu, 16 May 2013 22:09:47 +0100 (BST) (envelope-from rb@gid.co.uk) Subject: Re: tape (sa0) on sparc64 ? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: Date: Thu, 16 May 2013 22:08:22 +0100 Content-Transfer-Encoding: 7bit Message-Id: <0D672BB1-1928-4F7A-BF72-CA7EE15D0563@gid.co.uk> References: To: Zaphod Beeblebrox X-Mailer: Apple Mail (2.1283) Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 21:22:17 -0000 Hi, On 16 May 2013, at 21:51, Zaphod Beeblebrox wrote: > I have to retrieve some very old backups. They were made on FreeBSD and > are on tape... specifically DDS4. [etc] > However, attached to either controller (after a reboot of the machine and a > powercycle of the drive), I get: > > [1:25:325]root@run:/home/foo> dd if=/dev/sa0 of=tape5 > dd: /dev/sa0: Input/output error > 0+0 records in > 0+0 records out > 0 bytes transferred in 0.002930 secs (0 bytes/sec) > > ... which is a return code of '1' and no messages on the console... > > I have, before you ask, tried "bs=10k" and 20k ... but I believe this > command should run by itself fetching the first 512 bytes of each block --- > narrowing down the block size logically comes after making the tape go. Try bs=64k -- Bob Bishop rb@gid.co.uk From owner-freebsd-hackers@FreeBSD.ORG Thu May 16 23:56:15 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 82B521EA for ; Thu, 16 May 2013 23:56:15 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 457C87A6 for ; Thu, 16 May 2013 23:56:15 +0000 (UTC) Received: by mail-ve0-f177.google.com with SMTP id ox1so3478486veb.22 for ; Thu, 16 May 2013 16:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0SvcP5lluUhoLTNEZtIES7/8kcchcfiNQrI+f165//Y=; b=oJGSTyBDj8yt/VppqdhjQ8h6eXnhBst4EIsemJp6f3nge3FLoObw0E/MW+USB34L4b Kvd70+Fsl/kMfrt+kYjSz4OOoV0GTPwwDvH55dIWM7/C8QlUaouA9K4fuQYtHxoWPRwA uyYzuqQA4eF54BRPMC58aZGFMwpSeEPYv/Nmm2PyB/K4eWDJmcD9EchdhRqHlpZli7V1 yzQgktZF42PAMiHVOJlcjxqOmgpYrqzyIrluYnfGSEfMLD2opBnr5j4+dgS1xFZwvqDK VSGSkQX659LtHt62iZTZYJGRFa9r1PDOglQ8mB6vW0iCr82vCb7ZzlsXA8bqOgK10MdH 1b0A== MIME-Version: 1.0 X-Received: by 10.52.114.135 with SMTP id jg7mr24555892vdb.78.1368748574544; Thu, 16 May 2013 16:56:14 -0700 (PDT) Received: by 10.220.23.143 with HTTP; Thu, 16 May 2013 16:56:14 -0700 (PDT) In-Reply-To: <0D672BB1-1928-4F7A-BF72-CA7EE15D0563@gid.co.uk> References: <0D672BB1-1928-4F7A-BF72-CA7EE15D0563@gid.co.uk> Date: Thu, 16 May 2013 19:56:14 -0400 Message-ID: Subject: Re: tape (sa0) on sparc64 ? From: Zaphod Beeblebrox To: Bob Bishop Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 23:56:15 -0000 On Thu, May 16, 2013 at 5:08 PM, Bob Bishop wrote: > Hi, > > On 16 May 2013, at 21:51, Zaphod Beeblebrox wrote: > > > I have to retrieve some very old backups. They were made on FreeBSD and > > are on tape... specifically DDS4. [etc] > > However, attached to either controller (after a reboot of the machine > and a > > powercycle of the drive), I get: > > > > [1:25:325]root@run:/home/foo> dd if=/dev/sa0 of=tape5 > > dd: /dev/sa0: Input/output error > > 0+0 records in > > 0+0 records out > > 0 bytes transferred in 0.002930 secs (0 bytes/sec) > > > > ... which is a return code of '1' and no messages on the console... > > > > I have, before you ask, tried "bs=10k" and 20k ... but I believe this > > command should run by itself fetching the first 512 bytes of each block > --- > > narrowing down the block size logically comes after making the tape go. > > > Try bs=64k > Same result. Besides, as far as I understand, the proper operation (if the blocksize is too small) is to read the first $n bytes and then write them to the output.. But same result. From owner-freebsd-hackers@FreeBSD.ORG Fri May 17 00:31:02 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B379B909 for ; Fri, 17 May 2013 00:31:02 +0000 (UTC) (envelope-from grog@lemis.com) Received: from w3.lemis.com (w3.lemis.com [208.86.224.149]) by mx1.freebsd.org (Postfix) with ESMTP id 8E6AA8DA for ; Fri, 17 May 2013 00:31:02 +0000 (UTC) Received: from eureka.lemis.com (1032.x.rootbsd.net [208.86.224.149]) by w3.lemis.com (Postfix) with ESMTP id A87743B736; Fri, 17 May 2013 00:31:00 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 08ABAF75F3; Fri, 17 May 2013 10:30:59 +1000 (EST) Date: Fri, 17 May 2013 10:30:59 +1000 From: Greg 'groggy' Lehey To: Zaphod Beeblebrox Subject: Re: tape (sa0) on sparc64 ? Message-ID: <20130517003058.GW77641@eureka.lemis.com> References: <0D672BB1-1928-4F7A-BF72-CA7EE15D0563@gid.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Tln/wzp9jsNjmSUr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: The FreeBSD Project Phone: +61-3-5346-1370 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 00:31:02 -0000 --Tln/wzp9jsNjmSUr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thursday, 16 May 2013 at 19:56:14 -0400, Zaphod Beeblebrox wrote: > On Thu, May 16, 2013 at 5:08 PM, Bob Bishop wrote: >> On 16 May 2013, at 21:51, Zaphod Beeblebrox wrote: >> >>> I have to retrieve some very old backups. They were made on FreeBSD and >>> are on tape... specifically DDS4. [etc] >>> However, attached to either controller (after a reboot of the machine >> and a >>> powercycle of the drive), I get: >>> >>> [1:25:325]root@run:/home/foo> dd if=/dev/sa0 of=tape5 >>> dd: /dev/sa0: Input/output error >>> 0+0 records in >>> 0+0 records out >>> 0 bytes transferred in 0.002930 secs (0 bytes/sec) >>> >>> ... which is a return code of '1' and no messages on the console... >>> >>> I have, before you ask, tried "bs=10k" and 20k ... but I believe this >>> command should run by itself fetching the first 512 bytes of each block >> --- >>> narrowing down the block size logically comes after making the tape go. >> >> >> Try bs=64k > > Same result. Besides, as far as I understand, the proper operation > (if the blocksize is too small) is to read the first $n bytes and > then write them to the output.. The obvious question: can you write tapes and read them back? My experience with DDS tapes was of extreme unreliability. The age doesn't make things any easier. Greg -- Sent from my desktop computer. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua --Tln/wzp9jsNjmSUr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlGVekIACgkQIubykFB6QiNbnwCfes0z89YVMRVVQEnUe0NzH+w0 uAIAn3XRJaVEt2+55iM7vzRYWNTUmPa2 =IEct -----END PGP SIGNATURE----- --Tln/wzp9jsNjmSUr-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 17 00:57:00 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 39C78F0A; Fri, 17 May 2013 00:57:00 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by mx1.freebsd.org (Postfix) with ESMTP id DFC4E99C; Fri, 17 May 2013 00:56:59 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id ib11so140394vcb.36 for ; Thu, 16 May 2013 17:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Cj0vrQkGXbh/CM6SbBKwfE4H/g04ScwiTI4Plt3UxjQ=; b=iUfRnY++HK7uJYTHtZ5QgjMBKXH6wi1Hc+cwhYC2zOD/5nP3eueAoi2A8sLr1XNGW8 jnIxVjAshr6mTFQA6nwWStx7ZfOY0D3E4o6F44TMpNmE6crBLIH6jXRPJQa7FsEkmLR1 yOnFsrszR5T2ZlDaYDJBGpw9kmIVXhGNTfkYK2Un1PRM1gWz3zaCowc3KJ3lHvioPWfH nj6dgWmFwP25Ddrbwb/fkP08k/TmW5jASgHd4Vd2kZ0nUNLxZzNsoMtTEbk6gcgVwj5i gxatMJP/8eHzMQmEcP7039vaB0YPhDwNHt0Z5nAua2RU1u4yIfR6/DMbpzMhxylgG8ar f+qw== MIME-Version: 1.0 X-Received: by 10.220.194.5 with SMTP id dw5mr28785903vcb.47.1368752213346; Thu, 16 May 2013 17:56:53 -0700 (PDT) Received: by 10.220.23.143 with HTTP; Thu, 16 May 2013 17:56:53 -0700 (PDT) In-Reply-To: <20130517003058.GW77641@eureka.lemis.com> References: <0D672BB1-1928-4F7A-BF72-CA7EE15D0563@gid.co.uk> <20130517003058.GW77641@eureka.lemis.com> Date: Thu, 16 May 2013 20:56:53 -0400 Message-ID: Subject: Re: tape (sa0) on sparc64 ? From: Zaphod Beeblebrox To: "Greg 'groggy' Lehey" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 00:57:00 -0000 On Thu, May 16, 2013 at 8:30 PM, Greg 'groggy' Lehey wrote: > On Thursday, 16 May 2013 at 19:56:14 -0400, Zaphod Beeblebrox wrote: > > On Thu, May 16, 2013 at 5:08 PM, Bob Bishop wrote: > >> On 16 May 2013, at 21:51, Zaphod Beeblebrox wrote: > >> > > [about my tape drive not working] > The obvious question: can you write tapes and read them back? My > experience with DDS tapes was of extreme unreliability. The age > doesn't make things any easier. > Well... therein lies my other suspicion. I don't have any DDS4 tapes to try writing, but the DDS3 tapes I have fail to write. ... but they don't even try. The tape spools up when inserted and "mt offl" works (ejects the tape) and the drive doesn't indicate any error at this point --- but it doesn't even try to start moving for either read or write. From owner-freebsd-hackers@FreeBSD.ORG Fri May 17 02:04:20 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D8D061C6 for ; Fri, 17 May 2013 02:04:20 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id B1EE9CC1 for ; Fri, 17 May 2013 02:04:20 +0000 (UTC) Received: from Julian-MBP3.local ([137.122.64.25]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r4H249MP040901 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 16 May 2013 19:04:19 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51959013.5040005@freebsd.org> Date: Thu, 16 May 2013 22:04:03 -0400 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Daniel Eischen Subject: Re: Logging natd translations References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 02:04:20 -0000 On 5/15/13 9:52 PM, Daniel Eischen wrote: > On Wed, 15 May 2013, Daniel Eischen wrote: > >> We need to log all translations from internal IP addresses to >> external addresses. It's good enough to have IPv4 to Ipv4 >> translations for TCP streams, just one log for the start of >> each stream. >> >> We're using FreeBSD-9.1-stable and IPFW with userland natd. >> The -log option of natd just seems to log statistics, not >> any translation information. I can't see any easy way to >> do this with ipfw's rule log option either. >> >> Any ideas? > > To answer my own question, it looks like I can add an ipfw > rule such as: > > divert natd log tcp from INSIDE_NET to any OUTSIDE_NET setup > > and that basically gives me what I want. why not turn on the logging on natd? I think it has an option for logging new sessions.. From owner-freebsd-hackers@FreeBSD.ORG Fri May 17 02:22:11 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1E18E3EF for ; Fri, 17 May 2013 02:22:11 +0000 (UTC) (envelope-from grog@lemis.com) Received: from w3.lemis.com (w3.lemis.com [208.86.224.149]) by mx1.freebsd.org (Postfix) with ESMTP id EBB6AD3E for ; Fri, 17 May 2013 02:22:10 +0000 (UTC) Received: from eureka.lemis.com (1032.x.rootbsd.net [208.86.224.149]) by w3.lemis.com (Postfix) with ESMTP id 61A9C3B79C; Fri, 17 May 2013 02:22:08 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id D98B6F74D1; Fri, 17 May 2013 12:22:03 +1000 (EST) Date: Fri, 17 May 2013 12:22:03 +1000 From: Greg 'groggy' Lehey To: Zaphod Beeblebrox Subject: Re: tape (sa0) on sparc64 ? Message-ID: <20130517022203.GX77641@eureka.lemis.com> References: <0D672BB1-1928-4F7A-BF72-CA7EE15D0563@gid.co.uk> <20130517003058.GW77641@eureka.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Wn0J+vu9+NMIXK57" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: The FreeBSD Project Phone: +61-3-5346-1370 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 02:22:11 -0000 --Wn0J+vu9+NMIXK57 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thursday, 16 May 2013 at 20:56:53 -0400, Zaphod Beeblebrox wrote: > On Thu, May 16, 2013 at 8:30 PM, Greg 'groggy' Lehey wrote: > >> On Thursday, 16 May 2013 at 19:56:14 -0400, Zaphod Beeblebrox wrote: >>> On Thu, May 16, 2013 at 5:08 PM, Bob Bishop wrote: >>>> On 16 May 2013, at 21:51, Zaphod Beeblebrox wrote: >> > [about my tape drive not working] > >> The obvious question: can you write tapes and read them back? My >> experience with DDS tapes was of extreme unreliability. The age >> doesn't make things any easier. > > Well... therein lies my other suspicion. I don't have any DDS4 tapes to > try writing, but the DDS3 tapes I have fail to write. > > ... but they don't even try. The tape spools up when inserted and "mt > offl" works (ejects the tape) and the drive doesn't indicate any error at > this point --- but it doesn't even try to start moving for either read or > write. You'd expect at least a message, wouldn't you? It's difficult to say whether this is bitrot or taperot. Greg -- Sent from my desktop computer. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua --Wn0J+vu9+NMIXK57 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlGVlEsACgkQIubykFB6QiOyUwCfaHDGXB5Wllmkz6KOI8SrtLGk pUsAn12T8+JnSYDnf8mqebNLMRSUeJst =pbj2 -----END PGP SIGNATURE----- --Wn0J+vu9+NMIXK57-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 17 02:52:43 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8E1AE702; Fri, 17 May 2013 02:52:43 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) by mx1.freebsd.org (Postfix) with ESMTP id 56F0CE71; Fri, 17 May 2013 02:52:42 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r4H2qaFh010214; Thu, 16 May 2013 22:52:36 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.9]); Thu, 16 May 2013 22:52:36 -0400 (EDT) Date: Thu, 16 May 2013 22:52:36 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Julian Elischer Subject: Re: Logging natd translations In-Reply-To: <51959013.5040005@freebsd.org> Message-ID: References: <51959013.5040005@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 02:52:43 -0000 On Thu, 16 May 2013, Julian Elischer wrote: > On 5/15/13 9:52 PM, Daniel Eischen wrote: >> On Wed, 15 May 2013, Daniel Eischen wrote: >> >>> We need to log all translations from internal IP addresses to >>> external addresses. It's good enough to have IPv4 to Ipv4 >>> translations for TCP streams, just one log for the start of >>> each stream. >>> >>> We're using FreeBSD-9.1-stable and IPFW with userland natd. >>> The -log option of natd just seems to log statistics, not >>> any translation information. I can't see any easy way to >>> do this with ipfw's rule log option either. >>> >>> Any ideas? >> >> To answer my own question, it looks like I can add an ipfw >> rule such as: >> >> divert natd log tcp from INSIDE_NET to any OUTSIDE_NET setup >> >> and that basically gives me what I want. > > why not turn on the logging on natd? > > I think it has an option for logging new sessions.. I tried the -log option to natd, but it just logged statistics, not new connection information. natd(8) doesn't show any other useful options. When I did try natd -log, that was under an older version of FreeBSD (6.x?), but we just upgraded the system to 9-stable and I didn't try it again. -- DE From owner-freebsd-hackers@FreeBSD.ORG Fri May 17 06:54:33 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 78890B31 for ; Fri, 17 May 2013 06:54:33 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by mx1.freebsd.org (Postfix) with ESMTP id EEE1D99B for ; Fri, 17 May 2013 06:54:32 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.30]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MAiyD-1UoYQ833c3-00BtKe for ; Fri, 17 May 2013 08:54:31 +0200 Received: (qmail invoked by alias); 17 May 2013 06:54:31 -0000 Received: from f049230253.adsl.alicedsl.de (EHLO mandree.no-ip.org) [78.49.230.253] by mail.gmx.net (mp030) with SMTP; 17 May 2013 08:54:31 +0200 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX1/KdJoJcsvKdFLQGeJWzm+Rvk11qNZckYFhbCrKc0 XKP/GBn636L5ec Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id A966B23D2B1 for ; Fri, 17 May 2013 08:54:28 +0200 (CEST) Message-ID: <5195D424.70302@gmx.de> Date: Fri, 17 May 2013 08:54:28 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: tape (sa0) on sparc64 ? References: <0D672BB1-1928-4F7A-BF72-CA7EE15D0563@gid.co.uk> <20130517003058.GW77641@eureka.lemis.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 06:54:33 -0000 Am 17.05.2013 02:56, schrieb Zaphod Beeblebrox: > On Thu, May 16, 2013 at 8:30 PM, Greg 'groggy' Lehey wrote: > >> On Thursday, 16 May 2013 at 19:56:14 -0400, Zaphod Beeblebrox wrote: >>> On Thu, May 16, 2013 at 5:08 PM, Bob Bishop wrote: >>>> On 16 May 2013, at 21:51, Zaphod Beeblebrox wrote: >>>> >> >> > [about my tape drive not working] > > >> The obvious question: can you write tapes and read them back? My >> experience with DDS tapes was of extreme unreliability. The age >> doesn't make things any easier. >> > > Well... therein lies my other suspicion. I don't have any DDS4 tapes to > try writing, but the DDS3 tapes I have fail to write. > > ... but they don't even try. The tape spools up when inserted and "mt > offl" works (ejects the tape) and the drive doesn't indicate any error at > this point --- but it doesn't even try to start moving for either read or > write. Have you used dd, tar, or pax, to actually write data? I suppose newer DDS drives would not actually engage the tape to their head drum until you were actually reading/writing, in order to reduce wear and tear of tape and heads. Not that it helps you now: Personally, after a few first steps with DDS1DC and DDS2, I dropped helical scan stuff because I often found that I could read tapes only on the same drive that had written them (I had three drives around in the late 1990s/early 2000); no matter if the heads were cleaned or not, and I moved on going for for optical disks and linear tape (which includues MLR/SLR, DLT, SuperDLT, LTO; personally I used SLR2, SLR4DC and SLR6 aka SLR24). From owner-freebsd-hackers@FreeBSD.ORG Fri May 17 08:13:00 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5018FA55 for ; Fri, 17 May 2013 08:13:00 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id CD1FEC26 for ; Fri, 17 May 2013 08:12:59 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r4H8Aa9Z058070; Fri, 17 May 2013 10:10:36 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r4H8Aa5R058067; Fri, 17 May 2013 10:10:36 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 17 May 2013 10:10:36 +0200 (CEST) From: Wojciech Puchar To: Zaphod Beeblebrox Subject: Re: tape (sa0) on sparc64 ? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 17 May 2013 10:10:36 +0200 (CEST) Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 08:13:00 -0000 > 1: 0x26:DDS-4 variable 97000 DCLZ > 2: 0x26:DDS-4 variable 97000 DCLZ > 3: 0x26:DDS-4 variable 97000 DCLZ > --------------------------------- > Current Driver State: at rest. > --------------------------------- > File Number: 0 Record Number: 0 Residual Count 0 all fine. > > However, attached to either controller (after a reboot of the machine and a > powercycle of the drive), I get: > > [1:25:325]root@run:/home/foo> dd if=/dev/sa0 of=tape5 > dd: /dev/sa0: Input/output error > 0+0 records in > 0+0 records out > 0 bytes transferred in 0.002930 secs (0 bytes/sec) > > ... which is a return code of '1' and no messages on the console... > > I have, before you ask, tried "bs=10k" and 20k ... but I believe this > command should run by itself fetching the first 512 bytes of each block --- wrong. you have to specify proper block size or multiple of it. if you don't remember block size just try. I am not sure (not used tape for a long) but requesting larger block that is available should work too. if you used dump(8) then block size is most probably 32kB. try restore(8) or tar. From owner-freebsd-hackers@FreeBSD.ORG Fri May 17 09:22:09 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E8365F81; Fri, 17 May 2013 09:22:09 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 7B870F30; Fri, 17 May 2013 09:22:08 +0000 (UTC) Received: from [194.32.164.26] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id r4H9M7Jl054565; Fri, 17 May 2013 10:22:07 +0100 (BST) (envelope-from rb@gid.co.uk) Subject: Re: tape (sa0) on sparc64 ? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: <20130517003058.GW77641@eureka.lemis.com> Date: Fri, 17 May 2013 10:22:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D672BB1-1928-4F7A-BF72-CA7EE15D0563@gid.co.uk> <20130517003058.GW77641@eureka.lemis.com> To: Zaphod Beeblebrox X-Mailer: Apple Mail (2.1283) Cc: Greg 'groggy' Lehey , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 09:22:10 -0000 Hi, On 17 May 2013, at 01:30, Greg 'groggy' Lehey wrote: > On Thursday, 16 May 2013 at 19:56:14 -0400, Zaphod Beeblebrox wrote: >> On Thu, May 16, 2013 at 5:08 PM, Bob Bishop wrote: >>> On 16 May 2013, at 21:51, Zaphod Beeblebrox wrote: >>>=20 >>>> I have to retrieve some very old backups. They were made on = FreeBSD and >>>> are on tape... specifically DDS4. [etc] >>>> However, attached to either controller (after a reboot of the = machine >>> and a >>>> powercycle of the drive), I get: >>>>=20 >>>> [1:25:325]root@run:/home/foo> dd if=3D/dev/sa0 of=3Dtape5 >>>> dd: /dev/sa0: Input/output error >>>> 0+0 records in >>>> 0+0 records out >>>> 0 bytes transferred in 0.002930 secs (0 bytes/sec) >>>>=20 >>>> ... which is a return code of '1' and no messages on the console... >>>>=20 >>>> I have, before you ask, tried "bs=3D10k" and 20k ... but I believe = this >>>> command should run by itself fetching the first 512 bytes of each = block >>> --- >>>> narrowing down the block size logically comes after making the tape = go. >>>=20 >>>=20 >>> Try bs=3D64k >>=20 >> Same result. Besides, as far as I understand, the proper operation >> (if the blocksize is too small) is to read the first $n bytes and >> then write them to the output.. My (dim) memory says the drive won't read at all if you get the = blocksize wrong, so may be worth trying other sizes... > The obvious question: can you write tapes and read them back? ...but certainly try that. > My > experience with DDS tapes was of extreme unreliability. The age > doesn't make things any easier. There's a lot to go wrong with settings etc. See for instance: = http://fixunix.com/setup/398541-dds-4-tape-drive-compatiblity.html > Greg > -- > Sent from my desktop computer. > Finger grog@FreeBSD.org for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft MUA reports > problems, please read http://tinyurl.com/broken-mua -- Bob Bishop rb@gid.co.uk From owner-freebsd-hackers@FreeBSD.ORG Fri May 17 14:08:34 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 23AE3307 for ; Fri, 17 May 2013 14:08:34 +0000 (UTC) (envelope-from mj@feral.com) Received: from virtual.feral.com (virtual.feral.com [216.224.170.83]) by mx1.freebsd.org (Postfix) with ESMTP id CC889EAD for ; Fri, 17 May 2013 14:08:33 +0000 (UTC) Received: from [192.168.136.3] (76-14-48-84.sf-cable.astound.net [76.14.48.84] (may be forged)) by virtual.feral.com (8.14.4/8.14.4) with ESMTP id r4HE7PLT014485 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 17 May 2013 07:07:26 -0700 Message-ID: <51963997.9010208@feral.com> Date: Fri, 17 May 2013 07:07:19 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: tape (sa0) on sparc64 ? References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (virtual.feral.com [216.224.170.83]); Fri, 17 May 2013 07:07:26 -0700 (PDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 14:08:34 -0000 On 5/16/2013 1:51 PM, Zaphod Beeblebrox wrote: > ... > > [1:25:325]root@run:/home/foo> dd if=/dev/sa0 of=tape5 > hmm. try tcopy. Can we see any complaints from /var/log/messages? (this would be better discussed on freebsd-scsi) From owner-freebsd-hackers@FreeBSD.ORG Sat May 18 04:04:17 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9F36598C for ; Sat, 18 May 2013 04:04:17 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 65DC2E6C for ; Sat, 18 May 2013 04:04:17 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UdYNT-0004Mb-I4 for freebsd-hackers@freebsd.org; Sat, 18 May 2013 06:04:15 +0200 Received: from 137.122.39.160 ([137.122.39.160]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 18 May 2013 06:04:15 +0200 Received: from ivoras by 137.122.39.160 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 18 May 2013 06:04:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Subject: blogbench and write-open serialization Date: Sat, 18 May 2013 00:04:05 -0400 Lines: 17 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 137.122.39.160 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 04:04:17 -0000 During the BSDCan & DevSummit I got interested in finding out why blogbench is so slow on FreeBSD. After talking to jhb, it looked like one of the reasons might be that opening files with O_RDWR or O_WRONLY (anything opening the file for writing) is serialized. To check this, I've written a small test program, which I've run on CentOS 6.3 and FreeBSD 10-HEAD on the same hardware. Here are the results: https://wiki.freebsd.org/Benchmarking/OpenCloseBenchmark Conclusions: * Linux opens and closes files much faster than FreeBSD * Linux does not serialize write-open operations, while FreeBSD does * Even with O_RDONLY, FreeBSD is much slower in opening (and closing) files. I'd welcome a review of these results and comments. From owner-freebsd-hackers@FreeBSD.ORG Sat May 18 11:59:16 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0B2DF381 for ; Sat, 18 May 2013 11:59:16 +0000 (UTC) (envelope-from florent@peterschmitt.fr) Received: from peterschmitt.fr (peterschmitt.fr [5.135.177.31]) by mx1.freebsd.org (Postfix) with ESMTP id CCAE5DCD for ; Sat, 18 May 2013 11:59:15 +0000 (UTC) Received: from [192.168.0.130] (4ab54-4-88-163-248-31.fbx.proxad.net [88.163.248.31]) by peterschmitt.fr (Postfix) with ESMTPSA id 7F2A778A7 for ; Sat, 18 May 2013 13:59:22 +0200 (CEST) Message-ID: <51976D13.4010604@peterschmitt.fr> Date: Sat, 18 May 2013 13:59:15 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: blogbench and write-open serialization References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: florent+FreeBSD-hackers@peterschmitt.fr List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 11:59:16 -0000 Le 18/05/2013 06:04, Ivan Voras a écrit : > During the BSDCan & DevSummit I got interested in finding out why > blogbench is so slow on FreeBSD. After talking to jhb, it looked like > one of the reasons might be that opening files with O_RDWR or O_WRONLY > (anything opening the file for writing) is serialized. > > To check this, I've written a small test program, which I've run on > CentOS 6.3 and FreeBSD 10-HEAD on the same hardware. Here are the results: > > https://wiki.freebsd.org/Benchmarking/OpenCloseBenchmark > > Conclusions: > > * Linux opens and closes files much faster than FreeBSD > * Linux does not serialize write-open operations, while FreeBSD does > * Even with O_RDONLY, FreeBSD is much slower in opening (and closing) files. > > I'd welcome a review of these results and comments. Hi, I'm no able to say anything about that (because I've no idea of how does Linux or FreeBSD works ), but could it be a problem from filesystem ? Everytime I had UFS I found the entire system very slow when doing some I/O (many little freezes), and with ZFS it's globally much better. From owner-freebsd-hackers@FreeBSD.ORG Sat May 18 18:32:13 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 831763AF for ; Sat, 18 May 2013 18:32:13 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.13.206.130]) by mx1.freebsd.org (Postfix) with ESMTP id EC819DBC for ; Sat, 18 May 2013 18:32:11 +0000 (UTC) Received: (qmail 7884 invoked from network); 18 May 2013 18:32:08 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with CAMELLIA256-SHA encrypted SMTP; 18 May 2013 18:32:08 -0000 Message-ID: <5197C925.8060205@erdgeist.org> Date: Sat, 18 May 2013 14:32:05 -0400 From: Dirk Engling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Eugen-Andrei Gavriloaie Subject: Re: Managing userland data pointers in kqueue/kevent References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 18:32:13 -0000 On 13.05.13 11:19, Eugen-Andrei Gavriloaie wrote: > Regardless, it has all the ingredients for memory leaks and/or, the > worst one, use of corpse pointers which are bound to crash the app. I I earlier pointed out other things that prevent me from using kqueue as a proper storage for user land pointers: http://lists.freebsd.org/pipermail/freebsd-hackers/2013-March/042181.html To sum it up, once I pass a pointer via udata to the kqueue system, kqueue becomes the owner and the expected behaviour is (a) never silently swallow the pointer (b) provide an interface to retrieve the pointer anytime Besides the way you pointed out to violate (a), there is another way, re-adding an existing event. So I propose a flag EV_EXCL that will fail adding an existing event with EEXIST in data. As an alternative or in addition to that, re-adding an existing event without the EV_EXCL flag will cause the old event to be returned with the EV_DROPPED mechanism proposed. This can also be used to fulfill property (b). kqueue is an efficient store for the per-event-data. In an event base application, I usually allocate resources per new session, pass the metadata via udata to kevent and will see the udata pointer whenever the event triggers. But in order to clean up resources due to external events (like program termination), I have no way to ask my kqueue for the kevents (and thus the udata) I stored in them ... without knowing about them in the first place. For the program termination case, it would be enough to extend EV_DELETE with a flag to drop all filters and catch them by checking for the EV_DROPPED flag. This means that EV_DELETE could return a list of filters and can be called several times until no events are returned. Of course this can be extended to specifically drop events that match a certain filter, flag or fflag value, but for now you can also use different kqueues. Regards, erdgeist