Re: create_proc_entry and !CONFIG_PROC_FS

From: Adrian Bunk
Date: Sun Aug 31 2003 - 16:47:10 EST


On Sun, Aug 31, 2003 at 02:40:33PM -0700, Andrew Morton wrote:
> Adrian Bunk <bunk@xxxxxxxxx> wrote:
> >
> > Hi,
> >
> > I've observed a possible problem with create_proc_entry and
> > !CONFIG_PROC_FS.
> >
> > If !CONFIG_PROC_FS include/linux/proc_fs.h includes a dummy
> > create_proc_entry that simply returns NULL.
> >
> > Unfortunately, many callers of this function do things like e.g.
> >
> > static int __init br2684_init(void)
> > {
> > struct proc_dir_entry *p;
> > if ((p = create_proc_entry("br2684", 0, atm_proc_root)) == NULL)
> > return -ENOMEM;
> > p->proc_fops = &br2684_proc_operations;
> > br2684_ioctl_set(br2684_ioctl);
> > return 0;
> > }
> >
> >
> > IOW, the dummy create_proc_entry fixes the compilation but the init
> > function always returns -ENOMEM if !CONFIG_PROC_FS.
> >
> > Is there any better solution than removing the dummy create_proc_entry
> > and #ifdef'ing all places where it's used?
>
> The normal fix would be to sprinkle ifdefs throughout the driver itself.

That's what I was thinking of when I wrote "#ifdef'ing all places where
it's used"...

> You need to lok at the driver and ask yourself "is anyone ever going to want
> to use this in a no-procfs system". Probably, the answer is always "no".
> In which case appropriate fixes would be to ignore the problem, or disable
> the driver in config if !CONFIG_PROC_FS.

The latter is IMHO the better solution, a driver that compiles but
doesn't work (#if !CONFIG_PROC_FS) is simply useless.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/