From owner-freebsd-hackers@freebsd.org Sun May 15 14:32:34 2016 Return-Path: Delivered-To: freebsd-hackers@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 27C39B391F3 for ; Sun, 15 May 2016 14:32:34 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id E76851283 for ; Sun, 15 May 2016 14:32:33 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [172.16.0.5] (unknown [172.16.0.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 80CCC148E for ; Sun, 15 May 2016 14:32:27 +0000 (UTC) Subject: Update on EFI work: refactoring ready for testing, GELI coming very soon From: Eric McCorkle Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (13D15) Message-Id: Date: Sun, 15 May 2016 10:32:26 -0400 To: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 14:32:34 -0000 Hello everyone, I've been working on a rather significant refactoring of the EFI boot/loader= code. While this was originally in support of adding GELI support, it has g= rown to such a scope that it could be considered a patch in its own right. The branch containing my work can be found here: https://github.com/emc2/fre= ebsd/tree/efize The following is a summary of the changes: * Both boot1 and loader have been redesigned to look for instances of EFI_SI= MPLE_FILESYSTEM_PROTOCOL and load using that interface. In loader, this is a= ccomplished through a new synthetic filesystem driver (called efifs) that is= just a wrapper around EFI_SIMPLE_FILESYSTEM_PROTOCOL. In boot, this is ach= ieved by calling the interface directly. * The efipart and filesystem back ends (including ZFS) have been moved into a= drivers directory, where they have been wrapped up into a filesystem backen= d driver that does the same probing that loader does today, and then install= s an EFI_SIMPLE_FILESYSTEM_INTERFACE on all device handles that host support= ed filesystems. This interface is a wrapper around the filesystem interface= currently used by loader. * boot now uses the same filesystem backend code as loader. This increased i= ts size, necessitating recreation of the FAT templates. The old boot filesy= stem code and boot modules have been discarded. * loader can use any protocol interface installed by boot just fine. These r= emain valid until ExitBootServices is called. Moreover, the probing process= is idempotent, and is run by both boot and loader, with the first one to ru= n actually installing the interfaces. * I had originally hoped to move the entire code base to use the EFI driver m= odel, which would support hotplugging devices. However, the new bcache stuf= f currently requires that all devices be statically detected before the cach= es are used, which is fundamentally incompatible with this way of doing thin= gs. This was the sole blocker of such a transition (the handles.c code requ= ires some minor modification as well, but nothing problematic) * I had also considered altering the device name code to use textual represe= ntations of EFI device paths, but I don't see any real reason for doing so. * I have not touched efinet or nfs in this changeset. The rationale for these changes is as follows: * The model of looking for EFI_SIMPLE_FILESYSTEM_PROTOCOL instances and usin= g them to load things increases interoperability with other systems. For ex= ample, the new boot and loader would work just fine with interfaces installe= d by GRUB or another boot loader, or perhaps custom filesystem modules added= into an open-source firmware implementation like coreboot. * This model works really well for functionality like GELI or custom partiti= on schemes that potentially create new devices. All you do is create one or= more new device nodes, attach device paths and block io interfaces, and cal= l ConnectController on them (for now, it's necessary to make sure the fs_dri= ver runs AFTER) all new nodes have been created. This also vastly simplifies= passing information between stages about filesystems and devices (this is i= mportant for GELI). * This approach can leverage drivers that are mandated by the EFI spec, like= the GPT partition driver. This avoids reimplementing such a driver to supp= ort partition schemes nested inside GELI volumes, for example. * This model provides most of the groundwork for supporting hot plugging of d= evices at boot time. All that is required at this point is a refactoring of= bcache to support adding new devices dynamically (I had to draw the line so= mewhere, and this had already gotten big enough, and I want to focus on GELI= support) * Getting rid of the duplicated and minimized filesystem code in boot1 impro= ves maintainability. Indeed, the actual boot1 code is quite small now. Some notes and future work: * In general, the FreeBSD loader framework and the EFI framework do many sim= ilar things. For the most part, there is a fairly direct mapping, though EFI= interfaces tend to be more tedious. The one thing EFI does decidedly bette= r is support dynamic detection of devices (hotplugging). * There are some interesting possibilities for hotplugging beyond just the o= bvious. For example, loading GELI or other keys off of hotplugged USB stick= s. * I didn't touch efinet or nfs on this patch. It is certainly possible to e= fize them as well, but I don't have a test setup for doing so (or frankly, t= he motivation to do so). * It might make more sense to use the EFI_LOAD_FILE_PROTOCOL to do the actua= l loading, as some applications support this without supporting a full files= ystem interface (some embedded devices do this, as do some network boot prot= ocols). However, this would involve changing the non-EFI boot code and inte= rfaces, which is something I specifically wanted to avoid in this work. This changeset can be tested as is, and should just work. Disclaimer: I reb= ased it to head yesterday, and haven't had time to build and test it yet, bu= t I will. I know it works with ZFS, but I have no UFS systems on which to t= est that functionality. If you intend to test this, I STRONGLY recommend installing an EFI shell on y= our ESP, and then installing the modified boot block under something like bo= ot.tst. This will allow you to run the modified boot block, but fall back t= o a working boot if it fails. Also, I had modified the loader path to /boot= /loader.tst for similar reasons, and it may still be set to that in the code= . I am currently adding GELI support as a proper EFI driver, and should be com= ing in the very near future (the code is already written, in fact). If anyo= ne wants to test the refactoring by itself, any results or comments are cert= ainly appreciated.= From owner-freebsd-hackers@freebsd.org Sun May 15 16:01:00 2016 Return-Path: Delivered-To: freebsd-hackers@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 97DEAB3C970 for ; Sun, 15 May 2016 16:01:00 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 2204A1B40 for ; Sun, 15 May 2016 16:01:00 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-wm0-x235.google.com with SMTP id e201so74974640wme.0 for ; Sun, 15 May 2016 09:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=JIazMmnoKT8IQBm+Y/Rd6YaE/qh6TY50UAoKNHScYLI=; b=llqgj2UiPO0nFmCr5oSQwuyv5e2JfVR5Hc7KJk+3IKAzfl6gD1w801Cg2ERfG84rCz eYLFzF6AkUXG3nKAMCKlpjS7T40e+gO2EjDSVvmrPiab2Q+6rHLrT84mQw+cwHlEp87j tGiEphlUs0Z7ymGB8/bVvy3/JHNMbiPo3OsHoEuSg2HjSgw9c6N9U7CGBF94/4B82W35 ssjQnOlVsi/rqKmVAVgGt2h9tnPvrYW5hfcs9aI5Xu37rt+Zvglj8zpurjgj32fykdDr eTYfLTkfCsytv5sYaiXKmgG591I4ZVnRKwKvbjqJJzTyx5l6b8Qi24y2XoncU8JGdMQt bzng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=JIazMmnoKT8IQBm+Y/Rd6YaE/qh6TY50UAoKNHScYLI=; b=RUCJH/v5Sbw2gOL9FMjyXJoeLe2+YaMn1Vk1ghN5kSE0v6eGW0iPVYD3UENP5Ht1Fb v9LAn0xGsDOrx32BHWbmLPIHvvBQKKhRFFooOT7roiotg8XgfOAvU8f0SDz0IjW4AttM grzc/k+0MZsQxpIkSTJox6ijzkjqPIXHcnTR6qN9yKwtYnebvMnfRep1tYbwlooyppbT +cVx42jQDV/La/tZ9N4XNNjRDIfnwHnaS6+DorkEsvlhOwcah5tA1oyaejpjTc6cafIm RZvkvkG1fqadZrNCYYqPeGbjesl0CtiRslGv0mTM1DhCj+ZQPN+/mBC7SW75qmO90YLO IUlA== X-Gm-Message-State: AOPr4FXTqship3IEYDRvsnPGnsVASC9aKAefYoF1C3dLzRuMMGXr+SsZZ1F2voIUpE+M7oazxUX2uQ6C/+F2l14g MIME-Version: 1.0 X-Received: by 10.194.220.230 with SMTP id pz6mr24335318wjc.93.1463328058733; Sun, 15 May 2016 09:00:58 -0700 (PDT) Received: by 10.194.30.35 with HTTP; Sun, 15 May 2016 09:00:58 -0700 (PDT) In-Reply-To: References: Date: Sun, 15 May 2016 18:00:58 +0200 Message-ID: Subject: Re: Update on EFI work: refactoring ready for testing, GELI coming very soon From: Oliver Pinter To: Eric McCorkle , nao@enuenu.org Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 16:01:00 -0000 Hi Eric! Could you please take a look at this PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940 This feature would be nice too. On 5/15/16, Eric McCorkle wrote: > Hello everyone, > > I've been working on a rather significant refactoring of the EFI boot/loader > code. While this was originally in support of adding GELI support, it has > grown to such a scope that it could be considered a patch in its own right. > > The branch containing my work can be found here: > https://github.com/emc2/freebsd/tree/efize > > The following is a summary of the changes: > * Both boot1 and loader have been redesigned to look for instances of > EFI_SIMPLE_FILESYSTEM_PROTOCOL and load using that interface. In loader, > this is accomplished through a new synthetic filesystem driver (called > efifs) that is just a wrapper around EFI_SIMPLE_FILESYSTEM_PROTOCOL. In > boot, this is achieved by calling the interface directly. > * The efipart and filesystem back ends (including ZFS) have been moved into > a drivers directory, where they have been wrapped up into a filesystem > backend driver that does the same probing that loader does today, and then > installs an EFI_SIMPLE_FILESYSTEM_INTERFACE on all device handles that host > supported filesystems. This interface is a wrapper around the filesystem > interface currently used by loader. > * boot now uses the same filesystem backend code as loader. This increased > its size, necessitating recreation of the FAT templates. The old boot > filesystem code and boot modules have been discarded. > * loader can use any protocol interface installed by boot just fine. These > remain valid until ExitBootServices is called. Moreover, the probing > process is idempotent, and is run by both boot and loader, with the first > one to run actually installing the interfaces. > * I had originally hoped to move the entire code base to use the EFI driver > model, which would support hotplugging devices. However, the new bcache > stuff currently requires that all devices be statically detected before the > caches are used, which is fundamentally incompatible with this way of doing > things. This was the sole blocker of such a transition (the handles.c code > requires some minor modification as well, but nothing problematic) > * I had also considered altering the device name code to use textual > representations of EFI device paths, but I don't see any real reason for > doing so. > * I have not touched efinet or nfs in this changeset. > > The rationale for these changes is as follows: > * The model of looking for EFI_SIMPLE_FILESYSTEM_PROTOCOL instances and > using them to load things increases interoperability with other systems. > For example, the new boot and loader would work just fine with interfaces > installed by GRUB or another boot loader, or perhaps custom filesystem > modules added into an open-source firmware implementation like coreboot. > * This model works really well for functionality like GELI or custom > partition schemes that potentially create new devices. All you do is create > one or more new device nodes, attach device paths and block io interfaces, > and call ConnectController on them (for now, it's necessary to make sure the > fs_driver runs AFTER) all new nodes have been created. This also vastly > simplifies passing information between stages about filesystems and devices > (this is important for GELI). > * This approach can leverage drivers that are mandated by the EFI spec, like > the GPT partition driver. This avoids reimplementing such a driver to > support partition schemes nested inside GELI volumes, for example. > * This model provides most of the groundwork for supporting hot plugging of > devices at boot time. All that is required at this point is a refactoring > of bcache to support adding new devices dynamically (I had to draw the line > somewhere, and this had already gotten big enough, and I want to focus on > GELI support) > * Getting rid of the duplicated and minimized filesystem code in boot1 > improves maintainability. Indeed, the actual boot1 code is quite small > now. > > Some notes and future work: > * In general, the FreeBSD loader framework and the EFI framework do many > similar things. For the most part, there is a fairly direct mapping, though > EFI interfaces tend to be more tedious. The one thing EFI does decidedly > better is support dynamic detection of devices (hotplugging). > * There are some interesting possibilities for hotplugging beyond just the > obvious. For example, loading GELI or other keys off of hotplugged USB > sticks. > * I didn't touch efinet or nfs on this patch. It is certainly possible to > efize them as well, but I don't have a test setup for doing so (or frankly, > the motivation to do so). > * It might make more sense to use the EFI_LOAD_FILE_PROTOCOL to do the > actual loading, as some applications support this without supporting a full > filesystem interface (some embedded devices do this, as do some network boot > protocols). However, this would involve changing the non-EFI boot code and > interfaces, which is something I specifically wanted to avoid in this work. > > This changeset can be tested as is, and should just work. Disclaimer: I > rebased it to head yesterday, and haven't had time to build and test it yet, > but I will. I know it works with ZFS, but I have no UFS systems on which to > test that functionality. > > If you intend to test this, I STRONGLY recommend installing an EFI shell on > your ESP, and then installing the modified boot block under something like > boot.tst. This will allow you to run the modified boot block, but fall back > to a working boot if it fails. Also, I had modified the loader path to > /boot/loader.tst for similar reasons, and it may still be set to that in the > code. > > I am currently adding GELI support as a proper EFI driver, and should be > coming in the very near future (the code is already written, in fact). If > anyone wants to test the refactoring by itself, any results or comments are > certainly appreciated. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Sun May 15 18:53:22 2016 Return-Path: Delivered-To: freebsd-hackers@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 604ADB3C288 for ; Sun, 15 May 2016 18:53:22 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E7FD11A6 for ; Sun, 15 May 2016 18:53:22 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u4FIrFxN068537 for ; Sun, 15 May 2016 11:53:19 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201605151853.u4FIrFxN068537@gw.catspoiler.org> Date: Fri, 13 May 2016 23:29:52 -0700 (PDT) From: Don Lewis Subject: patch to fix acpidb CIDs 1011279 (Buffer not null terminated) and 978405 and 1199380 (Res To: freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 18:53:22 -0000 I posted a patch to fix some problems in acpidump here: https://reviews.freebsd.org/D6368 I don't really know how to drive acpidb, but I didn't notice any obvious breakage after the patch. From owner-freebsd-hackers@freebsd.org Sun May 15 20:37:43 2016 Return-Path: Delivered-To: freebsd-hackers@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 0848CB3C6B5 for ; Sun, 15 May 2016 20:37:43 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id B268A10BA for ; Sun, 15 May 2016 20:37:42 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [10.59.16.226] (mobile-107-107-62-133.mycingular.net [107.107.62.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 82F79156B; Sun, 15 May 2016 20:37:40 +0000 (UTC) User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Subject: Re: Update on EFI work: refactoring ready for testing, GELI coming very soon From: Eric McCorkle Date: Sun, 15 May 2016 16:37:38 -0400 To: Oliver Pinter ,nao@enuenu.org CC: "freebsd-hackers@freebsd.org" Message-ID: <1C7554E1-DF5F-4D86-B4D3-757CF55FCB9E@metricspace.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 20:37:43 -0000 How close is that patch to going in? Something like this would be pretty straightforward following the refactoring; however, its worth considering all the options here: * GRUB works fine pulling loader off the disk, with either ZFS or UFS, with no boot1 at all. This was my setup for developing the ZFS support, actually. * In theory it should be possible to install loader itself on the ESP and install a /boot/config that points it to the real kernel and rootfs The takeaway is that boot1 is kind of an odd citizen in the EFI world. When you get into things like GELI support and secure boot (my next planned thing after this), its role is much clearer, but at that point it also becomes a key attack vector in a system that's presumably trying to resist some level of tampering. What I'm getting at is that there is a future-oriented case for keeping boot1 simple, and if it's a boot menu you want, grub is already an option (also, the loader-only method). To be clear: I'm not opposed to adding this feature; I just want to make sure these issues are given due consideration. On May 15, 2016 12:00:58 PM EDT, Oliver Pinter wrote: >Hi Eric! > >Could you please take a look at this PR: >https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940 >This feature would be nice too. > >On 5/15/16, Eric McCorkle wrote: >> Hello everyone, >> >> I've been working on a rather significant refactoring of the EFI >boot/loader >> code. While this was originally in support of adding GELI support, >it has >> grown to such a scope that it could be considered a patch in its own >right. >> >> The branch containing my work can be found here: >> https://github.com/emc2/freebsd/tree/efize >> >> The following is a summary of the changes: >> * Both boot1 and loader have been redesigned to look for instances of >> EFI_SIMPLE_FILESYSTEM_PROTOCOL and load using that interface. In >loader, >> this is accomplished through a new synthetic filesystem driver >(called >> efifs) that is just a wrapper around EFI_SIMPLE_FILESYSTEM_PROTOCOL. >In >> boot, this is achieved by calling the interface directly. >> * The efipart and filesystem back ends (including ZFS) have been >moved into >> a drivers directory, where they have been wrapped up into a >filesystem >> backend driver that does the same probing that loader does today, and >then >> installs an EFI_SIMPLE_FILESYSTEM_INTERFACE on all device handles >that host >> supported filesystems. This interface is a wrapper around the >filesystem >> interface currently used by loader. >> * boot now uses the same filesystem backend code as loader. This >increased >> its size, necessitating recreation of the FAT templates. The old >boot >> filesystem code and boot modules have been discarded. >> * loader can use any protocol interface installed by boot just fine. >These >> remain valid until ExitBootServices is called. Moreover, the probing >> process is idempotent, and is run by both boot and loader, with the >first >> one to run actually installing the interfaces. >> * I had originally hoped to move the entire code base to use the EFI >driver >> model, which would support hotplugging devices. However, the new >bcache >> stuff currently requires that all devices be statically detected >before the >> caches are used, which is fundamentally incompatible with this way of >doing >> things. This was the sole blocker of such a transition (the >handles.c code >> requires some minor modification as well, but nothing problematic) >> * I had also considered altering the device name code to use textual >> representations of EFI device paths, but I don't see any real reason >for >> doing so. >> * I have not touched efinet or nfs in this changeset. >> >> The rationale for these changes is as follows: >> * The model of looking for EFI_SIMPLE_FILESYSTEM_PROTOCOL instances >and >> using them to load things increases interoperability with other >systems. >> For example, the new boot and loader would work just fine with >interfaces >> installed by GRUB or another boot loader, or perhaps custom >filesystem >> modules added into an open-source firmware implementation like >coreboot. >> * This model works really well for functionality like GELI or custom >> partition schemes that potentially create new devices. All you do is >create >> one or more new device nodes, attach device paths and block io >interfaces, >> and call ConnectController on them (for now, it's necessary to make >sure the >> fs_driver runs AFTER) all new nodes have been created. This also >vastly >> simplifies passing information between stages about filesystems and >devices >> (this is important for GELI). >> * This approach can leverage drivers that are mandated by the EFI >spec, like >> the GPT partition driver. This avoids reimplementing such a driver >to >> support partition schemes nested inside GELI volumes, for example. >> * This model provides most of the groundwork for supporting hot >plugging of >> devices at boot time. All that is required at this point is a >refactoring >> of bcache to support adding new devices dynamically (I had to draw >the line >> somewhere, and this had already gotten big enough, and I want to >focus on >> GELI support) >> * Getting rid of the duplicated and minimized filesystem code in >boot1 >> improves maintainability. Indeed, the actual boot1 code is quite >small >> now. >> >> Some notes and future work: >> * In general, the FreeBSD loader framework and the EFI framework do >many >> similar things. For the most part, there is a fairly direct mapping, >though >> EFI interfaces tend to be more tedious. The one thing EFI does >decidedly >> better is support dynamic detection of devices (hotplugging). >> * There are some interesting possibilities for hotplugging beyond >just the >> obvious. For example, loading GELI or other keys off of hotplugged >USB >> sticks. >> * I didn't touch efinet or nfs on this patch. It is certainly >possible to >> efize them as well, but I don't have a test setup for doing so (or >frankly, >> the motivation to do so). >> * It might make more sense to use the EFI_LOAD_FILE_PROTOCOL to do >the >> actual loading, as some applications support this without supporting >a full >> filesystem interface (some embedded devices do this, as do some >network boot >> protocols). However, this would involve changing the non-EFI boot >code and >> interfaces, which is something I specifically wanted to avoid in this >work. >> >> This changeset can be tested as is, and should just work. >Disclaimer: I >> rebased it to head yesterday, and haven't had time to build and test >it yet, >> but I will. I know it works with ZFS, but I have no UFS systems on >which to >> test that functionality. >> >> If you intend to test this, I STRONGLY recommend installing an EFI >shell on >> your ESP, and then installing the modified boot block under something >like >> boot.tst. This will allow you to run the modified boot block, but >fall back >> to a working boot if it fails. Also, I had modified the loader path >to >> /boot/loader.tst for similar reasons, and it may still be set to that >in the >> code. >> >> I am currently adding GELI support as a proper EFI driver, and should >be >> coming in the very near future (the code is already written, in >fact). If >> anyone wants to test the refactoring by itself, any results or >comments are >> certainly appreciated. >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >"freebsd-hackers-unsubscribe@freebsd.org" >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From owner-freebsd-hackers@freebsd.org Sun May 15 22:06:07 2016 Return-Path: Delivered-To: freebsd-hackers@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 B2F64B3B32E for ; Sun, 15 May 2016 22:06:07 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (207-172-209-83.c3-0.arl-ubr1.sbo-arl.ma.static.cable.rcn.com [207.172.209.83]) by mx1.freebsd.org (Postfix) with ESMTP id 6B20111C6 for ; Sun, 15 May 2016 22:06:06 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [172.16.0.5] (unknown [172.16.0.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id BBA64158A for ; Sun, 15 May 2016 22:06:05 +0000 (UTC) Subject: Proposal for an interface for communicating keys from loader to kernel From: Eric McCorkle Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (13D15) Message-Id: Date: Sun, 15 May 2016 18:06:04 -0400 To: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 22:06:07 -0000 I've developed a plan for a general interface for communicating keys from lo= ader to kernel as part of my ongoing work. As it involves creating an inter= face between kernel and loader, I wanted to put it out for discussion before= I start writing code on it. I'm aware of the current solution based on environment variables. It has a n= umber of shortcomings I aim to address with this proposal: * It communicates only a single key to the kernel * It could lead to accidental key disclosure by debugging (also, when last I= checked, the memory holding the key isn't properly zeroed out, which is a s= ecurity risk) * It is incompatible with hardware security modules (HSMs) The basic idea is that the interface for doing this will look like a KMS (ke= y management system) to loader. In EFI land, this will be accomplished usin= g the EFI_KMS_PROTOCOL interface (see UEFI spec 2.6). This should allow loa= der to treat a software-based approach and one that uses a hardware security= module of some kind as similarly as possible (some difference in the exact c= lient data may be necessary, but the interface as a whole should be the same= ). In EFI land, GELI (and any other crypto module) will be able to be configure= d to store keys into a KMS with a given name. There will be a software kern= el injection driver which implements EFI_KMS_PROTOCOL which functions as fol= lows: * The kernel (or a module) will have a static key buffer added, which includ= es space for some number of keys and their descriptors. The exact format of= this is TBD. It will have a specified name, and will be exposed as a linka= ble symbol. * The loader-side driver (which implements EFI_KMS_PROTOCOL) will maintain t= his data in a buffer whose size and format exactly matches the one in the ke= rnel. * boot1 and loader will store keys for any system that requests them (such a= s GELI) using the EFI_KMS_PROTOCOL functions. * Adding a client named "kernel", with the client data being a pointer to an= ELF image will cause the driver to resolve the symbol for the kernel key bu= ffer and copy all the data into place. Updating the client data will cause t= he driver to zero out the previous data and perform the lookup and copy agai= n. * During boot, the kernel is expected to check this buffer for keys first wh= en initializing any system that may require key input (such as GELI). It is= expected to zero out the buffer at the end of boot. This could alternately be implemented as a device driver. If there is an ex= isting generic KMS interface, then I should use it as a template for such a s= ystem (I am not aware of one, but that doesn't mean it doesn't exist). Should support for some kind of HSM device be added, this approach should re= quire minimal modification to support it fully. This should also be orthogo= nal to the current environment variable solution, so that approach can conti= nue to be used for as long as necessary. I anticipate having GELI probing and access working by next weekend, after w= hich I will implement the system I've described here. So I wanted to get th= is out for consideration before then. Comments and suggestions are welcome. Feel free to forward this proposal to= anyone or any list that should see it.= From owner-freebsd-hackers@freebsd.org Mon May 16 08:51:33 2016 Return-Path: Delivered-To: freebsd-hackers@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 94680B3D6C5 for ; Mon, 16 May 2016 08:51:33 +0000 (UTC) (envelope-from nao@enuenu.org) Received: from mail.tee-n.com (32.161.192.61.east.global.crust-r.net [61.192.161.32]) by mx1.freebsd.org (Postfix) with ESMTP id 5791E1E0F for ; Mon, 16 May 2016 08:51:32 +0000 (UTC) (envelope-from nao@enuenu.org) Received: from melon.enuenu.site (melon.enuenu.site [192.168.30.10]) by mail.tee-n.com (Postfix) with ESMTP id 8C5AAB1F3E; Mon, 16 May 2016 17:51:24 +0900 (JST) Received: from [192.168.30.136] (dhcp30136.enuenu.site [192.168.30.136]) by melon.enuenu.site (Postfix) with ESMTP id 85E0C5712D; Mon, 16 May 2016 17:51:24 +0900 (JST) Subject: Re: Update on EFI work: refactoring ready for testing, GELI coming very soon To: Eric McCorkle , Oliver Pinter References: <1C7554E1-DF5F-4D86-B4D3-757CF55FCB9E@metricspace.net> Cc: "freebsd-hackers@freebsd.org" From: Naomichi Nonaka Message-ID: <58159dcd-4187-473f-4a20-1d2f7a20c955@enuenu.org> Date: Mon, 16 May 2016 17:51:23 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <1C7554E1-DF5F-4D86-B4D3-757CF55FCB9E@metricspace.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 16 May 2016 11:28:44 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 08:51:33 -0000 Hi Eric. On 2016/05/16 5:37, Eric McCorkle wrote: > How close is that patch to going in? > > Something like this would be pretty straightforward following the > refactoring; however, its worth considering all the options here: > > * GRUB works fine pulling loader off the disk, with either ZFS or UFS, > with no boot1 at all. This was my setup for developing the ZFS support, > actually. Is Grub + loader really work in EFI mode ? My test results are 1) Grub's kfreebsd command does not support loader.efi 2) Chainload loader.efi in Grub couldn't show display. maybe it work in keadless but I didn't tested headless mode. 3) Chaiload boot1.efi in Grub works. That is why I wrote PR#207940. Maybe I miss something. So, If anyone successed to boot in Grub + loader.efi combination, please let me know. > * In theory it should be possible to install loader itself on the ESP > and install a /boot/config that points it to the real kernel and rootfs > > The takeaway is that boot1 is kind of an odd citizen in the EFI world. Year, I agree that. But I myself need boot menu, and expand boot1 seems better than to install Grub in Freebsd installer. > When you get into things like GELI support and secure boot (my next > planned thing after this), its role is much clearer, but at that point > it also becomes a key attack vector in a system that's presumably trying > to resist some level of tampering. > > What I'm getting at is that there is a future-oriented case for keeping > boot1 simple, and if it's a boot menu you want, grub is already an > option (also, the loader-only method). > > To be clear: I'm not opposed to adding this feature; I just want to make > sure these issues are given due consideration. I agree that too. Naomichi Nonaka > On May 15, 2016 12:00:58 PM EDT, Oliver Pinter > wrote: > > Hi Eric! > > Could you please take a look at this PR: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940 > This feature would be nice too. > > On 5/15/16, Eric McCorkle wrote: > > Hello everyone, > > I've been working on a rather significant refactoring of the EFI > boot/loader > code. While this was originally in support of adding GELI > support, it has > grown to such a scope that it could be considered a patch in its > own right. > > The branch containing my work can be found here: > https://github.com/emc2/freebsd/tree/efize > > The following is a summary of the changes: > * Both boot1 and loader have been redesigned to look for > instances of > EFI_SIMPLE_FILESYSTEM_PROTOCOL and load using that interface. In > loader, > this is accomplished through a new synthetic filesystem driver > (called > efifs) that is just a wrapper around > EFI_SIMPLE_FILESYSTEM_PROTOCOL. In > boot, this is achieved by calling the interface directly. > * The efipart and filesystem back ends (including ZFS) have been > moved into > a drivers directory, where they have been wrapped up into a > filesystem > backend driver that does the same probing that loader does > today, and then > installs an EFI_SIMPLE_FILESYSTEM_INTERFACE on all device > handles that host > supported filesystems. This interface is a wrapper around the > filesystem > interface currently used by loader. > * boot now uses the same filesystem backend code as loader. This > increased > its size, necessitating recreation of the FAT templates. The old > boot > filesystem code and boot modules have been discarded. > * loader can use any protocol interface installed by boot just > fine. These > remain valid until ExitBootServices is called. Moreover, the probing > process is idempotent, and is run by both boot and loader, with > the first > one to run actually installing the interfaces. > * I had originally hoped to move the entire code base to use the > EFI driver > model, which would support hotplugging devices. However, the new > bcache > stuff currently requires that all devices be statically detected > before the > caches are used, which is fundamentally incompatible with this > way of doing > things. This was the sole blocker of such a transition (the > handles.c code > requires some minor modification as well, but nothing problematic) > * I had also considered altering the device name code to use textual > representations of EFI device paths, but I don't see any real > reason for > doing so. > * I have not touched efinet or nfs in this changeset. > > The rationale for these changes is as follows: > * The model of looking for EFI_SIMPLE_FILESYSTEM_PROTOCOL > instances and > using them to load things increases interoperability with other > systems. > For example, the new boot and loader would work just fine with > interfaces > installed by GRUB or another boot loader, or perhaps custom > filesystem > modules added into an open-source firmware implementation like > coreboot. > * This model works really well for functionality like GELI or custom > partition schemes that potentially create new devices. All you > do is create > one or more new device nodes, attach device paths and block io > interfaces, > and call ConnectController on them (for now, it's necessary to > make sure the > fs_driver runs AFTER) all new nodes have been created. This also > vastly > simplifies passing information between stages about filesystems > and devices > (this is important for GELI). > * This approach can leverage drivers that are mandated by the > EFI spec, like > the GPT partition driver. This avoids reimplementing such a > driver to > support partition schemes nested inside GELI volumes, for example. > * This model provides most of the groundwork for supporting hot > plugging of > devices at boot time. All that is required at this point is a > refactoring > of bcache to support adding new devices dynamically (I had to > draw the line > somewhere, and this had already gotten big enough, and I want to > focus on > GELI support) > * Getting rid of the duplicated and minimized filesystem code in > boot1 > improves maintainability. Indeed, the actual boot1 code is quite > small > now. > > Some notes and future work: > * In general, the FreeBSD loader framework and the EFI framework > do many > similar things. For the most part, there is a fairly direct > mapping, though > EFI interfaces tend to be more tedious. The one thing EFI does > decidedly > better is support dynamic detection of devices (hotplugging). > * There are some interesting possibilities for hotplugging > beyond just the > obvious. For example, loading GELI or other keys off of > hotplugged USB > sticks. > * I didn't touch efinet or nfs on this patch. It is certainly > possible to > efize them as well, but I don't have a test setup for doing so > (or frankly, > the motivation to do so). > * It might make more sense to use the EFI_LOAD_FILE_PROTOCOL to > do the > actual loading, as some applications support this without > supporting a full > filesystem interface (some embedded devices do this, as do some > network boot > protocols). However, this would involve changing the non-EFI > boot code and > interfaces, which is something I specifically wanted to avoid in > this work. > > This changeset can be tested as is, and should just work. > Disclaimer: I > rebased it to head yesterday, and haven't had time to build and > test it yet, > but I will. I know it works with ZFS, but I have no UFS systems > on which to > test that functionality. > > If you intend to test this, I STRONGLY recommend installing an > EFI shell on > your ESP, and then installing the modified boot block under > something like > boot.tst. This will allow you to run the modified boot block, > but fall back > to a working boot if it fails. Also, I had modified the loader > path to > /boot/loader.tst for similar reasons, and it may still be set to > that in the > code. > > I am currently adding GELI support as a proper EFI driver, and > should be > coming in the very near future (the code is already written, in > fact). If > anyone wants to test the refactoring by itself, any results or > comments are > certainly appreciated. > ------------------------------------------------------------------------ > > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. From owner-freebsd-hackers@freebsd.org Mon May 16 13:14:13 2016 Return-Path: Delivered-To: freebsd-hackers@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 F05C7B3D1B5 for ; Mon, 16 May 2016 13:14:13 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (207-172-209-83.c3-0.arl-ubr1.sbo-arl.ma.static.cable.rcn.com [207.172.209.83]) by mx1.freebsd.org (Postfix) with ESMTP id CC6EA174D for ; Mon, 16 May 2016 13:14:13 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9] (unknown [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 0152B1749; Mon, 16 May 2016 13:14:11 +0000 (UTC) References: <1C7554E1-DF5F-4D86-B4D3-757CF55FCB9E@metricspace.net> <58159dcd-4187-473f-4a20-1d2f7a20c955@enuenu.org> Mime-Version: 1.0 (1.0) In-Reply-To: <58159dcd-4187-473f-4a20-1d2f7a20c955@enuenu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <78C98A5F-7887-4950-AF7D-E6E979F7FD05@metricspace.net> Cc: Oliver Pinter , "freebsd-hackers@freebsd.org" X-Mailer: iPad Mail (13D15) From: Eric McCorkle Subject: Re: Update on EFI work: refactoring ready for testing, GELI coming very soon Date: Mon, 16 May 2016 09:14:10 -0400 To: Naomichi Nonaka X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 13:14:14 -0000 > On May 16, 2016, at 04:51, Naomichi Nonaka wrote: >=20 > Hi Eric. >=20 >> On 2016/05/16 5:37, Eric McCorkle wrote: >> How close is that patch to going in? >>=20 >> Something like this would be pretty straightforward following the >> refactoring; however, its worth considering all the options here: >>=20 >> * GRUB works fine pulling loader off the disk, with either ZFS or UFS, >> with no boot1 at all. This was my setup for developing the ZFS support, >> actually. >=20 > Is Grub + loader really work in EFI mode ? >=20 > My test results are > 1) Grub's kfreebsd command does not support loader.efi > 2) Chainload loader.efi in Grub couldn't show display. maybe it work in ke= adless but I didn't tested headless mode. > 3) Chaiload boot1.efi in Grub works. >=20 > That is why I wrote PR#207940. Maybe I miss something. So, If anyone succe= ssed to boot in Grub + loader.efi combination, please let me know. Strange. The chainloader method works on one of my laptops. It's possible t= hat a patch since then has broken that. I know somebody ported the loader m= enu at some point. Prior to that, it was just a loader shell, and that did w= ork. I'll try updating that laptop and see if it still works.= From owner-freebsd-hackers@freebsd.org Mon May 16 16:45:10 2016 Return-Path: Delivered-To: freebsd-hackers@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 440A0B3D735 for ; Mon, 16 May 2016 16:45:10 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 3512612D2; Mon, 16 May 2016 16:45:10 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 2B4671ACD; Mon, 16 May 2016 16:45:10 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id C174B1D319; Mon, 16 May 2016 16:45:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id p1roxLcNJqqn; Mon, 16 May 2016 16:45:03 +0000 (UTC) Subject: Re: bsd.incs.mk: include subdirectories DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com DECDE1D313 To: Demetrius Siluanius , freebsd-hackers@freebsd.org References: From: Bryan Drewery Organization: FreeBSD Message-ID: <73a9d590-c845-910e-12ff-dd1580b81500@FreeBSD.org> Date: Mon, 16 May 2016 09:45:00 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 16:45:10 -0000 On 5/11/16 1:08 PM, Demetrius Siluanius wrote: > Hello everyone! >=20 > Recently I started porting a number of my projects to BSD world. I real= ized it > would be great if I could use a native make(1) tool instead of GNU make= . I'm > really impressed how easy it is to create a makefile for a library with= almost > a single '.include bsd.lib.mk' statement. Thank you guys for such an am= azing > build system! >=20 > The only thing I couldn't deal with is when headers must be placed into > subdirectories. For simplicity let's assume that project's headers hier= archy is > the following one: > include/ > mylib/ > A/ > A0.h > A1.h > B/ > B0.h > B1.h > base.h >=20 > The only header that will be used is "mylib/base.h", but it includes ot= her > headers using statements '#include "A/A0.h". What should I do to instal= l files > like this? I can't really understand what's happening inside of bsd.inc= s.mk > file, but I guess there should be something simpler than overriding the= default > 'installincludes' target. >=20 > I could't find any relevant information; I tried to find an example Mak= efile > which could have a similar headers hierarchy, but didn't succeed. Could= you > help me, please? Thank you! If I understand correctly then you want something like this in the Makefi= le: INCSGROUPS=3D A B INCS INCS=3D base.h INCSDIR=3D /usr/include/mylib A=3D A0.h A1.h ADIR=3D ${INCSDIR}/A B=3D B0.h B1.h BDIR=3D ${INCSDIR}/B The trick is that INCSGROUPS defines a and you can use DIR MODE GRP OWN and to define multiple groups of includes and where and how they should be installed. The default value for INCSGROUPS is just 'INCS' which is why INCSDIR and INCSOWN, etc, work= . Regards, Bryan Drewery From owner-freebsd-hackers@freebsd.org Wed May 18 17:21:16 2016 Return-Path: Delivered-To: freebsd-hackers@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 9F7BEB41533 for ; Wed, 18 May 2016 17:21:16 +0000 (UTC) (envelope-from rdarbha@juniper.net) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bbn0101.outbound.protection.outlook.com [157.56.111.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2AAF218BE for ; Wed, 18 May 2016 17:21:15 +0000 (UTC) (envelope-from rdarbha@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=v9qlAyMmbzIIv5eBWYz9ZK9nmscCdU4gLRMNnH59yHY=; b=CLnKfRJ3JsIn+3M+FvHAdPf6mvxHr2RFb0p7PDvgwviwhMrV2raGDTkdX3dFu8ruC4t92VLYz/nyz4GernzhBdy7g+GT0iLzxt16fCqUI5kC/OlnTSjq9WSL7W//qgiWTi2sHcI8h5qTN1cuWxTOxOjXSAKevyUtOZiaNxn/2EY= Received: from CO2PR05MB2709.namprd05.prod.outlook.com (10.166.200.9) by CO2PR05MB2710.namprd05.prod.outlook.com (10.166.200.10) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 18 May 2016 16:47:49 +0000 Received: from CO2PR05MB2709.namprd05.prod.outlook.com ([10.166.200.9]) by CO2PR05MB2709.namprd05.prod.outlook.com ([10.166.200.9]) with mapi id 15.01.0497.019; Wed, 18 May 2016 16:47:47 +0000 From: Raviprakash Darbha To: "freebsd-hackers@freebsd.org" CC: Raviprakash Darbha , Sreekanth Rupavatharam Subject: Recursive lock panic of unp_link_wlock Thread-Topic: Recursive lock panic of unp_link_wlock Thread-Index: AQHRsSUCW73eeA+qCECQ8qS591an7w== Date: Wed, 18 May 2016 16:47:47 +0000 Message-ID: <12B345F1-E72A-4274-AA70-65DEF556DB0A@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.15] x-ms-office365-filtering-correlation-id: be905138-080c-4c82-4185-08d37f3c24a6 x-microsoft-exchange-diagnostics: 1; CO2PR05MB2710; 5:CcgWjHf6lTiBLCV9Jo788hKgIEGI2tp9D3Q1zuuJeKBfh0WFc4bM9ugZ7Qds8gKqudfgJTbhfpIXTIfCklRJEaqnnQi8doM+lU3+98nih5pl8ZyBSt/IkgJOOY17KpPXC0hn/yJq5mQa7Azpn5PYyA==; 24:a2jENqazzpGPVbbZBQiHGLt6NwNOFaZmzeORFeGBsorX8MNubonJjiLKPbZTRK2SX2L5pxh5b/ahpsufPzhRmsnO4fNgJBinY4u9tseD4wU=; 7:bEAS0rhgHVnajRLuLKemVGEOkxdVl+cWapWP2MXHfmkzdpBBNggBA+WckRF/WiT6gpMVIyJlGINxdKgX64pN76+P/G7hyTUCUUXBGd9XiyvloQaZLR2GxY4GollmKKA7E/m/vF9S9HCeh+e8JYHAf/5UHwvv0hpDBo+JOrU/K5KXoFgCLL+Awr892UX1fxX3 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB2710; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:CO2PR05MB2710; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2710; x-forefront-prvs: 0946DC87A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(53754006)(5640700001)(77096005)(50986999)(3660700001)(92566002)(450100001)(54356999)(107886002)(110136002)(8936002)(3280700002)(5004730100002)(102836003)(87936001)(1220700001)(2906002)(586003)(6116002)(82746002)(66066001)(86362001)(19580405001)(122556002)(99286002)(5002640100001)(5890100001)(4001430100002)(36756003)(33656002)(2351001)(10400500002)(229853001)(189998001)(2900100001)(2501003)(16236675004)(4326007)(106116001)(19580395003)(83716003)(8676002)(81166006)(5008740100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2710; H:CO2PR05MB2709.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2016 16:47:47.7762 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2710 X-Mailman-Approved-At: Wed, 18 May 2016 17:59:17 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 17:21:16 -0000 SGVsbG8gQWxsDQoNCkkgaGF2ZSBoaXQgYSBjb25kaXRpb24gd2hlcmUgdW5wX2xpbmtfd2xvY2sg IGlzIGJlaW5nIGNhbGxlZCB0d2ljZSBpbiB0aGUgc2FtZSB0aHJlYWQgKCByZWN1cnNpdmUgbG9j a2luZykgIGJ1dCBpdCBoaXRzIGEgcGFuaWMgYXMgaXRzIG5vdCBhIHJlY3Vyc2l2ZSBsb2NrLiBX b25kZXJpbmcgaWYgdGhpcyBoYXMgYmVlbiBvYnNlcnZlZC4gVGhlIGZpbGUgaW4gY29udGV4dCBp cyBzeXMva2Vybi91aXBjX3VzcnJlcS5jIGFuZCBzeXMva2Vybi91aXBjX3NvY2tldC5jIC4gVGhl IGV4YWN0IGNhbGwgc3RhY2sgb2JzZXJ2ZWQgaXM6DQoNClVOUF9MSU5LX1dMT0NLKCk7ICAgICAg ICAgPOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlCAgMSBzdCBjYWxsDQrigKYuLg0K4oCmLi4NCmlmIChzby0+c29f cHJvdG8tPnByX2ZsYWdzICYgUFJfQ09OTlJFUVVJUkVEKSB7DQoNCiAgICAgICAgICAgICAgICBp ZiAoc28yLT5zb19vcHRpb25zICYgU09fQUNDRVBUQ09OTikgew0KDQogICAgICAgICAgICAgICAg ICAgICAgQ1VSVk5FVF9TRVQoc28yLT5zb192bmV0KTsNCg0KICAgICAgICAgICAgICAgICAgICAg ICBzbzMgPSBzb25ld2Nvbm4oc28yLCAwKTsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAv LyBFeHBhbmRpbmcgc29uZXdjb25uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgew0KDQogICAg ICAgICAgICAgICAgICAgICAgICAgICBzb25ld2Nvbm4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHsNCg0KICAgIOKApuKApg0KDQogICAgc29hbGxvYw0KDQogICAg4oCm4oCmLg0KDQog ICAgICBwcnVfYXR0YWNoDQoNCiAgICAgIOKApuKApi4uDQoNCiAgICAgICAgaWYgKCEoaGVhZC0+ c29fb3B0aW9ucyAmIFNPX0FDQ0VQVENPTk4pICYmDQoNCiAgICAgICAgICAgICAoKGhlYWQtPnNv X3Byb3RvLT5wcl9wcm90b2NvbCAhPSBJUFBST1RPX1NDVFApIHx8DQoNCiAgICAgICAgICAgICAg KGhlYWQtPnNvX3R5cGUgIT0gU09DS19TRVFQQUNLRVQpKSkgew0KDQogICAgICAgICAgICAgICAg IFNPQ0tfTE9DSyhzbyk7DQoNCiAgICAgICAgICAgICAgICAgc28tPnNvX2hlYWQgPSBOVUxMOw0K DQogICAgICAgICAgICAgICAgIHNvZnJlZShzbyk7ICAgICAgICAgICAgIC8qIE5COiByZXR1cm5z IEFDQ0VQVF9VTkxPQ0snZWQuICovDQoNCiAgICAgICAgICAgICAgICAvLyBFeHBhbmRpbmcgc29m cmVlDQoNCiAgICAgICAgICAgICAgICB7DQoNCiAgICAgICAgICAgICAgICAgICAgICDigKbigKYu DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIOKApuKApi4uDQoNCiAgICAgICAgICAgICAgICAg ICAgICBwcnVfZGV0YWNoDQoNCiAgICAgICAgICAgICAgICAgICAgICAvLyBleHBhbmRpbmcgcHJ1 X2RldGFjaA0KDQogICAgICAgICAgICAgICAgICAgICAgICB7DQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAvLyBSZWN1cnNpdmUgd2xvY2sgYWNxdWlyaW5nLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgVU5QX0xJTktfV0xPQ0soKSAgICAgPOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlCAgMm5kIENhbGwNCg0KICAg ICAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgfQ0KDQoNCg0KTGV0IG1l IGtub3cgaWYgYW55IG90aGVyIGRldGFpbHMgYXJlIG5lZWRlZC4gTm90IHN1cmUgaWYgdGhpcyBp cyBjYWxsIHN0YWNrIGlzIGV4cGVjdGVkLiBUaGlzIGlzIG9ic2VydmVkIG9uIFN0YWJsZSAxMCBh cyB3ZWxsIGFzIGhlYWQsDQoNClRoYW5rcw0KDQpSYXZpUHJha2FzaCBEYXJiaGENCg0KcmRhcmJo YUBqdW5pcGVyLm5ldDxtYWlsdG86cmRhcmJoYUBqdW5pcGVyLm5ldD4NCg0KDQoNCg== From owner-freebsd-hackers@freebsd.org Thu May 19 04:11:22 2016 Return-Path: Delivered-To: freebsd-hackers@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 4D667B4116E for ; Thu, 19 May 2016 04:11:22 +0000 (UTC) (envelope-from rwestlun@gmail.com) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 08AC01B4D for ; Thu, 19 May 2016 04:11:22 +0000 (UTC) (envelope-from rwestlun@gmail.com) Received: by mail-qk0-x22c.google.com with SMTP id n62so36916783qkc.2 for ; Wed, 18 May 2016 21:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=0h40GWBskqtFcuHjISy8oeQDD/YHae51rmUs0V4nu1k=; b=ABABWmHeoZlJZKLJ5dU9HyAp/Qq3WbHA4OmHfr6+vYACEpxwOnFiBnIh5RetrD9bhl qJxg1iUh+JlWc0cHViu0fRx97D99jnwHfOhms/A/kZbaU9M74eZdUN6ZuK6+xwGdubKT kXsH3uuSZLNIDT8k3A/ABw7gK1P/1kZz00yftmN6i9V8mnWvMVqfAv0P/3QEomkPBS/P jkfEHXuMZ9BewMxivPblDahYVifS5IX145amR+amXRHTXwbMj6i2Vkj2UEI3616S/6ih uJZSrabG57Dbdv3FasjZYRtEGh6TmZxvQ/aEVnbeXhCU+nchYdLKBmZf5ggiMYbD/LB6 yVNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=0h40GWBskqtFcuHjISy8oeQDD/YHae51rmUs0V4nu1k=; b=Zj1hp9FiwGjmQ2XEbQF3a+1bZqdgMhIba3/XERs3mgKuIIhrn4GUX9iQ5uPpzjAFYa zJL50nFD6aB/n/WWtXSCmzL7Dne5GIim1PZn+PZQvdRVgx8R5uoT4NVYU1o/gsqoMrns 1rzByKguJEYGmvPBQbQ+RToMpXm11DiWb+QnkeAYSERiep8xZVxinRlB7YUYhEWDueYo wVnET4JfSPYG/xZCSf60CGcv6pkXSlYglcuFOQDpiRuXidGe+9vhKAK6Rbf6o2xBgxS5 jfdoLtkZpV093yHHDxK/a1R+sHS2Yz0eskacd5Mr/KGmtkg69DFgdy2Bv9aHh93w2R1x CGZg== X-Gm-Message-State: AOPr4FU1WN42mKlMYTtbMbH/7r0Q36bl2u4HzKPIb68aPFWdiF6eBturAVxFuku0/e3fTg== X-Received: by 10.55.68.78 with SMTP id r75mr11722458qka.189.1463631081219; Wed, 18 May 2016 21:11:21 -0700 (PDT) Received: from gmail.com (c-98-216-247-110.hsd1.ma.comcast.net. [98.216.247.110]) by smtp.gmail.com with ESMTPSA id w70sm5797173qhw.22.2016.05.18.21.11.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 May 2016 21:11:20 -0700 (PDT) Date: Thu, 19 May 2016 00:11:18 -0400 From: Randy Westlund To: freebsd-hackers@freebsd.org Subject: What changes are welcome? Message-ID: <20160519041118.GE19887@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IU5/I01NYhRvwH70" Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 04:11:22 -0000 --IU5/I01NYhRvwH70 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'd like to start contributing to the base system, but I need clarification on what sort of changes would be welcome. I thought I'd start on simple compiler warnings. The top code in /contrib/top, for example uses K&R-style function definitions and implicit return types that spews -Wimplicit-int and -Wreturn-type warnings. While I'm silencing those, is it appropriate for me to make the file follow style(9)? Once I have a diff, should I just upload it to bugzilla, or is it preferable to put it on phabricator and then link to it from bugzilla? Randy --IU5/I01NYhRvwH70 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXPTzmAAoJEGaweXjzNsmpj3UH/3DF9qmAFPVKJZxe0D+Fmq3B C2nIClbfkFkekVOBuDzVbpMIhzQ5LyFiOEffLMS43sJvBpKvNQ9B3q/c3rXzs3dj GgcuiVr6IxoV9SuxgGQiVIagdOLGXFfsprijvCPkMzVThP+jaT3o5OgH+Uq//AXf zNvK2FYYNgT2Ne8J4XwYUP89UbMEKeN5Ft5iA0+1q3U/165pLo/wQBHUz8bOvPkx 2PzLjjyMG3zzkmqr7tpmHy0gNYEZx1E7e1gZYqy4JnkOEoDgTOetrTlPqidndbZP Jx/GmyctDtYiWLmxtRr5y73nNNdqG21SJVU51N3Iuot7vgXlgKS57JAWlY4XdWc= =ct/z -----END PGP SIGNATURE----- --IU5/I01NYhRvwH70-- From owner-freebsd-hackers@freebsd.org Thu May 19 04:14:32 2016 Return-Path: Delivered-To: freebsd-hackers@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 8922FB41324 for ; Thu, 19 May 2016 04:14:32 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id 6FC3E1FD9 for ; Thu, 19 May 2016 04:14:32 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 4E9C9DE32 for ; Thu, 19 May 2016 04:14:31 +0000 (UTC) Subject: Re: What changes are welcome? To: freebsd-hackers@freebsd.org References: <20160519041118.GE19887@gmail.com> From: Allan Jude Message-ID: <573D3DA7.20600@freebsd.org> Date: Thu, 19 May 2016 00:14:31 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160519041118.GE19887@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 04:14:32 -0000 On 2016-05-19 00:11, Randy Westlund wrote: > I'd like to start contributing to the base system, but I need > clarification on what sort of changes would be welcome. > > I thought I'd start on simple compiler warnings. The top code in > /contrib/top, for example uses K&R-style function definitions and > implicit return types that spews -Wimplicit-int and -Wreturn-type > warnings. > > While I'm silencing those, is it appropriate for me to make the file > follow style(9)? > > Once I have a diff, should I just upload it to bugzilla, or is it > preferable to put it on phabricator and then link to it from bugzilla? > > Randy > Generally, you likely want to avoid changing anything from contrib/ or vendor/, as that is code from other projects that is imported, and local changes complicate that. Of course, top is not really maintained 'upstream' anymore, so maybe it isn't a bad place to start. Phabricator is likely the best place for patches, it is much easier to review. -- Allan Jude From owner-freebsd-hackers@freebsd.org Thu May 19 05:19:06 2016 Return-Path: Delivered-To: freebsd-hackers@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 EC040B410CF for ; Thu, 19 May 2016 05:19:06 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 B8B7B1469 for ; Thu, 19 May 2016 05:19:06 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-io0-x22c.google.com with SMTP id i75so93461918ioa.3 for ; Wed, 18 May 2016 22:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=YcL62T6oZFvzoDEsV00kzD1FSiUdzwlBwq2iTRKaLwk=; b=HE2VWNNfNwohwN+z65cff6A3qw2iNl0pD4amzBGNJXce+s4bK3UlcB3OfY8n2B3Vt8 GjglFhCyWSJiGstZ1QhBTaxbxc9hMoILokwCRFFBP39XU2pZK+t+EEfcl0XpueSQdx9N qpm9dlnhLg65nCqUxPwP7FxeGz4lf+4Y16pICPYUmdgPVGHbQpeqJonqg5N041nkZ15h dT4d22ZvJTHHwyfFNEPaMF9nbz/DPWIsZkfjOYOE91fgNOU7Vwzf/ITzk8G8i4GJqP/Q j6j7wuo2zJNHqsW1YlV3itzDN3egTuYnc83mpSmk6oXGWZWwotwoyGh2E6379TtFC9p1 ajRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=YcL62T6oZFvzoDEsV00kzD1FSiUdzwlBwq2iTRKaLwk=; b=Ccv51uPVKQTeVM9ah3ZWIBlAmZE3ao3DAD8JtjI3YvG/UeA+HOo53dRkcj0Un1rLsM sYMEGmrnvebJcpll4AGw0l5qklNyHI8exGxeH6cNNB2NeBCk6T+/3l7ESvuoseme7vqi IIm1Wz22/Yyl3lmPyPMYm1foJhgKLbhkQQYQxO+NTjFN7z/7BDz19pXK5NMEa4btnrPG zCu7UOa0cz0dEygDuQHP2XNOrFMB/isq0Lqr/uV2lH/x7RQfQjgGeR9MS1gQD0zppsNC z7dvbogzWFGjL9Y42WfE0Gd9zZPG/MiPhFktLiEjKirOpdBUCweK0QWz9LQLkabpWrb/ tJuw== X-Gm-Message-State: AOPr4FUQHvKmwymg0+x9in5fbLqpc7z36SHOGpKto8MtjI7052k5sxZIuaQvsgM2GkKqUocS2VqRHMDEe0B4tA== MIME-Version: 1.0 X-Received: by 10.36.208.84 with SMTP id m81mr1325711itg.56.1463635146159; Wed, 18 May 2016 22:19:06 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.107.140.8 with HTTP; Wed, 18 May 2016 22:19:06 -0700 (PDT) In-Reply-To: <20160519041118.GE19887@gmail.com> References: <20160519041118.GE19887@gmail.com> Date: Wed, 18 May 2016 22:19:06 -0700 X-Google-Sender-Auth: 2jZSGV4QErMRiOtfeiKDSLEDe5g Message-ID: Subject: Re: What changes are welcome? From: "K. Macy" To: Randy Westlund Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 05:19:07 -0000 On Wed, May 18, 2016 at 9:11 PM, Randy Westlund wrote: > I'd like to start contributing to the base system, but I need > clarification on what sort of changes would be welcome. > > I thought I'd start on simple compiler warnings. The top code in > /contrib/top, for example uses K&R-style function definitions and > implicit return types that spews -Wimplicit-int and -Wreturn-type > warnings. > > While I'm silencing those, is it appropriate for me to make the file > follow style(9)? > > Once I have a diff, should I just upload it to bugzilla, or is it > preferable to put it on phabricator and then link to it from bugzilla? Phabricator is the place to put any patches you want reviewed. Just as important to understand as the technical is the social aspect. FreeBSD does not have a 6c equivalent to the Linux Foundation or large companies like Redhat where individuals are paid full-time to facilitate the import of contributions. You need to go out of your way to cultivate a rapport with one or more committers so that one of them will take time out of his day to commit your changes and potentially cope with any fallout. I contributed some changes a day or two ago and I broke the kernel build in a couple of arches :(. You're going to find that without such a rapport in place your patches are likely to be ignored or, if they're substantial, worse yet actually argued against. And if at first you're ignored, don't take it personally. FreeBSD is a collection of individuals, each with his or her own hot buttons and interests. -M From owner-freebsd-hackers@freebsd.org Thu May 19 06:33:18 2016 Return-Path: Delivered-To: freebsd-hackers@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 5F8BEB4126C for ; Thu, 19 May 2016 06:33:18 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 3257F19D4 for ; Thu, 19 May 2016 06:33:18 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9] (unknown [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 853631E14 for ; Thu, 19 May 2016 06:33:17 +0000 (UTC) Subject: Re: Update on EFI work: refactoring ready for testing, GELI coming very soon References: From: Eric McCorkle Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (13D15) In-Reply-To: Message-Id: Date: Thu, 19 May 2016 02:33:16 -0400 To: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 06:33:18 -0000 Update: GELI functionality is operational, with a GELI volume being detected= , a ZFS volume contained inside of it being detected and mounted, and a kern= el being loaded and booted from that filesystem. Kernel key injection is not yet implemented, as I promised to give until the= weekend for comments on my proposal. As such, it is not yet possible to co= mplete the boot process from a kernel loaded from a GELI volume. > On May 15, 2016, at 10:32, Eric McCorkle wrote: >=20 > Hello everyone, >=20 > I've been working on a rather significant refactoring of the EFI boot/load= er code. While this was originally in support of adding GELI support, it ha= s grown to such a scope that it could be considered a patch in its own right= . >=20 > The branch containing my work can be found here: https://github.com/emc2/f= reebsd/tree/efize >=20 > The following is a summary of the changes: > * Both boot1 and loader have been redesigned to look for instances of EFI_= SIMPLE_FILESYSTEM_PROTOCOL and load using that interface. In loader, this i= s accomplished through a new synthetic filesystem driver (called efifs) that= is just a wrapper around EFI_SIMPLE_FILESYSTEM_PROTOCOL. In boot, this is a= chieved by calling the interface directly. > * The efipart and filesystem back ends (including ZFS) have been moved int= o a drivers directory, where they have been wrapped up into a filesystem bac= kend driver that does the same probing that loader does today, and then inst= alls an EFI_SIMPLE_FILESYSTEM_INTERFACE on all device handles that host supp= orted filesystems. This interface is a wrapper around the filesystem interf= ace currently used by loader. > * boot now uses the same filesystem backend code as loader. This increase= d its size, necessitating recreation of the FAT templates. The old boot fil= esystem code and boot modules have been discarded. > * loader can use any protocol interface installed by boot just fine. Thes= e remain valid until ExitBootServices is called. Moreover, the probing proc= ess is idempotent, and is run by both boot and loader, with the first one to= run actually installing the interfaces. > * I had originally hoped to move the entire code base to use the EFI drive= r model, which would support hotplugging devices. However, the new bcache s= tuff currently requires that all devices be statically detected before the c= aches are used, which is fundamentally incompatible with this way of doing t= hings. This was the sole blocker of such a transition (the handles.c code r= equires some minor modification as well, but nothing problematic) > * I had also considered altering the device name code to use textual repre= sentations of EFI device paths, but I don't see any real reason for doing so= . > * I have not touched efinet or nfs in this changeset. >=20 > The rationale for these changes is as follows: > * The model of looking for EFI_SIMPLE_FILESYSTEM_PROTOCOL instances and us= ing them to load things increases interoperability with other systems. For e= xample, the new boot and loader would work just fine with interfaces install= ed by GRUB or another boot loader, or perhaps custom filesystem modules adde= d into an open-source firmware implementation like coreboot. > * This model works really well for functionality like GELI or custom parti= tion schemes that potentially create new devices. All you do is create one o= r more new device nodes, attach device paths and block io interfaces, and ca= ll ConnectController on them (for now, it's necessary to make sure the fs_dr= iver runs AFTER) all new nodes have been created. This also vastly simplifie= s passing information between stages about filesystems and devices (this is i= mportant for GELI). > * This approach can leverage drivers that are mandated by the EFI spec, li= ke the GPT partition driver. This avoids reimplementing such a driver to su= pport partition schemes nested inside GELI volumes, for example. > * This model provides most of the groundwork for supporting hot plugging o= f devices at boot time. All that is required at this point is a refactoring= of bcache to support adding new devices dynamically (I had to draw the line= somewhere, and this had already gotten big enough, and I want to focus on G= ELI support) > * Getting rid of the duplicated and minimized filesystem code in boot1 imp= roves maintainability. Indeed, the actual boot1 code is quite small now. >=20 > Some notes and future work: > * In general, the FreeBSD loader framework and the EFI framework do many s= imilar things. For the most part, there is a fairly direct mapping, though E= FI interfaces tend to be more tedious. The one thing EFI does decidedly bet= ter is support dynamic detection of devices (hotplugging). > * There are some interesting possibilities for hotplugging beyond just the= obvious. For example, loading GELI or other keys off of hotplugged USB sti= cks. > * I didn't touch efinet or nfs on this patch. It is certainly possible to= efize them as well, but I don't have a test setup for doing so (or frankly,= the motivation to do so). > * It might make more sense to use the EFI_LOAD_FILE_PROTOCOL to do the act= ual loading, as some applications support this without supporting a full fil= esystem interface (some embedded devices do this, as do some network boot pr= otocols). However, this would involve changing the non-EFI boot code and in= terfaces, which is something I specifically wanted to avoid in this work. >=20 > This changeset can be tested as is, and should just work. Disclaimer: I r= ebased it to head yesterday, and haven't had time to build and test it yet, b= ut I will. I know it works with ZFS, but I have no UFS systems on which to t= est that functionality. >=20 > If you intend to test this, I STRONGLY recommend installing an EFI shell o= n your ESP, and then installing the modified boot block under something like= boot.tst. This will allow you to run the modified boot block, but fall bac= k to a working boot if it fails. Also, I had modified the loader path to /b= oot/loader.tst for similar reasons, and it may still be set to that in the c= ode. >=20 > I am currently adding GELI support as a proper EFI driver, and should be c= oming in the very near future (the code is already written, in fact). If an= yone wants to test the refactoring by itself, any results or comments are ce= rtainly appreciated. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@freebsd.org Thu May 19 13:00:22 2016 Return-Path: Delivered-To: freebsd-hackers@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 E82ABB409EA for ; Thu, 19 May 2016 13:00:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 619CB10FF; Thu, 19 May 2016 13:00:21 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:UsHUtxUiFrc41XY5I3cx9XFmN0XV8LGtZVwlr6E/grcLSJyIuqrYZhOHt8tkgFKBZ4jH8fUM07OQ6PCxHzdaqsvd+Fk5M7VyFDY9wf0MmAIhBMPXQWbaF9XNKxIAIcJZSVV+9Gu6O0UGUOz3ZlnVv2HgpWVKQka3CwN5K6zPF5LIiIzvjqbpq8yVOF8D2Wb1SIgxBSv1hD2ZjtMRj4pmJ/R54TryiVwMRd5rw3h1L0mYhRf265T41pdi9yNNp6BprJYYAu3SNp41Rr1ADTkgL3t9pIiy7UGCHkOz4S5WcSNetxNDEkKNuBL/V5zgmiXgu+d3wyXcOtf5G+MaQzOnup1qQxygrS4MNDo09SmDkMl5h6FfrReJuhtw3oPQeIHTP/MoLfCVRs8TWWcUBpUZbCdGGI7pKtJXV+c= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CsBAD4tz1X/61jaINehA2BBK4XjW2FR0oCgXERAQEBAQEBAQFkJ4ItghYBBSMrHQMLEAIBCBgCAg0dIRAmAgQIKASHdAMXDrFvjS0NhFwFgQGFJIRNhBEQAgGFdAWXbBMyhgCKCYRPiGKPRwI2LIQJIIc5fwEBAQ X-IronPort-AV: E=Sophos;i="5.26,334,1459828800"; d="scan'208";a="282428167" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 19 May 2016 08:43:12 -0400 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 8F43015F594; Thu, 19 May 2016 08:43:12 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id qha5Vny4pDvc; Thu, 19 May 2016 08:43:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id D425815F59A; Thu, 19 May 2016 08:43:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 66obOFBPx_27; Thu, 19 May 2016 08:43:11 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id B834515F597; Thu, 19 May 2016 08:43:11 -0400 (EDT) Date: Thu, 19 May 2016 08:43:11 -0400 (EDT) From: Rick Macklem To: "K. Macy" Cc: Randy Westlund , freebsd-hackers@freebsd.org Message-ID: <606685411.106534014.1463661791680.JavaMail.zimbra@uoguelph.ca> In-Reply-To: References: <20160519041118.GE19887@gmail.com> Subject: Re: What changes are welcome? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF46 (Win)/8.0.9_GA_6191) Thread-Topic: What changes are welcome? Thread-Index: Ql0zmylDfMQu/o4uGYwBpNTKpuv2/A== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 13:00:23 -0000 K. Macy wrote: > On Wed, May 18, 2016 at 9:11 PM, Randy Westlund wrote: > > I'd like to start contributing to the base system, but I need > > clarification on what sort of changes would be welcome. > > > > I thought I'd start on simple compiler warnings. The top code in > > /contrib/top, for example uses K&R-style function definitions and > > implicit return types that spews -Wimplicit-int and -Wreturn-type > > warnings. > > > > While I'm silencing those, is it appropriate for me to make the file > > follow style(9)? > > Also, please note the following paragraph in style(9): In general code can be consider "new code" when it makes up about 50% or more of the file(s) involved. This is enough to break precedents in the existing code and use the current style(9)guidelines. Given this, I (others will disagree;-) wouldn't make style(9) changes that aren't required to fix the code unless you are re-writing a large part of the code. I'll also note that /contrib may not be a good place to start, since I think (not sure about userland) code in there is often taken from some upstream location and any changes done locally must be merged with upstream stuff each time it is updated. (I have no idea if /contrib/top is actually handled this way.) And, yes, as K. Macy noted, committers are pretty well all volunteers who work in certain areas of the code, so changes to some part of it they don't work in will probably be ignored unless it fixes something important. (For example, no one has recently been working on fuse. Since I am now using it, I have been coming up with some patches. I have not yet found anyone willing to review them, so I've been committing them without review. This is allowed in FreeBSD, but since fuse isn't my area of expertise, reviews would have been nice.) Most people start working on ports and become committers there and then src committers later. Btw, if you are interested in doing testing and review of fuse changes, you could email me. rick > > Once I have a diff, should I just upload it to bugzilla, or is it > > preferable to put it on phabricator and then link to it from bugzilla? > > Phabricator is the place to put any patches you want reviewed. > > > Just as important to understand as the technical is the social aspect. > FreeBSD does not have a 6c equivalent to the Linux Foundation or large > companies like Redhat where individuals are paid full-time to > facilitate the import of contributions. You need to go out of your way > to cultivate a rapport with one or more committers so that one of them > will take time out of his day to commit your changes and potentially > cope with any fallout. I contributed some changes a day or two ago and > I broke the kernel build in a couple of arches :(. You're going to > find that without such a rapport in place your patches are likely to > be ignored or, if they're substantial, worse yet actually argued > against. > > And if at first you're ignored, don't take it personally. FreeBSD is a > collection of individuals, each with his or her own hot buttons and > interests. > > -M > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Thu May 19 13:09:51 2016 Return-Path: Delivered-To: freebsd-hackers@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 D8302B40D65 for ; Thu, 19 May 2016 13:09:51 +0000 (UTC) (envelope-from sangeeta.manikonda@calsoftinc.com) Received: from mailrelay.nyi.net (mailrelay.nyi.net [64.90.175.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B616616C2 for ; Thu, 19 May 2016 13:09:51 +0000 (UTC) (envelope-from sangeeta.manikonda@calsoftinc.com) Received: from [114.143.187.14] (helo=csom.calsofthq.com) by mailrelay.nyi.net with smtp (Exim 4.63) (envelope-from ) id 1b3Nhe-0002Hy-EB for freebsd-hackers@freebsd.org; Thu, 19 May 2016 09:09:27 -0400 Received: from localhost (localhost [127.0.0.1]) by csom.calsofthq.com (Postfix) with ESMTP id E469DC050C for ; Thu, 19 May 2016 18:39:52 +0530 (IST) X-Virus-Scanned: Debian amavisd-new at csom2.calsoft.org Received: from csom.calsofthq.com ([127.0.0.1]) by localhost (csom.calsofthq.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id phUzzxqzwFsD for ; Thu, 19 May 2016 18:39:52 +0530 (IST) Received: from sangeeta.calsofthq.com (unknown [172.17.154.53]) by csom.calsofthq.com (Postfix) with ESMTPSA id 73DE0C031C for ; Thu, 19 May 2016 18:39:52 +0530 (IST) Message-ID: <573DBB14.7060507@calsoftinc.com> Date: Thu, 19 May 2016 18:39:40 +0530 From: sangeeta Manikonda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: FreeBSD CIFS share authentication using FreeIPA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 19 May 2016 13:41:02 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 13:09:51 -0000 Hi, I'm trying to configure FreeBSD to authenticate CIFS using LDAP + Kerberos exposed by FreeIPA. To achieve it, I started with configuration of FreeIPA client on FreeBSD 9.3, added it as a host on the freeIPA server on CentOS6. Second step was creating a CIFS share on FreeBSD and related configuration on FreeBSD. I'm stuck at this point and need some help to achieve it. Thanks. Sangeeta From owner-freebsd-hackers@freebsd.org Thu May 19 21:29:38 2016 Return-Path: Delivered-To: freebsd-hackers@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 B7C7BB41B53 for ; Thu, 19 May 2016 21:29:38 +0000 (UTC) (envelope-from rwestlun@gmail.com) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 721A812A4; Thu, 19 May 2016 21:29:38 +0000 (UTC) (envelope-from rwestlun@gmail.com) Received: by mail-qk0-x22f.google.com with SMTP id n63so56263680qkf.0; Thu, 19 May 2016 14:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=h5FwQomijjwUanPR6/lEscsJEbKg1oNSaFdByz9r0ew=; b=dmGOXSqxbKJdIY/ikyu+zsCh/hVKW3X3240vEngNA10nsaPbt9btUMUG3QkiioAz0k mZ88w1W200DaLEheH7TG5YMaf/uQG90JsMZSZrrqI0bzxl+pxkn9AHWXkxOfICKQIk/A HW5BN3RG47bH+g8MXRwyexbFuUu7z2xzOxoIBfEVx9C8awxkDSmaasApDMt840yF7oww VkcXzczYmZdMNr9/zuhOpFiFz53JKRvxoBo7wEvtAxEEIx+/OGudMBQxtMJ68pW4H1Q8 1fXACArITr6l46nftl03qCYfU65jZcRZ2OW1vCHU7ynpgyT1A9UHj8WfjnhGJzR5CrGv 30Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=h5FwQomijjwUanPR6/lEscsJEbKg1oNSaFdByz9r0ew=; b=JZH0niwqwpS5NT7wJoDn1FpoXAt0UI64NyTViBI52nVwN8rHFkyv9zGWvS6F56sdp1 rYOSEm73tZLhelSEbdOm4+SpdyqX+xfda1Pqbdzh1D8xJoUYQW4Vg2M8SYo5I1rlRCKw nqeK3p+wp2KcibhFcnrR5y+1rd93laXyyakisRKI3c0B3Q5FRhONJab54MN/j4q+d/oV D083HX1SK3aEOUi4AosktT9/jPEJPwczlJEgCBgXWaI0vRjkzwo9MFSCHyZjoaSNglxI Em50kxLUP1LP5o2z6uWIh1rBw1uPOLZpIwuH7oiAuw0GpbeMeigR9l3anPWBIB9Mb3OH GLiA== X-Gm-Message-State: AOPr4FVDHTnbdoQVIBCI12mg4bhWH/o58Pl1atzKDA3DHtAkDcbGFeFsCiu/UfjOKdZdYA== X-Received: by 10.55.33.102 with SMTP id h99mr17333993qkh.130.1463693377557; Thu, 19 May 2016 14:29:37 -0700 (PDT) Received: from gmail.com (c-98-216-247-110.hsd1.ma.comcast.net. [98.216.247.110]) by smtp.gmail.com with ESMTPSA id i206sm7417436qhi.9.2016.05.19.14.29.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 May 2016 14:29:36 -0700 (PDT) Date: Thu, 19 May 2016 17:29:34 -0400 From: Randy Westlund To: Allan Jude Cc: freebsd-hackers@freebsd.org Subject: Re: What changes are welcome? Message-ID: <20160519212934.GF19887@gmail.com> References: <20160519041118.GE19887@gmail.com> <573D3DA7.20600@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ls2Gy6y7jbHLe9Od" Content-Disposition: inline In-Reply-To: <573D3DA7.20600@freebsd.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 21:29:38 -0000 --Ls2Gy6y7jbHLe9Od Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 19, 2016 at 12:14:31AM -0400, Allan Jude wrote: > Generally, you likely want to avoid changing anything from contrib/ or > vendor/, as that is code from other projects that is imported, and local > changes complicate that. Of course, top is not really maintained > 'upstream' anymore, so maybe it isn't a bad place to start. >=20 > Phabricator is likely the best place for patches, it is much easier to > review. Indeed, looks like it's been 16 years. I silenced 131 warnings. https://reviews.freebsd.org/D6468 --Ls2Gy6y7jbHLe9Od Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXPjA+AAoJEGaweXjzNsmpEAcH/0sjaMBC/YQIi2oNtbTknBar HuXsk+gW1ob4W/yQ74fk8LN5AKV8NlGfrnSece+057/QZDJMRBRWMHqQK9RumP+P GdGFwJdeX29SV+CURAnENfCS5Is+Nra08Amkk/4h6b71yK1YCMSfwHSDSs5/0y3R EXQCdtLvSoiqyFfbER84iM3udLKgnZy2hOyxXwXzjWNu8Fh1OFaoHOcM7Ofegj6r zDC7SZkFTgQHlVi6IyrgtziBMTRDo8sfsmIfeLtoGdZh1gnRFBI3ZEDxBVPTwArM EBSiLZhI3fE5BTwKUBqX/0LKZdm0JQKUqdTvK7oGkJROwRcgnq9lcBwVUnA60Pc= =KHCd -----END PGP SIGNATURE----- --Ls2Gy6y7jbHLe9Od-- From owner-freebsd-hackers@freebsd.org Fri May 20 10:53:37 2016 Return-Path: Delivered-To: freebsd-hackers@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 80144B43BAD for ; Fri, 20 May 2016 10:53:37 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 3F9B31D5E for ; Fri, 20 May 2016 10:53:37 +0000 (UTC) (envelope-from ml@my.gd) Received: by mail-io0-x229.google.com with SMTP id f8so8794186ioe.3 for ; Fri, 20 May 2016 03:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=my-gd.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=mTw0zsSIpm4p8RTwPQ3bJaLeOLawrK82zw2pxi39B1A=; b=lONeF/9GKURvzpB6jsXXllFhWyyEIvS4UlvYAdGn8DmHNqAvPqyY2clLOa2abXhK1o HSDhTLIxwCtzAIzIkmun+XAyeqR9gks0k28IqqqHOPApPnspwScTAvB2aR+McvIBUtKI 2OZtEssQxk63gCWj1KbE2om8WSm7jabh6PvvpmXE8oYS+6y3GAltpwpCcudBGrxbua7S zKrdDAof2sXEB5bIeSlZ0K0xEh996DNK5elL2YXRgsQ9V1lDRvatlrpsOR7HXa2I0dPT rxXppk28MTWWm2omhtC9kRzSqSaFiKMyK9ghWavwbBTbNRMSkHRqBpru5lbrGrY9/4Y4 WdDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=mTw0zsSIpm4p8RTwPQ3bJaLeOLawrK82zw2pxi39B1A=; b=hinZPfm/BcGq26CI741SnY85xVV9N3G9CxG/QbrEW0TVEUmXzd7AyPNye6DyJQSBIb M9I5unyiKAnT6dMysZ5N3ye0Xnwpm/Ojy+1GT/ZCPgz/1Ue63nI5F+M7odWJ1ff5sOvx cEe+RDp+rOy+/TkwmT1x56WPdzXOMj/Y8OLZbwwOzbb1Z50qerxl55uTrxZoybFbDSAy P5sbM17uS2ODfXpKqdtpD3WWNW1rWVNRXaAVA8kzocd0VQP2MSUkVMuJL6VqBTn4R+D0 Ab0R3y83Vzb+tNyitWFCa6uL1Jsa1Zre81m46/7rN5K0IBGV0xTqIP0j7s7f0wrdH1K4 ui8g== X-Gm-Message-State: AOPr4FXdX9WK+pa+fA9PCeWhwrGPlCxheB50cgmtKvQAXyppxcijVDhFPCNtgGFSF5O9r+u1OaBPC1FzETad7g== MIME-Version: 1.0 X-Received: by 10.107.56.131 with SMTP id f125mr2294612ioa.188.1463741616576; Fri, 20 May 2016 03:53:36 -0700 (PDT) Received: by 10.79.124.93 with HTTP; Fri, 20 May 2016 03:53:36 -0700 (PDT) In-Reply-To: <20160519212934.GF19887@gmail.com> References: <20160519041118.GE19887@gmail.com> <573D3DA7.20600@freebsd.org> <20160519212934.GF19887@gmail.com> Date: Fri, 20 May 2016 12:53:36 +0200 Message-ID: Subject: Re: What changes are welcome? From: Damien Fleuriot To: freebsd-hackers@freebsd.org Cc: Allan Jude , Randy Westlund Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 10:53:37 -0000 On 19 May 2016 at 23:29, Randy Westlund wrote: > On Thu, May 19, 2016 at 12:14:31AM -0400, Allan Jude wrote: > > Generally, you likely want to avoid changing anything from contrib/ or > > vendor/, as that is code from other projects that is imported, and local > > changes complicate that. Of course, top is not really maintained > > 'upstream' anymore, so maybe it isn't a bad place to start. > > > > Phabricator is likely the best place for patches, it is much easier to > > review. > > Indeed, looks like it's been 16 years. I silenced 131 warnings. > > https://reviews.freebsd.org/D6468 > Sorry for hijacking ;) On the topic of contributing, there's a bug report I filed almost a year ago for net/relayd [1] The submitted change is very minor and mimics nginx's behaviour, adding a configuration sanity check before restarting or reloading net/relayd. Is there a better place for me to submit this, or would someone have the spare time to take a look ? Cheers :) [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200914 From owner-freebsd-hackers@freebsd.org Fri May 20 11:34:35 2016 Return-Path: Delivered-To: freebsd-hackers@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 DD53FB43D67 for ; Fri, 20 May 2016 11:34:35 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.0x20.net", Issuer "mail.0x20.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A53511776; Fri, 20 May 2016 11:34:35 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 0F4B26E0081; Fri, 20 May 2016 13:34:33 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id u4KBYWJd089237; Fri, 20 May 2016 13:34:32 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id u4KBYWvW088869; Fri, 20 May 2016 13:34:32 +0200 (CEST) (envelope-from lars) Date: Fri, 20 May 2016 13:34:32 +0200 From: Lars Engels To: Damien Fleuriot Cc: freebsd-hackers@freebsd.org, Randy Westlund , Allan Jude Subject: Re: What changes are welcome? Message-ID: <20160520113431.GW15808@e-new.0x20.net> References: <20160519041118.GE19887@gmail.com> <573D3DA7.20600@freebsd.org> <20160519212934.GF19887@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+rRWuC8ZLvVekNoN" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 11:34:36 -0000 --+rRWuC8ZLvVekNoN Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 20, 2016 at 12:53:36PM +0200, Damien Fleuriot wrote: > On 19 May 2016 at 23:29, Randy Westlund wrote: >=20 > > On Thu, May 19, 2016 at 12:14:31AM -0400, Allan Jude wrote: > > > Generally, you likely want to avoid changing anything from contrib/ or > > > vendor/, as that is code from other projects that is imported, and lo= cal > > > changes complicate that. Of course, top is not really maintained > > > 'upstream' anymore, so maybe it isn't a bad place to start. > > > > > > Phabricator is likely the best place for patches, it is much easier to > > > review. > > > > Indeed, looks like it's been 16 years. I silenced 131 warnings. > > > > https://reviews.freebsd.org/D6468 > > >=20 >=20 > Sorry for hijacking ;) >=20 >=20 >=20 > On the topic of contributing, there's a bug report I filed almost a year > ago for net/relayd [1] >=20 > The submitted change is very minor and mimics nginx's behaviour, adding a > configuration sanity check before restarting or reloading net/relayd. >=20 >=20 > Is there a better place for me to submit this, or would someone have the > spare time to take a look ? Yes, ports@ would be a better place. :) --+rRWuC8ZLvVekNoN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF8BAEBCgBmBQJXPvZHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tiBQH/2gQrImjZP39CkeUYs3K4WwH 7QAIsfcqySikhKLl31uaYYE93SEPNSEXdL+YztUaAHvOSbKJCfZSPes5+4V5ROD1 ti8MkWhgxi8DdjeIW/ilkyZyn/t+OsRGFg6libdxxhQLni3ICDvK/YKelbV2gvHf Rl5CXLb0zWk9AWuxTCr1ri5J2QBBvOAH97qx9zJJFVRyV83SEtMOTngRTzbEyzvB mYuyrzMALtkrOgXVYsja++BDlVR0GETkSRyjtrIFBGMilR6z5MYvMSxI4YIj1Vhh /Stm1qen7UcOVg2hC5/+fV6Grw3VhMAwqk4ea+V6PYYUphFo6kuGBnVKZVxWPDY= =Dsme -----END PGP SIGNATURE----- --+rRWuC8ZLvVekNoN-- From owner-freebsd-hackers@freebsd.org Fri May 20 12:00:15 2016 Return-Path: Delivered-To: freebsd-hackers@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 CAD63B438A3 for ; Fri, 20 May 2016 12:00:15 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 9267B16E2 for ; Fri, 20 May 2016 12:00:15 +0000 (UTC) (envelope-from ml@my.gd) Received: by mail-io0-x22d.google.com with SMTP id f8so10425514ioe.3 for ; Fri, 20 May 2016 05:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=my-gd.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ZNjJgRgOD8gkjU3aozgATQHsATJy2ajM8KoqJmgAAI4=; b=Owp/pcq7aWqynIzwLZHxX4LmN34YY//wEdO/KrdM+RN6W1rGkQPWqSRjTTnhzXVfY0 K4flSJLp37vmRNJv+m2z7QYoFcOjLSE6WlCWW8d1d2JFa0N+OnizdnC8Md9lw0SMhebG y4gKEI81ubsz11nehMd120OO4dDYbmwU/SjbPzL0FdrvWuNiySwLU0QWClPmulzBhp5M zpI9IspLsZMEx/Yl8nvDIYRFcROubTqnh8kLkjRNkweqGfTWnVG1tjhjyFcia7/uVd/e uSv8x33ReCExJYA9xiSE2XaDr3syaKAo2d9BVIivBh15MsHb6eP27CLJ70iszak8tZEE 7FaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ZNjJgRgOD8gkjU3aozgATQHsATJy2ajM8KoqJmgAAI4=; b=m2C/P+Q+HezX1KvCZk0ROWC2fpLBOhbl0AXy/0dUC+jqcPvDaf2HC81nd3p5p5Rb9U Ms0K8HMJ67ayFiLGakc0IZU+8PH1giruMkdzpudIt9biXqH0/bLQRkDyu477+PXfbJqx HAYO7KXTG8UHGLdyZbBtGgvtc8G0D2bFvAWUKmJPrT2O1GL0dcO9N899KA85IAqjo6Z2 8uNcm+/9Qq/padvPR3lTHixUp2ynge2h2VaznrZh9+W7ANewsI5yi8LbXOQcOyO2dWvx 3dX1xqXp4oqZSXnKWLz0ZjcaNOCoEPeJWa0TVFvHVo+aQlGqkx8D4OmZ6t0dCJmPNReV rfng== X-Gm-Message-State: AOPr4FUrmHyvQ1vXNOX/qzw0o0bXhtzWIXjoxmq0pVkDAZF3B4t7P3vwOuc5G5ZLiU2xHG4pv8dg8Z76+blLDw== MIME-Version: 1.0 X-Received: by 10.36.149.215 with SMTP id m206mr2741158itd.20.1463745611128; Fri, 20 May 2016 05:00:11 -0700 (PDT) Received: by 10.79.124.93 with HTTP; Fri, 20 May 2016 05:00:11 -0700 (PDT) In-Reply-To: <20160520113431.GW15808@e-new.0x20.net> References: <20160519041118.GE19887@gmail.com> <573D3DA7.20600@freebsd.org> <20160519212934.GF19887@gmail.com> <20160520113431.GW15808@e-new.0x20.net> Date: Fri, 20 May 2016 14:00:11 +0200 Message-ID: Subject: Re: What changes are welcome? From: Damien Fleuriot To: Lars Engels Cc: freebsd-hackers@freebsd.org, Randy Westlund , Allan Jude Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 12:00:15 -0000 On 20 May 2016 at 13:34, Lars Engels wrote: > On Fri, May 20, 2016 at 12:53:36PM +0200, Damien Fleuriot wrote: > > On 19 May 2016 at 23:29, Randy Westlund wrote: > > > > > On Thu, May 19, 2016 at 12:14:31AM -0400, Allan Jude wrote: > > > > Generally, you likely want to avoid changing anything from contrib/ > or > > > > vendor/, as that is code from other projects that is imported, and > local > > > > changes complicate that. Of course, top is not really maintained > > > > 'upstream' anymore, so maybe it isn't a bad place to start. > > > > > > > > Phabricator is likely the best place for patches, it is much easier > to > > > > review. > > > > > > Indeed, looks like it's been 16 years. I silenced 131 warnings. > > > > > > https://reviews.freebsd.org/D6468 > > > > > > > > > Sorry for hijacking ;) > > > > > > > > On the topic of contributing, there's a bug report I filed almost a year > > ago for net/relayd [1] > > > > The submitted change is very minor and mimics nginx's behaviour, adding a > > configuration sanity check before restarting or reloading net/relayd. > > > > > > Is there a better place for me to submit this, or would someone have the > > spare time to take a look ? > > Yes, ports@ would be a better place. :) > Yeah been there, done that... Since it's been almost a year however, I'll give it another go ;) From owner-freebsd-hackers@freebsd.org Sat May 21 13:27:04 2016 Return-Path: Delivered-To: freebsd-hackers@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 2968AB45630 for ; Sat, 21 May 2016 13:27:04 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A80F119CC for ; Sat, 21 May 2016 13:27:03 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.14.9) with ESMTPS id u4LDK4UR089867 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 21 May 2016 15:20:04 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id u4LDK3Rm023008 for ; Sat, 21 May 2016 15:20:03 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id u4LDJwWC023005 for ; Sat, 21 May 2016 15:19:58 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Sat, 21 May 2016 15:19:58 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: freebsd-hackers@freebsd.org Subject: arp proxy question Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Sat, 21 May 2016 15:20:04 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 13:27:04 -0000 i added pub entry in ARP table ? (XX.YY.ZZ.92) at d4:ae:52:bb:82:4f on bge0 permanent published [ethernet] (normal server addresses are .90 and .91) and run vtun tunnel to other computer from this server tunneling this .92 address there. tunnel works fine tun2: flags=8051 metric 0 mtu 1500 options=80000 inet XX.YY.ZZ.90 --> XX.YY.ZZ.92 netmask 0xffffffff Opened by PID 81626 the result is as below: # ping XX.YY.ZZ.92 PING XX.YY.ZZ.92 (XX.YY.ZZ.92): 56 data bytes 36 bytes from XX.YY.ZZ.92: Destination Host Unreachable Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 ee9c 0 0000 40 01 e752 XX.YY.ZZ.90 XX.YY.ZZ.92 64 bytes from XX.YY.ZZ.92: icmp_seq=1 ttl=64 time=10.788 ms 64 bytes from XX.YY.ZZ.92: icmp_seq=2 ttl=64 time=12.254 ms except this above everything is OK. what i do wrong? From owner-freebsd-hackers@freebsd.org Sat May 21 14:12:09 2016 Return-Path: Delivered-To: freebsd-hackers@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 DD516B45E69 for ; Sat, 21 May 2016 14:12:09 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id C35781D13 for ; Sat, 21 May 2016 14:12:09 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 6374CD03C for ; Sat, 21 May 2016 14:12:03 +0000 (UTC) Subject: Re: arp proxy question To: freebsd-hackers@freebsd.org References: From: Allan Jude Message-ID: <57406CB2.6000804@freebsd.org> Date: Sat, 21 May 2016 10:12:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 14:12:10 -0000 On 2016-05-21 09:19, Wojciech Puchar wrote: > i added pub entry in ARP table > > ? (XX.YY.ZZ.92) at d4:ae:52:bb:82:4f on bge0 permanent published [ethernet] > > (normal server addresses are .90 and .91) > > and run vtun tunnel to other computer from this server tunneling this > .92 address there. > > tunnel works fine > > tun2: flags=8051 metric 0 mtu 1500 > options=80000 > inet XX.YY.ZZ.90 --> XX.YY.ZZ.92 netmask 0xffffffff > Opened by PID 81626 > > > the result is as below: > > # ping XX.YY.ZZ.92 > PING XX.YY.ZZ.92 (XX.YY.ZZ.92): 56 data bytes > 36 bytes from XX.YY.ZZ.92: Destination Host Unreachable > Vr HL TOS Len ID Flg off TTL Pro cks Src Dst > 4 5 00 0054 ee9c 0 0000 40 01 e752 XX.YY.ZZ.90 XX.YY.ZZ.92 > > 64 bytes from XX.YY.ZZ.92: icmp_seq=1 ttl=64 time=10.788 ms > 64 bytes from XX.YY.ZZ.92: icmp_seq=2 ttl=64 time=12.254 ms > > except this above everything is OK. > > what i do wrong? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" Do you have the arp proxy sysctl enabled? sysctl net.link.ether.inet.proxyall=1 -- Allan Jude From owner-freebsd-hackers@freebsd.org Sat May 21 14:16:53 2016 Return-Path: Delivered-To: freebsd-hackers@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 2B2E0B45F3A for ; Sat, 21 May 2016 14:16:53 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 99EEE1EAC; Sat, 21 May 2016 14:16:52 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.14.9) with ESMTPS id u4LEGnaB091454 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 21 May 2016 16:16:50 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id u4LEGmYb024578; Sat, 21 May 2016 16:16:48 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id u4LEGh9D024575; Sat, 21 May 2016 16:16:43 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Sat, 21 May 2016 16:16:43 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: Allan Jude cc: freebsd-hackers@freebsd.org Subject: Re: arp proxy question In-Reply-To: <57406CB2.6000804@freebsd.org> Message-ID: References: <57406CB2.6000804@freebsd.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Sat, 21 May 2016 16:16:50 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 14:16:53 -0000 On Sat, 21 May 2016, Allan Jude wrote: > On 2016-05-21 09:19, Wojciech Puchar wrote: >> i added pub entry in ARP table >> >> ? (XX.YY.ZZ.92) at d4:ae:52:bb:82:4f on bge0 permanent published [ethernet] >> >> (normal server addresses are .90 and .91) >> >> and run vtun tunnel to other computer from this server tunneling this >> .92 address there. >> >> tunnel works fine >> >> tun2: flags=8051 metric 0 mtu 1500 >> options=80000 >> inet XX.YY.ZZ.90 --> XX.YY.ZZ.92 netmask 0xffffffff >> Opened by PID 81626 >> >> >> the result is as below: >> >> # ping XX.YY.ZZ.92 >> PING XX.YY.ZZ.92 (XX.YY.ZZ.92): 56 data bytes >> 36 bytes from XX.YY.ZZ.92: Destination Host Unreachable >> Vr HL TOS Len ID Flg off TTL Pro cks Src Dst >> 4 5 00 0054 ee9c 0 0000 40 01 e752 XX.YY.ZZ.90 XX.YY.ZZ.92 >> >> 64 bytes from XX.YY.ZZ.92: icmp_seq=1 ttl=64 time=10.788 ms >> 64 bytes from XX.YY.ZZ.92: icmp_seq=2 ttl=64 time=12.254 ms >> >> except this above everything is OK. >> >> what i do wrong? >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > Do you have the arp proxy sysctl enabled? > > sysctl net.link.ether.inet.proxyall=1 > changed and no effect.