From owner-freebsd-arch@FreeBSD.ORG Sun Jan 23 03:28: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 74D59106566C for ; Sun, 23 Jan 2011 03:28:27 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 2D1E18FC12 for ; Sun, 23 Jan 2011 03:28:26 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PgqOK-0002N7-8G for freebsd-arch@freebsd.org; Sun, 23 Jan 2011 04:13:24 +0100 Received: from 89-164-107-17.dsl.iskon.hr ([89.164.107.17]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Jan 2011 04:13:24 +0100 Received: from ivoras by 89-164-107-17.dsl.iskon.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Jan 2011 04:13:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Sun, 23 Jan 2011 04:12:51 +0100 Lines: 26 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 89-164-107-17.dsl.iskon.hr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 In-Reply-To: Subject: Re: Capsicum -- 9.x merge in sight 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, 23 Jan 2011 03:28:27 -0000 On 22.1.2011 16:25, Robert Watson wrote: > > Dear all: > > As many of you will now have heard, the Computer Laboratory at the > University of Cambridge and Google have been collaborating for the last > few years on a security research project called Capsicum. It consists of > a set of extensions to the POSIX API adding a new "capability mode", > "capabilities", "process descriptors", and several other additions > required to implement a capability-oriented sandbox model in UNIX. These Hello, How is Capsicum positioned, from user & admin perspective, when compared to the MAC work on FreeBSD and SELinux on Linux? Is one the superset of another, will one obsolete another? > The current plan is *not* to merge > libcapsicum, a userspace library used by certain applications to > construct sandboxes, as we feel the API remains insufficiently mature at > this point. I vaguely remember that the MAC work has never gotten as popular on FreeBSD as SELinux on Linux because it lacked user-oriented tools and documentation - is there a danger Capsicum will end up the same? From owner-freebsd-arch@FreeBSD.ORG Sun Jan 23 03:28:28 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 860F1106564A for ; Sun, 23 Jan 2011 03:28:28 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 41CE38FC16 for ; Sun, 23 Jan 2011 03:28:28 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PgqUm-0004xc-Qu for freebsd-arch@freebsd.org; Sun, 23 Jan 2011 04:20:04 +0100 Received: from 89-164-107-17.dsl.iskon.hr ([89.164.107.17]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Jan 2011 04:20:04 +0100 Received: from ivoras by 89-164-107-17.dsl.iskon.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Jan 2011 04:20:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Sun, 23 Jan 2011 04:17:12 +0100 Lines: 11 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 89-164-107-17.dsl.iskon.hr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 Subject: UFS & serialization 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, 23 Jan 2011 03:28:28 -0000 I'm not an Oracle user but I've come across an interesting article about Oracle's interaction with Solaris UFS: http://www.c0t0d0s0.org/archives/7146-Direct.html (as well as some nice DTrace examples). Could someone comment about how FreeBSD UFS fares compared to Solaris? AFAIK there is one-writer-multiple-readers semantics, and O_DIRECT in open(2) but it doesn't modify locking behaviour? From owner-freebsd-arch@FreeBSD.ORG Sun Jan 23 15:56: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 48BAB106564A; Sun, 23 Jan 2011 15:56:14 +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 211D68FC19; Sun, 23 Jan 2011 15:56:14 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id B9B3D46B09; Sun, 23 Jan 2011 10:56:13 -0500 (EST) Date: Sun, 23 Jan 2011 15:56:13 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ivan Voras In-Reply-To: Message-ID: References: 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: Capsicum -- 9.x merge in sight 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, 23 Jan 2011 15:56:14 -0000 On Sun, 23 Jan 2011, Ivan Voras wrote: >> As many of you will now have heard, the Computer Laboratory at the >> University of Cambridge and Google have been collaborating for the last few >> years on a security research project called Capsicum. It consists of a set >> of extensions to the POSIX API adding a new "capability mode", >> "capabilities", "process descriptors", and several other additions required >> to implement a capability-oriented sandbox model in UNIX. These > > Hello, > > How is Capsicum positioned, from user & admin perspective, when compared to > the MAC work on FreeBSD and SELinux on Linux? Is one the superset of > another, will one obsolete another? This is a point addressed in some detail in the paper, which considers the relationship between Capsicum and other security models. Capsicum is really addressed at the application author, whereas MAC models are typically addressed at a blend of system integrators and system administrators. As a result, users mostly benefit from Capcisum transparently. We argue that Capsicum complements other security techniques, such as MAC, DAC, etc, which serve different roles in system design. As a result, Capsicum should be entirely transparent to end users -- except that vulnerabilities in applications become less critical -- which is quite different from what you see in various MAC models, including the TE model shipped with SELinux. >> The current plan is *not* to merge libcapsicum, a userspace library used by >> certain applications to construct sandboxes, as we feel the API remains >> insufficiently mature at this point. > > I vaguely remember that the MAC work has never gotten as popular on FreeBSD > as SELinux on Linux because it lacked user-oriented tools and documentation > - is there a danger Capsicum will end up the same? There's a long philosophical discussion to have on this topic, but suffice to say that the success or failure of Capsicum will depend on its adoption by application writers. The starting point for applications is our own application suite: the tools, daemons, etc, in our own operating system, and it seems we have a lot of interest in our community in taking that task up. In as much as we can convince other OS authors that Capsicum is a good idea, and that they should adopt it, that will help a great deal. Discussions in the Chromium, NetBSD, etc, communities are promising in this sense, but a lot more has to be done. One of the hardest problems in this area is one that Capsicum makes accessible, but doesn't solve: how to improve programmability for compartmentalisation and privielge separation. Today, that programmability problem is significant, but there are also quite a few interested parties working on it, and also existing components that use compartmentalisation -- Chromium being one of them, and hence a good case study since it allows us to compare different models from a programmer perspective. If you haven't yet read the paper, please do so, as I think it will help answer some of these questions. You may remember, BTW, that while I was at NAI Labs, we had a project to port the SELinux FLASK/TE parts to FreeBSD, and for a period, shipped an "sebsd.ko" kernel module implementing it using FreeBSD's MAC Framework. We saw very little interest from the community, and part of the reason for that is that it's actually extremely difficult to use outside of narrow appliance-like environments (for which TE was originally designed). It turns out that TE is used with FreeBSD, however: McAfee's Sidewinder firewall (the origins of the TE implementation in SELinux began life at SCC, who were bought by McAfee a couple of years ago), and also the Kylin operating system, which actually does use our SEBSD work. If there's interest in updating SEBSD, the pieces are all in Perforce, and over the years, the MAC Framework has evolved in several ways that would make that easier. However, even in the Linux community, SELinux is considered fairly controversial and quite difficult to use. And, to be far, MAC is actually extensively used by FreeBSD consumers. You'll find the MAC Framework in use to host policies in many downstream products: Mac OS X, iPhoneOS (now iOS), Junos, McAfee's Sidewinder, nCircle's products, and so on. The thing that has made MAC most hard to deploy (and why Apple has found it easier to deploy) actually has to do with the weakness of semantics of path names in UNIX -- something that's a bit different in Mac OS X. That same weakness has made SELinux hard to deploy: you can't efficiently, effectively, and safely use path names for implicit security labelling, meaning that you end up having to manage security labels on objects. (There's some interesting literature on this, see DTE vs. TE). This same concern has hurt the effectiveness of auditing as well. But it's hard to fix: many UNIX file system concepts (hard links, flexible mounting model, files without names, etc) are embedded in the structures of critical applications. Robert From owner-freebsd-arch@FreeBSD.ORG Sun Jan 23 18:59: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 DC4D51065674; Sun, 23 Jan 2011 18:59:14 +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 225168FC1E; Sun, 23 Jan 2011 18:59:13 +0000 (UTC) Received: by wyf19 with SMTP id 19so3446770wyf.13 for ; Sun, 23 Jan 2011 10:59:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QHynQHNBWbY1/0b2kY4NQJOw4t9ktI2ZpY0IqDgDE3c=; b=L6zhfsibN4mEyNUHNSEA6jR71tBlLXbOmgGewPb+Lxb7Ouo7VmZlc0p2lu3CpVCc2g Zp+PfkXIYQQtLZ4jY3p2HWSqDeEnhJ+wDZFHggk4PPL1jmxmAePaE5rWqVilJ2AU3WSt m+qWzfJPrJU6smIh6fa5idjKBAxRJaFJVX7u4= 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; b=dCDX/r6gDcFbPtUdYRfuNH/rBTcwdowX+OZq6auh5ywAAyObjNi0aZJ8sHMAwUQxBn JEix+a5b//nEz199VmvT3dXx06drBIyY4umar2BYI4yzpQpjksyGQK91ZcmadN2RvQDS GSITbcHlXrXdgPIoSCzhTeo0GqVSGsJwMK55A= MIME-Version: 1.0 Received: by 10.216.30.137 with SMTP id k9mr2791549wea.31.1295809151699; Sun, 23 Jan 2011 10:59:11 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.254.226 with HTTP; Sun, 23 Jan 2011 10:59:11 -0800 (PST) In-Reply-To: <4D28EB32.9090807@freebsd.org> References: <4D28EB32.9090807@freebsd.org> Date: Sun, 23 Jan 2011 10:59:11 -0800 X-Google-Sender-Auth: 9S6oE1V9rd_zhuqe3D2xTDE39R8 Message-ID: From: Garrett Cooper To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-sysinstall@freebsd.org, freebsd-arch@freebsd.org Subject: Re: 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: Sun, 23 Jan 2011 18:59:15 -0000 On Sat, Jan 8, 2011 at 2:54 PM, Nathan Whitehorn wrote: > 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. Not sure if it matters anymore, but here are my comments: NOTE: this was using http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110118.iso.bz2 . 1. The i386 image (apparently) isn't compiled with ATACAM, etc support so opening /dev/cd0 always fails with ENODEV. 2. There's a lot of noise at bootup related to missing files. Putting in a dummy /etc/fstab, adding hostid_enable="NO", and setting hostname="" to a dummy value in rc.conf will help weed out some noise. 3. The initial dialog beeped when I first pressed the right key on my keyboard. Maybe hw.syscons.bell=0 would help? 4. Splitting up the Keyboard Menu into regions and providing human readable names would help. Partition Editor (I used Manual for the first try): 1. It would be helpful if the cursor was at the end of the textbox so that I didn't have to position the cursor at the end or press the delete key. 2. K is a bogus suffix for kilo-; k is correct. 3. Having a mountpoint for a bsdlabel partition doesn't make sense and is confusing. 4. Backing out of the Partition Manager and going back to the previous dialogs is impossible. 5. Noting that the values (freebsd-ufs, etc) map back to gpart driven values would be helpful. I exited the install and tried again on the command line. Couldn't conjure up the right gpart commands (manpage sucks for what I was looking for -- creating a new partition), I went back into the partedit command that was in /usr/libexec/ and entered in data manually . Committed my changes which threw me back into the prompt and then hit ^d to get back into the installer proper. The first run around failed for some odd reason (claimed it couldn't create boot/kernel.gz, or whatever, so there might be some error checking missing with mount, mkdir, etc). Chose restart, walked through the process again and chose manual, made sure the slice was properly configured for / and swap was setup, then continued. This time the install went through properly. Progress bar: I think you're on the right track by simplifying the install, but it could be polished to say: kernel world distribution (in what context is distribution? Is it configuration files, etc from `make distribution' ?) Configuring Network (etc) Seems like this could have been done earlier on to shrink the CD size down a bit. Add Users (YAY! something that finally works) - Prompts seem ok. - Login class - getting too specific IMO; this should be done after the first boot. - Home directory - /usr/home was the traditional home directory root for BSD I thought. - Home directory permissions - as an aside, what are the default? - Use password-based authentication - what other options are there other than not having a password or using a non-master.passwd backend like LDAP, etc? - Lock out account after creation - I would remove this; again, it seems like something that an admin can do after first boot. In general: Some of the dialogs are a bit small (like the DHCP status dialog). Enlarging them might help. Hopefully this feedback is helpful. Thanks! -Garrett From owner-freebsd-arch@FreeBSD.ORG Sun Jan 23 19:23:47 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 CBBF3106566B; Sun, 23 Jan 2011 19:23:47 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id 9B5CB8FC17; Sun, 23 Jan 2011 19:23:47 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LFH0010GPVM4B00@smtpauth2.wiscmail.wisc.edu>; Sun, 23 Jan 2011 13:23:46 -0600 (CST) Received: from comporellon.tachypleus.net (adsl-76-208-68-88.dsl.mdsnwi.sbcglobal.net [76.208.68.88]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LFH00E72PVFXS10@smtpauth2.wiscmail.wisc.edu>; Sun, 23 Jan 2011 13:23:40 -0600 (CST) Date: Sun, 23 Jan 2011 13:23:35 -0600 From: Nathan Whitehorn In-reply-to: To: Garrett Cooper Message-id: <4D3C8037.6040406@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.208.68.88 X-Spam-PmxInfo: Server=avs-12, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.1.23.191517, SenderIP=76.208.68.88 References: <4D28EB32.9090807@freebsd.org> User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101214 Thunderbird/3.1.7 Cc: freebsd-sysinstall@freebsd.org, freebsd-arch@freebsd.org Subject: Re: 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: Sun, 23 Jan 2011 19:23:48 -0000 On 01/23/11 12:59, Garrett Cooper wrote: > On Sat, Jan 8, 2011 at 2:54 PM, Nathan Whitehorn wrote: >> 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. > Not sure if it matters anymore, but here are my comments: It does very much matter. And all the CD environment stuff and the bsdinstall UI (which most of your comments are about) will be extremely similar to a merged pc-sysinstall installer. There is also a chance we will end up with bsdinstall basically as-is as the 9.0 installer if we can't get the merge done in time. > NOTE: this was using > http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110118.iso.bz2 > . > > 1. The i386 image (apparently) isn't compiled with ATACAM, etc support > so opening /dev/cd0 always fails with ENODEV. Yes. But it will fall back to acd0. This is for people with SCSI or USB CD drives. The real problem is if the CD ends up in [a]cd1, so cdboot needs a more robust mechanism here. > 2. There's a lot of noise at bootup related to missing files. Putting > in a dummy /etc/fstab, adding hostid_enable="NO", and setting > hostname="" to a dummy value in rc.conf will help weed out some noise. That's a good point. I've followed your suggestions. > 3. The initial dialog beeped when I first pressed the right key on my > keyboard. Maybe hw.syscons.bell=0 would help? Interesting. > 4. Splitting up the Keyboard Menu into regions and providing human > readable names would help. The keyboard menu just calls kbdmap, which is where the GUI comes from. The suggestion is good, but the change should be made there. > Partition Editor (I used Manual for the first try): > 1. It would be helpful if the cursor was at the end of the textbox so > that I didn't have to position the cursor at the end or press the > delete key. I'll see if there's a way to change this. > 2. K is a bogus suffix for kilo-; k is correct. This comes from humanize_number() in libutil, and would need to be changed there. > 3. Having a mountpoint for a bsdlabel partition doesn't make sense and > is confusing. That is true. Since the same form with the mountpoint also has the partition type, I could not find a clean way to make the last line go away. The same issue applies to swap. Ideas for this part of the UI would be very much appreciated. > 4. Backing out of the Partition Manager and going back to the previous > dialogs is impossible. Which previous dialogs do you mean? Do you want to back out of the partition manager to use the auto paritioner? If you press "Abort", you can restart the installation, which isn't so far off from that. There wasn't a whole lot of room at the bottom of the partitioner screen for a sysinstall-like "Auto Defaults" button. > 5. Noting that the values (freebsd-ufs, etc) map back to gpart driven > values would be helpful. There's a help line at the bottom of the screen with this information. Do you have a suggestion for making it more intuitive? Dialog doesn't support drop-down menus, which is what I would ordinarily use on this field. > I exited the install and tried again on the command line. Couldn't > conjure up the right gpart commands (manpage sucks for what I was > looking for -- creating a new partition), I went back into the > partedit command that was in /usr/libexec/ and entered in data > manually . Committed my changes which threw me back into the prompt > and then hit ^d to get back into the installer proper. The first run > around failed for some odd reason (claimed it couldn't create > boot/kernel.gz, or whatever, so there might be some error checking > missing with mount, mkdir, etc). Interesting. Let me know if you find out how this happened. > Chose restart, walked through the process again and chose manual, made > sure the slice was properly configured for / and swap was setup, then > continued. This time the install went through properly. > > Progress bar: > I think you're on the right track by simplifying the install, but it > could be polished to say: > > kernel > world > distribution (in what context is distribution? Is it configuration > files, etc from `make distribution' ?) That is exactly what "distribution" is. What goes in which files, and how many parts there are, is an interesting question. I think sysinstall splits up the base system a little too much. You suggest dropping the ".tgz" suffixes? > Configuring Network (etc) > > Seems like this could have been done earlier on to shrink the CD size > down a bit. Why would that shrink the CD size? It is done earlier if you need it to download the distfiles. I had placed it towards the end because it's part of a series of optional system configuration steps. > Add Users (YAY! something that finally works) > > - Prompts seem ok. > - Login class - getting too specific IMO; this should be done after > the first boot. > - Home directory - /usr/home was the traditional home directory root > for BSD I thought. > - Home directory permissions - as an aside, what are the default? > - Use password-based authentication - what other options are there > other than not having a password or using a non-master.passwd backend > like LDAP, etc? > - Lock out account after creation - I would remove this; again, it > seems like something that an admin can do after first boot. As you probably noticed, all this does (like the root password screen) is to run adduser in a chroot in the new system, so this is just the set of questions adduser asks. This could probably be prettified (and maybe simplified) somewhat. > In general: > > Some of the dialogs are a bit small (like the DHCP status dialog). > Enlarging them might help. All the dialogs just use the automatic sizing option in dialog. I think that its autosizing algorithm may be a little wonky, but I haven't looked too much at changing it. > Hopefully this feedback is helpful. It is! Please keep sending it. -Nathan From owner-freebsd-arch@FreeBSD.ORG Sun Jan 23 19:55:19 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 DBBC0106564A; Sun, 23 Jan 2011 19:55:19 +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 1D91B8FC12; Sun, 23 Jan 2011 19:55:18 +0000 (UTC) Received: by wyf19 with SMTP id 19so3474540wyf.13 for ; Sun, 23 Jan 2011 11:55:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MVeYxUkGbBDnaYJdtmOKVjSc3PQlqTndgdXELe1UrAg=; b=KfofZI+Ta624QlTVL+0FtzgtVKplbL59xpnZmuKQcLAot2hliCrwM3zfiPpTFYarMg 4zCeP6QcxhaptBghkdEs/i8zVEitSDKMV682CZNDXaIWB2x1wzz6evUbLh6f9x5b+2pO Fp+zOxuaVafYHP0hvBYzy4BTyzUfHm14DoU0A= 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=iGx4n0Igcc2FT7qkN8eiBU0z1lL+52Na6EzM4nzxXR06wc5m4H/BQB84K9m7YV0fuu ByAAxPsXAyvd/8SziZr9ruscgx1qDrX/JPouL/kZnlp7C3C2ukzdXigGbs0SMkfOODyc vjY0G1ML3w9BM8v+25NqPXMuD1/LjTlVtz1To= MIME-Version: 1.0 Received: by 10.216.141.75 with SMTP id f53mr2865084wej.16.1295812517427; Sun, 23 Jan 2011 11:55:17 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.254.226 with HTTP; Sun, 23 Jan 2011 11:55:17 -0800 (PST) In-Reply-To: <4D3C8037.6040406@freebsd.org> References: <4D28EB32.9090807@freebsd.org> <4D3C8037.6040406@freebsd.org> Date: Sun, 23 Jan 2011 11:55:17 -0800 X-Google-Sender-Auth: qlSpJCHYFB8BRtjdaOHIkWJxmpA Message-ID: From: Garrett Cooper To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-sysinstall@freebsd.org, freebsd-arch@freebsd.org Subject: Re: 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: Sun, 23 Jan 2011 19:55:20 -0000 On Sun, Jan 23, 2011 at 11:23 AM, Nathan Whitehorn wrote: > On 01/23/11 12:59, Garrett Cooper wrote: >> >> On Sat, Jan 8, 2011 at 2:54 PM, Nathan Whitehorn >> =A0wrote: >>> >>> I've spent some time integrating bsdinstall into startup of install CDs= , >>> mostly related to building useful live-CD-based installers. An i386 ima= ge >>> 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, th= is >>> 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. >> >> Not sure if it matters anymore, but here are my comments: > > It does very much matter. And all the CD environment stuff and the > bsdinstall UI (which most of your comments are about) will be extremely > similar to a merged pc-sysinstall installer. There is also a chance we wi= ll > end up with bsdinstall basically as-is as the 9.0 installer if we can't g= et > the merge done in time. Ok. >> NOTE: this was using >> http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110118.iso.bz2 >> . >> >> 1. The i386 image (apparently) isn't compiled with ATACAM, etc support >> so opening /dev/cd0 always fails with ENODEV. > > Yes. But it will fall back to acd0. This is for people with SCSI or USB C= D > drives. The real problem is if the CD ends up in [a]cd1, so cdboot needs = a > more robust mechanism here. I'm not so much worried about the failure as I am about the noise visible to the end user. A lot of stuff fails today silently, that should fail silently, and that's ok as long as it makes sense in the overall design of things. So again, printing that stuff is fine in verbose mode but doesn't make sense in a more polished / quiet mode that will be packaged as an install distribution to lots of users. >> 2. There's a lot of noise at bootup related to missing files. Putting >> in a dummy /etc/fstab, adding hostid_enable=3D"NO", and setting >> hostname=3D"" to a dummy value in rc.conf will help weed out some noise. > > That's a good point. I've followed your suggestions. Thanks! >> 3. The initial dialog beeped when I first pressed the right key on my >> keyboard. Maybe hw.syscons.bell=3D0 would help? > > Interesting. I didn't run in to this the second time, so it might be a bug with libdialog / the app. There's an option to have libdialog beep when you move the cursor, etc; I disabled the bell on the second go-around via the terminal, because I was getting tired of my PC speaker `cursing' at me when I hit tab / the arrow keys in the shell :P... >> 4. Splitting up the Keyboard Menu into regions and providing human >> readable names would help. > > The keyboard menu just calls kbdmap, which is where the GUI comes from. T= he > suggestion is good, but the change should be made there. Ok. >> Partition Editor (I used Manual for the first try): >> 1. It would be helpful if the cursor was at the end of the textbox so >> that I didn't have to position the cursor at the end or press the >> delete key. > > I'll see if there's a way to change this. Much appreciated :). If anything this should be done in libdialog, not in bsdinstall as it's more intuitive behavior that belongs there. >> 2. K is a bogus suffix for kilo-; k is correct. > > This comes from humanize_number() in libutil, and would need to be change= d > there. Ugh. Annoying... I can see what needs to be fixed next. >> 3. Having a mountpoint for a bsdlabel partition doesn't make sense and >> is confusing. > > That is true. Since the same form with the mountpoint also has the partit= ion > type, I could not find a clean way to make the last line go away. The sam= e > issue applies to swap. Ideas for this part of the UI would be very much > appreciated. Maybe graying out some fields would be helpful in the meantime? Not sure if that's possible with the new libdialog in an easy manner. >> 4. Backing out of the Partition Manager and going back to the previous >> dialogs is impossible. > > Which previous dialogs do you mean? Do you want to back out of the partit= ion > manager to use the auto paritioner? If you press "Abort", you can restart > the installation, which isn't so far off from that. There wasn't a whole = lot > of room at the bottom of the partitioner screen for a sysinstall-like "Au= to > Defaults" button. If I do into the manual partitioner and use the standard buttons (don't hit ^c, etc), then I couldn't get back to setting the hostname, going back and choosing the guided partitioner, etc. >> 5. Noting that the values (freebsd-ufs, etc) map back to gpart driven >> values would be helpful. > > There's a help line at the bottom of the screen with this information. Do > you have a suggestion for making it more intuitive? Dialog doesn't suppor= t > drop-down menus, which is what I would ordinarily use on this field. I'll look at that again in my next run-through. Before what was nice about sysinstall is that it placed the help diags further up on the screen, so visually I had to parse the text at the top first before I proceeded downward. [Most?] humans do top-down reading so I think that that concern should be pushed back to libdialog upstream. >> I exited the install and tried again on the command line. Couldn't >> conjure up the right gpart commands (manpage sucks for what I was >> looking for -- creating a new partition), I went back into the >> partedit command that was in /usr/libexec/ and entered in data >> manually . Committed my changes which threw me back into the prompt >> and then hit ^d to get back into the installer proper. The first run >> around failed for some odd reason (claimed it couldn't create >> boot/kernel.gz, or whatever, so there might be some error checking >> missing with mount, mkdir, etc). > > Interesting. Let me know if you find out how this happened. Will do. >> Chose restart, walked through the process again and chose manual, made >> sure the slice was properly configured for / and swap was setup, then >> continued. This time the install went through properly. >> >> Progress bar: >> I think you're on the right track by simplifying the install, but it >> could be polished to say: >> >> kernel >> world >> distribution (in what context is distribution? Is it configuration >> files, etc from `make distribution' ?) > > That is exactly what "distribution" is. What goes in which files, and how > many parts there are, is an interesting question. I think sysinstall spli= ts > up the base system a little too much. Agreed. But saying "Configuration files", etc is a bit easier for end-users to understand. > You suggest dropping the ".tgz" suffixes? Yup. It's just noise and people will ask questions if you switch to bzip2, lzma, 7z, etc. >> Configuring Network (etc) >> >> Seems like this could have been done earlier on to shrink the CD size >> down a bit. > > Why would that shrink the CD size? It is done earlier if you need it to > download the distfiles. I had placed it towards the end because it's part= of > a series of optional system configuration steps. Today I can download a bootonly ISO and pull down the package chunks I want instead of downloading a fat CD/DVD to do that. Network installs are nice. >> Add Users (YAY! something that finally works) >> >> - Prompts seem ok. >> - Login class - getting too specific IMO; this should be done after >> the first boot. >> - Home directory - /usr/home was the traditional home directory root >> for BSD I thought. >> - Home directory permissions - as an aside, what are the default? >> - Use password-based authentication - what other options are there >> other than not having a password or using a non-master.passwd backend >> like LDAP, etc? >> - Lock out account after creation - I would remove this; again, it >> seems like something that an admin can do after first boot. > > As you probably noticed, all this does (like the root password screen) is= to > run adduser in a chroot in the new system, so this is just the set of > questions adduser asks. This could probably be prettified (and maybe > simplified) somewhat. Hmmm.. ok. >> In general: >> >> Some of the dialogs are a bit small (like the DHCP status dialog). >> Enlarging them might help. > > All the dialogs just use the automatic sizing option in dialog. I think t= hat > its autosizing algorithm may be a little wonky, but I haven't looked too > much at changing it. Agreed. The new libdialog's algorithm for sizing windows is overly liberal in vertical space, but conservative in horizontal space, which is kind of annoying because 60 columns should be ok for an autosized line, and I hate scrolling up and down looking for what I need to read. >> Hopefully this feedback is helpful. > > It is! Please keep sending it. Ok :). Uh... lol. For starters I don't think that /usr/home should be 0700: $ ls -l /usr/home/ total 0 ls: /usr/home/: Permission denied $ ls -l /usr/ total 50 drwxr-xr-x 2 root wheel 7680 Jan 16 13:56 bin drwxr-xr-x 2 root wheel 512 Jan 16 13:56 games drwx------ 3 root wheel 512 Jan 23 02:58 home drwxr-xr-x 50 root wheel 5632 Jan 16 13:56 include drwxr-xr-x 6 root wheel 12800 Jan 16 13:56 lib drwxr-xr-x 5 root wheel 512 Jan 16 13:56 libdata drwxr-xr-x 5 root wheel 1536 Jan 16 13:56 libexec drwxr-xr-x 2 root wheel 512 Jan 16 13:56 local drwxr-xr-x 2 root wheel 512 Jan 16 13:56 obj drwxr-xr-x 2 root wheel 5120 Jan 16 13:56 sbin drwxr-xr-x 26 root wheel 512 Jan 16 13:56 share drwxr-xr-x 2 root wheel 512 Jan 16 13:56 src I punched in 0700 for the directory permission in the bsdinstall Add User dialog. So something like chmod 0755 "$(dirname $userhome)" should probably be done. Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Sun Jan 23 20:01: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 3D3BB106566B; Sun, 23 Jan 2011 20:01:10 +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 708E88FC17; Sun, 23 Jan 2011 20:01:09 +0000 (UTC) Received: by wwf26 with SMTP id 26so3313106wwf.31 for ; Sun, 23 Jan 2011 12:01:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Sd+IeNQF8dFqWNPOckratDcd9qRvk+iJYO886CmQbeY=; b=NLHwWrdRybRqGKwTJF0dNIUduwGw4kaAnFjUXv9mxFjB/qyRdbyFNMYe2sIpZ+m0sE CwrEC/i3GgtNlCVj7nDh8IBU0UZfx6yRzBhOhDqn3VwD1czhvAMNSu4neRjKNC5UCOfu IcHg5HadFnf439IZk9Yjlho/hy1jLUNJgaMvY= 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=XxoTG9cNGimh7Z7A+yOyy9dsmkQq7jbkNDv3SsV6bZw5sHPvcptxKyPVZU6qSzJd4C ASJRkXXzWXTuHqeyykZhankErC9NXlh2zyUttvHPPSkPcqr33oJ5jG7FciFkjV9ohE12 uk/h8kkgf2X3LzTvCebsi/eJmpNqbsv2vvTBo= MIME-Version: 1.0 Received: by 10.216.30.137 with SMTP id k9mr2828402wea.31.1295812867976; Sun, 23 Jan 2011 12:01:07 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.254.226 with HTTP; Sun, 23 Jan 2011 12:01:07 -0800 (PST) In-Reply-To: References: <4D28EB32.9090807@freebsd.org> <4D3C8037.6040406@freebsd.org> Date: Sun, 23 Jan 2011 12:01:07 -0800 X-Google-Sender-Auth: ObQameuP5zHkmWM1XZaOxZUgcT8 Message-ID: From: Garrett Cooper To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-sysinstall@freebsd.org, freebsd-arch@freebsd.org Subject: Re: 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: Sun, 23 Jan 2011 20:01:10 -0000 On Sun, Jan 23, 2011 at 11:55 AM, Garrett Cooper wrot= e: > On Sun, Jan 23, 2011 at 11:23 AM, Nathan Whitehorn > wrote: >> On 01/23/11 12:59, Garrett Cooper wrote: >>> >>> On Sat, Jan 8, 2011 at 2:54 PM, Nathan Whitehorn >>> =A0wrote: >>>> >>>> I've spent some time integrating bsdinstall into startup of install CD= s, >>>> mostly related to building useful live-CD-based installers. An i386 im= age >>>> 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, t= his >>>> 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. >>> >>> Not sure if it matters anymore, but here are my comments: >> >> It does very much matter. And all the CD environment stuff and the >> bsdinstall UI (which most of your comments are about) will be extremely >> similar to a merged pc-sysinstall installer. There is also a chance we w= ill >> end up with bsdinstall basically as-is as the 9.0 installer if we can't = get >> the merge done in time. > > Ok. > >>> NOTE: this was using >>> http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110118.iso.bz2 >>> . >>> >>> 1. The i386 image (apparently) isn't compiled with ATACAM, etc support >>> so opening /dev/cd0 always fails with ENODEV. >> >> Yes. But it will fall back to acd0. This is for people with SCSI or USB = CD >> drives. The real problem is if the CD ends up in [a]cd1, so cdboot needs= a >> more robust mechanism here. > > I'm not so much worried about the failure as I am about the noise > visible to the end user. A lot of stuff fails today silently, that > should fail silently, and that's ok as long as it makes sense in the > overall design of things. > > So again, printing that stuff is fine in verbose mode but doesn't make > sense in a more polished / quiet mode that will be packaged as an > install distribution to lots of users. > >>> 2. There's a lot of noise at bootup related to missing files. Putting >>> in a dummy /etc/fstab, adding hostid_enable=3D"NO", and setting >>> hostname=3D"" to a dummy value in rc.conf will help weed out some noise= . >> >> That's a good point. I've followed your suggestions. > > Thanks! > >>> 3. The initial dialog beeped when I first pressed the right key on my >>> keyboard. Maybe hw.syscons.bell=3D0 would help? >> >> Interesting. > > I didn't run in to this the second time, so it might be a bug with > libdialog / the app. There's an option to have libdialog beep when you > move the cursor, etc; I disabled the bell on the second go-around via > the terminal, because I was getting tired of my PC speaker `cursing' > at me when I hit tab / the arrow keys in the shell :P... > >>> 4. Splitting up the Keyboard Menu into regions and providing human >>> readable names would help. >> >> The keyboard menu just calls kbdmap, which is where the GUI comes from. = The >> suggestion is good, but the change should be made there. > > Ok. > >>> Partition Editor (I used Manual for the first try): >>> 1. It would be helpful if the cursor was at the end of the textbox so >>> that I didn't have to position the cursor at the end or press the >>> delete key. >> >> I'll see if there's a way to change this. > > Much appreciated :). If anything this should be done in libdialog, not > in bsdinstall as it's more intuitive behavior that belongs there. > >>> 2. K is a bogus suffix for kilo-; k is correct. >> >> This comes from humanize_number() in libutil, and would need to be chang= ed >> there. > > Ugh. Annoying... I can see what needs to be fixed next. > >>> 3. Having a mountpoint for a bsdlabel partition doesn't make sense and >>> is confusing. >> >> That is true. Since the same form with the mountpoint also has the parti= tion >> type, I could not find a clean way to make the last line go away. The sa= me >> issue applies to swap. Ideas for this part of the UI would be very much >> appreciated. > > Maybe graying out some fields would be helpful in the meantime? Not > sure if that's possible with the new libdialog in an easy manner. > >>> 4. Backing out of the Partition Manager and going back to the previous >>> dialogs is impossible. >> >> Which previous dialogs do you mean? Do you want to back out of the parti= tion >> manager to use the auto paritioner? If you press "Abort", you can restar= t >> the installation, which isn't so far off from that. There wasn't a whole= lot >> of room at the bottom of the partitioner screen for a sysinstall-like "A= uto >> Defaults" button. > > If I do into the manual partitioner and use the standard buttons > (don't hit ^c, etc), then I couldn't get back to setting the hostname, > going back and choosing the guided partitioner, etc. > >>> 5. Noting that the values (freebsd-ufs, etc) map back to gpart driven >>> values would be helpful. >> >> There's a help line at the bottom of the screen with this information. D= o >> you have a suggestion for making it more intuitive? Dialog doesn't suppo= rt >> drop-down menus, which is what I would ordinarily use on this field. > > I'll look at that again in my next run-through. Before what was nice > about sysinstall is that it placed the help diags further up on the > screen, so visually I had to parse the text at the top first before I > proceeded downward. [Most?] humans do top-down reading so I think that > that concern should be pushed back to libdialog upstream. > >>> I exited the install and tried again on the command line. Couldn't >>> conjure up the right gpart commands (manpage sucks for what I was >>> looking for -- creating a new partition), I went back into the >>> partedit command that was in /usr/libexec/ and entered in data >>> manually . Committed my changes which threw me back into the prompt >>> and then hit ^d to get back into the installer proper. The first run >>> around failed for some odd reason (claimed it couldn't create >>> boot/kernel.gz, or whatever, so there might be some error checking >>> missing with mount, mkdir, etc). >> >> Interesting. Let me know if you find out how this happened. > > Will do. > >>> Chose restart, walked through the process again and chose manual, made >>> sure the slice was properly configured for / and swap was setup, then >>> continued. This time the install went through properly. >>> >>> Progress bar: >>> I think you're on the right track by simplifying the install, but it >>> could be polished to say: >>> >>> kernel >>> world >>> distribution (in what context is distribution? Is it configuration >>> files, etc from `make distribution' ?) >> >> That is exactly what "distribution" is. What goes in which files, and ho= w >> many parts there are, is an interesting question. I think sysinstall spl= its >> up the base system a little too much. > > Agreed. But saying "Configuration files", etc is a bit easier for > end-users to understand. > >> You suggest dropping the ".tgz" suffixes? > > Yup. It's just noise and people will ask questions if you switch to > bzip2, lzma, 7z, etc. > >>> Configuring Network (etc) >>> >>> Seems like this could have been done earlier on to shrink the CD size >>> down a bit. >> >> Why would that shrink the CD size? It is done earlier if you need it to >> download the distfiles. I had placed it towards the end because it's par= t of >> a series of optional system configuration steps. > > Today I can download a bootonly ISO and pull down the package chunks I > want instead of downloading a fat CD/DVD to do that. Network installs > are nice. Forgot. Doing this will require a dialog to pick your choice of mirrors. ftp/http should suffice. There were far too many install options available via the menu in sysinstall for standard installations (it was one of the baggage items from the former installer that could easily be left behind). The being said, being able to run commands on the CLI, mount a directory to a predetermined location in place of using ftp/http would potentially be a good idea, so informed users can install via a msdosfs partition, NFS, SMB, etc. >>> Add Users (YAY! something that finally works) >>> >>> - Prompts seem ok. >>> - Login class - getting too specific IMO; this should be done after >>> the first boot. >>> - Home directory - /usr/home was the traditional home directory root >>> for BSD I thought. >>> - Home directory permissions - as an aside, what are the default? >>> - Use password-based authentication - what other options are there >>> other than not having a password or using a non-master.passwd backend >>> like LDAP, etc? >>> - Lock out account after creation - I would remove this; again, it >>> seems like something that an admin can do after first boot. >> >> As you probably noticed, all this does (like the root password screen) i= s to >> run adduser in a chroot in the new system, so this is just the set of >> questions adduser asks. This could probably be prettified (and maybe >> simplified) somewhat. > > Hmmm.. ok. > >>> In general: >>> >>> Some of the dialogs are a bit small (like the DHCP status dialog). >>> Enlarging them might help. >> >> All the dialogs just use the automatic sizing option in dialog. I think = that >> its autosizing algorithm may be a little wonky, but I haven't looked too >> much at changing it. > > Agreed. The new libdialog's algorithm for sizing windows is overly > liberal in vertical space, but conservative in horizontal space, which > is kind of annoying because 60 columns should be ok for an autosized > line, and I hate scrolling up and down looking for what I need to > read. > >>> Hopefully this feedback is helpful. >> >> It is! Please keep sending it. > > Ok :). Uh... lol. For starters I don't think that /usr/home should be 070= 0: > > $ ls -l /usr/home/ > total 0 > ls: /usr/home/: Permission denied > $ ls -l /usr/ > total 50 > drwxr-xr-x =A0 2 root =A0wheel =A0 7680 Jan 16 13:56 bin > drwxr-xr-x =A0 2 root =A0wheel =A0 =A0512 Jan 16 13:56 games > drwx------ =A0 3 root =A0wheel =A0 =A0512 Jan 23 02:58 home > drwxr-xr-x =A050 root =A0wheel =A0 5632 Jan 16 13:56 include > drwxr-xr-x =A0 6 root =A0wheel =A012800 Jan 16 13:56 lib > drwxr-xr-x =A0 5 root =A0wheel =A0 =A0512 Jan 16 13:56 libdata > drwxr-xr-x =A0 5 root =A0wheel =A0 1536 Jan 16 13:56 libexec > drwxr-xr-x =A0 2 root =A0wheel =A0 =A0512 Jan 16 13:56 local > drwxr-xr-x =A0 2 root =A0wheel =A0 =A0512 Jan 16 13:56 obj > drwxr-xr-x =A0 2 root =A0wheel =A0 5120 Jan 16 13:56 sbin > drwxr-xr-x =A026 root =A0wheel =A0 =A0512 Jan 16 13:56 share > drwxr-xr-x =A0 2 root =A0wheel =A0 =A0512 Jan 16 13:56 src > > I punched in 0700 for the directory permission in the bsdinstall Add > User dialog. So something like chmod 0755 "$(dirname $userhome)" > should probably be done. Thanks! -Garrett From owner-freebsd-arch@FreeBSD.ORG Sun Jan 23 20:05: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 C8869106564A; Sun, 23 Jan 2011 20:05:07 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id 924168FC12; Sun, 23 Jan 2011 20:05:07 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LFH00A00RSIYJ00@smtpauth1.wiscmail.wisc.edu>; Sun, 23 Jan 2011 14:05:06 -0600 (CST) Received: from comporellon.tachypleus.net (adsl-76-208-68-88.dsl.mdsnwi.sbcglobal.net [76.208.68.88]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LFH00258RSG9K10@smtpauth1.wiscmail.wisc.edu>; Sun, 23 Jan 2011 14:05:05 -0600 (CST) Date: Sun, 23 Jan 2011 14:05:04 -0600 From: Nathan Whitehorn In-reply-to: To: Garrett Cooper Message-id: <4D3C89F0.9090304@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.208.68.88 X-Spam-PmxInfo: Server=avs-14, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.1.23.195716, SenderIP=76.208.68.88 References: <4D28EB32.9090807@freebsd.org> <4D3C8037.6040406@freebsd.org> User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101214 Thunderbird/3.1.7 Cc: freebsd-sysinstall@freebsd.org, freebsd-arch@freebsd.org Subject: Re: 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: Sun, 23 Jan 2011 20:05:07 -0000 On 01/23/11 13:55, Garrett Cooper wrote: > On Sun, Jan 23, 2011 at 11:23 AM, Nathan Whitehorn > wrote: >> On 01/23/11 12:59, Garrett Cooper wrote: >>> On Sat, Jan 8, 2011 at 2:54 PM, Nathan Whitehorn >>> wrote: >>>> 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. >>> Not sure if it matters anymore, but here are my comments: >>> NOTE: this was using >>> http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110118.iso.bz2 >>> . >>> >>> 1. The i386 image (apparently) isn't compiled with ATACAM, etc support >>> so opening /dev/cd0 always fails with ENODEV. >> Yes. But it will fall back to acd0. This is for people with SCSI or USB CD >> drives. The real problem is if the CD ends up in [a]cd1, so cdboot needs a >> more robust mechanism here. > I'm not so much worried about the failure as I am about the noise > visible to the end user. A lot of stuff fails today silently, that > should fail silently, and that's ok as long as it makes sense in the > overall design of things. > > So again, printing that stuff is fine in verbose mode but doesn't make > sense in a more polished / quiet mode that will be packaged as an > install distribution to lots of users. Right. I'm just pointing out that it needs to be fixed for other reasons, too -- it's potentially broken in addition to being ugly. > >>> Partition Editor (I used Manual for the first try): >>> 1. It would be helpful if the cursor was at the end of the textbox so >>> that I didn't have to position the cursor at the end or press the >>> delete key. >> I'll see if there's a way to change this. > Much appreciated :). If anything this should be done in libdialog, not > in bsdinstall as it's more intuitive behavior that belongs there. Yes, I think so. > >>> 3. Having a mountpoint for a bsdlabel partition doesn't make sense and >>> is confusing. >> That is true. Since the same form with the mountpoint also has the partition >> type, I could not find a clean way to make the last line go away. The same >> issue applies to swap. Ideas for this part of the UI would be very much >> appreciated. > Maybe graying out some fields would be helpful in the meantime? Not > sure if that's possible with the new libdialog in an easy manner. It is possible to gray out fields, but you'd have to have hooks to check at each keystroke what the contents of the partition-type field are. I guess one option would be to not support mountpoints for partitions on MBR disks, but that would break setting the mount point of your linux partition, or adding FAT partitions, etc. >>> 4. Backing out of the Partition Manager and going back to the previous >>> dialogs is impossible. >> Which previous dialogs do you mean? Do you want to back out of the partition >> manager to use the auto paritioner? If you press "Abort", you can restart >> the installation, which isn't so far off from that. There wasn't a whole lot >> of room at the bottom of the partitioner screen for a sysinstall-like "Auto >> Defaults" button. > If I do into the manual partitioner and use the standard buttons > (don't hit ^c, etc), then I couldn't get back to setting the hostname, > going back and choosing the guided partitioner, etc. Ah, I see. You can do this by pressing "Finished", then "Abort". There should be a nicer way to do this. >>> 5. Noting that the values (freebsd-ufs, etc) map back to gpart driven >>> values would be helpful. >> There's a help line at the bottom of the screen with this information. Do >> you have a suggestion for making it more intuitive? Dialog doesn't support >> drop-down menus, which is what I would ordinarily use on this field. > I'll look at that again in my next run-through. Before what was nice > about sysinstall is that it placed the help diags further up on the > screen, so visually I had to parse the text at the top first before I > proceeded downward. [Most?] humans do top-down reading so I think that > that concern should be pushed back to libdialog upstream. As a human, I think I agree. This uses libdialog's help line functionality. I'm not sure if where that goes is a config option. > >>> Chose restart, walked through the process again and chose manual, made >>> sure the slice was properly configured for / and swap was setup, then >>> continued. This time the install went through properly. >>> >>> Progress bar: >>> I think you're on the right track by simplifying the install, but it >>> could be polished to say: >>> >>> kernel >>> world >>> distribution (in what context is distribution? Is it configuration >>> files, etc from `make distribution' ?) >> That is exactly what "distribution" is. What goes in which files, and how >> many parts there are, is an interesting question. I think sysinstall splits >> up the base system a little too much. > Agreed. But saying "Configuration files", etc is a bit easier for > end-users to understand. Yes. Adding human-readable aliases is probably a good idea. >>> Configuring Network (etc) >>> >>> Seems like this could have been done earlier on to shrink the CD size >>> down a bit. >> Why would that shrink the CD size? It is done earlier if you need it to >> download the distfiles. I had placed it towards the end because it's part of >> a series of optional system configuration steps. > Today I can download a bootonly ISO and pull down the package chunks I > want instead of downloading a fat CD/DVD to do that. Network installs > are nice. Yes, they are. The installer supports them already -- the ISOs I have sent out just come with the installation files, so that logic is never triggered. -Nathan From owner-freebsd-arch@FreeBSD.ORG Fri Jan 28 02:56:03 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 3E853106566B for ; Fri, 28 Jan 2011 02:56:03 +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 015ED8FC20 for ; Fri, 28 Jan 2011 02:56:02 +0000 (UTC) Received: by vws9 with SMTP id 9so1066069vws.13 for ; Thu, 27 Jan 2011 18:56:02 -0800 (PST) Received: by 10.220.193.77 with SMTP id dt13mr439179vcb.217.1296183360603; Thu, 27 Jan 2011 18:56:00 -0800 (PST) Received: from [10.0.1.198] ([72.253.42.56]) by mx.google.com with ESMTPS id o13sm5918031vch.16.2011.01.27.18.55.58 (version=SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 18:56:00 -0800 (PST) Date: Thu, 27 Jan 2011 16:59:01 -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: ofed merge soon 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, 28 Jan 2011 02:56:03 -0000 Hi Folks, I am merging ofed very soon. Here is the diff between the ofed base and head branches, which includes all of the diffs to vendor files and FreeBSD files: http://people.freebsd.org/~jeff/ofed.diff If you want to ignore the ofed parts just skip sys/ofed and contrib/ofed and you will be left with the changes to the base system required to support ofed. This includes things such as: 1) new config(8) options 2) Makefile glue 3) type change in sysctls for arg2. 4) IFT_INFINIBAND and related stack changes. 5) More generic vlan support 6) VM_WIRE_WRITE 7) endian changes The diffs are actually quite small when you eliminate ofed diffs. I don't know why I have so many merge properties but I'll just apply this diff to current, build & test before committing rather than have svn do it. Unless someone tells me otherwise. Before I commit I'm going to switch the default to not build ofed and the related kernel modules. I may add some more comments in various pieces as well. This is a last call for review. I had already sent out the individual pieces to interested parties. Thanks, Jeff From owner-freebsd-arch@FreeBSD.ORG Fri Jan 28 15:34:32 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 471941065670 for ; Fri, 28 Jan 2011 15:34:32 +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 18B1B8FC14 for ; Fri, 28 Jan 2011 15:34:32 +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 A5D0A46B35; Fri, 28 Jan 2011 10:34:31 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9A92E8A01D; Fri, 28 Jan 2011 10:34:30 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Fri, 28 Jan 2011 10:09:32 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <201101281009.32986.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 28 Jan 2011 10:34:30 -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: ofed merge soon 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, 28 Jan 2011 15:34:32 -0000 On Thursday, January 27, 2011 9:59:01 pm Jeff Roberson wrote: > Hi Folks, > > I am merging ofed very soon. Here is the diff between the ofed base and > head branches, which includes all of the diffs to vendor files and FreeBSD > files: > > http://people.freebsd.org/~jeff/ofed.diff Did you consider changing ndp to match the code from arp to print out the link layer addresses? If you don't want to do that, should there be a constant similar to ETHER_ADDR_LEN that is suitable for IB to avoid hardcoding '20' in ndp? Here is the similar code from arp (which ndp probably should adopt in some fashion): if (sdl->sdl_alen) { if ((sdl->sdl_type == IFT_ETHER || sdl->sdl_type == IFT_L2VLAN || sdl->sdl_type == IFT_BRIDGE) && sdl->sdl_alen == ETHER_ADDR_LEN) printf("%s", ether_ntoa((struct ether_addr *)LLADDR(sdl))); else { int n = sdl->sdl_nlen > 0 ? sdl->sdl_nlen + 1 : 0; printf("%s", link_ntoa(sdl) + n); } } else printf("(incomplete)"); > The diffs are actually quite small when you eliminate ofed diffs. I don't > know why I have so many merge properties but I'll just apply this diff to > current, build & test before committing rather than have svn do it. > Unless someone tells me otherwise. Just applying the diffs is probably fine. Also, at some point I would probably like to rename intr_drain() or hide it in some way so that only ofed uses it. FreeBSD drivers should drain interrupt handlers, not IRQs. I realize the ofed Linux compat shims are stuck with that interface, but for FreeBSD drivers I want a proper interface. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Jan 28 20:53:35 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 E7D611065672; Fri, 28 Jan 2011 20:53:35 +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 60C668FC17; Fri, 28 Jan 2011 20:53:34 +0000 (UTC) Received: by fxm16 with SMTP id 16so3916913fxm.13 for ; Fri, 28 Jan 2011 12:53:34 -0800 (PST) Received: by 10.223.93.144 with SMTP id v16mr2058788fam.35.1296248013140; Fri, 28 Jan 2011 12:53:33 -0800 (PST) Received: from [10.0.1.198] ([72.253.42.56]) by mx.google.com with ESMTPS id j12sm2523642fax.9.2011.01.28.12.53.28 (version=SSLv3 cipher=RC4-MD5); Fri, 28 Jan 2011 12:53:29 -0800 (PST) Date: Fri, 28 Jan 2011 10:56:30 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: John Baldwin In-Reply-To: <201101281009.32986.jhb@freebsd.org> Message-ID: References: <201101281009.32986.jhb@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: freebsd-arch@freebsd.org Subject: Re: ofed merge soon 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, 28 Jan 2011 20:53:36 -0000 On Fri, 28 Jan 2011, John Baldwin wrote: > On Thursday, January 27, 2011 9:59:01 pm Jeff Roberson wrote: >> Hi Folks, >> >> I am merging ofed very soon. Here is the diff between the ofed base and >> head branches, which includes all of the diffs to vendor files and FreeBSD >> files: >> >> http://people.freebsd.org/~jeff/ofed.diff > > Did you consider changing ndp to match the code from arp to print out the link > layer addresses? If you don't want to do that, should there be a constant > similar to ETHER_ADDR_LEN that is suitable for IB to avoid hardcoding '20' in > ndp? Here is the similar code from arp (which ndp probably should adopt in > some fashion): > You're right, I was lazy in ndp. Thanks for keeping me honest. > if (sdl->sdl_alen) { > if ((sdl->sdl_type == IFT_ETHER || > sdl->sdl_type == IFT_L2VLAN || > sdl->sdl_type == IFT_BRIDGE) && > sdl->sdl_alen == ETHER_ADDR_LEN) > printf("%s", ether_ntoa((struct ether_addr > *)LLADDR(sdl))); > else { > int n = sdl->sdl_nlen > 0 ? sdl->sdl_nlen + 1 : 0; > > printf("%s", link_ntoa(sdl) + n); > } > } else > printf("(incomplete)"); > >> The diffs are actually quite small when you eliminate ofed diffs. I don't >> know why I have so many merge properties but I'll just apply this diff to >> current, build & test before committing rather than have svn do it. >> Unless someone tells me otherwise. > > Just applying the diffs is probably fine. > > Also, at some point I would probably like to rename intr_drain() or hide it in > some way so that only ofed uses it. FreeBSD drivers should drain interrupt > handlers, not IRQs. I realize the ofed Linux compat shims are stuck with that > interface, but for FreeBSD drivers I want a proper interface. Any suggestions? Is there a proper interface available yet? The implementation I have requires internals that are not exposed outside of kern_intr.c so it has to live there. Thanks, Jeff > > -- > John Baldwin > From owner-freebsd-arch@FreeBSD.ORG Fri Jan 28 22:06:32 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 831861065695 for ; Fri, 28 Jan 2011 22:06:32 +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 532FB8FC12 for ; Fri, 28 Jan 2011 22:06:32 +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 DD9C746B39; Fri, 28 Jan 2011 17:06:31 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BD44D8A009; Fri, 28 Jan 2011 17:06:30 -0500 (EST) From: John Baldwin To: Jeff Roberson Date: Fri, 28 Jan 2011 17:06:27 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <201101281009.32986.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Message-Id: <201101281706.27514.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 28 Jan 2011 17:06:30 -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: freebsd-arch@freebsd.org Subject: Re: ofed merge soon 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, 28 Jan 2011 22:06:32 -0000 On Friday, January 28, 2011 3:56:30 pm Jeff Roberson wrote: > On Fri, 28 Jan 2011, John Baldwin wrote: > > > On Thursday, January 27, 2011 9:59:01 pm Jeff Roberson wrote: > >> Hi Folks, > >> > >> I am merging ofed very soon. Here is the diff between the ofed base and > >> head branches, which includes all of the diffs to vendor files and FreeBSD > >> files: > >> > >> http://people.freebsd.org/~jeff/ofed.diff > > > > Did you consider changing ndp to match the code from arp to print out the link > > layer addresses? If you don't want to do that, should there be a constant > > similar to ETHER_ADDR_LEN that is suitable for IB to avoid hardcoding '20' in > > ndp? Here is the similar code from arp (which ndp probably should adopt in > > some fashion): > > > > You're right, I was lazy in ndp. Thanks for keeping me honest. > > > if (sdl->sdl_alen) { > > if ((sdl->sdl_type == IFT_ETHER || > > sdl->sdl_type == IFT_L2VLAN || > > sdl->sdl_type == IFT_BRIDGE) && > > sdl->sdl_alen == ETHER_ADDR_LEN) > > printf("%s", ether_ntoa((struct ether_addr > > *)LLADDR(sdl))); > > else { > > int n = sdl->sdl_nlen > 0 ? sdl->sdl_nlen + 1 : 0; > > > > printf("%s", link_ntoa(sdl) + n); > > } > > } else > > printf("(incomplete)"); > > > >> The diffs are actually quite small when you eliminate ofed diffs. I don't > >> know why I have so many merge properties but I'll just apply this diff to > >> current, build & test before committing rather than have svn do it. > >> Unless someone tells me otherwise. > > > > Just applying the diffs is probably fine. > > > > Also, at some point I would probably like to rename intr_drain() or hide it in > > some way so that only ofed uses it. FreeBSD drivers should drain interrupt > > handlers, not IRQs. I realize the ofed Linux compat shims are stuck with that > > interface, but for FreeBSD drivers I want a proper interface. > > Any suggestions? Is there a proper interface available yet? The > implementation I have requires internals that are not exposed outside of > kern_intr.c so it has to live there. I think it will have to live there always, yes. Hmm, for now maybe just add a comment to say that it is only for Linux compat currently and not a supported interface. When I add a different drain interface I will make sure this function has the same semantics. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Sat Jan 29 09:32:34 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 722C31065673; Sat, 29 Jan 2011 09:32:34 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id CB2A18FC08; Sat, 29 Jan 2011 09:32:33 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=oR3+9dOmPeF3nZCt5Gxyvf/bIpfj8bfjGZkkfp/xES8= c=1 sm=1 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=A4605-F8WMvdPtQ9Sr4A:9 a=Hm0ptMbCims3pZfOlc0A:7 a=Ev1Jigx2tKM3rFiiZtnMjmgbhWAA:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 80645906; Sat, 29 Jan 2011 10:32:31 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Sat, 29 Jan 2011 10:32:35 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <201101281009.32986.jhb@freebsd.org> In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101291032.35544.hselasky@c2i.net> Cc: Subject: Re: ofed merge soon 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, 29 Jan 2011 09:32:34 -0000 Hi, Just a comment: + +#define DEFINE_MUTEX(lock) \ + mutex_t lock; \ + SX_SYSINIT_FLAGS(lock, &(lock).sx, "lnxmtx", SX_NOWITNESS) + +static inline void +linux_mutex_init(mutex_t *m) +{ + + memset(&m->sx, 0, sizeof(m->sx)); + sx_init_flags(&m->sx, "lnxmtx", SX_NOWITNESS); +} + +#define mutex_init linux_mutex_init I see you workaround the fact that Linux does not destroy any mutexes by disabling witness. Do you have any plan to upgrade the Linux 3rd party code to destroy mutexes? --HPS