From owner-soc-status@freebsd.org Sun Aug 23 20:33:56 2015 Return-Path: Delivered-To: soc-status@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DFC2A9C0123 for ; Sun, 23 Aug 2015 20:33:56 +0000 (UTC) (envelope-from ionutalex.teaca@gmail.com) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A3105C7C; Sun, 23 Aug 2015 20:33:56 +0000 (UTC) (envelope-from ionutalex.teaca@gmail.com) Received: by obbhe7 with SMTP id he7so97429410obb.0; Sun, 23 Aug 2015 13:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rxg8YyGHjlSUIe0fMnFcFlp0jYjSs7QBGruH9gL9ANk=; b=woov2618v1E5k6yI1U8gYm7K35rzM4mJXsnThLGl+y9oWOJMdoj42Q4uyPCtdR5chG P7yPphzc3wc1ewX6UqyMh9YN8ygQ1/pg2URHogzQEo3SjOOGjT00GMxfsDaP2Lf0PhwL 7QToBWZ1LMIRXgiDCcsT8rMgF9NFOknIEbu1hVK73zkqeCSISGYCf1+28KbGA8xeaZBf PWVvg83wFfpFizhQWlcF4RqFnjOpcML3djFfEM2Job6eNYYz0hTqzvqPkMD0SNnKLLHl +qLV3Coj7jK1lElxQ0BRvDma78jnMRrvhit1s44g3QrgfHy2q7eQNtGjQ4LgH/7LP5Xl LVfA== MIME-Version: 1.0 X-Received: by 10.182.86.72 with SMTP id n8mr18953309obz.9.1440362036054; Sun, 23 Aug 2015 13:33:56 -0700 (PDT) Received: by 10.76.84.37 with HTTP; Sun, 23 Aug 2015 13:33:55 -0700 (PDT) In-Reply-To: References: Date: Sun, 23 Aug 2015 23:33:55 +0300 Message-ID: Subject: Re: GSOC 2015 - NE2000 emulation in bhyve Status From: Alex Teaca To: soc-status@freebsd.org Cc: Gavin Atkinson Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2015 20:33:57 -0000 Hi, - I've redesign the implementation in order to add the LPC attachment - implement the LPC attachment of the NE2000 emulation - update the wiki page with the final results, tests and performance measured [0] https://wiki.freebsd.org/SummerOfCode2015/NE2000EmulationForBhyve Thanks, Alex On Tue, Aug 18, 2015 at 2:05 PM, Alex Teaca wrote: > Hi, > > I've measured the performance of the NE2000 implementation. I will update > the project wiki page with the results I've got. > > 2 commits related with the software reset state: > - redesign the emulation of the CR register > - implement the software reset workaround, and the software reset routine > Practically, they've fixed a bug, because the emulator was able to receive > traffic when the interface was down. From now on the packets are dropped. > > Started to research on the ISA attachment of the ne2k emulation. > > Thanks, > Alex > > > On Thu, Aug 6, 2015 at 12:29 AM, Alex Teaca > wrote: > >> Hi, >> >> - handle the received multicast traffic >> - accept the frames in the Promiscuous mode for the destination >> addresses that do not match the station's address >> >> Thanks, >> Alex >> >> >> >> On Wed, Jul 29, 2015 at 7:08 PM, Alex Teaca >> wrote: >> >>> Hi, >>> >>> - I've added support for the read-only registers from the page0 >>> - handle the monitor mode of the NIC >>> - lock the reception flow with the .pe_barwrite and .pe_barwrite flows >>> >>> At the moment I am going to handle the multicast traffic and promiscuous >>> mode. >>> >>> Thanks, >>> Alex >>> >>> >>> On Sat, Jul 11, 2015 at 12:27 PM, Alex Teaca >>> wrote: >>> >>>> Hi, >>>> >>>> I've implemented the reception protocol of the NE2000 nic card. In >>>> order to test it, I send in both directions (from guest to host and from >>>> host to guest) big files (about 350M) >>>> and it works without any problems. >>>> >>>> At the moment, I want to implement a mechanism to lock the access on >>>> the shared resources between the tx and rx flows. >>>> >>>> Thanks, >>>> Alex >>>> >>>> >>>> >>>> On Sun, Jun 28, 2015 at 7:16 PM, Alex Teaca >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> From the last status report: >>>>> >>>>> implement 2 commits: >>>>> - parse the input string parameter and get the tap name and mac >>>>> address from it >>>>> - implement some logging and asserts related with the receive buffer >>>>> ring >>>>> >>>>> Also, I start to think about the receive protocol which is the next >>>>> step of the implementation by reading the specification from the datasheet >>>>> and understanding the implementation of the ED driver regarding the >>>>> way it receives packets from the NE2000 memory. It is pretty clear >>>>> what we need to implement and after a short design I will be able to >>>>> implement. >>>>> >>>>> Thanks, >>>>> Alex >>>>> >>>>> >>>>> On Sun, Jun 14, 2015 at 11:37 PM, Alex Teaca < >>>>> ionutalex.teaca@gmail.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> At the moment I am able to configure an IP address on the network >>>>>> interface corresponding to the NE2000 NIC. When I ping >>>>>> to the host IP, the tcpdump catches both ARP Request (sent by the >>>>>> guest using the NE2000 card) and an ARP Reply >>>>>> sent by the host OS. So, there is implemented the transmission >>>>>> protocol. For reception, the packets are only read >>>>>> from the tap device when it is notified by the mevent mechanism. >>>>>> >>>>>> For mode details, see the commits. >>>>>> >>>>>> Thanks, >>>>>> Alex >>>>>> >>>>>> >>>>>> On Tue, Jun 2, 2015 at 7:45 PM, Alex Teaca >>>>> > wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I've started the implementation of the NE2000 module. At the moment >>>>>>> the ED driver is able to probe the emulated device (RealTek 8029) and add >>>>>>> it as a network interface. >>>>>>> >>>>>>> Some of the features which are implemented: >>>>>>> - implement some logging support >>>>>>> - clone the /usr/src/sys/dev/ed/if_edreg.h register interface from >>>>>>> the ed driver into the bhyve tree sources >>>>>>> - implement the NE2000 registers support and an API to access the >>>>>>> NIC registers (get and set by offset) >>>>>>> - design and implement the Remote DMA protocol so the ED driver can >>>>>>> store and load from the NIC's RAM memory >>>>>>> >>>>>>> Thanks, >>>>>>> Alex >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From owner-soc-status@freebsd.org Mon Aug 24 12:53:22 2015 Return-Path: Delivered-To: soc-status@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4CECD9C08AC for ; Mon, 24 Aug 2015 12:53:22 +0000 (UTC) (envelope-from roam@ringlet.net) Received: from nimbus.fccf.net (nimbus.fccf.net [77.77.144.35]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6901369 for ; Mon, 24 Aug 2015 12:53:21 +0000 (UTC) (envelope-from roam@ringlet.net) Received: from straylight.m.ringlet.net (unknown [46.233.30.128]) by nimbus.fccf.net (Postfix) with ESMTPSA id 5F728764 for ; Mon, 24 Aug 2015 15:53:12 +0300 (EEST) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 2543708 by straylight.m.ringlet.net (DragonFly Mail Agent v0.9); Mon, 24 Aug 2015 15:53:11 +0300 Date: Mon, 24 Aug 2015 15:53:11 +0300 From: Peter Pentchev To: soc-status@FreeBSD.org Subject: Final status report: ng_ayiya - an AYIYA Netgraph node Message-ID: <20150824125311.GA4751@straylight.m.ringlet.net> References: <20150620164531.GB2937@straylight.m.ringlet.net> <20150701162743.GA3137@straylight.m.ringlet.net> <20150803132622.GE3216@straylight.m.ringlet.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline In-Reply-To: <20150803132622.GE3216@straylight.m.ringlet.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 12:53:22 -0000 --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, The goal of this project is to create a Netgraph node that acts as a link between a socket (TCP, UDP, SCTP, ...) connection to an AYIYA server (for a start, the SixXS POPs) and a local network interface (for a start, one that can route IPv6 traffic). Wiki: https://wiki.freebsd.org/SummerOfCode2015/AYIYASixXSNetgraphNode Subversion: https://svnweb.freebsd.org/socsvn/soc2015/roam/ Testing: https://svnweb.freebsd.org/socsvn/soc2015/roam/README.txt?view=3Dco This is the final report for this project; the ng_ayiya node is ready for testing and, IMHO, for use with the SixXS AICCU tool. There is still quite some room for improvement, e.g. some fixes to the configuration and the shutdown of the AICCU tool, but the Netgraph AYIYA implementation is fully usable at least in the following scenarios: - run aiccu as a TIC+AYIYA client against the actual SixXS servers to operate a "real-world" SixXS IPv6-over-IPv4 AYIYA tunnel - run aiccu as a TIC+AYIYA client against a local TIC server from my Net-SixXS Perl distribution and a local AYIYA server from the ng_ayiya package (the GSoC product) - configure two ng_ayiya nodes, either by hand or using a helper script from the ng_ayiya package, as two sides of a local AYIYA tunnel The last couple of weeks of the GSoC work were mainly focused on the first two scenarios: using and testing the SixXS AICCU tool's operation against the real SixXS servers and against a newly-written ayiya_listen utility that waits for incoming UDP packets on port 5072 that have not been claimed by any established tunnel, figures out which of the configured tunnels the packet is for, sets up the Netgraph nodes for the tunnel's operation, and starts up an ayiya_resp instance for this tunnel to handle the initial packet and any more packets that have arrived before the Netgraph nodes have been configured. Again, there is some room for improvement there, especially with restarting the remote side of a tunnel, but this listener, along with the additional functionality of the ayiya_resp tool (read a packet from the listener and pass it on to the ng_ayiya node for processing) and the ng_ayiya node itself (inject a packet as if it had arrived over the wire), should be usable now. Due to quite some time mismanagement on my part, my mentor and I did not get to the step of performance testing aiccu+ng_ayiya vs. aiccu+tun during the GSoC timeframe as we had planned, but the functionality to do the testing should be in place now. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJV2xOzAAoJEGUe77AlJ98TiVYQAJHxQ5gSvLpVmBc9E7xa0lFQ V9g4qWPDC7s0/G4AyKf+2wGYcfFrrUl1FOG7Efg9pvvY0mlzw7rQlrBox0n04Bgb h+dsRLbReH94bvBWVDCvkbwZO2k1E+aCWZ5xP0M1KdXOTfer9pOo7WcIS6HffQz+ njPKz95jp+pBwkqSJCo03Y0TgbxQSOoB8VS70bBq33KUbDuoQMd2g29HlqWgWDfP z3J+kO3j3DeCbrcrNk/Vv9/jBHuVf+WytQxP9r/vzVf5s1E6kjOAFSmaaZQMza55 h7JGzq+fTBsbDfzbwczhCaqqaRj774UvEz3FMXcNUFOfQPX5ZhJpCPT/ftMBvnCP j2RRPoa2WWYRH2+OG06jWPUjcqAEPhPD1O2YRYWW/EE1LC3du/z3Ba8TvfuBMdQf ivbydwmbI47eEw2wNZEmr7ECW13ool73dW033R223aZZkDyFWXTc7H9ADiJVc9Jb z1cndvOB3wwVpGE62bTEhznJQ3o5eeoa0vzlxW1tF6YH6ml0Yffdcun8PDHLGJc9 gAuA+If/FZO3UdAAbG7LllGppVNcV1EgbI0sZOhqvCxEb1QG63jV7Ib0Duib+7bi MX/BgaTYg8yer9NNCaEm2RVsQveLgCekJmFx5rvtrBeaXmnUb9Wgc4oaolmCWL39 SyepLu2fnYk7Ms/dFbRb =p83J -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- From owner-soc-status@freebsd.org Tue Aug 25 13:40:24 2015 Return-Path: Delivered-To: soc-status@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 669CA9C2401 for ; Tue, 25 Aug 2015 13:40:24 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F8812A1 for ; Tue, 25 Aug 2015 13:40:23 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by qgeg42 with SMTP id g42so106701365qge.1 for ; Tue, 25 Aug 2015 06:40:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=tDzWRvIyNK4xtsyy1gCP+Y90cfm0ouyZNsGmlX7RtmI=; b=Lz3Uj/lWw+CGSazQ7Z7Or1NVIQdWD91dq+D1GyYZdKOiSHiU70NLBVF9OyqAnmKEjM IAxg3WdM9h74sUwmTDv/fgi6qA7bC3u1A3vmc7PUUjI4gkD1KMEdg5LGPXxIs5e6a83L brAx8C3x1+BzvzdYTyJH7Kww7ujN1+cjPhlaoAwKSQStxOzL82PndW8XzQecxIsi1epP ykBtpYcRmxh3kovilCKTXyIrqmqKgKlqUoFEQ2W+NZZ+wLfbuGmOcBBzJ/4z9caw96rg zV02EBGCp0j+M9/CtRL7CTbVycA2d5qlq1jT4gwdEkI5eDMnZAJKeXDd7azXsZEAhivi gbow== X-Gm-Message-State: ALoCoQmijwFPVbG6d3KX+9A4v2RYkQzt5qUMOjxeaLw+cKZXWzTjE3ePJucAETBQmsuo+CeX8Py9 MIME-Version: 1.0 X-Received: by 10.140.235.3 with SMTP id g3mr70324415qhc.56.1440510017192; Tue, 25 Aug 2015 06:40:17 -0700 (PDT) Received: by 10.55.167.5 with HTTP; Tue, 25 Aug 2015 06:40:17 -0700 (PDT) Date: Tue, 25 Aug 2015 15:40:17 +0200 Message-ID: Subject: FreeBSD libc security extensions - final status From: Oliver Pinter To: soc-status@freebsd.org Cc: Pedro Giffuni , Oliver Pinter Content-Type: text/plain; charset=UTF-8 X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 13:40:24 -0000 Dear All! This is the final status report of the "FreeBSD libc security extensions" project. My mentor is Pedro Giffuni. Since the first milestone, we decided to change the scheduling, and focus more on fixing the FORTIFY_SOURCE with clang and on the FORTIFY_SOURCE triggered errors both in base system and in ports. In overall, we have a good advance, and we added the following fortified functions: sys/poll.h related: int __poll_chk(struct pollfd *, nfds_t, int, size_t); int __ppoll_chk(struct pollfd *, nfds_t, const struct timespec *, const sigset_t *, size_t); sys/socket.h related: ssize_t __recvfrom_chk(int, void *, size_t, size_t, int, struct sockaddr * __restrict, socklen_t * __restrict); sys/stat.h related: extern mode_t __umask_chk(mode_t); stdio.h related: char *__fgets_chk(char *, int, FILE *, size_t); size_t __fread_chk(void * __restrict, size_t, size_t, FILE * __restrict, size_t); size_t __fwrite_chk(const void * __restrict, size_t, size_t, FILE * __restrict, size_t); int __sprintf_chk(char * __restrict, int, size_t, const char * __restrict, ...); int __vsprintf_chk(char * __restrict, int, size_t, const char * __restrict, __va_list); int __snprintf_chk(char * __restrict, size_t, int, size_t, const char * __restrict, ...); int __vsnprintf_chk(char * __restrict, size_t, int, size_t, const char * __restrict, __va_list); string.h related: void *__memccpy_chk(void *, const void *, int, size_t, size_t); void *__memchr_chk(const void *, int, size_t, size_t); void *__memcpy_chk(void *, const void *, size_t, size_t); void *__memmove_chk(void *, const void *, size_t, size_t); void *__memrchr_chk(const void *, int, size_t, size_t); void *__memset_chk(void *, int, size_t, size_t); char *__strcat_chk(char *__restrict, const char *__restrict, size_t); char *__strncat_chk(char *__restrict, const char *__restrict, size_t, size_t); char *__stpcpy_chk(char *, const char *, size_t); char *__stpncpy_chk(char * __restrict, const char * __restrict, size_t, size_t); char *__stpncpy_chk2(char * __restrict, const char * __restrict, size_t, size_t, size_t); char *__strcpy_chk(char *, const char *, size_t); char *__strncpy_chk(char *, const char *, size_t, size_t); char *__strncpy_chk2(char * __restrict, const char * __restrict, size_t, size_t, size_t); size_t __strlcpy_chk(char *, const char *, size_t, size_t); size_t __strlcat_chk(char * __restrict, const char * __restrict, size_t, size_t); size_t __strlen_chk(const char *, size_t); char *__strchr_chk(const char *, int, size_t); char *__strchrnul_chk(const char *, int, size_t); char *__strrchr_chk(const char *, int, size_t); strings.h related: void *__bcopy_chk(void *, const void *, size_t, size_t); void *__bzero_chk(void *, int, size_t, size_t); char *__rindex_chk(const char *, int, size_t); unistd.h relared: char *__getcwd_chk(char*, size_t, size_t); ssize_t __pread_chk(int, void *, size_t, off_t, size_t); ssize_t __read_chk(int, void *, size_t, size_t); ssize_t __readlink_chk(const char *, char *, size_t, size_t); ssize_t __readlinkat_chk(int, const char *, char *, size_t, size_t); All of these implementation have tested with clang and with gcc-4.2. I tested on amd64 with both clang and gcc, and Pedro tested with "make tinderbox". We asked a exp-run from ports guys. During these tests we observed some build environment problem[1], badly written codes and real buffer overflows. All of these have patches or PRs. exp-run: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202311 PRs: editors/emacs* - misused umask() parameter - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202574 mail/ifile - broken #undef __OPTIMIZE__ - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202572 net-p2p/namecoin - broken code - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202603 libdtrace - buffer overflow - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201657 Fixes: hyperv tools - uninitialized parameter - https://github.com/freebsd/freebsd/commit/4485ab4d3d63c821390eecb708c6ba6bfccdbe8f sys build framework[1] - badly passed compiler parameter - https://github.com/freebsd/freebsd/commit/057f55aa4b0390ec8926744ec9dbac8dde9dfa99 wall, syslogd - buffer overflow - https://github.com/freebsd/freebsd/commit/8597d814df1fcc6d7e612a9da2dfc99025f98867 TODO: * Create a user friendly error reporting, when the FORTIFY_SOURCE catches an error. Currently it just kill the program, and add not too verbose error line to syslog. We have asked Ed Master about using the execinfo stuff in libc, but he does not answered till yet. * Create a proper man page about fortify_source. Last, but not least I like to say thanks to my mentor Pedro, for the helps and test! From owner-soc-status@freebsd.org Thu Aug 27 09:59:38 2015 Return-Path: Delivered-To: soc-status@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF8069C31C5 for ; Thu, 27 Aug 2015 09:59:38 +0000 (UTC) (envelope-from btw@mail.ustc.edu.cn) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 48456D8B; Thu, 27 Aug 2015 09:59:36 +0000 (UTC) (envelope-from btw@mail.ustc.edu.cn) Received: from dell.my.domain (unknown [110.77.7.5]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygAXFfl2395VEuKTAA--.1033S2; Thu, 27 Aug 2015 17:59:32 +0800 (CST) From: Tiwei Bie To: soc-status@freebsd.org Cc: hiren@FreeBSD.org, rwatson@FreeBSD.org, gnn@FreeBSD.org Subject: Multiqueue testing project - final status report Date: Thu, 27 Aug 2015 17:59:23 +0800 Message-Id: <1440669563-38392-1-git-send-email-btw@mail.ustc.edu.cn> X-Mailer: git-send-email 2.4.6 X-CM-TRANSID: LkAmygAXFfl2395VEuKTAA--.1033S2 X-Coremail-Antispam: 1UD129KBjvdXoW7Gr4xtF45Cr47uFy7Kw13twb_yoWkGFX_u3 4jg3WDWw4UZayagr45tr45ta9rK3y8KFn7Aa10qFs5G34rJrsxWFZ3uF90vF1ruw4Y9r9x G3srta4agw1jgjkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbFkYjsxI4VWDJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z2 80aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAK zVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx 8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMxAIw28IcxkI7VAKI48JMxC20s02 6xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_Jr I_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v2 6r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj4 0_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWU JVW8JbIYCTnIWIevJa73UjIFyTuYvjxU2YiiDUUUU X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQcOAVQhmDWvGgAQs0 X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 09:59:38 -0000 Dear All! This is the final status report of the Multiqueue Testing Project. The aim of this project is to design and implement an infrastructure to validate that a number of the network stack's multiqueue behaviours are as expected. The deliverables of this project mainly consist of: - A general mechanism to collect the per-ring per-cpu statistics which can be used by all NIC drivers, and the extended netstat(1) which can report these statistics. - A suite of network stack behavior testing programs which consists of (a) a virtual multiqueue ethernet interface (vme), (b) a UDP packet generator based on vme, (c) a UDP server based on socket(2), (d) a TCP client based on lwip and vme, (e) a TCP server based on socket. At present, most parts of this project have been implemented. Few parts have been committed to -HEAD, and other parts have been submitted to Phabricator. Now, I'm also working on improving the IPv6 RSS supports with the help of adrian@. ^_^ Finally, I want to say thank you to my mentor Hiren, George and Robert, for the helps and guidance! ^_^ Many thanks! Best regards, Tiwei Bie From owner-soc-status@freebsd.org Fri Aug 28 13:18:38 2015 Return-Path: Delivered-To: soc-status@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B4DD9C4E61 for ; Fri, 28 Aug 2015 13:18:38 +0000 (UTC) (envelope-from mdw@freebsd.org) Received: from mehl.mmap.at (static.56.42.47.78.clients.your-server.de [78.47.42.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E988D7C; Fri, 28 Aug 2015 13:18:37 +0000 (UTC) (envelope-from mdw@freebsd.org) Received: from [10.0.0.108] (178-191-93-71.adsl.highway.telekom.at [178.191.93.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mehl.mmap.at (Postfix) with ESMTPSA id 7D7BCB069F; Fri, 28 Aug 2015 15:18:29 +0200 (CEST) Message-ID: <55E05FA4.90907@freebsd.org> Date: Fri, 28 Aug 2015 15:18:28 +0200 From: Manuel Wiesinger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: soc-status@FreeBSD.org Subject: Final status: Linux packages for pkg(8) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 13:18:38 -0000 Hi, Fully integrating my code into pkg(8), was unfortunately not entirely possible, within the scope of this years summer of code. The architecture to install packages is very specific and tailored for binary packages (i.e. common FreeBSD-packages). Changing huge parts of an existing software architecture requires lots of discussion. That was not possible in time. I think it would have made little sense to spend much time to get it working in a hackish way, that is ugly and thus useless in the end. For this reason I mocked many functions in accordance with bapt@ and created a very detailed list of suggested changes, to abstract functions so that they are repo specific. This list was was mailed to bapt@ for evaluation. Of course, it is important to me to fully integrate my code into pkg(8) and make it a part of FreeBSD. I will work through my list of suggestions stepwise and open pull requests on Github. This way discussion will take place regardless of the availability of upstream developers. I hope in the end this will highly simplify the development for other package types, such as RPMs (and conditionally even ruby-gems, etc.) There is fully working and fully integrated code for updating repositories, verifying the the manifests using gpg and for creating/deleting databases. There is mocked code for comparing package versions according to Debian's specification and to analyse, register and extract Debian-packages. This includes dependency and conflict parsing. This is basically all that is needed to use an official Debian repository. I spent a lot of time of to learn the ropes, and I want to use my gained knowledge to continue contributing to pkg(8). If possible I'll attend the EuroBSDcon in Stockholm and present what I have so far. Thank you for everything, Manuel From owner-soc-status@freebsd.org Fri Aug 28 18:21:10 2015 Return-Path: Delivered-To: soc-status@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F9969C53A3 for ; Fri, 28 Aug 2015 18:21:10 +0000 (UTC) (envelope-from cdlord2@illinois.edu) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 743BFCAE for ; Fri, 28 Aug 2015 18:21:09 +0000 (UTC) (envelope-from cdlord2@illinois.edu) Received: by igyq3 with SMTP id q3so18511838igy.1 for ; Fri, 28 Aug 2015 11:21:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=mGhoBRYk9lzSpYAt8eqlmIUbGK4eVaf9zER22VHRsfw=; b=Rwh4BpyeUVdIrjmWr5J1S6KeoHFC/hyCKcuENhVM/HI3h383N8qG+pw73OIBYmEz1X ZQgxTiMWWtpfH+Hf27LV+qwiKh2zPDU2DFlzbg/nNzx2VL09iKslKKmLbfBamia9Kfrm jz9v6KJB1l4daUEoqyoC64TdFOlF3w5lSVFwNoh6oL/6eTlzPYrPOdA03y3luKgmZplr OKBEZwpRuBFwwMwpZXUjPXcPuuZXHLPPsWhEksVu6OPkGrZAgKiY5Mc43nmvjSGGqSaM SVRacEM5Wz3EPW3doJjvcqaMCso3lDhFQxW9mOxuyTLpdhBaPpFjXNgy1Gpq3Xg5zBin obDA== X-Gm-Message-State: ALoCoQnsEw3bMgZFDE8ycIKGdjjUp3lHIadGdoAfHNZg+PYBZXUV6OffmDvDLXSZy989brvwm7n3 X-Received: by 10.50.98.1 with SMTP id ee1mr4806173igb.3.1440786069139; Fri, 28 Aug 2015 11:21:09 -0700 (PDT) Received: from [172.17.166.170] (mobile-130-126-255-161.near.illinois.edu. [130.126.255.161]) by smtp.gmail.com with ESMTPSA id 20sm4739004iof.18.2015.08.28.11.21.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Aug 2015 11:21:08 -0700 (PDT) Message-ID: <55E0A68B.2090606@illinois.edu> Date: Fri, 28 Aug 2015 13:20:59 -0500 From: "Colin D. Lord" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: soc-status@FreeBSD.org Subject: Update Ficl in Bootloader - Final Status Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 18:21:10 -0000 Hi everyone, Here's the current status of my project to update the Ficl version in the bootloader. When the summer began, I had two main goals for this project. The first was to get a working implementation of the bootloader running Ficl 4 in "compatibility mode", which would allow the FreeBSD Ficl customizations to carry over to Ficl 4, ideally without too much modification. The second goal was to remove the compatibility mode setting, which would require all of the FreeBSD customizations to be remade to use the Ficl 4 api. Turning off compatibility mode would offer the benefits of cleaner code and ease of future maintenance and understandability. I had initially expected to get a working bootloader by the middle of the summer. However, I hit many roadblocks and that timeline did not end up working out. While the bootloader currently builds, due to a bug related to the Ficl stack, it does not get very far through the boot process. So currently the Ficl 4 userland interpreter can be built and used, and the bootloader should build, but until the bug in Ficl is fixed, it will not run correctly. I expect the bootloader to work once that bug is fixed though. I put a few days of dedicated effort into finding the bug, but was unsuccessful in fixing it before time ran out. In a little more detail, the bug in the Ficl stack was that the stack simply did not grow, ie pushing an element, and then viewing the contents of the stack, resulted in the Ficl interpreter saying it had no items on the stack. While debugging, it appeared to me that while one item could be inserted, when accessing the item the pointer to the top of the stack would for some reason be reset to its initial value, making it appear as though the stack was empty. This bug also appears in the ports version of Ficl 4 (lang/ficl, port version 4.1.0_2), which is why we believe it is a bug in Ficl and not a result of a mistake while importing Ficl. The next steps therefore consist of fixing the Ficl stack to get a functioning loader, and then removing compatibility mode can be a consideration. Many thanks to Devin for helping me when I got stuck and providing guidance about all my questions, and also to Pedro for dropping in every once in a while to check on me. Colin From owner-soc-status@freebsd.org Sat Aug 29 21:01:20 2015 Return-Path: Delivered-To: soc-status@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F12939C5E4E for ; Sat, 29 Aug 2015 21:01:20 +0000 (UTC) (envelope-from gnn@freebsd.org) Received: from smtp.hungerhost.com (smtp.hungerhost.com [216.38.53.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE2FBB2E; Sat, 29 Aug 2015 21:01:20 +0000 (UTC) (envelope-from gnn@freebsd.org) Received: from 82-69-116-12.dsl.in-addr.zen.co.uk ([82.69.116.12]:63512 helo=[172.27.111.4]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1ZVmCj-0000SU-UE; Sat, 29 Aug 2015 15:54:22 -0400 From: "George Neville-Neil" To: "Tiwei Bie" Cc: soc-status@freebsd.org, hiren@FreeBSD.org, rwatson@FreeBSD.org Subject: Re: Multiqueue testing project - final status report Date: Sat, 29 Aug 2015 20:54:10 +0100 Message-ID: <3C4FC610-7052-4580-95CA-731097A15F92@freebsd.org> In-Reply-To: <1440669563-38392-1-git-send-email-btw@mail.ustc.edu.cn> References: <1440669563-38392-1-git-send-email-btw@mail.ustc.edu.cn> MIME-Version: 1.0 X-Mailer: MailMate (1.9.2r5107) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freebsd.org X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 21:01:21 -0000 On 27 Aug 2015, at 10:59, Tiwei Bie wrote: > Dear All! > > This is the final status report of the Multiqueue Testing Project. > > The aim of this project is to design and implement an infrastructure > to validate that a number of the network stack's multiqueue behaviours > are as expected. > > The deliverables of this project mainly consist of: > > - A general mechanism to collect the per-ring per-cpu statistics > which can be used by all NIC drivers, and the extended netstat(1) > which can report these statistics. > > - A suite of network stack behavior testing programs which consists > of (a) a virtual multiqueue ethernet interface (vme), (b) a UDP > packet generator based on vme, (c) a UDP server based on socket(2), > (d) a TCP client based on lwip and vme, (e) a TCP server based on > socket. > > At present, most parts of this project have been implemented. Few > parts have been committed to -HEAD, and other parts have been submitted > to Phabricator. > > Now, I'm also working on improving the IPv6 RSS supports with the > help of adrian@. ^_^ > > Finally, I want to say thank you to my mentor Hiren, George and Robert, > for the helps and guidance! ^_^ > Howdy, I've seen quite a few commits go by which is most excellent. Quick question, where are the tests? Did I miss those? Best, George