patches for PROC_FS=n (2.6.0-test7)

patches for PROC_FS=n (2.6.0-test7)

[Randy.Dunlap]

drivers/char/toshiba.c and
net/atm/clip.c don't build if PROC_FS=n.

Patches for them are available at:

http://developer.osdl.org/rddunlap/patches/toshiba_inline_260t7.patch
http://developer.osdl.org/rddunlap/patches/atmprocfs_260t7.patch

There are several other drivers/protocols that don't build
with PROC_FS=n, like arlan, siimage, ipx, llc, and bluetooth.

--
~Randy

Re: patches for PROC_FS=n (2.6.0-test7)

[David S. Miller]

On Fri, 10 Oct 2003 14:16:46 -0700
"Randy.Dunlap" <rddunlap@osdl.org> wrote:

> http://developer.osdl.org/rddunlap/patches/atmprocfs_260t7.patch

How can this be needed?  When procfs is disabled then
remove_proc_entry() is defined as "do { } while (0)", ie. a nop.

Re: patches for PROC_FS=n (2.6.0-test7)

[Sam Ravnborg]

On Sat, Oct 11, 2003 at 12:08:52PM -0700, David S. Miller wrote:
> On Fri, 10 Oct 2003 14:16:46 -0700
> "Randy.Dunlap" <rddunlap@osdl.org> wrote:
> 
> > http://developer.osdl.org/rddunlap/patches/atmprocfs_260t7.patch
> 
> How can this be needed?  When procfs is disabled then
> remove_proc_entry() is defined as "do { } while (0)", ie. a nop.

Due to this - the real offender:

from: net/atm/clip.c:
#ifdef CONFIG_PROC_FS
#include <linux/proc_fs.h>
#include <linux/seq_file.h>
#endif

	Sam

Re: patches for PROC_FS=n (2.6.0-test7)

[David S. Miller]

On Sat, 11 Oct 2003 21:40:08 +0200
Sam Ravnborg <sam@ravnborg.org> wrote:

> Due to this - the real offender:
> 
> from: net/atm/clip.c:
> #ifdef CONFIG_PROC_FS
> #include <linux/proc_fs.h>
> #include <linux/seq_file.h>
> #endif

That makes a whole lot more sense, here is the fix I just
checked in:

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1352  -> 1.1353 
#	      net/atm/clip.c	1.26    -> 1.27   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/10/11	davem@nuts.ninka.net	1.1353
# [ATM]: Kill PROC_FS ifdef around includes.
# --------------------------------------------
#
diff -Nru a/net/atm/clip.c b/net/atm/clip.c
--- a/net/atm/clip.c	Sat Oct 11 12:43:12 2003
+++ b/net/atm/clip.c	Sat Oct 11 12:43:12 2003
@@ -24,10 +24,8 @@
 #include <linux/if.h> /* for IFF_UP */
 #include <linux/inetdevice.h>
 #include <linux/bitops.h>
-#ifdef CONFIG_PROC_FS
 #include <linux/proc_fs.h>
 #include <linux/seq_file.h>
-#endif
 #include <net/route.h> /* for struct rtable and routing */
 #include <net/icmp.h> /* icmp_send */
 #include <asm/param.h> /* for HZ */

Re: patches for PROC_FS=n (2.6.0-test7)

[Randy.Dunlap]

On Sat, 11 Oct 2003 21:40:08 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:

| On Sat, Oct 11, 2003 at 12:08:52PM -0700, David S. Miller wrote:
| > On Fri, 10 Oct 2003 14:16:46 -0700
| > "Randy.Dunlap" <rddunlap@osdl.org> wrote:
| > 
| > > http://developer.osdl.org/rddunlap/patches/atmprocfs_260t7.patch
| > 
| > How can this be needed?  When procfs is disabled then
| > remove_proc_entry() is defined as "do { } while (0)", ie. a nop.
| 
| Due to this - the real offender:
| 
| from: net/atm/clip.c:
| #ifdef CONFIG_PROC_FS
| #include <linux/proc_fs.h>
| #include <linux/seq_file.h>
| #endif

ugh, thanks.

--
~Randy

Re: patches for PROC_FS=n (2.6.0-test7)

[Randy.Dunlap]

On Fri, 10 Oct 2003 16:06:29 -0700 (PDT) "Noah J. Misch" <noah@caltech.edu> wrote:

| > There are several other drivers/protocols that don't build
| > with PROC_FS=n, like arlan, siimage, ipx, llc, and bluetooth.
| 
| I put in a patch for ipx yesterday, and I have patches for siimage and llc
| pretty much ready to go.  I noticed the others but I have not done much.

