Messages in this thread | | | Date | Mon, 16 Oct 2000 02:27:47 +0200 | From | FORT David <> | Subject | Re: [2.4.0test10-pre3]drm_proc_init incorrect when multiple deviceare registering |
| |
Tigran Aivazian wrote:
> Hi David, > > Yes, this is a well-known problem and was briefly discussed between Rick > Faith, Al Viro and myself. The thing is that DRI design dictates > duplication of the code instead of sharing it between individual low-level > drivers (this is not silly -- there are lots of valid reasons for this as > was explained to me by Rick Faith) and this makes it rather clumsy to > share a common /proc entry as you can see from a little hack there which > used to work some time ago. > > So, one either needs to enhance the hack to work today (Rick's suggestion) > or to write a "drmfs" (Al Viro's suggestion) or to abandon the original > design of not-sharing the code and do share it (my suggestion but of > course it's up to Rick and other maintainers of that code -- they know > better how to make their own life easier). > > Regards, > Tigran > > On Mon, 16 Oct 2000, FORT David wrote: > > > Hi, > > I've just got a look at file drivers/char/drm/proc.c, correct me if i'm > > wrong but > > when registering using "drm_proc_init" each device supporting drm > > duplicates the dri dir entry, as "create_proc_entry " blindly create a > > new dri entry even if one already exists. > > > > IIRC a few month ago the same kind of error was occuring in /proc/irq, > > perhaps we should check in > > create_proc_entry that an entry exists before creating it, this could > > prevent each driver from doing this > > job. > > >
what about the follwing patch in fs/proc/generic.c, this would solve the problem for any driver wanting to create multiple entries using create_proc_entry:
*** generic.c.orig Mon Oct 16 01:49:23 2000 --- generic.c Mon Oct 16 02:17:09 2000 *************** *** 505,510 **** --- 505,515 ---- if (!parent && xlate_proc_name(name, &parent, &fn) != 0) goto out; len = strlen(fn); + /* check that entry doesn't already exist, + and return it if it's the case */ + for( ent = parent->subdir; ent; ent = ent->next ) + if( proc_match(len, fn, ent) ) return ent; +
ent = kmalloc(sizeof(struct proc_dir_entry) + len + 1, GFP_KERNEL); if (!ent)
This one have a big drawback: mode doesn't affect the returned entry. Anyway
if someone create a /proc entry, it may always have the same type. We could
also define a clear behaviour for such cases.
Same kind of patch could apply in proc_symlink, proc_mknod and proc_mkdir.
-- %--IRIN->-Institut-de-Recherche-en-Informatique-de-Nantes-----------------% % FORT David, % % 7 avenue de la morvandière 0240726275 % % 44470 Thouare, France epopo@onetelnet.fr % % ICU:78064991 AIM: enlighted popo fort@irin.univ-nantes.fr % %--LINUX-HTTPD-PIOGENE----------------------------------------------------% % -datamining <-/ | .~. % % -networking/flashed PHP3 coming soon | /V\ L I N U X % % -opensource | // \\ >Fear the Penguin< % % -GNOME/enlightenment/GIMP | /( )\ % % feel enlighted.... | ^^-^^ % % http://ibonneace.dnsalias.org/ when connected % %-------------------------------------------------------------------------%
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |