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/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:29 EST