Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 18 Feb 2003 09:02:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 18 Feb 2003 09:02:42 -0500 Received: from almesberger.net ([63.105.73.239]:62984 "EHLO host.almesberger.net") by vger.kernel.org with ESMTP id ; Tue, 18 Feb 2003 09:02:32 -0500 Date: Tue, 18 Feb 2003 11:12:15 -0300 From: Werner Almesberger To: Roman Zippel Cc: Rusty Russell , kuznet@ms2.inr.ac.ru, davem@redhat.com, kronos@kronoz.cjb.net, linux-kernel@vger.kernel.org Subject: Re: [RFC] Is an alternative module interface needed/possible? Message-ID: <20030218111215.T2092@almesberger.net> References: <20030217221837.Q2092@almesberger.net> <20030218050349.44B092C04E@lists.samba.org> <20030218042042.R2092@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from zippel@linux-m68k.org on Tue, Feb 18, 2003 at 01:06:36PM +0100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1988 Lines: 62 (I think we should limit the Cc:s to Roman, Rusty, the list, and me, and leave the others in peace. Please yell if you really want that extra copy :-) Roman Zippel wrote: > Basically I can agree with this, although I'd like to avoid that we > iterate too much over these steps, as it would too easily divert the > discussion to other things, so I'd rather take smaller steps and keep the > scope a bit broader. Good :-) I want to avoid modules as much as possible, because they've extensively been tackled in the past (which didn't help much making the interfaces better), and also because they're just a bit too political an issue. Okay, this brings us to the issue of broken interfaces. Do we have agreement that there are cases where interfaces like remove_proc_entry, in their current state, cannot be used correctly ? Example: static ...callback...(... struct file *file ...) { void *user = PDE(file->f_dentry->d_inode)->data; ... do something with "*user" ... } ... struct proc_dir_entry *de = create_proc_entry(...); void *my_data; de->data = my_data = kmalloc(...); ... remove_proc_entry(...); /* what happens with "my_data", formerly known as "de->data" ? */ a) kfree it. May cause an oops or other problems if we're in the middle of the callback. b) don't kfree it. So we now have a (hopefully small) memory leak. Problem: my_data may point to a lot more than just some tiny allocation. Okay so far ? (Possible solutions on the next, slid^H^H^H^Hposting :-) - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ - 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/