Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 19 Aug 2002 14:01:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 19 Aug 2002 14:01:13 -0400 Received: from air-2.osdl.org ([65.172.181.6]:15754 "EHLO cherise.pdx.osdl.net") by vger.kernel.org with ESMTP id ; Mon, 19 Aug 2002 14:01:12 -0400 Date: Mon, 19 Aug 2002 11:10:58 -0700 (PDT) From: Patrick Mochel X-X-Sender: mochel@cherise.pdx.osdl.net To: Adam Belay cc: greg@kroah.com, Subject: Re: [PATCH] 2.5.31 driverfs: patch for your consideration In-Reply-To: <3D5ECEFE.4020404@netscape.net> 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 Content-Length: 2167 Lines: 50 > I downloaded my patches through the mailing list and applied them: > > bash-2.05a$ cat ./driver.patch | patch -p1 -l -d linux > patching file drivers/base/interface.c > bash-2.05a$ cat ./driver2.patch | patch -p1 -l -d linux > patching file drivers/base/base.h > patching file drivers/base/core.c > patching file drivers/base/interface.c > > It applies cleanly but . . . patch -l does not imply cleanly. That will ignore the whitespace munging that your MUA is doing. > You're right the tabs are gone although when I applied my originals they > weren't. I hate netscape navigator. I gzipped them so netscape can't > mess them up. In the meantime I'm going to download mutt. Thanks for > your help. Let me know if the patch works this time. Also after > looking at the interface code I realized that not just my code used > sprintf. Do you think they should all use snprintf instead or is the > probability of a driver attribute exceeding the one page buffer size so > low that it doesn't matter? They should use snprintf. Thanks for pointing that out. > Also I was wondering if you think resource management variables (irq, > io, dma, etc) should live in the device structure like power management > variables do? Global resource management seams interesting to me, > although there already is a proc interface that does list resources, I'm > wondering if the driver model is a good place to put such an interface? Yes. We talked about doing that from the very beginning, and were going to see how things worked out. There was some dicussion about this at OLS, too. But, I'm not sure it's ready for it yet. What would be nice would be some way to cleanly represent conditional attributes of devices, like resource and power management. I think I almost have something with the device interface stuff, but I fear it's a fine line to cross over into Abstraction Hell... -pat - 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/