From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 00:49:44 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 078061065679 for ; Sun, 4 Apr 2010 00:49:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id A5CE08FC16 for ; Sun, 4 Apr 2010 00:49:43 +0000 (UTC) Received: (qmail 28574 invoked by uid 399); 4 Apr 2010 00:49:42 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 4 Apr 2010 00:49:42 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BB7E224.6020508@FreeBSD.org> Date: Sat, 03 Apr 2010 17:49:40 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hiroki Sato References: <4BB70E1E.3090102@FreeBSD.org> <20100403.205140.26884732.hrs@allbsd.org> In-Reply-To: <20100403.205140.26884732.hrs@allbsd.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 00:49:44 -0000 As we've discussed previously, you and I have a lot of disagreement on some of these principles. I'm going to outline my responses in some detail, however I'm also interested in what others have to say since I'd ultimately like to see some consensus from the community on how this should be configured. On 04/03/10 04:51, Hiroki Sato wrote: > Doug Barton wrote > in <4BB70E1E.3090102@FreeBSD.org>: > > do> 1. There should be an ipv6_enable knob to easily turn IPv6 configuration > do> on and off when INET6 is in the kernel. I think the value of this kind > do> of knob is obvious, but I'd be happy to elaborate if that is necessary. > > There were reasons related to technical difficulty and inconsistency > (and a bit my preference) to drop $ipv6_enable. > > First, we are overly abusing $xxx_enable knob even when no > corresponding rc.d/xxx file. I think $xxx_enable knob should be used > only for rc.d/xxx whenever possible. It is intuitive, and what the > original design of rc.d scripts intended. Although this would be > another topic, it was one of the motivation for me to remove the > knob. I'm just about the biggest rc.d purist there is, and even I don't agree with this. :) I also disagree with your idea that "the original design of rc.d scripts" didn't intend for concepts like this. > Second, if people need a way to disable IPv6 protocol, they have > already the way; no IPv6 configuration in /etc/rc.conf. If you need > a handy way for on-and-off, separating the IPv6 configuration from > rc.conf to rc.conf.ipv6 and putting a line ". /etc/rc.conf.ipv6" into > /etc/rc.conf should be enough, for example. Even if I agreed with this idea (and I don't necessarily have strong DISagreement with it) the knob has existed since the beginning of IPv6 support in FreeBSD, and shouldn't be removed lightly. Personally I find it handy to be able to configure things in rc.conf and turn them on and off with one knob without having to comment or uncomment a bunch of stuff. > After all, protocols cannot be disabled only by using rc.d scripts. > If we really need the way to do that, we have to have kernel-level > knobs like sysctl or ifconfig flag. The standard way for users to configure stuff like this is rc.conf. That's a feature. :) Yes, more detailed knobs exist, but should the user have to learn about them? > Also, we should not consider IPv6 as special. I wish that were so, but I disagree. I think we need to make it as easy as possible for users to take advantage of IPv6, but there are a lot of reasons why it is actually special. Primarily because unlike some of our other networking protocols it's "on the cusp" of being something that everyone will need someday, but isn't quite ready for prime time. > Why we have to have $ipv6_enable while we don't have $ipv4_enable? I actually look forward to the day when we have an ipv4_enable, and look forward even more to the day when it defaults to "off." :) > I am using INET6-only machines for years and the > process removing the IPv4 dependency in the userland was really hard, Have you ported any of those changes to FreeBSD? There is a lot of talk currently about a near-term future when internal networks are v6-only, and all communication with v4 networks happen over some kind of translation layer. I'm not sure whether I like those ideas or not, but I think it would be great for FreeBSD to be in a leadership role here. > do> 2. ipv6_network_interfaces should be set to AUTO, the same way that it > do> is for IPv4. > > I agree with this change, but I am still not sure if we should have > $ipv6_network_interfaces itself. I think it's useful because people may want to configure some interfaces for v6 and not others. > do> 3. Each IPv6 interface (other than lo0) should be configured with rtsol > do> by default, but manual configuration should still be possible. > > Why accepting RA and sending RS by default? Because (like it or not) that's how the protocol works for the vast majority of IPv6 networks. I think users should have the reasonable expectation that if they enable IPv6 it should "just work." That said, I added the NORTADV knob precisely because I look forward to the day when we have other viable options like DHCPv6. When the default for IPv6 configuration is no longer RA this should be revisited. > I object this because it > is too problematic. The KAME implementation does not care about > receiving RAs from multiple networks and we cannot control the > accept-or-not. My patch for per-IF ACCEPT_RTADV handling was the > first step, but still I can imagine cases which cause surprising > results for sysadmins. I actually agree with these concerns. I personally don't like RA, I think it has all the security concerns you describe and more. But it IS the way that the world works at the moment. DHCPv6 is in its infancy, which means that the only viable configuration options right now are RA and direct configuration via ifconfig_IF_v6. In the latter case my patch disables RA entirely for that interface. > For IPv4 we do not invoke dhclient by default. I think this is an apples and oranges comparison. IPv6 has a lot of similarities to IPv4, but they have a lot of differences as well. As I said above (for better or worse) RA is fundamental to the design and implementation of IPv6, and for almost all users it will be necessary in order to get IPv6 connectivity up. > This is not so simple. A network interface can appears by cloning or > adding a new NIC into the system, and then devd(8) invokes rc.d/netif > via /etc/pccard_ether asynchronously. If the kernel accepts RAs by > default, these dynamically-added ones will also become RA-receiving > interfaces. Pseudo ifconfig flags like NORTADV don't work for them. First, I am not proposing flipping the kernel sysctl by default, however the end result of my change is effectively the same; with the defaults I'm proposing any new interface that comes up would be configured with RA. However I think what you're describing is an extreme edge case. Users who add new interfaces to a system that has working IPv6 would generally expect that the new interfaces would also work, by default. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 02:13:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79311106566C; Sun, 4 Apr 2010 02:13:21 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 52BB88FC08; Sun, 4 Apr 2010 02:13:21 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o342D9cb074495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Apr 2010 19:13:09 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o342D9Ol074494; Sat, 3 Apr 2010 19:13:09 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA03194; Sat, 3 Apr 10 18:02:24 PST Date: Sat, 03 Apr 2010 19:01:52 -0700 From: perryh@pluto.rain.com To: mail25@bzerk.org Message-Id: <4bb7f310.gIt41bTtJElBEKHS%perryh@pluto.rain.com> References: <20100402165002.71A8B1CC09@ptavv.es.net> <77FCD9C7615944DBBD3369EC4E5A5C94@rivendell> <2972DD89-7D7D-4869-9280-305BACBFEC5A@bway.net> <20100403135703.GA63262@ei.bzerk.org> In-Reply-To: <20100403135703.GA63262@ei.bzerk.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 04 Apr 2010 04:50:36 +0000 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 02:13:21 -0000 Ruben de Groot wrote: > defer all questions about moving out of the base system ... Last I knew, X was not _in_ the base system :) From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 05:33:56 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6EC41065674; Sun, 4 Apr 2010 05:33:56 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 49BE58FC1A; Sun, 4 Apr 2010 05:33:56 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o345XrUG005467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Apr 2010 22:33:54 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id E6F751CC13; Sat, 3 Apr 2010 22:33:52 -0700 (PDT) To: Doug Barton In-reply-to: Your message of "Sat, 03 Apr 2010 17:49:40 PDT." <4BB7E224.6020508@FreeBSD.org> Date: Sat, 03 Apr 2010 22:33:52 -0700 From: "Kevin Oberman" Message-Id: <20100404053352.E6F751CC13@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-02_13:2010-02-06, 2010-04-02, 2010-04-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004030318 Cc: freebsd-current@FreeBSD.org, Hiroki Sato Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 05:33:56 -0000 > Date: Sat, 03 Apr 2010 17:49:40 -0700 > From: Doug Barton > Sender: owner-freebsd-current@freebsd.org > > As we've discussed previously, you and I have a lot of disagreement on > some of these principles. I'm going to outline my responses in some > detail, however I'm also interested in what others have to say since I'd > ultimately like to see some consensus from the community on how this > should be configured. I guess it's time to put in my $.02. I do have some experience with IPv6. I have the first system to run a production IPv6 address in that ARIN region sitting under my desk in Berkeley. I agree with one of Doug's points and one of Hiroki's. > > On 04/03/10 04:51, Hiroki Sato wrote: > > Doug Barton wrote > > in <4BB70E1E.3090102@FreeBSD.org>: > > > > do> 1. There should be an ipv6_enable knob to easily turn IPv6 configuration > > do> on and off when INET6 is in the kernel. I think the value of this kind > > do> of knob is obvious, but I'd be happy to elaborate if that is necessary. > > > > There were reasons related to technical difficulty and inconsistency > > (and a bit my preference) to drop $ipv6_enable. > > > > First, we are overly abusing $xxx_enable knob even when no > > corresponding rc.d/xxx file. I think $xxx_enable knob should be used > > only for rc.d/xxx whenever possible. It is intuitive, and what the > > original design of rc.d scripts intended. Although this would be > > another topic, it was one of the motivation for me to remove the > > knob. > > I'm just about the biggest rc.d purist there is, and even I don't agree > with this. :) I also disagree with your idea that "the original design > of rc.d scripts" didn't intend for concepts like this. > > > Second, if people need a way to disable IPv6 protocol, they have > > already the way; no IPv6 configuration in /etc/rc.conf. If you need > > a handy way for on-and-off, separating the IPv6 configuration from > > rc.conf to rc.conf.ipv6 and putting a line ". /etc/rc.conf.ipv6" into > > /etc/rc.conf should be enough, for example. > > Even if I agreed with this idea (and I don't necessarily have strong > DISagreement with it) the knob has existed since the beginning of IPv6 > support in FreeBSD, and shouldn't be removed lightly. Personally I find > it handy to be able to configure things in rc.conf and turn them on and > off with one knob without having to comment or uncomment a bunch of stuff. > The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I see no reason not to use them to enable or disable functionality whether it involves a script in rc.d or not. The idea is to have a clear, obvious way to enable or disable functionality. I see nothing in Hiroki's proposal that is nearly as clear and to the point as 'ipv6_enable'. > > After all, protocols cannot be disabled only by using rc.d scripts. > > If we really need the way to do that, we have to have kernel-level > > knobs like sysctl or ifconfig flag. > > The standard way for users to configure stuff like this is rc.conf. > That's a feature. :) Yes, more detailed knobs exist, but should the > user have to learn about them? > > > Also, we should not consider IPv6 as special. > > I wish that were so, but I disagree. I think we need to make it as easy > as possible for users to take advantage of IPv6, but there are a lot of > reasons why it is actually special. Primarily because unlike some of our > other networking protocols it's "on the cusp" of being something that > everyone will need someday, but isn't quite ready for prime time. > > > Why we have to have $ipv6_enable while we don't have $ipv4_enable? > > I actually look forward to the day when we have an ipv4_enable, and look > forward even more to the day when it defaults to "off." :) It's possible that the time will come this decade when IPv4 is really not needed by the typical user, but I don't expect utilization to drop low enough that it would be appropriate to make the default "no" (certainly not "off"). POLA and general conservatism will prevent this for a long time. > > I am using INET6-only machines for years and the > > process removing the IPv4 dependency in the userland was really hard, > > Have you ported any of those changes to FreeBSD? There is a lot of talk > currently about a near-term future when internal networks are v6-only, > and all communication with v4 networks happen over some kind of > translation layer. I'm not sure whether I like those ideas or not, but I > think it would be great for FreeBSD to be in a leadership role here. I hate the idea. I want a end-to-end network that can be trivially subordinated to the control of any entity and allows for the innovation that an end-to-end network allows. I also fear the stability of massive carrier grade NAT systems. There is a huge amount of state required for CGN and if something goes wrong, it goes VERY wrong. > > do> 2. ipv6_network_interfaces should be set to AUTO, the same way that it > > do> is for IPv4. > > > > I agree with this change, but I am still not sure if we should have > > $ipv6_network_interfaces itself. > > I think it's useful because people may want to configure some interfaces > for v6 and not others. I agree with Doug, here, though I think its use will be very limited. (But maybe I will be wrong.) > > do> 3. Each IPv6 interface (other than lo0) should be configured with rtsol > > do> by default, but manual configuration should still be possible. > > > > Why accepting RA and sending RS by default? > > Because (like it or not) that's how the protocol works for the vast > majority of IPv6 networks. I think users should have the reasonable > expectation that if they enable IPv6 it should "just work." > > That said, I added the NORTADV knob precisely because I look forward to > the day when we have other viable options like DHCPv6. When the default > for IPv6 configuration is no longer RA this should be revisited. > > > I object this because it > > is too problematic. The KAME implementation does not care about > > receiving RAs from multiple networks and we cannot control the > > accept-or-not. My patch for per-IF ACCEPT_RTADV handling was the > > first step, but still I can imagine cases which cause surprising > > results for sysadmins. > > I actually agree with these concerns. I personally don't like RA, I > think it has all the security concerns you describe and more. But it IS > the way that the world works at the moment. DHCPv6 is in its infancy, > which means that the only viable configuration options right now are RA > and direct configuration via ifconfig_IF_v6. In the latter case my patch > disables RA entirely for that interface. I would agree with Doug EXCEPT for experiences I have had. I have been at a conference where a rogue RA totally clobbered the IPv6 network. Yes, not that many of us were running over IPv6, but I was (see the headers on this message) and it was very annoying. (It was also totally inadvertent.) I also know that a large federal research lab discovered that they had hundreds of systems running IPv6 on their network without knowing it. Almost all UNIX systems turn it on by default and some systems were configured for RTADV. It was causing all sorts of problems that were very hard to track down. Neither of these cases involved any intent to cause harm, but they demonstrate that it would not be hard for a miscreant to take advantage of this. ATM there is no alternative to running RTADV, and I am hopeful that IETF finishes and that vendors quickly implement RA-Guard, as well as mods to DHCPv6 to allow it to operate without needing a system running RTADV on the wire. > > For IPv4 we do not invoke dhclient by default. > > I think this is an apples and oranges comparison. IPv6 has a lot of > similarities to IPv4, but they have a lot of differences as well. As I > said above (for better or worse) RA is fundamental to the design and > implementation of IPv6, and for almost all users it will be necessary in > order to get IPv6 connectivity up. I agree with Doug. This is one of the few areas where IPv4 and IPv6 are really different. While I don't agree that accepting RTADV should be the default, the IPv4 comparison is really not relevant. > > > This is not so simple. A network interface can appears by cloning or > > adding a new NIC into the system, and then devd(8) invokes rc.d/netif > > via /etc/pccard_ether asynchronously. If the kernel accepts RAs by > > default, these dynamically-added ones will also become RA-receiving > > interfaces. Pseudo ifconfig flags like NORTADV don't work for them. > > First, I am not proposing flipping the kernel sysctl by default, however > the end result of my change is effectively the same; with the defaults > I'm proposing any new interface that comes up would be configured with > RA. However I think what you're describing is an extreme edge case. > Users who add new interfaces to a system that has working IPv6 would > generally expect that the new interfaces would also work, by default. Why? They do not accept the same for IPv4. Why should they for IPv6? RTADV and automatic configuration seemed like a really good idea. But, as happens far too often, security issues were not properly considered. IPv6 is riddled with security issues (not the same as vulnerabilities) that make me very nervous. I think RTADV is a huge opportunity for DOS. Not an issue yeat and almost no one is dependent on IPv6, but that is likely to change. Just my opinions and I'd like to hear what others think, at least those who actually use IPv6 and understand the issues. Otherwise this thread turns into a bikeshed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 07:29:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C41C5106564A for ; Sun, 4 Apr 2010 07:29:29 +0000 (UTC) (envelope-from ipfreak@yahoo.com) Received: from web52305.mail.re2.yahoo.com (web52305.mail.re2.yahoo.com [206.190.48.148]) by mx1.freebsd.org (Postfix) with SMTP id 6DEC18FC17 for ; Sun, 4 Apr 2010 07:29:29 +0000 (UTC) Received: (qmail 92290 invoked by uid 60001); 4 Apr 2010 07:02:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1270364567; bh=cb3XE7eAUze8KmbdmfuerHun+2QreTtClfbp1RHs8Bc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=X57Q1V+zJHSDHxiHsX9vqJDFpF8RMtsLb4ihD/Tl/H+D1/r5ge5GkOaf2Ywp3s/sHScUHlywcuUCBfVoIcl0BCcFreBJ0toEs9OyzsU62YIoQdE2UQzCxLGG/5J1XBYnJa6IbG2okvEJTMqfqILifOFkku487IXjEzylid6vRHg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=KpmelVM4EpPAj+2IOjOwC5x28Sk5r7b7Wm8PhWG4XlrbMf2QEENO00w38hxZY1ARqrWcS3frYSGppt10EMHScUBCFDjIZzKMfF11dZEztAdBiavqtJ3jYp4DKiPZqOktHMF2v2nmgMBVjQTValyNlFpz/GGVU00ABTlqoJp7uBE=; Message-ID: <614718.91632.qm@web52305.mail.re2.yahoo.com> X-YMail-OSG: R7npcWkVM1n40ktJerkCkIQjysGNJzjRFvcpP.l1tIRKplv mJF0khyUiK1YxmxBBF4oRYUHiEE1l5SbVCjfw1vYMM6nKjyqpoODfAi1Odyn GWkTwwReINqRi.5zbIsaE3JSvntSZjzaB.pRhs2oaDcSA2kNKKPktPEaTjK1 tcMSX1d8Y_kuHvZjjOqxNp4azyBSXUyTCTaMakJMYZcVZM3mBrkh3P6_A2V0 Twsh69asqNM934iJaavfHbPa5JUFiVtWrpBdCkJRhVDZzjHLN8v1om37nadg bHIDX0zdhlNLlLkbOMhcrwh1Xvb5AnOZQPtj50D666WnOjoi.cOczPA-- Received: from [98.169.0.45] by web52305.mail.re2.yahoo.com via HTTP; Sun, 04 Apr 2010 00:02:47 PDT X-Mailer: YahooMailClassic/10.0.8 YahooMailWebService/0.8.100.260964 Date: Sun, 4 Apr 2010 00:02:47 -0700 (PDT) From: gahn To: free bsd , freebsd general questions MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: samba failed MD5 Checksum X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 07:29:29 -0000 Hi all: I am trying to compile the smaba34 but somehow it failed MD5 Checksum and SHA256 Checksum: -------------------------------------------------------- # make all ===> Vulnerability check disabled, database not found ===> Found saved configuration for samba34-3.4.5_1 ===> ------------------------------------------- ===> Run 'make config' to (re)configure the port ===> ------------------------------------------- ===> Extracting for samba34-3.4.5_1 => MD5 Checksum mismatch for samba-3.4.5.tar.gz. => SHA256 Checksum mismatch for samba-3.4.5.tar.gz. ===> Refetch for 1 more times files: samba-3.4.5.tar.gz samba-3.4.5.tar.gz ===> Vulnerability check disabled, database not found ===> Found saved configuration for samba34-3.4.5_1 ===> ------------------------------------------- ===> Run 'make config' to (re)configure the port ===> ------------------------------------------- => samba-3.4.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/. .... --------------------------------------------------------------------- actually "samba-3.4.5.tar.gz" does exist under /usr/ports/distfiles how could I fix this problem? I am using 7.2-p7... Thanks From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 07:41:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48BAE106566C for ; Sun, 4 Apr 2010 07:41:25 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 9FDAD8FC0C for ; Sun, 4 Apr 2010 07:41:24 +0000 (UTC) Received: by bwz8 with SMTP id 8so2378761bwz.3 for ; Sun, 04 Apr 2010 00:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ez2qZb9mQwgE0MH7PmnJdeyg8oKJsJPl7vhpmYnt4ME=; b=Llj5SqRx6StvDeewhzhYUHRtL4QCK9sCjKr0mTDVqbGw+o3mraEnSMcXhBzn3n1JY4 rD/CTDUmTAbow+X0fskSnlUM4GsxfZjZh3tghUambArTBrLCEKwhwChuHqTc8E6OJ4oL IfUyTgM30N/xpqvZ+iRCb85OXIqJLKEVswP3I= 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=UbWNiNTmvoMeyLACJ4oc7TnQX78cxppOUDwnCXHForHVBtAnsiBPF2sQ8z3MREPOUc /f1E6b95rOYg0dQ9vva1IAVSQEs5H+ccDIE6ePapsQV11ofyXA9d2u2ii3tzfPDelKaI kOu2i4UuFPwPuFn8tNPdRn95XotGkkQO/XGJY= MIME-Version: 1.0 Received: by 10.204.47.232 with HTTP; Sun, 4 Apr 2010 00:41:22 -0700 (PDT) In-Reply-To: <614718.91632.qm@web52305.mail.re2.yahoo.com> References: <614718.91632.qm@web52305.mail.re2.yahoo.com> Date: Sun, 4 Apr 2010 11:41:22 +0400 Received: by 10.204.138.219 with SMTP id b27mr5065085bku.139.1270366883001; Sun, 04 Apr 2010 00:41:23 -0700 (PDT) Message-ID: From: pluknet To: gahn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: free bsd , freebsd general questions Subject: Re: samba failed MD5 Checksum X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 07:41:25 -0000 On 4 April 2010 11:02, gahn wrote: > Hi all: > > I am trying to compile the smaba34 but somehow it failed MD5 Checksum and= SHA256 Checksum: > > -------------------------------------------------------- > # make all > =3D=3D=3D> =A0Vulnerability check disabled, database not found > =3D=3D=3D> =A0Found saved configuration for samba34-3.4.5_1 > =3D=3D=3D> =A0------------------------------------------- > =3D=3D=3D> =A0Run 'make config' to (re)configure the port > =3D=3D=3D> =A0------------------------------------------- > =3D=3D=3D> =A0Extracting for samba34-3.4.5_1 > =3D> MD5 Checksum mismatch for samba-3.4.5.tar.gz. > =3D> SHA256 Checksum mismatch for samba-3.4.5.tar.gz. > =3D=3D=3D> =A0Refetch for 1 more times files: samba-3.4.5.tar.gz samba-3.= 4.5.tar.gz > =3D=3D=3D> =A0Vulnerability check disabled, database not found > =3D=3D=3D> =A0Found saved configuration for samba34-3.4.5_1 > =3D=3D=3D> =A0------------------------------------------- > =3D=3D=3D> =A0Run 'make config' to (re)configure the port > =3D=3D=3D> =A0------------------------------------------- > =3D> samba-3.4.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/. > .... > --------------------------------------------------------------------- > > actually "samba-3.4.5.tar.gz" does exist under /usr/ports/distfiles > Looks like you have partially fetched distfile. Try to make distclean, then restart again. --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 08:04:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0209106564A for ; Sun, 4 Apr 2010 08:04:55 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2001:470:1f09:679::1]) by mx1.freebsd.org (Postfix) with ESMTP id 679228FC0A for ; Sun, 4 Apr 2010 08:04:55 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 9544DC400C for ; Sun, 4 Apr 2010 08:04:54 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=-3.4 required=8.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from core.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA for ; Sun, 4 Apr 2010 08:04:54 +0000 (UTC) From: Bruce Cran To: freebsd-current@freebsd.org Date: Sun, 4 Apr 2010 09:04:50 +0100 User-Agent: KMail/1.13.1 (FreeBSD/9.0-CURRENT; KDE/4.4.1; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201004040904.50998.bruce@cran.org.uk> Subject: "npxdna in kernel mode!" from VIA_RNG_store X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 08:04:55 -0000 I noticed my mini-ITX box (runnning -CURRENT) has been printing quite a few "npxdna in kernel mode!" messages recently, so I added KDB support to find out where they were coming from. The stack trace I got was: npxdna in kernel mode! KDB: stack backtrace: db_trace_self_wrapper(c07de67f,c8297ab8,c07a477e,c07fc759,7,...) at db_trace_self_wrapper+0x28 kdb_backtrace(c07fc759,7,33,50,13,...) at kdb_backtrace+0x31 trap(c8297ac4) at trap+0x55e calltrap() at calltrap+0x6 --- trap 0x16, eip = 0xc07801f0, esp = 0xc8297b04, ebp = 0xc8297b14 --- VIA_RNG_store(c0865760,4,c181e6c0,c054ad43,c0811dc0,...) at VIA_RNG_store+0x20 random_nehemiah_read(c185c000,80,2,c185c000,0,...) at random_nehemiah_read+0x71 random_read(c1476200,c8297c28,0,1000000,0,...) at random_read+0x7c devfs_read_f(c1566c08,c8297c28,c182e080,0,c181e6c0,...) at devfs_read_f+0xa1 fo_read(c1566c08,c8297c28,c182e080,0,c181e6c0,...) at fo_read+0x32 dofileread(c181e6c0,5,c1566c08,c8297c28,ffffffff,...) at dofileread+0x81 kern_readv(c181e6c0,5,c8297c28,5,c8297c48,...) at kern_readv+0x68 read(c181e6c0,c8297cc8,c181e6c0,c181e6c0,c187d2a8,...) at read+0x63 syscall(c8297d38) at syscall+0x3ad Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x28398b83, esp = 0xbfbfde5c, ebp = 0xbfbfdf18 --- A dmesg can be found at http://www.cran.org.uk/~brucec/freebsd/dmesg.itx -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 08:56:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B38E51065670 for ; Sun, 4 Apr 2010 08:56:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 162C38FC08 for ; Sun, 4 Apr 2010 08:56:24 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o348uI4m053234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Apr 2010 11:56:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o348uIDa050099; Sun, 4 Apr 2010 11:56:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o348uIA6050098; Sun, 4 Apr 2010 11:56:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 4 Apr 2010 11:56:18 +0300 From: Kostik Belousov To: Bruce Cran Message-ID: <20100404085618.GX2415@deviant.kiev.zoral.com.ua> References: <201004040904.50998.bruce@cran.org.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="my+VSKri2szq3kvl" Content-Disposition: inline In-Reply-To: <201004040904.50998.bruce@cran.org.uk> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: "npxdna in kernel mode!" from VIA_RNG_store X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 08:56:25 -0000 --my+VSKri2szq3kvl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 04, 2010 at 09:04:50AM +0100, Bruce Cran wrote: > I noticed my mini-ITX box (runnning -CURRENT) has been printing quite a f= ew=20 > "npxdna in kernel mode!" messages recently, so I added KDB support to fin= d out=20 > where they were coming from. The stack trace I got was: >=20 > npxdna in kernel mode! > KDB: stack backtrace: > db_trace_self_wrapper(c07de67f,c8297ab8,c07a477e,c07fc759,7,...) at=20 > db_trace_self_wrapper+0x28 > kdb_backtrace(c07fc759,7,33,50,13,...) at kdb_backtrace+0x31 > trap(c8297ac4) at trap+0x55e > calltrap() at calltrap+0x6 > --- trap 0x16, eip =3D 0xc07801f0, esp =3D 0xc8297b04, ebp =3D 0xc8297b14= --- > VIA_RNG_store(c0865760,4,c181e6c0,c054ad43,c0811dc0,...) at VIA_RNG_store= +0x20 > random_nehemiah_read(c185c000,80,2,c185c000,0,...) at=20 > random_nehemiah_read+0x71 > random_read(c1476200,c8297c28,0,1000000,0,...) at random_read+0x7c > devfs_read_f(c1566c08,c8297c28,c182e080,0,c181e6c0,...) at devfs_read_f+0= xa1 > fo_read(c1566c08,c8297c28,c182e080,0,c181e6c0,...) at fo_read+0x32 > dofileread(c181e6c0,5,c1566c08,c8297c28,ffffffff,...) at dofileread+0x81 > kern_readv(c181e6c0,5,c8297c28,5,c8297c48,...) at kern_readv+0x68 > read(c181e6c0,c8297cc8,c181e6c0,c181e6c0,c187d2a8,...) at read+0x63 > syscall(c8297d38) at syscall+0x3ad > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (3, FreeBSD ELF32, read), eip =3D 0x28398b83, esp =3D 0xbfbfd= e5c, ebp=20 > =3D 0xbfbfdf18 --- >=20 > A dmesg can be found at http://www.cran.org.uk/~brucec/freebsd/dmesg.itx Known issue. The patch at http://people.freebsd.org/~kib/misc/kern_fpu.2.patch contains the possible fix. --my+VSKri2szq3kvl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAku4VDIACgkQC3+MBN1Mb4jsggCg7NUQ8wx2FGcJM1OJ9iL8A+hf vG0An1HP4lKpge6fcvY2L7sn0Tm9/lIi =Ta6y -----END PGP SIGNATURE----- --my+VSKri2szq3kvl-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 09:42:54 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79755106564A; Sun, 4 Apr 2010 09:42:54 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 128488FC0A; Sun, 4 Apr 2010 09:42:53 +0000 (UTC) Received: from delta.allbsd.org (p3177-ipbf416funabasi.chiba.ocn.ne.jp [123.225.92.177]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id o349gIDb095987; Sun, 4 Apr 2010 18:42:28 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id o349gCwA008562; Sun, 4 Apr 2010 18:42:17 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 04 Apr 2010 18:41:41 +0900 (JST) Message-Id: <20100404.184141.03733377.hrs@allbsd.org> To: oberman@es.net From: Hiroki Sato In-Reply-To: <20100404053352.E6F751CC13@ptavv.es.net> References: <4BB7E224.6020508@FreeBSD.org> <20100404053352.E6F751CC13@ptavv.es.net> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sun_Apr__4_18_41_41_2010_687)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Sun, 04 Apr 2010 18:42:36 +0900 (JST) X-Spam-Status: No, score=0.4 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: freebsd-current@FreeBSD.org, dougb@FreeBSD.org Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 09:42:54 -0000 ----Security_Multipart(Sun_Apr__4_18_41_41_2010_687)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Kevin Oberman" wrote in <20100404053352.E6F751CC13@ptavv.es.net>: ob> The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I ob> see no reason not to use them to enable or disable functionality whether ob> it involves a script in rc.d or not. The idea is to have a clear, ob> obvious way to enable or disable functionality. I see nothing in Hiroki's ob> proposal that is nearly as clear and to the point as 'ipv6_enable'. Another reason I lean to not using xxx_enable is that an rc.d knob cannot control enabling/disabling the IPv6 functionality actually. It was true even when we were using the network_ipv6 script. I agree that the idea to use $xxx_enable is clear, but I think it is better not to use it because it cannot make the functionality enable/disable completely in this IPv6 case. "To use IPv6, please add an IPv6 GUA to the interface" makes everything simple. If we really need a knob for enable/disable, $ipv6_enable is the best. However, if it cannot disable actually, $xxx_enable is just a confusing name. I added $ipv6_prefer and removed $ipv6_enable because of this reason. I have seen a lot of people who are trying to add an IPv6 address to use IPv6 but do not notice they have ipv6_enable="NO". The trouble is that it actually works with some incomplete configurations. I want to get rid of such a possibility. Especially issues of "an interface has an IPv6 GUA and no link-local address" and "sysadmins who want IPv4 only do not notice an IPv6 link-local address can do L3 communication". The current default settings are not the best, but a result of trade-off. ob> > Have you ported any of those changes to FreeBSD? There is a lot of talk ob> > currently about a near-term future when internal networks are v6-only, ob> > and all communication with v4 networks happen over some kind of ob> > translation layer. I'm not sure whether I like those ideas or not, but I ob> > think it would be great for FreeBSD to be in a leadership role here. ob> ob> I hate the idea. I want a end-to-end network that can be trivially ob> subordinated to the control of any entity and allows for the innovation ob> that an end-to-end network allows. I also fear the stability of massive ob> carrier grade NAT systems. There is a huge amount of state required for ob> CGN and if something goes wrong, it goes VERY wrong. My goal is for eliminating implicit IPv4 dependency and make the world AF-neutral wherever possible, not eliminating IPv4. Something like changes to rc.d/netoptions in HEAD is a good example. ob> > > do> 2. ipv6_network_interfaces should be set to AUTO, the same way that it ob> > > do> is for IPv4. ob> > > ob> > > I agree with this change, but I am still not sure if we should have ob> > > $ipv6_network_interfaces itself. ob> > ob> > I think it's useful because people may want to configure some interfaces ob> > for v6 and not others. ob> ob> I agree with Doug, here, though I think its use will be very limited. ob> (But maybe I will be wrong.) I agree with the usefulness, but we can implement this functionality with no $ipv6_network_interfaces. For example, $network_interfaces is for all IFs and AFs, "ifconfig_DEFAULT_AF=IGNORE" is per-AF, and "ifconfig_IF_AF=IGNORE" is per-AF+IF. I think it is not necessary to have a global knobs for a specific AF because we already have a per-AF knob for each IF as described above. The reason why we have ipv6_* knobs equivalent to ones for IPv4 is that the "ipv6_"-prefixed knobs were used in KAME to separate the IPv6 knobs from the existing IPv4 ones. As I explained, I want to merge the duplicates in AF-neutral manner. Not want to eliminate the existing functionality itself. ob> > > For IPv4 we do not invoke dhclient by default. ob> > ob> > I think this is an apples and oranges comparison. IPv6 has a lot of ob> > similarities to IPv4, but they have a lot of differences as well. As I ob> > said above (for better or worse) RA is fundamental to the design and ob> > implementation of IPv6, and for almost all users it will be necessary in ob> > order to get IPv6 connectivity up. ob> ob> I agree with Doug. This is one of the few areas where IPv4 and IPv6 are ob> really different. While I don't agree that accepting RTADV should be the ob> default, the IPv4 comparison is really not relevant. No, my intension is not to compare IPv4 and IPv6 here. We have never enable L3 address autoconfiguration without explicit configuration before. This is reasonable and should be kept for IPv6, too. -- Hiroki ----Security_Multipart(Sun_Apr__4_18_41_41_2010_687)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAku4XtUACgkQTyzT2CeTzy3J3ACgweKnJzn7oPk+rsraK0lX+h2B MQYAn3Q+BBN65LzLGfOS2hE2KBiN/UBH =OhZ3 -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Apr__4_18_41_41_2010_687)---- From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 09:52:00 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E334F1065670 for ; Sun, 4 Apr 2010 09:52:00 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 1B3DC8FC12 for ; Sun, 4 Apr 2010 09:51:59 +0000 (UTC) Received: (qmail 83277 invoked from network); 4 Apr 2010 09:51:58 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 4 Apr 2010 09:51:58 -0000 Date: Sun, 04 Apr 2010 11:51:58 +0200 (CEST) Message-Id: <20100404.115158.74708010.sthaug@nethelp.no> To: hrs@FreeBSD.org From: sthaug@nethelp.no In-Reply-To: <20100404.184141.03733377.hrs@allbsd.org> References: <4BB7E224.6020508@FreeBSD.org> <20100404053352.E6F751CC13@ptavv.es.net> <20100404.184141.03733377.hrs@allbsd.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dougb@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 09:52:01 -0000 > No, my intension is not to compare IPv4 and IPv6 here. We have never > enable L3 address autoconfiguration without explicit configuration > before. This is reasonable and should be kept for IPv6, too. Agree 100%. Having IPv6 SLAAC as the default is a bad idea. On the other hand, I *do* like a single rc.conf knob (ipv6_enable) for the top level IPv6 functionality - even if it doesn't do a 100% job. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 11:24:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03386106564A; Sun, 4 Apr 2010 11:24:43 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 9A5718FC17; Sun, 4 Apr 2010 11:24:42 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so1134076qwe.7 for ; Sun, 04 Apr 2010 04:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=A4Z7vayfLPCfX1i0lCvR14knoAbv+70Q1j1Unlcc/6Q=; b=nPMEwz+beJkE9KKF+aD2UQD6rIir39fI9gPXAElmDGzN0s1gd+sqU8PmvUjajZjvqC 5/jHzN19v0ai28OFHPffPAtskf8YM0S0jYtYtiXfyndEz6iYnE/rTknwtLD8K2SoJm4x z48zkVjVwrwhQeEs4j02XEPeBZtOZZvmusu0Y= 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=DLYqxPpM/VgX6MhCLBIP+PmYfB6GnQZd/JTGCWc8Vre9q/hohYVMzaVUkL+SrtxUVQ oZdcmA9E4bhkJaVG4HnVvDXmD+u1yH0rGBrsYeJBh2QlctUMHNRTbTbiD08Ua3SObFN0 c+4oQSztOwgURSuQjPoSHcG46O31oMd5K+NZE= MIME-Version: 1.0 Received: by 10.229.33.72 with HTTP; Sun, 4 Apr 2010 04:24:41 -0700 (PDT) In-Reply-To: References: <4BA7E0B8.3080406@delphij.net> Date: Sun, 4 Apr 2010 04:24:41 -0700 Received: by 10.229.235.193 with SMTP id kh1mr7067532qcb.106.1270380281601; Sun, 04 Apr 2010 04:24:41 -0700 (PDT) Message-ID: From: Garrett Cooper To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, d@delphij.net Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 11:24:43 -0000 On 3/26/10, Robert Watson wrote: > On Mon, 22 Mar 2010, Xin LI wrote: > >> A MFC of this update is planned, but we will have to make some rather >> aggressive changes against the library and more testing. >> >> Please make sure that you have at least libxml2-2.7.6_2 in your ports tree >> >> before even thinking about updating your ports tree. Older libxml2 uses >> some knowledge of zlib internals that has been changed in this update >> which >> is known to cause problem. > > While the update sounds like a good idea (as does moving to symbol > verisoning > for this library), I'm not yet convinced an MFC is a good idea given the > compatibility issues you describe. Perhaps you could clarify a bit the > failure mode: this affects only people who rebuild their ports using exactly > the same ports versions, but after having done an upgrade that includes this > update? It sounds like existing binaries will continue to work since they > will reference the old library version? Yes, but the number of libraries which need to be fixed is a pain. If you go the conservative (not ultra conservative) route, you'll have to rebuild all dependencies of graphics/png and graphics/tiff (which includes a ton of gnome apps, X, etc). Oh, and did I forget to mention that libtool hardcodes paths and versioning information? Of course most people won't see this fact until they run make delete-old-libs, but it's a doosy... This is the primary reason why Gentoo Linux has a script to clean up these [libtool] messes... That point alone is a reason for being ultra-conservative with this MFCing change. This won't affect folks building from scratch after this commit, but it'll easily kill off an afternoon or day for folks upgrading if they one isn't careful because the impact is large. Of course scripting the activity to avoid these times of base system library bumps is trivial, but my script that I whipped up still has rough edges and I'd rather not submit it quite yet... Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 12:11:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF90A106564A for ; Sun, 4 Apr 2010 12:11:38 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 767A78FC0A for ; Sun, 4 Apr 2010 12:11:38 +0000 (UTC) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NyOfw-00087v-39; Sun, 04 Apr 2010 14:11:36 +0200 Message-ID: <4BB881F4.1030405@gwdg.de> Date: Sun, 04 Apr 2010 14:11:32 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.1.9) Gecko/20100402 Thunderbird/3.0.4 MIME-Version: 1.0 To: Garrett Cooper References: <4BA7E0B8.3080406@delphij.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 12:11:39 -0000 On 04.04.2010 13:24 (UTC+1), Garrett Cooper wrote: > On 3/26/10, Robert Watson wrote: >> On Mon, 22 Mar 2010, Xin LI wrote: >> >>> A MFC of this update is planned, but we will have to make some rather >>> aggressive changes against the library and more testing. >>> >>> Please make sure that you have at least libxml2-2.7.6_2 in your ports tree >>> >>> before even thinking about updating your ports tree. Older libxml2 uses >>> some knowledge of zlib internals that has been changed in this update >>> which >>> is known to cause problem. >> >> While the update sounds like a good idea (as does moving to symbol >> verisoning >> for this library), I'm not yet convinced an MFC is a good idea given the >> compatibility issues you describe. Perhaps you could clarify a bit the >> failure mode: this affects only people who rebuild their ports using exactly >> the same ports versions, but after having done an upgrade that includes this >> update? It sounds like existing binaries will continue to work since they >> will reference the old library version? > > Yes, but the number of libraries which need to be fixed is a pain. If > you go the conservative (not ultra conservative) route, you'll have to > rebuild all dependencies of graphics/png and graphics/tiff (which > includes a ton of gnome apps, X, etc). Oh, and did I forget to mention > that libtool hardcodes paths and versioning information? Of course > most people won't see this fact until they run make delete-old-libs, > but it's a doosy... This is the primary reason why Gentoo Linux has a > script to clean up these [libtool] messes... To avoid the biggest trouble when updating I temporarily went another way. Before 'make delete-old-libs' I made a copy of libz.so.5 under compat: cp -p /lib/libz.so.5 /usr/local/lib/compat/ cp -p /usr/lib32/libz.so.5 /usr/local/lib32/compat/ I plan to delete these copies in some weeks. Do you think this is ok or do I have to expect unwanted side effects? Thanks, Rainer Hurling > That point alone is a reason for being ultra-conservative with this > MFCing change. This won't affect folks building from scratch after > this commit, but it'll easily kill off an afternoon or day for folks > upgrading if they one isn't careful because the impact is large. > > Of course scripting the activity to avoid these times of base system > library bumps is trivial, but my script that I whipped up still has > rough edges and I'd rather not submit it quite yet... From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 12:54:17 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2952A1065670 for ; Sun, 4 Apr 2010 12:54:17 +0000 (UTC) (envelope-from regnauld@bluepipe.net) Received: from moof.catpipe.net (moof.catpipe.net [129.142.64.64]) by mx1.freebsd.org (Postfix) with ESMTP id D4CAB8FC08 for ; Sun, 4 Apr 2010 12:54:16 +0000 (UTC) Received: from localhost (moof.catpipe.net [129.142.64.64]) by localhost.catpipe.net (Postfix) with ESMTP id A70F183A587 for ; Sun, 4 Apr 2010 14:39:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at catpipe.net Received: from moof.catpipe.net ([129.142.64.64]) by localhost (moof.catpipe.net [129.142.64.64]) (amavisd-new, port 10024) with ESMTP id dHeYCSOJGohF for ; Sun, 4 Apr 2010 14:39:08 +0200 (CEST) Received: from macbook.catpipe.net (unknown [62.198.233.30]) (Authenticated sender: relayuser) by moof.catpipe.net (Postfix) with ESMTP id D8D2283A3E8 for ; Sun, 4 Apr 2010 14:39:07 +0200 (CEST) Received: by macbook.catpipe.net (Postfix, from userid 1001) id BAEBC517C18; Sun, 4 Apr 2010 14:39:07 +0200 (CEST) Date: Sun, 4 Apr 2010 14:39:07 +0200 From: Phil Regnauld To: freebsd-current@freebsd.org Message-ID: <20100404123907.GA84384@macbook.catpipe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: FreeBSD 9-CURRENT (and 8.0) on MacMini (rev. 3,1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 12:54:17 -0000 Hi everyone, Wasn't sure where to post this, so I'll try here as it involves -CURRENT as well, and effort is probably best spent there. Have acquired a MacMini "Server" model (4 GB RAM, 2 x 500 GB disk, and no optical drive) to build a workshop training server. I am trying to get FreeBSD to work on this beast, and so far I've had mitigated success. Below is the combination of versions that work/don't work. If it hangs/panics, it's at boot time. Boot mode ACPI NO ACPI/SAFE F7.2-R amd64 hang panic (in swapper) F7.2-R i386 WORKS, but 2.7 GB visible. PAE kernel panics on starting CPU2 no-ACPI not tested (not necessary) F8.0-R amd64 hang hang F8.0-R i386 hang hang ohci F8.0-S amd64 hang hang at ohci early: SMM active, request owner change F9.0-C amd64 panic acpica hang on md0: Preloaded image (Feb 2010 SNAP) F9.0-C i386 panic acpica panic acpica Stopped at kbd_enter+0x3a: movl $0,kbd_why (USB kbd dead here, cannot backtrace) Currently I'm running 7.3-STABLE/i386, without PAE, limited to 2.6 GB RAM. ZFS works like a charm, and so does the built-in ethernet. ACPI works too, but asmc(4) is not available in 7. cputemp(4) works fine as well, but I don't think the fans ever change speed (though I succeeded in building world and kernel multiple times, and the CPU core temp never exceeded 80 C). On those that don't work, apart from disabling ACPI, I've attempted disabling various bits of the HW (sio, atkbdc, fdc, ...) but that hasn't helped so far. Also, so advice out there recommends disabling HW in the BIOS, which a Mac doesn't have. I checked the archives for anything relevant, and do see that older versions of the MacMini hardware tend to work (with some quirks), but it amd64's has always been an issue, it seems. I've also checked out the following links: http://wiki.freebsd.org/AppleMacbook Including: "If your system stops early at boot, try reverting r189055: http://svn.freebsd.org/viewvc/base?view=revision&revision=189055" (haven't tried that yet, but since 9.0 doesn't work, I didn't see the point). So, anyway, I'd like to get -CURRENT or even 8-STABLE to work on this. I'm ready to spend time helping whoever can guide me in debugging this critter. DDB is a bit tricky since the USB tends to hang as well, and I can't break into the debugger, or the keyboard doesn't work in it. I can include verbose boot logs, test any kernel (setting up PXE boot env). I could file PRs (but would like to refrain from doing this until I'm sure I've tried the right steps and avoid polluting the PR DB with redundant tickets). Any help appreciated! Cheers, Phil From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 14:34:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F182E106566C for ; Sun, 4 Apr 2010 14:34:19 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f209.google.com (mail-fx0-f209.google.com [209.85.220.209]) by mx1.freebsd.org (Postfix) with ESMTP id 7E2F38FC12 for ; Sun, 4 Apr 2010 14:34:19 +0000 (UTC) Received: by fxm1 with SMTP id 1so2277805fxm.13 for ; Sun, 04 Apr 2010 07:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=vsaB7CaZ1C+4m3RkgPQjBPO5SNmBUQSpCdP8+9roVl8=; b=MCOgLnz1jpnXnXvWMqcR/44LdodSc24nv52KyxooUWPivuiXUtS/8Usf+JxDgSvkcY yVXXX07Ji6mkluU7rV5IUlV4riovo5hNGTrfSo01ezQ4OSxcnn6fVzGFAPU/OAMUE9Jo tDL7+pTIiMgYosWHg/Mg8OJRWM+h3MclZlFuU= 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=iQU3lg+PP8w9a4IIWM3aSnmdZ3WPHKEYCZfErv79eW1ZJMqIqWPwdslp6lL1uFTBxr RwXRfLA4nx8Y6wyXjdjaTNXSvFnER2Tg1SYMu31AOaRCU8UyJufFmJXfwO/kScp6dUDT L8ofGcdHa8ydQHPudPfa2CjXZQKBz+dk2GuV0= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.239.137.131 with HTTP; Sun, 4 Apr 2010 07:34:17 -0700 (PDT) In-Reply-To: <20100404123907.GA84384@macbook.catpipe.net> References: <20100404123907.GA84384@macbook.catpipe.net> Date: Sun, 4 Apr 2010 16:34:17 +0200 X-Google-Sender-Auth: 1175ab9563c2e185 Received: by 10.239.137.69 with SMTP id k5mr365384hbk.214.1270391658148; Sun, 04 Apr 2010 07:34:18 -0700 (PDT) Message-ID: From: Attilio Rao To: Phil Regnauld Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 9-CURRENT (and 8.0) on MacMini (rev. 3,1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 14:34:20 -0000 2010/4/4 Phil Regnauld : > Hi everyone, > > Wasn't sure where to post this, so I'll try here as it involves -CURRENT > as well, and effort is probably best spent there. > > Have acquired a MacMini "Server" model (4 GB RAM, 2 x 500 GB disk, and > no optical drive) to build a workshop training server. I am trying > to get FreeBSD to work on this beast, and so far I've had mitigated > success. > > Below is the combination of versions that work/don't work. =C2=A0If it ha= ngs/panics, > it's at boot time. > > Boot mode =C2=A0 =C2=A0 =C2=A0 ACPI =C2=A0 =C2=A0 =C2=A0NO ACPI/SAFE > > F7.2-R amd64 =C2=A0hang =C2=A0 =C2=A0 =C2=A0panic (in swapper) > F7.2-R i386 =C2=A0 WORKS, but 2.7 GB visible. PAE kernel panics on starti= ng CPU2 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0no-ACPI not tested (not n= ecessary) > > F8.0-R amd64 =C2=A0hang =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hang > F8.0-R =C2=A0i386 =C2=A0hang =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0han= g ohci > > F8.0-S amd64 =C2=A0hang =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hang at = ohci early: SMM active, request owner change > > F9.0-C amd64 =C2=A0panic acpica =C2=A0 =C2=A0hang on md0: Preloaded image= =C2=A0(Feb 2010 SNAP) > F9.0-C i386 =C2=A0 panic acpica =C2=A0 =C2=A0panic acpica > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Stopped at =C2=A0kbd_enter+0x3a: movl =C2=A0= $0,kbd_why > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(USB kbd dead here, cannot backtrace) I would start by compiling a debugging kernel and using serial port for capturing, starting reporting the ACPI bug in the latest case, then we can get useful informations. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 15:34:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18B09106564A for ; Sun, 4 Apr 2010 15:34:57 +0000 (UTC) (envelope-from regnauld@bluepipe.net) Received: from moof.catpipe.net (moof.catpipe.net [129.142.64.64]) by mx1.freebsd.org (Postfix) with ESMTP id B699D8FC15 for ; Sun, 4 Apr 2010 15:34:55 +0000 (UTC) Received: from localhost (moof.catpipe.net [129.142.64.64]) by localhost.catpipe.net (Postfix) with ESMTP id C308983B093; Sun, 4 Apr 2010 17:34:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at catpipe.net Received: from moof.catpipe.net ([129.142.64.64]) by localhost (moof.catpipe.net [129.142.64.64]) (amavisd-new, port 10024) with ESMTP id HdGBkBF7VZOn; Sun, 4 Apr 2010 17:34:54 +0200 (CEST) Received: from macbook.catpipe.net (unknown [62.198.233.30]) (Authenticated sender: relayuser) by moof.catpipe.net (Postfix) with ESMTP id 31AA383B090; Sun, 4 Apr 2010 17:34:54 +0200 (CEST) Received: by macbook.catpipe.net (Postfix, from userid 1001) id D4D3D52326D; Sun, 4 Apr 2010 17:34:53 +0200 (CEST) Date: Sun, 4 Apr 2010 17:34:53 +0200 From: Phil Regnauld To: Attilio Rao Message-ID: <20100404153452.GA85964@macbook.catpipe.net> References: <20100404123907.GA84384@macbook.catpipe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Darwin 10.2.0 i386 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 9-CURRENT (and 8.0) on MacMini (rev. 3,1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 15:34:57 -0000 Attilio Rao (attilio) writes: > > I would start by compiling a debugging kernel and using serial port > for capturing, starting reporting the ACPI bug in the latest case, > then we can get useful informations. Hi Attilio, Any pointers on how to achieve that on a machine with no serial ports ? I've checked out: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-gdb.html and http://wiki.freebsd.org/DebugWithDcons (there is a recognized firewire port) I don't otherwise see how to get a core to disk halfway through the boot process. Cheers, Phil From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 16:06:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BAD41065689; Sun, 4 Apr 2010 16:06:01 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 56F3D8FC18; Sun, 4 Apr 2010 16:05:59 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA27332; Sun, 04 Apr 2010 19:05:54 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NySKf-000CUR-QF; Sun, 04 Apr 2010 19:05:53 +0300 Message-ID: <4BB8B8E1.1050402@icyb.net.ua> Date: Sun, 04 Apr 2010 19:05:53 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Phil Regnauld References: <20100404123907.GA84384@macbook.catpipe.net> <20100404153452.GA85964@macbook.catpipe.net> In-Reply-To: <20100404153452.GA85964@macbook.catpipe.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-current@freebsd.org Subject: Re: FreeBSD 9-CURRENT (and 8.0) on MacMini (rev. 3,1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 16:06:01 -0000 on 04/04/2010 18:34 Phil Regnauld said the following: > Attilio Rao (attilio) writes: >> I would start by compiling a debugging kernel and using serial port >> for capturing, starting reporting the ACPI bug in the latest case, >> then we can get useful informations. > > Hi Attilio, > > Any pointers on how to achieve that on a machine with no serial ports ? > I've checked out: > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-gdb.html > and > http://wiki.freebsd.org/DebugWithDcons (there is a recognized firewire port) > > I don't otherwise see how to get a core to disk halfway through the boot > process. You could try to use firewire console. See dcons(4). Also, a good and quicker start is to report actual panics that you get, as Attilio has suggested. When everything else fails, a digital camera still can be used to get screen captures:-) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 16:22:50 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id CCB1D106564A; Sun, 4 Apr 2010 16:22:49 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Mon, 5 Apr 2010 01:22:48 +0900 From: Norikatsu Shigemura To: Alexander Motin Message-Id: <20100405012248.54f013ae.nork@FreeBSD.org> In-Reply-To: <4BB2F8F2.1020502@FreeBSD.org> References: <1266441783.00220803.1266429001@10.7.7.3> <4BB2F8F2.1020502@FreeBSD.org> X-Mailer: Sylpheed 3.0.0 (GTK+ 2.18.7; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ATA_CAM-ed mvsata(4) on OpenRD-client X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 16:22:50 -0000 Hi mav. On Wed, 31 Mar 2010 10:25:38 +0300 Alexander Motin wrote: > > spin lock 0xc3766680 (fvH) held by 0xc3613b48 (tid -1061308344) too long > > panic: spin lock held too long > > KDB: enter: panic > > [ thread pid 0 tid 100000 ] > > Stopped at 0xc09dcb50 = kdb_enter+0x48: ldrb r15, [r15, r15, ror r15]! > > db> > Fixed at SVN r205967. Oops, sorry! That's great news! I'll retry. From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 20:42:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CCF21065674 for ; Sun, 4 Apr 2010 20:42:28 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f195.google.com (mail-qy0-f195.google.com [209.85.221.195]) by mx1.freebsd.org (Postfix) with ESMTP id E6F648FC0A for ; Sun, 4 Apr 2010 20:42:27 +0000 (UTC) Received: by qyk33 with SMTP id 33so3614622qyk.28 for ; Sun, 04 Apr 2010 13:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=v8AGsm9j43wLczM9wrkkMPOJo/pOoJ4ySr7So5rU1Ps=; b=YvLSwWJv08gSbQfP4JC9D1TUUlN2PPjm1a6jRRSZWUXLtrfATcTJ/4gD1TZmcOM3cH PDje3ft/gkAdUQd23Pq2J2qXm5Pd9jTY72JcJJROVJVGOVVXD94Sz6CpAh2eBwFzW97O Ax4ytEY2pu4jLDMH0rUq2ZTXG0Ek02x4SzAYk= 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=qD9kRbzNtaCd3w2/SkUJ14Xgyq+Mq7nsgT9eiRdXXa0dvoQ1ARR1iZghIWapblWKZC clFjNiBecSisPMjiVaXmT18V1cdI46DugkHetd40SWjnN60FDmRxbdcr9S5ZMbL6naMC jMFAlDRgtn3FZ4zzFroHobisnsDq4QWDp8Wu4= MIME-Version: 1.0 Received: by 10.229.33.72 with HTTP; Sun, 4 Apr 2010 13:42:26 -0700 (PDT) In-Reply-To: <4BB881F4.1030405@gwdg.de> References: <4BA7E0B8.3080406@delphij.net> <4BB881F4.1030405@gwdg.de> Date: Sun, 4 Apr 2010 13:42:26 -0700 Received: by 10.229.241.66 with SMTP id ld2mr7733419qcb.78.1270413746334; Sun, 04 Apr 2010 13:42:26 -0700 (PDT) Message-ID: From: Garrett Cooper To: Rainer Hurling Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 20:42:28 -0000 On Sun, Apr 4, 2010 at 5:11 AM, Rainer Hurling wrote: > On 04.04.2010 13:24 (UTC+1), Garrett Cooper wrote: >> >> On 3/26/10, Robert Watson =A0wrote: >>> >>> On Mon, 22 Mar 2010, Xin LI wrote: >>> >>>> A MFC of this update is planned, but we will have to make some rather >>>> aggressive changes against the library and more testing. >>>> >>>> Please make sure that you have at least libxml2-2.7.6_2 in your ports >>>> tree >>>> >>>> before even thinking about updating your ports tree. =A0Older libxml2 = uses >>>> some knowledge of zlib internals that has been changed in this update >>>> which >>>> is known to cause problem. >>> >>> While the update sounds like a good idea (as does moving to symbol >>> verisoning >>> for this library), I'm not yet convinced an MFC is a good idea given th= e >>> compatibility issues you describe. =A0Perhaps you could clarify a bit t= he >>> failure mode: this affects only people who rebuild their ports using >>> exactly >>> the same ports versions, but after having done an upgrade that includes >>> this >>> update? =A0It sounds like existing binaries will continue to work since >>> they >>> will reference the old library version? >> >> Yes, but the number of libraries which need to be fixed is a pain. If >> you go the conservative (not ultra conservative) route, you'll have to >> rebuild all dependencies of graphics/png and graphics/tiff (which >> includes a ton of gnome apps, X, etc). Oh, and did I forget to mention >> that libtool hardcodes paths and versioning information? Of course >> most people won't see this fact until they run make delete-old-libs, >> but it's a doosy... This is the primary reason why Gentoo Linux has a >> script to clean up these [libtool] messes... > > To avoid the biggest trouble when updating I temporarily went another way= . > Before 'make delete-old-libs' I made a copy of libz.so.5 under compat: > > cp -p /lib/libz.so.5 /usr/local/lib/compat/ > cp -p /usr/lib32/libz.so.5 /usr/local/lib32/compat/ > > I plan to delete these copies in some weeks. Do you think this is ok or d= o I > have to expect unwanted side effects? I'm pretty sure that works as well (just make sure to rerun ldconfig and ldconfig -32 after the fact -- or do /etc/rc.d/ldconfig restart, boot your system into multiuser mode, etc, and you should be in good shape); it should get you past this transition. It would be nice if there an entry in UPDATING added for this to warn people of the breakage and this potential suggested workaround *HINT*... >> That point alone is a reason for being ultra-conservative with this >> MFCing change. This won't affect folks building from scratch after >> this commit, but it'll easily kill off an afternoon or day for folks >> upgrading if they one isn't careful because the impact is large. >> >> Of course scripting the activity to avoid these times of base system >> library bumps is trivial, but my script that I whipped up still has >> rough edges and I'd rather not submit it quite yet... Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 21:15:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11424106566B; Sun, 4 Apr 2010 21:15:40 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id 8D32A8FC0A; Sun, 4 Apr 2010 21:15:39 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-253-149.belrs3.nsw.optusnet.com.au [122.106.253.149]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o34LFOqb028268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Apr 2010 07:15:25 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o34LFO3f020187; Mon, 5 Apr 2010 07:15:24 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o34LFMaU020186; Mon, 5 Apr 2010 07:15:22 +1000 (EST) (envelope-from peter) Date: Mon, 5 Apr 2010 07:15:22 +1000 From: Peter Jeremy To: perryh@pluto.rain.com Message-ID: <20100404211522.GI86236@server.vk2pj.dyndns.org> References: <20100402165002.71A8B1CC09@ptavv.es.net> <77FCD9C7615944DBBD3369EC4E5A5C94@rivendell> <2972DD89-7D7D-4869-9280-305BACBFEC5A@bway.net> <20100403135703.GA63262@ei.bzerk.org> <4bb7f310.gIt41bTtJElBEKHS%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IbA9xpzOQlG26JSn" Content-Disposition: inline In-Reply-To: <4bb7f310.gIt41bTtJElBEKHS%perryh@pluto.rain.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) X-CMAE-Score: 0 Cc: mail25@bzerk.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 21:15:40 -0000 --IbA9xpzOQlG26JSn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Apr-03 19:01:52 -0700, perryh@pluto.rain.com wrote: >Ruben de Groot wrote: >> defer all questions about moving out of the base system ... > >Last I knew, X was not _in_ the base system :) Well, that's an excellent topic for another bikeshed - Should X be made part of the base system? I know it is on OpenBSD. :-) :-) --=20 Peter Jeremy --IbA9xpzOQlG26JSn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAku5AWoACgkQ/opHv/APuIcBAwCdE7yXAEp94LGfpC0aPc+E1GB1 8l4An3yWcDE96SvR7xlk9cnRCgz8sGPB =/jLJ -----END PGP SIGNATURE----- --IbA9xpzOQlG26JSn-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 22:06:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEF48106564A; Sun, 4 Apr 2010 22:06:16 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f195.google.com (mail-qy0-f195.google.com [209.85.221.195]) by mx1.freebsd.org (Postfix) with ESMTP id 6ECBF8FC12; Sun, 4 Apr 2010 22:06:16 +0000 (UTC) Received: by qyk33 with SMTP id 33so3647192qyk.28 for ; Sun, 04 Apr 2010 15:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:cc:content-type; bh=5r4dJgdljOTeBrjgVcqGVM2XR0S3d4Ti+Iwi6IawNTQ=; b=oenhVW6UL+PLIr3/H16yAh0ZKh2JohX9qPkiQAy+XvzbjiRbjM17TbIYypJ0HJzAgl D3vmbEo5nRBHNN95Y5GkD6fHWwJvuyc6Ql6zCJ1G1loL40v5jncTBrI0Yo/ApVi5UFf7 loBlkj124MqZo1Ym3FWT9ezm4rkZcd2v9SVco= 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=DsvZaasY3SVkZ5jbafWEv3hbCJa8T9c4uw5gWyM6OpvZFCyhQRvEXYQFGrqOaWUJBG eAvfxfuvvr+vD+V9zF8MxdJEKQm03lvUu2hYIg774jupQhJjndB++gwHt86gpzNaTx0H jV1E6dhiJtDC1pdD6PbXqAKnimQEfNNuiDwC8= MIME-Version: 1.0 Received: by 10.229.33.72 with HTTP; Sun, 4 Apr 2010 15:06:15 -0700 (PDT) Date: Sun, 4 Apr 2010 15:06:15 -0700 Received: by 10.229.230.65 with SMTP id jl1mr8118568qcb.7.1270418775393; Sun, 04 Apr 2010 15:06:15 -0700 (PDT) Message-ID: From: Garrett Cooper To: FreeBSD Ports Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , Xin Li Subject: Ports breakage since r205471 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 22:06:17 -0000 Hi all, I realize that this is most suitable for current@ and I'm cross-posting, but I wanted to jot down all of the ports broken since the zlib version bump so that we can keep track of what's going on and what needs to be fixed. The following 3rd party libraries and all of their dependencies: graphics/png graphics/tiff textproc/libxml2 all needed to be rebuilt. The following items incorrectly define LARGEFILE64 and result in errors like the following: /usr/include/zlib.h:1561: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gzseek64' /usr/include/zlib.h:1562: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gztell64' /usr/include/zlib.h:1563: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gzoffset64' /usr/include/zlib.h:1564: error: expected declaration specifiers or '...' before 'off64_t' /usr/include/zlib.h:1565: error: expected declaration specifiers or '...' before 'off64_t' devel/qt-moc lang/python (uses pieces from gpac-libgpac I think) multimedia/gpac-libgpac multimedia/vlc (draft patch attached to ports/145387) Also, I really think we should add packaging metadata to third party libraries in base and at least track the versioning and dependencies because this CURRENT upgrade has turned into a royal mess and has eaten up more of my time than it should have. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 00:42:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54CD31065674; Mon, 5 Apr 2010 00:42:10 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id E0D2E8FC14; Mon, 5 Apr 2010 00:42:09 +0000 (UTC) Received: from c122-106-158-90.carlnfd1.nsw.optusnet.com.au (c122-106-158-90.carlnfd1.nsw.optusnet.com.au [122.106.158.90]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o350ftN9023837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Apr 2010 10:41:58 +1000 Date: Mon, 5 Apr 2010 10:41:55 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Tijl Coosemans In-Reply-To: <201004031707.34650.tijl@coosemans.org> Message-ID: <20100405100420.N5172@delplex.bde.org> References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <4BB644CA.4000807@freebsd.org> <4BB64615.9060601@freebsd.org> <201004031707.34650.tijl@coosemans.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 05 Apr 2010 00:52:57 +0000 Cc: Kostik Belousov , freebsd-current@freebsd.org, Bruce Evans , Andriy Gapon Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 00:42:10 -0000 On Sat, 3 Apr 2010, Tijl Coosemans wrote: > Wikipedia's article on FAT has this to say about the maximum size of > clusters: > > "The limit on partition size was dictated by the 8-bit signed count of > sectors per cluster, which had a maximum power-of-two value of 64. With That seems unlikely. The MS-DOS file system is an old 1970's one meant for implementation in assembly language on an 8-bit CPU. No assembly language programmer for an 8-bit microprocessor would expect an 8 bit or 16 bit counter to be signed, since there aren't enough bits to waste 1 for the sign bit. My reference written in 1986 by an assembly-language oriented programmer (Duncan) only says that the value must be a power of 2 though it says that the most other 8-bit variables are BYTEs. > the standard hard disk sector size of 512 bytes, this gives a maximum > of 32 KB clusters, thereby fixing the "definitive" limit for the FAT16 > partition size at 2 gigabytes. On magneto-optical media, which can have > 1 or 2 KB sectors instead of 1/2 KB, this size limit is proportionally > larger. However, there was no need to use counts of larger than 1 in 1980, so support for values of 128 could easily have been broken. > Much later, Windows NT increased the maximum cluster size to 64 KB by > considering the sectors-per-cluster count as unsigned. However, the > resulting format was not compatible with any other FAT implementation > of the time, and it generated greater internal fragmentation. Windows > 98 also supported reading and writing this variant, but its disk > utilities did not work with it." This is demonstably false, since pcfs in FreeBSD-1 was another FAT implementation of the time (1993), and it is should be missing the bug since it uses the natural unsigned types for everything in the BPB. msdosfs in Linux probably provides a better demonstration since it was of production quality a year or 2 earlier and unlikely to have the bug. (I don't have its sources handy to check.) > I'm not sure the second paragraph is worth supporting, but the first > seems to say that 32k limit you have in your patch only applies to > disks with 512 byte sectors. For disks with larger sectors it would > be proportionally larger. It would be interesting to see what breaks with cluster sizes > 64K. These can be obtained using emulated or physical sector sizes larger than 512. Of course you don't want to actually use cluster sizes larger than 4K (far below 32K) about since they just give portability and fragmentation losses for tiny or negative performance gains (lose both space and time to fragmentation). My implementation of clustering for msdosfs made the cluster sizes unimportant provided it is small enough not to produce fragmentation, and there is little fragmentation due to other problems, and there is enough CPU to enblock and deblock the clusters. Clustering works better for msdosfs than for ffs because there are no indirect blocks or far-away inode blocks to put bubbles in the i/o pipeline. Bruce From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 01:00:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5EB3106566C for ; Mon, 5 Apr 2010 01:00:22 +0000 (UTC) (envelope-from akirchhoff135014@comcast.net) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id 8723F8FC17 for ; Mon, 5 Apr 2010 01:00:22 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id 1cC11e00Y1swQuc55d0Nbk; Mon, 05 Apr 2010 01:00:22 +0000 Received: from scroll.ashke.com ([68.45.22.62]) by omta15.westchester.pa.mail.comcast.net with comcast id 1d4u1e00E1LNQfY3bd4u8f; Mon, 05 Apr 2010 01:04:54 +0000 Date: Sun, 4 Apr 2010 21:00:21 -0400 From: Adam K Kirchhoff To: freebsd-current@freebsd.org Message-ID: <20100404210021.125ffa0b@scroll.ashke.com> In-Reply-To: <20100403165447.73c9d370@scroll.ashke.com> References: <20100403165447.73c9d370@scroll.ashke.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: iwi problems on -CURRENT (Apr 4. 2010) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 01:00:22 -0000 FYI, this happens with GENERIC, too. Adam On Sat, 3 Apr 2010 16:54:47 -0400 Adam K Kirchhoff wrote: > > I'm having some problems with iwi on -CURRENT. > > FreeBSD scroll.ashke.com 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Sat Apr > 3 EDT 2010 root@scroll.ashke.com:/usr/obj/usr/src/sys/SCROLL i386 > > SCROLL is simply GENERIC without INVARIANTS, INVARIANT_SUPPORT, > WITNESS, and WITNESS_SKIPSPIN. > > In loader.conf I have: > > if_iwi_load="YES" > iwi_bss_load="YES" > legal.intel_iwi.license_ack=1 > > In /etc/rc.conf I have: > > wlans_iwi0="wlan0" > ifconfig_wlan0="DHCP wpa" > > Upon bootup, iwi fails to work with: > > iwi0: at device 3.0 on pci3 > iwi0: [ITHREAD] > iwi0: parity error > iwi0: timeout waiting for iwi_bss firmware initialization to complete > iwi0: could not load boot firmware iwi_bss > iwi0: timeout waiting for master > > According to the iwi man page, "could not load boot firmware" "should > not happen" :-) > > Any thoughts on how to get this working? For what it's worth, I > installed FreeBSD on this machine earlier this week, immediately > upgraded to -CURRENT (previous installations from the 8-STABLE series > on this laptop refused to let any wireless driver connect to the APs > at work, so I specifically wanted to see if this had been fixed in > -CURRENT), and iwi worked fine for a few days. Then it stopped, > though I did not change anything on the system. I updated -CURRENT > today to see if doing so would get iwi working again, but it did not. > > Adam > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 01:01:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 632081065673 for ; Mon, 5 Apr 2010 01:01:00 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id 1A94F8FC20 for ; Mon, 5 Apr 2010 01:00:59 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so1262955qwe.7 for ; Sun, 04 Apr 2010 18:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:subject :message-id:reply-to:mime-version:content-type:content-disposition :user-agent; bh=BSEeYrZfT54CLT7VVgYdRnLyML3cfjGNrlrM9o6DT9Q=; b=IC++kRefebjDXkOw7nAl7ybF8feah2HQxeu6LgVPyU2YZ+s2Twe39bapZgTt3slY7g g/2ek9ZxPF7Gts0OSuK/7JQAwrVizthKZjtbMxnSlu4U1zmS5KPyotdjesPVapKetawb JJ+e2s4I7N7KIx2lYsk65oJpXHgAtYTtsVan4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:mime-version:content-type :content-disposition:user-agent; b=GtJgfQoAk5ZrG8fffvgYsHjmDuaMAPXNDopStqzltnDNW91h/2eiNoCHdcJXMQkfRw XlrhqIEo9p1XpiNjoG0wbizxtiKgCa6MN1s2vdOv1SpylCSKikiJAmMUkGfdE+INKoRS EnxGboTACHgyl3ktomxB0lO5hj9k8lyFG66cs= Received: by 10.229.217.206 with SMTP id hn14mr7788204qcb.70.1270429259206; Sun, 04 Apr 2010 18:00:59 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id v37sm4477851qce.12.2010.04.04.18.00.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 04 Apr 2010 18:00:58 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 4 Apr 2010 18:00:54 -0700 From: Pyun YongHyeon Date: Sun, 4 Apr 2010 18:00:54 -0700 To: freebsd-current@FreeBSD.org Message-ID: <20100405010054.GA1225@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: Call for testers: fxp(4) Rx buffer use after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 01:01:00 -0000 Hi, It seems that fxp(4) has a long standing races between controller and driver. The exotic RFD handling of controller is race prone as we had seen old ethernet controllers. I could easily reproduce this by rebooting system while netperf 64bytes UDP test is in progress. If heavy RX frames hit the controller while interface UP is in progress, controller started DMAing to freed mbufs such that "Memory modified after free" message showed up. Based on OpenBSD's patch I made a patch which seems to fix the issue. If you saw this type of issue please give it try and let me how it goes on your box. The patch has effect only on interrupt mode so if you're using polling(4) you would have no effects. You can get download the patch at the following URL. http://people.freebsd.org/~yongari/fxp/fxp.rx.race.patch After applying the patch you may see somewhat increased RNR counter value from sysctl node(dev.fxp.0.rnr). Previously fxp(4) might have lower RNR counter value but that fake value came from DMAing to freed mbufs which was completely wrong. Thanks. From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 01:58:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A2B41065670; Mon, 5 Apr 2010 01:58:42 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.221.175]) by mx1.freebsd.org (Postfix) with ESMTP id A95488FC16; Mon, 5 Apr 2010 01:58:41 +0000 (UTC) Received: by qyk5 with SMTP id 5so4107647qyk.3 for ; Sun, 04 Apr 2010 18:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=c7kBlyJSuPfuLQE9xMgO3sIG8VtwQzitH4lfirVeZm4=; b=u45ncTq5hFQfF/iK495bpp+s6xRQRbkGLd7bNn06co6540TFha3dS5JN5vn8CgQAgv E4attb4bQJ+DOfeMrYVeeQ1rKgVKKfemyZenlkdGEu5Rd+O9rA10spIyXEsWDpIJ3q3A Rxl1brFI91sVNwcn+4NnqI0ADAlLdgumDM+so= 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=RSn/qGTI2AUc1nlHweVwXdA5zlv/UvjF4W3LnZg1tT3lGSZXJT00wN7XQubntFSl6A BkE1BT5RSCpyOjfkIzF8vWKTOedDuTGzkhYcKBVm5fQlEbYbmk+quT77v7jImk9h3Xfg 60gxfvpRM2W4SzHKXWbchw9xL/DE0ePlXrx1Y= MIME-Version: 1.0 Received: by 10.229.33.72 with HTTP; Sun, 4 Apr 2010 18:58:40 -0700 (PDT) In-Reply-To: References: Date: Sun, 4 Apr 2010 18:58:40 -0700 Received: by 10.229.221.78 with SMTP id ib14mr8374548qcb.28.1270432720729; Sun, 04 Apr 2010 18:58:40 -0700 (PDT) Message-ID: From: Garrett Cooper To: FreeBSD Ports Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , Xin Li Subject: Re: Ports breakage since r205471 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 01:58:42 -0000 On Sun, Apr 4, 2010 at 3:06 PM, Garrett Cooper wrote: > Hi all, > =A0 =A0I realize that this is most suitable for current@ and I'm > cross-posting, but I wanted to jot down all of the ports broken since > the zlib version bump so that we can keep track of what's going on and > what needs to be fixed. > =A0 =A0The following 3rd party libraries and all of their dependencies: > > graphics/png > graphics/tiff > textproc/libxml2 > > =A0 all needed to be rebuilt. > =A0 The following items incorrectly define LARGEFILE64 and result in > errors like the following: > > /usr/include/zlib.h:1561: error: expected '=3D', ',', ';', 'asm' or > '__attribute__' before 'gzseek64' > /usr/include/zlib.h:1562: error: expected '=3D', ',', ';', 'asm' or > '__attribute__' before 'gztell64' > /usr/include/zlib.h:1563: error: expected '=3D', ',', ';', 'asm' or > '__attribute__' before 'gzoffset64' > /usr/include/zlib.h:1564: error: expected declaration specifiers or > '...' before 'off64_t' > /usr/include/zlib.h:1565: error: expected declaration specifiers or > '...' before 'off64_t' > > devel/qt-moc > lang/python (uses pieces from gpac-libgpac I think) > multimedia/gpac-libgpac > multimedia/vlc (draft patch attached to ports/145387) > > =A0 Also, I really think we should add packaging metadata to third > party libraries in base and at least track the versioning and > dependencies because this CURRENT upgrade has turned into a royal mess > and has eaten up more of my time than it should have. As jsa@ so kindly pointed out, upgrading to r206057 temporarily alleviates this issue. I'll keep on looking for problematic areas where this needs to be fixed, but a #warning should probably be added to the header to catch all of the offenders. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 02:53:44 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF91F106566B for ; Mon, 5 Apr 2010 02:53:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6BC308FC08 for ; Mon, 5 Apr 2010 02:53:44 +0000 (UTC) Received: (qmail 18412 invoked by uid 399); 5 Apr 2010 02:53:43 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 5 Apr 2010 02:53:43 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BB950B6.7060603@FreeBSD.org> Date: Sun, 04 Apr 2010 19:53:42 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Kevin Oberman References: <20100404053352.E6F751CC13@ptavv.es.net> In-Reply-To: <20100404053352.E6F751CC13@ptavv.es.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Hiroki Sato Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 02:53:44 -0000 Thanks for the reply, it's nice to get other viewpoints involved, especially from those who have actual working knowledge of IPv6. I'm going to snip the bits where we agree for ease of reading. On 04/03/10 22:33, Kevin Oberman wrote: >> Date: Sat, 03 Apr 2010 17:49:40 -0700 >> From: Doug Barton >> Sender: owner-freebsd-current@freebsd.org >> >> As we've discussed previously, you and I have a lot of disagreement on >> some of these principles. I'm going to outline my responses in some >> detail, however I'm also interested in what others have to say since I'd >> ultimately like to see some consensus from the community on how this >> should be configured. > > I guess it's time to put in my $.02. I do have some experience with > IPv6. I have the first system to run a production IPv6 address in that > ARIN region sitting under my desk in Berkeley. > > I agree with one of Doug's points and one of Hiroki's. >> >> On 04/03/10 04:51, Hiroki Sato wrote: >>> Doug Barton wrote >>> in <4BB70E1E.3090102@FreeBSD.org>: >> I actually look forward to the day when we have an ipv4_enable, and look >> forward even more to the day when it defaults to "off." :) > > It's possible that the time will come this decade when IPv4 is really > not needed by the typical user, but I don't expect utilization to drop > low enough that it would be appropriate to make the default "no" > (certainly not "off"). POLA and general conservatism will prevent this > for a long time. Yes, my sentiment is serious, but the practicalities dictated the smiley at the end. :) >>> do> 3. Each IPv6 interface (other than lo0) should be configured with rtsol >>> do> by default, but manual configuration should still be possible. > > I would agree with Doug EXCEPT for experiences I have had. I have been > at a conference where a rogue RA totally clobbered the IPv6 > network. Yes, not that many of us were running over IPv6, but I was (see > the headers on this message) and it was very annoying. (It was also > totally inadvertent.) > > I also know that a large federal research lab discovered that they had > hundreds of systems running IPv6 on their network without knowing > it. Almost all UNIX systems turn it on by default and some systems were > configured for RTADV. It was causing all sorts of problems that were very > hard to track down. > > Neither of these cases involved any intent to cause harm, but they > demonstrate that it would not be hard for a miscreant to take advantage > of this. > > ATM there is no alternative to running RTADV, and I am hopeful that IETF > finishes and that vendors quickly implement RA-Guard, as well as mods > to DHCPv6 to allow it to operate without needing a system running RTADV > on the wire. I've read the various opinions regarding having RA on by default, and have reconsidered my position. Therefore I'd like to offer a compromise. What I'm after is that modulo the need to toggle ipv6_enable if a user has an interface configured with IPv4 that the same interface should "just work" with IPv6. Given that RA is the default method of IPv6 deployment, and given that it will almost certainly be necessary, I thought enabling it by default was a good idea. However I'm nothing if not reasonable. :) So I'd like to suggest returning the default in ipv6_autoconfif() to off, but enabling it if the user has a DHCP option in their IPv4 configuration for that same interface. To that end I've modified my patch, you can see the new version at http://people.freebsd.org/~dougb/v6-enable-2.diff. I've also added support for an RTADV keyword in ifconfig_IF_ipv6 and updated rc.conf.5 to match. I think this is a reasonable compromise, as those users who are using DHCP for IPv4 already have the expectation that their interfaces will be automatically configured. Those who are manually specifying their v4 addresses will have a little more work to get IPv6 up and running, but I can just send them to Hiroki or Steinar for help. :) Incidental to the RA default, when working on this new patch I noticed that noafif() is only ever called by ipv6_autoconfif() so I changed it to be in line rather than a separate function. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 03:13:43 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F04D51065673 for ; Mon, 5 Apr 2010 03:13:43 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 9A9CC8FC13 for ; Mon, 5 Apr 2010 03:13:43 +0000 (UTC) Received: (qmail 8549 invoked by uid 399); 5 Apr 2010 03:13:42 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 5 Apr 2010 03:13:42 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BB95564.1070604@FreeBSD.org> Date: Sun, 04 Apr 2010 20:13:40 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hiroki Sato References: <4BB7E224.6020508@FreeBSD.org> <20100404053352.E6F751CC13@ptavv.es.net> <20100404.184141.03733377.hrs@allbsd.org> In-Reply-To: <20100404.184141.03733377.hrs@allbsd.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 03:13:44 -0000 On 04/04/10 02:41, Hiroki Sato wrote: > "Kevin Oberman" wrote > in <20100404053352.E6F751CC13@ptavv.es.net>: > > ob> The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I > ob> see no reason not to use them to enable or disable functionality whether > ob> it involves a script in rc.d or not. The idea is to have a clear, > ob> obvious way to enable or disable functionality. I see nothing in Hiroki's > ob> proposal that is nearly as clear and to the point as 'ipv6_enable'. > > Another reason I lean to not using xxx_enable is that an rc.d knob > cannot control enabling/disabling the IPv6 functionality actually. > It was true even when we were using the network_ipv6 script. But that's equally true of how you're using ipv6_prefer. :) You've basically just moved the overloading of 2 of the 3 previous functions of ipv6_enable to ipv6_prefer. I am suggesting that we split all 3 functions into different knobs. I also have a lot of sympathy for the idea that there "should" be a sysctl or something to "switch off" IPv6 functionality even if INET6 is in the kernel. However, doing so is beyond my ability, and even if I _could_ do that, I'd _still_ want to toggle it with ipv6_enable. :) > I agree that the idea to use $xxx_enable is clear, but I think it is > better not to use it because it cannot make the functionality > enable/disable completely in this IPv6 case. "To use IPv6, please > add an IPv6 GUA to the interface" makes everything simple. I think I can see your perspective on this, however I don't agree with you. It also seems to me that the consensus seems to be forming around the idea that maintaining the ipv6_enable knob is a good thing. > I have seen a lot of people who are trying to add an IPv6 address to > use IPv6 but do not notice they have ipv6_enable="NO". I actually agree that this is a problem, which is why I've jiggled the order in etc/defaults/rc.conf a bit, and expanded the documentation in rc.conf.5. At the end of the day though, I agree that there is a learning curve, but I think that given the default of having INET6 in GENERIC it's necessary. Also, this issue doesn't change with the way you're using ipv6_prefer, it just moves the problem to that knob instead of _enable. > The trouble > is that it actually works with some incomplete configurations. I > want to get rid of such a possibility. Especially issues of "an > interface has an IPv6 GUA and no link-local address" and "sysadmins > who want IPv4 only do not notice an IPv6 link-local address can do L3 > communication". I agree with your concerns in this area, which is why I moved the testing of ipv6_enable into ipv6if(). This way we don't get either of the problems you described. > ob> > Have you ported any of those changes to FreeBSD? There is a lot of talk > ob> > currently about a near-term future when internal networks are v6-only, > ob> > and all communication with v4 networks happen over some kind of > ob> > translation layer. I'm not sure whether I like those ideas or not, but I > ob> > think it would be great for FreeBSD to be in a leadership role here. > ob> > ob> I hate the idea. I want a end-to-end network that can be trivially > ob> subordinated to the control of any entity and allows for the innovation > ob> that an end-to-end network allows. I also fear the stability of massive > ob> carrier grade NAT systems. There is a huge amount of state required for > ob> CGN and if something goes wrong, it goes VERY wrong. > > My goal is for eliminating implicit IPv4 dependency and make the > world AF-neutral wherever possible, not eliminating IPv4. Something > like changes to rc.d/netoptions in HEAD is a good example. As I've said previously, I think this is a good goal, of which I am 100% supportive. I probably shouldn't have included the aside about IPv4 stuff in my previous post, sorry for distracting the conversation. > ob> > > do> 2. ipv6_network_interfaces should be set to AUTO, the same way that it > ob> > > do> is for IPv4. > ob> > > > ob> > > I agree with this change, but I am still not sure if we should have > ob> > > $ipv6_network_interfaces itself. > ob> > > ob> > I think it's useful because people may want to configure some interfaces > ob> > for v6 and not others. > ob> > ob> I agree with Doug, here, though I think its use will be very limited. > ob> (But maybe I will be wrong.) > > I agree with the usefulness, but we can implement this functionality > with no $ipv6_network_interfaces. For example, $network_interfaces > is for all IFs and AFs, "ifconfig_DEFAULT_AF=IGNORE" is per-AF, and > "ifconfig_IF_AF=IGNORE" is per-AF+IF. I think this might be an interesting next step, I will have to think more about it. At this time however I would really like to get HEAD back to something that reasonably resembles the previous status quo for the user interface in concept, with your improved features running under the hood. > I think it is not necessary to have a global knobs for a specific AF > because we already have a per-AF knob for each IF as described above. > The reason why we have ipv6_* knobs equivalent to ones for IPv4 is > that the "ipv6_"-prefixed knobs were used in KAME to separate the > IPv6 knobs from the existing IPv4 ones. As I explained, I want to > merge the duplicates in AF-neutral manner. Not want to eliminate the > existing functionality itself. Thank you for clarifying your goals. Hopefully by now it's clear that I generally agree with the direction that you're going, I would just like to move a little slower. > ob> > > For IPv4 we do not invoke dhclient by default. > ob> > > ob> > I think this is an apples and oranges comparison. IPv6 has a lot of > ob> > similarities to IPv4, but they have a lot of differences as well. As I > ob> > said above (for better or worse) RA is fundamental to the design and > ob> > implementation of IPv6, and for almost all users it will be necessary in > ob> > order to get IPv6 connectivity up. > ob> > ob> I agree with Doug. This is one of the few areas where IPv4 and IPv6 are > ob> really different. While I don't agree that accepting RTADV should be the > ob> default, the IPv4 comparison is really not relevant. > > No, my intension is not to compare IPv4 and IPv6 here. We have never > enable L3 address autoconfiguration without explicit configuration > before. This is reasonable and should be kept for IPv6, too. See my response to Kevin on this topic. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 03:15:57 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69AFE106566B for ; Mon, 5 Apr 2010 03:15:57 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id ECBF88FC16 for ; Mon, 5 Apr 2010 03:15:56 +0000 (UTC) Received: (qmail 10474 invoked by uid 399); 5 Apr 2010 03:15:56 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 5 Apr 2010 03:15:56 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BB955EB.9090000@FreeBSD.org> Date: Sun, 04 Apr 2010 20:15:55 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: sthaug@nethelp.no References: <4BB7E224.6020508@FreeBSD.org> <20100404053352.E6F751CC13@ptavv.es.net> <20100404.184141.03733377.hrs@allbsd.org> <20100404.115158.74708010.sthaug@nethelp.no> In-Reply-To: <20100404.115158.74708010.sthaug@nethelp.no> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, hrs@FreeBSD.org Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 03:15:57 -0000 On 04/04/10 02:51, sthaug@nethelp.no wrote: >> No, my intension is not to compare IPv4 and IPv6 here. We have never >> enable L3 address autoconfiguration without explicit configuration >> before. This is reasonable and should be kept for IPv6, too. > > Agree 100%. Having IPv6 SLAAC as the default is a bad idea. > > On the other hand, I *do* like a single rc.conf knob (ipv6_enable) for > the top level IPv6 functionality - even if it doesn't do a 100% job. Thanks for your response. Do you think the compromise that I suggested in my response to Kevin, enabling SLAAC for the interface if DHCP is in use for IPv4 is reasonable? Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 03:21:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C73C1065670 for ; Mon, 5 Apr 2010 03:21:03 +0000 (UTC) (envelope-from ipfreak@yahoo.com) Received: from web52303.mail.re2.yahoo.com (web52303.mail.re2.yahoo.com [206.190.48.146]) by mx1.freebsd.org (Postfix) with SMTP id D92B38FC08 for ; Mon, 5 Apr 2010 03:21:02 +0000 (UTC) Received: (qmail 2521 invoked by uid 60001); 5 Apr 2010 03:21:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1270437662; bh=UTz9HbeU4giVKKRzYxKE/zfxsM1ErdByLLJXAbxV/As=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=dlydj/Nt8YO0Yrx5O+haJGR+PpXon+Dx0Mazy4+1MqwzKdP2p2XjNdjLHOErTik/pLo9MYu/Ivwmkh1rgRvrVopq8zKUrE0wGgGzmEl7Gs3sfDpbojqi3wScWfUo+WntKMOdGxdybGmOX4oJjF3ltXc5wkMnx3lVGy+8cHTW7sc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=Q7Ym3q3JPrfrWMlxpCQEx42g9McwSMH5Cj0q2y68ucL9AKAD2dbgCYJfiPwrE9I1cMOmIUEeKAQA9wjwYg3HjkpQfEqNJ+XdQdzAS0JkvIbzfzjx0BEK7gwY8Csp/rfxUJiBJxiuvSDmUgfByboz3axX6PRUAn7G51IK+Vg6HW0=; Message-ID: <99965.1808.qm@web52303.mail.re2.yahoo.com> X-YMail-OSG: WKJjfWMVM1nfwmNyhW5Ls8LLqnNOjEX._vNqwAc6GCerQN5 89AXzSSklUiuCJTrTH_EO3wBCTVI8.XnHUs2QhdbGt3RChww2cE4jEdAPief eUJDQcyw1TX7rryEN_xIyzsmR81hdHXZX.uyCcHgYAANE64VpAtL7UDac9uw d7F.SX.o.49v9TJtR..WVsw3hp5UK_caM2tUm5i5RCjJS7bDReSYRWPlUQK3 AbubIH2zQynsnZ9j1TcfBxgm74YrNUffVlX88ZpbAmsO1KaPwwUNq3U1Ycw. u6XWSTI2jJ.TzsJK46RcnH1liInjpUtlQcIBetagMSZVLQSvIr_4PTw-- Received: from [98.169.0.45] by web52303.mail.re2.yahoo.com via HTTP; Sun, 04 Apr 2010 20:21:01 PDT X-Mailer: YahooMailClassic/10.0.8 YahooMailWebService/0.8.100.260964 Date: Sun, 4 Apr 2010 20:21:01 -0700 (PDT) From: gahn To: free bsd , freebsd general questions MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: weird errors or else? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 03:21:03 -0000 Hi all: I am compiling xscreensaver-kde and it stooped with following errors: ---------------------------------------------------------------- Package tocloft Note: The document has chapter divisions. ) (/usr/local/share/texmf-dist/tex/latex/hyperref/hyperref.sty (/usr/local/share/texmf-dist/tex/latex/hyperref/pd1enc.def) (/usr/local/share/texmf-dist/tex/latex/hyperref/hyperref.cfg) Implicit mode ON; LaTeX internals redefined (/usr/local/share/texmf-dist/tex/latex/hyperref/backref.sty) (/usr/local/share/texmf-dist/tex/latex/url/url.sty)) *hyperref using default driver hpdftex* (/usr/local/share/texmf-dist/tex/latex/hyperref/hpdftex.def (/usr/local/share/texmf-dist/tex/latex/psnfss/pifont.sty (/usr/local/share/texmf-dist/tex/latex/psnfss/upzd.fd) (/usr/local/share/texmf-dist/tex/latex/psnfss/upsy.fd))) Writing index file doxygen_manual.idx (./doxygen_manual.aux ! Text line contains an invalid character. l.2 ^^@ ^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@... ? ^C ! Text line contains an invalid character. l.2 ^^@^^@ ^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@... ? X No pages of output. Transcript written on doxygen_manual.log. gmake[1]: *** [doxygen_manual.pdf] Error 1 gmake: *** [pdf] Interrupt: 2 -------------------------------------------------------- seem to me it want to write something but it doesn't tell me what to do next... what should I do next? Thanks From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 04:21:42 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFBBF1065673; Mon, 5 Apr 2010 04:21:42 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 824518FC1A; Mon, 5 Apr 2010 04:21:40 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o354LcaT004920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 4 Apr 2010 21:21:38 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 46F2E1CC13; Sun, 4 Apr 2010 21:21:38 -0700 (PDT) To: Doug Barton In-reply-to: Your message of "Sun, 04 Apr 2010 20:13:40 PDT." <4BB95564.1070604@FreeBSD.org> Date: Sun, 04 Apr 2010 21:21:38 -0700 From: "Kevin Oberman" Message-Id: <20100405042138.46F2E1CC13@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-05_01:2010-02-06, 2010-04-05, 2010-04-04 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004040237 Cc: freebsd-current@FreeBSD.org, Hiroki Sato Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 04:21:43 -0000 > Date: Sun, 04 Apr 2010 20:13:40 -0700 > From: Doug Barton > > On 04/04/10 02:41, Hiroki Sato wrote: > > "Kevin Oberman" wrote > > in <20100404053352.E6F751CC13@ptavv.es.net>: > > > > ob> The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I > > ob> see no reason not to use them to enable or disable functionality whether > > ob> it involves a script in rc.d or not. The idea is to have a clear, > > ob> obvious way to enable or disable functionality. I see nothing in Hiroki's > > ob> proposal that is nearly as clear and to the point as 'ipv6_enable'. > > > > Another reason I lean to not using xxx_enable is that an rc.d knob > > cannot control enabling/disabling the IPv6 functionality actually. > > It was true even when we were using the network_ipv6 script. > > But that's equally true of how you're using ipv6_prefer. :) You've > basically just moved the overloading of 2 of the 3 previous functions of > ipv6_enable to ipv6_prefer. I am suggesting that we split all 3 > functions into different knobs. > > I also have a lot of sympathy for the idea that there "should" be a > sysctl or something to "switch off" IPv6 functionality even if INET6 is > in the kernel. However, doing so is beyond my ability, and even if I > _could_ do that, I'd _still_ want to toggle it with ipv6_enable. :) > > > I agree that the idea to use $xxx_enable is clear, but I think it is > > better not to use it because it cannot make the functionality > > enable/disable completely in this IPv6 case. "To use IPv6, please > > add an IPv6 GUA to the interface" makes everything simple. > > I think I can see your perspective on this, however I don't agree with > you. It also seems to me that the consensus seems to be forming around > the idea that maintaining the ipv6_enable knob is a good thing. > > > I have seen a lot of people who are trying to add an IPv6 address to > > use IPv6 but do not notice they have ipv6_enable="NO". > > I actually agree that this is a problem, which is why I've jiggled the > order in etc/defaults/rc.conf a bit, and expanded the documentation in > rc.conf.5. At the end of the day though, I agree that there is a > learning curve, but I think that given the default of having INET6 in > GENERIC it's necessary. Also, this issue doesn't change with the way > you're using ipv6_prefer, it just moves the problem to that knob instead > of _enable. > > > The trouble > > is that it actually works with some incomplete configurations. I > > want to get rid of such a possibility. Especially issues of "an > > interface has an IPv6 GUA and no link-local address" and "sysadmins > > who want IPv4 only do not notice an IPv6 link-local address can do L3 > > communication". > > I agree with your concerns in this area, which is why I moved the > testing of ipv6_enable into ipv6if(). This way we don't get either of > the problems you described. > > > ob> > Have you ported any of those changes to FreeBSD? There is a lot of talk > > ob> > currently about a near-term future when internal networks are v6-only, > > ob> > and all communication with v4 networks happen over some kind of > > ob> > translation layer. I'm not sure whether I like those ideas or not, but I > > ob> > think it would be great for FreeBSD to be in a leadership role here. > > ob> > > ob> I hate the idea. I want a end-to-end network that can be trivially > > ob> subordinated to the control of any entity and allows for the innovation > > ob> that an end-to-end network allows. I also fear the stability of massive > > ob> carrier grade NAT systems. There is a huge amount of state required for > > ob> CGN and if something goes wrong, it goes VERY wrong. > > > > My goal is for eliminating implicit IPv4 dependency and make the > > world AF-neutral wherever possible, not eliminating IPv4. Something > > like changes to rc.d/netoptions in HEAD is a good example. > > As I've said previously, I think this is a good goal, of which I am 100% > supportive. I probably shouldn't have included the aside about IPv4 > stuff in my previous post, sorry for distracting the conversation. > > > ob> > > do> 2. ipv6_network_interfaces should be set to AUTO, the same way that it > > ob> > > do> is for IPv4. > > ob> > > > > ob> > > I agree with this change, but I am still not sure if we should have > > ob> > > $ipv6_network_interfaces itself. > > ob> > > > ob> > I think it's useful because people may want to configure some interfaces > > ob> > for v6 and not others. > > ob> > > ob> I agree with Doug, here, though I think its use will be very limited. > > ob> (But maybe I will be wrong.) > > > > I agree with the usefulness, but we can implement this functionality > > with no $ipv6_network_interfaces. For example, $network_interfaces > > is for all IFs and AFs, "ifconfig_DEFAULT_AF=IGNORE" is per-AF, and > > "ifconfig_IF_AF=IGNORE" is per-AF+IF. > > I think this might be an interesting next step, I will have to think > more about it. At this time however I would really like to get HEAD back > to something that reasonably resembles the previous status quo for the > user interface in concept, with your improved features running under the > hood. > > > I think it is not necessary to have a global knobs for a specific AF > > because we already have a per-AF knob for each IF as described above. > > The reason why we have ipv6_* knobs equivalent to ones for IPv4 is > > that the "ipv6_"-prefixed knobs were used in KAME to separate the > > IPv6 knobs from the existing IPv4 ones. As I explained, I want to > > merge the duplicates in AF-neutral manner. Not want to eliminate the > > existing functionality itself. > > Thank you for clarifying your goals. Hopefully by now it's clear that I > generally agree with the direction that you're going, I would just like > to move a little slower. > > > ob> > > For IPv4 we do not invoke dhclient by default. > > ob> > > > ob> > I think this is an apples and oranges comparison. IPv6 has a lot of > > ob> > similarities to IPv4, but they have a lot of differences as well. As I > > ob> > said above (for better or worse) RA is fundamental to the design and > > ob> > implementation of IPv6, and for almost all users it will be necessary in > > ob> > order to get IPv6 connectivity up. > > ob> > > ob> I agree with Doug. This is one of the few areas where IPv4 and IPv6 are > > ob> really different. While I don't agree that accepting RTADV should be the > > ob> default, the IPv4 comparison is really not relevant. > > > > No, my intension is not to compare IPv4 and IPv6 here. We have never > > enable L3 address autoconfiguration without explicit configuration > > before. This is reasonable and should be kept for IPv6, too. > > See my response to Kevin on this topic. Gentlemen, I think this is converging on a good, functional solution. Making ipv6_enable="NO" really turn off IPv6 looks like the ideal answer, but I think it's up to Hiroki to determine if it is feasible. I did my last kernel programming on VMS about 25 years ago and it was in assembly and BLISS, not C. I am just a bit uncomfortable with the use of the DHCP tag in rc.conf to control the use of SLAAC as SLAAC is so different in function and capability from DHCPv4, but it's probably the best we can do. Thanks to both of you for your attention to this. I think IPv6 is critical and anything that makes the transition easier will bear great fruit at time goes on. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 04:26:24 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAB87106566B; Mon, 5 Apr 2010 04:26:24 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7D6B48FC20; Mon, 5 Apr 2010 04:26:24 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 69E6BA697D7; Mon, 5 Apr 2010 12:26:23 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id niQGqMNCND93; Mon, 5 Apr 2010 12:26:17 +0800 (CST) Received: from delta.delphij.net (c-69-181-251-61.hsd1.ca.comcast.net [69.181.251.61]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 92247A697D5; Mon, 5 Apr 2010 12:26:14 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=kE881lkShr7YCzd6jLjpxG4gDzOBEjF3OGriqBGlXBEoi2/3mRbelnspYEamBOQIW mcBl63uAVB35ZZXt1Z5Yw== Message-ID: <4BB96661.3070609@delphij.net> Date: Sun, 04 Apr 2010 21:26:09 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.8) Gecko/20100304 Thunderbird/3.0.3 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Garrett Cooper References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Ports , FreeBSD Current , Xin Li Subject: Re: Ports breakage since r205471 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 04:26:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010/04/04 18:58, Garrett Cooper wrote: [...] > As jsa@ so kindly pointed out, upgrading to r206057 temporarily I think you really want >= 206058 :( Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLuWZhAAoJEATO+BI/yjfBkrwH/iQTvZQJkYPCRXbqBPVqhTi2 5XMri6IMV7rEij2HIFd5X8IAbts+6YvzIEwEZnkNboBGvhHruwu3Jsip5B3dcNx/ vNPavaqm9p56RgM8Dkl8mg+zZ6VN0rTf9p4eJ1EsL1EuQF4HtiDWugK746CLI6Xa FH7LEXOEHYfEkLoqWMR2nFjGqpBi65g7H6BoT/hj3egTmNHZsMKck+TdViKwsY6X P4wqzlSQJ6u0Ri1k8GPeGgUiSyL8djG2DVXsbhMkWTfi6QS/YBy150tqqVT0ggjL 9pZ2e3jDcU3jrp+9iOrLLQUU5MgPdyz70OgnI2ZLTfiocAtXiVb5Z5xIp4F2BDM= =TKt/ -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 05:50:30 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7364106564A; Mon, 5 Apr 2010 05:50:29 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id CBB538FC08; Mon, 5 Apr 2010 05:50:28 +0000 (UTC) Received: from delta.allbsd.org (p3177-ipbf416funabasi.chiba.ocn.ne.jp [123.225.92.177]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id o355o3EI017687; Mon, 5 Apr 2010 14:50:14 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id o355nwE2009756; Mon, 5 Apr 2010 14:50:03 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 05 Apr 2010 14:42:52 +0900 (JST) Message-Id: <20100405.144252.55944627.hrs@allbsd.org> To: dougb@FreeBSD.org From: Hiroki Sato In-Reply-To: <4BB7E224.6020508@FreeBSD.org> References: <4BB70E1E.3090102@FreeBSD.org> <20100403.205140.26884732.hrs@allbsd.org> <4BB7E224.6020508@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Apr__5_14_42_52_2010_888)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Mon, 05 Apr 2010 14:50:20 +0900 (JST) X-Spam-Status: No, score=0.4 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 05:50:30 -0000 ----Security_Multipart(Mon_Apr__5_14_42_52_2010_888)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Barton wrote in <4BB7E224.6020508@FreeBSD.org>: do> As we've discussed previously, you and I have a lot of disagreement on do> some of these principles. I'm going to outline my responses in some do> detail, however I'm also interested in what others have to say since I'd do> ultimately like to see some consensus from the community on how this do> should be configured. Yes, I agree that it is good to have discussion with more people. do> I'm just about the biggest rc.d purist there is, and even I don't agree do> with this. :) I also disagree with your idea that "the original design do> of rc.d scripts" didn't intend for concepts like this. Sorry for the noise. This involves my preference and was a different story. Please ignore this for IPv6 discussion for the moment. do> > Second, if people need a way to disable IPv6 protocol, they have do> > already the way; no IPv6 configuration in /etc/rc.conf. If you need do> > a handy way for on-and-off, separating the IPv6 configuration from do> > rc.conf to rc.conf.ipv6 and putting a line ". /etc/rc.conf.ipv6" into do> > /etc/rc.conf should be enough, for example. do> do> Even if I agreed with this idea (and I don't necessarily have strong do> DISagreement with it) the knob has existed since the beginning of IPv6 do> support in FreeBSD, and shouldn't be removed lightly. Personally I find do> it handy to be able to configure things in rc.conf and turn them on and do> off with one knob without having to comment or uncomment a bunch of stuff. I didn't removed it *lightly*. My motivation for that is I want to enable IPv6 by default without making trouble for IPv4-only people. I also committed several kernel-level measures for people who want IPv4-only, IPv6-only, and the both to live without the knob at that time. Enabling/disabling IPv6 by using rc.d script was quite complex and the switching will be incomplete with no kernel support. My conclusion for integration of the network_ipv6->netif changes was "depend on if adding an GUA or not" and it works fine for asynchronous invocation of rc.d/netif as well as needs no reboot for the switch (see another email for the whole story). Some processing which were in network_ipv6 (calculating $rtsol_interface and so on) are intentionally removed thanks to this assumption. If you want to go back to the old days and enable receiving RA by default, we must look into the whole process carefully again. If people want to disable IPv6 GUA assignment in per-AF manner, it should be done by per-AF global knobs for $ifconfig_* because the GUA assignment involves $ifconfig_* knobs only for the user as explained in another email. Let me summarize what I agree and disagree again: a. I agree that it is useful to have a knob for disabling all of ifconfig_IF_ipv6 handling. However, I disagree with using the name "ipv6_enable" just for the purpose. ipv6_enable=NO never means disabling IPv6 functionality in the kernel, and it will cause people tend to think IPv6 is disabled completely. If we want to disable ifconfig_IF_AF lines in a handy manner, implementing ifconfig_DEFAULT_AF is more consistent and where we should go. All of AF-specific parameters for an interface are in $ifconfig_IF_AF, and having a global knob to define the default for all interfaces are quite reasonable to me. I do not want to go back to AF-specific handling like ipv6_* wherever possible. I think this policy is compatible with David Horn's suggestions. "ifconfig_DEFAULT_ipv6=DHCP" for DHCPv6 by default, "ifconfig_DEFAULT_ipv6=accept_rtadv" for SLAAC by default, "ifconfig_fxp0_ipv6=-accept_rtadv" for no-SLAAC for fxp0, for example (note that I do not stick to these keywords. "slaac" would also be a good candidate). No concern for conflicting/confusing with IPv4; this is orthogonal among AFs. We can support another new method by just adding a keyword. Note that SLAAC and DHCPv6 are exclusive. Combinations of DHCPv6-NA + SLAAC, or DHCPv6-PD + SLAAC are not extreme (the latter is rather popular). This is one of the reasons I stick to the per-IF/per-AF solution here. b. Disagree with disabling IPv6 by default. I think there is no technical and security reason to go back to the old days. do> > Also, we should not consider IPv6 as special. do> do> I wish that were so, but I disagree. I think we need to make it as easy do> as possible for users to take advantage of IPv6, but there are a lot of do> reasons why it is actually special. Primarily because unlike some of our do> other networking protocols it's "on the cusp" of being something that do> everyone will need someday, but isn't quite ready for prime time. IMO, at least for handling in rc.d scripts, it is not necessary to consider IPv6 as a special AF after I added AF-specific $ifconfig_* knobs, rc.d/netoptions changes, and so on. And, well, please let me suggest something for the further discussion here. Whether we have $ipv6_enable or not, whether we enable $ipv6_enable by default or not, and whether receiving RA by default or not, are separated topics from each other. So, I would like everyone's opinions for the following points separately: 1. Do we need a knob to disable IPv6? If so, which in the following is expected for that knob? 1-a) Disable ifconfig_IF_ipv6 processing only. This means people can still do manual configuration for IPv6. 1-b) Disable IPv6 functionlity completely. 2. If we have a knob described in 1, what should be the default value? 3. Do we go for "accept RAs by default"? We can break down this in the following way related to 2: 3-a) Enable IPv6 functionality and accept RAs by default. 3-b) Enable IPv6 functionality and not accept RAs by default 3-c) Disable IPv6 functionality by default and accept RAs if one enables IPv6 in rc.conf. 3-d) Disable IPv6 functionality by default and not accept RAs even if one enables IPv6 in rc.conf. My answers for them are: 1. No objection for 1-a, but if so the name $ipv6_enable is wrong to me. If people needs 1-b, it should be $ipv6_enable. I have no strong opinion on whether we have one of or both of them. If we can reach a consensus to have 1-b, I am ready to implement the necessary changes. 2. I am for "enabled by default" regardless of 1-a or 1-b. 3. I am for 3-b. -- Hiroki ----Security_Multipart(Mon_Apr__5_14_42_52_2010_888)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAku5eFwACgkQTyzT2CeTzy3FHgCdEpdHC8FQic4FZLam5nkNACKf ek4AoJKPVVQw7fSX29zNsGy4rpS+6JHT =Yg77 -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Apr__5_14_42_52_2010_888)---- From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 06:02:01 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 732631065672 for ; Mon, 5 Apr 2010 06:02:01 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id A79568FC18 for ; Mon, 5 Apr 2010 06:02:00 +0000 (UTC) Received: (qmail 23466 invoked from network); 5 Apr 2010 06:01:58 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 5 Apr 2010 06:01:58 -0000 Date: Mon, 05 Apr 2010 08:01:58 +0200 (CEST) Message-Id: <20100405.080158.74730374.sthaug@nethelp.no> To: dougb@FreeBSD.org From: sthaug@nethelp.no In-Reply-To: <4BB955EB.9090000@FreeBSD.org> References: <20100404.184141.03733377.hrs@allbsd.org> <20100404.115158.74708010.sthaug@nethelp.no> <4BB955EB.9090000@FreeBSD.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, hrs@FreeBSD.org Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 06:02:01 -0000 > >> No, my intension is not to compare IPv4 and IPv6 here. We have never > >> enable L3 address autoconfiguration without explicit configuration > >> before. This is reasonable and should be kept for IPv6, too. > > > > Agree 100%. Having IPv6 SLAAC as the default is a bad idea. > > > > On the other hand, I *do* like a single rc.conf knob (ipv6_enable) for > > the top level IPv6 functionality - even if it doesn't do a 100% job. > > Thanks for your response. Do you think the compromise that I suggested > in my response to Kevin, enabling SLAAC for the interface if DHCP is in > use for IPv4 is reasonable? I think this is reasonable. However, I think it would also be worth while to revisit this point when DHCPv6 has evolved to do a more complete job (like assign a default gateway). Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 06:15:11 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55B75106566B for ; Mon, 5 Apr 2010 06:15:11 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id D79218FC12 for ; Mon, 5 Apr 2010 06:15:10 +0000 (UTC) Received: (qmail 23384 invoked by uid 399); 5 Apr 2010 06:15:09 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 5 Apr 2010 06:15:09 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BB97FE1.6050702@FreeBSD.org> Date: Sun, 04 Apr 2010 23:14:57 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: sthaug@nethelp.no References: <20100404.184141.03733377.hrs@allbsd.org> <20100404.115158.74708010.sthaug@nethelp.no> <4BB955EB.9090000@FreeBSD.org> <20100405.080158.74730374.sthaug@nethelp.no> In-Reply-To: <20100405.080158.74730374.sthaug@nethelp.no> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, hrs@FreeBSD.org Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 06:15:11 -0000 On 04/04/10 23:01, sthaug@nethelp.no wrote: >>>> No, my intension is not to compare IPv4 and IPv6 here. We have never >>>> enable L3 address autoconfiguration without explicit configuration >>>> before. This is reasonable and should be kept for IPv6, too. >>> >>> Agree 100%. Having IPv6 SLAAC as the default is a bad idea. >>> >>> On the other hand, I *do* like a single rc.conf knob (ipv6_enable) for >>> the top level IPv6 functionality - even if it doesn't do a 100% job. >> >> Thanks for your response. Do you think the compromise that I suggested >> in my response to Kevin, enabling SLAAC for the interface if DHCP is in >> use for IPv4 is reasonable? > > I think this is reasonable. However, I think it would also be worth > while to revisit this point when DHCPv6 has evolved to do a more > complete job (like assign a default gateway). Absolutely. That's why I wanted to add the [NO]RTADV knobs, so that you could combine them with DHCPv6 options. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 07:05:10 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48106106566C for ; Mon, 5 Apr 2010 07:05:10 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 98B5F8FC13 for ; Mon, 5 Apr 2010 07:05:09 +0000 (UTC) Received: from delta.allbsd.org (p3177-ipbf416funabasi.chiba.ocn.ne.jp [123.225.92.177]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id o3574hIT019117 for ; Mon, 5 Apr 2010 16:04:55 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id o3574c9x009821 for ; Mon, 5 Apr 2010 16:04:40 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 05 Apr 2010 16:04:16 +0900 (JST) Message-Id: <20100405.160416.107652240.hrs@allbsd.org> To: freebsd-current@FreeBSD.org From: Hiroki Sato In-Reply-To: <4BB95564.1070604@FreeBSD.org> References: <20100404053352.E6F751CC13@ptavv.es.net> <20100404.184141.03733377.hrs@allbsd.org> <4BB95564.1070604@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Apr__5_16_04_16_2010_540)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Mon, 05 Apr 2010 16:05:02 +0900 (JST) X-Spam-Status: No, score=0.4 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 07:05:10 -0000 ----Security_Multipart(Mon_Apr__5_16_04_16_2010_540)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Barton wrote in <4BB95564.1070604@FreeBSD.org>: do> On 04/04/10 02:41, Hiroki Sato wrote: do> > "Kevin Oberman" wrote do> > in <20100404053352.E6F751CC13@ptavv.es.net>: do> > do> > ob> The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I do> > ob> see no reason not to use them to enable or disable functionality whether do> > ob> it involves a script in rc.d or not. The idea is to have a clear, do> > ob> obvious way to enable or disable functionality. I see nothing in Hiroki's do> > ob> proposal that is nearly as clear and to the point as 'ipv6_enable'. do> > do> > Another reason I lean to not using xxx_enable is that an rc.d knob do> > cannot control enabling/disabling the IPv6 functionality actually. do> > It was true even when we were using the network_ipv6 script. do> do> But that's equally true of how you're using ipv6_prefer. :) You've do> basically just moved the overloading of 2 of the 3 previous functions of do> ipv6_enable to ipv6_prefer. I am suggesting that we split all 3 do> functions into different knobs. No, the current ipv6_prefer=NO has nothing to do with disabling IPv6. It is just related to source address selection and a seatbelt for IPv4-only people. I do not think I just moved the old functions. Let me explain how these changes happened. As I explained earlier, I added $ipv6_prefer to *enable IPv6 by default*. IPv6 needs some configuration even if you do not use IPv4 when the kernel supports it, and skipping all of IPv6 configuration in the old rc.d/network_ipv6 script caused another problems. So, I thought it was possible to enable IPv6 by default and initialize the functionality with reasonable default parameters. This parameters included "disable ACCEPT_RTADV by default", which is one of the topics we are discussing now. After I moved the initialization outside of the $ipv6_enable, then I noticed that the rest which should be inside of the $ipv6_enable is IPv6 GUA address assignments and routing settings only. Here I stepped further; I changed the disabling feature of $ipv6_enable into "whether an IPv6 address is assigned or not". That was the whole story. The old rc.d/network_ipv6 had a lot more for IPv6 configuration in the $ipv6_enable conditional clause and ipv6_enable=NO meant to disable them, too. This is a big difference. The new ipv6_enable in your patch is not the same in this regard. Well, I can understand and agree that people want a handy knob to disable IPv6. I think it is more constructive for this discussion to be more specific what should be disabled, then. I am still not sure what you and other people mean by "disable IPv6". My opinion is "ipv6_enable=NO" should mean disabling IPv6 functionality completely. I do not want to call a knob just to ignore ifconfig_IF_ipv6 lines as "ipv6_enable" as well as do not want to disable IPv6 functionality completely by default. So I am interested in what people want more precisely. -- Hiroki ----Security_Multipart(Mon_Apr__5_16_04_16_2010_540)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAku5i3AACgkQTyzT2CeTzy3ZpACfbA+xpauXCH9nTfHuZcS45JRZ UhMAnjcH2Ql0uKRF4qy4sfiNGHRrMw6U =s7gB -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Apr__5_16_04_16_2010_540)---- From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 08:31:04 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87D481065673; Mon, 5 Apr 2010 08:31:04 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (unknown [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 13DDB8FC08; Mon, 5 Apr 2010 08:31:03 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 935A739824; Mon, 5 Apr 2010 10:30:56 +0200 (SAST) Date: Mon, 5 Apr 2010 10:30:56 +0200 From: John Hay To: Hiroki Sato Message-ID: <20100405083056.GA8863@zibbi.meraka.csir.co.za> References: <4BB70E1E.3090102@FreeBSD.org> <20100403.205140.26884732.hrs@allbsd.org> <4BB7E224.6020508@FreeBSD.org> <20100405.144252.55944627.hrs@allbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100405.144252.55944627.hrs@allbsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org, dougb@FreeBSD.org Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 08:31:04 -0000 On Mon, Apr 05, 2010 at 02:42:52PM +0900, Hiroki Sato wrote: > Doug Barton wrote > in <4BB7E224.6020508@FreeBSD.org>: > > do> As we've discussed previously, you and I have a lot of disagreement on > do> some of these principles. I'm going to outline my responses in some > do> detail, however I'm also interested in what others have to say since I'd > do> ultimately like to see some consensus from the community on how this > do> should be configured. > > Yes, I agree that it is good to have discussion with more people. > > do> I'm just about the biggest rc.d purist there is, and even I don't agree > do> with this. :) I also disagree with your idea that "the original design > do> of rc.d scripts" didn't intend for concepts like this. > > Sorry for the noise. This involves my preference and was a different > story. Please ignore this for IPv6 discussion for the moment. > > do> > Second, if people need a way to disable IPv6 protocol, they have > do> > already the way; no IPv6 configuration in /etc/rc.conf. If you need > do> > a handy way for on-and-off, separating the IPv6 configuration from > do> > rc.conf to rc.conf.ipv6 and putting a line ". /etc/rc.conf.ipv6" into > do> > /etc/rc.conf should be enough, for example. > do> > do> Even if I agreed with this idea (and I don't necessarily have strong > do> DISagreement with it) the knob has existed since the beginning of IPv6 > do> support in FreeBSD, and shouldn't be removed lightly. Personally I find > do> it handy to be able to configure things in rc.conf and turn them on and > do> off with one knob without having to comment or uncomment a bunch of stuff. > > I didn't removed it *lightly*. My motivation for that is I want to > enable IPv6 by default without making trouble for IPv4-only people. > I also committed several kernel-level measures for people who want > IPv4-only, IPv6-only, and the both to live without the knob at that > time. > > Enabling/disabling IPv6 by using rc.d script was quite complex and > the switching will be incomplete with no kernel support. My > conclusion for integration of the network_ipv6->netif changes was > "depend on if adding an GUA or not" and it works fine for > asynchronous invocation of rc.d/netif as well as needs no reboot for > the switch (see another email for the whole story). Some processing > which were in network_ipv6 (calculating $rtsol_interface and so on) > are intentionally removed thanks to this assumption. If you want to > go back to the old days and enable receiving RA by default, we must > look into the whole process carefully again. > > If people want to disable IPv6 GUA assignment in per-AF manner, it > should be done by per-AF global knobs for $ifconfig_* because the GUA > assignment involves $ifconfig_* knobs only for the user as explained > in another email. > > Let me summarize what I agree and disagree again: > > a. I agree that it is useful to have a knob for disabling all of > ifconfig_IF_ipv6 handling. However, I disagree with using the > name "ipv6_enable" just for the purpose. ipv6_enable=NO never > means disabling IPv6 functionality in the kernel, and it will > cause people tend to think IPv6 is disabled completely. > > If we want to disable ifconfig_IF_AF lines in a handy manner, > implementing ifconfig_DEFAULT_AF is more consistent and where we > should go. All of AF-specific parameters for an interface are in > $ifconfig_IF_AF, and having a global knob to define the default > for all interfaces are quite reasonable to me. I do not want to > go back to AF-specific handling like ipv6_* wherever possible. > > I think this policy is compatible with David Horn's suggestions. > "ifconfig_DEFAULT_ipv6=DHCP" for DHCPv6 by default, > "ifconfig_DEFAULT_ipv6=accept_rtadv" for SLAAC by default, > "ifconfig_fxp0_ipv6=-accept_rtadv" for no-SLAAC for fxp0, for > example (note that I do not stick to these keywords. "slaac" > would also be a good candidate). No concern for > conflicting/confusing with IPv4; this is orthogonal among AFs. We > can support another new method by just adding a keyword. > > Note that SLAAC and DHCPv6 are exclusive. Combinations of > DHCPv6-NA + SLAAC, or DHCPv6-PD + SLAAC are not extreme (the > latter is rather popular). This is one of the reasons I stick to > the per-IF/per-AF solution here. > > b. Disagree with disabling IPv6 by default. I think there is no > technical and security reason to go back to the old days. > > do> > Also, we should not consider IPv6 as special. > do> > do> I wish that were so, but I disagree. I think we need to make it as easy > do> as possible for users to take advantage of IPv6, but there are a lot of > do> reasons why it is actually special. Primarily because unlike some of our > do> other networking protocols it's "on the cusp" of being something that > do> everyone will need someday, but isn't quite ready for prime time. > > IMO, at least for handling in rc.d scripts, it is not necessary to > consider IPv6 as a special AF after I added AF-specific $ifconfig_* > knobs, rc.d/netoptions changes, and so on. > > And, well, please let me suggest something for the further discussion > here. Whether we have $ipv6_enable or not, whether we enable > $ipv6_enable by default or not, and whether receiving RA by default > or not, are separated topics from each other. So, I would like > everyone's opinions for the following points separately: > > 1. Do we need a knob to disable IPv6? If so, which in the following > is expected for that knob? > > 1-a) Disable ifconfig_IF_ipv6 processing only. This means people > can still do manual configuration for IPv6. > > 1-b) Disable IPv6 functionlity completely. > > 2. If we have a knob described in 1, what should be the default > value? > > 3. Do we go for "accept RAs by default"? We can break down this in > the following way related to 2: > > 3-a) Enable IPv6 functionality and accept RAs by default. > > 3-b) Enable IPv6 functionality and not accept RAs by default > > 3-c) Disable IPv6 functionality by default and accept RAs if one > enables IPv6 in rc.conf. > > 3-d) Disable IPv6 functionality by default and not accept RAs even > if one enables IPv6 in rc.conf. > > My answers for them are: > > 1. No objection for 1-a, but if so the name $ipv6_enable is wrong to > me. If people needs 1-b, it should be $ipv6_enable. I have no > strong opinion on whether we have one of or both of them. If we > can reach a consensus to have 1-b, I am ready to implement the > necessary changes. > > 2. I am for "enabled by default" regardless of 1-a or 1-b. > > 3. I am for 3-b. These questions actually start more questions for me. :-) Maybe we should also think from the user perspective and list a few use cases and what a user need to put in rc.conf to make that work? Your normal desktop/notebook user on a ipv6 radv network, what does he need to do to have his machine ipv6 usable? A network server that does not accept radv, what should its ipv6 config in rc.conf look like? What about a server that accept radv (so that it can get router info) and have fixed addresses for it services? A router kind of box, what should it look like? Maybe by stating these, and other, use-cases, it will make it easier to work back to what should happen under the hood? :-) And maybe if we can document this well in rc.conf(5) for instance, it would make it easier for people to start with ipv6. BTW I have been running an ipv6 network for 10+ years, but the SLAAC acronym is still strange to me. :-) BTW2 RA on the network has bitten us a few times on the network, but it always turned out to be innocent mistakes. We have also had rogue DHCP servers, which also was innocent mistakes, so I doubt if just moving from RA to DHCP6 will be the answer. :-) John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 08:50:48 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 418AE106566C; Mon, 5 Apr 2010 08:50:48 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: from mail.droso.net (koala.ipv6.droso.net [IPv6:2001:6c8:6:c:20d:56ff:fe6f:f935]) by mx1.freebsd.org (Postfix) with ESMTP id D0A3E8FC15; Mon, 5 Apr 2010 08:50:47 +0000 (UTC) Received: by mail.droso.net (Postfix, from userid 1001) id 01D361CC1E; Mon, 5 Apr 2010 10:50:45 +0200 (CEST) Date: Mon, 5 Apr 2010 10:50:45 +0200 From: Erwin Lansing To: Garrett Cooper Message-ID: <20100405085045.GD35766@droso.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hTpalTKak4w3chvU" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD/i386 7.2-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Ports , FreeBSD Current , Xin Li Subject: Re: Ports breakage since r205471 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 08:50:48 -0000 --hTpalTKak4w3chvU Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 04, 2010 at 03:06:15PM -0700, Garrett Cooper wrote: > Hi all, > I realize that this is most suitable for current@ and I'm > cross-posting, but I wanted to jot down all of the ports broken since > the zlib version bump so that we can keep track of what's going on and > what needs to be fixed. I have just started a new package build against todays HEAD on pointyhat , actually before seeing this thread, so these, and any others, will be picked up there. I'll update the list with the results when it finishes in a day or two. >=20 > Also, I really think we should add packaging metadata to third > party libraries in base and at least track the versioning and > dependencies because this CURRENT upgrade has turned into a royal mess > and has eaten up more of my time than it should have. Unfortunately, the story of ports on CuRRENT :-( -erwin --=20 Erwin Lansing http://droso.org Prediction is very difficult especially about the future erwin@FreeBSD.org --hTpalTKak4w3chvU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iD8DBQFLuaRlqy9aWxUlaZARAv7PAKDZWJX6Kbz6g/BrN/Bb2ShyEaiW5gCg6qOP JpKrTrqECMnDnZkLgtdrAxI= =+1X2 -----END PGP SIGNATURE----- --hTpalTKak4w3chvU-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 09:01:36 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDAD7106567B for ; Mon, 5 Apr 2010 09:01:36 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7522E8FC2E for ; Mon, 5 Apr 2010 09:01:36 +0000 (UTC) Received: (qmail 6053 invoked by uid 399); 5 Apr 2010 09:01:35 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 5 Apr 2010 09:01:35 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BB9A6EB.3060202@FreeBSD.org> Date: Mon, 05 Apr 2010 02:01:31 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hiroki Sato References: <20100404053352.E6F751CC13@ptavv.es.net> <20100404.184141.03733377.hrs@allbsd.org> <4BB95564.1070604@FreeBSD.org> <20100405.144934.236135572.hrs@allbsd.org> In-Reply-To: <20100405.144934.236135572.hrs@allbsd.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 09:01:36 -0000 I think it's clear at this point that you and I have some pretty serious disagreements about how this thing should look. I think that's unfortunate, since you have a lot of good ideas, I just think some of them are wrong. :) Seriously though, I hope we can find a way to come to agreement. I'm going to repeat myself one more time here, and in response to your other post, and then step back and let others express their opinions. I'd really like to come to an agreement on how to proceed in the next couple days. On 04/04/10 22:49, Hiroki Sato wrote: > Doug Barton wrote > in <4BB95564.1070604@FreeBSD.org>: > > do> On 04/04/10 02:41, Hiroki Sato wrote: > do> > "Kevin Oberman" wrote > do> > in <20100404053352.E6F751CC13@ptavv.es.net>: > do> > > do> > ob> The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I > do> > ob> see no reason not to use them to enable or disable functionality whether > do> > ob> it involves a script in rc.d or not. The idea is to have a clear, > do> > ob> obvious way to enable or disable functionality. I see nothing in Hiroki's > do> > ob> proposal that is nearly as clear and to the point as 'ipv6_enable'. > do> > > do> > Another reason I lean to not using xxx_enable is that an rc.d knob > do> > cannot control enabling/disabling the IPv6 functionality actually. > do> > It was true even when we were using the network_ipv6 script. > do> > do> But that's equally true of how you're using ipv6_prefer. :) You've > do> basically just moved the overloading of 2 of the 3 previous functions of > do> ipv6_enable to ipv6_prefer. I am suggesting that we split all 3 > do> functions into different knobs. > > No, the current ipv6_prefer=NO has nothing to do with disabling IPv6. > It is just related to source address selection and a seatbelt for > IPv4-only people. I do not think I just moved the old functions. > > Let me explain how these changes happened. As I explained earlier, I > added $ipv6_prefer to *enable IPv6 by default*. IPv6 needs some > configuration even if you do not use IPv4 when the kernel supports > it, and skipping all of IPv6 configuration in the old > rc.d/network_ipv6 script caused another problems. So, I thought it > was possible to enable IPv6 by default and initialize the > functionality with reasonable default parameters. This parameters > included "disable ACCEPT_RTADV by default", which is one of the > topics we are discussing now. I think most of what you've got here is right, and I've tried to preserve it in my changes. My understanding is that lo0 needs to be configured if INET6 is in the kernel, but none of the other interfaces need to be. > The old rc.d/network_ipv6 had a lot more for IPv6 configuration in > the $ipv6_enable conditional clause and ipv6_enable=NO meant to > disable them, too. This is a big difference. The new ipv6_enable in > your patch is not the same in this regard. The end result is the same though. If ipv6_enable=no then when ifconfig_up() calls ipv6if() it'll come back negative, and that interface won't be configured for IPv6 at all. Specifically, the "inet6 ifdisabled" ifconfig arg will be given. > Well, I can understand and agree that people want a handy knob to > disable IPv6. I think it is more constructive for this discussion to > be more specific what should be disabled, then. I am still not sure > what you and other people mean by "disable IPv6". My definition is "not configuring IPv6 on any interface other than lo0." > My opinion is "ipv6_enable=NO" should mean disabling IPv6 > functionality completely. If we had a method of "turning off" IPv6 at the kernel level even though INET6 is in the kernel then I would agree with you. Since we don't have that, "inet6 ifdisabled" is the next best option. > I do not want to call a knob just to > ignore ifconfig_IF_ipv6 lines as "ipv6_enable" That's not what I'm proposing, have you actually looked at my patch? > as well as do not want > to disable IPv6 functionality completely by default. I don't know exactly what you mean by this. I _think_ you mean that IPv6 functionality should remain available, but that the interfaces should not be configured unless there is a specific configuration given via ifconfig_IF_ipv6. Is that right? If so, I agree with you, and my patch accomplishes this. The difference being that in v2 of the patch RA has to be enabled in ifconfig_IF_ipv6, OR it will be enabled if there is IPv4 DHCP configuration for the interface. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 09:03:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F373A106566B; Mon, 5 Apr 2010 09:03:06 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9E4968FC0C; Mon, 5 Apr 2010 09:03:05 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 85258A56481; Mon, 5 Apr 2010 17:03:04 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id Rbm0YNGZkNYw; Mon, 5 Apr 2010 17:02:54 +0800 (CST) Received: from delta.delphij.net (c-69-181-251-61.hsd1.ca.comcast.net [69.181.251.61]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 0CB5FA562E9; Mon, 5 Apr 2010 17:02:51 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=LWSxz5GdTZAysb+W4YtOjckfGN1xAziNpe2CIuVX1qZ9BfrFEjnroY1WdmqJPjK0w 6sZPhC6/YE1AyhviSiaDw== Message-ID: <4BB9A736.9040802@delphij.net> Date: Mon, 05 Apr 2010 02:02:46 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.8) Gecko/20100304 Thunderbird/3.0.3 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Erwin Lansing References: <20100405085045.GD35766@droso.net> In-Reply-To: <20100405085045.GD35766@droso.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Ports , Garrett Cooper , FreeBSD Current , Xin Li Subject: Re: Ports breakage since r205471 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 09:03:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010/04/05 01:50, Erwin Lansing wrote: > On Sun, Apr 04, 2010 at 03:06:15PM -0700, Garrett Cooper wrote: >> Hi all, >> I realize that this is most suitable for current@ and I'm >> cross-posting, but I wanted to jot down all of the ports broken since >> the zlib version bump so that we can keep track of what's going on and >> what needs to be fixed. > > I have just started a new package build against todays HEAD on pointyhat > , actually before seeing this thread, so these, and any others, will be > picked up there. I'll update the list with the results when it finishes > in a day or two. Which svn revision is currently using on the build cluster? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLuac2AAoJEATO+BI/yjfBusMH/jAc2pH439rkteRRX5oK+IXo hV3qXE0pMNkrGDDciVbYuJ9r/niqdkBIqaaw2te8K97YwBAdpikheHV0NaHoOzYT J+OiKmTu2o96J7FV7ORSRmPUcKhHHTjXwLMF2Kz9MeoRvYJqyVk1m33wMuDdIGEe 57Pxq3sXpbfmUoOq5S7ITLXSPqE+l5Xh0j4wM7wULQWhabTw1akliDGxvwr1XqrU 8r+3dbLASzV8hitIXk92MLCfomJNDgsW3VV3nqlzmiLlwBOfGrGowZblKlgHUWO4 VEJ6qCXpRPGpelIVSDyguR3BCEl2m9tyQ3xQ8MEznjwuOJGpp8vwNrwAUOB0PpE= =g4ur -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 09:12:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A59BF106566B; Mon, 5 Apr 2010 09:12:24 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: from mail.droso.net (koala.ipv6.droso.net [IPv6:2001:6c8:6:c:20d:56ff:fe6f:f935]) by mx1.freebsd.org (Postfix) with ESMTP id 675778FC19; Mon, 5 Apr 2010 09:12:24 +0000 (UTC) Received: by mail.droso.net (Postfix, from userid 1001) id 4D5B61CC22; Mon, 5 Apr 2010 11:12:23 +0200 (CEST) Date: Mon, 5 Apr 2010 11:12:23 +0200 From: Erwin Lansing To: Xin LI Message-ID: <20100405091223.GF35766@droso.net> References: <20100405085045.GD35766@droso.net> <4BB9A736.9040802@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LJuv+M/03Kgs6kNS" Content-Disposition: inline In-Reply-To: <4BB9A736.9040802@delphij.net> X-Operating-System: FreeBSD/i386 7.2-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Ports , Garrett Cooper , FreeBSD Current , Xin Li Subject: Re: Ports breakage since r205471 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 09:12:24 -0000 --LJuv+M/03Kgs6kNS Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 05, 2010 at 02:02:46AM -0700, Xin LI wrote: > On 2010/04/05 01:50, Erwin Lansing wrote: > > On Sun, Apr 04, 2010 at 03:06:15PM -0700, Garrett Cooper wrote: > >> Hi all, > >> I realize that this is most suitable for current@ and I'm > >> cross-posting, but I wanted to jot down all of the ports broken since > >> the zlib version bump so that we can keep track of what's going on and > >> what needs to be fixed. > >=20 > > I have just started a new package build against todays HEAD on pointyhat > > , actually before seeing this thread, so these, and any others, will be > > picked up there. I'll update the list with the results when it finishes > > in a day or two. >=20 > Which svn revision is currently using on the build cluster? >=20 Unfortunately, we're still using cvs for updating, but I just double checked that it is past r206058. The update is less than an hour old =66rom cvs. -erwin --=20 Erwin Lansing http://droso.org Prediction is very difficult especially about the future erwin@FreeBSD.org --LJuv+M/03Kgs6kNS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iD8DBQFLual3qy9aWxUlaZARAidGAKC4QKfUrl1IBBtvlMpQrP1hOqtgJwCeJEwT s7RRcVyRtm4Y9o+5YNuBMlk= =3VW1 -----END PGP SIGNATURE----- --LJuv+M/03Kgs6kNS-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 09:30:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67922106566B; Mon, 5 Apr 2010 09:30:13 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id D4FC68FC0C; Mon, 5 Apr 2010 09:30:12 +0000 (UTC) Received: by qyk11 with SMTP id 11so3791291qyk.13 for ; Mon, 05 Apr 2010 02:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uGB1KeIwIYkhXOc+TGnsL4C3Miud7+e92y1J4njEiAQ=; b=kkconCrPFOnP0ZP9NVSFZa3BpNZ4fwN3rQKSE/OpZL61kE392tWjFAkxpZUYsf5Fh7 ZRNjpwMoLCJxY7xD4bikHZrhOwJMtQejef164CEK85Y9SD7cOJ+izzQRK0mdFyhcaCLB 8nuu2i+XVj99Cyf/Beo7jxnAI8rJoOnkWZWJw= 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=UdNOTviMUKOk3+Tq9pCRsYYV/ke74vF5sRaq755cJ7h87jfPgSkeXoNkz536qs8aj7 9sBS+iDMB+/fCp908ZW4l4xz27I8mcKF6C8/pXNTdJIWuxexCBZBLVpVf5wGfYfk2dGA sGOMuGRhmRhN8WnJFwBHbBoEgNfX9cXMex/g0= MIME-Version: 1.0 Received: by 10.229.33.72 with HTTP; Mon, 5 Apr 2010 02:30:12 -0700 (PDT) In-Reply-To: <20100405091223.GF35766@droso.net> References: <20100405085045.GD35766@droso.net> <4BB9A736.9040802@delphij.net> <20100405091223.GF35766@droso.net> Date: Mon, 5 Apr 2010 02:30:12 -0700 Received: by 10.229.242.85 with SMTP id lh21mr8481161qcb.67.1270459812214; Mon, 05 Apr 2010 02:30:12 -0700 (PDT) Message-ID: From: Garrett Cooper To: Erwin Lansing Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Ports , Xin Li , FreeBSD Current , Xin LI Subject: Re: Ports breakage since r205471 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 09:30:13 -0000 On Mon, Apr 5, 2010 at 2:12 AM, Erwin Lansing wrote: > On Mon, Apr 05, 2010 at 02:02:46AM -0700, Xin LI wrote: >> On 2010/04/05 01:50, Erwin Lansing wrote: >> > On Sun, Apr 04, 2010 at 03:06:15PM -0700, Garrett Cooper wrote: >> >> Hi all, >> >> =A0 =A0 I realize that this is most suitable for current@ and I'm >> >> cross-posting, but I wanted to jot down all of the ports broken since >> >> the zlib version bump so that we can keep track of what's going on an= d >> >> what needs to be fixed. >> > >> > I have just started a new package build against todays HEAD on pointyh= at >> > , actually before seeing this thread, so these, and any others, will b= e >> > picked up there. =A0I'll update the list with the results when it fini= shes >> > in a day or two. >> >> Which svn revision is currently using on the build cluster? >> > Unfortunately, we're still using cvs for updating, but I just double > checked that it is past r206058. =A0The update is less than an hour old > from cvs. You won't see the issue unless you roll back to before r206057; r206057 and r206058 disguise the compatibility issue by completely zapping the #ifdef _LARGEFILE64_SOURCE and #if _FILE_OFFSET_BITS =3D=3D 64 enable pieces. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 09:44:39 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B39901065673 for ; Mon, 5 Apr 2010 09:44:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 5CA5E8FC13 for ; Mon, 5 Apr 2010 09:44:38 +0000 (UTC) Received: (qmail 26503 invoked by uid 399); 5 Apr 2010 09:44:37 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 5 Apr 2010 09:44:37 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BB9B104.1040404@FreeBSD.org> Date: Mon, 05 Apr 2010 02:44:36 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hiroki Sato References: <4BB70E1E.3090102@FreeBSD.org> <20100403.205140.26884732.hrs@allbsd.org> <4BB7E224.6020508@FreeBSD.org> <20100405.144252.55944627.hrs@allbsd.org> In-Reply-To: <20100405.144252.55944627.hrs@allbsd.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 09:44:39 -0000 On 04/04/10 22:42, Hiroki Sato wrote: > Doug Barton wrote > in <4BB7E224.6020508@FreeBSD.org>: > > If people want to disable IPv6 GUA assignment in per-AF manner, it > should be done by per-AF global knobs for $ifconfig_* because the GUA > assignment involves $ifconfig_* knobs only for the user as explained > in another email. To be honest, I think what you're proposing is way too complicated, and unnecessarily so. I think you've got a very interesting vision for where we should end up down the road, but as I said in a previous message I think your proposed UI is much too complex. > Let me summarize what I agree and disagree again: > > a. I agree that it is useful to have a knob for disabling all of > ifconfig_IF_ipv6 handling. That's not what I'm actually proposing. Your idea is that the model should be focused on ifconfig_IF_ipv6. I'd like to make that completely unnecessary for the common case (RA). > However, I disagree with using the > name "ipv6_enable" just for the purpose. ipv6_enable=NO never > means disabling IPv6 functionality in the kernel, and it will > cause people tend to think IPv6 is disabled completely. Throughout this discussion you've been ignoring something very important. The ipv6_enable knob already existed, and already had well understood semantics, which you removed. IMO this is a serious POLA violation. What I'm suggesting is a return to the same semantics that we had previously, but with your improvements running under the hood. I think being able to disable RA particularly and IPv6 generally on a per-interface basis is a tremendous improvement. > If we want to disable ifconfig_IF_AF lines in a handy manner, > implementing ifconfig_DEFAULT_AF is more consistent and where we > should go. All of AF-specific parameters for an interface are in > $ifconfig_IF_AF, and having a global knob to define the default > for all interfaces are quite reasonable to me. I do not want to > go back to AF-specific handling like ipv6_* wherever possible. > > I think this policy is compatible with David Horn's suggestions. > "ifconfig_DEFAULT_ipv6=DHCP" for DHCPv6 by default, > "ifconfig_DEFAULT_ipv6=accept_rtadv" for SLAAC by default, > "ifconfig_fxp0_ipv6=-accept_rtadv" for no-SLAAC for fxp0, for > example (note that I do not stick to these keywords. "slaac" > would also be a good candidate). No concern for > conflicting/confusing with IPv4; this is orthogonal among AFs. We > can support another new method by just adding a keyword. Once again, I think what you're proposing is interesting, but way too complex. I certainly think it's too complex as a first step. > Note that SLAAC and DHCPv6 are exclusive. That's not accurate, but it's outside the scope of this issue. > Combinations of > DHCPv6-NA + SLAAC, or DHCPv6-PD + SLAAC are not extreme (the > latter is rather popular). This is one of the reasons I stick to > the per-IF/per-AF solution here. Once again, we don't disagree on the principle, that's why I'm adding support for [NO]RTADV so that down the road we could have something like ifconfig_IF_ipv6="RTADV DHCPV6-PD", etc. > b. Disagree with disabling IPv6 by default. I think there is no > technical and security reason to go back to the old days. Need to be clear on what this means. Given that INET6 is in GENERIC (which I think it should be) we have to have a sensible default when it comes to configuring the external interfaces. IMO the only sensible default for that is not to. Configuring them by default when the user doesn't actually have IPv6 connectivity to the outside world would cause a lot of problems. > And, well, please let me suggest something for the further discussion > here. Whether we have $ipv6_enable or not, whether we enable > $ipv6_enable by default or not, and whether receiving RA by default > or not, are separated topics from each other. So, I would like > everyone's opinions for the following points separately: > > 1. Do we need a knob to disable IPv6? If so, which in the following > is expected for that knob? > > 1-a) Disable ifconfig_IF_ipv6 processing only. This means people > can still do manual configuration for IPv6. My version of the patch does this. > 1-b) Disable IPv6 functionlity completely. We don't currently have a way to do this at all if INET6 is in the kernel. > 2. If we have a knob described in 1, what should be the default > value? Off. > 3. Do we go for "accept RAs by default"? We can break down this in > the following way related to 2: > > 3-a) Enable IPv6 functionality and accept RAs by default. > > 3-b) Enable IPv6 functionality and not accept RAs by default > > 3-c) Disable IPv6 functionality by default and accept RAs if one > enables IPv6 in rc.conf. I think this is the right answer, but others have expressed disagreement on accepting RAs by default. > 3-d) Disable IPv6 functionality by default and not accept RAs even > if one enables IPv6 in rc.conf. 3-e) ipv6_enable=no by default, RAs if DHCP is configured for the interface, or if the user explicitly configures it. > My answers for them are: > > 1. No objection for 1-a, but if so the name $ipv6_enable is wrong to > me. If people needs 1-b, it should be $ipv6_enable. I have no > strong opinion on whether we have one of or both of them. If we > can reach a consensus to have 1-b, I am ready to implement the > necessary changes. I would really appreciate it if you'd take a serious look at my v6-enable-2.diff patch. I think it does a pretty good job of restoring the previous UI and still maintaining the best of your improvements. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 05:51:12 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD57B106564A; Mon, 5 Apr 2010 05:51:11 +0000 (UTC) (envelope-from hrs@allbsd.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 876848FC19; Mon, 5 Apr 2010 05:51:10 +0000 (UTC) Received: from delta.allbsd.org (p3177-ipbf416funabasi.chiba.ocn.ne.jp [123.225.92.177]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id o355o5tN017688; Mon, 5 Apr 2010 14:50:15 +0900 (JST) (envelope-from hrs@allbsd.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id o355nwE3009756; Mon, 5 Apr 2010 14:50:04 +0900 (JST) (envelope-from hrs@allbsd.org) Date: Mon, 05 Apr 2010 14:49:34 +0900 (JST) Message-Id: <20100405.144934.236135572.hrs@allbsd.org> To: dougb@FreeBSD.org From: Hiroki Sato In-Reply-To: <4BB95564.1070604@FreeBSD.org> References: <20100404053352.E6F751CC13@ptavv.es.net> <20100404.184141.03733377.hrs@allbsd.org> <4BB95564.1070604@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Apr__5_14_49_34_2010_566)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Mon, 05 Apr 2010 14:50:36 +0900 (JST) X-Spam-Status: No, score=0.2 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, X_MAILER_PRESENT autolearn=unavailable version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org X-Mailman-Approved-At: Mon, 05 Apr 2010 11:54:04 +0000 Cc: freebsd-current@FreeBSD.org Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 05:51:12 -0000 ----Security_Multipart(Mon_Apr__5_14_49_34_2010_566)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Barton wrote in <4BB95564.1070604@FreeBSD.org>: do> On 04/04/10 02:41, Hiroki Sato wrote: do> > "Kevin Oberman" wrote do> > in <20100404053352.E6F751CC13@ptavv.es.net>: do> > do> > ob> The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I do> > ob> see no reason not to use them to enable or disable functionality whether do> > ob> it involves a script in rc.d or not. The idea is to have a clear, do> > ob> obvious way to enable or disable functionality. I see nothing in Hiroki's do> > ob> proposal that is nearly as clear and to the point as 'ipv6_enable'. do> > do> > Another reason I lean to not using xxx_enable is that an rc.d knob do> > cannot control enabling/disabling the IPv6 functionality actually. do> > It was true even when we were using the network_ipv6 script. do> do> But that's equally true of how you're using ipv6_prefer. :) You've do> basically just moved the overloading of 2 of the 3 previous functions of do> ipv6_enable to ipv6_prefer. I am suggesting that we split all 3 do> functions into different knobs. No, the current ipv6_prefer=NO has nothing to do with disabling IPv6. It is just related to source address selection and a seatbelt for IPv4-only people. I do not think I just moved the old functions. Let me explain how these changes happened. As I explained earlier, I added $ipv6_prefer to *enable IPv6 by default*. IPv6 needs some configuration even if you do not use IPv4 when the kernel supports it, and skipping all of IPv6 configuration in the old rc.d/network_ipv6 script caused another problems. So, I thought it was possible to enable IPv6 by default and initialize the functionality with reasonable default parameters. This parameters included "disable ACCEPT_RTADV by default", which is one of the topics we are discussing now. After I moved the initialization outside of the $ipv6_enable, then I noticed that the rest which should be inside of the $ipv6_enable is IPv6 GUA address assignments and routing settings only. Here I stepped further; I changed the disabling feature of $ipv6_enable into "whether an IPv6 address is assigned or not". That was the whole story. The old rc.d/network_ipv6 had a lot more for IPv6 configuration in the $ipv6_enable conditional clause and ipv6_enable=NO meant to disable them, too. This is a big difference. The new ipv6_enable in your patch is not the same in this regard. Well, I can understand and agree that people want a handy knob to disable IPv6. I think it is more constructive for this discussion to be more specific what should be disabled, then. I am still not sure what you and other people mean by "disable IPv6". My opinion is "ipv6_enable=NO" should mean disabling IPv6 functionality completely. I do not want to call a knob just to ignore ifconfig_IF_ipv6 lines as "ipv6_enable" as well as do not want to disable IPv6 functionality completely by default. So I am interested in what people want more precisely. -- Hiroki ----Security_Multipart(Mon_Apr__5_14_49_34_2010_566)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAku5ee4ACgkQTyzT2CeTzy3MCQCg3HuI3VtZ2CqJjqcmBpRpE0hQ gAsAn00OHyhd0Ef//mYQSGxM168Qe5VD =gL4z -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Apr__5_14_49_34_2010_566)---- From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 13:34:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 647C410656DB; Mon, 5 Apr 2010 13:34:23 +0000 (UTC) (envelope-from jhellenthal@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 23CF68FC17; Mon, 5 Apr 2010 13:34:22 +0000 (UTC) Received: by pvc7 with SMTP id 7so1805231pvc.13 for ; Mon, 05 Apr 2010 06:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=rUkwpeduTdQ2Sj1eZOpx9VVPPeu+AnoIsjbIRCMrKz0=; b=NFYUrCfs0HAoAfyw9aN4uOX1OK4x/3WQ5WsgzYFs9PBg9rBFMlkkFHRoGSZ8aYeTzc ppTL37DR0N71ZgQDQBP5J7msdgNXXyTGXA2iVXdNLeFox5KUsfsosktdvKwhyXlqKNAK Vm1KylnOLvtrZzhJO2D16aVBLPDF7KHOp8hcA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=nQDGC89wQIQnfYC59vO0lNlJj6XGgQpwNhzIvs8saMNAaD2D61PsODY8kctEFeOZek du7fnag8QdzFZ154Uhpj8j5VvV3haXJKk7Ikz2DJFj9triVJvXRjjwxwd/1t1UFxY/4V 7llieR75u28iYLp/qRo1OXR/wGZqJeCLr2nhk= Received: by 10.142.207.20 with SMTP id e20mr1818230wfg.122.1270474462575; Mon, 05 Apr 2010 06:34:22 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-151-92.dsl.klmzmi.sbcglobal.net [99.181.151.92]) by mx.google.com with ESMTPS id 20sm4581343iwn.1.2010.04.05.06.34.20 (version=SSLv3 cipher=RC4-MD5); Mon, 05 Apr 2010 06:34:21 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4BB9E6B6.6070205@dataix.net> Date: Mon, 05 Apr 2010 09:33:42 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: Kevin Oberman References: <20100405042138.46F2E1CC13@ptavv.es.net> In-Reply-To: <20100405042138.46F2E1CC13@ptavv.es.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Doug Barton , freebsd-current@freebsd.org Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 13:34:23 -0000 On 04/05/2010 00:21, Kevin Oberman wrote: >> Date: Sun, 04 Apr 2010 20:13:40 -0700 >> From: Doug Barton >> >> On 04/04/10 02:41, Hiroki Sato wrote: >>> "Kevin Oberman" wrote >>> in <20100404053352.E6F751CC13@ptavv.es.net>: > > Gentlemen, > > I think this is converging on a good, functional solution. Making > ipv6_enable="NO" really turn off IPv6 looks like the ideal answer, but I > think it's up to Hiroki to determine if it is feasible. I did my last > kernel programming on VMS about 25 years ago and it was in assembly and > BLISS, not C. > > I am just a bit uncomfortable with the use of the DHCP tag in rc.conf > to control the use of SLAAC as SLAAC is so different in function and > capability from DHCPv4, but it's probably the best we can do. > > Thanks to both of you for your attention to this. I think IPv6 is > critical and anything that makes the transition easier will bear great > fruit at time goes on. Not really seeing the correct thread to reply to with this content I decided to reply to Kevin and lead off from here. Seeing a lot of *_enable for interfaces makes sense in the traditional way of configuring daemons or enabling things like rtsold/rtadvd for IPv6. Don't get me wrong but the below I am not talking about phasing those _enables out for the daemons. Personally I believe that using them for such a behavior as configuring a protocol for a interface is incorrect usage given the current use of IPv4 and not needing something like ipv4_enable. Why not skip the need for ipv?_enable all-in-all and leave those out of the mix?. Since they do not really disable them or enable anything other than the ability to use and or check ipv6 related daemons. How about this? (using ath0 as the example interface) and following what we already do for DHCP on ipv4 interfaces. ifconfig_ath0_inet6="dead:beef:ffff:1000::1 RTSOL RTADV DHCP" While right now without inet6 would obviously be ipv4 configured and when the time comes to switch to IPv6 by default, chop the inet6 into just inet or inet4. This eventually should lead into a smoother transition than ipv4_enable ipv6_enable while relieving some of the checks that to me just seem useless and can be checked for just by the existance of the above interface with inet6 attached to the end. Obviously if the configuration line exists then the user wants ipv6 functionality configured so check that line and mark ipv6 enabled. Maybe its just me but I really think we are trying to check for way to much here to make it a usable solution for the end user. No offense intended. PS: I would really love to sort(1) a rc.conf and have ipv4 and ipv6 functionality sorted together by interface but this is not my main goal by writing this. Same would go for static_routes but that is another story. Regards, -- jhell From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 14:35:23 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 413DF1065670; Mon, 5 Apr 2010 14:35:23 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 41C7B8FC1A; Mon, 5 Apr 2010 14:35:22 +0000 (UTC) Received: from delta.allbsd.org (p3177-ipbf416funabasi.chiba.ocn.ne.jp [123.225.92.177]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id o35EYu8s027455; Mon, 5 Apr 2010 23:35:07 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id o35EYpJ4000487; Mon, 5 Apr 2010 23:34:54 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 05 Apr 2010 23:33:58 +0900 (JST) Message-Id: <20100405.233358.119402511.hrs@allbsd.org> To: jhay@meraka.org.za From: Hiroki Sato In-Reply-To: <20100405083056.GA8863@zibbi.meraka.csir.co.za> References: <4BB7E224.6020508@FreeBSD.org> <20100405.144252.55944627.hrs@allbsd.org> <20100405083056.GA8863@zibbi.meraka.csir.co.za> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Apr__5_23_33_58_2010_468)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Mon, 05 Apr 2010 23:35:14 +0900 (JST) X-Spam-Status: No, score=0.3 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: freebsd-current@FreeBSD.org, dougb@FreeBSD.org Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 14:35:23 -0000 ----Security_Multipart(Mon_Apr__5_23_33_58_2010_468)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Hay wrote in <20100405083056.GA8863@zibbi.meraka.csir.co.za>: jh> These questions actually start more questions for me. :-) Maybe we should jh> also think from the user perspective and list a few use cases and what a jh> user need to put in rc.conf to make that work? jh> jh> Your normal desktop/notebook user on a ipv6 radv network, what does he jh> need to do to have his machine ipv6 usable? Given that it is 9-CURRENT and the box has 1 NIC (fxp0), add the following line to rc.conf: ifconfig_fxp0_ipv6="accept_rtadv" jh> A network server that does not accept radv, what should its ipv6 config jh> in rc.conf look like? ifconfig_fxp0_ipv6="inet6 2001:db8:1::1/64" jh> What about a server that accept radv (so that it can get router info) jh> and have fixed addresses for it services? ifconfig_fxp0_ipv6="inet6 2001:db8:1::1/64 accept_rtadv" jh> A router kind of box, what should it look like? Given that the box has 2 NICs (fxp0 and fxp1), add the following lines to rc.conf: ipv6_gateway_enable="YES" ifconfig_fxp0_ipv6="inet6 2001:db8:1::1/64" ifconfig_fxp1_ipv6="inet6 2001:db8:2::1/64" And, no ifconfig_IF_ipv6 line means no IPv6 configuration for the IF. After my changes committed last September, the existence of ifconfig_IF_ipv6 is used as a flag for whether IPv6 is enable or not on that interface. -- Hiroki ----Security_Multipart(Mon_Apr__5_23_33_58_2010_468)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAku59NYACgkQTyzT2CeTzy2MswCeKSh3MG1l3UIhCDTERU3rmbFy GuwAoN4z2snV9rCiaGawfiYpTdRcIg8l =Aoyt -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Apr__5_23_33_58_2010_468)---- From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 15:12:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7B70106566C for ; Mon, 5 Apr 2010 15:12:09 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 628DD8FC15 for ; Mon, 5 Apr 2010 15:12:09 +0000 (UTC) Received: by bwz8 with SMTP id 8so3023748bwz.3 for ; Mon, 05 Apr 2010 08:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=+LEQksNfEJJH/WTQCW280kjPBwDZFVYvM+FLOv6JayQ=; b=VT1Ny4wXlozJxx3WOQd/paG1n3rOohj82/dICBeMCPASixpcrpE9+ED59/3NC/I22U ys5RpaDQiHq10tVviYawTLJLmP36mAzNzX8LnJeXQ31DzJxRksmXbKqyABEQ6P1RIc0h WRZlY3BfZSbEniu7HLYjGOKj777y0lYDxTc0g= 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 :content-type; b=Pv8tINN+FuxK7M36tNQwkFOqXn03Ontt/fBhLQ4CqedSxo2EVNNzJBjWw9G8iOliec S1TGKh6qv6lQ1wISyUMwUpMXOo0jHtYkj6EVXyEVqgNCx3nk+ObJOTeL8tk7oJMineAA ilduK4Klc65NZosNIX22DLPHmQAMDsuM+x6Wk= MIME-Version: 1.0 Received: by 10.204.47.232 with HTTP; Mon, 5 Apr 2010 08:12:08 -0700 (PDT) In-Reply-To: References: <20100312171758.GB31089@dragon.NUXI.org> <20100312.125032.270969355930630649.imp@bsdimp.com> <20100322185331.GA88847@dragon.NUXI.org> <20100322.130939.70320533309323962.imp@bsdimp.com> Date: Mon, 5 Apr 2010 19:12:08 +0400 Received: by 10.204.175.14 with SMTP id v14mr6632841bkz.72.1270480328432; Mon, 05 Apr 2010 08:12:08 -0700 (PDT) Message-ID: From: pluknet To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 15:12:09 -0000 Hi, the interesting part for me is how to properly assert now a value of e.g. KINFO_PROC_SIZE varying on err.. different COMPAT_FREEBSD32 arches (say, FreeBSD would have _kern_proc FreeBSD32 compat layer for top/ps/). -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 15:52:19 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51E79106564A for ; Mon, 5 Apr 2010 15:52:19 +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 8AE618FC0A for ; Mon, 5 Apr 2010 15:52:18 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 5006741C712 for ; Mon, 5 Apr 2010 17:52:17 +0200 (CEST) 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 FaYoJkwc-flW for ; Mon, 5 Apr 2010 17:52:16 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 677A141C6B4; Mon, 5 Apr 2010 17:52:16 +0200 (CEST) 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 8129D4448EC for ; Mon, 5 Apr 2010 15:52:03 +0000 (UTC) Date: Mon, 5 Apr 2010 15:52:03 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD current mailing list In-Reply-To: <4BB9E6B6.6070205@dataix.net> Message-ID: <20100405141615.F40281@maildrop.int.zabbadoz.net> References: <20100405042138.46F2E1CC13@ptavv.es.net> <4BB9E6B6.6070205@dataix.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD current mailing list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 15:52:19 -0000 On Mon, 5 Apr 2010, jhell wrote: Hi, reading the thread in thread view I had wondered why your reply had been ignored until I realized that it was the last to come in. So I'll use it to reply to, especially as I like it. I have no idea (unless I'll read them) about the guts of various shell function magic we use to configure interfaces, and I heck do not care about where it's called autoblah_foo or zigbangbusheek as none of our users does, so I'll ignore that. I'll probably have to comment on a few rc.conf knobs as that's all a user cares about. > Not really seeing the correct thread to reply to with this content I > decided to reply to Kevin and lead off from here. > > Seeing a lot of *_enable for interfaces makes sense in the traditional > way of configuring daemons or enabling things like rtsold/rtadvd for > IPv6. Don't get me wrong but the below I am not talking about phasing > those _enables out for the daemons. > > Personally I believe that using them for such a behavior as configuring > a protocol for a interface is incorrect usage given the current use of > IPv4 and not needing something like ipv4_enable. > > Why not skip the need for ipv?_enable all-in-all and leave those out of > the mix?. Since they do not really disable them or enable anything other > than the ability to use and or check ipv6 related daemons. As said, I like the idea of simplification. And I like the idea of having: ifconfig__ipv6="inet6 ..." ifconfig__ipv6_alias="inet6 ..." as well as ipv6_defaultrouter=".." ipv6_static_routes=".." ipv6_gateway_enable=".." An I like it for IPv4 and actually if you look at defaults/rc.conf you will find that we even liked it for: ifconfig_ed0_ipx="ipx 0x00010010" ipxgateway_enable="NO" So here comes one of the things I don't like, POLA back POLA forth. None of the three AFs was implemented in a consistent way. In the old days we used (and still) have (though a lot less) a mix of "ip6" and "ipv6" and while IPv4 was kind of "default" there was no ifconfig__ipv4=".." which has historic reasons I believe but it was ifconfig__ipx= and I like it that it's ifconfig__ipv6 now. It should be ipx_gateway_enable instaed of ipxgateway_enable but that's something to cleanup more easily;) Neither IPv4 nor IPX have an _enable="" knob in defaults/rc.conf and I cannot see why we would need it for IPv6. You don't configure it on an interface you don't have it configured an interface. The fact that it had been there for IPv6 is historic and could have been a good or bad idea at that time during the early days of development. I am actully too lazy to see why it had really been added. If I boot up without having any RC framework or anything but the shell run, these days I get a network stack with a loopback interface and it looks like this: # ifconfig -a lo0: flags=8008 metric 0 mtu 16384 options=3 if it also had an interface it would look like this: iface: flags=8842 metric 0 mtu 1500 ether 02:00:00:00:07:0a There is no IPv6 address, there is no IPv4 address, they are down because noone told them to be up. If I "up" them manually it looks like this: lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 nd6 options=21 iface: flags=8843 metric 0 mtu 1500 ether 02:00:00:00:07:0a inet6 fe80::ff:fe00:70a%iface prefixlen 64 scopeid 0x2 nd6 options=21 This actually is bad but that's because neither devd nor the rc framework were run yet and the kernel defaults were never changed (if my memory serves me right for RFC reasons). Silly me doing this in "single user";) I wouldn't want to have a link-local address on my non-loopback interfaces working unless I asked for them. That's why we had ipv6_autolinklocal in the past and that's why the current rc/devd/iface framework prevents this from happening unless explicitly asked for. That's why there is nd6 options=. If if were to implement 3927 (I think it was) 169.254.0.0 stuff like some other OSes do we would want to control that as well and have it off by default. Why do I not want that for our users? Let me repeat the argument from a couple of years ago from other people: "If I put my FreeBSD machine anywhere and I have no clue about IPv6 I don't want my neighbor to ping6 or ssh or even compromise my machine just because I didn't know we have this kind of thing and autom-agic happened." That's why link-local addresses had been disabled in the past (similar arguemnts would apply for the 169.254/16 case). Re-enabling them had never worked well in the past if ipv6_enable was NO on boot. You had to change the sysctl (manually) and then down up the interface(s) leading to serivce interruption even for IPv4. There is a PR about it if you want to check. In the past there was no way to express "enable it on my wired interface but not on my wireless" or "enable on the inside but not the outside interface" or enabled/disable it smoothly on run-time. It was global which was bad and has been fixed. I can savely put my FreeBSD laptop on a conference LAN and have DHCP enabled and be sure I'll only get at best an IPv4 address on the interface. I can configure IPv6 on my interfaces and not even have to think about IPv4 if not configured. Similary I do not have to think of IPv6 tcp_wrappers or firewalls or if my sshd would be reachable from the local LAN with hundreds of unknown people. I can savely express accept rtadv on the left interface but not on the right. I can say I want an IPv6 link-local on this one but not the others. I can even say "disable IPv6 processing on this interface" (kind of) and we actually do by default. Having any kind of auto-magic happen with an IPv4 DHCP knob for IPv6 will get us back to where we had been 6 years ago - or actually would make it worse as we'd mix v4 and v6 config options even more again. I don't want to go back. I want to move forward. I am trying to think of a reason I had needed ipv6_interfaces in the past and I can find some. I have checked my current configurations and I couldn't find any instance of *interfaces anymore. Being able to use ifconfig_**, especially with the IPv6 per interface options, seems to have fixed all for me with the current implementation. Why do we need ipv6_prefer? Well, actually we do not need it. We could have people use ip6addrctl and a static config file with their preference. It's really something entirely different to the overall interface configuration story and RS/RA things. It is one of those knobs like v4-mapped-v6 addresses that are supposed to ease transition (but not only). I actually do not care what it will end up by default if does what I tell it by configuration prefer IPv6 over IPv4 or not. It's one of the ipv6_ variables I might have to set if I would want IPv6 by default. It's a shame we didn't have that to decide whether to use IPX over IP or not;-) If you want to "fix" that make it more "if6addrctl" a-like so people can not only have YES/NO default but also a config file but I bet even fewer people will understand it; the current thing "just works" for users. So what do you people actually want to change? You want auto-magic to happen (again) that suits your local setup or that does what we used to have in the 5.x days? Well put your "local" needs into ifconfig__ipv6 and be done. Once DHCPv6 would come to your setup you would to undo some of this "automagic" again anyway and say ifconfig__ipv6="DHCP[6]" and be done. Right? If you want to help users running FreeBSD desktops build a crazy blinky app that says "Oh I have sniffed this network and found IPv6 was available but you haven't enabled it. Do you want to use it? Yes? Should I start the firewall for it as well?" and add some big buttons with smileys dancing kames and hopping Google letters but please do not have us make two steps backwards again. You want "sane" defaults for users? The only sane default is "if there is nothing configured, don't do anything" for everything else you need a good crystal ball and if you had that you wouldn't be here but would have won the lottery long ago. my 2cts. -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 18:50:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A970106566B for ; Mon, 5 Apr 2010 18:50:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 03BFD8FC18 for ; Mon, 5 Apr 2010 18:50:33 +0000 (UTC) Received: by bwz8 with SMTP id 8so3178205bwz.3 for ; Mon, 05 Apr 2010 11:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:subject :message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=Lq9rF9pfcdrhOhP5hdEIdMP6zmxoqzaGh2QqLVQppq4=; b=PAnR4706hGsVldK69icYqGfE2nQ8liEBYki4VTCXuIWQt+4I/S7UgHugc6JKcrXJN3 rFyDcBV0SnzGCdQiEbgvVBjmtc1A4l+Qqz/1kEhbBItAru8LfB107SySCcUdr7hE1XvM YYemxeRRVgeM5ltj7N87SI2oyT9acQw3RCP18= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=VafRdeSheZ7rH56sZivFon77zK0q5qMy+aodHSbP87/E744Sr5pazD0tAeRIw1OGKs y3tDP2gPe7XFWc3b6r8qgwzwzukDHuveLdWG2DvzwwWf1dAdiIswE5vUNrOjQtfjwUN5 FCnZ3pFtekvwZ1Nm/AihD1fRW1mNwMA+RtESE= Received: by 10.204.9.152 with SMTP id l24mr7141618bkl.193.1270493432798; Mon, 05 Apr 2010 11:50:32 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id s17sm107881900bkd.16.2010.04.05.11.50.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 05 Apr 2010 11:50:31 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 5 Apr 2010 11:50:25 -0700 From: Pyun YongHyeon Date: Mon, 5 Apr 2010 11:50:25 -0700 To: freebsd-current@FreeBSD.org Message-ID: <20100405185025.GE1225@michelle.cdnetworks.com> References: <20100405010054.GA1225@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100405010054.GA1225@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Call for testers: fxp(4) Rx buffer use after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 18:50:34 -0000 On Sun, Apr 04, 2010 at 06:00:54PM -0700, Pyun YongHyeon wrote: > Hi, > > It seems that fxp(4) has a long standing races between controller > and driver. The exotic RFD handling of controller is race prone as > we had seen old ethernet controllers. I could easily reproduce this > by rebooting system while netperf 64bytes UDP test is in progress. > If heavy RX frames hit the controller while interface UP is in > progress, controller started DMAing to freed mbufs such that > "Memory modified after free" message showed up. Based on OpenBSD's > patch I made a patch which seems to fix the issue. > If you saw this type of issue please give it try and let me how > it goes on your box. The patch has effect only on interrupt mode so > if you're using polling(4) you would have no effects. > You can get download the patch at the following URL. > http://people.freebsd.org/~yongari/fxp/fxp.rx.race.patch > > After applying the patch you may see somewhat increased RNR counter > value from sysctl node(dev.fxp.0.rnr). Previously fxp(4) might have > lower RNR counter value but that fake value came from DMAing to > freed mbufs which was completely wrong. > Hmm, it seems there are other issues in the patch. I'll post new patch after fixing this. > Thanks. From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 22:12:39 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFCF0106566B; Mon, 5 Apr 2010 22:12:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B65CD8FC14; Mon, 5 Apr 2010 22:12:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o35MCcQV037212; Mon, 5 Apr 2010 18:12:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o35MCcPn037211; Mon, 5 Apr 2010 22:12:38 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 5 Apr 2010 22:12:38 GMT Message-Id: <201004052212.o35MCcPn037211@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 22:12:40 -0000 TB --- 2010-04-05 20:44:45 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-05 20:44:45 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-04-05 20:44:45 - cleaning the object tree TB --- 2010-04-05 20:45:08 - cvsupping the source tree TB --- 2010-04-05 20:45:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-04-05 20:45:22 - building world TB --- 2010-04-05 20:45:22 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-05 20:45:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-05 20:45:22 - TARGET=ia64 TB --- 2010-04-05 20:45:22 - TARGET_ARCH=ia64 TB --- 2010-04-05 20:45:22 - TZ=UTC TB --- 2010-04-05 20:45:22 - __MAKE_CONF=/dev/null TB --- 2010-04-05 20:45:22 - cd /src TB --- 2010-04-05 20:45:22 - /usr/bin/make -B buildworld >>> World build started on Mon Apr 5 20:45:23 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Apr 5 22:02:36 UTC 2010 TB --- 2010-04-05 22:02:36 - generating LINT kernel config TB --- 2010-04-05 22:02:36 - cd /src/sys/ia64/conf TB --- 2010-04-05 22:02:36 - /usr/bin/make -B LINT TB --- 2010-04-05 22:02:36 - building LINT kernel TB --- 2010-04-05 22:02:36 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-05 22:02:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-05 22:02:36 - TARGET=ia64 TB --- 2010-04-05 22:02:36 - TARGET_ARCH=ia64 TB --- 2010-04-05 22:02:36 - TZ=UTC TB --- 2010-04-05 22:02:36 - __MAKE_CONF=/dev/null TB --- 2010-04-05 22:02:36 - cd /src TB --- 2010-04-05 22:02:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Apr 5 22:02:36 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/wi/if_wi_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/xe/if_xe.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/xe/if_xe_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/xl/if_xl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/fs/coda/coda_fbsd.c In file included from /src/sys/fs/coda/coda_fbsd.c:49: /src/sys/fs/coda/cnode.h:97: error: expected specifier-qualifier-list before 'CodaFid' /src/sys/fs/coda/cnode.h:199: error: expected ')' before '*' token *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-04-05 22:12:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-04-05 22:12:38 - ERROR: failed to build lint kernel TB --- 2010-04-05 22:12:38 - 4181.42 user 629.45 system 5273.71 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 22:38:24 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D7F1106566C; Mon, 5 Apr 2010 22:38:24 +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 DD7D78FC0A; Mon, 5 Apr 2010 22:38:23 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 7AFC446B2E; Mon, 5 Apr 2010 18:38:23 -0400 (EDT) Date: Mon, 5 Apr 2010 23:38:23 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: FreeBSD Tinderbox In-Reply-To: <201004052212.o35MCcPn037211@freebsd-current.sentex.ca> Message-ID: References: <201004052212.o35MCcPn037211@freebsd-current.sentex.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org, ia64@freebsd.org Subject: Re: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 22:38:24 -0000 On Mon, 5 Apr 2010, FreeBSD Tinderbox wrote: > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/wi/if_wi_pci.c > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/xe/if_xe.c > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/xe/if_xe_pccard.c > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/xl/if_xl.c > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/fs/coda/coda_fbsd.c > In file included from /src/sys/fs/coda/coda_fbsd.c:49: > /src/sys/fs/coda/cnode.h:97: error: expected specifier-qualifier-list before 'CodaFid' > /src/sys/fs/coda/cnode.h:199: error: expected ')' before '*' token Sorry all -- I'll commit a fix for this shortly -- my fault for building the modules rather than LINT: turns out that neither coda5 nor coda modules build the same code as the kernel. There's some argument coda5 should be removed at this point, but I'll leave that for another day. (waiting for LINT to compile ... this time) Robert From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 22:47:52 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38F81106566B; Mon, 5 Apr 2010 22:47:52 +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 1379F8FC12; Mon, 5 Apr 2010 22:47:52 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id A4E3D46B0C; Mon, 5 Apr 2010 18:47:51 -0400 (EDT) Date: Mon, 5 Apr 2010 23:47:51 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: FreeBSD Tinderbox In-Reply-To: Message-ID: References: <201004052212.o35MCcPn037211@freebsd-current.sentex.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org, ia64@freebsd.org Subject: Re: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 22:47:52 -0000 On Mon, 5 Apr 2010, Robert Watson wrote: >> In file included from /src/sys/fs/coda/coda_fbsd.c:49: >> /src/sys/fs/coda/cnode.h:97: error: expected specifier-qualifier-list >> before 'CodaFid' /src/sys/fs/coda/cnode.h:199: error: expected ')' before >> '*' token > > Sorry all -- I'll commit a fix for this shortly -- my fault for building the > modules rather than LINT: turns out that neither coda5 nor coda modules > build the same code as the kernel. There's some argument coda5 should be > removed at this point, but I'll leave that for another day. Perhaps it was a tinderbox race -- I can't reproduce this on amd64, and the line numbers don't really make sense. Oh well. I'll see if it pops up on other tinderboxen. Robert From owner-freebsd-current@FreeBSD.ORG Tue Apr 6 00:53:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E8FC106566B for ; Tue, 6 Apr 2010 00:53:43 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 583408FC15 for ; Tue, 6 Apr 2010 00:53:43 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id 68A2760D2 for ; Mon, 5 Apr 2010 20:53:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1270515222; bh=kt+mxCUBi2r9tyEBRiZjgfqUHDbWfzqPu3+iGBWe4xg=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=pC1fjhYHqoDrRBhDsu8exHzn5+eCln4kaBxrTpg7jsmmCdbdaSpzkCjr5DIQp5zI6 Ofl1Z/lyiv7MDzlCjqNf/x3uLO8k4KrW8LwVcDILK5X1dPFFVlV3v5gIPvxSo7k DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=AuX3WPTD7CIWLen21ewO+7O9gIHfFRoqIQ07/S/Iy3nP3KVP1b8tbM9+JwTeSB0mi Rg36zfNCIiEHrVM8dfRfFLIX5jpY54UfklBduv1iHN/fN99uSuJv5Q4rWANmn4A Message-ID: <4BBA8614.4000002@protected-networks.net> Date: Mon, 05 Apr 2010 20:53:40 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-current X-Enigmail-Version: 1.0.1 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Enabling AHCI on ICH7M X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 00:53:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My laptop manufacturer decided not to have AHCI included in the BIOS for this device, so I've been looking at what needs to happen in order to make this work. On this device, the BIOS doesn't even initialize BAR(5), so I need to start at that point .. from the Intel specs, it seemed fairly straight-forward: Give the AHCI sub-system a chunk of memory by initializing BAR(5), tell the PCI bridge(s) about it, reset the various config bits to flip from legacy to AHCI mode and leave the rest to what already exists in the ata-intel driver. My question, however, relates to the choice of memory: Can I simply call contigmalloc() to get a chunk of memory space whose physical address I can get with vtophys and leave the mapping for the PCI bridge to the existing call to bus_alloc_resource_any()? Is there a better method of finding some "free" physical space into which to put the ICH7M AHCI registers? imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAku6hhQACgkQQv9rrgRC1JJ9TgCghkR8j9xy2MbSNW1LSRMhzX6h AdAAnR6Ctnvyng4W9qRbP0vtM352SYSo =t6V3 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Apr 6 08:37:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82779106564A for ; Tue, 6 Apr 2010 08:37:13 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 0FE928FC0A for ; Tue, 6 Apr 2010 08:37:12 +0000 (UTC) Received: by bwz8 with SMTP id 8so3595306bwz.3 for ; Tue, 06 Apr 2010 01:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=r7W7eWgf+RlRY0b/BcriI7Y/oTOn4HUKb+JBC0b/ZDc=; b=L4UR/e59aX9yld4mxp4OqWKhzHfs077yDm9GxEsyk/sF8CS5/TzNCCFmRof88096FP STnnFr5e4/pNVcDHpr855LqC2R3FigTiivHZ5FN+JPnSw7iz2tsazahejm5ghFwc9BNp 1YOJ8o07t8oCoxY5FhMfa1jQyH8YA68AGL28k= 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=X4W/QKTn7QQtfoBRauMKZqvTanHNIsjCVfmUAGSJU4AoyUhxUrjGrliFm0CS2IsCA6 D2kZFb6M3Jn8gYvF9a2jMt4jJENCrgW3hwL5CZykYXpeBe9dRYjOiqVmYMnkqw+pxhLp wPiBLGdp6DcvcReMWoV1ktFhEm/9Qqexljq7w= MIME-Version: 1.0 Received: by 10.204.47.232 with HTTP; Tue, 6 Apr 2010 01:37:11 -0700 (PDT) In-Reply-To: <20091108143348.GQ2331@deviant.kiev.zoral.com.ua> References: <8f82c35c0911080555x6a0721fem7bc01d3e3ff30bcf@mail.gmail.com> <20091108143348.GQ2331@deviant.kiev.zoral.com.ua> Date: Tue, 6 Apr 2010 12:37:11 +0400 Received: by 10.204.162.199 with SMTP id w7mr7271282bkx.211.1270543031769; Tue, 06 Apr 2010 01:37:11 -0700 (PDT) Message-ID: From: pluknet To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Samba problems on 8.0-RC2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 08:37:13 -0000 On 8 November 2009 17:33, Kostik Belousov wrote: > On Sun, Nov 08, 2009 at 02:55:49PM +0100, Jon Theil Nielsen wrote: >> Hi >> >> After running the latest upgrade for samba33, I cannot start it anymore.= The >> error message is: >> *Starting smbd. >> /libexec/ld-elf.so.1: /usr/local/sbin/smbd: invalid PT_PHDR >> /usr/local/etc/rc.d/samba: WARNING: failed to start smbd* >> uname -a says: >> *mflserver2.mydomain.dk 8.0-RC2 FreeBSD 8.0-RC2 #0: Sun Nov =A08 02:37:4= 5 CET >> 2009 =A0 =A0 root@mydomain.dk:/usr/obj/usr/src/sys/SERVER2 =A0i386* >> I'm not sure if this problem is related to the system or to samba itself= . > > I think you have old rtld, i.e. it misses r197931, but new kernel. > Kernel maps PIE binaries at non-zero base address, that cannot be > properly handled by old rtld. > Hi. I faced this problem today on 7.3 kernel & 7.2 world. quagga refused to start bgpd with error: /libexec/ld-elf.so.1: /usr/local/sbin/bgpd: invalid PT_PHDR. Issue fixed after cp'ing /libexec/ld-elf.so.1 from 7.3 world. So I think the next entry probably needs to be (belatedly) added to 7'th UPDATING and/or errata as (as far as I know) that brakes "newer kernel usually works= with older world" users expectation. 20100119: PIE support has been improved. Kernel maps PIE binaries at non-zero base address. Users need to rebuild rtld(1) to hook up with a new kernel. --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Tue Apr 6 13:29:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AEEE1065672 for ; Tue, 6 Apr 2010 13:29:30 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by mx1.freebsd.org (Postfix) with ESMTP id AC5C38FC13 for ; Tue, 6 Apr 2010 13:29:29 +0000 (UTC) Received: by yxe4 with SMTP id 4so2865180yxe.28 for ; Tue, 06 Apr 2010 06:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=yFFefkVIXB9hISWtOa5UTve9qNUUOaE7YWy6Dy69BDI=; b=uh2GaAGFj2+IysZ7VbiKdpYsHRz6Z1afbj+pxxRQlO4XXizTtWV8OaLFp8ZJIB2WWn EMib59yJqV97754PIHOcmgUw5VV3dB9kGkxPVGgPvQupedNYcRuO/C6ZvzsvYP642QUb hxi+/zcajqpDzj5clJ6dXPwmEUsgLtdhcmyaY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=IGHcvfTdbpEBjyYZZIAbTJhapEk6JzUks9ZPKmIix1gPSqzTrrxmFnbYb0PHY0wj3d hiGUAFTkzaAFFQIaoLsdeiebcT0jmwzQHVu5VIfDc9u2cpnC6oXH/5s3dr3A6yZ6+JBl SNKgAnZ8ZWFI2Kwk3ngAetX1cEzH6QB4OW8Lk= Received: by 10.150.48.21 with SMTP id v21mr8284359ybv.323.1270560568847; Tue, 06 Apr 2010 06:29:28 -0700 (PDT) Received: from beastie.micom.mng.net ([202.179.21.137]) by mx.google.com with ESMTPS id 13sm8981842gxk.8.2010.04.06.06.29.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 06 Apr 2010 06:29:26 -0700 (PDT) Message-ID: <4BBB372C.1060302@gmail.com> Date: Tue, 06 Apr 2010 21:29:16 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.23 (X11/20091011) MIME-Version: 1.0 To: PseudoCylon References: <16641.96608.qm@web51806.mail.re2.yahoo.com> <4B9FA3E0.4050702@micom.mng.net> <633929.41041.qm@web51802.mail.re2.yahoo.com> <4BA22B8D.9030700@micom.mng.net> <375331.74876.qm@web51804.mail.re2.yahoo.com> <4BA38B26.6050208@micom.mng.net> <989377.89740.qm@web51802.mail.re2.yahoo.com> <4BAE01AC.7000509@gmail.com> <623907.37074.qm@web51803.mail.re2.yahoo.com> <4BB3575D.4040506@gmail.com> <87836.79143.qm@web51804.mail.re2.yahoo.com> In-Reply-To: <87836.79143.qm@web51804.mail.re2.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 13:29:30 -0000 PseudoCylon wrote: > ----- Original Message ---- > >> From: Ganbold >> To: PseudoCylon >> Cc: freebsd-current@freebsd.org >> Sent: Wed, March 31, 2010 8:08:29 AM >> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless >> >> Does stock run(4) support hostap mode yet? >> > > No. There were some bugs and I thought I fixed them. So, I called for test. It seems the driver is working on x86, but not on mips. hostap mode should work on your other computer with i386. > > I'm still working on patch. It panics where there wasn't any changes made. Strange... > Hi, Sorry, it looks like I missed some of your emails. Please let me know if you need any info from my side. thanks, Ganbold > > AK > > > __________________________________________________________________ > Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now > http://ca.toolbar.yahoo.com. > > -- It turned out that the worm exploited three or four different holes in the system. From this, and the fact that we were able to capture and examine some of the source code, we realized that we were dealing with someone very sharp, probably not someone here on campus. -- Dr. Richard LeBlanc, associate professor of ICS, in Georgia Tech's campus newspaper after the Internet worm. From owner-freebsd-current@FreeBSD.ORG Tue Apr 6 15:18:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FEE6106566B for ; Tue, 6 Apr 2010 15:18:15 +0000 (UTC) (envelope-from neshort@yahoo.com) Received: from web56507.mail.re3.yahoo.com (web56507.mail.re3.yahoo.com [66.196.97.36]) by mx1.freebsd.org (Postfix) with SMTP id C41688FC08 for ; Tue, 6 Apr 2010 15:18:14 +0000 (UTC) Received: (qmail 60377 invoked by uid 60001); 6 Apr 2010 15:18:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1270567093; bh=o2RYUJ6n+fNyRa8HITizTVzH0swwEGCnEmUPn3WG+tc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=trDReC3MPUcZmQXynq1yqI+gBYraknWNmoNad7kbu6skM0YscAXLzpFFIrQbMWV3+j4HqHOJOTEMLHvqaWJLfVBhP32oI2JfGhEwaZff9p8MCmlwWdyLs98yx3KbxhCBruaJv3aD0s97rbrEkk61TtDrVmvDvkKy7jG3g95PDPc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=zalKixSXcKRaJgMKMKmw4z9c1YLtD7fHHTzm3bRBpQOMRp3Sswkj9MasBVFI7EAEeJPqvBkvO1tg4krR3ZulPo7L8F7CEQccDdY6pr6ZTr6BsrQkerzR+jtyhMyQShvU8ABSVmGRnIEFiZs9PcMIuwf3G/Z0GHBrPOfn4k/AX+o=; Message-ID: <633876.59576.qm@web56507.mail.re3.yahoo.com> X-YMail-OSG: Yn4H3UUVM1m4LOOgrWSM5aeH5zrmYRcXANRD9ieeTclyDaP UIFqOVqD035W3UdNqvxckdnElHLUgfhsARMrabZPxDWp3ARbn0QS9E5zMLMW J3aNa4KS7TAbiTES9xCfnHcLKullWdl3ckBKlKkg5QnHe1Yx_dzFDPX36fJT yUe4YxX4FT_TNFJmGvgoutzvzhbHhQ_DLl2giygb59fruDGiYaizRpqk28C9 oCHMCTWI_zUIdNJEvLLftFm0blU6768YsYAre6GpaehzMNN8bEx_NZ_hb5oq BhYTEfxUjTDBBT2bS4gSla0744Fz8YymTTShDHysTsMrS2jUSVsAsRw-- Received: from [173.84.5.162] by web56507.mail.re3.yahoo.com via HTTP; Tue, 06 Apr 2010 08:18:13 PDT X-Mailer: YahooMailClassic/10.0.8 YahooMailWebService/0.8.100.260964 Date: Tue, 6 Apr 2010 08:18:13 -0700 (PDT) From: Neil Short To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 06 Apr 2010 15:21:44 +0000 Subject: atheros ar 9285 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 15:18:15 -0000 did the atheros ar 9285 patch ever get committed anywhere? I can't find it. ====== "What did you do?" the man holding the flashlight asked. "I put down a spider," he said, wondering why the man didn't see; in the beam of yellow light the spider bloated up larger than life. "So it could get away." From owner-freebsd-current@FreeBSD.ORG Tue Apr 6 15:24:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BDBD106566B for ; Tue, 6 Apr 2010 15:24:25 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id 386F28FC16 for ; Tue, 6 Apr 2010 15:24:24 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0L0G00220O4OO300@smtpauth3.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Tue, 06 Apr 2010 10:24:24 -0500 (CDT) Received: from comporellon.tachypleus.net (adsl-99-135-75-4.dsl.mdsnwi.sbcglobal.net [99.135.75.4]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0L0G00I1JO4M89A0@smtpauth3.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Tue, 06 Apr 2010 10:24:22 -0500 (CDT) Date: Tue, 06 Apr 2010 10:24:21 -0500 From: Nathan Whitehorn In-reply-to: To: pluknet Message-id: <4BBB5225.5020008@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=99.135.75.4 X-Spam-PmxInfo: Server=avs-12, Version=5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2010.4.6.151229, SenderIP=99.135.75.4 References: <20100312171758.GB31089@dragon.NUXI.org> <20100312.125032.270969355930630649.imp@bsdimp.com> <20100322185331.GA88847@dragon.NUXI.org> <20100322.130939.70320533309323962.imp@bsdimp.com> User-Agent: Thunderbird 2.0.0.24 (X11/20100320) Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 15:24:25 -0000 pluknet wrote: > Hi, > > the interesting part for me is how to properly assert now a value of e.g. > KINFO_PROC_SIZE varying on err.. different COMPAT_FREEBSD32 arches > (say, FreeBSD would have _kern_proc FreeBSD32 compat layer for top/ps/). > > Probably the cleanest thing would be to set KINFO_PROC_SIZE in machine/proc.h instead of where it is now, and then also define a KINFO_PROC32_SIZE or something in the same place. Also, that would be a really nice feature. -Nathan From owner-freebsd-current@FreeBSD.ORG Tue Apr 6 18:11:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 419FA106564A for ; Tue, 6 Apr 2010 18:11:45 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id B46358FC14 for ; Tue, 6 Apr 2010 18:11:44 +0000 (UTC) Received: by fxm26 with SMTP id 26so3848fxm.13 for ; Tue, 06 Apr 2010 11:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=uv8hoWNn3IbeR3wl6Z1URQFVrl1SB5LjzjrQaat16uw=; b=loZIZEHAC6xq2wwm20ol4LWAMx+PQz1QLcpQ5VYhX2WHuhuDsxrc6Zzd/BfXN7RQTA po1wWEtlDZLqODbXLOfue6nhntgsNycjdB+l03CGZ800UQep2dHzPSVgbSdGs71YQjaL R6sgFhFJJgmW2+HOq0Y7AZz/O+kX6hBuIaeec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=rn2eQOlHNfUK90sEPI8QweJ1fYXBGs1jcdJhc9Cr9pb98u46bTcz1x3JNJ4+PmKQZe rdZFLRPgUNkCoxc1Qy3rBb+lax/xifCr13AvzBtl+4cPdMjBfJ4o/no10GTlSg4lvNQ8 R1XmDY+iNZMWdmvPL0ORnUY4uqnqIvT4FaGYQ= Received: by 10.223.40.136 with SMTP id k8mr684589fae.24.1270577501857; Tue, 06 Apr 2010 11:11:41 -0700 (PDT) Received: from [10.0.10.2] (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 15sm8835392fxm.11.2010.04.06.11.11.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 06 Apr 2010 11:11:40 -0700 (PDT) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <633876.59576.qm@web56507.mail.re3.yahoo.com> Date: Tue, 6 Apr 2010 19:11:39 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <633876.59576.qm@web56507.mail.re3.yahoo.com> To: Neil Short X-Mailer: Apple Mail (2.1078) Cc: freebsd-current@freebsd.org Subject: Re: atheros ar 9285 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 18:11:45 -0000 On 6 Apr 2010, at 16:18, Neil Short wrote: > did the atheros ar 9285 patch ever get committed anywhere? I can't find it. Yes, current and 8-STABLE. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Tue Apr 6 22:11:04 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 125161065672; Tue, 6 Apr 2010 22:11:04 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.rulez.sk (services.rulez.sk [92.240.234.125]) by mx1.freebsd.org (Postfix) with ESMTP id B7D7E8FC1A; Tue, 6 Apr 2010 22:11:03 +0000 (UTC) Received: from services.rulez.sk (services.rulez.sk [92.240.234.125]) by services.rulez.sk (Postfix) with ESMTP id D2C9B1334796; Wed, 7 Apr 2010 00:11:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.rulez.sk ([92.240.234.125]) by services.rulez.sk (services.rulez.sk [92.240.234.125]) (amavisd-new, port 10024) with ESMTP id Fs7GYU2EJOtv; Wed, 7 Apr 2010 00:11:00 +0200 (CEST) Received: from danger-mbp.local (adsl-dyn182.78-98-228.t-com.sk [78.98.228.182]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.rulez.sk (Postfix) with ESMTPSA id C58FD13346DC; Wed, 7 Apr 2010 00:11:00 +0200 (CEST) Message-ID: <4BBBB174.7070408@FreeBSD.org> Date: Wed, 07 Apr 2010 00:11:00 +0200 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.2pre) Gecko/20100406 Lanikai/3.1b2pre MIME-Version: 1.0 To: current@freebsd.org, hackers@freebsd.org, developers@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Fwd: HEADSUP: Call for FreeBSD Status Reports - 1Q/2010 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 22:11:04 -0000 Hello guys, I'd like to remind you that the submission deadline is getting really close and to this date we have received only _one_ entry. If you have anything to report but need a little more time, please drop us at least a short message stating this fact to monthly@. Thank you! -------- Original Message -------- Subject: HEADSUP: Call for FreeBSD Status Reports - 1Q/2010 Date: Mon, 22 Mar 2010 03:06:31 +0100 From: Daniel Gerzo Organization: The FreeBSD Project To: current@freebsd.org, stable@freebsd.org, hackers@freebsd.org, questions@freebsd.org Dear all, I would like to remind you that the next round of status reports covering the first quarter of 2010 is due on April 15th, 2010. This initiative is very welcome in our community. Therefore, I would like to ask you to submit your status reports as soon as possible, so that we can compile the report on time. There is a lot of projects which are currently being worked on, so do not hesitate and write us a few lines - a short description about what you are working on, what are your plans and goals, so we can inform our community about your great work! Check out the reports from past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome too. Note that the submissions are accepted from anyone involved with the FreeBSD community, you do not have to be a FreeBSD committer. Submissions about anything related to FreeBSD are very welcome! Please email us the filled-in XML template to be found at http://www.freebsd.org/news/status/report-sample.xml to monthly@FreeBSD.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Wed Apr 7 03:49:03 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 000FB106567A for ; Wed, 7 Apr 2010 03:49:02 +0000 (UTC) (envelope-from lhmwzy@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id B17608FC26 for ; Wed, 7 Apr 2010 03:49:02 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so112598qwi.7 for ; Tue, 06 Apr 2010 20:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=69P7Pz8EZgR1e0KCswJfaa9UxUewM0ZYuKUjnvzHZEw=; b=w+ZVCVnuH03l8H3vV6GHI7nzXoQGRny3yE/aTsXh3jwq8kyiWxEKkowFXor6YN9IAX aLCUDusTzubMbyyFMWZ2CGOvyAQLVbFECzyxpC++pmMfj3O4RCByKHZPZeKJ+xoDNlqm wv9zXCjSTOIntq48hGZi8B/RxhOh7OJzXQSRU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=H3Noq9r/POF2tPfIEoG6pj9XXWlBaGgp2LQt9Q3PBA0HcJAPLXsysUg1b5k106Q86M pBeGdIZSVo4ydgW1VDuXB5NVMyh1wbhN8w908E/iHdqnzpDlG/wNE5bCbZEd66Ll0FOG o2p+lUdfyJyP/vouQIk0stg05b2EYtke5a1Mo= MIME-Version: 1.0 Received: by 10.229.217.139 with HTTP; Tue, 6 Apr 2010 20:26:58 -0700 (PDT) Date: Wed, 7 Apr 2010 11:26:58 +0800 Received: by 10.229.212.146 with SMTP id gs18mr1787175qcb.90.1270610818903; Tue, 06 Apr 2010 20:26:58 -0700 (PDT) Message-ID: From: lhmwzy To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: When will we can use ZFS v24? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 03:49:03 -0000 I found the zfs on FreeBSD is still V13 When will we can use ZFS v24? From owner-freebsd-current@FreeBSD.ORG Wed Apr 7 03:58:28 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD872106566B for ; Wed, 7 Apr 2010 03:58:28 +0000 (UTC) (envelope-from sfourman@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 8472F8FC17 for ; Wed, 7 Apr 2010 03:58:28 +0000 (UTC) Received: by pvc7 with SMTP id 7so442179pvc.13 for ; Tue, 06 Apr 2010 20:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=jaSYcW5+1PgVboBR7Stzl5K2bbhrtpzry1fiEzoTVIM=; b=KRMLEbnOfnw2QWdPzsAWDntydxxXucGxvTeiwYleFDg50KbTE1WepulUqvnjWj4ZYV xzC611/1bZEIQ+DSy06HwDOcRQPgKT4vUO/9Kcizvbv0xeTJR+VbMRRunP5hg9Z5A+FM 9as2bSbiKpOTTUoFCo0w+FPhQkSHjlCfjYxcU= 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=M2Kzaxpf07tp0d+hl+TAvvHCU2nvdi3zoXM0iKi4oN4oN6ayCuiidT3cmTM1f0TpqY Hhc3uyfqxTQLiYKPDg9bdRU/+w0wCCslAbss8dJiFMEf6cC8nJbP7z0qqrpx1aTRMURy TGGXdPtSZAH8ohvE20xsofcE8KrMLQydoRHKs= MIME-Version: 1.0 Received: by 10.143.34.1 with HTTP; Tue, 6 Apr 2010 20:58:27 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Apr 2010 22:58:27 -0500 Received: by 10.143.20.39 with SMTP id x39mr3242060wfi.236.1270612707957; Tue, 06 Apr 2010 20:58:27 -0700 (PDT) Message-ID: From: "Sam Fourman Jr." To: lhmwzy Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: When will we can use ZFS v24? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 03:58:28 -0000 On Tue, Apr 6, 2010 at 10:26 PM, lhmwzy wrote: > I found the zfs on FreeBSD is still V13 > When will we can use ZFS v24? I believe that patches for ZFS v22 is being worked on atm. Sam Fourman Jr. Fourman Networks From owner-freebsd-current@FreeBSD.ORG Wed Apr 7 04:35:30 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF1171065673 for ; Wed, 7 Apr 2010 04:35:30 +0000 (UTC) (envelope-from lhmwzy@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 8A1058FC15 for ; Wed, 7 Apr 2010 04:35:30 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so123081qwi.7 for ; Tue, 06 Apr 2010 21:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=vgVII/RS0H5X1cWYYFlGL2dMd7XqkBEBOBdwvJ48Cp8=; b=oNQaBT1OtUt/KwkFBPAEVfpxqYmdH7A73EW8a6kFzcbsZX2QsMYZ7I8pXjbi0oxFAn WwzGsYonsv5lBuRnOKxShpMxFvLsIXUzgc8VZdp9T53aJbKvsELp9utVbfl4STf5kdLe wrBbv+3HIMNw8oq7xK5G10ISUyAHOPcUmShuM= 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=n5lI+MtO4mY4wmBpOvsVU+E26lLwtMtucOg0lzNXLZ2Km7hEUiOdBMsqutF+MMmdWD DwM8Fx48C/5RsPD9cIjUurBWjT7i+hrV2D7xc8Vr9HrxhO8CNjfNUVSP7sKPvEzVqdAo wuExnWBFoCAR6Ejhofj3bf8b8w8wujmoNg0xM= MIME-Version: 1.0 Received: by 10.229.217.139 with HTTP; Tue, 6 Apr 2010 21:35:29 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Apr 2010 12:35:29 +0800 Received: by 10.229.212.146 with SMTP id gs18mr1907209qcb.90.1270614929490; Tue, 06 Apr 2010 21:35:29 -0700 (PDT) Message-ID: From: lhmwzy To: "Sam Fourman Jr." Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: When will we can use ZFS v24? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 04:35:30 -0000 What's your mean?? 2010/4/7 Sam Fourman Jr. : > On Tue, Apr 6, 2010 at 10:26 PM, lhmwzy wrote: >> I found the zfs on FreeBSD is still V13 >> When will we can use ZFS v24? > > I believe that patches for ZFS v22 is being worked on atm. > > Sam Fourman Jr. > Fourman Networks > From owner-freebsd-current@FreeBSD.ORG Wed Apr 7 04:38:22 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3BAE106566B for ; Wed, 7 Apr 2010 04:38:22 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9D7F28FC0C for ; Wed, 7 Apr 2010 04:38:22 +0000 (UTC) Received: by gwaa12 with SMTP id a12so413540gwa.13 for ; Tue, 06 Apr 2010 21:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=5sBokmoliuBK/z77PflPG3yAXoQ3FF2i1Q6jl8aiOtM=; b=ELmqMt6zp0ulRCexP/4PoGSlm6gWGDmWVj2WkG/8CxMFvMKM/sMTouQoHxjhJ6MXdW elClxZOi155pynJ0afmWZKHuWTJ04l3lPPvu/BDSfEJ+51x1kMVHajZb8WhEVYDcB+/W u8TKmCwLPpFiOjD42jwV8F923tGerq/LiW9dA= 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 :content-type; b=EdD2MwDBzSBbEoxc4FyUCu2cf8v2Fl+It98/g7M6twcuZ8vpIwKY6EVGR1TNA6t4Be d/UP8sMkW1icKt++lt4SDdQil/6v5OPf8uwIlRBxivn+gRf1H2q+FwTS2Q3jLx5yLXgJ c5G5jC5U4edC7vFS7qVoewLONvfveD9ZoiQb0= MIME-Version: 1.0 Received: by 10.231.35.203 with HTTP; Tue, 6 Apr 2010 21:38:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Apr 2010 21:38:21 -0700 Received: by 10.231.147.199 with SMTP id m7mr3816344ibv.87.1270615101397; Tue, 06 Apr 2010 21:38:21 -0700 (PDT) Message-ID: From: Freddie Cash To: current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: When will we can use ZFS v24? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 04:38:23 -0000 On Tue, Apr 6, 2010 at 9:35 PM, lhmwzy wrote: > What's your mean?? > See the archives for the freebsd-fs mailing list. There are two separate groups working on getting ZFSv22 added to FreeBSD 9-CURRENT. And there's work ongoing to get ZFSv15 added to FreeBSD 8-STABLE. IOW, just be patient. Good things will come to those who wait. ;) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Apr 7 09:48:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7B861065673 for ; Wed, 7 Apr 2010 09:48:05 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 5DEF28FC13 for ; Wed, 7 Apr 2010 09:48:04 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so339738fga.13 for ; Wed, 07 Apr 2010 02:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:received :message-id:subject:to:content-type; bh=eMmRGw8S9rfWDQYpVikRSa5XKPJqNJqYIhmQMRIWUmo=; b=Do0xdBXyKgIOtZ2KSrGEcHUAZz/KA/8Eqp/EU/PT4BkI8rk3TNDZsvZB3chvzL287P QMNtL5JaRSn2iYQ8ozJxKawqn0rYC3IFJnMJhnIDtoU6aFIfwQuEUDbuYLi1s/82IStB ZAGhi/WHa3FTL+gPKNpTGOC0GNj0PsHsuW22Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=swxrylamm8W20hv3Yi6is795TLsIEIM/SWA/bz29Gajg9J+9qTlZQkBR7Vky/o1ZZS bPtG1m7hbIZvQ7JQnTykzYWVlcrZMNCDObbJJZ07wA4/7iSd/CW4KnJEiXeD0xkGLYGi GKRHXg3lZH5xnbPHIW57sPljuRAKakROhkg6w= MIME-Version: 1.0 Received: by 10.86.54.3 with HTTP; Wed, 7 Apr 2010 02:47:44 -0700 (PDT) From: Eir Nym Date: Wed, 7 Apr 2010 13:47:44 +0400 Received: by 10.87.48.26 with SMTP id a26mr13413863fgk.5.1270633684158; Wed, 07 Apr 2010 02:48:04 -0700 (PDT) Message-ID: To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: BIND from system and from ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 09:48:05 -0000 All is good in BIND in system, except it depends on ports tree with various options. I have to do followed algorithm, to enable these options: 1) make and install base system 2) install needed dependencies from ports tree 3) rebuild and reinstall world This is more complex than: 1) make and install base system 2) install same(?) BIND from ports tree with same options Why does base system has any dependencies from ports? I know about application features, but special cases aren't special enough to break the rules, isn't it? From owner-freebsd-current@FreeBSD.ORG Wed Apr 7 14:31:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37D7B1065676 for ; Wed, 7 Apr 2010 14:31:05 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id BB0438FC14 for ; Wed, 7 Apr 2010 14:31:04 +0000 (UTC) Received: by ewy24 with SMTP id 24so518678ewy.33 for ; Wed, 07 Apr 2010 07:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:x-mailer :subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc; bh=5Ld/7ZQ3j5NXE04YJ0Z7UNEw+DO112WXKqtQ86yOKGI=; b=UGlBmdkq0tlqizkKRBb0E+aBJrOp0Kn5Mls+42ur6kyOWF/LqbROxfKhuWtAw67qUL q6NRWAjEr1xQAQJzWLCGH8+a9qKDaHSLhv6uE23VuOsdj0/ZWiztYeEO1q9Mwenw35UD 3FhrkPFcZX8RWynsETgMcvBm1Y6D/+UMJZ0Qk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:x-mailer:subject:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc; b=ollL4ay9LUQfsxEG9zPbDxAp/n//fCh8OAqC84CkDqjOhce+b+p8GE1J0IQpIMRj4X mMKHIbyF+ZMZhebWb4BPAIuzlicivLppTh4IWAE59BZjbfqpUVPzj+5sN9NzHRljhBth kcKp9hGvaR3FCbgmKUUePYaVw4pxL5Ox1WqQE= Received: by 10.213.38.67 with SMTP id a3mr5672188ebe.92.1270650663417; Wed, 07 Apr 2010 07:31:03 -0700 (PDT) Received: from [10.0.2.9] (luxproject.ritzio.com [213.247.244.184]) by mx.google.com with ESMTPS id 16sm8085952ewy.7.2010.04.07.07.31.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 07 Apr 2010 07:31:02 -0700 (PDT) From: Arseny Nasokin To: Eir Nym In-Reply-To: X-Mailer: iPhone Mail (7E18) References: Message-Id: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7E18) Date: Wed, 7 Apr 2010 18:31:08 +0400 Cc: "freebsd-current@freebsd.org" Subject: Re: BIND from system and from ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 14:31:05 -0000 On 7 Apr 2010, at 13:47, Eir Nym wrote: > All is good in BIND in system, except it depends on ports tree with > various options. WITH_BIND_XML and WITH_BIND_IDN > I have to do followed algorithm, to enable these options: > 1) make and install base system > 2) install needed dependencies from ports tree > 3) rebuild and reinstall world > > This is more complex than: > 1) make and install base system > 2) install same(?) BIND from ports tree with same options > > Why does base system has any dependencies from ports? > I know about application features, but special cases aren't special > enough to break the rules, isn't it? From owner-freebsd-current@FreeBSD.ORG Wed Apr 7 16:28:59 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9B7C106564A for ; Wed, 7 Apr 2010 16:28:58 +0000 (UTC) (envelope-from kraduk@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 798038FC08 for ; Wed, 7 Apr 2010 16:28:58 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so1469682fgb.13 for ; Wed, 07 Apr 2010 09:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=Bju2L76+VQNZcAavOgKPFZoPCMh/ldNbTnawo9qbVSo=; b=dCrqwEUcdFwxKux4BI0CNDaXNbIM5EO7l3ilnXQogLvSXxixqyqBrKHtK87Kyg/QEP pgLiE2fZhDFsjduNGCJAwLZSEm+3/fhWdRMeNaIygBz2dCtoliZmnJ+zlm0C6Y4tVEsk fj3RMISUi1kAsPfIjaKHiYwHOFwUZDBF1o2l0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=o3/jzLskgMKnc4eEDcLxHPVA8cfCvdDgSWLqokfAIhGhi9ZxMUMMS/91jdSuhmGa2w 7PVp7NjBE+S0GSa5RQctN7FfMKRZnxmwYImcztG8nLNk5m1KDLhnfVYgHMYLe2IDDW9+ oEcDO8/weqVRsgwRNK919nRp4C6NcxWmHumo8= MIME-Version: 1.0 Received: by 10.239.157.136 with HTTP; Wed, 7 Apr 2010 09:00:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Apr 2010 17:00:06 +0100 Received: by 10.239.137.11 with SMTP id j11mr756837hbj.177.1270656006344; Wed, 07 Apr 2010 09:00:06 -0700 (PDT) Message-ID: From: krad To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: When will we can use ZFS v24? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 16:28:59 -0000 On 7 April 2010 05:38, Freddie Cash wrote: > On Tue, Apr 6, 2010 at 9:35 PM, lhmwzy wrote: > > > What's your mean?? > > > > See the archives for the freebsd-fs mailing list. There are two separate > groups working on getting ZFSv22 added to FreeBSD 9-CURRENT. And there's > work ongoing to get ZFSv15 added to FreeBSD 8-STABLE. > > IOW, just be patient. Good things will come to those who wait. ;) > > -- > Freddie Cash > fjwcash@gmail.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > If you re hankering for dedup you better have a big box as its a complete resource hog. From what we have seen on our x4500 filers we need about 100gig of ram or l2arc ssd to hold the all the metadata for the 34TB of storage, otherwise the system grinds to a halt. From owner-freebsd-current@FreeBSD.ORG Wed Apr 7 16:35:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FCEA106564A; Wed, 7 Apr 2010 16:35:57 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward15.mail.yandex.net (forward15.mail.yandex.net [95.108.130.119]) by mx1.freebsd.org (Postfix) with ESMTP id D30718FC18; Wed, 7 Apr 2010 16:35:56 +0000 (UTC) Received: from web135.yandex.ru (web135.yandex.ru [95.108.131.157]) by forward15.mail.yandex.net (Yandex) with ESMTP id E6D75445912D; Wed, 7 Apr 2010 20:35:54 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1270658154; bh=xZo9tQkyyqdIT+2vGm27MNztuBjXIPxAwqLqKFab37Y=; h=From:To:Subject:MIME-Version:Message-Id:Date: Content-Transfer-Encoding:Content-Type; b=gpGLJv68FB5+SOSta4lTCseLAKlb2POfIlGF/HELhAP2U9/KoqF9DN17DLNfrG1KM ij1rWx37wS01SJwxoY9jRk3P5+K7J2J3cl+QPNtJ4rgGNNDHcdtiU17SUf1zFXn0F3 3Ul/yFejsklEtlz51jxPko1TJrxzwbI9VmM9MoRo= Received: from localhost (localhost.localdomain [127.0.0.1]) by web135.yandex.ru (Yandex) with ESMTP id E45011218001; Wed, 7 Apr 2010 20:35:54 +0400 (MSD) X-Yandex-Spam: 1 X-Yandex-Front: web135.yandex.ru X-Yandex-TimeMark: 1270658154 Received: from proxy.heavennet.ru (proxy.heavennet.ru [77.72.136.193]) by mail.yandex.ru with HTTP; Wed, 07 Apr 2010 20:35:51 +0400 From: Andrey V. Elsukov To: freebsd-current@freebsd.org,freebsd-geom@freebsd.org MIME-Version: 1.0 Message-Id: <55861270658151@web135.yandex.ru> Date: Wed, 07 Apr 2010 20:35:51 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: Subject: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 16:35:57 -0000 Hi, All. Some days ago i begun rewriting sade(8) to libgeom(3). Just for fun :-) Today i have progress and you can see some screenshoots here: http://butcher.heavennet.ru/sade/ What is done: 1. It's fully rewritten, but yes, i reuse some code from old sade. 2. I wrote small framework "customdlg" for creating custom dialogs (not yet fully finished, but works). 3. Now sade use libgeom for searching providers and it can use: {"DISK", "disk device"}, {"MD", "memory backed virtual disk"}, {"ZFS::ZVOL", "ZFS volume"}, {"MIRROR", "GEOM based mirror (RAID1)"}, {"STRIPE", "GEOM based stripe (RAID0)"}, {"RAID3", "GEOM based RAID3 array"}, {"CONCAT", "GEOM based concatenated disk"}, {"ELI", "GEOM based encrypted disk"}, {"JOURNAL", "GEOM based journalled disk"}, {"MULTIPATH", "GEOM based disk with multiple path"} 4. Access to partitions based on geom_part.so library. I made some changes in geom_part.c and sent it to Marcel, but currently didn't receive answer. Any way if these changes is not acceptable i can rewrite it for using libgeom(3) only. 5. Undo/Commit features are based on internal implementation of geom class PART. I found there two bugs: http://lists.freebsd.org/pipermail/freebsd-geom/2010-April/004018.html http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039390.html 6. All "device" related code can be placed in shared library and in future can be reused in another frontend... 7. New Partition Editor: * partitions list now scrollable; * all operations based on geom_part.so and similar to gpart(8); * opening partition editor on empty provider opens new "Selech Partitioning Scheme" dialog and create selected scheme; * new add slice dialog; * deleting slice from empty table destroys scheme; Todo: 1. Refine customdlg. 2. Waiting for fixes in geom_part_mbr, geom_part and geom_part.so. 3. "Set Type and Label" dialog. 4. Better wording needed for messages and help. My english is bad :( ------ Missing functions: Creating filesystem and save them into /etc/fstab. What new can be added: 1. Creating ZFS pools and datasets. 2. Creating GEOM-based raids. Any comments are welcome. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Wed Apr 7 17:33:37 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64086106566C for ; Wed, 7 Apr 2010 17:33:37 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id 2701E8FC24 for ; Wed, 7 Apr 2010 17:33:36 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id o37HXY8C009723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Apr 2010 12:33:34 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.3) with ESMTP id o37HXYmM018358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Apr 2010 12:33:34 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o37HXYKO018357; Wed, 7 Apr 2010 12:33:34 -0500 (CDT) (envelope-from dan) Date: Wed, 7 Apr 2010 12:33:34 -0500 From: Dan Nelson To: krad Message-ID: <20100407173334.GC76941@dan.emsphone.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 8.0-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.95.3 at email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Wed, 07 Apr 2010 12:33:34 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: Freddie Cash , current@freebsd.org Subject: Re: When will we can use ZFS v24? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 17:33:37 -0000 In the last episode (Apr 07), krad said: > On 7 April 2010 05:38, Freddie Cash wrote: > > On Tue, Apr 6, 2010 at 9:35 PM, lhmwzy wrote: > > > What's your mean?? > > > > See the archives for the freebsd-fs mailing list. There are two > > separate groups working on getting ZFSv22 added to FreeBSD 9-CURRENT. > > And there's work ongoing to get ZFSv15 added to FreeBSD 8-STABLE. > > > > IOW, just be patient. Good things will come to those who wait. ;) > > If you re hankering for dedup you better have a big box as its a complete > resource hog. From what we have seen on our x4500 filers we need about > 100gig of ram or l2arc ssd to hold the all the metadata for the 34TB of > storage, otherwise the system grinds to a halt. I wish they had an option for "opportunistic" dedup, where if a block is already in ARC it can be a dedupe candidate, but it won't look it up in the DDT if it isn't already in memory. That catches the simple "cp -R dir1 dir2" cases without blowing up the ARC on DDT blocks that 99.9999% of the time don't match. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Wed Apr 7 17:49:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5360F1065672 for ; Wed, 7 Apr 2010 17:49:36 +0000 (UTC) (envelope-from sektie@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1E0588FC1F for ; Wed, 7 Apr 2010 17:49:35 +0000 (UTC) Received: by pwi9 with SMTP id 9so1315714pwi.13 for ; Wed, 07 Apr 2010 10:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=SiqwQwC7dk1x9mEyrWc2Q+GdQqLveVaQBtCl3xbsRXg=; b=rNQqBX+Yv7ZCYbUgHnqWb4JN41d5MRXmveANcCl/xDZOCr+HYPjvXFpSLwJArN2p0t STMm9sWWeTETaIirf4f5yQnPcbN0XzF096XlucYqEQFBOhxEV80RfQuqo9pcC1bNvCKi nRfjKpzNchR396VAANyTKcHWEKdNGOcxQ4zMs= 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=OE0dfe51QLDxNhPSLEMVPvJcZMJVeBYEvdviqhhZIUgXG6fPBWik8xye7GdmUia5qe cyPC4k6rWLSIjVV25/xZuLuDh4J2YpWZet+mNLi9FzRjs5nJ6AprOuFkL6Ixj99OsWOD KLsUWuqpEsymaK2wHirqqxjN8l0zTV+S7AVP0= MIME-Version: 1.0 Sender: sektie@gmail.com Received: by 10.140.172.16 with HTTP; Wed, 7 Apr 2010 10:49:35 -0700 (PDT) In-Reply-To: <55861270658151@web135.yandex.ru> References: <55861270658151@web135.yandex.ru> Date: Wed, 7 Apr 2010 10:49:35 -0700 X-Google-Sender-Auth: e08edf60433e04b1 Received: by 10.141.91.16 with SMTP id t16mr3729411rvl.128.1270662575470; Wed, 07 Apr 2010 10:49:35 -0700 (PDT) Message-ID: From: Randi Harper To: "Andrey V. Elsukov" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Devin Teske , freebsd-geom@freebsd.org Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 17:49:36 -0000 On Wed, Apr 7, 2010 at 9:35 AM, Andrey V. Elsukov wrote= : > Hi, All. > > Some days ago i begun rewriting sade(8) to libgeom(3). Just for fun :-) > Today i have progress and you can see some screenshoots here: > http://butcher.heavennet.ru/sade/ > > What is done: > 1. It's fully rewritten, but yes, i reuse some code from old sade. > 2. I wrote small framework "customdlg" for creating custom dialogs (not y= et fully finished, but works). > 3. Now sade use libgeom for searching providers and it can use: > =A0 =A0 =A0 =A0{"DISK", =A0 =A0 =A0 =A0"disk device"}, > =A0 =A0 =A0 =A0{"MD", =A0 =A0 =A0 =A0 =A0"memory backed virtual disk"}, > =A0 =A0 =A0 =A0{"ZFS::ZVOL", =A0 "ZFS volume"}, > =A0 =A0 =A0 =A0{"MIRROR", =A0 =A0 =A0"GEOM based mirror (RAID1)"}, > =A0 =A0 =A0 =A0{"STRIPE", =A0 =A0 =A0"GEOM based stripe (RAID0)"}, > =A0 =A0 =A0 =A0{"RAID3", =A0 =A0 =A0 "GEOM based RAID3 array"}, > =A0 =A0 =A0 =A0{"CONCAT", =A0 =A0 =A0"GEOM based concatenated disk"}, > =A0 =A0 =A0 =A0{"ELI", =A0 =A0 =A0 =A0 "GEOM based encrypted disk"}, > =A0 =A0 =A0 =A0{"JOURNAL", =A0 =A0 "GEOM based journalled disk"}, > =A0 =A0 =A0 =A0{"MULTIPATH", =A0 "GEOM based disk with multiple path"} > 4. Access to partitions based on geom_part.so library. I made some change= s in geom_part.c and > sent it to Marcel, but currently didn't receive answer. Any way if these = changes is not acceptable > i can rewrite it for using libgeom(3) only. > 5. Undo/Commit features are based on internal implementation of geom clas= s PART. I found there > two bugs: > http://lists.freebsd.org/pipermail/freebsd-geom/2010-April/004018.html > http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039390.html > 6. All "device" related code can be placed in shared library and in futur= e can be reused in another > frontend... > 7. New Partition Editor: > * partitions list now scrollable; > * all operations based on geom_part.so and similar to gpart(8); > * opening partition editor on empty provider opens new "Selech Partitioni= ng Scheme" dialog > and create selected scheme; > * new add slice dialog; > * deleting slice from empty table destroys scheme; > > Todo: > 1. Refine customdlg. > 2. Waiting for fixes in geom_part_mbr, geom_part and geom_part.so. > 3. "Set Type and Label" dialog. > 4. Better wording needed for messages and help. My english is bad :( > ------ > Missing functions: > Creating filesystem and save them into /etc/fstab. > > What new can be added: > 1. Creating ZFS pools and datasets. > 2. Creating GEOM-based raids. > > Any comments are welcome. > -- > WBR, Andrey V. Elsukov > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > Wow. This is awesome. patches? :D I've been working on moving sysinstall from libdisk to libgeom, but unfortunately it's a bit more complicated (redoing the way we detect devices while I'm at it). I've done a lot of the heavy lifting code, but I haven't even started on the GUI parts yet. I'd love to see how someone else tackled doing this. I'm particularly interested in #5 & #7. :) Generally, we try to keep sysinstall's disk tools and sade in sync, so I would like to work with you on this and see what we can come up with. I'm not entirely sure if #2 is a viable option since we already have functions in sysinstall that handle generating dialog boxes with libdialog, but if it's an improvement on what's existing, bring it on. CC:ing Devin Teske on this thread, as he's displayed interest in helping as well. My goal is to get all this in for 8.2, so there's quite a bit to work out in a short period of time. -- randi From owner-freebsd-current@FreeBSD.ORG Wed Apr 7 18:42:44 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DAEB1065678 for ; Wed, 7 Apr 2010 18:42:44 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from hosting.nash.net.ua (hosting.nash.net.ua [193.151.252.10]) by mx1.freebsd.org (Postfix) with SMTP id 5B9C08FC26 for ; Wed, 7 Apr 2010 18:42:42 +0000 (UTC) Received: (qmail 17201 invoked by uid 509); 7 Apr 2010 18:14:38 -0000 Received: from ravenloft.kiev.ua (94.244.131.95) by hosting.nash.net.ua with SMTP; 7 Apr 2010 18:14:38 -0000 Date: Wed, 7 Apr 2010 21:13:36 +0300 From: Alex Kozlov To: Randi Harper , "Andrey V. Elsukov" , freebsd-current@freebsd.org, Devin Teske , freebsd-geom@freebsd.org Message-ID: <20100407181336.GA81809@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Cc: Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 18:42:44 -0000 On Wed, Apr 07, 2010 at 10:49:35AM -0700, Randi Harper wrote: > On Wed, Apr 7, 2010 at 9:35 AM, Andrey V. Elsukov wrote: > > Hi, All. > > > > Some days ago i begun rewriting sade(8) to libgeom(3). Just for fun :-) > > Today i have progress and you can see some screenshoots here: > > http://butcher.heavennet.ru/sade/ > > > > What is done: > > 1. It's fully rewritten, but yes, i reuse some code from old sade. > > 2. I wrote small framework "customdlg" for creating custom dialogs (not yet fully finished, but works). > > 3. Now sade use libgeom for searching providers and it can use: > >        {"DISK",        "disk device"}, > >        {"MD",          "memory backed virtual disk"}, > >        {"ZFS::ZVOL",   "ZFS volume"}, > >        {"MIRROR",      "GEOM based mirror (RAID1)"}, > >        {"STRIPE",      "GEOM based stripe (RAID0)"}, > >        {"RAID3",       "GEOM based RAID3 array"}, > >        {"CONCAT",      "GEOM based concatenated disk"}, > >        {"ELI",         "GEOM based encrypted disk"}, > >        {"JOURNAL",     "GEOM based journalled disk"}, > >        {"MULTIPATH",   "GEOM based disk with multiple path"} > > 4. Access to partitions based on geom_part.so library. I made some changes in geom_part.c and > > sent it to Marcel, but currently didn't receive answer. Any way if these changes is not acceptable > > i can rewrite it for using libgeom(3) only. > > 5. Undo/Commit features are based on internal implementation of geom class PART. I found there > > two bugs: > > http://lists.freebsd.org/pipermail/freebsd-geom/2010-April/004018.html > > http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039390.html > > 6. All "device" related code can be placed in shared library and in future can be reused in another > > frontend... > > 7. New Partition Editor: > > * partitions list now scrollable; > > * all operations based on geom_part.so and similar to gpart(8); > > * opening partition editor on empty provider opens new "Selech Partitioning Scheme" dialog > > and create selected scheme; > > * new add slice dialog; > > * deleting slice from empty table destroys scheme; > > > > Todo: > > 1. Refine customdlg. > > 2. Waiting for fixes in geom_part_mbr, geom_part and geom_part.so. > > 3. "Set Type and Label" dialog. > > 4. Better wording needed for messages and help. My english is bad :( > > ------ > > Missing functions: > > Creating filesystem and save them into /etc/fstab. > > > > What new can be added: > > 1. Creating ZFS pools and datasets. > > 2. Creating GEOM-based raids. > > > > Any comments are welcome. > > -- > > WBR, Andrey V. Elsukov > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > Wow. This is awesome. patches? :D > > I've been working on moving sysinstall from libdisk to libgeom, but > unfortunately it's a bit more complicated (redoing the way we detect > devices while I'm at it). I've done a lot of the heavy lifting code, > but I haven't even started on the GUI parts yet. I'd love to see how > someone else tackled doing this. I'm particularly interested in #5 & > #7. :) > > Generally, we try to keep sysinstall's disk tools and sade in sync, so > I would like to work with you on this and see what we can come up > with. I'm not entirely sure if #2 is a viable option since we already > have functions in sysinstall that handle generating dialog boxes with > libdialog, but if it's an improvement on what's existing, bring it on. I have half-finished code that uses /sbin/gpart instead of libdisk or libgeom. Half-finished, because it initialy used /sbin/{fidsk,bsdlabel,gpt} So now I plan to finish the conversion to gpart and add work with gpt to mbr and bsdlable handling. > CC:ing Devin Teske on this thread, as he's displayed interest in > helping as well. My goal is to get all this in for 8.2, so there's > quite a bit to work out in a short period of time. > > -- randi -- Adios From owner-freebsd-current@FreeBSD.ORG Wed Apr 7 19:20:06 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BC9B106566B; Wed, 7 Apr 2010 19:20:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 04C138FC12; Wed, 7 Apr 2010 19:20:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o37JK5nt080087; Wed, 7 Apr 2010 15:20:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o37JK5oq080085; Wed, 7 Apr 2010 19:20:05 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 7 Apr 2010 19:20:05 GMT Message-Id: <201004071920.o37JK5oq080085@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 19:20:06 -0000 TB --- 2010-04-07 18:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-07 18:15:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-04-07 18:15:00 - cleaning the object tree TB --- 2010-04-07 18:15:26 - cvsupping the source tree TB --- 2010-04-07 18:15:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-04-07 18:15:48 - building world TB --- 2010-04-07 18:15:48 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-07 18:15:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-07 18:15:48 - TARGET=pc98 TB --- 2010-04-07 18:15:48 - TARGET_ARCH=i386 TB --- 2010-04-07 18:15:48 - TZ=UTC TB --- 2010-04-07 18:15:48 - __MAKE_CONF=/dev/null TB --- 2010-04-07 18:15:48 - cd /src TB --- 2010-04-07 18:15:48 - /usr/bin/make -B buildworld >>> World build started on Wed Apr 7 18:15:49 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Apr 7 19:15:26 UTC 2010 TB --- 2010-04-07 19:15:26 - generating LINT kernel config TB --- 2010-04-07 19:15:26 - cd /src/sys/pc98/conf TB --- 2010-04-07 19:15:26 - /usr/bin/make -B LINT TB --- 2010-04-07 19:15:26 - building LINT kernel TB --- 2010-04-07 19:15:26 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-07 19:15:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-07 19:15:26 - TARGET=pc98 TB --- 2010-04-07 19:15:26 - TARGET_ARCH=i386 TB --- 2010-04-07 19:15:26 - TZ=UTC TB --- 2010-04-07 19:15:26 - __MAKE_CONF=/dev/null TB --- 2010-04-07 19:15:26 - cd /src TB --- 2010-04-07 19:15:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Apr 7 19:15:27 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/bwi/bwimac.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/bwi/bwiphy.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/bwi/bwirf.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/bwi/if_bwi.c cc1: warnings being treated as errors In file included from /src/sys/dev/bwi/if_bwi.c:68: /src/sys/net80211/ieee80211_ratectl.h: In function 'ieee80211_ratectl_rate': /src/sys/net80211/ieee80211_ratectl.h:97: warning: 'return' with no value, in function returning non-void *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-04-07 19:20:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-04-07 19:20:05 - ERROR: failed to build lint kernel TB --- 2010-04-07 19:20:05 - 2849.96 user 654.72 system 3904.70 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Apr 7 19:21:16 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17CAA106568C; Wed, 7 Apr 2010 19:21:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id CBE708FC0C; Wed, 7 Apr 2010 19:21:15 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o37JLFqv090891; Wed, 7 Apr 2010 15:21:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o37JLFMU090868; Wed, 7 Apr 2010 19:21:15 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 7 Apr 2010 19:21:15 GMT Message-Id: <201004071921.o37JLFMU090868@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 19:21:16 -0000 TB --- 2010-04-07 18:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-07 18:15:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-04-07 18:15:00 - cleaning the object tree TB --- 2010-04-07 18:15:30 - cvsupping the source tree TB --- 2010-04-07 18:15:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-04-07 18:15:51 - building world TB --- 2010-04-07 18:15:51 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-07 18:15:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-07 18:15:51 - TARGET=i386 TB --- 2010-04-07 18:15:51 - TARGET_ARCH=i386 TB --- 2010-04-07 18:15:51 - TZ=UTC TB --- 2010-04-07 18:15:51 - __MAKE_CONF=/dev/null TB --- 2010-04-07 18:15:51 - cd /src TB --- 2010-04-07 18:15:51 - /usr/bin/make -B buildworld >>> World build started on Wed Apr 7 18:15:51 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Apr 7 19:15:32 UTC 2010 TB --- 2010-04-07 19:15:32 - generating LINT kernel config TB --- 2010-04-07 19:15:32 - cd /src/sys/i386/conf TB --- 2010-04-07 19:15:32 - /usr/bin/make -B LINT TB --- 2010-04-07 19:15:32 - building LINT kernel TB --- 2010-04-07 19:15:32 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-07 19:15:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-07 19:15:32 - TARGET=i386 TB --- 2010-04-07 19:15:32 - TARGET_ARCH=i386 TB --- 2010-04-07 19:15:32 - TZ=UTC TB --- 2010-04-07 19:15:32 - __MAKE_CONF=/dev/null TB --- 2010-04-07 19:15:32 - cd /src TB --- 2010-04-07 19:15:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Apr 7 19:15:32 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/bwi/bwimac.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/bwi/bwiphy.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/bwi/bwirf.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/bwi/if_bwi.c cc1: warnings being treated as errors In file included from /src/sys/dev/bwi/if_bwi.c:68: /src/sys/net80211/ieee80211_ratectl.h: In function 'ieee80211_ratectl_rate': /src/sys/net80211/ieee80211_ratectl.h:97: warning: 'return' with no value, in function returning non-void *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-04-07 19:21:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-04-07 19:21:15 - ERROR: failed to build lint kernel TB --- 2010-04-07 19:21:15 - 2931.23 user 637.38 system 3974.83 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Apr 7 19:47:55 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EAA3106564A; Wed, 7 Apr 2010 19:47:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1EC4E8FC1E; Wed, 7 Apr 2010 19:47:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o37JlsuN064094; Wed, 7 Apr 2010 15:47:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o37JlsJE064088; Wed, 7 Apr 2010 19:47:54 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 7 Apr 2010 19:47:54 GMT Message-Id: <201004071947.o37JlsJE064088@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 19:47:55 -0000 TB --- 2010-04-07 18:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-07 18:15:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-04-07 18:15:00 - cleaning the object tree TB --- 2010-04-07 18:15:33 - cvsupping the source tree TB --- 2010-04-07 18:15:33 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-04-07 18:15:53 - building world TB --- 2010-04-07 18:15:53 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-07 18:15:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-07 18:15:53 - TARGET=amd64 TB --- 2010-04-07 18:15:53 - TARGET_ARCH=amd64 TB --- 2010-04-07 18:15:53 - TZ=UTC TB --- 2010-04-07 18:15:53 - __MAKE_CONF=/dev/null TB --- 2010-04-07 18:15:53 - cd /src TB --- 2010-04-07 18:15:53 - /usr/bin/make -B buildworld >>> World build started on Wed Apr 7 18:15:54 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Apr 7 19:42:31 UTC 2010 TB --- 2010-04-07 19:42:31 - generating LINT kernel config TB --- 2010-04-07 19:42:31 - cd /src/sys/amd64/conf TB --- 2010-04-07 19:42:31 - /usr/bin/make -B LINT TB --- 2010-04-07 19:42:31 - building LINT kernel TB --- 2010-04-07 19:42:31 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-07 19:42:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-07 19:42:31 - TARGET=amd64 TB --- 2010-04-07 19:42:31 - TARGET_ARCH=amd64 TB --- 2010-04-07 19:42:31 - TZ=UTC TB --- 2010-04-07 19:42:31 - __MAKE_CONF=/dev/null TB --- 2010-04-07 19:42:31 - cd /src TB --- 2010-04-07 19:42:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Apr 7 19:42:31 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/bwi/bwimac.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/bwi/bwiphy.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/bwi/bwirf.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/bwi/if_bwi.c cc1: warnings being treated as errors In file included from /src/sys/dev/bwi/if_bwi.c:68: /src/sys/net80211/ieee80211_ratectl.h: In function 'ieee80211_ratectl_rate': /src/sys/net80211/ieee80211_ratectl.h:97: warning: 'return' with no value, in function returning non-void *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-04-07 19:47:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-04-07 19:47:54 - ERROR: failed to build lint kernel TB --- 2010-04-07 19:47:54 - 4092.70 user 914.16 system 5573.82 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Apr 7 20:52:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 537B8106566C; Wed, 7 Apr 2010 20:52:38 +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 22F918FC15; Wed, 7 Apr 2010 20:52:38 +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 CBA5146B3B; Wed, 7 Apr 2010 16:52:37 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id CA7328A025; Wed, 7 Apr 2010 16:52:35 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 7 Apr 2010 15:49:41 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <20100312171758.GB31089@dragon.NUXI.org> <4BBB5225.5020008@freebsd.org> In-Reply-To: <4BBB5225.5020008@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004071549.41672.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 07 Apr 2010 16:52:35 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.8 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: pluknet , Nathan Whitehorn Subject: Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 20:52:38 -0000 On Tuesday 06 April 2010 11:24:21 am Nathan Whitehorn wrote: > pluknet wrote: > > Hi, > > > > the interesting part for me is how to properly assert now a value of e.g. > > KINFO_PROC_SIZE varying on err.. different COMPAT_FREEBSD32 arches > > (say, FreeBSD would have _kern_proc FreeBSD32 compat layer for top/ps/). > > > > > Probably the cleanest thing would be to set KINFO_PROC_SIZE in > machine/proc.h instead of where it is now, and then also define a > KINFO_PROC32_SIZE or something in the same place. Also, that would be a > really nice feature. Yes, I think this sounds like the best approach. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 05:25:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB383106566C; Thu, 8 Apr 2010 05:25:57 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward1.mail.yandex.net (forward1.mail.yandex.net [77.88.46.6]) by mx1.freebsd.org (Postfix) with ESMTP id 8E8B28FC13; Thu, 8 Apr 2010 05:25:51 +0000 (UTC) Received: from smtp1.mail.yandex.net (smtp1.mail.yandex.net [77.88.46.101]) by forward1.mail.yandex.net (Yandex) with ESMTP id EEEF669E8534; Thu, 8 Apr 2010 09:25:48 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1270704349; bh=bIgARXcxUflqXCjsoDKr1paOedy78pLRALGAVyeq6OY=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=wY3J211WF1aO5ovKYEpecczRCT/5eRywhx2NOM2ypntN8pHZ1lIfFKW5J2ju4egfW rWjItlBOBd2n6qXLmRGbbhcsbMO77fgL6zzBTHl0gJe2fVu5e+yinTyLUcbXsfYiQX RN/uq9piI8wt4hbASyxuJFGi9GM6xD+cGvlWK4gM= Received: from [127.0.0.1] (mail.kirov.so-cdu.ru [77.72.136.145]) by smtp1.mail.yandex.net (Yandex) with ESMTPSA id 81705E60148; Thu, 8 Apr 2010 09:25:48 +0400 (MSD) Message-ID: <4BBD68DB.7050600@yandex.ru> Date: Thu, 08 Apr 2010 09:25:47 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Randi Harper References: <55861270658151@web135.yandex.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1270704348 X-Yandex-Spam: 1 X-Yandex-Front: smtp1.mail.yandex.net Cc: freebsd-current@freebsd.org, Devin Teske , freebsd-geom@freebsd.org Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 05:25:57 -0000 On 07.04.2010 21:49, Randi Harper wrote: > Wow. This is awesome. patches? :D :) I'm not ready yet to publish code. I planned to announce this RFC a bit later, when code will be finished. But Konstantin (kib@) suggested do it before finishing. > I've been working on moving sysinstall from libdisk to libgeom, but > unfortunately it's a bit more complicated (redoing the way we detect > devices while I'm at it). I've done a lot of the heavy lifting code, > but I haven't even started on the GUI parts yet. I'd love to see how > someone else tackled doing this. I'm particularly interested in #5& > #7. :) Initially i wanted to only modify current sade's code to move it from libdisk to libgeom. But after several attempts i decided that it will be easier to rewrite it :) > Generally, we try to keep sysinstall's disk tools and sade in sync, so > I would like to work with you on this and see what we can come up > with. I'm not entirely sure if #2 is a viable option since we already > have functions in sysinstall that handle generating dialog boxes with > libdialog, but if it's an improvement on what's existing, bring it on. Yes, I looked at this code in sysinstall and in libdialog. Also I looked to another console UI libs. The main problem of using external libraries is that not so easy import them into base system. libdialog have several problemls too, imho. 1. Custom dialogs based on ComposeObj are ugly :) 2. It supports *only* single-byte characters. Initially I wanted to write code with message catalogs support. But after several tests I leaved this idea. Also it seems there is no catgets analog for wide characters. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 06:27:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33BDF1065670; Thu, 8 Apr 2010 06:27:40 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2001:470:1f09:679::1]) by mx1.freebsd.org (Postfix) with ESMTP id EB9EB8FC0A; Thu, 8 Apr 2010 06:27:39 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 291A0978F; Thu, 8 Apr 2010 06:27:38 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 Received: from core.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Thu, 8 Apr 2010 06:27:38 +0000 (UTC) From: Bruce Cran To: freebsd-current@freebsd.org Date: Thu, 8 Apr 2010 07:27:20 +0100 User-Agent: KMail/1.13.2 (FreeBSD/9.0-CURRENT; KDE/4.4.2; amd64; ; ) References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> In-Reply-To: <4BBD68DB.7050600@yandex.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201004080727.21020.bruce@cran.org.uk> Cc: "Andrey V. Elsukov" , Devin Teske , Randi Harper , freebsd-geom@freebsd.org Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 06:27:40 -0000 On Thursday 08 April 2010 06:25:47 Andrey V. Elsukov wrote: > I'm not ready yet to publish code. I planned to announce this RFC > a bit later, when code will be finished. But Konstantin (kib@) suggested > do it before finishing. That's a shame. As long as the source isn't available it's of little interest to me. For anyone who wants to see the bits of code I've got so far, I've created a Google Code project at http://code.google.com/p/gcpart/ . I'm currently trying to figure out how to get the partitioning scheme out of the XML tree, which is why there's no geom code there yet. As soon as I do so, I'll start checking in my effort at the new partitioning application. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 06:51:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A35F5106564A; Thu, 8 Apr 2010 06:51:11 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward3.mail.yandex.net (forward3.mail.yandex.net [77.88.46.8]) by mx1.freebsd.org (Postfix) with ESMTP id 4E70F8FC08; Thu, 8 Apr 2010 06:51:11 +0000 (UTC) Received: from smtp1.mail.yandex.net (smtp1.mail.yandex.net [77.88.46.101]) by forward3.mail.yandex.net (Yandex) with ESMTP id A8CD656D8D8F; Thu, 8 Apr 2010 10:51:09 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1270709469; bh=BcfpUZTX50q6Q6KyGhyKSWB+gMx/S8ixkKfZSGS8Aeo=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Utb/8W0y/d+34sEKAb0Rsb9Ss9Uy0og50eSUCstwEsEvKM2pFPK9fpaozmYNtZlAk JIoW+w++QtBjgIe3m/NQOjhy8cfoZI0pRUdasn+A5k2gR62ncAuoK0Q8cas21n9dNF nsYRwn7zBz3Ax2wDCeIR6pRavh8uzeAtgIt8JXWs= Received: from [127.0.0.1] (ns.kirov.so-ups.ru [77.72.136.145]) by smtp1.mail.yandex.net (Yandex) with ESMTPSA id 41744E60136; Thu, 8 Apr 2010 10:51:09 +0400 (MSD) Message-ID: <4BBD7CDC.2070505@yandex.ru> Date: Thu, 08 Apr 2010 10:51:08 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Bruce Cran References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> <201004080727.21020.bruce@cran.org.uk> In-Reply-To: <201004080727.21020.bruce@cran.org.uk> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1270709469 X-Yandex-Spam: 1 X-Yandex-Front: smtp1.mail.yandex.net Cc: freebsd-current@freebsd.org, Devin Teske , Randi Harper , freebsd-geom@freebsd.org Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 06:51:11 -0000 On 08.04.2010 10:27, Bruce Cran wrote: > That's a shame. As long as the source isn't available it's of little interest > to me. > > For anyone who wants to see the bits of code I've got so far, I've created a > Google Code project at http://code.google.com/p/gcpart/ . I'm currently trying > to figure out how to get the partitioning scheme out of the XML tree, which is > why there's no geom code there yet. As soon as I do so, I'll start checking > in my effort at the new partitioning application. I just thinking about future of my project. It seems there are several people who worked on the same before. And I have not finished yet only few things from initially planned. After that i can remove any unused code, write some comments and publish it somewhere in perforce. Also at this time code depends on changes which i made in geom_part.so and which are not yet commited into base system. After code review there can be several ways to go. And I have an interest which way will be for me :) -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 07:27:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFFEF106566B; Thu, 8 Apr 2010 07:27:31 +0000 (UTC) (envelope-from sektie@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 826428FC13; Thu, 8 Apr 2010 07:27:31 +0000 (UTC) Received: by pwi9 with SMTP id 9so1853066pwi.13 for ; Thu, 08 Apr 2010 00:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type; bh=Shgc3RUcm6FF1CzGfE4QxVEscoHdY+1QLOFvcXgrg+I=; b=j37r4xf+TWAqxxp0aqFNK0WGzGesqsoun2Kdior5XQs/1A7REPkpBZPbRUjI/qCjqr KLJGYd1AlKtrG3E8DbW1UOPFAAW2Zn9q8Dvnmv6ZmklLLMRENaY8aPqglYNoQ/RmwK7z +bzUQ6vU23UIpfMW0mupQVZyG3wVnNEYkVzBA= 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=bXIQEXt35mEoZyu9hMDkPUMfNiAeSXQVRGw1ctaDDf4fWixjWCrgdU8WZlsWQ/Vjhg PJ2Q5S+RX2p1UKQIIlBvnNsDxc3APiVvj1NqNxqH8asp9sBSB4MSy1EitEX+PIM6vDMV WnXbe+s58rSfyvCCsb4bsaWjMVkhAF8qA26xE= MIME-Version: 1.0 Sender: sektie@gmail.com Received: by 10.140.255.21 with HTTP; Thu, 8 Apr 2010 00:27:31 -0700 (PDT) In-Reply-To: <4BBD68DB.7050600@yandex.ru> References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> Date: Thu, 8 Apr 2010 00:27:31 -0700 X-Google-Sender-Auth: 27edbe57c791ca11 Received: by 10.140.255.8 with SMTP id c8mr1644091rvi.7.1270711651128; Thu, 08 Apr 2010 00:27:31 -0700 (PDT) Message-ID: From: Randi Harper To: "Andrey V. Elsukov" Content-Type: text/plain; charset=ISO-8859-1 Cc: adrian@freebsd.org, freebsd-current@freebsd.org, Devin Teske , freebsd-geom@freebsd.org Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 07:27:31 -0000 2010/4/7 Andrey V. Elsukov : > On 07.04.2010 21:49, Randi Harper wrote: >> >> Wow. This is awesome. patches? :D > > :) > I'm not ready yet to publish code. I planned to announce this RFC > a bit later, when code will be finished. But Konstantin (kib@) suggested > do it before finishing. > >> I've been working on moving sysinstall from libdisk to libgeom, but >> unfortunately it's a bit more complicated (redoing the way we detect >> devices while I'm at it). I've done a lot of the heavy lifting code, >> but I haven't even started on the GUI parts yet. I'd love to see how >> someone else tackled doing this. I'm particularly interested in #5& >> #7. :) > > Initially i wanted to only modify current sade's code to move it from > libdisk to libgeom. But after several attempts i decided that it will be > easier to rewrite it :) > >> Generally, we try to keep sysinstall's disk tools and sade in sync, so >> I would like to work with you on this and see what we can come up >> with. I'm not entirely sure if #2 is a viable option since we already >> have functions in sysinstall that handle generating dialog boxes with >> libdialog, but if it's an improvement on what's existing, bring it on. > > Yes, I looked at this code in sysinstall and in libdialog. Also I looked > to another console UI libs. The main problem of using external libraries > is that not so easy import them into base system. > > libdialog have several problemls too, imho. > 1. Custom dialogs based on ComposeObj are ugly :) > 2. It supports *only* single-byte characters. Initially I wanted to > write code with message catalogs support. But after several tests > I leaved this idea. Also it seems there is no catgets analog for > wide characters. > > -- > WBR, Andrey V. Elsukov It's great that you want to work on this, but there are other people working in the same area, so keeping your code to yourself for too long makes it very likely that it will never get used. -- randi From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 07:27:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D7851065675 for ; Thu, 8 Apr 2010 07:27:54 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from web51802.mail.re2.yahoo.com (web51802.mail.re2.yahoo.com [206.190.38.233]) by mx1.freebsd.org (Postfix) with SMTP id 4F2DC8FC1F for ; Thu, 8 Apr 2010 07:27:54 +0000 (UTC) Received: (qmail 96083 invoked by uid 60001); 8 Apr 2010 07:27:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1270711673; bh=iTOX9mJm3xo3+43k3PDPW0hWI/jSlqPucn6IO6xdliY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=htORsmK4IBrzvf80NDa/wYT1oiEk0UqtYx18ID2dTxCn+ENpWv4Yhtp/UHRC4VHvsZDQnj3N1Ac4YrhLJyiaV5mBOUUZ/OlEgYerK4NlHNJ13I/C3ylzIWTzm9GDHenry9E+og4xmU6Jr7EThM6Qlxi0XdQkwwmQ74VuH0gIpJA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=yoMlqYlYE8gEX55c5ewLID1VlvwIp1FvRGfr4pfw+obMZ8p0DzRnBfjXhFPdUxo6oCuXiYrL1pWV0HiMMHvLmQzPjO1afXQmIDH1onUSMatodAiyOP5ZlfX7dfmyj8JqU44e1hted5LJX4kYQQJ3zWSZX9GFg5BVJ9A5VrigIxU=; Message-ID: <665283.95271.qm@web51802.mail.re2.yahoo.com> X-YMail-OSG: dOp7JBIVM1mPMUqx9bCQDVwss_1PVut_Ntk6YS0_x6jIIhP XoxU1EQ4PHz8IqLEY4h2Ge_uEt2ehoss9XDiqsVCEbLDC.YeRsB0HNFaDNE4 d91TUXTKaWvpkt0pBC.g2c58Juve0tm1PJCnU7ZLQu82PS9uWqNwfvlJ77Nt J1lPpYdRP0SHaP6j0SzfqoOO4Awh._hSpjNY4LSQYZJe3c3FmXLzJPs8G5yz Oa6kMaYWw_7zMUikj1QdhOH0OHyrGkCdiMMsszmowE3Kb1KTHm_958wDfBlL d_Ik_1kw.gD4_pG3dygHNN3.7TkUoTr0X9vwMBidAzMBxSPogTAaIJRbE_g1 tR5hIwtXmDuXypkzJJpL3HxRPzCE9RdYoG._aj5UFioJa0rNhjA-- Received: from [173.183.132.20] by web51802.mail.re2.yahoo.com via HTTP; Thu, 08 Apr 2010 00:27:53 PDT X-Mailer: YahooMailRC/324.3 YahooMailWebService/0.8.100.260964 References: <16641.96608.qm@web51806.mail.re2.yahoo.com> <4B9FA3E0.4050702@micom.mng.net> <633929.41041.qm@web51802.mail.re2.yahoo.com> <4BA22B8D.9030700@micom.mng.net> <375331.74876.qm@web51804.mail.re2.yahoo.com> <4BA38B26.6050208@micom.mng.net> <989377.89740.qm@web51802.mail.re2.yahoo.com> <4BAE01AC.7000509@gmail.com> <623907.37074.qm@web51803.mail.re2.yahoo.com> <4BB3575D.4040506@gmail.com> <87836.79143.qm@web51804.mail.re2.yahoo.com> <4BBB372C.1060302@gmail.com> Date: Thu, 8 Apr 2010 00:27:53 -0700 (PDT) From: PseudoCylon To: Ganbold In-Reply-To: <4BBB372C.1060302@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 07:27:54 -0000 Hi, Sorry for taking long to fix. Here is another patch. **But before trying it out, please check rev. of your system.** If you are using r206358 (15:29 UTC Apr. 7) or newer, the driver won't work. If you are using older system, please try this patch. http://projects.nasreddine.com/projects/run/repository/revisions/mips1_fix/show/dev/usb/wlan Only if_run.c is patched since last time. (click file name, then click "download") If you are using r206358 or newer, please give me some time to fix. I'm stating it now. Is your kernel compiled with INVARIANTS option? AK ----- Original Message ---- > From: Ganbold > To: PseudoCylon > Cc: freebsd-current@freebsd.org > Sent: Tue, April 6, 2010 7:29:16 AM > Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > > PseudoCylon wrote: > ----- Original Message ---- > > >> From: Ganbold < > href="mailto:ganbold@gmail.com">ganbold@gmail.com> >> To: > PseudoCylon < > href="mailto:moonlightakkiy@yahoo.ca">moonlightakkiy@yahoo.ca> >> > Cc: > href="mailto:freebsd-current@freebsd.org">freebsd-current@freebsd.org >> > Sent: Wed, March 31, 2010 8:08:29 AM >> Subject: Re: CALL for TEST > [HOSTAP] run(4) ralink usb wireless >> >> Does stock run(4) > support hostap mode yet? >> > > No. There > were some bugs and I thought I fixed them. So, I called for test. It seems the > driver is working on x86, but not on mips. hostap mode should work on your other > computer with i386. > > I'm still working on patch. It panics where > there wasn't any changes made. Strange... > > Hi, Sorry, it looks like I missed some of your emails. Please > let me know if you need any info from my > side. thanks, Ganbold > > > AK > > __________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 08:12:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82FEF106566B; Thu, 8 Apr 2010 08:12:29 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward10.mail.yandex.net (forward10.mail.yandex.net [77.88.61.49]) by mx1.freebsd.org (Postfix) with ESMTP id 29B668FC08; Thu, 8 Apr 2010 08:12:27 +0000 (UTC) Received: from smtp6.mail.yandex.net (smtp6.mail.yandex.net [77.88.61.56]) by forward10.mail.yandex.net (Yandex) with ESMTP id B55CB1321959; Thu, 8 Apr 2010 12:09:40 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1270714180; bh=zasEUgyRcr47hQ5g0pbF5jSpV1QszOkTNwetS6mtOkw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=aCfcim6SoRFbtqcEe28BvNDmamRNdsR/tZprM/O9Y99fGZyG1XIUSJKKTzUzwZcVO Z/n0CR/F/7QhBHAZELZ3t06znnCjXGJTDiTgUBdXMWcx6I1HbZtGc3g2XOtFyPgtAz lKp4PVs1/pciopbFf9GAJ3/M1f2BjAnf4yQnEXiA= Received: from [127.0.0.1] (ns.kirov.so-cdu.ru [77.72.136.145]) by smtp6.mail.yandex.net (Yandex) with ESMTPSA id 5E16914C8032; Thu, 8 Apr 2010 12:09:40 +0400 (MSD) Message-ID: <4BBD8F43.5080606@yandex.ru> Date: Thu, 08 Apr 2010 12:09:39 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Randi Harper References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1270714180 X-Yandex-Spam: 1 X-Yandex-Front: smtp6.mail.yandex.net Cc: adrian@freebsd.org, freebsd-current@freebsd.org, Devin Teske , freebsd-geom@freebsd.org Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 08:12:29 -0000 On 08.04.2010 11:27, Randi Harper wrote: > It's great that you want to work on this, but there are other people > working in the same area, so keeping your code to yourself for too > long makes it very likely that it will never get used. Ok. I put the code here: http://butcher.heavennet.ru/sade/sade-20100408.tgz -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 08:38:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61E1F106564A for ; Thu, 8 Apr 2010 08:38:21 +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 8DEBA8FC17 for ; Thu, 8 Apr 2010 08:38:20 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2CF7F.dip.t-dialin.net [217.226.207.127]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 8ADA98442CF; Thu, 8 Apr 2010 10:38:13 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 97785504B; Thu, 8 Apr 2010 10:38:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1270715890; bh=aANFLhxYypyao71LqraQa+Ve87gtxaf/RsowIXYm4AI=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=uPOe4rpQwSMzvPxDBYVVJd+VT7cAnOVlJf9O1KqH/nt3SGhxws8u+SN7ThZauC2EG +gNSGj+ASi3U4gxHlTci/m/VLEAUvYJ9HCd8rakeCBLH4s3wjPcOuU+VRPKofop+4A MQJr1b6OI2Qnh/VCO/h+qVuV271/jWcbdNj16T/SFxNdQ1eUAZEyhOU+3zqz0K726s Z3mhG4PbbOEqblJf0FEFFNzVgtJe1bibge3gIzlRMu60FlUT3ZOTY9mssEfFH806s7 6R98BvWR9d3fLRtbJTM+wQdA5CDCJzgJ9gYRGhRBCmw3+dWLlOBmVVl9feBAfrD+RE aqy0+HoHueVWw== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id o388cA26066315; Thu, 8 Apr 2010 10:38:10 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 08 Apr 2010 10:38:09 +0200 Message-ID: <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> Date: Thu, 08 Apr 2010 10:38:09 +0200 From: Alexander Leidinger To: "Andrey V. Elsukov" References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> <201004080727.21020.bruce@cran.org.uk> <4BBD7CDC.2070505@yandex.ru> In-Reply-To: <4BBD7CDC.2070505@yandex.ru> 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: 8ADA98442CF.D705A X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.44, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1271320695.93974@vKlu4naqNwYPQ3AYHlLF0w X-EBL-Spam-Status: No Cc: Bruce Cran , Devin, freebsd-geom@freebsd.org, Teske , Randi Harper , freebsd-current@freebsd.org Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 08:38:21 -0000 Quoting "Andrey V. Elsukov" (from Thu, 08 Apr 2010 10:51:08 +0400): > On 08.04.2010 10:27, Bruce Cran wrote: >> That's a shame. As long as the source isn't available it's of >> little interest >> to me. >> >> For anyone who wants to see the bits of code I've got so far, I've created a >> Google Code project at http://code.google.com/p/gcpart/ . I'm >> currently trying >> to figure out how to get the partitioning scheme out of the XML >> tree, which is >> why there's no geom code there yet. As soon as I do so, I'll start checking >> in my effort at the new partitioning application. > > I just thinking about future of my project. It seems there are several people > who worked on the same before. And I have not finished yet only few > things from > initially planned. After that i can remove any unused code, write > some comments > and publish it somewhere in perforce. Please consider using SVN instead. A lot more users will be able to check out from there. > Also at this time code depends on changes which i made in > geom_part.so and which > are not yet commited into base system. > After code review there can be several ways to go. And I have an > interest which way > will be for me :) It looks like other people had a look at sysinstall, not at sade. As sysinstall is supposed to be used at installation time, and the intent for sade was to offer the functionality (or more) of the part of sysinstall which is useful after installation (and to prevent admins from using sysinstall after the installation to prevent some unwanted foot-shooting), I do not think that we need to think about a strong lock between sysinstall and sade. If you can enhance sade beyond what sysinstall is able to do, I would say go ahead (note: I committed sade). Bye, Alexander. -- Leela: "He's crude and gross and he treats me like a slave." Fry: "Then dump his one-eyed ass." http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 08:46:06 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21159106564A for ; Thu, 8 Apr 2010 08:46:06 +0000 (UTC) (envelope-from kraduk@googlemail.com) Received: from mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by mx1.freebsd.org (Postfix) with ESMTP id 9BF128FC14 for ; Thu, 8 Apr 2010 08:46:05 +0000 (UTC) Received: by fxm25 with SMTP id 25so27669fxm.3 for ; Thu, 08 Apr 2010 01:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=vzhGnLvP81kbYXwGftZOl7hTyV/ATS357b/vOKwMfBE=; b=aqnssRpgcqVTJdJ40SyfsSwwNizjD5ALzQ4fno+vqy/KevG9vfIz3kG9+XYfg8kVtA qJLqldPmrRnMLC9HkMhjWxVhwvCnCwYWDGDRTQjHXKh5D4ItXLql3p2Q+vdAIZcjogdH MAdwstPn+lq+6w8AEM8GgiM/CB8qC6JIa9rb0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bjXxvnAS6QMRiP9qRF/k2QgFSLjUBX9SsUGWn8HdV8SVrYLIiRi5A0DsJC9iPc6sLe /uHT+E2paGwfoIkHbphihNnPAc7yDbTTR0U2/igXL6opOUggb91yYVGBioU3qgLH5/0N 3EPs3sFEn9GvYLwB1/oTspYdqo4M69cUibSKI= MIME-Version: 1.0 Received: by 10.239.157.136 with HTTP; Thu, 8 Apr 2010 01:46:04 -0700 (PDT) In-Reply-To: <20100407173334.GC76941@dan.emsphone.com> References: <20100407173334.GC76941@dan.emsphone.com> Date: Thu, 8 Apr 2010 09:46:04 +0100 Received: by 10.239.193.144 with SMTP id j16mr444611hbi.76.1270716364190; Thu, 08 Apr 2010 01:46:04 -0700 (PDT) Message-ID: From: krad To: Dan Nelson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Freddie Cash , current@freebsd.org Subject: Re: When will we can use ZFS v24? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 08:46:06 -0000 On 7 April 2010 18:33, Dan Nelson wrote: > In the last episode (Apr 07), krad said: > > On 7 April 2010 05:38, Freddie Cash wrote: > > > On Tue, Apr 6, 2010 at 9:35 PM, lhmwzy wrote: > > > > What's your mean?? > > > > > > See the archives for the freebsd-fs mailing list. There are two > > > separate groups working on getting ZFSv22 added to FreeBSD 9-CURRENT. > > > And there's work ongoing to get ZFSv15 added to FreeBSD 8-STABLE. > > > > > > IOW, just be patient. Good things will come to those who wait. ;) > > > > If you re hankering for dedup you better have a big box as its a complete > > resource hog. From what we have seen on our x4500 filers we need about > > 100gig of ram or l2arc ssd to hold the all the metadata for the 34TB of > > storage, otherwise the system grinds to a halt. > > I wish they had an option for "opportunistic" dedup, where if a block is > already in ARC it can be a dedupe candidate, but it won't look it up in the > DDT if it isn't already in memory. That catches the simple "cp -R dir1 > dir2" cases without blowing up the ARC on DDT blocks that 99.9999% of the > time don't match. > > -- > Dan Nelson > dnelson@allantgroup.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > ZFS is still currently in heavy development so it might happen. Having siad that it looks like oracle have totally buggered it up for everyone with their retroactive licenses. I hope the CDL was tight enough that stuff wont have to get pulled from freebsd From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 09:05:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7000A106566B; Thu, 8 Apr 2010 09:05:36 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 219038FC1C; Thu, 8 Apr 2010 09:05:35 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 33B841FFC22; Thu, 8 Apr 2010 09:05:35 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 1434A844C6; Thu, 8 Apr 2010 11:05:35 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Leidinger References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> <201004080727.21020.bruce@cran.org.uk> <4BBD7CDC.2070505@yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> Date: Thu, 08 Apr 2010 11:05:34 +0200 In-Reply-To: <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> (Alexander Leidinger's message of "Thu, 08 Apr 2010 10:38:09 +0200") Message-ID: <867hoi8gbl.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , freebsd-current@freebsd.org, freebsd-geom@freebsd.org, Teske , Randi Harper , "Andrey V. Elsukov" , Devin@FreeBSD.ORG Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 09:05:36 -0000 Alexander Leidinger writes: > Please consider using SVN instead. A lot more users will be able to > check out from there. We don't grant non-committers access to the Subversion repo. > It looks like other people had a look at sysinstall, not at sade. As > sysinstall is supposed to be used at installation time, and the intent > for sade was to offer the functionality (or more) of the part of > sysinstall which is useful after installation (and to prevent admins > from using sysinstall after the installation to prevent some unwanted > foot-shooting), I do not think that we need to think about a strong > lock between sysinstall and sade. Yes we do. Otherwise we'll just end up back where we are today, where if you want anything more complicated than a single-disk install you have to drop into the fixit shell and do it manually before running the installation procedure. Anythig that sade can do, we want sysinstall to do as well, and we don't want to implement everything twice. My suggestion is to add a "sysinstall mode" to sade where it operates under certain (minor) constraints and reports what it did in a format that sysinstall can parse, so sysinstall can just fork-exec sade instead of duplicating the code. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 10:06:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D790C106564A for ; Thu, 8 Apr 2010 10:06:03 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by mx1.freebsd.org (Postfix) with ESMTP id D81508FC14 for ; Thu, 8 Apr 2010 10:06:02 +0000 (UTC) Received: by fxm25 with SMTP id 25so23862fxm.3 for ; Thu, 08 Apr 2010 03:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=c0O6dn6n5vVob/n/2w7fdXlyn/jsTdLeEC/cfHLNovc=; b=KLaWEHS48w/qpJ4MelyP5s9rdMYu9f/SiPCCXgiWASpAV6wYWWCUOvce8G/03/VaDE hGcFYb4DuRMVH5GGfXwo4YBfoDdUocgL9SAjX/MJpN03Q/RCyRgKq+KcDqY4f2rADw2V yV9ukw3kKgNACvcoaFEyhb5dcLQvdgHgmK+5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=plI52ajDxoXeJNTDRZHrvpnOvuOJKLEeEpmxgCK1goHpK8VK62Mg409tvP1DvEARxy SJk+cXJCuX0c55f4SdKMUIR1OqTimxJE3Gizv3iaG8Zm/W7eXCltyLnc4YGb3OIHCyO3 7XC6Rf3gOu004WT7Eks/M4ySzeFeIvQbSw+M8= Received: by 10.223.50.68 with SMTP id y4mr2148563faf.51.1270721161866; Thu, 08 Apr 2010 03:06:01 -0700 (PDT) Received: from [10.0.10.2] (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 14sm1247106fxm.9.2010.04.08.03.06.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 08 Apr 2010 03:06:01 -0700 (PDT) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Rui Paulo In-Reply-To: <867hoi8gbl.fsf@ds4.des.no> Date: Thu, 8 Apr 2010 11:05:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> <201004080727.21020.bruce@cran.org.uk> <4BBD7CDC.2070505@yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1078) Cc: Bruce Cran , freebsd-geom@freebsd.org, Teske , Randi Harper , freebsd-current@freebsd.org, Devin@FreeBSD.ORG, "Andrey V. Elsukov" , Alexander Leidinger Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 10:06:03 -0000 On 8 Apr 2010, at 10:05, Dag-Erling Sm=F8rgrav wrote: > Alexander Leidinger writes: >> Please consider using SVN instead. A lot more users will be able to >> check out from there. >=20 > We don't grant non-committers access to the Subversion repo. The SVN repo is available to the public via HTTP. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 10:15:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BE9D106566B; Thu, 8 Apr 2010 10:15:09 +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 0EC6A8FC0C; Thu, 8 Apr 2010 10:15:08 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2CF7F.dip.t-dialin.net [217.226.207.127]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 29A5E8442D0; Thu, 8 Apr 2010 12:15:04 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 42E655056; Thu, 8 Apr 2010 12:15:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1270721701; bh=slvV61o7vcBBw/krqiBb+PvPNKGto5e8uOS5jhvE+wI=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=dhnQF28omWnIQdmiJ0x6n+akrcQen3WLkp+W4917RcJLu5ZtLvrf/YNHuFc5/M+Bb aQQykhh2GQGwVjGV4IqJM2GCKgsYIEtgg6ubuLs+7BIg5wGDCBGE3zNgQDah2zrS0b J03XGep6VSUC+vc6HvIajn9NQtSPR2vZa0mDtlaS4gMAAoKthnq4wJ9ljv4+wwfp+I 4/YGbtyPENC/6ils7dsTF1HgBBRHhwqfHU0WTO2tWijKV4OG9ZRTp4YeVytuWBdoxl xb1tmV2eW9SF+UVwQTWxQI61UyC3O0j4LohFoiDd1ep7UkbhZbFGBl2sO/8gquw6Tc fq9qZ6pBqy8vg== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id o38AF0YC088184; Thu, 8 Apr 2010 12:15:00 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 08 Apr 2010 12:15:00 +0200 Message-ID: <20100408121500.13995d1eu7b9bt0k@webmail.leidinger.net> Date: Thu, 08 Apr 2010 12:15:00 +0200 From: Alexander Leidinger To: Dag-Erling =?utf-8?b?U23Dg8K4cmdyYXY=?= References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> <201004080727.21020.bruce@cran.org.uk> <4BBD7CDC.2070505@yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> In-Reply-To: <867hoi8gbl.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: 29A5E8442D0.9E186 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.44, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1271326504.70378@xnbci6vqNKk8wDxFQPqwJA X-EBL-Spam-Status: No Cc: Bruce Cran , freebsd-current@FreeBSD.ORG, freebsd-geom@FreeBSD.ORG, Teske , Randi Harper , "Andrey V. Elsukov" , Devin@FreeBSD.ORG Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 10:15:09 -0000 Quoting Dag-Erling Sm=C3=83=C2=B8rgrav (from Thu, 08 Apr 2010 = =20 11:05:34 +0200): > Alexander Leidinger writes: >> Please consider using SVN instead. A lot more users will be able to >> check out from there. > > We don't grant non-committers access to the Subversion repo. Ooops... seems I misremembered his status. Somehow I associate him =20 with something FreeBSD related. Andrey, did you participate in a GSoC? >> It looks like other people had a look at sysinstall, not at sade. As >> sysinstall is supposed to be used at installation time, and the intent >> for sade was to offer the functionality (or more) of the part of >> sysinstall which is useful after installation (and to prevent admins >> from using sysinstall after the installation to prevent some unwanted >> foot-shooting), I do not think that we need to think about a strong >> lock between sysinstall and sade. > > Yes we do. Otherwise we'll just end up back where we are today, where > if you want anything more complicated than a single-disk install you > have to drop into the fixit shell and do it manually before running the > installation procedure. Anythig that sade can do, we want sysinstall to > do as well, and we don't want to implement everything twice. From the man page: ---snip--- NOTES The sade utility aims to provide a handy tool for disk management tas= ks on an already installed system. ---snip--- Disk management tasks contains stuff which exceeds what sysinstall =20 needs to provide. One possible extension is to display content from =20 /etc/dumpdates along with partitions (would be helpful if someone uses =20 dump to make backups and wants to delete a partition, but only if =20 there is a recent backup available). > My suggestion is to add a "sysinstall mode" to sade where it operates > under certain (minor) constraints and reports what it did in a format > that sysinstall can parse, so sysinstall can just fork-exec sade instead > of duplicating the code. I think this is more complicated than to refactor the interesting part =20 into a backend with an API which both tools can use. This would also =20 allow someone to write a GUI program (e.g. for PC-BSD). Again, there is no need for a *strong* lock between sysinstall and =20 sade. Both should provide similar features regarding partition and =20 slice handling, but they do not need to share exactly the same =20 interface code. Bye, Alexander. --=20 Above all else - sky. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 10:19:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 393A6106564A for ; Thu, 8 Apr 2010 10:19:30 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from mail.stillbilde.net (unknown [IPv6:2002:51af:3dc3:0:20c:29ff:fece:79f3]) by mx1.freebsd.org (Postfix) with ESMTP id B33268FC16 for ; Thu, 8 Apr 2010 10:19:29 +0000 (UTC) Received: from [IPv6:2002:51af:3dc3:0:8898:16b7:5ffe:35d7] (unknown [IPv6:2002:51af:3dc3:0:8898:16b7:5ffe:35d7]) (Authenticated sender: svein-listmail) by mail.stillbilde.net (Familien Skogens mail) with ESMTPSA id 4F5EA7B for ; Thu, 8 Apr 2010 12:19:34 +0200 (CEST) Message-ID: <4BBDADAC.7080803@stillbilde.net> Date: Thu, 08 Apr 2010 12:19:24 +0200 From: "Svein Skogen (Listmail Account)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> <201004080727.21020.bruce@cran.org.uk> <4BBD7CDC.2070505@yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> In-Reply-To: <867hoi8gbl.fsf@ds4.des.no> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig78661AF243B84F14DC2E64AD" Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 10:19:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig78661AF243B84F14DC2E64AD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08.04.2010 11:05, Dag-Erling Sm=C3=B8rgrav wrote: > Alexander Leidinger writes: >> Please consider using SVN instead. A lot more users will be able to >> check out from there. >=20 > We don't grant non-committers access to the Subversion repo. >=20 >> It looks like other people had a look at sysinstall, not at sade. As >> sysinstall is supposed to be used at installation time, and the intent= >> for sade was to offer the functionality (or more) of the part of >> sysinstall which is useful after installation (and to prevent admins >> from using sysinstall after the installation to prevent some unwanted >> foot-shooting), I do not think that we need to think about a strong >> lock between sysinstall and sade. >=20 > Yes we do. Otherwise we'll just end up back where we are today, where > if you want anything more complicated than a single-disk install you > have to drop into the fixit shell and do it manually before running the= > installation procedure. Anythig that sade can do, we want sysinstall t= o > do as well, and we don't want to implement everything twice. >=20 > My suggestion is to add a "sysinstall mode" to sade where it operates > under certain (minor) constraints and reports what it did in a format > that sysinstall can parse, so sysinstall can just fork-exec sade instea= d > of duplicating the code. Wouldn't a setup similar to fetch/libfetch do the trick here? Move most of the actual "working payload" of sade into a library, and make sade just a frontend for this? That way poking the sysinstall code to use sade should be easier, and updates will automagically fix both things? //Svein --=20 --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg =C3=98stli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ ------------------------------------------------------------ --------------enig78661AF243B84F14DC2E64AD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) iEYEARECAAYFAku9ra8ACgkQODUnwSLUlKQaVgCgpLIvqQWK/NsUv4e6i7IUZl6U 3JQAnjz0dNoBMFTsYOBzplrfaYiMA6mO =FkCG -----END PGP SIGNATURE----- --------------enig78661AF243B84F14DC2E64AD-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 10:20:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40FF8106566C; Thu, 8 Apr 2010 10:20:40 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4BFC98FC1C; Thu, 8 Apr 2010 10:20:38 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA21604; Thu, 08 Apr 2010 13:20:31 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BBDADEE.1090401@icyb.net.ua> Date: Thu, 08 Apr 2010 13:20:30 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> <201004080727.21020.bruce@cran.org.uk> <4BBD7CDC.2070505@yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> In-Reply-To: <867hoi8gbl.fsf@ds4.des.no> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "Andrey V. Elsukov" , Alexander Leidinger , freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 10:20:40 -0000 on 08/04/2010 12:05 Dag-Erling Smørgrav said the following: > Alexander Leidinger writes: >> Please consider using SVN instead. A lot more users will be able to >> check out from there. > > We don't grant non-committers access to the Subversion repo. But nothing stops Andrey from creating his own svn/hg/git/etc repo _just_ for his sade bits. It's easy. This is what I would do even just for my own sake. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 10:30:36 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12FEB106566B; Thu, 8 Apr 2010 10:30:36 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward11.mail.yandex.net (forward11.mail.yandex.net [95.108.130.93]) by mx1.freebsd.org (Postfix) with ESMTP id 706B38FC0A; Thu, 8 Apr 2010 10:30:35 +0000 (UTC) Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67]) by forward11.mail.yandex.net (Yandex) with ESMTP id 5A999F488B5; Thu, 8 Apr 2010 14:30:34 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1270722634; bh=HYZC3P6RF0Rq0XOLRh9MZchyCALtutjXz1omf/4jVRo=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=kupFUl63Gqqm9SG+Xg7BooweG5zL9d9vPdxDtobXdG2jBKtHwwyo3eC1rLdgJi8bv AhFiZryQ+EiUPryMKWeZEtFD2BH6c27Sydq6K/oA6F+NXrY3+q/O2eM7WW3QHJmqrf lFCCqJnglNMrOwtkfaDSbP63g+bJvuD9TeXLyG9A= Received: from [127.0.0.1] (mail.kirov.so-cdu.ru [77.72.136.145]) by smtp11.mail.yandex.net (Yandex) with ESMTPSA id CC430673007D; Thu, 8 Apr 2010 14:30:33 +0400 (MSD) Message-ID: <4BBDB049.4010605@yandex.ru> Date: Thu, 08 Apr 2010 14:30:33 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Alexander Leidinger References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> <201004080727.21020.bruce@cran.org.uk> <4BBD7CDC.2070505@yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <20100408121500.13995d1eu7b9bt0k@webmail.leidinger.net> In-Reply-To: <20100408121500.13995d1eu7b9bt0k@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1270722634 X-Yandex-Spam: 1 X-Yandex-Front: smtp11.mail.yandex.net Cc: Bruce Cran , freebsd-geom@FreeBSD.ORG, Teske , Randi Harper , freebsd-current@FreeBSD.ORG, Devin@FreeBSD.ORG, =?UTF-8?B?RGFnLUVybGluZyBTbcODwrhyZ3Jhdg==?= Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 10:30:36 -0000 On 08.04.2010 14:15, Alexander Leidinger wrote: >> We don't grant non-committers access to the Subversion repo. > > Ooops... seems I misremembered his status. Somehow I associate him with > something FreeBSD related. Andrey, did you participate in a GSoC? No, I'm not fit for GSoC. >> My suggestion is to add a "sysinstall mode" to sade where it operates >> under certain (minor) constraints and reports what it did in a format >> that sysinstall can parse, so sysinstall can just fork-exec sade instead >> of duplicating the code. I like this idea. Any way i'll try to finish my work myself. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 11:13:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7CE6106566B; Thu, 8 Apr 2010 11:13:05 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8E34E8FC18; Thu, 8 Apr 2010 11:13:05 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 8C5941FFC22; Thu, 8 Apr 2010 11:13:04 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 2DAB7844A8; Thu, 8 Apr 2010 13:13:04 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Rui Paulo References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> <201004080727.21020.bruce@cran.org.uk> <4BBD7CDC.2070505@yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> Date: Thu, 08 Apr 2010 13:13:03 +0200 In-Reply-To: (Rui Paulo's message of "Thu, 8 Apr 2010 11:05:59 +0100") Message-ID: <86ochuuri8.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , freebsd-geom@freebsd.org, Teske , Randi Harper , freebsd-current@freebsd.org, "Andrey V. Elsukov" , Alexander Leidinger Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 11:13:05 -0000 Rui Paulo writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Alexander Leidinger writes: > > > Please consider using SVN instead. A lot more users will be able > > > to check out from there. > > We don't grant non-committers access to the Subversion repo. > The SVN repo is available to the public via HTTP. AFAIK, the OP is not a committer, and hence does not have write access. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 12:01:35 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E06B106566B; Thu, 8 Apr 2010 12:01:35 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id E9DE78FC34; Thu, 8 Apr 2010 12:01:34 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 089C91FFC22; Thu, 8 Apr 2010 12:01:34 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id DD803844A8; Thu, 8 Apr 2010 14:01:33 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Leidinger References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> <201004080727.21020.bruce@cran.org.uk> <4BBD7CDC.2070505@yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <20100408121500.13995d1eu7b9bt0k@webmail.leidinger.net> Date: Thu, 08 Apr 2010 14:01:33 +0200 In-Reply-To: <20100408121500.13995d1eu7b9bt0k@webmail.leidinger.net> (Alexander Leidinger's message of "Thu, 08 Apr 2010 12:15:00 +0200") Message-ID: <86fx36up9e.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , freebsd-current@FreeBSD.ORG, freebsd-geom@FreeBSD.ORG, Teske , Randi Harper , "Andrey V. Elsukov" , Devin@FreeBSD.ORG Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 12:01:35 -0000 Alexander Leidinger writes: > I think this is more complicated than to refactor the interesting part > into a backend with an API which both tools can use. This would also > allow someone to write a GUI program (e.g. for PC-BSD). There have been at least three or four attempts to do this in the past. One of them was even fully funded by the FreeBSD Foundation. They all failed. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 13:22:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C8FE1065673 for ; Thu, 8 Apr 2010 13:22:26 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from relay.wahome.ru (relay.wahome.ru [95.211.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id 55E8D8FC1A for ; Thu, 8 Apr 2010 13:22:26 +0000 (UTC) Received: from mmx.lexasoft.ru (mmx.lexasoft.ru [92.241.160.6]) by relay.wahome.ru (Postfix) with ESMTP id E3D4B6B1915 for ; Thu, 8 Apr 2010 17:03:59 +0400 (MSD) Received: from [10.100.0.2] (petrovich-telecom-gw.wahome.ru [77.91.225.38]) by mmx.lexasoft.ru (Postfix) with ESMTPSA id 6FF182848C for ; Thu, 8 Apr 2010 17:06:56 +0400 (MSD) From: Alexey Tarasov Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Apr 2010 17:06:55 +0400 Message-Id: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> To: freebsd-current@freebsd.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 13:22:26 -0000 Hello. There is only one possibility to change sector size of physical disk = (gnop -S 4096 ...). May be it is possible to add such possibility to gpart? e.g. gpart = create -S 4096 -t gpt ad0? It will help all unlucky WD Advanced Format disks users. :-D -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(") From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 13:33:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89DE91065670 for ; Thu, 8 Apr 2010 13:33:15 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp2b.orange.fr (smtp2b.orange.fr [80.12.242.145]) by mx1.freebsd.org (Postfix) with ESMTP id 2915E8FC13 for ; Thu, 8 Apr 2010 13:33:13 +0000 (UTC) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2b14.orange.fr (SMTP Server) with ESMTP id 0359C7000267 for ; Thu, 8 Apr 2010 15:33:11 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2b14.orange.fr (SMTP Server) with ESMTP id F41E670009E7 for ; Thu, 8 Apr 2010 15:33:10 +0200 (CEST) Received: from localhost (AToulouse-553-1-155-53.w92-156.abo.wanadoo.fr [92.156.227.53]) by mwinf2b14.orange.fr (SMTP Server) with ESMTP id 3F1FD7000267 for ; Thu, 8 Apr 2010 15:33:08 +0200 (CEST) X-ME-UUID: 20100408133308258.3F1FD7000267@mwinf2b14.orange.fr Message-ID: <4BBDDB13.5020703@orange.fr> Date: Thu, 08 Apr 2010 15:33:07 +0200 From: Claude Buisson User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: FreeBSD Current Content-Type: multipart/mixed; boundary="------------040009020300060908010807" Subject: buildworld fails building _dtrace_tools X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 13:33:15 -0000 This is a multi-part message in MIME format. --------------040009020300060908010807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, I am trying to buildworld from source csuped on April 4, and the build fails in the bootstrap tools / dtrace tools phase (see listing below) To be considered: the building system is from the same source, but built WITHOUT_CDDL the failing build is done with WITHOUT_CDDL commented out in src.conf What I am doing wrong ? TIA Claude Buisson --------------040009020300060908010807 Content-Type: text/plain; name="mbw.out0" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="mbw.out0" U2NyaXB0IHN0YXJ0ZWQgb24gVGh1IEFwciAgOCAxNDo0MToxNiAyMDEwCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ Pj4gV29ybGQgYnVpbGQgc3RhcnRlZCBvbiBUaHUgQXByICA4IDE0OjQxOjE3IENFU1QgMjAx MA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiBSZWJ1aWxkaW5nIHRoZSB0ZW1wb3Jhcnkg YnVpbGQgdHJlZQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCnJtIC1yZiAvdXNyL29iai9ob21lL3NyYy90bXANCm1r ZGlyIC1wIC91c3Ivb2JqL2hvbWUvc3JjL3RtcC9saWINCm1rZGlyIC1wIC91c3Ivb2JqL2hv bWUvc3JjL3RtcC91c3INCm1rZGlyIC1wIC91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kv dXNyDQptdHJlZSAtZGVVIC1mIC9ob21lL3NyYy9ldGMvbXRyZWUvQlNELnVzci5kaXN0ICAt cCAvdXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3VzciA+L2Rldi9udWxsDQptdHJlZSAt ZGVVIC1mIC9ob21lL3NyYy9ldGMvbXRyZWUvQlNELnVzci5kaXN0ICAtcCAvdXNyL29iai9o b21lL3NyYy90bXAvdXNyID4vZGV2L251bGwNCm10cmVlIC1kZVUgLWYgL2hvbWUvc3JjL2V0 Yy9tdHJlZS9CU0QuaW5jbHVkZS5kaXN0ICAtcCAvdXNyL29iai9ob21lL3NyYy90bXAvdXNy L2luY2x1ZGUgPi9kZXYvbnVsbA0KbG4gLXNmIC9ob21lL3NyYy9zeXMgL3Vzci9vYmovaG9t ZS9zcmMvdG1wDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gc3RhZ2UgMS4xOiBsZWdhY3kgcmVsZWFzZSBj b21wYXRpYmlsaXR5IHNoaW1zDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KY2QgL2hvbWUvc3JjOyBNQUtFT0JKRElS UFJFRklYPS91c3Ivb2JqL2hvbWUvc3JjL3RtcCAgSU5TVEFMTD0ic2ggL2hvbWUvc3JjL3Rv b2xzL2luc3RhbGwuc2giICBQQVRIPS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNy L3NiaW46L3Vzci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvYmluOi91c3Ivb2JqL2hv bWUvc3JjL3RtcC9sZWdhY3kvdXNyL2dhbWVzOi9zYmluOi9iaW46L3Vzci9zYmluOi91c3Iv YmluICBXT1JMRFRNUD0vdXNyL29iai9ob21lL3NyYy90bXAgIFZFUlNJT049IkZyZWVCU0Qg OS4wLUNVUlJFTlQgaTM4NiA5MDAwMTAiICBNQUtFRkxBR1M9Ii1tIC9ob21lL3NyYy90b29s cy9idWlsZC9tayAgLUQgQUxXQVlTX0NIRUNLX01BS0UgLW0gL2hvbWUvc3JjL3NoYXJlL21r IiBtYWtlIC1mIE1ha2VmaWxlLmluYzEgIERFU1RESVI9ICBCT09UU1RSQVBQSU5HPTkwMDAx MCAgU1NQX0NGTEFHUz0gIC1EV0lUSE9VVF9IVE1MIC1EV0lUSE9VVF9JTkZPIC1ETk9fTElO VCAtRFdJVEhPVVRfTUFOICAtRE5PX1BJQyAtRFdJVEhPVVRfUFJPRklMRSAtRE5PX1NIQVJF RCAgLUROT19DUFVfQ0ZMQUdTIC1ETk9fV0FSTlMgLUROT19DVEYgbGVnYWN5DQo9PT0+IHRv b2xzL2J1aWxkIChvYmosaW5jbHVkZXMsZGVwZW5kLGFsbCxpbnN0YWxsKQ0KL3Vzci9vYmov aG9tZS9zcmMvdG1wL2hvbWUvc3JjL3Rvb2xzL2J1aWxkIGNyZWF0ZWQgZm9yIC9ob21lL3Ny Yy90b29scy9idWlsZA0KY2QgL2hvbWUvc3JjL3Rvb2xzL2J1aWxkOyBtYWtlIGJ1aWxkaW5j bHVkZXM7IG1ha2UgaW5zdGFsbGluY2x1ZGVzDQpybSAtZiAuZGVwZW5kDQpta2RlcCAtZiAu ZGVwZW5kIC1hICAgIC1ETkRFQlVHIC1JL3Vzci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91 c3IvaW5jbHVkZSAvaG9tZS9zcmMvdG9vbHMvYnVpbGQvZHVtbXkuYw0KY2MgLU8yIC1waXBl IC1ETkRFQlVHIC1zdGQ9Z251OTkgICAtSS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kv dXNyL2luY2x1ZGUgLWMgL2hvbWUvc3JjL3Rvb2xzL2J1aWxkL2R1bW15LmMNCmJ1aWxkaW5n IHN0YXRpYyBlZ2FjeSBsaWJyYXJ5DQpyYW5saWIgbGliZWdhY3kuYQ0Kc2ggL2hvbWUvc3Jj L3Rvb2xzL2luc3RhbGwuc2ggLUMgLW8gcm9vdCAtZyB3aGVlbCAtbSA0NDQgICBsaWJlZ2Fj eS5hIC91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2xpYg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pj4+IHN0YWdlIDEuMjogYm9vdHN0cmFwIHRvb2xzDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KY2QgL2hvbWUvc3Jj OyBNQUtFT0JKRElSUFJFRklYPS91c3Ivb2JqL2hvbWUvc3JjL3RtcCAgSU5TVEFMTD0ic2gg L2hvbWUvc3JjL3Rvb2xzL2luc3RhbGwuc2giICBQQVRIPS91c3Ivb2JqL2hvbWUvc3JjL3Rt cC9sZWdhY3kvdXNyL3NiaW46L3Vzci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvYmlu Oi91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2dhbWVzOi9zYmluOi9iaW46L3Vz ci9zYmluOi91c3IvYmluICBXT1JMRFRNUD0vdXNyL29iai9ob21lL3NyYy90bXAgIFZFUlNJ T049IkZyZWVCU0QgOS4wLUNVUlJFTlQgaTM4NiA5MDAwMTAiICBNQUtFRkxBR1M9Ii1tIC9o b21lL3NyYy90b29scy9idWlsZC9tayAgLUQgQUxXQVlTX0NIRUNLX01BS0UgLW0gL2hvbWUv c3JjL3NoYXJlL21rIiBtYWtlIC1mIE1ha2VmaWxlLmluYzEgIERFU1RESVI9ICBCT09UU1RS QVBQSU5HPTkwMDAxMCAgU1NQX0NGTEFHUz0gIC1EV0lUSE9VVF9IVE1MIC1EV0lUSE9VVF9J TkZPIC1ETk9fTElOVCAtRFdJVEhPVVRfTUFOICAtRE5PX1BJQyAtRFdJVEhPVVRfUFJPRklM RSAtRE5PX1NIQVJFRCAgLUROT19DUFVfQ0ZMQUdTIC1ETk9fV0FSTlMgLUROT19DVEYgYm9v dHN0cmFwLXRvb2xzDQo9PT0+IGNkZGwvdXNyLmJpbi9zZ3Ntc2cgKG9iaixkZXBlbmQsYWxs LGluc3RhbGwpDQovdXNyL29iai9ob21lL3NyYy90bXAvaG9tZS9zcmMvY2RkbC91c3IuYmlu L3Nnc21zZyBjcmVhdGVkIGZvciAvaG9tZS9zcmMvY2RkbC91c3IuYmluL3Nnc21zZw0Kcm0g LWYgLmRlcGVuZA0KbWtkZXAgLWYgLmRlcGVuZCAtYSAgICAtSS9ob21lL3NyYy9jZGRsL3Vz ci5iaW4vc2dzbXNnLy4uLy4uLy4uL3N5cy9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcyAtSS9o b21lL3NyYy9jZGRsL3Vzci5iaW4vc2dzbXNnLy4uLy4uLy4uL2NkZGwvY29tcGF0L29wZW5z b2xhcmlzL2luY2x1ZGUgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL3Nnc21zZy8uLi8uLi8u Li9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvY21kL3Nncy9pbmNsdWRlIC1JL2hvbWUvc3Jj L2NkZGwvdXNyLmJpbi9zZ3Ntc2cvLi4vLi4vLi4vc3lzL2NkZGwvY29udHJpYi9vcGVuc29s YXJpcy91dHMvY29tbW9uIC1ETkVFRF9TT0xBUklTX0JPT0xFQU4gLUROREVCVUcgLUkvdXNy L29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC9ob21lL3NyYy9jZGRsL3Vz ci5iaW4vc2dzbXNnLy4uLy4uLy4uL3N5cy9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvY29t bW9uL2F2bC9hdmwuYyAvaG9tZS9zcmMvY2RkbC91c3IuYmluL3Nnc21zZy8uLi8uLi8uLi9j ZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvY21kL3Nncy90b29scy9jb21tb24vc2dzbXNnLmMg L2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9zZ3Ntc2cvLi4vLi4vLi4vY2RkbC9jb250cmliL29w ZW5zb2xhcmlzL2NtZC9zZ3MvdG9vbHMvY29tbW9uL3N0cmluZ190YWJsZS5jIC9ob21lL3Ny Yy9jZGRsL3Vzci5iaW4vc2dzbXNnLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJp cy9jbWQvc2dzL3Rvb2xzL2NvbW1vbi9maW5kcHJpbWUuYw0KZWNobyBzZ3Ntc2c6IC91c3Iv bGliL2xpYmMuYSAvdXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9saWIvbGliZWdh Y3kuYSA+PiAuZGVwZW5kDQpjYyAtTzIgLXBpcGUgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmlu L3Nnc21zZy8uLi8uLi8uLi9zeXMvY2RkbC9jb21wYXQvb3BlbnNvbGFyaXMgIC1JL2hvbWUv c3JjL2NkZGwvdXNyLmJpbi9zZ3Ntc2cvLi4vLi4vLi4vY2RkbC9jb21wYXQvb3BlbnNvbGFy aXMvaW5jbHVkZSAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL3Nnc21zZy8uLi8uLi8uLi9j ZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvY21kL3Nncy9pbmNsdWRlICAtSS9ob21lL3NyYy9j ZGRsL3Vzci5iaW4vc2dzbXNnLy4uLy4uLy4uL3N5cy9jZGRsL2NvbnRyaWIvb3BlbnNvbGFy aXMvdXRzL2NvbW1vbiAtRE5FRURfU09MQVJJU19CT09MRUFOIC1ETkRFQlVHIC1zdGQ9Z251 ODkgIC1Xbm8tdW5rbm93bi1wcmFnbWFzIC1JL3Vzci9vYmovaG9tZS9zcmMvdG1wL2xlZ2Fj eS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvY2RkbC91c3IuYmluL3Nnc21zZy8uLi8uLi8u Li9zeXMvY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2NvbW1vbi9hdmwvYXZsLmMNCmNjIC1P MiAtcGlwZSAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vc2dzbXNnLy4uLy4uLy4uL3N5cy9j ZGRsL2NvbXBhdC9vcGVuc29sYXJpcyAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL3Nnc21z Zy8uLi8uLi8uLi9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcy9pbmNsdWRlICAtSS9ob21lL3Ny Yy9jZGRsL3Vzci5iaW4vc2dzbXNnLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJp cy9jbWQvc2dzL2luY2x1ZGUgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9zZ3Ntc2cvLi4v Li4vLi4vc3lzL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uIC1ETkVFRF9T T0xBUklTX0JPT0xFQU4gLUROREVCVUcgLXN0ZD1nbnU4OSAgLVduby11bmtub3duLXByYWdt YXMgLUkvdXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21l L3NyYy9jZGRsL3Vzci5iaW4vc2dzbXNnLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29s YXJpcy9jbWQvc2dzL3Rvb2xzL2NvbW1vbi9zZ3Ntc2cuYw0KSW4gZmlsZSBpbmNsdWRlZCBm cm9tIC9ob21lL3NyYy9jZGRsL3Vzci5iaW4vc2dzbXNnLy4uLy4uLy4uL2NkZGwvY29udHJp Yi9vcGVuc29sYXJpcy9jbWQvc2dzL3Rvb2xzL2NvbW1vbi9zZ3Ntc2cuYzo4MToNCi9ob21l L3NyYy9jZGRsL3Vzci5iaW4vc2dzbXNnLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29s YXJpcy9jbWQvc2dzL2luY2x1ZGUvc2dzLmg6NDY6MTogd2FybmluZzogIk5ERUJVRyIgcmVk ZWZpbmVkDQo8Y29tbWFuZC1saW5lPjogd2FybmluZzogdGhpcyBpcyB0aGUgbG9jYXRpb24g b2YgdGhlIHByZXZpb3VzIGRlZmluaXRpb24NCmNjIC1PMiAtcGlwZSAtSS9ob21lL3NyYy9j ZGRsL3Vzci5iaW4vc2dzbXNnLy4uLy4uLy4uL3N5cy9jZGRsL2NvbXBhdC9vcGVuc29sYXJp cyAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL3Nnc21zZy8uLi8uLi8uLi9jZGRsL2NvbXBh dC9vcGVuc29sYXJpcy9pbmNsdWRlICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vc2dzbXNn Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9jbWQvc2dzL2luY2x1ZGUgIC1J L2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9zZ3Ntc2cvLi4vLi4vLi4vc3lzL2NkZGwvY29udHJp Yi9vcGVuc29sYXJpcy91dHMvY29tbW9uIC1ETkVFRF9TT0xBUklTX0JPT0xFQU4gLUROREVC VUcgLXN0ZD1nbnU4OSAgLVduby11bmtub3duLXByYWdtYXMgLUkvdXNyL29iai9ob21lL3Ny Yy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9jZGRsL3Vzci5iaW4vc2dz bXNnLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9jbWQvc2dzL3Rvb2xzL2Nv bW1vbi9zdHJpbmdfdGFibGUuYw0KSW4gZmlsZSBpbmNsdWRlZCBmcm9tIC9ob21lL3NyYy9j ZGRsL3Vzci5iaW4vc2dzbXNnLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9j bWQvc2dzL3Rvb2xzL2NvbW1vbi9zdHJpbmdfdGFibGUuYzozMToNCi9ob21lL3NyYy9jZGRs L3Vzci5iaW4vc2dzbXNnLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9jbWQv c2dzL2luY2x1ZGUvc2dzLmg6NDY6MTogd2FybmluZzogIk5ERUJVRyIgcmVkZWZpbmVkDQo8 Y29tbWFuZC1saW5lPjogd2FybmluZzogdGhpcyBpcyB0aGUgbG9jYXRpb24gb2YgdGhlIHBy ZXZpb3VzIGRlZmluaXRpb24NCmNjIC1PMiAtcGlwZSAtSS9ob21lL3NyYy9jZGRsL3Vzci5i aW4vc2dzbXNnLy4uLy4uLy4uL3N5cy9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcyAgLUkvaG9t ZS9zcmMvY2RkbC91c3IuYmluL3Nnc21zZy8uLi8uLi8uLi9jZGRsL2NvbXBhdC9vcGVuc29s YXJpcy9pbmNsdWRlICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vc2dzbXNnLy4uLy4uLy4u L2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9jbWQvc2dzL2luY2x1ZGUgIC1JL2hvbWUvc3Jj L2NkZGwvdXNyLmJpbi9zZ3Ntc2cvLi4vLi4vLi4vc3lzL2NkZGwvY29udHJpYi9vcGVuc29s YXJpcy91dHMvY29tbW9uIC1ETkVFRF9TT0xBUklTX0JPT0xFQU4gLUROREVCVUcgLXN0ZD1n bnU4OSAgLVduby11bmtub3duLXByYWdtYXMgLUkvdXNyL29iai9ob21lL3NyYy90bXAvbGVn YWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9jZGRsL3Vzci5iaW4vc2dzbXNnLy4uLy4u Ly4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9jbWQvc2dzL3Rvb2xzL2NvbW1vbi9maW5k cHJpbWUuYw0KSW4gZmlsZSBpbmNsdWRlZCBmcm9tIC9ob21lL3NyYy9jZGRsL3Vzci5iaW4v c2dzbXNnLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9jbWQvc2dzL3Rvb2xz L2NvbW1vbi9maW5kcHJpbWUuYzozMDoNCi9ob21lL3NyYy9jZGRsL3Vzci5iaW4vc2dzbXNn Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9jbWQvc2dzL2luY2x1ZGUvc2dz Lmg6NDY6MTogd2FybmluZzogIk5ERUJVRyIgcmVkZWZpbmVkDQo8Y29tbWFuZC1saW5lPjog d2FybmluZzogdGhpcyBpcyB0aGUgbG9jYXRpb24gb2YgdGhlIHByZXZpb3VzIGRlZmluaXRp b24NCmNjIC1PMiAtcGlwZSAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vc2dzbXNnLy4uLy4u Ly4uL3N5cy9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcyAgLUkvaG9tZS9zcmMvY2RkbC91c3Iu YmluL3Nnc21zZy8uLi8uLi8uLi9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcy9pbmNsdWRlICAt SS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vc2dzbXNnLy4uLy4uLy4uL2NkZGwvY29udHJpYi9v cGVuc29sYXJpcy9jbWQvc2dzL2luY2x1ZGUgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9z Z3Ntc2cvLi4vLi4vLi4vc3lzL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9u IC1ETkVFRF9TT0xBUklTX0JPT0xFQU4gLUROREVCVUcgLXN0ZD1nbnU4OSAgLVduby11bmtu b3duLXByYWdtYXMgLUkvdXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRl ICAtc3RhdGljIC1ML3Vzci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvbGliIC1vIHNn c21zZyBhdmwubyBzZ3Ntc2cubyBzdHJpbmdfdGFibGUubyBmaW5kcHJpbWUubyAtbGVnYWN5 DQpzaCAvaG9tZS9zcmMvdG9vbHMvaW5zdGFsbC5zaCAtcyAtbyByb290IC1nIHdoZWVsIC1t IDU1NSAgIHNnc21zZyAvdXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9iaW4NCj09 PT4gY2RkbC9saWIvbGliY3RmIChvYmosZGVwZW5kLGFsbCxpbnN0YWxsKQ0KL3Vzci9vYmov aG9tZS9zcmMvdG1wL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0ZiBjcmVhdGVkIGZvciAvaG9t ZS9zcmMvY2RkbC9saWIvbGliY3RmDQpybSAtZiAuZGVwZW5kDQpta2RlcCAtZiAuZGVwZW5k IC1hICAgIC1EQ1RGX09MRF9WRVJTSU9OUyAtSS9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYv Li4vLi4vLi4vc3lzL2NkZGwvY29tcGF0L29wZW5zb2xhcmlzIC1JL2hvbWUvc3JjL2NkZGwv bGliL2xpYmN0Zi8uLi8uLi8uLi9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcy9pbmNsdWRlIC1J L2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNv bGFyaXMvaGVhZCAtSS9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYvLi4vLi4vLi4vY2RkbC9j b250cmliL29wZW5zb2xhcmlzL2NvbW1vbi9jdGYgLUkvaG9tZS9zcmMvY2RkbC9saWIvbGli Y3RmLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9saWIvbGliY3RmL2NvbW1v biAtSS9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYvLi4vLi4vLi4vc3lzL2NkZGwvY29udHJp Yi9vcGVuc29sYXJpcy91dHMvY29tbW9uIC1ETkVFRF9TT0xBUklTX0JPT0xFQU4gLUROREVC VUcgLUkvdXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC9ob21lL3Ny Yy9jZGRsL2xpYi9saWJjdGYvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2Nv bW1vbi9jdGYvY3RmX2NyZWF0ZS5jIC9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYvLi4vLi4v Li4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2NvbW1vbi9jdGYvY3RmX2RlY2wuYyAvaG9t ZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJp cy9jb21tb24vY3RmL2N0Zl9lcnJvci5jIC9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYvLi4v Li4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2NvbW1vbi9jdGYvY3RmX2hhc2guYyAv aG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29s YXJpcy9jb21tb24vY3RmL2N0Zl9sYWJlbHMuYyAvaG9tZS9zcmMvY2RkbC9saWIvbGliY3Rm Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9saWIvbGliY3RmL2NvbW1vbi9j dGZfbGliLmMgL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8uLi9jZGRsL2NvbnRy aWIvb3BlbnNvbGFyaXMvY29tbW9uL2N0Zi9jdGZfbG9va3VwLmMgL2hvbWUvc3JjL2NkZGwv bGliL2xpYmN0Zi8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvY29tbW9uL2N0 Zi9jdGZfb3Blbi5jIC9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYvLi4vLi4vLi4vY2RkbC9j b250cmliL29wZW5zb2xhcmlzL2xpYi9saWJjdGYvY29tbW9uL2N0Zl9zdWJyLmMgL2hvbWUv c3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMv Y29tbW9uL2N0Zi9jdGZfdHlwZXMuYyAvaG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4u Ly4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9jb21tb24vY3RmL2N0Zl91dGlsLmMNCmNj IC1PMiAtcGlwZSAtRENURl9PTERfVkVSU0lPTlMgLUkvaG9tZS9zcmMvY2RkbC9saWIvbGli Y3RmLy4uLy4uLy4uL3N5cy9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcyAgLUkvaG9tZS9zcmMv Y2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwvY29tcGF0L29wZW5zb2xhcmlzL2luY2x1 ZGUgIC1JL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8uLi9jZGRsL2NvbnRyaWIv b3BlbnNvbGFyaXMvaGVhZCAgLUkvaG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4u L2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9jb21tb24vY3RmICAtSS9ob21lL3NyYy9jZGRs L2xpYi9saWJjdGYvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2xpYi9saWJj dGYvY29tbW9uICAtSS9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYvLi4vLi4vLi4vc3lzL2Nk ZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uIC1ETkVFRF9TT0xBUklTX0JPT0xF QU4gLUROREVCVUcgLXN0ZD1nbnU4OSAgLVduby11bmtub3duLXByYWdtYXMgLUkvdXNyL29i ai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9jZGRsL2xp Yi9saWJjdGYvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2NvbW1vbi9jdGYv Y3RmX2NyZWF0ZS5jDQovaG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwv Y29udHJpYi9vcGVuc29sYXJpcy9jb21tb24vY3RmL2N0Zl9jcmVhdGUuYzogSW4gZnVuY3Rp b24gJ2N0Zl9jcmVhdGUnOg0KL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8uLi9j ZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvY29tbW9uL2N0Zi9jdGZfY3JlYXRlLmM6NjM6IHdh cm5pbmc6IGFzc2lnbm1lbnQgZGlzY2FyZHMgcXVhbGlmaWVycyBmcm9tIHBvaW50ZXIgdGFy Z2V0IHR5cGUNCi9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYvLi4vLi4vLi4vY2RkbC9jb250 cmliL29wZW5zb2xhcmlzL2NvbW1vbi9jdGYvY3RmX2NyZWF0ZS5jOjY2OiB3YXJuaW5nOiBh c3NpZ25tZW50IGRpc2NhcmRzIHF1YWxpZmllcnMgZnJvbSBwb2ludGVyIHRhcmdldCB0eXBl DQovaG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVu c29sYXJpcy9jb21tb24vY3RmL2N0Zl9jcmVhdGUuYzogSW4gZnVuY3Rpb24gJ2N0Zl91cGRh dGUnOg0KL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8uLi9jZGRsL2NvbnRyaWIv b3BlbnNvbGFyaXMvY29tbW9uL2N0Zi9jdGZfY3JlYXRlLmM6MzY3OiB3YXJuaW5nOiBhc3Np Z25tZW50IGRpc2NhcmRzIHF1YWxpZmllcnMgZnJvbSBwb2ludGVyIHRhcmdldCB0eXBlDQpj YyAtTzIgLXBpcGUgLURDVEZfT0xEX1ZFUlNJT05TIC1JL2hvbWUvc3JjL2NkZGwvbGliL2xp YmN0Zi8uLi8uLi8uLi9zeXMvY2RkbC9jb21wYXQvb3BlbnNvbGFyaXMgIC1JL2hvbWUvc3Jj L2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8uLi9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcy9pbmNs dWRlICAtSS9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYvLi4vLi4vLi4vY2RkbC9jb250cmli L29wZW5zb2xhcmlzL2hlYWQgIC1JL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8u Li9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvY29tbW9uL2N0ZiAgLUkvaG9tZS9zcmMvY2Rk bC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9saWIvbGli Y3RmL2NvbW1vbiAgLUkvaG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL3N5cy9j ZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbiAtRE5FRURfU09MQVJJU19CT09M RUFOIC1ETkRFQlVHIC1zdGQ9Z251ODkgIC1Xbm8tdW5rbm93bi1wcmFnbWFzIC1JL3Vzci9v YmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvY2RkbC9s aWIvbGliY3RmLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9jb21tb24vY3Rm L2N0Zl9kZWNsLmMNCmNjIC1PMiAtcGlwZSAtRENURl9PTERfVkVSU0lPTlMgLUkvaG9tZS9z cmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL3N5cy9jZGRsL2NvbXBhdC9vcGVuc29sYXJp cyAgLUkvaG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwvY29tcGF0L29w ZW5zb2xhcmlzL2luY2x1ZGUgIC1JL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8u Li9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvaGVhZCAgLUkvaG9tZS9zcmMvY2RkbC9saWIv bGliY3RmLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9jb21tb24vY3RmICAt SS9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5z b2xhcmlzL2xpYi9saWJjdGYvY29tbW9uICAtSS9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYv Li4vLi4vLi4vc3lzL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uIC1ETkVF RF9TT0xBUklTX0JPT0xFQU4gLUROREVCVUcgLXN0ZD1nbnU4OSAgLVduby11bmtub3duLXBy YWdtYXMgLUkvdXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9o b21lL3NyYy9jZGRsL2xpYi9saWJjdGYvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xh cmlzL2NvbW1vbi9jdGYvY3RmX2Vycm9yLmMNCmNjIC1PMiAtcGlwZSAtRENURl9PTERfVkVS U0lPTlMgLUkvaG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL3N5cy9jZGRsL2Nv bXBhdC9vcGVuc29sYXJpcyAgLUkvaG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4u L2NkZGwvY29tcGF0L29wZW5zb2xhcmlzL2luY2x1ZGUgIC1JL2hvbWUvc3JjL2NkZGwvbGli L2xpYmN0Zi8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvaGVhZCAgLUkvaG9t ZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJp cy9jb21tb24vY3RmICAtSS9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYvLi4vLi4vLi4vY2Rk bC9jb250cmliL29wZW5zb2xhcmlzL2xpYi9saWJjdGYvY29tbW9uICAtSS9ob21lL3NyYy9j ZGRsL2xpYi9saWJjdGYvLi4vLi4vLi4vc3lzL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91 dHMvY29tbW9uIC1ETkVFRF9TT0xBUklTX0JPT0xFQU4gLUROREVCVUcgLXN0ZD1nbnU4OSAg LVduby11bmtub3duLXByYWdtYXMgLUkvdXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vz ci9pbmNsdWRlIC1jIC9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYvLi4vLi4vLi4vY2RkbC9j b250cmliL29wZW5zb2xhcmlzL2NvbW1vbi9jdGYvY3RmX2hhc2guYw0KY2MgLU8yIC1waXBl IC1EQ1RGX09MRF9WRVJTSU9OUyAtSS9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYvLi4vLi4v Li4vc3lzL2NkZGwvY29tcGF0L29wZW5zb2xhcmlzICAtSS9ob21lL3NyYy9jZGRsL2xpYi9s aWJjdGYvLi4vLi4vLi4vY2RkbC9jb21wYXQvb3BlbnNvbGFyaXMvaW5jbHVkZSAgLUkvaG9t ZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJp cy9oZWFkICAtSS9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYvLi4vLi4vLi4vY2RkbC9jb250 cmliL29wZW5zb2xhcmlzL2NvbW1vbi9jdGYgIC1JL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0 Zi8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvbGliL2xpYmN0Zi9jb21tb24g IC1JL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8uLi9zeXMvY2RkbC9jb250cmli L29wZW5zb2xhcmlzL3V0cy9jb21tb24gLURORUVEX1NPTEFSSVNfQk9PTEVBTiAtRE5ERUJV RyAtc3RkPWdudTg5ICAtV25vLXVua25vd24tcHJhZ21hcyAtSS91c3Ivb2JqL2hvbWUvc3Jj L3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8u Li8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvY29tbW9uL2N0Zi9jdGZfbGFiZWxz LmMNCmNjIC1PMiAtcGlwZSAtRENURl9PTERfVkVSU0lPTlMgLUkvaG9tZS9zcmMvY2RkbC9s aWIvbGliY3RmLy4uLy4uLy4uL3N5cy9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcyAgLUkvaG9t ZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwvY29tcGF0L29wZW5zb2xhcmlz L2luY2x1ZGUgIC1JL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8uLi9jZGRsL2Nv bnRyaWIvb3BlbnNvbGFyaXMvaGVhZCAgLUkvaG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4u Ly4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9jb21tb24vY3RmICAtSS9ob21lL3Ny Yy9jZGRsL2xpYi9saWJjdGYvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2xp Yi9saWJjdGYvY29tbW9uICAtSS9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYvLi4vLi4vLi4v c3lzL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uIC1ETkVFRF9TT0xBUklT X0JPT0xFQU4gLUROREVCVUcgLXN0ZD1nbnU4OSAgLVduby11bmtub3duLXByYWdtYXMgLUkv dXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9j ZGRsL2xpYi9saWJjdGYvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2xpYi9s aWJjdGYvY29tbW9uL2N0Zl9saWIuYw0KL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8u Li8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvbGliL2xpYmN0Zi9jb21tb24vY3RmX2xp Yi5jOiBJbiBmdW5jdGlvbiAnY3RmX2Zkb3Blbic6DQovaG9tZS9zcmMvY2RkbC9saWIvbGli Y3RmLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9saWIvbGliY3RmL2NvbW1v bi9jdGZfbGliLmM6MjU1OiB3YXJuaW5nOiBhc3NpZ25tZW50IGRpc2NhcmRzIHF1YWxpZmll cnMgZnJvbSBwb2ludGVyIHRhcmdldCB0eXBlDQpjYyAtTzIgLXBpcGUgLURDVEZfT0xEX1ZF UlNJT05TIC1JL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8uLi9zeXMvY2RkbC9j b21wYXQvb3BlbnNvbGFyaXMgIC1JL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8u Li9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcy9pbmNsdWRlICAtSS9ob21lL3NyYy9jZGRsL2xp Yi9saWJjdGYvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2hlYWQgIC1JL2hv bWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFy aXMvY29tbW9uL2N0ZiAgLUkvaG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL2Nk ZGwvY29udHJpYi9vcGVuc29sYXJpcy9saWIvbGliY3RmL2NvbW1vbiAgLUkvaG9tZS9zcmMv Y2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL3N5cy9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMv dXRzL2NvbW1vbiAtRE5FRURfU09MQVJJU19CT09MRUFOIC1ETkRFQlVHIC1zdGQ9Z251ODkg IC1Xbm8tdW5rbm93bi1wcmFnbWFzIC1JL3Vzci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91 c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwv Y29udHJpYi9vcGVuc29sYXJpcy9jb21tb24vY3RmL2N0Zl9sb29rdXAuYw0KY2MgLU8yIC1w aXBlIC1EQ1RGX09MRF9WRVJTSU9OUyAtSS9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYvLi4v Li4vLi4vc3lzL2NkZGwvY29tcGF0L29wZW5zb2xhcmlzICAtSS9ob21lL3NyYy9jZGRsL2xp Yi9saWJjdGYvLi4vLi4vLi4vY2RkbC9jb21wYXQvb3BlbnNvbGFyaXMvaW5jbHVkZSAgLUkv aG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29s YXJpcy9oZWFkICAtSS9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYvLi4vLi4vLi4vY2RkbC9j b250cmliL29wZW5zb2xhcmlzL2NvbW1vbi9jdGYgIC1JL2hvbWUvc3JjL2NkZGwvbGliL2xp YmN0Zi8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvbGliL2xpYmN0Zi9jb21t b24gIC1JL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8uLi9zeXMvY2RkbC9jb250 cmliL29wZW5zb2xhcmlzL3V0cy9jb21tb24gLURORUVEX1NPTEFSSVNfQk9PTEVBTiAtRE5E RUJVRyAtc3RkPWdudTg5ICAtV25vLXVua25vd24tcHJhZ21hcyAtSS91c3Ivb2JqL2hvbWUv c3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0 Zi8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvY29tbW9uL2N0Zi9jdGZfb3Bl bi5jDQovaG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwvY29udHJpYi9v cGVuc29sYXJpcy9jb21tb24vY3RmL2N0Zl9vcGVuLmM6IEluIGZ1bmN0aW9uICdjdGZfYnVm b3Blbic6DQovaG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwvY29udHJp Yi9vcGVuc29sYXJpcy9jb21tb24vY3RmL2N0Zl9vcGVuLmM6Njk3OiB3YXJuaW5nOiBhc3Np Z25tZW50IGRpc2NhcmRzIHF1YWxpZmllcnMgZnJvbSBwb2ludGVyIHRhcmdldCB0eXBlDQov aG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29s YXJpcy9jb21tb24vY3RmL2N0Zl9vcGVuLmM6Njk5OiB3YXJuaW5nOiBhc3NpZ25tZW50IGRp c2NhcmRzIHF1YWxpZmllcnMgZnJvbSBwb2ludGVyIHRhcmdldCB0eXBlDQovaG9tZS9zcmMv Y2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9jb21t b24vY3RmL2N0Zl9vcGVuLmM6NzAxOiB3YXJuaW5nOiBhc3NpZ25tZW50IGRpc2NhcmRzIHF1 YWxpZmllcnMgZnJvbSBwb2ludGVyIHRhcmdldCB0eXBlDQpjYyAtTzIgLXBpcGUgLURDVEZf T0xEX1ZFUlNJT05TIC1JL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8uLi9zeXMv Y2RkbC9jb21wYXQvb3BlbnNvbGFyaXMgIC1JL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8u Li8uLi8uLi9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcy9pbmNsdWRlICAtSS9ob21lL3NyYy9j ZGRsL2xpYi9saWJjdGYvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2hlYWQg IC1JL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3Bl bnNvbGFyaXMvY29tbW9uL2N0ZiAgLUkvaG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4u Ly4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9saWIvbGliY3RmL2NvbW1vbiAgLUkvaG9t ZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL3N5cy9jZGRsL2NvbnRyaWIvb3BlbnNv bGFyaXMvdXRzL2NvbW1vbiAtRE5FRURfU09MQVJJU19CT09MRUFOIC1ETkRFQlVHIC1zdGQ9 Z251ODkgIC1Xbm8tdW5rbm93bi1wcmFnbWFzIC1JL3Vzci9vYmovaG9tZS9zcmMvdG1wL2xl Z2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4u L2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9saWIvbGliY3RmL2NvbW1vbi9jdGZfc3Vici5j DQpjYyAtTzIgLXBpcGUgLURDVEZfT0xEX1ZFUlNJT05TIC1JL2hvbWUvc3JjL2NkZGwvbGli L2xpYmN0Zi8uLi8uLi8uLi9zeXMvY2RkbC9jb21wYXQvb3BlbnNvbGFyaXMgIC1JL2hvbWUv c3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8uLi9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcy9p bmNsdWRlICAtSS9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYvLi4vLi4vLi4vY2RkbC9jb250 cmliL29wZW5zb2xhcmlzL2hlYWQgIC1JL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8u Li8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvY29tbW9uL2N0ZiAgLUkvaG9tZS9zcmMv Y2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9saWIv bGliY3RmL2NvbW1vbiAgLUkvaG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL3N5 cy9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbiAtRE5FRURfU09MQVJJU19C T09MRUFOIC1ETkRFQlVHIC1zdGQ9Z251ODkgIC1Xbm8tdW5rbm93bi1wcmFnbWFzIC1JL3Vz ci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvY2Rk bC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9jb21tb24v Y3RmL2N0Zl90eXBlcy5jDQpjYyAtTzIgLXBpcGUgLURDVEZfT0xEX1ZFUlNJT05TIC1JL2hv bWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8uLi9zeXMvY2RkbC9jb21wYXQvb3BlbnNv bGFyaXMgIC1JL2hvbWUvc3JjL2NkZGwvbGliL2xpYmN0Zi8uLi8uLi8uLi9jZGRsL2NvbXBh dC9vcGVuc29sYXJpcy9pbmNsdWRlICAtSS9ob21lL3NyYy9jZGRsL2xpYi9saWJjdGYvLi4v Li4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2hlYWQgIC1JL2hvbWUvc3JjL2NkZGwv bGliL2xpYmN0Zi8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvY29tbW9uL2N0 ZiAgLUkvaG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwvY29udHJpYi9v cGVuc29sYXJpcy9saWIvbGliY3RmL2NvbW1vbiAgLUkvaG9tZS9zcmMvY2RkbC9saWIvbGli Y3RmLy4uLy4uLy4uL3N5cy9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbiAt RE5FRURfU09MQVJJU19CT09MRUFOIC1ETkRFQlVHIC1zdGQ9Z251ODkgIC1Xbm8tdW5rbm93 bi1wcmFnbWFzIC1JL3Vzci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAt YyAvaG9tZS9zcmMvY2RkbC9saWIvbGliY3RmLy4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVu c29sYXJpcy9jb21tb24vY3RmL2N0Zl91dGlsLmMNCmJ1aWxkaW5nIHN0YXRpYyBjdGYgbGli cmFyeQ0KcmFubGliIGxpYmN0Zi5hDQpzaCAvaG9tZS9zcmMvdG9vbHMvaW5zdGFsbC5zaCAt QyAtbyByb290IC1nIHdoZWVsIC1tIDQ0NCAgIGxpYmN0Zi5hIC91c3Ivb2JqL2hvbWUvc3Jj L3RtcC9sZWdhY3kvdXNyL2xpYg0KPT09PiBsaWIvbGliZWxmIChvYmosZGVwZW5kLGFsbCxp bnN0YWxsKQ0KL3Vzci9vYmovaG9tZS9zcmMvdG1wL2hvbWUvc3JjL2xpYi9saWJlbGYgY3Jl YXRlZCBmb3IgL2hvbWUvc3JjL2xpYi9saWJlbGYNCm00IC1EIFNSQ0RJUj0vaG9tZS9zcmMv bGliL2xpYmVsZiAvaG9tZS9zcmMvbGliL2xpYmVsZi9saWJlbGZfZnNpemUubTQgPiBsaWJl bGZfZnNpemUuYw0KbTQgLUQgU1JDRElSPS9ob21lL3NyYy9saWIvbGliZWxmIC9ob21lL3Ny Yy9saWIvbGliZWxmL2xpYmVsZl9tc2l6ZS5tNCA+IGxpYmVsZl9tc2l6ZS5jDQptNCAtRCBT UkNESVI9L2hvbWUvc3JjL2xpYi9saWJlbGYgL2hvbWUvc3JjL2xpYi9saWJlbGYvbGliZWxm X2NvbnZlcnQubTQgPiBsaWJlbGZfY29udmVydC5jDQpybSAtZiAuZGVwZW5kDQpta2RlcCAt ZiAuZGVwZW5kIC1hICAgIC1JLiAtSS9ob21lL3NyYy9saWIvbGliZWxmIC1ETElCRUxGX1RF U1RfSE9PS1MgLUROREVCVUcgLUkvdXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9p bmNsdWRlIC9ob21lL3NyYy9saWIvbGliZWxmL2VsZl9iZWdpbi5jIC9ob21lL3NyYy9saWIv bGliZWxmL2VsZl9jbnRsLmMgL2hvbWUvc3JjL2xpYi9saWJlbGYvZWxmX2VuZC5jIC9ob21l L3NyYy9saWIvbGliZWxmL2VsZl9lcnJtc2cuYyAvaG9tZS9zcmMvbGliL2xpYmVsZi9lbGZf ZXJybm8uYyAvaG9tZS9zcmMvbGliL2xpYmVsZi9lbGZfZGF0YS5jIC9ob21lL3NyYy9saWIv bGliZWxmL2VsZl9maWxsLmMgL2hvbWUvc3JjL2xpYi9saWJlbGYvZWxmX2ZsYWcuYyAvaG9t ZS9zcmMvbGliL2xpYmVsZi9lbGZfZ2V0YXJoZHIuYyAvaG9tZS9zcmMvbGliL2xpYmVsZi9l bGZfZ2V0YXJzeW0uYyAvaG9tZS9zcmMvbGliL2xpYmVsZi9lbGZfZ2V0YmFzZS5jIC9ob21l L3NyYy9saWIvbGliZWxmL2VsZl9nZXRpZGVudC5jIC9ob21lL3NyYy9saWIvbGliZWxmL2Vs Zl9oYXNoLmMgL2hvbWUvc3JjL2xpYi9saWJlbGYvZWxmX2tpbmQuYyAvaG9tZS9zcmMvbGli L2xpYmVsZi9lbGZfbWVtb3J5LmMgL2hvbWUvc3JjL2xpYi9saWJlbGYvZWxmX25leHQuYyAv aG9tZS9zcmMvbGliL2xpYmVsZi9lbGZfcmFuZC5jIC9ob21lL3NyYy9saWIvbGliZWxmL2Vs Zl9yYXdmaWxlLmMgL2hvbWUvc3JjL2xpYi9saWJlbGYvZWxmX3BobnVtLmMgL2hvbWUvc3Jj L2xpYi9saWJlbGYvZWxmX3NobnVtLmMgL2hvbWUvc3JjL2xpYi9saWJlbGYvZWxmX3Noc3Ry bmR4LmMgL2hvbWUvc3JjL2xpYi9saWJlbGYvZWxmX3Njbi5jIC9ob21lL3NyYy9saWIvbGli ZWxmL2VsZl9zdHJwdHIuYyAvaG9tZS9zcmMvbGliL2xpYmVsZi9lbGZfdXBkYXRlLmMgL2hv bWUvc3JjL2xpYi9saWJlbGYvZWxmX3ZlcnNpb24uYyAvaG9tZS9zcmMvbGliL2xpYmVsZi9n ZWxmX2NhcC5jIC9ob21lL3NyYy9saWIvbGliZWxmL2dlbGZfY2hlY2tzdW0uYyAvaG9tZS9z cmMvbGliL2xpYmVsZi9nZWxmX2R5bi5jIC9ob21lL3NyYy9saWIvbGliZWxmL2dlbGZfZWhk ci5jIC9ob21lL3NyYy9saWIvbGliZWxmL2dlbGZfZ2V0Y2xhc3MuYyAvaG9tZS9zcmMvbGli L2xpYmVsZi9nZWxmX2ZzaXplLmMgL2hvbWUvc3JjL2xpYi9saWJlbGYvZ2VsZl9tb3ZlLmMg L2hvbWUvc3JjL2xpYi9saWJlbGYvZ2VsZl9waGRyLmMgL2hvbWUvc3JjL2xpYi9saWJlbGYv Z2VsZl9yZWwuYyAvaG9tZS9zcmMvbGliL2xpYmVsZi9nZWxmX3JlbGEuYyAvaG9tZS9zcmMv bGliL2xpYmVsZi9nZWxmX3NoZHIuYyAvaG9tZS9zcmMvbGliL2xpYmVsZi9nZWxmX3N5bS5j IC9ob21lL3NyYy9saWIvbGliZWxmL2dlbGZfc3ltaW5mby5jIC9ob21lL3NyYy9saWIvbGli ZWxmL2dlbGZfc3ltc2huZHguYyAvaG9tZS9zcmMvbGliL2xpYmVsZi9nZWxmX3hsYXRlLmMg L2hvbWUvc3JjL2xpYi9saWJlbGYvbGliZWxmLmMgL2hvbWUvc3JjL2xpYi9saWJlbGYvbGli ZWxmX2FsaWduLmMgL2hvbWUvc3JjL2xpYi9saWJlbGYvbGliZWxmX2FsbG9jYXRlLmMgL2hv bWUvc3JjL2xpYi9saWJlbGYvbGliZWxmX2FyLmMgL2hvbWUvc3JjL2xpYi9saWJlbGYvbGli ZWxmX2NoZWNrc3VtLmMgL2hvbWUvc3JjL2xpYi9saWJlbGYvbGliZWxmX2RhdGEuYyAvaG9t ZS9zcmMvbGliL2xpYmVsZi9saWJlbGZfZWhkci5jIC9ob21lL3NyYy9saWIvbGliZWxmL2xp YmVsZl9leHRlbmRlZC5jIC9ob21lL3NyYy9saWIvbGliZWxmL2xpYmVsZl9waGRyLmMgL2hv bWUvc3JjL2xpYi9saWJlbGYvbGliZWxmX3NoZHIuYyAvaG9tZS9zcmMvbGliL2xpYmVsZi9s aWJlbGZfeGxhdGUuYyBsaWJlbGZfZnNpemUuYyBsaWJlbGZfbXNpemUuYyBsaWJlbGZfY29u dmVydC5jDQpjYyAtTzIgLXBpcGUgLUkuIC1JL2hvbWUvc3JjL2xpYi9saWJlbGYgLURMSUJF TEZfVEVTVF9IT09LUyAtRE5ERUJVRyAtc3RkPWdudTk5ICAgLUkvdXNyL29iai9ob21lL3Ny Yy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9saWIvbGliZWxmL2VsZl9i ZWdpbi5jDQpjYyAtTzIgLXBpcGUgLUkuIC1JL2hvbWUvc3JjL2xpYi9saWJlbGYgLURMSUJF TEZfVEVTVF9IT09LUyAtRE5ERUJVRyAtc3RkPWdudTk5ICAgLUkvdXNyL29iai9ob21lL3Ny Yy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9saWIvbGliZWxmL2VsZl9j bnRsLmMNCmNjIC1PMiAtcGlwZSAtSS4gLUkvaG9tZS9zcmMvbGliL2xpYmVsZiAtRExJQkVM Rl9URVNUX0hPT0tTIC1ETkRFQlVHIC1zdGQ9Z251OTkgICAtSS91c3Ivb2JqL2hvbWUvc3Jj L3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUvc3JjL2xpYi9saWJlbGYvZWxmX2Vu ZC5jDQpjYyAtTzIgLXBpcGUgLUkuIC1JL2hvbWUvc3JjL2xpYi9saWJlbGYgLURMSUJFTEZf VEVTVF9IT09LUyAtRE5ERUJVRyAtc3RkPWdudTk5ICAgLUkvdXNyL29iai9ob21lL3NyYy90 bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9saWIvbGliZWxmL2VsZl9lcnJt c2cuYw0KY2MgLU8yIC1waXBlIC1JLiAtSS9ob21lL3NyYy9saWIvbGliZWxmIC1ETElCRUxG X1RFU1RfSE9PS1MgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1JL3Vzci9vYmovaG9tZS9zcmMv dG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvbGliL2xpYmVsZi9lbGZfZXJy bm8uYw0KY2MgLU8yIC1waXBlIC1JLiAtSS9ob21lL3NyYy9saWIvbGliZWxmIC1ETElCRUxG X1RFU1RfSE9PS1MgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1JL3Vzci9vYmovaG9tZS9zcmMv dG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvbGliL2xpYmVsZi9lbGZfZGF0 YS5jDQpjYyAtTzIgLXBpcGUgLUkuIC1JL2hvbWUvc3JjL2xpYi9saWJlbGYgLURMSUJFTEZf VEVTVF9IT09LUyAtRE5ERUJVRyAtc3RkPWdudTk5ICAgLUkvdXNyL29iai9ob21lL3NyYy90 bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9saWIvbGliZWxmL2VsZl9maWxs LmMNCmNjIC1PMiAtcGlwZSAtSS4gLUkvaG9tZS9zcmMvbGliL2xpYmVsZiAtRExJQkVMRl9U RVNUX0hPT0tTIC1ETkRFQlVHIC1zdGQ9Z251OTkgICAtSS91c3Ivb2JqL2hvbWUvc3JjL3Rt cC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUvc3JjL2xpYi9saWJlbGYvZWxmX2ZsYWcu Yw0KY2MgLU8yIC1waXBlIC1JLiAtSS9ob21lL3NyYy9saWIvbGliZWxmIC1ETElCRUxGX1RF U1RfSE9PS1MgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1JL3Vzci9vYmovaG9tZS9zcmMvdG1w L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvbGliL2xpYmVsZi9lbGZfZ2V0YXJo ZHIuYw0KY2MgLU8yIC1waXBlIC1JLiAtSS9ob21lL3NyYy9saWIvbGliZWxmIC1ETElCRUxG X1RFU1RfSE9PS1MgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1JL3Vzci9vYmovaG9tZS9zcmMv dG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvbGliL2xpYmVsZi9lbGZfZ2V0 YXJzeW0uYw0KY2MgLU8yIC1waXBlIC1JLiAtSS9ob21lL3NyYy9saWIvbGliZWxmIC1ETElC RUxGX1RFU1RfSE9PS1MgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1JL3Vzci9vYmovaG9tZS9z cmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvbGliL2xpYmVsZi9lbGZf Z2V0YmFzZS5jDQpjYyAtTzIgLXBpcGUgLUkuIC1JL2hvbWUvc3JjL2xpYi9saWJlbGYgLURM SUJFTEZfVEVTVF9IT09LUyAtRE5ERUJVRyAtc3RkPWdudTk5ICAgLUkvdXNyL29iai9ob21l L3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9saWIvbGliZWxmL2Vs Zl9nZXRpZGVudC5jDQpjYyAtTzIgLXBpcGUgLUkuIC1JL2hvbWUvc3JjL2xpYi9saWJlbGYg LURMSUJFTEZfVEVTVF9IT09LUyAtRE5ERUJVRyAtc3RkPWdudTk5ICAgLUkvdXNyL29iai9o b21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9saWIvbGliZWxm L2VsZl9oYXNoLmMNCmNjIC1PMiAtcGlwZSAtSS4gLUkvaG9tZS9zcmMvbGliL2xpYmVsZiAt RExJQkVMRl9URVNUX0hPT0tTIC1ETkRFQlVHIC1zdGQ9Z251OTkgICAtSS91c3Ivb2JqL2hv bWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUvc3JjL2xpYi9saWJlbGYv ZWxmX2tpbmQuYw0KY2MgLU8yIC1waXBlIC1JLiAtSS9ob21lL3NyYy9saWIvbGliZWxmIC1E TElCRUxGX1RFU1RfSE9PS1MgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1JL3Vzci9vYmovaG9t ZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvbGliL2xpYmVsZi9l bGZfbWVtb3J5LmMNCmNjIC1PMiAtcGlwZSAtSS4gLUkvaG9tZS9zcmMvbGliL2xpYmVsZiAt RExJQkVMRl9URVNUX0hPT0tTIC1ETkRFQlVHIC1zdGQ9Z251OTkgICAtSS91c3Ivb2JqL2hv bWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUvc3JjL2xpYi9saWJlbGYv ZWxmX25leHQuYw0KY2MgLU8yIC1waXBlIC1JLiAtSS9ob21lL3NyYy9saWIvbGliZWxmIC1E TElCRUxGX1RFU1RfSE9PS1MgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1JL3Vzci9vYmovaG9t ZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvbGliL2xpYmVsZi9l bGZfcmFuZC5jDQpjYyAtTzIgLXBpcGUgLUkuIC1JL2hvbWUvc3JjL2xpYi9saWJlbGYgLURM SUJFTEZfVEVTVF9IT09LUyAtRE5ERUJVRyAtc3RkPWdudTk5ICAgLUkvdXNyL29iai9ob21l L3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9saWIvbGliZWxmL2Vs Zl9yYXdmaWxlLmMNCmNjIC1PMiAtcGlwZSAtSS4gLUkvaG9tZS9zcmMvbGliL2xpYmVsZiAt RExJQkVMRl9URVNUX0hPT0tTIC1ETkRFQlVHIC1zdGQ9Z251OTkgICAtSS91c3Ivb2JqL2hv bWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUvc3JjL2xpYi9saWJlbGYv ZWxmX3BobnVtLmMNCmNjIC1PMiAtcGlwZSAtSS4gLUkvaG9tZS9zcmMvbGliL2xpYmVsZiAt RExJQkVMRl9URVNUX0hPT0tTIC1ETkRFQlVHIC1zdGQ9Z251OTkgICAtSS91c3Ivb2JqL2hv bWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUvc3JjL2xpYi9saWJlbGYv ZWxmX3NobnVtLmMNCmNjIC1PMiAtcGlwZSAtSS4gLUkvaG9tZS9zcmMvbGliL2xpYmVsZiAt RExJQkVMRl9URVNUX0hPT0tTIC1ETkRFQlVHIC1zdGQ9Z251OTkgICAtSS91c3Ivb2JqL2hv bWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUvc3JjL2xpYi9saWJlbGYv ZWxmX3Noc3RybmR4LmMNCmNjIC1PMiAtcGlwZSAtSS4gLUkvaG9tZS9zcmMvbGliL2xpYmVs ZiAtRExJQkVMRl9URVNUX0hPT0tTIC1ETkRFQlVHIC1zdGQ9Z251OTkgICAtSS91c3Ivb2Jq L2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUvc3JjL2xpYi9saWJl bGYvZWxmX3Njbi5jDQpjYyAtTzIgLXBpcGUgLUkuIC1JL2hvbWUvc3JjL2xpYi9saWJlbGYg LURMSUJFTEZfVEVTVF9IT09LUyAtRE5ERUJVRyAtc3RkPWdudTk5ICAgLUkvdXNyL29iai9o b21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9saWIvbGliZWxm L2VsZl9zdHJwdHIuYw0KY2MgLU8yIC1waXBlIC1JLiAtSS9ob21lL3NyYy9saWIvbGliZWxm IC1ETElCRUxGX1RFU1RfSE9PS1MgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1JL3Vzci9vYmov aG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvbGliL2xpYmVs Zi9lbGZfdXBkYXRlLmMNCmNjIC1PMiAtcGlwZSAtSS4gLUkvaG9tZS9zcmMvbGliL2xpYmVs ZiAtRExJQkVMRl9URVNUX0hPT0tTIC1ETkRFQlVHIC1zdGQ9Z251OTkgICAtSS91c3Ivb2Jq L2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUvc3JjL2xpYi9saWJl bGYvZWxmX3ZlcnNpb24uYw0KY2MgLU8yIC1waXBlIC1JLiAtSS9ob21lL3NyYy9saWIvbGli ZWxmIC1ETElCRUxGX1RFU1RfSE9PS1MgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1JL3Vzci9v YmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvbGliL2xp YmVsZi9nZWxmX2NhcC5jDQpjYyAtTzIgLXBpcGUgLUkuIC1JL2hvbWUvc3JjL2xpYi9saWJl bGYgLURMSUJFTEZfVEVTVF9IT09LUyAtRE5ERUJVRyAtc3RkPWdudTk5ICAgLUkvdXNyL29i ai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9saWIvbGli ZWxmL2dlbGZfY2hlY2tzdW0uYw0KY2MgLU8yIC1waXBlIC1JLiAtSS9ob21lL3NyYy9saWIv bGliZWxmIC1ETElCRUxGX1RFU1RfSE9PS1MgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1JL3Vz ci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvbGli L2xpYmVsZi9nZWxmX2R5bi5jDQpjYyAtTzIgLXBpcGUgLUkuIC1JL2hvbWUvc3JjL2xpYi9s aWJlbGYgLURMSUJFTEZfVEVTVF9IT09LUyAtRE5ERUJVRyAtc3RkPWdudTk5ICAgLUkvdXNy L29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9saWIv bGliZWxmL2dlbGZfZWhkci5jDQpjYyAtTzIgLXBpcGUgLUkuIC1JL2hvbWUvc3JjL2xpYi9s aWJlbGYgLURMSUJFTEZfVEVTVF9IT09LUyAtRE5ERUJVRyAtc3RkPWdudTk5ICAgLUkvdXNy L29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9saWIv bGliZWxmL2dlbGZfZ2V0Y2xhc3MuYw0KY2MgLU8yIC1waXBlIC1JLiAtSS9ob21lL3NyYy9s aWIvbGliZWxmIC1ETElCRUxGX1RFU1RfSE9PS1MgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1J L3Vzci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMv bGliL2xpYmVsZi9nZWxmX2ZzaXplLmMNCmNjIC1PMiAtcGlwZSAtSS4gLUkvaG9tZS9zcmMv bGliL2xpYmVsZiAtRExJQkVMRl9URVNUX0hPT0tTIC1ETkRFQlVHIC1zdGQ9Z251OTkgICAt SS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUvc3Jj L2xpYi9saWJlbGYvZ2VsZl9tb3ZlLmMNCmNjIC1PMiAtcGlwZSAtSS4gLUkvaG9tZS9zcmMv bGliL2xpYmVsZiAtRExJQkVMRl9URVNUX0hPT0tTIC1ETkRFQlVHIC1zdGQ9Z251OTkgICAt SS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUvc3Jj L2xpYi9saWJlbGYvZ2VsZl9waGRyLmMNCmNjIC1PMiAtcGlwZSAtSS4gLUkvaG9tZS9zcmMv bGliL2xpYmVsZiAtRExJQkVMRl9URVNUX0hPT0tTIC1ETkRFQlVHIC1zdGQ9Z251OTkgICAt SS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUvc3Jj L2xpYi9saWJlbGYvZ2VsZl9yZWwuYw0KY2MgLU8yIC1waXBlIC1JLiAtSS9ob21lL3NyYy9s aWIvbGliZWxmIC1ETElCRUxGX1RFU1RfSE9PS1MgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1J L3Vzci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMv bGliL2xpYmVsZi9nZWxmX3JlbGEuYw0KY2MgLU8yIC1waXBlIC1JLiAtSS9ob21lL3NyYy9s aWIvbGliZWxmIC1ETElCRUxGX1RFU1RfSE9PS1MgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1J L3Vzci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMv bGliL2xpYmVsZi9nZWxmX3NoZHIuYw0KY2MgLU8yIC1waXBlIC1JLiAtSS9ob21lL3NyYy9s aWIvbGliZWxmIC1ETElCRUxGX1RFU1RfSE9PS1MgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1J L3Vzci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMv bGliL2xpYmVsZi9nZWxmX3N5bS5jDQpjYyAtTzIgLXBpcGUgLUkuIC1JL2hvbWUvc3JjL2xp Yi9saWJlbGYgLURMSUJFTEZfVEVTVF9IT09LUyAtRE5ERUJVRyAtc3RkPWdudTk5ICAgLUkv dXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9s aWIvbGliZWxmL2dlbGZfc3ltaW5mby5jDQpjYyAtTzIgLXBpcGUgLUkuIC1JL2hvbWUvc3Jj L2xpYi9saWJlbGYgLURMSUJFTEZfVEVTVF9IT09LUyAtRE5ERUJVRyAtc3RkPWdudTk5ICAg LUkvdXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3Ny Yy9saWIvbGliZWxmL2dlbGZfc3ltc2huZHguYw0KY2MgLU8yIC1waXBlIC1JLiAtSS9ob21l L3NyYy9saWIvbGliZWxmIC1ETElCRUxGX1RFU1RfSE9PS1MgLUROREVCVUcgLXN0ZD1nbnU5 OSAgIC1JL3Vzci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9t ZS9zcmMvbGliL2xpYmVsZi9nZWxmX3hsYXRlLmMNCmNjIC1PMiAtcGlwZSAtSS4gLUkvaG9t ZS9zcmMvbGliL2xpYmVsZiAtRExJQkVMRl9URVNUX0hPT0tTIC1ETkRFQlVHIC1zdGQ9Z251 OTkgICAtSS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hv bWUvc3JjL2xpYi9saWJlbGYvbGliZWxmLmMNCmNjIC1PMiAtcGlwZSAtSS4gLUkvaG9tZS9z cmMvbGliL2xpYmVsZiAtRExJQkVMRl9URVNUX0hPT0tTIC1ETkRFQlVHIC1zdGQ9Z251OTkg ICAtSS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUv c3JjL2xpYi9saWJlbGYvbGliZWxmX2FsaWduLmMNCmNjIC1PMiAtcGlwZSAtSS4gLUkvaG9t ZS9zcmMvbGliL2xpYmVsZiAtRExJQkVMRl9URVNUX0hPT0tTIC1ETkRFQlVHIC1zdGQ9Z251 OTkgICAtSS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hv bWUvc3JjL2xpYi9saWJlbGYvbGliZWxmX2FsbG9jYXRlLmMNCmNjIC1PMiAtcGlwZSAtSS4g LUkvaG9tZS9zcmMvbGliL2xpYmVsZiAtRExJQkVMRl9URVNUX0hPT0tTIC1ETkRFQlVHIC1z dGQ9Z251OTkgICAtSS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUg LWMgL2hvbWUvc3JjL2xpYi9saWJlbGYvbGliZWxmX2FyLmMNCmNjIC1PMiAtcGlwZSAtSS4g LUkvaG9tZS9zcmMvbGliL2xpYmVsZiAtRExJQkVMRl9URVNUX0hPT0tTIC1ETkRFQlVHIC1z dGQ9Z251OTkgICAtSS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUg LWMgL2hvbWUvc3JjL2xpYi9saWJlbGYvbGliZWxmX2NoZWNrc3VtLmMNCmNjIC1PMiAtcGlw ZSAtSS4gLUkvaG9tZS9zcmMvbGliL2xpYmVsZiAtRExJQkVMRl9URVNUX0hPT0tTIC1ETkRF QlVHIC1zdGQ9Z251OTkgICAtSS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2lu Y2x1ZGUgLWMgL2hvbWUvc3JjL2xpYi9saWJlbGYvbGliZWxmX2RhdGEuYw0KY2MgLU8yIC1w aXBlIC1JLiAtSS9ob21lL3NyYy9saWIvbGliZWxmIC1ETElCRUxGX1RFU1RfSE9PS1MgLURO REVCVUcgLXN0ZD1nbnU5OSAgIC1JL3Vzci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3Iv aW5jbHVkZSAtYyAvaG9tZS9zcmMvbGliL2xpYmVsZi9saWJlbGZfZWhkci5jDQpjYyAtTzIg LXBpcGUgLUkuIC1JL2hvbWUvc3JjL2xpYi9saWJlbGYgLURMSUJFTEZfVEVTVF9IT09LUyAt RE5ERUJVRyAtc3RkPWdudTk5ICAgLUkvdXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vz ci9pbmNsdWRlIC1jIC9ob21lL3NyYy9saWIvbGliZWxmL2xpYmVsZl9leHRlbmRlZC5jDQpj YyAtTzIgLXBpcGUgLUkuIC1JL2hvbWUvc3JjL2xpYi9saWJlbGYgLURMSUJFTEZfVEVTVF9I T09LUyAtRE5ERUJVRyAtc3RkPWdudTk5ICAgLUkvdXNyL29iai9ob21lL3NyYy90bXAvbGVn YWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9saWIvbGliZWxmL2xpYmVsZl9waGRyLmMN CmNjIC1PMiAtcGlwZSAtSS4gLUkvaG9tZS9zcmMvbGliL2xpYmVsZiAtRExJQkVMRl9URVNU X0hPT0tTIC1ETkRFQlVHIC1zdGQ9Z251OTkgICAtSS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9s ZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUvc3JjL2xpYi9saWJlbGYvbGliZWxmX3NoZHIu Yw0KY2MgLU8yIC1waXBlIC1JLiAtSS9ob21lL3NyYy9saWIvbGliZWxmIC1ETElCRUxGX1RF U1RfSE9PS1MgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1JL3Vzci9vYmovaG9tZS9zcmMvdG1w L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvbGliL2xpYmVsZi9saWJlbGZfeGxh dGUuYw0KY2MgLU8yIC1waXBlIC1JLiAtSS9ob21lL3NyYy9saWIvbGliZWxmIC1ETElCRUxG X1RFU1RfSE9PS1MgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1JL3Vzci9vYmovaG9tZS9zcmMv dG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyBsaWJlbGZfZnNpemUuYw0KY2MgLU8yIC1waXBl IC1JLiAtSS9ob21lL3NyYy9saWIvbGliZWxmIC1ETElCRUxGX1RFU1RfSE9PS1MgLUROREVC VUcgLXN0ZD1nbnU5OSAgIC1JL3Vzci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5j bHVkZSAtYyBsaWJlbGZfbXNpemUuYw0KY2MgLU8yIC1waXBlIC1JLiAtSS9ob21lL3NyYy9s aWIvbGliZWxmIC1ETElCRUxGX1RFU1RfSE9PS1MgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1J L3Vzci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyBsaWJlbGZfY29u dmVydC5jDQpidWlsZGluZyBzdGF0aWMgZWxmIGxpYnJhcnkNCnJhbmxpYiBsaWJlbGYuYQ0K c2ggL2hvbWUvc3JjL3Rvb2xzL2luc3RhbGwuc2ggLUMgLW8gcm9vdCAtZyB3aGVlbCAtbSA0 NDQgICBsaWJlbGYuYSAvdXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9saWINCnNo IC9ob21lL3NyYy90b29scy9pbnN0YWxsLnNoIC1DIC1vIHJvb3QgLWcgd2hlZWwgLW0gNDQ0 ICAvaG9tZS9zcmMvbGliL2xpYmVsZi9saWJlbGYuaCAvaG9tZS9zcmMvbGliL2xpYmVsZi9n ZWxmLmggL3Vzci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZQ0KPT09PiBs aWIvbGliZHdhcmYgKG9iaixkZXBlbmQsYWxsLGluc3RhbGwpDQovdXNyL29iai9ob21lL3Ny Yy90bXAvaG9tZS9zcmMvbGliL2xpYmR3YXJmIGNyZWF0ZWQgZm9yIC9ob21lL3NyYy9saWIv bGliZHdhcmYNCnJtIC1mIC5kZXBlbmQNCm1rZGVwIC1mIC5kZXBlbmQgLWEgICAgLUkvaG9t ZS9zcmMvbGliL2xpYmR3YXJmIC1ETkRFQlVHIC1JL3Vzci9vYmovaG9tZS9zcmMvdG1wL2xl Z2FjeS91c3IvaW5jbHVkZSAvaG9tZS9zcmMvbGliL2xpYmR3YXJmL2R3YXJmX2FiYnJldi5j IC9ob21lL3NyYy9saWIvbGliZHdhcmYvZHdhcmZfYXR0ci5jIC9ob21lL3NyYy9saWIvbGli ZHdhcmYvZHdhcmZfYXR0cnZhbC5jIC9ob21lL3NyYy9saWIvbGliZHdhcmYvZHdhcmZfY3Uu YyAvaG9tZS9zcmMvbGliL2xpYmR3YXJmL2R3YXJmX2RlYWxsb2MuYyAvaG9tZS9zcmMvbGli L2xpYmR3YXJmL2R3YXJmX2RpZS5jIC9ob21lL3NyYy9saWIvbGliZHdhcmYvZHdhcmZfZHVt cC5jIC9ob21lL3NyYy9saWIvbGliZHdhcmYvZHdhcmZfZXJybXNnLmMgL2hvbWUvc3JjL2xp Yi9saWJkd2FyZi9kd2FyZl9lcnJuby5jIC9ob21lL3NyYy9saWIvbGliZHdhcmYvZHdhcmZf ZmluaXNoLmMgL2hvbWUvc3JjL2xpYi9saWJkd2FyZi9kd2FyZl9mb3JtLmMgL2hvbWUvc3Jj L2xpYi9saWJkd2FyZi9kd2FyZl9pbml0LmMgL2hvbWUvc3JjL2xpYi9saWJkd2FyZi9kd2Fy Zl9sb2MuYw0KY2MgLU8yIC1waXBlIC1JL2hvbWUvc3JjL2xpYi9saWJkd2FyZiAtRE5ERUJV RyAtc3RkPWdudTk5ICAgLUkvdXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNs dWRlIC1jIC9ob21lL3NyYy9saWIvbGliZHdhcmYvZHdhcmZfYWJicmV2LmMNCmNjIC1PMiAt cGlwZSAtSS9ob21lL3NyYy9saWIvbGliZHdhcmYgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1J L3Vzci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMv bGliL2xpYmR3YXJmL2R3YXJmX2F0dHIuYw0KY2MgLU8yIC1waXBlIC1JL2hvbWUvc3JjL2xp Yi9saWJkd2FyZiAtRE5ERUJVRyAtc3RkPWdudTk5ICAgLUkvdXNyL29iai9ob21lL3NyYy90 bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9saWIvbGliZHdhcmYvZHdhcmZf YXR0cnZhbC5jDQpjYyAtTzIgLXBpcGUgLUkvaG9tZS9zcmMvbGliL2xpYmR3YXJmIC1ETkRF QlVHIC1zdGQ9Z251OTkgICAtSS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2lu Y2x1ZGUgLWMgL2hvbWUvc3JjL2xpYi9saWJkd2FyZi9kd2FyZl9jdS5jDQpjYyAtTzIgLXBp cGUgLUkvaG9tZS9zcmMvbGliL2xpYmR3YXJmIC1ETkRFQlVHIC1zdGQ9Z251OTkgICAtSS91 c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUvc3JjL2xp Yi9saWJkd2FyZi9kd2FyZl9kZWFsbG9jLmMNCmNjIC1PMiAtcGlwZSAtSS9ob21lL3NyYy9s aWIvbGliZHdhcmYgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1JL3Vzci9vYmovaG9tZS9zcmMv dG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvbGliL2xpYmR3YXJmL2R3YXJm X2RpZS5jDQpjYyAtTzIgLXBpcGUgLUkvaG9tZS9zcmMvbGliL2xpYmR3YXJmIC1ETkRFQlVH IC1zdGQ9Z251OTkgICAtSS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1 ZGUgLWMgL2hvbWUvc3JjL2xpYi9saWJkd2FyZi9kd2FyZl9kdW1wLmMNCmNjIC1PMiAtcGlw ZSAtSS9ob21lL3NyYy9saWIvbGliZHdhcmYgLUROREVCVUcgLXN0ZD1nbnU5OSAgIC1JL3Vz ci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvbGli L2xpYmR3YXJmL2R3YXJmX2Vycm1zZy5jDQpjYyAtTzIgLXBpcGUgLUkvaG9tZS9zcmMvbGli L2xpYmR3YXJmIC1ETkRFQlVHIC1zdGQ9Z251OTkgICAtSS91c3Ivb2JqL2hvbWUvc3JjL3Rt cC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUvc3JjL2xpYi9saWJkd2FyZi9kd2FyZl9l cnJuby5jDQpjYyAtTzIgLXBpcGUgLUkvaG9tZS9zcmMvbGliL2xpYmR3YXJmIC1ETkRFQlVH IC1zdGQ9Z251OTkgICAtSS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1 ZGUgLWMgL2hvbWUvc3JjL2xpYi9saWJkd2FyZi9kd2FyZl9maW5pc2guYw0KY2MgLU8yIC1w aXBlIC1JL2hvbWUvc3JjL2xpYi9saWJkd2FyZiAtRE5ERUJVRyAtc3RkPWdudTk5ICAgLUkv dXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9s aWIvbGliZHdhcmYvZHdhcmZfZm9ybS5jDQpjYyAtTzIgLXBpcGUgLUkvaG9tZS9zcmMvbGli L2xpYmR3YXJmIC1ETkRFQlVHIC1zdGQ9Z251OTkgICAtSS91c3Ivb2JqL2hvbWUvc3JjL3Rt cC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUvc3JjL2xpYi9saWJkd2FyZi9kd2FyZl9p bml0LmMNCmNjIC1PMiAtcGlwZSAtSS9ob21lL3NyYy9saWIvbGliZHdhcmYgLUROREVCVUcg LXN0ZD1nbnU5OSAgIC1JL3Vzci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVk ZSAtYyAvaG9tZS9zcmMvbGliL2xpYmR3YXJmL2R3YXJmX2xvYy5jDQpidWlsZGluZyBzdGF0 aWMgZHdhcmYgbGlicmFyeQ0KcmFubGliIGxpYmR3YXJmLmENCnNoIC9ob21lL3NyYy90b29s cy9pbnN0YWxsLnNoIC1DIC1vIHJvb3QgLWcgd2hlZWwgLW0gNDQ0ICAgbGliZHdhcmYuYSAv dXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9saWINCnNoIC9ob21lL3NyYy90b29s cy9pbnN0YWxsLnNoIC1DIC1vIHJvb3QgLWcgd2hlZWwgLW0gNDQ0ICAvaG9tZS9zcmMvbGli L2xpYmR3YXJmL2R3YXJmLmggL2hvbWUvc3JjL2xpYi9saWJkd2FyZi9saWJkd2FyZi5oIC91 c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUNCj09PT4gY2RkbC91c3Iu YmluL2N0ZmNvbnZlcnQgKG9iaixkZXBlbmQsYWxsLGluc3RhbGwpDQovdXNyL29iai9ob21l L3NyYy90bXAvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQgY3JlYXRlZCBmb3Ig L2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0DQpybSAtZiAuZGVwZW5kDQpta2Rl cCAtZiAuZGVwZW5kIC1hICAgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0 Ly4uLy4uLy4uL3N5cy9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcyAtSS9ob21lL3NyYy9jZGRs L3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcy9p bmNsdWRlIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2Nk ZGwvY29udHJpYi9vcGVuc29sYXJpcyAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29u dmVydC8uLi8uLi8uLi9zeXMvY2RkbC9jb250cmliL29wZW5zb2xhcmlzIC1JL2hvbWUvc3Jj L2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29s YXJpcy9oZWFkIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4u L2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy90b29scy9jdGYvY29tbW9uIC1JL2hvbWUvc3Jj L2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29s YXJpcy90b29scy9jdGYvY3Z0IC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0 Ly4uLy4uLy4uL3N5cy9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbiAtRE5F RURfU09MQVJJU19CT09MRUFOIC1ETkRFQlVHIC1JL3Vzci9vYmovaG9tZS9zcmMvdG1wL2xl Z2FjeS91c3IvaW5jbHVkZSAvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4v Li4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3Rvb2xzL2N0Zi9jdnQvYWxpc3QuYyAv aG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vY2RkbC9jb250cmli L29wZW5zb2xhcmlzL3Rvb2xzL2N0Zi9jdnQvY3RmLmMgL2hvbWUvc3JjL2NkZGwvdXNyLmJp bi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy90b29scy9j dGYvY3Z0L2N0ZmNvbnZlcnQuYyAvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQv Li4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3Rvb2xzL2N0Zi9jdnQvZHdhcmYu YyAvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vY2RkbC9jb250 cmliL29wZW5zb2xhcmlzL3Rvb2xzL2N0Zi9jdnQvZml4dXBfdGRlc2NzLmMgL2hvbWUvc3Jj L2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29s YXJpcy90b29scy9jdGYvY3Z0L2hhc2guYyAvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNv bnZlcnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3Rvb2xzL2N0Zi9jdnQv aWlkZXNjLmMgL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2Nk ZGwvY29udHJpYi9vcGVuc29sYXJpcy90b29scy9jdGYvY3Z0L2lucHV0LmMgL2hvbWUvc3Jj L2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29s YXJpcy90b29scy9jdGYvY29tbW9uL2xpc3QuYyAvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0 ZmNvbnZlcnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3Rvb2xzL2N0Zi9j b21tb24vbWVtb3J5LmMgL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4u Ly4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy90b29scy9jdGYvY3Z0L21lcmdlLmMgL2hv bWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9v cGVuc29sYXJpcy90b29scy9jdGYvY3Z0L291dHB1dC5jIC9ob21lL3NyYy9jZGRsL3Vzci5i aW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdG9vbHMv Y3RmL2N2dC9zdF9wYXJzZS5jIC9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8u Li8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdG9vbHMvY3RmL2N2dC9zdGFicy5j IC9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRy aWIvb3BlbnNvbGFyaXMvdG9vbHMvY3RmL2N2dC9zdGFjay5jIC9ob21lL3NyYy9jZGRsL3Vz ci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdG9v bHMvY3RmL2N2dC9zdHJ0YWIuYyAvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQv Li4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3Rvb2xzL2N0Zi9jb21tb24vc3lt Ym9sLmMgL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwv Y29udHJpYi9vcGVuc29sYXJpcy90b29scy9jdGYvY3Z0L3RkYXRhLmMgL2hvbWUvc3JjL2Nk ZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJp cy90b29scy9jdGYvY3Z0L3RyYXZlcnNlLmMgL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZj b252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy90b29scy9jdGYvY3Z0 L3V0aWwuYw0KZWNobyBjdGZjb252ZXJ0OiAvdXNyL2xpYi9saWJjLmEgL3Vzci9saWIvbGli Y3RmLmEgL3Vzci9saWIvbGliZHdhcmYuYSAvdXNyL2xpYi9saWJlbGYuYSAvdXNyL2xpYi9s aWJ6LmEgL3Vzci9saWIvbGlicHRocmVhZC5hIC91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdh Y3kvdXNyL2xpYi9saWJlZ2FjeS5hID4+IC5kZXBlbmQNCmNjIC1PMiAtcGlwZSAtSS9ob21l L3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9zeXMvY2RkbC9jb21wYXQv b3BlbnNvbGFyaXMgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4u Ly4uL2NkZGwvY29tcGF0L29wZW5zb2xhcmlzL2luY2x1ZGUgIC1JL2hvbWUvc3JjL2NkZGwv dXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcyAg LUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vc3lzL2NkZGwv Y29udHJpYi9vcGVuc29sYXJpcyAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZl cnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2hlYWQgIC1JL2hvbWUvc3Jj L2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29s YXJpcy90b29scy9jdGYvY29tbW9uICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29u dmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdG9vbHMvY3RmL2N2dCAg LUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vc3lzL2NkZGwv Y29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uIC1ETkVFRF9TT0xBUklTX0JPT0xFQU4g LUROREVCVUcgLWcgLXN0ZD1nbnU4OSAgLVduby11bmtub3duLXByYWdtYXMgLUkvdXNyL29i ai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9jZGRsL3Vz ci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdG9v bHMvY3RmL2N2dC9hbGlzdC5jDQpjYyAtTzIgLXBpcGUgLUkvaG9tZS9zcmMvY2RkbC91c3Iu YmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vc3lzL2NkZGwvY29tcGF0L29wZW5zb2xhcmlzICAt SS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbXBh dC9vcGVuc29sYXJpcy9pbmNsdWRlICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29u dmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMgIC1JL2hvbWUvc3JjL2Nk ZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL3N5cy9jZGRsL2NvbnRyaWIvb3BlbnNv bGFyaXMgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2Nk ZGwvY29udHJpYi9vcGVuc29sYXJpcy9oZWFkICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4v Y3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdG9vbHMvY3Rm L2NvbW1vbiAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4v Y2RkbC9jb250cmliL29wZW5zb2xhcmlzL3Rvb2xzL2N0Zi9jdnQgIC1JL2hvbWUvc3JjL2Nk ZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL3N5cy9jZGRsL2NvbnRyaWIvb3BlbnNv bGFyaXMvdXRzL2NvbW1vbiAtRE5FRURfU09MQVJJU19CT09MRUFOIC1ETkRFQlVHIC1nIC1z dGQ9Z251ODkgIC1Xbm8tdW5rbm93bi1wcmFnbWFzIC1JL3Vzci9vYmovaG9tZS9zcmMvdG1w L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZl cnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3Rvb2xzL2N0Zi9jdnQvY3Rm LmMNCmNjIC1PMiAtcGlwZSAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8u Li8uLi8uLi9zeXMvY2RkbC9jb21wYXQvb3BlbnNvbGFyaXMgIC1JL2hvbWUvc3JjL2NkZGwv dXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29tcGF0L29wZW5zb2xhcmlzL2lu Y2x1ZGUgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2Nk ZGwvY29udHJpYi9vcGVuc29sYXJpcyAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNv bnZlcnQvLi4vLi4vLi4vc3lzL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcyAgLUkvaG9tZS9z cmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5z b2xhcmlzL2hlYWQgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4u Ly4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy90b29scy9jdGYvY29tbW9uICAtSS9ob21l L3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3Bl bnNvbGFyaXMvdG9vbHMvY3RmL2N2dCAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNv bnZlcnQvLi4vLi4vLi4vc3lzL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9u IC1ETkVFRF9TT0xBUklTX0JPT0xFQU4gLUROREVCVUcgLWcgLXN0ZD1nbnU4OSAgLVduby11 bmtub3duLXByYWdtYXMgLUkvdXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNs dWRlIC1jIC9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRs L2NvbnRyaWIvb3BlbnNvbGFyaXMvdG9vbHMvY3RmL2N2dC9jdGZjb252ZXJ0LmMNCmNjIC1P MiAtcGlwZSAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9z eXMvY2RkbC9jb21wYXQvb3BlbnNvbGFyaXMgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9j dGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29tcGF0L29wZW5zb2xhcmlzL2luY2x1ZGUgIC1J L2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJp Yi9vcGVuc29sYXJpcyAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4v Li4vLi4vc3lzL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcyAgLUkvaG9tZS9zcmMvY2RkbC91 c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2hl YWQgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwv Y29udHJpYi9vcGVuc29sYXJpcy90b29scy9jdGYvY29tbW9uICAtSS9ob21lL3NyYy9jZGRs L3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMv dG9vbHMvY3RmL2N2dCAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4v Li4vLi4vc3lzL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uIC1ETkVFRF9T T0xBUklTX0JPT0xFQU4gLUROREVCVUcgLWcgLXN0ZD1nbnU4OSAgLVduby11bmtub3duLXBy YWdtYXMgLUkvdXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9o b21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIv b3BlbnNvbGFyaXMvdG9vbHMvY3RmL2N2dC9kd2FyZi5jDQpjYyAtTzIgLXBpcGUgLUkvaG9t ZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vc3lzL2NkZGwvY29tcGF0 L29wZW5zb2xhcmlzICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8u Li8uLi9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcy9pbmNsdWRlICAtSS9ob21lL3NyYy9jZGRs L3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMg IC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL3N5cy9jZGRs L2NvbnRyaWIvb3BlbnNvbGFyaXMgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252 ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9oZWFkICAtSS9ob21lL3Ny Yy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNv bGFyaXMvdG9vbHMvY3RmL2NvbW1vbiAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNv bnZlcnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3Rvb2xzL2N0Zi9jdnQg IC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL3N5cy9jZGRs L2NvbnRyaWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbiAtRE5FRURfU09MQVJJU19CT09MRUFO IC1ETkRFQlVHIC1nIC1zdGQ9Z251ODkgIC1Xbm8tdW5rbm93bi1wcmFnbWFzIC1JL3Vzci9v YmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvY2RkbC91 c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3Rv b2xzL2N0Zi9jdnQvZml4dXBfdGRlc2NzLmMNCmNjIC1PMiAtcGlwZSAtSS9ob21lL3NyYy9j ZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9zeXMvY2RkbC9jb21wYXQvb3BlbnNv bGFyaXMgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2Nk ZGwvY29tcGF0L29wZW5zb2xhcmlzL2luY2x1ZGUgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJp bi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcyAgLUkvaG9t ZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vc3lzL2NkZGwvY29udHJp Yi9vcGVuc29sYXJpcyAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4v Li4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2hlYWQgIC1JL2hvbWUvc3JjL2NkZGwv dXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy90 b29scy9jdGYvY29tbW9uICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8u Li8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdG9vbHMvY3RmL2N2dCAgLUkvaG9t ZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vc3lzL2NkZGwvY29udHJp Yi9vcGVuc29sYXJpcy91dHMvY29tbW9uIC1ETkVFRF9TT0xBUklTX0JPT0xFQU4gLUROREVC VUcgLWcgLXN0ZD1nbnU4OSAgLVduby11bmtub3duLXByYWdtYXMgLUkvdXNyL29iai9ob21l L3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9jZGRsL3Vzci5iaW4v Y3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdG9vbHMvY3Rm L2N2dC9oYXNoLmMNCmNjIC1PMiAtcGlwZSAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3Rm Y29udmVydC8uLi8uLi8uLi9zeXMvY2RkbC9jb21wYXQvb3BlbnNvbGFyaXMgIC1JL2hvbWUv c3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29tcGF0L29wZW5z b2xhcmlzL2luY2x1ZGUgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4u Ly4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcyAgLUkvaG9tZS9zcmMvY2RkbC91c3Iu YmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vc3lzL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcyAg LUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vY2RkbC9jb250 cmliL29wZW5zb2xhcmlzL2hlYWQgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252 ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy90b29scy9jdGYvY29tbW9u ICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2Nv bnRyaWIvb3BlbnNvbGFyaXMvdG9vbHMvY3RmL2N2dCAgLUkvaG9tZS9zcmMvY2RkbC91c3Iu YmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vc3lzL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91 dHMvY29tbW9uIC1ETkVFRF9TT0xBUklTX0JPT0xFQU4gLUROREVCVUcgLWcgLXN0ZD1nbnU4 OSAgLVduby11bmtub3duLXByYWdtYXMgLUkvdXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5 L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8u Li8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdG9vbHMvY3RmL2N2dC9paWRlc2MuYw0K Y2MgLU8yIC1waXBlIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4u Ly4uL3N5cy9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcyAgLUkvaG9tZS9zcmMvY2RkbC91c3Iu YmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vY2RkbC9jb21wYXQvb3BlbnNvbGFyaXMvaW5jbHVk ZSAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vY2RkbC9j b250cmliL29wZW5zb2xhcmlzICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVy dC8uLi8uLi8uLi9zeXMvY2RkbC9jb250cmliL29wZW5zb2xhcmlzICAtSS9ob21lL3NyYy9j ZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFy aXMvaGVhZCAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4v Y2RkbC9jb250cmliL29wZW5zb2xhcmlzL3Rvb2xzL2N0Zi9jb21tb24gIC1JL2hvbWUvc3Jj L2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29s YXJpcy90b29scy9jdGYvY3Z0ICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVy dC8uLi8uLi8uLi9zeXMvY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3V0cy9jb21tb24gLURO RUVEX1NPTEFSSVNfQk9PTEVBTiAtRE5ERUJVRyAtZyAtc3RkPWdudTg5ICAtV25vLXVua25v d24tcHJhZ21hcyAtSS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUg LWMgL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29u dHJpYi9vcGVuc29sYXJpcy90b29scy9jdGYvY3Z0L2lucHV0LmMNCmNjIC1PMiAtcGlwZSAt SS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9zeXMvY2RkbC9j b21wYXQvb3BlbnNvbGFyaXMgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0 Ly4uLy4uLy4uL2NkZGwvY29tcGF0L29wZW5zb2xhcmlzL2luY2x1ZGUgIC1JL2hvbWUvc3Jj L2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29s YXJpcyAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vc3lz L2NkZGwvY29udHJpYi9vcGVuc29sYXJpcyAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0 ZmNvbnZlcnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2hlYWQgIC1JL2hv bWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9v cGVuc29sYXJpcy90b29scy9jdGYvY29tbW9uICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4v Y3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdG9vbHMvY3Rm L2N2dCAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vc3lz L2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uIC1ETkVFRF9TT0xBUklTX0JP T0xFQU4gLUROREVCVUcgLWcgLXN0ZD1nbnU4OSAgLVduby11bmtub3duLXByYWdtYXMgLUkv dXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9j ZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFy aXMvdG9vbHMvY3RmL2NvbW1vbi9saXN0LmMNCmNjIC1PMiAtcGlwZSAtSS9ob21lL3NyYy9j ZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9zeXMvY2RkbC9jb21wYXQvb3BlbnNv bGFyaXMgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2Nk ZGwvY29tcGF0L29wZW5zb2xhcmlzL2luY2x1ZGUgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJp bi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcyAgLUkvaG9t ZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vc3lzL2NkZGwvY29udHJp Yi9vcGVuc29sYXJpcyAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4v Li4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2hlYWQgIC1JL2hvbWUvc3JjL2NkZGwv dXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy90 b29scy9jdGYvY29tbW9uICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8u Li8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdG9vbHMvY3RmL2N2dCAgLUkvaG9t ZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vc3lzL2NkZGwvY29udHJp Yi9vcGVuc29sYXJpcy91dHMvY29tbW9uIC1ETkVFRF9TT0xBUklTX0JPT0xFQU4gLUROREVC VUcgLWcgLXN0ZD1nbnU4OSAgLVduby11bmtub3duLXByYWdtYXMgLUkvdXNyL29iai9ob21l L3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9jZGRsL3Vzci5iaW4v Y3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdG9vbHMvY3Rm L2NvbW1vbi9tZW1vcnkuYw0KY2MgLU8yIC1waXBlIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJp bi9jdGZjb252ZXJ0Ly4uLy4uLy4uL3N5cy9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcyAgLUkv aG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vY2RkbC9jb21wYXQv b3BlbnNvbGFyaXMvaW5jbHVkZSAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZl cnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzICAtSS9ob21lL3NyYy9jZGRs L3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9zeXMvY2RkbC9jb250cmliL29wZW5zb2xh cmlzICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRs L2NvbnRyaWIvb3BlbnNvbGFyaXMvaGVhZCAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0 ZmNvbnZlcnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3Rvb2xzL2N0Zi9j b21tb24gIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2Nk ZGwvY29udHJpYi9vcGVuc29sYXJpcy90b29scy9jdGYvY3Z0ICAtSS9ob21lL3NyYy9jZGRs L3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9zeXMvY2RkbC9jb250cmliL29wZW5zb2xh cmlzL3V0cy9jb21tb24gLURORUVEX1NPTEFSSVNfQk9PTEVBTiAtRE5ERUJVRyAtZyAtc3Rk PWdudTg5ICAtV25vLXVua25vd24tcHJhZ21hcyAtSS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9s ZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0 Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy90b29scy9jdGYvY3Z0L21lcmdl LmMNCmNjIC1PMiAtcGlwZSAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8u Li8uLi8uLi9zeXMvY2RkbC9jb21wYXQvb3BlbnNvbGFyaXMgIC1JL2hvbWUvc3JjL2NkZGwv dXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29tcGF0L29wZW5zb2xhcmlzL2lu Y2x1ZGUgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2Nk ZGwvY29udHJpYi9vcGVuc29sYXJpcyAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNv bnZlcnQvLi4vLi4vLi4vc3lzL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcyAgLUkvaG9tZS9z cmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5z b2xhcmlzL2hlYWQgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4u Ly4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy90b29scy9jdGYvY29tbW9uICAtSS9ob21l L3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3Bl bnNvbGFyaXMvdG9vbHMvY3RmL2N2dCAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNv bnZlcnQvLi4vLi4vLi4vc3lzL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9u IC1ETkVFRF9TT0xBUklTX0JPT0xFQU4gLUROREVCVUcgLWcgLXN0ZD1nbnU4OSAgLVduby11 bmtub3duLXByYWdtYXMgLUkvdXNyL29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNs dWRlIC1jIC9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRs L2NvbnRyaWIvb3BlbnNvbGFyaXMvdG9vbHMvY3RmL2N2dC9vdXRwdXQuYw0KY2MgLU8yIC1w aXBlIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL3N5cy9j ZGRsL2NvbXBhdC9vcGVuc29sYXJpcyAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNv bnZlcnQvLi4vLi4vLi4vY2RkbC9jb21wYXQvb3BlbnNvbGFyaXMvaW5jbHVkZSAgLUkvaG9t ZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29w ZW5zb2xhcmlzICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8u Li9zeXMvY2RkbC9jb250cmliL29wZW5zb2xhcmlzICAtSS9ob21lL3NyYy9jZGRsL3Vzci5i aW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvaGVhZCAg LUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vY2RkbC9jb250 cmliL29wZW5zb2xhcmlzL3Rvb2xzL2N0Zi9jb21tb24gIC1JL2hvbWUvc3JjL2NkZGwvdXNy LmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy90b29s cy9jdGYvY3Z0ICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8u Li9zeXMvY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3V0cy9jb21tb24gLURORUVEX1NPTEFS SVNfQk9PTEVBTiAtRE5ERUJVRyAtZyAtc3RkPWdudTg5ICAtV25vLXVua25vd24tcHJhZ21h cyAtSS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL2hvbWUv c3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVu c29sYXJpcy90b29scy9jdGYvY3Z0L3N0X3BhcnNlLmMNCmNjIC1PMiAtcGlwZSAtSS9ob21l L3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9zeXMvY2RkbC9jb21wYXQv b3BlbnNvbGFyaXMgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4u Ly4uL2NkZGwvY29tcGF0L29wZW5zb2xhcmlzL2luY2x1ZGUgIC1JL2hvbWUvc3JjL2NkZGwv dXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcyAg LUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vc3lzL2NkZGwv Y29udHJpYi9vcGVuc29sYXJpcyAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZl cnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2hlYWQgIC1JL2hvbWUvc3Jj L2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29s YXJpcy90b29scy9jdGYvY29tbW9uICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29u dmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdG9vbHMvY3RmL2N2dCAg LUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vc3lzL2NkZGwv Y29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uIC1ETkVFRF9TT0xBUklTX0JPT0xFQU4g LUROREVCVUcgLWcgLXN0ZD1nbnU4OSAgLVduby11bmtub3duLXByYWdtYXMgLUkvdXNyL29i ai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9jZGRsL3Vz ci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdG9v bHMvY3RmL2N2dC9zdGFicy5jDQpjYyAtTzIgLXBpcGUgLUkvaG9tZS9zcmMvY2RkbC91c3Iu YmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vc3lzL2NkZGwvY29tcGF0L29wZW5zb2xhcmlzICAt SS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbXBh dC9vcGVuc29sYXJpcy9pbmNsdWRlICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29u dmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMgIC1JL2hvbWUvc3JjL2Nk ZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL3N5cy9jZGRsL2NvbnRyaWIvb3BlbnNv bGFyaXMgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2Nk ZGwvY29udHJpYi9vcGVuc29sYXJpcy9oZWFkICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4v Y3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdG9vbHMvY3Rm L2NvbW1vbiAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4v Y2RkbC9jb250cmliL29wZW5zb2xhcmlzL3Rvb2xzL2N0Zi9jdnQgIC1JL2hvbWUvc3JjL2Nk ZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL3N5cy9jZGRsL2NvbnRyaWIvb3BlbnNv bGFyaXMvdXRzL2NvbW1vbiAtRE5FRURfU09MQVJJU19CT09MRUFOIC1ETkRFQlVHIC1nIC1z dGQ9Z251ODkgIC1Xbm8tdW5rbm93bi1wcmFnbWFzIC1JL3Vzci9vYmovaG9tZS9zcmMvdG1w L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZl cnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3Rvb2xzL2N0Zi9jdnQvc3Rh Y2suYw0KY2MgLU8yIC1waXBlIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0 Ly4uLy4uLy4uL3N5cy9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcyAgLUkvaG9tZS9zcmMvY2Rk bC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vY2RkbC9jb21wYXQvb3BlbnNvbGFyaXMv aW5jbHVkZSAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4v Y2RkbC9jb250cmliL29wZW5zb2xhcmlzICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3Rm Y29udmVydC8uLi8uLi8uLi9zeXMvY2RkbC9jb250cmliL29wZW5zb2xhcmlzICAtSS9ob21l L3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3Bl bnNvbGFyaXMvaGVhZCAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4v Li4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3Rvb2xzL2N0Zi9jb21tb24gIC1JL2hv bWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9v cGVuc29sYXJpcy90b29scy9jdGYvY3Z0ICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3Rm Y29udmVydC8uLi8uLi8uLi9zeXMvY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3V0cy9jb21t b24gLURORUVEX1NPTEFSSVNfQk9PTEVBTiAtRE5ERUJVRyAtZyAtc3RkPWdudTg5ICAtV25v LXVua25vd24tcHJhZ21hcyAtSS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kvdXNyL2lu Y2x1ZGUgLWMgL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2Nk ZGwvY29udHJpYi9vcGVuc29sYXJpcy90b29scy9jdGYvY3Z0L3N0cnRhYi5jDQpjYyAtTzIg LXBpcGUgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vc3lz L2NkZGwvY29tcGF0L29wZW5zb2xhcmlzICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3Rm Y29udmVydC8uLi8uLi8uLi9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcy9pbmNsdWRlICAtSS9o b21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIv b3BlbnNvbGFyaXMgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4u Ly4uL3N5cy9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMgIC1JL2hvbWUvc3JjL2NkZGwvdXNy LmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9oZWFk ICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2Nv bnRyaWIvb3BlbnNvbGFyaXMvdG9vbHMvY3RmL2NvbW1vbiAgLUkvaG9tZS9zcmMvY2RkbC91 c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3Rv b2xzL2N0Zi9jdnQgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4u Ly4uL3N5cy9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbiAtRE5FRURfU09M QVJJU19CT09MRUFOIC1ETkRFQlVHIC1nIC1zdGQ9Z251ODkgIC1Xbm8tdW5rbm93bi1wcmFn bWFzIC1JL3Vzci9vYmovaG9tZS9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9t ZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29w ZW5zb2xhcmlzL3Rvb2xzL2N0Zi9jb21tb24vc3ltYm9sLmMNCmNjIC1PMiAtcGlwZSAtSS9o b21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9zeXMvY2RkbC9jb21w YXQvb3BlbnNvbGFyaXMgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4u Ly4uLy4uL2NkZGwvY29tcGF0L29wZW5zb2xhcmlzL2luY2x1ZGUgIC1JL2hvbWUvc3JjL2Nk ZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJp cyAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vc3lzL2Nk ZGwvY29udHJpYi9vcGVuc29sYXJpcyAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNv bnZlcnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2hlYWQgIC1JL2hvbWUv c3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29udHJpYi9vcGVu c29sYXJpcy90b29scy9jdGYvY29tbW9uICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3Rm Y29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdG9vbHMvY3RmL2N2 dCAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vc3lzL2Nk ZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uIC1ETkVFRF9TT0xBUklTX0JPT0xF QU4gLUROREVCVUcgLWcgLXN0ZD1nbnU4OSAgLVduby11bmtub3duLXByYWdtYXMgLUkvdXNy L29iai9ob21lL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC9ob21lL3NyYy9jZGRs L3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMv dG9vbHMvY3RmL2N2dC90ZGF0YS5jDQpjYyAtTzIgLXBpcGUgLUkvaG9tZS9zcmMvY2RkbC91 c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vc3lzL2NkZGwvY29tcGF0L29wZW5zb2xhcmlz ICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2Nv bXBhdC9vcGVuc29sYXJpcy9pbmNsdWRlICAtSS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3Rm Y29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMgIC1JL2hvbWUvc3Jj L2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL3N5cy9jZGRsL2NvbnRyaWIvb3Bl bnNvbGFyaXMgIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4u L2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9oZWFkICAtSS9ob21lL3NyYy9jZGRsL3Vzci5i aW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdG9vbHMv Y3RmL2NvbW1vbiAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4v Li4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3Rvb2xzL2N0Zi9jdnQgIC1JL2hvbWUvc3Jj L2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL3N5cy9jZGRsL2NvbnRyaWIvb3Bl bnNvbGFyaXMvdXRzL2NvbW1vbiAtRE5FRURfU09MQVJJU19CT09MRUFOIC1ETkRFQlVHIC1n IC1zdGQ9Z251ODkgIC1Xbm8tdW5rbm93bi1wcmFnbWFzIC1JL3Vzci9vYmovaG9tZS9zcmMv dG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNv bnZlcnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3Rvb2xzL2N0Zi9jdnQv dHJhdmVyc2UuYw0KY2MgLU8yIC1waXBlIC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZj b252ZXJ0Ly4uLy4uLy4uL3N5cy9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcyAgLUkvaG9tZS9z cmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4vLi4vLi4vY2RkbC9jb21wYXQvb3BlbnNv bGFyaXMvaW5jbHVkZSAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZlcnQvLi4v Li4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzICAtSS9ob21lL3NyYy9jZGRsL3Vzci5i aW4vY3RmY29udmVydC8uLi8uLi8uLi9zeXMvY2RkbC9jb250cmliL29wZW5zb2xhcmlzICAt SS9ob21lL3NyYy9jZGRsL3Vzci5iaW4vY3RmY29udmVydC8uLi8uLi8uLi9jZGRsL2NvbnRy aWIvb3BlbnNvbGFyaXMvaGVhZCAgLUkvaG9tZS9zcmMvY2RkbC91c3IuYmluL2N0ZmNvbnZl cnQvLi4vLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3Rvb2xzL2N0Zi9jb21tb24g IC1JL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4uLy4uL2NkZGwvY29u dHJpYi9vcGVuc29sYXJpcy90b29scy9jdGYvY3Z0ICAtSS9ob21lL3NyYy9jZGRsL3Vzci5i aW4vY3RmY29udmVydC8uLi8uLi8uLi9zeXMvY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3V0 cy9jb21tb24gLURORUVEX1NPTEFSSVNfQk9PTEVBTiAtRE5ERUJVRyAtZyAtc3RkPWdudTg5 ICAtV25vLXVua25vd24tcHJhZ21hcyAtSS91c3Ivb2JqL2hvbWUvc3JjL3RtcC9sZWdhY3kv dXNyL2luY2x1ZGUgLWMgL2hvbWUvc3JjL2NkZGwvdXNyLmJpbi9jdGZjb252ZXJ0Ly4uLy4u Ly4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy90b29scy9jdGYvY3Z0L3V0aWwuYw0KbWFr ZTogZG9uJ3Qga25vdyBob3cgdG8gbWFrZSAvdXNyL2xpYi9saWJjdGYuYS4gU3RvcA0KKioq IEVycm9yIGNvZGUgMg0KDQpTdG9wIGluIC9ob21lL3NyYy4NCioqKiBFcnJvciBjb2RlIDEN Cg0KU3RvcCBpbiAvaG9tZS9zcmMuDQoqKiogRXJyb3IgY29kZSAxDQoNClN0b3AgaW4gL2hv bWUvc3JjLg0KClNjcmlwdCBkb25lIG9uIFRodSBBcHIgIDggMTQ6NDE6MzkgMjAxMAo= --------------040009020300060908010807-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 13:36:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C15571065673 for ; Thu, 8 Apr 2010 13:36:39 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7C2468FC22 for ; Thu, 8 Apr 2010 13:36:39 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 912821FFC22; Thu, 8 Apr 2010 13:36:38 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 498C9844A8; Thu, 8 Apr 2010 15:36:37 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexey Tarasov References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> Date: Thu, 08 Apr 2010 15:36:37 +0200 In-Reply-To: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> (Alexey Tarasov's message of "Thu, 8 Apr 2010 17:06:55 +0400") Message-ID: <868w8yukuy.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 13:36:40 -0000 Alexey Tarasov writes: > There is only one possibility to change sector size of physical disk > (gnop -S 4096 ...). May be it is possible to add such possibility to > gpart? e.g. gpart create -S 4096 -t gpt ad0? I don't quite see how that would work - do you mean gpart should configure a gnop? AFAIK there is no "gnop label", so you can't set up a persistent gnop; you have to set it up manually at boot time every time, and there's a risk that the fs (or other layers higher up) will taste the underlying device instead of the gnop. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 13:44:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8273C1065674 for ; Thu, 8 Apr 2010 13:44:04 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from relay.wahome.ru (relay.wahome.ru [95.211.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id 4AB278FC12 for ; Thu, 8 Apr 2010 13:44:03 +0000 (UTC) Received: from mmx.lexasoft.ru (mmx.lexasoft.ru [92.241.160.6]) by relay.wahome.ru (Postfix) with ESMTP id A0CC66B21EA; Thu, 8 Apr 2010 17:41:05 +0400 (MSD) Received: from [10.100.0.2] (petrovich-telecom-gw.wahome.ru [77.91.225.38]) by mmx.lexasoft.ru (Postfix) with ESMTPSA id 01F612848C; Thu, 8 Apr 2010 17:44:01 +0400 (MSD) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1077) From: Alexey Tarasov In-Reply-To: <868w8yukuy.fsf@ds4.des.no> Date: Thu, 8 Apr 2010 17:44:00 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1077) Cc: Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 13:44:04 -0000 No, no. I mean that gpart should act like gnop presenting another sector size to = user. I that possible at all? On 08.04.2010, at 17:36, Dag-Erling Sm=C3=B8rgrav wrote: > I don't quite see how that would work - do you mean gpart should > configure a gnop? AFAIK there is no "gnop label", so you can't set up = a > persistent gnop; you have to set it up manually at boot time every = time, > and there's a risk that the fs (or other layers higher up) will taste > the underlying device instead of the gnop. -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(") From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 13:53:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15BD71065672; Thu, 8 Apr 2010 13:53:20 +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 A9C788FC22; Thu, 8 Apr 2010 13:53:19 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2CF7F.dip.t-dialin.net [217.226.207.127]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 65F5D8442CF; Thu, 8 Apr 2010 15:53:13 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 664465074; Thu, 8 Apr 2010 15:53:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1270734790; bh=ofIeURU8Tk1u16OOkOWKx6VzaqkL7Mkpwus1Q9/7JoI=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=fPoE8Gv48nA15QlvunY/Z/jrcOezGzk5gLY1Bl4ZevZ8sT08W+Y0CnjE3677S7vk+ 6xALQu2Dx4O2Zi13STw3lzidrwiNLt1Fl8FYEMiPYg+gIi2mVn76Ny2RNzFVoB6zxy c8VBRSD/SyKVt6u03YSjXekZAJKrr3yEGYTT3NN/1Q19mWh43YlNuj6sWNx0/XP//o mKKf2R8wwEnplU7wetFrT6hveGkltZTEYoA9CkSQB8sPy0iz+u9nDIv/hvfmYs0S0Y 9LeamIf4uwAhXEKsXxX0c0T1fcmER3cQdQQ+Wxdt/GNdroMXdeS6KleUeFck3UTY49 grrp47Tv6sFtg== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id o38Dr9Qa037083; Thu, 8 Apr 2010 15:53:09 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 08 Apr 2010 15:53:09 +0200 Message-ID: <20100408155309.42884l21ogy7m7sw@webmail.leidinger.net> Date: Thu, 08 Apr 2010 15:53:09 +0200 From: Alexander Leidinger To: Dag-Erling =?utf-8?b?U23Dg8K4cmdyYXY=?= References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> <201004080727.21020.bruce@cran.org.uk> <4BBD7CDC.2070505@yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <20100408121500.13995d1eu7b9bt0k@webmail.leidinger.net> <86fx36up9e.fsf@ds4.des.no> In-Reply-To: <86fx36up9e.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: 65F5D8442CF.12F7D X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.44, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1271339594.6354@8RWDoP8L3F1XA4vV1f1WTA X-EBL-Spam-Status: No Cc: Bruce Cran , freebsd-current@FreeBSD.ORG, freebsd-geom@FreeBSD.ORG, Teske , Randi Harper , "Andrey V. Elsukov" , Devin@FreeBSD.ORG Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 13:53:20 -0000 Quoting Dag-Erling Sm=C3=83=C2=B8rgrav (from Thu, 08 Apr 2010 = =20 14:01:33 +0200): > Alexander Leidinger writes: >> I think this is more complicated than to refactor the interesting part >> into a backend with an API which both tools can use. This would also >> allow someone to write a GUI program (e.g. for PC-BSD). > > There have been at least three or four attempts to do this in the past. > One of them was even fully funded by the FreeBSD Foundation. They all > failed. I was told a lot of people tried to make the WITH_CTF part working =20 without the need to use -DWITH_CTF each time at the command line and =20 failed. Nevertless I did it. So telling something is not possible =20 because other people tried and failed is ridiculous. If there is no =20 proof that it can not be done, I'm sure someone exists who is able to =20 do it. I stand by my words and still say that it is less complicated to put =20 the logic into a backend-lib. If Andrey has problems to do this, I'm =20 willing to invest some time to mentor him in this regard. BTW: I do not think you talk about a partition editor, but about the =20 complete sysinstall. This is a different beast than only the part =20 which I outlined above. Andrey has already some working stuff which =20 just needs to be refactored into frontend/backend-lib parts. Bye, Alexander. --=20 UNIX is many things to many people, but it's never been everything to anybody. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 13:55:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1D231065672; Thu, 8 Apr 2010 13:55:00 +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 CBB3C8FC18; Thu, 8 Apr 2010 13:54:58 +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 6491B46B58; Thu, 8 Apr 2010 09:54:58 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id A79D68A025; Thu, 8 Apr 2010 09:54:57 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 8 Apr 2010 08:49:12 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <55861270658151@web135.yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> In-Reply-To: <867hoi8gbl.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201004080849.12151.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 08 Apr 2010 09:54:57 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.8 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Bruce Cran , freebsd-geom@freebsd.org, Teske , Randi Harper , "Andrey V. Elsukov" , Alexander Leidinger , Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?= Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 13:55:00 -0000 On Thursday 08 April 2010 5:05:34 am Dag-Erling Sm=C3=B8rgrav wrote: > Alexander Leidinger writes: > > Please consider using SVN instead. A lot more users will be able to > > check out from there. >=20 > We don't grant non-committers access to the Subversion repo. >=20 > > It looks like other people had a look at sysinstall, not at sade. As > > sysinstall is supposed to be used at installation time, and the intent > > for sade was to offer the functionality (or more) of the part of > > sysinstall which is useful after installation (and to prevent admins > > from using sysinstall after the installation to prevent some unwanted > > foot-shooting), I do not think that we need to think about a strong > > lock between sysinstall and sade. >=20 > Yes we do. Otherwise we'll just end up back where we are today, where > if you want anything more complicated than a single-disk install you > have to drop into the fixit shell and do it manually before running the > installation procedure. Anythig that sade can do, we want sysinstall to > do as well, and we don't want to implement everything twice. >=20 > My suggestion is to add a "sysinstall mode" to sade where it operates > under certain (minor) constraints and reports what it did in a format > that sysinstall can parse, so sysinstall can just fork-exec sade instead > of duplicating the code. Actually, I would rather have sysinstall just invoke sade to do the disk=20 related stuff. Also, I think sysinstall should allow for a "back-door" mod= e=20 where a user can setup partitions however they like and mount them at /mnt = and=20 then let sysinstall use the setup the user created. This will allow users = to=20 setup more complex setups that sysinstall/sade do not currently support and= =20 allow sade to focus on simpler, common usage cases w/o having to handle=20 painful edge cases. It would also allow for new modules to be added to sad= e=20 over time w/o requiring it to support every possible disk layout from the=20 beginning. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 14:08:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3E38106567C; Thu, 8 Apr 2010 14:08:41 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by mx1.freebsd.org (Postfix) with ESMTP id C08348FC1E; Thu, 8 Apr 2010 14:08:40 +0000 (UTC) Received: by fxm25 with SMTP id 25so221611fxm.3 for ; Thu, 08 Apr 2010 07:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Nxibvwy0iy6OwFBEquSaiRJty746c5yNGFLqbOw38wk=; b=xZHikXwYrjuWNTiRB2yOBSJr/4S1muUuCR4rA1zWZ01A6wZcEUQNexljRPW09l3/xY XIATgNVu9IHFrz4rooJ2Dh4d0DdNobQn7jQ/dQna0UfLyh6A5yIQY0GF5d0G8SDyI57+ u0S6MXceTEq186uhC9bBVEl50xl6iudwcmVrk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=qpQzIz/m6WxlxRnM31WIQN/P5rJYBY85HbEYfKb8rzrbu9h3BZQKqmcQwWRznBPX4A f/hS0h7x4DiBaEcsj4TtoijASFN2Gd5nwj33+qAvP3iLaONztSkIL0DgOhSK7Ku8XZ1Q NB2rZ2G+6n32ZcrIoHwYpIpubq3ZNkpt1LMbE= Received: by 10.223.17.216 with SMTP id t24mr167927faa.90.1270735719519; Thu, 08 Apr 2010 07:08:39 -0700 (PDT) Received: from [10.0.10.2] (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 14sm82935fxm.9.2010.04.08.07.08.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 08 Apr 2010 07:08:38 -0700 (PDT) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Rui Paulo In-Reply-To: <201004080849.12151.jhb@freebsd.org> Date: Thu, 8 Apr 2010 15:08:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2FEF9866-2B2E-4AAC-B504-02CF1537AEC0@freebsd.org> References: <55861270658151@web135.yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <201004080849.12151.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1078) Cc: Bruce Cran , freebsd-current@freebsd.org, freebsd-geom@freebsd.org, Teske , Randi Harper , "Andrey V. Elsukov" , =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , Alexander Leidinger Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:08:42 -0000 On 8 Apr 2010, at 13:49, John Baldwin wrote: > On Thursday 08 April 2010 5:05:34 am Dag-Erling Sm=F8rgrav wrote: >> Alexander Leidinger writes: >>> Please consider using SVN instead. A lot more users will be able to >>> check out from there. >>=20 >> We don't grant non-committers access to the Subversion repo. >>=20 >>> It looks like other people had a look at sysinstall, not at sade. As >>> sysinstall is supposed to be used at installation time, and the = intent >>> for sade was to offer the functionality (or more) of the part of >>> sysinstall which is useful after installation (and to prevent admins >>> from using sysinstall after the installation to prevent some = unwanted >>> foot-shooting), I do not think that we need to think about a strong >>> lock between sysinstall and sade. >>=20 >> Yes we do. Otherwise we'll just end up back where we are today, = where >> if you want anything more complicated than a single-disk install you >> have to drop into the fixit shell and do it manually before running = the >> installation procedure. Anythig that sade can do, we want sysinstall = to >> do as well, and we don't want to implement everything twice. >>=20 >> My suggestion is to add a "sysinstall mode" to sade where it operates >> under certain (minor) constraints and reports what it did in a format >> that sysinstall can parse, so sysinstall can just fork-exec sade = instead >> of duplicating the code. >=20 > Actually, I would rather have sysinstall just invoke sade to do the = disk=20 > related stuff. Also, I think sysinstall should allow for a = "back-door" mode=20 > where a user can setup partitions however they like and mount them at = /mnt and=20 > then let sysinstall use the setup the user created. This will allow = users to=20 > setup more complex setups that sysinstall/sade do not currently = support and=20 > allow sade to focus on simpler, common usage cases w/o having to = handle=20 > painful edge cases. It would also allow for new modules to be added = to sade=20 > over time w/o requiring it to support every possible disk layout from = the=20 > beginning. I couldn't agree more. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 14:09:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D0651065677 for ; Thu, 8 Apr 2010 14:09:25 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 314EB8FC27 for ; Thu, 8 Apr 2010 14:09:24 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 3447F1FFC22; Thu, 8 Apr 2010 14:09:24 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 1A29E844A8; Thu, 8 Apr 2010 16:09:24 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexey Tarasov References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> Date: Thu, 08 Apr 2010 16:09:24 +0200 In-Reply-To: <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> (Alexey Tarasov's message of "Thu, 8 Apr 2010 17:44:00 +0400") Message-ID: <86zl1et4rv.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:09:25 -0000 Alexey Tarasov writes: > I mean that gpart should act like gnop presenting another sector size > to user. I that possible at all? That depends on the underlying partition scheme. My guess is "no". (it all boils down to whether the desired logical sector size can somehow be recorded on-disk) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 14:12:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1DF11065674 for ; Thu, 8 Apr 2010 14:12:25 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from relay.wahome.ru (relay.wahome.ru [95.211.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id 985448FC19 for ; Thu, 8 Apr 2010 14:12:25 +0000 (UTC) Received: from mmx.lexasoft.ru (mmx.lexasoft.ru [92.241.160.6]) by relay.wahome.ru (Postfix) with ESMTP id 5D3566B2187; Thu, 8 Apr 2010 18:09:27 +0400 (MSD) Received: from [10.100.0.2] (petrovich-telecom-gw.wahome.ru [77.91.225.38]) by mmx.lexasoft.ru (Postfix) with ESMTPSA id A83142848C; Thu, 8 Apr 2010 18:12:23 +0400 (MSD) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=utf-8 From: Alexey Tarasov In-Reply-To: <86zl1et4rv.fsf@ds4.des.no> Date: Thu, 8 Apr 2010 18:12:22 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1077) Cc: Alexey Tarasov Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:12:25 -0000 Ok, in case of GPT? :-) GPT implementation can be the simplest solution to this problem compared = to implementing additional ATA commands to determine if disk is in = Advanced Format. On 08.04.2010, at 18:09, Dag-Erling Sm=C3=B8rgrav wrote: > Alexey Tarasov writes: >> I mean that gpart should act like gnop presenting another sector size >> to user. I that possible at all? >=20 > That depends on the underlying partition scheme. My guess is "no". >=20 > (it all boils down to whether the desired logical sector size can > somehow be recorded on-disk) >=20 -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(") From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 14:15:28 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8772106566C; Thu, 8 Apr 2010 14:15:28 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 61EE58FC1C; Thu, 8 Apr 2010 14:15:28 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 73C0E1FFC22; Thu, 8 Apr 2010 14:15:27 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 51E5F844C6; Thu, 8 Apr 2010 16:15:27 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Leidinger References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> <201004080727.21020.bruce@cran.org.uk> <4BBD7CDC.2070505@yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <20100408121500.13995d1eu7b9bt0k@webmail.leidinger.net> <86fx36up9e.fsf@ds4.des.no> <20100408155309.42884l21ogy7m7sw@webmail.leidinger.net> Date: Thu, 08 Apr 2010 16:15:27 +0200 In-Reply-To: <20100408155309.42884l21ogy7m7sw@webmail.leidinger.net> (Alexander Leidinger's message of "Thu, 08 Apr 2010 15:53:09 +0200") Message-ID: <86vdc2t4hs.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , freebsd-current@FreeBSD.ORG, freebsd-geom@FreeBSD.ORG, Teske , Randi Harper , "Andrey V. Elsukov" , Devin@FreeBSD.ORG Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:15:28 -0000 Alexander Leidinger writes: > Dag-Erling Sm=C3=B8rgrav writes: > > There have been at least three or four attempts to do this in the > > past. One of them was even fully funded by the FreeBSD Foundation. > > They all failed. > I was told a lot of people tried to make the WITH_CTF part working > without the need to use -DWITH_CTF each time at the command line and > failed. Nevertless I did it. So telling something is not possible > because other people tried and failed is ridiculous. It's not ridiculous, it's experience. *Painful* experience over a period of nearly 15 years. > BTW: I do not think you talk about a partition editor, but about the > complete sysinstall. Yes and no. I'm talking about making the user interface pluggable, i.e. run the same program (whether sysinstall or sade) with, say, an ncurses interface on the console and a gtk interface in X. Debian's package system does this, to a certain extent, but only for very simple configuration questions - about the same level of functionality that you get with an HTML form. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 14:19:50 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C8DD106566C; Thu, 8 Apr 2010 14:19:50 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id DD9758FC0A; Thu, 8 Apr 2010 14:19:49 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id D50471FFC22; Thu, 8 Apr 2010 14:19:48 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id AB308844C6; Thu, 8 Apr 2010 16:19:48 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: John Baldwin References: <55861270658151@web135.yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <201004080849.12151.jhb@freebsd.org> Date: Thu, 08 Apr 2010 16:19:48 +0200 In-Reply-To: <201004080849.12151.jhb@freebsd.org> (John Baldwin's message of "Thu, 8 Apr 2010 08:49:12 -0400") Message-ID: <86r5mqt4aj.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , freebsd-geom@freebsd.org, Teske , Randi Harper , freebsd-current@freebsd.org, "Andrey V. Elsukov" , Alexander Leidinger Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:19:50 -0000 John Baldwin writes: > Dag-Erling Sm=C3=B8rgrav writes: > > My suggestion is to add a "sysinstall mode" to sade where it > > operates under certain (minor) constraints and reports what it did > > in a format that sysinstall can parse, so sysinstall can just > > fork-exec sade instead of duplicating the code. > Actually, I would rather have sysinstall just invoke sade to do the > disk related stuff. ...which is exactly what I said - but in the sysinstall case, you may want to ask some additional questions ("are you sure you want to proceed without a swap partition?") or place some additional constraints (such as "don't allow the user to mount something on top of /mnt or /rescue"), and sysinstall needs to know the outcome. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 14:24:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49C27106566B for ; Thu, 8 Apr 2010 14:24:14 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 0CECE8FC1E for ; Thu, 8 Apr 2010 14:24:13 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 257EC1FFC22; Thu, 8 Apr 2010 14:24:13 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id E7866844C6; Thu, 8 Apr 2010 16:24:12 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexey Tarasov References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> Date: Thu, 08 Apr 2010 16:24:12 +0200 In-Reply-To: (Alexey Tarasov's message of "Thu, 8 Apr 2010 18:12:22 +0400") Message-ID: <86mxxet437.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:24:14 -0000 Alexey Tarasov writes: > Ok, in case of GPT? :-) I doubt it, but I don't know for sure. > GPT implementation can be the simplest solution to this problem > compared to implementing additional ATA commands to determine if disk > is in Advanced Format. There are two issues: 1) There is already an ATA command to report both physical and logical sector sizes, but the disk lies - it always reports 512/512. 2) The disk may have already been formatted on a system that doesn't support 4k sectors, and may contain unaligned partitions and file systems, which won't be visible if we forcibly and unconditionally use 4k sectors. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 14:26:44 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76312106564A for ; Thu, 8 Apr 2010 14:26:44 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from relay.wahome.ru (relay.wahome.ru [95.211.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id 3BDC38FC13 for ; Thu, 8 Apr 2010 14:26:44 +0000 (UTC) Received: from mmx.lexasoft.ru (mmx.lexasoft.ru [92.241.160.6]) by relay.wahome.ru (Postfix) with ESMTP id 573FF6B21A0; Thu, 8 Apr 2010 18:23:46 +0400 (MSD) Received: from [10.100.0.2] (petrovich-telecom-gw.wahome.ru [77.91.225.38]) by mmx.lexasoft.ru (Postfix) with ESMTPSA id 840942848C; Thu, 8 Apr 2010 18:26:42 +0400 (MSD) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=utf-8 From: Alexey Tarasov In-Reply-To: <86mxxet437.fsf@ds4.des.no> Date: Thu, 8 Apr 2010 18:26:41 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1077) Cc: Alexey Tarasov Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:26:44 -0000 > 1) There is already an ATA command to report both physical and logical > sector sizes, but the disk lies - it always reports 512/512. Advanced Format disks reports 512, but there is another command in ATA = standard which can tell us if it uses 4k sector. > 2) The disk may have already been formatted on a system that doesn't > support 4k sectors, and may contain unaligned partitions and file > systems, which won't be visible if we forcibly and unconditionally > use 4k sectors. I mean that when I create *NEW* GPT scheme I can set up sector size = emulation. It will never touch existing unaligned partitions. -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(") From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 14:35:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4DEA106564A for ; Thu, 8 Apr 2010 14:35:19 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id A66B08FC17 for ; Thu, 8 Apr 2010 14:35:19 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id AB0AE1FFC51; Thu, 8 Apr 2010 14:35:18 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 8BF02844C6; Thu, 8 Apr 2010 16:35:18 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexey Tarasov References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> Date: Thu, 08 Apr 2010 16:35:18 +0200 In-Reply-To: (Alexey Tarasov's message of "Thu, 8 Apr 2010 18:26:41 +0400") Message-ID: <86eiiqt3kp.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:35:20 -0000 Alexey Tarasov writes: > Advanced Format disks reports 512, but there is another command in ATA > standard which can tell us if it uses 4k sector. Send me one and I'll look into it :) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 14:39:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAA18106566B; Thu, 8 Apr 2010 14:39:46 +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 78FDD8FC21; Thu, 8 Apr 2010 14:39:46 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2CF7F.dip.t-dialin.net [217.226.207.127]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id D87048442D1; Thu, 8 Apr 2010 16:39:39 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id EC2A7507B; Thu, 8 Apr 2010 16:39:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1270737577; bh=hLJDdclSZQN91spArM8qed/yuk34P300zTOngNWT3fs=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=G0vpTojOZkka3ro2h9GJgmdBaXHbgv+2oSYHZsLGNshcsDb4oUa4t41l+RTEjCslR s23AE38PIAWYE1XMr0rasHay97jJtfvRlhFEhUanG6sRA44dABbeO8ZhhfjK7Hkr2v zH0HFCzB9ZX2VD8yxYjvhAX5HIoP7NtMr56jaXcvAeCicFmEUG/OS5Sr4i1W49HSIj WBEXpxrzmrpx6pTwv1/elcwNdWRsHdkZOH+I5YAdSsQ2Dtb7aQVB1M/KF8AHvInnFE Fj50uu60YSflgjslx7z+gOFb0z1jAGYx7AZumvz4D/zQntk6YevxaAT5Tpo3uRVTTm QWrPFc7qKIwjA== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id o38EdaD3047706; Thu, 8 Apr 2010 16:39:36 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 08 Apr 2010 16:39:36 +0200 Message-ID: <20100408163936.137245fp5ycrre0w@webmail.leidinger.net> Date: Thu, 08 Apr 2010 16:39:36 +0200 From: Alexander Leidinger To: Dag-Erling =?utf-8?b?U23Dg8K4cmdyYXY=?= References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> <201004080727.21020.bruce@cran.org.uk> <4BBD7CDC.2070505@yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <20100408121500.13995d1eu7b9bt0k@webmail.leidinger.net> <86fx36up9e.fsf@ds4.des.no> <20100408155309.42884l21ogy7m7sw@webmail.leidinger.net> <86vdc2t4hs.fsf@ds4.des.no> In-Reply-To: <86vdc2t4hs.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: D87048442D1.3A80B X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.286, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, TW_GT 0.08, TW_JH 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1271342382.17624@f9xC2t94hCNKDPJiG+wipA X-EBL-Spam-Status: No Cc: Bruce Cran , freebsd-current@FreeBSD.ORG, freebsd-geom@FreeBSD.ORG, Teske , Randi Harper , "Andrey V. Elsukov" Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:39:47 -0000 Quoting Dag-Erling Sm=C3=83=C2=B8rgrav (from Thu, 08 Apr 2010 = =20 16:15:27 +0200): > Alexander Leidinger writes: >> Dag-Erling Sm=C3=B8rgrav writes: >> > There have been at least three or four attempts to do this in the >> > past. One of them was even fully funded by the FreeBSD Foundation. >> > They all failed. >> I was told a lot of people tried to make the WITH_CTF part working >> without the need to use -DWITH_CTF each time at the command line and >> failed. Nevertless I did it. So telling something is not possible >> because other people tried and failed is ridiculous. > > It's not ridiculous, it's experience. *Painful* experience over a > period of nearly 15 years. > >> BTW: I do not think you talk about a partition editor, but about the >> complete sysinstall. > > Yes and no. I'm talking about making the user interface pluggable, > i.e. run the same program (whether sysinstall or sade) with, say, an > ncurses interface on the console and a gtk interface in X. I did not suggest to run the same program and get different =20 interfaces. My suggestion was to have a backend-lib and a frontend. =20 The backend containing the "business-logic", and the frontend being =20 the presentation layer. If you want a GTK GUI, write a new frontend. In the case of sysinstall and sade, both use some kind of curses =20 interface, my suggestion was to the lib as they are both 2 different =20 kind of frontends (two different kinds of point of view regarding the =20 required functionality). I was misunderstanding your idea in the beginning, I was understanding =20 the description of jhb better. It surely is an applicable idea (and an =20 improvement to what we have currently), but it looks like it is =20 limiting what we could do with sade (the frontend part, not the =20 backend part) if it would be decoupled from sysinstall. Bye, Alexander. --=20 BOFH excuse #144: Too few computrons available http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 14:40:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C5E01065678 for ; Thu, 8 Apr 2010 14:40:53 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from relay.wahome.ru (relay.wahome.ru [95.211.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id D4DC08FC1F for ; Thu, 8 Apr 2010 14:40:52 +0000 (UTC) Received: from mmx.lexasoft.ru (mmx.lexasoft.ru [92.241.160.6]) by relay.wahome.ru (Postfix) with ESMTP id F07746B2161; Thu, 8 Apr 2010 18:37:54 +0400 (MSD) Received: from [10.100.0.2] (petrovich-telecom-gw.wahome.ru [77.91.225.38]) by mmx.lexasoft.ru (Postfix) with ESMTPSA id 4427F28491; Thu, 8 Apr 2010 18:40:51 +0400 (MSD) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=utf-8 From: Alexey Tarasov In-Reply-To: <86eiiqt3kp.fsf@ds4.des.no> Date: Thu, 8 Apr 2010 18:40:50 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <846676C4-C1B8-44DB-AA01-B664614DE59F@lexasoft.ru> References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> <86eiiqt3kp.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1077) Cc: Alexey Tarasov Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:40:53 -0000 http://www.wdc.com/wdproducts/library/WhitePapers/ENG/2579-771430.pdf > References > The ATA8-ACS and SBC-3 standards have provisions for a disk drive to = report Advanced Format sector sizes and other performance optimization = information. These standards are used for SATA, SAS, USB, and IEEE 1394 = based interface technologies. On 08.04.2010, at 18:35, Dag-Erling Sm=C3=B8rgrav wrote: > Alexey Tarasov writes: >> Advanced Format disks reports 512, but there is another command in = ATA >> standard which can tell us if it uses 4k sector. >=20 > Send me one and I'll look into it :) >=20 > DES > --=20 > Dag-Erling Sm=C3=B8rgrav - des@des.no > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(") From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 14:47:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA40E1065688 for ; Thu, 8 Apr 2010 14:47:52 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 61F088FC08 for ; Thu, 8 Apr 2010 14:47:51 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so1823778fgb.13 for ; Thu, 08 Apr 2010 07:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=mEuLsPZ1pnvTrCaFsEIX+rDJzyGFQCUz7bMHx5lfhpQ=; b=kxXBX99WLXB+6paIXEe9rKzfGaw/RuaGIda6otgKfo+dyPhHobj3D7vbGnJPTKdWnx nfdQOBQ7EHrgOxsI6rFtajmaIA3v5b3XbzcM85KSbD/IX4R+Gz5tKQjBcrBij+MPnku0 1HJFOeai2mhQ0RH05Sm6Byx4wVYTTsqsQMo2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=VWDHNz9dl2QUnGU/gPGdLedFFHChOdILSCxkqFkPsMtS1UbM6AwRyOHIAQqgDWzv58 prRHVhNUudsZhKXiNSbBLdg/StY4LiuAMtFO/A2qxyOY0ufJXuBMZRbR9IGPe76sOsEK Rab+Q7ZYeD8Oms3AX1gzq4YfJQMMalvfkc04M= Received: by 10.87.47.23 with SMTP id z23mr529334fgj.28.1270738070978; Thu, 08 Apr 2010 07:47:50 -0700 (PDT) Received: from beastie.micom.mng.net ([202.179.21.135]) by mx.google.com with ESMTPS id l12sm741285fgb.27.2010.04.08.07.47.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 08 Apr 2010 07:47:49 -0700 (PDT) Message-ID: <4BBDEC8F.9050803@gmail.com> Date: Thu, 08 Apr 2010 22:47:43 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.23 (X11/20091011) MIME-Version: 1.0 To: PseudoCylon References: <16641.96608.qm@web51806.mail.re2.yahoo.com> <4B9FA3E0.4050702@micom.mng.net> <633929.41041.qm@web51802.mail.re2.yahoo.com> <4BA22B8D.9030700@micom.mng.net> <375331.74876.qm@web51804.mail.re2.yahoo.com> <4BA38B26.6050208@micom.mng.net> <989377.89740.qm@web51802.mail.re2.yahoo.com> <4BAE01AC.7000509@gmail.com> <623907.37074.qm@web51803.mail.re2.yahoo.com> <4BB3575D.4040506@gmail.com> <87836.79143.qm@web51804.mail.re2.yahoo.com> <4BBB372C.1060302@gmail.com> <665283.95271.qm@web51802.mail.re2.yahoo.com> In-Reply-To: <665283.95271.qm@web51802.mail.re2.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ganbold Tsagaankhuu , freebsd-current@freebsd.org Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:47:53 -0000 Hi, PseudoCylon wrote: > Hi, > > Sorry for taking long to fix. Here is another patch. > > **But before trying it out, please check rev. of your system.** > > If you are using r206358 (15:29 UTC Apr. 7) or newer, the driver won't work. If you are using older system, please try this patch. > http://projects.nasreddine.com/projects/run/repository/revisions/mips1_fix/show/dev/usb/wlan > Only if_run.c is patched since last time. (click file name, then click "download") > > Ok, here it is: http://freebsd.pastebin.com/g2YBBDeG > If you are using r206358 or newer, please give me some time to fix. I'm stating it now. > > Is your kernel compiled with INVARIANTS option? > Tried, but if_arge panics at boot with INVARIANTS option. arge0: at mem 0x19000000-0x19000fff irq 2 on nexus0 panic: mtx_lock() of spin mutex arge mii lock @ /usr/mysrc/sys/mips/atheros/if_arge.c:554 thanks, Ganbold Ts > AK > > > > ----- Original Message ---- > >> From: Ganbold >> To: PseudoCylon >> Cc: freebsd-current@freebsd.org >> Sent: Tue, April 6, 2010 7:29:16 AM >> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless >> >> PseudoCylon wrote: >> ----- Original Message ---- >> >> >> >>> From: Ganbold < >>> >> href="mailto:ganbold@gmail.com">ganbold@gmail.com> >> >>> To: >>> >> PseudoCylon < >> href="mailto:moonlightakkiy@yahoo.ca">moonlightakkiy@yahoo.ca> >> >> Cc: >> href="mailto:freebsd-current@freebsd.org">freebsd-current@freebsd.org >> >> Sent: Wed, March 31, 2010 8:08:29 AM >> >>> Subject: Re: CALL for TEST >>> >> [HOSTAP] run(4) ralink usb wireless >> >>> Does stock run(4) >>> >> support hostap mode yet? >> >>> >>> >> No. There >> were some bugs and I thought I fixed them. So, I called for test. It seems the >> driver is working on x86, but not on mips. hostap mode should work on your other >> computer with i386. >> >> I'm still working on patch. It panics where >> there wasn't any changes made. Strange... >> >> >> > > Hi, > > Sorry, it looks like I missed some of your emails. > Please > >> let me know if you need any info from my >> side. >> > > thanks, > > Ganbold > > >> AK >> >> >> > > > __________________________________________________________________ > Looking for the perfect gift? Give the gift of Flickr! > > http://www.flickr.com/gift/ > > -- MONTANA: Where forty-three below keeps out the riff-raff. From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 14:50:18 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09E09106566B; Thu, 8 Apr 2010 14:50:18 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id B832B8FC1D; Thu, 8 Apr 2010 14:50:17 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id BA20A1FFC51; Thu, 8 Apr 2010 14:50:16 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 92F7B844C6; Thu, 8 Apr 2010 16:50:16 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Leidinger References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> <201004080727.21020.bruce@cran.org.uk> <4BBD7CDC.2070505@yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <20100408121500.13995d1eu7b9bt0k@webmail.leidinger.net> <86fx36up9e.fsf@ds4.des.no> <20100408155309.42884l21ogy7m7sw@webmail.leidinger.net> <86vdc2t4hs.fsf@ds4.des.no> <20100408163936.137245fp5ycrre0w@webmail.leidinger.net> Date: Thu, 08 Apr 2010 16:50:16 +0200 In-Reply-To: <20100408163936.137245fp5ycrre0w@webmail.leidinger.net> (Alexander Leidinger's message of "Thu, 08 Apr 2010 16:39:36 +0200") Message-ID: <86aatet2vr.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , freebsd-current@FreeBSD.ORG, freebsd-geom@FreeBSD.ORG, Teske , Randi Harper , "Andrey V. Elsukov" Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:50:18 -0000 Alexander Leidinger writes: > I did not suggest to run the same program and get different > interfaces. My suggestion was to have a backend-lib and a frontend. > The backend containing the "business-logic", and the frontend being > the presentation layer. What you call the presentation layer is actually 80% of the work. What you call the business logic already exists (libgeom). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 15:05:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFF8B106566B for ; Thu, 8 Apr 2010 15:05:41 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by mx1.freebsd.org (Postfix) with ESMTP id 72B648FC14 for ; Thu, 8 Apr 2010 15:05:41 +0000 (UTC) Received: by fxm25 with SMTP id 25so1812fxm.3 for ; Thu, 08 Apr 2010 08:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type; bh=7elZoEmDAi0tKthIfMOcH9KGCdHONe/W+AqdNzKXFHA=; b=W+ObPe4tct8QGCM0to4ICedvLBzJJ/wfEHyZ6ALTUWzZWUvAcKX9o2CZpWEitEQqnM S+HGz709xhFpQTUSe18VQcuPstgakzQ+pfp5qZZtfV9vs54JKJtOVoym4gcbBQT3rJlB 905LqNhYWF03SWudgG7t49xufHYkeXK2mcpAU= 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=ZuDD1S7627o63Y36xyrAaDzT/2LJJ+QcM+a46JgPZOt2qCfCNyw7BVyf3w21zouvXN Fpgnu6kADGsxmJ1dF03I4TE+k6ZzYU6p3y2fPMFAKxZkJ1A45d0JXKHovJUWYYshUrGY uh5RaIksErntIZ6/lGtGaRxRVV6J0jvyUd+cI= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.239.137.131 with HTTP; Thu, 8 Apr 2010 08:05:39 -0700 (PDT) In-Reply-To: References: <3bbf2fe11002200946h7480d203naabd7a49fd851f5a@mail.gmail.com> Date: Thu, 8 Apr 2010 17:05:39 +0200 X-Google-Sender-Auth: 363eb938774e9524 Received: by 10.239.134.148 with SMTP id 20mr29343hbz.42.1270739139875; Thu, 08 Apr 2010 08:05:39 -0700 (PDT) Message-ID: From: Attilio Rao To: Marcin Cieslak Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: ZFS DEADLKRES X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 15:05:42 -0000 2010/2/22 Marcin Cieslak : > > > > On Sat, 20 Feb 2010, Attilio Rao wrote: > >> 2010/2/18 Marcin Cieslak : >>> >>> My r203753 amd64 laptop falls into the deadlock situation >>> every night while running periodic daily script. I am pretty >>> certain this is related to ZFS. >>> >>> I have enabled DEADLKRES in the kernel. I even have >>> a separate dump partition (not used for swap). >> >> May you reproduce the bug with WITNESS? >> If you can, you should enable DEADLKRES too and once it panics let >> extract a textdump(4) with the following commands: >> bt, ps, show alllocks, show pcpu, allthreads > > Unfortunately, there is no way to write anything to disk. > All attempts to talk to the ata subsystem from ddb(4) > fail with EIO (probably timeout). This may be a false positive. May you please try the following patch and report if you can fix it does fix it or not?: http://www.freebsd.org/~attilio/Sandvine/deadlkres/deadlkres-blessed.diff Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 15:13:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4B291065672; Thu, 8 Apr 2010 15:13:01 +0000 (UTC) (envelope-from kris@pcbsd.org) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) by mx1.freebsd.org (Postfix) with ESMTP id 8FA028FC1B; Thu, 8 Apr 2010 15:13:01 +0000 (UTC) Received: from mail.ixsystems.com (localhost [127.0.0.1]) by mail.iXsystems.com (Postfix) with ESMTP id 2EFC8A664B9; Thu, 8 Apr 2010 07:53:58 -0700 (PDT) Received: from mail.iXsystems.com ([127.0.0.1]) by mail.ixsystems.com (mail.ixsystems.com [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16348-03; Thu, 8 Apr 2010 07:53:58 -0700 (PDT) Received: from [192.168.0.55] (unknown [75.131.46.136]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 04D46A66400; Thu, 8 Apr 2010 07:53:56 -0700 (PDT) Message-ID: <4BBDB5BC.3060002@pcbsd.org> Date: Thu, 08 Apr 2010 10:53:48 +0000 From: Kris Moore User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.8) Gecko/20100302 Thunderbird/3.0.3 MIME-Version: 1.0 To: Alexander Leidinger References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> <201004080727.21020.bruce@cran.org.uk> <4BBD7CDC.2070505@yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <20100408121500.13995d1eu7b9bt0k@webmail.leidinger.net> <86fx36up9e.fsf@ds4.des.no> <20100408155309.42884l21ogy7m7sw@webmail.leidinger.net> <86vdc2t4hs.fsf@ds4.des.no> <20100408163936.137245fp5ycrre0w@webmail.leidinger.net> In-Reply-To: <20100408163936.137245fp5ycrre0w@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Bruce Cran , freebsd-geom@FreeBSD.ORG, Teske , Randi Harper , freebsd-current@FreeBSD.ORG, "Andrey V. Elsukov" , =?UTF-8?B?RGFnLUVybGluZyBTbcODwrhyZ3Jhdg==?= Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 15:13:01 -0000 On 04/08/2010 14:39, Alexander Leidinger wrote: > Quoting Dag-Erling Smørgrav (from Thu, 08 Apr 2010 > 16:15:27 +0200): > >> Alexander Leidinger writes: >>> Dag-Erling Smørgrav writes: >>> > There have been at least three or four attempts to do this in the >>> > past. One of them was even fully funded by the FreeBSD Foundation. >>> > They all failed. >>> I was told a lot of people tried to make the WITH_CTF part working >>> without the need to use -DWITH_CTF each time at the command line and >>> failed. Nevertless I did it. So telling something is not possible >>> because other people tried and failed is ridiculous. >> >> It's not ridiculous, it's experience. *Painful* experience over a >> period of nearly 15 years. >> >>> BTW: I do not think you talk about a partition editor, but about the >>> complete sysinstall. >> >> Yes and no. I'm talking about making the user interface pluggable, >> i.e. run the same program (whether sysinstall or sade) with, say, an >> ncurses interface on the console and a gtk interface in X. > > I did not suggest to run the same program and get different > interfaces. My suggestion was to have a backend-lib and a frontend. > The backend containing the "business-logic", and the frontend being > the presentation layer. If you want a GTK GUI, write a new frontend. > In the case of sysinstall and sade, both use some kind of curses > interface, my suggestion was to the lib as they are both 2 different > kind of frontends (two different kinds of point of view regarding the > required functionality). > > I was misunderstanding your idea in the beginning, I was understanding > the description of jhb better. It surely is an applicable idea (and an > improvement to what we have currently), but it looks like it is > limiting what we could do with sade (the frontend part, not the > backend part) if it would be decoupled from sysinstall. > > Bye, > Alexander. > That's a pretty similar to the approach we've taken with our new backend in PC-BSD 8.x. The notable exception is that instead of just a lib, our backend is a complete program (written in sh), which performs scripted installs, and provides all the functionality for front-ends to query the system and present data to the end-user. This has a few advantages, in that the backend can be used stand-alone for scripted installations and also provide great flexibility to the front-end developer. They don't need to worry about performing any of the actual installation logic, they just provide a way for users to select their installation options, generate a configuration script, and let the backend run with it. -- Kris Moore PC-BSD Software iXsystems From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 15:24:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB603106564A for ; Thu, 8 Apr 2010 15:24:24 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout6.freenet.de (mout6.freenet.de [IPv6:2001:748:100:40::2:8]) by mx1.freebsd.org (Postfix) with ESMTP id 6F4A98FC1B for ; Thu, 8 Apr 2010 15:24:24 +0000 (UTC) Received: from [195.4.92.21] (helo=11.mx.freenet.de) by mout6.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #3) id 1Nztag-0002g1-Ks; Thu, 08 Apr 2010 17:24:22 +0200 Received: from p57ae1e92.dip0.t-ipconnect.de ([87.174.30.146]:37615 helo=ernst.jennejohn.org) by 11.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #3) id 1Nztag-0007U6-DW; Thu, 08 Apr 2010 17:24:22 +0200 Date: Thu, 8 Apr 2010 17:24:21 +0200 From: Gary Jennejohn To: Alexey Tarasov Message-ID: <20100408172421.62d73a90@ernst.jennejohn.org> In-Reply-To: <846676C4-C1B8-44DB-AA01-B664614DE59F@lexasoft.ru> References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> <86eiiqt3kp.fsf@ds4.des.no> <846676C4-C1B8-44DB-AA01-B664614DE59F@lexasoft.ru> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= , freebsd-current@freebsd.org Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 15:24:24 -0000 On Thu, 8 Apr 2010 18:40:50 +0400 Alexey Tarasov wrote: > http://www.wdc.com/wdproducts/library/WhitePapers/ENG/2579-771430.pdf > > > References > > The ATA8-ACS and SBC-3 standards have provisions for a disk drive to report Advanced Format sector sizes and other performance optimization information. These standards are used for SATA, SAS, USB, and IEEE 1394 based interface technologies. > This is apparently the Long Physical Sector features set. The question is whether it's been implemented. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 15:35:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21B261065673 for ; Thu, 8 Apr 2010 15:35:39 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id D51568FC16 for ; Thu, 8 Apr 2010 15:35:38 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:41e8:4158:889c:9c05] (unknown [IPv6:2001:7b8:3a7:0:41e8:4158:889c:9c05]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 881515C59; Thu, 8 Apr 2010 17:35:36 +0200 (CEST) Message-ID: <4BBDF7D3.3050300@andric.com> Date: Thu, 08 Apr 2010 17:35:47 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.2pre) Gecko/20100404 Lanikai/3.1b2pre MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> <86eiiqt3kp.fsf@ds4.des.no> <846676C4-C1B8-44DB-AA01-B664614DE59F@lexasoft.ru> <20100408172421.62d73a90@ernst.jennejohn.org> In-Reply-To: <20100408172421.62d73a90@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?av?= , =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgr?=, freebsd-current@freebsd.org, Alexey Tarasov Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 15:35:39 -0000 On 2010-04-08 17:24, Gary Jennejohn wrote: >>> References >>> The ATA8-ACS and SBC-3 standards have provisions for a disk drive to report Advanced Format sector sizes and other performance optimization information. These standards are used for SATA, SAS, USB, and IEEE 1394 based interface technologies. >> > > This is apparently the Long Physical Sector features set. The question is > whether it's been implemented. Isn't this already done? At least it looks like it: http://svn.freebsd.org/viewvc/base?view=revision&revision=198897 It might even have been MFC'd... :) From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 16:47:05 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 337EA106564A for ; Thu, 8 Apr 2010 16:47:05 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 058768FC15 for ; Thu, 8 Apr 2010 16:47:04 +0000 (UTC) Received: by pwi9 with SMTP id 9so2256456pwi.13 for ; Thu, 08 Apr 2010 09:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=mjrSGHXgsL15e/hRblbHDTY3t+aQqBA2yIwhLs2kqlU=; b=otr9Ste7dTeCjIsbckee8/q11XlYst/zGp6XxnKHeb6a7+ZEB49PDeJ/pvVuI5BKyL D4EqrVBvSHIOgMS4tCh9OGHwDQwiQD09iOZw4gw/LsSceDODtQbiEPfCvkMZN56ywMll Cco5aWlkrUQjLnLxbwjAfhsFttMwFMSt/wcY0= 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=rtzAshZ3bodKknZZEFEYnBkNq6nxFyN+uLIqBjvZaScZNCe2y3wGQPxz1m5qjxjNYF 9vTCqQmuyIRUJh/DDrQoGnwBCgT2pnjQegDvrdtxtYQlzXyq5gFciRnRqXRbT5WceG5e q9Zf6oGKrEPkZX9IM/LLk6A6q8SEV+4gabGDU= MIME-Version: 1.0 Received: by 10.143.34.1 with HTTP; Thu, 8 Apr 2010 09:47:04 -0700 (PDT) In-Reply-To: References: <20100407173334.GC76941@dan.emsphone.com> Date: Thu, 8 Apr 2010 11:47:04 -0500 Received: by 10.142.209.8 with SMTP id h8mr290772wfg.82.1270745224681; Thu, 08 Apr 2010 09:47:04 -0700 (PDT) Message-ID: From: "Sam Fourman Jr." To: krad Content-Type: text/plain; charset=ISO-8859-1 Cc: Freddie Cash , Dan Nelson , current@freebsd.org Subject: Re: When will we can use ZFS v24? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 16:47:05 -0000 > ZFS is still currently in heavy development so it might happen. Having siad > that it looks like oracle have totally buggered it up for everyone with > their retroactive licenses. I hope the CDL was tight enough that stuff wont > have to get pulled from freebsd is that even possible with CDDL? Sam Fourman Jr. Fourman Networks From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 16:48:08 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A47981065675; Thu, 8 Apr 2010 16:48:08 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from crivens.kernel32.de (crivens.asm68k.org [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0858FC17; Thu, 8 Apr 2010 16:48:08 +0000 (UTC) Received: from www.terrorteam.de (localhost [127.0.0.1]) by crivens.kernel32.de (Postfix) with ESMTP id ED551B037F; Thu, 8 Apr 2010 18:30:54 +0200 (CEST) MIME-Version: 1.0 Date: Thu, 08 Apr 2010 18:30:54 +0200 From: Marian Hettwer To: Kris Moore In-Reply-To: <4BBDB5BC.3060002@pcbsd.org> References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> <201004080727.21020.bruce@cran.org.uk> <4BBD7CDC.2070505@yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <20100408121500.13995d1eu7b9bt0k@webmail.leidinger.net> <86fx36up9e.fsf@ds4.des.no> <20100408155309.42884l21ogy7m7sw@webmail.leidinger.net> <86vdc2t4hs.fsf@ds4.des.no> <20100408163936.137245fp5ycrre0w@webmail.leidinger.net> <4BBDB5BC.3060002@pcbsd.org> Message-ID: X-Sender: mh@kernel32.de User-Agent: RoundCube Webmail/0.1-rc2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Cc: Bruce Cran , freebsd-geom@FreeBSD.ORG, =?UTF-8?Q?Dag-Erling_Sm=C3=83=C2=B8rgrav?= , Teske , Randi Harper , freebsd-current@FreeBSD.ORG, "Andrey V. Elsukov" , Alexander Leidinger Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 16:48:08 -0000 On Thu, 08 Apr 2010 10:53:48 +0000, Kris Moore wrote: It's not nice to hijack a topic, but this is way to interesting for me, so I do it anway :) > This has a few advantages, in that the backend can be used stand-alone > for scripted installations and also provide great flexibility > to the front-end developer. They don't need to worry about performing > any of the actual installation logic, they just provide a way > for users to select their installation options, generate a configuration > script, and let the backend run with it. scripted installation! Are you able to do a pxeboot, nfsroot and then scripted installation? Are those scripts portable to FreeBSD or PC-BSD only? Could you give me a hint where to find them? TIA, Marian From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 16:49:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B5C2106566C; Thu, 8 Apr 2010 16:49:09 +0000 (UTC) (envelope-from kris@pcbsd.org) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) by mx1.freebsd.org (Postfix) with ESMTP id 74FA08FC1E; Thu, 8 Apr 2010 16:49:09 +0000 (UTC) Received: from mail.ixsystems.com (localhost [127.0.0.1]) by mail.iXsystems.com (Postfix) with ESMTP id 364F5A664A9; Thu, 8 Apr 2010 09:49:07 -0700 (PDT) Received: from mail.iXsystems.com ([127.0.0.1]) by mail.ixsystems.com (mail.ixsystems.com [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 17854-10; Thu, 8 Apr 2010 09:49:07 -0700 (PDT) Received: from [192.168.0.55] (unknown [75.131.46.136]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id C640DA66457; Thu, 8 Apr 2010 09:49:05 -0700 (PDT) Message-ID: <4BBDD0B9.3060902@pcbsd.org> Date: Thu, 08 Apr 2010 12:48:57 +0000 From: Kris Moore User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.8) Gecko/20100302 Thunderbird/3.0.3 MIME-Version: 1.0 To: Marian Hettwer References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> <201004080727.21020.bruce@cran.org.uk> <4BBD7CDC.2070505@yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <20100408121500.13995d1eu7b9bt0k@webmail.leidinger.net> <86fx36up9e.fsf@ds4.des.no> <20100408155309.42884l21ogy7m7sw@webmail.leidinger.net> <86vdc2t4hs.fsf@ds4.des.no> <20100408163936.137245fp5ycrre0w@webmail.leidinger.net> <4BBDB5BC.3060002@pcbsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Bruce Cran , freebsd-geom@FreeBSD.ORG, =?UTF-8?B?RGFnLUVybGluZyBTbcODwrhyZ3Jhdg==?= , Teske , Randi Harper , freebsd-current@FreeBSD.ORG, "Andrey V. Elsukov" , Alexander Leidinger Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 16:49:09 -0000 On 04/08/2010 16:30, Marian Hettwer wrote: > On Thu, 08 Apr 2010 10:53:48 +0000, Kris Moore wrote: > > It's not nice to hijack a topic, but this is way to interesting for me, so > I do it anway :) > :) I didn't mean to hijack either, was trying to discuss advantage of having backend as a executable vs a library which can't be used standalone without front-end. This would in effect lock you completely into front-end logic, which may not meet a users specific needs, even though backend can do what user wants. >> This has a few advantages, in that the backend can be used stand-alone >> for scripted installations and also provide great flexibility >> to the front-end developer. They don't need to worry about performing >> any of the actual installation logic, they just provide a way >> for users to select their installation options, generate a configuration >> > >> script, and let the backend run with it. >> > scripted installation! > Are you able to do a pxeboot, nfsroot and then scripted installation? > Are those scripts portable to FreeBSD or PC-BSD only? > Could you give me a hint where to find them? > > TIA, > Marian > Correct, every install it does is a fully-scripted installation, and it can be used with pxeboot, or in a custom mfsroot image easily. Supports ZFS, glabel, gmirror, geli, GPT, gpart, vanilla FreeBSD installs, etc. http://trac.pcbsd.org/browser/pcbsd/trunk/pc-sysinstall Checkout examples/README for all the gory details of config-file generation. One caveat, the version in trunk is being very actively worked on by myself at the moment to prepare for 8.1, needs more docs, etc ;) -- Kris Moore PC-BSD Software iXsystems From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 14:51:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C677D1065677; Thu, 8 Apr 2010 14:51:52 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id A7C958FC17; Thu, 8 Apr 2010 14:51:52 +0000 (UTC) Received: from [66.92.34.148] (port=53761 helo=dsl092-034-148.lax1.dsl.speakeasy.net) by postoffice.vicor.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.43) id 1Nzt58-00071e-C1; Thu, 08 Apr 2010 07:51:51 -0700 From: Devin Teske To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86r5mqt4aj.fsf@ds4.des.no> References: <55861270658151@web135.yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <201004080849.12151.jhb@freebsd.org> <86r5mqt4aj.fsf@ds4.des.no> Content-Type: text/plain; charset=utf-8 Organization: Vicor, Inc Date: Thu, 08 Apr 2010 07:51:45 -0700 Message-Id: <1270738305.29753.39.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-41.el4) Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 686168b083bebe0229d0cf78d78c0aff X-Scan-Host: postoffice.vicor.com X-Mailman-Approved-At: Thu, 08 Apr 2010 17:02:47 +0000 Cc: Bruce Cran , freebsd-geom@freebsd.org, Randi Harper , freebsd-current@freebsd.org, "Andrey V. Elsukov" , Alexander Leidinger Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:51:52 -0000 I too love the idea of "generalizing" (abstracting) the dirty-work to a set of libraries and leaving the user interface up to the userland applications. Thusly, an app in /usr/X11R6/bin can use said libraries in plugging in functionality to an X11 GUI application, meanwhile an app in /bin or /sbin (presumably, since we're talking about low-level system utilities) could use the same libraries for plugging the same functionality into a command-line interface (beit command-driven or ncurses/libdialog driven). However, I'm still wondering what that change would mean to our beloved sysinstall when it comes time to place sysinstall into the mfsroot for the CD-ROM installer. Currently, the mfsroot contains very little in the ways of ELF binaries: -sh, [ (test), arp, boot_crunch, camcontrol, cpio, dhclient, find, fsck_4.2bsd, fsck_ffs, fsck_ufs, gunzip, gzip, hostname, ifconfig, minigzip, mount_nfs, newfs, ppp, pwd, rm, route, rtsol, sed, sh, sysinstall, test, tunefs, usbconfig, and zcat Every last one of those is (a) statically linked and (b) hard-linked to one-another (really, they are all hard-links to boot_crunch which is a by-product of crunchgen(1)). What might the landscape look like if we move down the road toward separating the back-end from the front-end? Presumably though, we could simply put the bits back together, no? Currently, the following libraries are slurped into the crunchgen configuration: -ll, -ledit, -lutil, -lmd, -lcrypt, -lftpio, -lz, -lnetgraph, -ldialog, -lncurses, -ldisk, -lcam, -lsbuf, -lufs, -ldevinfo, -lbsdxml, -larchive, -lbz2, -lusb, and -ljail Which I show to be these files in RELENG_8: /usr/lib/libl.a /usr/lib/libedit.a /usr/lib/libutil.a /usr/lib/libmd.a /usr/lib/libcrypt.a /usr/lib/libftpio.a /usr/lib/libz.a /usr/lib/libnetgraph.a /usr/lib/libdialog.a /usr/lib/libncurses.a /usr/lib/libdisk.a /usr/lib/libcam.a /usr/lib/libsbuf.a /usr/lib/libufs.a /usr/lib/libdevinfo.a /usr/lib/libbsdxml.a /usr/lib/libarchive.a /usr/lib/libbz2.a /usr/lib/libusb.a /usr/lib/libjail.a I think I just answered my own question... We should have no problem re-incorporating any heretofore developed libraries (for the back-end functionality) *back into* the crunchgen (1)'ed binaries. In fact, if we, say for example, developed /usr/lib/libsysinstall.a and /usr/lib/libsade.a , we could then simply just patch `/usr/src/release/i386/boot_crunch.conf' in the following manner: [dteske@push800 /usr/src/release/i386]$ diff -u boot_crunch.conf{.bak,} --- boot_crunch.conf.bak 2010-04-08 07:10:49.000000000 -0700 +++ boot_crunch.conf 2010-04-08 07:10:27.000000000 -0700 @@ -46,3 +46,4 @@ libs -ll -ledit -lutil -lmd -lcrypt -lftpio -lz -lnetgraph libs -ldialog -lncurses -ldisk -lcam -lsbuf -lufs -ldevinfo libs -lbsdxml -larchive -lbz2 -lusb -ljail +libs -lsysinstall -lsade Assuming of course that `release' (and intrinsically `buildworld') is made to generate the libraries at /R/stage/trees/base/usr/lib/libsysinstall.a and /R/stage/trees/base/usr/lib/libsade.a (and respectively for `buildworld', /usr/obj/usr/src/tmp/usr/lib/libsysinstall.a and /usr/obj/usr/src/tmp/usr/lib/libsade.a). So, I guess my fears of "mucking up" the install environment are unfounded. All-in-all, I'm right there with y'all on the idea of separating the front-end from the back-end. It needs to be done (and will open up a flurry of new installer interfaces and utilities that require low-end stuff usually own made-available by sysinstall internals). -- Devin On Thu, 2010-04-08 at 16:19 +0200, Dag-Erling Sm=C3=B8rgrav wrote: > John Baldwin writes: > > Dag-Erling Sm=C3=B8rgrav writes: > > > My suggestion is to add a "sysinstall mode" to sade where it > > > operates under certain (minor) constraints and reports what it did > > > in a format that sysinstall can parse, so sysinstall can just > > > fork-exec sade instead of duplicating the code. > > Actually, I would rather have sysinstall just invoke sade to do the > > disk related stuff. >=20 > ...which is exactly what I said - but in the sysinstall case, you may > want to ask some additional questions ("are you sure you want to proceed > without a swap partition?") or place some additional constraints (such > as "don't allow the user to mount something on top of /mnt or /rescue"), > and sysinstall needs to know the outcome. >=20 > DES --=20 Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <- From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 14:51:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28B1B1065670; Thu, 8 Apr 2010 14:51:53 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id 07A7E8FC19; Thu, 8 Apr 2010 14:51:53 +0000 (UTC) Received: from [66.92.34.148] (port=53729 helo=dsl092-034-148.lax1.dsl.speakeasy.net) by postoffice.vicor.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.43) id 1Nzsei-0006Zn-C0; Thu, 08 Apr 2010 07:24:30 -0700 From: Devin Teske To: Rui Paulo In-Reply-To: <2FEF9866-2B2E-4AAC-B504-02CF1537AEC0@freebsd.org> References: <55861270658151@web135.yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <201004080849.12151.jhb@freebsd.org> <2FEF9866-2B2E-4AAC-B504-02CF1537AEC0@freebsd.org> Content-Type: text/plain; charset=utf-8 Organization: Vicor, Inc Date: Thu, 08 Apr 2010 07:24:27 -0700 Message-Id: <1270736667.29753.14.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-41.el4) Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 69742ae7263525fe64d4e6a2add40d07 X-Scan-Host: postoffice.vicor.com X-Mailman-Approved-At: Thu, 08 Apr 2010 17:05:29 +0000 Cc: Bruce Cran , freebsd-current@freebsd.org, freebsd-geom@freebsd.org, Randi Harper , "Andrey V. Elsukov" , Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= , Alexander Leidinger Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:51:53 -0000 (( wishing that I hadn't un-CC'd the group on earlier e-mails )) Some concerns that I have with separating the code into a back-end versus front-end... 1. Is it currently the idea that -- when it comes down to the crunchgen stuff -- we are going to re-work the code that generates the non-shared binaries for mfsroot? or move away from the crunchgen/mfsroot paradigm? 2. If moving away from crunchgen/mfsroot, ... are we effectively making the statement that we no longer "support" installing FreeBSD on your floppy-enabled kitchen toaster? I'm not saying that there's an overwhelming need to retain the ability to install FreeBSD via floppy, ... but it uber-legacy support is something to be proud-of (just as lack-thereof could perhaps be something to be ashamed of -- I can fall into either camp channeling visions of Steve-Jobs-style mac-like shunning of the floppy drive or even Bill Gates almost sickening legacy- support of DOS). 3. We could abandon chrunchgen/mfsroot and simply load up all the back- end bits with the front-end bits for sysinstall to function in the installer environment ... but my quarrel is ... will it still fit on a floppy? if not, are we prepared to deprecate that? otherwise, does anyone care that the installer environment will be changing from a collection of staticallly-linked binaries to a "mess" ? I actually have a really nifty idea for deprecating mfsroot... and that's to start using syslinux as the boot-loader (which as of version 3.84 supports booting *.iso files). We're doing that in our company now... we have a CD-ROM that boots SYSLINUX and displays a menu with many options (among them "FreeBSD"). Selecting "FreeBSD" from the menu uses SYSLINUX's "memdisk" module to then boot `mdroot.iso' which essentially an `mfsroot'. The benefit here is that the `mdroot.iso' can be built cross-platform (matters not if you download our CVS tree to a Linux box or FreeBSD box... as long as you have `mkisofs' you can "compile" the disc and all incumbent file systems). The further beauty of this method is that the resultant mdroot.iso can be large (currently 14MB in our company ... but that's only because it contains two monolithic custom kernels which -- because we have a custom boot loader that allows us to cycle through any number of kernels at boot time to select the proper one for the hardware in question). -- Devin On Thu, 2010-04-08 at 15:08 +0100, Rui Paulo wrote: > On 8 Apr 2010, at 13:49, John Baldwin wrote: >=20 > > On Thursday 08 April 2010 5:05:34 am Dag-Erling Sm=C3=B8rgrav wrote: > >> Alexander Leidinger writes: > >>> Please consider using SVN instead. A lot more users will be able to > >>> check out from there. > >>=20 > >> We don't grant non-committers access to the Subversion repo. > >>=20 > >>> It looks like other people had a look at sysinstall, not at sade. As > >>> sysinstall is supposed to be used at installation time, and the inten= t > >>> for sade was to offer the functionality (or more) of the part of > >>> sysinstall which is useful after installation (and to prevent admins > >>> from using sysinstall after the installation to prevent some unwanted > >>> foot-shooting), I do not think that we need to think about a strong > >>> lock between sysinstall and sade. > >>=20 > >> Yes we do. Otherwise we'll just end up back where we are today, where > >> if you want anything more complicated than a single-disk install you > >> have to drop into the fixit shell and do it manually before running th= e > >> installation procedure. Anythig that sade can do, we want sysinstall = to > >> do as well, and we don't want to implement everything twice. > >>=20 > >> My suggestion is to add a "sysinstall mode" to sade where it operates > >> under certain (minor) constraints and reports what it did in a format > >> that sysinstall can parse, so sysinstall can just fork-exec sade inste= ad > >> of duplicating the code. > >=20 > > Actually, I would rather have sysinstall just invoke sade to do the dis= k=20 > > related stuff. Also, I think sysinstall should allow for a "back-door"= mode=20 > > where a user can setup partitions however they like and mount them at /= mnt and=20 > > then let sysinstall use the setup the user created. This will allow us= ers to=20 > > setup more complex setups that sysinstall/sade do not currently support= and=20 > > allow sade to focus on simpler, common usage cases w/o having to handle= =20 > > painful edge cases. It would also allow for new modules to be added to= sade=20 > > over time w/o requiring it to support every possible disk layout from t= he=20 > > beginning. >=20 > I couldn't agree more. >=20 > Regards, > -- > Rui Paulo >=20 --=20 Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <- From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 17:01:54 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEB2D106566B; Thu, 8 Apr 2010 17:01:54 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id AA1EC8FC0A; Thu, 8 Apr 2010 17:01:54 +0000 (UTC) Received: from [66.92.34.148] (port=54183 helo=dsl092-034-148.lax1.dsl.speakeasy.net) by postoffice.vicor.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.43) id 1Nzv6n-00010X-LI; Thu, 08 Apr 2010 10:01:39 -0700 From: Devin Teske To: Kris Moore In-Reply-To: <4BBDD0B9.3060902@pcbsd.org> References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> <201004080727.21020.bruce@cran.org.uk> <4BBD7CDC.2070505@yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <20100408121500.13995d1eu7b9bt0k@webmail.leidinger.net> <86fx36up9e.fsf@ds4.des.no> <20100408155309.42884l21ogy7m7sw@webmail.leidinger.net> <86vdc2t4hs.fsf@ds4.des.no> <20100408163936.137245fp5ycrre0w@webmail.leidinger.net> <4BBDB5BC.3060002@pcbsd.org> <4BBDD0B9.3060902@pcbsd.org> Content-Type: text/plain Organization: Vicor, Inc Date: Thu, 08 Apr 2010 10:01:37 -0700 Message-Id: <1270746097.29753.106.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-41.el4) Content-Transfer-Encoding: 7bit X-Scan-Signature: 69742ae7263525fe64d4e6a2add40d07 X-Scan-Host: postoffice.vicor.com X-Mailman-Approved-At: Thu, 08 Apr 2010 17:10:59 +0000 Cc: Bruce Cran , freebsd-geom@FreeBSD.ORG, Dag-Erling =?ISO-8859-1?Q?Sm=C3=B8rgrav?= , Randi Harper , freebsd-current@FreeBSD.ORG, "Andrey V. Elsukov" , Alexander Leidinger , Marian Hettwer Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 17:01:54 -0000 Randi and I were discussion the possibility of having sysinstall "remember" what you did and then able to write out a suitable `install.cfg' file that could be subsequently used to perform a human- less automated install with the same settings. To expand a little on that... I'd like to draw a similarity to AppleScript. If you are familiar with AppleScript, you know that one can launch on Macintoshes (going back as far as Mac OS 7.0.1) an application known as the "Script Editor" which had a "Record" button in the [then] top-left corner of the window. After clicking that "Record" button, the system then recorded what you did (including in the Desktop [Finder] and other 3rd-party programs) and saved a series of scripted commands which could simply be "Run" (or optionally saved into an executable script) to reproduce everything you did at-once. The way that this worked was by way of the developer "plugging in" specific resources (if you're familiar with the ol' days, you'll undoubtedly remember ResEdit -- specifically, a developer would add an 'aete' resource to the RSRC fork of the HFS file structure (among others). Then, when a scriptable-action was performed within the application, rather than calling some internally obscure sub-routine to perform the task, the developer would have the application actually send an AppleScript event to the MacOS which then sent it back to the application. Therefore, when the ScriptEditor is "recording", what it records is the events being passed from the application to itself as you go about clicking, dragging and typing things. It is in this manner that I think we would be best served in contemplating a "self-scripting" engine. That is to say, that -- altogether now -- we: a. separate the GUI front-end from the actual tasks that need to be performed (back-end; for example, tasks to partition disks, perform newfs, etc. etc.) b. have either all commands in the library pass through a "dispatcher" or only export a single dispatcher function from the library (requiring all "commands" to pass through this single function) Then it would then (I perceive) perhaps become a trivial task to have the dispatcher "record" the events. Another benefit of this would be that it wouldn't matter whom or what performed anything at all... there would be a mechanism for recording what was done regardless. And thus, we would usher in the age of being even the lay user being able to script the installer to do his/her bidding. No? -- Devin On Thu, 2010-04-08 at 12:48 +0000, Kris Moore wrote: > On 04/08/2010 16:30, Marian Hettwer wrote: > > On Thu, 08 Apr 2010 10:53:48 +0000, Kris Moore wrote: > > > > It's not nice to hijack a topic, but this is way to interesting for me, so > > I do it anway :) > > > :) I didn't mean to hijack either, was trying to discuss advantage of > having backend > as a executable vs a library which can't be used standalone without > front-end. > This would in effect lock you completely into front-end logic, which may > not meet > a users specific needs, even though backend can do what user wants. > > >> This has a few advantages, in that the backend can be used stand-alone > >> for scripted installations and also provide great flexibility > >> to the front-end developer. They don't need to worry about performing > >> any of the actual installation logic, they just provide a way > >> for users to select their installation options, generate a configuration > >> > > > >> script, and let the backend run with it. > >> > > scripted installation! > > Are you able to do a pxeboot, nfsroot and then scripted installation? > > Are those scripts portable to FreeBSD or PC-BSD only? > > Could you give me a hint where to find them? > > > > TIA, > > Marian > > > > Correct, every install it does is a fully-scripted installation, and > it can be used with pxeboot, or in a custom mfsroot image easily. > Supports ZFS, glabel, gmirror, geli, GPT, gpart, vanilla FreeBSD > installs, etc. > > http://trac.pcbsd.org/browser/pcbsd/trunk/pc-sysinstall > > Checkout examples/README for all the gory details of config-file > generation. > > One caveat, the version in trunk is being very actively worked on by > myself at the > moment to prepare for 8.1, needs more docs, etc ;) > -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <- From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 18:03:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F56C106566B; Thu, 8 Apr 2010 18:03:40 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id B81048FC12; Thu, 8 Apr 2010 18:03:39 +0000 (UTC) Received: by qyk11 with SMTP id 11so1791273qyk.13 for ; Thu, 08 Apr 2010 11:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Vdy2xzS0Nuv186QeGmCiyafGhTCP8sEhkKK3MKzpD2k=; b=V+An6HkQe5gvd9H5syzzd6qONwj/XvUUucf9fRY2DjiHzWZQ5ehKa46DGo571G2FfQ IElVf05oB3RErv0+NJG+j2wOi/BYW8hRc7i8ZZG/H0GVso/IO6QgrO1YpDqWMn4dW7e0 fkokxZRAJrOB+zHNwxhzx7PeKeeLh3/TKoR7o= 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=DY4SW7Urxh2PD/ECY08611TauT/G2QUqkouPSym7rxJb9oLvRJVYU17/XOErJM/HzO JeAMB4zz0BsfhjaHJrvQO1TO755DmZOn9KRalOElInokyW8HE9wI5RyGJVDmtemH6vF/ yUEfZTv2zz0aKAnsfcWABuaOEykUt0a4u5Pzo= MIME-Version: 1.0 Received: by 10.229.33.72 with HTTP; Thu, 8 Apr 2010 11:03:37 -0700 (PDT) In-Reply-To: <86r5mqt4aj.fsf@ds4.des.no> References: <55861270658151@web135.yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <201004080849.12151.jhb@freebsd.org> <86r5mqt4aj.fsf@ds4.des.no> Date: Thu, 8 Apr 2010 11:03:37 -0700 Received: by 10.229.241.82 with SMTP id ld18mr51884qcb.60.1270749818090; Thu, 08 Apr 2010 11:03:38 -0700 (PDT) Message-ID: From: Garrett Cooper To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , freebsd-geom@freebsd.org, Teske , Randi Harper , freebsd-current@freebsd.org, "Andrey V. Elsukov" , Alexander Leidinger Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 18:03:40 -0000 2010/4/8 Dag-Erling Sm=F8rgrav : > John Baldwin writes: >> Dag-Erling Sm=F8rgrav writes: >> > My suggestion is to add a "sysinstall mode" to sade where it >> > operates under certain (minor) constraints and reports what it did >> > in a format that sysinstall can parse, so sysinstall can just >> > fork-exec sade instead of duplicating the code. >> Actually, I would rather have sysinstall just invoke sade to do the >> disk related stuff. > > ...which is exactly what I said - but in the sysinstall case, you may > want to ask some additional questions ("are you sure you want to proceed > without a swap partition?") or place some additional constraints (such > as "don't allow the user to mount something on top of /mnt or /rescue"), > and sysinstall needs to know the outcome. If the user shoots him or herself in the foot, that's their own problem. They should at least read hier(7) or ask a question on questions@ beforehand. As long as the auto-partitioner is correct, it's fine. Complicating the tool with a lot of unnecessary criteria will just produce unnecessary bloat. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 18:27:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6DD910656BD; Thu, 8 Apr 2010 18:27:36 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 6C4068FC25; Thu, 8 Apr 2010 18:27:36 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 1FE571FFC22; Thu, 8 Apr 2010 18:27:35 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 2A432844A8; Thu, 8 Apr 2010 20:27:03 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Garrett Cooper References: <55861270658151@web135.yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <201004080849.12151.jhb@freebsd.org> <86r5mqt4aj.fsf@ds4.des.no> Date: Thu, 08 Apr 2010 20:27:03 +0200 In-Reply-To: (Garrett Cooper's message of "Thu, 8 Apr 2010 11:03:37 -0700") Message-ID: <86sk75ol54.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , freebsd-geom@freebsd.org, Teske , Randi Harper , freebsd-current@freebsd.org, "Andrey V. Elsukov" , Alexander Leidinger Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 18:27:36 -0000 Garrett Cooper writes: > If the user shoots him or herself in the foot, that's their own > problem. That kind of attitude is why people choose Linux over FreeBSD... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 18:15:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75542106564A; Thu, 8 Apr 2010 18:15:41 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id E43FE8FC13; Thu, 8 Apr 2010 18:15:40 +0000 (UTC) Received: by qyk11 with SMTP id 11so1803844qyk.13 for ; Thu, 08 Apr 2010 11:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0fOIlXbPh+qpJ4z1xcRrCH0I8dZGNaDwjo2/LDEsacs=; b=ElhU+XOXcFNspsPRaPI95Mw18wX+GwV589YHCe/PalztPCH5kGf+YDd+Zr9hgihBGS ZTGaJ1jQMA+22FBCpvPcsy9TeLC4tY1CqMTWKu2vzdMIkuOar0rD/mcDDAiKIvBW+Hk9 5XYBOnnlKqkTAlYBTdcdPRWylk20xUKaZWycs= 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=YI+5521QKSsii7fIUTAQPIC15Xq2QPoKoQ0DJheClAGzNNEakqn8uYqesV2MH6WB5o iAp3Xr3hmwj2UIPpcFyL3/7zlgYDjHhBnGAp2Ggpmcof+isiBz6YgaklyvA+r6npm/8g otKGq+QX467af72dpYkXRNC7V/VqNN1TkKbyI= MIME-Version: 1.0 Received: by 10.229.33.72 with HTTP; Thu, 8 Apr 2010 11:15:36 -0700 (PDT) In-Reply-To: <1270746097.29753.106.camel@localhost.localdomain> References: <55861270658151@web135.yandex.ru> <20100408121500.13995d1eu7b9bt0k@webmail.leidinger.net> <86fx36up9e.fsf@ds4.des.no> <20100408155309.42884l21ogy7m7sw@webmail.leidinger.net> <86vdc2t4hs.fsf@ds4.des.no> <20100408163936.137245fp5ycrre0w@webmail.leidinger.net> <4BBDB5BC.3060002@pcbsd.org> <4BBDD0B9.3060902@pcbsd.org> <1270746097.29753.106.camel@localhost.localdomain> Date: Thu, 8 Apr 2010 11:15:36 -0700 Received: by 10.229.104.195 with SMTP id q3mr639347qco.56.1270750536778; Thu, 08 Apr 2010 11:15:36 -0700 (PDT) Message-ID: From: Garrett Cooper To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 08 Apr 2010 18:45:13 +0000 Cc: Bruce Cran , freebsd-geom@freebsd.org, Alexander Leidinger , Randi Harper , freebsd-current@freebsd.org, "Andrey V. Elsukov" , =?ISO-8859-1?Q?Dag=2DErling_Sm=C3=B8rgrav?= , Marian Hettwer , Kris Moore Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 18:15:41 -0000 On Thu, Apr 8, 2010 at 10:01 AM, Devin Teske wrote: > Randi and I were discussion the possibility of having sysinstall > "remember" what you did and then able to write out a suitable > `install.cfg' file that could be subsequently used to perform a human- > less automated install with the same settings. [...] > On Thu, 2010-04-08 at 12:48 +0000, Kris Moore wrote: >> On 04/08/2010 16:30, Marian Hettwer wrote: >> > On Thu, 08 Apr 2010 10:53:48 +0000, Kris Moore =A0wrot= e: >> > >> > It's not nice to hijack a topic, but this is way to interesting for me= , so >> > I do it anway :) >> > >> :) I didn't mean to hijack either, was trying to discuss advantage of >> having backend >> as a executable vs a library which can't be used standalone without >> front-end. >> This would in effect lock you completely into front-end logic, which may >> not meet >> a users specific needs, even though backend can do what user wants. >> >> >> This has a few advantages, in that the backend can be used stand-alon= e >> >> for scripted installations and also provide great flexibility >> >> to the front-end developer. They don't need to worry about performing >> >> any of the actual installation logic, they just provide a way >> >> for users to select their installation options, generate a configurat= ion >> >> >> > >> >> script, and let the backend run with it. >> >> >> > scripted installation! >> > Are you able to do a pxeboot, nfsroot and then scripted installation? >> > Are those scripts portable to FreeBSD or PC-BSD only? >> > Could you give me a hint where to find them? >> > >> > TIA, >> > Marian >> > >> >> Correct, every install it does is a fully-scripted installation, and >> it can be used with pxeboot, or in a custom mfsroot image easily. >> Supports ZFS, glabel, gmirror, geli, GPT, gpart, vanilla FreeBSD >> installs, etc. >> >> http://trac.pcbsd.org/browser/pcbsd/trunk/pc-sysinstall >> >> Checkout examples/README for all the gory details of config-file >> generation. >> >> One caveat, the version in trunk is being very actively worked on by >> myself at the >> moment to prepare for 8.1, needs more docs, etc ;) 1. Please don't top post :). 2. install.cfg is just a hacky / non-style(9) compliant way of specifying how to do an install. If you could separate out sysinstall into separate utilities and have each of the pieces execute as shell commands with predefined variables at install, you'll be lightyears ahead of where sysinstall is today. 3. sysinstall(8) does a lot of crud that it shouldn't do for all systems. Powerusers won't use sysinstall because does too much crap; all of the items that sysinstall does behind the scenes to get a working system should be properly documented in a doc article. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 19:30:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99F11106566B for ; Thu, 8 Apr 2010 19:30:13 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id 83CA28FC1C for ; Thu, 8 Apr 2010 19:30:13 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp024.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L0K002GPOU21T70@asmtp024.mac.com> for freebsd-current@freebsd.org; Thu, 08 Apr 2010 12:30:06 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004080166 From: Marcel Moolenaar In-reply-to: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> Date: Thu, 08 Apr 2010 12:30:01 -0700 Message-id: References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> To: Alexey Tarasov X-Mailer: Apple Mail (2.1078) Cc: freebsd-current@freebsd.org Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:30:13 -0000 On Apr 8, 2010, at 6:06 AM, Alexey Tarasov wrote: > Hello. > > There is only one possibility to change sector size of physical disk (gnop -S 4096 ...). > May be it is possible to add such possibility to gpart? e.g. gpart create -S 4096 -t gpt ad0? > It will help all unlucky WD Advanced Format disks users. :-D A better approach is to have tunables for geom_disk to do this. This should absolutely not be part of a partitioning tool. It violates everything there is to violate AFAICT. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 19:31:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 574AA106564A; Thu, 8 Apr 2010 19:31:53 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id BDA1C8FC1C; Thu, 8 Apr 2010 19:31:52 +0000 (UTC) Received: by qyk11 with SMTP id 11so1876808qyk.13 for ; Thu, 08 Apr 2010 12:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=i1LwHXQDHnU9ck2omK1B40vP0gW0gtj7KgHh+QA6lyM=; b=eSfVKr4E0JU9E8TuckzGiCTp5d0xowGGqNN0zHgg1h0B2/50zF6UjcTjnnOVXBRTYi ZwYYvEQHr+Vv74hy7fCnFIb20UbVxlX9DByZy8jvppn/+Bnd4tvPg30R/TYy1S/7gdoE 3fLnDiwHnfisLpknCcYAEVOuIu9Qnhpybgrgs= 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=vKEl9ybM14ZCAsZAVtJkSfRFdb9fWSxdsC7hkRE45IjNcDcKIH04NtrjjngoIUNvES 2cia8wHCZ1veR4hZ1hSEm5fKmlBEt/Wc5fQSc90ZrtbXaMl/GRcmTWD/BtHD0KlFR0VM uGlBilE2mAcVQENUrsyja/P/6uoa+SLHewy6k= MIME-Version: 1.0 Received: by 10.229.33.72 with HTTP; Thu, 8 Apr 2010 12:31:51 -0700 (PDT) In-Reply-To: <86sk75ol54.fsf@ds4.des.no> References: <55861270658151@web135.yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <201004080849.12151.jhb@freebsd.org> <86r5mqt4aj.fsf@ds4.des.no> <86sk75ol54.fsf@ds4.des.no> Date: Thu, 8 Apr 2010 12:31:51 -0700 Received: by 10.229.221.78 with SMTP id ib14mr940835qcb.28.1270755111819; Thu, 08 Apr 2010 12:31:51 -0700 (PDT) Message-ID: From: Garrett Cooper To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , freebsd-geom@freebsd.org, Teske , Randi Harper , freebsd-current@freebsd.org, "Andrey V. Elsukov" , Alexander Leidinger Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:31:53 -0000 2010/4/8 Dag-Erling Sm=F8rgrav : > Garrett Cooper writes: >> If the user shoots him or herself in the foot, that's their own >> problem. > > That kind of attitude is why people choose Linux over FreeBSD... Where do you draw the line though? /media, /libexec, /proc, /sys, etc? I think it's better to educate users than build in more complexity to the install application. Besides, how many people have you heard of that created slices for /mnt or /rescue lately? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 19:34:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3054106564A for ; Thu, 8 Apr 2010 19:34:11 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from relay.wahome.ru (relay.wahome.ru [95.211.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id 840998FC0A for ; Thu, 8 Apr 2010 19:34:11 +0000 (UTC) Received: from mmx.lexasoft.ru (mmx.lexasoft.ru [92.241.160.6]) by relay.wahome.ru (Postfix) with ESMTP id 28D206B21F7; Thu, 8 Apr 2010 23:31:13 +0400 (MSD) Received: from [10.100.0.2] (petrovich-telecom-gw.wahome.ru [77.91.225.38]) by mmx.lexasoft.ru (Postfix) with ESMTPSA id 357E02848C; Thu, 8 Apr 2010 23:34:09 +0400 (MSD) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=utf-8 From: Alexey Tarasov In-Reply-To: <4BBDF7D3.3050300@andric.com> Date: Thu, 8 Apr 2010 23:34:07 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> <86eiiqt3kp.fsf@ds4.des.no> <846676C4-C1B8-44DB-AA01-B664614DE59F@lexasoft.ru> <20100408172421.62d73a90@ernst.jennejohn.org> <4BBDF7D3.3050300@andric.com> To: Dimitry Andric , freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1077) Cc: Alexey Tarasov Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:34:11 -0000 Hello. Thank you for the information. In 8-STABLE snapshot 201002 diskinfo shows 512k sector size yet. I will try CURRENT tomorrow. On 08.04.2010, at 19:35, Dimitry Andric wrote: > On 2010-04-08 17:24, Gary Jennejohn wrote: >>>> References >>>> The ATA8-ACS and SBC-3 standards have provisions for a disk drive = to report Advanced Format sector sizes and other performance = optimization information. These standards are used for SATA, SAS, USB, = and IEEE 1394 based interface technologies. >>>=20 >>=20 >> This is apparently the Long Physical Sector features set. The = question is >> whether it's been implemented. >=20 > Isn't this already done? At least it looks like it: >=20 > http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D198897 >=20 > It might even have been MFC'd... :) >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(") From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 19:35:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4988A1065695; Thu, 8 Apr 2010 19:35:04 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 896858FC1E; Thu, 8 Apr 2010 19:35:03 +0000 (UTC) Received: by qyk11 with SMTP id 11so1879987qyk.13 for ; Thu, 08 Apr 2010 12:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/VG4w/HSwGZWQZcnNpn2XoTOOWdtM8Xe8dSCzNh3sms=; b=SjhEZGXm7TpUBabualDm6PKcclQv+BcbQPcEt35cwPABum7Yo1F4C1xnOSO/9GBqFz u9pt9ZFRhcvOucBEKVqguDCUfE2mew5OCbVO1oaT6o/lC5TKuE6fDZnsc61P4EL/HZFm JrDutLpLtfGPDGvxjDQ+lcFeKQiTPy9NM6f0U= 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=ZQZYj1tq83V3M/IDLwiIQsaKpcUPyalSYEfgG4W2plirmYRo85pPFMTGX6sDp8jSYb gQMgszDqEu4i5LDVE2fKAODih5g64bjZPFVcFuGwjq3VTF8dRZtAZWVeFmccW+7qWThN g6ID9+NVgtxLUB9Me/7WnsEhMfl+flfDd32nc= MIME-Version: 1.0 Received: by 10.229.33.72 with HTTP; Thu, 8 Apr 2010 12:35:02 -0700 (PDT) In-Reply-To: References: <55861270658151@web135.yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <201004080849.12151.jhb@freebsd.org> <86r5mqt4aj.fsf@ds4.des.no> <86sk75ol54.fsf@ds4.des.no> Date: Thu, 8 Apr 2010 12:35:02 -0700 Received: by 10.229.221.78 with SMTP id ib14mr947319qcb.28.1270755302731; Thu, 08 Apr 2010 12:35:02 -0700 (PDT) Message-ID: From: Garrett Cooper To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , freebsd-geom@freebsd.org, Teske , Randi Harper , freebsd-current@freebsd.org, "Andrey V. Elsukov" , Alexander Leidinger Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:35:04 -0000 2010/4/8 Garrett Cooper : > 2010/4/8 Dag-Erling Sm=F8rgrav : >> Garrett Cooper writes: >>> If the user shoots him or herself in the foot, that's their own >>> problem. >> >> That kind of attitude is why people choose Linux over FreeBSD... > > =A0 =A0Where do you draw the line though? /media, /libexec, /proc, /sys, > etc? I think it's better to educate users than build in more > complexity to the install application. > =A0 =A0Besides, how many people have you heard of that created slices for > /mnt or /rescue lately? Sorry -- meant partition -_-... Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 19:46:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21223106564A; Thu, 8 Apr 2010 19:46:12 +0000 (UTC) (envelope-from kris@pcbsd.org) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) by mx1.freebsd.org (Postfix) with ESMTP id 99B4C8FC14; Thu, 8 Apr 2010 19:46:11 +0000 (UTC) Received: from mail.ixsystems.com (localhost [127.0.0.1]) by mail.iXsystems.com (Postfix) with ESMTP id 59AD1A664B1; Thu, 8 Apr 2010 12:46:09 -0700 (PDT) Received: from mail.iXsystems.com ([127.0.0.1]) by mail.ixsystems.com (mail.ixsystems.com [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 20222-02; Thu, 8 Apr 2010 12:46:09 -0700 (PDT) Received: from [192.168.0.55] (unknown [75.131.46.136]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 166B4A66457; Thu, 8 Apr 2010 12:46:07 -0700 (PDT) Message-ID: <4BBDFA38.1050208@pcbsd.org> Date: Thu, 08 Apr 2010 15:46:00 +0000 From: Kris Moore User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.8) Gecko/20100302 Thunderbird/3.0.3 MIME-Version: 1.0 To: Garrett Cooper References: <55861270658151@web135.yandex.ru> <20100408121500.13995d1eu7b9bt0k@webmail.leidinger.net> <86fx36up9e.fsf@ds4.des.no> <20100408155309.42884l21ogy7m7sw@webmail.leidinger.net> <86vdc2t4hs.fsf@ds4.des.no> <20100408163936.137245fp5ycrre0w@webmail.leidinger.net> <4BBDB5BC.3060002@pcbsd.org> <4BBDD0B9.3060902@pcbsd.org> <1270746097.29753.106.camel@localhost.localdomain> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org, Devin Teske , Randi Harper , "Andrey V. Elsukov" , =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , Alexander Leidinger , Marian Hettwer Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:46:12 -0000 On 04/08/2010 18:15, Garrett Cooper wrote: > On Thu, Apr 8, 2010 at 10:01 AM, Devin Teske wrote: > >> Randi and I were discussion the possibility of having sysinstall >> "remember" what you did and then able to write out a suitable >> `install.cfg' file that could be subsequently used to perform a human- >> less automated install with the same settings. >> > In a sense that's what our back-end / front-end is doing currently. The program flow works like thus: Front-end starts, queries all relevant information from back-end, Disks, Network Cards, etc, then proceeds to walk the user through the steps gathering enough information to perform an installation. This gives front-end control over its own data gathering logic from the user, since the way I do something in a QT GUI may not work via command-line without a mouse or the other way around. When we are done gathering information, the front-end writes out an install.cfg directive and starts the back-end processing it. The front-end then waits and displays backend output to the user in a sane manner, allowing user to watch whats going on. (example) http://trac.pcbsd.org/browser/pcbsd/trunk/pc-sysinstall/examples/pcinstall.cfg.zfs So with this method, its pretty much doing what you describe. Every install is a scripted install, and if you want to do unattended installs, you can use the front-end to generate all the options you want, copy and/or tweak the resulting config to be used again later. If the backend is simply a library and not executable, then you'll end up needing scripting support or ways to run one implemented directly in each front-end, which can get messy to maintain across curses/gtk/qt/web, etc. -- Kris Moore PC-BSD Software iXsystems From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 19:52:32 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E82881065680 for ; Thu, 8 Apr 2010 19:52:32 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from relay.wahome.ru (relay.wahome.ru [95.211.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id 561CF8FC16 for ; Thu, 8 Apr 2010 19:52:31 +0000 (UTC) Received: from mmx.lexasoft.ru (mmx.lexasoft.ru [92.241.160.6]) by relay.wahome.ru (Postfix) with ESMTP id C3B8F6B21F7; Thu, 8 Apr 2010 23:32:25 +0400 (MSD) Received: from [10.100.0.2] (petrovich-telecom-gw.wahome.ru [77.91.225.38]) by mmx.lexasoft.ru (Postfix) with ESMTPSA id 1FC2F2848C; Thu, 8 Apr 2010 23:35:21 +0400 (MSD) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=utf-8 From: Alexey Tarasov In-Reply-To: Date: Thu, 8 Apr 2010 23:35:20 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <25C7E5C9-3B26-46AE-97D6-131A550DC579@lexasoft.ru> References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> To: Marcel Moolenaar , current@freebsd.org X-Mailer: Apple Mail (2.1077) Cc: Alexey Tarasov Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:52:33 -0000 I agree with you completely. Seems that support of this disks is already commited in CURRENT, will = try it tomorrow. > A better approach is to have tunables for geom_disk to do this. This = should absolutely > not be part of a partitioning tool. It violates everything there is to = violate AFAICT. > FYI, -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(") From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 20:16:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90C85106564A; Thu, 8 Apr 2010 20:16:57 +0000 (UTC) (envelope-from sektie@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 534258FC08; Thu, 8 Apr 2010 20:16:57 +0000 (UTC) Received: by pwi9 with SMTP id 9so2489863pwi.13 for ; Thu, 08 Apr 2010 13:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type; bh=AEzWLefTh3qNVK8fiwyMo05JGj9KFs/mqhPuW5DUGKo=; b=vP4OKqNBqB0tTRF0lOviOyI0i1dB6mqWc3i3xSZJAVflkjlPYy/q3QETiH4dy5Kqrq QtLZQds5berodlUVlYAlm1/HwgxyxfgcybQvaviiZDD6/ILpd2zFho2fnBz2Gcb5EOxh CCUdp1OKqddKDBlv/2DNxqNURlDpZaogUSfNg= 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=GiV1QafpzK5bvUe3AMzmF1ZG54zXzXeWKDa40AIU87G0u0Ia77n5ZF8qar5upW9qcc XjEDtNcSu+eBvA4N4KamwU5X/x9Y/m+EVw9kpw/YXzu8DSRnC4NaNeQp5Q1KP7xwfLiH bKaEi9mjGIFH7lT5/5NH+nhARANnsgmiqZPiU= MIME-Version: 1.0 Sender: sektie@gmail.com Received: by 10.140.255.21 with HTTP; Thu, 8 Apr 2010 13:16:55 -0700 (PDT) In-Reply-To: References: <55861270658151@web135.yandex.ru> <86fx36up9e.fsf@ds4.des.no> <20100408155309.42884l21ogy7m7sw@webmail.leidinger.net> <86vdc2t4hs.fsf@ds4.des.no> <20100408163936.137245fp5ycrre0w@webmail.leidinger.net> <4BBDB5BC.3060002@pcbsd.org> <4BBDD0B9.3060902@pcbsd.org> <1270746097.29753.106.camel@localhost.localdomain> Date: Thu, 8 Apr 2010 13:16:55 -0700 X-Google-Sender-Auth: aea8d5815711557f Received: by 10.140.248.7 with SMTP id v7mr974898rvh.252.1270757816711; Thu, 08 Apr 2010 13:16:56 -0700 (PDT) Message-ID: From: Randi Harper To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 08 Apr 2010 20:21:29 +0000 Cc: Bruce Cran , freebsd-geom@freebsd.org, Alexander Leidinger , Devin Teske , freebsd-current@freebsd.org, "Andrey V. Elsukov" , =?ISO-8859-1?Q?Dag=2DErling_Sm=C3=B8rgrav?= , Marian Hettwer , Kris Moore Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:16:57 -0000 On Thu, Apr 8, 2010 at 11:15 AM, Garrett Cooper wrote: > 2. install.cfg is just a hacky / non-style(9) compliant way of > specifying how to do an install. If you could separate out sysinstall > into separate utilities and have each of the pieces execute as shell > commands with predefined variables at install, you'll be lightyears > ahead of where sysinstall is today. What does style(9) have to do with install.cfg? From the header in the man page, style(9) is a "kernel source file style guide". install.cfg is a configuration file. It is not source code. install.cfg isn't as good as it could be, admittedly. Like much of sysinstall, it needs some work, but I wouldn't call it "hacky". It's readable and fairly easy to understand. What you're talking about doing is rewriting all of sysinstall. How many people have said at some point "I'm going to rewrite sysinstall" or "I'm going to write a replacement for sysinstall"? How many of those people were successful? We're working on a plan and tackling one problem at a time, keeping goals manageable. As a result, sysinstall is getting more TLC now than it has in a very long time. > 3. sysinstall(8) does a lot of crud that it shouldn't do for all > systems. Powerusers won't use sysinstall because does too much crap; > all of the items that sysinstall does behind the scenes to get a > working system should be properly documented in a doc article. I consider myself a poweruser, and I've stuck to using sysinstall. I just select 'custom'. I know a lot of other powerusers - people that have been sysadmins for a very long time - that also use sysinstall. Please don't presume to speak for sysadmins everywhere. I'm not sure what "crud" you're talking about in specific. There's some things I'd like to see go away (some of the post-install configuration bits, how the ports tree is installed). There will be an epic discussion soon of where we'd all like to see sysinstall go ("away" is not the answer I'm looking for :D), but this is going off topic of the original thread. There's a lot of work being done to sysinstall right now by a number of people. I don't want to further complicate things by pushing what you're suggesting into the mix. What we're discussing at the moment is sade/sysinstall specific and affects what happens in the immediate future, not a laundry list of "this is why sysinstall sucks". File a PR. Submit patches. -- randi From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 20:44:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09CB51065678 for ; Thu, 8 Apr 2010 20:44:25 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id BB6208FC1D for ; Thu, 8 Apr 2010 20:44:24 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:41e8:4158:889c:9c05] (unknown [IPv6:2001:7b8:3a7:0:41e8:4158:889c:9c05]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6C0E25C59; Thu, 8 Apr 2010 22:44:23 +0200 (CEST) Message-ID: <4BBE4032.3030806@andric.com> Date: Thu, 08 Apr 2010 22:44:34 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.2pre) Gecko/20100404 Lanikai/3.1b2pre MIME-Version: 1.0 To: Alexey Tarasov References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> <86eiiqt3kp.fsf@ds4.des.no> <846676C4-C1B8-44DB-AA01-B664614DE59F@lexasoft.ru> <20100408172421.62d73a90@ernst.jennejohn.org> <4BBDF7D3.3050300@andric.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:44:25 -0000 On 2010-04-08 21:34, Alexey Tarasov wrote: > Thank you for the information. > In 8-STABLE snapshot 201002 diskinfo shows 512k sector size yet. > I will try CURRENT tomorrow. It looks like the code was MFC'd to stable/8 in r199443. However, even in -CURRENT, the sector size you see in diskinfo will also be 512B. For ada(4) disks, it seems the d_sectorsize field of geom_disk's struct disk is initialized using the _logical_ sector size, not the physical sector size (which may be a multiple of the logical sector size). That said, if the physical sector size is larger than the logical sector size, the d_stripesize field is initialized with it. So if you run "diskinfo -v" on the disk, what is the output for stripesize? From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 21:18:57 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA9341065740 for ; Thu, 8 Apr 2010 21:18:57 +0000 (UTC) (envelope-from kraduk@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 544018FC0C for ; Thu, 8 Apr 2010 21:18:56 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so1938402fgb.13 for ; Thu, 08 Apr 2010 14:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=ETwhBs4vri/c2laeoDIE/BGbHCHcmElSv7le5NMYNrU=; b=I7sFW0Gs+GjRKv07jyyh/L2OXzadsJWGqDj7NBIZRL8AwXQc1rqjcxk9u8tI4yNAdc aneS6EPNF3XwXqfRr/9CRqZ9YpEHcThIyAq+RvenwYt4KaqIAkjYawsVPo98iMbGAYKP R141t220Y8Den/6U0/KMNdBxCRWZgHMwwg1M0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=r09zwD+4flB3a216t5J9qEDdlhJtySWJeqKFf1EbdYLTcT3VbY0ExFhe/9GKUUxgaW /aIp90+PGtd42CKn9pFe0ILGxcAy6Rl6X5+6Dd5GLhpqfCr0gFbithJsVN4gwH34oq/9 6ndcOSL+wXiyco/uOUiWdKAuFGZAYi1yMqQz0= MIME-Version: 1.0 Received: by 10.239.157.136 with HTTP; Thu, 8 Apr 2010 14:18:55 -0700 (PDT) In-Reply-To: References: <20100407173334.GC76941@dan.emsphone.com> Date: Thu, 8 Apr 2010 22:18:55 +0100 Received: by 10.239.193.82 with SMTP id h18mr74696hbi.23.1270761535685; Thu, 08 Apr 2010 14:18:55 -0700 (PDT) Message-ID: From: krad To: "Sam Fourman Jr." Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Freddie Cash , Dan Nelson , current@freebsd.org Subject: Re: When will we can use ZFS v24? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 21:18:57 -0000 On 8 April 2010 17:47, Sam Fourman Jr. wrote: > > ZFS is still currently in heavy development so it might happen. Having > siad > > that it looks like oracle have totally buggered it up for everyone with > > their retroactive licenses. I hope the CDL was tight enough that stuff > wont > > have to get pulled from freebsd > > is that even possible with CDDL? > > Sam Fourman Jr. > Fourman Networks > im not a lawyer but it wouldn't surprise me From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 21:31:01 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE0ED1065676 for ; Thu, 8 Apr 2010 21:31:01 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout025.mac.com (asmtpout025.mac.com [17.148.16.100]) by mx1.freebsd.org (Postfix) with ESMTP id B18CA8FC1D for ; Thu, 8 Apr 2010 21:31:01 +0000 (UTC) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp025.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L0K00ELHUFJFB90@asmtp025.mac.com> for current@freebsd.org; Thu, 08 Apr 2010 14:30:57 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004080193 From: Chuck Swiger In-reply-to: Date: Thu, 08 Apr 2010 14:30:55 -0700 Content-transfer-encoding: quoted-printable Message-id: <8114C0B7-2288-457C-88D6-E5E3B0CC4E51@mac.com> References: <20100407173334.GC76941@dan.emsphone.com> To: krad X-Mailer: Apple Mail (2.1078) Cc: current@freebsd.org Subject: Re: When will we can use ZFS v24? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 21:31:01 -0000 Hi-- On Apr 8, 2010, at 2:18 PM, krad wrote: [ ... ] >> is that even possible with CDDL? >>=20 >=20 > im not a lawyer but it wouldn't surprise me I'm not a lawyer either, but I was active in reviewing and suggesting = changes to CDDL submission for OSI approval back in 2004. A copyright owner always has the ability to relicense their code under = other terms, but existing code is guaranteed to be available, = redistributable to others, etc under the terms of the current version of = CDDL; in particular see: > 4. Versions of the License. >=20 > =95 4.1. New Versions. >=20 > Sun Microsystems, Inc. is the initial license steward and may publish = revised and/or new versions of this License from time to time. Each = version will be given a distinguishing version number. Except as = provided in Section 4.3, no one other than the license steward has the = right to modify this License. >=20 > =95 4.2. Effect of New Versions. >=20 > You may always continue to use, distribute or otherwise make the = Covered Software available under the terms of the version of the License = under which You originally received the Covered Software. If the Initial = Developer includes a notice in the Original Software prohibiting it from = being distributed or otherwise made available under any subsequent = version of the License, You must distribute and make the Covered = Software available under the terms of the version of the License under = which You originally received the Covered Software. Otherwise, You may = also choose to use, distribute or otherwise make the Covered Software = available under the terms of any subsequent version of the License = published by the license steward. If Oracle chooses, they might make future changes to the ZFS source code = under different or more restrictive licensing terms, but what's = available now is always going to be available. Regards, --=20 -Chuck From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 21:39:20 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9490106566C for ; Thu, 8 Apr 2010 21:39:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3D20C8FC15 for ; Thu, 8 Apr 2010 21:39:19 +0000 (UTC) Received: (qmail 23444 invoked by uid 399); 8 Apr 2010 21:39:18 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 8 Apr 2010 21:39:18 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BBE4D04.5010902@FreeBSD.org> Date: Thu, 08 Apr 2010 14:39:16 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Rui Paulo X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: r206358/r206369 prevent me from connecting via wpi0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 21:39:20 -0000 Rui, I updated my kernel to the latest today, and was unable to connect via wireless. I have a 3945ABG using wpi. I rolled back to r206357 and everything worked fine. I then rolled forward to r206369 (your rate control mod + bug fixes and - debugging code) and it stopped working. I didn't bother picking up r206370-2 since I don't have the affected devices and had already tried a more recent kernel. I'm on a C2D using i386 and SMP in case it matters. I use wpa2 on my access point. Let me know if there is any other information that you need. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 01:56:13 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 181DB106566C for ; Fri, 9 Apr 2010 01:56:13 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id D28228FC08 for ; Fri, 9 Apr 2010 01:56:12 +0000 (UTC) Received: (qmail 18758 invoked by uid 399); 9 Apr 2010 01:56:12 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 9 Apr 2010 01:56:12 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BBE893B.7080109@FreeBSD.org> Date: Thu, 08 Apr 2010 18:56:11 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hiroki Sato References: <20100404053352.E6F751CC13@ptavv.es.net> <20100404.184141.03733377.hrs@allbsd.org> <4BB95564.1070604@FreeBSD.org> <20100405.144934.236135572.hrs@allbsd.org> In-Reply-To: <20100405.144934.236135572.hrs@allbsd.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 01:56:13 -0000 On 04/04/10 22:49, Hiroki Sato wrote: > Doug Barton wrote > in <4BB95564.1070604@FreeBSD.org>: > > do> On 04/04/10 02:41, Hiroki Sato wrote: > do> > "Kevin Oberman" wrote > do> > in <20100404053352.E6F751CC13@ptavv.es.net>: > do> > > do> > ob> The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I > do> > ob> see no reason not to use them to enable or disable functionality whether > do> > ob> it involves a script in rc.d or not. The idea is to have a clear, > do> > ob> obvious way to enable or disable functionality. I see nothing in Hiroki's > do> > ob> proposal that is nearly as clear and to the point as 'ipv6_enable'. > do> > > do> > Another reason I lean to not using xxx_enable is that an rc.d knob > do> > cannot control enabling/disabling the IPv6 functionality actually. > do> > It was true even when we were using the network_ipv6 script. > do> > do> But that's equally true of how you're using ipv6_prefer. :) You've > do> basically just moved the overloading of 2 of the 3 previous functions of > do> ipv6_enable to ipv6_prefer. I am suggesting that we split all 3 > do> functions into different knobs. > > No, the current ipv6_prefer=NO has nothing to do with disabling IPv6. if checkyesno ipv6_prefer; then _ipv6_opts="-ifdisabled" else _ipv6_opts="ifdisabled" fi In any case, I give up. Reasonable arguments for not continuing to pursue ipv6_enable: 1. Of those who expressed an opinion, it was roughly evenly divided between support and opposition. 2. In the months since your original commit, I'm the only one who has expressed a strong preference for keeping it. Unreasonable arguments: I am completely out of time and energy to continue discussing it. So, I just committed r206408 that has most of my previously posted changes, but altered to fit both the lack of ipv6_enable, and the requirement to explicitly configure the interface. I've chosen to take the complete lack of commentary on any of my previous patches to be implicit approval of the changes. The one area where we did seem to reach consensus is that ipv6_network_interfaces=AUTO is a reasonable intermediate step, so I've included that change as well. The actual changes and the rationale for them are described in the commit message. The documentation in rc.conf.5 is greatly expanded as well, which I think should make things perfectly clear. With these changes you can now configure RA as simply as adding ifconfig__ipv6=RTADV to rc.conf (assuming of course that INET6 is in the kernel). The lo0 interface will continue to be configured by default. If there are no ifconfig__ipv6 options for any of the other interfaces they will not be configured for IPv6 at all. Any commentary on the technical merits of the changes is welcome assuming that the code has been reviewed and understood. Regards, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 02:07:37 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F8F2106566B for ; Fri, 9 Apr 2010 02:07:37 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id ED9898FC0C for ; Fri, 9 Apr 2010 02:07:36 +0000 (UTC) Received: (qmail 32093 invoked by uid 399); 9 Apr 2010 02:07:36 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 9 Apr 2010 02:07:36 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BBE8BE6.4010507@FreeBSD.org> Date: Thu, 08 Apr 2010 19:07:34 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: FreeBSD current mailing list References: <20100405042138.46F2E1CC13@ptavv.es.net> <4BB9E6B6.6070205@dataix.net> <20100405141615.F40281@maildrop.int.zabbadoz.net> In-Reply-To: <20100405141615.F40281@maildrop.int.zabbadoz.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 02:07:37 -0000 [ snipped ] On 04/05/10 08:52, Bjoern A. Zeeb wrote: > > I have no idea (unless I'll read them) about the guts of various shell > function magic we use to configure interfaces, and I heck do not care > about where it's called autoblah_foo or zigbangbusheek as none of our > users does, so I'll ignore that. I'll probably have to comment on a > few rc.conf knobs as that's all a user cares about. Agreed. I've tried to make the point repeatedly that the users should not have to learn about the internals to do simple enabling of the interface. > Neither IPv4 nor IPX have an _enable="" knob in defaults/rc.conf > and I cannot see why we would need it for IPv6. You don't configure > it on an interface you don't have it configured an interface. > The fact that it had been there for IPv6 is historic and could have > been a good or bad idea at that time during the early days of > development. I am actully too lazy to see why it had really been added. See my answer to Hiroki. Since there was no clear consensus to keep ipv6_enable I agree to allow it to stay deprecated. > I wouldn't want to have a link-local address on my non-loopback > interfaces working unless I asked for them. That's why we had > ipv6_autolinklocal in the past and that's why the current rc/devd/iface > framework prevents this from happening unless explicitly asked for. > That's why there is nd6 options=. I agree that this is a feature, and I've maintained it in the changes I just committed. > I am trying to think of a reason I had needed ipv6_interfaces in the > past and I can find some. I have checked my current configurations > and I couldn't find any instance of *interfaces anymore. Being able > to use ifconfig_**, especially with the IPv6 per interface options, > seems to have fixed all for me with the current implementation. It's probably worth pointing out that this is because of the defaults in /etc/defaults/rc.conf. > Why do we need ipv6_prefer? Well, actually we do not need it. We > could have people use ip6addrctl and a static config file with their > preference. Here I disagree. Having a nice knob in rc.conf makes this an easy thing for users to configure, and is consistent with your point of view above that users should not have to learn about the internals to do simple configuration. > So what do you people actually want to change? You want auto-magic to > happen (again) that suits your local setup or that does what we used > to have in the 5.x days? Well put your "local" needs into > ifconfig__ipv6 and be done. For the record, I resent your implication that my motivations are personal. I wasn't even using the stock interface until recently, and I am more than capable of writing all the custom configuration scripts I need. My motivation is simply to keep things simple for our users, and avoid what I consider to be a POLA violation. However, given the lack of consensus around keeping the ipv6_enable option I'll accept the community's decision and move on. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 05:34:41 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFDEF106564A for ; Fri, 9 Apr 2010 05:34:41 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-pz0-f201.google.com (mail-pz0-f201.google.com [209.85.222.201]) by mx1.freebsd.org (Postfix) with ESMTP id 7BD3F8FC27 for ; Fri, 9 Apr 2010 05:34:41 +0000 (UTC) Received: by pzk39 with SMTP id 39so101499pzk.7 for ; Thu, 08 Apr 2010 22:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OduXC265t+qlW4j2ihl6CchizxcNoEUoyj7pkFEMGCI=; b=IA094evUuVxTXuuwFKslTHlp6s4eANr35ZCFG/lIUkjxCNAhVaMwuuRoEtdeEbSLOb tUURZlcr/FjI5pils192kEzmag4l1SVQng+tBXDO+mf3U0AfUD+3WBhmKWSJUZn53woK cwSvj64hFm1xC9/0tP9Stgwm075MIn12aSPG4= 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=DDIKm48kbdEODUh4ZBm9RD2Bb4Dli3+Jcf2v4H35tmd3BYALeMCUOAAnBo4PktnRxU OlsYZwIvRrhrgj0fZ0ep/xBLshE4RUTMCEyHvLKk8GcyfJC8TBlVB/PpHosm9XkYSrnr tefaXpbz1n6UM/ZIBTLuGLjb/jNmASWPyjOmQ= MIME-Version: 1.0 Received: by 10.143.14.19 with HTTP; Thu, 8 Apr 2010 22:34:40 -0700 (PDT) In-Reply-To: <8114C0B7-2288-457C-88D6-E5E3B0CC4E51@mac.com> References: <20100407173334.GC76941@dan.emsphone.com> <8114C0B7-2288-457C-88D6-E5E3B0CC4E51@mac.com> Date: Thu, 8 Apr 2010 22:34:40 -0700 Received: by 10.143.136.2 with SMTP id o2mr713987wfn.94.1270791280873; Thu, 08 Apr 2010 22:34:40 -0700 (PDT) Message-ID: From: Garrett Cooper To: Chuck Swiger Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: krad , current@freebsd.org Subject: Re: When will we can use ZFS v24? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 05:34:41 -0000 On Thu, Apr 8, 2010 at 2:30 PM, Chuck Swiger wrote: > Hi-- > > On Apr 8, 2010, at 2:18 PM, krad wrote: > [ ... ] >>> is that even possible with CDDL? >>> >> >> im not a lawyer but it wouldn't surprise me > > I'm not a lawyer either, but I was active in reviewing and suggesting cha= nges to CDDL submission for OSI approval back in 2004. > > A copyright owner always has the ability to relicense their code under ot= her terms, but existing code is guaranteed to be available, redistributable= to others, etc under the terms of the current version of CDDL; in particul= ar see: > >> 4. Versions of the License. >> >> =A0 =A0 =A0 =95 4.1. New Versions. >> >> Sun Microsystems, Inc. is the initial license steward and may publish re= vised and/or new versions of this License from time to time. Each version w= ill be given a distinguishing version number. Except as provided in Section= 4.3, no one other than the license steward has the right to modify this Li= cense. >> >> =A0 =A0 =A0 =95 4.2. Effect of New Versions. >> >> You may always continue to use, distribute or otherwise make the Covered= Software available under the terms of the version of the License under whi= ch You originally received the Covered Software. If the Initial Developer i= ncludes a notice in the Original Software prohibiting it from being distrib= uted or otherwise made available under any subsequent version of the Licens= e, You must distribute and make the Covered Software available under the te= rms of the version of the License under which You originally received the C= overed Software. Otherwise, You may also choose to use, distribute or other= wise make the Covered Software available under the terms of any subsequent = version of the License published by the license steward. > > If Oracle chooses, they might make future changes to the ZFS source code = under different or more restrictive licensing terms, but what's available n= ow is always going to be available. The same of basic principle applies to BDB; originally it was BSD licensed in 1.x under FreeBSD, then GPLed in 2.x+ (IIRC), then left to pasture in 4.x after Oracle acquired Sleepycat DB. MySQL is GPLv2 today... who knows what it might be tomorrow... Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 06:57:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 023BE106564A for ; Fri, 9 Apr 2010 06:57:34 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id A8CFA8FC12 for ; Fri, 9 Apr 2010 06:57:33 +0000 (UTC) Received: from [195.93.240.104] (port=28453 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O089j-000FLe-LM for freebsd-current@freebsd.org; Fri, 09 Apr 2010 10:57:31 +0400 Message-ID: <4BBECFDB.6080001@lissyara.su> Date: Fri, 09 Apr 2010 10:57:31 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.23) Gecko/20091202 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: freebsd-current@freebsd.org X-White-List: YES X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: load ipfw table addresses from file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 06:57:34 -0000 hi! is there any plans to implement such opportunities? for large files (we have 60k lines) it's very slow work srv1# sh -E # wc -l /root/scripts/db/table.25.txt 61073 /root/scripts/db/table.25.txt # date && for i in `cat /root/scripts/db/table.25.txt`; do ipfw table 25 add $i; done && date ïÿòíèöà, 9 àïðåëÿ 2010 ã. 10:42:01 (MSD) ïÿòíèöà, 9 àïðåëÿ 2010 ã. 10:52:43 (MSD) # it took more than 10 minutes on busy server =( From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 07:24:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F3811065670; Fri, 9 Apr 2010 07:24:36 +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 9F3C18FC1F; Fri, 9 Apr 2010 07:24:35 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2CF0E.dip.t-dialin.net [217.226.207.14]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 90A9C8442D0; Fri, 9 Apr 2010 09:24:29 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 8749E5072; Fri, 9 Apr 2010 09:24:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1270797865; bh=iavYjFY305ihnnkjBOfoNJYaRkTzwVRzx/gEcHt0sQY=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=bBl3RttgagsSV0OKIHsXy15hoYTmdh+sVka7DsfDmsPEEMxw4RQShUAt3+ReUKfKq SS70ebr1BEbS8Yu/x+HzYmzuv0p2XWO0lvAv/eQsSNL8itf/e7Sztoj3Yrz7AjcVUt YhFzMu8Gios3HiApiMymirX1M9XKWeSmOWamFql+MEIlE1zecwNJXw9vsu1d0HtYpq 7TKu1AmH6ubMnWxieEOH+myCIi1o/AYuLw6VnhEjF5BfClAsJ9XqNvrkjV60GTMzC7 TYf9oumgICe5qHgNx3nyPirAkgyqANHXIFEOPM3GRIAkUS5UxtcbQkbpi5bHiXxgEp bASrZV5yEFH3Q== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id o397OOnA048955; Fri, 9 Apr 2010 09:24:24 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 09 Apr 2010 09:24:24 +0200 Message-ID: <20100409092424.14844pciys1tofms@webmail.leidinger.net> Date: Fri, 09 Apr 2010 09:24:24 +0200 From: Alexander Leidinger To: Dag-Erling =?utf-8?b?U23Dg8K4cmdyYXY=?= References: <55861270658151@web135.yandex.ru> <4BBD68DB.7050600@yandex.ru> <201004080727.21020.bruce@cran.org.uk> <4BBD7CDC.2070505@yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <20100408121500.13995d1eu7b9bt0k@webmail.leidinger.net> <86fx36up9e.fsf@ds4.des.no> <20100408155309.42884l21ogy7m7sw@webmail.leidinger.net> <86vdc2t4hs.fsf@ds4.des.no> <20100408163936.137245fp5ycrre0w@webmail.leidinger.net> <86aatet2vr.fsf@ds4.des.no> In-Reply-To: <86aatet2vr.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: 90A9C8442D0.C0C57 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.44, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1271402671.18638@U5gotQXbFz9Ioa7x3sGepA X-EBL-Spam-Status: No Cc: Bruce Cran , freebsd-current@FreeBSD.ORG, freebsd-geom@FreeBSD.ORG, Teske , Randi Harper , "Andrey V. Elsukov" Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:24:36 -0000 Quoting Dag-Erling Sm=C3=83=C2=B8rgrav (from Thu, 08 Apr 2010 = =20 16:50:16 +0200): > Alexander Leidinger writes: >> I did not suggest to run the same program and get different >> interfaces. My suggestion was to have a backend-lib and a frontend. >> The backend containing the "business-logic", and the frontend being >> the presentation layer. > > What you call the presentation layer is actually 80% of the work. What > you call the business logic already exists (libgeom). That's an oversimplification. There is more code which can be shared. Bye, Alexander. --=20 I'm RELIGIOUS!! I love a man with a HAIRPIECE!! Equip me with MISSILES!! http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 07:41:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCC3F106566B for ; Fri, 9 Apr 2010 07:41:23 +0000 (UTC) (envelope-from hizel@vyborg.ru) Received: from mail.vyborg.ru (mail.vyborg.ru [195.177.105.12]) by mx1.freebsd.org (Postfix) with ESMTP id 54E388FC1B for ; Fri, 9 Apr 2010 07:41:22 +0000 (UTC) Received: from hzwork.vyborg.ru (o.vyborg.ru [195.177.104.22]) by mail.vyborg.ru (8.14.3/8.14.3) with ESMTP id o397FdNL027948 for ; Fri, 9 Apr 2010 11:15:40 +0400 (MSD) (envelope-from hizel@vyborg.ru) Date: Fri, 9 Apr 2010 11:14:12 +0400 From: Hizel Ildar To: freebsd-current@freebsd.org Message-ID: <20100409111412.11e340b7@hzwork.vyborg.ru> In-Reply-To: <4BBECFDB.6080001@lissyara.su> References: <4BBECFDB.6080001@lissyara.su> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.20.0; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: load ipfw table addresses from file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:41:23 -0000 =D0=92 Fri, 09 Apr 2010 10:57:31 +0400 Alex Keda =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > hi! > is there any plans to implement such opportunities? > for large files (we have 60k lines) it's very slow work >=20 > srv1# sh -E > # wc -l /root/scripts/db/table.25.txt > 61073 /root/scripts/db/table.25.txt > # date && for i in `cat /root/scripts/db/table.25.txt`; do ipfw table > 25 add $i; done && date > =D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D0=B0, 9 =D0=B0=D0=BF=D1=80=D0=B5= =D0=BB=D1=8F 2010 =D0=B3. 10:42:01 (MSD) > =D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D0=B0, 9 =D0=B0=D0=BF=D1=80=D0=B5= =D0=BB=D1=8F 2010 =D0=B3. 10:52:43 (MSD) > # > it took more than 10 minutes on busy server =3D( > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" >=20 my variant: se@serv4 ~ >wc -l ip2.txt=20 65536 ip2.txt se@serv4 ~ >sudo ipfw table 25 flush se@serv4 ~ >sudo time ipfw /home/se/ip2.txt 0.94 real 0.54 user 0.39 sys se@serv4 ~ >sudo ipfw table 25 list | wc -l 65536 but file like: table 25 add 192.168.0.36 table 25 add 192.168.0.37 table 25 add 192.168.0.38 table 25 add 192.168.0.39 table 25 add 192.168.0.40 table 25 add 192.168.0.41 table 25 add 192.168.0.42 From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 08:02:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E98C8106564A for ; Fri, 9 Apr 2010 08:02:54 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 76E298FC13 for ; Fri, 9 Apr 2010 08:02:53 +0000 (UTC) Received: from [195.93.240.104] (port=29106 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O09Ax-000HsI-2f for freebsd-current@freebsd.org; Fri, 09 Apr 2010 12:02:51 +0400 Message-ID: <4BBEDF2B.5020102@lissyara.su> Date: Fri, 09 Apr 2010 12:02:51 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.23) Gecko/20091202 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4BBECFDB.6080001@lissyara.su> <20100409111412.11e340b7@hzwork.vyborg.ru> In-Reply-To: <20100409111412.11e340b7@hzwork.vyborg.ru> X-White-List: YES X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: load ipfw table addresses from file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 08:02:55 -0000 09.04.2010 11:14, Hizel Ildar пишет: > Ð’ Fri, 09 Apr 2010 10:57:31 +0400 > Alex Keda пишет: > > >> hi! >> is there any plans to implement such opportunities? >> for large files (we have 60k lines) it's very slow work >> >> srv1# sh -E >> # wc -l /root/scripts/db/table.25.txt >> 61073 /root/scripts/db/table.25.txt >> # date&& for i in `cat /root/scripts/db/table.25.txt`; do ipfw table >> 25 add $i; done&& date >> пÑтница, 9 Ð°Ð¿Ñ€ÐµÐ»Ñ 2010 г. 10:42:01 (MSD) >> пÑтница, 9 Ð°Ð¿Ñ€ÐµÐ»Ñ 2010 г. 10:52:43 (MSD) >> # >> it took more than 10 minutes on busy server =( >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> >> > my variant: > > se@serv4 ~>wc -l ip2.txt > 65536 ip2.txt > se@serv4 ~>sudo ipfw table 25 flush > se@serv4 ~>sudo time ipfw /home/se/ip2.txt > 0.94 real 0.54 user 0.39 sys > se@serv4 ~>sudo ipfw table 25 list | wc -l > 65536 > > but file like: > table 25 add 192.168.0.36 > table 25 add 192.168.0.37 > table 25 add 192.168.0.38 > thanks, it is faster, but - this is a crutch =) From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 08:06:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D143106566C for ; Fri, 9 Apr 2010 08:06:49 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 1F6E18FC1A for ; Fri, 9 Apr 2010 08:06:48 +0000 (UTC) Received: by qyk11 with SMTP id 11so2389390qyk.13 for ; Fri, 09 Apr 2010 01:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=M9bIFHIp3MZYeK5ULYldFVqP2mPKs2NSsN2fySXq5UU=; b=IYlePvRJ1pqsg0Y+T2ndFAiKdqjIkUZn2oezn3LS82QKtONtKU0JgcyERi8qGUPbk/ Z6QP2tIO6+E3cGv0EoAD8XP8CuCYIpQ52I0yewbe96ahBGabHV1PefzWPiQGumYK9wMu hhlRNLaoKo9EG0LTP78MfY1rABB7khn6iGmeM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=m/qzhGRY4X7wLEu2eCOH6SXl41Ua6yufcEAbzhbmRk9KqbI8BrLSWVYxuunCo+yXUF qIjwE70PwUSs/zyy8oTs/hJ1BMawpUobByDfhgee9s8I4B8HrJxjlwBKwJLZKiLM4HsC Of/EulhKnu355lnPHchtEIKKDSomO1Nte6ayg= Received: by 10.229.218.204 with SMTP id hr12mr1903594qcb.101.1270800407945; Fri, 09 Apr 2010 01:06:47 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id f5sm1470866qcg.8.2010.04.09.01.06.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Apr 2010 01:06:46 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BBEE016.9060108@elischer.org> Date: Fri, 09 Apr 2010 01:06:46 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Alex Keda References: <4BBECFDB.6080001@lissyara.su> <20100409111412.11e340b7@hzwork.vyborg.ru> <4BBEDF2B.5020102@lissyara.su> In-Reply-To: <4BBEDF2B.5020102@lissyara.su> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: load ipfw table addresses from file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 08:06:49 -0000 On 4/9/10 1:02 AM, Alex Keda wrote: > 09.04.2010 11:14, Hizel Ildar пишет: >>> # wc -l /root/scripts/db/table.25.txt >>> 61073 /root/scripts/db/table.25.txt >>> # date&& for i in `cat /root/scripts/db/table.25.txt`; do ipfw table >>> 25 add $i; done&& date >>> пÑтница, 9 Ð°Ð¿Ñ€ÐµÐ»Ñ 2010 г. 10:42:01 (MSD) >>> пÑтница, 9 Ð°Ð¿Ñ€ÐµÐ»Ñ 2010 г. 10:52:43 (MSD) >>> # >>> it took more than 10 minutes on busy server =( >>> _______________________________________________ [...] >> but file like: >> table 25 add 192.168.0.36 >> table 25 add 192.168.0.37 >> table 25 add 192.168.0.38 > thanks, it is faster, but - this is a crutch =) yes but it is a crutch that is 600 times faster. From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 09:23:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 458421065673; Fri, 9 Apr 2010 09:23:52 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id F17708FC15; Fri, 9 Apr 2010 09:23:51 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id BB3C61FFC22; Fri, 9 Apr 2010 09:23:50 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 52E36844A6; Fri, 9 Apr 2010 11:23:19 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Garrett Cooper References: <55861270658151@web135.yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <201004080849.12151.jhb@freebsd.org> <86r5mqt4aj.fsf@ds4.des.no> <86sk75ol54.fsf@ds4.des.no> Date: Fri, 09 Apr 2010 11:23:18 +0200 In-Reply-To: (Garrett Cooper's message of "Thu, 8 Apr 2010 12:31:51 -0700") Message-ID: <86fx356ku1.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , freebsd-geom@freebsd.org, Teske , Randi Harper , freebsd-current@freebsd.org, "Andrey V. Elsukov" , Alexander Leidinger Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 09:23:52 -0000 Garrett Cooper writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Garrett Cooper writes: > > > Dag-Erling Sm=C3=B8rgrav writes: > > > > [restored relevant context which was removed earlier in the thread] > > > > ...which is exactly what I said - but in the sysinstall case, you m= ay > > > > want to ask some additional questions ("are you sure you want to pr= oceed > > > > without a swap partition?") or place some additional constraints (s= uch > > > > as "don't allow the user to mount something on top of /mnt or /resc= ue"), > > > > and sysinstall needs to know the outcome. > > > If the user shoots him or herself in the foot, that's their own > > > problem. > > That kind of attitude is why people choose Linux over FreeBSD... > Where do you draw the line though? /media, /libexec, /proc, /sys, etc? > I think it's better to educate users than build in more complexity to > the install application. I draw the line at mounting something - anything - on top of directories that contain files that are critical to sysinstall's operation. IIRC, /mnt is where the installation CD is mounted. In sysinstall mode, sade's role is to 1) make sure that something sensible is mounted in the location where sysinstall is going to install the OS, 2) assist the user in making the correct disk, slice, partition or what-have-you bootable, 3) within reasonable limits, prevent the user from doing something that will break sysinstall, and 4) optionally allow the user to prepare additional filesystems that sysinstall doesn't care about (e.g. /usr/obj), as long as this does not conflict with 3). I think the easiest way to achieve this is for sysinstall to provide an empty directory (e.g. /inst) and have sade operate with that directory as root, so what the user sees is how things will look when the system reboots after installation; when the user asks sade to create /usr/obj, sade actually creates /inst/usr/obj. Last but not least, sade should report what it did to sysinstall - perhaps in fstab format, since sysinstall needs to populate (/inst)/etc/fstab anyway. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 09:25:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E923E1065677 for ; Fri, 9 Apr 2010 09:25:59 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id B5BBD8FC16 for ; Fri, 9 Apr 2010 09:25:58 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1O0ATH-0001qL-ES for freebsd-current@freebsd.org; Fri, 09 Apr 2010 11:25:51 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Apr 2010 11:25:51 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Apr 2010 11:25:51 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Fri, 09 Apr 2010 11:25:46 +0200 Lines: 27 Message-ID: References: <4BBECFDB.6080001@lissyara.su> <20100409111412.11e340b7@hzwork.vyborg.ru> <4BBEDF2B.5020102@lissyara.su> <4BBEE016.9060108@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.8) Gecko/20100329 Thunderbird/3.0.3 In-Reply-To: <4BBEE016.9060108@elischer.org> X-Enigmail-Version: 1.0.1 Subject: Re: load ipfw table addresses from file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 09:26:00 -0000 On 04/09/10 10:06, Julian Elischer wrote: > On 4/9/10 1:02 AM, Alex Keda wrote: >> 09.04.2010 11:14, Hizel Ildar пишет: > >>>> # wc -l /root/scripts/db/table.25.txt >>>> 61073 /root/scripts/db/table.25.txt >>>> # date&& for i in `cat /root/scripts/db/table.25.txt`; do ipfw table >>>> 25 add $i; done&& date >>>> пÑтница, 9 Ð°Ð¿Ñ€ÐµÐ»Ñ 2010 г. 10:42:01 (MSD) >>>> пÑтница, 9 Ð°Ð¿Ñ€ÐµÐ»Ñ 2010 г. 10:52:43 (MSD) >>>> # >>>> it took more than 10 minutes on busy server =( >>>> _______________________________________________ > [...] > >>> but file like: >>> table 25 add 192.168.0.36 >>> table 25 add 192.168.0.37 >>> table 25 add 192.168.0.38 >> thanks, it is faster, but - this is a crutch =) > > yes but it is a crutch that is 600 times faster. I've never used the feature but ipfw has "-p preprocessor" argument which looks like it might be used to process the file containing raw IP addresses with a simple script that appends "table 25 add" to each address before returning it to ipfw. From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 10:42:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EC0A106566B for ; Fri, 9 Apr 2010 10:42:28 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from hydra.fletchermoorland.co.uk (hydra.fletchermoorland.co.uk [78.33.209.59]) by mx1.freebsd.org (Postfix) with ESMTP id CE7218FC18 for ; Fri, 9 Apr 2010 10:42:27 +0000 (UTC) Received: from demophon.fletchermoorland.co.uk (demophon.fletchermoorland.co.uk [192.168.0.154]) by hydra.fletchermoorland.co.uk (8.14.3/8.14.3) with ESMTP id o39AgIBH013568; Fri, 9 Apr 2010 11:42:19 +0100 (BST) (envelope-from paul@fletchermoorland.co.uk) Message-ID: <4BBF048A.407@fletchermoorland.co.uk> Date: Fri, 09 Apr 2010 10:42:18 +0000 From: Paul Wootton User-Agent: Thunderbird 2.0.0.23 (X11/20091217) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <55861270658151@web135.yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <201004080849.12151.jhb@freebsd.org> <86r5mqt4aj.fsf@ds4.des.no> <86sk75ol54.fsf@ds4.des.no> <86fx356ku1.fsf@ds4.des.no> In-Reply-To: <86fx356ku1.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.5 required=10.0 tests=ALL_TRUSTED,BAYES_50, DNS_FROM_OPENWHOIS,FH_DATE_PAST_20XX autolearn=no version=3.2.5 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hydra.fletchermoorland.co.uk Cc: Bruce Cran , freebsd-geom@freebsd.org, Alexander Leidinger , Teske , Randi Harper , freebsd-current@freebsd.org, "Andrey V. Elsukov" , Garrett Cooper Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 10:42:28 -0000 Dag-Erling Smørgrav wrote: > Garrett Cooper writes: > >> Dag-Erling Smørgrav writes: >> >>> Garrett Cooper writes: >>> >>>> Dag-Erling Smørgrav writes: >>>> >>>>> [restored relevant context which was removed earlier in the thread] >>>>> ...which is exactly what I said - but in the sysinstall case, you may >>>>> want to ask some additional questions ("are you sure you want to proceed >>>>> without a swap partition?") or place some additional constraints (such >>>>> as "don't allow the user to mount something on top of /mnt or /rescue"), >>>>> and sysinstall needs to know the outcome. >>>>> >>>> If the user shoots him or herself in the foot, that's their own >>>> problem. >>>> >>> That kind of attitude is why people choose Linux over FreeBSD... >>> >> Where do you draw the line though? /media, /libexec, /proc, /sys, etc? >> I think it's better to educate users than build in more complexity to >> the install application. >> > > I draw the line at mounting something - anything - on top of directories > that contain files that are critical to sysinstall's operation. IIRC, > /mnt is where the installation CD is mounted. > > In sysinstall mode, sade's role is to 1) make sure that something > sensible is mounted in the location where sysinstall is going to install > the OS, 2) assist the user in making the correct disk, slice, partition > or what-have-you bootable, 3) within reasonable limits, prevent the user > from doing something that will break sysinstall, and 4) optionally allow > the user to prepare additional filesystems that sysinstall doesn't care > about (e.g. /usr/obj), as long as this does not conflict with 3). > > I think the easiest way to achieve this is for sysinstall to provide an > empty directory (e.g. /inst) and have sade operate with that directory > as root, so what the user sees is how things will look when the system > reboots after installation; when the user asks sade to create /usr/obj, > sade actually creates /inst/usr/obj. > > Last but not least, sade should report what it did to sysinstall - > perhaps in fstab format, since sysinstall needs to populate > (/inst)/etc/fstab anyway. > > DES > But... If this is a fresh install, then you really have not lost anything if you making a mistake. If sysinstall / sade is run from a running system and a mistake is made then you could loose your data, but as you will need to have su-ed up, how does this differ from typing a wrong command in? Just my 2 cents Paul From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 11:01:02 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0E8B106564A; Fri, 9 Apr 2010 11:01:02 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from relay.wahome.ru (relay.wahome.ru [95.211.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id A0B2E8FC14; Fri, 9 Apr 2010 11:01:02 +0000 (UTC) Received: from mmx.lexasoft.ru (mmx.lexasoft.ru [92.241.160.6]) by relay.wahome.ru (Postfix) with ESMTP id 17E1F6B219C; Fri, 9 Apr 2010 14:58:04 +0400 (MSD) Received: from [10.100.0.2] (petrovich-telecom-gw.wahome.ru [77.91.225.38]) by mmx.lexasoft.ru (Postfix) with ESMTPSA id 8B5A32848C; Fri, 9 Apr 2010 15:01:00 +0400 (MSD) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=utf-8 From: Alexey Tarasov In-Reply-To: <4BBE4032.3030806@andric.com> Date: Fri, 9 Apr 2010 15:00:59 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <539094C7-278A-4674-8A06-E8BAF8F29E58@lexasoft.ru> References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> <86eiiqt3kp.fsf@ds4.des.no> <846676C4-C1B8-44DB-AA01-B664614DE59F@lexasoft.ru> <20100408172421.62d73a90@ernst.jennejohn.org> <4BBDF7D3.3050300@andric.com> <4BBE4032.3030806@andric.com> To: Dimitry Andric , current@freebsd.org X-Mailer: Apple Mail (2.1077) Cc: =?iso-8859-1?Q?av_Sm=F8rgrav?= , mav@FreeBSD.org, Alexey Tarasov Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 11:01:03 -0000 I've booted from dvd to fixit mode and got the following: FreeBSD 8.0-STABLE-201002 FreeBSD 8.0-STABLE-201002 #0: Tue Feb 16 = 21:05:59 UTC 2010 = root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 ATA channel 0: Master: ad0 ATA/ATAPI revision 0 Slave: no device present ATA channel 2: Master: ad4 SATA revision 2.x Slave: no device present ATA channel 3: Master: ad6 SATA revision 2.x Slave: no device present ATA channel 4: Master: ad8 SATA revision 2.x Slave: no device present ATA channel 5: Master: ad10 SATA revision 2.x Slave: no device present /dev/ad4 512 # sectorsize 1500301910016 # mediasize in bytes (1.4T) 2930277168 # mediasize in sectors 0 # stripesize 0 # stripeoffset 2907021 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. WD-WMAVU1512579 # Disk ident. Seems that mav@ commit doesn't work? o_O On 09.04.2010, at 0:44, Dimitry Andric wrote: > That said, if the physical sector size is larger than the logical > sector size, the d_stripesize field is initialized with it. So if you > run "diskinfo -v" on the disk, what is the output for stripesize? -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(") From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 11:01:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03A07106566B for ; Fri, 9 Apr 2010 11:01:34 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 5AB088FC25 for ; Fri, 9 Apr 2010 11:01:33 +0000 (UTC) Received: from megatron.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 8ABFE171F; Fri, 9 Apr 2010 13:01:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mail; t=1270810884; x= 1272625284; bh=pH8Fqp8GECWPlSBWJZmjIp5C8olkd9v9WFtH4++16MY=; b=n 5rxuKHWZ4CRXBzxL0UG0B5myVpkvJkWa8p36fbMGr4j0lX82ORgnHzNhDDOc1oMJ Afv1BGm689fTHA0Lh7WxFNEVCpEkwFyDOQmMSvusozUhN0pkLRj0dSL79IT0lgyU cuyGSPEfgB6+YT1Ty7tGroQaUQ9y7ouylcLoClv+uo= X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by megatron.madpilot.net (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EqlmDLHGxkU4; Fri, 9 Apr 2010 13:01:24 +0200 (CEST) Received: by megatron.madpilot.net (Postfix, from userid 1000) id F06171717; Fri, 9 Apr 2010 13:01:23 +0200 (CEST) Date: Fri, 9 Apr 2010 13:01:23 +0200 From: Guido Falsi To: John Baldwin Message-ID: <20100409110123.GA42615@megatron.madpilot.net> References: <747dc8f31002220835g481b0baeqb1d6df32a79b7da2@mail.gmail.com> <201002231740.46478.jhb@freebsd.org> <179b97fb1002231659h742fd72enca5cfa1d09b822f6@mail.gmail.com> <201002240955.27357.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201002240955.27357.jhb@freebsd.org> X-Operating-System: FreeBSD 8.0-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Brandon Gooch , freebsd-current@freebsd.org Subject: Re: ZFS boot problems with memory > 1MB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 11:01:34 -0000 On Wed, Feb 24, 2010 at 09:55:27AM -0500, John Baldwin wrote: > On Tuesday 23 February 2010 7:59:58 pm Brandon Gooch wrote: > > On Tue, Feb 23, 2010 at 10:40 PM, John Baldwin wrote: > > > On Tuesday 23 February 2010 5:04:03 pm Brandon Gooch wrote: > > >> On Tue, Feb 23, 2010 at 3:03 PM, John Baldwin wrote: [...] > > >> > > >> Adding printf statements to drvread(): > > >> > > >> printf("dsk->xxx: %u\n", dsk->xxx): > > >> > > >> Output: > > >> > > >> error 1 lba 48 > > >> dsk->drive: 0 > > >> dsk->type: 0 > > >> dsk->unit: 0 > > >> dsk->slice: 0 > > >> dsk->part: 0 > > >> dsk->init: 0 > > >> dsk->start: 978673664 > > > > > > This value looks a bit high, do you have a partition that starts at an > offset > > > of about 466GB into the disk? > > > > > >> error 1 lba 1 > > >> dsk->drive: 0 > > >> dsk->type: 0 > > >> dsk->unit: 0 > > >> dsk->slice: 0 > > >> dsk->part: 0 > > >> dsk->init: 0 > > >> dsk->start: 0 > > >> No ZFS pools located, can't boot > > > > > > Sorry, I meant members of the 'packet' variable, though dsk->start is > useful > > > to have as well. > > > > > > -- > > > John Baldwin > > > > > > > Here it is (with some crazy dsk stuff included): > > > > error 1 lba 48 > > packet.len: 16 > > packet.seg: 8192 > > packet.count: 16 > > packet.lba: 47 > > packet.off: 0 > > dsk->drive: 4294967295 > > dsk->slice: 4294967295 > > dsk->type: 4294967295 > > dsk->part: 4294967295 > > dsk->unit: 4294967295 > > dsk->init: 4294967295 > > dsk->start: 4294967295 > > These are all -1 now which looks wrong. The raw LBA being 47 instead of 48 > would seem to indicate that that is the case though. > > > error 1 lba 1 > > packet.len: 16 > > packet.seg: 8704 > > packet.count: 1 > > packet.lba: 1 > > packet.off: 0 > > Odd that the lba here isn't 0. > > Can you add some more printfs, maybe to probe_drive() to try narrow down how > many types that is being invoked and for which drive numbers? Hi! I'm seeing a very similar (perhaps the same) problem on a server I'm trying to configure. Is there any news about this issue? This server is an HP DL360G6 server. Unluckily it has a smartarray thing on it, the disk are behind it. I wanted to configure a 6 drive raidz2 with the driver present(configured as stand alone raid0 units, this is as near you can go to have the smartarray give direct access to the drive to the system, I know this is not optimal.) After following the RootOnZFS instructions after boot the system gives me the same symptoms the parent gets. Old gptzfsboot is not an option here. It fails to malloc. I imagine 128K heap is not enough for my setup. I tried adding some more printfs but it outputs really a lot of data. especially from drive_probe(). I see it cycling through the drives and reading various addresses, what surprises me is it gets very high LBA numbers. For example the last try(which remains on screen) looks like this: packet.len = 16 packet.count = 16 packet.off = 0 packet.seg = 8192 packet.lba = 1716867670 dsk->drive = 133 dsk->type = 0 dsk->unit = 5 dsk->slice = 0 dsk->part = 0 dsk->init = 0 dsk->start = 1716867430 Hope this information helps. I will need some guidance to tinker zfsboot.c code any more tha this :( This is a new machine I'm trying to configure. At present it's available for any experiment. At some time I will have to make it work anyway(even resorting to an UFS /boot ior similar) but I have some time to experiment with it. So I'm available for any further help or testing needed. Thank you in advance for any help! -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 11:14:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10927106566C for ; Fri, 9 Apr 2010 11:14:10 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from relay.wahome.ru (relay.wahome.ru [95.211.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id C9B998FC08 for ; Fri, 9 Apr 2010 11:14:09 +0000 (UTC) Received: from mmx.lexasoft.ru (mmx.lexasoft.ru [92.241.160.6]) by relay.wahome.ru (Postfix) with ESMTP id A90E56B21B1; Fri, 9 Apr 2010 15:11:11 +0400 (MSD) Received: from [10.100.0.2] (petrovich-telecom-gw.wahome.ru [77.91.225.38]) by mmx.lexasoft.ru (Postfix) with ESMTPSA id 1F0542848C; Fri, 9 Apr 2010 15:14:08 +0400 (MSD) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=utf-8 From: Alexey Tarasov In-Reply-To: <4BBEE533.2050507@icyb.net.ua> Date: Fri, 9 Apr 2010 15:14:07 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <90829696-180F-49E1-B37A-5144DE9E30D6@lexasoft.ru> References: <201003291616.27838.Pascal.Stumpf@cubes.de> <9D752CC7-5CCA-454D-8BEC-F3D5E6F8445C@lexasoft.ru> <46D5776E-39F0-48A7-B1C0-B844BF5147C5@lexasoft.ru> <4BBEE533.2050507@icyb.net.ua> To: Andriy Gapon , freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1077) Cc: Alexey Tarasov Subject: Re: ZFS raidz and 4k sector disks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 11:14:10 -0000 Hello. I see considerably increased performance when creating over gnop -S 4096 = virtual disk. Even when I create zpool over raw disks the performance is = very bad and concurent writes stalls. When using gnop, zfs works VERY = fast! Btw, here is another discussion, may be there is a bug in a mav@ commit, = because he has added support for >512 sector size: = http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016495.html =D0=9F=D1=80=D0=B5=D0=B2=D0=B5=D0=B4 =D0=A3=D0=BA=D1=80=D0=B0=D0=B8=D0=BD=D0= =B5! =3D) On 09.04.2010, at 12:28, Andriy Gapon wrote: > on 08/04/2010 16:55 Alexey Tarasov said the following: >> Hello. >>=20 >> I've tried all methods and realized that unfortunately the only = working >> method is gnop. So you can't use these disks for ZFS at all now. >=20 > Why? And what are you actually trying to do? > My understanding was that even with 512-byte sectors ZFS still aligns = its > on-disk data with > 4K alignment. > Do you see otherwise? What problem do you have? >=20 > --=20 > Andriy Gapon -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(") From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 11:19:40 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58E15106564A; Fri, 9 Apr 2010 11:19:40 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 060B68FC1F; Fri, 9 Apr 2010 11:19:38 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA17150; Fri, 09 Apr 2010 14:19:19 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BBF0D36.8050900@icyb.net.ua> Date: Fri, 09 Apr 2010 14:19:18 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: Alexey Tarasov References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> <86eiiqt3kp.fsf@ds4.des.no> <846676C4-C1B8-44DB-AA01-B664614DE59F@lexasoft.ru> <20100408172421.62d73a90@ernst.jennejohn.org> <4BBDF7D3.3050300@andric.com> <4BBE4032.3030806@andric.com> <539094C7-278A-4674-8A06-E8BAF8F29E58@lexasoft.ru> In-Reply-To: <539094C7-278A-4674-8A06-E8BAF8F29E58@lexasoft.ru> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: =?UTF-8?B?YXYgU23DuHJncmF2?= , Dimitry Andric , mav@freebsd.org, current@freebsd.org Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 11:19:40 -0000 on 09/04/2010 14:00 Alexey Tarasov said the following: > I've booted from dvd to fixit mode and got the following: > > FreeBSD 8.0-STABLE-201002 FreeBSD 8.0-STABLE-201002 #0: Tue Feb 16 21:05:59 UTC 2010 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > ATA channel 0: > Master: ad0 ATA/ATAPI revision 0 > Slave: no device present > ATA channel 2: > Master: ad4 SATA revision 2.x > Slave: no device present > ATA channel 3: > Master: ad6 SATA revision 2.x > Slave: no device present > ATA channel 4: > Master: ad8 SATA revision 2.x > Slave: no device present > ATA channel 5: > Master: ad10 SATA revision 2.x > Slave: no device present > > /dev/ad4 > 512 # sectorsize > 1500301910016 # mediasize in bytes (1.4T) > 2930277168 # mediasize in sectors > 0 # stripesize > 0 # stripeoffset > 2907021 # Cylinders according to firmware. > 16 # Heads according to firmware. > 63 # Sectors according to firmware. > WD-WMAVU1512579 # Disk ident. > > Seems that mav@ commit doesn't work? o_O Or the disk doesn't actually report 4096 anywhere anyhow... Have you considered that? If yes, can you verify using any tools of any OS that the disk reports 4K in any way? P.S. DES's name looks strange in headers :-) P.P.S. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? > On 09.04.2010, at 0:44, Dimitry Andric wrote: > >> That said, if the physical sector size is larger than the logical >> sector size, the d_stripesize field is initialized with it. So if you >> run "diskinfo -v" on the disk, what is the output for stripesize? > > -- > Alexey Tarasov > > (\__/) > (='.'=) > E[: | | | | :]З > (")_(") > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 11:27:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 029871065673 for ; Fri, 9 Apr 2010 11:27:12 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from relay.wahome.ru (relay.wahome.ru [95.211.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id B59098FC15 for ; Fri, 9 Apr 2010 11:27:11 +0000 (UTC) Received: from mmx.lexasoft.ru (mmx.lexasoft.ru [92.241.160.6]) by relay.wahome.ru (Postfix) with ESMTP id 954156B222F; Fri, 9 Apr 2010 15:24:13 +0400 (MSD) Received: from [10.100.0.2] (petrovich-telecom-gw.wahome.ru [77.91.225.38]) by mmx.lexasoft.ru (Postfix) with ESMTPSA id 375C52848C; Fri, 9 Apr 2010 15:27:10 +0400 (MSD) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=utf-8 From: Alexey Tarasov In-Reply-To: <4BBF0D36.8050900@icyb.net.ua> Date: Fri, 9 Apr 2010 15:27:09 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> <86eiiqt3kp.fsf@ds4.des.no> <846676C4-C1B8-44DB-AA01-B664614DE59F@lexasoft.ru> <20100408172421.62d73a90@ernst.jennejohn.org> <4BBDF7D3.3050300@andric.com> <4BBE4032.3030806@andric.com> <539094C7-278A-4674-8A06-E8BAF8F29E58@lexasoft.ru> <4BBF0D36.8050900@icyb.net.ua> To: Andriy Gapon , freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1077) Cc: Alexey Tarasov Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 11:27:12 -0000 > Or the disk doesn't actually report 4096 anywhere anyhow... Have you = considered > that? If yes, can you verify using any tools of any OS that the disk = reports 4K > in any way? In the previous discussion we found that the disk reports 512 sector = size, but there are additional ATA commands to determine if it has real = sector size larger than 4k. I will try to confirm this. > P.S. DES's name looks strange in headers :-) Really. :-) > P.P.S. > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? Sorry, to few experience. =3D) -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(") From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 11:29:44 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F29C7106566B; Fri, 9 Apr 2010 11:29:44 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id AC5D88FC15; Fri, 9 Apr 2010 11:29:44 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 9E0831FFC51; Fri, 9 Apr 2010 11:29:43 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 3376F844A7; Fri, 9 Apr 2010 13:29:12 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Paul Wootton References: <55861270658151@web135.yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <201004080849.12151.jhb@freebsd.org> <86r5mqt4aj.fsf@ds4.des.no> <86sk75ol54.fsf@ds4.des.no> <86fx356ku1.fsf@ds4.des.no> <4BBF048A.407@fletchermoorland.co.uk> Date: Fri, 09 Apr 2010 13:29:12 +0200 In-Reply-To: <4BBF048A.407@fletchermoorland.co.uk> (Paul Wootton's message of "Fri, 09 Apr 2010 10:42:18 +0000") Message-ID: <8639z47tkn.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , freebsd-geom@freebsd.org, Alexander Leidinger , Teske , Randi Harper , freebsd-current@freebsd.org, "Andrey V. Elsukov" , Garrett Cooper Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 11:29:45 -0000 Paul Wootton writes: > But... If this is a fresh install, then you really have not lost > anything if you making a mistake. If sysinstall / sade is run from a > running system and a mistake is made then you could loose your data, > but as you will need to have su-ed up, how does this differ from > typing a wrong command in? Please, please, go have a cup of coffee, then come back and *read what I wrote* instead of just making stuff up. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 11:32:01 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD30F106564A; Fri, 9 Apr 2010 11:32:01 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 987188FC1B; Fri, 9 Apr 2010 11:32:01 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id DEC5E1FFC22; Fri, 9 Apr 2010 11:32:00 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 3840D844A7; Fri, 9 Apr 2010 13:31:29 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Andriy Gapon References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> <86eiiqt3kp.fsf@ds4.des.no> <846676C4-C1B8-44DB-AA01-B664614DE59F@lexasoft.ru> <20100408172421.62d73a90@ernst.jennejohn.org> <4BBDF7D3.3050300@andric.com> <4BBE4032.3030806@andric.com> <539094C7-278A-4674-8A06-E8BAF8F29E58@lexasoft.ru> <4BBF0D36.8050900@icyb.net.ua> Date: Fri, 09 Apr 2010 13:31:29 +0200 In-Reply-To: <4BBF0D36.8050900@icyb.net.ua> (Andriy Gapon's message of "Fri, 09 Apr 2010 14:19:18 +0300") Message-ID: <86y6gw6ewe.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Dimitry Andric , mav@freebsd.org, Alexey Tarasov , current@freebsd.org Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 11:32:01 -0000 Andriy Gapon writes: > P.S. DES's name looks strange in headers :-) Get a better MUA. MIME quoted-printable has been around for what, 15 years? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 11:32:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 777991065670 for ; Fri, 9 Apr 2010 11:32:06 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B584E8FC16 for ; Fri, 9 Apr 2010 11:32:05 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA17345; Fri, 09 Apr 2010 14:32:03 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BBF1033.5030409@icyb.net.ua> Date: Fri, 09 Apr 2010 14:32:03 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: Alexey Tarasov References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> <86eiiqt3kp.fsf@ds4.des.no> <846676C4-C1B8-44DB-AA01-B664614DE59F@lexasoft.ru> <20100408172421.62d73a90@ernst.jennejohn.org> <4BBDF7D3.3050300@andric.com> <4BBE4032.3030806@andric.com> <539094C7-278A-4674-8A06-E8BAF8F29E58@lexasoft.ru> <4BBF0D36.8050900@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 11:32:06 -0000 on 09/04/2010 14:27 Alexey Tarasov said the following: >> Or the disk doesn't actually report 4096 anywhere anyhow... Have you >> considered that? If yes, can you verify using any tools of any OS that the >> disk reports 4K in any way? > > In the previous discussion we found that the disk reports 512 sector size, but > there are additional ATA commands to determine if it has real sector size > larger than 4k. I will try to confirm this. Thank you. I think that this would be an interesting detail. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 11:33:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C2D1106564A for ; Fri, 9 Apr 2010 11:33:58 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from relay.wahome.ru (relay.wahome.ru [95.211.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id 29EC48FC22 for ; Fri, 9 Apr 2010 11:33:57 +0000 (UTC) Received: from mmx.lexasoft.ru (mmx.lexasoft.ru [92.241.160.6]) by relay.wahome.ru (Postfix) with ESMTP id 2187C6B2206; Fri, 9 Apr 2010 15:31:00 +0400 (MSD) Received: from [10.100.0.2] (petrovich-telecom-gw.wahome.ru [77.91.225.38]) by mmx.lexasoft.ru (Postfix) with ESMTPSA id 96FCF2848C; Fri, 9 Apr 2010 15:33:56 +0400 (MSD) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=utf-8 From: Alexey Tarasov In-Reply-To: <4BBF1033.5030409@icyb.net.ua> Date: Fri, 9 Apr 2010 15:33:55 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5D7D5FDB-8BF7-4FE6-919A-5C5E7B8784F5@lexasoft.ru> References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> <86eiiqt3kp.fsf@ds4.des.no> <846676C4-C1B8-44DB-AA01-B664614DE59F@lexasoft.ru> <20100408172421.62d73a90@ernst.jennejohn.org> <4BBDF7D3.3050300@andric.com> <4BBE4032.3030806@andric.com> <539094C7-278A-4674-8A06-E8BAF8F29E58@lexasoft.ru> <4BBF0D36.8050900@icyb.net.ua> <4BBF1033.5030409@icyb.net.ua> To: Andriy Gapon , freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1077) Cc: Alexey Tarasov Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 11:33:58 -0000 On 09.04.2010, at 15:32, Andriy Gapon wrote: > on 09/04/2010 14:27 Alexey Tarasov said the following: >>> Or the disk doesn't actually report 4096 anywhere anyhow... Have = you >>> considered that? If yes, can you verify using any tools of any OS = that the >>> disk reports 4K in any way? >>=20 >> In the previous discussion we found that the disk reports 512 sector = size, but >> there are additional ATA commands to determine if it has real sector = size >> larger than 4k. I will try to confirm this. >=20 > Thank you. I think that this would be an interesting detail. >=20 Here is the reference: http://www.wdc.com/wdproducts/library/WhitePapers/ENG/2579-771430.pdf > References > The ATA8-ACS and SBC-3 standards have provisions for a disk drive to = report Advanced Format sector sizes and other performance optimization = information. These standards are used for SATA, SAS, USB, and IEEE 1394 = based interface technologies. -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(") From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 11:41:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85AF21065672 for ; Fri, 9 Apr 2010 11:41:12 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C12EE8FC0C for ; Fri, 9 Apr 2010 11:41:11 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA17488; Fri, 09 Apr 2010 14:41:09 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BBF1255.30303@icyb.net.ua> Date: Fri, 09 Apr 2010 14:41:09 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: Alexey Tarasov References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> <86eiiqt3kp.fsf@ds4.des.no> <846676C4-C1B8-44DB-AA01-B664614DE59F@lexasoft.ru> <20100408172421.62d73a90@ernst.jennejohn.org> <4BBDF7D3.3050300@andric.com> <4BBE4032.3030806@andric.com> <539094C7-278A-4674-8A06-E8BAF8F29E58@lexasoft.ru> <4BBF0D36.8050900@icyb.net.ua> <4BBF1033.5030409@icyb.net.ua> <5D7D5FDB-8BF7-4FE6-919A-5C5E7B8784F5@lexasoft.ru> In-Reply-To: <5D7D5FDB-8BF7-4FE6-919A-5C5E7B8784F5@lexasoft.ru> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 11:41:12 -0000 on 09/04/2010 14:33 Alexey Tarasov said the following: > On 09.04.2010, at 15:32, Andriy Gapon wrote: > >> on 09/04/2010 14:27 Alexey Tarasov said the following: >>>> Or the disk doesn't actually report 4096 anywhere anyhow... Have you >>>> considered that? If yes, can you verify using any tools of any OS that the >>>> disk reports 4K in any way? >>> In the previous discussion we found that the disk reports 512 sector size, but >>> there are additional ATA commands to determine if it has real sector size >>> larger than 4k. I will try to confirm this. >> Thank you. I think that this would be an interesting detail. >> > > Here is the reference: > > http://www.wdc.com/wdproducts/library/WhitePapers/ENG/2579-771430.pdf I saw it, but I want to see what's reported in reality. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 11:43:48 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9215E1065670 for ; Fri, 9 Apr 2010 11:43:48 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CEBEF8FC1C for ; Fri, 9 Apr 2010 11:43:47 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA17519; Fri, 09 Apr 2010 14:43:15 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BBF12D3.6060900@icyb.net.ua> Date: Fri, 09 Apr 2010 14:43:15 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , Dimitry Andric References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> <86eiiqt3kp.fsf@ds4.des.no> <846676C4-C1B8-44DB-AA01-B664614DE59F@lexasoft.ru> <20100408172421.62d73a90@ernst.jennejohn.org> <4BBDF7D3.3050300@andric.com> <4BBE4032.3030806@andric.com> <539094C7-278A-4674-8A06-E8BAF8F29E58@lexasoft.ru> <4BBF0D36.8050900@icyb.net.ua> <86y6gw6ewe.fsf@ds4.des.no> In-Reply-To: <86y6gw6ewe.fsf@ds4.des.no> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: current@freebsd.org Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 11:43:48 -0000 on 09/04/2010 14:31 Dag-Erling Smørgrav said the following: > Andriy Gapon writes: >> P.S. DES's name looks strange in headers :-) > > Get a better MUA. MIME quoted-printable has been around for what, 15 > years? The advice is misdirected. Right, Dmitry? :-) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 11:45:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E8231065670 for ; Fri, 9 Apr 2010 11:45:22 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from relay.wahome.ru (relay.wahome.ru [95.211.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id CF1F08FC13 for ; Fri, 9 Apr 2010 11:45:21 +0000 (UTC) Received: from mmx.lexasoft.ru (mmx.lexasoft.ru [92.241.160.6]) by relay.wahome.ru (Postfix) with ESMTP id BC2876B2187; Fri, 9 Apr 2010 15:42:23 +0400 (MSD) Received: from [10.100.0.2] (petrovich-telecom-gw.wahome.ru [77.91.225.38]) by mmx.lexasoft.ru (Postfix) with ESMTPSA id 4DE0F2848C; Fri, 9 Apr 2010 15:45:20 +0400 (MSD) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=utf-8 From: Alexey Tarasov In-Reply-To: <4BBF1255.30303@icyb.net.ua> Date: Fri, 9 Apr 2010 15:45:19 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> <86eiiqt3kp.fsf@ds4.des.no> <846676C4-C1B8-44DB-AA01-B664614DE59F@lexasoft.ru> <20100408172421.62d73a90@ernst.jennejohn.org> <4BBDF7D3.3050300@andric.com> <4BBE4032.3030806@andric.com> <539094C7-278A-4674-8A06-E8BAF8F29E58@lexasoft.ru> <4BBF0D36.8050900@icyb.net.ua> <4BBF1033.5030409@icyb.net.ua> <5D7D5FDB-8BF7-4FE6-919A-5C5E7B8784F5@lexasoft.ru> <4BBF1255.30303@icyb.net.ua> To: Andriy Gapon , freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1077) Cc: Alexey Tarasov Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 11:45:22 -0000 > I saw it, but I want to see what's reported in reality. Installing Windows 7 now. How can OS installation be so long? :-) -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(") From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 11:57:11 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 339231065674 for ; Fri, 9 Apr 2010 11:57:11 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id AAE568FC14 for ; Fri, 9 Apr 2010 11:57:10 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so120312fgb.13 for ; Fri, 09 Apr 2010 04:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=S7qqn406TwZdtmYVxNptZV9KOjHkSqznVbfVV3I3AF0=; b=DwYKMFC3dXTNo7D1D/kfNY5r6hg8yDt2KVAwUpUiFv9W5t41rKx7fAo8o6je9XMiy1 iFeiJDc1Al2Ih9IeWKvRRY8zkQ1Fwzgb1TpALlQYTT4sCujIln3me38nqOBzqNCljtNI UiQF2P8CYyXeQenxIMW+VlmyOpSDgZuJhPjSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=hUB/lw6UTAdhTDRQSNprymiTKf5NppMNUXO8QPJpIeZqFBIH5F2fEcp3btBFSd7o0L 2HPX45/q8xpVJmzY0hqgv02XtmdY7ccKZSOGK360wYFLO28s81IG73K2M8xOPM/hrNDF dkPnLcGMmzZJ/T/Pstt0ngb2nEpzyVlikufh4= Received: by 10.86.124.4 with SMTP id w4mr197288fgc.54.1270814227405; Fri, 09 Apr 2010 04:57:07 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm700986fxm.0.2010.04.09.04.57.05 (version=SSLv3 cipher=RC4-MD5); Fri, 09 Apr 2010 04:57:06 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BBF160B.8060104@FreeBSD.org> Date: Fri, 09 Apr 2010 14:56:59 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Andriy Gapon References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> <86eiiqt3kp.fsf@ds4.des.no> <846676C4-C1B8-44DB-AA01-B664614DE59F@lexasoft.ru> <20100408172421.62d73a90@ernst.jennejohn.org> <4BBDF7D3.3050300@andric.com> <4BBE4032.3030806@andric.com> <539094C7-278A-4674-8A06-E8BAF8F29E58@lexasoft.ru> <4BBF0D36.8050900@icyb.net.ua> In-Reply-To: <4BBF0D36.8050900@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?YXYgU23DuHJncmF2?= , Dimitry Andric , Alexey Tarasov , current@freebsd.org Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 11:57:11 -0000 Andriy Gapon wrote: > on 09/04/2010 14:00 Alexey Tarasov said the following: >> I've booted from dvd to fixit mode and got the following: >> /dev/ad4 >> 512 # sectorsize >> 1500301910016 # mediasize in bytes (1.4T) >> 2930277168 # mediasize in sectors >> 0 # stripesize >> 0 # stripeoffset >> 2907021 # Cylinders according to firmware. >> 16 # Heads according to firmware. >> 63 # Sectors according to firmware. >> WD-WMAVU1512579 # Disk ident. >> >> Seems that mav@ commit doesn't work? o_O Commit was to "ada" driver, not to "ad". > Or the disk doesn't actually report 4096 anywhere anyhow... Have you considered > that? If yes, can you verify using any tools of any OS that the disk reports 4K > in any way? My testing WDC Green disk with Advanced Format doesn't reports it's physical sector size. I've studied it's IDENTIFY output even manually. `camcontrol devinfo ada0 -v` dumps full identify data. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 11:59:25 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12A031065672 for ; Fri, 9 Apr 2010 11:59:25 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by mx1.freebsd.org (Postfix) with ESMTP id 868DF8FC21 for ; Fri, 9 Apr 2010 11:59:24 +0000 (UTC) Received: by fxm25 with SMTP id 25so683397fxm.3 for ; Fri, 09 Apr 2010 04:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=SH2nAToBACI2UUkrDSgzco079AE107El1CnUH8NgpkQ=; b=uWK9FEoMpF5Hb2Nej3LiEF7XZZuT0QyMylz8LCcczuIT5DqukIc5RONI6YwHzMu5Zd cjNI6ikSMVAwF6eze1I1UQR2+//73MkuDWEETqTr8Sqx5k1ZFOFOe1tZC5+OeaB2xOV7 I2o/ZRpMhctnflUG94YUtBDeFMIgt36aGToGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=mwwht45J0k2mVhS88LINfs+ZdfhD3TsVk3m7n+VahvFCa2cZdA83Bnsh/IPYEpdbma zcE1WVY7IqwSbW66H9tcWCMJTNyzFwvbU05erLVG7k+tjWSBZ6oFBeXIfG1SJAny9vxM icA+WV4+QGbNhqZAdYj81FMbpKCPIhho+MboU= Received: by 10.223.144.84 with SMTP id y20mr1531757fau.78.1270814363365; Fri, 09 Apr 2010 04:59:23 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm693075fxm.15.2010.04.09.04.59.21 (version=SSLv3 cipher=RC4-MD5); Fri, 09 Apr 2010 04:59:22 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BBF1694.8020604@FreeBSD.org> Date: Fri, 09 Apr 2010 14:59:16 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Andriy Gapon References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> <86eiiqt3kp.fsf@ds4.des.no> <846676C4-C1B8-44DB-AA01-B664614DE59F@lexasoft.ru> <20100408172421.62d73a90@ernst.jennejohn.org> <4BBDF7D3.3050300@andric.com> <4BBE4032.3030806@andric.com> <539094C7-278A-4674-8A06-E8BAF8F29E58@lexasoft.ru> <4BBF0D36.8050900@icyb.net.ua> <4BBF160B.8060104@FreeBSD.org> In-Reply-To: <4BBF160B.8060104@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?YXYgU23DuHJncmF2?= , Dimitry Andric , Alexey Tarasov , current@freebsd.org Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 11:59:25 -0000 Alexander Motin wrote: > Andriy Gapon wrote: >> on 09/04/2010 14:00 Alexey Tarasov said the following: >>> I've booted from dvd to fixit mode and got the following: >>> /dev/ad4 >>> 512 # sectorsize >>> 1500301910016 # mediasize in bytes (1.4T) >>> 2930277168 # mediasize in sectors >>> 0 # stripesize >>> 0 # stripeoffset >>> 2907021 # Cylinders according to firmware. >>> 16 # Heads according to firmware. >>> 63 # Sectors according to firmware. >>> WD-WMAVU1512579 # Disk ident. >>> >>> Seems that mav@ commit doesn't work? o_O > > Commit was to "ada" driver, not to "ad". > >> Or the disk doesn't actually report 4096 anywhere anyhow... Have you considered >> that? If yes, can you verify using any tools of any OS that the disk reports 4K >> in any way? > > My testing WDC Green disk with Advanced Format doesn't reports it's > physical sector size. I've studied it's IDENTIFY output even manually. > `camcontrol devinfo ada0 -v` dumps full identify data. Oops, I've meant `camcontrol identify ada0 -v`. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 12:14:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59E891065670 for ; Fri, 9 Apr 2010 12:14:42 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9BD3E8FC0A for ; Fri, 9 Apr 2010 12:14:41 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA18121; Fri, 09 Apr 2010 15:14:39 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BBF1A2E.1070102@icyb.net.ua> Date: Fri, 09 Apr 2010 15:14:38 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: Alexey Tarasov References: <201003291616.27838.Pascal.Stumpf@cubes.de> <9D752CC7-5CCA-454D-8BEC-F3D5E6F8445C@lexasoft.ru> <46D5776E-39F0-48A7-B1C0-B844BF5147C5@lexasoft.ru> <4BBEE533.2050507@icyb.net.ua> <90829696-180F-49E1-B37A-5144DE9E30D6@lexasoft.ru> In-Reply-To: <90829696-180F-49E1-B37A-5144DE9E30D6@lexasoft.ru> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ZFS raidz and 4k sector disks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 12:14:42 -0000 on 09/04/2010 14:14 Alexey Tarasov said the following: > Hello. > > I see considerably increased performance when creating over gnop -S 4096 virtual disk. Even when I create zpool over raw disks the performance is very bad and concurent writes stalls. When using gnop, zfs works VERY fast! > > Btw, here is another discussion, may be there is a bug in a mav@ commit, because he has added support for >512 sector size: > http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016495.html Looks like I was wrong: /* * Determine the device's minimum transfer size. */ *ashift = highbit(MAX(pp->sectorsize, SPA_MINBLOCKSIZE)) - 1; This is in vdev_geom_open and SPA_MINBLOCKSIZE is 512. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 12:15:13 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E2851065670; Fri, 9 Apr 2010 12:15:13 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5B8478FC0A; Fri, 9 Apr 2010 12:15:13 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:1137:7e67:e251:d871] (unknown [IPv6:2001:7b8:3a7:0:1137:7e67:e251:d871]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 183DC5C59; Fri, 9 Apr 2010 14:15:12 +0200 (CEST) Message-ID: <4BBF1A4F.1010904@andric.com> Date: Fri, 09 Apr 2010 14:15:11 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.2pre) Gecko/20100404 Lanikai/3.1b2pre MIME-Version: 1.0 To: Alexey Tarasov References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> <86eiiqt3kp.fsf@ds4.des.no> <846676C4-C1B8-44DB-AA01-B664614DE59F@lexasoft.ru> <20100408172421.62d73a90@ernst.jennejohn.org> <4BBDF7D3.3050300@andric.com> <4BBE4032.3030806@andric.com> <539094C7-278A-4674-8A06-E8BAF8F29E58@lexasoft.ru> In-Reply-To: <539094C7-278A-4674-8A06-E8BAF8F29E58@lexasoft.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , mav@FreeBSD.org, current@freebsd.org Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 12:15:13 -0000 On 2010-04-09 13:00, Alexey Tarasov wrote: > /dev/ad4 > 512 # sectorsize > 1500301910016 # mediasize in bytes (1.4T) > 2930277168 # mediasize in sectors > 0 # stripesize > 0 # stripeoffset > 2907021 # Cylinders according to firmware. > 16 # Heads according to firmware. > 63 # Sectors according to firmware. > WD-WMAVU1512579 # Disk ident. > > Seems that mav@ commit doesn't work? o_O No, the problem is that you must use the ada(4) driver instead of ad(4). The new physical and logical sector support has only been implemented for the newer AHCI-over-CAM stack. From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 12:37:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2C02106566C for ; Fri, 9 Apr 2010 12:37:05 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from relay.wahome.ru (relay.wahome.ru [95.211.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id 46E518FC2B for ; Fri, 9 Apr 2010 12:37:05 +0000 (UTC) Received: from mmx.lexasoft.ru (mmx.lexasoft.ru [92.241.160.6]) by relay.wahome.ru (Postfix) with ESMTP id 1A7BF6B219C; Fri, 9 Apr 2010 16:34:07 +0400 (MSD) Received: from [10.100.0.2] (petrovich-telecom-gw.wahome.ru [77.91.225.38]) by mmx.lexasoft.ru (Postfix) with ESMTPSA id 533D82848C; Fri, 9 Apr 2010 16:37:03 +0400 (MSD) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=utf-8 From: Alexey Tarasov In-Reply-To: <4BBF1A4F.1010904@andric.com> Date: Fri, 9 Apr 2010 16:37:02 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <318B377E-F87A-4512-B919-8668857074F6@lexasoft.ru> References: <1A417529-F467-4411-970A-3FF41080AC61@lexasoft.ru> <868w8yukuy.fsf@ds4.des.no> <6313EB8E-D3DA-459F-A372-0E871359FA1C@lexasoft.ru> <86zl1et4rv.fsf@ds4.des.no> <86mxxet437.fsf@ds4.des.no> <86eiiqt3kp.fsf@ds4.des.no> <846676C4-C1B8-44DB-AA01-B664614DE59F@lexasoft.ru> <20100408172421.62d73a90@ernst.jennejohn.org> <4BBDF7D3.3050300@andric.com> <4BBE4032.3030806@andric.com> <539094C7-278A-4674-8A06-E8BAF8F29E58@lexasoft.ru> <4BBF1A4F.1010904@andric.com> To: Dimitry Andric , freebsd-current@freebsd.org, Andriy Gapon X-Mailer: Apple Mail (2.1077) Cc: Alexey Tarasov Subject: Re: gpart and sector size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 12:37:05 -0000 > No, the problem is that you must use the ada(4) driver instead of = ad(4). > The new physical and logical sector support has only been implemented > for the newer AHCI-over-CAM stack. pass0: Raw identify data: 0: 427a 3fff c837 0010 0000 0000 003f 0000=20 8: 0000 0000 2020 2020 2057 442d 574d 4156=20 16: 5531 3531 3235 3739 0000 0000 0032 3830=20 24: 2e30 3041 3830 5744 4320 5744 3135 4541=20 32: 5253 2d30 305a 3542 3120 2020 2020 2020=20 40: 2020 2020 2020 2020 2020 2020 2020 8010=20 48: 0000 2f00 4001 0000 0000 0007 3fff 0010=20 56: 003f fc10 00fb 0110 ffff 0fff 0000 0007=20 64: 0003 0078 0078 0078 0078 0000 0000 0000=20 72: 0000 0000 0000 001f 1706 0000 0044 0040=20 80: 01fe 0000 746b 7f61 4123 7469 bc41 4123=20 88: 407f 00ab 00ab 0000 fffe 0000 80fe 0000=20 96: 0000 0000 0000 0000 7b30 aea8 0000 0000=20 104: 0000 0000 0000 0000 5001 4ee0 5743 482f=20 112: 0000 0000 0000 0000 0000 0000 0000 4018=20 120: 4018 0000 0000 0000 0000 0000 0000 0000=20 128: 0021 0000 0000 0000 0000 16db 0000 0000=20 136: 0000 0000 0000 0000 0000 0000 0004 0000=20 144: 0000 0000 0000 0000 0000 0000 0000 0000=20 152: 0000 0000 0000 0000 0000 0000 0000 0000=20 160: 0000 0000 0000 0000 0000 0000 0000 0000=20 168: 0000 0000 0000 0000 0000 0000 0000 0000=20 176: 0000 0000 0000 0000 0000 0000 0000 0000=20 184: 0000 0000 0000 0000 0000 0000 0000 0000=20 192: 0000 0000 0000 0000 0000 0000 0000 0000=20 200: 0000 0000 0000 0000 0000 0000 3031 0000=20 208: 0000 0000 0000 0000 0000 0000 0000 0000=20 216: 0000 0000 0000 0000 0000 0000 101e 0000=20 224: 0000 0000 0000 0000 0000 0000 0000 0000=20 232: 0000 0000 0001 1000 0000 0000 0000 0000=20 240: 0000 0000 0000 0000 0000 0000 0000 0000=20 248: 0000 0000 0000 0000 0000 0000 0000 3aa5=20 pass0: ATA-8 SATA 2.x device pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-8 SATA 2.x device model WDC WD15EARS-00Z5B1 firmware revision 80.00A80 serial number WD-WMAVU1512579 WWN 50014ee05743482f cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 268435455 sectors LBA48 supported 2930277168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6=20 Feature Support Enable Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no 0/0x00 automatic acoustic management yes no 254/0xFE 128/0x80 media status notification no no power-up in Standby yes no write-read-verify no no 0/0x0 unload no no free-fall no no data set management (TRIM) no Seems that the only possible way to use this disks is adding permanent = (not like gnop) sector size emulation to some part of GEOM. -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(") From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 12:43:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6084106566C for ; Fri, 9 Apr 2010 12:43:23 +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 6114B8FC1C for ; Fri, 9 Apr 2010 12:43:23 +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 D7F1946B6C; Fri, 9 Apr 2010 08:43:22 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id E09BA8A025; Fri, 9 Apr 2010 08:43:21 -0400 (EDT) From: John Baldwin To: Guido Falsi Date: Fri, 9 Apr 2010 08:39:58 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <747dc8f31002220835g481b0baeqb1d6df32a79b7da2@mail.gmail.com> <201002240955.27357.jhb@freebsd.org> <20100409110123.GA42615@megatron.madpilot.net> In-Reply-To: <20100409110123.GA42615@megatron.madpilot.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004090839.58461.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 09 Apr 2010 08:43:22 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.8 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Brandon Gooch , freebsd-current@freebsd.org Subject: Re: ZFS boot problems with memory > 1MB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 12:43:23 -0000 On Friday 09 April 2010 7:01:23 am Guido Falsi wrote: > On Wed, Feb 24, 2010 at 09:55:27AM -0500, John Baldwin wrote: > > On Tuesday 23 February 2010 7:59:58 pm Brandon Gooch wrote: > > > On Tue, Feb 23, 2010 at 10:40 PM, John Baldwin wrote: > > > > On Tuesday 23 February 2010 5:04:03 pm Brandon Gooch wrote: > > > >> On Tue, Feb 23, 2010 at 3:03 PM, John Baldwin wrote: > [...] > > > >> > > > >> Adding printf statements to drvread(): > > > >> > > > >> printf("dsk->xxx: %u\n", dsk->xxx): > > > >> > > > >> Output: > > > >> > > > >> error 1 lba 48 > > > >> dsk->drive: 0 > > > >> dsk->type: 0 > > > >> dsk->unit: 0 > > > >> dsk->slice: 0 > > > >> dsk->part: 0 > > > >> dsk->init: 0 > > > >> dsk->start: 978673664 > > > > > > > > This value looks a bit high, do you have a partition that starts at an > > offset > > > > of about 466GB into the disk? > > > > > > > >> error 1 lba 1 > > > >> dsk->drive: 0 > > > >> dsk->type: 0 > > > >> dsk->unit: 0 > > > >> dsk->slice: 0 > > > >> dsk->part: 0 > > > >> dsk->init: 0 > > > >> dsk->start: 0 > > > >> No ZFS pools located, can't boot > > > > > > > > Sorry, I meant members of the 'packet' variable, though dsk->start is > > useful > > > > to have as well. > > > > > > > > -- > > > > John Baldwin > > > > > > > > > > Here it is (with some crazy dsk stuff included): > > > > > > error 1 lba 48 > > > packet.len: 16 > > > packet.seg: 8192 > > > packet.count: 16 > > > packet.lba: 47 > > > packet.off: 0 > > > dsk->drive: 4294967295 > > > dsk->slice: 4294967295 > > > dsk->type: 4294967295 > > > dsk->part: 4294967295 > > > dsk->unit: 4294967295 > > > dsk->init: 4294967295 > > > dsk->start: 4294967295 > > > > These are all -1 now which looks wrong. The raw LBA being 47 instead of 48 > > would seem to indicate that that is the case though. > > > > > error 1 lba 1 > > > packet.len: 16 > > > packet.seg: 8704 > > > packet.count: 1 > > > packet.lba: 1 > > > packet.off: 0 > > > > Odd that the lba here isn't 0. > > > > Can you add some more printfs, maybe to probe_drive() to try narrow down how > > many types that is being invoked and for which drive numbers? > > Hi! > > I'm seeing a very similar (perhaps the same) problem on a server I'm > trying to configure. > > Is there any news about this issue? > > This server is an HP DL360G6 server. Unluckily it has a smartarray thing > on it, the disk are behind it. > > I wanted to configure a 6 drive raidz2 with the driver > present(configured as stand alone raid0 units, this is as near you can > go to have the smartarray give direct access to the drive to the > system, I know this is not optimal.) > > After following the RootOnZFS instructions after boot the system gives > me the same symptoms the parent gets. Old gptzfsboot is not an option > here. It fails to malloc. I imagine 128K heap is not enough for my > setup. > > I tried adding some more printfs but it outputs really a lot of data. > especially from drive_probe(). I see it cycling through the drives and > reading various addresses, what surprises me is it gets very high LBA > numbers. For example the last try(which remains on screen) looks like > this: > > packet.len = 16 > packet.count = 16 > packet.off = 0 > packet.seg = 8192 > packet.lba = 1716867670 > dsk->drive = 133 > dsk->type = 0 > dsk->unit = 5 > dsk->slice = 0 > dsk->part = 0 > dsk->init = 0 > dsk->start = 1716867430 > > Hope this information helps. What error code are you seeing, 1? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 12:43:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69B52106564A; Fri, 9 Apr 2010 12:43:24 +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 36DD48FC1D; Fri, 9 Apr 2010 12:43:24 +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 CFF6246B65; Fri, 9 Apr 2010 08:43:23 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 01FC18A026; Fri, 9 Apr 2010 08:43:23 -0400 (EDT) From: John Baldwin To: "Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?=" Date: Fri, 9 Apr 2010 08:40:54 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <55861270658151@web135.yandex.ru> <86fx356ku1.fsf@ds4.des.no> In-Reply-To: <86fx356ku1.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201004090840.54701.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 09 Apr 2010 08:43:23 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.8 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Bruce Cran , freebsd-geom@freebsd.org, Alexander Leidinger , Teske , Randi Harper , freebsd-current@freebsd.org, "Andrey V. Elsukov" , Garrett Cooper Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 12:43:24 -0000 On Friday 09 April 2010 5:23:18 am Dag-Erling Sm=C3=B8rgrav wrote: > Garrett Cooper writes: > > Dag-Erling Sm=C3=B8rgrav writes: > > > Garrett Cooper writes: > > > > Dag-Erling Sm=C3=B8rgrav writes: > > > > > [restored relevant context which was removed earlier in the threa= d] > > > > > ...which is exactly what I said - but in the sysinstall case, you= =20 may > > > > > want to ask some additional questions ("are you sure you want to= =20 proceed > > > > > without a swap partition?") or place some additional constraints= =20 (such > > > > > as "don't allow the user to mount something on top of /mnt or=20 /rescue"), > > > > > and sysinstall needs to know the outcome. > > > > If the user shoots him or herself in the foot, that's their own > > > > problem. > > > That kind of attitude is why people choose Linux over FreeBSD... > > Where do you draw the line though? /media, /libexec, /proc, /sys, etc? > > I think it's better to educate users than build in more complexity to > > the install application. >=20 > I draw the line at mounting something - anything - on top of directories > that contain files that are critical to sysinstall's operation. IIRC, > /mnt is where the installation CD is mounted. =46YI, the CD is mounted at /dist. sysinstall mounts the new filesystems i= n=20 /mnt and then chroots into /mnt before doing the actual install. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 13:15:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D96AC10657DD; Fri, 9 Apr 2010 13:15:39 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 7F1598FC13; Fri, 9 Apr 2010 13:15:39 +0000 (UTC) Received: from megatron.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 6F0C3188F; Fri, 9 Apr 2010 15:15:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mail; t=1270818935; x= 1272633335; bh=pj1bZaBuId/0Kyc8QVElA8Mnh+lAiDl7nGewHXYbPQk=; b=p tkVBSsnlb/budp1JMfmREf0DdSVN4VK+gbokX8Idw9Lh6+Ex7x6IGI0stofOQxmT IaWXXACtzSR3KV6UtjeIB4j/BXJxmf/RVfGVD9BKwJ0/3Cz+I2kndBv9+MaH7ngp 2Ic9jhRt5enH/X2XeFQ3zBbVecaemq5R1S4nxgjVN0= X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by megatron.madpilot.net (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OemZfgS7aPOC; Fri, 9 Apr 2010 15:15:35 +0200 (CEST) Received: by megatron.madpilot.net (Postfix, from userid 1000) id AD7E31887; Fri, 9 Apr 2010 15:15:35 +0200 (CEST) Date: Fri, 9 Apr 2010 15:15:35 +0200 From: Guido Falsi To: John Baldwin Message-ID: <20100409131535.GB42615@megatron.madpilot.net> References: <747dc8f31002220835g481b0baeqb1d6df32a79b7da2@mail.gmail.com> <201002240955.27357.jhb@freebsd.org> <20100409110123.GA42615@megatron.madpilot.net> <201004090839.58461.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201004090839.58461.jhb@freebsd.org> X-Operating-System: FreeBSD 8.0-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Brandon Gooch , freebsd-current@freebsd.org Subject: Re: ZFS boot problems with memory > 1MB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 13:15:42 -0000 On Fri, Apr 09, 2010 at 08:39:58AM -0400, John Baldwin wrote: > On Friday 09 April 2010 7:01:23 am Guido Falsi wrote: > > On Wed, Feb 24, 2010 at 09:55:27AM -0500, John Baldwin wrote: > wrote: > > > > Hi! > > > > I'm seeing a very similar (perhaps the same) problem on a server I'm > > trying to configure. > > > > Is there any news about this issue? > > > > This server is an HP DL360G6 server. Unluckily it has a smartarray thing > > on it, the disk are behind it. > > > > I wanted to configure a 6 drive raidz2 with the driver > > present(configured as stand alone raid0 units, this is as near you can > > go to have the smartarray give direct access to the drive to the > > system, I know this is not optimal.) > > > > After following the RootOnZFS instructions after boot the system gives > > me the same symptoms the parent gets. Old gptzfsboot is not an option > > here. It fails to malloc. I imagine 128K heap is not enough for my > > setup. > > > > I tried adding some more printfs but it outputs really a lot of data. > > especially from drive_probe(). I see it cycling through the drives and > > reading various addresses, what surprises me is it gets very high LBA > > numbers. For example the last try(which remains on screen) looks like > > this: > > > > packet.len = 16 > > packet.count = 16 > > packet.off = 0 > > packet.seg = 8192 > > packet.lba = 1716867670 > > dsk->drive = 133 > > dsk->type = 0 > > dsk->unit = 5 > > dsk->slice = 0 > > dsk->part = 0 > > dsk->init = 0 > > dsk->start = 1716867430 > > > > Hope this information helps. > > What error code are you seeing, 1? Yes, exactly 1. With LBAs 1 or 32 reported in the error code(not the additional printfs I added). The error appears 8 times. Which is strange since the system has 6 disks, but 8 bays. -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 17:44:49 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C76F106566B for ; Fri, 9 Apr 2010 17:44:49 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id 1AD9C8FC21 for ; Fri, 9 Apr 2010 17:44:48 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id o39Hil6U032918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Apr 2010 12:44:47 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.3) with ESMTP id o39Hikbq098459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Apr 2010 12:44:46 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o39HikSs098456; Fri, 9 Apr 2010 12:44:46 -0500 (CDT) (envelope-from dan) Date: Fri, 9 Apr 2010 12:44:45 -0500 From: Dan Nelson To: Garrett Cooper Message-ID: <20100409174445.GA4359@dan.emsphone.com> References: <20100407173334.GC76941@dan.emsphone.com> <8114C0B7-2288-457C-88D6-E5E3B0CC4E51@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 8.0-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.95.3 at email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Fri, 09 Apr 2010 12:44:47 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: krad , current@freebsd.org Subject: Re: When will we can use ZFS v24? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 17:44:49 -0000 In the last episode (Apr 08), Garrett Cooper said: > On Thu, Apr 8, 2010 at 2:30 PM, Chuck Swiger wrote: > > On Apr 8, 2010, at 2:18 PM, krad wrote: > > [ ... ] > >>> is that even possible with CDDL? > >> > >> im not a lawyer but it wouldn't surprise me > > > > I'm not a lawyer either, but I was active in reviewing and suggesting > > changes to CDDL submission for OSI approval back in 2004. > > > > A copyright owner always has the ability to relicense their code under > > other terms, but existing code is guaranteed to be available, > > redistributable to others, etc under the terms of the current version of > > CDDL; in particular see: > > > > If Oracle chooses, they might make future changes to the ZFS source code > > under different or more restrictive licensing terms, but what's > > available now is always going to be available. > > The same of basic principle applies to BDB; originally it was BSD licensed > in 1.x under FreeBSD, then GPLed in 2.x+ (IIRC), then left to pasture in > 4.x after Oracle acquired Sleepycat DB. MySQL is GPLv2 today... who > knows what it might be tomorrow... BDB was never GPL'ed; it was and still is BSD-licensed. http://www.oracle.com/technology/software/products/berkeley-db/htdocs/oslicense.html -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 18:25:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F0291065674; Fri, 9 Apr 2010 18:25:52 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 8D4918FC15; Fri, 9 Apr 2010 18:25:51 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so1176602qwi.7 for ; Fri, 09 Apr 2010 11:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k4JAVSGcbsMdH8xHdtxZTh6I+PY9Hi9IXkm4HkBxV6k=; b=u991YrYzZQwNfePnbT3vZFCeQZZbEWDstTQyOcg4wxDAJY12Gs7M5K8A6dNKdT1Vyi t/ZOzcWpHJgS9/s5e+vvmwP15QHfnJL9A/bcheYWgJK2eazgUFkdhNg5IpOErKerhsye X6AOgRfE9RnK0BWDT4YvOKsxTiNKdfuhvIsLk= 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=B3IAfxB2BVHNXQkMjAftAIkpEOLJ4+hQ4LBCfLXbcQ5W7eUvImMclShqFFHP9Qbce6 xmoRSBWadLFl838Wvq5uofb3ZQIlYlEdZMSIzROL1SfLoAHYB58wOCzLo4xhpjY5Ziwv M1yrV9geFmvoeKDCgkSCw5qLYjiCyj/GxAuyM= MIME-Version: 1.0 Received: by 10.229.33.72 with HTTP; Fri, 9 Apr 2010 11:20:00 -0700 (PDT) In-Reply-To: <86fx356ku1.fsf@ds4.des.no> References: <55861270658151@web135.yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <201004080849.12151.jhb@freebsd.org> <86r5mqt4aj.fsf@ds4.des.no> <86sk75ol54.fsf@ds4.des.no> <86fx356ku1.fsf@ds4.des.no> Date: Fri, 9 Apr 2010 11:20:00 -0700 Received: by 10.229.211.204 with SMTP id gp12mr444117qcb.59.1270837200788; Fri, 09 Apr 2010 11:20:00 -0700 (PDT) Message-ID: From: Garrett Cooper To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , freebsd-geom@freebsd.org, Teske , Randi Harper , freebsd-current@freebsd.org, "Andrey V. Elsukov" , Alexander Leidinger Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 18:25:52 -0000 2010/4/9 Dag-Erling Sm=F8rgrav : > Garrett Cooper writes: >> Dag-Erling Sm=F8rgrav writes: >> > Garrett Cooper writes: >> > > Dag-Erling Sm=F8rgrav writes: >> > > > [restored relevant context which was removed earlier in the thread= ] >> > > > ...which is exactly what I said - but in the sysinstall case, you = may >> > > > want to ask some additional questions ("are you sure you want to p= roceed >> > > > without a swap partition?") or place some additional constraints (= such >> > > > as "don't allow the user to mount something on top of /mnt or /res= cue"), >> > > > and sysinstall needs to know the outcome. >> > > If the user shoots him or herself in the foot, that's their own >> > > problem. >> > That kind of attitude is why people choose Linux over FreeBSD... >> Where do you draw the line though? /media, /libexec, /proc, /sys, etc? >> I think it's better to educate users than build in more complexity to >> the install application. > > I draw the line at mounting something - anything - on top of directories > that contain files that are critical to sysinstall's operation. =A0IIRC, > /mnt is where the installation CD is mounted. Ok... rather than hardcoding this list into sysinstall or sade, it would be nice if it was in some kind of flexible metadata. > In sysinstall mode, sade's role is to 1) make sure that something > sensible is mounted in the location where sysinstall is going to install > the OS, 2) assist the user in making the correct disk, slice, partition > or what-have-you bootable, What is sensible today, may not be sensible for all cases or sensible tomorrow. For instance, there have been some reports about the `Auto defaults' in sysinstall completely screwing up the size as the default was way too low for /, and thus a user shot himself in the foot when doing a binary upgrade via freebsd-update. This `smart default' needs to exist as a minimum and maximum defined in some kind of metadata, and it would definitely help if one knew what the use-case would be for the machine, but one doesn't know this data from the way that things have been setup. > 3) within reasonable limits, prevent the user > from doing something that will break sysinstall, Point being, how do you qualify the act of not `break[ing] sysinstall'? > and 4) optionally allow > the user to prepare additional filesystems that sysinstall doesn't care > about (e.g. /usr/obj), as long as this does not conflict with 3). > > I think the easiest way to achieve this is for sysinstall to provide an > empty directory (e.g. /inst) and have sade operate with that directory > as root, so what the user sees is how things will look when the system > reboots after installation; when the user asks sade to create /usr/obj, > sade actually creates /inst/usr/obj. Now you're making a dangerous assumption that /inst isn't being used by the end-user for any predefined purpose. > Last but not least, sade should report what it did to sysinstall - > perhaps in fstab format, since sysinstall needs to populate > (/inst)/etc/fstab anyway. Ok. Or maybe since `we're here' sade needs to be populating $DESTDIR/etc/fstab, not sysinstall ? Ideally sysinstall should be a thin wrapper over a number of different utilities which would provide the code for thinking things together, not doing a bunch of operations. That way the code itself could be divorced from the activities it's performing a bit better and people could swap in other solutions as they feel fit (say the PCBSD QT installer, or the myriad of different installers available today for FreeBSD in GTK, QT, etc format). Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 19:00:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BDD51065689 for ; Fri, 9 Apr 2010 19:00:39 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2DCFF8FC24 for ; Fri, 9 Apr 2010 19:00:38 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id o39J0b0k051687; Fri, 9 Apr 2010 15:00:37 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201004091900.o39J0b0k051687@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 09 Apr 2010 15:00:30 -0400 To: Jack Vogel , pyunyh@gmail.com From: Mike Tancsa In-Reply-To: References: <201004081313.o38DD4JM041821@lava.sentex.ca> <201004081446.o38EkU7h042296@lava.sentex.ca> <20100408181741.GI5734@michelle.cdnetworks.com> <201004081831.o38IVR3s043434@lava.sentex.ca> <20100408205626.GN5734@michelle.cdnetworks.com> <201004082105.o38L5DCH044187@lava.sentex.ca> <20100408230750.GR5734@michelle.cdnetworks.com> <201004091317.o39DHFEl049965@lava.sentex.ca> <20100409164115.GB1085@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@freebsd.org Subject: LOR on em in HEAD ( was Re: em driver regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 19:00:39 -0000 While testing an i5 box with HEAD checked out from this morning, bringing up the second NIC generated this LOR on the console em1: link state changed to UP lock order reversal: 1st 0xc5dc7c10 em1:rx(1) (em1:rx(1)) @ /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4089 2nd 0xc0f7e88c udp (udp) @ /usr/HEAD/src/sys/netinet/udp_usrreq.c:454 KDB: stack backtrace: db_trace_self_wrapper(c0cb4d33,c5b72a70,c08e4d65,c08d50db,c0cb7d58,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08d50db,c0cb7d58,c5d31a98,c5d2cb60,c5b72acc,...) at kdb_backtrace+0x29 _witness_debugger(c0cb7d58,c0f7e88c,c0c9cf0b,c5d2cb60,c0cd04ca,...) at _witness_debugger+0x25 witness_checkorder(c0f7e88c,1,c0cd04ca,1c6,0,...) at witness_checkorder+0x839 _rw_rlock(c0f7e88c,c0cd04ca,1c6,c5d33088,c5e8be24,...) at _rw_rlock+0x9c udp_input(c67faa00,14,0,c5e8bd80,c0dfa860,...) at udp_input+0x246 ip_input(c67faa00,c5f2f380,c5b72be8,c07463b6,c0dfa860,...) at ip_input+0x606 netisr_dispatch_src(1,0,c67faa00,c5b72c20,c0954bc1,...) at netisr_dispatch_src+0xcd netisr_dispatch(1,c67faa00,c6018c00,c6018c00,c6852800,...) at netisr_dispatch+0x20 ether_demux(c6018c00,c67faa00,3,0,3,...) at ether_demux+0x1a1 ether_input(c6018c00,c67faa00,c11a0e17,ff9,64,...) at ether_input+0x365 em_rxeof(c5e8bd80,109,c6016180,0,c5b72cc8,...) at em_rxeof+0x13c em_msix_rx(c5dc7c00,c5b72cc8,c088eb14,c0e133c0,c60342b8,...) at em_msix_rx+0x25 intr_event_execute_handlers(c5d807f8,c6034280,c0cacd7e,533,c60342f0,...) at intr_event_execute_handlers+0x125 ithread_loop(c603b4a0,c5b72d38,c0cacaed,343,c5d807f8,...) at ithread_loop+0x9f fork_exit(c0877800,c603b4a0,c5b72d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc5b72d70, ebp = 0 --- 0(i5b)# uname -a FreeBSD i5b.sentex.ca 9.0-CURRENT FreeBSD 9.0-CURRENT #2: Fri Apr 9 11:56:25 EDT 2010 mdtancsa@ich10.sentex.ca:/usr/HEAD/obj/usr/HEAD/src/sys/GENERIC i386 0(i5b)# em0@pci0:0:25:0: class=0x020000 card=0x34ec8086 chip=0x10ef8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP em1@pci0:3:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled 0(i5b)# vmstat -i interrupt total rate irq4: uart0 6156 3 irq8: rtc 224879 127 irq21: ehci0 2662 1 irq23: ehci1 3674 2 cpu0: timer 1754210 998 irq256: em0 10778 6 irq257: em1 331 0 irq258: em1 4 0 irq260: em1 4 0 irq261: em1 8 0 irq262: ahci0 69 0 cpu3: timer 1753938 998 cpu2: timer 1753932 998 cpu1: timer 1753886 998 Total 7264531 4134 0(i5b)# CPU: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz (2666.65-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106e5 Family = 6 Model = 1e Stepping = 5 Features=0xbfebfbff Features2=0x98e3fd AMD Features=0x28100000 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 2577711104 (2458 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 19:09:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87AB0106564A for ; Fri, 9 Apr 2010 19:09:26 +0000 (UTC) (envelope-from jfvogel@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 15A3D8FC15 for ; Fri, 9 Apr 2010 19:09:25 +0000 (UTC) Received: by wyb28 with SMTP id 28so206547wyb.13 for ; Fri, 09 Apr 2010 12:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=Cv9ts+Ew9G8Ni+YOifckTpaW1uQVS4yXcoJ11UYYuRY=; b=KwCmk87Y5Cr1rgbvyJjcXwUXVghZAf9qPM7SWg18QJfllxVlv279xzBXQmCauiOfsj LC0RTfELZjh/2w3F8/E6Znfh51FNiyWGtOov/OuD+bW74NopdEvwrwPuPC8ktPxrE/+6 Kd7Yf0gG4nKf/VPEuERU+p6nE1TEmn8G+lgXE= 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=P66Dv8ecpVnMbNuANc2ECAsfiYwen3s1+3+pICigf9WJvUnKbrMxYz7A72qyMa3W3v XgOXBdaIXfm0u5m7uJw18xC4gPU+m6mizw8RSzU07sowQi6VOcvcLT0dUm0oxQFt1xwK ywaZhx1PiIH62UfcTL4Pq2LgWECH9L5aBO2uA= MIME-Version: 1.0 Received: by 10.216.11.8 with HTTP; Fri, 9 Apr 2010 12:09:24 -0700 (PDT) In-Reply-To: <201004091900.o39J0b0k051687@lava.sentex.ca> References: <201004081313.o38DD4JM041821@lava.sentex.ca> <201004081831.o38IVR3s043434@lava.sentex.ca> <20100408205626.GN5734@michelle.cdnetworks.com> <201004082105.o38L5DCH044187@lava.sentex.ca> <20100408230750.GR5734@michelle.cdnetworks.com> <201004091317.o39DHFEl049965@lava.sentex.ca> <20100409164115.GB1085@michelle.cdnetworks.com> <201004091900.o39J0b0k051687@lava.sentex.ca> Date: Fri, 9 Apr 2010 12:09:24 -0700 Received: by 10.216.88.131 with SMTP id a3mr245816wef.153.1270840164099; Fri, 09 Apr 2010 12:09:24 -0700 (PDT) Message-ID: From: Jack Vogel To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, freebsd-current@freebsd.org Subject: Re: LOR on em in HEAD ( was Re: em driver regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 19:09:26 -0000 Someone else also pointed this out. I'm dubious about its claim. This happens because there is an RX lock taken in rxeof, its held thru the call into the stack, it then encounters another lock there and hence this complaint. I've had the RX hold as it is for a long while and would rather not have to give it up, can someone look at it and advise? Cheers, Jack On Fri, Apr 9, 2010 at 12:00 PM, Mike Tancsa wrote: > While testing an i5 box with HEAD checked out from this morning, bringing > up the second NIC generated this LOR on the console > > em1: link state changed to UP > lock order reversal: > 1st 0xc5dc7c10 em1:rx(1) (em1:rx(1)) @ > /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4089 > 2nd 0xc0f7e88c udp (udp) @ /usr/HEAD/src/sys/netinet/udp_usrreq.c:454 > KDB: stack backtrace: > db_trace_self_wrapper(c0cb4d33,c5b72a70,c08e4d65,c08d50db,c0cb7d58,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c08d50db,c0cb7d58,c5d31a98,c5d2cb60,c5b72acc,...) at > kdb_backtrace+0x29 > _witness_debugger(c0cb7d58,c0f7e88c,c0c9cf0b,c5d2cb60,c0cd04ca,...) at > _witness_debugger+0x25 > witness_checkorder(c0f7e88c,1,c0cd04ca,1c6,0,...) at > witness_checkorder+0x839 > _rw_rlock(c0f7e88c,c0cd04ca,1c6,c5d33088,c5e8be24,...) at _rw_rlock+0x9c > udp_input(c67faa00,14,0,c5e8bd80,c0dfa860,...) at udp_input+0x246 > ip_input(c67faa00,c5f2f380,c5b72be8,c07463b6,c0dfa860,...) at > ip_input+0x606 > netisr_dispatch_src(1,0,c67faa00,c5b72c20,c0954bc1,...) at > netisr_dispatch_src+0xcd > netisr_dispatch(1,c67faa00,c6018c00,c6018c00,c6852800,...) at > netisr_dispatch+0x20 > ether_demux(c6018c00,c67faa00,3,0,3,...) at ether_demux+0x1a1 > ether_input(c6018c00,c67faa00,c11a0e17,ff9,64,...) at ether_input+0x365 > em_rxeof(c5e8bd80,109,c6016180,0,c5b72cc8,...) at em_rxeof+0x13c > em_msix_rx(c5dc7c00,c5b72cc8,c088eb14,c0e133c0,c60342b8,...) at > em_msix_rx+0x25 > intr_event_execute_handlers(c5d807f8,c6034280,c0cacd7e,533,c60342f0,...) at > intr_event_execute_handlers+0x125 > ithread_loop(c603b4a0,c5b72d38,c0cacaed,343,c5d807f8,...) at > ithread_loop+0x9f > fork_exit(c0877800,c603b4a0,c5b72d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc5b72d70, ebp = 0 --- > > 0(i5b)# uname -a > FreeBSD i5b.sentex.ca 9.0-CURRENT FreeBSD 9.0-CURRENT #2: Fri Apr 9 > 11:56:25 EDT 2010 mdtancsa@ich10.sentex.ca:/usr/HEAD/obj/usr/HEAD/src/sys/GENERIC > i386 > 0(i5b)# > > em0@pci0:0:25:0: class=0x020000 card=0x34ec8086 chip=0x10ef8086 > rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 13[e0] = PCI Advanced Features: FLR TP > em1@pci0:3:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled > > > 0(i5b)# vmstat -i > interrupt total rate > irq4: uart0 6156 3 > irq8: rtc 224879 127 > irq21: ehci0 2662 1 > irq23: ehci1 3674 2 > cpu0: timer 1754210 998 > irq256: em0 10778 6 > irq257: em1 331 0 > irq258: em1 4 0 > irq260: em1 4 0 > irq261: em1 8 0 > irq262: ahci0 69 0 > cpu3: timer 1753938 998 > cpu2: timer 1753932 998 > cpu1: timer 1753886 998 > Total 7264531 4134 > 0(i5b)# > > CPU: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz (2666.65-MHz 686-class > CPU) > Origin = "GenuineIntel" Id = 0x106e5 Family = 6 Model = 1e Stepping = > 5 > > Features=0xbfebfbff > > Features2=0x98e3fd > AMD Features=0x28100000 > AMD Features2=0x1 > TSC: P-state invariant > real memory = 4294967296 (4096 MB) > avail memory = 2577711104 (2458 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > > > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 19:08:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96BCD106564A; Fri, 9 Apr 2010 19:08:16 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward3.mail.yandex.net (forward3.mail.yandex.net [77.88.46.8]) by mx1.freebsd.org (Postfix) with ESMTP id F12AB8FC08; Fri, 9 Apr 2010 19:08:14 +0000 (UTC) Received: from web44.yandex.ru (web44.yandex.ru [77.88.47.183]) by forward3.mail.yandex.net (Yandex) with ESMTP id 1A90456D99EF; Fri, 9 Apr 2010 23:08:13 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1270840093; bh=fUJeAkVjNt9ZQENbeGu0NxNZzuP74i7UMu4uUvTYFRo=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=huqwTJb9bUykPEscYmZlUMLbK2LjnuMecgwu6hSq/FMtixt69H5QFDQmz4SXY1Fnn YfGSqMhGQZpnNc3JpAm6g70gIlvrmadbuPQm+HNn6JCYsJhODLuOvK+OwpkAoLKfC7 DAEnKjXT1A2RCqdVkR/TrGVs2Wdzr5wlIoDPzZuA= Received: from localhost (localhost.localdomain [127.0.0.1]) by web44.yandex.ru (Yandex) with ESMTP id 1164A758039; Fri, 9 Apr 2010 23:08:13 +0400 (MSD) X-Yandex-Spam: 1 X-Yandex-Front: web44.yandex.ru X-Yandex-TimeMark: 1270840093 Received: from www.heavennet.ru (www.heavennet.ru [77.72.136.193]) by mail.yandex.ru with HTTP; Fri, 09 Apr 2010 23:08:11 +0400 From: Andrey V. Elsukov To: Garrett Cooper In-Reply-To: References: <55861270658151@web135.yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <201004080849.12151.jhb@freebsd.org> <86r5mqt4aj.fsf@ds4.des.no> <86sk75ol54.fsf@ds4.des.no> <86fx356ku1.fsf@ds4.des.no> MIME-Version: 1.0 Message-Id: <232101270840092@web44.yandex.ru> Date: Fri, 09 Apr 2010 23:08:12 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailman-Approved-At: Fri, 09 Apr 2010 19:39:28 +0000 Cc: Bruce Cran , Marcel Moolenaar , freebsd-geom@freebsd.org, Teske , Randi Harper , freebsd-current@freebsd.org, Alexander Leidinger , =?utf-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= Subject: Re: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 19:08:17 -0000 09.04.10, 11:20, "Garrett Cooper" : > Ok. Or maybe since `we're here' sade needs to be populating > $DESTDIR/etc/fstab, not sysinstall ? I'm also looking for answer to this question. It seems that all basic operations with partitions are already implemented. And I think about next steps. Also I think I should make a dialog for writing bootcode. And there are a bunch of different bootstrap code which can be used with different schemes. So if anyone can share own experience I'll be grateful. MBR: /boot/mbr - standart boot record (is it needed? Is it not the same which gpart creates?). /boot/boot0 - boot0 boot manager. /boot/boot0sio - boot0 boot manager with redirected output ot com1. GPT: /boot/pmbr - protective mbr /boot/gptboot - bootstrap code for booting from GPT, should be installed to freebsd-boot partition. /boot/gptzfsboot - bootstrap code for booting from GPT and ZFS, should be installed to freebsd-boot partition. /boot/zfsboot - bootstrap code for booting from ZFS from MBR, it seems this bootcode doesn't have a correct way (e.g `gpart bootcode ...`) to be writed. What about VTOC8, PC98, APM? -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 20:13:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C16931065670 for ; Fri, 9 Apr 2010 20:13:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4771A8FC19 for ; Fri, 9 Apr 2010 20:13:12 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id d26so247645eyd.9 for ; Fri, 09 Apr 2010 13:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=SW1UunJPh9HmhNmbNj6BHK69QPQ5JxEWEVhPO8Y5xA0=; b=mReD0WYLfp4U9gX/8Xlmj73OHkCQp8/5y3LEQoehwAGFcqEjB/d+ts4C2ewoj+oZbH ZrdBKpm1Wx3Sb++V1MfaKqz8H8rtbInBar6sB1rbb9H6F+MIZJq8/1v/Pn30RykMBgUu /9nsaARadRHnZwiqfSEJ/SWKEAwzuJuYF63tU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=aHyw9CG2XPoBS95ADcXmfeSozfR3uvKQ0y/H25vMMsi3V8rHjN0k/iCANeTvRnW2oh 6p7kqSB2oDwn4v2rDHaZJwGywgBMkz2tLFb0ZPozL29r/aHqke6Bjazr3vjud09dJN54 0q/MGlRDfYNzWnfv59A/zgbKnKgDftPu6jAkU= Received: by 10.213.39.197 with SMTP id h5mr286325ebe.35.1270843991908; Fri, 09 Apr 2010 13:13:11 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 14sm1002481ewy.6.2010.04.09.13.13.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Apr 2010 13:13:10 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 9 Apr 2010 13:13:07 -0700 From: Pyun YongHyeon Date: Fri, 9 Apr 2010 13:13:07 -0700 To: Jack Vogel Message-ID: <20100409201307.GF1085@michelle.cdnetworks.com> References: <201004081831.o38IVR3s043434@lava.sentex.ca> <20100408205626.GN5734@michelle.cdnetworks.com> <201004082105.o38L5DCH044187@lava.sentex.ca> <20100408230750.GR5734@michelle.cdnetworks.com> <201004091317.o39DHFEl049965@lava.sentex.ca> <20100409164115.GB1085@michelle.cdnetworks.com> <201004091900.o39J0b0k051687@lava.sentex.ca> 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: freebsd-current@freebsd.org, Mike Tancsa Subject: Re: LOR on em in HEAD ( was Re: em driver regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 20:13:13 -0000 On Fri, Apr 09, 2010 at 12:09:24PM -0700, Jack Vogel wrote: > Someone else also pointed this out. I'm dubious about its claim. I can't reproduce the LOR with latest em(4)(r206429). > This happens because there is an RX lock taken in rxeof, its held > thru the call into the stack, it then encounters another lock there > and hence this complaint. I've had the RX hold as it is for a long > while and would rather not have to give it up, can someone look > at it and advise? > > Cheers, > > Jack > > > On Fri, Apr 9, 2010 at 12:00 PM, Mike Tancsa wrote: > > > While testing an i5 box with HEAD checked out from this morning, bringing > > up the second NIC generated this LOR on the console > > > > em1: link state changed to UP > > lock order reversal: > > 1st 0xc5dc7c10 em1:rx(1) (em1:rx(1)) @ > > /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4089 > > 2nd 0xc0f7e88c udp (udp) @ /usr/HEAD/src/sys/netinet/udp_usrreq.c:454 > > KDB: stack backtrace: > > db_trace_self_wrapper(c0cb4d33,c5b72a70,c08e4d65,c08d50db,c0cb7d58,...) at > > db_trace_self_wrapper+0x26 > > kdb_backtrace(c08d50db,c0cb7d58,c5d31a98,c5d2cb60,c5b72acc,...) at > > kdb_backtrace+0x29 > > _witness_debugger(c0cb7d58,c0f7e88c,c0c9cf0b,c5d2cb60,c0cd04ca,...) at > > _witness_debugger+0x25 > > witness_checkorder(c0f7e88c,1,c0cd04ca,1c6,0,...) at > > witness_checkorder+0x839 > > _rw_rlock(c0f7e88c,c0cd04ca,1c6,c5d33088,c5e8be24,...) at _rw_rlock+0x9c > > udp_input(c67faa00,14,0,c5e8bd80,c0dfa860,...) at udp_input+0x246 > > ip_input(c67faa00,c5f2f380,c5b72be8,c07463b6,c0dfa860,...) at > > ip_input+0x606 > > netisr_dispatch_src(1,0,c67faa00,c5b72c20,c0954bc1,...) at > > netisr_dispatch_src+0xcd > > netisr_dispatch(1,c67faa00,c6018c00,c6018c00,c6852800,...) at > > netisr_dispatch+0x20 > > ether_demux(c6018c00,c67faa00,3,0,3,...) at ether_demux+0x1a1 > > ether_input(c6018c00,c67faa00,c11a0e17,ff9,64,...) at ether_input+0x365 > > em_rxeof(c5e8bd80,109,c6016180,0,c5b72cc8,...) at em_rxeof+0x13c > > em_msix_rx(c5dc7c00,c5b72cc8,c088eb14,c0e133c0,c60342b8,...) at > > em_msix_rx+0x25 > > intr_event_execute_handlers(c5d807f8,c6034280,c0cacd7e,533,c60342f0,...) at > > intr_event_execute_handlers+0x125 > > ithread_loop(c603b4a0,c5b72d38,c0cacaed,343,c5d807f8,...) at > > ithread_loop+0x9f > > fork_exit(c0877800,c603b4a0,c5b72d38) at fork_exit+0xb8 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0, eip = 0, esp = 0xc5b72d70, ebp = 0 --- > > > > 0(i5b)# uname -a > > FreeBSD i5b.sentex.ca 9.0-CURRENT FreeBSD 9.0-CURRENT #2: Fri Apr 9 > > 11:56:25 EDT 2010 mdtancsa@ich10.sentex.ca:/usr/HEAD/obj/usr/HEAD/src/sys/GENERIC > > i386 > > 0(i5b)# > > > > em0@pci0:0:25:0: class=0x020000 card=0x34ec8086 chip=0x10ef8086 > > rev=0x05 hdr=0x00 > > vendor = 'Intel Corporation' > > class = network > > subclass = ethernet > > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > cap 13[e0] = PCI Advanced Features: FLR TP > > em1@pci0:3:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 rev=0x00 > > hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > > class = network > > subclass = ethernet > > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > cap 05[d0] = MSI supports 1 message, 64 bit > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled > > > > > > 0(i5b)# vmstat -i > > interrupt total rate > > irq4: uart0 6156 3 > > irq8: rtc 224879 127 > > irq21: ehci0 2662 1 > > irq23: ehci1 3674 2 > > cpu0: timer 1754210 998 > > irq256: em0 10778 6 > > irq257: em1 331 0 > > irq258: em1 4 0 > > irq260: em1 4 0 > > irq261: em1 8 0 > > irq262: ahci0 69 0 > > cpu3: timer 1753938 998 > > cpu2: timer 1753932 998 > > cpu1: timer 1753886 998 > > Total 7264531 4134 > > 0(i5b)# > > > > CPU: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz (2666.65-MHz 686-class > > CPU) > > Origin = "GenuineIntel" Id = 0x106e5 Family = 6 Model = 1e Stepping = > > 5 > > > > Features=0xbfebfbff > > > > Features2=0x98e3fd > > AMD Features=0x28100000 > > AMD Features2=0x1 > > TSC: P-state invariant > > real memory = 4294967296 (4096 MB) > > avail memory = 2577711104 (2458 MB) > > ACPI APIC Table: > > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > > > > > > > > > -------------------------------------------------------------------- > > Mike Tancsa, tel +1 519 651 3400 > > Sentex Communications, mike@sentex.net > > Providing Internet since 1994 www.sentex.net > > Cambridge, Ontario Canada www.sentex.net/mike > > > > From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 20:16:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8AC8106564A for ; Fri, 9 Apr 2010 20:16:42 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 468C98FC19 for ; Fri, 9 Apr 2010 20:16:41 +0000 (UTC) Received: by wwb24 with SMTP id 24so1145648wwb.13 for ; Fri, 09 Apr 2010 13:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=dUyvjQi+hO+g94HEOGviYEDzzzMcJNWWXm1XE0IYJOw=; b=GgAz2qYXCs2sBhraQUyqdytbjQZXTVyokFY03qrA79yLiY+jUHptuL8fEs+zRXRZB0 n44xHDo54U7T0MQBXiK1HkoOZNkyWo+s0HuY5ShEqUDfAcYokmycoTATu3XYxwOd9xko rtKhk26xYZ8ACDxj/xE5GMCNax22KKcLAB8sA= 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=ANFvn+YmwKb4W6szeQM4wKQOiTMBg8TcLe83gqhZUDVCta3MTkHVTHzzkNfxuIyJxM CW5EWX9rvTqg64I483sWaRifWOKelO2JXXflcezDM9eqdpBMWaKyAXZFwC3xMEOjxiaU I3sBC89ttrEPGoeo0OhdbmiUM122tffa+AOCI= MIME-Version: 1.0 Received: by 10.216.11.8 with HTTP; Fri, 9 Apr 2010 13:16:40 -0700 (PDT) In-Reply-To: <20100409201307.GF1085@michelle.cdnetworks.com> References: <201004081831.o38IVR3s043434@lava.sentex.ca> <201004082105.o38L5DCH044187@lava.sentex.ca> <20100408230750.GR5734@michelle.cdnetworks.com> <201004091317.o39DHFEl049965@lava.sentex.ca> <20100409164115.GB1085@michelle.cdnetworks.com> <201004091900.o39J0b0k051687@lava.sentex.ca> <20100409201307.GF1085@michelle.cdnetworks.com> Date: Fri, 9 Apr 2010 13:16:40 -0700 Received: by 10.216.185.139 with SMTP id u11mr321710wem.13.1270844201167; Fri, 09 Apr 2010 13:16:41 -0700 (PDT) Message-ID: From: Jack Vogel To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Mike Tancsa Subject: Re: LOR on em in HEAD ( was Re: em driver regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 20:16:42 -0000 On Fri, Apr 9, 2010 at 1:13 PM, Pyun YongHyeon wrote: > On Fri, Apr 09, 2010 at 12:09:24PM -0700, Jack Vogel wrote: > > Someone else also pointed this out. I'm dubious about its claim. > > I can't reproduce the LOR with latest em(4)(r206429). > > Hmmm, wonder what changed that effected that, oh well that's good :) Jack From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 21:05:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A6BC1065780 for ; Fri, 9 Apr 2010 21:05:30 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1161C8FC38 for ; Fri, 9 Apr 2010 21:05:29 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id o39L5SSh052323; Fri, 9 Apr 2010 17:05:28 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201004092105.o39L5SSh052323@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 09 Apr 2010 17:05:22 -0400 To: pyunyh@gmail.com, Jack Vogel From: Mike Tancsa In-Reply-To: <20100409201307.GF1085@michelle.cdnetworks.com> References: <201004081831.o38IVR3s043434@lava.sentex.ca> <20100408205626.GN5734@michelle.cdnetworks.com> <201004082105.o38L5DCH044187@lava.sentex.ca> <20100408230750.GR5734@michelle.cdnetworks.com> <201004091317.o39DHFEl049965@lava.sentex.ca> <20100409164115.GB1085@michelle.cdnetworks.com> <201004091900.o39J0b0k051687@lava.sentex.ca> <20100409201307.GF1085@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: LOR on em in HEAD ( was Re: em driver regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 21:05:30 -0000 At 04:13 PM 4/9/2010, Pyun YongHyeon wrote: >On Fri, Apr 09, 2010 at 12:09:24PM -0700, Jack Vogel wrote: > > Someone else also pointed this out. I'm dubious about its claim. > >I can't reproduce the LOR with latest em(4)(r206429). I still get it for some reason 1st 0xc5dc7610 em1:rx(1) (em1:rx(1)) @ /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4087 2nd 0xc0f7df0c udp (udp) @ /usr/HEAD/src/sys/netinet/udp_usrreq.c:454 KDB: stack backtrace: db_trace_self_wrapper(c0cb4313,c5b72a64,c08e4305,c08d467b,c0cb7338,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08d467b,c0cb7338,c5d31a98,c5d2cb60,c5b72ac0,...) at kdb_backtrace+0x29 _witness_debugger(c0cb7338,c0f7df0c,c0c9c4eb,c5d2cb60,c0ccfaf7,...) at _witness_debugger+0x25 witness_checkorder(c0f7df0c,1,c0ccfaf7,1c6,0,...) at witness_checkorder+0x839 _rw_rlock(c0f7df0c,c0ccfaf7,1c6,c5d33088,c5e8be24,...) at _rw_rlock+0x9c udp_input(c6905900,14,0,c5e8bd80,c0df9ee0,...) at udp_input+0x246 ip_input(c6905900,c5f39240,c5b72bdc,c0745956,c0df9ee0,...) at ip_input+0x606 netisr_dispatch_src(1,0,c6905900,c5b72c14,c0954161,...) at netisr_dispatch_src+0xcd netisr_dispatch(1,c6905900,c6018c00,c6018c00,c6925800,...) at netisr_dispatch+0x20 ether_demux(c6018c00,c6905900,3,0,3,...) at ether_demux+0x1a1 ether_input(c6018c00,c6905900,c119f2d7,ff7,63,...) at ether_input+0x365 em_rxeof(c5e8bd80,109,c6016180,0,c5b72cc8,...) at em_rxeof+0x133 em_msix_rx(c5dc7600,c5b72cc8,c088e0b4,c0e13740,c60342b8,...) at em_msix_rx+0x25 intr_event_execute_handlers(c5d807f8,c6034280,c0cac35e,533,c60342f0,...) at intr_event_execute_handlers+0x125 ithread_loop(c603b4a0,c5b72d38,c0cac0cd,343,c5d807f8,...) at ithread_loop+0x9f fork_exit(c0876da0,c603b4a0,c5b72d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc5b72d70, ebp = 0 --- Perhaps because multi-queue is still enabled ? 0(i5b)% vmstat -i interrupt total rate irq4: uart0 6637 28 irq21: ehci0 382 1 irq23: ehci1 615 2 cpu0: timer 462573 1993 irq256: em0 7640 32 irq257: em1 5 0 irq258: em1 6 0 irq261: em1 2 0 irq262: ahci0 69 0 cpu3: timer 461507 1989 cpu2: timer 460985 1987 cpu1: timer 461545 1989 Total 1861966 8025 0(i5b)% em0: port 0x3040-0x305f mem 0xc1b00000-0xc1b1ffff,0xc1b25000-0xc1b25fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:c8:4b:99 ehci0: mem 0xc1b22000-0xc1b223ff irq 21 at device 26.0 on pci0 ehci0: [ITHREAD] usbus0: EHCI version 1.0 usbus0: on ehci0 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 16 at device 28.4 on pci0 pci3: on pcib3 em1: port 0x1000-0x101f mem 0xc1900000-0xc191ffff,0xc1920000-0xc1923fff irq 16 at device 0.0 on pci3 em1: Using MSIX interrupts with 5 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:15:17:c8:4b:98 -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 21:11:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E76DE1065673 for ; Fri, 9 Apr 2010 21:11:56 +0000 (UTC) (envelope-from jfvogel@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 251DF8FC1A for ; Fri, 9 Apr 2010 21:11:55 +0000 (UTC) Received: by wyb28 with SMTP id 28so248317wyb.13 for ; Fri, 09 Apr 2010 14:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=+YdQluIevLR1eQ0SzZPisNSABAghnDCCZT7v3cLNDj8=; b=LYV68bmc2mCwPaaGTaiO7yqpNEIg7dUFyDqSyhvDPBTPbo6Mbc29KbJH9SE65L1zeY BoKD99qurNRG3jKig6OYwBLUO0bVUrnGxVNbzF/M6PMjaXzBvomJ6VpMTvA3DRdax1CP 8p/K0pGSxOL6u475cA8gnj9l4magelVqivGLU= 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=fxmW54qXjY2xh1IPiUsM3N8KdtPY8Nwd23IgIfOgrI856O+Zxk+1cSIMAPIYZnmExp Ek/2Az+ECQgb24hmTg0Ldk5F64xyQQM1GMglkxHJw56cQPw3DD3FkKcLZtX+gYjdvWfT kT5ddqfAhKcb3lDyFmyoxZ9vK8aAuzMlBhGco= MIME-Version: 1.0 Received: by 10.216.11.8 with HTTP; Fri, 9 Apr 2010 14:11:54 -0700 (PDT) In-Reply-To: <201004092105.o39L5SSh052323@lava.sentex.ca> References: <201004081831.o38IVR3s043434@lava.sentex.ca> <20100408230750.GR5734@michelle.cdnetworks.com> <201004091317.o39DHFEl049965@lava.sentex.ca> <20100409164115.GB1085@michelle.cdnetworks.com> <201004091900.o39J0b0k051687@lava.sentex.ca> <20100409201307.GF1085@michelle.cdnetworks.com> <201004092105.o39L5SSh052323@lava.sentex.ca> Date: Fri, 9 Apr 2010 14:11:54 -0700 Received: by 10.216.157.202 with SMTP id o52mr322693wek.227.1270847514926; Fri, 09 Apr 2010 14:11:54 -0700 (PDT) Message-ID: From: Jack Vogel To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, freebsd-current@freebsd.org Subject: Re: LOR on em in HEAD ( was Re: em driver regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 21:11:57 -0000 Don't know, but I would just ignore it, I think its a false warning anyway. Jack On Fri, Apr 9, 2010 at 2:05 PM, Mike Tancsa wrote: > At 04:13 PM 4/9/2010, Pyun YongHyeon wrote: > >> On Fri, Apr 09, 2010 at 12:09:24PM -0700, Jack Vogel wrote: >> > Someone else also pointed this out. I'm dubious about its claim. >> >> I can't reproduce the LOR with latest em(4)(r206429). >> > > > I still get it for some reason > > 1st 0xc5dc7610 em1:rx(1) (em1:rx(1)) @ > /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4087 > 2nd 0xc0f7df0c udp (udp) @ /usr/HEAD/src/sys/netinet/udp_usrreq.c:454 > KDB: stack backtrace: > db_trace_self_wrapper(c0cb4313,c5b72a64,c08e4305,c08d467b,c0cb7338,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c08d467b,c0cb7338,c5d31a98,c5d2cb60,c5b72ac0,...) at > kdb_backtrace+0x29 > _witness_debugger(c0cb7338,c0f7df0c,c0c9c4eb,c5d2cb60,c0ccfaf7,...) at > _witness_debugger+0x25 > witness_checkorder(c0f7df0c,1,c0ccfaf7,1c6,0,...) at > witness_checkorder+0x839 > _rw_rlock(c0f7df0c,c0ccfaf7,1c6,c5d33088,c5e8be24,...) at _rw_rlock+0x9c > udp_input(c6905900,14,0,c5e8bd80,c0df9ee0,...) at udp_input+0x246 > ip_input(c6905900,c5f39240,c5b72bdc,c0745956,c0df9ee0,...) at > ip_input+0x606 > netisr_dispatch_src(1,0,c6905900,c5b72c14,c0954161,...) at > netisr_dispatch_src+0xcd > netisr_dispatch(1,c6905900,c6018c00,c6018c00,c6925800,...) at > netisr_dispatch+0x20 > ether_demux(c6018c00,c6905900,3,0,3,...) at ether_demux+0x1a1 > ether_input(c6018c00,c6905900,c119f2d7,ff7,63,...) at ether_input+0x365 > em_rxeof(c5e8bd80,109,c6016180,0,c5b72cc8,...) at em_rxeof+0x133 > em_msix_rx(c5dc7600,c5b72cc8,c088e0b4,c0e13740,c60342b8,...) at > em_msix_rx+0x25 > intr_event_execute_handlers(c5d807f8,c6034280,c0cac35e,533,c60342f0,...) at > intr_event_execute_handlers+0x125 > ithread_loop(c603b4a0,c5b72d38,c0cac0cd,343,c5d807f8,...) at > ithread_loop+0x9f > fork_exit(c0876da0,c603b4a0,c5b72d38) at fork_exit+0xb8 > > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc5b72d70, ebp = 0 --- > > Perhaps because multi-queue is still enabled ? > > > 0(i5b)% vmstat -i > interrupt total rate > irq4: uart0 6637 28 > irq21: ehci0 382 1 > irq23: ehci1 615 2 > cpu0: timer 462573 1993 > irq256: em0 7640 32 > irq257: em1 5 0 > irq258: em1 6 0 > > irq261: em1 2 0 > irq262: ahci0 69 0 > cpu3: timer 461507 1989 > cpu2: timer 460985 1987 > cpu1: timer 461545 1989 > Total 1861966 8025 > 0(i5b)% > > > em0: port 0x3040-0x305f mem > 0xc1b00000-0xc1b1ffff,0xc1b25000-0xc1b25fff irq 20 at device 25.0 on pci0 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:15:17:c8:4b:99 > ehci0: mem 0xc1b22000-0xc1b223ff irq > 21 at device 26.0 on pci0 > ehci0: [ITHREAD] > usbus0: EHCI version 1.0 > usbus0: on ehci0 > pcib2: irq 16 at device 28.0 on pci0 > pci2: on pcib2 > pcib3: irq 16 at device 28.4 on pci0 > pci3: on pcib3 > em1: port 0x1000-0x101f mem > 0xc1900000-0xc191ffff,0xc1920000-0xc1923fff irq 16 at device 0.0 on pci3 > em1: Using MSIX interrupts with 5 vectors > em1: [ITHREAD] > em1: [ITHREAD] > em1: [ITHREAD] > em1: [ITHREAD] > em1: [ITHREAD] > em1: Ethernet address: 00:15:17:c8:4b:98 > > > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 23:53:12 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BC501065672 for ; Fri, 9 Apr 2010 23:53:12 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 78DAC8FC19 for ; Fri, 9 Apr 2010 23:53:11 +0000 (UTC) Received: (qmail 31737 invoked by uid 399); 9 Apr 2010 23:53:10 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 9 Apr 2010 23:53:10 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Fri, 9 Apr 2010 16:53:09 -0700 (PDT) From: Doug Barton To: Rui Paulo In-Reply-To: <4BBE4D04.5010902@FreeBSD.org> Message-ID: References: <4BBE4D04.5010902@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-current@FreeBSD.org Subject: Re: r206358/r206369 prevent me from connecting via wpi0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 23:53:12 -0000 Good news. A post r206419 kernel works as anticipated. Thanks for jumping on this. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 00:06:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E03A1065672 for ; Sat, 10 Apr 2010 00:06:49 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id A1EC18FC0C for ; Sat, 10 Apr 2010 00:06:48 +0000 (UTC) Received: (qmail 17380 invoked by uid 399); 10 Apr 2010 00:06:47 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 10 Apr 2010 00:06:47 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Fri, 9 Apr 2010 17:06:46 -0700 (PDT) From: Doug Barton To: Eir Nym In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: BIND from system and from ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 00:06:49 -0000 On Wed, 7 Apr 2010, Eir Nym wrote: > All is good in BIND in system, except it depends on ports tree with > various options. > I have to do followed algorithm, to enable these options: > 1) make and install base system > 2) install needed dependencies from ports tree There is another step here, enable optional dependencies that are not enabled by default. > 3) rebuild and reinstall world > > This is more complex than: > 1) make and install base system > 2) install same(?) BIND from ports tree with same options So do that. :) Nothing requires you to use the optional mechanism in the base. > Why does base system has any dependencies from ports? > I know about application features, but special cases aren't special > enough to break the rules, isn't it? You haven't actually expressed a problem here. Can you enumerate any actual concerns you have, and what the implications of them are? FWIW, I added the options that exist now in response to user demand. People wanted to be able to use BIND in the base with those options enabled. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 01:59:36 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DA0E106566B; Sat, 10 Apr 2010 01:59:36 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id A4E278FC17; Sat, 10 Apr 2010 01:59:35 +0000 (UTC) Received: by qyk11 with SMTP id 11so3250017qyk.13 for ; Fri, 09 Apr 2010 18:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=najLhVHXRUCasjntxqxIgJxumoAxxuIUpHaqpbuYCBA=; b=OmYgQrjfX11jlq4bOB+INJ9Dto/WLcrZuMCQLoppcrfgTI5Jsl0XS+fjaFYFwYj1GZ BOArn6fVOKWuO2phyyr0TKSM1kVTbaNIDiilTOnzWM5zqyAD5bWjwbviOEr7zoo98C7+ 88en+Ywbo7fw1h6zoWNxRT61LYq6ZM/13Qkl0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=gtTku+qj6MFM1Zp9HuH7/vy0NeIX9xB0jbio9igsPwZeHbUkcMltklojx7HnARn+oT 9oEUVta7Bxuc+j2HLwVk/EOwrllIy/R2FA099+9sr8rVz6bOkpVPAEwBoxm6qVOW6tiQ SEVWm1shxNr+ByuHW8IBedCOa/KKD4X9ixldU= Received: by 10.229.238.70 with SMTP id kr6mr1198254qcb.49.1270863105369; Fri, 09 Apr 2010 18:31:45 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id w30sm2548444qce.10.2010.04.09.18.31.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Apr 2010 18:31:45 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BBFD502.1010507@elischer.org> Date: Fri, 09 Apr 2010 18:31:46 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: FreeBSD Current , ports@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 01:59:36 -0000 sorry for the cross-post.. Last night at the Bay Area FreeBSD Users Group meeting we had a discussion about ports, and what is good about them and what is bad about them. This has been a topic of discussion quite a bit recently and we were looking for a solution that would allow us to keep the good parts of the current ports system but would allow us to give a better user experience for non guru users. The scheme we came up with involves a merging of the ports tree and the PBI system, developed for PC-BSD. Basically, the addition of a makepbi keyword in the .mk files to allow the automatic generation of PBIs for 'simple' ports such as 'cowsay' (the canonical simple app). More complicated apps would need manual work in Makefile or in a separate pbi-recipe file, but once the support was done we could proceed one port at a time. Not all ports make sense in a PBI format. (e.g. libraries etc. may not) One issue that was raised is the increase of storage overhead when using PBI packages as they include a copy of all required libraries and resources, which means that one would very quickly get duplicate copies of things. Our suggestions include the ability of the PBI management software to resolve and (using hard links) eliminate duplicate items. This is not as easy as it sounds but can be achieved using a special variant of 'objcopy' (at least that is our theory). The aim is to make all apps installed on a system much more resilient to dependency problems. In addition there was discussion on how builds need to be doable as non-root uids sometimes, and that users on a system should be able to install packages (PBIs) as thie selves to get local versions of apps for themselves. Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some others and I, felt that these ideas seemed to make some sense and so I put them here for comment. Julian From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 03:11:48 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 449C6106564A; Sat, 10 Apr 2010 03:11:48 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id DBDF68FC1B; Sat, 10 Apr 2010 03:11:47 +0000 (UTC) Received: by qyk11 with SMTP id 11so3285170qyk.13 for ; Fri, 09 Apr 2010 20:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=mdXsdg9IXPnmGm3OT339S1I1CvKGSsKhjEAYvMKZ0FM=; b=d4OenA40ztOMQb+PNCb99WW76kY5R1WMX+qBwHAv8a1v/OzQMygBwDM9otY1bpXO2X JsXwcFW3nz+eKov9L5HXf8LPzyttmiriswKfiUGWTTAhOIXMYlBws3BgygDXQG26hXko oHK2UHvnTovIo9XPW0K2jKIjqtiAY8MXz51Fo= 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=OQIPYU2luMA9eq+G5Q/V2J8hzvMPBd4MpLzW7/JB0V2Z8fiNrJJ4rAVJ3YHImR5SVd 4TJY4/pkVm2wBO5If4CO0SIlRCqLizs3/xhVl9B+RNO0VytuyQibANx++1L/8aMDZRij rK5n+69ux4S5Y7gBZNAz2vrbVmz/aJhQ+JQcs= MIME-Version: 1.0 Received: by 10.229.85.147 with HTTP; Fri, 9 Apr 2010 20:11:47 -0700 (PDT) In-Reply-To: <4BBFD502.1010507@elischer.org> References: <4BBFD502.1010507@elischer.org> Date: Fri, 9 Apr 2010 22:11:47 -0500 Received: by 10.229.81.81 with SMTP id w17mr1441775qck.4.1270869107083; Fri, 09 Apr 2010 20:11:47 -0700 (PDT) Message-ID: From: Adam Vande More To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@freebsd.org, FreeBSD Current Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 03:11:48 -0000 On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer wrote: > > Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some > others and I, felt that these ideas seemed to make some sense > and so I put them here for comment. > > FWIW, when I see these discussions I'm always left wondering what's the bad part? I do think there are problems, but there doesn't seem to be a clear defined set of what is wrong. IMO, there should be a defined set of goals to judge possible implementations against. In manys ways, simply having a "Lastest" package archive for RELEASE that is rebuilt say weekly which would resolve most of the problems I run into and address some the non-power users desires as well. Anyways, I'm sure this will be an entertaining thread. -- Adam Vande More From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 04:55:28 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCAB1106566C; Sat, 10 Apr 2010 04:55:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 803C28FC20; Sat, 10 Apr 2010 04:55:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o3A4tRsR096840; Sat, 10 Apr 2010 00:55:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o3A4tR6Y096833; Sat, 10 Apr 2010 04:55:27 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 10 Apr 2010 04:55:27 GMT Message-Id: <201004100455.o3A4tR6Y096833@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 04:55:29 -0000 TB --- 2010-04-10 03:50:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-10 03:50:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-04-10 03:50:00 - cleaning the object tree TB --- 2010-04-10 03:50:23 - cvsupping the source tree TB --- 2010-04-10 03:50:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-04-10 03:51:58 - building world TB --- 2010-04-10 03:51:58 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-10 03:51:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-10 03:51:58 - TARGET=pc98 TB --- 2010-04-10 03:51:58 - TARGET_ARCH=i386 TB --- 2010-04-10 03:51:58 - TZ=UTC TB --- 2010-04-10 03:51:58 - __MAKE_CONF=/dev/null TB --- 2010-04-10 03:51:58 - cd /src TB --- 2010-04-10 03:51:58 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 10 03:51:58 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 10 04:50:53 UTC 2010 TB --- 2010-04-10 04:50:53 - generating LINT kernel config TB --- 2010-04-10 04:50:53 - cd /src/sys/pc98/conf TB --- 2010-04-10 04:50:53 - /usr/bin/make -B LINT TB --- 2010-04-10 04:50:53 - building LINT kernel TB --- 2010-04-10 04:50:53 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-10 04:50:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-10 04:50:53 - TARGET=pc98 TB --- 2010-04-10 04:50:53 - TARGET_ARCH=i386 TB --- 2010-04-10 04:50:53 - TZ=UTC TB --- 2010-04-10 04:50:53 - __MAKE_CONF=/dev/null TB --- 2010-04-10 04:50:53 - cd /src TB --- 2010-04-10 04:50:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 10 04:50:53 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/e1000/if_em.c:4396: error: expected declaration specifiers or '...' before 'ims_mask' cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c:4396: warning: data definition has no type or storage class /src/sys/dev/e1000/if_em.c:4396: warning: type defaults to 'int' in declaration of 'bus_space_write_4' /src/sys/dev/e1000/if_em.c:4396: warning: function declaration isn't a prototype /src/sys/dev/e1000/if_em.c:4396: error: conflicting types for 'bus_space_write_4' ./machine/bus.h:367: error: previous definition of 'bus_space_write_4' was here /src/sys/dev/e1000/if_em.c:4397: error: expected identifier or '(' before '}' token *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-04-10 04:55:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-04-10 04:55:27 - ERROR: failed to build lint kernel TB --- 2010-04-10 04:55:27 - 2866.64 user 652.77 system 3926.66 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 04:56:52 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51317106566C; Sat, 10 Apr 2010 04:56:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 04A898FC1F; Sat, 10 Apr 2010 04:56:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o3A4uptT003048; Sat, 10 Apr 2010 00:56:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o3A4upEN003047; Sat, 10 Apr 2010 04:56:51 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 10 Apr 2010 04:56:51 GMT Message-Id: <201004100456.o3A4upEN003047@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 04:56:52 -0000 TB --- 2010-04-10 03:50:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-10 03:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-04-10 03:50:00 - cleaning the object tree TB --- 2010-04-10 03:50:25 - cvsupping the source tree TB --- 2010-04-10 03:50:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-04-10 03:51:58 - building world TB --- 2010-04-10 03:51:58 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-10 03:51:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-10 03:51:58 - TARGET=i386 TB --- 2010-04-10 03:51:58 - TARGET_ARCH=i386 TB --- 2010-04-10 03:51:58 - TZ=UTC TB --- 2010-04-10 03:51:58 - __MAKE_CONF=/dev/null TB --- 2010-04-10 03:51:58 - cd /src TB --- 2010-04-10 03:51:58 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 10 03:51:58 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 10 04:51:14 UTC 2010 TB --- 2010-04-10 04:51:14 - generating LINT kernel config TB --- 2010-04-10 04:51:14 - cd /src/sys/i386/conf TB --- 2010-04-10 04:51:14 - /usr/bin/make -B LINT TB --- 2010-04-10 04:51:14 - building LINT kernel TB --- 2010-04-10 04:51:14 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-10 04:51:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-10 04:51:14 - TARGET=i386 TB --- 2010-04-10 04:51:14 - TARGET_ARCH=i386 TB --- 2010-04-10 04:51:14 - TZ=UTC TB --- 2010-04-10 04:51:14 - __MAKE_CONF=/dev/null TB --- 2010-04-10 04:51:14 - cd /src TB --- 2010-04-10 04:51:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 10 04:51:14 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/e1000/if_em.c:4396: error: expected declaration specifiers or '...' before 'ims_mask' cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c:4396: warning: data definition has no type or storage class /src/sys/dev/e1000/if_em.c:4396: warning: type defaults to 'int' in declaration of 'bus_space_write_4' /src/sys/dev/e1000/if_em.c:4396: warning: function declaration isn't a prototype /src/sys/dev/e1000/if_em.c:4396: error: conflicting types for 'bus_space_write_4' ./machine/bus.h:537: error: previous definition of 'bus_space_write_4' was here /src/sys/dev/e1000/if_em.c:4397: error: expected identifier or '(' before '}' token *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-04-10 04:56:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-04-10 04:56:51 - ERROR: failed to build lint kernel TB --- 2010-04-10 04:56:51 - 2953.20 user 637.71 system 4010.59 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 05:21:19 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABE56106564A; Sat, 10 Apr 2010 05:21:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6118C8FC15; Sat, 10 Apr 2010 05:21:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o3A5LIlw021161; Sat, 10 Apr 2010 01:21:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o3A5LIOS021160; Sat, 10 Apr 2010 05:21:18 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 10 Apr 2010 05:21:18 GMT Message-Id: <201004100521.o3A5LIOS021160@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 05:21:19 -0000 TB --- 2010-04-10 03:50:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-10 03:50:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-04-10 03:50:00 - cleaning the object tree TB --- 2010-04-10 03:50:34 - cvsupping the source tree TB --- 2010-04-10 03:50:34 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-04-10 03:51:58 - building world TB --- 2010-04-10 03:51:58 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-10 03:51:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-10 03:51:58 - TARGET=amd64 TB --- 2010-04-10 03:51:58 - TARGET_ARCH=amd64 TB --- 2010-04-10 03:51:58 - TZ=UTC TB --- 2010-04-10 03:51:58 - __MAKE_CONF=/dev/null TB --- 2010-04-10 03:51:58 - cd /src TB --- 2010-04-10 03:51:58 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 10 03:51:59 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Apr 10 05:15:20 UTC 2010 TB --- 2010-04-10 05:15:20 - generating LINT kernel config TB --- 2010-04-10 05:15:20 - cd /src/sys/amd64/conf TB --- 2010-04-10 05:15:20 - /usr/bin/make -B LINT TB --- 2010-04-10 05:15:20 - building LINT kernel TB --- 2010-04-10 05:15:20 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-10 05:15:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-10 05:15:20 - TARGET=amd64 TB --- 2010-04-10 05:15:20 - TARGET_ARCH=amd64 TB --- 2010-04-10 05:15:20 - TZ=UTC TB --- 2010-04-10 05:15:20 - __MAKE_CONF=/dev/null TB --- 2010-04-10 05:15:20 - cd /src TB --- 2010-04-10 05:15:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 10 05:15:20 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/e1000/if_em.c:4396: error: expected declaration specifiers or '...' before 'ims_mask' cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c:4396: warning: data definition has no type or storage class /src/sys/dev/e1000/if_em.c:4396: warning: type defaults to 'int' in declaration of 'bus_space_write_4' /src/sys/dev/e1000/if_em.c:4396: warning: function declaration isn't a prototype /src/sys/dev/e1000/if_em.c:4396: error: conflicting types for 'bus_space_write_4' ./machine/bus.h:497: error: previous definition of 'bus_space_write_4' was here /src/sys/dev/e1000/if_em.c:4397: error: expected identifier or '(' before '}' token *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-04-10 05:21:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-04-10 05:21:18 - ERROR: failed to build lint kernel TB --- 2010-04-10 05:21:18 - 4127.45 user 893.15 system 5477.86 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 06:06:10 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07443106566B; Sat, 10 Apr 2010 06:06:10 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by mx1.freebsd.org (Postfix) with ESMTP id C57E78FC08; Sat, 10 Apr 2010 06:06:09 +0000 (UTC) Received: by pzk35 with SMTP id 35so23618pzk.3 for ; Fri, 09 Apr 2010 23:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9X2CBT24yN+GH76dE4KTZ2f+dmBBzFr1LQzk1hBGgtc=; b=H2Hl08o67ZaRc1It1yc01VqIMAeFir4NU4UBDxAuwF4cQWkBpJTpmNrnzeRd/Ni2Rd ClIsKCXgyHTp4NmJ15XI+s4Fudg4lCC5wXIt9UNbhkVO1RXb6MJfB7ndIUnYECQ2tdJC rLlDDk8pnRBlN9Yn0q+w40xFngCqLjsiam1EM= 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=BTCkARQwKqmaOrac5TyvT1t7m2OPpBxd+hYQpbH37i6c6m75ULjuo+gdEsH2iZaolC e8l3fcqmhnyrtyp7rnldMdeLSf/FeteyL342INMCPmiAWcr+dSXeasBSReBFAZ3gDXLq APXWZrS9ZHMTUcb8Qufy4PD1rpKG9sPJqI/+4= MIME-Version: 1.0 Received: by 10.143.30.2 with HTTP; Fri, 9 Apr 2010 23:06:09 -0700 (PDT) In-Reply-To: <4BBFD502.1010507@elischer.org> References: <4BBFD502.1010507@elischer.org> Date: Sat, 10 Apr 2010 01:06:09 -0500 Received: by 10.142.207.19 with SMTP id e19mr689984wfg.186.1270879569357; Fri, 09 Apr 2010 23:06:09 -0700 (PDT) Message-ID: From: "Sam Fourman Jr." To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ports@freebsd.org, "Dave Fourman\(Gmail\)" , Vanessa Kraus , FreeBSD Current Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 06:06:10 -0000 On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer wrote= : > sorry for the cross-post.. > > Last night at the Bay Area FreeBSD Users Group meeting we had > a discussion about ports, and what is good about them and what > is bad about them. This has been a topic of discussion quite a > bit recently and we were looking for a solution that would > allow us to keep the good parts of the current ports system > but would allow us to give a better user experience for non > guru users. > > The scheme we came up with involves a merging of the > ports tree and the PBI system, developed for PC-BSD. > > Basically, the addition of a makepbi keyword in the .mk > files to allow the automatic generation of PBIs for 'simple' > ports such as 'cowsay' (the canonical simple app). > More complicated apps would need manual work in Makefile or > in a separate pbi-recipe file, but once the support was done > we could proceed one port at a time. =A0Not all ports make sense > in a PBI format. (e.g. libraries etc. may not) I for one support this Idea, and at a BoF FreeBSD Desktop session at BSDCan= 2008 one of my suggestions was to have FreeBSD "bless PBI's" I think this is good For PC-BSD. and in return it is GREAT for FreeBSD, as it will widen the user base and hopefully attract a few more good developers. keep this discussion going, because there isn't mush of a downside so far as I can see. Sam Fourman Jr. > One issue that was raised is the increase of storage > overhead when using PBI packages as they include a copy of > all required libraries and resources, which means that one would > very quickly get duplicate copies of things. > > Our suggestions include the ability of the PBI management software > to resolve and (using hard links) eliminate duplicate items. > This is not as easy as it sounds but can be achieved using a > special variant of 'objcopy' (at least that is our theory). > > The aim is to make all apps installed on a system much more > resilient to dependency problems. > > In addition there was discussion on how builds need to be doable as non-r= oot > uids sometimes, and that users on a system should be > able to install packages (PBIs) as thie selves to get local > versions of apps for themselves. > > Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some > others and I, felt that these ideas seemed to make some sense > and so I put them here for comment. > > > Julian > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 06:20:14 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 015491065674; Sat, 10 Apr 2010 06:20:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C282F8FC16; Sat, 10 Apr 2010 06:20:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o3A6KCct056942; Sat, 10 Apr 2010 02:20:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o3A6KCVZ056937; Sat, 10 Apr 2010 06:20:12 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 10 Apr 2010 06:20:12 GMT Message-Id: <201004100620.o3A6KCVZ056937@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 06:20:14 -0000 TB --- 2010-04-10 04:56:51 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-10 04:56:51 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-04-10 04:56:51 - cleaning the object tree TB --- 2010-04-10 04:57:04 - cvsupping the source tree TB --- 2010-04-10 04:57:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-04-10 05:15:24 - building world TB --- 2010-04-10 05:15:24 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-10 05:15:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-10 05:15:24 - TARGET=powerpc TB --- 2010-04-10 05:15:24 - TARGET_ARCH=powerpc TB --- 2010-04-10 05:15:24 - TZ=UTC TB --- 2010-04-10 05:15:24 - __MAKE_CONF=/dev/null TB --- 2010-04-10 05:15:24 - cd /src TB --- 2010-04-10 05:15:24 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 10 05:15:24 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 10 06:15:46 UTC 2010 TB --- 2010-04-10 06:15:46 - generating LINT kernel config TB --- 2010-04-10 06:15:46 - cd /src/sys/powerpc/conf TB --- 2010-04-10 06:15:46 - /usr/bin/make -B LINT TB --- 2010-04-10 06:15:46 - building LINT kernel TB --- 2010-04-10 06:15:46 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-10 06:15:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-10 06:15:46 - TARGET=powerpc TB --- 2010-04-10 06:15:46 - TARGET_ARCH=powerpc TB --- 2010-04-10 06:15:46 - TZ=UTC TB --- 2010-04-10 06:15:46 - __MAKE_CONF=/dev/null TB --- 2010-04-10 06:15:46 - cd /src TB --- 2010-04-10 06:15:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 10 06:15:46 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/dpt/dpt_scsi.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror eisa_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 /src/sys/dev/e1000/if_em.c:4396: error: expected identifier or '(' before 'struct' /src/sys/dev/e1000/if_em.c:4396: error: expected ')' before '(' token /src/sys/dev/e1000/if_em.c:4396: error: expected ')' before '->' token /src/sys/dev/e1000/if_em.c:4396: error: expected ')' before '->' token /src/sys/dev/e1000/if_em.c:4397: error: expected identifier or '(' before '}' token *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-04-10 06:20:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-04-10 06:20:12 - ERROR: failed to build lint kernel TB --- 2010-04-10 06:20:12 - 2958.63 user 590.91 system 5001.45 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 06:26:09 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 165C3106564A; Sat, 10 Apr 2010 06:26:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BF22D8FC0A; Sat, 10 Apr 2010 06:26:08 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o3A6Q8YY096547; Sat, 10 Apr 2010 02:26:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o3A6Q7vD096546; Sat, 10 Apr 2010 06:26:07 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 10 Apr 2010 06:26:07 GMT Message-Id: <201004100626.o3A6Q7vD096546@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 06:26:09 -0000 TB --- 2010-04-10 05:21:18 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-10 05:21:18 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-04-10 05:21:18 - cleaning the object tree TB --- 2010-04-10 05:21:37 - cvsupping the source tree TB --- 2010-04-10 05:21:37 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-04-10 05:24:23 - building world TB --- 2010-04-10 05:24:23 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-10 05:24:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-10 05:24:23 - TARGET=sparc64 TB --- 2010-04-10 05:24:23 - TARGET_ARCH=sparc64 TB --- 2010-04-10 05:24:23 - TZ=UTC TB --- 2010-04-10 05:24:23 - __MAKE_CONF=/dev/null TB --- 2010-04-10 05:24:23 - cd /src TB --- 2010-04-10 05:24:23 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 10 05:24:23 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 10 06:21:59 UTC 2010 TB --- 2010-04-10 06:21:59 - generating LINT kernel config TB --- 2010-04-10 06:21:59 - cd /src/sys/sparc64/conf TB --- 2010-04-10 06:21:59 - /usr/bin/make -B LINT TB --- 2010-04-10 06:21:59 - building LINT kernel TB --- 2010-04-10 06:21:59 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-10 06:21:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-10 06:21:59 - TARGET=sparc64 TB --- 2010-04-10 06:21:59 - TARGET_ARCH=sparc64 TB --- 2010-04-10 06:21:59 - TZ=UTC TB --- 2010-04-10 06:21:59 - __MAKE_CONF=/dev/null TB --- 2010-04-10 06:21:59 - cd /src TB --- 2010-04-10 06:21:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 10 06:21:59 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/e1000/if_em.c:4396: error: expected declaration specifiers or '...' before 'ims_mask' cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c:4396: warning: data definition has no type or storage class /src/sys/dev/e1000/if_em.c:4396: warning: type defaults to 'int' in declaration of 'bus_space_write_4' /src/sys/dev/e1000/if_em.c:4396: warning: function declaration isn't a prototype /src/sys/dev/e1000/if_em.c:4396: error: conflicting types for 'bus_space_write_4' ./machine/bus.h:295: error: previous definition of 'bus_space_write_4' was here /src/sys/dev/e1000/if_em.c:4397: error: expected identifier or '(' before '}' token *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-04-10 06:26:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-04-10 06:26:07 - ERROR: failed to build lint kernel TB --- 2010-04-10 06:26:07 - 2805.06 user 584.35 system 3889.18 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 06:28:28 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 328D51065670; Sat, 10 Apr 2010 06:28:28 +0000 (UTC) (envelope-from sfourman@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 EF7F28FC19; Sat, 10 Apr 2010 06:28:27 +0000 (UTC) Received: by pvc7 with SMTP id 7so2751345pvc.13 for ; Fri, 09 Apr 2010 23:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fyTzW4g28UM/puK0hsSYARQklBH74aZTGerLHiIe9uI=; b=GCkSU20ptKjk2a6w9qnxTz1hWeQX3fhowoQcOk93tUo9OtfznZlrPk+nnJ6qVzDiLx II7ZYzHJ8YHtXks7++Mss4OWR/G/YCdW1d4OrBsbdO15a+a1oEv9RxBVxlmg9MsIfMIA mpANP1qPPomUCReJKpFT8hjyMfkb6rlHXrvdI= 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=uabeQLzRdoCkBGxVMqKE/sdlZrd85ftoEJ3p99xGiN//AzhMKGKaRz9YiR1yUTUxVU xPEfqvuEUNgUBN/HvUwDSEFxcIYDSrspbjrwhVpYrRdfiN40X7td9++8eMQ0vXOy1wm6 g6tRavRa14lu21EnR42IWHgHNojdP4q60oDk8= MIME-Version: 1.0 Received: by 10.143.30.2 with HTTP; Fri, 9 Apr 2010 23:28:27 -0700 (PDT) In-Reply-To: References: <4BBFD502.1010507@elischer.org> Date: Sat, 10 Apr 2010 01:28:27 -0500 Received: by 10.142.247.28 with SMTP id u28mr691373wfh.69.1270880907296; Fri, 09 Apr 2010 23:28:27 -0700 (PDT) Message-ID: From: "Sam Fourman Jr." To: Adam Vande More Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kris Moore , John Hixson , ports@freebsd.org, Julian Elischer , "Dave Fourman\(Gmail\)" , Matt Olander , Vanessa Kraus , FreeBSD Current Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 06:28:28 -0000 On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande More wr= ote: > On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer wro= te: > >> >> Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some >> others and I, felt that these ideas seemed to make some sense >> and so I put them here for comment. >> >> > FWIW, when I see these discussions I'm always left wondering what's the b= ad > part? =A0I do think there are problems, but there doesn't seem to be a cl= ear > defined set of what is wrong. =A0 IMO, there should be a defined set of g= oals > to judge possible implementations against. Let me start by saying FreeBSD ports is by far the best system I have used to date. but as good as it is, there is room for improvement. Being a FreeBSD user now for many years, one thing I think would be nice is= : being able to have easier access to development ports( Masked ports kinda like Gentoo). right now is a GREAT example, currently there are new Gnome ,KDE and Xorg. these are all MAJOR ports,dependencies run deeper and deeper with every rel= ease. there can never be enough testing...but they all exist in random subversion servers around the web... I would very much like to help test these Major ports, but installing them is a pain. there should be some sort of overlay system in place, so I can just build the development ports after agreeing to a few well placed warnings of course. and Well if I hose my system all to hell.. well then I could just click on a bunch of PBI's and I am back in business.= .. better still, make the development ports a PBI, I am just thinking out loud here,but that may work, toughts? one could say I could use merge scripts like marcusmerge for example, or use Virtualbox... but for large ports like Xorg and gnome or KDE, virtualbox doesn't cut it y= et... thinks like Nvidia Video cards, multiple monitors, USB devices, and whatnot do not work on virtual box.. PBI's for development ports, with all the dependencies, wrapped in one pack= age. solution? well let all the developers develop working ports in progress in one place, give users like me a way to track these changes and install and test them... I think FreeBSD becomes a better place for it. Sam Fourman Jr. Fourman Networks From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 06:36:06 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D6F1106566B; Sat, 10 Apr 2010 06:36:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E70328FC0A; Sat, 10 Apr 2010 06:36:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o3A6a5Mh052554; Sat, 10 Apr 2010 02:36:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o3A6a5vJ052549; Sat, 10 Apr 2010 06:36:05 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 10 Apr 2010 06:36:05 GMT Message-Id: <201004100636.o3A6a5vJ052549@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 06:36:06 -0000 TB --- 2010-04-10 04:41:04 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-10 04:41:04 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-04-10 04:41:04 - cleaning the object tree TB --- 2010-04-10 04:41:22 - cvsupping the source tree TB --- 2010-04-10 04:41:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-04-10 05:15:24 - building world TB --- 2010-04-10 05:15:24 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-10 05:15:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-10 05:15:24 - TARGET=ia64 TB --- 2010-04-10 05:15:24 - TARGET_ARCH=ia64 TB --- 2010-04-10 05:15:24 - TZ=UTC TB --- 2010-04-10 05:15:24 - __MAKE_CONF=/dev/null TB --- 2010-04-10 05:15:24 - cd /src TB --- 2010-04-10 05:15:24 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 10 05:15:24 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 10 06:30:51 UTC 2010 TB --- 2010-04-10 06:30:51 - generating LINT kernel config TB --- 2010-04-10 06:30:51 - cd /src/sys/ia64/conf TB --- 2010-04-10 06:30:51 - /usr/bin/make -B LINT TB --- 2010-04-10 06:30:51 - building LINT kernel TB --- 2010-04-10 06:30:51 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-10 06:30:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-10 06:30:51 - TARGET=ia64 TB --- 2010-04-10 06:30:51 - TARGET_ARCH=ia64 TB --- 2010-04-10 06:30:51 - TZ=UTC TB --- 2010-04-10 06:30:51 - __MAKE_CONF=/dev/null TB --- 2010-04-10 06:30:51 - cd /src TB --- 2010-04-10 06:30:51 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 10 06:30:51 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/e1000/if_em.c:4396: error: expected declaration specifiers or '...' before 'ims_mask' cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c:4396: warning: data definition has no type or storage class /src/sys/dev/e1000/if_em.c:4396: warning: type defaults to 'int' in declaration of 'bus_space_write_4' /src/sys/dev/e1000/if_em.c:4396: warning: function declaration isn't a prototype /src/sys/dev/e1000/if_em.c:4396: error: conflicting types for 'bus_space_write_4' ./machine/bus.h:274: error: previous definition of 'bus_space_write_4' was here /src/sys/dev/e1000/if_em.c:4397: error: expected identifier or '(' before '}' token *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-04-10 06:36:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-04-10 06:36:05 - ERROR: failed to build lint kernel TB --- 2010-04-10 06:36:05 - 3944.74 user 620.29 system 6900.22 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 07:05:01 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E31E3106566C; Sat, 10 Apr 2010 07:05:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 80D9C8FC0C; Sat, 10 Apr 2010 07:05:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o3A74xw2018523; Sat, 10 Apr 2010 03:04:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o3A74x8T018522; Sat, 10 Apr 2010 07:04:59 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 10 Apr 2010 07:04:59 GMT Message-Id: <201004100704.o3A74x8T018522@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 07:05:01 -0000 TB --- 2010-04-10 06:04:15 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-10 06:04:15 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-04-10 06:04:15 - cleaning the object tree TB --- 2010-04-10 06:04:27 - cvsupping the source tree TB --- 2010-04-10 06:04:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-04-10 06:07:13 - building world TB --- 2010-04-10 06:07:13 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-10 06:07:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-10 06:07:13 - TARGET=sun4v TB --- 2010-04-10 06:07:13 - TARGET_ARCH=sparc64 TB --- 2010-04-10 06:07:13 - TZ=UTC TB --- 2010-04-10 06:07:13 - __MAKE_CONF=/dev/null TB --- 2010-04-10 06:07:13 - cd /src TB --- 2010-04-10 06:07:13 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 10 06:07:13 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 10 07:00:54 UTC 2010 TB --- 2010-04-10 07:00:54 - generating LINT kernel config TB --- 2010-04-10 07:00:54 - cd /src/sys/sun4v/conf TB --- 2010-04-10 07:00:54 - /usr/bin/make -B LINT TB --- 2010-04-10 07:00:54 - building LINT kernel TB --- 2010-04-10 07:00:54 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-10 07:00:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-10 07:00:54 - TARGET=sun4v TB --- 2010-04-10 07:00:54 - TARGET_ARCH=sparc64 TB --- 2010-04-10 07:00:54 - TZ=UTC TB --- 2010-04-10 07:00:54 - __MAKE_CONF=/dev/null TB --- 2010-04-10 07:00:54 - cd /src TB --- 2010-04-10 07:00:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 10 07:00:54 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/e1000/if_em.c:4396: error: expected declaration specifiers or '...' before 'ims_mask' cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c:4396: warning: data definition has no type or storage class /src/sys/dev/e1000/if_em.c:4396: warning: type defaults to 'int' in declaration of 'bus_space_write_4' /src/sys/dev/e1000/if_em.c:4396: warning: function declaration isn't a prototype /src/sys/dev/e1000/if_em.c:4396: error: conflicting types for 'bus_space_write_4' ./machine/bus.h:295: error: previous definition of 'bus_space_write_4' was here /src/sys/dev/e1000/if_em.c:4397: error: expected identifier or '(' before '}' token *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-04-10 07:04:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-04-10 07:04:59 - ERROR: failed to build lint kernel TB --- 2010-04-10 07:04:59 - 2824.87 user 547.76 system 3644.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 09:33:37 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2CB1106564A for ; Sat, 10 Apr 2010 09:33:37 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id B5BD18FC12 for ; Sat, 10 Apr 2010 09:33:37 +0000 (UTC) Received: from mobileKamikaze.norad (unknown [88.130.199.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id BE5798A1A73 for ; Sat, 10 Apr 2010 11:33:36 +0200 (CEST) Message-ID: <4BC045EF.2030400@bsdforen.de> Date: Sat, 10 Apr 2010 11:33:35 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Trivial PR, fix shutdown of rc services started with onestart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 09:33:38 -0000 This morning I took a look at my outstanding PRs. There is a PR I consider old and trivial: This one proposes a change that always treats rc script execution of active services as if _enable="YES" was set. This ensures, among other things, a clean shutdown procedure for services started with onestart: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/130414 Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 07:20:32 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A58C106564A; Sat, 10 Apr 2010 07:20:32 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id A33258FC08; Sat, 10 Apr 2010 07:20:31 +0000 (UTC) Received: by qyk11 with SMTP id 11so3385624qyk.13 for ; Sat, 10 Apr 2010 00:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nWdkOwURMkz2gc4lVBBDPEsZbYriWAy9KhEIwiZVtvA=; b=ebD5ogm4xcO1SSuM9eqqhcEIFngdu4mLPVvEmlRlAiRjm+r2FHXugobzEGoAnOIW48 auToWdjB6qGxu8tUKzd4e1zT7AjWRTWEHbHU2m17ILFJMVX3YWpZ7k81g7qWfAHCq/WI WhhyUYOXiJ9BvOGvv0ORQbwVqfsC4ySbNOzZI= 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=HFHxMA7nOEYj1wbU0hzEMx+tTQpdR7N4n9Nd5ohxRQRjbwjdAjxzEFyODRPIozjqYg xQXvmq2Yc5AyO637Zb2maUFaNQJA/cYk+8af0jf729+md6Ged5mUx3Y+I+NwVxiI7cFh xRr+SxGyBqxyOjgG085q3Jn7WB3uKbu/whhRI= MIME-Version: 1.0 Received: by 10.229.28.85 with HTTP; Sat, 10 Apr 2010 00:20:29 -0700 (PDT) In-Reply-To: References: <4BBFD502.1010507@elischer.org> Date: Sat, 10 Apr 2010 00:20:29 -0700 Received: by 10.229.14.157 with SMTP id g29mr1678954qca.57.1270884029394; Sat, 10 Apr 2010 00:20:29 -0700 (PDT) Message-ID: From: Garrett Cooper To: "Sam Fourman Jr." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 10 Apr 2010 11:26:17 +0000 Cc: Adam Vande More , Kris Moore , John Hixson , ports@freebsd.org, Julian Elischer , "Dave Fourman\(Gmail\)" , Matt Olander , Vanessa Kraus , FreeBSD Current Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 07:20:32 -0000 On Fri, Apr 9, 2010 at 11:28 PM, Sam Fourman Jr. wrote= : > On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande More = wrote: >> On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer wr= ote: >> >>> >>> Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some >>> others and I, felt that these ideas seemed to make some sense >>> and so I put them here for comment. >>> >>> >> FWIW, when I see these discussions I'm always left wondering what's the = bad >> part? =A0I do think there are problems, but there doesn't seem to be a c= lear >> defined set of what is wrong. =A0 IMO, there should be a defined set of = goals >> to judge possible implementations against. > > > Let me start by saying FreeBSD ports is by far the best system I have > used to date. > but as good as it is, there is room for improvement. > > Being a FreeBSD user now for many years, one thing I think would be nice = is: > being able to have easier access to development ports( Masked ports > kinda like Gentoo). Masking ports and packages in general introduces all sorts of fun new complexity for end users as well as maintainers. The last time I used Gentoo (which was only a matter of months ago), a lot portage packages were still masked even though they've been stable for months, years, etc. This is very annoying for me as an end-user because bug blah could be fixed in a later release but in order to unmask the pieces for version blah, I had to unmask 10~15 other `unstable packages', which greatly increased the chance of instability on my system (this was particularly the case back several years ago, but Gentoo has become more conservative over the years, and appears to be approaching some level of equilibrium with Fedora, Ubuntu, etc in terms of releases and package versioning). > right now is a GREAT example, currently there are new Gnome ,KDE and Xorg= . > these are all MAJOR ports,dependencies run deeper and deeper with every r= elease. > there can never be enough testing...but they all exist in random > subversion servers around the web... ports isn't going to solve this. Post the Xorg modularization (which needed to occur anyhow because Xorg and Xfree86 before that was were monolithic beasts), I personally don't see that change in the amount of flux on a quarterly cycle, and the number of packages I install today isn't that much greater than back 6 years ago when I started using FreeBSD. So, while there might be some claim here to note, I think it's mostly exaggerated. > I would very much like to help test these Major ports, but installing > them is a pain. > there should be some sort of overlay system in place, so I can just > build the development ports > after agreeing to a few well placed warnings of course. and Well if I > hose my system all to hell.. > well then I could just click on a bunch of PBI's and I am back in busines= s... Ok, apart from the interface (click a PBI, and magically you have packages installed)... how is this really different from binary packages? Have you tried installing binary packages lately via pkg_add? If not, I'd give it a shot instead of installing from ports. > better still, make the development ports a PBI, I am just thinking out > loud here,but that may work, toughts? > > one could say I could use merge scripts like marcusmerge for example, > or use Virtualbox... > but for large ports like Xorg and gnome or KDE, virtualbox doesn't cut it= yet... > thinks like Nvidia Video cards, multiple monitors, USB devices, and > whatnot do not work on virtual box.. > PBI's for development ports, with all the dependencies, wrapped in one pa= ckage. Ok, well here's the thing. Instead of having N shared dependencies and libraries in /usr/local/lib, you'd have N**2 shared dependencies and libraries in each and every package. Now, let's look at size difference. Here's just one sample: $ ls -l irssi-0.8.14_1.tbz ~/Downloads/Irssi0.8.14_1-PV0.pbi -rw-r--r-- 1 gcooper gcooper 6856203 Apr 10 00:05 /usr/home/gcooper/Downloads/Irssi0.8.14_1-PV0.pbi -rw-r--r-- 1 root wheel 517442 Apr 10 00:07 irssi-0.8.14_1.tbz The .tbz file is a file created with pkg_create -b, and the other file is the PBI I pulled off of http://www.pbidir.com/bt/download/210/2079 . Big difference in size (13.25 fold difference). PBIs only comprise a small set of packages in FreeBSD; if my understanding is correct based on a mirror referenced in pbidir.com, the number is currently under 500~750 PBIs -- this is drastically smaller than the number of binary packages produced by ports on a regular basis for FreeBSD. > solution? well let all the developers develop working ports in > progress in one place, give users like me a way to track these changes > and install and test them... I think FreeBSD becomes a better place for i= t. Packages are more of the answer IMO, not PBIs. PBIs are merely a different set of contents and different means of delivering those contents, and while I like the idea of point - click - install, I'm not ready to create unnecessary complexity by having libraries rev'ed according to what the maintainer A believes are correct, even though maintainer B set it differently, and I'm not interested in sacrificing disk space for this reason. If I wanted to use a packaging scheme like this, I should be using Mac OSX as my primary operating system. Thanks, -Garrett PS Don't let this discourage you though in considering the entry-level user case. I'm just apparently more insane than some folks (not as insane as some others though), and I just don't believe in this ideology because things are fine for me as-is. From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 07:39:40 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F230106564A; Sat, 10 Apr 2010 07:39:40 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by mx1.freebsd.org (Postfix) with ESMTP id 02C238FC16; Sat, 10 Apr 2010 07:39:39 +0000 (UTC) Received: by pzk35 with SMTP id 35so44367pzk.3 for ; Sat, 10 Apr 2010 00:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ST001ZqKtZkB1MMJqtUh+m2LZmpoqi7RVZ3PQ2WCL7A=; b=arH8DHnyTPNWvroVtJ8KUPuBT1kESVEIaHI7KH1KTeV8HQ5o8UvPX+lfhyORyNR7Za GEZW5PG9gtJxXWmc2F9R4w1AypVwRIpDA1l6063+1riSpJhPkcabfpeKEH5jqZE5tP04 81odlwsal1h4GFNqCcX1/RXrpspRk8zePtvTU= 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=ia934mHSs2fsG2mJJG6YO90Bsc66BK540+kLtynHpGwE4+YEGQvi5CO4Og3l1f/lng /5t5R3+3wAYS4ugplNwdkNc1JtDa10Pk9BPiKIaz+FsO3JxysjuFgDKPmxm3yqjM1PJ2 uji6nasZ0gFTrwyP9cAB4J68o5mqST3CANSco= MIME-Version: 1.0 Received: by 10.143.30.2 with HTTP; Sat, 10 Apr 2010 00:39:38 -0700 (PDT) In-Reply-To: References: <4BBFD502.1010507@elischer.org> Date: Sat, 10 Apr 2010 02:39:38 -0500 Received: by 10.143.26.20 with SMTP id d20mr697736wfj.31.1270885178708; Sat, 10 Apr 2010 00:39:38 -0700 (PDT) Message-ID: From: "Sam Fourman Jr." To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 10 Apr 2010 11:26:29 +0000 Cc: Adam Vande More , Kris Moore , John Hixson , ports@freebsd.org, Julian Elischer , "Dave Fourman\(Gmail\)" , Matt Olander , Vanessa Kraus , FreeBSD Current Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 07:39:40 -0000 On Sat, Apr 10, 2010 at 2:20 AM, Garrett Cooper wrote: > On Fri, Apr 9, 2010 at 11:28 PM, Sam Fourman Jr. wro= te: >> On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande More = wrote: >>> On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer w= rote: >>> >>>> >>>> Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some >>>> others and I, felt that these ideas seemed to make some sense >>>> and so I put them here for comment. >>>> >>>> >>> FWIW, when I see these discussions I'm always left wondering what's the= bad >>> part? =A0I do think there are problems, but there doesn't seem to be a = clear >>> defined set of what is wrong. =A0 IMO, there should be a defined set of= goals >>> to judge possible implementations against. >> >> >> Let me start by saying FreeBSD ports is by far the best system I have >> used to date. >> but as good as it is, there is room for improvement. >> >> Being a FreeBSD user now for many years, one thing I think would be nice= is: >> being able to have easier access to development ports( Masked ports >> kinda like Gentoo). > > Masking ports and packages in general introduces all sorts of fun new > complexity for end users as well as maintainers. The last time I used > Gentoo (which was only a matter of months ago), a lot portage packages > were still masked even though they've been stable for months, years, > etc. This is very annoying for me as an end-user because bug blah > could be fixed in a later release but in order to unmask the pieces > for version blah, I had to unmask 10~15 other `unstable packages', > which greatly increased the chance of instability on my system (this > was particularly the case back several years ago, but Gentoo has > become more conservative over the years, and appears to be approaching > some level of equilibrium with Fedora, Ubuntu, etc in terms of > releases and package versioning). I wasn't suggesting that the current way Gentoo did Masking was the correct= way, in fact you have valid points that I agree with and I used Gentoo last Week= :) What I like is that, most of the portage development in done in tree, maybe the real solution is, to just have a development and release ports tree? > >> right now is a GREAT example, currently there are new Gnome ,KDE and Xor= g. >> these are all MAJOR ports,dependencies run deeper and deeper with every = release. >> there can never be enough testing...but they all exist in random >> subversion servers around the web... > > ports isn't going to solve this. Post the Xorg modularization (which > needed to occur anyhow because Xorg and Xfree86 before that was were > monolithic beasts), I personally don't see that change in the amount > of =A0flux on a quarterly cycle, and the number of packages I install > today isn't that much greater than back 6 years ago when I started > using FreeBSD. So, while there might be some claim here to note, I > think it's mostly exaggerated. Again, I agree with you, I just want a easier way to test these large ports= . >> I would very much like to help test these Major ports, but installing >> them is a pain. >> there should be some sort of overlay system in place, so I can just >> build the development ports >> after agreeing to a few well placed warnings of course. and Well if I >> hose my system all to hell.. >> well then I could just click on a bunch of PBI's and I am back in busine= ss... > > Ok, apart from the interface (click a PBI, and magically you have > packages installed)... how is this really different from binary > packages? Have you tried installing binary packages lately via > pkg_add? If not, I'd give it a shot instead of installing from ports. pkg_add does work, I have done it several times, upon learning about PBI's a few years back I wondered to myself, why not just use packages,and make some sort of GUI to add a icon to the whole ordeal. but now I get the Idea of dependencies,it pleges evey Open source OS, even ubuntu breaks every now and again. >> better still, make the development ports a PBI, I am just thinking out >> loud here,but that may work, toughts? >> >> one could say I could use merge scripts like marcusmerge for example, >> or use Virtualbox... >> but for large ports like Xorg and gnome or KDE, virtualbox doesn't cut i= t yet... >> thinks like Nvidia Video cards, multiple monitors, USB devices, and >> whatnot do not work on virtual box.. >> PBI's for development ports, with all the dependencies, wrapped in one p= ackage. > > Ok, well here's the thing. Instead of having N shared dependencies and > libraries in /usr/local/lib, you'd have N**2 shared dependencies and > libraries in each and every package. Now, let's look at size > difference. Here's just one sample: > > $ ls -l irssi-0.8.14_1.tbz ~/Downloads/Irssi0.8.14_1-PV0.pbi > -rw-r--r-- =A01 gcooper =A0gcooper =A06856203 Apr 10 00:05 > /usr/home/gcooper/Downloads/Irssi0.8.14_1-PV0.pbi > -rw-r--r-- =A01 root =A0 =A0 wheel =A0 =A0 517442 Apr 10 00:07 irssi-0.8.= 14_1.tbz > > The .tbz file is a file created with pkg_create -b, and the other file > is the PBI I pulled off of http://www.pbidir.com/bt/download/210/2079 > . Big difference in size (13.25 fold difference). > > PBIs only comprise a small set of packages in FreeBSD; if my > understanding is correct based on a mirror referenced in pbidir.com, > the number is currently under 500~750 PBIs -- this is drastically > smaller than the number of binary packages produced by ports on a > regular basis for FreeBSD. > >> solution? well let all the developers develop working ports in >> progress in one place, give users like me a way to track these changes >> and install and test them... I think FreeBSD becomes a better place for = it. > > Packages are more of the answer IMO, not PBIs. PBIs are merely a > different set of contents and different means of delivering those > contents, and while I like the idea of point - click - install, I'm > not ready to create unnecessary complexity by having libraries rev'ed > according to what the maintainer A believes are correct, even though > maintainer B set it differently, and I'm not interested in sacrificing > disk space for this reason. If I wanted to use a packaging scheme like > this, I should be using Mac OSX as my primary operating system. > > Thanks, > -Garrett > > PS Don't let this discourage you though in considering the entry-level > user case. I'm just apparently more insane than some folks (not as > insane as some others though), and I just don't believe in this > ideology because things are fine for me as-is. > From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 08:45:50 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6D7A106564A; Sat, 10 Apr 2010 08:45:50 +0000 (UTC) (envelope-from julianelischer@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 755C28FC19; Sat, 10 Apr 2010 08:45:50 +0000 (UTC) Received: by vws17 with SMTP id 17so2210971vws.13 for ; Sat, 10 Apr 2010 01:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=vm7RTFZwCrSYxJRV0w9FU/v+HMq6m/cUskRy9JfLDL0=; b=GFVUHW1DpsAn5yo8iBXronkeiSUlcz0ja+c+pE7yonKc6w6yjCa6oAfcSBZDFY6RUM ZqP4yjKTt+hIeX/wzO6JRP9J7z1Hjai2l6XQZrubjRqkCgDk06AAEBpv6EbhhyIOp4Kq DN05LA230D4tgm37yTUI+Llo5sy4QHkjcJ2zk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=nzSw2fif0oeDBD7y85ivC0JHD3WXeKqt47agefkCfHyU3tib/G4PPAF6FGnsSpheOg 5DN7/oAORpqAdxQ9dUjuKPUxhPOS9KxBPs0rctq7Qcqva+jLsHKeHhQTewSYy3MpPu2t nAYpnbzm9XKJ11DscmVVtATT/c2nmnhr/5T7s= Received: by 10.220.61.12 with SMTP id r12mr650261vch.139.1270889149149; Sat, 10 Apr 2010 01:45:49 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id 29sm45147690vws.5.2010.04.10.01.45.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 10 Apr 2010 01:45:48 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BC03ABA.6090309@elischer.org> Date: Sat, 10 Apr 2010 01:45:46 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Garrett Cooper References: <4BBFD502.1010507@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 10 Apr 2010 11:26:50 +0000 Cc: Adam Vande More , Kris Moore , John Hixson , ports@freebsd.org, "Sam Fourman Jr." , "Dave Fourman\(Gmail\)" , Matt Olander , Vanessa Kraus , FreeBSD Current Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 08:45:51 -0000 On 4/10/10 12:20 AM, Garrett Cooper wrote: > On Fri, Apr 9, 2010 at 11:28 PM, Sam Fourman Jr. wrote: >> On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande More wrote: >>> On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer wrote: >>> >>>> >>>> Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some >>>> others and I, felt that these ideas seemed to make some sense >>>> and so I put them here for comment. >>>> >>>> >>> FWIW, when I see these discussions I'm always left wondering what's the bad >>> part? I do think there are problems, but there doesn't seem to be a clear >>> defined set of what is wrong. IMO, there should be a defined set of goals >>> to judge possible implementations against. >> >> >> Let me start by saying FreeBSD ports is by far the best system I have >> used to date. >> but as good as it is, there is room for improvement. >> >> Being a FreeBSD user now for many years, one thing I think would be nice is: >> being able to have easier access to development ports( Masked ports >> kinda like Gentoo). > > Masking ports and packages in general introduces all sorts of fun new > complexity for end users as well as maintainers. The last time I used > Gentoo (which was only a matter of months ago), a lot portage packages > were still masked even though they've been stable for months, years, > etc. This is very annoying for me as an end-user because bug blah > could be fixed in a later release but in order to unmask the pieces > for version blah, I had to unmask 10~15 other `unstable packages', > which greatly increased the chance of instability on my system (this > was particularly the case back several years ago, but Gentoo has > become more conservative over the years, and appears to be approaching > some level of equilibrium with Fedora, Ubuntu, etc in terms of > releases and package versioning). > >> right now is a GREAT example, currently there are new Gnome ,KDE and Xorg. >> these are all MAJOR ports,dependencies run deeper and deeper with every release. >> there can never be enough testing...but they all exist in random >> subversion servers around the web... > > ports isn't going to solve this. Post the Xorg modularization (which > needed to occur anyhow because Xorg and Xfree86 before that was were > monolithic beasts), I personally don't see that change in the amount > of flux on a quarterly cycle, and the number of packages I install > today isn't that much greater than back 6 years ago when I started > using FreeBSD. So, while there might be some claim here to note, I > think it's mostly exaggerated. > >> I would very much like to help test these Major ports, but installing >> them is a pain. >> there should be some sort of overlay system in place, so I can just >> build the development ports >> after agreeing to a few well placed warnings of course. and Well if I >> hose my system all to hell.. >> well then I could just click on a bunch of PBI's and I am back in business... > > Ok, apart from the interface (click a PBI, and magically you have > packages installed)... how is this really different from binary > packages? Have you tried installing binary packages lately via > pkg_add? If not, I'd give it a shot instead of installing from ports. yes but there are still dependency problems if you want to install a single package and you installed all the previous ones a year ago. With PBIs each package is self standing, so you can install one and not worry if it requires a different version of some library to what you installed last year. > >> better still, make the development ports a PBI, I am just thinking out >> loud here,but that may work, toughts? >> >> one could say I could use merge scripts like marcusmerge for example, >> or use Virtualbox... >> but for large ports like Xorg and gnome or KDE, virtualbox doesn't cut it yet... >> thinks like Nvidia Video cards, multiple monitors, USB devices, and >> whatnot do not work on virtual box.. >> PBI's for development ports, with all the dependencies, wrapped in one package. > > Ok, well here's the thing. Instead of having N shared dependencies and > libraries in /usr/local/lib, you'd have N**2 shared dependencies and > libraries in each and every package. Now, let's look at > $ ls -l irssi-0.8.14_1.tbz ~/Downloads/Irssi0.8.14_1-PV0.pbi > -rw-r--r-- 1 gcooper gcooper 6856203 Apr 10 00:05 > /usr/home/gcooper/Downloads/Irssi0.8.14_1-PV0.pbi > -rw-r--r-- 1 root wheel 517442 Apr 10 00:07 irssi-0.8.14_1.tbz > > The .tbz file is a file created with pkg_create -b, and the other file > is the PBI I pulled off of http://www.pbidir.com/bt/download/210/2079 > . Big difference in size (13.25 fold difference). Yes but that is a worst case thing. We are talking about making a system where the PBIs contain all the libraries needed but that only some of them are installed, when there is not already the same one (i.e. identical) installed by a previous PBI. so if you installed, say, 20 PBI from the same 'set' you woudl only be installing one copy of the libraries that > > PBIs only comprise a small set of packages in FreeBSD; if my > understanding is correct based on a mirror referenced in pbidir.com, > the number is currently under 500~750 PBIs -- this is drastically > smaller than the number of binary packages produced by ports on a > regular basis for FreeBSD. > >> solution? well let all the developers develop working ports in >> progress in one place, give users like me a way to track these changes >> and install and test them... I think FreeBSD becomes a better place for it. > > Packages are more of the answer IMO, not PBIs. PBIs are merely a > different set of contents and different means of delivering those > contents, and while I like the idea of point - click - install, I'm > not ready to create unnecessary complexity by having libraries rev'ed > according to what the maintainer A believes are correct, even though > maintainer B set it differently, and I'm not interested in sacrificing > disk space for this reason. If I wanted to use a packaging scheme like > this, I should be using Mac OSX as my primary operating system. well no-one is going to make you use PBIs > > Thanks, > -Garrett > > PS Don't let this discourage you though in considering the entry-level > user case. I'm just apparently more insane than some folks (not as > insane as some others though), and I just don't believe in this > ideology because things are fine for me as-is. From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 10:35:06 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3BE31065702; Sat, 10 Apr 2010 10:35:06 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 7AAAC8FC3D; Sat, 10 Apr 2010 10:35:06 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so1384128qwi.7 for ; Sat, 10 Apr 2010 03:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yWRDNotqJPbEQ8XOlAZ6uR+oMCx4pk1/zlZkr0L0Afc=; b=aztY4U/LXNFydr0EofYcD6C2bN1r0VvdLP/M9YWC0HHi+w2F0RVATqTz3BknNkWGKc OSlLoTo3hXi6qcENf7ciFjPOcEmoh+FRirzvA9g43CL/PncLKrQkrQQYe7wgq+GRiKH0 k0JRp797o0r/Jwdy5v6snwNFBPtkFfO54V4Os= 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=ap/jMdPq9EoiSY+mf4K0yKsLx97ZdIb43M6Umf5kWJdEu4gBPTJ/qQ2PIOuEIyJIIt D6suMgHNyOzn37sOnyqWjqgwsw/+uGoYT58aU1pxiqm/UbPgMTEiVD3Qrj+sgJXSk2yr 33xULWKoMdi4PN2GeO/OPRHYeMsw51s+kik/4= MIME-Version: 1.0 Received: by 10.229.28.85 with HTTP; Sat, 10 Apr 2010 03:35:04 -0700 (PDT) In-Reply-To: <4BC03ABA.6090309@elischer.org> References: <4BBFD502.1010507@elischer.org> <4BC03ABA.6090309@elischer.org> Date: Sat, 10 Apr 2010 03:35:04 -0700 Received: by 10.229.184.130 with SMTP id ck2mr1774113qcb.95.1270895704841; Sat, 10 Apr 2010 03:35:04 -0700 (PDT) Message-ID: From: Garrett Cooper To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 10 Apr 2010 11:27:06 +0000 Cc: Adam Vande More , Kris Moore , John Hixson , ports@freebsd.org, "Sam Fourman Jr." , "Dave Fourman\(Gmail\)" , Matt Olander , Vanessa Kraus , FreeBSD Current Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 10:35:07 -0000 On Sat, Apr 10, 2010 at 1:45 AM, Julian Elischer wrot= e: > On 4/10/10 12:20 AM, Garrett Cooper wrote: >> >> On Fri, Apr 9, 2010 at 11:28 PM, Sam Fourman Jr. >> =A0wrote: >>> >>> On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande More >>> =A0wrote: >>>> >>>> On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer >>>> =A0wrote: >>>> >>>>> >>>>> Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some >>>>> others and I, felt that these ideas seemed to make some sense >>>>> and so I put them here for comment. >>>>> >>>>> >>>> FWIW, when I see these discussions I'm always left wondering what's th= e >>>> bad >>>> part? =A0I do think there are problems, but there doesn't seem to be a >>>> clear >>>> defined set of what is wrong. =A0 IMO, there should be a defined set o= f >>>> goals >>>> to judge possible implementations against. >>> >>> >>> Let me start by saying FreeBSD ports is by far the best system I have >>> used to date. >>> but as good as it is, there is room for improvement. >>> >>> Being a FreeBSD user now for many years, one thing I think would be nic= e >>> is: >>> being able to have easier access to development ports( Masked ports >>> kinda like Gentoo). >> >> Masking ports and packages in general introduces all sorts of fun new >> complexity for end users as well as maintainers. The last time I used >> Gentoo (which was only a matter of months ago), a lot portage packages >> were still masked even though they've been stable for months, years, >> etc. This is very annoying for me as an end-user because bug blah >> could be fixed in a later release but in order to unmask the pieces >> for version blah, I had to unmask 10~15 other `unstable packages', >> which greatly increased the chance of instability on my system (this >> was particularly the case back several years ago, but Gentoo has >> become more conservative over the years, and appears to be approaching >> some level of equilibrium with Fedora, Ubuntu, etc in terms of >> releases and package versioning). >> >>> right now is a GREAT example, currently there are new Gnome ,KDE and >>> Xorg. >>> these are all MAJOR ports,dependencies run deeper and deeper with every >>> release. >>> there can never be enough testing...but they all exist in random >>> subversion servers around the web... >> >> ports isn't going to solve this. Post the Xorg modularization (which >> needed to occur anyhow because Xorg and Xfree86 before that was were >> monolithic beasts), I personally don't see that change in the amount >> of =A0flux on a quarterly cycle, and the number of packages I install >> today isn't that much greater than back 6 years ago when I started >> using FreeBSD. So, while there might be some claim here to note, I >> think it's mostly exaggerated. >> >>> I would very much like to help test these Major ports, but installing >>> them is a pain. >>> there should be some sort of overlay system in place, so I can just >>> build the development ports >>> after agreeing to a few well placed warnings of course. and Well if I >>> hose my system all to hell.. >>> well then I could just click on a bunch of PBI's and I am back in >>> business... >> >> Ok, apart from the interface (click a PBI, and magically you have >> packages installed)... how is this really different from binary >> packages? Have you tried installing binary packages lately via >> pkg_add? If not, I'd give it a shot instead of installing from ports. > > > yes but there are still dependency problems if you want to install a sing= le > package and you installed all the previous ones a year ago. > With PBIs each package is self standing, so you can install one > and not worry if it requires a different version of some library > to what you installed last year. If I'm understanding you correctly you're saying it's an issue when I do: pkg_add A B C # 1 year passes pkg_add D # D depends on A, B, C, of different revisions. pkg_add barfs because it can't find the applications, etc. This is something that's been hashed over a number of times (a few of which I've participated in in #bsdports). There needs to be a simple update command which will handle the action of upgrading packages, because there isn't a proper command that will do so today. Unless PBIs are self-contained entities which have their own sets of dependent utilities and libraries, etc (which you weren't suggesting in the sentence above), or install into a common location with versioned directories (which is a pain in the ass and involves a lot of hardcoded pains dealing with libtool files, libraries, etc -- been there, done that with Gentoo Linux -- there are hack scripts written to work around several possible hardcoded version issue, and there are a handful), AFAIK there's nothing positive and new that PBIs can bring to the table in this regard that can't be implemented in pkg_install as-is, other than the point-click-install user-friendly interface. >>> better still, make the development ports a PBI, I am just thinking out >>> loud here,but that may work, toughts? >>> >>> one could say I could use merge scripts like marcusmerge for example, >>> or use Virtualbox... >>> but for large ports like Xorg and gnome or KDE, virtualbox doesn't cut = it >>> yet... >>> thinks like Nvidia Video cards, multiple monitors, USB devices, and >>> whatnot do not work on virtual box.. >>> PBI's for development ports, with all the dependencies, wrapped in one >>> package. >> >> Ok, well here's the thing. Instead of having N shared dependencies and >> libraries in /usr/local/lib, you'd have N**2 shared dependencies and >> libraries in each and every package. Now, let's look at > > > >> $ ls -l irssi-0.8.14_1.tbz ~/Downloads/Irssi0.8.14_1-PV0.pbi >> -rw-r--r-- =A01 gcooper =A0gcooper =A06856203 Apr 10 00:05 >> /usr/home/gcooper/Downloads/Irssi0.8.14_1-PV0.pbi >> -rw-r--r-- =A01 root =A0 =A0 wheel =A0 =A0 517442 Apr 10 00:07 irssi-0.8= .14_1.tbz >> >> The .tbz file is a file created with pkg_create -b, and the other file >> is the PBI I pulled off of http://www.pbidir.com/bt/download/210/2079 >> . Big difference in size (13.25 fold difference). > > Yes but that is a worst case thing. =A0We are talking about making > a system where the PBIs contain all the libraries needed but that > only some of them are installed, when there is not already the > same one (i.e. identical) installed by a previous PBI. > so if you installed, say, 20 PBI from the same 'set' you woudl only > be installing one copy of the libraries that See above comment. >> PBIs only comprise a small set of packages in FreeBSD; if my >> understanding is correct based on a mirror referenced in pbidir.com, >> the number is currently under 500~750 PBIs -- this is drastically >> smaller than the number of binary packages produced by ports on a >> regular basis for FreeBSD. >> >>> solution? well let all the developers develop working ports in >>> progress in one place, give users like me a way to track these changes >>> and install and test them... I think FreeBSD becomes a better place for >>> it. >> >> Packages are more of the answer IMO, not PBIs. PBIs are merely a >> different set of contents and different means of delivering those >> contents, and while I like the idea of point - click - install, I'm >> not ready to create unnecessary complexity by having libraries rev'ed >> according to what the maintainer A believes are correct, even though >> maintainer B set it differently, and I'm not interested in sacrificing >> disk space for this reason. If I wanted to use a packaging scheme like >> this, I should be using Mac OSX as my primary operating system. > > well no-one is going to make you use PBIs Yes, but if I now have to waste more bandwidth and disk space installing packages, why shouldn't I go to another operating system? Switching over to PBIs will reel in more desktop and entry-level sysadmins, etc, but I fear that it will isolate folks in the embedded market as well as several more seasoned users because of the implications involved with the extra bandwidth requirement and footprint. >> Thanks, >> -Garrett >> >> PS Don't let this discourage you though in considering the entry-level >> user case. I'm just apparently more insane than some folks (not as >> insane as some others though), and I just don't believe in this >> ideology because things are fine for me as-is. From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 14:19:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 316581065673 for ; Sat, 10 Apr 2010 14:19:02 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 00F8D8FC12 for ; Sat, 10 Apr 2010 14:19:01 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 6154BEB1B3 for ; Sat, 10 Apr 2010 10:19:01 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 10 Apr 2010 10:19:01 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=q5gVznjvarQWE756+hx3TiB5fRs=; b=XAY9wjo14oiIf0gbzbuwWbLYHU682Eb2YPQsu3MbVcH626/W+I6pT0S5on6AekTvDFVbwHxUNYIGUphOwt5EZiL0OJpk22pcYDdIfhBILY+UZPXxzWlE24IW8/IgkD1eu2rjc/WRf71/v/lRvnbCWuCZ6UfmxhKs6CvZzeL1qiE= X-Sasl-enc: HmsKZSKl+oA/+9itxDrsdhu0nHLjLBY3i3XWXeZ7IcZ2 1270909141 Received: from anglepoise.lon.incunabulum.net (cpc2-dals7-0-0-cust253.hari.cable.virginmedia.com [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 03BB636E7A for ; Sat, 10 Apr 2010 10:19:00 -0400 (EDT) Message-ID: <4BC088D3.3010908@incunabulum.net> Date: Sat, 10 Apr 2010 15:18:59 +0100 From: Bruce Simpson User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100406 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4BBFD502.1010507@elischer.org> In-Reply-To: <4BBFD502.1010507@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 14:19:02 -0000 On 04/10/10 02:31, Julian Elischer wrote: > > Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some > others and I, felt that these ideas seemed to make some sense > and so I put them here for comment. Please do. Someone has to do something about deployment. For what it's worth, I've tripped over the garden rake on the ground, that is 'unsatisfied dependency' one too many times in commercial work. If PBIs can address this, even for FreeBSD's embedded and server use cases, they will likely be well recieved. From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 13:43:29 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4301F106564A; Sat, 10 Apr 2010 13:43:29 +0000 (UTC) (envelope-from kris@pcbsd.org) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) by mx1.freebsd.org (Postfix) with ESMTP id 201308FC08; Sat, 10 Apr 2010 13:43:28 +0000 (UTC) Received: from mail.ixsystems.com (localhost [127.0.0.1]) by mail.iXsystems.com (Postfix) with ESMTP id D2A5AA6642E; Sat, 10 Apr 2010 06:18:32 -0700 (PDT) Received: from mail.iXsystems.com ([127.0.0.1]) by mail.ixsystems.com (mail.ixsystems.com [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 46242-02; Sat, 10 Apr 2010 06:18:31 -0700 (PDT) Received: from mail.ixsystems.com (localhost [127.0.0.1]) by mail.iXsystems.com (Postfix) with ESMTP id D91ABA66400; Sat, 10 Apr 2010 06:18:30 -0700 (PDT) MIME-Version: 1.0 X-Priority: Normal X-Mailer: AtMail 1.03 Message-ID: <49684.1270905510@pcbsd.org> To: "Garrett Cooper" , "Julian Elischer" X-Origin: 75.131.46.136 X-Atmail-Account: kris@pcbsd.org Date: Sat, 10 Apr 2010 06:18:30 -0700 From: kris@pcbsd.org X-Mailman-Approved-At: Sat, 10 Apr 2010 14:34:54 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Adam Vande More , Kris Moore , John Hixson , ports@freebsd.org, "Sam Fourman Jr." , "Dave Fourman\(Gmail\)" , Matt Olander , Vanessa Kraus , FreeBSD Current Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kris@pcbsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 13:43:29 -0000 =20 BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px On Sat 10/04/10 3:35 AM , Garrett Cooper wrote: [...] > > yes but there are still dependency problems if you want to install a single > package and you installed all the previous ones a year ago. > With PBIs each package is self standing, so you can install one > and not worry if it requires a different version of some library > to what you installed last year. If I'm understanding you correctly you're saying it's an issue when I do: pkg_add A B C # 1 year passes pkg_add D # D depends on A, B, C, of different revisions. pkg_add barfs because it can't find the applications, etc. This is something that's been hashed over a number of times (a few of which I've participated in in #bsdports). There needs to be a simple update command which will handle the action of upgrading packages, because there isn't a proper command that will do so today. Unless PBIs are self-contained entities which have their own sets of dependent utilities and libraries, etc (which you weren't suggesting in the sentence above), or install into a common location with versioned directories (which is a pain in the ass and involves a lot of hardcoded pains dealing with libtool files, libraries, etc -- been there, done that with Gentoo Linux -- there are hack scripts written to work around several possible hardcoded version issue, and there are a handful), AFAIK there's nothing positive and new that PBIs can bring to the table in this regard that can't be implemented in pkg_install as-is, other than the point-click-install user-friendly interface. Incorrect. The difference is in complexity at install-time. Even if you improve the package manager to better resolve and upgrade all related dependencies as a result of doing a firefox upgrade, the fact still remains that just to update one package, you may have to also update a TON of various packages / libraries, any of which may be critical to other applications on your system. If just a single one of those things fails, you can end up breaking a lot of applications on your system or even your entire desktop. PBI system simplifies this process. Updating firefox, since its self-contained, does NOT run the risk of borking anything else on the system. You don't need to work about libpng, libjpeg, or some other seemingly trivial library (to the end user) causing a huge breakage for xorg, or KDE/Gnome, etc. This in my opinion is the fatal flaw of pretty much every open-source system out there right now. Something both windows & mac have recognized and dealt with. We instead try to write more and more complex package resolvers, while failing to address the main issue, that with such a complex chain of dependencies for something as simple as upgrading firefox, it increases the chances exponentially that something will break and ruin your day / weekend. >> PBIs only comprise a small set of packages in FreeBSD; if my >> understanding is correct based on a mirror referenced in pbidir.com, >> the number is currently under 500~750 PBIs -- this is drastically >> smaller than the number of binary packages produced by ports on a >> regular basis for FreeBSD. >> >>> solution? well let all the developers develop working ports in >>> progress in one place, give users like me a way to track these changes >>> and install and test them... I think FreeBSD becomes a better place for >>> it. >> >> Packages are more of the answer IMO, not PBIs. PBIs are merely a >> different set of contents and different means of delivering those >> contents, and while I like the idea of point - click - install, I'm >> not ready to create unnecessary complexity by having libraries rev'ed >> according to what the maintainer A believes are correct, even though >> maintainer B set it differently, and I'm not interested in sacrificing >> disk space for this reason. If I wanted to use a packaging scheme like >> this, I should be using Mac OSX as my primary operating system. > > well no-one is going to make you use PBIs Yes, but if I now have to waste more bandwidth and disk space installing packages, why shouldn't I go to another operating system? Switching over to PBIs will reel in more desktop and entry-level sysadmins, etc, but I fear that it will isolate folks in the embedded market as well as several more seasoned users because of the implications involved with the extra bandwidth requirement and footprint. This gave me a bit of a chuckle. PBI would not be intended as a replacement for ports, rather a utilizing of ports in such a way that we can start building self-contained, stand-alone binaries for end-users and those of us who value their time more than a few MB of disk space.=20 Considering at every BSD conference it seems that the majority of developers are running Mac laptops, it would seem that even some developers agree with the principle, they just aren't doing it on FreeBSD. :) However for my more hard-core friends, nothing stopping you from running your own ports down the road, more power to ya! For doing something like embedded work or=20 a server this makes total sense and I think it is a huge positive for FreeBSD, no reason to trash that or break it in any way. For the other 99.9% of society who want something "that just works" for day-to-day computing,=20 something like PBI is very attractive. It would be great to have an OS that offers best of both worlds. -- Kris Moore ------------------------- Message sent via Atmail Open - http://atmail.org/ From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 14:46:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC96B1065672 for ; Sat, 10 Apr 2010 14:46:28 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id DF6528FC0A for ; Sat, 10 Apr 2010 14:46:27 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id o3AEkQ0O058513; Sat, 10 Apr 2010 10:46:26 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201004101446.o3AEkQ0O058513@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 10 Apr 2010 10:46:21 -0400 To: Jack Vogel From: Mike Tancsa In-Reply-To: References: <201004081831.o38IVR3s043434@lava.sentex.ca> <20100408230750.GR5734@michelle.cdnetworks.com> <201004091317.o39DHFEl049965@lava.sentex.ca> <20100409164115.GB1085@michelle.cdnetworks.com> <201004091900.o39J0b0k051687@lava.sentex.ca> <20100409201307.GF1085@michelle.cdnetworks.com> <201004092105.o39L5SSh052323@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pyunyh@gmail.com, freebsd-current@freebsd.org Subject: Re: LOR on em in HEAD ( was Re: em driver regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 14:46:28 -0000 At 05:11 PM 4/9/2010, Jack Vogel wrote: >Don't know, but I would just ignore it, I think its a false warning anyway. OK. I updated to HEAD as of this AM, but now I get a panic at bootup odule pci/rl failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz (2666.65-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106e5 Family = 6 Model = 1e Stepping = 5 Features=0xbfebfbff Features2=0x98e3fd AMD Features=0x28100000 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 2577711104 (2458 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 5.0 on pci0 pci1: on pcib1 vgapci0: port 0x2000-0x20ff mem 0xb0000000-0xbfffffff,0xc1a00000-0xc1a0ffff irq 16 at device 0.0 on pci1 pci1: at device 0.1 (no driver attached) pci0: at device 8.0 (no driver attached) pci0: at device 8.1 (no driver attached) pci0: at device 8.2 (no driver attached) pci0: at device 8.3 (no driver attached) pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) em0: port 0x3040-0x305f mem 0xc1b00000-0xc1b1ffff,0xc1b25000-0xc1b25fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:c8:4b:99 ehci0: mem 0xc1b22000-0xc1b223ff irq 21 at device 26.0 on pci0 ehci0: [ITHREAD] usbus0: EHCI version 1.0 usbus0: on ehci0 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 16 at device 28.4 on pci0 pci3: on pcib3 em1: port 0x1000-0x101f mem 0xc1900000-0xc191ffff,0xc1920000-0xc1923fff irq 16 at device 0.0 on pci3 em1: Using MSIX interrupts with 5 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:15:17:c8:4b:98 pcib4: irq 18 at device 28.6 on pci0 pci4: on pcib4 pcib5: irq 19 at device 28.7 on pci0 pci5: on pcib5 ehci1: mem 0xc1b21000-0xc1b213ff irq 23 at device 29.0 on pci0 ehci1: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci1 pcib6: at device 30.0 on pci0 pci6: on pcib6 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x3068-0x306f,0x3074-0x3077,0x3060-0x3067,0x3070-0x3073,0x3020-0x303f mem 0xc1b20000-0xc1b207ff irq 18 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.30 with 6 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 acpi_button0: enable wake failed atrtc0: port 0x70-0x71,0x74-0x77 irq 8 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (115200,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] pmtimer0 on isa0 orm0: at iomem 0xd3000-0xd3fff,0xd4000-0xd4fff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] ppc0: parallel port not found. est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich3 bus 0 scbus3 target 0 lun 0 ada1: ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) lapic4: Forcing LINT1 to edge trigger SMP: AP CPU #2 Launched! lapic2: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! lapic6: Forcing LINT1 to edge trigger SMP: AP CPU #3 Launched! WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered ugen0.2: at usbus0 ugen1.2: at usbus1 uhub2: on usbus0 uhub3: on usbus1 Root mount waiting for: usbus1 usbus0 uhub2: 6 ports with 6 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen1.3: at usbus1 ukbd0: on usbus1 kbd0 at ukbd0 ums0: on usbus1 ums0: 3 buttons and [Z] coordinates ID=0 Root mount waiting for: usbus1 ugen1.4: at usbus1 ukbd1: on usbus1 kbd2 at ukbd1 ums1: on usbus1 ums1: 5 buttons and [XYZ] coordinates ID=1 Trying to mount root from nfs: NFS ROOT: 10.255.255.1:/usr/home/pxe9/ panic: mutex em0:rx(0) not owned at /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4093 cpuid = 3 KDB: enter: panic [ thread pid 0 tid 100032 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt Tracing pid 0 tid 100032 td 0xc5f5bb40 kdb_enter(c0cb0e9d,c0cb0e9d,c0caf56e,c5b2ac28,3,...) at kdb_enter+0x3a panic(c0caf56e,c6002024,c11a0357,ffd,c5b2ac7c,...) at panic+0x136 _mtx_assert(c6002010,4,c11a0357,ffd,64,...) at _mtx_assert+0x87 em_rxeof(246,c5ff7d98,c5b2aca8,c088e194,c5ff7d98,...) at em_rxeof+0x3b em_handle_que(c6006000,1,c0cb5c9c,4f,c5ff7d98,...) at em_handle_que+0x38 taskqueue_run(c5ff7d80,c5ff7d98,c0ca6410,0,c0caf5f6,...) at taskqueue_run+0x103 taskqueue_thread_loop(c600a520,c5b2ad38,c0cac192,343,c0e0ce20,...) at taskqueue_thread_loop+0x68 fork_exit(c08dcde0,c600a520,c5b2ad38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc5b2ad70, ebp = 0 --- db> >Jack > > >On Fri, Apr 9, 2010 at 2:05 PM, Mike Tancsa ><mike@sentex.net> wrote: >At 04:13 PM 4/9/2010, Pyun YongHyeon wrote: >On Fri, Apr 09, 2010 at 12:09:24PM -0700, Jack Vogel wrote: > > Someone else also pointed this out. I'm dubious about its claim. > >I can't reproduce the LOR with latest em(4)(r206429). > > > >I still get it for some reason > > 1st 0xc5dc7610 em1:rx(1) (em1:rx(1)) @ > /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4087 > 2nd 0xc0f7df0c udp (udp) @ /usr/HEAD/src/sys/netinet/udp_usrreq.c:454 >KDB: stack backtrace: >db_trace_self_wrapper(c0cb4313,c5b72a64,c08e4305,c08d467b,c0cb7338,...) >at db_trace_self_wrapper+0x26 >kdb_backtrace(c08d467b,c0cb7338,c5d31a98,c5d2cb60,c5b72ac0,...) at >kdb_backtrace+0x29 >_witness_debugger(c0cb7338,c0f7df0c,c0c9c4eb,c5d2cb60,c0ccfaf7,...) >at _witness_debugger+0x25 >witness_checkorder(c0f7df0c,1,c0ccfaf7,1c6,0,...) at witness_checkorder+0x839 >_rw_rlock(c0f7df0c,c0ccfaf7,1c6,c5d33088,c5e8be24,...) at _rw_rlock+0x9c >udp_input(c6905900,14,0,c5e8bd80,c0df9ee0,...) at udp_input+0x246 >ip_input(c6905900,c5f39240,c5b72bdc,c0745956,c0df9ee0,...) at ip_input+0x606 >netisr_dispatch_src(1,0,c6905900,c5b72c14,c0954161,...) at >netisr_dispatch_src+0xcd >netisr_dispatch(1,c6905900,c6018c00,c6018c00,c6925800,...) at >netisr_dispatch+0x20 >ether_demux(c6018c00,c6905900,3,0,3,...) at ether_demux+0x1a1 >ether_input(c6018c00,c6905900,c119f2d7,ff7,63,...) at ether_input+0x365 >em_rxeof(c5e8bd80,109,c6016180,0,c5b72cc8,...) at em_rxeof+0x133 >em_msix_rx(c5dc7600,c5b72cc8,c088e0b4,c0e13740,c60342b8,...) at >em_msix_rx+0x25 >intr_event_execute_handlers(c5d807f8,c6034280,c0cac35e,533,c60342f0,...) >at intr_event_execute_handlers+0x125 >ithread_loop(c603b4a0,c5b72d38,c0cac0cd,343,c5d807f8,...) at ithread_loop+0x9f >fork_exit(c0876da0,c603b4a0,c5b72d38) at fork_exit+0xb8 > >fork_trampoline() at fork_trampoline+0x8 >--- trap 0, eip = 0, esp = 0xc5b72d70, ebp = 0 --- > >Perhaps because multi-queue is still enabled ? > > >0(i5b)% vmstat -i >interrupt total rate >irq4: uart0 6637 28 >irq21: ehci0 382 1 >irq23: ehci1 615 2 >cpu0: timer 462573 1993 >irq256: em0 7640 32 >irq257: em1 5 0 >irq258: em1 6 0 > >irq261: em1 2 0 >irq262: ahci0 69 0 >cpu3: timer 461507 1989 >cpu2: timer 460985 1987 >cpu1: timer 461545 1989 >Total 1861966 8025 >0(i5b)% > > >em0: port 0x3040-0x305f >mem 0xc1b00000-0xc1b1ffff,0xc1b25000-0xc1b25fff irq 20 at device 25.0 on pci0 >em0: Using MSI interrupt >em0: [FILTER] >em0: Ethernet address: 00:15:17:c8:4b:99 >ehci0: mem >0xc1b22000-0xc1b223ff irq 21 at device 26.0 on pci0 >ehci0: [ITHREAD] >usbus0: EHCI version 1.0 >usbus0: on ehci0 >pcib2: irq 16 at device 28.0 on pci0 >pci2: on pcib2 >pcib3: irq 16 at device 28.4 on pci0 >pci3: on pcib3 >em1: port 0x1000-0x101f >mem 0xc1900000-0xc191ffff,0xc1920000-0xc1923fff irq 16 at device 0.0 on pci3 >em1: Using MSIX interrupts with 5 vectors >em1: [ITHREAD] >em1: [ITHREAD] >em1: [ITHREAD] >em1: [ITHREAD] >em1: [ITHREAD] >em1: Ethernet address: 00:15:17:c8:4b:98 > > > >-------------------------------------------------------------------- >Mike Tancsa, tel +1 519 651 3400 >Sentex >Communications, >mike@sentex.net >Providing Internet since >1994 www.sentex.net >Cambridge, Ontario >Canada www.sentex.net/mike > -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 16:06:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FBC2106564A for ; Sat, 10 Apr 2010 16:06:54 +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 B6E5C8FC13 for ; Sat, 10 Apr 2010 16:06:53 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 0D16041C751; Sat, 10 Apr 2010 18:06:53 +0200 (CEST) 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 t3j+v+di5LMZ; Sat, 10 Apr 2010 18:06:52 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 0058941C750; Sat, 10 Apr 2010 18:06:51 +0200 (CEST) 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 BC4C64448EC; Sat, 10 Apr 2010 16:05:31 +0000 (UTC) Date: Sat, 10 Apr 2010 16:05:31 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Mike Tancsa In-Reply-To: <201004101446.o3AEkQ0O058513@lava.sentex.ca> Message-ID: <20100410160008.Q40281@maildrop.int.zabbadoz.net> References: <201004081831.o38IVR3s043434@lava.sentex.ca> <20100408230750.GR5734@michelle.cdnetworks.com> <201004091317.o39DHFEl049965@lava.sentex.ca> <20100409164115.GB1085@michelle.cdnetworks.com> <201004091900.o39J0b0k051687@lava.sentex.ca> <20100409201307.GF1085@michelle.cdnetworks.com> <201004092105.o39L5SSh052323@lava.sentex.ca> <201004101446.o3AEkQ0O058513@lava.sentex.ca> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: pyunyh@gmail.com, freebsd-current@freebsd.org, Jack Vogel Subject: Re: LOR on em in HEAD ( was Re: em driver regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 16:06:54 -0000 On Sat, 10 Apr 2010, Mike Tancsa wrote: Hi Mike, > At 05:11 PM 4/9/2010, Jack Vogel wrote: >> Don't know, but I would just ignore it, I think its a false warning anyway. > > OK. I updated to HEAD as of this AM, but now I get a panic at bootup > ... > Trying to mount root from nfs: > NFS ROOT: 10.255.255.1:/usr/home/pxe9/ > panic: mutex em0:rx(0) not owned at > /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4093 > cpuid = 3 > KDB: enter: panic > [ thread pid 0 tid 100032 ] > Stopped at kdb_enter+0x3a: movl $0,kdb_why > db> bt > Tracing pid 0 tid 100032 td 0xc5f5bb40 > kdb_enter(c0cb0e9d,c0cb0e9d,c0caf56e,c5b2ac28,3,...) at kdb_enter+0x3a > panic(c0caf56e,c6002024,c11a0357,ffd,c5b2ac7c,...) at panic+0x136 > _mtx_assert(c6002010,4,c11a0357,ffd,64,...) at _mtx_assert+0x87 > em_rxeof(246,c5ff7d98,c5b2aca8,c088e194,c5ff7d98,...) at em_rxeof+0x3b > em_handle_que(c6006000,1,c0cb5c9c,4f,c5ff7d98,...) at em_handle_que+0x38 > taskqueue_run(c5ff7d80,c5ff7d98,c0ca6410,0,c0caf5f6,...) at > taskqueue_run+0x103 > taskqueue_thread_loop(c600a520,c5b2ad38,c0cac192,343,c0e0ce20,...) at > taskqueue_thread_loop+0x68 > fork_exit(c08dcde0,c600a520,c5b2ad38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc5b2ad70, ebp = 0 --- > db> This is a bug that seems to only happen in the Kitchener area as I hit it with a machine there just a few minutes ago as well. This one has fixed it for me: http://lists.freebsd.org/pipermail/svn-src-head/2010-April/016249.html /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 16:28:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A240106564A; Sat, 10 Apr 2010 16:28:20 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id EDA428FC1A; Sat, 10 Apr 2010 16:28:19 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id A29F81FFC22; Sat, 10 Apr 2010 16:28:18 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 28E1E84490; Sat, 10 Apr 2010 18:27:47 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Garrett Cooper References: <55861270658151@web135.yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <201004080849.12151.jhb@freebsd.org> <86r5mqt4aj.fsf@ds4.des.no> <86sk75ol54.fsf@ds4.des.no> <86fx356ku1.fsf@ds4.des.no> Date: Sat, 10 Apr 2010 18:27:46 +0200 In-Reply-To: (Garrett Cooper's message of "Fri, 9 Apr 2010 11:20:00 -0700") Message-ID: <86633zuvb1.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , freebsd-geom@freebsd.org, Teske , Randi Harper , freebsd-current@freebsd.org, "Andrey V. Elsukov" , Alexander Leidinger Subject: Re: [RFC] Rewriting sade(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 16:28:20 -0000 Garrett Cooper writes: > Now you're making a dangerous assumption that /inst isn't being used > by the end-user for any predefined purpose. No, I'm making the entirely reasonable assumption that *during the installation process* sysinstall can mount whatever the hell it wants wherever the hell it wants. Why is this so hard to understand? If the user wants to create an /inst filesystem *during installation* it will be mounted as /inst/inst. If the user runs sade *at a later time* and creates an /inst filesystem, it will be mounted as /inst. > Ok. Or maybe since `we're here' sade needs to be populating > $DESTDIR/etc/fstab, not sysinstall ? At that time (when sysinstall invokes sade) there is no $DESTDIR/etc - sysinstall hasn't yet started extracting the base distribution. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 17:18:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47E961065673 for ; Sat, 10 Apr 2010 17:18:16 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id EF2138FC16 for ; Sat, 10 Apr 2010 17:18:15 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so1458215qwi.7 for ; Sat, 10 Apr 2010 10:18:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=F3RwwOlJ6d4l7ZZVNJpiCgRtUgLgg/NgQ24e6d8Yi80=; b=pUTHdH3LcE7r682UViWhhMw+Zc/3CkhMX7wqJf3pf95g1yxFChKstkT1AfYjCahwjd rGkAtPFTLFt41uohwnB7jfhZBWRU2KXq0ScAlfYa+/ZLbuhNmIjkqfnqhD/GjAb5TaXy weWxUbRyZtA3kk2h3t1pQcaQh6WlRNaugu/Lo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=gIYYCum/yYmFKjZRdlGhTKhlZDtL3/y1UKdroxigEfiuzYuYh1evcqkni3Xbf2jK1R s3WZrwubDBeIboc5Tg1daYN9XhWyHkogpnj3WqWCwbzHgW+dkX4Lychg5umsypD4P7lk HXvVuMuaTIT9Oogek+DttAsRzluC4ihtjMBDc= Received: by 10.229.224.133 with SMTP id io5mr2559701qcb.37.1270919894827; Sat, 10 Apr 2010 10:18:14 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id y41sm3382856qce.23.2010.04.10.10.18.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 10 Apr 2010 10:18:14 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BC0B2D6.7030500@elischer.org> Date: Sat, 10 Apr 2010 10:18:14 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4BBFD502.1010507@elischer.org> <4BC088D3.3010908@incunabulum.net> In-Reply-To: <4BC088D3.3010908@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 17:18:16 -0000 On 4/10/10 7:18 AM, Bruce Simpson wrote: > On 04/10/10 02:31, Julian Elischer wrote: >> >> Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some >> others and I, felt that these ideas seemed to make some sense >> and so I put them here for comment. > > Please do. Someone has to do something about deployment. > > For what it's worth, I've tripped over the garden rake on the ground, > that is 'unsatisfied dependency' one too many times in commercial work. > > If PBIs can address this, even for FreeBSD's embedded and server use > cases, they will likely be well recieved. though the embedded people would be EXACTLY the people who would NOT use this new feature. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 17:54:48 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28F291065676; Sat, 10 Apr 2010 17:54:48 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id BA7B48FC19; Sat, 10 Apr 2010 17:54:47 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so1464784qwi.7 for ; Sat, 10 Apr 2010 10:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=8jV0qbXefPI8PgJJZeBXZtsf3OHb+ccU0TkANZvDXaA=; b=k3s7BnfYEoMJ5qnr45oW7yqrkL5JT6rnnzSqLY8MpE0pQf6VF7qM0BYaojh9dN31qy r4vg/gMgJaX+r8Sq5JWedviAx/POE+vrkJV6ikK0v0g7Vk04d5BUG0/2nf2zHXvIc3xQ BMJ+I+ss/g82Zs2mMpp1RmgEAR/FjU/iHGE90= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=j2BuNbhlGiYkgJ5QMFXhn65IJyrPgxobYaqUDnMGS3EzIemmcqQmKuBKOEca2auAmJ 8HEQSWZhb6q4bnFSr5iixANMwYSrlTiB4JWxQh5LLlI3MAjC7TO6FJU79taO1Y77Vcfq WbEK9YnsCWVZIRFfsA1W0qoZK09rzatm8q0IY= Received: by 10.229.97.147 with SMTP id l19mr2678847qcn.24.1270922086868; Sat, 10 Apr 2010 10:54:46 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id v37sm3436679qce.12.2010.04.10.10.54.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 10 Apr 2010 10:54:46 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BC0BB67.1050705@elischer.org> Date: Sat, 10 Apr 2010 10:54:47 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Sam Fourman Jr." References: <49684.1270905510@pcbsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, FreeBSD Current , kris@pcbsd.org Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 17:54:48 -0000 On 4/10/10 10:36 AM, Sam Fourman Jr. wrote: > > I do have a question, assuming PBI's were merged officially into the > FreeBSD ports tree, > say I had PostgreSQL Server installed, via PBI. then I wanted to tweak > a setting so I: > > cd /usr/ports/databases/postgresql84-server/&& make deinstall clean > > would the PBI at this point be removed? or no because it is self contained? > to some extent that depends on what we do. From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 19:29:37 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A99B8106566B for ; Sat, 10 Apr 2010 19:29:37 +0000 (UTC) (envelope-from jfvogel@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 36DA78FC0A for ; Sat, 10 Apr 2010 19:29:36 +0000 (UTC) Received: by wyb28 with SMTP id 28so456330wyb.13 for ; Sat, 10 Apr 2010 12:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=ivdS3mqfD6TatJ54SsSaRi7M2+kaxdFe0mq6anS+5pU=; b=GlrIcO28bS9sSLRbJqoln41UcIIFAnbUbII99eCyuoVX/XAK5enAMx/odK4eM7UbLk NwR0e+jLh7CRCIxHlrtlbJwtg+IQ/jsdNAWpASgPOhq1exrkZwNfFCPWUNEeojJm9bF1 dUzV+z1q94pf+IpZ8JcwzsWDq6Qiefor0W0Ww= 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=j986GQiH7KImG9HMQLSHApz8b4iUO1Zr6ZnFfsQ5wnfss3iypelgGes2DgjySTbDgp 4jHSU9fv1HwX9AOd6nqpQo5qiJhbm9C5mNVkm8Q+otzEm/yP9l4AARUGc4X1WNaTH9xK hLtTwaA7aHLGyQQ2SETu9zW2mN8cmP+3j1kBw= MIME-Version: 1.0 Received: by 10.216.11.8 with HTTP; Sat, 10 Apr 2010 12:29:35 -0700 (PDT) In-Reply-To: <20100410160008.Q40281@maildrop.int.zabbadoz.net> References: <201004081831.o38IVR3s043434@lava.sentex.ca> <20100409164115.GB1085@michelle.cdnetworks.com> <201004091900.o39J0b0k051687@lava.sentex.ca> <20100409201307.GF1085@michelle.cdnetworks.com> <201004092105.o39L5SSh052323@lava.sentex.ca> <201004101446.o3AEkQ0O058513@lava.sentex.ca> <20100410160008.Q40281@maildrop.int.zabbadoz.net> Date: Sat, 10 Apr 2010 12:29:35 -0700 Received: by 10.216.88.131 with SMTP id a3mr973932wef.153.1270927776066; Sat, 10 Apr 2010 12:29:36 -0700 (PDT) Message-ID: From: Jack Vogel To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, freebsd-current@freebsd.org, Mike Tancsa Subject: Re: LOR on em in HEAD ( was Re: em driver regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 19:29:37 -0000 Added the missing locks around calls to rxeof and checked it in a minute ago. Sorry guys! Jack On Sat, Apr 10, 2010 at 9:05 AM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > On Sat, 10 Apr 2010, Mike Tancsa wrote: > > Hi Mike, > > > At 05:11 PM 4/9/2010, Jack Vogel wrote: >> >>> Don't know, but I would just ignore it, I think its a false warning >>> anyway. >>> >> >> OK. I updated to HEAD as of this AM, but now I get a panic at bootup >> >> ... > > Trying to mount root from nfs: >> NFS ROOT: 10.255.255.1:/usr/home/pxe9/ >> panic: mutex em0:rx(0) not owned at >> /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4093 >> cpuid = 3 >> KDB: enter: panic >> [ thread pid 0 tid 100032 ] >> Stopped at kdb_enter+0x3a: movl $0,kdb_why >> db> bt >> Tracing pid 0 tid 100032 td 0xc5f5bb40 >> kdb_enter(c0cb0e9d,c0cb0e9d,c0caf56e,c5b2ac28,3,...) at kdb_enter+0x3a >> panic(c0caf56e,c6002024,c11a0357,ffd,c5b2ac7c,...) at panic+0x136 >> _mtx_assert(c6002010,4,c11a0357,ffd,64,...) at _mtx_assert+0x87 >> em_rxeof(246,c5ff7d98,c5b2aca8,c088e194,c5ff7d98,...) at em_rxeof+0x3b >> em_handle_que(c6006000,1,c0cb5c9c,4f,c5ff7d98,...) at em_handle_que+0x38 >> taskqueue_run(c5ff7d80,c5ff7d98,c0ca6410,0,c0caf5f6,...) at >> taskqueue_run+0x103 >> taskqueue_thread_loop(c600a520,c5b2ad38,c0cac192,343,c0e0ce20,...) at >> taskqueue_thread_loop+0x68 >> fork_exit(c08dcde0,c600a520,c5b2ad38) at fork_exit+0xb8 >> fork_trampoline() at fork_trampoline+0x8 >> --- trap 0, eip = 0, esp = 0xc5b2ad70, ebp = 0 --- >> db> >> > > > This is a bug that seems to only happen in the Kitchener area as I hit > it with a machine there just a few minutes ago as well. > > This one has fixed it for me: > http://lists.freebsd.org/pipermail/svn-src-head/2010-April/016249.html > > /bz > > -- > Bjoern A. Zeeb It will not break if you know what you are doing. > From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 17:03:33 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EC24106566C; Sat, 10 Apr 2010 17:03:33 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id A39C38FC0C; Sat, 10 Apr 2010 17:03:32 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so1455388qwi.7 for ; Sat, 10 Apr 2010 10:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=T2QYXm4vT/QBuzUfSr1EK+DHAHappLnjWGFREXZBzyY=; b=gN78wPE/yaTyYlcbH2bqpytlSXL3V9vHkgr5grFQeWgE7tXaEeiBmyStG2usobbcDE /GMkeD6wZw43Kn8AZNkaY6UtRQW0stNnxux+wutmYxNAFr6WpJKFZegPT9scvyJNSryj P01hJnfhEIaxjLgyFS3wLUwYBY1XSTeq5Sdv8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=gqmSIcLdGlCU4PcP9HwEHrJvNlPrbHHqDfbV0O2fv0HsDc6TJ9UuPT2XfUz+NTtACe hLP+DMJGNewrrrChXQQxGvVnke57dqY6CBVWFuGVOLj8XY+PFCejuxLbtmr6RZxfktq5 Pvq7YKg1DlwITG+LDQfps/j/2UmH4dgygnb0Q= Received: by 10.229.35.80 with SMTP id o16mr2375032qcd.93.1270919011473; Sat, 10 Apr 2010 10:03:31 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id w30sm3372964qce.10.2010.04.10.10.03.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 10 Apr 2010 10:03:30 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BC0AF62.9050600@elischer.org> Date: Sat, 10 Apr 2010 10:03:30 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Garrett Cooper References: <4BBFD502.1010507@elischer.org> <4BC03ABA.6090309@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 10 Apr 2010 19:57:23 +0000 Cc: Adam Vande More , Kris Moore , John Hixson , ports@freebsd.org, "Sam Fourman Jr." , "Dave Fourman\(Gmail\)" , Matt Olander , Vanessa Kraus , FreeBSD Current Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 17:03:33 -0000 On 4/10/10 3:35 AM, Garrett Cooper wrote: > On Sat, Apr 10, 2010 at 1:45 AM, Julian Elischer wrote: >> On 4/10/10 12:20 AM, Garrett Cooper wrote: >>> >>> On Fri, Apr 9, 2010 at 11:28 PM, Sam Fourman Jr. >>> wrote: >>>> >>>> On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande More >>>> wrote: >>>>> >>>>> On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer >>>>> wrote: >>>>> >>>>>> >>>>>> Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some >>>>>> others and I, felt that these ideas seemed to make some sense >>>>>> and so I put them here for comment. >>>>>> >>>>>> >>>>> FWIW, when I see these discussions I'm always left wondering what's the >>>>> bad >>>>> part? I do think there are problems, but there doesn't seem to be a >>>>> clear >>>>> defined set of what is wrong. IMO, there should be a defined set of >>>>> goals >>>>> to judge possible implementations against. >>>> >>>> >>>> Let me start by saying FreeBSD ports is by far the best system I have >>>> used to date. >>>> but as good as it is, there is room for improvement. >>>> >>>> Being a FreeBSD user now for many years, one thing I think would be nice >>>> is: >>>> being able to have easier access to development ports( Masked ports >>>> kinda like Gentoo). >>> >>> Masking ports and packages in general introduces all sorts of fun new >>> complexity for end users as well as maintainers. The last time I used >>> Gentoo (which was only a matter of months ago), a lot portage packages >>> were still masked even though they've been stable for months, years, >>> etc. This is very annoying for me as an end-user because bug blah >>> could be fixed in a later release but in order to unmask the pieces >>> for version blah, I had to unmask 10~15 other `unstable packages', >>> which greatly increased the chance of instability on my system (this >>> was particularly the case back several years ago, but Gentoo has >>> become more conservative over the years, and appears to be approaching >>> some level of equilibrium with Fedora, Ubuntu, etc in terms of >>> releases and package versioning). >>> >>>> right now is a GREAT example, currently there are new Gnome ,KDE and >>>> Xorg. >>>> these are all MAJOR ports,dependencies run deeper and deeper with every >>>> release. >>>> there can never be enough testing...but they all exist in random >>>> subversion servers around the web... >>> >>> ports isn't going to solve this. Post the Xorg modularization (which >>> needed to occur anyhow because Xorg and Xfree86 before that was were >>> monolithic beasts), I personally don't see that change in the amount >>> of flux on a quarterly cycle, and the number of packages I install >>> today isn't that much greater than back 6 years ago when I started >>> using FreeBSD. So, while there might be some claim here to note, I >>> think it's mostly exaggerated. >>> >>>> I would very much like to help test these Major ports, but installing >>>> them is a pain. >>>> there should be some sort of overlay system in place, so I can just >>>> build the development ports >>>> after agreeing to a few well placed warnings of course. and Well if I >>>> hose my system all to hell.. >>>> well then I could just click on a bunch of PBI's and I am back in >>>> business... >>> >>> Ok, apart from the interface (click a PBI, and magically you have >>> packages installed)... how is this really different from binary >>> packages? Have you tried installing binary packages lately via >>> pkg_add? If not, I'd give it a shot instead of installing from ports. >> >> >> yes but there are still dependency problems if you want to install a single >> package and you installed all the previous ones a year ago. >> With PBIs each package is self standing, so you can install one >> and not worry if it requires a different version of some library >> to what you installed last year. > > If I'm understanding you correctly you're saying it's an issue when I do: > > pkg_add A B C > > # 1 year passes > > pkg_add D > > # D depends on A, B, C, of different revisions. pkg_add barfs because > it can't find the applications, etc. > > This is something that's been hashed over a number of times (a few of > which I've participated in in #bsdports). There needs to be a simple > update command which will handle the action of upgrading packages, > because there isn't a proper command that will do so today. > > Unless PBIs are self-contained entities which have their own sets of > dependent utilities and libraries, etc (which you weren't suggesting > in the sentence above), or install into a common location with > versioned directories (which is a pain in the ass and involves a lot > of hardcoded pains dealing with libtool files, libraries, etc -- been > there, done that with Gentoo Linux -- there are hack scripts written > to work around several possible hardcoded version issue, and there are > a handful), AFAIK there's nothing positive and new that PBIs can bring > to the table in this regard that can't be implemented in pkg_install > as-is, other than the point-click-install user-friendly interface. ok that's your opinion n the matter. I for one think htat hte default ettin for PBIs to install all the dependencies, in this day of 1TB drives, makes sense and is a good capability for us to have, even if not everyone needs to use it. If you can do this with package code, Maybe you will supply the packages.. > >>>> better still, make the development ports a PBI, I am just thinking out >>>> loud here,but that may work, toughts? >>>> >>>> one could say I could use merge scripts like marcusmerge for example, >>>> or use Virtualbox... >>>> but for large ports like Xorg and gnome or KDE, virtualbox doesn't cut it >>>> yet... >>>> thinks like Nvidia Video cards, multiple monitors, USB devices, and >>>> whatnot do not work on virtual box.. >>>> PBI's for development ports, with all the dependencies, wrapped in one >>>> package. >>> >>> Ok, well here's the thing. Instead of having N shared dependencies and >>> libraries in /usr/local/lib, you'd have N**2 shared dependencies and >>> libraries in each and every package. Now, let's look at >> >> >> >>> $ ls -l irssi-0.8.14_1.tbz ~/Downloads/Irssi0.8.14_1-PV0.pbi >>> -rw-r--r-- 1 gcooper gcooper 6856203 Apr 10 00:05 >>> /usr/home/gcooper/Downloads/Irssi0.8.14_1-PV0.pbi >>> -rw-r--r-- 1 root wheel 517442 Apr 10 00:07 irssi-0.8.14_1.tbz >>> >>> The .tbz file is a file created with pkg_create -b, and the other file >>> is the PBI I pulled off of http://www.pbidir.com/bt/download/210/2079 >>> . Big difference in size (13.25 fold difference). >> >> Yes but that is a worst case thing. We are talking about making >> a system where the PBIs contain all the libraries needed but that >> only some of them are installed, when there is not already the >> same one (i.e. identical) installed by a previous PBI. >> so if you installed, say, 20 PBI from the same 'set' you woudl only >> be installing one copy of the libraries that > > See above comment. > >>> PBIs only comprise a small set of packages in FreeBSD; if my >>> understanding is correct based on a mirror referenced in pbidir.com, >>> the number is currently under 500~750 PBIs -- this is drastically >>> smaller than the number of binary packages produced by ports on a >>> regular basis for FreeBSD. >>> >>>> solution? well let all the developers develop working ports in >>>> progress in one place, give users like me a way to track these changes >>>> and install and test them... I think FreeBSD becomes a better place for >>>> it. >>> >>> Packages are more of the answer IMO, not PBIs. PBIs are merely a >>> different set of contents and different means of delivering those >>> contents, and while I like the idea of point - click - install, I'm >>> not ready to create unnecessary complexity by having libraries rev'ed >>> according to what the maintainer A believes are correct, even though >>> maintainer B set it differently, and I'm not interested in sacrificing >>> disk space for this reason. If I wanted to use a packaging scheme like >>> this, I should be using Mac OSX as my primary operating system. >> >> well no-one is going to make you use PBIs > > Yes, but if I now have to waste more bandwidth and disk space > installing packages, why shouldn't I go to another operating system? > Switching over to PBIs will reel in more desktop and entry-level > sysadmins, etc, but I fear that it will isolate folks in the embedded > market as well as several more seasoned users because of the > implications involved with the extra bandwidth requirement and > footprint. why? As people have said before.. embedded folks usually want to compile everyrthing for themselves anyhow. > >>> Thanks, >>> -Garrett >>> >>> PS Don't let this discourage you though in considering the entry-level >>> user case. I'm just apparently more insane than some folks (not as >>> insane as some others though), and I just don't believe in this >>> ideology because things are fine for me as-is. From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 17:36:53 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C869106564A; Sat, 10 Apr 2010 17:36:53 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 05A888FC08; Sat, 10 Apr 2010 17:36:52 +0000 (UTC) Received: by pwi9 with SMTP id 9so4027387pwi.13 for ; Sat, 10 Apr 2010 10:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FE+iqo5q6G5iRid7Xqt8QD5TJjHc2FY01fvea6pL9II=; b=LH2+MTmBe9ufCMoSniVPG0kihSYGHhI2HYNni41iHOI7lYSqUhTqMeLnko4gtdyORR Jzs/fMwEHkTAn7sT7nHgPk4glQlbLXxSEDwgqVIyv0I/pcgT8RZUveIqOzrhljeo8Aej QOI8Xmsi1SCzGp/c1brLNn2/pOSggWQv/XnIk= 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=n3lozlg3z68/7A+QXkoFgozW6pVa2HH5YsU/vI7rosqdOSEgUmLIE/mKq1Nwu4QYfO AGQmLgZ96EVbee2mKj1eVS94x3CD/zHX50H9F+PC6qDrvIf0GkT4JvKJqbD9wUV/ArrP 6EmJlU4r+ijkASxnrcBnUiqa9sfPJvXPp0pTQ= MIME-Version: 1.0 Received: by 10.143.30.2 with HTTP; Sat, 10 Apr 2010 10:36:52 -0700 (PDT) In-Reply-To: <49684.1270905510@pcbsd.org> References: <49684.1270905510@pcbsd.org> Date: Sat, 10 Apr 2010 12:36:52 -0500 Received: by 10.142.248.9 with SMTP id v9mr845061wfh.6.1270921012332; Sat, 10 Apr 2010 10:36:52 -0700 (PDT) Message-ID: From: "Sam Fourman Jr." To: kris@pcbsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 10 Apr 2010 19:57:31 +0000 Cc: Adam Vande More , Kris Moore , John Hixson , ports@freebsd.org, Julian Elischer , "Dave Fourman\(Gmail\)" , Garrett Cooper , Matt Olander , Vanessa Kraus , FreeBSD Current Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 17:36:53 -0000 On Sat, Apr 10, 2010 at 8:18 AM, wrote: > > > > > On Sat 10/04/10 3:35 AM , Garrett Cooper wrote: > > [...] > >> >> yes but there are still dependency problems if you want to install a >> single >> package and you installed all the previous ones a year ago. >> With PBIs each package is self standing, so you can install one >> and not worry if it requires a different version of some library >> to what you installed last year. > > If I'm understanding you correctly you're saying it's an issue when I do: > > pkg_add A B C > > # 1 year passes > > pkg_add D > > # D depends on A, B, C, of different revisions. pkg_add barfs because > it can't find the applications, etc. > > This is something that's been hashed over a number of times (a few of > which I've participated in in #bsdports). There needs to be a simple > update command which will handle the action of upgrading packages, > because there isn't a proper command that will do so today. > > Unless PBIs are self-contained entities which have their own sets of > dependent utilities and libraries, etc (which you weren't suggesting > in the sentence above), or install into a common location with > versioned directories (which is a pain in the ass and involves a lot > of hardcoded pains dealing with libtool files, libraries, etc -- been > there, done that with Gentoo Linux -- there are hack scripts written > to work around several possible hardcoded version issue, and there are > a handful), AFAIK there's nothing positive and new that PBIs can bring > to the table in this regard that can't be implemented in pkg_install > as-is, other than the point-click-install user-friendly interface. > > > > Incorrect. The difference is in complexity at install-time. Even if you > improve the package manager > > to better resolve and upgrade all related dependencies as a result of doi= ng > a firefox upgrade, the fact > > still remains that just to update one package, you may have to also updat= e a > TON of various packages > > / libraries, any of which may be critical to other applications on your > system. If just a single one of those > > things fails, you can end up breaking a lot of applications on your syste= m > or even your entire desktop. > > PBI system simplifies this process. Updating firefox, since its > self-contained, does NOT run the risk > > of borking anything else on the system. You don't need to work about libp= ng, > libjpeg, or some other seemingly > > trivial library (to the end user) causing a huge breakage for xorg, or > KDE/Gnome, etc. > > This in my opinion is the fatal flaw of pretty much every open-source sys= tem > out there right now. Something both > > windows & mac have recognized and dealt with. We instead try to write mor= e > and more complex package resolvers, > > while failing to address the main issue, that with such a complex chain o= f > dependencies for something as simple > > as upgrading firefox, it increases the chances exponentially that somethi= ng > will break and ruin your day / weekend. > > > >>> PBIs only comprise a small set of packages in FreeBSD; if my >>> understanding is correct based on a mirror referenced in pbidir.com, >>> the number is currently under 500~750 PBIs -- this is drastically >>> smaller than the number of binary packages produced by ports on a >>> regular basis for FreeBSD. >>> >>>> solution? well let all the developers develop working ports in >>>> progress in one place, give users like me a way to track these changes >>>> and install and test them... I think FreeBSD becomes a better place fo= r >>>> it. >>> >>> Packages are more of the answer IMO, not PBIs. PBIs are merely a >>> different set of contents and different means of delivering those >>> contents, and while I like the idea of point - click - install, I'm >>> not ready to create unnecessary complexity by having libraries rev'ed >>> according to what the maintainer A believes are correct, even though >>> maintainer B set it differently, and I'm not interested in sacrificing >>> disk space for this reason. If I wanted to use a packaging scheme like >>> this, I should be using Mac OSX as my primary operating system. >> >> well no-one is going to make you use PBIs > > Yes, but if I now have to waste more bandwidth and disk space > installing packages, why shouldn't I go to another operating system? > Switching over to PBIs will reel in more desktop and entry-level > sysadmins, etc, but I fear that it will isolate folks in the embedded > market as well as several more seasoned users because of the > implications involved with the extra bandwidth requirement and > footprint. > > This gave me a bit of a chuckle. PBI would not be intended as a replaceme= nt > for ports, > rather a utilizing of ports in such a way that we can start building > self-contained, stand-alone > binaries for end-users and those of us who value their time more than a f= ew > MB of disk space. > Considering at every BSD conference it seems that the majority of develop= ers > are running Mac > laptops, it would seem that even some developers agree with the principle= , > they just aren't doing > it on FreeBSD. :) > I also, noticed this, and a several years back I was a Newcomer to FreeBSD I was at BSDCan, and I wondered, why are all the developers using OSX? it was then that I knew,that if we could get PC-BSD to the point where the FreeBSD developers CHOSE to use it over say OSX, we would REALLY help FreeBSD as a whole. it is for this exact reason, I believe PBI's should be merged in with the ports tree in some fashion. I do have a question, assuming PBI's were merged officially into the FreeBSD ports tree, say I had PostgreSQL Server installed, via PBI. then I wanted to tweak a setting so I: cd /usr/ports/databases/postgresql84-server/ && make deinstall clean would the PBI at this point be removed? or no because it is self contained? > However for my more hard-core friends, nothing stopping you from running > your own ports down > the road, more power to ya! For doing something like embedded work or=A0 = a > server this makes total > sense and I think it is a huge positive for FreeBSD, no reason to trash t= hat > or break it in any way. > For the other 99.9% of society who want something "that just works" for > day-to-day computing, > something like PBI is very attractive. It would be great to have an OS th= at > offers best of both worlds. > > -- > Kris Moore > > > > > > ________________________________ > Message sent via Atmail Open - http://atmail.org/ From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 19:07:32 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DE50106566C for ; Sat, 10 Apr 2010 19:07:32 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id C6E458FC12 for ; Sat, 10 Apr 2010 19:07:31 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.3/8.14.3) id o3AJ7hUx004398; Sat, 10 Apr 2010 19:07:43 GMT (envelope-from kientzle@freebsd.org) Received: from horton.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id vr77fgpbtqk5k23xpe5ei4aghw; Sat, 10 Apr 2010 19:07:42 +0000 (UTC) (envelope-from kientzle@freebsd.org) Message-ID: <4BC0CC6F.7010009@freebsd.org> Date: Sat, 10 Apr 2010 12:07:27 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.23) Gecko/20100314 SeaMonkey/1.1.18 MIME-Version: 1.0 To: Garrett Cooper References: <4BBFD502.1010507@elischer.org> <4BC03ABA.6090309@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 10 Apr 2010 19:57:47 +0000 Cc: Adam Vande More , Kris Moore , John Hixson , ports@freebsd.org, Julian Elischer , "Sam Fourman Jr." , "Dave Fourman\(Gmail\)" , Matt Olander , Vanessa Kraus , FreeBSD Current Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 19:07:32 -0000 Garrett Cooper wrote: > If I'm understanding you correctly you're saying it's an issue when I do: > > pkg_add A B C > > # 1 year passes > > pkg_add D > > # D depends on A, B, C, of different revisions. pkg_add barfs because > it can't find the applications, etc. > > This is something that's been hashed over a number of times (a few of > which I've participated in in #bsdports). There needs to be a simple > update command which will handle the action of upgrading packages, > because there isn't a proper command that will do so today. I'm not convinced that the "simple update command" you mention is actually feasible, much less desirable. (If I want to try out the new Firefox, why does that imply that my year-old Gimp has to be upgraded?) As for feasibility, here's the easy problem: A2.7 requires B3.6 ... one year passes ... A4.8 now requires B7.2 But A4.8 is incompatible with B3.6 and A2.7 is incompatible with B7.2. So neither A nor B can be updated separately without breaking the system. Here's the hard problem: A2.7 requires B3.6 ... one year passes ... I want to install C1.0 which requires B7.2 but there hasn't been a new release of A that works with B7.2. So I now simply cannot have both C1.0 and A2.7 installed at the same time because they require different versions of B. PBI avoids both of these problems. It may be unsuitable for embedded systems[1], but I see no reason we should not extend the existing ports/packages system with additional tools that target certain use cases, and PBI seems a good fit for the desktop case. Tim [1] Actually, PBI might work just fine even for embedded if we address the disk bloat issue. One approach would be to make /Package/Bar/libfoo-2.8.7.so a symlink or hardlink to /Package/Shared/libfoo-2.8.7.so- This gives easy sharing of identical files. It's even easy to handle at install time: * Installer writes libfoo-2.8.7.so to /Package/Shared/libfoo-2.8.7.so-temp- * Installer computes hash of file as it's written * Installer renames file (delete if rename fails with EEXIST) * Installer writes symlink or hardlink into /Package/Bar From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 20:15:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0ADD1065722 for ; Sat, 10 Apr 2010 20:15:01 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 874DA8FC0A for ; Sat, 10 Apr 2010 20:15:01 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1O0h4x-00058m-EL for freebsd-current@freebsd.org; Sat, 10 Apr 2010 22:14:55 +0200 Received: from 200.41.broadband11.iol.cz ([90.178.41.200]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Apr 2010 22:14:55 +0200 Received: from gamato by 200.41.broadband11.iol.cz with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Apr 2010 22:14:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: martinko Date: Sat, 10 Apr 2010 22:14:47 +0200 Lines: 12 Message-ID: <4BC0DC37.7050909@users.sf.net> References: <20100120024245.GD46479@stlux503.dsto.defence.gov.au> 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: 200.41.broadband11.iol.cz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.8) Gecko/20100220 SeaMonkey/2.0.3 In-Reply-To: <20100120024245.GD46479@stlux503.dsto.defence.gov.au> Cc: freebsd-x11@freebsd.org Subject: Re: code.google -> Xpra (anyone planning to port it ?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 20:15:01 -0000 Wilkinson, Alex wrote: > Howdy people, > > This looks like a very nice app, has anyone got it working on FreeBSD yet ? > > http://code.google.com/p/partiwm/wiki/xpra > > -Alex > Well, and what about http://code.google.com/p/neatx/ ? That would be useful! :-) From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 21:12:16 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EC62106564A; Sat, 10 Apr 2010 21:12:16 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id D84738FC08; Sat, 10 Apr 2010 21:12:15 +0000 (UTC) Received: by qyk11 with SMTP id 11so3734061qyk.13 for ; Sat, 10 Apr 2010 14:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=qEAGxMVhRRlVPfF8fhkHuiTYifr4VFzc45C7DlzaKFQ=; b=W3Iw4kWDWQ2dxm+wmz1KNVGRm7ax9yBw5jYj2a0gE51ddRTVAnkGER+UkowS8WsiO4 c1A8K/5k3qIR/KFey2UO+AL0Bh8QZJdcd0R7q+WdzGgecEV0BOdkIxw1F9i6y7MhNe1D 5yLxuk+r2M6qxJlk8Oa6/KpIUFombGv/AU/Vs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=eDtmtmIw/SuGaQZNsjD7zSuy8KsCi9MBElR7hzXGLlnYDLokOZD9ma/KC0hu+rvCgV tFWNuGm90rjR+Diw+Jj/y7a8c9hxMdWqUedbTew2C8xpoza/+0uXWS9j0+lBmAjJDM78 K0Wh5gG++18nfLpPi8gzj+3I70Nwmv7wSX84M= Received: by 10.229.217.206 with SMTP id hn14mr2801432qcb.70.1270933934928; Sat, 10 Apr 2010 14:12:14 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id v37sm3695078qce.18.2010.04.10.14.12.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 10 Apr 2010 14:12:14 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BC0E9AE.1000904@elischer.org> Date: Sat, 10 Apr 2010 14:12:14 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Tim Kientzle References: <4BBFD502.1010507@elischer.org> <4BC03ABA.6090309@elischer.org> <4BC0CC6F.7010009@freebsd.org> In-Reply-To: <4BC0CC6F.7010009@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, "Sam Fourman Jr." , FreeBSD Current Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 21:12:16 -0000 On 4/10/10 12:07 PM, Tim Kientzle wrote: > Garrett Cooper wrote: >> If I'm understanding you correctly you're saying it's an issue when I do: >> >> pkg_add A B C >> >> # 1 year passes >> >> pkg_add D >> >> # D depends on A, B, C, of different revisions. pkg_add barfs because >> it can't find the applications, etc. >> >> This is something that's been hashed over a number of times (a few of >> which I've participated in in #bsdports). There needs to be a simple >> update command which will handle the action of upgrading packages, >> because there isn't a proper command that will do so today. > > I'm not convinced that the "simple update command" you > mention is actually feasible, much less desirable. > (If I want to try out the new Firefox, why does that > imply that my year-old Gimp has to be upgraded?) > > As for feasibility, here's the easy problem: > A2.7 requires B3.6 > ... one year passes ... > A4.8 now requires B7.2 > But A4.8 is incompatible with B3.6 and A2.7 is > incompatible with B7.2. So neither A nor B > can be updated separately without breaking the system. > > Here's the hard problem: > A2.7 requires B3.6 > ... one year passes ... > I want to install C1.0 which requires B7.2 > but there hasn't been a new release of A that > works with B7.2. > So I now simply cannot have both C1.0 and A2.7 > installed at the same time because they require > different versions of B. > > PBI avoids both of these problems. It may > be unsuitable for embedded systems[1], but > I see no reason we should not extend the existing > ports/packages system with additional tools that > target certain use cases, and PBI seems a good > fit for the desktop case. > > Tim > > [1] Actually, PBI might work just fine even for > embedded if we address the disk bloat issue. One > approach would be to make > /Package/Bar/libfoo-2.8.7.so > a symlink or hardlink to > /Package/Shared/libfoo-2.8.7.so- > This gives easy sharing of identical files. > It's even easy to handle at install time: > * Installer writes libfoo-2.8.7.so to > /Package/Shared/libfoo-2.8.7.so-temp- > * Installer computes hash of file as it's written > * Installer renames file (delete if rename fails with EEXIST) > * Installer writes symlink or hardlink into /Package/Bar yeah that's more or less what we were thinking.. hardlinks allow you to garbage collect when the last pbi that needs something is replaced/removed. It's also to handle the cases where library A wants library B. you don't want library A in the shared place looking for B back in the original PBI directory so there may need to be some patching up. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 22:07:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 381151065670 for ; Sat, 10 Apr 2010 22:07:59 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 078638FC19 for ; Sat, 10 Apr 2010 22:07:58 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id o3AM7uPb060629; Sat, 10 Apr 2010 18:07:56 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201004102207.o3AM7uPb060629@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 10 Apr 2010 18:07:52 -0400 To: Jack Vogel , "Bjoern A. Zeeb" From: Mike Tancsa In-Reply-To: References: <201004081831.o38IVR3s043434@lava.sentex.ca> <20100409164115.GB1085@michelle.cdnetworks.com> <201004091900.o39J0b0k051687@lava.sentex.ca> <20100409201307.GF1085@michelle.cdnetworks.com> <201004092105.o39L5SSh052323@lava.sentex.ca> <201004101446.o3AEkQ0O058513@lava.sentex.ca> <20100410160008.Q40281@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pyunyh@gmail.com, freebsd-current@freebsd.org Subject: Re: LOR on em in HEAD ( was Re: em driver regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 22:07:59 -0000 At 03:29 PM 4/10/2010, Jack Vogel wrote: >Added the missing locks around calls to rxeof and checked it in a minute ago. > >Sorry guys! Looks good for me now. BTW, I thought the multi-queue was supposed to be disabled on the em nic ? em0: port 0x3040-0x305f mem 0xc1b00000-0xc1b1ffff,0xc1b25000-0xc1b25fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:c8:4b:99 em1: port 0x1000-0x101f mem 0xc1900000-0xc191ffff,0xc1920000-0xc1923fff irq 16 at device 0.0 on pci3 em1: Using MSIX interrupts with 5 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:15:17:c8:4b:98 0(i5b)% vmstat -i interrupt total rate irq4: uart0 6285 13 irq21: ehci0 728 1 irq23: ehci1 1078 2 cpu0: timer 924321 1992 irq256: em0 9375 20 irq257: em1 127 0 irq258: em1 7 0 irq261: em1 2 0 irq262: ahci0 69 0 cpu3: timer 923686 1990 cpu1: timer 923651 1990 cpu2: timer 923597 1990 Total 3712926 8001 0(i5b)% em0@pci0:0:25:0: class=0x020000 card=0x34ec8086 chip=0x10ef8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP em1@pci0:3:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled >Jack > > >On Sat, Apr 10, 2010 at 9:05 AM, Bjoern A. Zeeb ><bzeeb-lists@lists.zabbadoz.net> wrote: >On Sat, 10 Apr 2010, Mike Tancsa wrote: > >Hi Mike, > > >At 05:11 PM 4/9/2010, Jack Vogel wrote: >Don't know, but I would just ignore it, I think its a false warning anyway. > > >OK. I updated to HEAD as of this AM, but now I get a panic at bootup > >... > >Trying to mount root from nfs: >NFS ROOT: 10.255.255.1:/usr/home/pxe9/ >panic: mutex em0:rx(0) not owned at >/usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4093 >cpuid = 3 >KDB: enter: panic >[ thread pid 0 tid 100032 ] >Stopped at kdb_enter+0x3a: movl $0,kdb_why >db> bt >Tracing pid 0 tid 100032 td 0xc5f5bb40 >kdb_enter(c0cb0e9d,c0cb0e9d,c0caf56e,c5b2ac28,3,...) at kdb_enter+0x3a >panic(c0caf56e,c6002024,c11a0357,ffd,c5b2ac7c,...) at panic+0x136 >_mtx_assert(c6002010,4,c11a0357,ffd,64,...) at _mtx_assert+0x87 >em_rxeof(246,c5ff7d98,c5b2aca8,c088e194,c5ff7d98,...) at em_rxeof+0x3b >em_handle_que(c6006000,1,c0cb5c9c,4f,c5ff7d98,...) at em_handle_que+0x38 >taskqueue_run(c5ff7d80,c5ff7d98,c0ca6410,0,c0caf5f6,...) at >taskqueue_run+0x103 >taskqueue_thread_loop(c600a520,c5b2ad38,c0cac192,343,c0e0ce20,...) >at taskqueue_thread_loop+0x68 >fork_exit(c08dcde0,c600a520,c5b2ad38) at fork_exit+0xb8 >fork_trampoline() at fork_trampoline+0x8 >--- trap 0, eip = 0, esp = 0xc5b2ad70, ebp = 0 --- >db> > > > >This is a bug that seems to only happen in the Kitchener area as I hit >it with a machine there just a few minutes ago as well. > >This one has fixed it for me: >http://lists.freebsd.org/pipermail/svn-src-head/2010-April/016249.html > >/bz > >-- >Bjoern A. Zeeb It will not break if you know what you are doing. > -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 22:45:25 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ADD11065673; Sat, 10 Apr 2010 22:45:25 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1B7958FC1F; Sat, 10 Apr 2010 22:45:24 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.3/8.14.3) id o3AMjaKx005708; Sat, 10 Apr 2010 22:45:36 GMT (envelope-from kientzle@freebsd.org) Received: from horton.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id eivfvtwtf7266ixd6zrdpsdpmw; Sat, 10 Apr 2010 22:45:36 +0000 (UTC) (envelope-from kientzle@freebsd.org) Message-ID: <4BC0FF80.4000907@freebsd.org> Date: Sat, 10 Apr 2010 15:45:20 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.23) Gecko/20100314 SeaMonkey/1.1.18 MIME-Version: 1.0 To: Julian Elischer References: <4BBFD502.1010507@elischer.org> <4BC03ABA.6090309@elischer.org> <4BC0CC6F.7010009@freebsd.org> <4BC0E9AE.1000904@elischer.org> In-Reply-To: <4BC0E9AE.1000904@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, FreeBSD Current Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 22:45:25 -0000 Julian Elischer wrote: > On 4/10/10 12:07 PM, Tim Kientzle wrote: >> [1] Actually, PBI might work just fine even for >> embedded if we address the disk bloat issue. One >> approach would be to make >> /Package/Bar/libfoo-2.8.7.so >> a symlink or hardlink to >> /Package/Shared/libfoo-2.8.7.so- >> This gives easy sharing of identical files. > > yeah that's more or less what we were thinking.. > hardlinks allow you to garbage collect when the last pbi that needs > something is replaced/removed. The point of /Package/Shared in this design is basically that it provides a list of all of the files that can be shared, so you avoid doing a full disk search to identify other places that might have this file. You could accomplish the same goal by building and storing a database of sharable files somewhere, of course. (Curiously, no one has mentioned filesystem-level deduping yet as the "big hammer" solution... ;-) The LD_LIBRARY_PATH issue is the most interesting problem here. I don't immediately see a solution that doesn't include teaching ld-elf.so.1 about some form of per-application library path. Tim From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 23:10:16 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02FCF1065672; Sat, 10 Apr 2010 23:10:16 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id C7E468FC18; Sat, 10 Apr 2010 23:10:15 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.3/8.14.3) id o3ANAR0j005912; Sat, 10 Apr 2010 23:10:27 GMT (envelope-from kientzle@freebsd.org) Received: from horton.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id 7b85d2kbtn9fwqdbh9q7g6npca; Sat, 10 Apr 2010 23:10:26 +0000 (UTC) (envelope-from kientzle@freebsd.org) Message-ID: <4BC10553.1080705@freebsd.org> Date: Sat, 10 Apr 2010 16:10:11 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.23) Gecko/20100314 SeaMonkey/1.1.18 MIME-Version: 1.0 To: "Sam Fourman Jr." References: <49684.1270905510@pcbsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, Kris Moore , Julian Elischer , FreeBSD Current Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 23:10:16 -0000 Sam Fourman Jr. wrote: > I do have a question, assuming PBI's were merged officially into the > FreeBSD ports tree, > say I had PostgreSQL Server installed, via PBI. then I wanted to tweak > a setting so I: > > cd /usr/ports/databases/postgresql84-server/ && make deinstall clean > > would the PBI at this point be removed? or no because it is self contained? Basically, I believe the proposal here is to add: * make pbi to the ports build system to create a PBI from a port and possibly add * make installpbi * make deinstallpbi to install/deinstall just the resulting PBI. In particular, I don't think anyone is suggesting removing or changing any existing ports/package capability. People who are happy with the existing ports/package system could continue using it exactly as-is. This would imply that you might build Postgres and install it both as a port/package and simultaneously as a PBI. I'm not sure what that would mean, though. The big question, of course: what impact would the addition of "make pbi" have on existing port/package support efforts? Is this creating extra work for existing maintainers? Should it be optional (enabled per-port) or somehow default? I suspect the next step is for someone to put forward a proposed implementation of "make pbi" so those interested can start trying it out and see what the impacts are. (If only the GSoC proposal deadline hadn't already passed. ;-) Tim From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 23:47:01 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0783B106566C; Sat, 10 Apr 2010 23:47:01 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id E04B58FC08; Sat, 10 Apr 2010 23:47:00 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 744558C07D; Sat, 10 Apr 2010 18:47:00 -0500 (CDT) Date: Sat, 10 Apr 2010 18:47:00 -0500 From: Mark Linimon To: Julian Elischer Message-ID: <20100410234700.GG6166@lonesome.com> References: <4BBFD502.1010507@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BBFD502.1010507@elischer.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ports@freebsd.org, FreeBSD Current Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 23:47:01 -0000 not to be a troll but ... ... for those that want the ease-of-use of PBIs, why not just use PC-BSD in the first place? They seem to have their own QA process in place in terms of keeping the various large applications at a sane level. Kernel development could (just like it is on the Macs) be done in some kind of virtualization context. My own experience with helping people who try to run FreeBSD-CURRENT with an up-to-date ports tree is that there are far too many moving parts for it to be dependable. (For more on how often ports get broken by changes in -CURRENT, see http://wiki.freebsd.org/PortsBrokenOnCurrent. Note that that list is not complete.) mcl