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?
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
Adrian Bunk <[email protected]> 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.
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.
On Sun, Aug 31, 2003 at 02:40:33PM -0700, Andrew Morton wrote:
> Adrian Bunk <[email protected]> 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