From owner-soc-status@freebsd.org Sun Jun 28 16:16:06 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 1F21098F348 for ; Sun, 28 Jun 2015 16:16:06 +0000 (UTC) (envelope-from ionutalex.teaca@gmail.com) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 E52F9198E; Sun, 28 Jun 2015 16:16:02 +0000 (UTC) (envelope-from ionutalex.teaca@gmail.com) Received: by oiyy130 with SMTP id y130so103904222oiy.0; Sun, 28 Jun 2015 09:16:02 -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=/TMg/KSzDQ07+kMq6SWwXPVwkLvBBmjSJih+Zs13KQ0=; b=o6poZ5fUJlKyVwIW6UGf1ONRVPr/az0wd30KPv2rHxMKIrL58XkG5ToyJl0Vtei+xD 1mSy4X+hcXOt37QksvV4w/EFX1Fv/KiDlTASJNaHeSUCr8SsPilPNtBJzaztG9Yk4S9Z UXPpO4HwV5kYPcZqlxTBiMJNSXxksIleOjJ5WWgfV4qvyg+m463oVhai85NynFZ00vwG XiA39pVb4GisPfLFRml7a1/RP22cBXzpwvau6AgcObWqNiKynB4G3n2gXv2oLZvqEc0p v5JvqPztj6nXrx1vmNu4Td3Y4O5EhoPuWUdAI3X4I88xTz89d7eaDT0efxCrtgkqKccd Qr5g== MIME-Version: 1.0 X-Received: by 10.182.24.97 with SMTP id t1mr10469756obf.32.1435508162060; Sun, 28 Jun 2015 09:16:02 -0700 (PDT) Received: by 10.76.84.37 with HTTP; Sun, 28 Jun 2015 09:16:02 -0700 (PDT) In-Reply-To: References: Date: Sun, 28 Jun 2015 19:16:02 +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, 28 Jun 2015 16:16:06 -0000 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 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 Tue Jun 30 13:56:13 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 BA97898E1A1 for ; Tue, 30 Jun 2015 13:56:13 +0000 (UTC) (envelope-from prasadjoshi.linux@gmail.com) Received: from mail-vn0-x22c.google.com (mail-vn0-x22c.google.com [IPv6:2607:f8b0:400c:c0f::22c]) (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 771331584 for ; Tue, 30 Jun 2015 13:56:13 +0000 (UTC) (envelope-from prasadjoshi.linux@gmail.com) Received: by vnbg129 with SMTP id g129so1649897vnb.3 for ; Tue, 30 Jun 2015 06:56:12 -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=bqZ80Yuikv8cQ4NVaGs6Bm2HL2DcnZWCqEklkkA5ZGU=; b=HV7gYUgcE4kH9uXX56NA6rTVAFFVqFz7HZ5f9HhrYozbRrFHFOdHKoLE9SINOV8wnu eB++i6bTmc1P9sY9rIN6iUC61wmeqrKvkL+1z9iKahP+GIpz/TdJ7CuaymT5F1THrmqG rgyFMazfFPIv9BwcQYBnv/NIMEa1EU9TALf4tMgXMAuIb2FoqzxIx8QjYlAOSpUGBYOF BSG0LtiAh6Xl0wp0JM9ILvNpmhL3BFymwYbL6CeTj75RuupRGUmTRqWBjLRp+uZgtbbH 8pEeHkKSX4RtyG6RNOYhzVLuB5Rx+tcxCXjt/vlQVRiareuMbwQd4v9RtEB40U6RcLtb +Osg== MIME-Version: 1.0 X-Received: by 10.52.189.75 with SMTP id gg11mr20048616vdc.27.1435672572466; Tue, 30 Jun 2015 06:56:12 -0700 (PDT) Received: by 10.31.190.76 with HTTP; Tue, 30 Jun 2015 06:56:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Jun 2015 19:26:12 +0530 Message-ID: Subject: Re: [gsoc15] dynamically discover bes From: Prasad Joshi To: soc-status@freebsd.org Cc: Xin LI 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, 30 Jun 2015 13:56:13 -0000 Week 5 Update - I did not work on GSoC for 3 days in this week. Had to attend full day sessions in the University. - Last week I was faced with a problem with booting alternate (non-active) BE. Plan in this week was to locate the problem. It seems like, during bootup zfsloader needs to initialize libzfs library. The libzfs library initialization fails because '/dev/zfs' cannot be opened. I verified the zfs kernel modules, which create the device are loaded. I think, and as suggested by mentor, I will have to set vfs.root.mountfrom environment variable during bootup. Thanks and Regards, Prasad On Mon, Jun 22, 2015 at 11:42 PM, Prasad Joshi wrote: > Week 4 update > > - I have been able to discover BEs on console. I could detect active BE. > Created list of BEs. Code to sort BEs on object number, name, or timestamp > is added. > > - I am able to boot from nonactive BE to some extent. At the moment, code > requires me to enter BE number to boot from. > > Tasks next week > 1. Identify a problem with be bootup. > 2. Pass mount point info through env variable to loader. > 3. Start with console based menu. > > Thanks and Regards, > Prasad > > On Jun 15, 2015 7:48 PM, "Prasad Joshi" wrote: >> >> Week 3 status >> ========== >> After understanding on disk representation of snapshots and clones, I >> have been able to find names of the BEs created using beadm command. I >> could print the BE names on console. >> >> The next task would be to convert BE names to object numbers, create >> list of BEs. >> >> Thanks and Regards, >> Prasad >> >> On Tue, Jun 9, 2015 at 6:36 AM, Prasad Joshi >> wrote: >> > Last week I mostly worked on understanding beadm and gptzfsboot code >> > >> > beadm create prepares new BE by creating a snapshot and clone of that >> > snapshot. beadm activate command sets bootfs property of the POOL. >> > bootfs property contains object number of active dataset object. >> > During bootup gptzfsboot probes all the disks, creating SPA for any >> > valid pool. gptzfsboot assumes the first pool it finds as a primary >> > pool, it then reads meta object set, then tries to find object nunber >> > of active dataset object either through >> > a. bootfs - it would be set if BE was already created >> > b. mos->properties_zap->root_dataset->dd_head_dataset_obj (through >> > root_datasets bonus buffer) >> > Once the object number is obtaind gptzfsboot mounts the dataset. >> > >> > After mounting, few files are looked up like /boot/config or >> > /boot.config for presense of boot command (did not went into details >> > of this). Then (if keyboard is not hit), gptzfsboot execs >> > /boot/zfsloader. If gptzfsboot is interrupted by keyboard, then it >> > displays default BE or POOL it is trying to boot from (using >> > zfs_rlookup() to map active dataset object to string BE name). Though >> > I haven't checked this but through serial console user would be >> > allowed to enter other pool or BE to boot from. >> > >> > I could not go into details of how gptzfsboot reads /boot/zfsloader from >> > disk. >> > >> > Pending Tasks >> > ============= >> > 1. Understand upon keyboard interruption, how user entered zfs paths >> > (format [zfs:pool/filesystem:][/path/to/loader]) are converted in >> > object numbers? >> > 2. Learn ZFS on disk format in more details so as to identify active >> > dataset object numbers of all BEs. Once the object numbers are >> > available, I can use zfs_rlookup() function to map object number to >> > printable pool name. >> > 3. Prepare library for console based menu. >> > >> > Plan for next week >> > ================== >> > Pending task 2 above From owner-soc-status@freebsd.org Wed Jul 1 11:49:08 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 2724898DD23 for ; Wed, 1 Jul 2015 11:49:08 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (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 B48171663 for ; Wed, 1 Jul 2015 11:49:07 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: by wguu7 with SMTP id u7so34469241wgu.3 for ; Wed, 01 Jul 2015 04:49:06 -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 :content-type; bh=RuuAxhZIsTJ/Uc0Q5KOYGnyMJ8JVIpDGMbgJndJkJ+E=; b=vuP4Dx/RW0P6ValaOGk2/5CeunkNDGMurmv8IyKmrvdjM1Nkcp52xBuHxGcKgVDJAw PeeHLUMlSXfS79DC8zzTaWMq/+Pzw3wCFFITlIsIhgup+uzP8wfOpnGM4IxIiQkPi9BX x+o7jpckVRQX1inSRQG9dM+eG8H2rZ/Fr32laYlMG/YcjpKK2C6TcfJGilgvjYsQH8Xo Mdt/CFoiwhJwRi547YH8emCiCQw3ZwB+hpj4qpH2o9akvgF1/wzGQe9za3MKE1xy1b2f AoqmEDRRHvCpinX+8OOU/niYdOMEe+LqTIovq5ajG/opddozn+FAkAhM1JlaH0DqYhPo E0eg== MIME-Version: 1.0 X-Received: by 10.195.11.168 with SMTP id ej8mr48591223wjd.150.1435751346178; Wed, 01 Jul 2015 04:49:06 -0700 (PDT) Received: by 10.28.21.134 with HTTP; Wed, 1 Jul 2015 04:49:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Jul 2015 14:49:06 +0300 Message-ID: Subject: Re: [GSOC] bhyve port on ARM - weekly status report From: Mihai Carabas To: soc-status@freebsd.org 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: Wed, 01 Jul 2015 11:49:08 -0000 Hi everyone, Sorry for the late weekly status report. > Further I've written an initialization code for HYP mode, installing a > stub handler for HYP exception for platforms that have support for this. > The stub handler permits changing the exception vectors. Later, when the > vmm module will be loaded, the handler will be replaced by a fully fledged > one which will take care of VM context switch and various exceptions. [2] > > In the last week I copied the vmm code from amd64 platform and I stripped it down to only basic operations (vmm init/cleanup, vminit/cleanup and vmrun). I've written some code for mapping operation [1] (PL-2 stage1 and PL1 stage-2 - combined) for LPAE format (this is the only format supported in HYP-mode). Unfortunatelly the FreeBSD pmap code doesn't support LPAE format and I couldn't integrate memory management in the PMAP infrastructure (like it is currently in amd64 - this will be handled after this basic implementation because is an entire project that needs to be tackled). I've also been writing the low-level initialization code for the hypervisor to replace the stub code installed at boot time. Right now we are able to insert the vmm-arm.ko module which performs all the necesary initialization (installs the new exception vector, activates the MMU). When we remove the vmm-arm module the stub exception vector is reinstalled and the MMU deactivated, bringing the host to the initial state. Thank you, Mihai [1] https://svnweb.freebsd.org/socsvn/soc2015/mihai/bhyve-on-arm-head/sys/arm/vmm/mmu.c?view=markup From owner-soc-status@freebsd.org Wed Jul 1 16:28:12 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 ADDE899236C for ; Wed, 1 Jul 2015 16:28:12 +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 6F6261FC5 for ; Wed, 1 Jul 2015 16:28:08 +0000 (UTC) (envelope-from roam@ringlet.net) Received: from straylight.m.ringlet.net (87-126-10-54.btc-net.bg [87.126.10.54]) by nimbus.fccf.net (Postfix) with ESMTPSA id 86B5D9D0 for ; Wed, 1 Jul 2015 19:27:59 +0300 (EEST) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 254035c by straylight.m.ringlet.net (DragonFly Mail Agent v0.9); Wed, 01 Jul 2015 19:27:43 +0300 Date: Wed, 1 Jul 2015 19:27:43 +0300 From: Peter Pentchev To: soc-status@FreeBSD.org Subject: Re: Status report: ng_ayiya - an AYIYA Netgraph node Message-ID: <20150701162743.GA3137@straylight.m.ringlet.net> References: <20150620164531.GB2937@straylight.m.ringlet.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <20150620164531.GB2937@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: Wed, 01 Jul 2015 16:28:12 -0000 --huq684BweRXVnRxX 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 The major change in week 5 was that the Netgraph node now forwards all the "unusual" packets received from the AYIYA server to a userland application, and also signs and forwards any AYIYA packets received from the application to the remote server. This allows userland programs to take care of all the non-IPv6-forwarding aspects of the AYIYA protocol, such as: - sending periodic "heartbeat" packets to the server to let it know that we are still alive even if there has been no forwarded traffic (nobody is really using the IPv6 tunnel) - sending various queries to the server to figure out who we are talking to (operating system, software version, etc) - replying to such queries received from the server - handling a server's "message of the day" packet that, by specification, should be displayed to the operator who brought the tunnel up I also added a sample configuration file describing a tunnel between two IPv4 addresses in the RFC 1918 space, so it would be even easier to test the Netgraph AYIYA node - the testing scaffold may be run on two hosts in the local network to bring up a ng_ayiya node and an IPv6 interface on each host. In the documentation department, a ng_ayiya.4 manual page is also present now and will be installed once the kernel module source is turned into a FreeBSD port. With these changes, and with the assorted minor bugfixes and cleanup that also happened this week, I believe that the ng_ayiya node is functionally complete and ready for testing and optimization. Thus, in the next week I'll try to teach the SixXS AICCU tool to bring up and use the Netgraph node instead of a gif interface as it does now. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 --huq684BweRXVnRxX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVlBT6AAoJEGUe77AlJ98TrfgQAIELVwPgc6e6cBnrk1IJYPF/ voBTZydExvDPC+bx+8em3KFjUCJ9KlH0B4ta6lLf9iVdbTmbuL+0/pjIikyD+9bq luSH0GsvV37Eqn2A6WFxCz9Y19zebo+02P7WNpVjeE+1FAEP/1ZqTc0O+m9jqY1M 4/LsMglEuB3xFpHM6cmWuTly0Lo62Rz7HXsf0kbpJufr4FAd73Iyj5tGho0GSfzA CGXM+CGnZp/CiyLThq9NFv8m1dhjFnST4bswLwIQKn0PznKkUc4AAPwMoHzV2pxt 9uKC66jY5T3J+Jv/7DAvjkV4CWvjjwx+BvuxFJILjxFr6YWnp6Nu49uGtTOj0T7+ yqDXZHdKeWeEq+68t7C7EMDqqTAqb1Ln2NQ7gWKIeaLnsaKvgP8fBsT7+7dli7TE fWSVJBfszuhrKDooCZDZo2XD6CWUZU4Zet80s6FYxSFL8La2BhuMewsWVB9ox0Co ErqB4NJIU1disKtWHkOya+8nqDywQ/8pzWjW7oppusdFNj+UFoKhE/mle8r+58kT Ic6i7AZQUxbT+34LDqz0C9iCFlcLk4MCdDh9X+UgMKlbm3+8ZYzw8BKwiEf6iYYF KtwBYstNCuzUUOUuzB7zbbNrHzTS7dPOVFlQfTODdSzDyhwDW321Wh+1FBN/f+Fq sV8l1UVzf+06PnjWAGri =Sx36 -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- From owner-soc-status@freebsd.org Wed Jul 1 20:26:11 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 13AC09924B3 for ; Wed, 1 Jul 2015 20:26:11 +0000 (UTC) (envelope-from kczekirda@gmail.com) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (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 D29792575 for ; Wed, 1 Jul 2015 20:26:10 +0000 (UTC) (envelope-from kczekirda@gmail.com) Received: by obdbs4 with SMTP id bs4so36167965obd.3 for ; Wed, 01 Jul 2015 13:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=pg8vBrP8OaMB196e8BqZF9el8wvY5kPimHy7FvnrY8c=; b=oCxlprXc4bI1ZRLoi5w1Tsil1OipdQmDl/kE/mvA5UhZmduoAH+cqnlMxx7aldWjEb 8BNVgOfJbR2byhmmBAYTueG4YSJ51AV15/pm07hF2Lg0c5QZxvyxuhbDtszrcJR2XqAC hFKFo8/plaWTyw5oEnDL3vLNAgx711K30HTYHyU0sza5ZFiHfrl4lmyFeQe3uh4p9IZ5 vJ6xet0ffTQGZMcrAL0fBOWS1Hzl3Srnj2Q4C4+0KEPvQOLUfjv6/7gjKOfYmMLKmlhD qd5wGddAC9kMXPuoZK6whEsOvOndYa0hIB7+G/SVCawqrnOQjrtWBESibuQROZKwHcI/ O5OA== X-Received: by 10.182.80.68 with SMTP id p4mr25573050obx.46.1435782369945; Wed, 01 Jul 2015 13:26:09 -0700 (PDT) MIME-Version: 1.0 Sender: kczekirda@gmail.com Received: by 10.76.37.134 with HTTP; Wed, 1 Jul 2015 13:25:40 -0700 (PDT) From: Kamil Czekirda Date: Wed, 1 Jul 2015 22:25:40 +0200 X-Google-Sender-Auth: 8SKQvhRo3AA-HuYX6dYs1YbVYwk Message-ID: Subject: Weekly status #5 To: soc-status@freebsd.org 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: Wed, 01 Jul 2015 20:26:11 -0000 Hi, My infrastructure can build releases, I can boot mfsBSD on nodes using sanboot from ipxe. In next step the node mounts /usr/src and /usr/obj from my local FreeNAS storage by NFS protocol. At this moment I have to manually decide what to boot by iPXE menu, but I'm working on automation on server. I don't follow my schedule, decided to do some tasks from next steps and then come back and finish for example booting from NFS by iPXE, but I'm not sure I really need this. Regards, Kamil