From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751695AbbJQSiE (ORCPT ); Sat, 17 Oct 2015 14:38:04 -0400 Received: from h1446028.stratoserver.net ([85.214.92.142]:35590 "EHLO mail.ahsoftware.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751631AbbJQSho (ORCPT ); Sat, 17 Oct 2015 14:37:44 -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> Cc: Linux Kernel Mailing List , Andrew Morton , Greg Kroah-Hartman , Russell King , Grant Likely From: Alexander Holler Message-ID: <5622956F.80408@ahsoftware.de> Date: Sat, 17 Oct 2015 20:37:35 +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 20:23 schrieb Linus Torvalds: > On Sat, Oct 17, 2015 at 10:14 AM, Alexander Holler wrote: >> >> Assuming three different ethernet-drivers, without any special code, >> the dependency graph would not require any special order inbetween them >> and would look like that: > > This seems *fundamentally* wrong. > > This is in no way specific to network drivers (or to disk drivers, or > to anything else). > > So requiring extra logic for this implies that something is seriously wrong. > > If two drivers aren't ordered by dependencies, they should always be > in link order, regardless of any hacks like these. If they're not, > things are wrong. > > I think your problem is that you make that dependency thing a separate > ordering, so now it matters whether a driver has a dependency or not. I'm making dependencies the only ordering for annotated initcalls. 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. > If something like this is to work, it has to work *with* the normal > ordering, not outside of it and then have these kinds of broken > special cases. > > The normal init orderings (ie core -> postcore -> arch -> subsys -> fs > -> rootfs -> device -> late) should just be an extra dependency, I > think. > > The way that you just insert the annotated dependencies in between > levels 6 and 7 ("device" and "late") can't be right. It means - for > example - that you can't have subsystems that have dependencies. Sorry, but that's wrong. I've choosen to place initcalls between 5 and 6 to make it easier to move both, subsystems as well as normal drivers to the (new) level with annotated initcalls. If you look at what I've already "annotated", you will see there are quiet a lot initcalls I've moved from below 6 to the new level. > So I really think that if we do dependencies, then the current levels > have to be added as dependencies, so that "subsys_initcall(xyz)" > basically means "xyz depends on the 'subsys' event, and 'subsys_end' > depends on xyz". Then within that, you might have another bus driver > that in turn depends on 'xyz'. It would be absolutely no problem to introduce "virtual" initcalls for any level, e.g. just depencies = { everything_below } initcall foo() { return 0; } annotated_initcall(foo, id, dependencies), Regards, Alexander Holler