ipx is merged.  I'll leave siimage and llc to Noah.
Patch below fixes af_bluetooth.  Comments on it?

--
~Randy


patch_name:	bt_noprocfs.patch
patch_version:	2003-10-12.19:11:03
author:		Randy.Dunlap <rddunlap@osdl.org>
description:	af_bluetooth uses/needs proc_bt when PROC_FS=n
product:	Linux
product_versions: 2.6.0-test7
diffstat:	=
 net/bluetooth/af_bluetooth.c |    2 --
 1 files changed, 2 deletions(-)


diff -Naur ./net/bluetooth/af_bluetooth.c~btprocfs ./net/bluetooth/af_bluetooth.c
--- ./net/bluetooth/af_bluetooth.c~btprocfs	2003-10-08 12:24:02.000000000 -0700
+++ ./net/bluetooth/af_bluetooth.c	2003-10-12 19:09:11.000000000 -0700
@@ -56,9 +56,7 @@
 #define BT_DBG( A... )
 #endif
 
-#ifdef CONFIG_PROC_FS
 struct proc_dir_entry *proc_bt;
-#endif
 
 /* Bluetooth sockets */
 #define BT_MAX_PROTO	5

Re: patches for PROC_FS=n (2.6.0-test7)

[Noah J. Misch]

Randy,

That fix looks like the best to me.  I did notice also that proc_bt_rfcomm and
proc_bt_hci have similar #ifdef wrappers.  I think that's okay since they aren't
EXPORT_SYMBOL-ed, and they're used in fewer places.

FYI, IPX won't compile without CONFIG_PROC_FS at this time.  The merged patch
depended on a patch that I sent to Linus and posted to linux-kernel alongside
the IPX patch.  I also sent them to linux-net (accidentally, instead of netdev).
I may need to resend that patch.  In the mean time, if you actually need to use
IPX without procfs, you can grab the patch (and rationale) here:
http://www.ussg.iu.edu/hypermail/linux/kernel/0310.1/0452.html

FYI #2, from elsewhere in the department of fixing exotic breakage, I'm working
on patches that will allow one to compile a linux kernel under Unix and other
similar systems.  I've gotten allnoconfig for i386 to build from Solaris 2.7 on
sun4u, but a number of the userspace tools that support the build process of
optional components need a bit more help.

On Sun, 12 Oct 2003, Randy.Dunlap wrote:

> On Fri, 10 Oct 2003 16:06:29 -0700 (PDT) "Noah J. Misch" <noah@caltech.edu> wrote:
>
> | > There are several other drivers/protocols that don't build
> | > with PROC_FS=n, like arlan, siimage, ipx, llc, and bluetooth.
> |
> | I put in a patch for ipx yesterday, and I have patches for siimage and llc
> | pretty much ready to go.  I noticed the others but I have not done much.
>
> ipx is merged.  I'll leave siimage and llc to Noah.
> Patch below fixes af_bluetooth.  Comments on it?
>
> --
> ~Randy
>
>
> patch_name:	bt_noprocfs.patch
> patch_version:	2003-10-12.19:11:03
> author:		Randy.Dunlap <rddunlap@osdl.org>
> description:	af_bluetooth uses/needs proc_bt when PROC_FS=n
> product:	Linux
> product_versions: 2.6.0-test7
> diffstat:	=
>  net/bluetooth/af_bluetooth.c |    2 --
>  1 files changed, 2 deletions(-)
>
>
> diff -Naur ./net/bluetooth/af_bluetooth.c~btprocfs ./net/bluetooth/af_bluetooth.c
> --- ./net/bluetooth/af_bluetooth.c~btprocfs	2003-10-08 12:24:02.000000000 -0700
> +++ ./net/bluetooth/af_bluetooth.c	2003-10-12 19:09:11.000000000 -0700
> @@ -56,9 +56,7 @@
>  #define BT_DBG( A... )
>  #endif
>
> -#ifdef CONFIG_PROC_FS
>  struct proc_dir_entry *proc_bt;
> -#endif
>
>  /* Bluetooth sockets */
>  #define BT_MAX_PROTO	5
>
>

Re: patches for PROC_FS=n (2.6.0-test7)

[Randy.Dunlap]

On Fri, 10 Oct 2003 16:06:29 -0700 (PDT) "Noah J. Misch" <noah@caltech.edu> wrote:

| > There are several other drivers/protocols that don't build
| > with PROC_FS=n, like arlan, siimage, ipx, llc, and bluetooth.


