Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 3 Jun 2002 14:14:01 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 3 Jun 2002 14:14:00 -0400 Received: from pD952AF1C.dip.t-dialin.net ([217.82.175.28]:21124 "EHLO hawkeye.luckynet.adm") by vger.kernel.org with ESMTP id ; Mon, 3 Jun 2002 14:13:59 -0400 Date: Mon, 3 Jun 2002 12:13:29 -0600 (MDT) From: Thunder from the hill X-X-Sender: thunder@hawkeye.luckynet.adm To: Horst von Brand cc: jt@hpl.hp.com, Kai Germaschewski , Dan Aloni , Linux kernel mailing list , Alan Cox , Jeff Garzik Subject: Re: Link order madness :-( In-Reply-To: <200206031729.g53HTwTo002828@pincoya.inf.utfsm.cl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Mon, 3 Jun 2002, Horst von Brand wrote: > There should be a way of saying "This must be initialized after this, and > before that" (the "before that" might perhaps be taken care of by the > "that" itself). Spiced with a few "barriers": "Networking inited", etc. Suggestion #1: make up an inittask table (bad idea, huge table) that gets freed on end of init. Suggestion #2: each big subsystem (net, scsi, pcmcia, etc.) gets a lock that is engaged when starting, and is checked by the subsystems. The subsystems' init won't take place unless the parent subsystem is up. At end of init, these locks get freed. Suggestion #3 (possibly the worst ever): let the subsubsystems be init'ed by the subsystems, using #ifdef'd calls... I must leave now, sorry. Regards, Thunder -- ship is leaving right on time | Thunder from the hill at ngforever empty harbour, wave goodbye | evacuation of the isle | free inhabitant not directly caveman's paintings drowning | belonging anywhere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/