From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 01:15:30 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60A201065689 for ; Sun, 25 Jan 2009 01:15:30 +0000 (UTC) (envelope-from prvs=julian=2693e0778@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 4EE238FC17 for ; Sun, 25 Jan 2009 01:15:30 +0000 (UTC) (envelope-from prvs=julian=2693e0778@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.85]) by smtp-outbound.ironport.com with ESMTP; 24 Jan 2009 15:49:46 -0800 Message-ID: <497BA91D.805@elischer.org> Date: Sat, 24 Jan 2009 15:49:49 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2009 01:15:30 -0000 Currently we have: spin locks.. you really don't want to hold these for any time at all, and this is enforced to some extent in the waiter. regular mutexes.. You can hold these for as long as you want but teh shorter the better and you can't sleep when holding them. The "shortness" of the time of holding the mutex is not enforced. "Sleeps" (including sx-locks and friends) You may hold these or be descheduled for really long periods of time. Now it occurs to me that there is a subclass of regular mutexes, usage, which is where you want to use a mutex to guard some small but critical structure, and that you know that access to that structure will be quick, and that you can guarantee that you will not acquire any other locks (which could introduce unknown delay) while hoding the lock. One way of thinking about this is that this lock would always be a leaf node on the tree of lock orders. I would like to be able to add a flag to a mutex that tags it as a 'leaf' mutex. As a result it would be illegal to take any other mutex while holding a leaf mutex. Somewhat similar to the way that it is illegal to take aregular mutex while holding a spin mutex.. In netgraph I have a stipulation that is hard to specify which is that you MAY take a mutex in a netgraph node if you can guarantee that the mutex WILL be satisfied very quickly, but it'd be nice to be able to specify "you may only take 'leaf' mutexes within an netgraph node". thoughts? (especially from jhb and other locking types). From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 04:25:41 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F117F106566C for ; Sun, 25 Jan 2009 04:25:41 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id C4A5D8FC12 for ; Sun, 25 Jan 2009 04:25:41 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5480360rvf.43 for ; Sat, 24 Jan 2009 20:25:41 -0800 (PST) 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:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=cnt7hmpcu039z+pH2Z1IcrJLBPTkhIyF/iLiudJ1pxE=; b=Jmb6NhLc4RvntpCrjTgcXsG61X9tG2yDyHbneXatRCiJ1d/YCfJ507QmorLHwaF6WV mO0W+lBVgGMEuLaQJfUo5jfMO3IvHK3I0p/PGu4A1Oeqa9GRt4OTgKpQ/CgOgTg8TuNB W6NdXNQ+tSMxiridNSzLX/b6I0ajNoED1CI1o= 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=s/xbz3sUnZ94pYlvCSJGAOpTHX2KTCw7DMByvY44WukwyDGi/PCXKcSi231wFlbuNY W6f5B2DSSem7d2I8NPZimS4FC3jArCQ9jyDtLpjtBvTl+ut0m1XVmDNRQft4OoeY7Oid Qs8W7suQd8YorZCwReixp4lcS5/1ukXisB5XE= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.140.170.21 with SMTP id s21mr1039592rve.205.1232855803849; Sat, 24 Jan 2009 19:56:43 -0800 (PST) In-Reply-To: <497BA91D.805@elischer.org> References: <497BA91D.805@elischer.org> Date: Sat, 24 Jan 2009 19:56:43 -0800 X-Google-Sender-Auth: a6e2a05d4e55e352 Message-ID: <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com> From: Kip Macy To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2009 04:25:42 -0000 The adaptive spinning of regular mutexes already satisfies your need for "short" hold. You might wish to add a thread flag used when INVARIANTS is enabled that is set when a leaf mutex is acquired and checked on all mutex acquisitions. -Kip On Sat, Jan 24, 2009 at 3:49 PM, Julian Elischer wrote: > Currently we have: > spin locks.. > you really don't want to hold these for > any time at all, and this is enforced to some extent in the waiter. > > regular mutexes.. > You can hold these for as long as you want but teh shorter > the better and you can't sleep when holding them. The > "shortness" of the time of holding the mutex is not enforced. > > "Sleeps" (including sx-locks and friends) > You may hold these or be descheduled for really long periods of time. > > > Now it occurs to me that there is a subclass of regular mutexes, > usage, which is where you want to use a mutex to guard some small > but critical structure, and that you know that access to that structure will > be quick, and that you can guarantee that you will > not acquire any other locks (which could introduce unknown delay) > while hoding the lock. > > One way of thinking about this is that this lock would always be > a leaf node on the tree of lock orders. > I would like to be able to add a flag to a mutex > that tags it as a 'leaf' mutex. As a result it would be illegal > to take any other mutex while holding a leaf mutex. Somewhat > similar to the way that it is illegal to take aregular > mutex while holding a spin mutex.. > > > In netgraph I have a stipulation that is hard to specify which > is that you MAY take a mutex in a netgraph node if you can guarantee > that the mutex WILL be satisfied very quickly, but it'd > be nice to be able to specify "you may only take 'leaf' mutexes within an > netgraph node". > > > thoughts? (especially from jhb and other locking types). > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 08:18:45 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8B5E106564A for ; Sun, 25 Jan 2009 08:18:45 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id AD9058FC17 for ; Sun, 25 Jan 2009 08:18:45 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 744203F129; Sun, 25 Jan 2009 08:18:44 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n0P8IhHg023212; Sun, 25 Jan 2009 08:18:43 GMT (envelope-from phk@critter.freebsd.dk) To: Julian Elischer From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 24 Jan 2009 15:49:49 PST." <497BA91D.805@elischer.org> Date: Sun, 25 Jan 2009 08:18:43 +0000 Message-ID: <23211.1232871523@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2009 08:18:46 -0000 In message <497BA91D.805@elischer.org>, Julian Elischer writes: >I would like to be able to add a flag to a mutex >that tags it as a 'leaf' mutex. As a result it would be illegal >to take any other mutex while holding a leaf mutex. I second that, even if the flag is purely documentary, it is a good idea. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 08:45:31 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCCD31065672 for ; Sun, 25 Jan 2009 08:45:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outn.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id 6E2328FC16 for ; Sun, 25 Jan 2009 08:45:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 9E8D524E9; Sun, 25 Jan 2009 00:31:22 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 594A42D601A; Sun, 25 Jan 2009 00:31:22 -0800 (PST) Message-ID: <497C235E.5090807@elischer.org> Date: Sun, 25 Jan 2009 00:31:26 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Kip Macy References: <497BA91D.805@elischer.org> <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com> In-Reply-To: <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2009 08:45:31 -0000 Kip Macy wrote: > The adaptive spinning of regular mutexes already satisfies your need > for "short" hold. You might wish to add a thread flag used when > INVARIANTS is enabled that is set when a leaf mutex is acquired and > checked on all mutex acquisitions. ummm that was what I was asking for.. an official designation of a 'leaf' mutex... > > -Kip > > On Sat, Jan 24, 2009 at 3:49 PM, Julian Elischer wrote: >> Currently we have: >> spin locks.. >> you really don't want to hold these for >> any time at all, and this is enforced to some extent in the waiter. >> >> regular mutexes.. >> You can hold these for as long as you want but teh shorter >> the better and you can't sleep when holding them. The >> "shortness" of the time of holding the mutex is not enforced. >> >> "Sleeps" (including sx-locks and friends) >> You may hold these or be descheduled for really long periods of time. >> >> >> Now it occurs to me that there is a subclass of regular mutexes, >> usage, which is where you want to use a mutex to guard some small >> but critical structure, and that you know that access to that structure will >> be quick, and that you can guarantee that you will >> not acquire any other locks (which could introduce unknown delay) >> while hoding the lock. >> >> One way of thinking about this is that this lock would always be >> a leaf node on the tree of lock orders. >> I would like to be able to add a flag to a mutex >> that tags it as a 'leaf' mutex. As a result it would be illegal >> to take any other mutex while holding a leaf mutex. Somewhat >> similar to the way that it is illegal to take aregular >> mutex while holding a spin mutex.. >> >> >> In netgraph I have a stipulation that is hard to specify which >> is that you MAY take a mutex in a netgraph node if you can guarantee >> that the mutex WILL be satisfied very quickly, but it'd >> be nice to be able to specify "you may only take 'leaf' mutexes within an >> netgraph node". >> >> >> thoughts? (especially from jhb and other locking types). >> >> >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >> From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 08:50:31 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9EDA106566B for ; Sun, 25 Jan 2009 08:50:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outu.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id D2BC28FC22 for ; Sun, 25 Jan 2009 08:50:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id BE12424D0; Sun, 25 Jan 2009 00:36:40 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 57A392D600E; Sun, 25 Jan 2009 00:36:40 -0800 (PST) Message-ID: <497C249C.5060507@elischer.org> Date: Sun, 25 Jan 2009 00:36:44 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Poul-Henning Kamp References: <23211.1232871523@critter.freebsd.dk> In-Reply-To: <23211.1232871523@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2009 08:50:32 -0000 Poul-Henning Kamp wrote: > In message <497BA91D.805@elischer.org>, Julian Elischer writes: > >> I would like to be able to add a flag to a mutex >> that tags it as a 'leaf' mutex. As a result it would be illegal >> to take any other mutex while holding a leaf mutex. > > I second that, even if the flag is purely documentary, it is a > good idea. > Even purely documentary would be good but given the option, I'd like it to scream when Witness is enabled and you try get another mutex.... there are certain contexts (e.g. in most netgraph nodes) where we really want the authors to only take such locks and taking more unpredictable mutexes plays havoc with netgraph response times as a system as a whole, since if one node blocks, teh thread doesn't get to go off and service other nodes. From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 09:11:54 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6731F1065675 for ; Sun, 25 Jan 2009 09:11:54 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 38D918FC1E for ; Sun, 25 Jan 2009 09:11:54 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5536350rvf.43 for ; Sun, 25 Jan 2009 01:11:53 -0800 (PST) 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:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=worrHFJ+m8UY8pQPxH+OucmlgoPtgl5WvN72Y5Ao7uw=; b=HpeYrZqndk8IcCCo1rOcF5uEtseTbUQfZzAH4OKnJmxzEen9petQGHWZHG0XHbIDLv Q1sNBCXkeUEDMffY6uDrO2YdivYlXAtOZIJzUNJI8LwXK9dHByScR1cqNoWoSsBwAzrw FW115YHPnqn1Ekpub5Gw6GznHcl3m2M235xOA= 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=sZX+y66n9yMbs6Aiig0QFkP3YZ7hesyO/VYOzH6fne6nf4Js95Iix+NUPPMeC5dmf2 sasGbw2Z4jJVKtUlRlMVaQXK3Ov1xd/gEWKERjLSJyBWITVXzy58+QFuqi5kkG0ZfqfJ F1g7q+aYm8XWx90Qo6Z1zvKdyUOFJM6gxGZUQ= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.141.82.20 with SMTP id j20mr920761rvl.190.1232874713721; Sun, 25 Jan 2009 01:11:53 -0800 (PST) In-Reply-To: <497C235E.5090807@elischer.org> References: <497BA91D.805@elischer.org> <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com> <497C235E.5090807@elischer.org> Date: Sun, 25 Jan 2009 09:11:53 +0000 X-Google-Sender-Auth: 25717fad44469c2e Message-ID: <3c1674c90901250111w34f9d016xb8e812cf46433970@mail.gmail.com> From: Kip Macy To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2009 09:11:54 -0000 On Sun, Jan 25, 2009 at 8:31 AM, Julian Elischer wrote: > Kip Macy wrote: >> >> The adaptive spinning of regular mutexes already satisfies your need >> for "short" hold. You might wish to add a thread flag used when >> INVARIANTS is enabled that is set when a leaf mutex is acquired and >> checked on all mutex acquisitions. > > ummm that was what I was asking for.. an official designation of a 'leaf' > mutex... uhm ... I was explaining a way to implement it without WITNESS. -Kip > >> >> -Kip >> >> On Sat, Jan 24, 2009 at 3:49 PM, Julian Elischer >> wrote: >>> >>> Currently we have: >>> spin locks.. >>> you really don't want to hold these for >>> any time at all, and this is enforced to some extent in the waiter. >>> >>> regular mutexes.. >>> You can hold these for as long as you want but teh shorter >>> the better and you can't sleep when holding them. The >>> "shortness" of the time of holding the mutex is not enforced. >>> >>> "Sleeps" (including sx-locks and friends) >>> You may hold these or be descheduled for really long periods of time. >>> >>> >>> Now it occurs to me that there is a subclass of regular mutexes, >>> usage, which is where you want to use a mutex to guard some small >>> but critical structure, and that you know that access to that structure >>> will >>> be quick, and that you can guarantee that you will >>> not acquire any other locks (which could introduce unknown delay) >>> while hoding the lock. >>> >>> One way of thinking about this is that this lock would always be >>> a leaf node on the tree of lock orders. >>> I would like to be able to add a flag to a mutex >>> that tags it as a 'leaf' mutex. As a result it would be illegal >>> to take any other mutex while holding a leaf mutex. Somewhat >>> similar to the way that it is illegal to take aregular >>> mutex while holding a spin mutex.. >>> >>> >>> In netgraph I have a stipulation that is hard to specify which >>> is that you MAY take a mutex in a netgraph node if you can guarantee >>> that the mutex WILL be satisfied very quickly, but it'd >>> be nice to be able to specify "you may only take 'leaf' mutexes within an >>> netgraph node". >>> >>> >>> thoughts? (especially from jhb and other locking types). >>> >>> >>> _______________________________________________ >>> freebsd-arch@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >>> > > From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 09:18:55 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B664106566C for ; Sun, 25 Jan 2009 09:18:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outo.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id 30DBE8FC08 for ; Sun, 25 Jan 2009 09:18:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 0B4BA24D0; Sun, 25 Jan 2009 01:18:55 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id A9E5F2D601A; Sun, 25 Jan 2009 01:18:54 -0800 (PST) Message-ID: <497C2E82.6010600@elischer.org> Date: Sun, 25 Jan 2009 01:18:58 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Jeff Roberson References: <497BA91D.805@elischer.org> <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com> <497C235E.5090807@elischer.org> <20090124224716.X983@desktop> In-Reply-To: <20090124224716.X983@desktop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Kip Macy Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2009 09:18:55 -0000 Jeff Roberson wrote: > On Sun, 25 Jan 2009, Julian Elischer wrote: > >> Kip Macy wrote: >>> The adaptive spinning of regular mutexes already satisfies your need >>> for "short" hold. You might wish to add a thread flag used when >>> INVARIANTS is enabled that is set when a leaf mutex is acquired and >>> checked on all mutex acquisitions. >> >> ummm that was what I was asking for.. an official designation of a >> 'leaf' mutex... > > It'd be much easier to add the flag as a mtx_init() flag and have > witness check it. It'd only take 15 minutes to do properly. more or less what I was suggesting. > > What is the case you have where you can not acquire non leaf mutexes? > An example is netgraph. In netgraph you have one (or a small number) thread which is processing on behalf of a number of nodes which may be doing work on behalf of completely different entities. If such a worker thread blocks then other work becomes starved.. A similar example might be made for geom I expect. If a worker thread blocks other work can be starved. Now you still in these modules need some way to synchronize between threads to protect local resources etc. So you still want to be able to use mutexes for this but you wnat to be able to tell the module author "yes you can use mutexes but you can't do so in a way that introduces any threat of undetirminsitic blocking". i.e. once you have mutex in your node, to do something, do it quickly and drop teh mutex, and do NOT go acquiring something that might sleep on us. I'm already worried about people getting mbufs etc in netgraph, and it may turn out that we are already hitting this without knowing it.. From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 09:20:40 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89B92106566C for ; Sun, 25 Jan 2009 09:20:40 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id 66FFA8FC1D for ; Sun, 25 Jan 2009 09:20:40 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by wa-out-1112.google.com with SMTP id k34so308086wah.27 for ; Sun, 25 Jan 2009 01:20:40 -0800 (PST) Received: by 10.115.14.1 with SMTP id r1mr916431wai.171.1232873499206; Sun, 25 Jan 2009 00:51:39 -0800 (PST) Received: from ?10.0.1.199? (udp005586uds.hawaiiantel.net [72.234.105.237]) by mx.google.com with ESMTPS id n22sm24113234pof.16.2009.01.25.00.51.36 (version=SSLv3 cipher=RC4-MD5); Sun, 25 Jan 2009 00:51:38 -0800 (PST) Date: Sat, 24 Jan 2009 22:49:01 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Julian Elischer In-Reply-To: <497C235E.5090807@elischer.org> Message-ID: <20090124224716.X983@desktop> References: <497BA91D.805@elischer.org> <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com> <497C235E.5090807@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Kip Macy Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2009 09:20:41 -0000 On Sun, 25 Jan 2009, Julian Elischer wrote: > Kip Macy wrote: >> The adaptive spinning of regular mutexes already satisfies your need >> for "short" hold. You might wish to add a thread flag used when >> INVARIANTS is enabled that is set when a leaf mutex is acquired and >> checked on all mutex acquisitions. > > ummm that was what I was asking for.. an official designation of a 'leaf' > mutex... It'd be much easier to add the flag as a mtx_init() flag and have witness check it. It'd only take 15 minutes to do properly. What is the case you have where you can not acquire non leaf mutexes? Thanks, Jeff > >> >> -Kip >> >> On Sat, Jan 24, 2009 at 3:49 PM, Julian Elischer >> wrote: >>> Currently we have: >>> spin locks.. >>> you really don't want to hold these for >>> any time at all, and this is enforced to some extent in the waiter. >>> >>> regular mutexes.. >>> You can hold these for as long as you want but teh shorter >>> the better and you can't sleep when holding them. The >>> "shortness" of the time of holding the mutex is not enforced. >>> >>> "Sleeps" (including sx-locks and friends) >>> You may hold these or be descheduled for really long periods of time. >>> >>> >>> Now it occurs to me that there is a subclass of regular mutexes, >>> usage, which is where you want to use a mutex to guard some small >>> but critical structure, and that you know that access to that structure >>> will >>> be quick, and that you can guarantee that you will >>> not acquire any other locks (which could introduce unknown delay) >>> while hoding the lock. >>> >>> One way of thinking about this is that this lock would always be >>> a leaf node on the tree of lock orders. >>> I would like to be able to add a flag to a mutex >>> that tags it as a 'leaf' mutex. As a result it would be illegal >>> to take any other mutex while holding a leaf mutex. Somewhat >>> similar to the way that it is illegal to take aregular >>> mutex while holding a spin mutex.. >>> >>> >>> In netgraph I have a stipulation that is hard to specify which >>> is that you MAY take a mutex in a netgraph node if you can guarantee >>> that the mutex WILL be satisfied very quickly, but it'd >>> be nice to be able to specify "you may only take 'leaf' mutexes within an >>> netgraph node". >>> >>> >>> thoughts? (especially from jhb and other locking types). >>> >>> >>> _______________________________________________ >>> freebsd-arch@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >>> > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 09:37:28 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 659C0106566C; Sun, 25 Jan 2009 09:37:28 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 465558FC13; Sun, 25 Jan 2009 09:37:28 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 7097A1A3C3B; Sun, 25 Jan 2009 01:28:38 -0800 (PST) Date: Sun, 25 Jan 2009 01:28:38 -0800 From: Alfred Perlstein To: Jeff Roberson Message-ID: <20090125092838.GC87077@elvis.mu.org> References: <497BA91D.805@elischer.org> <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com> <497C235E.5090807@elischer.org> <20090124224716.X983@desktop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090124224716.X983@desktop> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org, Julian Elischer , Kip Macy Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2009 09:37:28 -0000 * Jeff Roberson [090125 01:21] wrote: > On Sun, 25 Jan 2009, Julian Elischer wrote: > > >Kip Macy wrote: > >>The adaptive spinning of regular mutexes already satisfies your need > >>for "short" hold. You might wish to add a thread flag used when > >>INVARIANTS is enabled that is set when a leaf mutex is acquired and > >>checked on all mutex acquisitions. > > > >ummm that was what I was asking for.. an official designation of a 'leaf' > >mutex... > > It'd be much easier to add the flag as a mtx_init() flag and have witness > check it. It'd only take 15 minutes to do properly. > > What is the case you have where you can not acquire non leaf mutexes? Jeff, I think that Julian really wants to prevent a sleep inside his context. Right now, I think we only check for mutexes held before a sleep that arne't sleepable. It might make sense to allow one to just mark a thread non-sleepable even though no mutex is held. Julian, is that right? > > Thanks, > Jeff > > > > >> > >>-Kip > >> > >>On Sat, Jan 24, 2009 at 3:49 PM, Julian Elischer > >>wrote: > >>>Currently we have: > >>>spin locks.. > >>>you really don't want to hold these for > >>>any time at all, and this is enforced to some extent in the waiter. > >>> > >>>regular mutexes.. > >>>You can hold these for as long as you want but teh shorter > >>>the better and you can't sleep when holding them. The > >>>"shortness" of the time of holding the mutex is not enforced. > >>> > >>>"Sleeps" (including sx-locks and friends) > >>> You may hold these or be descheduled for really long periods of time. > >>> > >>> > >>>Now it occurs to me that there is a subclass of regular mutexes, > >>>usage, which is where you want to use a mutex to guard some small > >>>but critical structure, and that you know that access to that structure > >>>will > >>>be quick, and that you can guarantee that you will > >>>not acquire any other locks (which could introduce unknown delay) > >>>while hoding the lock. > >>> > >>>One way of thinking about this is that this lock would always be > >>>a leaf node on the tree of lock orders. > >>>I would like to be able to add a flag to a mutex > >>>that tags it as a 'leaf' mutex. As a result it would be illegal > >>>to take any other mutex while holding a leaf mutex. Somewhat > >>>similar to the way that it is illegal to take aregular > >>>mutex while holding a spin mutex.. > >>> > >>> > >>>In netgraph I have a stipulation that is hard to specify which > >>>is that you MAY take a mutex in a netgraph node if you can guarantee > >>>that the mutex WILL be satisfied very quickly, but it'd > >>>be nice to be able to specify "you may only take 'leaf' mutexes within an > >>>netgraph node". > >>> > >>> > >>>thoughts? (especially from jhb and other locking types). > >>> > >>> > >>>_______________________________________________ > >>>freebsd-arch@freebsd.org mailing list > >>>http://lists.freebsd.org/mailman/listinfo/freebsd-arch > >>>To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > >>> > > > >_______________________________________________ > >freebsd-arch@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-arch > >To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 09:42:28 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77B921065677; Sun, 25 Jan 2009 09:42:28 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6465A8FC1D; Sun, 25 Jan 2009 09:42:28 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 6EB2C1A3C39; Sun, 25 Jan 2009 01:27:12 -0800 (PST) Date: Sun, 25 Jan 2009 01:27:12 -0800 From: Alfred Perlstein To: Julian Elischer Message-ID: <20090125092712.GB87077@elvis.mu.org> References: <497BA91D.805@elischer.org> <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com> <497C235E.5090807@elischer.org> <20090124224716.X983@desktop> <497C2E82.6010600@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <497C2E82.6010600@elischer.org> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org, Kip Macy Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2009 09:42:28 -0000 * Julian Elischer [090125 01:19] wrote: > Jeff Roberson wrote: > >On Sun, 25 Jan 2009, Julian Elischer wrote: > > > >>Kip Macy wrote: > >>>The adaptive spinning of regular mutexes already satisfies your need > >>>for "short" hold. You might wish to add a thread flag used when > >>>INVARIANTS is enabled that is set when a leaf mutex is acquired and > >>>checked on all mutex acquisitions. > >> > >>ummm that was what I was asking for.. an official designation of a > >>'leaf' mutex... > > > >It'd be much easier to add the flag as a mtx_init() flag and have > >witness check it. It'd only take 15 minutes to do properly. > > more or less what I was suggesting. > > > > >What is the case you have where you can not acquire non leaf mutexes? > > > An example is netgraph. In netgraph you have one (or a small number) > thread which is processing on behalf of a number of nodes which may be > doing work on behalf of completely different entities. > If such a worker thread blocks then other work becomes starved.. > > A similar example might be made for geom I expect. If a worker thread > blocks other work can be starved. > > Now you still in these modules need some way to synchronize > between threads to protect local resources etc. So you still > want to be able to use mutexes for this but you wnat to be able to > tell the module author "yes you can use mutexes but you can't > do so in a way that introduces any threat of undetirminsitic blocking". > > i.e. once you have mutex in your node, to do something, do it quickly > and drop teh mutex, and do NOT go acquiring something that > might sleep on us. > > I'm already worried about people getting mbufs etc in netgraph, > and it may turn out that we are already hitting this without > knowing it.. You could probably easily add this to witness_warn, basically check a count in the thread that's recursive for not allowing sleeps. Currently, whenever a proceess would sleep, witness checks the list of locks that the thread holds for locks that shouldn't be slept on. You could pretty easily add a check here too. -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 09:43:43 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AABD91065675 for ; Sun, 25 Jan 2009 09:43:43 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 6ECFB8FC2A for ; Sun, 25 Jan 2009 09:43:43 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 7E8C51CE11; Sun, 25 Jan 2009 10:43:42 +0100 (CET) Date: Sun, 25 Jan 2009 10:43:42 +0100 From: Ed Schouten To: Julian Elischer Message-ID: <20090125094342.GD41248@hoeg.nl> References: <497BA91D.805@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YV7D9JCVdz8QpFLW" Content-Disposition: inline In-Reply-To: <497BA91D.805@elischer.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: arch@freebsd.org Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2009 09:43:44 -0000 --YV7D9JCVdz8QpFLW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Julian, I thought we already supported something like that. Isn't THREAD_NO_SLEEPING() and THREAD_SLEEPING_OK() exactly what you describe? --=20 Ed Schouten WWW: http://80386.nl/ --YV7D9JCVdz8QpFLW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkl8NE4ACgkQ52SDGA2eCwW/1wCeO9Dn5CviMB5YLOuYXnXOiZca +5EAnAvCMssHZvvzAOCOVyp8KIaH+0WN =6cyJ -----END PGP SIGNATURE----- --YV7D9JCVdz8QpFLW-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 09:49:02 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F55A106566C for ; Sun, 25 Jan 2009 09:49:02 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id DA1988FC14 for ; Sun, 25 Jan 2009 09:49:01 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 14F4A1CC25; Sun, 25 Jan 2009 10:49:01 +0100 (CET) Date: Sun, 25 Jan 2009 10:49:01 +0100 From: Ed Schouten To: Julian Elischer Message-ID: <20090125094901.GE41248@hoeg.nl> References: <497BA91D.805@elischer.org> <20090125094342.GD41248@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nG7dHWd/DOCuxGWF" Content-Disposition: inline In-Reply-To: <20090125094342.GD41248@hoeg.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: arch@freebsd.org Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2009 09:49:02 -0000 --nG7dHWd/DOCuxGWF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Ed Schouten wrote: > I thought we already supported something like that. Isn't > THREAD_NO_SLEEPING() and THREAD_SLEEPING_OK() exactly what you describe? Oh wait, never mind. That only prevents a thread from sleeping on a sleepqueue. --=20 Ed Schouten WWW: http://80386.nl/ --nG7dHWd/DOCuxGWF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkl8NYwACgkQ52SDGA2eCwUNMwCfW1YyQDMxOkk371gW0Nh9Wy3G iKQAnAv47Uq580sP6EbthCOCftLHNOdm =WAD6 -----END PGP SIGNATURE----- --nG7dHWd/DOCuxGWF-- From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 06:53:41 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 956981065674 for ; Mon, 26 Jan 2009 06:53:41 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outX.internet-mail-service.net (outx.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id 7786D8FC19 for ; Mon, 26 Jan 2009 06:53:41 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id A34FE24AC; Sun, 25 Jan 2009 22:53:41 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id B19B32D6017; Sun, 25 Jan 2009 22:53:40 -0800 (PST) Message-ID: <497D5DF8.8000706@elischer.org> Date: Sun, 25 Jan 2009 22:53:44 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Alfred Perlstein References: <497BA91D.805@elischer.org> <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com> <497C235E.5090807@elischer.org> <20090124224716.X983@desktop> <20090125092838.GC87077@elvis.mu.org> In-Reply-To: <20090125092838.GC87077@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Kip Macy Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2009 06:53:41 -0000 Alfred Perlstein wrote: > * Jeff Roberson [090125 01:21] wrote: >> On Sun, 25 Jan 2009, Julian Elischer wrote: >> >>> Kip Macy wrote: >>>> The adaptive spinning of regular mutexes already satisfies your need >>>> for "short" hold. You might wish to add a thread flag used when >>>> INVARIANTS is enabled that is set when a leaf mutex is acquired and >>>> checked on all mutex acquisitions. >>> ummm that was what I was asking for.. an official designation of a 'leaf' >>> mutex... >> It'd be much easier to add the flag as a mtx_init() flag and have witness >> check it. It'd only take 15 minutes to do properly. >> >> What is the case you have where you can not acquire non leaf mutexes? > > Jeff, I think that Julian really wants to prevent a sleep inside > his context. Right now, I think we only check for mutexes held > before a sleep that arne't sleepable. It might make sense to allow > one to just mark a thread non-sleepable even though no mutex is > held. > > Julian, is that right? basically, though I don't know the details of implementation.. I just know that mutexes per se aren't bad for netgraph but that node authors need some guidance on how to use them and some way to prove to them when they do the wrong thing. > >> Thanks, >> Jeff >> >>>> -Kip >>>> >>>> On Sat, Jan 24, 2009 at 3:49 PM, Julian Elischer >>>> wrote: >>>>> Currently we have: >>>>> spin locks.. >>>>> you really don't want to hold these for >>>>> any time at all, and this is enforced to some extent in the waiter. >>>>> >>>>> regular mutexes.. >>>>> You can hold these for as long as you want but teh shorter >>>>> the better and you can't sleep when holding them. The >>>>> "shortness" of the time of holding the mutex is not enforced. >>>>> >>>>> "Sleeps" (including sx-locks and friends) >>>>> You may hold these or be descheduled for really long periods of time. >>>>> >>>>> >>>>> Now it occurs to me that there is a subclass of regular mutexes, >>>>> usage, which is where you want to use a mutex to guard some small >>>>> but critical structure, and that you know that access to that structure >>>>> will >>>>> be quick, and that you can guarantee that you will >>>>> not acquire any other locks (which could introduce unknown delay) >>>>> while hoding the lock. >>>>> >>>>> One way of thinking about this is that this lock would always be >>>>> a leaf node on the tree of lock orders. >>>>> I would like to be able to add a flag to a mutex >>>>> that tags it as a 'leaf' mutex. As a result it would be illegal >>>>> to take any other mutex while holding a leaf mutex. Somewhat >>>>> similar to the way that it is illegal to take aregular >>>>> mutex while holding a spin mutex.. >>>>> >>>>> >>>>> In netgraph I have a stipulation that is hard to specify which >>>>> is that you MAY take a mutex in a netgraph node if you can guarantee >>>>> that the mutex WILL be satisfied very quickly, but it'd >>>>> be nice to be able to specify "you may only take 'leaf' mutexes within an >>>>> netgraph node". >>>>> >>>>> >>>>> thoughts? (especially from jhb and other locking types). >>>>> >>>>> >>>>> _______________________________________________ >>>>> freebsd-arch@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >>>>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >>>>> >>> _______________________________________________ >>> freebsd-arch@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >>> >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 10:51:41 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 174491065670; Mon, 26 Jan 2009 10:51:41 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 02EEA8FC12; Mon, 26 Jan 2009 10:51:40 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id E578D1A3C39; Mon, 26 Jan 2009 02:51:40 -0800 (PST) Date: Mon, 26 Jan 2009 02:51:40 -0800 From: Alfred Perlstein To: Julian Elischer Message-ID: <20090126105140.GL5889@elvis.mu.org> References: <497BA91D.805@elischer.org> <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com> <497C235E.5090807@elischer.org> <20090124224716.X983@desktop> <20090125092838.GC87077@elvis.mu.org> <497D5DF8.8000706@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <497D5DF8.8000706@elischer.org> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org, Kip Macy Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2009 10:51:41 -0000 * Julian Elischer [090125 22:53] wrote: > Alfred Perlstein wrote: > > > >Jeff, I think that Julian really wants to prevent a sleep inside > >his context. Right now, I think we only check for mutexes held > >before a sleep that arne't sleepable. It might make sense to allow > >one to just mark a thread non-sleepable even though no mutex is > >held. > > > >Julian, is that right? > > basically, though I don't know the details of implementation.. > I just know that mutexes per se aren't bad for netgraph but > that node authors need some guidance on how to use them and > some way to prove to them when they do the wrong thing. The way to add the assertion you want would be to keep a count inside of the thread structure "td_nosleep", set to 0 at thread creation, then you can do this: TD_SLEEP_NO(td); /* td->td_nosleep++ */ call_some_untrusted_code(); TD_SLEEP_OK(td); /* td->td_nosleep-- */ Then add this to subr_witness.c:witness_warn(): if (flags & WARN_SLEEPOK && td->td_nosleep != 0) { printf("Sleeping in unsleepable context.\n"); n++; /* this variable is local to witness_warn() and triggers an ASSERT at the end */ } I could have sworn we already had such a feature, but it appears that it's only accessable if you're holding a lock, if you added this counter, then you could catch sleeps without needing a lock held. -Alfred From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 11:06:53 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65996106564A for ; Mon, 26 Jan 2009 11:06:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 380A18FC14 for ; Mon, 26 Jan 2009 11:06:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0QB6rWk024203 for ; Mon, 26 Jan 2009 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0QB6qdV024199 for freebsd-arch@FreeBSD.org; Mon, 26 Jan 2009 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Jan 2009 11:06:52 GMT Message-Id: <200901261106.n0QB6qdV024199@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2009 11:06:53 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 14:58:32 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DADBF1065761; Mon, 26 Jan 2009 14:58:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A97758FC2A; Mon, 26 Jan 2009 14:58:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 3BDA246B0C; Mon, 26 Jan 2009 09:58:32 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0QEw2xv078018; Mon, 26 Jan 2009 09:58:25 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Mon, 26 Jan 2009 09:36:17 -0500 User-Agent: KMail/1.9.7 References: <497BA91D.805@elischer.org> <497D5DF8.8000706@elischer.org> <20090126105140.GL5889@elvis.mu.org> In-Reply-To: <20090126105140.GL5889@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901260936.18232.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 26 Jan 2009 09:58:26 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8904/Mon Jan 26 08:06:06 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arch@freebsd.org, Alfred Perlstein , Julian Elischer , Kip Macy Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2009 14:58:33 -0000 On Monday 26 January 2009 5:51:40 am Alfred Perlstein wrote: > * Julian Elischer [090125 22:53] wrote: > > Alfred Perlstein wrote: > > > > > >Jeff, I think that Julian really wants to prevent a sleep inside > > >his context. Right now, I think we only check for mutexes held > > >before a sleep that arne't sleepable. It might make sense to allow > > >one to just mark a thread non-sleepable even though no mutex is > > >held. > > > > > >Julian, is that right? > > > > basically, though I don't know the details of implementation.. > > I just know that mutexes per se aren't bad for netgraph but > > that node authors need some guidance on how to use them and > > some way to prove to them when they do the wrong thing. > > The way to add the assertion you want would be to keep a count > inside of the thread structure "td_nosleep", set to 0 at thread > creation, then you can do this: > > TD_SLEEP_NO(td); /* td->td_nosleep++ */ > call_some_untrusted_code(); > TD_SLEEP_OK(td); /* td->td_nosleep-- */ > > Then add this to subr_witness.c:witness_warn(): > > if (flags & WARN_SLEEPOK && td->td_nosleep != 0) { > printf("Sleeping in unsleepable context.\n"); > n++; /* this variable is local to witness_warn() > and triggers an ASSERT at the end */ > } > > I could have sworn we already had such a feature, but it appears > that it's only accessable if you're holding a lock, if you added > this counter, then you could catch sleeps without needing a lock > held. We have this feature already for sleeping, but I think Julian isn't worried about sleeping (i.e. *sleep() or cv_*wait*()), but wants to prevent the code from acquiring any other locks. It's easy to add a MTX_LEAF, I'm just not sure if we really want to micro-manage the code that much. WITNESS will already catch any LORs, and if they are acquiring a rarely-contested lock then they aren't going to back up traffic in the common case. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 14:58:32 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DADBF1065761; Mon, 26 Jan 2009 14:58:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A97758FC2A; Mon, 26 Jan 2009 14:58:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 3BDA246B0C; Mon, 26 Jan 2009 09:58:32 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0QEw2xv078018; Mon, 26 Jan 2009 09:58:25 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Mon, 26 Jan 2009 09:36:17 -0500 User-Agent: KMail/1.9.7 References: <497BA91D.805@elischer.org> <497D5DF8.8000706@elischer.org> <20090126105140.GL5889@elvis.mu.org> In-Reply-To: <20090126105140.GL5889@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901260936.18232.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 26 Jan 2009 09:58:26 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8904/Mon Jan 26 08:06:06 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arch@freebsd.org, Alfred Perlstein , Julian Elischer , Kip Macy Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2009 14:58:33 -0000 On Monday 26 January 2009 5:51:40 am Alfred Perlstein wrote: > * Julian Elischer [090125 22:53] wrote: > > Alfred Perlstein wrote: > > > > > >Jeff, I think that Julian really wants to prevent a sleep inside > > >his context. Right now, I think we only check for mutexes held > > >before a sleep that arne't sleepable. It might make sense to allow > > >one to just mark a thread non-sleepable even though no mutex is > > >held. > > > > > >Julian, is that right? > > > > basically, though I don't know the details of implementation.. > > I just know that mutexes per se aren't bad for netgraph but > > that node authors need some guidance on how to use them and > > some way to prove to them when they do the wrong thing. > > The way to add the assertion you want would be to keep a count > inside of the thread structure "td_nosleep", set to 0 at thread > creation, then you can do this: > > TD_SLEEP_NO(td); /* td->td_nosleep++ */ > call_some_untrusted_code(); > TD_SLEEP_OK(td); /* td->td_nosleep-- */ > > Then add this to subr_witness.c:witness_warn(): > > if (flags & WARN_SLEEPOK && td->td_nosleep != 0) { > printf("Sleeping in unsleepable context.\n"); > n++; /* this variable is local to witness_warn() > and triggers an ASSERT at the end */ > } > > I could have sworn we already had such a feature, but it appears > that it's only accessable if you're holding a lock, if you added > this counter, then you could catch sleeps without needing a lock > held. We have this feature already for sleeping, but I think Julian isn't worried about sleeping (i.e. *sleep() or cv_*wait*()), but wants to prevent the code from acquiring any other locks. It's easy to add a MTX_LEAF, I'm just not sure if we really want to micro-manage the code that much. WITNESS will already catch any LORs, and if they are acquiring a rarely-contested lock then they aren't going to back up traffic in the common case. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 14:58:41 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AB3A1065752 for ; Mon, 26 Jan 2009 14:58:41 +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 979918FC1D for ; Mon, 26 Jan 2009 14:58:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 1F94346B3B for ; Mon, 26 Jan 2009 09:58:38 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0QEw2xw078018 for ; Mon, 26 Jan 2009 09:58:31 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: arch@freebsd.org Date: Mon, 26 Jan 2009 09:47:32 -0500 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901260947.32870.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 26 Jan 2009 09:58:32 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8904/Mon Jan 26 08:06:06 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2009 14:58:45 -0000 After the changes to make hints always reserve device names, soem folks ran into issues with devices changing names due to previously unused hints now always being honored (e.g. hints for non-existent ISA le(4) cards always reserving le0). What I would like to do to help minimize this further is to trim the default set of hints. The number of machines that will run 8.0 that have ISA slots is incredibly small, probably zero. To that end, I would like to remove all hints for ISA adapters from i386 and amd64 (amd64 already has most of them removed). Also, the hint for vga0 is not needed as the vga_isa driver uses an identify routine to always add itself. Note that end-users can always add hints back later if desired/needed. However, changing the defaults means that some hardware may no longer work out of the box. My guess though is that the set of such hardware is the empty set. If we wanted, we could go further and assume that all machines have either PnPBIOS or ACPI and remove most of the other hints as well. We already sort of assume that on amd64 (which has no atrtc0 hints, but still has hints for fdc0, ppc0, and some other devices). Here is the proposed diff: --- //depot/user/jhb/acpipci/amd64/conf/GENERIC.hints +++ /home/jhb/work/p4/acpipci/amd64/conf/GENERIC.hints @@ -13,7 +13,6 @@ hint.atkbd.0.irq="1" hint.psm.0.at="atkbdc" hint.psm.0.irq="12" -hint.vga.0.at="isa" hint.sc.0.at="isa" hint.sc.0.flags="0x100" hint.uart.0.at="isa" @@ -23,13 +22,5 @@ hint.uart.1.at="isa" hint.uart.1.port="0x2F8" hint.uart.1.irq="3" -hint.uart.2.at="isa" -hint.uart.2.disabled="1" -hint.uart.2.port="0x3E8" -hint.uart.2.irq="5" -hint.uart.3.at="isa" -hint.uart.3.disabled="1" -hint.uart.3.port="0x2E8" -hint.uart.3.irq="9" hint.ppc.0.at="isa" hint.ppc.0.irq="7" --- //depot/user/jhb/acpipci/i386/conf/GENERIC.hints +++ /home/jhb/work/p4/acpipci/i386/conf/GENERIC.hints @@ -13,21 +13,12 @@ hint.ata.1.at="isa" hint.ata.1.port="0x170" hint.ata.1.irq="15" -hint.adv.0.at="isa" -hint.adv.0.disabled="1" -hint.bt.0.at="isa" -hint.bt.0.disabled="1" -hint.aha.0.at="isa" -hint.aha.0.disabled="1" -hint.aic.0.at="isa" -hint.aic.0.disabled="1" hint.atkbdc.0.at="isa" hint.atkbdc.0.port="0x060" hint.atkbd.0.at="atkbdc" hint.atkbd.0.irq="1" hint.psm.0.at="atkbdc" hint.psm.0.irq="12" -hint.vga.0.at="isa" hint.sc.0.at="isa" hint.sc.0.flags="0x100" hint.apm.0.disabled="1" @@ -39,41 +30,8 @@ hint.uart.1.at="isa" hint.uart.1.port="0x2F8" hint.uart.1.irq="3" -hint.uart.2.at="isa" -hint.uart.2.disabled="1" -hint.uart.2.port="0x3E8" -hint.uart.2.irq="5" -hint.uart.3.at="isa" -hint.uart.3.disabled="1" -hint.uart.3.port="0x2E8" -hint.uart.3.irq="9" hint.ppc.0.at="isa" hint.ppc.0.irq="7" -hint.ed.0.at="isa" -hint.ed.0.disabled="1" -hint.ed.0.port="0x280" -hint.ed.0.irq="10" -hint.ed.0.maddr="0xd8000" -hint.cs.0.at="isa" -hint.cs.0.disabled="1" -hint.cs.0.port="0x300" -hint.sn.0.at="isa" -hint.sn.0.disabled="1" -hint.sn.0.port="0x300" -hint.sn.0.irq="10" -hint.ie.0.at="isa" -hint.ie.0.disabled="1" -hint.ie.0.port="0x300" -hint.ie.0.irq="10" -hint.ie.0.maddr="0xd0000" -hint.fe.0.at="isa" -hint.fe.0.disabled="1" -hint.fe.0.port="0x300" -hint.le.0.at="isa" -hint.le.0.disabled="1" -hint.le.0.port="0x280" -hint.le.0.irq="10" -hint.le.0.drq="0" hint.atrtc.0.at="isa" hint.atrtc.0.port="0x70" hint.atrtc.0.irq="8" -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 15:31:39 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F159A106568D; Mon, 26 Jan 2009 15:31:39 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx1.rink.nu (gloom.rink.nu [213.34.49.2]) by mx1.freebsd.org (Postfix) with ESMTP id B24278FC1A; Mon, 26 Jan 2009 15:31:39 +0000 (UTC) (envelope-from rink@rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id 45ECC6D41A; Mon, 26 Jan 2009 16:16:02 +0100 (CET) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.2]) by localhost (gloom.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsGCwYJQqfDT; Mon, 26 Jan 2009 16:15:58 +0100 (CET) Received: by mx1.rink.nu (Postfix, from userid 1000) id DBD1C6D439; Mon, 26 Jan 2009 16:15:58 +0100 (CET) Date: Mon, 26 Jan 2009 16:15:58 +0100 From: Rink Springer To: John Baldwin Message-ID: <20090126151558.GA41388@rink.nu> References: <200901260947.32870.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200901260947.32870.jhb@freebsd.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2009 15:31:40 -0000 On Mon, Jan 26, 2009 at 09:47:32AM -0500, John Baldwin wrote: > If we wanted, we could go further and assume that all machines have either > PnPBIOS or ACPI and remove most of the other hints as well. We already sort > of assume that on amd64 (which has no atrtc0 hints, but still has hints for > fdc0, ppc0, and some other devices). > > Here is the proposed diff: This diff makes sense to me - besides, it's always possible to enter the hints at the loader prompt if desired to get a device to work and adding that to a local loader.conf later; I don't think these defaults are worth the clutter since almost nobody probably has these devices anyway... Regards, -- Rink P.W. Springer - http://rink.nu "Chance favours the prepared mind" - Penn From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 18:05:19 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30C6B10656F0 for ; Mon, 26 Jan 2009 18:05:19 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outJ.internet-mail-service.net (outj.internet-mail-service.net [216.240.47.233]) by mx1.freebsd.org (Postfix) with ESMTP id 0DFFA8FC21 for ; Mon, 26 Jan 2009 18:05:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 8485424E3; Mon, 26 Jan 2009 10:05:18 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 9919C2D6025; Mon, 26 Jan 2009 10:05:17 -0800 (PST) Message-ID: <497DFB61.1010602@elischer.org> Date: Mon, 26 Jan 2009 10:05:21 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: John Baldwin References: <497BA91D.805@elischer.org> <497D5DF8.8000706@elischer.org> <20090126105140.GL5889@elvis.mu.org> <200901260936.18232.jhb@freebsd.org> In-Reply-To: <200901260936.18232.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Alfred Perlstein , Kip Macy , freebsd-arch@freebsd.org Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2009 18:05:21 -0000 John Baldwin wrote: > On Monday 26 January 2009 5:51:40 am Alfred Perlstein wrote: >> * Julian Elischer [090125 22:53] wrote: >>> Alfred Perlstein wrote: >>>> Jeff, I think that Julian really wants to prevent a sleep inside >>>> his context. Right now, I think we only check for mutexes held >>>> before a sleep that arne't sleepable. It might make sense to allow >>>> one to just mark a thread non-sleepable even though no mutex is >>>> held. >>>> >>>> Julian, is that right? >>> basically, though I don't know the details of implementation.. >>> I just know that mutexes per se aren't bad for netgraph but >>> that node authors need some guidance on how to use them and >>> some way to prove to them when they do the wrong thing. >> The way to add the assertion you want would be to keep a count >> inside of the thread structure "td_nosleep", set to 0 at thread >> creation, then you can do this: >> >> TD_SLEEP_NO(td); /* td->td_nosleep++ */ >> call_some_untrusted_code(); >> TD_SLEEP_OK(td); /* td->td_nosleep-- */ >> >> Then add this to subr_witness.c:witness_warn(): >> >> if (flags & WARN_SLEEPOK && td->td_nosleep != 0) { >> printf("Sleeping in unsleepable context.\n"); >> n++; /* this variable is local to witness_warn() >> and triggers an ASSERT at the end */ >> } >> >> I could have sworn we already had such a feature, but it appears >> that it's only accessable if you're holding a lock, if you added >> this counter, then you could catch sleeps without needing a lock >> held. > > We have this feature already for sleeping, but I think Julian isn't worried > about sleeping (i.e. *sleep() or cv_*wait*()), but wants to prevent the code > from acquiring any other locks. It's easy to add a MTX_LEAF, I'm just not > sure if we really want to micro-manage the code that much. WITNESS will > already catch any LORs, and if they are acquiring a rarely-contested lock > then they aren't going to back up traffic in the common case. > maybe what I want is to be able to label a lock as "fleeting" By which I mean that the work that would be done while holding this lock would be fleeting (momentary) in nature. An example f a fleeting lock would be something that gains the lock in order to safely switch two pointers. no malloc is required and nothing is going to take a long time. locks that are NOT momentary include holding the process list lock while allocating a large buffer (series of them) and dumping the contents of all processes and things like that. one might almost say that a fleeting lock might be gotten while holding another fleeting lock, but that is pushing it for me.. From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 18:15:33 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69A1E10656D6 for ; Mon, 26 Jan 2009 18:15:33 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outg.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id 49CC58FC12 for ; Mon, 26 Jan 2009 18:15:33 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 8485424E3; Mon, 26 Jan 2009 10:05:18 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 9919C2D6025; Mon, 26 Jan 2009 10:05:17 -0800 (PST) Message-ID: <497DFB61.1010602@elischer.org> Date: Mon, 26 Jan 2009 10:05:21 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: John Baldwin References: <497BA91D.805@elischer.org> <497D5DF8.8000706@elischer.org> <20090126105140.GL5889@elvis.mu.org> <200901260936.18232.jhb@freebsd.org> In-Reply-To: <200901260936.18232.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Alfred Perlstein , Kip Macy , freebsd-arch@freebsd.org Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2009 18:15:34 -0000 John Baldwin wrote: > On Monday 26 January 2009 5:51:40 am Alfred Perlstein wrote: >> * Julian Elischer [090125 22:53] wrote: >>> Alfred Perlstein wrote: >>>> Jeff, I think that Julian really wants to prevent a sleep inside >>>> his context. Right now, I think we only check for mutexes held >>>> before a sleep that arne't sleepable. It might make sense to allow >>>> one to just mark a thread non-sleepable even though no mutex is >>>> held. >>>> >>>> Julian, is that right? >>> basically, though I don't know the details of implementation.. >>> I just know that mutexes per se aren't bad for netgraph but >>> that node authors need some guidance on how to use them and >>> some way to prove to them when they do the wrong thing. >> The way to add the assertion you want would be to keep a count >> inside of the thread structure "td_nosleep", set to 0 at thread >> creation, then you can do this: >> >> TD_SLEEP_NO(td); /* td->td_nosleep++ */ >> call_some_untrusted_code(); >> TD_SLEEP_OK(td); /* td->td_nosleep-- */ >> >> Then add this to subr_witness.c:witness_warn(): >> >> if (flags & WARN_SLEEPOK && td->td_nosleep != 0) { >> printf("Sleeping in unsleepable context.\n"); >> n++; /* this variable is local to witness_warn() >> and triggers an ASSERT at the end */ >> } >> >> I could have sworn we already had such a feature, but it appears >> that it's only accessable if you're holding a lock, if you added >> this counter, then you could catch sleeps without needing a lock >> held. > > We have this feature already for sleeping, but I think Julian isn't worried > about sleeping (i.e. *sleep() or cv_*wait*()), but wants to prevent the code > from acquiring any other locks. It's easy to add a MTX_LEAF, I'm just not > sure if we really want to micro-manage the code that much. WITNESS will > already catch any LORs, and if they are acquiring a rarely-contested lock > then they aren't going to back up traffic in the common case. > maybe what I want is to be able to label a lock as "fleeting" By which I mean that the work that would be done while holding this lock would be fleeting (momentary) in nature. An example f a fleeting lock would be something that gains the lock in order to safely switch two pointers. no malloc is required and nothing is going to take a long time. locks that are NOT momentary include holding the process list lock while allocating a large buffer (series of them) and dumping the contents of all processes and things like that. one might almost say that a fleeting lock might be gotten while holding another fleeting lock, but that is pushing it for me.. From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 20:38:24 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D5D6106566B for ; Mon, 26 Jan 2009 20:38:24 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6D6BF8FC08 for ; Mon, 26 Jan 2009 20:38:24 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 5D07E1A3C39; Mon, 26 Jan 2009 12:38:24 -0800 (PST) Date: Mon, 26 Jan 2009 12:38:24 -0800 From: Alfred Perlstein To: John Baldwin Message-ID: <20090126203824.GO5889@elvis.mu.org> References: <200901260947.32870.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200901260947.32870.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2009 20:38:24 -0000 There's no way to conditionally include them based on if ISA is present? * John Baldwin [090126 06:59] wrote: > After the changes to make hints always reserve device names, soem folks ran > into issues with devices changing names due to previously unused hints now > always being honored (e.g. hints for non-existent ISA le(4) cards always > reserving le0). What I would like to do to help minimize this further is to > trim the default set of hints. The number of machines that will run 8.0 that > have ISA slots is incredibly small, probably zero. To that end, I would like > to remove all hints for ISA adapters from i386 and amd64 (amd64 already has > most of them removed). Also, the hint for vga0 is not needed as the vga_isa > driver uses an identify routine to always add itself. Note that end-users > can always add hints back later if desired/needed. However, changing the > defaults means that some hardware may no longer work out of the box. My > guess though is that the set of such hardware is the empty set. > > If we wanted, we could go further and assume that all machines have either > PnPBIOS or ACPI and remove most of the other hints as well. We already sort > of assume that on amd64 (which has no atrtc0 hints, but still has hints for > fdc0, ppc0, and some other devices). > > Here is the proposed diff: > > --- //depot/user/jhb/acpipci/amd64/conf/GENERIC.hints > +++ /home/jhb/work/p4/acpipci/amd64/conf/GENERIC.hints > @@ -13,7 +13,6 @@ > hint.atkbd.0.irq="1" > hint.psm.0.at="atkbdc" > hint.psm.0.irq="12" > -hint.vga.0.at="isa" > hint.sc.0.at="isa" > hint.sc.0.flags="0x100" > hint.uart.0.at="isa" > @@ -23,13 +22,5 @@ > hint.uart.1.at="isa" > hint.uart.1.port="0x2F8" > hint.uart.1.irq="3" > -hint.uart.2.at="isa" > -hint.uart.2.disabled="1" > -hint.uart.2.port="0x3E8" > -hint.uart.2.irq="5" > -hint.uart.3.at="isa" > -hint.uart.3.disabled="1" > -hint.uart.3.port="0x2E8" > -hint.uart.3.irq="9" > hint.ppc.0.at="isa" > hint.ppc.0.irq="7" > --- //depot/user/jhb/acpipci/i386/conf/GENERIC.hints > +++ /home/jhb/work/p4/acpipci/i386/conf/GENERIC.hints > @@ -13,21 +13,12 @@ > hint.ata.1.at="isa" > hint.ata.1.port="0x170" > hint.ata.1.irq="15" > -hint.adv.0.at="isa" > -hint.adv.0.disabled="1" > -hint.bt.0.at="isa" > -hint.bt.0.disabled="1" > -hint.aha.0.at="isa" > -hint.aha.0.disabled="1" > -hint.aic.0.at="isa" > -hint.aic.0.disabled="1" > hint.atkbdc.0.at="isa" > hint.atkbdc.0.port="0x060" > hint.atkbd.0.at="atkbdc" > hint.atkbd.0.irq="1" > hint.psm.0.at="atkbdc" > hint.psm.0.irq="12" > -hint.vga.0.at="isa" > hint.sc.0.at="isa" > hint.sc.0.flags="0x100" > hint.apm.0.disabled="1" > @@ -39,41 +30,8 @@ > hint.uart.1.at="isa" > hint.uart.1.port="0x2F8" > hint.uart.1.irq="3" > -hint.uart.2.at="isa" > -hint.uart.2.disabled="1" > -hint.uart.2.port="0x3E8" > -hint.uart.2.irq="5" > -hint.uart.3.at="isa" > -hint.uart.3.disabled="1" > -hint.uart.3.port="0x2E8" > -hint.uart.3.irq="9" > hint.ppc.0.at="isa" > hint.ppc.0.irq="7" > -hint.ed.0.at="isa" > -hint.ed.0.disabled="1" > -hint.ed.0.port="0x280" > -hint.ed.0.irq="10" > -hint.ed.0.maddr="0xd8000" > -hint.cs.0.at="isa" > -hint.cs.0.disabled="1" > -hint.cs.0.port="0x300" > -hint.sn.0.at="isa" > -hint.sn.0.disabled="1" > -hint.sn.0.port="0x300" > -hint.sn.0.irq="10" > -hint.ie.0.at="isa" > -hint.ie.0.disabled="1" > -hint.ie.0.port="0x300" > -hint.ie.0.irq="10" > -hint.ie.0.maddr="0xd0000" > -hint.fe.0.at="isa" > -hint.fe.0.disabled="1" > -hint.fe.0.port="0x300" > -hint.le.0.at="isa" > -hint.le.0.disabled="1" > -hint.le.0.port="0x280" > -hint.le.0.irq="10" > -hint.le.0.drq="0" > hint.atrtc.0.at="isa" > hint.atrtc.0.port="0x70" > hint.atrtc.0.irq="8" > > > -- > John Baldwin > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 21:57:26 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AA9E1065674; Mon, 26 Jan 2009 21:57:26 +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 1D7758FC08; Mon, 26 Jan 2009 21:57:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id A9D3946B0C; Mon, 26 Jan 2009 16:57:25 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0QLvJk9080649; Mon, 26 Jan 2009 16:57:19 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Alfred Perlstein Date: Mon, 26 Jan 2009 16:40:59 -0500 User-Agent: KMail/1.9.7 References: <200901260947.32870.jhb@freebsd.org> <20090126203824.GO5889@elvis.mu.org> In-Reply-To: <20090126203824.GO5889@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901261640.59239.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 26 Jan 2009 16:57:20 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8905/Mon Jan 26 12:29:36 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2009 21:57:26 -0000 On Monday 26 January 2009 3:38:24 pm Alfred Perlstein wrote: > There's no way to conditionally include them based on if > ISA is present? No, but I dare you to show me a box with ISA expansion slots that you plan to run 8.0 on. :) Or rather, I dare you to show me _enough_ of said boxes to where removing these hints from the default set will inconvenience more users than the folks having their ethernet come up as le1 in vmware guests. :) -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 22:02:30 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47F891065690; Mon, 26 Jan 2009 22:02:30 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2FF148FC1B; Mon, 26 Jan 2009 22:02:30 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id E46F31A3C39; Mon, 26 Jan 2009 14:02:29 -0800 (PST) Date: Mon, 26 Jan 2009 14:02:29 -0800 From: Alfred Perlstein To: John Baldwin Message-ID: <20090126220229.GR5889@elvis.mu.org> References: <200901260947.32870.jhb@freebsd.org> <20090126203824.GO5889@elvis.mu.org> <200901261640.59239.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200901261640.59239.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2009 22:02:42 -0000 * John Baldwin [090126 13:57] wrote: > On Monday 26 January 2009 3:38:24 pm Alfred Perlstein wrote: > > There's no way to conditionally include them based on if > > ISA is present? > > No, but I dare you to show me a box with ISA expansion slots that you plan to > run 8.0 on. :) Or rather, I dare you to show me _enough_ of said boxes to > where removing these hints from the default set will inconvenience more users > than the folks having their ethernet come up as le1 in vmware guests. :) I agree with you, I was just wondering if it was just a matter of a few lines of code somehow so that some enthusiast who wants to play with FreeBSD on some old piece of junk doesn't get some cryptic error that sort of reduces them to "toggling in load.conf tunables at the console". :) no big deal. -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 22:36:56 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AED91065742; Mon, 26 Jan 2009 22:36:56 +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 4CA478FC19; Mon, 26 Jan 2009 22:36:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id E93B246B43; Mon, 26 Jan 2009 17:36:55 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0QMaimR080872; Mon, 26 Jan 2009 17:36:50 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Alfred Perlstein Date: Mon, 26 Jan 2009 17:36:32 -0500 User-Agent: KMail/1.9.7 References: <200901260947.32870.jhb@freebsd.org> <200901261640.59239.jhb@freebsd.org> <20090126220229.GR5889@elvis.mu.org> In-Reply-To: <20090126220229.GR5889@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901261736.32442.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 26 Jan 2009 17:36:50 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8905/Mon Jan 26 12:29:36 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2009 22:36:57 -0000 On Monday 26 January 2009 5:02:29 pm Alfred Perlstein wrote: > * John Baldwin [090126 13:57] wrote: > > On Monday 26 January 2009 3:38:24 pm Alfred Perlstein wrote: > > > There's no way to conditionally include them based on if > > > ISA is present? > > > > No, but I dare you to show me a box with ISA expansion slots that you plan to > > run 8.0 on. :) Or rather, I dare you to show me _enough_ of said boxes to > > where removing these hints from the default set will inconvenience more users > > than the folks having their ethernet come up as le1 in vmware guests. :) > > I agree with you, I was just wondering if it was just a matter of > a few lines of code somehow so that some enthusiast who wants to play > with FreeBSD on some old piece of junk doesn't get some cryptic > error that sort of reduces them to "toggling in load.conf tunables > at the console". :) Heh, well, what will happen is that their device won't work until they either edit /boot/device.hints and reboot, or toggle in the tunables at the loader prompt. :-P -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 15:10:49 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 325911065674 for ; Tue, 27 Jan 2009 15:10:49 +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 0CAB38FC1A for ; Tue, 27 Jan 2009 15:10:49 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 9D77546B4C; Tue, 27 Jan 2009 10:10:48 -0500 (EST) Date: Tue, 27 Jan 2009 15:10:48 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <497C249C.5060507@elischer.org> Message-ID: References: <23211.1232871523@critter.freebsd.dk> <497C249C.5060507@elischer.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Poul-Henning Kamp Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2009 15:10:49 -0000 On Sun, 25 Jan 2009, Julian Elischer wrote: > Even purely documentary would be good but given the option, I'd like it to > scream when Witness is enabled and you try get another mutex.... > > there are certain contexts (e.g. in most netgraph nodes) where we really > want the authors to only take such locks and taking more unpredictable > mutexes plays havoc with netgraph response times as a system as a whole, > since if one node blocks, teh thread doesn't get to go off and service other > nodes. I thought lots of Netgraph nodes liked to do things like call m_pullup() and m_prepend()? Disallowing acquiring mutexes will prevent them from doing that. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 18:26:31 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33A571065674 for ; Tue, 27 Jan 2009 18:26:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outg.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id 168F98FC21 for ; Tue, 27 Jan 2009 18:26:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 3CAD22425; Tue, 27 Jan 2009 10:26:33 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 9A8142D600D; Tue, 27 Jan 2009 10:26:30 -0800 (PST) Message-ID: <497F51D6.1000903@elischer.org> Date: Tue, 27 Jan 2009 10:26:30 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Robert Watson References: <23211.1232871523@critter.freebsd.dk> <497C249C.5060507@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Poul-Henning Kamp Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2009 18:26:31 -0000 Robert Watson wrote: > On Sun, 25 Jan 2009, Julian Elischer wrote: > >> Even purely documentary would be good but given the option, I'd like >> it to scream when Witness is enabled and you try get another mutex.... >> >> there are certain contexts (e.g. in most netgraph nodes) where we >> really want the authors to only take such locks and taking more >> unpredictable mutexes plays havoc with netgraph response times as a >> system as a whole, since if one node blocks, teh thread doesn't get to >> go off and service other nodes. > > I thought lots of Netgraph nodes liked to do things like call m_pullup() > and m_prepend()? Disallowing acquiring mutexes will prevent them from > doing that. I think I mentioned that in another mail. The problem I see is that some module writers are tempted to just use a mutex in their node without thinking about what the result will be. My understanding is that the mbuf allocation code has been tuned to within an inch of its life to try keep it's waits to a minimum. I am worried about it, but I am more worried about a netgraph node waiting on something that is depending on some piece of hardware such as what I think HPS had in his suggested patch for the bluetooth code.. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 19:46:15 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C61E8106566B; Tue, 27 Jan 2009 19:46:15 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7E43E8FC1C; Tue, 27 Jan 2009 19:46:15 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id n0RJUhV5005160; Tue, 27 Jan 2009 14:30:43 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Tue, 27 Jan 2009 14:30:43 -0500 (EST) Date: Tue, 27 Jan 2009 14:30:43 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Julian Elischer In-Reply-To: <497F51D6.1000903@elischer.org> Message-ID: References: <23211.1232871523@critter.freebsd.dk> <497C249C.5060507@elischer.org> <497F51D6.1000903@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Poul-Henning Kamp , Robert Watson Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2009 19:46:16 -0000 On Tue, 27 Jan 2009, Julian Elischer wrote: > Robert Watson wrote: >> On Sun, 25 Jan 2009, Julian Elischer wrote: >> >>> Even purely documentary would be good but given the option, I'd like it to >>> scream when Witness is enabled and you try get another mutex.... >>> >>> there are certain contexts (e.g. in most netgraph nodes) where we really >>> want the authors to only take such locks and taking more unpredictable >>> mutexes plays havoc with netgraph response times as a system as a whole, >>> since if one node blocks, teh thread doesn't get to go off and service >>> other nodes. >> >> I thought lots of Netgraph nodes liked to do things like call m_pullup() >> and m_prepend()? Disallowing acquiring mutexes will prevent them from >> doing that. > > I think I mentioned that in another mail. > The problem I see is that some module writers are tempted to > just use a mutex in their node without thinking about what the > result will be. My understanding is that the mbuf allocation > code has been tuned to within an inch of its life to try > keep it's waits to a minimum. I am worried about it, > but I am more worried about a netgraph node waiting on something > that is depending on some piece of hardware such as what I think > HPS had in his suggested patch for the bluetooth code.. I thought all you wanted to mandate that the netgraph code itself didn't nest any mutexes. If it doesn't hold any of its own mutexes while calling m_prepend(), etc, then is that still a problem? -- DE From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 20:09:22 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46634106564A for ; Tue, 27 Jan 2009 20:09:22 +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 022AB8FC08 for ; Tue, 27 Jan 2009 20:09:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 7861A46B03; Tue, 27 Jan 2009 15:09:21 -0500 (EST) Date: Tue, 27 Jan 2009 20:09:21 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <497F51D6.1000903@elischer.org> Message-ID: References: <23211.1232871523@critter.freebsd.dk> <497C249C.5060507@elischer.org> <497F51D6.1000903@elischer.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Poul-Henning Kamp Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2009 20:09:22 -0000 On Tue, 27 Jan 2009, Julian Elischer wrote: > Robert Watson wrote: >> On Sun, 25 Jan 2009, Julian Elischer wrote: >> >>> Even purely documentary would be good but given the option, I'd like it to >>> scream when Witness is enabled and you try get another mutex.... >>> >>> there are certain contexts (e.g. in most netgraph nodes) where we really >>> want the authors to only take such locks and taking more unpredictable >>> mutexes plays havoc with netgraph response times as a system as a whole, >>> since if one node blocks, teh thread doesn't get to go off and service >>> other nodes. >> >> I thought lots of Netgraph nodes liked to do things like call m_pullup() >> and m_prepend()? Disallowing acquiring mutexes will prevent them from >> doing that. > > I think I mentioned that in another mail. The problem I see is that some > module writers are tempted to just use a mutex in their node without > thinking about what the result will be. My understanding is that the mbuf > allocation code has been tuned to within an inch of its life to try keep > it's waits to a minimum. I am worried about it, but I am more worried about > a netgraph node waiting on something that is depending on some piece of > hardware such as what I think HPS had in his suggested patch for the > bluetooth code.. Right, but what I'm saying is: if we have a MTX_LEAFNODE flag for mtx_init(9), it won't work for any code that holds the lock over a call to the mbuf routines. I am happy with us adding a MTX_LEAFNODE flag and would use it myself, I just not sure it will work for Netgraph node mutexes. The case you're talking about is generally problematic for mutexes anyway -- in principle we divide the world of sleeping into two categories: sleeps of strictly "bounded" length that generall correspond to the sleeps associated with mutex or rwlock acquire, and sleeps of potentially "unbounded" length, such as those associated with msleep(9), cv_wait(9), sx(9), lockmgr(9), etc. If you try to perform an unbounded sleep while holding a mutex, then WITNESS will already complain about sleeping while holding a lock. The tricky case is the "may sleep" case, in which case we already have a WITNESS call you can do to say this code may sleep, even though it doesn't in the common case, so warn if this is called with a mutex held so that we can catch that happening". For example, mb_reclaim does this so that any attempt to call it with a mutex held will throw up a red flag: /* * This is the protocol drain routine. * * No locks should be held when this is called. The drain routines have to * presently acquire some locks which raises the possibility of lock order * reversal. */ static void mb_reclaim(void *junk) { struct domain *dp; struct protosw *pr; WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK | WARN_PANIC, NULL, "mb_reclaim()"); for (dp = domains; dp != NULL; dp = dp->dom_next) for (pr = dp->dom_protosw; pr < dp->dom_protoswNPROTOSW; pr++) if (pr->pr_drain != NULL) (*pr->pr_drain)(); } If there is a common or unconditional call to msleep(9) in code called by Netgraph with a mutex held, however, then it should already be displaying a warning when that happens. If you want to simulate this effect without a lock necessarily be held, you can do what the softclock() code does: THREAD_NO_SLEEPING(); c_func(c_arg); THREAD_SLEEPING_OK(); This causes WITNESS to complain loudly if the callout handler attempts to perform an unbounded sleep (i.e., msleep(), cv_wait(), etc). Splitting the world into bounded an unbounded sleeps is quite useful, and is entirely about the sort of deadlock/cascading delay scenario you have in mind: code inside a mutex-protected block is essentially a critical section, and should never wait a long time, especially given that ithreads may acquire mutexes leading to potential deadlocks if msleep() is effectively waiting on an interrupt that will never be delivered -- if we allow ithreads to wait on msleep(), which we don't because of the above mechanisms. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 06:39:52 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7EC2106564A; Wed, 28 Jan 2009 06:39:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 69F178FC1A; Wed, 28 Jan 2009 06:39:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0S6cgcC090421; Tue, 27 Jan 2009 23:38:42 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 27 Jan 2009 23:39:03 -0700 (MST) Message-Id: <20090127.233903.-432839944.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200901260947.32870.jhb@freebsd.org> References: <200901260947.32870.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 06:39:53 -0000 In message: <200901260947.32870.jhb@freebsd.org> John Baldwin writes: : After the changes to make hints always reserve device names, soem folks ran : into issues with devices changing names due to previously unused hints now : always being honored (e.g. hints for non-existent ISA le(4) cards always : reserving le0). What I would like to do to help minimize this further is to : trim the default set of hints. The number of machines that will run 8.0 that : have ISA slots is incredibly small, probably zero. To that end, I would like : to remove all hints for ISA adapters from i386 and amd64 (amd64 already has : most of them removed). Also, the hint for vga0 is not needed as the vga_isa : driver uses an identify routine to always add itself. Note that end-users : can always add hints back later if desired/needed. However, changing the : defaults means that some hardware may no longer work out of the box. My : guess though is that the set of such hardware is the empty set. Your guess likely would be incorrect. There's still a number of embedded machines that have pc-104 busses attached to them. However, the set is getting much smaller... : If we wanted, we could go further and assume that all machines have either : PnPBIOS or ACPI and remove most of the other hints as well. We already sort : of assume that on amd64 (which has no atrtc0 hints, but still has hints for : fdc0, ppc0, and some other devices). A pure PNPBIOS enumerated system is almost working today. It works on x86 most of the time. I've run systems that had only minimal hints for sio2 and sio3 and a couple of other minor variants. : Here is the proposed diff: I don't like this change. However, you've hit on part of the reason I don't like the change. I don't think it goes far enough, and at the same time loses valuable history. To address the latter, I'd do a cp GENERIC.hints LEGACY.hints and add comments to the top that this is for systems that don't have PNPBIOS or ACPI or that there's problems with those. To address the former, I'd propose something more like: hint.fd.0.at="fdc0" hint.fd.0.drive="0" hint.fd.1.at="fdc0" hint.fd.1.drive="1" hint.atkbd.0.at="atkbdc" hint.psm.0.at="atkbdc" hint.sc.0.at="isa" hint.sc.0.flags="0x100" hint.uart.0.port="0x3F8" hint.uart.0.flags="0x10" hint.uart.1.port="0x2F8" Not sure that the 'sc' lines are needed, but I was too chicken to try without them. They used to be needed... The above wires up everything that isn't on the ISA bus, and gives hints that uart0 should be the one at 0x3f8, etc. Warner : --- //depot/user/jhb/acpipci/amd64/conf/GENERIC.hints : +++ /home/jhb/work/p4/acpipci/amd64/conf/GENERIC.hints : @@ -13,7 +13,6 @@ : hint.atkbd.0.irq="1" : hint.psm.0.at="atkbdc" : hint.psm.0.irq="12" : -hint.vga.0.at="isa" : hint.sc.0.at="isa" : hint.sc.0.flags="0x100" : hint.uart.0.at="isa" : @@ -23,13 +22,5 @@ : hint.uart.1.at="isa" : hint.uart.1.port="0x2F8" : hint.uart.1.irq="3" : -hint.uart.2.at="isa" : -hint.uart.2.disabled="1" : -hint.uart.2.port="0x3E8" : -hint.uart.2.irq="5" : -hint.uart.3.at="isa" : -hint.uart.3.disabled="1" : -hint.uart.3.port="0x2E8" : -hint.uart.3.irq="9" : hint.ppc.0.at="isa" : hint.ppc.0.irq="7" : --- //depot/user/jhb/acpipci/i386/conf/GENERIC.hints : +++ /home/jhb/work/p4/acpipci/i386/conf/GENERIC.hints : @@ -13,21 +13,12 @@ : hint.ata.1.at="isa" : hint.ata.1.port="0x170" : hint.ata.1.irq="15" : -hint.adv.0.at="isa" : -hint.adv.0.disabled="1" : -hint.bt.0.at="isa" : -hint.bt.0.disabled="1" : -hint.aha.0.at="isa" : -hint.aha.0.disabled="1" : -hint.aic.0.at="isa" : -hint.aic.0.disabled="1" : hint.atkbdc.0.at="isa" : hint.atkbdc.0.port="0x060" : hint.atkbd.0.at="atkbdc" : hint.atkbd.0.irq="1" : hint.psm.0.at="atkbdc" : hint.psm.0.irq="12" : -hint.vga.0.at="isa" : hint.sc.0.at="isa" : hint.sc.0.flags="0x100" : hint.apm.0.disabled="1" : @@ -39,41 +30,8 @@ : hint.uart.1.at="isa" : hint.uart.1.port="0x2F8" : hint.uart.1.irq="3" : -hint.uart.2.at="isa" : -hint.uart.2.disabled="1" : -hint.uart.2.port="0x3E8" : -hint.uart.2.irq="5" : -hint.uart.3.at="isa" : -hint.uart.3.disabled="1" : -hint.uart.3.port="0x2E8" : -hint.uart.3.irq="9" : hint.ppc.0.at="isa" : hint.ppc.0.irq="7" : -hint.ed.0.at="isa" : -hint.ed.0.disabled="1" : -hint.ed.0.port="0x280" : -hint.ed.0.irq="10" : -hint.ed.0.maddr="0xd8000" : -hint.cs.0.at="isa" : -hint.cs.0.disabled="1" : -hint.cs.0.port="0x300" : -hint.sn.0.at="isa" : -hint.sn.0.disabled="1" : -hint.sn.0.port="0x300" : -hint.sn.0.irq="10" : -hint.ie.0.at="isa" : -hint.ie.0.disabled="1" : -hint.ie.0.port="0x300" : -hint.ie.0.irq="10" : -hint.ie.0.maddr="0xd0000" : -hint.fe.0.at="isa" : -hint.fe.0.disabled="1" : -hint.fe.0.port="0x300" : -hint.le.0.at="isa" : -hint.le.0.disabled="1" : -hint.le.0.port="0x280" : -hint.le.0.irq="10" : -hint.le.0.drq="0" : hint.atrtc.0.at="isa" : hint.atrtc.0.port="0x70" : hint.atrtc.0.irq="8" : : : -- : John Baldwin : _______________________________________________ : freebsd-arch@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-arch : To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" : From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 06:42:29 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 854EE106564A; Wed, 28 Jan 2009 06:42:29 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2E8F08FC18; Wed, 28 Jan 2009 06:42:29 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0S6dMqg090482; Tue, 27 Jan 2009 23:39:22 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 27 Jan 2009 23:39:43 -0700 (MST) Message-Id: <20090127.233943.1750429792.imp@bsdimp.com> To: alfred@freebsd.org From: "M. Warner Losh" In-Reply-To: <20090126203824.GO5889@elvis.mu.org> References: <200901260947.32870.jhb@freebsd.org> <20090126203824.GO5889@elvis.mu.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 06:42:29 -0000 In message: <20090126203824.GO5889@elvis.mu.org> Alfred Perlstein writes: : There's no way to conditionally include them based on if : ISA is present? ISA is always present. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 06:45:16 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC580106564A; Wed, 28 Jan 2009 06:45:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8CFB58FC12; Wed, 28 Jan 2009 06:45:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0S6hpQ0090542; Tue, 27 Jan 2009 23:43:51 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 27 Jan 2009 23:44:12 -0700 (MST) Message-Id: <20090127.234412.-1417606075.imp@bsdimp.com> To: alfred@freebsd.org From: "M. Warner Losh" In-Reply-To: <20090126220229.GR5889@elvis.mu.org> References: <20090126203824.GO5889@elvis.mu.org> <200901261640.59239.jhb@freebsd.org> <20090126220229.GR5889@elvis.mu.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 06:45:17 -0000 In message: <20090126220229.GR5889@elvis.mu.org> Alfred Perlstein writes: : * John Baldwin [090126 13:57] wrote: : > On Monday 26 January 2009 3:38:24 pm Alfred Perlstein wrote: : > > There's no way to conditionally include them based on if : > > ISA is present? : > : > No, but I dare you to show me a box with ISA expansion slots that you plan to : > run 8.0 on. :) Or rather, I dare you to show me _enough_ of said boxes to : > where removing these hints from the default set will inconvenience more users : > than the folks having their ethernet come up as le1 in vmware guests. :) : : I agree with you, I was just wondering if it was just a matter of : a few lines of code somehow so that some enthusiast who wants to play : with FreeBSD on some old piece of junk doesn't get some cryptic : error that sort of reduces them to "toggling in load.conf tunables : at the console". :) They'll get nothing. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 08:54:14 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68D8D106567D; Wed, 28 Jan 2009 08:54:14 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 2A1148FC2A; Wed, 28 Jan 2009 08:54:14 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id DE8B03F130; Wed, 28 Jan 2009 08:54:12 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n0S8sCgW029726; Wed, 28 Jan 2009 08:54:12 GMT (envelope-from phk@critter.freebsd.dk) To: Robert Watson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 27 Jan 2009 20:09:21 GMT." Date: Wed, 28 Jan 2009 08:54:12 +0000 Message-ID: <29725.1233132852@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@FreeBSD.org, Julian Elischer Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 08:54:15 -0000 In message , Robert Wats on writes: >Right, but what I'm saying is: if we have a MTX_LEAFNODE flag for mtx_init(9), >it won't work for any code that holds the lock over a call to the mbuf >routines. I am happy with us adding a MTX_LEAFNODE flag and would use it >myself, I just not sure it will work for Netgraph node mutexes. 100% agreement there, the kind of usage I expected for this was the 3-line protected regions that grab a reference count og stick something onto a list etc. Memory allocation and similar would not apply. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 09:00:32 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 888A0106566B; Wed, 28 Jan 2009 09:00:32 +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 60E5D8FC12; Wed, 28 Jan 2009 09:00:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id C21D646B6C; Wed, 28 Jan 2009 04:00:31 -0500 (EST) Date: Wed, 28 Jan 2009 09:00:31 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <497DFB61.1010602@elischer.org> Message-ID: References: <497BA91D.805@elischer.org> <497D5DF8.8000706@elischer.org> <20090126105140.GL5889@elvis.mu.org> <200901260936.18232.jhb@freebsd.org> <497DFB61.1010602@elischer.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Alfred Perlstein , Kip Macy , freebsd-arch@freebsd.org Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 09:00:33 -0000 On Mon, 26 Jan 2009, Julian Elischer wrote: > maybe what I want is to be able to label a lock as "fleeting" By which I > mean that the work that would be done while holding this lock would be > fleeting (momentary) in nature. > > An example f a fleeting lock would be something that gains the lock in order > to safely switch two pointers. no malloc is required and nothing is going to > take a long time. > > locks that are NOT momentary include holding the process list lock while > allocating a large buffer (series of them) and dumping the contents of all > processes and things like that. > > one might almost say that a fleeting lock might be gotten while holding > another fleeting lock, but that is pushing it for me.. It was probably clear from my previous e-mail, but just in case it wasn't: we already do this. Mutexes and rwlocks (and rmlocks for that matter) fall into the category you call "fleeting", which are allowed to be held over one another (subject to lock order), but never over "non-fleeting" locks such as sx and lockmgr locks. This is comparable to the upper/lower half kernel concept that existed previously: one is allowed to wait for the other, but not vice versa; we allow ithreads to acquire mutexes and rwlocks, but not sx locks because that might involve waiting for themselves. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 09:00:32 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 888A0106566B; Wed, 28 Jan 2009 09:00:32 +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 60E5D8FC12; Wed, 28 Jan 2009 09:00:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id C21D646B6C; Wed, 28 Jan 2009 04:00:31 -0500 (EST) Date: Wed, 28 Jan 2009 09:00:31 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <497DFB61.1010602@elischer.org> Message-ID: References: <497BA91D.805@elischer.org> <497D5DF8.8000706@elischer.org> <20090126105140.GL5889@elvis.mu.org> <200901260936.18232.jhb@freebsd.org> <497DFB61.1010602@elischer.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Alfred Perlstein , Kip Macy , freebsd-arch@freebsd.org Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 09:00:33 -0000 On Mon, 26 Jan 2009, Julian Elischer wrote: > maybe what I want is to be able to label a lock as "fleeting" By which I > mean that the work that would be done while holding this lock would be > fleeting (momentary) in nature. > > An example f a fleeting lock would be something that gains the lock in order > to safely switch two pointers. no malloc is required and nothing is going to > take a long time. > > locks that are NOT momentary include holding the process list lock while > allocating a large buffer (series of them) and dumping the contents of all > processes and things like that. > > one might almost say that a fleeting lock might be gotten while holding > another fleeting lock, but that is pushing it for me.. It was probably clear from my previous e-mail, but just in case it wasn't: we already do this. Mutexes and rwlocks (and rmlocks for that matter) fall into the category you call "fleeting", which are allowed to be held over one another (subject to lock order), but never over "non-fleeting" locks such as sx and lockmgr locks. This is comparable to the upper/lower half kernel concept that existed previously: one is allowed to wait for the other, but not vice versa; we allow ithreads to acquire mutexes and rwlocks, but not sx locks because that might involve waiting for themselves. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 14:31:24 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDA2A10656E2 for ; Wed, 28 Jan 2009 14:31: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 ACE8F8FC27 for ; Wed, 28 Jan 2009 14:31:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 3BB8B46B3C; Wed, 28 Jan 2009 09:31:24 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0SEVBlS097233; Wed, 28 Jan 2009 09:31:18 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Wed, 28 Jan 2009 09:30:50 -0500 User-Agent: KMail/1.9.7 References: <200901260947.32870.jhb@freebsd.org> <20090127.233903.-432839944.imp@bsdimp.com> In-Reply-To: <20090127.233903.-432839944.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901280930.50727.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 28 Jan 2009 09:31:18 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8914/Wed Jan 28 01:40:00 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 14:31:25 -0000 On Wednesday 28 January 2009 1:39:03 am M. Warner Losh wrote: > In message: <200901260947.32870.jhb@freebsd.org> > John Baldwin writes: > : After the changes to make hints always reserve device names, soem folks ran > : into issues with devices changing names due to previously unused hints now > : always being honored (e.g. hints for non-existent ISA le(4) cards always > : reserving le0). What I would like to do to help minimize this further is to > : trim the default set of hints. The number of machines that will run 8.0 that > : have ISA slots is incredibly small, probably zero. To that end, I would like > : to remove all hints for ISA adapters from i386 and amd64 (amd64 already has > : most of them removed). Also, the hint for vga0 is not needed as the vga_isa > : driver uses an identify routine to always add itself. Note that end-users > : can always add hints back later if desired/needed. However, changing the > : defaults means that some hardware may no longer work out of the box. My > : guess though is that the set of such hardware is the empty set. > > Your guess likely would be incorrect. There's still a number of > embedded machines that have pc-104 busses attached to them. However, > the set is getting much smaller... Yes, but do any of those devices have 'adv0', 'bt0', 'aha0', 'aic0', 'ed0', 'cs0', 'sn0', 'ie0', 'fe0', or 'le0' on the PC-104 bus? If not, then the set remains empty. I'm not removing support for ISA devices. I'm removing hints for a specific set of ISA add-on cards. > : If we wanted, we could go further and assume that all machines have either > : PnPBIOS or ACPI and remove most of the other hints as well. We already sort > : of assume that on amd64 (which has no atrtc0 hints, but still has hints for > : fdc0, ppc0, and some other devices). > > A pure PNPBIOS enumerated system is almost working today. It works on > x86 most of the time. I've run systems that had only minimal hints > for sio2 and sio3 and a couple of other minor variants. Yes, many of my machines also work fine with only a syscons hint. The issue is if we still want to support machines that have neither ACPI nor PnPBIOS (or where someone has to disable both) out of the box. > : Here is the proposed diff: > > I don't like this change. However, you've hit on part of the reason I > don't like the change. I don't think it goes far enough, and at the > same time loses valuable history. > > To address the latter, I'd do a cp GENERIC.hints LEGACY.hints and add > comments to the top that this is for systems that don't have PNPBIOS > or ACPI or that there's problems with those. These are already present in /sys//conf/NOTES. We already have all the various historical hints already documented there. The real issue is what set of hints we will include in the default set to support hardware out of the box. The reason I have not gone further and assumed PnPBIOS or ACPI is that it is a separate question, and I'd rather do this in stages. > To address the former, I'd propose something more like: > > hint.fd.0.at="fdc0" > hint.fd.0.drive="0" > hint.fd.1.at="fdc0" > hint.fd.1.drive="1" > hint.atkbd.0.at="atkbdc" > hint.psm.0.at="atkbdc" > hint.sc.0.at="isa" > hint.sc.0.flags="0x100" > hint.uart.0.port="0x3F8" > hint.uart.0.flags="0x10" > hint.uart.1.port="0x2F8" > > Not sure that the 'sc' lines are needed, but I was too chicken to try > without them. They used to be needed... The above wires up > everything that isn't on the ISA bus, and gives hints that uart0 > should be the one at 0x3f8, etc. I think the fd lines are very much not needed since fdc can enumerate floppy drives on its own. The rest of the hints don't actually work aside from sc0 as hints require an 'at' hint before they wire anything. The sc0 hints are still required, though it would be nice to fix syscons to not need a hint and just always add a device in an identify routine instead. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 16:51:42 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0CEB106566B; Wed, 28 Jan 2009 16:51:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 526978FC18; Wed, 28 Jan 2009 16:51:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0SGmIWa006016; Wed, 28 Jan 2009 09:48:18 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 28 Jan 2009 09:48:40 -0700 (MST) Message-Id: <20090128.094840.-1264100779.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200901280930.50727.jhb@freebsd.org> References: <200901260947.32870.jhb@freebsd.org> <20090127.233903.-432839944.imp@bsdimp.com> <200901280930.50727.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 16:51:43 -0000 In message: <200901280930.50727.jhb@freebsd.org> John Baldwin writes: : On Wednesday 28 January 2009 1:39:03 am M. Warner Losh wrote: : > In message: <200901260947.32870.jhb@freebsd.org> : > John Baldwin writes: : > : After the changes to make hints always reserve device names, soem folks ran : > : into issues with devices changing names due to previously unused hints now : > : always being honored (e.g. hints for non-existent ISA le(4) cards always : > : reserving le0). What I would like to do to help minimize this further is to : > : trim the default set of hints. The number of machines that will run 8.0 that : > : have ISA slots is incredibly small, probably zero. To that end, I would like : > : to remove all hints for ISA adapters from i386 and amd64 (amd64 already has : > : most of them removed). Also, the hint for vga0 is not needed as the vga_isa : > : driver uses an identify routine to always add itself. Note that end-users : > : can always add hints back later if desired/needed. However, changing the : > : defaults means that some hardware may no longer work out of the box. My : > : guess though is that the set of such hardware is the empty set. : > : > Your guess likely would be incorrect. There's still a number of : > embedded machines that have pc-104 busses attached to them. However, : > the set is getting much smaller... : : Yes, but do any of those devices have 'adv0', 'bt0', 'aha0', 'aic0', 'ed0', : 'cs0', 'sn0', 'ie0', 'fe0', or 'le0' on the PC-104 bus? If not, then the : set remains empty. I'm not removing support for ISA devices. I'm removing : hints for a specific set of ISA add-on cards. Right, PC-104 is ISA and has the same devices. And the cards connected typically aren't those drivers, but can be (esp ed0 or cs0). Many older SBCs have these wired into the isa bus w/o the need for an external card. These are unlikely to run 8 well, and more modern cards with PC-104 bus have all the basics on the PCI bus. My comment wasn't meant as a "don't do it" but rather a note that the embedded world significantly lags the desktop/server/laptop market. : > : If we wanted, we could go further and assume that all machines have either : > : PnPBIOS or ACPI and remove most of the other hints as well. We already sort : > : of assume that on amd64 (which has no atrtc0 hints, but still has hints for : > : fdc0, ppc0, and some other devices). : > : > A pure PNPBIOS enumerated system is almost working today. It works on : > x86 most of the time. I've run systems that had only minimal hints : > for sio2 and sio3 and a couple of other minor variants. : : Yes, many of my machines also work fine with only a syscons hint. The issue : is if we still want to support machines that have neither ACPI nor PnPBIOS : (or where someone has to disable both) out of the box. We can't have it both ways easily. I think we need to have a more complete file that matches the drivers that are in GENERIC, even if we don't turn them all on by default. I'm cool with having such people have to copy over additional files to make them work. Such machines are going to be very rare, since it is impossible to turn off PnPBIOS tables in the BIOS, and it has been present since the 486 era of machines at least (don't have any 386s to check). PNPBIOS tends to be used in the embedded world a lot since there's a bigger variety of BIOSes that are present there due to cost issues... : > : Here is the proposed diff: : > : > I don't like this change. However, you've hit on part of the reason I : > don't like the change. I don't think it goes far enough, and at the : > same time loses valuable history. : > : > To address the latter, I'd do a cp GENERIC.hints LEGACY.hints and add : > comments to the top that this is for systems that don't have PNPBIOS : > or ACPI or that there's problems with those. : : These are already present in /sys//conf/NOTES. We already have all : the various historical hints already documented there. The real issue is : what set of hints we will include in the default set to support hardware : out of the box. The reason I have not gone further and assumed PnPBIOS : or ACPI is that it is a separate question, and I'd rather do this in stages. I still think it would be a good idea to have them all in an easy-to-deploy file that people can copy to /boot/device.hints. : > To address the former, I'd propose something more like: : > : > hint.fd.0.at="fdc0" : > hint.fd.0.drive="0" : > hint.fd.1.at="fdc0" : > hint.fd.1.drive="1" : > hint.atkbd.0.at="atkbdc" : > hint.psm.0.at="atkbdc" : > hint.sc.0.at="isa" : > hint.sc.0.flags="0x100" : > hint.uart.0.port="0x3F8" : > hint.uart.0.flags="0x10" : > hint.uart.1.port="0x2F8" : > : > Not sure that the 'sc' lines are needed, but I was too chicken to try : > without them. They used to be needed... The above wires up : > everything that isn't on the ISA bus, and gives hints that uart0 : > should be the one at 0x3f8, etc. : : I think the fd lines are very much not needed since fdc can enumerate floppy : drives on its own. The rest of the hints don't actually work aside from : sc0 as hints require an 'at' hint before they wire anything. The sc0 hints : are still required, though it would be nice to fix syscons to not need a hint : and just always add a device in an identify routine instead. I know that on my PNPBIOS enumerated embedded board that the fdc driver didn't add the fd devices without those lines as recently as 6.2. To be honest, I've not tested it recently since I haven't booted FreeBSD on a system with a floppy in quite some time. Code inspection suggests that they are still needed: /* * Probe and attach any children. We should probably detect * devices from the BIOS unless overridden. */ name = device_get_nameunit(dev); i = 0; while ((resource_find_match(&i, &dname, &dunit, "at", name)) == 0) { resource_int_value(dname, dunit, "drive", &dunit); fdc_add_child(dev, dname, dunit); } We should add back in the 'at' isa lines for uart 0 and 1 to my list then to make wiring work. I'm neutral on the identify routine approach. In general, we shouldn't have that. Instead, shouldn't sc match some PNP device and attach to that only when the VGA hardware is actually present? I ran into problems on really low-end boards that had no VGA hardware, but I can't recall the details at the moment. Soekris boards are the most widely available in this class, although there are others. hint.fd.0.at="fdc0" hint.fd.0.drive="0" hint.fd.1.at="fdc0" hint.fd.1.drive="1" hint.atkbd.0.at="atkbdc" hint.psm.0.at="atkbdc" hint.sc.0.at="isa" hint.sc.0.flags="0x100" hint.uart.0.at="isa" hint.uart.0.port="0x3F8" hint.uart.0.flags="0x10" hint.uart.1.at="isa" hint.uart.1.port="0x2F8" Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 19:14:41 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5D7B1065670; Wed, 28 Jan 2009 19:14:41 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp7.server.rpi.edu (smtp7.server.rpi.edu [128.113.2.227]) by mx1.freebsd.org (Postfix) with ESMTP id A0D678FC0A; Wed, 28 Jan 2009 19:14:41 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp7.server.rpi.edu (8.13.1/8.13.1) with ESMTP id n0SI8Q6X003016; Wed, 28 Jan 2009 13:08:27 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20090127.233903.-432839944.imp@bsdimp.com> References: <200901260947.32870.jhb@freebsd.org> <20090127.233903.-432839944.imp@bsdimp.com> Date: Wed, 28 Jan 2009 13:08:26 -0500 To: "M. Warner Losh" , jhb@FreeBSD.org From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 1.30 (*) [Hold at 20.00] COMBINED_FROM, J_CHICKENPOX_65, J_CHICKENPOX_75 X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.227 Cc: arch@FreeBSD.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 19:14:42 -0000 At 11:39 PM -0700 1/27/09, M. Warner Losh wrote: >I don't like this change. However, you've hit on part of the reason I >don't like the change. I don't think it goes far enough, and at the >same time loses valuable history. > >To address the latter, I'd do a cp GENERIC.hints LEGACY.hints and add >comments to the top that this is for systems that don't have PNPBIOS >or ACPI or that there's problems with those. Admittedly I know almost nothing about the hints themselves, but I like this idea. We already supply multiple kernel files, even though everything is documented in NOTES. We do it because it's convenient and it costs us nothing. We could even install the LEGACY.hints file as /boot/legacy.hints, and then if someone has a problem we can say "go into the boot loader, and type 'include /boot/legacy.hints'. If that doesn't solve your problem, then your problem is not related to this big change to /boot/device.hints". And if it *does* solve their problem, they can just look at 'dmesg' after they boot up, and get a good idea of what lines they need to add to /boot/device.hints. I don't see how this would cost us much (compared to *not* having a legacy.hints file), and yet it might make things much easier if it turns out that too many hints had been removed. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 19:27:40 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A63910656F4; Wed, 28 Jan 2009 19:27:40 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E12828FC13; Wed, 28 Jan 2009 19:27:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0SJNo08011647; Wed, 28 Jan 2009 12:23:50 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 28 Jan 2009 12:24:11 -0700 (MST) Message-Id: <20090128.122411.1626285557.imp@bsdimp.com> To: gad@FreeBSD.org From: "M. Warner Losh" In-Reply-To: References: <200901260947.32870.jhb@freebsd.org> <20090127.233903.-432839944.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, jhb@FreeBSD.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 19:27:41 -0000 In message: Garance A Drosehn writes: : At 11:39 PM -0700 1/27/09, M. Warner Losh wrote: : >I don't like this change. However, you've hit on part of the reason I : >don't like the change. I don't think it goes far enough, and at the : >same time loses valuable history. : > : >To address the latter, I'd do a cp GENERIC.hints LEGACY.hints and add : >comments to the top that this is for systems that don't have PNPBIOS : >or ACPI or that there's problems with those. : : Admittedly I know almost nothing about the hints themselves, but I : like this idea. We already supply multiple kernel files, even though : everything is documented in NOTES. We do it because it's convenient : and it costs us nothing. : : We could even install the LEGACY.hints file as /boot/legacy.hints, : and then if someone has a problem we can say "go into the boot : loader, and type 'include /boot/legacy.hints'. If that doesn't : solve your problem, then your problem is not related to this big : change to /boot/device.hints". And if it *does* solve their problem, : they can just look at 'dmesg' after they boot up, and get a good idea : of what lines they need to add to /boot/device.hints. : : I don't see how this would cost us much (compared to *not* having a : legacy.hints file), and yet it might make things much easier if it : turns out that too many hints had been removed. Actually, that's a very clever idea you've stumbled into. The boot loader already know if acpi is involved, and could trivially be augmented to know if there's PNP data. If neither of them are in place, it could automatically load legacy.hints... But the cheap 'get the file there' is a good idea. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 20:41:35 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A13D1106575C; Wed, 28 Jan 2009 20:41:35 +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 61B5F8FC08; Wed, 28 Jan 2009 20:41:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id E7B3146B65; Wed, 28 Jan 2009 15:41:34 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0SKekcn099624; Wed, 28 Jan 2009 15:41:29 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Wed, 28 Jan 2009 15:40:30 -0500 User-Agent: KMail/1.9.7 References: <200901260947.32870.jhb@freebsd.org> <20090128.122411.1626285557.imp@bsdimp.com> In-Reply-To: <20090128.122411.1626285557.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200901281540.30546.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 28 Jan 2009 15:41:29 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8914/Wed Jan 28 01:40:00 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arch@freebsd.org, gad@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 20:41:36 -0000 On Wednesday 28 January 2009 2:24:11 pm M. Warner Losh wrote: > In message: > Garance A Drosehn writes: > : At 11:39 PM -0700 1/27/09, M. Warner Losh wrote: > : >I don't like this change. However, you've hit on part of the reason I > : >don't like the change. I don't think it goes far enough, and at the > : >same time loses valuable history. > : > > : >To address the latter, I'd do a cp GENERIC.hints LEGACY.hints and add > : >comments to the top that this is for systems that don't have PNPBIOS > : >or ACPI or that there's problems with those. > : > : Admittedly I know almost nothing about the hints themselves, but I > : like this idea. We already supply multiple kernel files, even though > : everything is documented in NOTES. We do it because it's convenient > : and it costs us nothing. > : > : We could even install the LEGACY.hints file as /boot/legacy.hints, > : and then if someone has a problem we can say "go into the boot > : loader, and type 'include /boot/legacy.hints'. If that doesn't > : solve your problem, then your problem is not related to this big > : change to /boot/device.hints". And if it *does* solve their problem, > : they can just look at 'dmesg' after they boot up, and get a good idea > : of what lines they need to add to /boot/device.hints. > : > : I don't see how this would cost us much (compared to *not* having a > : legacy.hints file), and yet it might make things much easier if it > : turns out that too many hints had been removed. > > Actually, that's a very clever idea you've stumbled into. The boot > loader already know if acpi is involved, and could trivially be > augmented to know if there's PNP data. If neither of them are in > place, it could automatically load legacy.hints... > > But the cheap 'get the file there' is a good idea. What I'm worried about I guess is how long we have to maintain this. Also, why do we have hints for ed0 but not ex0? That is, the current list is rather arbitrary and only caters to certain rare hardware and not to other rare hardware. I'd rather just do a simple clean break and drop all of the rare hardware. I don't really think there will be anyone who actually _needs_ to include /boot/legacy.hints, but we will be stuck with this very arbitrary file forever. Also, none of the hints I'm proposing to remove are relevant to the non-PnPBIOS case. They are all devices that the PnPBIOS would not enumerate anyway. The PnPBIOS related hints are an entirely separate ball of wax from ISA NICs. For the PnPBIOS case I could possibly see the case for a legacy.hints (though I'd rather have an x86 isa0 driver that added suitable devices explicitly if there was no ACPI or PnPBIOS), but the primary motivation for the recent changes to the hints code was to allow for the graceful coexistence of those hints with ACPI and PnPBIOS. That is, it should be perfectly fine to use that sort of legacy.hints by default, and not require the users to manually load it for the non-(ACPI or PnPBIOS) case. In that case, legacy.hints basically degenerates back into device.hints, which is basically what I proposed at the very beginning. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 20:52:24 2009 Return-Path: Delivered-To: arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A42AA1065746 for ; Wed, 28 Jan 2009 20:52:24 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 603A08FC17 for ; Wed, 28 Jan 2009 20:52:24 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n0SKtLrK063855; Wed, 28 Jan 2009 15:55:21 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n0SKtLdC063854; Wed, 28 Jan 2009 15:55:21 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Wed, 28 Jan 2009 15:55:21 -0500 From: David Schultz To: Julian Elischer Message-ID: <20090128205521.GA63687@zim.MIT.EDU> Mail-Followup-To: Julian Elischer , Jeff Roberson , arch@FreeBSD.ORG, Kip Macy References: <497BA91D.805@elischer.org> <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com> <497C235E.5090807@elischer.org> <20090124224716.X983@desktop> <497C2E82.6010600@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <497C2E82.6010600@elischer.org> Cc: arch@FreeBSD.ORG, Kip Macy Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 20:52:25 -0000 On Sun, Jan 25, 2009, Julian Elischer wrote: > Jeff Roberson wrote: > >What is the case you have where you can not acquire non leaf mutexes? > > > An example is netgraph. In netgraph you have one (or a small number) > thread which is processing on behalf of a number of nodes which may be > doing work on behalf of completely different entities. > If such a worker thread blocks then other work becomes starved.. It sounds like acquiring non-leaf mutexes here is a red herring; the real issue is that you don't want worker threads to block for long periods of time. Adding an arbitrary rule about mutexes doesn't seem like the right approach: it isn't needed for correctness, it breaks modularity (because you can only call routines if you can guarantee that they follow the rule; cf. Robert's comments), and it may need to be violated on occasion. Tools like dtrace are great for tracking down performance problems associated with lock contention, and they don't require adding unnecessary magic to the locking API. On a related note, one thing that might help performance is to add a way to create dynamically-sized worker thread pools. This doesn't help when you have high contention for the same resource (as all the threads block on the same mutex), but it does help when you have contention for multiple resources, and several threads may be blocked at any given time. .NET's ThreadPool and many commercial application servers have APIs to do things like this, and kern/vfs_aio.c has a special-purpose thread pool to handle blocking I/O. Note that I'm not familiar with the guts of netgraph, so you should take this with a grain of salt and come up with your own opinion about this idea. From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 21:45:48 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D854106567D; Wed, 28 Jan 2009 21:45:48 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0D9868FC12; Wed, 28 Jan 2009 21:45:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0SLgjG6015280; Wed, 28 Jan 2009 14:42:45 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 28 Jan 2009 14:43:07 -0700 (MST) Message-Id: <20090128.144307.-1398303613.imp@bsdimp.com> To: jhb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <200901281540.30546.jhb@freebsd.org> References: <20090128.122411.1626285557.imp@bsdimp.com> <200901281540.30546.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, gad@FreeBSD.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 21:45:48 -0000 In message: <200901281540.30546.jhb@freebsd.org> John Baldwin writes: : On Wednesday 28 January 2009 2:24:11 pm M. Warner Losh wrote: : > In message: : > Garance A Drosehn writes: : > : At 11:39 PM -0700 1/27/09, M. Warner Losh wrote: : > : >I don't like this change. However, you've hit on part of the reason I : > : >don't like the change. I don't think it goes far enough, and at the : > : >same time loses valuable history. : > : > : > : >To address the latter, I'd do a cp GENERIC.hints LEGACY.hints and add : > : >comments to the top that this is for systems that don't have PNPBIOS : > : >or ACPI or that there's problems with those. : > : : > : Admittedly I know almost nothing about the hints themselves, but I : > : like this idea. We already supply multiple kernel files, even though : > : everything is documented in NOTES. We do it because it's convenient : > : and it costs us nothing. : > : : > : We could even install the LEGACY.hints file as /boot/legacy.hints, : > : and then if someone has a problem we can say "go into the boot : > : loader, and type 'include /boot/legacy.hints'. If that doesn't : > : solve your problem, then your problem is not related to this big : > : change to /boot/device.hints". And if it *does* solve their problem, : > : they can just look at 'dmesg' after they boot up, and get a good idea : > : of what lines they need to add to /boot/device.hints. : > : : > : I don't see how this would cost us much (compared to *not* having a : > : legacy.hints file), and yet it might make things much easier if it : > : turns out that too many hints had been removed. : > : > Actually, that's a very clever idea you've stumbled into. The boot : > loader already know if acpi is involved, and could trivially be : > augmented to know if there's PNP data. If neither of them are in : > place, it could automatically load legacy.hints... : > : > But the cheap 'get the file there' is a good idea. : : What I'm worried about I guess is how long we have to maintain this. Forever. : Also, why do we have hints for ed0 but not ex0? ex0 has an identify routine, and ed0 doesn't. : That is, the current list is : rather arbitrary and only caters to certain rare hardware and not to other : rare hardware. I'd rather just do a simple clean break and drop all of the : rare hardware. I don't really think there will be anyone who actually : _needs_ to include /boot/legacy.hints, but we will be stuck with this very : arbitrary file forever. Why does it matter that we have to keep this around forever? Why not clean up the drivers from GENERIC then? It seems like we're only solving part of the problem... : Also, none of the hints I'm proposing to remove are relevant to the : non-PnPBIOS case. They are all devices that the PnPBIOS would not enumerate : anyway. Not necessarily. Many of them would be enumerated for built-in devices (as opposed to ISA add-in cards). : The PnPBIOS related hints are an entirely separate ball of wax from ISA NICs. : For the PnPBIOS case I could possibly see the case for a legacy.hints (though : I'd rather have an x86 isa0 driver that added suitable devices explicitly if : there was no ACPI or PnPBIOS), but the primary motivation for the recent : changes to the hints code was to allow for the graceful coexistence of those : hints with ACPI and PnPBIOS. That is, it should be perfectly fine to use : that sort of legacy.hints by default, and not require the users to manually : load it for the non-(ACPI or PnPBIOS) case. In that case, legacy.hints : basically degenerates back into device.hints, which is basically what I : proposed at the very beginning. The problem is that we still need to have a minimal device.hints for things like the atkbdc and fdc, plus the hack for uart. That's why I suggested copying the current device.hints to legacy.hints (maybe augmenting it to be more real) and then slashing device.hints to the bone. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 21:51:28 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74F2C106570F; Wed, 28 Jan 2009 21:51:28 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id EABDA8FC08; Wed, 28 Jan 2009 21:51:27 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id n0SLpHwv004811; Wed, 28 Jan 2009 16:51:17 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <200901281540.30546.jhb@freebsd.org> References: <200901260947.32870.jhb@freebsd.org> <20090128.122411.1626285557.imp@bsdimp.com> <200901281540.30546.jhb@freebsd.org> Date: Wed, 28 Jan 2009 16:51:16 -0500 To: John Baldwin , "M. Warner Losh" From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 0.70 () [Hold at 20.00] COMBINED_FROM,J_CHICKENPOX_65 X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.226 Cc: arch@FreeBSD.org, gad@FreeBSD.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 21:51:29 -0000 At 3:40 PM -0500 1/28/09, John Baldwin wrote: >On Wednesday 28 January 2009 2:24:11 pm M. Warner Losh wrote: > > In message: > > Garance A Drosehn writes: > > : >> : We could even install the LEGACY.hints file as /boot/legacy.hints, >> : and then if someone has a problem we can say "go into the boot >> : loader, and type 'include /boot/legacy.hints'. If that doesn't >> : solve your problem, then your problem is not related to this big >> : change to /boot/device.hints". And if it *does* solve their problem, >> : they can just look at 'dmesg' after they boot up, and get a good idea >> : of what lines they need to add to /boot/device.hints. >> : >> : I don't see how this would cost us much (compared to *not* having a >> : legacy.hints file), and yet it might make things much easier if it >> : turns out that too many hints had been removed. >> >> Actually, that's a very clever idea you've stumbled into. The boot >> loader already know if acpi is involved, and could trivially be >> augmented to know if there's PNP data. If neither of them are in >> place, it could automatically load legacy.hints... >> >> But the cheap 'get the file there' is a good idea. > >What I'm worried about I guess is how long we have to maintain this. Also, >why do we have hints for ed0 but not ex0? That is, the current list is >rather arbitrary and only caters to certain rare hardware and not to other >rare hardware. I'd rather just do a simple clean break and drop all of the >rare hardware. I don't really think there will be anyone who actually >_needs_ to include /boot/legacy.hints, but we will be stuck with this very >arbitrary file forever. I don't see why we would be stuck with it forever. The only way the user will *use* the file is if they explicitly type "include /boot/legacy.hints" before 'boot' while in the boot loader. Every time they boot, they will have to go through these extra steps. Nothing will automatically use the file for them. The proposal is to remove a lot of lines. You then say "if this *does* cause a problem, they can always type in the 5 lines of hints that they need" -- assuming they know exactly which hints they need to type as they reboot into 8.0-RELEASE for the first time (which is when we are the most likely to see this hit non-developer users). Once a non- developer is in that situation, do you want to talk them through figuring out which hints they need, and then having them type in those lines? Or do you want to say: "Huh. I'm not sure what your problem is, but trying typing in this one line to the boot loader. If that works, then we can figure out what lines need to be added to your personal device.hints file for your specific hardware --- and you will never again have to type in 'include /boot/legacy.hints'". I'm not saying we keep installing the legacy.hints file forever. But it might be awfully convenient to have it there for 8.0-release and maybe 8.1-release (since we know many people won't really install 8.x-stable until 8.1-release). After that, we simply stop installing the file. And if we do have this convenient file there, then we can justify removing even more lines from default device.hints file, the one which is always automatically sourced for all users. A legacy.hints file just seems to be an extremely low-cost safety measure as we make the transition. Btw, I do very much like the idea of making device.hints smaller. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 22:20:52 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10BD510656DF; Wed, 28 Jan 2009 22:20:52 +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 BE4318FC12; Wed, 28 Jan 2009 22:20:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 3236E46B49; Wed, 28 Jan 2009 17:20:51 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0SMKjQd000441; Wed, 28 Jan 2009 17:20:45 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Wed, 28 Jan 2009 17:20:40 -0500 User-Agent: KMail/1.9.7 References: <200901281540.30546.jhb@freebsd.org> <20090128.144307.-1398303613.imp@bsdimp.com> In-Reply-To: <20090128.144307.-1398303613.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901281720.40491.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 28 Jan 2009 17:20:45 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8915/Wed Jan 28 14:49:32 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arch@freebsd.org, gad@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 22:20:53 -0000 On Wednesday 28 January 2009 4:43:07 pm M. Warner Losh wrote: > In message: <200901281540.30546.jhb@freebsd.org> > John Baldwin writes: > : On Wednesday 28 January 2009 2:24:11 pm M. Warner Losh wrote: > : > In message: > : > Garance A Drosehn writes: > : > : At 11:39 PM -0700 1/27/09, M. Warner Losh wrote: > : > : >I don't like this change. However, you've hit on part of the reason I > : > : >don't like the change. I don't think it goes far enough, and at the > : > : >same time loses valuable history. > : > : > > : > : >To address the latter, I'd do a cp GENERIC.hints LEGACY.hints and add > : > : >comments to the top that this is for systems that don't have PNPBIOS > : > : >or ACPI or that there's problems with those. > : > : > : > : Admittedly I know almost nothing about the hints themselves, but I > : > : like this idea. We already supply multiple kernel files, even though > : > : everything is documented in NOTES. We do it because it's convenient > : > : and it costs us nothing. > : > : > : > : We could even install the LEGACY.hints file as /boot/legacy.hints, > : > : and then if someone has a problem we can say "go into the boot > : > : loader, and type 'include /boot/legacy.hints'. If that doesn't > : > : solve your problem, then your problem is not related to this big > : > : change to /boot/device.hints". And if it *does* solve their problem, > : > : they can just look at 'dmesg' after they boot up, and get a good idea > : > : of what lines they need to add to /boot/device.hints. > : > : > : > : I don't see how this would cost us much (compared to *not* having a > : > : legacy.hints file), and yet it might make things much easier if it > : > : turns out that too many hints had been removed. > : > > : > Actually, that's a very clever idea you've stumbled into. The boot > : > loader already know if acpi is involved, and could trivially be > : > augmented to know if there's PNP data. If neither of them are in > : > place, it could automatically load legacy.hints... > : > > : > But the cheap 'get the file there' is a good idea. > : > : What I'm worried about I guess is how long we have to maintain this. > > Forever. Ah, yes, that is what I'd like to avoid. :( > : Also, why do we have hints for ed0 but not ex0? > > ex0 has an identify routine, and ed0 doesn't. fe0 doesn't have an identify routine nor hints in the default set. We don't ship hints for sound blaster ISA cards by default either not all of which are PnP (mine wasn't). The point being that the set of ISA adapters with hints in the current device.hints is an arbitrary subset. > : That is, the current list is > : rather arbitrary and only caters to certain rare hardware and not to other > : rare hardware. I'd rather just do a simple clean break and drop all of the > : rare hardware. I don't really think there will be anyone who actually > : _needs_ to include /boot/legacy.hints, but we will be stuck with this very > : arbitrary file forever. > > Why does it matter that we have to keep this around forever? Why not > clean up the drivers from GENERIC then? It seems like we're only > solving part of the problem... The motivation for cleaning up hints is that our default set of hints has resulted in extra fallout for other folks in combination with my hint-wiring changes which I only committed after several people asked me to commit them. To that end, I am simply trying to engage in the smallest possible change that is also self-consistent. Dropping all non-PnPBIOS/ACPI hints seems to fit that bill. > : Also, none of the hints I'm proposing to remove are relevant to the > : non-PnPBIOS case. They are all devices that the PnPBIOS would not enumerate > : anyway. > > Not necessarily. Many of them would be enumerated for built-in > devices (as opposed to ISA add-in cards). PNP devices are not PNPBIOS devices. No BIOS is going to have an ed0 device or ie0 device in the PNPBIOS table or ACPI namespace. > : The PnPBIOS related hints are an entirely separate ball of wax from ISA NICs. > : For the PnPBIOS case I could possibly see the case for a legacy.hints (though > : I'd rather have an x86 isa0 driver that added suitable devices explicitly if > : there was no ACPI or PnPBIOS), but the primary motivation for the recent > : changes to the hints code was to allow for the graceful coexistence of those > : hints with ACPI and PnPBIOS. That is, it should be perfectly fine to use > : that sort of legacy.hints by default, and not require the users to manually > : load it for the non-(ACPI or PnPBIOS) case. In that case, legacy.hints > : basically degenerates back into device.hints, which is basically what I > : proposed at the very beginning. > > The problem is that we still need to have a minimal device.hints for > things like the atkbdc and fdc, plus the hack for uart. That's why I > suggested copying the current device.hints to legacy.hints (maybe > augmenting it to be more real) and then slashing device.hints to the > bone. These are all devices that I count as PNPBIOS devices. I can put back the fd0 and fd1 hints, but the rest of the devices being removed are all non-PNPBIOS devices. To me at least there is a distinction. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 22:42:44 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67BD910656DB; Wed, 28 Jan 2009 22:42:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 00D108FC12; Wed, 28 Jan 2009 22:42:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0SMflVr016056; Wed, 28 Jan 2009 15:41:47 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 28 Jan 2009 15:42:09 -0700 (MST) Message-Id: <20090128.154209.1492588688.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200901281720.40491.jhb@freebsd.org> References: <200901281540.30546.jhb@freebsd.org> <20090128.144307.-1398303613.imp@bsdimp.com> <200901281720.40491.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, gad@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 22:42:44 -0000 In message: <200901281720.40491.jhb@freebsd.org> John Baldwin writes: : fe0 doesn't have an identify routine nor hints in the default set. We don't : ship hints for sound blaster ISA cards by default either not all of which are : PnP (mine wasn't). The point being that the set of ISA adapters with hints : in the current device.hints is an arbitrary subset. Yes. It represents the terminal state of GENERIC when it was converted to hints. I still don't understand your resistance to having a fully populated hints file hanging around as legacy.hints. It is so utterly cheap to do that I can't believe you'd argue about doing it. : PNP devices are not PNPBIOS devices. No BIOS is going to have an ed0 device : or ie0 device in the PNPBIOS table or ACPI namespace. I'm sorry, but you think I'm confused when I'm not. You are not correct here. There *ARE* PNPBIOS entires for ed/ne2000 devices on some boards. I had a board that has them on it at Timing Solutions, and I believe I have at least two laptops that have various PNPBIOS entries for things like ethernet controllers (ne2000) and SCSI controllers (sym based). These are not ADD-IN cards that enumerate with PNP. These are built-in devices that enumerate with PNPBIOS. I'll keep repeating this until you understand that there are such things. Of course, I'm not sure it is relevant. : These are all devices that I count as PNPBIOS devices. I can put back the fd0 : and fd1 hints, but the rest of the devices being removed are all non-PNPBIOS : devices. To me at least there is a distinction. You have to put back the fd0 and fd1 devices, since they are only enumerated for ACPI right now. They aren't enumerated for pnpbios at all. So how far are we from what I posted? # $FreeBSD$ hint.fd.0.at="fdc0" hint.fd.0.drive="0" hint.fd.1.at="fdc0" hint.fd.1.drive="1" hint.atkbd.0.at="atkbdc" hint.psm.0.at="atkbdc" hint.vga.0.at="isa" hint.sc.0.at="isa" hint.sc.0.flags="0x100" hint.uart.0.at="isa" hint.uart.0.port="0x3F8" hint.uart.0.flags="0x10" hint.uart.1.at="isa" hint.uart.1.port="0x2F8" Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 22:59:02 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30A7D106564A; Wed, 28 Jan 2009 22:59:02 +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 F35E08FC08; Wed, 28 Jan 2009 22:59:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 91A8C46BA7; Wed, 28 Jan 2009 17:59:01 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0SMwtDU000679; Wed, 28 Jan 2009 17:58:55 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Wed, 28 Jan 2009 17:58:47 -0500 User-Agent: KMail/1.9.7 References: <200901281540.30546.jhb@freebsd.org> <200901281720.40491.jhb@freebsd.org> <20090128.154209.1492588688.imp@bsdimp.com> In-Reply-To: <20090128.154209.1492588688.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901281758.47741.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 28 Jan 2009 17:58:55 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8915/Wed Jan 28 14:49:32 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arch@freebsd.org, gad@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 22:59:02 -0000 On Wednesday 28 January 2009 5:42:09 pm M. Warner Losh wrote: > : These are all devices that I count as PNPBIOS devices. I can put back the fd0 > : and fd1 hints, but the rest of the devices being removed are all non-PNPBIOS > : devices. To me at least there is a distinction. > > You have to put back the fd0 and fd1 devices, since they are only > enumerated for ACPI right now. They aren't enumerated for pnpbios at > all. > > So how far are we from what I posted? I don't know, but I give up, do whatever you want. I'm not going to mess with it anymore. > # $FreeBSD$ > hint.fd.0.at="fdc0" > hint.fd.0.drive="0" > hint.fd.1.at="fdc0" > hint.fd.1.drive="1" > hint.atkbd.0.at="atkbdc" > hint.psm.0.at="atkbdc" > hint.vga.0.at="isa" These three aren't actually needed on PnPBIOS/ACPI systems. > hint.sc.0.at="isa" > hint.sc.0.flags="0x100" > hint.uart.0.at="isa" > hint.uart.0.port="0x3F8" > hint.uart.0.flags="0x10" > hint.uart.1.at="isa" > hint.uart.1.port="0x2F8" -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Jan 30 16:33:17 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4CB8106567A; Fri, 30 Jan 2009 16:33:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 544238FC3E; Fri, 30 Jan 2009 16:33:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0UGUShh050004; Fri, 30 Jan 2009 09:30:28 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 30 Jan 2009 09:30:52 -0700 (MST) Message-Id: <20090130.093052.-2022808221.imp@bsdimp.com> To: obrien@FreeBSD.org, arch@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20090130.085130.-4349483.imp@bsdimp.com> References: <200901130653.n0D6rrNX092719@svn.freebsd.org> <20090130015518.GA20404@hades.panopticon> <20090130.085130.-4349483.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2009 16:33:23 -0000 OMG! There's too much make output now, and the recent changes broke useful make features. All but one were eventually fixed. I just fixed the -s breakage. I'm planning on committing the following, if it passes code review and item #3 below. First, there was absolutely no reason to introduce -Q. -v is otherwise unused and matches the 'opt-in' debugging that's present in the rest of make and the build system and other utilities like cp and mv which will tell you what they are doing only if asked. Second, the extra always on debug introduces a performance penalty. Usually, one has to have good justification for doing this. Third, I'd like to collect votes on this. Do you like the new debugging, or would you rather see it just when asked. I'll let the majority rule as to whether to commit this patch. Please let me know privately. I'll tally the results and commit based on it. Finally, if there's any real, persuasive argument that should override the vote, I'd like to hear it. Thank you for your time. Warner Index: job.c =================================================================== --- job.c (revision 187843) +++ job.c (working copy) @@ -2362,7 +2362,7 @@ makeErrors = 0; lastNode = NULL; - if ((maxJobs == 1 && fifoFd < 0) || is_posix || beQuiet) { + if ((maxJobs == 1 && fifoFd < 0) || is_posix || !beVerbose) { /* * If only one job can run at a time, there's no need for a * banner, no is there? Index: main.c =================================================================== --- main.c (revision 187921) +++ main.c (working copy) @@ -126,7 +126,6 @@ Boolean mfAutoDeps; /* .MAKEFILEDEPS target seen */ Boolean beSilent; /* -s flag */ Boolean beVerbose; /* -v flag */ -Boolean beQuiet; /* -Q flag */ Boolean compatMake; /* -B argument */ int debug; /* -d flag */ Boolean ignoreErrors; /* -i flag */ @@ -517,11 +516,6 @@ printGraphOnly = TRUE; debug |= DEBUG_GRAPH1; break; - case 'Q': - beQuiet = TRUE; - beVerbose = FALSE; - MFLAGS_append("-Q", NULL); - break; case 'q': queryFlag = TRUE; /* Kind of nonsensical, wot? */ @@ -532,7 +526,7 @@ MFLAGS_append("-r", NULL); break; case 's': - beQuiet = TRUE; + beVerbose = FALSE; beSilent = TRUE; MFLAGS_append("-s", NULL); break; @@ -542,7 +536,6 @@ break; case 'v': beVerbose = TRUE; - beQuiet = FALSE; MFLAGS_append("-v", NULL); break; case 'x': Index: globals.h =================================================================== --- globals.h (revision 187843) +++ globals.h (working copy) @@ -76,7 +76,6 @@ extern Boolean ignoreErrors; /* True if should ignore all errors */ extern Boolean beSilent; /* True if should print no commands */ extern Boolean beVerbose; /* True if should print extra cruft */ -extern Boolean beQuiet; /* True if want quiet headers with -j */ extern Boolean noExecute; /* True if should execute nothing */ extern Boolean allPrecious; /* True if every target is precious */ extern Boolean is_posix; /* .POSIX target seen */ From owner-freebsd-arch@FreeBSD.ORG Sat Jan 31 10:10:13 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F46B1065691 for ; Sat, 31 Jan 2009 10:10:13 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 005258FC14 for ; Sat, 31 Jan 2009 10:10:12 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.2/8.14.2) with ESMTP id n0V9VUTd060962; Sat, 31 Jan 2009 01:31:30 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.2/Submit) id n0V9VUcO060961; Sat, 31 Jan 2009 01:31:30 -0800 (PST) (envelope-from obrien) Date: Sat, 31 Jan 2009 01:31:30 -0800 From: "David O'Brien" To: John Baldwin Message-ID: <20090131093130.GA17896@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, John Baldwin , freebsd-arch@freebsd.org References: <200901260947.32870.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200901260947.32870.jhb@freebsd.org> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2009 10:10:13 -0000 On Mon, Jan 26, 2009 at 09:47:32AM -0500, John Baldwin wrote: > After the changes to make hints always reserve device names, soem folks ran > into issues with devices changing names due to previously unused hints now > always being honored (e.g. hints for non-existent ISA le(4) cards always > reserving le0). What I would like to do to help minimize this further is to > trim the default set of hints. The number of machines that will run 8.0 that > have ISA slots is incredibly small, probably zero. For AMD64 machines its definitely zero. > To that end, I would like > to remove all hints for ISA adapters from i386 and amd64 (amd64 already > has most of them removed). .. > If we wanted, we could go further and assume that all machines have > either PnPBIOS or ACPI and remove most of the other hints as well. At least for amd64, I'd like to see all the hints removed. We should make these assumptions. For i386 you're getting some resistance, but I don't see any reason to not do this for amd64. -- -- David (obrien@FreeBSD.org)