Here's a patch for the wireless/arlan driver for PROC_FS=n.
Currently it defines both a function and a macro for
init_arlan_proc() if PROC_FS=n.  This causes a bunch of
compile-time errors.

It looks to me like it should always call the init_arlan_proc()
(and cleanup_arlan_proc()) functions since it inits some sysctl tables.
Or am I misunderstanding it?

Thanks,
--
~Randy


patch_name:	arlan_noprocfs.patch
patch_version:	2003-10-12.19:46:24
author:		Randy.Dunlap <rddunlap@osdl.org>
description:	use init_arlan_proc() for sysctl inits
product:	Linux
product_versions: 2.6.0-test7
diffstat:	=
 drivers/net/wireless/arlan.h |    5 -----
 1 files changed, 5 deletions(-)


diff -Naur ./drivers/net/wireless/arlan.h~arlanprocfs ./drivers/net/wireless/arlan.h
--- ./drivers/net/wireless/arlan.h~arlanprocfs	2003-10-08 12:24:08.000000000 -0700
+++ ./drivers/net/wireless/arlan.h	2003-10-12 19:45:46.000000000 -0700
@@ -39,13 +39,8 @@
 #define ARLAN_RCV_PROMISC 1
 #define ARLAN_RCV_CONTROL 2
 
-#ifdef CONFIG_PROC_FS
 extern int init_arlan_proc(void);
 extern void cleanup_arlan_proc(void);
-#else
-#define init_arlan_proc()	(0)
-#define cleanup_arlan_proc()	do { } while (0);
-#endif
 
 extern struct net_device *arlan_device[MAX_ARLANS];
 extern int	arlan_debug;

Re: patches for PROC_FS=n (2.6.0-test7)

[Elmer]

arlan.c is ok without arlan-proc.c
as init_arlan_proc is in arlan-proc.c, it shoult be
OK, as long as radio parameters are saved into cards ROM.

I have forgot a lot about that code, of course.



Elmer

Re: patches for PROC_FS=n (2.6.0-test7)

[Randy.Dunlap]

On Mon, 13 Oct 2003 13:31:30 +0200 (EET) Elmer <elmer@linking.ee> wrote:

| 
| 
| arlan.c is ok without arlan-proc.c
| as init_arlan_proc is in arlan-proc.c, it shoult be
| OK, as long as radio parameters are saved into cards ROM.
| 
| I have forgot a lot about that code, of course.

Hi Elmer,
Sure, I understand the last comment.

I don't quite understand the first paragraph though.
Could we try again?

Currently arlan.c + arlan-proc.c does not build if CONFIG_PROC_FS=n.
The Makefile always builds arlan-main.o and arlan-proc.o.
Are you saying that this is incorrect?
Should arlan-proc.o only be built/used when CONFIG_PROC_FS=y?

Thanks.
--
~Randy

Re: patches for PROC_FS=n (2.6.0-test7)

[Noah J. Misch]

Randy,

I poked around the driver a bit and uncovered a few points that suggest to me a
different approach to the problem.

The file arlan-proc.c contains a number of functions supporting the driver's
sysctl interface.  Nothing in that file appears procfs-specific.

I would change the Makefile to compile arlan-proc.c depending on CONFIG_SYSCTL
and remove the #ifdef CONFIG_PROC_FS guarding much of that file.  I would then
make arlan.h define macro or static inline stubs for init_arlan_proc and
cleanup_arlan_proc much like the current arlan.h does.

For the matter, perhaps one could add an extra config option, ARLAN_SYSCTL, that
depends on ARLAN and SYSCTL, and conditional-compile arlan-proc.c on that
instead of CONFIG_SYSCTL itself.  That way, users could leave it out to save
space without zapping all sysctls.  I would go for this approach myself.

The configuration help text for the arlan driver claims that it builds a module
for the driver and another for its sysctl interface.  It doesn't do that at the
moment, but that is another option (though not one I like as much).

What do you think?

On Sun, 12 Oct 2003, Randy.Dunlap wrote:

