From owner-freebsd-arch@FreeBSD.ORG Sun Jan 2 19:22:14 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B684106566C; Sun, 2 Jan 2011 19:22:14 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id C73888FC08; Sun, 2 Jan 2011 19:22:13 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id DDE4A58134; Sun, 2 Jan 2011 12:49:36 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id yJhBET4LLuoO; Sun, 2 Jan 2011 12:49:36 -0600 (CST) Received: from wanderer.tachypleus.net (unknown [76.210.75.5]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 607365811B; Sun, 2 Jan 2011 12:49:36 -0600 (CST) Message-ID: <4D20C8BF.701@freebsd.org> Date: Sun, 02 Jan 2011 12:49:35 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101227 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org, freebsd-sysinstall@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: BSDInstall: I want the bikeshed painted plaid X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 19:22:14 -0000 As those of you who obsessively follow the SVN commit mails may have noticed, I recently began work on a new installer, which I have tentatively named 'bsdinstall'. You can find the code itself at svn://svn.freebsd.org/base/user/nwhitehorn/bsdinstall and a wiki page describing it at http://wiki.freebsd.org/BSDInstall. Why Plaid? ---------- This project started because we have never, in three major releases, shipped an installer on PowerPC capable of installing a booting system without absurd amounts of handholding and use of external tools. This is especially galling when we have tools in the base (gpart, newfs, and tar) fully capable of doing this. As it turns out, by the time you've written a shell script to combine these things, you're well on your way to deciding to write a new installer. The goal of this project then, was to maximally reuse existing tools and to make the installer a chain of easily modifiable or replaceable components so that future installer-tinkerers will not run away in terror as quickly as I and many others have from sysinstall and libdisk. Architecture ------------ BSDInstall is a set of tools that are called in sequence by a master script. These tools are, for example, the partition editor, the thing that fetches the distributions from the network, the thing that untars them, etc. Since these are just called in sequence from a shell script, a scripted installation can easily replace them with other things, (e.g. hard-coded gpart commands), leave steps out, add new ones, or interleave additional system modifications. Status ------ This provides almost all of the functionality of the existing sysinstall 'Express' track, and works Right Now. It installs working, bootable systems you can ssh into immediately after reboot on i386, amd64, sparc64, powerpc, and powerpc64. There is untested support for pc98. The final architecture on which we use sysinstall, ia64, is currently unsupported, because I don't know how to set up booting on those systems. Paint Comes in Plaid? --------------------- With only a little more spit and polish, I think this could easily replace sysinstall for the 9.0 release. It works right now on almost all architectures for which we ship install media. There are no dependencies on strange scripting languages, and only one on tools not currently in the base system. bsdinstall depends on the newer dialog and libdialog from Thomas Dickey (devel/cdialog). This is LGPL2, but that is better than the current dialog's license, and the software is so much better to develop with than the current mess that is libdialog it might be good to have anyway. In addition, I believe he is the sole author, and it's possible he could be persuaded to relicense it. I don't entirely know how all of this relates to pc-sysinstall. pc-sysinstall has some more features (e.g. installation onto geli disks), and certainly more thought went into it, but requires an immense amount of work to make it work on non-x86 systems and a text front-end is not yet complete. When it is ready, a lot of the infrastructural changes required for bsdinstall (live CDs for installation, a new libdialog, revised distfile format, etc.) will probably help pc-sysinstall as well. -Nathan From owner-freebsd-arch@FreeBSD.ORG Sun Jan 2 19:51:40 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1515106566C; Sun, 2 Jan 2011 19:51:40 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8467A8FC0A; Sun, 2 Jan 2011 19:51:40 +0000 (UTC) Received: by pvc22 with SMTP id 22so2743010pvc.13 for ; Sun, 02 Jan 2011 11:51:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=EkZ+4AITfJUQc92KdFwgtMuDxS1Y/gLALHkdyJM7akc=; b=x5ffiqZRgHHnPbJo5XvBdl0GFkn3h12FEDPS2MyOA4Yw+1AwTBYORH4OU1MgPw43OZ bimp6HpBc+TnIsOMaoeqBoUZzkBoaGMaoTn0Euu2sA4s5n79mXWFN53VGLcYnWcQEnCn D68vCrNITV17JUX13b0PPHxuCstSdZCnz5dME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=m7WkLGnlA8H2vZhjma9dQvGMLEIdv2XI9HnlQ2Vy5EUrdQ/lXETe5Vioi5xcu3rNrq f5R2C/G3Eaoh8VOotbnhmt3y8KNUdRgi2LxXF05vMvIjYCRbgjSkpDzXo9Iot6OobgE6 o/iEevze586b0LaJTR4fQBBstzTcyQ/72rsdE= Received: by 10.142.191.10 with SMTP id o10mr14844026wff.208.1293997899303; Sun, 02 Jan 2011 11:51:39 -0800 (PST) Received: from [192.168.20.5] (c-24-130-151-210.hsd1.ca.comcast.net [24.130.151.210]) by mx.google.com with ESMTPS id b11sm28078518wff.9.2011.01.02.11.51.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 02 Jan 2011 11:51:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <4D20C8BF.701@freebsd.org> Date: Sun, 2 Jan 2011 11:51:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D20C8BF.701@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1082) Cc: freebsd-sysinstall@freebsd.org, freebsd-arch@FreeBSD.org Subject: Re: BSDInstall: I want the bikeshed painted plaid X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 19:51:40 -0000 On Jan 2, 2011, at 10:49 AM, Nathan Whitehorn wrote: > As those of you who obsessively follow the SVN commit mails may have = noticed, I recently began work on a new installer, which I have = tentatively named 'bsdinstall'. You can find the code itself at = svn://svn.freebsd.org/base/user/nwhitehorn/bsdinstall and a wiki page = describing it at http://wiki.freebsd.org/BSDInstall. >=20 > Why Plaid? > ---------- > This project started because we have never, in three major releases, = shipped an installer on PowerPC capable of installing a booting system = without absurd amounts of handholding and use of external tools. This is = especially galling when we have tools in the base (gpart, newfs, and = tar) fully capable of doing this. As it turns out, by the time you've = written a shell script to combine these things, you're well on your way = to deciding to write a new installer. >=20 > The goal of this project then, was to maximally reuse existing tools = and to make the installer a chain of easily modifiable or replaceable = components so that future installer-tinkerers will not run away in = terror as quickly as I and many others have from sysinstall and libdisk. >=20 > Architecture > ------------ > BSDInstall is a set of tools that are called in sequence by a master = script. These tools are, for example, the partition editor, the thing = that fetches the distributions from the network, the thing that untars = them, etc. Since these are just called in sequence from a shell script, = a scripted installation can easily replace them with other things, (e.g. = hard-coded gpart commands), leave steps out, add new ones, or interleave = additional system modifications. >=20 > Status > ------ > This provides almost all of the functionality of the existing = sysinstall 'Express' track, and works Right Now. It installs working, = bootable systems you can ssh into immediately after reboot on i386, = amd64, sparc64, powerpc, and powerpc64. There is untested support for = pc98. The final architecture on which we use sysinstall, ia64, is = currently unsupported, because I don't know how to set up booting on = those systems. >=20 > Paint Comes in Plaid? > --------------------- > With only a little more spit and polish, I think this could easily = replace sysinstall for the 9.0 release. It works right now on almost all = architectures for which we ship install media. There are no dependencies = on strange scripting languages, and only one on tools not currently in = the base system. >=20 > bsdinstall depends on the newer dialog and libdialog from Thomas = Dickey (devel/cdialog). This is LGPL2, but that is better than the = current dialog's license, and the software is so much better to develop = with than the current mess that is libdialog it might be good to have = anyway. In addition, I believe he is the sole author, and it's possible = he could be persuaded to relicense it. >=20 > I don't entirely know how all of this relates to pc-sysinstall. = pc-sysinstall has some more features (e.g. installation onto geli = disks), and certainly more thought went into it, but requires an immense = amount of work to make it work on non-x86 systems and a text front-end = is not yet complete. When it is ready, a lot of the infrastructural = changes required for bsdinstall (live CDs for installation, a new = libdialog, revised distfile format, etc.) will probably help = pc-sysinstall as well. Please see pc-sysinstall if you like to see a different effort = in chartreuse. No guarantees as to how many x86-isms are in the = infrastructure. Thanks, -Garrett= From owner-freebsd-arch@FreeBSD.ORG Sun Jan 2 20:04:25 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68BAF106566C; Sun, 2 Jan 2011 20:04:25 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 22E3D8FC15; Sun, 2 Jan 2011 20:04:25 +0000 (UTC) Received: by pzk32 with SMTP id 32so3101189pzk.13 for ; Sun, 02 Jan 2011 12:04:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=mkmwi1smN+gtyi41D9qGDhtgfLZ6XknPAYMltiDuIt8=; b=Rqh5RTO3T5q2YZAl4FLLtKIIZlbtcrNAnhbBIRTErEHDHPuwmPw6trAqR+whJNx3z3 syR7+BFssv5CklniIESyKtkmLJCtPoHhzuPxBnJ5MIS9ALcGnl8xxj+UJunkTi81oeF3 MF5yl6rjjUZQEhdyBI2ObXcLum38bBnE6chFQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=AAf4TyZ2g097tTmtJT/9Kmf8eTLZyzCzC1/cq50i3pVJSwAf3uiHXIQ9b5c7cwr6Vr 8Uc24rs8QoF7pssPWjkfDOxtGIUO9JtB4nee0zK6Em2EAC1ZB85m8rf5EnytjrOgsknL 7pqMsu4ARvXrD81ZuhQevp5vl52RtJijI47Pw= Received: by 10.142.177.10 with SMTP id z10mr16069919wfe.141.1293998664623; Sun, 02 Jan 2011 12:04:24 -0800 (PST) Received: from [192.168.20.5] (c-24-130-151-210.hsd1.ca.comcast.net [24.130.151.210]) by mx.google.com with ESMTPS id q13sm28108856wfc.17.2011.01.02.12.04.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 02 Jan 2011 12:04:23 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: Date: Sun, 2 Jan 2011 12:04:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <29AA82C4-6301-4DCD-BC9D-423AD162998E@gmail.com> References: <4D20C8BF.701@freebsd.org> To: Garrett Cooper X-Mailer: Apple Mail (2.1082) Cc: jhixson@gmail.com, freebsd-arch@FreeBSD.org, Nathan Whitehorn , Bruce Cran , matt@ixsystems.com, freebsd-sysinstall@freebsd.org Subject: Re: BSDInstall: I want the bikeshed painted plaid X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 20:04:25 -0000 On Jan 2, 2011, at 11:51 AM, Garrett Cooper wrote: > On Jan 2, 2011, at 10:49 AM, Nathan Whitehorn wrote: >=20 >> As those of you who obsessively follow the SVN commit mails may have = noticed, I recently began work on a new installer, which I have = tentatively named 'bsdinstall'. You can find the code itself at = svn://svn.freebsd.org/base/user/nwhitehorn/bsdinstall and a wiki page = describing it at http://wiki.freebsd.org/BSDInstall. >>=20 >> Why Plaid? >> ---------- >> This project started because we have never, in three major releases, = shipped an installer on PowerPC capable of installing a booting system = without absurd amounts of handholding and use of external tools. This is = especially galling when we have tools in the base (gpart, newfs, and = tar) fully capable of doing this. As it turns out, by the time you've = written a shell script to combine these things, you're well on your way = to deciding to write a new installer. >>=20 >> The goal of this project then, was to maximally reuse existing tools = and to make the installer a chain of easily modifiable or replaceable = components so that future installer-tinkerers will not run away in = terror as quickly as I and many others have from sysinstall and libdisk. >>=20 >> Architecture >> ------------ >> BSDInstall is a set of tools that are called in sequence by a master = script. These tools are, for example, the partition editor, the thing = that fetches the distributions from the network, the thing that untars = them, etc. Since these are just called in sequence from a shell script, = a scripted installation can easily replace them with other things, (e.g. = hard-coded gpart commands), leave steps out, add new ones, or interleave = additional system modifications. >>=20 >> Status >> ------ >> This provides almost all of the functionality of the existing = sysinstall 'Express' track, and works Right Now. It installs working, = bootable systems you can ssh into immediately after reboot on i386, = amd64, sparc64, powerpc, and powerpc64. There is untested support for = pc98. The final architecture on which we use sysinstall, ia64, is = currently unsupported, because I don't know how to set up booting on = those systems. >>=20 >> Paint Comes in Plaid? >> --------------------- >> With only a little more spit and polish, I think this could easily = replace sysinstall for the 9.0 release. It works right now on almost all = architectures for which we ship install media. There are no dependencies = on strange scripting languages, and only one on tools not currently in = the base system. >>=20 >> bsdinstall depends on the newer dialog and libdialog from Thomas = Dickey (devel/cdialog). This is LGPL2, but that is better than the = current dialog's license, and the software is so much better to develop = with than the current mess that is libdialog it might be good to have = anyway. In addition, I believe he is the sole author, and it's possible = he could be persuaded to relicense it. >>=20 >> I don't entirely know how all of this relates to pc-sysinstall. = pc-sysinstall has some more features (e.g. installation onto geli = disks), and certainly more thought went into it, but requires an immense = amount of work to make it work on non-x86 systems and a text front-end = is not yet complete. When it is ready, a lot of the infrastructural = changes required for bsdinstall (live CDs for installation, a new = libdialog, revised distfile format, etc.) will probably help = pc-sysinstall as well. >=20 > Please see pc-sysinstall if you like to see a different effort = in chartreuse. No guarantees as to how many x86-isms are in the = infrastructure. Should have read down to the bottom of the email... = pc-sysinstall really needs to be made non-x86 centric in order to be a = usable installer backend -- not sure how much effort has been put into = making this happen, but I _do_ have a PowerPC Mac I could test on so we = could work together to resolve any x86-isms and I might be able to hack = something together with mips in my spare time (I have potential access = to systems in my old work group, but I'd need to clear it with them = before I did anything with that). text-sysinstall was a WiP but = abandoned because some folks claimed that they were going to produce a = solution to that with lynx, a webserver, etc on install media. Looks = like that idea hasn't panned out though (it's been 2 months and I = haven't seen a prototype or mumbles on arch@, sysinstall@, etc), so a = libdialog-like solution is needed. Scripting changes should be = relatively cakewalk as long as I have a process for producing = pc-sysinstall based media, but there are other potential areas that need = to be audited for security issues in pc-sysinstall. Once upon a time = pc-sysinstall cached passwords on installed media based on some = discussions I had with Bruce Cran... not secure in the least; other = issues may lurk behind the scenes. Bruce Cran and I are interested parties in whatever will = transpire, so please let us know what you have planned. I think everyone can agree that sysinstall is dying and it's = time to sink some nails into its coffin before we send it on its way. Thanks, -Garrett= From owner-freebsd-arch@FreeBSD.ORG Sun Jan 2 20:19:52 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D0711065694; Sun, 2 Jan 2011 20:19:52 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id E04E28FC13; Sun, 2 Jan 2011 20:19:51 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 46E6A58137; Sun, 2 Jan 2011 14:19:51 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id 2zzY1LUDnxNS; Sun, 2 Jan 2011 14:19:51 -0600 (CST) Received: from wanderer.tachypleus.net (unknown [76.210.75.5]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 37D9858134; Sun, 2 Jan 2011 14:19:50 -0600 (CST) Message-ID: <4D20DDE4.8080306@freebsd.org> Date: Sun, 02 Jan 2011 14:19:48 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101227 Thunderbird/3.1.7 MIME-Version: 1.0 To: Garrett Cooper References: <4D20C8BF.701@freebsd.org> <29AA82C4-6301-4DCD-BC9D-423AD162998E@gmail.com> In-Reply-To: <29AA82C4-6301-4DCD-BC9D-423AD162998E@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jhixson@gmail.com, matt@ixsystems.com, Bruce Cran , freebsd-sysinstall@freebsd.org, freebsd-arch@FreeBSD.org Subject: Re: BSDInstall: I want the bikeshed painted plaid X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 20:19:52 -0000 On 01/02/11 14:04, Garrett Cooper wrote: > On Jan 2, 2011, at 11:51 AM, Garrett Cooper wrote: > >> On Jan 2, 2011, at 10:49 AM, Nathan Whitehorn wrote: >>> Paint Comes in Plaid? --------------------- With only a little >>> more spit and polish, I think this could easily replace >>> sysinstall for the 9.0 release. It works right now on almost all >>> architectures for which we ship install media. There are no >>> dependencies on strange scripting languages, and only one on >>> tools not currently in the base system. >>> >>> bsdinstall depends on the newer dialog and libdialog from Thomas >>> Dickey (devel/cdialog). This is LGPL2, but that is better than >>> the current dialog's license, and the software is so much better >>> to develop with than the current mess that is libdialog it might >>> be good to have anyway. In addition, I believe he is the sole >>> author, and it's possible he could be persuaded to relicense it. >>> >>> I don't entirely know how all of this relates to pc-sysinstall. >>> pc-sysinstall has some more features (e.g. installation onto geli >>> disks), and certainly more thought went into it, but requires an >>> immense amount of work to make it work on non-x86 systems and a >>> text front-end is not yet complete. When it is ready, a lot of >>> the infrastructural changes required for bsdinstall (live CDs for >>> installation, a new libdialog, revised distfile format, etc.) >>> will probably help pc-sysinstall as well. >> >> Please see pc-sysinstall if you like to see a different effort in >> chartreuse. No guarantees as to how many x86-isms are in the >> infrastructure. > > Should have read down to the bottom of the email... pc-sysinstall > really needs to be made non-x86 centric in order to be a usable > installer backend -- not sure how much effort has been put into > making this happen, but I _do_ have a PowerPC Mac I could test on so > we could work together to resolve any x86-isms and I might be able to > hack something together with mips in my spare time (I have potential > access to systems in my old work group, but I'd need to clear it with > them before I did anything with that). text-sysinstall was a WiP but > abandoned because some folks claimed that they were going to produce > a solution to that with lynx, a webserver, etc on install media. > Looks like that idea hasn't panned out though (it's been 2 months and > I haven't seen a prototype or mumbles on arch@, sysinstall@, etc), so > a libdialog-like solution is needed. Scripting changes should be > relatively cakewalk as long as I have a process for producing > pc-sysinstall based media, but there are other potential areas that > need to be audited for security issues in pc-sysinstall. Once upon a > time pc-sysinstall cached passwords on installed media based on some > discussions I had with Bruce Cran... not secure in the least; other > issues may lurk behind the scenes. Bruce Cran and I are interested > parties in whatever will transpire, so please let us know what you > have planned. I think everyone can agree that sysinstall is dying and > it's time to sink some nails into its coffin before we send it on its > way. > Thanks, -Garrett I spent a bunch of time looking at pc-sysinstall before starting to work on this. The major problem for non-x86 systems is that it heavily assumes that your disks are either MBR+bsdlabel or GPT. If you have anything different (APM, VTOC8, or even a raw bsdlabel or MBR installation on x86), it breaks in strange and fascinating ways due to a random mixture of if (scheme == MBR) else and if (scheme == GPT) else in the backend. Some of these are easily fixed, but it looked quite difficult to root out all of the places this assumption is made, not to mention teaching it about various styles of boot code, that the same partitioning scheme may need to be set up different ways on different architectures, etc. txt-sysinstall also segfaults when you try to run it on powerpc at the moment, though that is likely a simple bug and I didn't look into it in detail. What I intended with bsdinstall is to have something simple, flexible, and easily maintained that works immediately on all platforms and will be ready for 9.0 for sure. If pc-sysinstall materializes before then, or after then, and people like it better, I'm more than happy to get out of the way; this is the reason the wiki page is titled "Stopgap Installer". In the interim, I hoped to at least start laying out the hammer and nails next to sysinstall's coffin. -Nathan From owner-freebsd-arch@FreeBSD.ORG Sun Jan 2 20:35:53 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78F031065674; Sun, 2 Jan 2011 20:35:53 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 06D0C8FC14; Sun, 2 Jan 2011 20:35:53 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 1AA09E625D; Sun, 2 Jan 2011 20:35:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=rHWw/X5LB5t0 Wi3OUJfzl+tpazA=; b=gzkLM1AGhNTE6QrDT9VzCCDgndFQ28gIZMVF9NDtXTA1 nx21v/gVWfAW9LBCKrh+iKE2fHxZN+edYqGhHVKIC6DGvbUp8y0zyKedqxKr2FAf 11JVe3FGSYgnZuEVFLJzB3wQ6dh4JNdrnrutrQJi6KOkTnyTBq0a8igbGc7f5Dc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=UrylYL 16d447Bzkcw42LFTWAoQeBk257oMQnZvGvvlVf8/F9U9ubH82iVVd3b0KWleCkzM PKWZjdpd70p8t4RRAATRT9H9Cxzx2itZpCzM+L2Uqr3feMzjBSl0T7XqZf9yu4mp cxbVRINYTfL7YHYj1xptsnm14aqDb7Hv+GC3E= Received: from unknown (client-86-27-23-77.glfd.adsl.virginmedia.com [86.27.23.77]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id B81DAE60EA; Sun, 2 Jan 2011 20:35:51 +0000 (GMT) Date: Sun, 2 Jan 2011 20:35:48 +0000 From: Bruce Cran To: Nathan Whitehorn Message-ID: <20110102203548.000052e8@unknown> In-Reply-To: <4D20C8BF.701@freebsd.org> References: <4D20C8BF.701@freebsd.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-sysinstall@freebsd.org, freebsd-arch@FreeBSD.org Subject: Re: BSDInstall: I want the bikeshed painted plaid X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 20:35:53 -0000 On Sun, 02 Jan 2011 12:49:35 -0600 Nathan Whitehorn wrote: > As those of you who obsessively follow the SVN commit mails may have > noticed, I recently began work on a new installer, which I have > tentatively named 'bsdinstall'. You can find the code itself at > svn://svn.freebsd.org/base/user/nwhitehorn/bsdinstall and a wiki page > describing it at http://wiki.freebsd.org/BSDInstall. You may want to reconsider having single large distfiles: people still want to do ftp installs over dialup and having chunks of around 10MB or so would allow downloads to be re-tried if the connection fails. Some people think modern FreeBSD releases shouldn't be installed on anything other than modern hardware and technologies (i.e. broadband), but I disagree. -- Bruce Cran From owner-freebsd-arch@FreeBSD.ORG Sun Jan 2 20:39:42 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9825C106564A; Sun, 2 Jan 2011 20:39:42 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 6E99F8FC14; Sun, 2 Jan 2011 20:39:42 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id D2E1F58139; Sun, 2 Jan 2011 14:39:41 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id sHD7Pli+e-b0; Sun, 2 Jan 2011 14:39:41 -0600 (CST) Received: from wanderer.tachypleus.net (unknown [76.210.75.5]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 497235811D; Sun, 2 Jan 2011 14:39:41 -0600 (CST) Message-ID: <4D20E28C.4090907@freebsd.org> Date: Sun, 02 Jan 2011 14:39:40 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101227 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bruce Cran References: <4D20C8BF.701@freebsd.org> <20110102203548.000052e8@unknown> In-Reply-To: <20110102203548.000052e8@unknown> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-sysinstall@freebsd.org, freebsd-arch@FreeBSD.org Subject: Re: BSDInstall: I want the bikeshed painted plaid X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 20:39:42 -0000 On 01/02/11 14:35, Bruce Cran wrote: > On Sun, 02 Jan 2011 12:49:35 -0600 > Nathan Whitehorn wrote: > >> As those of you who obsessively follow the SVN commit mails may have >> noticed, I recently began work on a new installer, which I have >> tentatively named 'bsdinstall'. You can find the code itself at >> svn://svn.freebsd.org/base/user/nwhitehorn/bsdinstall and a wiki page >> describing it at http://wiki.freebsd.org/BSDInstall. > > You may want to reconsider having single large distfiles: people still > want to do ftp installs over dialup and having chunks of around 10MB or > so would allow downloads to be re-tried if the connection fails. > Some people think modern FreeBSD releases shouldn't be installed on > anything other than modern hardware and technologies (i.e. broadband), > but I disagree. > That's a good point. I was planning on using libfetch's restart feature for this case. Do you think that would be unreliable? -Nathan From owner-freebsd-arch@FreeBSD.ORG Sun Jan 2 20:43:41 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E40F1106566B; Sun, 2 Jan 2011 20:43:41 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 992288FC12; Sun, 2 Jan 2011 20:43:41 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id B131DE625D; Sun, 2 Jan 2011 20:43:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=aC9ZMf68tB/w 01yMTp5ANMJLp8Q=; b=fN7NQWhvGTOwkPbQ7f29TipC5u3osX6mGNo+qhgmgsVa urAPAOV39ajoMQQ7Zw3HaaOf6QveeUgBLBPe/4mCrfGPKo90t6JbgU8ch3nzQCOw 0KyPEp89rxdtlNuRjLbGumzLQSQMeeuZLhnj52Urs6EgAY/agyJrei00gjgNxAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=B61GcI 4SuKbQullZmWMHXA7NA4GMZktDIBzuvoqr1iBCDuCE9hGR9hAmDDMfV+jpUN7uS3 1BE7aOKLPhjF3cMBK4fP4a8ghknowiquMA781Cv0sihZP2uwKOnL3elE2D5kgFh8 es8WcMQpHfTrH33+ylFxle56sz31TGQZtkWqs= Received: from unknown (client-86-27-23-77.glfd.adsl.virginmedia.com [86.27.23.77]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 637A2E60EA; Sun, 2 Jan 2011 20:43:40 +0000 (GMT) Date: Sun, 2 Jan 2011 20:43:37 +0000 From: Bruce Cran To: Nathan Whitehorn Message-ID: <20110102204337.0000324f@unknown> In-Reply-To: <4D20E28C.4090907@freebsd.org> References: <4D20C8BF.701@freebsd.org> <20110102203548.000052e8@unknown> <4D20E28C.4090907@freebsd.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-sysinstall@freebsd.org, freebsd-arch@FreeBSD.org Subject: Re: BSDInstall: I want the bikeshed painted plaid X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 20:43:42 -0000 On Sun, 02 Jan 2011 14:39:40 -0600 Nathan Whitehorn wrote: > That's a good point. I was planning on using libfetch's restart > feature for this case. Do you think that would be unreliable? I'm not sure enough servers support it that you could rely on it. -- Bruce Cran From owner-freebsd-arch@FreeBSD.ORG Sun Jan 2 22:02:57 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 055BE106564A; Sun, 2 Jan 2011 22:02:57 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 190FE8FC0C; Sun, 2 Jan 2011 22:02:55 +0000 (UTC) Received: by wwf26 with SMTP id 26so12730849wwf.31 for ; Sun, 02 Jan 2011 14:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ZZWIIq+Kp2iQtNYSNJJqSiNaHmLR3IPCLkNJBKBuRFg=; b=C4N2t7uHxSAEZ2e2F09oOKmgslF+AV+guQ6pVBNCI2mMLWg3ich2mAdnTd8fwuuXYM BYtYTZ+gCRIpXSZ6jNE296HMwPoUFk3im/4VLkOAh1mzNu4gSbhnulceZ35Tz+xo0FvH C+cCH7TM4s1LpI7GM6qpfbe43kpASt8W4i4J4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GMi02RMdWYpOp4/DPdiB3Nox7Zk2yr5G1W80G8BVWg5vePSBaag8dsfHTysMPP2Ps4 XHv9d8KKXRj5Lq9ujzAE2HuLi1OB1h1p2Qrxi6Qyg6NAgOPI5EQQtPOcBtz67g2IkV3r 0+etSBdYcco/BpkAfLo4hWEYhq3F8RRZeuj3g= MIME-Version: 1.0 Received: by 10.216.78.146 with SMTP id g18mr590783wee.1.1294005774969; Sun, 02 Jan 2011 14:02:54 -0800 (PST) Received: by 10.216.254.226 with HTTP; Sun, 2 Jan 2011 14:02:54 -0800 (PST) In-Reply-To: References: <4D20C8BF.701@freebsd.org> <29AA82C4-6301-4DCD-BC9D-423AD162998E@gmail.com> <4D20DDE4.8080306@freebsd.org> Date: Sun, 2 Jan 2011 14:02:54 -0800 Message-ID: From: Garrett Cooper To: John Hixson Content-Type: text/plain; charset=ISO-8859-1 Cc: Bruce Cran , freebsd-sysinstall@freebsd.org, Nathan Whitehorn , matt@ixsystems.com, freebsd-arch@freebsd.org Subject: Re: BSDInstall: I want the bikeshed painted plaid X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 22:02:57 -0000 On Sun, Jan 2, 2011 at 1:51 PM, John Hixson wrote: > > > On Sun, Jan 2, 2011 at 12:19 PM, Nathan Whitehorn > wrote: >> >> I spent a bunch of time looking at pc-sysinstall before starting to work >> on this. The major problem for non-x86 systems is that it heavily assumes >> that your disks are either MBR+bsdlabel or GPT. If you have anything >> different (APM, VTOC8, or even a raw bsdlabel or MBR installation on x86), >> it breaks in strange and fascinating ways due to a random mixture of if >> (scheme == MBR) else and if (scheme == GPT) else in the backend. Some of >> these are easily fixed, but it looked quite difficult to root out all of the >> places this assumption is made, not to mention teaching it about various >> styles of boot code, that the same partitioning scheme may need to be set up >> different ways on different architectures, etc. txt-sysinstall also >> segfaults when you try to run it on powerpc at the moment, though that is >> likely a simple bug and I didn't look into it in detail. >> >> What I intended with bsdinstall is to have something simple, flexible, and >> easily maintained that works immediately on all platforms and will be ready >> for 9.0 for sure. If pc-sysinstall materializes before then, or after then, >> and people like it better, I'm more than happy to get out of the way; this >> is the reason the wiki page is titled "Stopgap Installer". In the interim, I >> hoped to at least start laying out the hammer and nails next to sysinstall's >> coffin. >> -Nathan >> > > I would be more than happy to help out with making pc-sysinstall work on > non-x86 systems, however I don't have access to any. Do any of you have > hardware that could possibly be used by interested parties? I'm sure all the > work that's gone into bsdinstall could be used in pc-sysinstall or vice > versa. I have a powerpc mac and I might be able to scrounge up another powerbook. Not sure if the powerbook is DoA or not as I don't have the adapter anymore... Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Sun Jan 2 22:12:27 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98967106564A; Sun, 2 Jan 2011 22:12:27 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 1990B8FC0A; Sun, 2 Jan 2011 22:12:26 +0000 (UTC) Received: from rbpbp.gid.co.uk (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id p02LpOxl000681; Sun, 2 Jan 2011 21:51:24 GMT (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: <29AA82C4-6301-4DCD-BC9D-423AD162998E@gmail.com> Date: Sun, 2 Jan 2011 21:51:18 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3521807A-456D-482B-B79C-260E7FEB5941@gid.co.uk> References: <4D20C8BF.701@freebsd.org> <29AA82C4-6301-4DCD-BC9D-423AD162998E@gmail.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1082) Cc: jhixson@gmail.com, freebsd-arch@freebsd.org, Nathan Whitehorn , Bruce Cran , matt@ixsystems.com, freebsd-sysinstall@freebsd.org Subject: Re: BSDInstall: I want the bikeshed painted plaid X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 22:12:27 -0000 Hi, On 2 Jan 2011, at 20:04, Garrett Cooper wrote: > I think everyone can agree that sysinstall is dying and it's time to = sink some nails into its coffin before we send it on its way. A stake through its cold black heart and a full magazine of silver = bullets to the head might be more apposite. -- Bob Bishop rb@gid.co.uk From owner-freebsd-arch@FreeBSD.ORG Sun Jan 2 22:19:08 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 667A2106564A; Sun, 2 Jan 2011 22:19:08 +0000 (UTC) (envelope-from jhixson@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 01DEF8FC18; Sun, 2 Jan 2011 22:19:07 +0000 (UTC) Received: by iyb26 with SMTP id 26so12156451iyb.13 for ; Sun, 02 Jan 2011 14:19:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=QamlmbxhNZdiVnRbzgulB310zKDb1+Z4pOXiICWSnqE=; b=c2kMP8AZEyABxUvpRT63MouIszIYKbMyhBMbKgvMSn3d6jDGgdIxUVuHNzIaM5hhc0 onrzTNYE/SYakgVSdGb8Sfs7491aNyWMhWWTp/YY6FdgvXjIG1eM6z2w5Gg1M5EnYCVZ /nTvjtniXm59rYhwicEqXNMr352/qNw5xbPhw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=R1s1+WEnP1yIbj+oJaylK3aTcMYfFakDYgUEM3Rwsr7fAp7K6D+td3PNmlAdDo24Vx USMDXYO9va76zyFx/6icPH8JKJKS8aJhnkjQq7M/FHDgHxmXPdD1+r8IVMMwvfnsYhet B1CN1XKGtU62344+HyhVZhpd0mIyYFZboSyc8= MIME-Version: 1.0 Received: by 10.42.167.131 with SMTP id s3mr20338648icy.288.1294005105684; Sun, 02 Jan 2011 13:51:45 -0800 (PST) Received: by 10.42.58.72 with HTTP; Sun, 2 Jan 2011 13:51:45 -0800 (PST) In-Reply-To: <4D20DDE4.8080306@freebsd.org> References: <4D20C8BF.701@freebsd.org> <29AA82C4-6301-4DCD-BC9D-423AD162998E@gmail.com> <4D20DDE4.8080306@freebsd.org> Date: Sun, 2 Jan 2011 13:51:45 -0800 Message-ID: From: John Hixson To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Garrett Cooper , matt@ixsystems.com, Bruce Cran , freebsd-sysinstall@freebsd.org, freebsd-arch@freebsd.org Subject: Re: BSDInstall: I want the bikeshed painted plaid X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 22:19:08 -0000 On Sun, Jan 2, 2011 at 12:19 PM, Nathan Whitehorn wrote: > > I spent a bunch of time looking at pc-sysinstall before starting to work on > this. The major problem for non-x86 systems is that it heavily assumes that > your disks are either MBR+bsdlabel or GPT. If you have anything different > (APM, VTOC8, or even a raw bsdlabel or MBR installation on x86), it breaks > in strange and fascinating ways due to a random mixture of if (scheme == > MBR) else and if (scheme == GPT) else in the backend. Some of these are > easily fixed, but it looked quite difficult to root out all of the places > this assumption is made, not to mention teaching it about various styles of > boot code, that the same partitioning scheme may need to be set up different > ways on different architectures, etc. txt-sysinstall also segfaults when you > try to run it on powerpc at the moment, though that is likely a simple bug > and I didn't look into it in detail. > > What I intended with bsdinstall is to have something simple, flexible, and > easily maintained that works immediately on all platforms and will be ready > for 9.0 for sure. If pc-sysinstall materializes before then, or after then, > and people like it better, I'm more than happy to get out of the way; this > is the reason the wiki page is titled "Stopgap Installer". In the interim, I > hoped to at least start laying out the hammer and nails next to sysinstall's > coffin. > -Nathan > > I would be more than happy to help out with making pc-sysinstall work on non-x86 systems, however I don't have access to any. Do any of you have hardware that could possibly be used by interested parties? I'm sure all the work that's gone into bsdinstall could be used in pc-sysinstall or vice versa. - John From owner-freebsd-arch@FreeBSD.ORG Sun Jan 2 22:31:21 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DBA4106566B for ; Sun, 2 Jan 2011 22:31:21 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 89BDE8FC14 for ; Sun, 2 Jan 2011 22:31:20 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 02931359956 for ; Sun, 2 Jan 2011 23:31:19 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id EDD9A1727D; Sun, 2 Jan 2011 23:31:18 +0100 (CET) Date: Sun, 2 Jan 2011 23:31:18 +0100 From: Jilles Tjoelker To: freebsd-arch@freebsd.org Message-ID: <20110102223118.GA95551@stack.nl> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: init(8) running rc.shutdown inappropriately, mechanism for halt(8)/reboot(8) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 22:31:21 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline As discussed on the svn-src commits mailing list, I think halt and reboot should be changed to trigger the shutdown by sending a signal to init, either directly or by calling shutdown. The new poweroff utility should do the same as halt -p. A new -f option and the filenames fastboot and fasthalt keep the current behaviour of killing all processes and calling reboot(2) directly, and the same applies if one of the options -d, -n and -q is used (which cannot be passed to init). I'm aware of shutdown's -o option which makes it call halt(8) or reboot(8). These invocations should gain the -f option or change to fasthalt/fastboot. The current halt and reboot programs do not run /etc/rc.shutdown, which may cause daemons not to be shut down correctly. At this time, there is no way to fix this properly, because /etc/rc.shutdown should not be run from single-user mode (if this is done, /etc/rc.d/mixer overwrites /var/db/mixer*-state with the defaults, for example) and reboot has no way to know this. When rebooting by sending a signal to init (directly, via ctrl+alt+del, by re-executing /sbin/init or via shutdown), /etc/rc.shutdown is always executed. The attached patch changes this, executing it only if /etc/rc has completed. The bigger-picture goal is to make all the common ways of shutting down (ctrl+alt+del, shutdown(8), halt(8), reboot(8), poweroff(8)) work properly both in single-user and multi-user. Currently, only ctrl+alt+del, shutdown(8) and poweroff(8) work properly in multi-user, while only halt(8) and reboot(8) work properly in single-user. The patch also fixes segfaults and other erratic behaviour if init receives SIGHUP or SIGTSTP while in single-user mode. The patch does not attempt to fix any badness with signal handlers (assumption that pointers can be read and written atomically, EINTR race condition). I believe the patch does not make this badness any worse. If the attachment does not work, the patch is also here for some time: http://www.stack.nl/~jilles/unix/init-fixes-20110102.patch -- Jilles Tjoelker --CE+1k2dSO48ffgeK Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="init-fixes-20110102.patch" Index: sbin/init/init.c =================================================================== --- sbin/init/init.c (revision 216859) +++ sbin/init/init.c (working copy) @@ -122,6 +122,7 @@ static state_func_t clean_ttys(void); static state_func_t catatonia(void); static state_func_t death(void); +static state_func_t death_single(void); static state_func_t run_script(const char *); @@ -136,6 +137,7 @@ static void transition(state_t); static state_t requested_transition; +static state_t current_state = death_single; static void setctty(const char *); static const char *get_shell(void); @@ -559,8 +561,9 @@ transition(state_t s) { + current_state = s; for (;;) - s = (state_t) (*s)(); + current_state = (state_t) (*current_state)(); } /* @@ -796,7 +799,7 @@ * Returns 0 on success, otherwise the next transition to enter: * - single_user if fork/execv/waitpid failed, or if the script * terminated with a signal or exit code != 0. - * - death if a SIGTERM was delivered to init(8). + * - death_single if a SIGTERM was delivered to init(8). */ static state_func_t run_script(const char *script) @@ -852,8 +855,8 @@ if ((wpid = waitpid(-1, &status, WUNTRACED)) != -1) collect_child(wpid); if (wpid == -1) { - if (requested_transition == death) - return (state_func_t) death; + if (requested_transition == death_single) + return (state_func_t) death_single; if (errno == EINTR) continue; warning("wait for %s on %s failed: %m; going to " @@ -1306,7 +1309,9 @@ switch (sig) { case SIGHUP: - requested_transition = clean_ttys; + if (current_state == read_ttys || current_state == multi_user || + current_state == clean_ttys || current_state == catatonia) + requested_transition = clean_ttys; break; case SIGUSR2: howto = RB_POWEROFF; @@ -1315,10 +1320,17 @@ case SIGINT: Reboot = TRUE; case SIGTERM: - requested_transition = death; + if (current_state == read_ttys || current_state == multi_user || + current_state == clean_ttys || current_state == catatonia) + requested_transition = death; + else + requested_transition = death_single; break; case SIGTSTP: - requested_transition = catatonia; + if (current_state == runcom || current_state == read_ttys || + current_state == clean_ttys || + current_state == multi_user || current_state == catatonia) + requested_transition = catatonia; break; default: requested_transition = 0; @@ -1494,9 +1506,6 @@ { struct utmpx utx; session_t *sp; - int i; - pid_t pid; - static const int death_sigs[2] = { SIGTERM, SIGKILL }; /* NB: should send a message to the session logger to avoid blocking. */ utx.ut_type = SHUTDOWN_TIME; @@ -1518,6 +1527,22 @@ /* Try to run the rc.shutdown script within a period of time */ runshutdown(); + return (state_func_t) death_single; +} + +/* + * Do what is necessary to reinitialize single user mode or reboot + * from an incomplete state. + */ +static state_func_t +death_single(void) +{ + int i; + pid_t pid; + static const int death_sigs[2] = { SIGTERM, SIGKILL }; + + revoke(_PATH_CONSOLE); + for (i = 0; i < 2; ++i) { if (kill(-1, death_sigs[i]) == -1 && errno == ESRCH) return (state_func_t) single_user; --CE+1k2dSO48ffgeK-- From owner-freebsd-arch@FreeBSD.ORG Mon Jan 3 03:54:58 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 249D6106566B; Mon, 3 Jan 2011 03:54:58 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id F03F08FC0C; Mon, 3 Jan 2011 03:54:57 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 50EA458134; Sun, 2 Jan 2011 21:54:57 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id wGgi5r440bWt; Sun, 2 Jan 2011 21:54:57 -0600 (CST) Received: from wanderer.tachypleus.net (unknown [76.210.75.5]) by mail.icecube.wisc.edu (Postfix) with ESMTP id DA04B5811B; Sun, 2 Jan 2011 21:54:56 -0600 (CST) Message-ID: <4D21488F.90107@freebsd.org> Date: Sun, 02 Jan 2011 21:54:55 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101227 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org, freebsd-sysinstall@freebsd.org References: <4D20C8BF.701@freebsd.org> In-Reply-To: <4D20C8BF.701@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: BSDInstall: I want the bikeshed painted plaid X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 03:54:58 -0000 On 01/02/11 12:49, Nathan Whitehorn wrote: > As those of you who obsessively follow the SVN commit mails may have > noticed, I recently began work on a new installer, which I have > tentatively named 'bsdinstall'. You can find the code itself at > svn://svn.freebsd.org/base/user/nwhitehorn/bsdinstall and a wiki page > describing it at http://wiki.freebsd.org/BSDInstall. > By popular demand, I have made some images for people to experiment with. These are at http://people.freebsd.org/~nwhitehorn/test-bsdinstall.img.bz2 (raw image) and http://people.freebsd.org/~nwhitehorn/test-bsdinstall.vdi.bz2 (VirtualBox image). The root password is 'bsdinstall', and further instructions are in the motd. -Nathan From owner-freebsd-arch@FreeBSD.ORG Mon Jan 3 17:02:00 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F8301065670; Mon, 3 Jan 2011 17:02:00 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 39E2F8FC1B; Mon, 3 Jan 2011 17:01:59 +0000 (UTC) Received: by iwn39 with SMTP id 39so13811836iwn.13 for ; Mon, 03 Jan 2011 09:01:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=nbVPQw35YgttEVtKpwKmXy6yJpDmDuNCwsR2mvr8t90=; b=MfVqDmaUpvchQQHyh+LcA8ulGVPXWczrYszGvhR2RhhIoPonpzze50doANaxQNloSf xZT/6leAg2CDEixX9gfPJekffknVEJk0LnawEuJm1dYylCOX9W4zloSRAERnqrjsFWbr R1Nhz1z+zy4U6Y1X/UA0kvynphBhQQXqC0KfA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qDkJegy1oRO+MfpJfe18KP/WWQObYhmPLB2I1DI639DERAIPtQ64LiNO71gBc4kU3r m3akSvSM9rpY+vdnhHUgV35fINoNRnqjxhluz8AW4tR046AXbv6+qPeiGu+KDkTLvwBj PInqK5eXClEPfxSqYvOiKQwbDDi+epQUBITh4= MIME-Version: 1.0 Received: by 10.231.206.206 with SMTP id fv14mr4209473ibb.75.1294072599090; Mon, 03 Jan 2011 08:36:39 -0800 (PST) Received: by 10.231.79.197 with HTTP; Mon, 3 Jan 2011 08:36:39 -0800 (PST) In-Reply-To: <4D21488F.90107@freebsd.org> References: <4D20C8BF.701@freebsd.org> <4D21488F.90107@freebsd.org> Date: Mon, 3 Jan 2011 11:36:39 -0500 Message-ID: From: Mehmet Erol Sanliturk To: Nathan Whitehorn Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-sysinstall@freebsd.org, freebsd-arch@freebsd.org Subject: Re: BSDInstall: I want the bikeshed painted plaid X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 17:02:00 -0000 On Sun, Jan 2, 2011 at 10:54 PM, Nathan Whitehorn wrote: > On 01/02/11 12:49, Nathan Whitehorn wrote: > >> As those of you who obsessively follow the SVN commit mails may have >> noticed, I recently began work on a new installer, which I have >> tentatively named 'bsdinstall'. You can find the code itself at >> svn://svn.freebsd.org/base/user/nwhitehorn/bsdinstall and a wiki page >> describing it at http://wiki.freebsd.org/BSDInstall. >> >> > Personally I am installing many Linux and BSD operating systems to learn their features as much as possible and to utilize some of them for software development and a base for my developed applications . Up to now I could NOT be able to advance very much . In my daily operations , use of Mandriva Linux come out the best , and continuously I am using it . The main distinguishing differences for me are the following : - For the ordinary user ( not the root or as super user ) : - When a USB stick or external hard disk is attached , automatic mounting and usability of it ( read , write ) at least FAT or NTFS formatted ones ( Mandriva Linux requires other ones to be root mounted , as default ) . - Auto mount of CD or DVD ( especially ones containing data ) . - Usability of USB attached devices such as web camera . - Burning CD or DVD without interfering super user or root privileges . - Allowance of root login in GUI mode at the start up without entry from ordinary user mode into root mode . ( Debian Linux has such an option which asks to root whether root logins will be possible or not in GUI mode . Mandriva Linux has safe mode login with ability using KDE/GNOME ( the installed one ) by startx command , or choice from menu as Console login , and then issuing startx ) . All of the above features are available in Mandriva Linux , and Fedora or Debian Linux ( I did not burn CD or DVD in Fedora or Debian Linux ) . In FreeBSD , after an install , by following a pile of flash cards , it is necessary to enter some of the above features one by one . Up to now I could NOT be able to achieve burning of CD/DVD , auto mount CD/DVD or USB sticks , even I did NOT try to attach external HDD . I am using PC-BSD . It is allowing DVD burning with K3b version 1.0.5 , but very slowly which may be considered unusable . After burning 9 more DVDs , I will erase PC-BSD because I could NOT be able to manage its KDE wall paper which changing it itself , but it is irritating me very much . ( There is NO root login , automounts USB sticks , but not NTFS external HDD ) . Among the BSD operating systems , the best is FreeBSD , with the above missing parts ( at least for me . I can not work with it easily , this may mean that other people will have much more difficulty than me ( I have a PhD in Computer Engineering , and my life is passing in front of the personal computers .) . Another most important problem is hard disk partitioning . In Mandriva Linux , there are two main partitions : sda1 for operating system ( / ) sda6 for /home . During install , if there is an installed system which will be replaced : Check - Install ( upgrade is also available , Install fully installs from scratch ) - Use current partitions It is asking mount points : Give sda1 as / sda6 as /home . It is formatting ONLY and ONLY sda1 , but NOT sda6 ( /home ) . The only loss is user names . During user definitions , IF the SAME USER NAMES are given , all of the data are again belong to their original users without any loss . In that way , I am able to install any new Mandriva Linux version easily . Even when older installed structure is ext3 , but new version is ext4 , it is installing ext3 for the older available structure . I have noticed this after installing all of the operating system on a new disk . Its file system was ext4 , the other one ext3 ( installed on older version ) . My conclusion is that , the hard disk layout structure of FreeBSD , really needs a new design . I am so desperate about such installs that , I am thinking to write a new install program with respect to my experiences . My difficulty is I am not using C and not fluent as much as to write a competent install program . My ideas about partitions are as follows : Partition 1 : Operating System . 2 : Packages / Ports used globally 3 : User definitions ( names , privileges , passwords , etc ) 4 : /home : User data directories ( each user will have a jailed environment , means he/she will be able to pkg_add into HIS/HER environment . The root will add them for global use ) 5. ... others . With one important feature : Partitions 2 , 3 , 4 should be assignable to either a single disk ( with the 1 : Operating system partition ) or MULTIPLE , DIFFERENT disks : In that way default home will be /home , additional home directories in different disk units , for example /homeA , /homeB , ... Therefore , during user definitions , it should be possible to specify his/her home explicitly when there are multiple home directories . With the above layout , it will be possible to install operating system ONLY into its own partition without touching to other partitions when it is decided to upgrade a system in that way . Installing the operating system in the following way , may allow experimenting and using different versions on the same system : /FreeBSD /FreeBSD/8.2/ /FreeBSD/8.3/ /FreeBSD/9.0/ etc. , each one in its own directory with the usual subdirectories . For the packages , require that each package installs into ... /package_name/version/ which will allow installation of different versions in the same partition ( some of the packages are using this structure , but not all of the ) . This is important for different operating system versions . When an additional Operating system is installed , it will FORMAT its own directories , IF there are EXISTING other versions , with some other necessary options , such Format ALL of them . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-arch@FreeBSD.ORG Mon Jan 3 20:50:37 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AAF1106566C for ; Mon, 3 Jan 2011 20:50:37 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id D16348FC0C for ; Mon, 3 Jan 2011 20:50:36 +0000 (UTC) Received: by wyf19 with SMTP id 19so13694620wyf.13 for ; Mon, 03 Jan 2011 12:50:36 -0800 (PST) Received: by 10.216.0.140 with SMTP id 12mr8054734web.29.1294086523318; Mon, 03 Jan 2011 12:28:43 -0800 (PST) Received: from [10.0.1.198] ([72.253.42.56]) by mx.google.com with ESMTPS id 7sm10094615wet.24.2011.01.03.12.28.41 (version=SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 12:28:42 -0800 (PST) Date: Mon, 3 Jan 2011 10:31:24 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: arch@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 20:50:37 -0000 Hello Folks, Some of you may have seen my infiniband work proceed in svn. It is coming to a close soon and I will be integrating it into current. I have a few patches to the kernel to send for review but I wanted to bring up the KPI wrapper itself for discussion. The infiniband port has been done by creating a 10,000 line KPI compatability layer. With this layer the vast majority of the driver code runs unmodified. The exceptions are anything that interfaces with skbs and most of the code that deals with network interfaces. Some examples of things supported by the wrapper: atomics, types, bitops, byte order conversion, character devices, pci devices, dma, non-device files, idr tables, interrupts, ioremap, hashes, kobjects, radix trees, lists, modules, notifier blocks, rbtrees, rwlock, rwsem, semaphore, schedule, spinlocks, kalloc, wait queues, workqueues, timers, etc. Obviously a complete wrapper is impossible and I only implemented the features that I needed. The build is accomplished by pointing the linux compatible code at sys/ofed/include/ which has a simulated linux kernel include tree. There are some config(8) changes to help this along as well. I have seen that some attempt at similar wrappers has been made elsewhere. I wonder if instead of making each one tailored to individual components, which mostly seem to be filesystems so far, should we put this in a central place under compat somewhere? Is this project doomed to be tied to a single consumer by the specific nature of it? Other comments or concerns? Thanks, Jeff From owner-freebsd-arch@FreeBSD.ORG Mon Jan 3 21:14:18 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A341106566C for ; Mon, 3 Jan 2011 21:14:18 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 400F08FC12 for ; Mon, 3 Jan 2011 21:14:18 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id BCF493F610; Mon, 3 Jan 2011 20:56:39 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id p03Kudwk082827; Mon, 3 Jan 2011 20:56:39 GMT (envelope-from phk@critter.freebsd.dk) To: Jeff Roberson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 03 Jan 2011 10:31:24 -1000." Date: Mon, 03 Jan 2011 20:56:39 +0000 Message-ID: <82826.1294088199@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 21:14:18 -0000 In message , Jeff Roberson writes: >I have seen that some attempt at similar wrappers has been made elsewhere. >I wonder if instead of making each one tailored to individual components, >which mostly seem to be filesystems so far, should we put this in a >central place under compat somewhere? My inflation devalued $0.02: We should face our NIH syndrome and for those differences between Linux and FreeBSD KPI which are purely a naming or trivial argument difference, try to reduce the differences. Those where there are substantial differences, we should only have one compat layer, not one for each driver. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Jan 3 21:18:42 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51933106564A for ; Mon, 3 Jan 2011 21:18:42 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 307378FC14 for ; Mon, 3 Jan 2011 21:18:41 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 223EE1A3C3A; Mon, 3 Jan 2011 13:02:24 -0800 (PST) Date: Mon, 3 Jan 2011 13:02:23 -0800 From: Alfred Perlstein To: Jeff Roberson Message-ID: <20110103210223.GV2973@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 21:18:42 -0000 * Jeff Roberson [110103 12:51] wrote: > Hello Folks, > > Some of you may have seen my infiniband work proceed in svn. It is coming > to a close soon and I will be integrating it into current. I have a few > patches to the kernel to send for review but I wanted to bring up the KPI > wrapper itself for discussion. > > The infiniband port has been done by creating a 10,000 line KPI > compatability layer. With this layer the vast majority of the driver code > runs unmodified. The exceptions are anything that interfaces with skbs > and most of the code that deals with network interfaces. > > Some examples of things supported by the wrapper: > > atomics, types, bitops, byte order conversion, character devices, pci > devices, dma, non-device files, idr tables, interrupts, ioremap, hashes, > kobjects, radix trees, lists, modules, notifier blocks, rbtrees, rwlock, > rwsem, semaphore, schedule, spinlocks, kalloc, wait queues, workqueues, > timers, etc. > > Obviously a complete wrapper is impossible and I only implemented the > features that I needed. The build is accomplished by pointing the linux > compatible code at sys/ofed/include/ which has a simulated linux kernel > include tree. There are some config(8) changes to help this along as > well. > > I have seen that some attempt at similar wrappers has been made elsewhere. > I wonder if instead of making each one tailored to individual components, > which mostly seem to be filesystems so far, should we put this in a > central place under compat somewhere? Is this project doomed to be tied > to a single consumer by the specific nature of it? > > Other comments or concerns? I think this is really cool. Brilliant actually. What do you think about proposing it on some standards list as a cross unix KPI? That way we can see upcoming changes and maybe have a say in pushing back on gratuitous changes that would break our clients? -Alfred From owner-freebsd-arch@FreeBSD.ORG Mon Jan 3 23:16:16 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D26C0106566B for ; Mon, 3 Jan 2011 23:16:16 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f68.google.com (mail-ww0-f68.google.com [74.125.82.68]) by mx1.freebsd.org (Postfix) with ESMTP id 66A3F8FC08 for ; Mon, 3 Jan 2011 23:16:16 +0000 (UTC) Received: by wwj40 with SMTP id 40so5055569wwj.7 for ; Mon, 03 Jan 2011 15:16:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=aPRBEPjmtNdPIS1MWoJbXWl10uwjgFk9dl2Je9uDp3w=; b=X6VARJP+bvhiJnG47d42N/VmRlsJKjj95+bGkII8kIvAz8q2bZi2Qdbdl3UhUt/E8S NdW4FEBJlT6TOPNKmrfSyGtniu2Kl74EZxyVcqWHQCQzFQ5QNczCvOA9As/vA4Muju+V 5V5zkms+rDPDfX67drV3KiahmZAh5CymMbO6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=iMDv1r8T8FshuU6TmYNzCX5jHQKG8LfX6D1A+z70NIqk92ICu1VIgwTmWr5JkdzFZf PI2Ia9MW0ZBsbymsEIaS4E09LUiFOe0kCFtZBeAUOcZtB6u+bDwsLcHAxgTEP0Od8+vJ a4fQyLRCUn57VWA0Gzz24FSj5zdtnYymq5NyY= MIME-Version: 1.0 Received: by 10.216.78.146 with SMTP id g18mr1748871wee.1.1294095749533; Mon, 03 Jan 2011 15:02:29 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.254.226 with HTTP; Mon, 3 Jan 2011 15:02:29 -0800 (PST) In-Reply-To: <20110103210223.GV2973@elvis.mu.org> References: <20110103210223.GV2973@elvis.mu.org> Date: Mon, 3 Jan 2011 15:02:29 -0800 X-Google-Sender-Auth: LdQPSyn9neQWrmoVXijeUCpBM7U Message-ID: From: Garrett Cooper To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 23:16:17 -0000 On Mon, Jan 3, 2011 at 1:02 PM, Alfred Perlstein wrote= : > * Jeff Roberson [110103 12:51] wrote: >> Hello Folks, >> >> Some of you may have seen my infiniband work proceed in svn. =A0It is co= ming >> to a close soon and I will be integrating it into current. =A0I have a f= ew >> patches to the kernel to send for review but I wanted to bring up the KP= I >> wrapper itself for discussion. >> >> The infiniband port has been done by creating a 10,000 line KPI >> compatability layer. =A0With this layer the vast majority of the driver = code >> runs unmodified. =A0The exceptions are anything that interfaces with skb= s >> and most of the code that deals with network interfaces. >> >> Some examples of things supported by the wrapper: >> >> atomics, types, bitops, byte order conversion, character devices, pci >> devices, dma, non-device files, idr tables, interrupts, ioremap, hashes, >> kobjects, radix trees, lists, modules, notifier blocks, rbtrees, rwlock, >> rwsem, semaphore, schedule, spinlocks, kalloc, wait queues, workqueues, >> timers, etc. >> >> Obviously a complete wrapper is impossible and I only implemented the >> features that I needed. =A0The build is accomplished by pointing the lin= ux >> compatible code at sys/ofed/include/ which has a simulated linux kernel >> include tree. =A0There are some config(8) changes to help this along as >> well. >> >> I have seen that some attempt at similar wrappers has been made elsewher= e. >> I wonder if instead of making each one tailored to individual components= , >> which mostly seem to be filesystems so far, should we put this in a >> central place under compat somewhere? =A0Is this project doomed to be ti= ed >> to a single consumer by the specific nature of it? >> >> Other comments or concerns? > > I think this is really cool. =A0Brilliant actually. > > What do you think about proposing it on some standards list as a > cross unix KPI? =A0That way we can see upcoming changes and maybe > have a say in pushing back on gratuitous changes that would break > our clients? That would be really nice, but I doubt people could agree on a single set of KPIs for everything and given the rate of progress with opengroup, I don't think it will fly (in particular with our and Linux's rate of development). Thankfully some of stuff (from what I've seen) is easy to port back and forth, but it varies depending on how tied the code is to the OS of course :(. Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Mon Jan 3 23:31:51 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D30721065670; Mon, 3 Jan 2011 23:31:51 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 74E148FC0C; Mon, 3 Jan 2011 23:31:51 +0000 (UTC) Received: by vws9 with SMTP id 9so5831546vws.13 for ; Mon, 03 Jan 2011 15:31:50 -0800 (PST) Received: by 10.220.176.10 with SMTP id bc10mr6857697vcb.52.1294097510449; Mon, 03 Jan 2011 15:31:50 -0800 (PST) Received: from [10.0.1.198] ([72.253.42.56]) by mx.google.com with ESMTPS id a6sm749194vcm.22.2011.01.03.15.31.47 (version=SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 15:31:49 -0800 (PST) Date: Mon, 3 Jan 2011 13:34:30 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Garrett Cooper In-Reply-To: Message-ID: References: <20110103210223.GV2973@elvis.mu.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2547152148-1943602431-1294097674=:1450" Cc: arch@freebsd.org, Alfred Perlstein Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 23:31:52 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2547152148-1943602431-1294097674=:1450 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 3 Jan 2011, Garrett Cooper wrote: > On Mon, Jan 3, 2011 at 1:02 PM, Alfred Perlstein wrote: >> * Jeff Roberson [110103 12:51] wrote: >>> Hello Folks, >>> >>> Some of you may have seen my infiniband work proceed in svn.  It is coming >>> to a close soon and I will be integrating it into current.  I have a few >>> patches to the kernel to send for review but I wanted to bring up the KPI >>> wrapper itself for discussion. >>> >>> The infiniband port has been done by creating a 10,000 line KPI >>> compatability layer.  With this layer the vast majority of the driver code >>> runs unmodified.  The exceptions are anything that interfaces with skbs >>> and most of the code that deals with network interfaces. >>> >>> Some examples of things supported by the wrapper: >>> >>> atomics, types, bitops, byte order conversion, character devices, pci >>> devices, dma, non-device files, idr tables, interrupts, ioremap, hashes, >>> kobjects, radix trees, lists, modules, notifier blocks, rbtrees, rwlock, >>> rwsem, semaphore, schedule, spinlocks, kalloc, wait queues, workqueues, >>> timers, etc. >>> >>> Obviously a complete wrapper is impossible and I only implemented the >>> features that I needed.  The build is accomplished by pointing the linux >>> compatible code at sys/ofed/include/ which has a simulated linux kernel >>> include tree.  There are some config(8) changes to help this along as >>> well. >>> >>> I have seen that some attempt at similar wrappers has been made elsewhere. >>> I wonder if instead of making each one tailored to individual components, >>> which mostly seem to be filesystems so far, should we put this in a >>> central place under compat somewhere?  Is this project doomed to be tied >>> to a single consumer by the specific nature of it? >>> >>> Other comments or concerns? >> >> I think this is really cool.  Brilliant actually. >> >> What do you think about proposing it on some standards list as a >> cross unix KPI?  That way we can see upcoming changes and maybe >> have a say in pushing back on gratuitous changes that would break >> our clients? > > That would be really nice, but I doubt people could agree on a > single set of KPIs for everything and given the rate of progress with > opengroup, I don't think it will fly (in particular with our and > Linux's rate of development). Thankfully some of stuff (from what I've > seen) is easy to port back and forth, but it varies depending on how > tied the code is to the OS of course :(. Also, linux likes to change things very rapidly. Not to mention a lot of their APIs go against the grain on BSD and we would not find them aesthetically or architecturally pleasing. Thanks, Jeff > Thanks, > -Garrett > --2547152148-1943602431-1294097674=:1450-- From owner-freebsd-arch@FreeBSD.ORG Mon Jan 3 23:45:19 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A232C106564A for ; Mon, 3 Jan 2011 23:45:19 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 61A288FC12 for ; Mon, 3 Jan 2011 23:45:19 +0000 (UTC) Received: by vws9 with SMTP id 9so5835696vws.13 for ; Mon, 03 Jan 2011 15:45:18 -0800 (PST) Received: by 10.220.184.66 with SMTP id cj2mr6093108vcb.140.1294098317962; Mon, 03 Jan 2011 15:45:17 -0800 (PST) Received: from [10.0.1.198] ([72.253.42.56]) by mx.google.com with ESMTPS id p8sm4371070vcr.42.2011.01.03.15.45.15 (version=SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 15:45:16 -0800 (PST) Date: Mon, 3 Jan 2011 13:47:57 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Poul-Henning Kamp In-Reply-To: <82826.1294088199@critter.freebsd.dk> Message-ID: References: <82826.1294088199@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 23:45:19 -0000 On Mon, 3 Jan 2011, Poul-Henning Kamp wrote: > In message , Jeff Roberson writes: > >> I have seen that some attempt at similar wrappers has been made elsewhere. >> I wonder if instead of making each one tailored to individual components, >> which mostly seem to be filesystems so far, should we put this in a >> central place under compat somewhere? > > My inflation devalued $0.02: > > We should face our NIH syndrome and for those differences between > Linux and FreeBSD KPI which are purely a naming or trivial argument > difference, try to reduce the differences. Unfortunately it would create quite a lot of code churn as there are relatively few that are minorly different. You can page through the wrapper code if you're interested. http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/ofed/include/linux/ > > Those where there are substantial differences, we should only have > one compat layer, not one for each driver. I would like this to be the case. So we can converge on something complete. There are of course big differences between minor linux kernel revisions and that poses problems. However those should be easier than the bsd/linux differences. I think my proposal is to move these files to a more generic location so they are more visible and available to other projects. Maintainers of individual kernel ports would have to decide if they want to use what is there. The other important question is are there really many other places that this would be useful? One example I can think of is network device drivers. If you look at the ipoib port, for example, it's basically linux code + mbufs. It does allow rapid porting if you don't mind having a weird hybrid result. The reason I did it for ipoib was to permit taking in bug fixes and changes from linux. Luigi also did something for usb which I did not bring in. I felt some of his wrapper code was GPL polluted. Thanks, Jeff > > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > From owner-freebsd-arch@FreeBSD.ORG Mon Jan 3 23:45:44 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 055E91065670 for ; Mon, 3 Jan 2011 23:45:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id ABD3D8FC16 for ; Mon, 3 Jan 2011 23:45:43 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id p03Ne8AU066645 for ; Mon, 3 Jan 2011 16:40:08 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4D225E56.2080603@bsdimp.com> Date: Mon, 03 Jan 2011 16:40:06 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <20110103210223.GV2973@elvis.mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 23:45:44 -0000 On 01/03/2011 16:34, Jeff Roberson wrote: > On Mon, 3 Jan 2011, Garrett Cooper wrote: > >> On Mon, Jan 3, 2011 at 1:02 PM, Alfred Perlstein >> wrote: >>> * Jeff Roberson [110103 12:51] wrote: >>>> Hello Folks, >>>> >>>> Some of you may have seen my infiniband work proceed in svn. It is >>>> coming >>>> to a close soon and I will be integrating it into current. I have >>>> a few >>>> patches to the kernel to send for review but I wanted to bring up >>>> the KPI >>>> wrapper itself for discussion. >>>> >>>> The infiniband port has been done by creating a 10,000 line KPI >>>> compatability layer. With this layer the vast majority of the >>>> driver code >>>> runs unmodified. The exceptions are anything that interfaces with >>>> skbs >>>> and most of the code that deals with network interfaces. >>>> >>>> Some examples of things supported by the wrapper: >>>> >>>> atomics, types, bitops, byte order conversion, character devices, pci >>>> devices, dma, non-device files, idr tables, interrupts, ioremap, >>>> hashes, >>>> kobjects, radix trees, lists, modules, notifier blocks, rbtrees, >>>> rwlock, >>>> rwsem, semaphore, schedule, spinlocks, kalloc, wait queues, >>>> workqueues, >>>> timers, etc. >>>> >>>> Obviously a complete wrapper is impossible and I only implemented the >>>> features that I needed. The build is accomplished by pointing the >>>> linux >>>> compatible code at sys/ofed/include/ which has a simulated linux >>>> kernel >>>> include tree. There are some config(8) changes to help this along as >>>> well. >>>> >>>> I have seen that some attempt at similar wrappers has been made >>>> elsewhere. >>>> I wonder if instead of making each one tailored to individual >>>> components, >>>> which mostly seem to be filesystems so far, should we put this in a >>>> central place under compat somewhere? Is this project doomed to be >>>> tied >>>> to a single consumer by the specific nature of it? >>>> >>>> Other comments or concerns? >>> >>> I think this is really cool. Brilliant actually. >>> >>> What do you think about proposing it on some standards list as a >>> cross unix KPI? That way we can see upcoming changes and maybe >>> have a say in pushing back on gratuitous changes that would break >>> our clients? >> >> That would be really nice, but I doubt people could agree on a >> single set of KPIs for everything and given the rate of progress with >> opengroup, I don't think it will fly (in particular with our and >> Linux's rate of development). Thankfully some of stuff (from what I've >> seen) is easy to port back and forth, but it varies depending on how >> tied the code is to the OS of course :(. > > Also, linux likes to change things very rapidly. Not to mention a lot > of their APIs go against the grain on BSD and we would not find them > aesthetically or architecturally pleasing. Yea, that's happened so often, one has to wonder if it is intentional on their part :) But, alas, I think phk's signature actually explains it. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 01:54:44 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACE14106564A for ; Tue, 4 Jan 2011 01:54:44 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 5182F8FC08 for ; Tue, 4 Jan 2011 01:54:43 +0000 (UTC) Received: from [172.16.135.102] (lportal.in1.lcl [172.16.1.9]) by ns1.feral.com (8.14.4/8.14.3) with ESMTP id p041LaiK000554 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 3 Jan 2011 17:21:37 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4D22761D.2020706@feral.com> Date: Mon, 03 Jan 2011 17:21:33 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <20110103210223.GV2973@elvis.mu.org> <4D225E56.2080603@bsdimp.com> In-Reply-To: <4D225E56.2080603@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Mon, 03 Jan 2011 17:21:37 -0800 (PST) Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 01:54:44 -0000 >> Also, linux likes to change things very rapidly. Not to mention a >> lot of their APIs go against the grain on BSD and we would not find >> them aesthetically or architecturally pleasing. > > Yea, that's happened so often, one has to wonder if it is intentional > on their part :) But, alas, I think phk's signature actually explains > it. > > You should read http://www.kernel.org/doc/Documentation/stable_api_nonsense.txt for a reasoning. It's also a misreading of both motive and capabilities to ascribe either malice or incompetence to the linux folks. On the title subject, having written several multiplatform drivers and been involved trying to write APIs and ABIs common to multiple platforms and OS' for the last 20 odd years or so, I have to say I have very mixed feelings about the approach Jeff has taken here. Syntactic differences between different OS functions are *generally* trivial. printf is printf. Semantic, and implied semantic differences can be tricky. The linux locking model is fundamentally different from the FreeBSD, and only conscious and careful programming in code that calls shim layer stuff can avoid problems (although maybe Jeff has been cleverer than I can be with this). Given the above, centralized KAPI services that multiple OS platforms can share seem a hard goal to reach. There was at least one (sponsored by SCO) which was a complete non-starter (despite the best of intentions). There have been several hardware based efforts that have also come a cropper (I20 and OBIOS). Even *within* a single OS community, variants abound that are irreconcilable (the multiple *BSDs; AT&T vs BSD; .....). And once you get outside the kernel, it's complete chaos (the multitude of Linux distros). I take from all of this that only select and relatively contained kernel subsystems are good candidates for multiple platform instantiations. Direct hardware drivers are generally pretty good for this since they can usually be written with shim type supports pretty easily. Filesystems are tricky. The attempts by SGI to maintain multiple platform versions of XFS have failed spectacularly. The GFS folks gave up on this one early. OFED is something of a special case. It's a very large body of code, written specifically for Linux, and is essentially the de facto standard for HPC interconnects. Like I said, I have mixed feelings about Jeff's approach here. On the one hand, that's a huge shim layer to write (10K LOC!). On the *other* hand, it makes importation of updated (Linux based) code quite workable. What that *does* imply is that native OFED development will unlikely ever be undertaken on FreeBSD (probably fine- whoza gonna pay for it that ain't paying for Linux development already?). The other thing to ask in making for common functionality is whether or not there are performance and/or functionality tradeoffs being made. There are things you can do in the FreeBSD kernel that you can't (easily) do in Linux (and vice versa). That's another consideration. Anyway, to end this meandering email, my suggestion would be "Yes, the 10K LOC would be useful for all modules to use!", but only expect it to work (well) for OFED. From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 02:03:33 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5AA5106564A for ; Tue, 4 Jan 2011 02:03:33 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f196.google.com (mail-wy0-f196.google.com [74.125.82.196]) by mx1.freebsd.org (Postfix) with ESMTP id 46E3A8FC08 for ; Tue, 4 Jan 2011 02:03:32 +0000 (UTC) Received: by wyb40 with SMTP id 40so5101252wyb.7 for ; Mon, 03 Jan 2011 18:03:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+B5NdDKf/o+dZWT+nethsmLp/tzw7Ird3Npd6HoaM7Q=; b=heolAUw7b3i3rgP+SB3wFMFM1aJc8QQIK5T1JPvaBAL+/Of3L9FrxltYYEhnVzPA0f oU/mWrc9SYkbCkNc3TyHKhTjlkedBheXqaDh+BmXpXeYdiyTxjAHpVVEgcIIRlEHaWu5 S19V4yci6vW3EZ2PWO3pRFdWt9beWPrPZckUs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=B375BpwFxvS+DAuLHpNjsXbDwjfnoBoTbhbT0xPX2WHtsdvvjiukUfkBAEFkGIdo2g J1G72MXovg2WHehoG100BcUWS1GfAsf1X4DKOWZQFGiItqzXWViIKklBv1ODb4nCHx1O e28JjkkWlxacQLj4Zx+XNMbp0tX7c7S6Tpqq8= MIME-Version: 1.0 Received: by 10.216.154.140 with SMTP id h12mr1401930wek.46.1294106610311; Mon, 03 Jan 2011 18:03:30 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.254.226 with HTTP; Mon, 3 Jan 2011 18:03:30 -0800 (PST) In-Reply-To: <4D22761D.2020706@feral.com> References: <20110103210223.GV2973@elvis.mu.org> <4D225E56.2080603@bsdimp.com> <4D22761D.2020706@feral.com> Date: Mon, 3 Jan 2011 18:03:30 -0800 X-Google-Sender-Auth: ZOEKe2kbiwulq3F6ConlGGhuZ2o Message-ID: From: Garrett Cooper To: Matthew Jacob Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 02:03:33 -0000 On Mon, Jan 3, 2011 at 5:21 PM, Matthew Jacob wrote: > >>> Also, linux likes to change things very rapidly. =A0Not to mention a lo= t of >>> their APIs go against the grain on BSD and we would not find them >>> aesthetically or architecturally pleasing. >> >> Yea, that's happened so often, one has to wonder if it is intentional on >> their part :) =A0But, alas, I think phk's signature actually explains it= . >> >> > > You should read > http://www.kernel.org/doc/Documentation/stable_api_nonsense.txt for a > reasoning. It's also a misreading of both motive and capabilities to ascr= ibe > either malice or incompetence to the linux folks. > > On the title subject, having written several multiplatform drivers and be= en > involved trying to write APIs and ABIs common to multiple platforms and O= S' > for the last 20 odd years or so, I have to say I have very mixed feelings > about the approach Jeff has taken here. > > Syntactic differences between different OS functions are *generally* > trivial. =A0printf is printf. > > Semantic, and implied semantic differences can be tricky. The linux locki= ng > model is fundamentally different from the FreeBSD, and only conscious and > careful programming in code that calls shim layer stuff can avoid problem= s > (although maybe Jeff has been cleverer than I can be with this). > > Given the above, centralized KAPI services that multiple OS platforms can > share seem a hard goal to reach. There was at least one (sponsored by SCO= ) > which was a complete non-starter (despite the best of intentions). There > have been several hardware based efforts that have also come a cropper (I= 20 > and OBIOS). > > Even *within* a single OS community, variants abound that are irreconcila= ble > (the multiple *BSDs; AT&T vs BSD; .....). And once you get outside the > kernel, it's complete chaos (the multitude of Linux distros). > > I take from all of this that only select and relatively contained kernel > subsystems are good candidates for multiple platform instantiations. Dire= ct > hardware drivers are generally pretty good for this since they can usuall= y > be written with shim type supports pretty easily. > > Filesystems are tricky. The attempts by SGI to maintain multiple platform > versions of XFS have failed spectacularly. The GFS folks gave up on this = one > early. > > OFED is something of a special case. It's a very large body of code, writ= ten > specifically for Linux, and is essentially the de facto standard for HPC > interconnects. Like I said, I have mixed feelings about Jeff's approach > here. > > On the one hand, that's a huge shim layer to write (10K LOC!). > > On the *other* hand, it makes importation of updated (Linux based) code > quite workable. What that *does* imply is that native OFED development wi= ll > unlikely ever be undertaken on FreeBSD (probably fine- whoza gonna pay fo= r > it that ain't paying for Linux development already?). > > The other thing to ask in making for common functionality is whether or n= ot > there are performance and/or functionality tradeoffs being made. There ar= e > things you can do in the FreeBSD kernel that you can't (easily) do in Lin= ux > (and vice versa). That's another consideration. > > Anyway, to end this meandering email, my suggestion would be "Yes, the 10= K > LOC would be useful for all modules to use!", but only expect it to work > (well) for OFED. Too bad they didn't see the value in standardizing the technology as a standard (apart from opengroup) like IPMI was standardized by Dell, HP, Intel, etc. That would have been nice (drop the compatibility layer all together)... Oh well... BTW Jeff -- have you run this stuff through LTP yet :) (check with ale for more details or me if you want since I'm the "lucky" primary committer right now)? There isn't much in terms of driver compatibility testing available, but there are a ton of functional testcases that can be run through linux compat that could be leveraged. HTH, -Garrett From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 03:21:37 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 245A1106564A for ; Tue, 4 Jan 2011 03:21:37 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id D9FDF8FC1C for ; Tue, 4 Jan 2011 03:21:36 +0000 (UTC) Received: by qyk8 with SMTP id 8so14123420qyk.13 for ; Mon, 03 Jan 2011 19:21:36 -0800 (PST) Received: by 10.224.2.77 with SMTP id 13mr1725088qai.155.1294109546907; Mon, 03 Jan 2011 18:52:26 -0800 (PST) Received: from [10.0.1.198] ([72.253.42.56]) by mx.google.com with ESMTPS id g32sm12473747qck.34.2011.01.03.18.52.24 (version=SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 18:52:25 -0800 (PST) Date: Mon, 3 Jan 2011 16:55:06 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Matthew Jacob In-Reply-To: <4D22761D.2020706@feral.com> Message-ID: References: <20110103210223.GV2973@elvis.mu.org> <4D225E56.2080603@bsdimp.com> <4D22761D.2020706@feral.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 03:21:37 -0000 On Mon, 3 Jan 2011, Matthew Jacob wrote: > >>> Also, linux likes to change things very rapidly. Not to mention a lot of >>> their APIs go against the grain on BSD and we would not find them >>> aesthetically or architecturally pleasing. >> >> Yea, that's happened so often, one has to wonder if it is intentional on >> their part :) But, alas, I think phk's signature actually explains it. >> >> > > You should read > http://www.kernel.org/doc/Documentation/stable_api_nonsense.txt for a > reasoning. It's also a misreading of both motive and capabilities to ascribe > either malice or incompetence to the linux folks. > I would agree to this. It's more an issue of different priorities. We tend to have more layering, contained APIs, and long-term stability. They tend to favor performance above all else. > On the title subject, having written several multiplatform drivers and been > involved trying to write APIs and ABIs common to multiple platforms and OS' > for the last 20 odd years or so, I have to say I have very mixed feelings > about the approach Jeff has taken here. > > Syntactic differences between different OS functions are *generally* trivial. > printf is printf. > > Semantic, and implied semantic differences can be tricky. The linux locking > model is fundamentally different from the FreeBSD, and only conscious and > careful programming in code that calls shim layer stuff can avoid problems > (although maybe Jeff has been cleverer than I can be with this). The locking was relatively straightforward. And in fact our kernel looks like a preemptable real-time linux kernel. In that case they do the very same transformations that I have done. Spinlocks become mutexes, there are no real spinlocks, and semaphores, etc. are implemented with sx. In other cases I had to be very careful to preserve the semantics and contexts of execution which at times required the implementation of new BSD functionality. Indeed any way you crack the nut care and attention to detail are required. > > Given the above, centralized KAPI services that multiple OS platforms can > share seem a hard goal to reach. There was at least one (sponsored by SCO) > which was a complete non-starter (despite the best of intentions). There have > been several hardware based efforts that have also come a cropper (I20 and > OBIOS). I agree with this. > > Even *within* a single OS community, variants abound that are irreconcilable > (the multiple *BSDs; AT&T vs BSD; .....). And once you get outside the > kernel, it's complete chaos (the multitude of Linux distros). > > I take from all of this that only select and relatively contained kernel > subsystems are good candidates for multiple platform instantiations. Direct > hardware drivers are generally pretty good for this since they can usually be > written with shim type supports pretty easily. > > Filesystems are tricky. The attempts by SGI to maintain multiple platform > versions of XFS have failed spectacularly. The GFS folks gave up on this one > early. Yes, you'll notice I only did minimal compatibility with network interfaces and none with mbufs. At some points the wrapper is not worthwhile. For Infiniband SDP (sockets) and IPOIB were a more direct porting since they touched layers that were too big to translate. > > OFED is something of a special case. It's a very large body of code, written > specifically for Linux, and is essentially the de facto standard for HPC > interconnects. Like I said, I have mixed feelings about Jeff's approach here. > > On the one hand, that's a huge shim layer to write (10K LOC!). > > On the *other* hand, it makes importation of updated (Linux based) code quite > workable. What that *does* imply is that native OFED development will > unlikely ever be undertaken on FreeBSD (probably fine- whoza gonna pay for it > that ain't paying for Linux development already?). Please consider that we have imported nearly 700,000 lines of code as part of the OFED distribution. Actually writing the shim layer took less time than it would to hand port all of that and in almost all cases the only gain would be incompatability with updates as most differences are actually quite trivial. Just yesterday I updated our sources with 9 months of changes from the ofed git repository. It took about an hour to resolve the diffs and update the wrapper with a few missing features. It took probably 4 hours for all of the svn operations to complete. The original OFED porting effort I did with John Polstra and the people at Isilon was never updated to my knowledge. It was more mechanical changes and 'felt' more like FreeBSD but fell so far out of date as to be useless. Interestingly there was originally a porting layer in the ofed stack back as it originally compiled on many operating systems. However the opensource effort focused on linux and the linux people wouldn't take it without the shims removed. > > The other thing to ask in making for common functionality is whether or not > there are performance and/or functionality tradeoffs being made. There are > things you can do in the FreeBSD kernel that you can't (easily) do in Linux > (and vice versa). That's another consideration. > > Anyway, to end this meandering email, my suggestion would be "Yes, the 10K > LOC would be useful for all modules to use!", but only expect it to work > (well) for OFED. The two parts of OFED which required hand porting ended up requiring less of it and being more compatible with the Linux code as a result of leaving things which didn't matter using the wrapper. It's not an all or none approach. Of course that isn't aesthetically pleasing but functionally it's very useful. Thanks, Jeff > > _______________________________________________ > 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 Tue Jan 4 03:29:41 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF6D01065670 for ; Tue, 4 Jan 2011 03:29:40 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8E6D28FC15 for ; Tue, 4 Jan 2011 03:29:40 +0000 (UTC) Received: by vws9 with SMTP id 9so5906410vws.13 for ; Mon, 03 Jan 2011 19:29:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=8R22jhzI7YShV8y04ps8PSjfVCFuluMgrg4A2/Dz+Lc=; b=b70vfRucAINz19CzESPYVcli2Z4ymktlqWEgZFdG6715AFL+Pmb902AtqWZjy7U1vu 0n69mCCBDXruhwU2t5WlmT1e1qXXvWNV3Zpz+9nFLYfNAYptMl+dc9hKEP1XHeioyqGE BYZS5NsvMu2giuBQGgW97WmvfHbTiDbt1ry8M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=YqWJBioLTW9FzjIfaLxVJYqJWMBsQ34B7iyvEYIJ7dAP4xu6UUJqYiCtyOmURCHxsj kUT9S5leDGx60x2E7/ZDsK+WiXhn23dGUdYpRrgFnisGmS0uqzDVwUCIniZsyPyuZpvG dkjYw8uldjWS4sniz3GdEVwYtpG4vHXi05OG0= Received: by 10.220.178.65 with SMTP id bl1mr3851348vcb.112.1294110121775; Mon, 03 Jan 2011 19:02:01 -0800 (PST) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id c15sm4417053vcs.7.2011.01.03.19.01.59 (version=SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 19:02:00 -0800 (PST) Date: Mon, 3 Jan 2011 22:01:53 -0500 From: Alexander Kabaev To: Jeff Roberson Message-ID: <20110103220153.69cf59e0@kan.dnsalias.net> In-Reply-To: References: X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/4KhrGAVoBU+Vq5xlvI9K._V"; protocol="application/pgp-signature" Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 03:29:41 -0000 --Sig_/4KhrGAVoBU+Vq5xlvI9K._V Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 3 Jan 2011 10:31:24 -1000 (HST) Jeff Roberson wrote: > Hello Folks, >=20 > Some of you may have seen my infiniband work proceed in svn. It is > coming to a close soon and I will be integrating it into current. I > have a few patches to the kernel to send for review but I wanted to > bring up the KPI wrapper itself for discussion. >=20 > The infiniband port has been done by creating a 10,000 line KPI=20 > compatability layer. With this layer the vast majority of the driver > code runs unmodified. The exceptions are anything that interfaces > with skbs and most of the code that deals with network interfaces. >=20 > Some examples of things supported by the wrapper: >=20 > atomics, types, bitops, byte order conversion, character devices, pci=20 > devices, dma, non-device files, idr tables, interrupts, ioremap, > hashes, kobjects, radix trees, lists, modules, notifier blocks, > rbtrees, rwlock, rwsem, semaphore, schedule, spinlocks, kalloc, wait > queues, workqueues, timers, etc. >=20 > Obviously a complete wrapper is impossible and I only implemented the=20 > features that I needed. The build is accomplished by pointing the > linux compatible code at sys/ofed/include/ which has a simulated > linux kernel include tree. There are some config(8) changes to help > this along as well. >=20 > I have seen that some attempt at similar wrappers has been made > elsewhere. I wonder if instead of making each one tailored to > individual components, which mostly seem to be filesystems so far, > should we put this in a central place under compat somewhere? Is > this project doomed to be tied to a single consumer by the specific > nature of it? >=20 > Other comments or concerns? >=20 > Thanks, > Jeff This probably will go against popular opinion here, but having 10k linux emulation layer that _almost_ work in the tree will be an unfortunate event and will do more damage to FreeBSD as a platform than good in the long run. I would rather see this code never hit main repository.=20 --=20 Alexander Kabaev --Sig_/4KhrGAVoBU+Vq5xlvI9K._V Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iD8DBQFNIo2mQ6z1jMm+XZYRAs4GAJ4q/7LNwfJ6QzSFArE6caC3rlniAgCg1w3H nfyav3zCcGw3RgeK8Bls8kM= =aeYH -----END PGP SIGNATURE----- --Sig_/4KhrGAVoBU+Vq5xlvI9K._V-- From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 03:34:39 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4BD1106566B for ; Tue, 4 Jan 2011 03:34:39 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6AAB38FC08 for ; Tue, 4 Jan 2011 03:34:39 +0000 (UTC) Received: by iwn39 with SMTP id 39so14225525iwn.13 for ; Mon, 03 Jan 2011 19:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=0gLGfjJK0njppuSW6AmP2i46GF8KfOt1VtSmAZ/tH5Y=; b=KxkXVRADu+e4ttc5GSrmmGYMiaDUfBv/fLh5iC6lqFqg3rt1muwLvICR3MAg4rHqCy FYVZLYtqvNBKoGceczTIxDzhy9Ab4uJO51hwXQT+spNT+XZll6ozqFWnTITvdGzHcwVg 2Y6eVjaj2pTBTi23arebQEKdywHaqQFQ+cAY0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=jTEPdA5OriJUH8QrE5CQMY0vSlrLezjoB2H72iebdVJmcsGnEuFcIxYuKHRoJPtIlr sNKQD4heL5MDVtgkfh5FJ7QES3RVT9oyTDxTexevgqQZ/iQl4BFHagm760SvB55qDphS nKLYGAnwzsv57oxtTIg3gwpk+cVKFeFChuVKQ= MIME-Version: 1.0 Received: by 10.231.37.129 with SMTP id x1mr5165703ibd.1.1294112078771; Mon, 03 Jan 2011 19:34:38 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.231.172.69 with HTTP; Mon, 3 Jan 2011 19:34:38 -0800 (PST) In-Reply-To: <20110103220153.69cf59e0@kan.dnsalias.net> References: <20110103220153.69cf59e0@kan.dnsalias.net> Date: Mon, 3 Jan 2011 19:34:38 -0800 X-Google-Sender-Auth: FIXk8oMVtCIANg9XrZD28lHiVYc Message-ID: From: mdf@FreeBSD.org To: Alexander Kabaev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 03:34:39 -0000 On Mon, Jan 3, 2011 at 7:01 PM, Alexander Kabaev wrote: > On Mon, 3 Jan 2011 10:31:24 -1000 (HST) > Jeff Roberson wrote: >> >> The infiniband port has been done by creating a 10,000 line KPI >> compatability layer. =A0With this layer the vast majority of the driver >> code runs unmodified. =A0The exceptions are anything that interfaces >> with skbs and most of the code that deals with network interfaces. > > This probably will go against popular opinion here, but having 10k > linux emulation layer that _almost_ work in the tree will be an > unfortunate event and will do more damage to FreeBSD as a platform than > good in the long run. I would rather see this code never hit main > repository. I don't agree or disagree with this opinion yet, but I would like some detail on why you think it would be unfortunate and do damage to FreeBSD. That's a pretty loaded statement and I believe it deserves fleshing out. Specifically, I can't tell if you're saying that the problem is that the layer almost works (for some value of almost...) and if it would be okay if the layer "worked" (for some value of works). Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 03:39:05 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1408A106564A for ; Tue, 4 Jan 2011 03:39:05 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9C81E8FC13 for ; Tue, 4 Jan 2011 03:39:04 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.4/8.14.4) with ESMTP id p043d3HK081917; Mon, 3 Jan 2011 22:39:03 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.4/8.14.4/Submit) id p043d3uw081916; Mon, 3 Jan 2011 22:39:03 -0500 (EST) (envelope-from wollman) Date: Mon, 3 Jan 2011 22:39:03 -0500 (EST) From: Garrett Wollman Message-Id: <201101040339.p043d3uw081916@hergotha.csail.mit.edu> To: jroberson@jroberson.net X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: <20110104032143$6d5e@grapevine.csail.mit.edu> References: <20110103210223.GV2973@elvis.mu.org> <4D225E56.2080603@bsdimp.com> <4D22761D.2020706@feral.com> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (hergotha.csail.mit.edu [127.0.0.1]); Mon, 03 Jan 2011 22:39:03 -0500 (EST) X-Spam-Status: No, score=-0.6 required=5.0 tests=ALL_TRUSTED,LOTS_OF_MONEY, TO_NO_BRKTS_PCNT autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on hergotha.csail.mit.edu Cc: , arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 03:39:05 -0000 In article <20110104032143$6d5e@grapevine.csail.mit.edu>, Jeff Roberson writes: >The original OFED porting effort I did with John Polstra and the people at >Isilon was never updated to my knowledge. It was more mechanical changes >and 'felt' more like FreeBSD but fell so far out of date as to be useless. >Interestingly there was originally a porting layer in the ofed stack back >as it originally compiled on many operating systems. However the >opensource effort focused on linux and the linux people wouldn't take it >without the shims removed. And that, I am absolutely, 100% willing to ascribe to malice on the Linux kernel developers' part. (And there's more than one example like this, not all of them as easily resolved,[1] due to issues with licensing and ownership of original-vendor-abandoned code.) Fundamentally, maintaining any sort of Linux compatibility is a losing battle, since the hordes will keep on rototilling interfaces in every release until the cows come home, with no concern (and in many cases utter contempt) for anyone else who might need to maintain kernel code. It's a testament to their size and ability that they have managed to keep the system relatively usable and stable over the long term when major parts of the system get replaced on such a regular basis. -GAWollman [1] If you can call "removing support for other operating systems" "resolving". From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 04:15:14 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32B7C106564A for ; Tue, 4 Jan 2011 04:15:14 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f196.google.com (mail-wy0-f196.google.com [74.125.82.196]) by mx1.freebsd.org (Postfix) with ESMTP id B641B8FC16 for ; Tue, 4 Jan 2011 04:15:13 +0000 (UTC) Received: by wyb40 with SMTP id 40so5120822wyb.7 for ; Mon, 03 Jan 2011 20:15:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=vdPn6EmYlC+depSCh2aguCS0FzLXwj11P4z1vrBcjWg=; b=D5VIpU6Ij++tlgjIq0BTawTs4hM/LHWJQXkjoI2MvgdLPfV836Ro8qfz2d++WIYN+e JOvptmuur759ECmfPJVlRLb445NK1M0ybwa5B9Kg2mv/dT7UDyhiwCY/D1jxjjMZlR7F GCgNhQ6jziAfpjL0urf0CBuKrNwZXldhm5KKM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Oja2LhPtW+Ww9j3NYhU8LL++4BAd3a1kxjsZQxtIHKXueEqXNMsbZ0yav3Ciqx6rhz DRCi8R/Z5IYX+YDRUnFJEXf9UdxZ0GqIQBwDh/cWrlRaAq0STMzvgCyBOi231sI6SSzk J8TwohkzqEiecQDNFEJ+WpCyb+GHzjL87yW2Y= MIME-Version: 1.0 Received: by 10.216.141.37 with SMTP id f37mr6810088wej.31.1294114512617; Mon, 03 Jan 2011 20:15:12 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.254.226 with HTTP; Mon, 3 Jan 2011 20:15:12 -0800 (PST) In-Reply-To: <201101040339.p043d3uw081916@hergotha.csail.mit.edu> References: <20110103210223.GV2973@elvis.mu.org> <4D225E56.2080603@bsdimp.com> <4D22761D.2020706@feral.com> <20110104032143$6d5e@grapevine.csail.mit.edu> <201101040339.p043d3uw081916@hergotha.csail.mit.edu> Date: Mon, 3 Jan 2011 20:15:12 -0800 X-Google-Sender-Auth: MwQlj6NE_U4Ccg-TaO_u2qNu0J8 Message-ID: From: Garrett Cooper To: Garrett Wollman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 04:15:14 -0000 On Mon, Jan 3, 2011 at 7:39 PM, Garrett Wollman wrote: > In article <20110104032143$6d5e@grapevine.csail.mit.edu>, Jeff > Roberson writes: > >>The original OFED porting effort I did with John Polstra and the people a= t >>Isilon was never updated to my knowledge. =A0It was more mechanical chang= es >>and 'felt' more like FreeBSD but fell so far out of date as to be useless= . >>Interestingly there was originally a porting layer in the ofed stack back >>as it originally compiled on many operating systems. =A0However the >>opensource effort focused on linux and the linux people wouldn't take it >>without the shims removed. > > And that, I am absolutely, 100% willing to ascribe to malice on the > Linux kernel developers' part. =A0(And there's more than one example > like this, not all of them as easily resolved,[1] due to issues with > licensing and ownership of original-vendor-abandoned code.) > > Fundamentally, maintaining any sort of Linux compatibility is a losing > battle, since the hordes will keep on rototilling interfaces in every > release until the cows come home, with no concern (and in many cases > utter contempt) for anyone else who might need to maintain kernel > code. =A0It's a testament to their size and ability that they have > managed to keep the system relatively usable and stable over the long > term when major parts of the system get replaced on such a regular > basis. Yeah... but rototilling cow crap on a regular basis still doesn't make one a proper farmer :(... bugs occur everywhere of course, but the complete lack of disregard or interest for testing (even in LTP) seems to just scream maintenance nightmare longterm. Oh well, I've given up harping on Linux devs because they don't seem to want to listen, and I look forward to the day that my committership in that project is done. I guess big companies that depend on Linux have expendable resources to toss at projects then; would be nice if we had those resources *grin*. `Fixing' issues using brute force isn't smart and it's not scalable, as I'm sure more folks on here are aware than I am. Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 04:56:13 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01B06106564A; Tue, 4 Jan 2011 04:56:13 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id A06D98FC0C; Tue, 4 Jan 2011 04:56:12 +0000 (UTC) Received: by yxh35 with SMTP id 35so5975545yxh.13 for ; Mon, 03 Jan 2011 20:56:11 -0800 (PST) Received: by 10.150.216.5 with SMTP id o5mr1144075ybg.181.1294116971468; Mon, 03 Jan 2011 20:56:11 -0800 (PST) Received: from [10.0.1.198] ([72.253.42.56]) by mx.google.com with ESMTPS id 8sm3501441yhl.44.2011.01.03.20.56.08 (version=SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 20:56:10 -0800 (PST) Date: Mon, 3 Jan 2011 18:58:51 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Garrett Cooper In-Reply-To: Message-ID: References: <20110103210223.GV2973@elvis.mu.org> <4D225E56.2080603@bsdimp.com> <4D22761D.2020706@feral.com> <20110104032143$6d5e@grapevine.csail.mit.edu> <201101040339.p043d3uw081916@hergotha.csail.mit.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2547152148-1407749382-1294117135=:1450" Cc: arch@freebsd.org, Garrett Wollman Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 04:56:13 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2547152148-1407749382-1294117135=:1450 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 3 Jan 2011, Garrett Cooper wrote: > On Mon, Jan 3, 2011 at 7:39 PM, Garrett Wollman > wrote: >> In article <20110104032143$6d5e@grapevine.csail.mit.edu>, Jeff >> Roberson writes: >> >>> The original OFED porting effort I did with John Polstra and the people at >>> Isilon was never updated to my knowledge.  It was more mechanical changes >>> and 'felt' more like FreeBSD but fell so far out of date as to be useless. >>> Interestingly there was originally a porting layer in the ofed stack back >>> as it originally compiled on many operating systems.  However the >>> opensource effort focused on linux and the linux people wouldn't take it >>> without the shims removed. >> >> And that, I am absolutely, 100% willing to ascribe to malice on the >> Linux kernel developers' part.  (And there's more than one example >> like this, not all of them as easily resolved,[1] due to issues with >> licensing and ownership of original-vendor-abandoned code.) >> >> Fundamentally, maintaining any sort of Linux compatibility is a losing >> battle, since the hordes will keep on rototilling interfaces in every >> release until the cows come home, with no concern (and in many cases >> utter contempt) for anyone else who might need to maintain kernel >> code.  It's a testament to their size and ability that they have >> managed to keep the system relatively usable and stable over the long >> term when major parts of the system get replaced on such a regular >> basis. > > Yeah... but rototilling cow crap on a regular basis still doesn't make > one a proper farmer :(... bugs occur everywhere of course, but the > complete lack of disregard or interest for testing (even in LTP) seems > to just scream maintenance nightmare longterm. Oh well, I've given up > harping on Linux devs because they don't seem to want to listen, and I > look forward to the day that my committership in that project is done. > > I guess big companies that depend on Linux have expendable resources > to toss at projects then; would be nice if we had those resources > *grin*. `Fixing' issues using brute force isn't smart and it's not > scalable, as I'm sure more folks on here are aware than I am. Hey guys. I appreciate this discussion and I think it's valuable in another context but let's try to keep the linux derision out of the mailing archives for our architectural discussion group. Thanks, Jeff > > Thanks, > -Garrett > --2547152148-1407749382-1294117135=:1450-- From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 05:00:23 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1091E106564A for ; Tue, 4 Jan 2011 05:00:23 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id C7CE78FC12 for ; Tue, 4 Jan 2011 05:00:22 +0000 (UTC) Received: by gwj21 with SMTP id 21so6864070gwj.13 for ; Mon, 03 Jan 2011 21:00:22 -0800 (PST) Received: by 10.236.105.161 with SMTP id k21mr1787681yhg.87.1294117221977; Mon, 03 Jan 2011 21:00:21 -0800 (PST) Received: from [10.0.1.198] ([72.253.42.56]) by mx.google.com with ESMTPS id 55sm12833413yhl.37.2011.01.03.21.00.18 (version=SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 21:00:20 -0800 (PST) Date: Mon, 3 Jan 2011 19:03:01 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Alexander Kabaev In-Reply-To: <20110103220153.69cf59e0@kan.dnsalias.net> Message-ID: References: <20110103220153.69cf59e0@kan.dnsalias.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 05:00:23 -0000 On Mon, 3 Jan 2011, Alexander Kabaev wrote: > On Mon, 3 Jan 2011 10:31:24 -1000 (HST) > Jeff Roberson wrote: > >> Hello Folks, >> >> Some of you may have seen my infiniband work proceed in svn. It is >> coming to a close soon and I will be integrating it into current. I >> have a few patches to the kernel to send for review but I wanted to >> bring up the KPI wrapper itself for discussion. >> >> The infiniband port has been done by creating a 10,000 line KPI >> compatability layer. With this layer the vast majority of the driver >> code runs unmodified. The exceptions are anything that interfaces >> with skbs and most of the code that deals with network interfaces. >> >> Some examples of things supported by the wrapper: >> >> atomics, types, bitops, byte order conversion, character devices, pci >> devices, dma, non-device files, idr tables, interrupts, ioremap, >> hashes, kobjects, radix trees, lists, modules, notifier blocks, >> rbtrees, rwlock, rwsem, semaphore, schedule, spinlocks, kalloc, wait >> queues, workqueues, timers, etc. >> >> Obviously a complete wrapper is impossible and I only implemented the >> features that I needed. The build is accomplished by pointing the >> linux compatible code at sys/ofed/include/ which has a simulated >> linux kernel include tree. There are some config(8) changes to help >> this along as well. >> >> I have seen that some attempt at similar wrappers has been made >> elsewhere. I wonder if instead of making each one tailored to >> individual components, which mostly seem to be filesystems so far, >> should we put this in a central place under compat somewhere? Is >> this project doomed to be tied to a single consumer by the specific >> nature of it? >> >> Other comments or concerns? >> >> Thanks, >> Jeff > > > This probably will go against popular opinion here, but having 10k > linux emulation layer that _almost_ work in the tree will be an > unfortunate event and will do more damage to FreeBSD as a platform than > good in the long run. I would rather see this code never hit main > repository. I would argue that the layer works very well for infiniband. Much better than almost. It is only almost complete in that there is no need for me to implement features that we're not using. I am interested in hearing your other concerns however. Thanks, Jeff > > -- > Alexander Kabaev > From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 05:01:37 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDEF3106566B for ; Tue, 4 Jan 2011 05:01:37 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8AE978FC14 for ; Tue, 4 Jan 2011 05:01:37 +0000 (UTC) Received: from [192.168.1.100] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.4/8.14.3) with ESMTP id p0451aAI001441 for ; Mon, 3 Jan 2011 21:01:36 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4D22A9B5.7080402@feral.com> Date: Mon, 03 Jan 2011 21:01:41 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <20110103220153.69cf59e0@kan.dnsalias.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.67.166.1]); Mon, 03 Jan 2011 21:01:36 -0800 (PST) Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 05:01:37 -0000 On 1/3/2011 7:34 PM, mdf@freebsd.org wrote: > On Mon, Jan 3, 2011 at 7:01 PM, Alexander Kabaev wrote: > ... > I don't agree or disagree with this opinion yet, but I would like some > detail on why you think it would be unfortunate and do damage to > FreeBSD. That's a pretty loaded statement and I believe it deserves > fleshing out. > Yes, I'd like to hear more about this too. From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 08:14:29 2011 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B788A1065696; Tue, 4 Jan 2011 08:14:29 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 171558FC13; Tue, 4 Jan 2011 08:14:29 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id B5C7D3F5BC; Tue, 4 Jan 2011 08:14:27 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id p048ERa2085272; Tue, 4 Jan 2011 08:14:27 GMT (envelope-from phk@critter.freebsd.dk) To: Jeff Roberson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 03 Jan 2011 13:34:30 -1000." Date: Tue, 04 Jan 2011 08:14:27 +0000 Message-ID: <85271.1294128867@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@FreeBSD.org, Alfred Perlstein , Garrett Cooper Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 08:14:29 -0000 In message , Jeff Roberson writes: >Also, linux likes to change things very rapidly. Not to mention a lot of >their APIs go against the grain on BSD and we would not find them >aesthetically or architecturally pleasing. Absolutely. But we, as a project, must also weigh the cost of our sensibilities and preferences, against how much work we must expend to uphold them. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 08:16:23 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08BCA106566B; Tue, 4 Jan 2011 08:16:23 +0000 (UTC) (envelope-from coco@executive-computing.de) Received: from mail.moehre.org (mail.moehre.org [195.96.35.7]) by mx1.freebsd.org (Postfix) with ESMTP id 92FC48FC1C; Tue, 4 Jan 2011 08:16:22 +0000 (UTC) Received: from mail.moehre.org (unknown [195.96.35.7]) by mail.moehre.org (Postfix) with ESMTP id 650868B143B; Tue, 4 Jan 2011 08:58:28 +0100 (CET) X-Spam-Flag: NO X-Spam-Score: -100.965 X-Spam-Level: X-Spam-Status: No, score=-100.965 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, AWL=0.035, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mail.moehre.org ([195.96.35.7]) by mail.moehre.org (mail.moehre.org [195.96.35.7]) (amavisd-new, port 10024) with ESMTP id 1-QMSzR7uf0m; Tue, 4 Jan 2011 08:58:26 +0100 (CET) Received: from [192.168.100.30] (p54B0DD94.dip.t-dialin.net [84.176.221.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: coco@executive-computing.de) by mail.moehre.org (Postfix) with ESMTPSA id 4EC188B141B; Tue, 4 Jan 2011 08:58:26 +0100 (CET) Message-ID: <4D22D30A.2050606@executive-computing.de> Date: Tue, 04 Jan 2011 08:58:02 +0100 From: Marco Steinbach User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: John Hixson References: <4D20C8BF.701@freebsd.org> <29AA82C4-6301-4DCD-BC9D-423AD162998E@gmail.com> <4D20DDE4.8080306@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , Bruce Cran , Nathan Whitehorn , freebsd-arch@freebsd.org, matt@ixsystems.com, freebsd-sysinstall@freebsd.org Subject: Re: BSDInstall: I want the bikeshed painted plaid X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 08:16:23 -0000 John Hixson wrote on 02.01.2011 22:51: > On Sun, Jan 2, 2011 at 12:19 PM, Nathan Whitehorn wrote: > >> I spent a bunch of time looking at pc-sysinstall before starting to work on >> this. The major problem for non-x86 systems is that it heavily assumes that >> your disks are either MBR+bsdlabel or GPT. If you have anything different >> (APM, VTOC8, or even a raw bsdlabel or MBR installation on x86), it breaks >> in strange and fascinating ways due to a random mixture of if (scheme == >> MBR) else and if (scheme == GPT) else in the backend. Some of these are >> easily fixed, but it looked quite difficult to root out all of the places >> this assumption is made, not to mention teaching it about various styles of >> boot code, that the same partitioning scheme may need to be set up different >> ways on different architectures, etc. txt-sysinstall also segfaults when you >> try to run it on powerpc at the moment, though that is likely a simple bug >> and I didn't look into it in detail. >> >> What I intended with bsdinstall is to have something simple, flexible, and >> easily maintained that works immediately on all platforms and will be ready >> for 9.0 for sure. If pc-sysinstall materializes before then, or after then, >> and people like it better, I'm more than happy to get out of the way; this >> is the reason the wiki page is titled "Stopgap Installer". In the interim, I >> hoped to at least start laying out the hammer and nails next to sysinstall's >> coffin. >> -Nathan >> >> > I would be more than happy to help out with making pc-sysinstall work on > non-x86 systems, however I don't have access to any. Do any of you have > hardware that could possibly be used by interested parties? I'm sure all the > work that's gone into bsdinstall could be used in pc-sysinstall or vice > versa. I have PowerMacs (G3/G4) and Netras/Ultras (T1 105, U10, U5) at my discretion. I've never installed FreeBSD on any of them, but would be willing to give it a shot. I can provide serial console access to the Sparcs, but the PowerMacs supposedly need "hands on", which I can also provide. If there's interest, I humbly suggest discussing further details on the course of action at sysinstall@, to which I just subscribed. MfG CoCo From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 13:23:02 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAC9D106566C for ; Tue, 4 Jan 2011 13:23:02 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 648A88FC18 for ; Tue, 4 Jan 2011 13:23:02 +0000 (UTC) Received: by qwj9 with SMTP id 9so13953832qwj.13 for ; Tue, 04 Jan 2011 05:23:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=yD97Cs34Bm4fgPu+U55A2bw/O0XAKoLymJY91fL+Z90=; b=F4HWzalyy8Dr0PVbJFROVdEfUtprlMgx0vW01b5u7CGlr1dnZLK328QRSe9ruuQ44G ll7kJmPYJf0sp+p9/y5zLR0/5C8o0zDJnA/LHnUFK6ytKIlXtoVxMDFTTczVa5DYVLG7 h7ngYYfoFUM/q9j8WC81zbVrvkbJBhGmNgtNc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=swrwjfcI8rTtLv93sk2rhu751wBmWNaXHBc8rOQ78WBDK2qrBCx4lQzA0VsjkXP4bU FPfDuPAt+kS2TxDjXswa7YUGrhWJLRerwvascSgwoq2Za8SYwNIgN93CMFKt3BUb0agv qcAOJpCAJr74c0ZHl6TlyAA5Xlgq2j1BTD+44= Received: by 10.229.84.137 with SMTP id j9mr19114028qcl.214.1294147380834; Tue, 04 Jan 2011 05:23:00 -0800 (PST) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id t7sm11614852qcs.40.2011.01.04.05.22.58 (version=SSLv3 cipher=RC4-MD5); Tue, 04 Jan 2011 05:22:58 -0800 (PST) Date: Tue, 4 Jan 2011 08:22:52 -0500 From: Alexander Kabaev To: Jeff Roberson Message-ID: <20110104082252.45bb5e7f@kan.dnsalias.net> In-Reply-To: References: <20110103220153.69cf59e0@kan.dnsalias.net> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/InHXaOUp4rOrZf6bSMUJWl1"; protocol="application/pgp-signature" Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 13:23:02 -0000 --Sig_/InHXaOUp4rOrZf6bSMUJWl1 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 3 Jan 2011 19:03:01 -1000 (HST) Jeff Roberson wrote: > On Mon, 3 Jan 2011, Alexander Kabaev wrote: >=20 > > On Mon, 3 Jan 2011 10:31:24 -1000 (HST) > > Jeff Roberson wrote: > > > >> Hello Folks, > >> > >> Some of you may have seen my infiniband work proceed in svn. It is > >> coming to a close soon and I will be integrating it into current. > >> I have a few patches to the kernel to send for review but I wanted > >> to bring up the KPI wrapper itself for discussion. > >> > >> The infiniband port has been done by creating a 10,000 line KPI > >> compatability layer. With this layer the vast majority of the > >> driver code runs unmodified. The exceptions are anything that > >> interfaces with skbs and most of the code that deals with network > >> interfaces. > >> > >> Some examples of things supported by the wrapper: > >> > >> atomics, types, bitops, byte order conversion, character devices, > >> pci devices, dma, non-device files, idr tables, interrupts, > >> ioremap, hashes, kobjects, radix trees, lists, modules, notifier > >> blocks, rbtrees, rwlock, rwsem, semaphore, schedule, spinlocks, > >> kalloc, wait queues, workqueues, timers, etc. > >> > >> Obviously a complete wrapper is impossible and I only implemented > >> the features that I needed. The build is accomplished by pointing > >> the linux compatible code at sys/ofed/include/ which has a > >> simulated linux kernel include tree. There are some config(8) > >> changes to help this along as well. > >> > >> I have seen that some attempt at similar wrappers has been made > >> elsewhere. I wonder if instead of making each one tailored to > >> individual components, which mostly seem to be filesystems so far, > >> should we put this in a central place under compat somewhere? Is > >> this project doomed to be tied to a single consumer by the specific > >> nature of it? > >> > >> Other comments or concerns? > >> > >> Thanks, > >> Jeff > > > > > > This probably will go against popular opinion here, but having 10k > > linux emulation layer that _almost_ work in the tree will be an > > unfortunate event and will do more damage to FreeBSD as a platform > > than good in the long run. I would rather see this code never hit > > main repository. >=20 > I would argue that the layer works very well for infiniband. Much > better than almost. It is only almost complete in that there is no > need for me to implement features that we're not using. >=20 > I am interested in hearing your other concerns however. >=20 > Thanks, > Jeff >=20 The considerations are simple enough. First, we do not have many IB users of FreeBSD in the wild and those that we have (Isilon) seem to be perfectly capable of managing the IB stack out of the tree, without dumping the thousands of lines of the code into the base. If they had the stack before, but were not willing/capable to provide adequate care for it in the past, there is no reason to expect things to change with second stack, which now will rot in our tree instead of theirs.=20 Second, semi-complete Linux compat layer in kernel will have the same effect as linuxulator in userland - we do have some vendors still trying to bother with FreeBSD drivers for their hardware now and we will have none after we provide the possibility to hack their Linux code to run somewhat stably on top of Linux compat layer. Due to intentional fluidity of Linux kAPI, our shims will never quite walk and quack like their original implementation in Linux kernel and combined result will always be lees stable than native Linux linux drivers in Linux kernel. --=20 Alexander Kabaev --Sig_/InHXaOUp4rOrZf6bSMUJWl1 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iD8DBQFNIx8xQ6z1jMm+XZYRApuTAJsEbIXbzyEGrU02xMeVe9jGDqikOQCgmdwi QrhoNQGPtVoG53kO541mFac= =J46A -----END PGP SIGNATURE----- --Sig_/InHXaOUp4rOrZf6bSMUJWl1-- From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 14:17:46 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9DC71065674; Tue, 4 Jan 2011 14:17:46 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE1C8FC1A; Tue, 4 Jan 2011 14:17:45 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=YBW/O6h5Sxti+EPY3DQm/1QFLiJsbZukn1QSWKMgb2w= c=1 sm=1 a=Q9fys5e9bTEA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=30vXWNrVMD3G1FlBmEIA:9 a=D26i-uPSezeBdPE5XmD-jHNgFqcA:4 a=PUjeQqilurYA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 70295735; Tue, 04 Jan 2011 15:07:42 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Tue, 4 Jan 2011 15:07:49 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <20110104082252.45bb5e7f@kan.dnsalias.net> In-Reply-To: <20110104082252.45bb5e7f@kan.dnsalias.net> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201101041507.49225.hselasky@c2i.net> Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 14:17:46 -0000 On Tuesday 04 January 2011 14:22:52 Alexander Kabaev wrote: > > > linux emulation layer that almost work in the tree will be an =46rom the side line: Have you considered putting all the linux stuff in userspace, alike what=20 webcamd in /usr/ports/multimedia/webcamd does? License wise I think it is a bad idea to have Linux code compiled together= =20 with FreeBSD code. =2D-HPS From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 14:17:46 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9DC71065674; Tue, 4 Jan 2011 14:17:46 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE1C8FC1A; Tue, 4 Jan 2011 14:17:45 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=YBW/O6h5Sxti+EPY3DQm/1QFLiJsbZukn1QSWKMgb2w= c=1 sm=1 a=Q9fys5e9bTEA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=30vXWNrVMD3G1FlBmEIA:9 a=D26i-uPSezeBdPE5XmD-jHNgFqcA:4 a=PUjeQqilurYA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 70295735; Tue, 04 Jan 2011 15:07:42 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Tue, 4 Jan 2011 15:07:49 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <20110104082252.45bb5e7f@kan.dnsalias.net> In-Reply-To: <20110104082252.45bb5e7f@kan.dnsalias.net> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201101041507.49225.hselasky@c2i.net> Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 14:17:46 -0000 On Tuesday 04 January 2011 14:22:52 Alexander Kabaev wrote: > > > linux emulation layer that almost work in the tree will be an =46rom the side line: Have you considered putting all the linux stuff in userspace, alike what=20 webcamd in /usr/ports/multimedia/webcamd does? License wise I think it is a bad idea to have Linux code compiled together= =20 with FreeBSD code. =2D-HPS From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 16:05:33 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E779D106564A for ; Tue, 4 Jan 2011 16:05:33 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id A9FFE8FC1A for ; Tue, 4 Jan 2011 16:05:33 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 9DF5558143; Tue, 4 Jan 2011 09:37:24 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id zMWJvM3FXatO; Tue, 4 Jan 2011 09:37:24 -0600 (CST) Received: from wanderer.tachypleus.net (unknown [76.210.75.5]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 108CD5811E; Tue, 4 Jan 2011 09:37:23 -0600 (CST) Message-ID: <4D233EB3.100@freebsd.org> Date: Tue, 04 Jan 2011 09:37:23 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101227 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alexander Kabaev References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> In-Reply-To: <20110104082252.45bb5e7f@kan.dnsalias.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 16:05:34 -0000 On 01/04/11 07:22, Alexander Kabaev wrote: > On Mon, 3 Jan 2011 19:03:01 -1000 (HST) > Jeff Roberson wrote: > >> On Mon, 3 Jan 2011, Alexander Kabaev wrote: >> >>> On Mon, 3 Jan 2011 10:31:24 -1000 (HST) >>> Jeff Roberson wrote: >> I would argue that the layer works very well for infiniband. Much >> better than almost. It is only almost complete in that there is no >> need for me to implement features that we're not using. >> >> I am interested in hearing your other concerns however. >> >> Thanks, >> Jeff >> > > The considerations are simple enough. First, we do not have many IB > users of FreeBSD in the wild and those that we have (Isilon) seem to be > perfectly capable of managing the IB stack out of the tree, without > dumping the thousands of lines of the code into the base. If they had > the stack before, but were not willing/capable to provide adequate care > for it in the past, there is no reason to expect things to change with > second stack, which now will rot in our tree instead of theirs. Before this, it was very difficult to be an Infiniband user on FreeBSD, which I think explains the dearth. And that Isilon chose to port this giant piece of code twice indicates that they do care very much. > Second, semi-complete Linux compat layer in kernel will have the > same effect as linuxulator in userland - we do have some vendors still > trying to bother with FreeBSD drivers for their hardware now and we > will have none after we provide the possibility to hack their Linux > code to run somewhat stably on top of Linux compat layer. Due to > intentional fluidity of Linux kAPI, our shims will never quite walk and > quack like their original implementation in Linux kernel and combined > result will always be lees stable than native Linux linux drivers in > Linux kernel. This is perhaps an argument for keeping it tightly coupled to the Infiniband stack, but certainly not for keeping it out of the tree. It seems that most vendor drivers have their own adaptation layer anyway and it would be just as easy for them to continue supporting FreeBSD as they always have. Project Evil did not lead to a huge decrease in availability of FreeBSD network drivers. As far as I understand, as well, this emulation layer is much less complete even than our NDIS support. -Nathan From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 16:44:33 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D683E106564A for ; Tue, 4 Jan 2011 16:44:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A7A198FC08 for ; Tue, 4 Jan 2011 16:44:33 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5B28346B5C; Tue, 4 Jan 2011 11:44:33 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 780418A027; Tue, 4 Jan 2011 11:44:32 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 4 Jan 2011 11:44:26 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <20110104082252.45bb5e7f@kan.dnsalias.net> In-Reply-To: <20110104082252.45bb5e7f@kan.dnsalias.net> MIME-Version: 1.0 Message-Id: <201101041144.26815.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 04 Jan 2011 11:44:32 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 16:44:33 -0000 On Tuesday, January 04, 2011 8:22:52 am Alexander Kabaev wrote: > The considerations are simple enough. First, we do not have many IB > users of FreeBSD in the wild and those that we have (Isilon) seem to be > perfectly capable of managing the IB stack out of the tree, without > dumping the thousands of lines of the code into the base. If they had > the stack before, but were not willing/capable to provide adequate care > for it in the past, there is no reason to expect things to change with > second stack, which now will rot in our tree instead of theirs. Actually, there are three different companies funding the IB port because there are in fact multiple users of IB on FreeBSD. It seems silly to have three+ different versions of the IB stack maintained separately rather than pooling developer resources across multiple FreeBSD consumers to amortize the future maintenance costs. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 16:56:45 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF629106564A; Tue, 4 Jan 2011 16:56:45 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 2C8568FC0A; Tue, 4 Jan 2011 16:56:45 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.4/8.14.4) with ESMTP id p049SAIo020866; Tue, 4 Jan 2011 03:28:54 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.4/8.14.4/Submit) id p03Jtsq2040059; Mon, 3 Jan 2011 13:55:54 -0600 (CST) (envelope-from brooks) Date: Mon, 3 Jan 2011 13:55:54 -0600 From: Brooks Davis To: Bruce Cran Message-ID: <20110103195554.GA39958@lor.one-eyed-alien.net> References: <4D20C8BF.701@freebsd.org> <20110102203548.000052e8@unknown> <4D20E28C.4090907@freebsd.org> <20110102204337.0000324f@unknown> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: <20110102204337.0000324f@unknown> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 04 Jan 2011 03:28:55 -0600 (CST) Cc: freebsd-arch@freebsd.org, Nathan Whitehorn , freebsd-sysinstall@freebsd.org Subject: Re: BSDInstall: I want the bikeshed painted plaid X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 16:56:46 -0000 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 02, 2011 at 08:43:37PM +0000, Bruce Cran wrote: > On Sun, 02 Jan 2011 14:39:40 -0600 > Nathan Whitehorn wrote: >=20 > > That's a good point. I was planning on using libfetch's restart > > feature for this case. Do you think that would be unreliable? >=20 > I'm not sure enough servers support it that you could rely on it. I'd be pretty surprised if you could find a a non-toy http server that didn't support ranged gets. FTP support should be similar since restart has been at least moderately common as long as I've been on the internet (since the early 90s). -- Brooks --T4sUOijqQbZv57TR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFNIinJXY6L6fI4GtQRAtNaAJ9L/P3JBTd5qI0KTL+Y8FF0XltlOQCfVrKC 8n1sf1dyPCQ+vAznePdrZXQ= =Nj9c -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 17:31:59 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F107C1065674; Tue, 4 Jan 2011 17:31:58 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 2BCB28FC14; Tue, 4 Jan 2011 17:31:57 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id p04GtV5b077020; Tue, 4 Jan 2011 09:55:32 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <85271.1294128867@critter.freebsd.dk> Date: Tue, 4 Jan 2011 09:55:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <85271.1294128867@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.1082) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: arch@freebsd.org, Alfred Perlstein , Garrett Cooper Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 17:31:59 -0000 On Jan 4, 2011, at 1:14 AM, Poul-Henning Kamp wrote: > In message , Jeff Roberson = writes: >=20 >> Also, linux likes to change things very rapidly. Not to mention a = lot of=20 >> their APIs go against the grain on BSD and we would not find them=20 >> aesthetically or architecturally pleasing. >=20 > Absolutely. >=20 > But we, as a project, must also weigh the cost of our sensibilities > and preferences, against how much work we must expend to uphold them. >=20 I have mixed feelings about Jeff's shim layer. On the plus side, I = think that there's value to emulation without copying. On the negative = side, I agree with ALexander's concern that it's a large chuck of code = to be maintained. Emulation isn't a bad thing. It allows IHV's as well = as individual developers to take baby steps with getting familiar with = FreeBSD. It lowers the barrier to entry. The ones who aren't going = to put in the effort to making the leap from "emulation" to "native" = likely aren't going to take the leap with going from "nothing" to = "native" either. I understand the argument that it will coddle people = into using just the emulation and not the native interfaces, thus = degrading the value of the native interfaces. I'm just not sure how = much I believe that in my experience. I recall years ago Matt Jacob mentioning with some concern that the = project seemed to be aimed at creating a "FreeSolaris" of sorts; many of = the architectural decisions seemed to be based on the argument that = Solaris was doing it, so FreeBSD should too. That's fine, and there's a = certain amount of comfort in following an arguably decent architectural = standard like Solaris, though I understand what I believed to be Matt's = point about retaining some identity and exploring new paths rather than = just following old paths. In my not so humble opinion, Linux is not an architectural model to be = envied or copied, regardless of how pragmatic it might seem. Sure, = gratuitous differences can be argued against, but there are a lot of = fundamental architectural things that linux succeed at purely by brute = force of will, and nothing more. FreeBSD should be careful to not envy = that model. I think that there's a lot less value in both the long and = short terms in a "FreeLinux" than in a "FreeSolaris", and neither are = all that good in the long term. Having an emulation gives people a lower barrier to entry and some = stepping stones to getting comfortable with FreeBSD. It gives them a = series of achievable goals with costs and benefits at each step that can = be weighed. Aiming at simply evolving the native interfaces to be like = linux simply means that FreeBSD becomes a poor copy of linux with = nothing else under the surface to set it apart or create an attraction. Scott From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 18:18:54 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E31651065696 for ; Tue, 4 Jan 2011 18:18:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BDB0F8FC18 for ; Tue, 4 Jan 2011 18:18:54 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 5B97846B09; Tue, 4 Jan 2011 13:18:54 -0500 (EST) Date: Tue, 4 Jan 2011 18:18:54 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jeff Roberson In-Reply-To: Message-ID: References: <82826.1294088199@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Poul-Henning Kamp Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 18:18:55 -0000 On Mon, 3 Jan 2011, Jeff Roberson wrote: >> Those where there are substantial differences, we should only have one >> compat layer, not one for each driver. > > I would like this to be the case. So we can converge on something complete. > There are of course big differences between minor linux kernel revisions and > that poses problems. However those should be easier than the bsd/linux > differences. > > I think my proposal is to move these files to a more generic location so > they are more visible and available to other projects. Maintainers of > individual kernel ports would have to decide if they want to use what is > there. I think it's worth making a comparison with how we handle our Open Solaris shim parts, found (largely) in opensolaris.ko, which supports Solaris-derived features such as DTrace and ZFS. It is forced to address header location issues, license isolation issues, etc, and there may be some useful lessons there. There are also some potentially relevant problems: for example, in a formal sense, what version of an OS's KPI do we track? I'm no expert on opensolaris.ko, but my recollection is that we had a problem for a while where our versions of DTrace and ZFS did not come from the same version of Solaris. This even though the Sun (now Oracle) folks put a lot of work into stable kernel programming interfaces for dervice driver authors, etc. The Linux community is less well-known for its efforts in this area, and have faster-moving KPIs. Do we think there's sufficient KPI stability there to have a linux_kpi.ko (or whatever) that can serve more than one major consumer? Or is it sufficient to say that all Linux-derived code should track one Linux kernel version? On a related note, I've been pondering Apple's KPI changes to FReeBSD recently as well -- I'd like to import some of their many enhancements to our smbfs (also to be found in Solaris, FYI), and their KPI work has minimised easy porting of changes between the FreeBSD and Mac OS X. Since we invest relatively little work in smbfs, and they are deeply invested in a functional smbfs, I've also been pondering an xnu.ko (or at least, xnu_mbuf.h). Finally, lest we convince ourselves that every KPI is better/worse than ours: the same problem exists for people working on several other OS's that downstream our code: Mac OS X, Solaris, NetBSD, OpenBSD, etc. Operating system kernels are rapidly evolving, highly concurrent, highly specialised, and highly optimised C programs -- not only is variation a pretty natural thing, but I suspect any attempt to standardise would hold everyone back. Robert From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 19:02:00 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 290B1106566C for ; Tue, 4 Jan 2011 19:02:00 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id E81478FC12 for ; Tue, 4 Jan 2011 19:01:58 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.4/8.14.3) with ESMTP id p04J1vIe005289 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 4 Jan 2011 11:01:58 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4D236EA1.8000101@feral.com> Date: Tue, 04 Jan 2011 11:01:53 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <20110104082252.45bb5e7f@kan.dnsalias.net> <201101041144.26815.jhb@freebsd.org> In-Reply-To: <201101041144.26815.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Tue, 04 Jan 2011 11:01:58 -0800 (PST) Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 19:02:00 -0000 On 1/4/2011 8:44 AM, John Baldwin wrote: > > Actually, there are three different companies funding the IB port because > there are in fact multiple users of IB on FreeBSD. It seems silly to have > three+ different versions of the IB stack maintained separately rather than > pooling developer resources across multiple FreeBSD consumers to amortize the > future maintenance costs. > Hear, Hear! To a certain degree these three companies are competitors, but in the case of having a working IB stack, it benefits us all to have a common one. From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 19:29:36 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E94E71065670 for ; Tue, 4 Jan 2011 19:29:36 +0000 (UTC) (envelope-from chris@behanna.org) Received: from nm4.bullet.mail.ac4.yahoo.com (nm4.bullet.mail.ac4.yahoo.com [98.139.52.201]) by mx1.freebsd.org (Postfix) with SMTP id A09F28FC1A for ; Tue, 4 Jan 2011 19:29:36 +0000 (UTC) Received: from [98.139.52.196] by nm4.bullet.mail.ac4.yahoo.com with NNFMP; 04 Jan 2011 19:15:58 -0000 Received: from [98.139.52.136] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 04 Jan 2011 19:15:54 -0000 Received: from [127.0.0.1] by omp1019.mail.ac4.yahoo.com with NNFMP; 04 Jan 2011 19:15:54 -0000 X-Yahoo-Newman-Id: 544603.65159.bm@omp1019.mail.ac4.yahoo.com Received: (qmail 60710 invoked from network); 4 Jan 2011 19:15:54 -0000 Received: from tourmalet.ticom-geo.com (chris@64.132.190.26 with plain) by smtp101.sbc.mail.re3.yahoo.com with SMTP; 04 Jan 2011 11:15:54 -0800 PST X-Yahoo-SMTP: IImPLAuswBCrx2RdXZGWc4UZbB59Q8rbW69ykY5boJ7l_g-- X-YMail-OSG: J5u1AhYVM1ncxgQkEjcF0vaOXDhEF.9ohIwCy2jJKUV2nnS hdzg1YP1LWrSHwl_69QwsL5QiZesy6drxeRiMfmGh0uS4OuJgXqmsAk6OoFv z31T8Y0o2hIzVqjUHr5lmlEycmBWvttte_gqo3a12hqOX_N9xFoSkGSEkOtd _xYQQC9HehWhvc784KjSRuRSgf7vqJJOV_SmqtgA0m7mtkngtlWrte5pBizg ..43mPgmEfxvIA7QAMdBbzvOzJRv_A7KIXsumiQ3qm._waDOLtXdRsim2Teb Xgw-- X-Yahoo-Newman-Property: ymail-3 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Chris BeHanna In-Reply-To: Date: Tue, 4 Jan 2011 13:15:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <55CB0273-36D6-44FC-9F28-8E59003051D2@behanna.org> References: <82826.1294088199@critter.freebsd.dk> To: arch@freebsd.org X-Mailer: Apple Mail (2.1082) Cc: Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 19:29:37 -0000 On Jan 4, 2011, at 12:18 , Robert Watson wrote: > On Mon, 3 Jan 2011, Jeff Roberson wrote: >=20 >>> Those where there are substantial differences, we should only have = one compat layer, not one for each driver. >>=20 >> I would like this to be the case. So we can converge on something = complete. There are of course big differences between minor linux kernel = revisions and that poses problems. However those should be easier than = the bsd/linux differences. >>=20 >> I think my proposal is to move these files to a more generic location = so they are more visible and available to other projects. Maintainers = of individual kernel ports would have to decide if they want to use what = is there. >=20 > I think it's worth making a comparison with how we handle our Open = Solaris shim parts, found (largely) in opensolaris.ko, which supports = Solaris-derived features such as DTrace and ZFS. It is forced to = address header location issues, license isolation issues, etc, and there = may be some useful lessons there. >=20 > There are also some potentially relevant problems: for example, in a = formal sense, what version of an OS's KPI do we track? I'm no expert on = opensolaris.ko, but my recollection is that we had a problem for a while = where our versions of DTrace and ZFS did not come from the same version = of Solaris. This even though the Sun (now Oracle) folks put a lot of = work into stable kernel programming interfaces for dervice driver = authors, etc. The Linux community is less well-known for its efforts in = this area, and have faster-moving KPIs. Do we think there's sufficient = KPI stability there to have a linux_kpi.ko (or whatever) that can serve = more than one major consumer? Or is it sufficient to say that all = Linux-derived code should track one Linux kernel version? >=20 > [...snip...] Please forgive me for intruding, but I have some experience with = this that you may find valuable. In a past life, I worked at a storage = company, where my main area of responsibility for some years was porting = our out-of-tree file system kernel module across several Linux distros = on several architectures, a feat which would not have been possible = without a very large kAPI abstraction layer and a clever mechanism for = cross-building different kernel versions on the same machine, in the = same build output tree. I would say that you want to pick a major release of one or at = most two major commercial distros (I'll pick on Red Hat Enterprise Linux = and the enterprise SuSE for illustration), and track the major releases = of them that correspond to roughly the same Linux kernel version, and = then STICK to that for the life of a given FreeBSD release stream. = Commercial vendors backport fixes into their otherwise-fairly-stable = major releases, which minimizes your pain. There are still some changes = here and there along the way, and you have to decide how many kernel = config options you are willing to support (I'd suggest the default SMP, = maybe the default PAE, and punt everything else or you'll go mad). The combinatorial pain of committing to more than that leads to = a desire for seppuku: I had to support multiple kernel versions each = (and often multiple configurations per kernel) for Red Hat 7, 8, 9; RHEL = 4 and 5, SuSE Enterprise 9, 10, 10.1, and 10.2, SuSE Desktop 9 and 10, = and Fedora 4, 5, and 6 across x86, x86-64, and IA-64, and it ended up = being more than 400 binaries to be generated, tested, and delivered = every time we issued a patch release. Linux is shifting sand. Picking and sticking to the default = configurations of at most one major release each of two major distros, = per FreeBSD release stream, at least puts you on the hard-packed stuff = near the tide line. Even that is a moving target, as RHEL and SuSE will = issue a frequent stream of security updates that will bump kernel patch = versions, so "version magic" gets to be a pain to get modules to = auto-load, though there is some provision for "weak" symbol versioning = in 2.6.18 and beyond. --=20 Chris BeHanna chris@behanna.org From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 20:50:53 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D4C0106566B for ; Tue, 4 Jan 2011 20:50:53 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8E4E88FC14 for ; Tue, 4 Jan 2011 20:50:52 +0000 (UTC) Received: by fxm16 with SMTP id 16so14322975fxm.13 for ; Tue, 04 Jan 2011 12:50:51 -0800 (PST) Received: by 10.223.96.139 with SMTP id h11mr653559fan.82.1294174251635; Tue, 04 Jan 2011 12:50:51 -0800 (PST) Received: from [10.0.1.198] ([72.253.42.56]) by mx.google.com with ESMTPS id y3sm5263479fai.38.2011.01.04.12.50.49 (version=SSLv3 cipher=RC4-MD5); Tue, 04 Jan 2011 12:50:50 -0800 (PST) Date: Tue, 4 Jan 2011 10:53:30 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Alexander Kabaev In-Reply-To: <20110104082252.45bb5e7f@kan.dnsalias.net> Message-ID: References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 20:50:53 -0000 On Tue, 4 Jan 2011, Alexander Kabaev wrote: > On Mon, 3 Jan 2011 19:03:01 -1000 (HST) > Jeff Roberson wrote: > >> On Mon, 3 Jan 2011, Alexander Kabaev wrote: >> >>> On Mon, 3 Jan 2011 10:31:24 -1000 (HST) >>> Jeff Roberson wrote: >>> >>>> Hello Folks, >>>> >>>> Some of you may have seen my infiniband work proceed in svn. It is >>>> coming to a close soon and I will be integrating it into current. >>>> I have a few patches to the kernel to send for review but I wanted >>>> to bring up the KPI wrapper itself for discussion. >>>> >>>> The infiniband port has been done by creating a 10,000 line KPI >>>> compatability layer. With this layer the vast majority of the >>>> driver code runs unmodified. The exceptions are anything that >>>> interfaces with skbs and most of the code that deals with network >>>> interfaces. >>>> >>>> Some examples of things supported by the wrapper: >>>> >>>> atomics, types, bitops, byte order conversion, character devices, >>>> pci devices, dma, non-device files, idr tables, interrupts, >>>> ioremap, hashes, kobjects, radix trees, lists, modules, notifier >>>> blocks, rbtrees, rwlock, rwsem, semaphore, schedule, spinlocks, >>>> kalloc, wait queues, workqueues, timers, etc. >>>> >>>> Obviously a complete wrapper is impossible and I only implemented >>>> the features that I needed. The build is accomplished by pointing >>>> the linux compatible code at sys/ofed/include/ which has a >>>> simulated linux kernel include tree. There are some config(8) >>>> changes to help this along as well. >>>> >>>> I have seen that some attempt at similar wrappers has been made >>>> elsewhere. I wonder if instead of making each one tailored to >>>> individual components, which mostly seem to be filesystems so far, >>>> should we put this in a central place under compat somewhere? Is >>>> this project doomed to be tied to a single consumer by the specific >>>> nature of it? >>>> >>>> Other comments or concerns? >>>> >>>> Thanks, >>>> Jeff >>> >>> >>> This probably will go against popular opinion here, but having 10k >>> linux emulation layer that _almost_ work in the tree will be an >>> unfortunate event and will do more damage to FreeBSD as a platform >>> than good in the long run. I would rather see this code never hit >>> main repository. >> >> I would argue that the layer works very well for infiniband. Much >> better than almost. It is only almost complete in that there is no >> need for me to implement features that we're not using. >> >> I am interested in hearing your other concerns however. >> >> Thanks, >> Jeff >> > Alexander, let me first start out by saying I have a great deal of respect for you and I hear your concerns. I see that this is a somewhat heated issue and I can really only address the technical points. The more existential questions about FreeBSD will have to be left to others. > The considerations are simple enough. First, we do not have many IB > users of FreeBSD in the wild and those that we have (Isilon) seem to be > perfectly capable of managing the IB stack out of the tree, without > dumping the thousands of lines of the code into the base. If they had > the stack before, but were not willing/capable to provide adequate care > for it in the past, there is no reason to expect things to change with > second stack, which now will rot in our tree instead of theirs. They provided adequate care for it to keep their product running on old versions of FreeBSD. Unfortunately it is a large stack and there are a great number of people and organizations working on improving and advancing it on Linux via OFED and having a private stack does not give you the benefit of their work. The motivation for making the wrapper layer was entirely to keep pace with this development and make it less likely that what is in the tree will rot. > > Second, semi-complete Linux compat layer in kernel will have the > same effect as linuxulator in userland - we do have some vendors still > trying to bother with FreeBSD drivers for their hardware now and we > will have none after we provide the possibility to hack their Linux > code to run somewhat stably on top of Linux compat layer. Due to > intentional fluidity of Linux kAPI, our shims will never quite walk and > quack like their original implementation in Linux kernel and combined > result will always be lees stable than native Linux linux drivers in > Linux kernel. I have heard this argument about the linuxulator and what we're really talking about is slipping FreeBSD marketshare. I don't share the view that the linuxulator futhered this slip but rather my view is that it allows us to stay relevant in areas where companies can not justify an independent FreeBSD effort. Adobe is a good example of this. Let's talk nuts and bolts about what this thing does. In the vast majority of cases it simply shuffles arguments and function names around where there is a 1:1 correlation between linux api and FreeBSD API. Think about things like atomics, callouts, locks, jiffies vs ticks, etc. In these areas the systems are trivially different. In a very small number of areas where this wasn't the case I did a direct port and noted it with an #ifdef. This works specifically in the infiniband case because it is its own middle layer. You can't write a scsi driver for linux and use it on BSD with this. You can't write a network driver even. But if you do bring in code from linux you don't have to worry about changing every kmalloc to malloc and every printk to printf so diffs can be reduced in trivial cases. I thought given your work on XFS for FreeBSD that would make sense to you. Our options are, to leave FreeBSD users without infiniband, which I can tell you has cost us more market share as I know of specific cases we have lost due to it. To maintain our own stack independently, which no one has the budget for. Or to try to integrate with OFED. Do you see some other approach? Thanks, Jeff > > > -- > Alexander Kabaev > From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 21:25:45 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DD1D106566B; Tue, 4 Jan 2011 21:25:45 +0000 (UTC) (envelope-from jhixson@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 97A088FC12; Tue, 4 Jan 2011 21:25:44 +0000 (UTC) Received: by iyb26 with SMTP id 26so13934662iyb.13 for ; Tue, 04 Jan 2011 13:25:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=gOjOScYKLx7ceuzqAX+yeCd4rAyBLrblvSTEMEkMgwM=; b=JQYMQV2wYD/zbIyQLsVjqgJkiuJFl0D2+HfFQp7kQHPne61N7jTyiOHXkTl6kMKm36 6QI0gvu+S0gl1W56pl7n/XHyHxHK9FfxoZH+n+RTDuShq7k2CRmBukLXfuHgg91Ub0wa mddmSiEZpmUa4Xt/1KR4kJOZKojcrxOEj+F8w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aTCjAIvgO7+CO6ON0zypoGdUMo92jC50lBcTtkSuAlCrOM0y/Gf305amKUknojWuLz 4bgbPLzkSuXYoJZkEfsv9sk6qVB9DSBpIMg1r3lrMYV87dMT2K24+/sqaAw+Cwg4qgxg UtDnnA3KWdwOF29wd5D4+VmBkIkIsObXNShRM= MIME-Version: 1.0 Received: by 10.42.166.200 with SMTP id p8mr21422061icy.87.1294176343784; Tue, 04 Jan 2011 13:25:43 -0800 (PST) Received: by 10.42.58.72 with HTTP; Tue, 4 Jan 2011 13:25:43 -0800 (PST) In-Reply-To: <4D22D30A.2050606@executive-computing.de> References: <4D20C8BF.701@freebsd.org> <29AA82C4-6301-4DCD-BC9D-423AD162998E@gmail.com> <4D20DDE4.8080306@freebsd.org> <4D22D30A.2050606@executive-computing.de> Date: Tue, 4 Jan 2011 13:25:43 -0800 Message-ID: From: John Hixson To: Marco Steinbach Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Garrett Cooper , Bruce Cran , john@ixsystems.com, Nathan Whitehorn , freebsd-arch@freebsd.org, matt@ixsystems.com, freebsd-sysinstall@freebsd.org Subject: Re: BSDInstall: I want the bikeshed painted plaid X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 21:25:45 -0000 On Mon, Jan 3, 2011 at 11:58 PM, Marco Steinbach < coco@executive-computing.de> wrote: > John Hixson wrote on 02.01.2011 22:51: > > On Sun, Jan 2, 2011 at 12:19 PM, Nathan Whitehorn > >wrote: >> >> I spent a bunch of time looking at pc-sysinstall before starting to work >>> on >>> this. The major problem for non-x86 systems is that it heavily assumes >>> that >>> your disks are either MBR+bsdlabel or GPT. If you have anything different >>> (APM, VTOC8, or even a raw bsdlabel or MBR installation on x86), it >>> breaks >>> in strange and fascinating ways due to a random mixture of if (scheme == >>> MBR) else and if (scheme == GPT) else in the backend. Some of these are >>> easily fixed, but it looked quite difficult to root out all of the places >>> this assumption is made, not to mention teaching it about various styles >>> of >>> boot code, that the same partitioning scheme may need to be set up >>> different >>> ways on different architectures, etc. txt-sysinstall also segfaults when >>> you >>> try to run it on powerpc at the moment, though that is likely a simple >>> bug >>> and I didn't look into it in detail. >>> >>> What I intended with bsdinstall is to have something simple, flexible, >>> and >>> easily maintained that works immediately on all platforms and will be >>> ready >>> for 9.0 for sure. If pc-sysinstall materializes before then, or after >>> then, >>> and people like it better, I'm more than happy to get out of the way; >>> this >>> is the reason the wiki page is titled "Stopgap Installer". In the >>> interim, I >>> hoped to at least start laying out the hammer and nails next to >>> sysinstall's >>> coffin. >>> -Nathan >>> >>> >>> I would be more than happy to help out with making pc-sysinstall work on >> non-x86 systems, however I don't have access to any. Do any of you have >> hardware that could possibly be used by interested parties? I'm sure all >> the >> work that's gone into bsdinstall could be used in pc-sysinstall or vice >> versa. >> > > I have PowerMacs (G3/G4) and Netras/Ultras (T1 105, U10, U5) at my > discretion. I've never installed FreeBSD on any of them, but would be > willing to give it a shot. > > I can provide serial console access to the Sparcs, but the PowerMacs > supposedly need "hands on", which I can also provide. > > If there's interest, I humbly suggest discussing further details on the > course of action at sysinstall@, to which I just subscribed. > > I just subscribed to sysinstall@. I'd be happy to help starting out on the sparcs. I have no experience whatsoever on powermac, but it sounds fun ;-). - John From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 22:44:10 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29C8F106564A for ; Tue, 4 Jan 2011 22:44:10 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-29.mx.aerioconnect.net [216.240.47.89]) by mx1.freebsd.org (Postfix) with ESMTP id 082E78FC08 for ; Tue, 4 Jan 2011 22:44:09 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id p04Mi8en004296; Tue, 4 Jan 2011 14:44:08 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 379072D6012; Tue, 4 Jan 2011 14:44:06 -0800 (PST) Message-ID: <4D23A2CF.1010904@freebsd.org> Date: Tue, 04 Jan 2011 14:44:31 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeff Roberson References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 22:44:10 -0000 On 1/4/11 12:53 PM, Jeff Roberson wrote: > On Tue, 4 Jan 2011, Alexander Kabaev wrote: > >> On Mon, 3 Jan 2011 19:03:01 -1000 (HST) >> Jeff Roberson wrote: >> >>> On Mon, 3 Jan 2011, Alexander Kabaev wrote: >>> >>>> On Mon, 3 Jan 2011 10:31:24 -1000 (HST) >>>> Jeff Roberson wrote: >>>> >>>>> Hello Folks, >>>>> >>>>> Some of you may have seen my infiniband work proceed in svn. It is >>>>> coming to a close soon and I will be integrating it into current. >>>>> I have a few patches to the kernel to send for review but I wanted >>>>> to bring up the KPI wrapper itself for discussion. >>>>> >>>>> The infiniband port has been done by creating a 10,000 line KPI >>>>> compatability layer. With this layer the vast majority of the >>>>> driver code runs unmodified. The exceptions are anything that >>>>> interfaces with skbs and most of the code that deals with network >>>>> interfaces. >>>>> >>>>> Some examples of things supported by the wrapper: >>>>> >>>>> atomics, types, bitops, byte order conversion, character devices, >>>>> pci devices, dma, non-device files, idr tables, interrupts, >>>>> ioremap, hashes, kobjects, radix trees, lists, modules, notifier >>>>> blocks, rbtrees, rwlock, rwsem, semaphore, schedule, spinlocks, >>>>> kalloc, wait queues, workqueues, timers, etc. >>>>> >>>>> Obviously a complete wrapper is impossible and I only implemented >>>>> the features that I needed. The build is accomplished by pointing >>>>> the linux compatible code at sys/ofed/include/ which has a >>>>> simulated linux kernel include tree. There are some config(8) >>>>> changes to help this along as well. >>>>> >>>>> I have seen that some attempt at similar wrappers has been made >>>>> elsewhere. I wonder if instead of making each one tailored to >>>>> individual components, which mostly seem to be filesystems so far, >>>>> should we put this in a central place under compat somewhere? Is >>>>> this project doomed to be tied to a single consumer by the specific >>>>> nature of it? >>>>> >>>>> Other comments or concerns? >>>>> >>>>> Thanks, >>>>> Jeff >>>> >>>> >>>> This probably will go against popular opinion here, but having 10k >>>> linux emulation layer that _almost_ work in the tree will be an >>>> unfortunate event and will do more damage to FreeBSD as a platform >>>> than good in the long run. I would rather see this code never hit >>>> main repository. >>> >>> I would argue that the layer works very well for infiniband. Much >>> better than almost. It is only almost complete in that there is no >>> need for me to implement features that we're not using. >>> >>> I am interested in hearing your other concerns however. >>> >>> Thanks, >>> Jeff >>> >> > > Alexander, let me first start out by saying I have a great deal of > respect for you and I hear your concerns. I see that this is a > somewhat heated issue and I can really only address the technical > points. The more existential questions about FreeBSD will have to > be left to others. > >> The considerations are simple enough. First, we do not have many IB >> users of FreeBSD in the wild and those that we have (Isilon) seem >> to be >> perfectly capable of managing the IB stack out of the tree, without >> dumping the thousands of lines of the code into the base. If they had >> the stack before, but were not willing/capable to provide adequate >> care >> for it in the past, there is no reason to expect things to change with >> second stack, which now will rot in our tree instead of theirs. > > They provided adequate care for it to keep their product running on > old versions of FreeBSD. Unfortunately it is a large stack and > there are a great number of people and organizations working on > improving and advancing it on Linux via OFED and having a private > stack does not give you the benefit of their work. The motivation > for making the wrapper layer was entirely to keep pace with this > development and make it less likely that what is in the tree will rot. > >> >> Second, semi-complete Linux compat layer in kernel will have the >> same effect as linuxulator in userland - we do have some vendors still >> trying to bother with FreeBSD drivers for their hardware now and we >> will have none after we provide the possibility to hack their Linux >> code to run somewhat stably on top of Linux compat layer. Due to >> intentional fluidity of Linux kAPI, our shims will never quite walk >> and >> quack like their original implementation in Linux kernel and combined >> result will always be lees stable than native Linux linux drivers in >> Linux kernel. > > I have heard this argument about the linuxulator and what we're > really talking about is slipping FreeBSD marketshare. I don't share > the view that the linuxulator futhered this slip but rather my view > is that it allows us to stay relevant in areas where companies can > not justify an independent FreeBSD effort. Adobe is a good example > of this. > > Let's talk nuts and bolts about what this thing does. In the vast > majority of cases it simply shuffles arguments and function names > around where there is a 1:1 correlation between linux api and > FreeBSD API. Think about things like atomics, callouts, locks, > jiffies vs ticks, etc. In these areas the systems are trivially > different. In a very small number of areas where this wasn't the > case I did a direct port and noted it with an #ifdef. > > This works specifically in the infiniband case because it is its own > middle layer. You can't write a scsi driver for linux and use it on > BSD with this. You can't write a network driver even. But if you > do bring in code from linux you don't have to worry about changing > every kmalloc to malloc and every printk to printf so diffs can be > reduced in trivial cases. I thought given your work on XFS for > FreeBSD that would make sense to you. > > Our options are, to leave FreeBSD users without infiniband, which I > can tell you has cost us more market share as I know of specific > cases we have lost due to it. To maintain our own stack > independently, which no one has the budget for. Or to try to > integrate with OFED. Do you see some other approach? As you may know Alexander and I both work for a company that produces a "large" driver that runs on everything from windows to FreeBSD and everything in between (linux, osx, esx, aix, solaris).. we have a porting layer (Alexander hates it I know). But it's not a freebsd to linux layer, it's a freebsd (or whatever) to 'internal' layer, (though it started out being the first). Looking at what we have and what you have it seems to me that we could take a subset of the basic CS101 methods that are there and make a linux driver porter's toolkit. things like linux style linked lists vs out queue macros can be addressed easily, but it's just a pain in the neck to do so.. also linux run queues and such are different but making a small set of toolkits to do so wouldn't be a bad idea. some of the more esoteric parts might stay with the ib code however. > > Thanks, > Jeff > >> >> >> -- >> Alexander Kabaev >> > _______________________________________________ > 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 Tue Jan 4 23:10:23 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 673DC1065670 for ; Tue, 4 Jan 2011 23:10:23 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2415E8FC15 for ; Tue, 4 Jan 2011 23:10:22 +0000 (UTC) Received: by vws9 with SMTP id 9so6165547vws.13 for ; Tue, 04 Jan 2011 15:10:22 -0800 (PST) Received: by 10.220.81.5 with SMTP id v5mr6740600vck.74.1294182620899; Tue, 04 Jan 2011 15:10:20 -0800 (PST) Received: from [10.0.1.198] ([72.253.42.56]) by mx.google.com with ESMTPS id u4sm4725501vch.36.2011.01.04.15.10.17 (version=SSLv3 cipher=RC4-MD5); Tue, 04 Jan 2011 15:10:19 -0800 (PST) Date: Tue, 4 Jan 2011 13:13:00 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Julian Elischer In-Reply-To: <4D23A2CF.1010904@freebsd.org> Message-ID: References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <4D23A2CF.1010904@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 23:10:23 -0000 On Tue, 4 Jan 2011, Julian Elischer wrote: > On 1/4/11 12:53 PM, Jeff Roberson wrote: >> On Tue, 4 Jan 2011, Alexander Kabaev wrote: >> >>> On Mon, 3 Jan 2011 19:03:01 -1000 (HST) >>> Jeff Roberson wrote: >>> >>>> On Mon, 3 Jan 2011, Alexander Kabaev wrote: >>>> >>>>> On Mon, 3 Jan 2011 10:31:24 -1000 (HST) >>>>> Jeff Roberson wrote: >>>>> >>>>>> Hello Folks, >>>>>> >>>>>> Some of you may have seen my infiniband work proceed in svn. It is >>>>>> coming to a close soon and I will be integrating it into current. >>>>>> I have a few patches to the kernel to send for review but I wanted >>>>>> to bring up the KPI wrapper itself for discussion. >>>>>> >>>>>> The infiniband port has been done by creating a 10,000 line KPI >>>>>> compatability layer. With this layer the vast majority of the >>>>>> driver code runs unmodified. The exceptions are anything that >>>>>> interfaces with skbs and most of the code that deals with network >>>>>> interfaces. >>>>>> >>>>>> Some examples of things supported by the wrapper: >>>>>> >>>>>> atomics, types, bitops, byte order conversion, character devices, >>>>>> pci devices, dma, non-device files, idr tables, interrupts, >>>>>> ioremap, hashes, kobjects, radix trees, lists, modules, notifier >>>>>> blocks, rbtrees, rwlock, rwsem, semaphore, schedule, spinlocks, >>>>>> kalloc, wait queues, workqueues, timers, etc. >>>>>> >>>>>> Obviously a complete wrapper is impossible and I only implemented >>>>>> the features that I needed. The build is accomplished by pointing >>>>>> the linux compatible code at sys/ofed/include/ which has a >>>>>> simulated linux kernel include tree. There are some config(8) >>>>>> changes to help this along as well. >>>>>> >>>>>> I have seen that some attempt at similar wrappers has been made >>>>>> elsewhere. I wonder if instead of making each one tailored to >>>>>> individual components, which mostly seem to be filesystems so far, >>>>>> should we put this in a central place under compat somewhere? Is >>>>>> this project doomed to be tied to a single consumer by the specific >>>>>> nature of it? >>>>>> >>>>>> Other comments or concerns? >>>>>> >>>>>> Thanks, >>>>>> Jeff >>>>> >>>>> >>>>> This probably will go against popular opinion here, but having 10k >>>>> linux emulation layer that _almost_ work in the tree will be an >>>>> unfortunate event and will do more damage to FreeBSD as a platform >>>>> than good in the long run. I would rather see this code never hit >>>>> main repository. >>>> >>>> I would argue that the layer works very well for infiniband. Much >>>> better than almost. It is only almost complete in that there is no >>>> need for me to implement features that we're not using. >>>> >>>> I am interested in hearing your other concerns however. >>>> >>>> Thanks, >>>> Jeff >>>> >>> >> >> Alexander, let me first start out by saying I have a great deal of respect >> for you and I hear your concerns. I see that this is a somewhat heated >> issue and I can really only address the technical points. The more >> existential questions about FreeBSD will have to be left to others. >> >>> The considerations are simple enough. First, we do not have many IB >>> users of FreeBSD in the wild and those that we have (Isilon) seem to be >>> perfectly capable of managing the IB stack out of the tree, without >>> dumping the thousands of lines of the code into the base. If they had >>> the stack before, but were not willing/capable to provide adequate care >>> for it in the past, there is no reason to expect things to change with >>> second stack, which now will rot in our tree instead of theirs. >> >> They provided adequate care for it to keep their product running on old >> versions of FreeBSD. Unfortunately it is a large stack and there are a >> great number of people and organizations working on improving and advancing >> it on Linux via OFED and having a private stack does not give you the >> benefit of their work. The motivation for making the wrapper layer was >> entirely to keep pace with this development and make it less likely that >> what is in the tree will rot. >> >>> >>> Second, semi-complete Linux compat layer in kernel will have the >>> same effect as linuxulator in userland - we do have some vendors still >>> trying to bother with FreeBSD drivers for their hardware now and we >>> will have none after we provide the possibility to hack their Linux >>> code to run somewhat stably on top of Linux compat layer. Due to >>> intentional fluidity of Linux kAPI, our shims will never quite walk and >>> quack like their original implementation in Linux kernel and combined >>> result will always be lees stable than native Linux linux drivers in >>> Linux kernel. >> >> I have heard this argument about the linuxulator and what we're really >> talking about is slipping FreeBSD marketshare. I don't share the view that >> the linuxulator futhered this slip but rather my view is that it allows us >> to stay relevant in areas where companies can not justify an independent >> FreeBSD effort. Adobe is a good example of this. >> >> Let's talk nuts and bolts about what this thing does. In the vast majority >> of cases it simply shuffles arguments and function names around where there >> is a 1:1 correlation between linux api and FreeBSD API. Think about things >> like atomics, callouts, locks, jiffies vs ticks, etc. In these areas the >> systems are trivially different. In a very small number of areas where >> this wasn't the case I did a direct port and noted it with an #ifdef. >> >> This works specifically in the infiniband case because it is its own middle >> layer. You can't write a scsi driver for linux and use it on BSD with >> this. You can't write a network driver even. But if you do bring in code >> from linux you don't have to worry about changing every kmalloc to malloc >> and every printk to printf so diffs can be reduced in trivial cases. I >> thought given your work on XFS for FreeBSD that would make sense to you. >> >> Our options are, to leave FreeBSD users without infiniband, which I can >> tell you has cost us more market share as I know of specific cases we have >> lost due to it. To maintain our own stack independently, which no one has >> the budget for. Or to try to integrate with OFED. Do you see some other >> approach? > As you may know Alexander and I both work for a company that produces a > "large" driver that runs on everything from windows to FreeBSD and everything > in between (linux, osx, esx, aix, solaris).. we have a porting layer > (Alexander hates it I know). > But it's not a freebsd to linux layer, it's a freebsd (or whatever) to > 'internal' layer, > (though it started out being the first). > Looking at what we have and what you have it seems to me that we could take a > subset of the basic CS101 > methods that are there and make a linux driver porter's toolkit. Yes the problem in this case is that OFED controls the code and they specifically removed a portability layer. So the portability layer is the Linux APIs they are currently using. Really in some sense it ends up being the same thing. > > things like linux style linked lists vs out queue macros can be > addressed easily, but it's just a pain in the neck to do so.. > also linux run queues and such are different but making a small > set of toolkits to do so wouldn't be a bad idea. > some of the more esoteric parts might stay with the ib code however. After this discussion I'm leaning towards leaving the layer I have in the ofed/ directory and leaving it tied to the version of ofed we currently have imported. They actually have a set of scripts to 'backport' their stack to different linux versions if we were to standardize on some older linux kernel release but I don't think it's worth the effort. I understand wanting to limit the spread of hybridized linux kernel code. It is not my first choice but comparing it with the alternative of not having some desired feature I will choose the feature. Thanks, Jeff > > > >> >> Thanks, >> Jeff >> >>> >>> >>> -- >>> Alexander Kabaev >>> >> _______________________________________________ >> 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 Wed Jan 5 01:39:32 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1192610656A4; Wed, 5 Jan 2011 01:39:32 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D76978FC19; Wed, 5 Jan 2011 01:39:31 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p051dTAH082252; Wed, 5 Jan 2011 01:39:30 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4D23CBD1.90600@freebsd.org> Date: Wed, 05 Jan 2011 09:39:29 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100630) MIME-Version: 1.0 To: Scott Long References: <85271.1294128867@critter.freebsd.dk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Poul-Henning Kamp , Alfred Perlstein , Garrett Cooper Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 01:39:32 -0000 Scott Long wrote: > On Jan 4, 2011, at 1:14 AM, Poul-Henning Kamp wrote: >> In message , Jeff Roberson writes: >> >>> Also, linux likes to change things very rapidly. Not to mention a lot of >>> their APIs go against the grain on BSD and we would not find them >>> aesthetically or architecturally pleasing. >> Absolutely. >> >> But we, as a project, must also weigh the cost of our sensibilities >> and preferences, against how much work we must expend to uphold them. >> > > I have mixed feelings about Jeff's shim layer. On the plus side, I think that there's value to emulation without copying. On the negative side, I agree with ALexander's concern that it's a large chuck of code to be maintained. Emulation isn't a bad thing. It allows IHV's as well as individual developers to take baby steps with getting familiar with FreeBSD. It lowers the barrier to entry. The ones who aren't going to put in the effort to making the leap from "emulation" to "native" likely aren't going to take the leap with going from "nothing" to "native" either. I understand the argument that it will coddle people into using just the emulation and not the native interfaces, thus degrading the value of the native interfaces. I'm just not sure how much I believe that in my experience. > > I recall years ago Matt Jacob mentioning with some concern that the project seemed to be aimed at creating a "FreeSolaris" of sorts; many of the architectural decisions seemed to be based on the argument that Solaris was doing it, so FreeBSD should too. That's fine, and there's a certain amount of comfort in following an arguably decent architectural standard like Solaris, though I understand what I believed to be Matt's point about retaining some identity and exploring new paths rather than just following old paths. > > In my not so humble opinion, Linux is not an architectural model to be envied or copied, regardless of how pragmatic it might seem. Sure, gratuitous differences can be argued against, but there are a lot of fundamental architectural things that linux succeed at purely by brute force of will, and nothing more. FreeBSD should be careful to not envy that model. I think that there's a lot less value in both the long and short terms in a "FreeLinux" than in a "FreeSolaris", and neither are all that good in the long term. > > Having an emulation gives people a lower barrier to entry and some stepping stones to getting comfortable with FreeBSD. It gives them a series of achievable goals with costs and benefits at each step that can be weighed. Aiming at simply evolving the native interfaces to be like linux simply means that FreeBSD becomes a poor copy of linux with nothing else under the surface to set it apart or create an attraction. > > Scott > Which OS can attract me ? Linux and FreeSolarisBSD all are old technology, I also have mixed feeling, I think I can not learn more from these OSes. :-) Regards, David Xu From owner-freebsd-arch@FreeBSD.ORG Wed Jan 5 09:22:35 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39EE11065674 for ; Wed, 5 Jan 2011 09:22:35 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id DF37B8FC08 for ; Wed, 5 Jan 2011 09:22:34 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3A1FD.dip.t-dialin.net [87.179.161.253]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 505FF844012; Wed, 5 Jan 2011 10:05:17 +0100 (CET) Received: from webmail.leidinger.net (unknown [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 311F7198B; Wed, 5 Jan 2011 10:05:10 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p0594rZ9061072; Wed, 5 Jan 2011 10:04:53 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 05 Jan 2011 10:04:52 +0100 Message-ID: <20110105100452.16086vb1bb08xcco@webmail.leidinger.net> Date: Wed, 05 Jan 2011 10:04:52 +0100 From: Alexander Leidinger To: Jeff Roberson References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <4D23A2CF.1010904@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 505FF844012.A3A37 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.274, required 6, autolearn=disabled, RDNS_NONE 1.27) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1294823119.04438@hn6KITv9pbtYUObhjN0nNg X-EBL-Spam-Status: No Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 09:22:35 -0000 Quoting Jeff Roberson (from Tue, 4 Jan 2011 13:13:00 -1000 (HST)): > After this discussion I'm leaning towards leaving the layer I have > in the ofed/ directory and leaving it tied to the version of ofed we > currently have imported. To give you one more little argument in favour of this: copies in SVN are cheap. If there is the need to have the compat shim available for something else, it can be put into another place later. On a somewhat related area: now that you've done this huge compat work you have a very good idea which parts correspond to what in the other OS. It would be great if this could be documented somewhere (wiki?) in a way that people which are interested to write a FreeBSD native driver just need to have a look at some pages to be able to see what linux stuff they have to change in which way to get a big part of the porting covered. IMO this would also help in reviewing and verifying the correctness of your current work (and as such would be beneficial to the sponsors of this work), as people could see if you missed some semantic differences or overlooked some implicit assumptions. Bye, Alexander. -- The Feynman Problem-Solving Algorithm: (1) write down the problem. (2) think very hard. (3) write down the answer. -- Murray Gell-Mann http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Wed Jan 5 09:56:19 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14F18106566C for ; Wed, 5 Jan 2011 09:56:19 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F3C218FC08; Wed, 5 Jan 2011 09:56:18 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p059uHNJ050039; Wed, 5 Jan 2011 09:56:18 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4D244042.4010004@freebsd.org> Date: Wed, 05 Jan 2011 17:56:18 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100630) MIME-Version: 1.0 To: Alexander Leidinger References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <4D23A2CF.1010904@freebsd.org> <20110105100452.16086vb1bb08xcco@webmail.leidinger.net> In-Reply-To: <20110105100452.16086vb1bb08xcco@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 09:56:19 -0000 Alexander Leidinger wrote: > Quoting Jeff Roberson (from Tue, 4 Jan 2011 > 13:13:00 -1000 (HST)): > >> After this discussion I'm leaning towards leaving the layer I have in >> the ofed/ directory and leaving it tied to the version of ofed we >> currently have imported. > > To give you one more little argument in favour of this: copies in SVN > are cheap. If there is the need to have the compat shim available for > something else, it can be put into another place later. > > On a somewhat related area: now that you've done this huge compat work > you have a very good idea which parts correspond to what in the other > OS. It would be great if this could be documented somewhere (wiki?) in a > way that people which are interested to write a FreeBSD native driver > just need to have a look at some pages to be able to see what linux > stuff they have to change in which way to get a big part of the porting > covered. IMO this would also help in reviewing and verifying the > correctness of your current work (and as such would be beneficial to the > sponsors of this work), as people could see if you missed some semantic > differences or overlooked some implicit assumptions. > > Bye, > Alexander. > This is still uncertain, the patch is so large, I don't know who will review it, the person who has ability to review it must know Linux locking and OFED very well ? plus few of us are using OFED. Just like my process shared pthread mutex project, few of us are using the pshared mutex, so it seems nobody wants to make a comment. From owner-freebsd-arch@FreeBSD.ORG Wed Jan 5 10:18:24 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE4E3106566C for ; Wed, 5 Jan 2011 10:18:24 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 4F9488FC0C for ; Wed, 5 Jan 2011 10:18:24 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3A1FD.dip.t-dialin.net [87.179.161.253]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id F113E844012; Wed, 5 Jan 2011 11:18:19 +0100 (CET) Received: from webmail.leidinger.net (unknown [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 829E41993; Wed, 5 Jan 2011 11:18:13 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p05AHvwA099090; Wed, 5 Jan 2011 11:17:57 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 05 Jan 2011 11:17:57 +0100 Message-ID: <20110105111757.71361dh7p5bqyhy8@webmail.leidinger.net> Date: Wed, 05 Jan 2011 11:17:57 +0100 From: Alexander Leidinger To: David Xu References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <4D23A2CF.1010904@freebsd.org> <20110105100452.16086vb1bb08xcco@webmail.leidinger.net> <4D244042.4010004@freebsd.org> In-Reply-To: <4D244042.4010004@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: F113E844012.A5B97 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.274, required 6, autolearn=disabled, RDNS_NONE 1.27) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1294827500.70349@PP4FyZT/nQl8dVsrr4WvpQ X-EBL-Spam-Status: No Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 10:18:25 -0000 Quoting David Xu (from Wed, 05 Jan 2011 17:56:18 +0800): > Alexander Leidinger wrote: >> Quoting Jeff Roberson (from Tue, 4 Jan >> 2011 13:13:00 -1000 (HST)): >> >>> After this discussion I'm leaning towards leaving the layer I have >>> in the ofed/ directory and leaving it tied to the version of ofed >>> we currently have imported. >> >> To give you one more little argument in favour of this: copies in >> SVN are cheap. If there is the need to have the compat shim >> available for something else, it can be put into another place later. >> >> On a somewhat related area: now that you've done this huge compat >> work you have a very good idea which parts correspond to what in >> the other OS. It would be great if this could be documented >> somewhere (wiki?) in a way that people which are interested to >> write a FreeBSD native driver just need to have a look at some >> pages to be able to see what linux stuff they have to change in >> which way to get a big part of the porting covered. IMO this would >> also help in reviewing and verifying the correctness of your >> current work (and as such would be beneficial to the sponsors of >> this work), as people could see if you missed some semantic >> differences or overlooked some implicit assumptions. > This is still uncertain, the patch is so large, I don't know who will > review it, the person who has ability to review it must know Linux > locking and OFED very well ? plus few of us are using OFED. I do not think that people do need to know both at the same. I think the most critical part in the review is the linux compat shim. The pure OFED part is shared with Linux. Currently one needs to know both worlds (Linux + FreeBSD) to review it. If there is some good documentation, this can be split up into two parts. One part for people with good linux knowledge to check if the description in the docs is OK (semantic, invariants, assumptions, ...) and one part for people with good FreeBSD knowledge to check if the FreeBSD part is implementing what is described. Bye, Alexander. -- One can't proceed from the informal to the formal by formal means. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Wed Jan 5 14:56:58 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22583106566B; Wed, 5 Jan 2011 14:56:58 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id DCFF98FC24; Wed, 5 Jan 2011 14:56:57 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 535D258133; Wed, 5 Jan 2011 08:56:57 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id Im5vfXo9rHHS; Wed, 5 Jan 2011 08:56:57 -0600 (CST) Received: from comporellon.tachypleus.net (unknown [76.210.75.5]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 0D9585811E; Wed, 5 Jan 2011 08:56:55 -0600 (CST) Message-ID: <4D2486B7.2040305@freebsd.org> Date: Wed, 05 Jan 2011 08:56:55 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101214 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Hixson References: <4D20C8BF.701@freebsd.org> <29AA82C4-6301-4DCD-BC9D-423AD162998E@gmail.com> <4D20DDE4.8080306@freebsd.org> <4D22D30A.2050606@executive-computing.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Garrett Cooper , Bruce Cran , john@ixsystems.com, freebsd-arch@freebsd.org, Marco Steinbach , matt@ixsystems.com, freebsd-sysinstall@freebsd.org Subject: Re: BSDInstall: I want the bikeshed painted plaid X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 14:56:58 -0000 On 01/04/11 15:25, John Hixson wrote: > > > On Mon, Jan 3, 2011 at 11:58 PM, Marco Steinbach > > wrote: > > John Hixson wrote on 02.01.2011 22:51: > > On Sun, Jan 2, 2011 at 12:19 PM, Nathan Whitehorn > >wrote: > > I spent a bunch of time looking at pc-sysinstall before > starting to work on > this. The major problem for non-x86 systems is that it > heavily assumes that > your disks are either MBR+bsdlabel or GPT. If you have > anything different > (APM, VTOC8, or even a raw bsdlabel or MBR installation on > x86), it breaks > in strange and fascinating ways due to a random mixture of > if (scheme == > MBR) else and if (scheme == GPT) else in the backend. Some > of these are > easily fixed, but it looked quite difficult to root out > all of the places > this assumption is made, not to mention teaching it about > various styles of > boot code, that the same partitioning scheme may need to > be set up different > ways on different architectures, etc. txt-sysinstall also > segfaults when you > try to run it on powerpc at the moment, though that is > likely a simple bug > and I didn't look into it in detail. > > What I intended with bsdinstall is to have something > simple, flexible, and > easily maintained that works immediately on all platforms > and will be ready > for 9.0 for sure. If pc-sysinstall materializes before > then, or after then, > and people like it better, I'm more than happy to get out > of the way; this > is the reason the wiki page is titled "Stopgap Installer". > In the interim, I > hoped to at least start laying out the hammer and nails > next to sysinstall's > coffin. > -Nathan > > > I would be more than happy to help out with making > pc-sysinstall work on > non-x86 systems, however I don't have access to any. Do any of > you have > hardware that could possibly be used by interested parties? > I'm sure all the > work that's gone into bsdinstall could be used in > pc-sysinstall or vice > versa. > > > I have PowerMacs (G3/G4) and Netras/Ultras (T1 105, U10, U5) at my > discretion. I've never installed FreeBSD on any of them, but > would be willing to give it a shot. > > I can provide serial console access to the Sparcs, but the > PowerMacs supposedly need "hands on", which I can also provide. > > If there's interest, I humbly suggest discussing further details > on the course of action at sysinstall@, to which I just subscribed. > > > I just subscribed to sysinstall@. I'd be happy to help starting out on > the sparcs. I have no experience whatsoever on powermac, but it sounds > fun ;-). > You can look in bsdinstall's partedit/partedit_${MACHINE}.c for how various platforms need to be set up. APM on PPC is very similar to GPT, and VTOC8 is a little bit of an oddball scheme because UFS partitions need partcode on them. Bear in mind that PPC will very soon support non-powermac platforms, so please avoid hardcoding any assumptions about what "powerpc" requires. Similarly, several partition types (MBR, GPT) require different setup on different platforms. -Nathan From owner-freebsd-arch@FreeBSD.ORG Wed Jan 5 17:40:56 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D04C106566B for ; Wed, 5 Jan 2011 17:40:56 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id ED10A8FC23 for ; Wed, 5 Jan 2011 17:40:55 +0000 (UTC) Received: by vws9 with SMTP id 9so6409804vws.13 for ; Wed, 05 Jan 2011 09:40:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=VzcBVaY/vlG+59TCmMg5oZcSTzPyI9vpkYEkW5qSn2I=; b=PQ5bR7N2MUuM/oVvIuDODHs99TkC+DUUdCZXZJMHCuKdLqmTqHrMuosd8K7r94xR0/ rywD1+rBkFTPfxVwz64Ng/+V5XPJHnrwaKaTiQvWA+hlDPz/DbqRt/Nk1bghzZYPiKaE d1fJ63WKcr+t2hYPYhhrGL+frr1t820VBXTZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=jfXTorOihgm+WgWhwFtK2nByARWioVoOGojm0hv8vzWeko9IYbHd8+ocivu+MZHZ5T CSwqI2lGc2g/yeqQs9e95zAOpBJmaWJ3qwdeD9qZxqq2r1SN16+11HPD5mQbG3vzQvEV FeDYWIcI7P52kJaXUtmcWdtTfYnsfekY/Atow= Received: by 10.220.203.140 with SMTP id fi12mr7268223vcb.168.1294249255009; Wed, 05 Jan 2011 09:40:55 -0800 (PST) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id k39sm4976874vcr.26.2011.01.05.09.40.51 (version=SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 09:40:52 -0800 (PST) Date: Wed, 5 Jan 2011 12:40:45 -0500 From: Alexander Kabaev To: Jeff Roberson Message-ID: <20110105124045.6a0ddd1a@kan.dnsalias.net> In-Reply-To: References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/6unfE.pUuvCHovK6j4HUKv6"; protocol="application/pgp-signature" Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 17:40:56 -0000 --Sig_/6unfE.pUuvCHovK6j4HUKv6 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 4 Jan 2011 10:53:30 -1000 (HST) Jeff Roberson wrote: > On Tue, 4 Jan 2011, Alexander Kabaev wrote: >=20 > > On Mon, 3 Jan 2011 19:03:01 -1000 (HST) > > Jeff Roberson wrote: > >>> > >>> This probably will go against popular opinion here, but having 10k > >>> linux emulation layer that _almost_ work in the tree will be an > >>> unfortunate event and will do more damage to FreeBSD as a platform > >>> than good in the long run. I would rather see this code never hit > >>> main repository. > >> > >> I would argue that the layer works very well for infiniband. Much > >> better than almost. It is only almost complete in that there is no > >> need for me to implement features that we're not using. > >> > >> I am interested in hearing your other concerns however. > >> > >> Thanks, > >> Jeff > >> > > >=20 > Alexander, let me first start out by saying I have a great deal of > respect for you and I hear your concerns. I see that this is a > somewhat heated issue and I can really only address the technical > points. The more existential questions about FreeBSD will have to be > left to others. >=20 Well, my objection was leaning more on the existential side of the argument rather than technical point. I will be the last person out there doubting that you will get all the technically challenges right. > > The considerations are simple enough. First, we do not have many IB > > users of FreeBSD in the wild and those that we have (Isilon) seem > > to be perfectly capable of managing the IB stack out of the tree, > > without dumping the thousands of lines of the code into the base. > > If they had the stack before, but were not willing/capable to > > provide adequate care for it in the past, there is no reason to > > expect things to change with second stack, which now will rot in > > our tree instead of theirs. >=20 > They provided adequate care for it to keep their product running on > old versions of FreeBSD. Unfortunately it is a large stack and there > are a great number of people and organizations working on improving > and advancing it on Linux via OFED and having a private stack does > not give you the benefit of their work. The motivation for making > the wrapper layer was entirely to keep pace with this development and > make it less likely that what is in the tree will rot. I fail to see what having the code in the tree is set to achieve. If we have hordes of potential customers waiting for Infiniband drivers to hit the tree, they kept surprisingly low profile to date. All ten of them. You said so yourself, the codebase is HUGE and who is going to feed and care for it once your relationship to this work is over? None of our big customers do really care about ongoing FreeBSD development in -current and instead center their interest around specific version of stable they happen to base their products on. I do not see that changing. We have much less complicated pieces of software in the tree that are used by many, many more people than Infiniband ever will and yet their development has stagnated in the absence of active maintainer (smbfs *cough*). With Infiniband, where minuscule percentage of FreeBSD developers have access to the hardware and specs the rot is not only likely possibility, but guaranteed certainty. > > > > Second, semi-complete Linux compat layer in kernel will have the > > same effect as linuxulator in userland - we do have some vendors > > still trying to bother with FreeBSD drivers for their hardware now > > and we will have none after we provide the possibility to hack > > their Linux code to run somewhat stably on top of Linux compat > > layer. Due to intentional fluidity of Linux kAPI, our shims will > > never quite walk and quack like their original implementation in > > Linux kernel and combined result will always be lees stable than > > native Linux linux drivers in Linux kernel. >=20 > I have heard this argument about the linuxulator and what we're > really talking about is slipping FreeBSD marketshare. I don't share > the view that the linuxulator futhered this slip but rather my view > is that it allows us to stay relevant in areas where companies can > not justify an independent FreeBSD effort. Adobe is a good example > of this. >=20 It compounded the Adobe's reluctance to work on portable flash player. > Let's talk nuts and bolts about what this thing does. In the vast=20 > majority of cases it simply shuffles arguments and function names > around where there is a 1:1 correlation between linux api and FreeBSD > API. Think about things like atomics, callouts, locks, jiffies vs > ticks, etc. In these areas the systems are trivially different. In > a very small number of areas where this wasn't the case I did a > direct port and noted it with an #ifdef. There are also less beautiful things like struct task in td_retval[1], etc. The layer does look complete enough to compel device writers to start relying on ii. But it is written to cover OFED needs only, so any other work will likely require extending your wrapper some more again and again. Before you know it we are in an arms race against Linux kernel which we cannot win. > This works specifically in the infiniband case because it is its own=20 > middle layer. You can't write a scsi driver for linux and use it on > BSD with this. You can't write a network driver even. But if you do > bring in code from linux you don't have to worry about changing every > kmalloc to malloc and every printk to printf so diffs can be reduced > in trivial cases. I thought given your work on XFS for FreeBSD that > would make sense to you. Well, XFS I worked on had clear separation on OS-specific and core parts with minor incursions of linuxisms in core. This probably has changed with SGI demise and consequent death of Irix. > Our options are, to leave FreeBSD users without infiniband, which I > can tell you has cost us more market share as I know of specific > cases we have lost due to it. To maintain our own stack > independently, which no one has the budget for. Or to try to > integrate with OFED. Do you see some other approach? Maintain OFED-compatible stack out of the tree. Make it downloadable in source form to anyone who cares, there won't be many in absolute numbers. NVidia has managed this + complication of binary blob, multiple commercial vendors on Linux have managed this and if parties interested in Infiniband on FreeBSD can not, what makes anyone think that driver in the tree will fare any better than shared stack maintained elsewhere? --=20 Alexander Kabaev --Sig_/6unfE.pUuvCHovK6j4HUKv6 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iD8DBQFNJK0iQ6z1jMm+XZYRAqEqAKDoPgc6CSXmic5Yzley4+kAgcG3BwCfTJ1E dzW5IzHilj0+4f5gUpwzrTE= =O1sK -----END PGP SIGNATURE----- --Sig_/6unfE.pUuvCHovK6j4HUKv6-- From owner-freebsd-arch@FreeBSD.ORG Wed Jan 5 18:19:24 2011 Return-Path: Delivered-To: arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1360B1065672 for ; Wed, 5 Jan 2011 18:19:24 +0000 (UTC) (envelope-from ache@vniz.net) Received: from vniz.net (vniz.net [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 5CDBA8FC15 for ; Wed, 5 Jan 2011 18:19:22 +0000 (UTC) Received: from vniz.net (localhost [127.0.0.1]) by vniz.net (8.14.4/8.14.4) with ESMTP id p05HxQaR002209; Wed, 5 Jan 2011 20:59:26 +0300 (MSK) (envelope-from ache@vniz.net) Received: (from ache@localhost) by vniz.net (8.14.4/8.14.4/Submit) id p05HxQGi002208; Wed, 5 Jan 2011 20:59:26 +0300 (MSK) (envelope-from ache) Date: Wed, 5 Jan 2011 20:59:26 +0300 From: Andrey Chernov To: Alexander Kabaev Message-ID: <20110105175926.GA2101@vniz.net> References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <20110105124045.6a0ddd1a@kan.dnsalias.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@FreeBSD.ORG Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 18:19:24 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 05, 2011 at 12:40:45PM -0500, Alexander Kabaev wrote: > > I have heard this argument about the linuxulator and what we're > > really talking about is slipping FreeBSD marketshare. I don't share > > the view that the linuxulator futhered this slip but rather my view > > is that it allows us to stay relevant in areas where companies can > > not justify an independent FreeBSD effort. Adobe is a good example > > of this. > >=20 >=20 > It compounded the Adobe's reluctance to work on portable flash player. I agree with Alexander even more. We don't need _any_ Linux emulator in=20 the tree and even in the ports. Flash player is a good example of how=20 Linux emulator is harmful: instead of sending tons of complaints to Adobe= =20 to force them to make native FreeBSD version, users tends to install Flash= =20 via emulator and got all its pain as result.=20 BTW, I have nothing against having source level Linux compatibility in=20 some places, because resulting binary will be FreeBSD one in any case, but= =20 I'm strongly against executable binary compatibility level.=20 --=20 http://ache.vniz.net/ --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAk0ksX0ACgkQVg5YK5ZEdN2pEACcCdBV/hF5+ce8awcaA40s2qCA 0RAAn3S9ZsQAxxAyW+cZv6H0sr3c85Ne =vDbs -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- From owner-freebsd-arch@FreeBSD.ORG Wed Jan 5 21:35:21 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82C4D10656BA; Wed, 5 Jan 2011 21:35:21 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1B8948FC21; Wed, 5 Jan 2011 21:35:20 +0000 (UTC) Received: by qyk36 with SMTP id 36so15346076qyk.13 for ; Wed, 05 Jan 2011 13:35:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.45.132 with SMTP id e4mr21622754qaf.296.1294261779449; Wed, 05 Jan 2011 13:09:39 -0800 (PST) Received: by 10.220.188.68 with HTTP; Wed, 5 Jan 2011 13:09:39 -0800 (PST) In-Reply-To: <20110105175926.GA2101@vniz.net> References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> Date: Wed, 5 Jan 2011 13:09:39 -0800 Message-ID: From: Peter Wemm To: Andrey Chernov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 21:35:21 -0000 On Wed, Jan 5, 2011 at 9:59 AM, Andrey Chernov wrote: > On Wed, Jan 05, 2011 at 12:40:45PM -0500, Alexander Kabaev wrote: >> > I have heard this argument about the linuxulator and what we're >> > really talking about is slipping FreeBSD marketshare. =A0I don't share >> > the view that the linuxulator futhered this slip but rather my view >> > is that it allows us to stay relevant in areas where companies can >> > not justify an independent FreeBSD effort. =A0Adobe is a good example >> > of this. >> > >> >> It compounded the Adobe's reluctance to work on portable flash player. > > I agree with Alexander even more. We don't need _any_ Linux emulator in > the tree and even in the ports. Flash player is a good example of how > Linux emulator is harmful: instead of sending tons of complaints to Adobe > to force them to make native FreeBSD version, users tends to install Flas= h > via emulator and got all its pain as result. > > BTW, I have nothing against having source level Linux compatibility in > some places, because resulting binary will be FreeBSD one in any case, bu= t > I'm strongly against executable binary compatibility level. There's also the issue of the Linux folks using the API's as a political tool. The whole selective API exporting based on GPL status etc is a whole can of worms. I believe I've even read that they consider merely using non-blessed APIs causes your code to be a derivative of their GPL'ed code. Thought should be considered for their reactions to us implementing an API that they consider consumers of to be automatically become GPL'ed. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Wed Jan 5 21:42:30 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD5F1106566B for ; Wed, 5 Jan 2011 21:42:30 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id A3BF68FC13 for ; Wed, 5 Jan 2011 21:42:30 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.4/8.14.3) with ESMTP id p05LgKmh027885 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 5 Jan 2011 13:42:29 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4D24E5B6.8060904@feral.com> Date: Wed, 05 Jan 2011 13:42:14 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Wed, 05 Jan 2011 13:42:30 -0800 (PST) Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 21:42:30 -0000 >> >> BTW, I have nothing against having source level Linux compatibility in >> some places, because resulting binary will be FreeBSD one in any case, but >> I'm strongly against executable binary compatibility level. > Hmm. Well, that's a non-starter. Storage vendors provide tools for Linux and Windows. That's it. Those tools have to be used on FreeBSD. Therefore, binary execution of such tools, and the infrastructure to support that, is pretty much mandatory. From owner-freebsd-arch@FreeBSD.ORG Wed Jan 5 21:46:11 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75C911065765; Wed, 5 Jan 2011 21:46:10 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 922318FC1B; Wed, 5 Jan 2011 21:46:09 +0000 (UTC) Received: by wyf19 with SMTP id 19so15937045wyf.13 for ; Wed, 05 Jan 2011 13:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=D8b06ZwAHszKe7obp+yO8G3wSYlpfh/Zwr2QnzTtqFo=; b=jF46Gs0IO32v2U8tgqAOxVtqCcOVkOWjDm4lzX79zgp7aCqaal9Sa97P4Ft7wQf7Gx VH/TYDNVhsnp1CrIVguiRz8E16VyqRarmhFuBvbdmSnTRIiW6O7c8LsDhycbu1hlq8I4 yr4IvWzPHBli3ODMdkqMARkb29GuiQ6hqQxAE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=deDdO3ON+LEnKm2qZZBtPfA7GlMfZa11u2JFX3cbpUW1JR++V6zneYqlIY9Q+8ymXL vtv5aqh+eruxN0mziXngec3ce1MB5/M/pidBhYHX67VOztxkrle8hIdpAkPvQNwvL4qW CekbQQpSLIuPbBwO1074s+D+YUMBdcoKVKADY= MIME-Version: 1.0 Received: by 10.216.185.142 with SMTP id u14mr553wem.31.1294263968594; Wed, 05 Jan 2011 13:46:08 -0800 (PST) Received: by 10.216.254.226 with HTTP; Wed, 5 Jan 2011 13:46:08 -0800 (PST) In-Reply-To: References: <4D20C8BF.701@freebsd.org> <29AA82C4-6301-4DCD-BC9D-423AD162998E@gmail.com> <4D20DDE4.8080306@freebsd.org> <4D22D30A.2050606@executive-computing.de> Date: Wed, 5 Jan 2011 13:46:08 -0800 Message-ID: From: Garrett Cooper To: John Hixson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , john@ixsystems.com, Nathan Whitehorn , freebsd-arch@freebsd.org, Marco Steinbach , matt@ixsystems.com, freebsd-sysinstall@freebsd.org Subject: Re: BSDInstall: I want the bikeshed painted plaid X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 21:46:11 -0000 On Tue, Jan 4, 2011 at 1:25 PM, John Hixson wrote: > > > On Mon, Jan 3, 2011 at 11:58 PM, Marco Steinbach > wrote: >> >> John Hixson wrote on 02.01.2011 22:51: >>> >>> On Sun, Jan 2, 2011 at 12:19 PM, Nathan Whitehorn >>> wrote: >>> >>>> I spent a bunch of time looking at pc-sysinstall before starting to wo= rk >>>> on >>>> this. The major problem for non-x86 systems is that it heavily assumes >>>> that >>>> your disks are either MBR+bsdlabel or GPT. If you have anything >>>> different >>>> (APM, VTOC8, or even a raw bsdlabel or MBR installation on x86), it >>>> breaks >>>> in strange and fascinating ways due to a random mixture of if (scheme = =3D=3D >>>> MBR) else and if (scheme =3D=3D GPT) else in the backend. Some of thes= e are >>>> easily fixed, but it looked quite difficult to root out all of the >>>> places >>>> this assumption is made, not to mention teaching it about various styl= es >>>> of >>>> boot code, that the same partitioning scheme may need to be set up >>>> different >>>> ways on different architectures, etc. txt-sysinstall also segfaults wh= en >>>> you >>>> try to run it on powerpc at the moment, though that is likely a simple >>>> bug >>>> and I didn't look into it in detail. >>>> >>>> What I intended with bsdinstall is to have something simple, flexible, >>>> and >>>> easily maintained that works immediately on all platforms and will be >>>> ready >>>> for 9.0 for sure. If pc-sysinstall materializes before then, or after >>>> then, >>>> and people like it better, I'm more than happy to get out of the way; >>>> this >>>> is the reason the wiki page is titled "Stopgap Installer". In the >>>> interim, I >>>> hoped to at least start laying out the hammer and nails next to >>>> sysinstall's >>>> coffin. >>>> -Nathan >>>> >>>> >>> I would be more than happy to help out with making pc-sysinstall work o= n >>> non-x86 systems, however I don't have access to any. Do any of you have >>> hardware that could possibly be used by interested parties? I'm sure al= l >>> the >>> work that's gone into bsdinstall could be used in pc-sysinstall or vice >>> versa. >> >> I have PowerMacs (G3/G4) and Netras/Ultras (T1 105, U10, U5) at my >> discretion. =A0I've never installed FreeBSD on any of them, but would be >> willing to give it a shot. >> >> I can provide serial console access to the Sparcs, but the PowerMacs >> supposedly need "hands on", which I can also provide. >> >> If there's interest, I humbly suggest discussing further details on the >> course of action at sysinstall@, to which I just subscribed. >> > > I just subscribed to sysinstall@. I'd be happy to help starting out on th= e > sparcs. I have no experience whatsoever on powermac, but it sounds fun ;-= ). PowerPC macs aren't that hard because the `newer' ones run openfirmware like sparcs. Some of the hardware is different and more `interesting', but that shouldn't deter anyone from making progress on a Mac with netboot images (it's one-time setup in openfirmware if done properly and pretty trivial at that). Lemme know if you need help with this offline and I'll see what I can do. Cheers, -Garrett From owner-freebsd-arch@FreeBSD.ORG Wed Jan 5 21:47:31 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45AB7106566B; Wed, 5 Jan 2011 21:47:31 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 469818FC1A; Wed, 5 Jan 2011 21:47:30 +0000 (UTC) Received: by wyf19 with SMTP id 19so15938100wyf.13 for ; Wed, 05 Jan 2011 13:47:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=we9lN5IifnO+rQBHV7LLtl0GCPArCQwO9YoVVYn4mGI=; b=J7gWuFlXIbX6uXjBEhbefIUPdh4OYZW7d/tiLM8IwWUYjgrbmR9HuUU0r1utWzuJOF eUZQymEcBPoCyQPP2MJghcCD34M3hzON//FPvFDcHoEm9GbfNdxGW/hbBOwi33hS9WZC IWWWwIlRMSSGh8POSSogKKcOxn8GTtfmw8470= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mk6tdVcWFb91uOdaza9lphpmuVJGuL3vhUB98MEd4F2oO4XwU6GVXd6LMdki0svQ0L ag1rix90kP+gHKWllJs7wQwELtZOkZJ7HvtJXb9ZNbYKhdL8tus4wq5YmRlAw+pOKzHI A6azS/MYwNlaPd4/FuJW+4kE9OAxYz3cXxoIA= MIME-Version: 1.0 Received: by 10.216.141.37 with SMTP id f37mr8795891wej.31.1294264049469; Wed, 05 Jan 2011 13:47:29 -0800 (PST) Received: by 10.216.254.226 with HTTP; Wed, 5 Jan 2011 13:47:29 -0800 (PST) In-Reply-To: <4D2486B7.2040305@freebsd.org> References: <4D20C8BF.701@freebsd.org> <29AA82C4-6301-4DCD-BC9D-423AD162998E@gmail.com> <4D20DDE4.8080306@freebsd.org> <4D22D30A.2050606@executive-computing.de> <4D2486B7.2040305@freebsd.org> Date: Wed, 5 Jan 2011 13:47:29 -0800 Message-ID: From: Garrett Cooper To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: John Hixson , Bruce Cran , john@ixsystems.com, freebsd-arch@freebsd.org, Marco Steinbach , matt@ixsystems.com, freebsd-sysinstall@freebsd.org Subject: Re: BSDInstall: I want the bikeshed painted plaid X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 21:47:31 -0000 On Wed, Jan 5, 2011 at 6:56 AM, Nathan Whitehorn w= rote: > On 01/04/11 15:25, John Hixson wrote: > > On Mon, Jan 3, 2011 at 11:58 PM, Marco Steinbach > wrote: >> >> John Hixson wrote on 02.01.2011 22:51: >>> >>> On Sun, Jan 2, 2011 at 12:19 PM, Nathan Whitehorn >>> wrote: >>> >>>> I spent a bunch of time looking at pc-sysinstall before starting to wo= rk >>>> on >>>> this. The major problem for non-x86 systems is that it heavily assumes >>>> that >>>> your disks are either MBR+bsdlabel or GPT. If you have anything >>>> different >>>> (APM, VTOC8, or even a raw bsdlabel or MBR installation on x86), it >>>> breaks >>>> in strange and fascinating ways due to a random mixture of if (scheme = =3D=3D >>>> MBR) else and if (scheme =3D=3D GPT) else in the backend. Some of thes= e are >>>> easily fixed, but it looked quite difficult to root out all of the >>>> places >>>> this assumption is made, not to mention teaching it about various styl= es >>>> of >>>> boot code, that the same partitioning scheme may need to be set up >>>> different >>>> ways on different architectures, etc. txt-sysinstall also segfaults wh= en >>>> you >>>> try to run it on powerpc at the moment, though that is likely a simple >>>> bug >>>> and I didn't look into it in detail. >>>> >>>> What I intended with bsdinstall is to have something simple, flexible, >>>> and >>>> easily maintained that works immediately on all platforms and will be >>>> ready >>>> for 9.0 for sure. If pc-sysinstall materializes before then, or after >>>> then, >>>> and people like it better, I'm more than happy to get out of the way; >>>> this >>>> is the reason the wiki page is titled "Stopgap Installer". In the >>>> interim, I >>>> hoped to at least start laying out the hammer and nails next to >>>> sysinstall's >>>> coffin. >>>> -Nathan >>>> >>>> >>> I would be more than happy to help out with making pc-sysinstall work o= n >>> non-x86 systems, however I don't have access to any. Do any of you have >>> hardware that could possibly be used by interested parties? I'm sure al= l >>> the >>> work that's gone into bsdinstall could be used in pc-sysinstall or vice >>> versa. >> >> I have PowerMacs (G3/G4) and Netras/Ultras (T1 105, U10, U5) at my >> discretion. =A0I've never installed FreeBSD on any of them, but would be >> willing to give it a shot. >> >> I can provide serial console access to the Sparcs, but the PowerMacs >> supposedly need "hands on", which I can also provide. >> >> If there's interest, I humbly suggest discussing further details on the >> course of action at sysinstall@, to which I just subscribed. >> > > I just subscribed to sysinstall@. I'd be happy to help starting out on th= e > sparcs. I have no experience whatsoever on powermac, but it sounds fun ;-= ). > > > You can look in bsdinstall's partedit/partedit_${MACHINE}.c for how vario= us > platforms need to be set up. APM on PPC is very similar to GPT, and VTOC8= is > a little bit of an oddball scheme because UFS partitions need partcode on > them. Bear in mind that PPC will very soon support non-powermac platforms= , > so please avoid hardcoding any assumptions about what "powerpc" requires. > Similarly, several partition types (MBR, GPT) require different setup on > different platforms. /me is itching to see some Freescale and PS3 action... maybe Xbox 360 sometime in the future :)? Thanks :P... -Garrett From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 00:11:39 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38F5E106566C for ; Thu, 6 Jan 2011 00:11:39 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id EAECB8FC13 for ; Thu, 6 Jan 2011 00:11:38 +0000 (UTC) Received: by vws9 with SMTP id 9so6535760vws.13 for ; Wed, 05 Jan 2011 16:11:38 -0800 (PST) Received: by 10.220.83.196 with SMTP id g4mr6596114vcl.247.1294272696354; Wed, 05 Jan 2011 16:11:36 -0800 (PST) Received: from [10.0.1.198] ([72.253.42.56]) by mx.google.com with ESMTPS id d14sm5155363vcx.47.2011.01.05.16.11.33 (version=SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 16:11:35 -0800 (PST) Date: Wed, 5 Jan 2011 14:14:15 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Andrey Chernov In-Reply-To: <20110105175926.GA2101@vniz.net> Message-ID: References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.ORG Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 00:11:39 -0000 On Wed, 5 Jan 2011, Andrey Chernov wrote: > On Wed, Jan 05, 2011 at 12:40:45PM -0500, Alexander Kabaev wrote: >>> I have heard this argument about the linuxulator and what we're >>> really talking about is slipping FreeBSD marketshare. I don't share >>> the view that the linuxulator futhered this slip but rather my view >>> is that it allows us to stay relevant in areas where companies can >>> not justify an independent FreeBSD effort. Adobe is a good example >>> of this. >>> >> >> It compounded the Adobe's reluctance to work on portable flash player. > > I agree with Alexander even more. We don't need _any_ Linux emulator in > the tree and even in the ports. Flash player is a good example of how > Linux emulator is harmful: instead of sending tons of complaints to Adobe > to force them to make native FreeBSD version, users tends to install Flash > via emulator and got all its pain as result. There are not enough freebsd desktop users to justify the effort even if everyone of them sent an email in. I once offered to port recent vmware to BSD for free and they turned me down because they didn't want to deal with it. We have not been marginalized in this space because we have an emulator. We just don't have the marketshare in many areas. If anything, these emulators improve our marketshare. Thanks, Jeff > > BTW, I have nothing against having source level Linux compatibility in > some places, because resulting binary will be FreeBSD one in any case, but > I'm strongly against executable binary compatibility level. > > -- > http://ache.vniz.net/ > From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 00:17:24 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E581D106564A for ; Thu, 6 Jan 2011 00:17:24 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 85F568FC1C for ; Thu, 6 Jan 2011 00:17:24 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id p060HLNG085594; Wed, 5 Jan 2011 17:17:21 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: Date: Wed, 5 Jan 2011 17:17:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> To: Jeff Roberson X-Mailer: Apple Mail (2.1082) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 00:17:25 -0000 On Jan 5, 2011, at 5:14 PM, Jeff Roberson wrote: > On Wed, 5 Jan 2011, Andrey Chernov wrote: >=20 >> On Wed, Jan 05, 2011 at 12:40:45PM -0500, Alexander Kabaev wrote: >>>> I have heard this argument about the linuxulator and what we're >>>> really talking about is slipping FreeBSD marketshare. I don't = share >>>> the view that the linuxulator futhered this slip but rather my view >>>> is that it allows us to stay relevant in areas where companies can >>>> not justify an independent FreeBSD effort. Adobe is a good example >>>> of this. >>>>=20 >>>=20 >>> It compounded the Adobe's reluctance to work on portable flash = player. >>=20 >> I agree with Alexander even more. We don't need _any_ Linux emulator = in >> the tree and even in the ports. Flash player is a good example of how >> Linux emulator is harmful: instead of sending tons of complaints to = Adobe >> to force them to make native FreeBSD version, users tends to install = Flash >> via emulator and got all its pain as result. >=20 > There are not enough freebsd desktop users to justify the effort even = if everyone of them sent an email in. >=20 > I once offered to port recent vmware to BSD for free and they turned = me down because they didn't want to deal with it. >=20 > We have not been marginalized in this space because we have an = emulator. We just don't have the marketshare in many areas. If = anything, these emulators improve our marketshare. I agree entirely. Companies look at marketshare and ability to turn = more revenue than costs (i.e. profit). Like Jeff, I've had my share of = dealing with companies who have made a conscious to support or not = support FreeBSD based on those factors. Petitions and letters sound = great on Slashdot, but don't work in the real world. Emulation = increases marketshare. Scott From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 02:44:09 2011 Return-Path: Delivered-To: arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72BD0106566C for ; Thu, 6 Jan 2011 02:44:09 +0000 (UTC) (envelope-from ache@vniz.net) Received: from vniz.net (vniz.net [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id E86F08FC19 for ; Thu, 6 Jan 2011 02:44:07 +0000 (UTC) Received: from vniz.net (localhost [127.0.0.1]) by vniz.net (8.14.4/8.14.4) with ESMTP id p062i6nB023032; Thu, 6 Jan 2011 05:44:06 +0300 (MSK) (envelope-from ache@vniz.net) Received: (from ache@localhost) by vniz.net (8.14.4/8.14.4/Submit) id p062i40v023031; Thu, 6 Jan 2011 05:44:04 +0300 (MSK) (envelope-from ache) Date: Thu, 6 Jan 2011 05:44:04 +0300 From: Andrey Chernov To: Scott Long Message-ID: <20110106024403.GB22349@vniz.net> References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@FreeBSD.ORG Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 02:44:09 -0000 On Wed, Jan 05, 2011 at 05:17:21PM -0700, Scott Long wrote: > > We have not been marginalized in this space because we have an emulator. We just don't have the marketshare in many areas. If anything, these emulators improve our marketshare. > > I agree entirely. Companies look at marketshare and ability to turn more revenue than costs (i.e. profit). Like Jeff, I've had my share of dealing with companies who have made a conscious to support or not support FreeBSD based on those factors. Petitions and letters sound great on Slashdot, but don't work in the real world. Emulation increases marketshare. Emulation decreases our marketshare, presenting us like not-so-good-but-trying Linux clone, so, for this reason alone, every serious company will put its money on Linux product running on real Linux instead of thinking about porting it into FreeBSD. -- http://ache.vniz.net/ From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 02:49:29 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 198811065672 for ; Thu, 6 Jan 2011 02:49:29 +0000 (UTC) (envelope-from ache@vniz.net) Received: from vniz.net (vniz.net [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 892378FC16 for ; Thu, 6 Jan 2011 02:49:28 +0000 (UTC) Received: from vniz.net (localhost [127.0.0.1]) by vniz.net (8.14.4/8.14.4) with ESMTP id p062UFwq022929; Thu, 6 Jan 2011 05:30:15 +0300 (MSK) (envelope-from ache@vniz.net) Received: (from ache@localhost) by vniz.net (8.14.4/8.14.4/Submit) id p062UEAX022928; Thu, 6 Jan 2011 05:30:14 +0300 (MSK) (envelope-from ache) Date: Thu, 6 Jan 2011 05:30:14 +0300 From: Andrey Chernov To: Matthew Jacob Message-ID: <20110106023014.GA22349@vniz.net> Mail-Followup-To: Andrey Chernov , Matthew Jacob , freebsd-arch@FreeBSD.ORG References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> <4D24E5B6.8060904@feral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <4D24E5B6.8060904@feral.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 02:49:29 -0000 On Wed, Jan 05, 2011 at 01:42:14PM -0800, Matthew Jacob wrote: > >> BTW, I have nothing against having source level Linux compatibility in > >> some places, because resulting binary will be FreeBSD one in any case,= but > >> I'm strongly against executable binary compatibility level. > > >=20 > Hmm. Well, that's a non-starter. Storage vendors provide tools for Linux= =20 > and Windows. That's it. Those tools have to be used on FreeBSD.=20 > Therefore, binary execution of such tools, and the infrastructure to=20 > support that, is pretty much mandatory. Minimal Windows required to run storage configuration tools may run just=20 =66rom USB flash drive, you don't need to infect FreeBSD just for that. --=20 http://ache.vniz.net/ From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 02:53:22 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC7D1106566C for ; Thu, 6 Jan 2011 02:53:22 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 717A68FC15 for ; Thu, 6 Jan 2011 02:53:22 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id p062rLSW011146; Wed, 5 Jan 2011 21:53:21 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Wed, 05 Jan 2011 21:53:21 -0500 (EST) Date: Wed, 5 Jan 2011 21:53:21 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Andrey Chernov In-Reply-To: <20110106024403.GB22349@vniz.net> Message-ID: References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> <20110106024403.GB22349@vniz.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Scott Long Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 02:53:22 -0000 On Thu, 6 Jan 2011, Andrey Chernov wrote: > On Wed, Jan 05, 2011 at 05:17:21PM -0700, Scott Long wrote: >>> We have not been marginalized in this space because we have an >>> emulator. We just don't have the marketshare in many areas. If >>> anything, these emulators improve our marketshare. >> >> I agree entirely. Companies look at marketshare and ability to turn >> more revenue than costs (i.e. profit). Like Jeff, I've had my share >> of dealing with companies who have made a conscious to support or not >> support FreeBSD based on those factors. Petitions and letters sound >> great on Slashdot, but don't work in the real world. Emulation >> increases marketshare. > > Emulation decreases our marketshare, presenting us like > not-so-good-but-trying Linux clone, so, for this reason alone, every > serious company will put its money on Linux product running on real Linux > instead of thinking about porting it into FreeBSD. Has anyone asked, instead of putting Linux shims into FreeBSD, why aren't FreeBSD shims put into Linux? If the FreeBSD ABI/KPI is supposedly more stable than Linux, then wouldn't it make more sense to do it that way? And I suppose part of the answer to that question is, it would not be acceptible to the Linux folks. -- DE From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 04:00:55 2011 Return-Path: Delivered-To: arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3565A106564A; Thu, 6 Jan 2011 04:00:55 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id E4AEB8FC12; Thu, 6 Jan 2011 04:00:54 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id p0640pNw007328; Wed, 5 Jan 2011 21:00:51 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <20110106024403.GB22349@vniz.net> Date: Wed, 5 Jan 2011 21:00:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8A69DE05-A433-4D40-8E63-8F06215606F2@samsco.org> References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> <20110106024403.GB22349@vniz.net> To: Andrey Chernov X-Mailer: Apple Mail (2.1082) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: arch@FreeBSD.ORG Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 04:00:55 -0000 On Jan 5, 2011, at 7:44 PM, Andrey Chernov wrote: > On Wed, Jan 05, 2011 at 05:17:21PM -0700, Scott Long wrote: >>> We have not been marginalized in this space because we have an = emulator. We just don't have the marketshare in many areas. If = anything, these emulators improve our marketshare. >>=20 >> I agree entirely. Companies look at marketshare and ability to turn = more revenue than costs (i.e. profit). Like Jeff, I've had my share of = dealing with companies who have made a conscious to support or not = support FreeBSD based on those factors. Petitions and letters sound = great on Slashdot, but don't work in the real world. Emulation = increases marketshare. >=20 > Emulation decreases our marketshare, presenting us like=20 > not-so-good-but-trying Linux clone, so, for this reason alone, every=20= > serious company will put its money on Linux product running on real = Linux=20 > instead of thinking about porting it into FreeBSD. >=20 I'm sorry, this simply hasn't been true in my experience. I've worked = with companies that have decided to support FreeBSD, and I've worked = with companies that have decided not to support FreeBSD. Emulation has = never been used as an excuse to not support FreeBSD. It's purely a = cost/benefit decision. Scott From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 04:08:31 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46DBF1065670 for ; Thu, 6 Jan 2011 04:08:31 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id CA3A08FC12 for ; Thu, 6 Jan 2011 04:08:30 +0000 (UTC) Received: by wwf26 with SMTP id 26so15824069wwf.31 for ; Wed, 05 Jan 2011 20:08:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+RGHxe5fe5gMhh+X0HqRpvfj947Irv3relNOqkqr0OY=; b=lnFB9ypCUWxN5724PIyQApwGaaH2ibt/XhJuK25EWEODkUysI1xAmeHokPTIOSq+tR y2O3yDms6Ze+elSjr9hTOFpBZDbn0FozpDLV6gL1iWPNyxe6BYDOxU/J9mR15ucRrdUY wUbXXcnjkCcbXSaf5jWCRXJUmTXtDhSMFpJHA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=IZeXtYbwlFygPWPh0aYgsziG2ZZc6eRrxMFJFvyy3Anq5iceIRDgI9WtM0X1QOClMT o27QsR/xtFW5BC5J3oWIlqNMaGDWDLgV9T62IliuXjxmIXvBRMyVdbd7iMI6C0k5y6wQ TBcl4sg9k5rQx55iLC71r9unMiyltJDaYgz4s= MIME-Version: 1.0 Received: by 10.216.29.71 with SMTP id h49mr181670wea.46.1294286909169; Wed, 05 Jan 2011 20:08:29 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.254.226 with HTTP; Wed, 5 Jan 2011 20:08:29 -0800 (PST) In-Reply-To: References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> <20110106024403.GB22349@vniz.net> Date: Wed, 5 Jan 2011 20:08:29 -0800 X-Google-Sender-Auth: 6goNij2ugiuosgIGNlQvLCgeq9k Message-ID: From: Garrett Cooper To: Daniel Eischen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, Scott Long Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 04:08:31 -0000 On Wed, Jan 5, 2011 at 6:53 PM, Daniel Eischen wrote= : > On Thu, 6 Jan 2011, Andrey Chernov wrote: > >> On Wed, Jan 05, 2011 at 05:17:21PM -0700, Scott Long wrote: >>>> >>>> We have not been marginalized in this space because we have an emulato= r. >>>> We just don't have the marketshare in many areas. =A0If anything, thes= e >>>> emulators improve our marketshare. >>> >>> I agree entirely. =A0Companies look at marketshare and ability to turn = more >>> revenue than costs (i.e. profit). =A0Like Jeff, I've had my share of de= aling >>> with companies who have made a conscious to support or not support Free= BSD >>> based on those factors. =A0Petitions and letters sound great on Slashdo= t, but >>> don't work in the real world. =A0Emulation increases marketshare. >> >> Emulation decreases our marketshare, presenting us like >> not-so-good-but-trying Linux clone, so, for this reason alone, every >> serious company will put its money on Linux product running on real Linu= x >> instead of thinking about porting it into FreeBSD. > > Has anyone asked, instead of putting Linux shims into FreeBSD, > why aren't FreeBSD shims put into Linux? =A0If the FreeBSD ABI/KPI > is supposedly more stable than Linux, then wouldn't it make > more sense to do it that way? > > And I suppose part of the answer to that question is, it would > not be acceptible to the Linux folks. Pretty sure it's because many hardcore Linux folks don't like the BSD license (and the fact that it's business friendly, i.e. closed source drivers are ok?). The OSS soundsystem was a prime example of what happens when code that's BSD licensed gets put in the Linux kernel (well, ok... there were other reasons but as I was reading that was a big source of contention with the Linux crowd and that system, despite the fact that it was better than ALSA for a long time, and is still better in some ways [1]). -Garrett 1. http://4front-tech.com/hannublog/?p=3D5 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 04:18:25 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0E63106564A for ; Thu, 6 Jan 2011 04:18:25 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3D26D8FC08 for ; Thu, 6 Jan 2011 04:18:24 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id p064IO4t010799; Wed, 5 Jan 2011 23:18:24 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Wed, 05 Jan 2011 23:18:24 -0500 (EST) Date: Wed, 5 Jan 2011 23:18:24 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Garrett Cooper In-Reply-To: Message-ID: References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> <20110106024403.GB22349@vniz.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1307206911-1294287504=:11613" Cc: arch@freebsd.org, Scott Long Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 04:18:25 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1307206911-1294287504=:11613 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 5 Jan 2011, Garrett Cooper wrote: > On Wed, Jan 5, 2011 at 6:53 PM, Daniel Eischen wro= te: >> >> Has anyone asked, instead of putting Linux shims into FreeBSD, >> why aren't FreeBSD shims put into Linux? =A0If the FreeBSD ABI/KPI >> is supposedly more stable than Linux, then wouldn't it make >> more sense to do it that way? >> >> And I suppose part of the answer to that question is, it would >> not be acceptible to the Linux folks. > > Pretty sure it's because many hardcore Linux folks don't like the > BSD license (and the fact that it's business friendly, i.e. closed > source drivers are ok?). The OSS soundsystem was a prime example of > what happens when code that's BSD licensed gets put in the Linux > kernel (well, ok... there were other reasons but as I was reading that > was a big source of contention with the Linux crowd and that system, > despite the fact that it was better than ALSA for a long time, and is > still better in some ways [1]). Well, they would be shims that just implement the FreeBSD API using Linux APIs and some glue, so I don't see why they wouldn't or couldn't be GPL licensed. I'm assuming (perhaps incorrectly) that Jeff's proposed Linux shims are BSD licensed, so the converse should be doable as well. But regardless, Jeff's already done the work, so they should just get imported into FreeBSD someplace. --=20 DE ---559023410-1307206911-1294287504=:11613-- From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 04:41:24 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 191CD106564A for ; Thu, 6 Jan 2011 04:41:24 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id D452E8FC14 for ; Thu, 6 Jan 2011 04:41:23 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.4/8.14.3) with ESMTP id p064fL0s099358 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 5 Jan 2011 20:41:22 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4D2547ED.6080402@feral.com> Date: Wed, 05 Jan 2011 20:41:17 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Andrey Chernov , freebsd-arch@freebsd.org References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> <4D24E5B6.8060904@feral.com> <20110106023014.GA22349@vniz.net> In-Reply-To: <20110106023014.GA22349@vniz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Wed, 05 Jan 2011 20:41:23 -0800 (PST) Cc: Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 04:41:24 -0000 >> Hmm. Well, that's a non-starter. Storage vendors provide tools for Linux >> and Windows. That's it. Those tools have to be used on FreeBSD. >> Therefore, binary execution of such tools, and the infrastructure to >> support that, is pretty much mandatory. > Minimal Windows required to run storage configuration tools may run just > from USB flash drive, you don't need to infect FreeBSD just for that. > No, that's a non-starter still From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 04:46:02 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D655106566C; Thu, 6 Jan 2011 04:46:02 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 284E78FC18; Thu, 6 Jan 2011 04:46:02 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p064k0ip062296; Thu, 6 Jan 2011 04:46:01 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4D254909.5040604@freebsd.org> Date: Thu, 06 Jan 2011 12:46:01 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100630) MIME-Version: 1.0 To: Scott Long References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> <20110106024403.GB22349@vniz.net> <8A69DE05-A433-4D40-8E63-8F06215606F2@samsco.org> In-Reply-To: <8A69DE05-A433-4D40-8E63-8F06215606F2@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 04:46:02 -0000 Scott Long wrote: > On Jan 5, 2011, at 7:44 PM, Andrey Chernov wrote: >> On Wed, Jan 05, 2011 at 05:17:21PM -0700, Scott Long wrote: >>>> We have not been marginalized in this space because we have an emulator. We just don't have the marketshare in many areas. If anything, these emulators improve our marketshare. >>> I agree entirely. Companies look at marketshare and ability to turn more revenue than costs (i.e. profit). Like Jeff, I've had my share of dealing with companies who have made a conscious to support or not support FreeBSD based on those factors. Petitions and letters sound great on Slashdot, but don't work in the real world. Emulation increases marketshare. >> Emulation decreases our marketshare, presenting us like >> not-so-good-but-trying Linux clone, so, for this reason alone, every >> serious company will put its money on Linux product running on real Linux >> instead of thinking about porting it into FreeBSD. >> > > I'm sorry, this simply hasn't been true in my experience. I've worked with companies that have decided to support FreeBSD, and I've worked with companies that have decided not to support FreeBSD. Emulation has never been used as an excuse to not support FreeBSD. It's purely a cost/benefit decision. > > Scott > Vendor vs User, two sides. Here, if one is native, another is emulation, people would run native version rather than emulation. From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 04:57:10 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1363F1065672 for ; Thu, 6 Jan 2011 04:57:10 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id CE9508FC0A for ; Thu, 6 Jan 2011 04:57:09 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.4/8.14.3) with ESMTP id p064uweM099440 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 5 Jan 2011 20:57:09 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4D254B99.1010501@feral.com> Date: Wed, 05 Jan 2011 20:56:57 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> <20110106024403.GB22349@vniz.net> <8A69DE05-A433-4D40-8E63-8F06215606F2@samsco.org> <4D254909.5040604@freebsd.org> In-Reply-To: <4D254909.5040604@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Wed, 05 Jan 2011 20:57:09 -0800 (PST) Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 04:57:10 -0000 > > Vendor vs User, two sides. Here, if one is native, another > is emulation, people would run native version rather than emulation. > > Hmm. Large chunks of code is run in the windows world in 'emulation' mode. I don't think people really care as long as it doesn't mess up and annoy them. From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 06:02:00 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22D5A106566C for ; Thu, 6 Jan 2011 06:02:00 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id B9EE58FC15 for ; Thu, 6 Jan 2011 06:01:59 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id p065dex7012390; Wed, 5 Jan 2011 22:39:40 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <4D24E5B6.8060904@feral.com> Date: Wed, 5 Jan 2011 22:39:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> <4D24E5B6.8060904@feral.com> To: Matthew Jacob X-Mailer: Apple Mail (2.1082) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 06:02:00 -0000 On Jan 5, 2011, at 2:42 PM, Matthew Jacob wrote: >=20 >=20 >=20 >>>=20 >>> BTW, I have nothing against having source level Linux compatibility = in >>> some places, because resulting binary will be FreeBSD one in any = case, but >>> I'm strongly against executable binary compatibility level. >>=20 >=20 > Hmm. Well, that's a non-starter. Storage vendors provide tools for = Linux and Windows. That's it. Those tools have to be used on FreeBSD. = Therefore, binary execution of such tools, and the infrastructure to = support that, is pretty much mandatory. Areca provides FreeBSD tools LSI provides FreeBSD tools Adaptec used to provide FreeBSD tools for most of their stuff, back when = they were still around/relevant Highpoint provides FreeBSD tools Who am I missing... Emulex I guess, but they provide nothing for = FreeBSD. PMC maybe, but I'm waiting to see how their integration with = the Adaptec assets goes before I pass judgement. Marvell doesn't, but = they don't sell into the channel anyways, only to integrators, and their = chips tend to be used for crummy software storage stacks. Qlogic, JNI, = and other FC players, maybe? The shortage of enterprise FC vendor = support is disappointing, but I think that FreeBSD has a lot more = deficiencies in that area than just vendor support. In any case, there is definitely a lot more that "zero" vendor support = for native FreeBSD tools. It lacks in the low-end BIOS-based softraid, = and it lacks in the high-end FC area, but the middle is covered quite = well, IMHO. Scott From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 07:05:32 2011 Return-Path: Delivered-To: arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 505BD106566C for ; Thu, 6 Jan 2011 07:05:32 +0000 (UTC) (envelope-from ache@vniz.net) Received: from vniz.net (vniz.net [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id C49A08FC12 for ; Thu, 6 Jan 2011 07:05:31 +0000 (UTC) Received: from vniz.net (localhost [127.0.0.1]) by vniz.net (8.14.4/8.14.4) with ESMTP id p0675Ul8026721; Thu, 6 Jan 2011 10:05:30 +0300 (MSK) (envelope-from ache@vniz.net) Received: (from ache@localhost) by vniz.net (8.14.4/8.14.4/Submit) id p0675TPC026720; Thu, 6 Jan 2011 10:05:29 +0300 (MSK) (envelope-from ache) Date: Thu, 6 Jan 2011 10:05:28 +0300 From: Andrey Chernov To: David Xu Message-ID: <20110106070528.GA26547@vniz.net> References: <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> <20110106024403.GB22349@vniz.net> <8A69DE05-A433-4D40-8E63-8F06215606F2@samsco.org> <4D254909.5040604@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D254909.5040604@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@FreeBSD.ORG, Scott Long Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 07:05:32 -0000 On Thu, Jan 06, 2011 at 12:46:01PM +0800, David Xu wrote: > > > > I'm sorry, this simply hasn't been true in my experience. I've worked with companies that have decided to support FreeBSD, and I've worked with companies that have decided not to support FreeBSD. Emulation has never been used as an excuse to not support FreeBSD. It's purely a cost/benefit decision. > > > > Scott > > > > Vendor vs User, two sides. Here, if one is native, another > is emulation, people would run native version rather than emulation. Yes, I mean that case. Speaking in general, only one kind of emulation increases marketshare, it is big->small way. Say, Symbian emulation (small devices) for their desktop developer toolchaing on x86 (big device). But big->big way is pure nonsense. Moreover, if that way ever happens, the rule is: loser emulates winner, becoming even more loser than before (staying with its own originality instead is more winning strategy). And we need to not confuse emulation and hardware-supported virtualizations because such virtualizations is able to run full OSes (i.e. is kind of different machines). So, I am for emulation like Symbian and for virtualization like vmware, but not for Linux emulation. -- http://ache.vniz.net/ From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 11:40:08 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23AFC1065670 for ; Thu, 6 Jan 2011 11:40:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 9E6A48FC17 for ; Thu, 6 Jan 2011 11:40:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 2726741C705 for ; Thu, 6 Jan 2011 12:40:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id mAfFx4r4ISby for ; Thu, 6 Jan 2011 12:40:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 939E241C6FC; Thu, 6 Jan 2011 12:40:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 87C294448F3 for ; Thu, 6 Jan 2011 11:37:04 +0000 (UTC) Date: Thu, 6 Jan 2011 11:37:04 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: arch@freebsd.org In-Reply-To: Message-ID: <20110106113536.O14966@maildrop.int.zabbadoz.net> References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> <20110106024403.GB22349@vniz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 11:40:08 -0000 On Wed, 5 Jan 2011, Daniel Eischen wrote: > On Thu, 6 Jan 2011, Andrey Chernov wrote: > >> On Wed, Jan 05, 2011 at 05:17:21PM -0700, Scott Long wrote: >>>> We have not been marginalized in this space because we have an emulator. >>>> We just don't have the marketshare in many areas. If anything, these >>>> emulators improve our marketshare. >>> >>> I agree entirely. Companies look at marketshare and ability to turn more >>> revenue than costs (i.e. profit). Like Jeff, I've had my share of dealing >>> with companies who have made a conscious to support or not support FreeBSD >>> based on those factors. Petitions and letters sound great on Slashdot, >>> but don't work in the real world. Emulation increases marketshare. >> >> Emulation decreases our marketshare, presenting us like >> not-so-good-but-trying Linux clone, so, for this reason alone, every >> serious company will put its money on Linux product running on real Linux >> instead of thinking about porting it into FreeBSD. > > Has anyone asked, instead of putting Linux shims into FreeBSD, > why aren't FreeBSD shims put into Linux? If the FreeBSD ABI/KPI > is supposedly more stable than Linux, then wouldn't it make > more sense to do it that way? You people know that a lot of linux tools are ported to freebsd? I mean there is a glibc for FreeBSD out and (soon to be) in an official Linux distribution release. > And I suppose part of the answer to that question is, it would > not be acceptible to the Linux folks. -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 13:16:21 2011 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03A02106566C; Thu, 6 Jan 2011 13:16:21 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (mail.farley.org [IPv6:2001:470:1f0f:20:2::11]) by mx1.freebsd.org (Postfix) with ESMTP id 966448FC0A; Thu, 6 Jan 2011 13:16:20 +0000 (UTC) Received: from thor.farley.org (HPooka@thor.farley.org [IPv6:2001:470:1f0f:20:1::5]) by mail.farley.org (8.14.4/8.14.4) with ESMTP id p06DGJ60088940; Thu, 6 Jan 2011 07:16:19 -0600 (CST) (envelope-from scf@FreeBSD.org) Date: Thu, 6 Jan 2011 07:16:19 -0600 (CST) From: "Sean C. Farley" To: Andrey Chernov In-Reply-To: <20110105175926.GA2101@vniz.net> Message-ID: References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Spam-Status: No, score=-1.6 required=4.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.farley.org Cc: arch@FreeBSD.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 13:16:21 -0000 On Wed, 5 Jan 2011, Andrey Chernov wrote: > On Wed, Jan 05, 2011 at 12:40:45PM -0500, Alexander Kabaev wrote: >>> I have heard this argument about the linuxulator and what we're >>> really talking about is slipping FreeBSD marketshare. I don't share >>> the view that the linuxulator futhered this slip but rather my view >>> is that it allows us to stay relevant in areas where companies can >>> not justify an independent FreeBSD effort. Adobe is a good example >>> of this. >> >> It compounded the Adobe's reluctance to work on portable flash player. > > I agree with Alexander even more. We don't need _any_ Linux emulator > in the tree and even in the ports. Flash player is a good example of > how Linux emulator is harmful: instead of sending tons of complaints > to Adobe to force them to make native FreeBSD version, users tends to > install Flash via emulator and got all its pain as result. Well, there have been some requests[1] sent to Adobe for a native version especially after running Flash through emulation. This is even after having to register to vote or attach a comment for the bug. It is the fourth most popular Flash bug. If anyone wants to vote for it, not just submit a comment to it, then I want to mention that two votes are (at least were) allowed per bug. I should ask some people at work to vote for it. > BTW, I have nothing against having source level Linux compatibility in > some places, because resulting binary will be FreeBSD one in any case, but > I'm strongly against executable binary compatibility level. While you may be correct, there are some items to note: 1. Wine has not stopped Adobe from providing Linux binaries. 2. Nvidia[2] provided a FreeBSD driver and binaries after people were attempting to run the Linux driver in emulation. Sean 1. http://bugs.adobe.com/jira/browse/FP-1060 2. Thank you, Nvidia! -- scf@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 14:20:07 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B34CA10656B4 for ; Thu, 6 Jan 2011 14:20:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 463328FC27 for ; Thu, 6 Jan 2011 14:20:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 4B2A341C705; Thu, 6 Jan 2011 15:20:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 3j3F2mkl9wMX; Thu, 6 Jan 2011 15:20:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 8C4A741C6FC; Thu, 6 Jan 2011 15:20:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id EC5714448F3; Thu, 6 Jan 2011 14:17:17 +0000 (UTC) Date: Thu, 6 Jan 2011 14:17:17 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Jeff Roberson In-Reply-To: Message-ID: <20110106140722.E14966@maildrop.int.zabbadoz.net> References: <82826.1294088199@critter.freebsd.dk> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 14:20:07 -0000 On Mon, 3 Jan 2011, Jeff Roberson wrote: > Unfortunately it would create quite a lot of code churn as there are > relatively few that are minorly different. You can page through the wrapper > code if you're interested. > > http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/ofed/include/linux/ One thing I am not too sure about is sys/ofed. Given the entire discussions it might well be better suited in sys/contrib/ofed under the assumtion that the code is mostly maintained outside our tree and we get in occational updates. I hadn't quite liked the sys/cddl but given that we had sys/gnu as well. And then there is sys/compat. I wonder if you could still or maybe not make the shim layer something like it's own .ko kind of like opensolaris.ko (you cannot name it linux.ko though;) I guess similarly things in user space might go to contrib as well? Would you by any chance be able to generate a patch for all the sys/ and config etc. changes outside the ofed directory for prior review by people? I am just fearing that there might be bits for the V_irtualization side etc to consider, as might be for others with outstanding work. Thanks, /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 14:27:28 2011 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 624D01065672; Thu, 6 Jan 2011 14:27:28 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (diana.db.net [66.113.102.10]) by mx1.freebsd.org (Postfix) with ESMTP id 453948FC14; Thu, 6 Jan 2011 14:27:28 +0000 (UTC) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 4CCAD2282A; Thu, 6 Jan 2011 07:07:21 -0700 (MST) Received: by night.db.net (Postfix, from userid 100) id 34B3C5CA3; Thu, 6 Jan 2011 09:07:33 -0500 (EST) Date: Thu, 6 Jan 2011 09:07:33 -0500 From: Diane Bruce To: "Sean C. Farley" Message-ID: <20110106140733.GA90903@night.db.net> References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: arch@FreeBSD.org, Andrey Chernov Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 14:27:28 -0000 Bleh! Bleh! what a rash of comments! On Thu, Jan 06, 2011 at 07:16:19AM -0600, Sean C. Farley wrote: > On Wed, 5 Jan 2011, Andrey Chernov wrote: > > >On Wed, Jan 05, 2011 at 12:40:45PM -0500, Alexander Kabaev wrote: > >>>I have heard this argument about the linuxulator and what we're I have always found the linuxulator handy for converting the no-so-zealot linuxer into trying FreeBSD. "You can continue to run your old binaries for a time". Ditto for the extfs support. > >>>really talking about is slipping FreeBSD marketshare. I don't share ... > >>>not justify an independent FreeBSD effort. Adobe is a good example > >>>of this. > >> > >>It compounded the Adobe's reluctance to work on portable flash player. > > > >I agree with Alexander even more. We don't need _any_ Linux emulator > >in the tree and even in the ports. Flash player is a good example of Ok, if the linuxulator is trivial, easy to do sure. Run a linux binary. The same way it would be nice to run an OSX binary, or a solaris binary, or a whatever. OSX is problematical for the graphics of course, but for plain ol' binaries, why not? I might also point out that the earliest versions of Unix were capable of running RT-11 binaries. (Thanks to UoT, hi Henry if you are reading!) I believe it was done so the RT-11 dungeo.exe could be run on unix. ;-) > >how Linux emulator is harmful: instead of sending tons of complaints > >to Adobe to force them to make native FreeBSD version, users tends to > >install Flash via emulator and got all its pain as result. But they don't even seem to care about the linux binary either. From what I have been hearing, they still have problems with that one. > > Well, there have been some requests[1] sent to Adobe for a native > version especially after running Flash through emulation. This is even > after having to register to vote or attach a comment for the bug. It is > the fourth most popular Flash bug. Adobe was a bad example. I believe they only care about Windows and OSX. I bet they get paid real money for that work. ... > >BTW, I have nothing against having source level Linux compatibility in > >some places, because resulting binary will be FreeBSD one in any case, but > >I'm strongly against executable binary compatibility level. Provided it is useful as a bridge for users converting from linux to FreeBSD or to prompt work on a native version, I think it is fine. I think you are throwing out the baby with the h2o. - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 17:16:11 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12B85106566B for ; Thu, 6 Jan 2011 17:16:11 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id CEBFC8FC17 for ; Thu, 6 Jan 2011 17:16:10 +0000 (UTC) Received: from [192.168.1.100] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.4/8.14.3) with ESMTP id p06HG90d002921; Thu, 6 Jan 2011 09:16:09 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4D25F8E1.9020205@feral.com> Date: Thu, 06 Jan 2011 09:16:17 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Scott Long References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> <4D24E5B6.8060904@feral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.67.166.1]); Thu, 06 Jan 2011 09:16:10 -0800 (PST) Cc: freebsd-arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 17:16:11 -0000 > Areca provides FreeBSD tools > LSI provides FreeBSD tools Not all of them. We're using the Santricity JAVA tools which are linux based thru sg at Panasas. From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 17:56:00 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B12F0106566B for ; Thu, 6 Jan 2011 17:56:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6BA938FC12 for ; Thu, 6 Jan 2011 17:56:00 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id p06HnsfD032273 for ; Thu, 6 Jan 2011 10:49:54 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4D2600C0.40804@bsdimp.com> Date: Thu, 06 Jan 2011 10:49:52 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> <4D24E5B6.8060904@feral.com> In-Reply-To: <4D24E5B6.8060904@feral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 17:56:00 -0000 On 01/05/2011 14:42, Matthew Jacob wrote: > > > >>> >>> BTW, I have nothing against having source level Linux compatibility in >>> some places, because resulting binary will be FreeBSD one in any >>> case, but >>> I'm strongly against executable binary compatibility level. >> > > Hmm. Well, that's a non-starter. Storage vendors provide tools for > Linux and Windows. That's it. Those tools have to be used on FreeBSD. > Therefore, binary execution of such tools, and the infrastructure to > support that, is pretty much mandatory. I've encountered dozens of little tools over the years that I've needed to run on my FreeBSD box that were linux only. They were produced by enthusiasts in some area (TiVo, ZipIt, etc) that don't have the resources to port them to FreeBSD. The Linuxulator made my FreeBSD system more useful by being able to tap into these communities more easily. The whole Adobe Flash thing is a red herring. Even if we couldn't run the Linux version, a native version likely wouldn't happen. A combination of politics and low demand get in the way. Solving the low demand problem doesn't solve the politics problem. It also doesn't solve the "Flash sucks" problem either (npviewer.bin anyone?). Let's be careful not to cut off our nose to spite our face. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 18:03:37 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8200C106564A for ; Thu, 6 Jan 2011 18:03:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3C2A08FC17 for ; Thu, 6 Jan 2011 18:03:37 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id p06Hx6sR032362 for ; Thu, 6 Jan 2011 10:59:06 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4D2602E8.6080609@bsdimp.com> Date: Thu, 06 Jan 2011 10:59:04 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> <20110106024403.GB22349@vniz.net> <8A69DE05-A433-4D40-8E63-8F06215606F2@samsco.org> In-Reply-To: <8A69DE05-A433-4D40-8E63-8F06215606F2@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:03:37 -0000 On 01/05/2011 21:00, Scott Long wrote: > I'm sorry, this simply hasn't been true in my experience. I've worked with companies that have decided to support FreeBSD, and I've worked with companies that have decided not to support FreeBSD. Emulation has never been used as an excuse to not support FreeBSD. It's purely a cost/benefit decision. Yes. I've been on the inside of a few of them, even seeing some business case figures. These usually say that for the segment that company X is going after for product Y can sell 1000 units to customer W and another Z000 to the market as it emerges over the next 2 years. 1000 units gets them $200k profit, development costs are $100k for developer time, test time, etc. Z is large, so potential revenue form this project is in the millions, with a guaranteed small initial profit. Decision: go. There's been other times where similar analysis has resulted in a 'no go' decision, since other opportunities are bigger. Other factors are in the noise until after the decision to go/nogo has been made. Warner P.S. The numbers above are hypothetical, but representative of the kinds of things that people look at in making a decision to support an OS natively. From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 18:55:37 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B02851065670 for ; Thu, 6 Jan 2011 18:55:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6F7AA8FC0A for ; Thu, 6 Jan 2011 18:55:37 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id p06IkdRM033084 for ; Thu, 6 Jan 2011 11:46:39 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4D260E0D.8080003@bsdimp.com> Date: Thu, 06 Jan 2011 11:46:37 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org References: <82826.1294088199@critter.freebsd.dk> <20110106140722.E14966@maildrop.int.zabbadoz.net> In-Reply-To: <20110106140722.E14966@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:55:37 -0000 On 01/06/2011 07:17, Bjoern A. Zeeb wrote: > On Mon, 3 Jan 2011, Jeff Roberson wrote: > >> Unfortunately it would create quite a lot of code churn as there are >> relatively few that are minorly different. You can page through the >> wrapper code if you're interested. >> >> http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/ofed/include/linux/ >> > > One thing I am not too sure about is sys/ofed. Given the entire > discussions it might well be better suited in sys/contrib/ofed under > the assumtion that the code is mostly maintained outside our tree and > we get in occational updates. If you look at what Jeff has done, you'll see that the external code follows our standards of residing in sys/contrib/ofed, while the code that glues it into the tree is in sys/ofed. > I hadn't quite liked the sys/cddl but given that we had sys/gnu as > well. And then there is sys/compat. A slight case could be made for sys/compat/linux, but that is already taken. > I wonder if you could still or maybe not make the shim layer something > like it's own .ko kind of like opensolaris.ko (you cannot name it > linux.ko though;) I'd actually prefer that we not do this. opensolaris.ko made sense because we have zfs and dtrace, and even that causes problems as we get version skew between them... > I guess similarly things in user space might go to contrib as well? src/contrib is for code that's maintained outside the source tree that we adapt. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 19:52:30 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2A921065675 for ; Thu, 6 Jan 2011 19:52:30 +0000 (UTC) (envelope-from zml@FreeBSD.org) Received: from seaxch10.isilon.com (seaxch10.isilon.com [74.85.160.26]) by mx1.freebsd.org (Postfix) with ESMTP id C2B2A8FC16 for ; Thu, 6 Jan 2011 19:52:30 +0000 (UTC) Received: from famine.isilon.com ([10.54.190.95]) by seaxch10.isilon.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Jan 2011 11:40:30 -0800 Received: by famine.isilon.com (Postfix, from userid 2106) id 935C450C1A8; Thu, 6 Jan 2011 11:40:30 -0800 (PST) Date: Thu, 6 Jan 2011 11:40:30 -0800 From: Zachary Loafman To: Jeff Roberson Message-ID: <20110106194030.GA27507@famine.west.isilon.com> References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 06 Jan 2011 19:40:30.0474 (UTC) FILETIME=[93861EA0:01CBADD9] Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 19:52:31 -0000 On Tue, Jan 04, 2011 at 10:53:30AM -1000, Jeff Roberson wrote: > >The considerations are simple enough. First, we do not have many IB > >users of FreeBSD in the wild and those that we have (Isilon) seem to be > >perfectly capable of managing the IB stack out of the tree, without > >dumping the thousands of lines of the code into the base. If they had > >the stack before, but were not willing/capable to provide adequate care > >for it in the past, there is no reason to expect things to change with > >second stack, which now will rot in our tree instead of theirs. > > They provided adequate care for it to keep their product running on > old versions of FreeBSD. Unfortunately it is a large stack and > there are a great number of people and organizations working on > improving and advancing it on Linux via OFED and having a private > stack does not give you the benefit of their work. The motivation > for making the wrapper layer was entirely to keep pace with this > development and make it less likely that what is in the tree will > rot. Allow me to speak for a moment on Isilon's behalf and make a public commitment: We intend to maintain the OFED port in the tree and any necessary shim layer that interacts with it. I understand your concerns about our past performance .. yes, we had a very ancient stack, and we let it fall into disrepair, basically only modifying it enough to be sufficient for our product. It wasn't even a complete port - it was missing many of the diagnostic tools, the verbs layer and various libraries that make up the complete OFED stack. This contract was largely undetaken to "catch up" on OFED, so we could get back in a position where we could actively maintain it. There was almost no way to use the original port to do this. It was our first car, and we ran it into the ground. Now Jeff has given us a shiny new car, and we intend to maintain it. Unlike 4 years ago, we now have staffed IB personnel that will be working with the code in the FreeBSD tree. We have every incentive to make sure IB stays working in head - it saves us so much time when we merge. And, for those who heard of our recent acquisition by EMC, we have a nod from our parent company to keep doing what we're doing. I hope this mitigates most of the non-technical concerns. -- Zach Loafman | Staff Engineer | Isilon Systems From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 20:11:14 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 748A9106564A for ; Thu, 6 Jan 2011 20:11:14 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id 553D98FC17 for ; Thu, 6 Jan 2011 20:11:14 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from sa-nc-mfg-69.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp029.mac.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 64bit)) with ESMTPSA id <0LEM00M997YDKX80@asmtp029.mac.com> for freebsd-arch@FreeBSD.org; Thu, 06 Jan 2011 11:11:02 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1010190000 definitions=main-1101060070 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-01-06_09:2011-01-06, 2011-01-06, 1970-01-01 signatures=0 From: Marcel Moolenaar In-reply-to: <4D2602E8.6080609@bsdimp.com> Date: Thu, 06 Jan 2011 11:11:00 -0800 Message-id: <1BD6D137-8BBD-4EBE-A5B0-3B716B78BA08@mac.com> References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> <20110106024403.GB22349@vniz.net> <8A69DE05-A433-4D40-8E63-8F06215606F2@samsco.org> <4D2602E8.6080609@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1082) Cc: freebsd-arch@FreeBSD.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 20:11:14 -0000 On Jan 6, 2011, at 9:59 AM, Warner Losh wrote: > On 01/05/2011 21:00, Scott Long wrote: >> I'm sorry, this simply hasn't been true in my experience. I've worked with companies that have decided to support FreeBSD, and I've worked with companies that have decided not to support FreeBSD. Emulation has never been used as an excuse to not support FreeBSD. It's purely a cost/benefit decision. > > Yes. I've been on the inside of a few of them, even seeing some business case figures. These usually say that for the segment that company X is going after for product Y can sell 1000 units to customer W and another Z000 to the market as it emerges over the next 2 years. 1000 units gets them $200k profit, development costs are $100k for developer time, test time, etc. Z is large, so potential revenue form this project is in the millions, with a guaranteed small initial profit. Decision: go. But one cannot ignore the fact that a compatibility layer allows companies to support FreeBSD at lower development cost by eliminating the native port and instead just focus on the qualifying their Linux support within the emulation layer. If decisions are purely cost/benefit, then a compatibility layer reduces the cost, hence increases the benefit so if FreeBSD is at all a consideration, it will be through emulation. Is this what we want promote? Also, the experience that you and Scott have may be biased. You won't want to work for a company that is inherently Linux centric, right? Likewise, Linux-centric companies may be more interested in hiring Linux hackers and not FreeBSD hackers, right? So, doesn't that mean that your experience is ipso facto biased towards the companies that would even consider FreeBSD to begin with? What about those companies that couldn't care less about FreeBSD? Those for which cost and benefit are absolutes? I very much doubt that they are going to invest in an entirely new OS -- in order to support it natively, when their Linux-centric development teams can do the same using emulation? What I'm saying is this: do we really have an abjective view or are we biased towards FreeBSD-friendliness simply because we are FreeBSD hackers discussing on a FreeBSD email list and working for companies that like FreeBSD in some form or shape? Are we therefore the right people to argue whether Linux KPI emulation is good or bad for FreeBSD in the long run? I'm indecisive. It may be a damned if you do and damned if you don't kind of scenario. If that's the case, I'd rather be damned without it :-) -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 20:47:31 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8B591065695 for ; Thu, 6 Jan 2011 20:47:31 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id A5EE88FC26 for ; Thu, 6 Jan 2011 20:47:31 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Thu, 6 Jan 2011 15:36:44 -0500 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 33CDC33C00; Thu, 6 Jan 2011 15:36:44 -0500 (EST) Date: Thu, 6 Jan 2011 15:36:44 -0500 From: Ed Maste CC: Message-ID: <20110106203644.GA28026@sandvine.com> References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> <4D24E5B6.8060904@feral.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 20:47:32 -0000 On Wed, Jan 05, 2011 at 10:39:40PM -0700, Scott Long wrote: > Adaptec used to provide FreeBSD tools for most of their stuff, back when they were still around/relevant For what it's worth, Adaptec is now providing both their commandline tool for FreeBSD 6/7/8 in i386 and amd64 builds (6 binaries), as well as their Java management UI. That is, over time their support of FreeBSD has increased over time. (I'm still waiting to see if/how this changes under PMC, of course.) -Ed From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 20:51:06 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58A5B106564A for ; Thu, 6 Jan 2011 20:51:06 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 204E38FC1A for ; Thu, 6 Jan 2011 20:51:05 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id p06Kp1Pw017496; Thu, 6 Jan 2011 13:51:01 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <1BD6D137-8BBD-4EBE-A5B0-3B716B78BA08@mac.com> Date: Thu, 6 Jan 2011 13:51:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <76C52A35-1C49-4720-A8E2-B9A383F6FCF2@samsco.org> References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> <20110106024403.GB22349@vniz.net> <8A69DE05-A433-4D40-8E63-8F06215606F2@samsco.org> <4D2602E8.6080609@bsdimp.com> <1BD6D137-8BBD-4EBE-A5B0-3B716B78BA08@mac.com> To: Marcel Moolenaar X-Mailer: Apple Mail (2.1082) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 20:51:06 -0000 On Jan 6, 2011, at 12:11 PM, Marcel Moolenaar wrote: >=20 > On Jan 6, 2011, at 9:59 AM, Warner Losh wrote: >=20 >> On 01/05/2011 21:00, Scott Long wrote: >>> I'm sorry, this simply hasn't been true in my experience. I've = worked with companies that have decided to support FreeBSD, and I've = worked with companies that have decided not to support FreeBSD. = Emulation has never been used as an excuse to not support FreeBSD. It's = purely a cost/benefit decision. >>=20 >> Yes. I've been on the inside of a few of them, even seeing some = business case figures. These usually say that for the segment that = company X is going after for product Y can sell 1000 units to customer W = and another Z000 to the market as it emerges over the next 2 years. = 1000 units gets them $200k profit, development costs are $100k for = developer time, test time, etc. Z is large, so potential revenue form = this project is in the millions, with a guaranteed small initial profit. = Decision: go. >=20 > But one cannot ignore the fact that a compatibility layer allows = companies > to support FreeBSD at lower development cost by eliminating the native = port > and instead just focus on the qualifying their Linux support within = the > emulation layer. If decisions are purely cost/benefit, then a = compatibility > layer reduces the cost, hence increases the benefit so if FreeBSD is = at all > a consideration, it will be through emulation. >=20 > Is this what we want promote? >=20 > Also, the experience that you and Scott have may be biased. You won't = want > to work for a company that is inherently Linux centric, right? = Likewise, > Linux-centric companies may be more interested in hiring Linux hackers = and > not FreeBSD hackers, right? So, doesn't that mean that your experience = is > ipso facto biased towards the companies that would even consider = FreeBSD > to begin with? > What about those companies that couldn't care less about FreeBSD? = Those > for which cost and benefit are absolutes? > I very much doubt that they are going to invest in an entirely new OS = -- > in order to support it natively, when their Linux-centric development = teams > can do the same using emulation? >=20 > What I'm saying is this: do we really have an abjective view or are we > biased towards FreeBSD-friendliness simply because we are FreeBSD = hackers > discussing on a FreeBSD email list and working for companies that like > FreeBSD in some form or shape? >=20 > Are we therefore the right people to argue whether Linux KPI emulation = is > good or bad for FreeBSD in the long run? >=20 > I'm indecisive. It may be a damned if you do and damned if you don't > kind of scenario. If that's the case, I'd rather be damned without it = :-) >=20 There's a lot to this email that is silly, ignorant, and frustrating. = I'm bowing out of the discussion. Go on and build your walls around = FreeBSD and burn the bridges. Or don't. Scott From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 21:30:31 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2EAF106564A; Thu, 6 Jan 2011 21:30:31 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 590328FC1E; Thu, 6 Jan 2011 21:30:31 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.4/8.14.4) with ESMTP id p06LUUvp006270; Thu, 6 Jan 2011 16:30:30 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.4/8.14.4/Submit) id p06LUUmA006269; Thu, 6 Jan 2011 16:30:30 -0500 (EST) (envelope-from wollman) Date: Thu, 6 Jan 2011 16:30:30 -0500 (EST) From: Garrett Wollman Message-Id: <201101062130.p06LUUmA006269@hergotha.csail.mit.edu> To: zml@freebsd.org X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: <20110106194030.GA27507@famine.west.isilon.com> References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (hergotha.csail.mit.edu [127.0.0.1]); Thu, 06 Jan 2011 16:30:30 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on hergotha.csail.mit.edu Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 21:30:31 -0000 In article <20110106194030.GA27507@famine.west.isilon.com>, zml@freebsd.org writes: >Unlike 4 years ago, we now have staffed IB personnel that will be >working with the code in the FreeBSD tree. We have every incentive to >make sure IB stays working in head - it saves us so much time when we >merge. And, for those who heard of our recent acquisition by EMC, we >have a nod from our parent company to keep doing what we're doing. > >I hope this mitigates most of the non-technical concerns. I *hope* we are clear that we want Infiniband support in the tree. I don't think we agree about whether we want the compatibility layer to grow into a general "Linux KPI support layer" or simply part of the Infiniband stack in parallel with the adaptation layers used by lots of other vendor-supported drivers. So long as it remains what it currently is -- just the interfaces you need to make your code work -- then there is less chance of it becoming a maintenance problem in the future. On the other hand, we already have this issue with other bits of Linux kernel code that have been ported, more or less successfully, and their own (much thinner) compatibility glue layers. The argument that having only one such layer is better than having many is not unreasonable; it's just not clear to me that this is maintainable. -GAWollman From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 22:04:59 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BF8D1065673 for ; Thu, 6 Jan 2011 22:04:59 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id BA6268FC14 for ; Thu, 6 Jan 2011 22:04:58 +0000 (UTC) Received: by fxm16 with SMTP id 16so16383563fxm.13 for ; Thu, 06 Jan 2011 14:04:57 -0800 (PST) Received: by 10.223.53.68 with SMTP id l4mr975491fag.44.1294351497780; Thu, 06 Jan 2011 14:04:57 -0800 (PST) Received: from [10.0.1.198] ([72.253.42.56]) by mx.google.com with ESMTPS id k6sm5995562faa.6.2011.01.06.14.04.54 (version=SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 14:04:56 -0800 (PST) Date: Thu, 6 Jan 2011 12:07:36 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Marcel Moolenaar In-Reply-To: <1BD6D137-8BBD-4EBE-A5B0-3B716B78BA08@mac.com> Message-ID: References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> <20110106024403.GB22349@vniz.net> <8A69DE05-A433-4D40-8E63-8F06215606F2@samsco.org> <4D2602E8.6080609@bsdimp.com> <1BD6D137-8BBD-4EBE-A5B0-3B716B78BA08@mac.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-arch@FreeBSD.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 22:04:59 -0000 On Thu, 6 Jan 2011, Marcel Moolenaar wrote: > > On Jan 6, 2011, at 9:59 AM, Warner Losh wrote: > >> On 01/05/2011 21:00, Scott Long wrote: >>> I'm sorry, this simply hasn't been true in my experience. I've worked with companies that have decided to support FreeBSD, and I've worked with companies that have decided not to support FreeBSD. Emulation has never been used as an excuse to not support FreeBSD. It's purely a cost/benefit decision. >> >> Yes. I've been on the inside of a few of them, even seeing some business case figures. These usually say that for the segment that company X is going after for product Y can sell 1000 units to customer W and another Z000 to the market as it emerges over the next 2 years. 1000 units gets them $200k profit, development costs are $100k for developer time, test time, etc. Z is large, so potential revenue form this project is in the millions, with a guaranteed small initial profit. Decision: go. > > But one cannot ignore the fact that a compatibility layer allows companies > to support FreeBSD at lower development cost by eliminating the native port > and instead just focus on the qualifying their Linux support within the > emulation layer. If decisions are purely cost/benefit, then a compatibility > layer reduces the cost, hence increases the benefit so if FreeBSD is at all > a consideration, it will be through emulation. > > Is this what we want promote? > > Also, the experience that you and Scott have may be biased. You won't want > to work for a company that is inherently Linux centric, right? Likewise, > Linux-centric companies may be more interested in hiring Linux hackers and > not FreeBSD hackers, right? So, doesn't that mean that your experience is > ipso facto biased towards the companies that would even consider FreeBSD > to begin with? > What about those companies that couldn't care less about FreeBSD? Those > for which cost and benefit are absolutes? > I very much doubt that they are going to invest in an entirely new OS -- > in order to support it natively, when their Linux-centric development teams > can do the same using emulation? > > What I'm saying is this: do we really have an abjective view or are we > biased towards FreeBSD-friendliness simply because we are FreeBSD hackers > discussing on a FreeBSD email list and working for companies that like > FreeBSD in some form or shape? Hey Marcel, You may know that as a contractor I work for quite a number of different companies and not always on FreeBSD. I have worked with companies developing products from the start when operating system selection had to be made. I have worked for companies with existing Linux products that want to explore costs to produce FreeBSD versions or drivers. I have been at companies who bailed on BSD and switched to Linux at great expense. I have bugfixes in the Linux kernel and have written Linux device drivers and other features. I'm not going to claim that I have an objective viewpoint or that I know the right answers. I have seen a lot though by virtue of working with many companies and evangelizing FreeBSD, often unsuccessfully. Additionally, I have good friends who work regularly on Linux, contribute to lkml, and are generally connected in that world. My view is that companies needing a platform will reject FreeBSD for lack of features or lack of marketing clout. Linux has a stronger brand and people may want to advertise that association. IB is one feature that has cost us users, as is virtualization, and perhaps some driver support. The desktop apps that people want are a non-starter. If you talk to Linux people they're barely holding on to native versions of many packages with significantly more users than we have. They complain that adobe isn't supporting them, flash is too buggy, they're second class citizens in every way in commercial desktop software. To think that these companies even consider us is overstating our case. We need to do almost everything we can to reduce the barriers of use for FreeBSD in server and platform (juniper, isilon, type users) users. In my view, this is the core market and this is where we shine. They only way to keep users, developers, and mindshare is to grow our base by providing what they need. Emulation is one, imperfect, way to get there. The ports tree is obviously exceptional and superior where possible. In this specific case, there is no reasonable way to get an infiniband stack without the wrapper. There is already an industry consortium with developers from many companies working full time to make the one in linux a reality. There is only a casual interest in BSD and only companies already heavily invested in BSD are willing to go through the expense and time required to get a stack. Others simply install linux and move on. I can tell you that this was the only stumbling block to using FreeBSD for a company started by one of Isilon's original founders. I believe FreeBSD is an organization of principals and values that make it excellent. I understand how this is a compromise and even I myself will tell you it is. However, we need to keep in sight that we won't all get to continue doing what we love if we don't keep working to make it as appealing as possible. We are in every way the underdog the underdog doesn't have the clout to dictate terms. There has been quite a lot of good discussion and interesting points of view presented. However this will likely be my last contribution to the discussion. I'm going to work with the appropriate people to get this reviewed and in and will do what I can to minimize any view of a generic linux wrapper to prevent the abuse in other new code. I hope this resolution is acceptable enough to the detractors. Thanks to everyone who participated for their thoughts, Jeff > > Are we therefore the right people to argue whether Linux KPI emulation is > good or bad for FreeBSD in the long run? > > I'm indecisive. It may be a damned if you do and damned if you don't > kind of scenario. If that's the case, I'd rather be damned without it :-) > > -- > Marcel Moolenaar > xcllnt@mac.com > > > > _______________________________________________ > 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 Jan 6 22:40:07 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC4491065696 for ; Thu, 6 Jan 2011 22:40:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 7D4FF8FC18 for ; Thu, 6 Jan 2011 22:40:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 80D7941C670; Thu, 6 Jan 2011 23:40:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id u+ylsl5I1Srh; Thu, 6 Jan 2011 23:40:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id E133F41C66F; Thu, 6 Jan 2011 23:40:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 517AB4448F3; Thu, 6 Jan 2011 22:37:36 +0000 (UTC) Date: Thu, 6 Jan 2011 22:37:35 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Warner Losh In-Reply-To: <4D260E0D.8080003@bsdimp.com> Message-ID: <20110106222945.R14966@maildrop.int.zabbadoz.net> References: <82826.1294088199@critter.freebsd.dk> <20110106140722.E14966@maildrop.int.zabbadoz.net> <4D260E0D.8080003@bsdimp.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@FreeBSD.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 22:40:08 -0000 On Thu, 6 Jan 2011, Warner Losh wrote: > On 01/06/2011 07:17, Bjoern A. Zeeb wrote: >> On Mon, 3 Jan 2011, Jeff Roberson wrote: >> >>> Unfortunately it would create quite a lot of code churn as there are >>> relatively few that are minorly different. You can page through the >>> wrapper code if you're interested. >>> >>> http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/ofed/include/linux/ >> >> One thing I am not too sure about is sys/ofed. Given the entire >> discussions it might well be better suited in sys/contrib/ofed under >> the assumtion that the code is mostly maintained outside our tree and >> we get in occational updates. > > If you look at what Jeff has done, you'll see that the external code follows > our standards of residing in sys/contrib/ofed, while the code that glues it > into the tree is in sys/ofed. I might just be too blind to see an ofed there: http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/contrib/ It's rdma I guess. It feels just awkward to have the glue in sys/mumble rather than completely bundled in sys/contrib/ofed/** like we do for ipfilter, pf, ... to my understanding. The real glue into our stack, I assume, sits in net*/* mostly. >> I guess similarly things in user space might go to contrib as well? > src/contrib is for code that's maintained outside the source tree that we > adapt. Are all user space tools hand-rolled or are they ported over as well? Maybe I should wait till Jeff will post the diff to see. /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 22:50:13 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B986106566B for ; Thu, 6 Jan 2011 22:50:13 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id EC3BF8FC12 for ; Thu, 6 Jan 2011 22:50:12 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from sa-nc-mfg-69.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp023.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LEM0069MI3BFZD0@asmtp023.mac.com> for freebsd-arch@FreeBSD.org; Thu, 06 Jan 2011 14:49:59 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-01-06_11:2011-01-06, 2011-01-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1010190000 definitions=main-1101060098 From: Marcel Moolenaar In-reply-to: Date: Thu, 06 Jan 2011 14:49:58 -0800 Message-id: <190CA4F9-E0FB-4B0C-9DED-CC12FB7FD190@mac.com> References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> <20110105124045.6a0ddd1a@kan.dnsalias.net> <20110105175926.GA2101@vniz.net> <20110106024403.GB22349@vniz.net> <8A69DE05-A433-4D40-8E63-8F06215606F2@samsco.org> <4D2602E8.6080609@bsdimp.com> <1BD6D137-8BBD-4EBE-A5B0-3B716B78BA08@mac.com> To: Jeff Roberson X-Mailer: Apple Mail (2.1082) Cc: freebsd-arch@FreeBSD.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 22:50:13 -0000 On Jan 6, 2011, at 2:07 PM, Jeff Roberson wrote: > On Thu, 6 Jan 2011, Marcel Moolenaar wrote: > >> >> On Jan 6, 2011, at 9:59 AM, Warner Losh wrote: >> >>> On 01/05/2011 21:00, Scott Long wrote: >>>> I'm sorry, this simply hasn't been true in my experience. I've worked with companies that have decided to support FreeBSD, and I've worked with companies that have decided not to support FreeBSD. Emulation has never been used as an excuse to not support FreeBSD. It's purely a cost/benefit decision. >>> >>> Yes. I've been on the inside of a few of them, even seeing some business case figures. These usually say that for the segment that company X is going after for product Y can sell 1000 units to customer W and another Z000 to the market as it emerges over the next 2 years. 1000 units gets them $200k profit, development costs are $100k for developer time, test time, etc. Z is large, so potential revenue form this project is in the millions, with a guaranteed small initial profit. Decision: go. >> >> But one cannot ignore the fact that a compatibility layer allows companies >> to support FreeBSD at lower development cost by eliminating the native port >> and instead just focus on the qualifying their Linux support within the >> emulation layer. If decisions are purely cost/benefit, then a compatibility >> layer reduces the cost, hence increases the benefit so if FreeBSD is at all >> a consideration, it will be through emulation. >> >> Is this what we want promote? >> >> Also, the experience that you and Scott have may be biased. You won't want >> to work for a company that is inherently Linux centric, right? Likewise, >> Linux-centric companies may be more interested in hiring Linux hackers and >> not FreeBSD hackers, right? So, doesn't that mean that your experience is >> ipso facto biased towards the companies that would even consider FreeBSD >> to begin with? >> What about those companies that couldn't care less about FreeBSD? Those >> for which cost and benefit are absolutes? >> I very much doubt that they are going to invest in an entirely new OS -- >> in order to support it natively, when their Linux-centric development teams >> can do the same using emulation? >> >> What I'm saying is this: do we really have an abjective view or are we >> biased towards FreeBSD-friendliness simply because we are FreeBSD hackers >> discussing on a FreeBSD email list and working for companies that like >> FreeBSD in some form or shape? > > Hey Marcel, Hi jeff, First off: thanks for a perfect response. I know my experience in this regard is limited and I really needed to hear a bit more details than "in my experience", followed by a claim I couldn't validate. > My view is that companies needing a platform will reject FreeBSD for lack of features or lack of marketing clout. Linux has a stronger brand and people may want to advertise that association. IB is one feature that has cost us users, as is virtualization, and perhaps some driver support. I can relate to that. Virtualization is becoming the achilles' heel within Juniper. I can hopefully share more on that in the near future... > I believe FreeBSD is an organization of principals and values that make it excellent. I understand how this is a compromise and even I myself will tell you it is. However, we need to keep in sight that we won't all get to continue doing what we love if we don't keep working to make it as appealing as possible. We are in every way the underdog the underdog doesn't have the clout to dictate terms. Agreed. FWIW: I support what you've done on this basis. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Thu Jan 6 23:15:20 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82CCD106564A for ; Thu, 6 Jan 2011 23:15:20 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 450828FC15 for ; Thu, 6 Jan 2011 23:15:20 +0000 (UTC) Received: by vws9 with SMTP id 9so6868032vws.13 for ; Thu, 06 Jan 2011 15:15:19 -0800 (PST) Received: by 10.220.195.65 with SMTP id eb1mr7483440vcb.35.1294355718160; Thu, 06 Jan 2011 15:15:18 -0800 (PST) Received: from [10.0.1.198] ([72.253.42.56]) by mx.google.com with ESMTPS id a6sm1904771vcm.46.2011.01.06.15.15.15 (version=SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 15:15:17 -0800 (PST) Date: Thu, 6 Jan 2011 13:17:57 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: "Bjoern A. Zeeb" In-Reply-To: <20110106222945.R14966@maildrop.int.zabbadoz.net> Message-ID: References: <82826.1294088199@critter.freebsd.dk> <20110106140722.E14966@maildrop.int.zabbadoz.net> <4D260E0D.8080003@bsdimp.com> <20110106222945.R14966@maildrop.int.zabbadoz.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@FreeBSD.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 23:15:20 -0000 On Thu, 6 Jan 2011, Bjoern A. Zeeb wrote: > On Thu, 6 Jan 2011, Warner Losh wrote: > >> On 01/06/2011 07:17, Bjoern A. Zeeb wrote: >>> On Mon, 3 Jan 2011, Jeff Roberson wrote: >>> >>>> Unfortunately it would create quite a lot of code churn as there are >>>> relatively few that are minorly different. You can page through the >>>> wrapper code if you're interested. >>>> >>>> http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/ofed/include/linux/ >>> >>> One thing I am not too sure about is sys/ofed. Given the entire >>> discussions it might well be better suited in sys/contrib/ofed under >>> the assumtion that the code is mostly maintained outside our tree and >>> we get in occational updates. >> >> If you look at what Jeff has done, you'll see that the external code >> follows our standards of residing in sys/contrib/ofed, while the code that >> glues it into the tree is in sys/ofed. > > I might just be too blind to see an ofed there: > http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/contrib/ > > It's rdma I guess. It feels just awkward to have the glue in > sys/mumble rather than completely bundled in sys/contrib/ofed/** like > we do for ipfilter, pf, ... to my understanding. > > The real glue into our stack, I assume, sits in net*/* mostly. That rdma was existing for iwarp stubs. I expect it will go away when chelsio finishes integrating with the ofed work for full iwarp support. I have the code in sys/ofed but it could easily be moved to sys/contrib/ofed. That is probably more appropriate. I was thinking just ofed as it was another native network like netinet, netatalk, netipx, etc. It perhaps would have been more appropriate to call it infiniband/. The extra directory is not a real problem either way. > > >>> I guess similarly things in user space might go to contrib as well? >> src/contrib is for code that's maintained outside the source tree that we >> adapt. > > Are all user space tools hand-rolled or are they ported over as well? > All userspace tools are ported in contrib/ofed. Only minor changes were required to build on BSD. We have a very complete stack. I know of no feature that is missing. > > Maybe I should wait till Jeff will post the diff to see. I don't mind discussing the technical points further at all. I just don't feel I have any more to add about the more existential topics. Thanks, Jeff > > /bz > > -- > Bjoern A. Zeeb You have to have visions! > Going to jail sucks -- All my daemons like it! > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html > _______________________________________________ > 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 Jan 6 23:40:07 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 752761065674 for ; Thu, 6 Jan 2011 23:40:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id EFEF68FC13 for ; Thu, 6 Jan 2011 23:40:06 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 125D241C7AD; Fri, 7 Jan 2011 00:40:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id qZaKtBP-t1ff; Fri, 7 Jan 2011 00:40:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 9355B41C7AC; Fri, 7 Jan 2011 00:40:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 21F494448F3; Thu, 6 Jan 2011 23:38:00 +0000 (UTC) Date: Thu, 6 Jan 2011 23:38:00 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Jeff Roberson In-Reply-To: Message-ID: <20110106233726.M14966@maildrop.int.zabbadoz.net> References: <82826.1294088199@critter.freebsd.dk> <20110106140722.E14966@maildrop.int.zabbadoz.net> <4D260E0D.8080003@bsdimp.com> <20110106222945.R14966@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@FreeBSD.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 23:40:07 -0000 On Thu, 6 Jan 2011, Jeff Roberson wrote: > On Thu, 6 Jan 2011, Bjoern A. Zeeb wrote: > >> On Thu, 6 Jan 2011, Warner Losh wrote: >> >>> On 01/06/2011 07:17, Bjoern A. Zeeb wrote: >>>> On Mon, 3 Jan 2011, Jeff Roberson wrote: >>>> >>>>> Unfortunately it would create quite a lot of code churn as there are >>>>> relatively few that are minorly different. You can page through the >>>>> wrapper code if you're interested. >>>>> >>>>> http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/ofed/include/linux/ >>>> >>>> One thing I am not too sure about is sys/ofed. Given the entire >>>> discussions it might well be better suited in sys/contrib/ofed under >>>> the assumtion that the code is mostly maintained outside our tree and >>>> we get in occational updates. >>> >>> If you look at what Jeff has done, you'll see that the external code >>> follows our standards of residing in sys/contrib/ofed, while the code that >>> glues it into the tree is in sys/ofed. >> >> I might just be too blind to see an ofed there: >> http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/contrib/ >> >> It's rdma I guess. It feels just awkward to have the glue in >> sys/mumble rather than completely bundled in sys/contrib/ofed/** like >> we do for ipfilter, pf, ... to my understanding. >> >> The real glue into our stack, I assume, sits in net*/* mostly. > > That rdma was existing for iwarp stubs. I expect it will go away when > chelsio finishes integrating with the ofed work for full iwarp support. > > I have the code in sys/ofed but it could easily be moved to sys/contrib/ofed. > That is probably more appropriate. I was thinking just ofed as it was > another native network like netinet, netatalk, netipx, etc. It perhaps would > have been more appropriate to call it infiniband/. > > The extra directory is not a real problem either way. > >> >> >>>> I guess similarly things in user space might go to contrib as well? >>> src/contrib is for code that's maintained outside the source tree that we >>> adapt. >> >> Are all user space tools hand-rolled or are they ported over as well? >> > > All userspace tools are ported in contrib/ofed. Only minor changes were > required to build on BSD. We have a very complete stack. I know of no > feature that is missing. > >> >> Maybe I should wait till Jeff will post the diff to see. > > I don't mind discussing the technical points further at all. I just don't > feel I have any more to add about the more existential topics. I think I am fine with what you are saying:) Thanks a lot! /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-arch@FreeBSD.ORG Fri Jan 7 11:02:43 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 140C4106564A for ; Fri, 7 Jan 2011 11:02:43 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id C05DD8FC18 for ; Fri, 7 Jan 2011 11:02:42 +0000 (UTC) Received: by qwj9 with SMTP id 9so17007701qwj.13 for ; Fri, 07 Jan 2011 03:02:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.220.133 with SMTP id hy5mr21839293qcb.269.1294396564460; Fri, 07 Jan 2011 02:36:04 -0800 (PST) Received: by 10.229.233.209 with HTTP; Fri, 7 Jan 2011 02:36:04 -0800 (PST) X-Originating-IP: [109.174.58.22] In-Reply-To: References: Date: Fri, 7 Jan 2011 16:36:04 +0600 Message-ID: From: Max Khon To: Jeff Roberson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 11:02:43 -0000 Jeff, On Tue, Jan 4, 2011 at 2:31 AM, Jeff Roberson wrote: Some of you may have seen my infiniband work proceed in svn. It is coming > to a close soon and I will be integrating it into current. I have a few > patches to the kernel to send for review but I wanted to bring up the KPI > wrapper itself for discussion. > > The infiniband port has been done by creating a 10,000 line KPI > compatability layer. With this layer the vast majority of the driver code > runs unmodified. The exceptions are anything that interfaces with skbs and > most of the code that deals with network interfaces. > > Some examples of things supported by the wrapper: > > atomics, types, bitops, byte order conversion, character devices, pci > devices, dma, non-device files, idr tables, interrupts, ioremap, hashes, > kobjects, radix trees, lists, modules, notifier blocks, rbtrees, rwlock, > rwsem, semaphore, schedule, spinlocks, kalloc, wait queues, workqueues, > timers, etc. > > Obviously a complete wrapper is impossible and I only implemented the > features that I needed. The build is accomplished by pointing the linux > compatible code at sys/ofed/include/ which has a simulated linux kernel > include tree. There are some config(8) changes to help this along as well. > > I have seen that some attempt at similar wrappers has been made elsewhere. > I wonder if instead of making each one tailored to individual components, > which mostly seem to be filesystems so far, should we put this in a central > place under compat somewhere? Is this project doomed to be tied to a single > consumer by the specific nature of it? > DAHDI/FreeBSD project will surely benefit from having your linux KAPI compat layer in the tree. I even considered to use your KAPI compat layer but decided to stay with own linux KAPI emulation layer (much thinner, but much less featured and complete when compared to your work) because your work requires kernel modifications (AFAIR there were changes at least in sleepqueue FreeBSD KAPI) but I needed support for FreeBSD 7/8 without requiring end users to apply kernel patches. I will definitely use your KAPI compat layer once it is made available in the tree. Also, it may have sense to have a backport for older FreeBSD releases (or have it as a FreeBSD port) and to commit those kernel modifications to earlier releases. For those that think that linux KAPI compat may distract developers from FreeBSD: Digium folks would not like to have OS-independent layer + Linux or FreeBSD layers below it in their DAHDI source tree because they plan to have their code merged into Linux mainline some time and it would be much harder (if not completely impossible) to have it in mainline _with_ KAPI abstraction layer. So I did not have other choice than having linux KAPI compat layer in the end. Max From owner-freebsd-arch@FreeBSD.ORG Fri Jan 7 15:15:22 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 804FE106566B for ; Fri, 7 Jan 2011 15:15:22 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 2EC138FC18 for ; Fri, 7 Jan 2011 15:15:22 +0000 (UTC) Received: from grapeape2.cs.duke.edu (grapeape2.cs.duke.edu [152.3.140.76]) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id p07FFLVT013298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jan 2011 10:15:21 -0500 (EST) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu p07FFLVT013298 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1294413321; bh=+7pms0GeDu0RNQW6KoUAH+QDTkZ5XC9Wz4J7PMn8p0Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=nIZuBIhvhjvPmsqxPBMhY+nN6k4xcXjfezEIoiN4lUdjRQ6Ux0OBG4ni37TuzrT9M beirLh5xK2OdPwSxvnA7xZUIfqua1g/uKibnFm7lscl6w9svM/eWMuv3H7GBpyx5vN WGX9rdoMp7ggcSNbhK10lnVfM38HOzhMQ1LyrP/VPbxqEk/jojtwAOJJ3Yyj0G3oBU Aucsp8DaRpQblfd2IQo5mSVwVwlZT/BJIrlSnzRULO8orcIOASYgR3Vcx8R5FR99kZ 83ST7nf8wsNA8ABL7llBgOeRhdGFEBRU86bjTcUFMLk+9iApPju6mVjhYkZVT/ghL3 M6UdKZFUatupA== Received: (from gallatin@localhost) by grapeape2.cs.duke.edu (8.12.10/8.12.10/Submit) id p07FFKam010007; Fri, 7 Jan 2011 10:15:20 -0500 (EST) Date: Fri, 7 Jan 2011 10:15:20 -0500 From: Andrew Gallatin To: Jeff Roberson Message-ID: <20110107151520.GA9925@grapeape2.cs.duke.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: SunOS 5.10 on an sun4u User-Agent: Mutt/1.5.13 (2006-08-11) Cc: arch@freebsd.org Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 15:15:22 -0000 This looks fantastic! Jeff Roberson [jroberson@jroberson.net] wrote: > I have seen that some attempt at similar wrappers has been made elsewhere. > I wonder if instead of making each one tailored to individual components, > which mostly seem to be filesystems so far, should we put this in a > central place under compat somewhere? Is this project doomed to be tied > to a single consumer by the specific nature of it? I'd prefer to see it in a central place so that other projects could add to the interfaces. For example, I've long wanted to get the V4L DVB tree compiling on FreeBSD, but I've never had the time to start the project. I imagine it has just gotten 90% easier. > Other comments or concerns? What version of the linux kernel do you target? I've just been browsing the SVN repo, but I did not see a linux/version.h with a #define LINUX_VERSION_CODE in it. That suggests there is no chance of getting "simple", single file character drivers with build instructions like make -C /lib/modules/`uname -r`/build SUBDIRS=`pwd` to work. I guess there a more complex glue layer for building? For people complaining about linux API churn -- there is a stable linux KABI via RHEL. Each major RHEL release has a symbol whitelist that they promise to maintain binary compat for across the lifetime of the major release (many years). I honestly think the "holy grail" would be to implement enough of the RHEL6 KABI that you could just load binary linux drivers built on RHEL6 the same way we load NDIS drivers. BTW, is OFED KABI compliant on RHEL? Eg, can you build an OFED DUT that will work across RHEL revisions, or is it tied to symbols that are not on the kabi whitelist? At work, I maintain our linux driver (and FreeBSD & all *nix drivers). For a "simple" 10G NIC, we're at about 1K LOC for shims to allow us to compile on later 2.4 and all 2.6 kernels. So I'm impressed at "just" 10K LOC for a shim layer between FreeBSD & Linux. ESX uses slightly modified linux drivers via a shim layer. So there is a precedent for this & they are a much fatter GPL target. FWIW, I've often wished for a native ESX interface, since their shim layer is "not quite" linux, and takes features from different versions. I don't see us dropping native FreeBSD support even if the shim layer was as good as ESX's. Drew From owner-freebsd-arch@FreeBSD.ORG Fri Jan 7 15:26:27 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D526106564A; Fri, 7 Jan 2011 15:26:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 99C738FC13; Fri, 7 Jan 2011 15:26:26 +0000 (UTC) Received: by wyf19 with SMTP id 19so17665977wyf.13 for ; Fri, 07 Jan 2011 07:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=SzGUJPJVzhDV+PqgpNyofih1qgSv0YxG1L1ay05c1Go=; b=jaGmJq4IkkeM7cRatsH3al2XlpWm2p8ArtB3RZF1r/bpiQNajZTRawWQlFKKYGEJJR TxJgSs0XMSBaEChviQzUNptfe3moPs9kHUVydnhL64wVPMLkVAg1TFDgepUhJxfTmudm fliECiYv6/ciTaeoE0sejWKgJu6v5+t2YDqfU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=acmirXaT1a98b5H2KF0H6pmE5Er6k56xaiWUxoec8KiwZo45HrPAhT6asD/79V2bZx B6TzkDYZ5q8Cpoi/I8Higu/Y+iBfeMqgg4Bk1llLFOhC5NtkCWd02csewiNLedJtILb2 5g6nO0EwFay8yKCkqSiQyvrgUyqCBzRSgJnEw= MIME-Version: 1.0 Received: by 10.216.181.141 with SMTP id l13mr16486698wem.22.1294413981656; Fri, 07 Jan 2011 07:26:21 -0800 (PST) Received: by 10.216.159.201 with HTTP; Fri, 7 Jan 2011 07:26:21 -0800 (PST) Date: Fri, 7 Jan 2011 23:26:21 +0800 Message-ID: From: Adrian Chadd To: Sam Leffler Content-Type: text/plain; charset=ISO-8859-1 Cc: Bernhard Schmidt , freebsd-arch@freebsd.org, Rui Paulo , FreeBSD Net Subject: net80211 11n fixes: Begin handling 11n channel status flags X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 15:26:27 -0000 Hi all, Here's the first 11n related patch to push into -HEAD. This adds handling 11na/11ng HT/20 channel flags when scanning for access points. Without this patch, 11na/11ng APs aren't considered for association. I'd like to push this into -HEAD and a modified version of it into -8. With this, my modified ath+hal driver can be built as a module and installed for testing without any further kernel changes. http://people.freebsd.org/~adrian/ath/net80211_11n_fixes_1.diff I'll look at getting HT/40 modes working at a later date. Thanks, Adrian From owner-freebsd-arch@FreeBSD.ORG Fri Jan 7 23:13:37 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DB44106566B for ; Fri, 7 Jan 2011 23:13:37 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6888D8FC14 for ; Fri, 7 Jan 2011 23:13:37 +0000 (UTC) Received: by iwn39 with SMTP id 39so17922977iwn.13 for ; Fri, 07 Jan 2011 15:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=OpP1j5oObTUo5Nf+ET+lCgItdgje5CQr5Vp4T8IzbKA=; b=pGSwCTvfYK8Fzqpteey+uRtz+nT17G1mmzFKE7dMWqoF7AulqkOvgvQzktfHod6D2H y6hb06udsmLqYE9AdiH/Wbml3T6XG95NyPyGCVXYaeERA+zLGYcjT5VoO+OczNbvLbId RcwOXje1xiSjjPiF7fAA4PWzVddZELIP5JSGU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=iYQw/V0SInTCLCXBqbpDMl/ECbXypDQ1rzhBX5KkHB/C1N5p5eVpeXXb+KTwAxlzFw yflKhYFIXtfUFQiHMDndn4E1zY7JUGr8At4t894V8YdTzMAiFN5TJXo4i331ZA+u+Rvq ia24fHAsdQoN6MTc0N485RAcKgecSnpbgpjjo= MIME-Version: 1.0 Received: by 10.231.40.3 with SMTP id i3mr24902711ibe.129.1294442016904; Fri, 07 Jan 2011 15:13:36 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.231.160.147 with HTTP; Fri, 7 Jan 2011 15:13:36 -0800 (PST) Date: Fri, 7 Jan 2011 15:13:36 -0800 X-Google-Sender-Auth: WhYX7KJBD0CWk3XxYySpdmDS19Y Message-ID: From: mdf@FreeBSD.org To: FreeBSD Arch Content-Type: text/plain; charset=ISO-8859-1 Subject: SYSCTL type safety X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 23:13:37 -0000 Long ago at Isilon we ran into a problem with some sysctls in the stock FreeBSD tree using the wrong type, like SYSCTL_ULONG on an int, or just mixing unsigned/signed. We have a patch that uses transparent unions to cause a compile-time error with a type mismatch. For a while I was hesitant to push this since I wasn't sure about the use of a gcc extension, but the SYSCTL fixes and the way to keep them sane came up again when we started building a new driver locally, and the build failed until we fixed some SYSCTL stuff. Anyways, the patch to sys/sysctl.h is at http://people.freebsd.org/~mdf/bsd-sysctl-type-safety.diff Please chime in if you think this is a bad thing to add to the tree. I will of course ensure a make universe passes locally before committing this part. The plan is to change the SYSCTL use, not the base type of the variable, for any conflicts found. Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Sat Jan 8 03:53:39 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E297910656CF; Sat, 8 Jan 2011 03:53:39 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id B54DF8FC13; Sat, 8 Jan 2011 03:53:39 +0000 (UTC) Received: from cpe-74-66-24-70.nyc.res.rr.com ([74.66.24.70] helo=[192.168.1.119]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PbPXU-00046I-4F; Fri, 07 Jan 2011 22:32:24 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: George Neville-Neil In-Reply-To: Date: Fri, 7 Jan 2011 22:32:23 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: To: mdf@FreeBSD.org X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: FreeBSD Arch Subject: Re: SYSCTL type safety X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 03:53:40 -0000 On Jan 7, 2011, at 18:13 , mdf@FreeBSD.org wrote: > Long ago at Isilon we ran into a problem with some sysctls in the > stock FreeBSD tree using the wrong type, like SYSCTL_ULONG on an int, > or just mixing unsigned/signed. We have a patch that uses transparent > unions to cause a compile-time error with a type mismatch. For a > while I was hesitant to push this since I wasn't sure about the use of > a gcc extension, but the SYSCTL fixes and the way to keep them sane > came up again when we started building a new driver locally, and the > build failed until we fixed some SYSCTL stuff. > > Anyways, the patch to sys/sysctl.h is at > > http://people.freebsd.org/~mdf/bsd-sysctl-type-safety.diff > > Please chime in if you think this is a bad thing to add to the tree. > I will of course ensure a make universe passes locally before > committing this part. The plan is to change the SYSCTL use, not the > base type of the variable, for any conflicts found. > I have read, but not tried the patch. I definitely like the idea. Best, George From owner-freebsd-arch@FreeBSD.ORG Sat Jan 8 03:58:29 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FD4E10656A6; Sat, 8 Jan 2011 03:58:29 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id EFF638FC13; Sat, 8 Jan 2011 03:58:28 +0000 (UTC) Received: by wyf19 with SMTP id 19so18215627wyf.13 for ; Fri, 07 Jan 2011 19:58:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=mw6LXB1rb813Qr1bE3mZRDassAonuCUS07eJrpWliHM=; b=ni7WaaJCsVl3CnNSWgq2qjQiKBNBpnoKz0azEDloQbGz1MDGm5mbxBFS7zD8/UqHaz 7mQzJZzhJew+HEhVpGiuRwfCDx6DWmcC0ApwSnZ2b82dH+Ws2FWg7e/wVxzdyUHeq3Wm GPQXdlACF82hEMTE2BSxGb9TwEGQ5kgxD7b2w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=SJ6y+wqt+DYdjCP20g80fiYvgWf2mzuxZQSLJUnhXAyiWWTFvssITz65m+0hbKPo+p OjSpGiXr7uDK7AApGD4O4SjEHqgAQHWYaUg7H9jq6+gCedVC2che5LtimaAXiuqlpkAe R8mPzlxzjvg4rOy5vDBBjwChj/48+/Qx8oTb8= MIME-Version: 1.0 Received: by 10.216.191.215 with SMTP id g65mr1825290wen.16.1294459107459; Fri, 07 Jan 2011 19:58:27 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.254.226 with HTTP; Fri, 7 Jan 2011 19:58:27 -0800 (PST) In-Reply-To: References: Date: Fri, 7 Jan 2011 19:58:27 -0800 X-Google-Sender-Auth: -fCzRAj4_rBtYr5Y2ahUWNdIgXM Message-ID: From: Garrett Cooper To: George Neville-Neil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mdf@freebsd.org, FreeBSD Arch Subject: Re: SYSCTL type safety X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 03:58:29 -0000 On Fri, Jan 7, 2011 at 7:32 PM, George Neville-Neil wrote: > > On Jan 7, 2011, at 18:13 , mdf@FreeBSD.org wrote: > >> Long ago at Isilon we ran into a problem with some sysctls in the >> stock FreeBSD tree using the wrong type, like SYSCTL_ULONG on an int, >> or just mixing unsigned/signed. =A0We have a patch that uses transparent >> unions to cause a compile-time error with a type mismatch. =A0For a >> while I was hesitant to push this since I wasn't sure about the use of >> a gcc extension, but the SYSCTL fixes and the way to keep them sane >> came up again when we started building a new driver locally, and the >> build failed until we fixed some SYSCTL stuff. >> >> Anyways, the patch to sys/sysctl.h is at >> >> http://people.freebsd.org/~mdf/bsd-sysctl-type-safety.diff >> >> Please chime in if you think this is a bad thing to add to the tree. >> I will of course ensure a make universe passes locally before >> committing this part. =A0The plan is to change the SYSCTL use, not the >> base type of the variable, for any conflicts found. >> > > I have read, but not tried the patch. =A0I definitely like the idea. +1 (haven't tried, like the idea). Similar needs to be done for tunables as well. Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Sat Jan 8 22:54:44 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4348106564A; Sat, 8 Jan 2011 22:54:44 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id ADB848FC13; Sat, 8 Jan 2011 22:54:44 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 44B9D5811B; Sat, 8 Jan 2011 16:54:44 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id 0jHgQpAiqADI; Sat, 8 Jan 2011 16:54:44 -0600 (CST) Received: from wanderer.tachypleus.net (unknown [76.210.75.5]) by mail.icecube.wisc.edu (Postfix) with ESMTP id CBB7258119; Sat, 8 Jan 2011 16:54:43 -0600 (CST) Message-ID: <4D28EB32.9090807@freebsd.org> Date: Sat, 08 Jan 2011 16:54:42 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101227 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org, freebsd-sysinstall@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: BSDInstall ISO images X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 22:54:44 -0000 I've spent some time integrating bsdinstall into startup of install CDs, mostly related to building useful live-CD-based installers. An i386 image can be found here (other architectures may follow, as my very slow DSL line permits): http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110108.iso.bz2 The source for this can be found at: svn://svn.freebsd.org/base/user/nwhitehorn/bsdinstall The bits related to live CD usage are the testsystem.sh and rc.local files. Instead of running sysinstall as an init replacement, I have written a small rc.local script that gives the user the option to either start the installer, open a single-user-mode style shell, or to continue to boot to a multi-user live CD. Also, instead of the md root used by sysinstall, this just boots from the CD directly. This prevents the need for sysinstall's media selection, since the distribution files are in the mounted root file system. I would appreciate any comments or test results. -Nathan