From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751889AbbJQTHt (ORCPT ); Sat, 17 Oct 2015 15:07:49 -0400 Received: from h1446028.stratoserver.net ([85.214.92.142]:36866 "EHLO mail.ahsoftware.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751334AbbJQTHr (ORCPT ); Sat, 17 Oct 2015 15:07:47 -0400 Subject: Re: [PATCH 04/14] init: deps: order network interfaces by link order To: Linus Torvalds References: <1445102067-11519-1-git-send-email-holler@ahsoftware.de> <1445102067-11519-5-git-send-email-holler@ahsoftware.de> <5622956F.80408@ahsoftware.de> Cc: Linux Kernel Mailing List , Andrew Morton , Greg Kroah-Hartman , Russell King , Grant Likely From: Alexander Holler Message-ID: <56229C7B.1080705@ahsoftware.de> Date: Sat, 17 Oct 2015 21:07:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 17.10.2015 um 21:03 schrieb Linus Torvalds: > On Sat, Oct 17, 2015 at 11:37 AM, Alexander Holler wrote: >> >> Otherwise it's impossible to call initcalls in parallel. I've seen a stable >> topological sort somewhere, but whenever you want to parallelize the >> initcalls, the stable ordering would be gone anyway. So I've decided not to >> look further at a stable topological sort. > > So five seconds of googling gave me freely usable source code for a > stable topological sort, that also has a nice reported added > advantage: > > "An interesting property of a stable topological sort is that cyclic > dependencies are tolerated and resolved according to original order of > elements in sequence. This is a desirable feature for many > applications because it allows to sort any sequence with any > imaginable dependencies between the elements" > > which seems to be *exactly* what you'd want, especially considering > that right now your patches add extra "no-dependency" markers exactly > because of the cyclical problem. That's the stable topological sort I've mentioned the link to in the discussion with you. > > I think it was the #2 hit on google for "stable topological sort". I > didn't look closely at the source code, but it was not big. > > And no, since we don't actually want to parallelize the initcalls > anyway (I had this discussion with you just a month ago), your > objections seem even more questionable. We have separate machinery for > "do this asynchronously", and we want to _keep_ that separate. I've understood that now. Sorry for wasting your time. Alexander Holler