> On Fri, 10 Oct 2003 16:06:29 -0700 (PDT) "Noah J. Misch" <noah@caltech.edu> wrote:
>
> | > There are several other drivers/protocols that don't build
> | > with PROC_FS=n, like arlan, siimage, ipx, llc, and bluetooth.
>
>
> Here's a patch for the wireless/arlan driver for PROC_FS=n.
> Currently it defines both a function and a macro for
> init_arlan_proc() if PROC_FS=n.  This causes a bunch of
> compile-time errors.
>
> It looks to me like it should always call the init_arlan_proc()
> (and cleanup_arlan_proc()) functions since it inits some sysctl tables.
> Or am I misunderstanding it?
>
> Thanks,
> --
> ~Randy
>
>
> patch_name:	arlan_noprocfs.patch
> patch_version:	2003-10-12.19:46:24
> author:		Randy.Dunlap <rddunlap@osdl.org>
> description:	use init_arlan_proc() for sysctl inits
> product:	Linux
> product_versions: 2.6.0-test7
> diffstat:	=
>  drivers/net/wireless/arlan.h |    5 -----
>  1 files changed, 5 deletions(-)
>
>
> diff -Naur ./drivers/net/wireless/arlan.h~arlanprocfs ./drivers/net/wireless/arlan.h
> --- ./drivers/net/wireless/arlan.h~arlanprocfs	2003-10-08 12:24:08.000000000 -0700
> +++ ./drivers/net/wireless/arlan.h	2003-10-12 19:45:46.000000000 -0700
> @@ -39,13 +39,8 @@
>  #define ARLAN_RCV_PROMISC 1
>  #define ARLAN_RCV_CONTROL 2
>
> -#ifdef CONFIG_PROC_FS
>  extern int init_arlan_proc(void);
>  extern void cleanup_arlan_proc(void);
> -#else
> -#define init_arlan_proc()	(0)
> -#define cleanup_arlan_proc()	do { } while (0);
> -#endif
>
>  extern struct net_device *arlan_device[MAX_ARLANS];
>  extern int	arlan_debug;
>
>

Re: patches for PROC_FS=n (2.6.0-test7)

[Randy.Dunlap]

On Mon, 13 Oct 2003 22:52:56 -0700 (PDT) "Noah J. Misch" <noah@caltech.edu> wrote:

| Randy,
| 
| I poked around the driver a bit and uncovered a few points that suggest to me a
| different approach to the problem.
| 
| The file arlan-proc.c contains a number of functions supporting the driver's
| sysctl interface.  Nothing in that file appears procfs-specific.

Right.

| I would change the Makefile to compile arlan-proc.c depending on CONFIG_SYSCTL
| and remove the #ifdef CONFIG_PROC_FS guarding much of that file.  I would then
| make arlan.h define macro or static inline stubs for init_arlan_proc and
| cleanup_arlan_proc much like the current arlan.h does.

That's about what I was planning to do next if I didn't hear anything
else from Elmer.

| For the matter, perhaps one could add an extra config option, ARLAN_SYSCTL, that
| depends on ARLAN and SYSCTL, and conditional-compile arlan-proc.c on that
| instead of CONFIG_SYSCTL itself.  That way, users could leave it out to save
| space without zapping all sysctls.  I would go for this approach myself.

I wouldn't prefer this, but if you make the patch, do whatever you want.
I think that CONFIG_SYSCTL should be enough to determine/decide/control it.

| The configuration help text for the arlan driver claims that it builds a module
| for the driver and another for its sysctl interface.  It doesn't do that at the
| moment, but that is another option (though not one I like as much).

I missed this config help text.  Glad you caught it.
But I wouldn't make that a separate module.

| What do you think?

Go ahead, your choice, but my preferences are above.


| On Sun, 12 Oct 2003, Randy.Dunlap wrote:
| 
| > On Fri, 10 Oct 2003 16:06:29 -0700 (PDT) "Noah J. Misch" <noah@caltech.edu> wrote:
| >
| > | > There are several other drivers/protocols that don't build
| > | > with PROC_FS=n, like arlan, siimage, ipx, llc, and bluetooth.
| >
| >
| > Here's a patch for the wireless/arlan driver for PROC_FS=n.
| > Currently it defines both a function and a macro for
| > init_arlan_proc() if PROC_FS=n.  This causes a bunch of
| > compile-time errors.
| >
| > It looks to me like it should always call the init_arlan_proc()
| > (and cleanup_arlan_proc()) functions since it inits some sysctl tables.
| > Or am I misunderstanding it?

Thanks.  And I hope that your mailbox is functional now.

--
~Randy

Re: patches for PROC_FS=n (2.6.0-test7)

[Elmer]

on the other hand,  consider following:

1. the card is shit, also, on ISA interface
2. most people do write configuration parameters into cards BIOS under DOS
and do not need interface for configuration.
3. all of contents should be in /proc/sys , as far as I remember, I have
tried to implement all via sysctl rather than procfs io.
4. there is a file, reading of which causes card reset. Most of people
need this.

Therefore sensible solution would be simple, whatever it is.

Elmer.