From owner-freebsd-arch@FreeBSD.ORG Wed Jun 10 20:23:32 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10D74845 for ; Wed, 10 Jun 2015 20:23:32 +0000 (UTC) (envelope-from stefan.andritoiu@gmail.com) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (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 CCDDE16AD for ; Wed, 10 Jun 2015 20:23:31 +0000 (UTC) (envelope-from stefan.andritoiu@gmail.com) Received: by oiav1 with SMTP id v1so712205oia.0 for ; Wed, 10 Jun 2015 13:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jlxV0A7Y7cO2zwg4jE5bhg1yZpOJE4PEw3t7WWgwkqk=; b=XD6FvTHZY+AjpgCK3c9+Td+PhQDW9cWUnKX+4gOHHUYAyx24+202sOG9NTwDBakTyu KDY0RohrQ0xgmGDtUBISeb8P9fX1vQo7aSWgB7kuTLPP77Sa+oqwsJY1EqAYROUZ0wPv Xj1PaMRGN5OgjnaePjqN9YTXAeH6e4DPUtYXt1HMtcfZiR6Xv9Rpof9J0TDVyJmn+2XZ jX0H3Iu6K7E9dvK+do+IB0f8B+OH5i+aDW/4aAxNRPtR0OKBckbSWTuiaryihqUhF3HE V+7QGRaDmJJ5S5tJAA7FbRGPxX2iG3A6OtYmoXbYmZ+ZYpnotGxYX95wU7akhrclve+t U/PQ== MIME-Version: 1.0 X-Received: by 10.182.20.232 with SMTP id q8mr4406983obe.83.1433967811149; Wed, 10 Jun 2015 13:23:31 -0700 (PDT) Received: by 10.60.82.168 with HTTP; Wed, 10 Jun 2015 13:23:31 -0700 (PDT) Date: Wed, 10 Jun 2015 23:23:31 +0300 Message-ID: Subject: [Gang scheduling implementation in the ULE scheduler] Problem with sending IPIs to other CPUs From: Stefan Andritoiu To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 20:23:32 -0000 Hello, I am currently working on a gang scheduling implementation for the bhyve VCPU-threads on FreeBSD 10.1. I have added a new field "int gang" to the thread structure to specify the gang it is part of (0 for no gang), and have modified the bhyve code to initialize this field when a VCPU is created. I will post these modifications in another message. When I start a Virtual Machine, during the guest's boot, IPIs are sent and received correctly between CPUs, but after a few seconds I get: spin lock 0xffffffff8164c290 (smp rendezvous) held by 0xfffff8000296c000 (tid 100009) too long panic: spin lock held too long If I limit the number of IPIs that are sent, I do not have this problem. Which leads me to believe that (because of the constant context-switch when the guest boots), the high number of IPIs sent starve the system. Does anyone know what is happening? And maybe know of a possible solution? Thank you, Stefan ====================================================================================== I have added here the modifications to the sched_ule.c file and a brief explanation of it: In struct tdq, I have added two new field: - int scheduled_gang; /* Set to a non-zero value if the respective CPU is required to schedule a thread belonging to a gang. The value of scheduled_gang also being the ID of the gang that we want scheduled. For now I have considered only one running guest, so the value is 0 or 1 */ - int gang_leader; /* Set if the respective CPU is the one who has initialized gang scheduling. Zero otherwise. Not relevant to the final code and will be removed. Just for debugging purposes. */ Created a new function "static void schedule_gang(void * arg)" that will be called by each processor when it receives an IPI from the gang leader: - sets scheduled_gang = 1 - informs the system that it needs to reschedule. Not yet implemented In function "struct thread* tdq_choose (struct tdq * tdq)": if (tdq->scheduled_gang) - checks to see if a thread belonging to a gang must be scheduled. If so, calls functions that check the runqs and return a gang thread. I have yet to implement these functions. In function "sched_choose()": if (td->gang) - checks if the chosen thread is part of a gang. If so it signals all other CPUs to run function "schedule_gang(void * gang)". if (tdq->scheduled_gang) - if scheduled_gang is set it means that the scheduler is called after the the code in schedule_gang() has ran, and bypasses sending IPIs to the other CPUs. If not for this checkup, a CPU would receive a IPI; set scheduled_gang=1; the scheduler would be called and would choose a thread to run; that thread would be part of a gang; an IPI would be sent to all other CPUs. A constant back-and-forth of IPIs between the CPUs would be created. The CPU that initializes gang scheduling, does not receive an IPI, and does not even call the "schedule_gang(void * gang)" function. It continues in scheduling the gang-thread it selected, the one that started the gang scheduling process. =================================================================== --- sched_ule.c (revision 24) +++ sched_ule.c (revision 26) @@ -247,6 +247,9 @@ struct runq tdq_timeshare; /* timeshare run queue. */ struct runq tdq_idle; /* Queue of IDLE threads. */ char tdq_name[TDQ_NAME_LEN]; + + int gang_leader; + int scheduled_gang; #ifdef KTR char tdq_loadname[TDQ_LOADNAME_LEN]; #endif @@ -1308,6 +1311,20 @@ struct thread *td; TDQ_LOCK_ASSERT(tdq, MA_OWNED); + + /* Pick gang thread to run */ + if (tdq->scheduled_gang){ + /* basically the normal choosing of threads but with regards to scheduled_gang + tdq = runq_choose_gang(&tdq->realtime); + if (td != NULL) + return (td); + + td = runq_choose_from_gang(&tdq->tdq_timeshare, tdq->tdq_ridx); + if (td != NULL) + return (td); + */ + } + td = runq_choose(&tdq->tdq_realtime); if (td != NULL) return (td); @@ -2295,6 +2312,22 @@ return (load); } +static void +schedule_gang(void * arg){ + struct tdq *tdq; + struct tdq *from_tdq = arg; + tdq = TDQ_SELF(); + + if(tdq == from_tdq){ + /* Just for testing IPI. Code is never reached, and should never be*/ + tdq->scheduled_gang = 1; +// printf("[schedule_gang] received IPI from himself\n"); + } + else{ + tdq->scheduled_gang = 1; +// printf("[schedule_gang] received on cpu: %s \n", tdq->tdq_name); + } +} /* * Choose the highest priority thread to run. The thread is removed from * the run-queue while running however the load remains. For SMP we set @@ -2305,11 +2338,26 @@ { struct thread *td; struct tdq *tdq; + cpuset_t map; tdq = TDQ_SELF(); TDQ_LOCK_ASSERT(tdq, MA_OWNED); td = tdq_choose(tdq); if (td) { + if(tdq->scheduled_gang){ + /* Scheduler called after IPI + jump over rendezvous*/ + tdq->scheduled_gang = 0; + } + else{ + if(td->gang){ + map = all_cpus; + CPU_CLR(curcpu, &map); + + smp_rendezvous_cpus(map, NULL, schedule_gang, NULL, tdq); + } + } + tdq_runq_rem(tdq, td); tdq->tdq_lowpri = td->td_priority; return (td); From owner-freebsd-arch@FreeBSD.ORG Wed Jun 10 22:46:59 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A88F412 for ; Wed, 10 Jun 2015 22:46:59 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E5EA91ADA for ; Wed, 10 Jun 2015 22:46:55 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t5AMks2f062201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Jun 2015 15:46:54 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t5AMksbi062200 for arch@FreeBSD.org; Wed, 10 Jun 2015 15:46:54 -0700 (PDT) (envelope-from jmg) Date: Wed, 10 Jun 2015 15:46:54 -0700 From: John-Mark Gurney To: arch@FreeBSD.org Subject: compiling parts of kernel in userland Message-ID: <20150610224654.GM86224@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Wed, 10 Jun 2015 15:46:54 -0700 (PDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 22:46:59 -0000 I'm not the only one doing this (libzpool does this w/ zfs_context.h), but what do we need to do to make it easier/more standard to be able to compile kernel code into a userland program for testing and other purposes. I know I'm now the only one to do it, but I can't seem to find any docs on how people are doing this, and exactly what issues people have run into when doing this. My goal is to have documentation and integrated necessary code into FreeBSD to make this as simple as possible. My main goal is to make it easier to compile kernel code into userland test harnesses. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Thu Jun 11 05:13:24 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F12F0313 for ; Thu, 11 Jun 2015 05:13:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (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 BC6131AF6 for ; Thu, 11 Jun 2015 05:13:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iebmu5 with SMTP id mu5so46578943ieb.1 for ; Wed, 10 Jun 2015 22:13:24 -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:content-type; bh=4BHT4r2d/7Tjoy9Vp8wNN2t8tp9GmLv0ZGzeTAqgvkg=; b=A/M7ix38wxJMMnO4+4FtLvM/ofRWc27w36x1rYhrY0OTzYPVROuWTAZ+rHzD5VLzq/ MPX9DlgsWEa1bNw+3NGa3GlHwdkbMOjsSHVHKWj8BZH02r8GRkXRws0/GixwFG2wBc5A GKq7cidf20K70i+DC0DFJ2PeiIXIGxWKSEeJlhhMjzP3nO+0IF/JtEhLYZSBvuVI4cGV aap9vjHIgSNIwZBFzLj8ox3fW+W9I9zc8+//b6m9aaN/9SKSXNJbZZg4cLgRmRkcU2xM d72XA6LfY2bCbWzeZnk26lw54kJM5qmWQq9vr4JOekSxKvTcTUvB5M39o3OyFozi/Rdp 1ffA== MIME-Version: 1.0 X-Received: by 10.50.97.105 with SMTP id dz9mr10269418igb.49.1433999604090; Wed, 10 Jun 2015 22:13:24 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Wed, 10 Jun 2015 22:13:24 -0700 (PDT) In-Reply-To: <20150610224654.GM86224@funkthat.com> References: <20150610224654.GM86224@funkthat.com> Date: Wed, 10 Jun 2015 22:13:24 -0700 X-Google-Sender-Auth: 3YEd5fzkoXvibkTPy501ZvswtBY Message-ID: Subject: Re: compiling parts of kernel in userland From: Adrian Chadd To: John-Mark Gurney Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 05:13:25 -0000 Hi, please look at libuinet. I'd really like the libuinet framework to be in freebsd-head so we can build various forms of the freebsd kernel as userland support code. -a On 10 June 2015 at 15:46, John-Mark Gurney wrote: > I'm not the only one doing this (libzpool does this w/ zfs_context.h), > but what do we need to do to make it easier/more standard to be able > to compile kernel code into a userland program for testing and other > purposes. > > I know I'm now the only one to do it, but I can't seem to find any > docs on how people are doing this, and exactly what issues people have > run into when doing this. > > My goal is to have documentation and integrated necessary code into > FreeBSD to make this as simple as possible. My main goal is to make > it easier to compile kernel code into userland test harnesses. > > Thanks. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Thu Jun 11 06:48:09 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B1A646C; Thu, 11 Jun 2015 06:48:09 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-pa0-x241.google.com (mail-pa0-x241.google.com [IPv6:2607:f8b0:400e:c03::241]) (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 2B26910E0; Thu, 11 Jun 2015 06:48:09 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by pablj1 with SMTP id lj1so14708045pab.0; Wed, 10 Jun 2015 23:48:08 -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:content-type; bh=/D3PGVFx+U29k20wfKNbK+vKuMnQb/BjH4qKUQ09RlE=; b=lgTRX2LtdAc9zjMHFJTxj0uCtEenx6AS9+1DRSghP2poo0rsvMwEp468Hah4RquHBX qZKoVlELn/fZkHRP3qwogMCUkEvUVw1jhga9P+oiQZ7lwqo4C9L2ZN4agDEyqj2YT/oK p6SWBVRtnveF2q+KvFrxJeaN4WJgKZJGiuK4yOpZbVd6Wdz+gJid+DcP2UcAFCwM/qVU l55D/RqDxs4zRvPV0rsVsl4bmvN128X23cDqvs5D7hABZDS3mT6KOnmE7G8HeNr2w+HB sygzPHdHEnjc1PVCedl3fuutYOZB2yBhsh0E1fzETk0EVpwtSrQUa2QrFvMnDKOA4six cErg== MIME-Version: 1.0 X-Received: by 10.66.66.65 with SMTP id d1mr12396064pat.22.1434005288284; Wed, 10 Jun 2015 23:48:08 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.66.236.36 with HTTP; Wed, 10 Jun 2015 23:48:08 -0700 (PDT) Received: by 10.66.236.36 with HTTP; Wed, 10 Jun 2015 23:48:08 -0700 (PDT) In-Reply-To: References: <20150610224654.GM86224@funkthat.com> Date: Wed, 10 Jun 2015 23:48:08 -0700 X-Google-Sender-Auth: JQ9YA0U1jFvuy_jnpka29zYnv1o Message-ID: Subject: Re: compiling parts of kernel in userland From: "K. Macy" To: Adrian Chadd Cc: arch@freebsd.org, John-Mark Gurney Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 06:48:09 -0000 I started work on something I called libukern which allows you to run essentially all non platform code in user adding a PCI passthrough driver so one can run unmodified drivers in user. Libuinet is great as far as it goes, but it's just the network stack. If you want something other than just networking you'll have to do something else. -K On Jun 10, 2015 10:13 PM, "Adrian Chadd" wrote: > Hi, > > please look at libuinet. I'd really like the libuinet framework to be > in freebsd-head so we can build various forms of the freebsd kernel as > userland support code. > > > -a > > > On 10 June 2015 at 15:46, John-Mark Gurney wrote: > > I'm not the only one doing this (libzpool does this w/ zfs_context.h), > > but what do we need to do to make it easier/more standard to be able > > to compile kernel code into a userland program for testing and other > > purposes. > > > > I know I'm now the only one to do it, but I can't seem to find any > > docs on how people are doing this, and exactly what issues people have > > run into when doing this. > > > > My goal is to have documentation and integrated necessary code into > > FreeBSD to make this as simple as possible. My main goal is to make > > it easier to compile kernel code into userland test harnesses. > > > > Thanks. > > > > -- > > John-Mark Gurney Voice: +1 415 225 5579 > > > > "All that I will do, has been done, All that I have, has not." > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Thu Jun 11 06:53:12 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 831A963F; Thu, 11 Jun 2015 06:53:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (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 377C1145B; Thu, 11 Jun 2015 06:53:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by qkcv189 with SMTP id v189so8432996qkc.2; Wed, 10 Jun 2015 23:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=/4CifM9lS4btfBEJ7kqJB9gmy+nusQdw3bH51WqvAkg=; b=p4RvsrETwpMUTJrlLULX9LA40qq83wpEz4ysImLmhwUbbQEzsjJo2bqPnmk1y1YDvu 1iy8i/aqeKNcxf89r6TqhvPQV2Axl+eKNESRvYIoKIxYI/ootWaWmtor2ZiD4SZVPsKp 0GCb8tciS1OKvOg7e2XkCN5YjH6+lY17hs0RPw3mX3dfmftkE4wu5p5vXWu1QDJIBc62 EwjgFBlc+7TwiDCY0jQNdIwpQCAcmUgkFYqHOu20oqS3530+D0NZ5GfCdadEUM7P9ano 9WuoqHclLkJ3lHy1pOvcXbW6P78DDqd8voXRTROITCDF66hvtTlCKZyk5tGk1RDyTPrV wGaQ== X-Received: by 10.55.20.136 with SMTP id 8mr15514830qku.8.1434005591191; Wed, 10 Jun 2015 23:53:11 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:99d4:e155:4cfb:c95a? ([2601:8:ab80:7d6:99d4:e155:4cfb:c95a]) by mx.google.com with ESMTPSA id e69sm5227997qkh.19.2015.06.10.23.53.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Jun 2015 23:53:10 -0700 (PDT) Subject: Re: compiling parts of kernel in userland Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_EC27A3DA-3B84-4423-AF4B-E7D9B6C51F43"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Garrett Cooper In-Reply-To: Date: Wed, 10 Jun 2015 23:53:08 -0700 Cc: Adrian Chadd , arch@freebsd.org, John-Mark Gurney , "freebsd-testing@freebsd.org" Message-Id: <5E0E3EAE-F184-478F-B2A0-D3FAB71ADB20@gmail.com> References: <20150610224654.GM86224@funkthat.com> To: "K. Macy" X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 06:53:12 -0000 --Apple-Mail=_EC27A3DA-3B84-4423-AF4B-E7D9B6C51F43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 (Adding -testing because this pertains to testing) On Jun 10, 2015, at 23:48, K. Macy wrote: > I started work on something I called libukern which allows you to run > essentially all non platform code in user adding a PCI passthrough = driver > so one can run unmodified drivers in user. Libuinet is great as far as = it > goes, but it's just the network stack. If you want something other = than > just networking you'll have to do something else. If I had enough time and interest I=92d look at investing my efforts in = porting RUMP from NetBSD to FreeBSD and going about it that route, but = I=92m busy with other efforts so I can=92t dedicate my time here yet. It = seems like RUMP is the direction we should be going in=85 Thanks, -NGie --Apple-Mail=_EC27A3DA-3B84-4423-AF4B-E7D9B6C51F43 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVeTBVAAoJEMZr5QU6S73eG/kH/2V4jYDn3pDmF/zWVu3sUgKt /ynWHnAERPKDXDbQPu37cyFD8IwwhEx3XB4gPkSqnj7r34sy4Vaua1qK4Vc21L3Y H4Hlely7kUCJ7bknbTPCDhnsUSsCt/B81LvoeY5PaS8mz+GQQQgtRmrV3/vQP/xy tY6LD9SfoMOgE5i7+5zzp2FvcQ/0OX9dTsjffKYTQTdnOTHB79yPtEHgNth/9y37 oel4Toxzoq0W88Gbv2WI5gtW6CHmSQ2oHCU5EZIvGnsMqDGm3NUO0k2lxT0KRfIY hLXBz6J6XdIWApgtsxSQbWwwhN9QF1HHQKaAOnwvdCX+73kjDAga4hzZiEqXPmc= =WmbU -----END PGP SIGNATURE----- --Apple-Mail=_EC27A3DA-3B84-4423-AF4B-E7D9B6C51F43-- From owner-freebsd-arch@FreeBSD.ORG Thu Jun 11 06:56:31 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 677E6736; Thu, 11 Jun 2015 06:56:31 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-pa0-x243.google.com (mail-pa0-x243.google.com [IPv6:2607:f8b0:400e:c03::243]) (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 35A90148F; Thu, 11 Jun 2015 06:56:31 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by pabli10 with SMTP id li10so14701423pab.2; Wed, 10 Jun 2015 23:56:30 -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:content-type; bh=U92FpxExSA+nLAV89mbK/2vOoDs+H5OlUYHYdSP4Fmc=; b=O/upn+dQq+Ma9dBPVZvIw4g957MKyuO5sxf7m2+j+CeGo4nmYnQzHP4fju9I9N/I6K QcneRHeovjtK7n7sqQOWhg3ZDdWrWb+4rEXiirDpjrPE6v3FuMyL4m5IHCbEbGvLumKU iMP44rqfe04PdK9kXYgdP4h5V6Uc3RYpCKdyz7C7wKOg8Rpte67ppRBH3WZDwijPDCFj maeXfXZiXBBRQYxS3wNySWIyu/t78EUDXsIJ21FZj6Q/U9txj/WJhQvx2J/JSiPRhwvM estEZNBt8ewkFVZuBhEW9SzAwlNDeLvng09I6Wnpkqi2q2FQPya+2yebeP/MxsUPHAb9 cgeQ== MIME-Version: 1.0 X-Received: by 10.70.128.13 with SMTP id nk13mr12233200pdb.21.1434005790804; Wed, 10 Jun 2015 23:56:30 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.66.236.36 with HTTP; Wed, 10 Jun 2015 23:56:30 -0700 (PDT) Received: by 10.66.236.36 with HTTP; Wed, 10 Jun 2015 23:56:30 -0700 (PDT) In-Reply-To: <5E0E3EAE-F184-478F-B2A0-D3FAB71ADB20@gmail.com> References: <20150610224654.GM86224@funkthat.com> <5E0E3EAE-F184-478F-B2A0-D3FAB71ADB20@gmail.com> Date: Wed, 10 Jun 2015 23:56:30 -0700 X-Google-Sender-Auth: FJcILfgGe-QHhJT4Q7gkABNR5Jc Message-ID: Subject: Re: compiling parts of kernel in userland From: "K. Macy" To: Garrett Cooper Cc: arch@freebsd.org, John-Mark Gurney , Adrian Chadd , "freebsd-testing@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 06:56:31 -0000 On Jun 10, 2015 11:53 PM, "Garrett Cooper" wrote: > > (Adding -testing because this pertains to testing) > > On Jun 10, 2015, at 23:48, K. Macy wrote: > > > I started work on something I called libukern which allows you to run > > essentially all non platform code in user adding a PCI passthrough driver > > so one can run unmodified drivers in user. Libuinet is great as far as it > > goes, but it's just the network stack. If you want something other than > > just networking you'll have to do something else. > > If I had enough time and interest I=E2=80=99d look at investing my effort= s in porting RUMP from NetBSD to FreeBSD and going about it that route, but I=E2= =80=99m busy with other efforts so I can=E2=80=99t dedicate my time here yet. It se= ems like RUMP is the direction we should be going in=E2=80=A6 I looked at that first before starting a predecessor to uinet. You'll just have to trust me: no, it's not. -K From owner-freebsd-arch@FreeBSD.ORG Thu Jun 11 06:57:25 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87B3F7F9; Thu, 11 Jun 2015 06:57:25 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x244.google.com (mail-pa0-x244.google.com [IPv6:2607:f8b0:400e:c03::244]) (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 511AE1499; Thu, 11 Jun 2015 06:57:25 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pablj1 with SMTP id lj1so14744238pab.3; Wed, 10 Jun 2015 23:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=TXT5woOfOaJVnhQsVJ6HYtb+ztnl60FMPYk3R1OKJGk=; b=qaNxME48iOX2JJBzIo+tuCibGn79kBbY4cNxwcxWDfr4ki9hrel5nPTMx7AQ7jpJZZ xaREO6LGvVbdrEEEGeZS7Q/DXnDKB3GwDULKlviHHtCNN9b6l7JgSPIpxbORhplzAAX9 CHcyLjV66HwH++322XHtGkm8oz3MB3qlZrk1voEbE9VDXeesICDHJcSPaFJZMDRUCNtA fqELOL/5nsBrCgR+RKDkYbWalAqghe002zx15SgacVEuIw29Rv54Ua+eRrMgN8+def2c W7AVe57XC/u20r4zewWrfPdqRaUXgZSyFslqXzMywGi4FTRD0asCbN6QBCA/XtUHGmtx /O4g== X-Received: by 10.66.250.131 with SMTP id zc3mr12439966pac.136.1434005844805; Wed, 10 Jun 2015 23:57:24 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:99d4:e155:4cfb:c95a? ([2601:8:ab80:7d6:99d4:e155:4cfb:c95a]) by mx.google.com with ESMTPSA id ss3sm10533549pab.43.2015.06.10.23.57.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Jun 2015 23:57:24 -0700 (PDT) Subject: Re: compiling parts of kernel in userland Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8A383AC1-5A75-4E81-9399-00DC50B69F22"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Garrett Cooper In-Reply-To: Date: Wed, 10 Jun 2015 23:57:22 -0700 Cc: arch@freebsd.org, John-Mark Gurney , Adrian Chadd , "freebsd-testing@freebsd.org" Message-Id: <3FE09AEA-A7C9-4406-83D7-541C823BB416@gmail.com> References: <20150610224654.GM86224@funkthat.com> <5E0E3EAE-F184-478F-B2A0-D3FAB71ADB20@gmail.com> To: "K. Macy" X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 06:57:25 -0000 --Apple-Mail=_8A383AC1-5A75-4E81-9399-00DC50B69F22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 10, 2015, at 23:56, K. Macy wrote: > On Jun 10, 2015 11:53 PM, "Garrett Cooper" = wrote: > > > > (Adding -testing because this pertains to testing) > > > > On Jun 10, 2015, at 23:48, K. Macy wrote: > > > > > I started work on something I called libukern which allows you to = run > > > essentially all non platform code in user adding a PCI passthrough = driver > > > so one can run unmodified drivers in user. Libuinet is great as = far as it > > > goes, but it's just the network stack. If you want something other = than > > > just networking you'll have to do something else. > > > > If I had enough time and interest I=92d look at investing my efforts = in porting RUMP from NetBSD to FreeBSD and going about it that route, = but I=92m busy with other efforts so I can=92t dedicate my time here = yet. It seems like RUMP is the direction we should be going in=85 >=20 > I looked at that first before starting a predecessor to uinet. You'll = just have to trust me: no, it's not. Why/how is it deficient? --Apple-Mail=_8A383AC1-5A75-4E81-9399-00DC50B69F22 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVeTFSAAoJEMZr5QU6S73ewlcH/jFSzJrI/PuV132NDD3/aCin h0zaSAoF1V1UET9gvLbgAhxXf+her9dRuuyy4HiAQ5mshRo3ABYC58VPj06uVILR GzhRoXT469J+tqZIIHHQx/aU+Sok8vr2um64Uxu2MZ37GKRhO8sHS4YYcdXku88E eC8izD4KRxud9DyOJEjUfI2RjQmLapEclJ35tRu4IqpKfXQwx1jlQZZWhn1V7hCK y3I4QGBMpTqNxQCmUURL0yTq8qAqDfQ2fSBdH7gJhWYK/0Ia93WcvpnaNDYzfl37 RGZY0N7xhGUeZtVyL2DpQ7m2DGDxipoDlu49Zlyq//NuoenpmY4SUh/ovxbBX4w= =zx+c -----END PGP SIGNATURE----- --Apple-Mail=_8A383AC1-5A75-4E81-9399-00DC50B69F22-- From owner-freebsd-arch@FreeBSD.ORG Thu Jun 11 07:10:02 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 530F8A06; Thu, 11 Jun 2015 07:10:02 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F9D21713; Thu, 11 Jun 2015 07:10:02 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by pdbki1 with SMTP id ki1so52161880pdb.1; Thu, 11 Jun 2015 00:10:01 -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:content-type; bh=3z9ODyoDGv1Cijk5goDlDbuhEpBh2xs2winR6GQo9jA=; b=sbDwmBzJtc0QD/Vukqe0DTX3/opm6at2Ciyd/g9nHYoHB+lz+vOWAa1r7uAdEktf3j 9U6W7H8ZQrKdMmDcoHtN8CGPJ6BjXdZFKX54U+52BfehMcp5UK9cepmYzFmS6E4W4J6A 4EYZm139zDy/oiMoc5L4RDcsA5pCOyzBd+GpiejKDthjbKrBEhChSsnEN/DRtG5xRf8G NWQsrrJjdM9wGd9LDchu/48v3SpBx0zCF0wa005ytNTTRsoPjgOIM+pwWZk9+wUeR64a Sn6dDEKe0jANbjW1RZb9q6ormKUckSbUeaAjG9r6QsApKdoJiNrImdS75jQI/R8LaE7a UULA== MIME-Version: 1.0 X-Received: by 10.70.38.10 with SMTP id c10mr12457167pdk.72.1434006601587; Thu, 11 Jun 2015 00:10:01 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.66.236.36 with HTTP; Thu, 11 Jun 2015 00:10:01 -0700 (PDT) Received: by 10.66.236.36 with HTTP; Thu, 11 Jun 2015 00:10:01 -0700 (PDT) In-Reply-To: <3FE09AEA-A7C9-4406-83D7-541C823BB416@gmail.com> References: <20150610224654.GM86224@funkthat.com> <5E0E3EAE-F184-478F-B2A0-D3FAB71ADB20@gmail.com> <3FE09AEA-A7C9-4406-83D7-541C823BB416@gmail.com> Date: Thu, 11 Jun 2015 00:10:01 -0700 X-Google-Sender-Auth: 7wOF7uY4ril1pMcTk0KUkpQIIMM Message-ID: Subject: Re: compiling parts of kernel in userland From: "K. Macy" To: Garrett Cooper Cc: arch@freebsd.org, John-Mark Gurney , Adrian Chadd , "freebsd-testing@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 07:10:02 -0000 On Jun 10, 2015 11:57 PM, "Garrett Cooper" wrote: > > On Jun 10, 2015, at 23:56, K. Macy wrote: > > > On Jun 10, 2015 11:53 PM, "Garrett Cooper" wrote: > > > > > > (Adding -testing because this pertains to testing) > > > > > > On Jun 10, 2015, at 23:48, K. Macy wrote: > > > > > > > I started work on something I called libukern which allows you to run > > > > essentially all non platform code in user adding a PCI passthrough driver > > > > so one can run unmodified drivers in user. Libuinet is great as far as it > > > > goes, but it's just the network stack. If you want something other than > > > > just networking you'll have to do something else. > > > > > > If I had enough time and interest I=E2=80=99d look at investing my ef= forts in porting RUMP from NetBSD to FreeBSD and going about it that route, but I=E2= =80=99m busy with other efforts so I can=E2=80=99t dedicate my time here yet. It se= ems like RUMP is the direction we should be going in=E2=80=A6 > > > > I looked at that first before starting a predecessor to uinet. You'll just have to trust me: no, it's not. > > Why/how is it deficient? It's a horrible unmaintainable steaming pile. There are of course no objective metrics for such a statement without my wasting hours to go back and look through it to come up with a comprehensive explanation. So I imagine you'll want to debate this endlessly. Before you push this any further, download RUMP and just make it *compile* with FreeBSD sources. And at least when I was looking there was no thought given to device passthrough. At least the rubbish that is COMPAT_MACH they had the sense to put in Attic. I effectively ended up starting over again with OSFMK sources. Speaking from experience on many "science projects", one "science project" doesn't necessarily make a good foundation for another. -K From owner-freebsd-arch@FreeBSD.ORG Thu Jun 11 10:40:25 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37730621; Thu, 11 Jun 2015 10:40:25 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E8DE51C86; Thu, 11 Jun 2015 10:40:24 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id CA2FA1FE023; Thu, 11 Jun 2015 12:40:12 +0200 (CEST) Message-ID: <557965BD.5070608@selasky.org> Date: Thu, 11 Jun 2015 12:41:01 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "K. Macy" , Garrett Cooper CC: "freebsd-testing@freebsd.org" , arch@freebsd.org, John-Mark Gurney , Adrian Chadd Subject: Re: compiling parts of kernel in userland References: <20150610224654.GM86224@funkthat.com> <5E0E3EAE-F184-478F-B2A0-D3FAB71ADB20@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 10:40:25 -0000 On 06/11/15 08:56, K. Macy wrote: > On Jun 10, 2015 11:53 PM, "Garrett Cooper" wrote: >> >> (Adding -testing because this pertains to testing) >> >> On Jun 10, 2015, at 23:48, K. Macy wrote: >> >>> I started work on something I called libukern which allows you to run >>> essentially all non platform code in user adding a PCI passthrough > driver >>> so one can run unmodified drivers in user. Libuinet is great as far as > it >>> goes, but it's just the network stack. If you want something other than >>> just networking you'll have to do something else. >> >> If I had enough time and interest I’d look at investing my efforts in > porting RUMP from NetBSD to FreeBSD and going about it that route, but I’m > busy with other efforts so I can’t dedicate my time here yet. It seems like > RUMP is the direction we should be going in… > > I looked at that first before starting a predecessor to uinet. You'll just > have to trust me: no, it's not. > FYI: We already have libcuse and cuse.ko in base for character devices in userspace. --HPS From owner-freebsd-arch@FreeBSD.ORG Fri Jun 12 02:53:44 2015 Return-Path: Delivered-To: arch@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D065D49; Fri, 12 Jun 2015 02:53:44 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (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 1836E1F7C; Fri, 12 Jun 2015 02:53:44 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: by ykfw62 with SMTP id w62so4108252ykf.2; Thu, 11 Jun 2015 19:53:43 -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:content-type; bh=o/MPxr4pOoa8KuRlkTTHr1R4Y+2xKNXUKM4S3zjM6MM=; b=Zfkglwe8JOvtPmM6ZWtrkxRwwzdBAbSv5vcqeM11s4LUtij8skRvjTbO5xx1OBQfM+ YTU13zXF2HsAF25/kvezVEdz4vpKJz0JHFJsMgLn4mf1rThM9x5SMC3qq6LVLq+39O+I OsLG78MEpg9XtlfWuAt8WIas9g9LDFaB18pFj8liEEk6ZfMRFj+v1AcgZZNtX5Y7Q66O +6phYUvvl3mFpix+vItw8E1BHfVwAJCljEWlPoYvyBe8T4J9+JJN/cPhi4dEMA7ghnzg 5zwI9YY0273j8htZMod8McmlS0I2F2vyFoUBxhfEh/E1s+WhTALK75IAXdOdZtVr3qy6 jTBw== MIME-Version: 1.0 X-Received: by 10.170.52.211 with SMTP id 202mr15896671yku.86.1434077623136; Thu, 11 Jun 2015 19:53:43 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.13.233.70 with HTTP; Thu, 11 Jun 2015 19:53:43 -0700 (PDT) In-Reply-To: References: <20150610224654.GM86224@funkthat.com> <5E0E3EAE-F184-478F-B2A0-D3FAB71ADB20@gmail.com> <3FE09AEA-A7C9-4406-83D7-541C823BB416@gmail.com> Date: Thu, 11 Jun 2015 19:53:43 -0700 X-Google-Sender-Auth: rm9KkjEH3N4cvhVmyAX8CIBL2RI Message-ID: Subject: Re: compiling parts of kernel in userland From: Craig Rodrigues To: "K. Macy" Cc: "freebsd-testing@freebsd.org" , arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 02:53:44 -0000 On Thu, Jun 11, 2015 at 12:10 AM, K. Macy wrote: > > It's a horrible unmaintainable steaming pile. There are of course no > objective metrics for such a statement without my wasting hours to go back > and look through it to come up with a comprehensive explanation. So I > imagine you'll want to debate this endlessly. > No, I'm not interested in debating endlessly. However, if you had some rough data points as to the downsides of rump kernels, it would be very useful for others to know what the problems are. You have a lot of knowledge, so it is nice to share your experiences with others. I've read the whitepapers on rump kernels, and seen some of the presentations on it. On the surface, the NetBSD developers who have worked on rump seem like reasonable and smart folks who put a lot of hard work into their project. If I didn't know any better, I would say their stuff is good. If rump is hard to compile on FreeBSD, that is one valid point. If you have other points besides, "it's a steaming pile", it would be nice to hear your thoughts. Otherwise it sounds like "not invented in FreeBSD, so it sucks". I recently asked a similar question about xhyve (bhyve for OS X), and got a simple succinct answer: https://lists.freebsd.org/pipermail/freebsd-virtualization/2015-June/003624.html That's really all that is needed. If it will take hours to gather that info, then I agree, that is a waste of your time. I'd rather see you contribute stuff to FreeBSD, possibly using this Github pull requests using this workflow: https://lists.freebsd.org/pipermail/freebsd-current/2015-April/055551.html :) -- Craig -- Craig From owner-freebsd-arch@FreeBSD.ORG Fri Jun 12 03:03:09 2015 Return-Path: Delivered-To: arch@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5AA32129; Fri, 12 Jun 2015 03:03:09 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::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 25C2A1448; Fri, 12 Jun 2015 03:03:09 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by pabqy3 with SMTP id qy3so13748063pab.3; Thu, 11 Jun 2015 20:03:08 -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:content-type; bh=xPi0fgn+nciaU0B6g4dUBeT9fv5pjgTvTbnViViZ6lg=; b=ScljZ8jWU+DnedEgUbvBloOgld9yCZGTQBPoiHEKL3pGIn8CkD4RKG0jVa0oeYR6zs mnPf4/5c/4pyYwCPnR5cFdH3Lx0MHbelliUYJitd+RYGH7R+8mCK5OhWYlEXASs1SMRu kyU5GOzUqKyniEmLohf2U51TAS13OcmImj9uE0ipKcuD0yqoAnFimn2LcLw++u+bvx55 HXnmnWeYSFczx6GeB/DnsA8LPl8A6XRHrrg52PhbyV6UiCtPRrKDTqx/eFCt1ZcffDxK RnbK2mIwMnATHeGsP1x2q0F+bBKZV6TBlx5poow5SZhgoj/TL8bNh+nbPPSRJTh5b2DO riig== MIME-Version: 1.0 X-Received: by 10.70.133.36 with SMTP id oz4mr19610947pdb.65.1434078188519; Thu, 11 Jun 2015 20:03:08 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.66.236.36 with HTTP; Thu, 11 Jun 2015 20:03:08 -0700 (PDT) Received: by 10.66.236.36 with HTTP; Thu, 11 Jun 2015 20:03:08 -0700 (PDT) In-Reply-To: References: <20150610224654.GM86224@funkthat.com> <5E0E3EAE-F184-478F-B2A0-D3FAB71ADB20@gmail.com> <3FE09AEA-A7C9-4406-83D7-541C823BB416@gmail.com> Date: Thu, 11 Jun 2015 20:03:08 -0700 X-Google-Sender-Auth: 63-A08C0Vrv2bBx6jCmwxr3NVtU Message-ID: Subject: Re: compiling parts of kernel in userland From: "K. Macy" To: Craig Rodrigues Cc: arch@freebsd.org, freebsd-testing@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 03:03:09 -0000 On Jun 11, 2015 7:53 PM, "Craig Rodrigues" wrote: > > > > On Thu, Jun 11, 2015 at 12:10 AM, K. Macy wrote: >> >> >> It's a horrible unmaintainable steaming pile. There are of course no >> objective metrics for such a statement without my wasting hours to go back >> and look through it to come up with a comprehensive explanation. So I >> imagine you'll want to debate this endlessly. > > > No, I'm not interested in debating endlessly. > > However, if you had some rough data points as to the downsides > of rump kernels, it would be very useful for others to know what the > problems are. You have a lot of knowledge, so it is nice to share > your experiences with others. > > I've read the whitepapers on rump kernels, and seen some of the > presentations on it. On the surface, the NetBSD developers who > have worked on rump seem like reasonable and smart folks who put a lot of > hard work into their project. If I didn't know any better, I would say their > stuff is good. > > If rump is hard to compile on FreeBSD, that is one valid point. > If you have other points besides, "it's a steaming pile", it would be nice > to hear your thoughts. Otherwise it sounds like "not invented in FreeBSD, so it sucks". > > I recently asked a similar question about xhyve (bhyve for OS X), > and got a simple succinct answer: > https://lists.freebsd.org/pipermail/freebsd-virtualization/2015-June/003624.html > > That's really all that is needed. If it will take hours to gather that info, > then I agree, that is a waste of your time. I'd rather see you contribute > stuff to FreeBSD, possibly using this Github pull requests > using this workflow: > > https://lists.freebsd.org/pipermail/freebsd-current/2015-April/055551.html The idea behind RUMP is of course sound and useful. And the implementation may well have improved dramatically since I last looked. However, my personal experience with much of NetBSD outside of the core kernel (xen, mach, SPARC, and perhaps RUMP) is that the code is really unpleasant to work with and not any sort of reusable framework beyond, perhaps, answering specific questions. Dillon had some sort of toy user space kernel a while back. If he he has maintained that it is very likely a better starting point. -K > :) > > -- > Craig > > > > -- > Craig > From owner-freebsd-arch@FreeBSD.ORG Fri Jun 12 20:44:53 2015 Return-Path: Delivered-To: arch@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EFD9BAE4 for ; Fri, 12 Jun 2015 20:44:53 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D40C7C for ; Fri, 12 Jun 2015 20:44:52 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t5CKigbh098650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Jun 2015 23:44:42 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t5CKigJi098649; Fri, 12 Jun 2015 23:44:42 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 12 Jun 2015 23:44:42 +0300 From: Gleb Smirnoff To: Alan Cox Cc: Konstantin Belousov , arch@FreeBSD.org Subject: Re: more strict KPI for vm_pager_get_pages() Message-ID: <20150612204442.GL73119@glebius.int.ru> References: <20150430142408.GS546@nginx.com> <20150506114549.GS34544@FreeBSD.org> <20150610183047.GT2499@kib.kiev.ua> <20150610184251.GP73119@glebius.int.ru> <20150611024706.GW2499@kib.kiev.ua> <20150611103743.GV73119@glebius.int.ru> <20150612040959.GB2080@kib.kiev.ua> <557B3311.40908@rice.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <557B3311.40908@rice.edu> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 20:44:54 -0000 Alan, [cc arch@ back] On Fri, Jun 12, 2015 at 02:29:21PM -0500, Alan Cox wrote: A> I'm fine with changing the rules or expectations concerning the A> *requested* page. In fact, there are inconsistencies among the callers A> in whether they believe that the requested page could disappear. A> Specifically, some callers (e.g., kern_exec.c) handle the possibility of A> the requested page disappearing and treat its disappearance as an I/O A> error, while other callers (e.g., tmpfs_subr.c) would crash if the A> requested disappeared. Since we also expect the requested page to A> remain busy until we return to the caller, I don't see the point in A> handling the possibility that the requested page disappeared. In other A> words, error or no error, the request page remains allocated and busy; A> moreover, we guarantee that the array entry references the correct page. A> A> On the other hand, I'm not ready to make a guarantee about the state of A> the array entries for the non-request pages. In the general case, the A> I/O completion handlers will unbusy and place the pages in a paging A> queue. So, in principle, they could be reclaimed before control was A> returned to vm_pager_get_pages()'s caller, and even if the pager updated A> the array entries, they would no longer be valid. For example, the page A> daemon could reclaim them, or another thread could simply decide to free A> them for some arbitrary reason. A> A> In a nutshell, I'm fine with all of the changes except the one to A> vm_thread_swapin(). The change to vm_thread_swapin() is only safe A> because the pages have been wired and the pages are used in a particular A> way, i.e., the implementation of a thread stack. Replying to the last two paragraphs: Yes, and this lack of guarantee is the inconsistency, that I'd like to address. The patch committed is only a first step of a bigger vm_pager_get_pages KPI strictening. Let's get back to the patch that started this topic: https://lists.freebsd.org/pipermail/freebsd-arch/2015-April/017154.html -- Totus tuus, Glebius. From owner-freebsd-arch@FreeBSD.ORG Fri Jun 12 22:42:22 2015 Return-Path: Delivered-To: arch@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD7E05CC; Fri, 12 Jun 2015 22:42:21 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (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 A4D0AF6F; Fri, 12 Jun 2015 22:42:21 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id t5CMgDcC014168; Fri, 12 Jun 2015 17:42:13 -0500 Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by pp2.rice.edu with ESMTP id 1v01su8add-1; Fri, 12 Jun 2015 17:42:13 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh11.mail.rice.edu (Postfix) with ESMTPSA id 457064C02AD; Fri, 12 Jun 2015 17:42:13 -0500 (CDT) Message-ID: <557B6044.7060103@rice.edu> Date: Fri, 12 Jun 2015 17:42:12 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Gleb Smirnoff CC: Konstantin Belousov , arch@FreeBSD.org Subject: Re: more strict KPI for vm_pager_get_pages() References: <20150430142408.GS546@nginx.com> <20150506114549.GS34544@FreeBSD.org> <20150610183047.GT2499@kib.kiev.ua> <20150610184251.GP73119@glebius.int.ru> <20150611024706.GW2499@kib.kiev.ua> <20150611103743.GV73119@glebius.int.ru> <20150612040959.GB2080@kib.kiev.ua> <557B3311.40908@rice.edu> <20150612204442.GL73119@glebius.int.ru> In-Reply-To: <20150612204442.GL73119@glebius.int.ru> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=5.98132654516803e-13 kscore.compositescore=7.64885099702184e-10 circleOfTrustscore=0 compositescore=0.601496849000349 suspectscore=10 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.601496849000349 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.00149684900034924 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1506120395 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 22:42:22 -0000 On 06/12/2015 15:44, Gleb Smirnoff wrote: > Alan, > > [cc arch@ back] > > On Fri, Jun 12, 2015 at 02:29:21PM -0500, Alan Cox wrote: > A> I'm fine with changing the rules or expectations concerning the > A> *requested* page. In fact, there are inconsistencies among the call= ers > A> in whether they believe that the requested page could disappear.=20 > A> Specifically, some callers (e.g., kern_exec.c) handle the possibilit= y of > A> the requested page disappearing and treat its disappearance as an I/= O > A> error, while other callers (e.g., tmpfs_subr.c) would crash if the > A> requested disappeared. Since we also expect the requested page to > A> remain busy until we return to the caller, I don't see the point in > A> handling the possibility that the requested page disappeared. In ot= her > A> words, error or no error, the request page remains allocated and bus= y; > A> moreover, we guarantee that the array entry references the correct p= age. > A>=20 > A> On the other hand, I'm not ready to make a guarantee about the state= of > A> the array entries for the non-request pages. In the general case, t= he > A> I/O completion handlers will unbusy and place the pages in a paging > A> queue. So, in principle, they could be reclaimed before control was= > A> returned to vm_pager_get_pages()'s caller, and even if the pager upd= ated > A> the array entries, they would no longer be valid. For example, the = page > A> daemon could reclaim them, or another thread could simply decide to = free > A> them for some arbitrary reason. > A>=20 > A> In a nutshell, I'm fine with all of the changes except the one to > A> vm_thread_swapin(). The change to vm_thread_swapin() is only safe > A> because the pages have been wired and the pages are used in a partic= ular > A> way, i.e., the implementation of a thread stack. > > Replying to the last two paragraphs: > > Yes, and this lack of guarantee is the inconsistency, that I'd like to > address. The patch committed is only a first step of a bigger > vm_pager_get_pages KPI strictening. > > Let's get back to the patch that started this topic: > > https://lists.freebsd.org/pipermail/freebsd-arch/2015-April/017154.html= > I'm not sure that I understand what inconsistency you're referring to here. That the request page is handled differently from the non-request pages? Again, I'm happy with the changes to the handling of the request page.=20 However, I'm still on the fence about the other proposed changes, and I feel like the change to vm_thread_swapin() in the patch we are discussing is qualitatively different from the other changes in that same patch. In particular, it is the only part of that patch that touches non-request pages. As such, I didn't think it belongs. From owner-freebsd-arch@FreeBSD.ORG Sat Jun 13 22:40:10 2015 Return-Path: Delivered-To: freebsd-arch@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 498009FC for ; Sat, 13 Jun 2015 22:40:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (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 163231D6 for ; Sat, 13 Jun 2015 22:40:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iesa3 with SMTP id a3so42709847ies.2 for ; Sat, 13 Jun 2015 15:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=V6DyUJn5zbZqXa2s1e5j1eSzdtPo2xiJBvICocG3f0w=; b=HG/igZVoQfuqJqtYdlfuecAsCFCOCiLR4qWhf7EBHBlSH//lY9xAOfCZ8WgBwiFH0s vM3wgPL77qz1jsdQ/NCaw2RFEEnK3VKOvrQOSXbsPU8jdbuCy5Fg+K5WxVF3ASqZIxK+ +HCFd95dcPbaikTbO8mw+HxHr82vG4KCVbKQsW2mI1/BzUm1Db1Js2iPzWF4OkJ9BHAG 6k8dxM0WN3GuXjFI+QJBW85vSacu6MxAb4ln5moxF/2J2aHZCFG+gSaxjBcoW0IWL4oY NCE32VywSt0dMwBmrgY/O5iteB0YPn5eZeEkdjZrJrc9kpBzR98+fpalCEZ/iQEpFo/0 FrjA== MIME-Version: 1.0 X-Received: by 10.43.163.129 with SMTP id mo1mr22577409icc.61.1434235209386; Sat, 13 Jun 2015 15:40:09 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Sat, 13 Jun 2015 15:40:09 -0700 (PDT) Date: Sat, 13 Jun 2015 15:40:09 -0700 X-Google-Sender-Auth: u9vyveOmCY8s5VUB15Ugh6PB8a8 Message-ID: Subject: [rfc] add MK_TELNET_SSL as a build option From: Adrian Chadd To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 22:40:10 -0000 Hi, The wifi builds have a need for building telnet/telnetd without ssl/kerberos in order to meet size constraints and to allow them to be crunch'ed. I'd like to add the following patch to -HEAD, minus the comments in libtelnet that are currently a reminder to me of what needs to be turned into function pointers so things link correctly. I'd appreciate feedback here as it does involve addin ga new MK, and I really dislike it. :( adrian@lucy-11i386:~/work/freebsd/head-embedded-2/src % cat /tmp/diff Index: contrib/telnet/libtelnet/misc-proto.h =================================================================== --- contrib/telnet/libtelnet/misc-proto.h (revision 284291) +++ contrib/telnet/libtelnet/misc-proto.h (working copy) @@ -71,6 +71,11 @@ /* * These functions are imported from the application */ +/* + * XXX TODO: turn into a function set that's passed in + * from telnet/telnetd main(). That way it can be + * built via crunchgen. + */ int net_write(unsigned char *, int); void net_encrypt(void); int telnet_spin(void); Index: lib/libtelnet/Makefile =================================================================== --- lib/libtelnet/Makefile (revision 284291) +++ lib/libtelnet/Makefile (working copy) @@ -15,7 +15,7 @@ WARNS?= 2 -.if ${MK_OPENSSL} != "no" +.if ${MK_OPENSSL} != "no" && ${MK_TELNET_SSL} != "no" SRCS+= encrypt.c auth.c enc_des.c sra.c pk.c CFLAGS+= -DENCRYPTION -DAUTHENTICATION -DSRA .endif Index: libexec/telnetd/Makefile =================================================================== --- libexec/telnetd/Makefile (revision 284291) +++ libexec/telnetd/Makefile (working copy) @@ -31,7 +31,7 @@ LIBADD= telnet util ncursesw -.if ${MK_OPENSSL} != "no" +.if ${MK_OPENSSL} != "no" && ${MK_TELNET_SSL} != "no" SRCS+= authenc.c CFLAGS+= -DAUTHENTICATION -DENCRYPTION LIBADD+= mp crypto pam adrian@lucy-11i386:~/work/freebsd/head-embedded-2/src % more /tmp/diff Index: contrib/telnet/libtelnet/misc-proto.h =================================================================== --- contrib/telnet/libtelnet/misc-proto.h (revision 284291) +++ contrib/telnet/libtelnet/misc-proto.h (working copy) @@ -71,6 +71,11 @@ /* * These functions are imported from the application */ +/* + * XXX TODO: turn into a function set that's passed in + * from telnet/telnetd main(). That way it can be + * built via crunchgen. + */ int net_write(unsigned char *, int); void net_encrypt(void); int telnet_spin(void); Index: lib/libtelnet/Makefile =================================================================== --- lib/libtelnet/Makefile (revision 284291) +++ lib/libtelnet/Makefile (working copy) @@ -15,7 +15,7 @@ WARNS?= 2 -.if ${MK_OPENSSL} != "no" +.if ${MK_OPENSSL} != "no" && ${MK_TELNET_SSL} != "no" SRCS+= encrypt.c auth.c enc_des.c sra.c pk.c CFLAGS+= -DENCRYPTION -DAUTHENTICATION -DSRA .endif Index: libexec/telnetd/Makefile =================================================================== --- libexec/telnetd/Makefile (revision 284291) +++ libexec/telnetd/Makefile (working copy) @@ -31,7 +31,7 @@ LIBADD= telnet util ncursesw -.if ${MK_OPENSSL} != "no" +.if ${MK_OPENSSL} != "no" && ${MK_TELNET_SSL} != "no" SRCS+= authenc.c CFLAGS+= -DAUTHENTICATION -DENCRYPTION LIBADD+= mp crypto pam Index: share/mk/src.opts.mk =================================================================== --- share/mk/src.opts.mk (revision 284291) +++ share/mk/src.opts.mk (working copy) @@ -161,6 +161,7 @@ TCP_WRAPPERS \ TCSH \ TELNET \ + TELNET_SSL \ TESTS \ TEXTPROC \ TFTP \ @@ -290,6 +291,7 @@ .if ${MK_CRYPT} == "no" MK_OPENSSL:= no +MK_TELNET_SSL:= no MK_OPENSSH:= no MK_KERBEROS:= no .endif @@ -312,6 +314,7 @@ .endif .if ${MK_OPENSSL} == "no" +MK_TELNET_SSL:= no MK_OPENSSH:= no MK_KERBEROS:= no .endif Index: tools/bsdbox/Makefile =================================================================== --- tools/bsdbox/Makefile (revision 284291) +++ tools/bsdbox/Makefile (working copy) @@ -100,7 +100,7 @@ .include "Makefile.kld" # telnet/telnetd are too broken to include as a crunchgen'ed binary, # thanks to some of the horrible layering violations going on. -# .include "Makefile.telnetd" +.include "Makefile.telnetd" .include "Makefile.fs" CRUNCH_LIBS+= -lcrypto -lssl -lz Index: tools/bsdbox/Makefile.telnetd =================================================================== --- tools/bsdbox/Makefile.telnetd (revision 284291) +++ tools/bsdbox/Makefile.telnetd (working copy) @@ -1,4 +1,4 @@ -# Build telnetd +# Build telnet/telnetd # Question - why is telnetds objects ending up in the srcdir? -adrian # This won't work yet - because telnetd relies on libtelnet.a which includes @@ -8,7 +8,8 @@ # $FreeBSD$ +CRUNCH_BUILDOPTS_telnetd= MK_KERBEROS_SUPPORT=no CRUNCH_PROGS_libexec+= telnetd CRUNCH_PROGS_usr.bin+= telnet -CRUNCH_LIBS+= -lkrb5 -lhx509 -lasn1 -lcom_err -lroken -ltelnetd -# CRUNCH_BUILDOPTS_telnetd= MK_KERBEROS_SUPPORT=no +#CRUNCH_LIBS+= -lkrb5 -lhx509 -lasn1 -lcom_err -lroken +CRUNCH_LIBS+= ../../lib/libtelnet/libtelnet.a Index: usr.bin/telnet/Makefile =================================================================== --- usr.bin/telnet/Makefile (revision 284291) +++ usr.bin/telnet/Makefile (working copy) @@ -30,7 +30,7 @@ CFLAGS+= -DHAS_CGETENT .endif -.if ${MK_OPENSSL} != "no" +.if ${MK_OPENSSL} != "no" && ${MK_TELNET_SSL} != "no" SRCS+= authenc.c CFLAGS+= -DENCRYPTION -DAUTHENTICATION -DIPSEC LIBADD+= mp crypto ipsec pam adrian@lucy-11i386:~/work/freebsd/head-embedded-2/src % From owner-freebsd-arch@FreeBSD.ORG Sat Jun 13 22:46:36 2015 Return-Path: Delivered-To: freebsd-arch@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9AD6D33; Sat, 13 Jun 2015 22:46:35 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::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 AEEAC5F6; Sat, 13 Jun 2015 22:46:35 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pdjm12 with SMTP id m12so46089083pdj.3; Sat, 13 Jun 2015 15:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=6Ujz1ppmwZXAsxQOztUqnriDl/tGQ0aBf+fwxma3Tbk=; b=aHOA0ZrPs145QMJ8CU2cBy0PYIzZFbSWBxkBtaumkc5J9ehEqyJCpWgC2a271BVL/0 57udo6oeVGzWdW8j5QAESOTuSoKAhKwP2PFR8VbrUQ78R6Uf8p4tTHItpMoEYUEt+L5x 9c19QUgczER2BnDMIgWJhSv8PX6wFb6HniY6IQn+jnTDdRw16UdQB0BrsGmJzD+dXWh3 ifTCjdiFf9YG5r1JJuVDvmoy7m44VJ1qZgXSopgx9mvNdXpJDkQPrzkwtSLWV3UVnm1z TuJqyfwmWE7X21N3gVNfFRDZe0VloKrBuakQWI6ctPBd9VjDAF04GtkYko1gkSH6XnMW edfQ== X-Received: by 10.70.130.168 with SMTP id of8mr35219820pdb.131.1434235595165; Sat, 13 Jun 2015 15:46:35 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:2434:29cc:2519:36ef? ([2601:8:ab80:7d6:2434:29cc:2519:36ef]) by mx.google.com with ESMTPSA id da2sm7624287pbb.57.2015.06.13.15.46.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Jun 2015 15:46:34 -0700 (PDT) Subject: Re: [rfc] add MK_TELNET_SSL as a build option Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_618C496D-6111-4B62-AE81-F4BBD2B80512"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Garrett Cooper In-Reply-To: Date: Sat, 13 Jun 2015 15:46:31 -0700 Cc: "freebsd-arch@freebsd.org" Message-Id: <181503FC-ED51-4F8B-A900-53B51578E2C0@gmail.com> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 22:46:36 -0000 --Apple-Mail=_618C496D-6111-4B62-AE81-F4BBD2B80512 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 13, 2015, at 15:40, Adrian Chadd wrote: > Hi, >=20 > The wifi builds have a need for building telnet/telnetd without > ssl/kerberos in order to meet size constraints and to allow them to be > crunch=92ed. ... > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- contrib/telnet/libtelnet/misc-proto.h (revision 284291) > +++ contrib/telnet/libtelnet/misc-proto.h (working copy) > @@ -71,6 +71,11 @@ > /* > * These functions are imported from the application > */ > +/* > + * XXX TODO: turn into a function set that's passed in > + * from telnet/telnetd main(). That way it can be > + * built via crunchgen. > + */ What=92s the story behind the TODO? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- lib/libtelnet/Makefile (revision 284291) > +++ lib/libtelnet/Makefile (working copy) > @@ -15,7 +15,7 @@ >=20 > WARNS?=3D 2 >=20 > -.if ${MK_OPENSSL} !=3D "no" > +.if ${MK_OPENSSL} !=3D "no" && ${MK_TELNET_SSL} !=3D =93no" Please reduce this to ${MK_TELNET_SSL} !=3D =93no=94 (here and = elsewhere). ${MK_OPENSSL} =3D=3D =93no=94 already handles setting this = knob in src.opts.mk, so there=92s no reason why you need to check both = knobs. Thanks! --Apple-Mail=_618C496D-6111-4B62-AE81-F4BBD2B80512 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVfLLHAAoJEMZr5QU6S73exegH/ibrlENrc3HBPaz/fjGzfKVd 5Jhe3TODAU2kWq7CepipD4LpZWZa3SBfzjZZIUXDDuop8m9Nucvojsb7qGKiaSiL P/XnSXFmCvuvbhiC0Ad/x9LH6y4pQHJ+gc4dL4sl7t1sT469H3JV5QLSeLjyjYNN dO+RxOCt+48InKuDNhEJyJa1oG8kpPUCYeU5+5yYLXfR5ePjSFUHz4j018EF9xs3 ILYXAVBz7EX/q2l4woZudy13QtOaJTim5r0NRKmuuqFGWdRQQbU9+H/vTft36N8X dxQpvoyXxTfyZsYQwM5A6LE4/fDMfs9HASQdx1aR/h7AYjLVGYELJ2VYtUixHvQ= =M6Xv -----END PGP SIGNATURE----- --Apple-Mail=_618C496D-6111-4B62-AE81-F4BBD2B80512-- From owner-freebsd-arch@FreeBSD.ORG Sat Jun 13 23:34:17 2015 Return-Path: Delivered-To: freebsd-arch@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46CFB81E for ; Sat, 13 Jun 2015 23:34:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (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 10E2AD5 for ; Sat, 13 Jun 2015 23:34:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iebmu5 with SMTP id mu5so43040249ieb.1 for ; Sat, 13 Jun 2015 16:34:16 -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:content-type; bh=eM66yl31kbtEgg4q0VhpzPqI4uQd1GHFvrObU3uqhEE=; b=whivUXiut1vm6ZtznrdcYgUSN6JefCci/2QSZTBHMaOJJUdmt4gQyiubGkS7PuFGFY UV0Kt4bl9iZgBIpgnH18WL0dlRhETO9fDaVazob3lEoeRGtYLQRVLgbaN77RX6UtbULL bx73Q4lXJj/qMIZQwPF0KccuzQKcYfwP1XXdCnU9CTFvxveifCBpPwum4a60qeRhNZRx UQhumf0/SOmb3b3FcH7xJoliGex5vkYYUTJUZP+ICotHkPkvK0THLfddIXxBfHYgvP1G HW4pZABCdeespn1wwG3xfpR3iL/CJT1mTqY001aAxHOmn8rZNA6KU3WbMG3oJ62mZgWZ X52A== MIME-Version: 1.0 X-Received: by 10.50.97.105 with SMTP id dz9mr12429131igb.49.1434238456598; Sat, 13 Jun 2015 16:34:16 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Sat, 13 Jun 2015 16:34:16 -0700 (PDT) In-Reply-To: <181503FC-ED51-4F8B-A900-53B51578E2C0@gmail.com> References: <181503FC-ED51-4F8B-A900-53B51578E2C0@gmail.com> Date: Sat, 13 Jun 2015 16:34:16 -0700 X-Google-Sender-Auth: H4_eu00PlhRPGz6b7jlz2FoTsPo Message-ID: Subject: Re: [rfc] add MK_TELNET_SSL as a build option From: Adrian Chadd To: Garrett Cooper Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 23:34:17 -0000 The telnet library requires those routines to be defined by the application, but when doing crunchgen style binaries that doesn't work - two sets of each of those symbols are defined and things don't link. The solution here is to create a struct with function pointers that the application registers at startup time, rather than having the library link /into/ the application. -adrian