Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 7 Jan 2002 13:30:48 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 7 Jan 2002 13:30:38 -0500 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:64523 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Mon, 7 Jan 2002 13:30:30 -0500 Date: Mon, 7 Jan 2002 10:29:22 -0800 (PST) From: Linus Torvalds To: Abramo Bagnara cc: Alan Cox , Christoph Hellwig , Jaroslav Kysela , , , Subject: Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel In-Reply-To: <3C39E6A0.34A88990@alsa-project.org> 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 On Mon, 7 Jan 2002, Abramo Bagnara wrote: > > IMO the latter makes much more sense (also for "net" case), but I doubt > you're willing to change current schema. Agreed. I do not really think that it makes sense to move "drivers/net" to "net/drivers" even if it _would_ be the logical way to group all net things together. Whatever potential incremental advantage (if any) just isn't worth the disruption. > If you want to keep top level cleaner and avoid proliferation of entries > we might have: > > subsys/sound ... No, I hate to create structure abstractions for their own sake, and a "subsys" kind of abstraction doesn't really add any information. I have no problems with making the linux "root" directory a bit larger, it's certainly not problematic (what, 22 entries, and no new ones generated dynamically - fits on one screen even on an old vt100). That might change if we end up creating _more_ subdirectories, of course, although even then I'd really want to group them according to some clear goal or property of the grouping (ie not "subsys" kinds of things). Linus - 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/