[PATCH] 2.5.27 sysctl

[PATCH] 2.5.27 sysctl

[Marcin Dalecki]

[-- Attachment #1: Type: text/plain, Size: 199 bytes --]

This is making the sysctl code acutally be written in C.
It wasn't mostly due to georgeous ommitted size array "forward
declarations". As a side effect it makes the table structure easier to
deduce.

[-- Attachment #2: sysctl-2.5.27.diff --]
[-- Type: text/plain, Size: 7694 bytes --]

diff -urN linux-2.5.27/include/linux/sysctl.h linux/include/linux/sysctl.h
--- linux-2.5.27/include/linux/sysctl.h	2002-07-20 21:11:05.000000000 +0200
+++ linux/include/linux/sysctl.h	2002-07-21 19:30:43.000000000 +0200
@@ -126,7 +126,7 @@
 	KERN_S390_USER_DEBUG_LOGGING=51,  /* int: dumps of user faults */
 	KERN_CORE_USES_PID=52,		/* int: use core or core.%pid */
 	KERN_TAINTED=53,	/* int: various kernel tainted flags */
-	KERN_CADPID=54,		/* int: PID of the process to notify on CAD */
+	KERN_CADPID=54		/* int: PID of the process to notify on CAD */
 };
 
 
@@ -148,7 +148,7 @@
 	VM_DIRTY_SYNC=13,	/* dirty_sync_ratio */
 	VM_DIRTY_WB_CS=14,	/* dirty_writeback_centisecs */
 	VM_DIRTY_EXPIRE_CS=15,	/* dirty_expire_centisecs */
-	VM_NR_PDFLUSH_THREADS=16, /* nr_pdflush_threads */
+	VM_NR_PDFLUSH_THREADS=16 /* nr_pdflush_threads */
 };
 
 
@@ -225,7 +225,7 @@
 {
 	NET_UNIX_DESTROY_DELAY=1,
 	NET_UNIX_DELETE_DELAY=2,
-	NET_UNIX_MAX_DGRAM_QLEN=3,
+	NET_UNIX_MAX_DGRAM_QLEN=3
 };
 
 /* /proc/sys/net/ipv4 */
@@ -344,7 +344,7 @@
 	NET_IPV4_CONF_LOG_MARTIANS=11,
 	NET_IPV4_CONF_TAG=12,
 	NET_IPV4_CONF_ARPFILTER=13,
-	NET_IPV4_CONF_MEDIUM_ID=14,
+	NET_IPV4_CONF_MEDIUM_ID=14
 };
 
 /* /proc/sys/net/ipv6 */
@@ -553,7 +553,7 @@
 	FS_LEASES=13,	/* int: leases enabled */
 	FS_DIR_NOTIFY=14,	/* int: directory notification enabled */
 	FS_LEASE_TIME=15,	/* int: maximum time to wait for a lease break */
-	FS_DQSTATS=16,	/* disc quota usage statistics */
+	FS_DQSTATS=16	/* disc quota usage statistics */
 };
 
 /* /proc/sys/fs/quota/ */
@@ -565,7 +565,7 @@
 	FS_DQ_CACHE_HITS = 5,
 	FS_DQ_ALLOCATED = 6,
 	FS_DQ_FREE = 7,
-	FS_DQ_SYNCS = 8,
+	FS_DQ_SYNCS = 8
 };
 
 /* CTL_DEBUG names: */
@@ -619,12 +619,12 @@
 
 /* /proc/sys/dev/parport/parport n/devices/ */
 enum {
-	DEV_PARPORT_DEVICES_ACTIVE=-3,
+	DEV_PARPORT_DEVICES_ACTIVE=-3
 };
 
 /* /proc/sys/dev/parport/parport n/devices/device n */
 enum {
-	DEV_PARPORT_DEVICE_TIMESLICE=1,
+	DEV_PARPORT_DEVICE_TIMESLICE=1
 };
 
 /* /proc/sys/dev/mac_hid */
@@ -645,7 +645,7 @@
 	ABI_DEFHANDLER_LCALL7=3,/* default handler for procs using lcall7 */
 	ABI_DEFHANDLER_LIBCSO=4,/* default handler for an libc.so ELF interp */
 	ABI_TRACE=5,		/* tracing flags */
-	ABI_FAKE_UTSNAME=6,	/* fake target utsname information */
+	ABI_FAKE_UTSNAME=6	/* fake target utsname information */
 };
 
 #ifdef __KERNEL__
diff -urN linux-2.5.27/kernel/sysctl.c linux/kernel/sysctl.c
--- linux-2.5.27/kernel/sysctl.c	2002-07-20 21:11:07.000000000 +0200
+++ linux/kernel/sysctl.c	2002-07-21 19:30:43.000000000 +0200
@@ -102,59 +102,10 @@
 static int proc_doutsstring(ctl_table *table, int write, struct file *filp,
 		  void *buffer, size_t *lenp);
 
-static ctl_table root_table[];
-static struct ctl_table_header root_table_header =
-	{ root_table, LIST_HEAD_INIT(root_table_header.ctl_entry) };
-
-static ctl_table kern_table[];
-static ctl_table vm_table[];
-#ifdef CONFIG_NET
-extern ctl_table net_table[];
-#endif
-static ctl_table proc_table[];
-static ctl_table fs_table[];
-static ctl_table debug_table[];
-static ctl_table dev_table[];
 extern ctl_table random_table[];
 
-/* /proc declarations: */
-
-#ifdef CONFIG_PROC_FS
-
-static ssize_t proc_readsys(struct file *, char *, size_t, loff_t *);
-static ssize_t proc_writesys(struct file *, const char *, size_t, loff_t *);
-static int proc_sys_permission(struct inode *, int);
-
-struct file_operations proc_sys_file_operations = {
-	read:		proc_readsys,
-	write:		proc_writesys,
-};
-
-static struct inode_operations proc_sys_inode_operations = {
-	permission:	proc_sys_permission,
-};
-
-extern struct proc_dir_entry *proc_sys_root;
-
-static void register_proc_table(ctl_table *, struct proc_dir_entry *);
-static void unregister_proc_table(ctl_table *, struct proc_dir_entry *);
-#endif
-
 /* The default sysctl tables: */
 
-static ctl_table root_table[] = {
-	{CTL_KERN, "kernel", NULL, 0, 0555, kern_table},
-	{CTL_VM, "vm", NULL, 0, 0555, vm_table},
-#ifdef CONFIG_NET
-	{CTL_NET, "net", NULL, 0, 0555, net_table},
-#endif
-	{CTL_PROC, "proc", NULL, 0, 0555, proc_table},
-	{CTL_FS, "fs", NULL, 0, 0555, fs_table},
-	{CTL_DEBUG, "debug", NULL, 0, 0555, debug_table},
-        {CTL_DEV, "dev", NULL, 0, 0555, dev_table},
-	{0}
-};
-
 static ctl_table kern_table[] = {
 	{KERN_OSTYPE, "ostype", system_utsname.sysname, 64,
 	 0444, NULL, &proc_doutsstring, &sysctl_string},
@@ -235,7 +186,7 @@
 #ifdef CONFIG_MAGIC_SYSRQ
 	{KERN_SYSRQ, "sysrq", &sysrq_enabled, sizeof (int),
 	 0644, NULL, &proc_dointvec},
-#endif	 
+#endif
 	{KERN_CADPID, "cad_pid", &cad_pid, sizeof (int),
 	 0600, NULL, &proc_dointvec},
 	{KERN_MAX_THREADS, "threads-max", &max_threads, sizeof(int),
@@ -264,7 +215,6 @@
 static int one = 1;
 static int one_hundred = 100;
 
-
 static ctl_table vm_table[] = {
 	{VM_OVERCOMMIT_MEMORY, "overcommit_memory", &sysctl_overcommit_memory,
 	 sizeof(sysctl_overcommit_memory), 0644, NULL, &proc_dointvec},
@@ -307,6 +257,10 @@
 	{0}
 };
 
+#ifdef CONFIG_NET
+extern ctl_table net_table[];
+#endif
+
 static ctl_table proc_table[] = {
 	{0}
 };
@@ -343,7 +297,48 @@
 
 static ctl_table dev_table[] = {
 	{0}
-};  
+};
+
+static ctl_table root_table[] = {
+	{CTL_KERN, "kernel", NULL, 0, 0555, kern_table},
+	{CTL_VM, "vm", NULL, 0, 0555, vm_table},
+#ifdef CONFIG_NET
+	{CTL_NET, "net", NULL, 0, 0555, net_table},
+#endif
+	{CTL_PROC, "proc", NULL, 0, 0555, proc_table},
+	{CTL_FS, "fs", NULL, 0, 0555, fs_table},
+	{CTL_DEBUG, "debug", NULL, 0, 0555, debug_table},
+        {CTL_DEV, "dev", NULL, 0, 0555, dev_table},
+	{0}
+};
+static struct ctl_table_header root_table_header =
+	{ root_table, LIST_HEAD_INIT(root_table_header.ctl_entry) };
+
+static ctl_table debug_table[];
+static ctl_table dev_table[];
+
+/* /proc declarations: */
+
+#ifdef CONFIG_PROC_FS
+
+static ssize_t proc_readsys(struct file *, char *, size_t, loff_t *);
+static ssize_t proc_writesys(struct file *, const char *, size_t, loff_t *);
+static int proc_sys_permission(struct inode *, int);
+
+struct file_operations proc_sys_file_operations = {
+	read:		proc_readsys,
+	write:		proc_writesys,
+};
+
+static struct inode_operations proc_sys_inode_operations = {
+	permission:	proc_sys_permission,
+};
+
+extern struct proc_dir_entry *proc_sys_root;
+
+static void register_proc_table(ctl_table *, struct proc_dir_entry *);
+static void unregister_proc_table(ctl_table *, struct proc_dir_entry *);
+#endif
 
 extern void init_irq_proc (void);
 
diff -urN linux-2.5.27/net/sunrpc/sysctl.c linux/net/sunrpc/sysctl.c
--- linux-2.5.27/net/sunrpc/sysctl.c	2002-07-20 21:11:07.000000000 +0200
+++ linux/net/sunrpc/sysctl.c	2002-07-21 19:30:43.000000000 +0200
@@ -33,29 +33,6 @@
 #ifdef RPC_DEBUG
 
 static struct ctl_table_header *sunrpc_table_header;
-static ctl_table		sunrpc_table[];
-
-void
-rpc_register_sysctl(void)
-{
-	if (!sunrpc_table_header) {
-		sunrpc_table_header = register_sysctl_table(sunrpc_table, 1);
-#ifdef CONFIG_PROC_FS
-		if (sunrpc_table[0].de)
-			sunrpc_table[0].de->owner = THIS_MODULE;
-#endif
-	}
-			
-}
-
-void
-rpc_unregister_sysctl(void)
-{
-	if (sunrpc_table_header) {
-		unregister_sysctl_table(sunrpc_table_header);
-		sunrpc_table_header = NULL;
-	}
-}
 
 static int
 proc_dodebug(ctl_table *table, int write, struct file *file,
@@ -135,4 +112,26 @@
 	{0}
 };
 
+void
+rpc_register_sysctl(void)
+{
+	if (!sunrpc_table_header) {
+		sunrpc_table_header = register_sysctl_table(sunrpc_table, 1);
+#ifdef CONFIG_PROC_FS
+		if (sunrpc_table[0].de)
+			sunrpc_table[0].de->owner = THIS_MODULE;
+#endif
+	}
+			
+}
+
+void
+rpc_unregister_sysctl(void)
+{
+	if (sunrpc_table_header) {
+		unregister_sysctl_table(sunrpc_table_header);
+		sunrpc_table_header = NULL;
+	}
+}
+
 #endif

Re: [PATCH] 2.5.27 sysctl

[Christoph Hellwig]

On Mon, Jul 22, 2002 at 12:42:07PM +0200, Marcin Dalecki wrote:
> This is making the sysctl code acutally be written in C.
> It wasn't mostly due to georgeous ommitted size array "forward
> declarations". As a side effect it makes the table structure easier to
> deduce.

Please don't remove the trailing commas in the enums.  they make adding
to them much easier and are allowed by gcc (and maybe C99, I'm not
sure).

Re: [PATCH] 2.5.27 sysctl

[Marcin Dalecki]

Christoph Hellwig wrote:
> On Mon, Jul 22, 2002 at 12:42:07PM +0200, Marcin Dalecki wrote:
> 
>>This is making the sysctl code acutally be written in C.
>>It wasn't mostly due to georgeous ommitted size array "forward
>>declarations". As a side effect it makes the table structure easier to
>>deduce.
> 
> 
> Please don't remove the trailing commas in the enums.  they make adding
> to them much easier and are allowed by gcc (and maybe C99, I'm not
> sure).

It's an GNU-ism. If you have any problem with "adding vales", just
invent some dummy end-value. I have a problem with using -pedantic.

Re: [PATCH] 2.5.27 sysctl

[Christoph Hellwig]

On Mon, Jul 22, 2002 at 12:56:07PM +0200, Marcin Dalecki wrote:
> > Please don't remove the trailing commas in the enums.  they make adding
> > to them much easier and are allowed by gcc (and maybe C99, I'm not
> > sure).
> 
> It's an GNU-ism.

So what?

The kernel is full of GNUisms, and this one is actually usefull.

> If you have any problem with "adding vales", just
> invent some dummy end-value. I have a problem with using -pedantic.

-pedantic barfs on named initializers, so you have to remove them first.

Re: [PATCH] 2.5.27 sysctl

[Marcin Dalecki]

Christoph Hellwig wrote:
> On Mon, Jul 22, 2002 at 12:56:07PM +0200, Marcin Dalecki wrote:
> 
>>>Please don't remove the trailing commas in the enums.  they make adding
>>>to them much easier and are allowed by gcc (and maybe C99, I'm not
>>>sure).
>>
>>It's an GNU-ism.
> 
> 
> So what?

So i did.

> 
> The kernel is full of GNUisms, and this one is actually usefull.

Its is not half as full as you may think.

Re: [PATCH] 2.5.27 sysctl

[Christoph Hellwig]

On Mon, Jul 22, 2002 at 12:56:07PM +0200, Marcin Dalecki wrote:
> It's an GNU-ism.

Actually I've looked it up in my copy of the last C99 draft:

	[#5]  This  edition  replaces  the previous edition, ISO/IEC |
	9899:1990,   as   amended   and   corrected    by    ISO/IEC |
	9899/COR1:1994,    ISO/IEC   9899/COR2:1995,   and   ISO/IEC |
	9899/AMD1:1995.  Major changes  from  the  previous  edition |
	include:

	[some stuff snipped]

  	  -- trailing comma allowed in enum declaration              |

So please let it in.

Re: [PATCH] 2.5.27 sysctl

[Dave Jones]

On Mon, Jul 22, 2002 at 12:56:07PM +0200, Marcin Dalecki wrote:

 > > Please don't remove the trailing commas in the enums.  they make adding
 > > to them much easier and are allowed by gcc (and maybe C99, I'm not
 > > sure).
 > It's an GNU-ism. If you have any problem with "adding vales", just
 > invent some dummy end-value. I have a problem with using -pedantic.

If you feel like doing 'warnings patrol', then there are a bunch of
more important regular warnings[1] that need fixing up without having to look
through the pedantic output. Last I checked the pedantic stuff flagged
a lot of bits that the fix ended up uglier than the warning
(which 99.9% of people won't ever see anyway)

        Dave

[1] Although more important would be stabilising IDE, but thats a sidenote.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH] 2.5.27 sysctl

[bart]

On 22 Jul, Marcin Dalecki wrote:
> Christoph Hellwig wrote:
>> On Mon, Jul 22, 2002 at 12:42:07PM +0200, Marcin Dalecki wrote:
>> 
>>>This is making the sysctl code acutally be written in C.
>>>It wasn't mostly due to georgeous ommitted size array "forward
>>>declarations". As a side effect it makes the table structure easier to
>>>deduce.
>> 
>> 
>> Please don't remove the trailing commas in the enums.  they make adding
>> to them much easier and are allowed by gcc (and maybe C99, I'm not
>> sure).
> 
> It's an GNU-ism. If you have any problem with "adding vales", just
> invent some dummy end-value. I have a problem with using -pedantic.
> 

Trailing commas in enums were NOT allowed before C99. C99 allows them,
and gcc and some other compilers allowed this syntax before C99. 
Since the kernel is going to use the .field= (C99) syntax for structure
initialisers anyway, I don't see any point in removing trailing commas.
(Especially not in code I once wrote :-))

As an aside, the fact that gcc warns about them is probably a compiler
bug: (http://gcc.gnu.org/c99status.html)
'In some places, -pedantic warnings don't take proper account of the
standard version selected.'

Bart

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

-- 
Bart Hartgers - TUE Eindhoven 
http://plasimo.phys.tue.nl/bart/contact.html

Re: [PATCH] 2.5.27 sysctl

[Marcin Dalecki]

Alan Cox wrote:
> On Mon, 2002-07-22 at 11:56, Marcin Dalecki wrote:
> 
>>Christoph Hellwig wrote:
>>
>>>On Mon, Jul 22, 2002 at 12:42:07PM +0200, Marcin Dalecki wrote:
>>>
>>>
>>>>This is making the sysctl code acutally be written in C.
>>>>It wasn't mostly due to georgeous ommitted size array "forward
>>>>declarations". As a side effect it makes the table structure easier to
>>>>deduce.
>>>
>>>
>>>Please don't remove the trailing commas in the enums.  they make adding
>>>to them much easier and are allowed by gcc (and maybe C99, I'm not
>>>sure).
>>
>>It's an GNU-ism. If you have any problem with "adding vales", just
>>invent some dummy end-value. I have a problem with using -pedantic.
> 
> 
> You seem to have it permanently engaged 8)
> 
> If you are upset about that GNUism why doesn't your patch fix the other
> GNU-isms in the same file ? Also the entire kernel is *full* of GNU C
> extensions.

That's a common rumour. struct inits are going to go anyway.
The rest is only about 30 ({ ... }) in inclue/linux.
Of course some of the GNU extensions are actually usefull.
Trailing , at enum declarations make up for a nice shift reduce conflict
expirence in yacc. (And perhaps slower compilation...)

RE: [PATCH] 2.5.27 sysctl

[BALBIR SINGH]

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

|-----Original Message-----
|From: linux-kernel-owner@vger.kernel.org 
|[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Marcin Dalecki
|Sent: Monday, July 22, 2002 4:26 PM
|To: Christoph Hellwig
|Cc: martin@dalecki.de; Linus Torvalds; Kernel Mailing List
|Subject: Re: [PATCH] 2.5.27 sysctl
|
|
|Christoph Hellwig wrote:
|> On Mon, Jul 22, 2002 at 12:42:07PM +0200, Marcin Dalecki wrote:
|> 
|>>This is making the sysctl code acutally be written in C.
|>>It wasn't mostly due to georgeous ommitted size array "forward 
|>>declarations". As a side effect it makes the table structure 
|easier to 
|>>deduce.
|> 
|> 
|> Please don't remove the trailing commas in the enums.  they make 
|> adding to them much easier and are allowed by gcc (and maybe 
|C99, I'm 
|> not sure).
|
|It's an GNU-ism. If you have any problem with "adding vales", 
|just invent some dummy end-value. I have a problem with using 
|-pedantic.

Its not, ANSI C allows a trailing comma.

Balbir


[-- Attachment #2: Wipro_Disclaimer.txt --]
[-- Type: text/plain, Size: 490 bytes --]

**************************Disclaimer************************************

Information contained in this E-MAIL being proprietary to Wipro Limited is 
'privileged' and 'confidential' and intended for use only by the individual
 or entity to which it is addressed. You are notified that any use, copying 
or dissemination of the information contained in the E-MAIL in any manner 
whatsoever is strictly prohibited.

***************************************************************************

Re: [PATCH] 2.5.27 sysctl

[Alan Cox]

On Mon, 2002-07-22 at 11:56, Marcin Dalecki wrote:
> Christoph Hellwig wrote:
> > On Mon, Jul 22, 2002 at 12:42:07PM +0200, Marcin Dalecki wrote:
> > 
> >>This is making the sysctl code acutally be written in C.
> >>It wasn't mostly due to georgeous ommitted size array "forward
> >>declarations". As a side effect it makes the table structure easier to
> >>deduce.
> > 
> > 
> > Please don't remove the trailing commas in the enums.  they make adding
> > to them much easier and are allowed by gcc (and maybe C99, I'm not
> > sure).
> 
> It's an GNU-ism. If you have any problem with "adding vales", just
> invent some dummy end-value. I have a problem with using -pedantic.

You seem to have it permanently engaged 8)

If you are upset about that GNUism why doesn't your patch fix the other
GNU-isms in the same file ? Also the entire kernel is *full* of GNU C
extensions.

Re: [PATCH] 2.5.27 sysctl

[Alexander Viro]

On Mon, 22 Jul 2002, Marcin Dalecki wrote:

> > The kernel is full of GNUisms, and this one is actually usefull.
> 
> Its is not half as full as you may think.

Trailing comma in enums has _exactly_ the same status as .foo = bar in
structure initializers.  Both appear in C99 and were compiler-specific
extensions before that.

If -pedantic is unhappy about one but not another - take it with gcc
folks, it's a bug in gcc.

Speaking of GNUisms, inline assembler is one and it's by far the worst
obstacle to portability.  Speaking of *REALLY* ugly stuff - may I point
you to abuses of ##?  Yes, it's legal C.  No, using it is a Bad Idea(tm).
And the actual uses of _that_ one in the tree can give you the second
look at your breakfast - grep around and you'll see.

Re: [PATCH] 2.5.27 sysctl

[Marcin Dalecki]

Alexander Viro wrote:
> 
> On Mon, 22 Jul 2002, Marcin Dalecki wrote:
> 
> 
>>>The kernel is full of GNUisms, and this one is actually usefull.
>>
>>Its is not half as full as you may think.
> 
> 
> Trailing comma in enums has _exactly_ the same status as .foo = bar in
> structure initializers.  Both appear in C99 and were compiler-specific
> extensions before that.

Yes the C99 people did give in on this point :-). But only until
recently. And really the only way to find out what the warinigs
are about is to have a look at cparse.y...

> If -pedantic is unhappy about one but not another - take it with gcc
> folks, it's a bug in gcc.
> 
> Speaking of GNUisms, inline assembler is one and it's by far the worst
> obstacle to portability. 

Sure, but this extension is actually a justifyed one.

 > Speaking of *REALLY* ugly stuff - may I point
> you to abuses of ##?  Yes, it's legal C.  No, using it is a Bad Idea(tm).
> And the actual uses of _that_ one in the tree can give you the second
> look at your breakfast - grep around and you'll see.

Da, kanieczna. Ja znaju: It's resulting in semi "self modifying" code.
Sometimes usefull but not in 80% where they are actually used is the
({ ... }) extension for example as well. In most of the cases where its
used we should simply rely on the fact that gcc got now much better at
doing function inlining instead. See the spinlock patch for example.
Best abuse example are the byte swapping macros...

But one quite justifyed example of usage is the
wait_event_interruptible(), where it's used to assert repeated condition
evaluation. However this puts the fact aside that 
wait_event_interruptible() isn't a polite abstraction in first place...

Re: [PATCH] 2.5.27 sysctl

[Daniel Egger]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

Am Mon, 2002-07-22 um 12.42 schrieb Marcin Dalecki:

> diff -urN linux-2.5.27/include/linux/sysctl.h linux/include/linux/sysctl.h
> --- linux-2.5.27/include/linux/sysctl.h	2002-07-20 21:11:05.000000000 +0200
> +++ linux/include/linux/sysctl.h	2002-07-21 19:30:43.000000000 +0200
> @@ -126,7 +126,7 @@
>  	KERN_S390_USER_DEBUG_LOGGING=51,  /* int: dumps of user faults */
>  	KERN_CORE_USES_PID=52,		/* int: use core or core.%pid */
>  	KERN_TAINTED=53,	/* int: various kernel tainted flags */
> -	KERN_CADPID=54,		/* int: PID of the process to notify on CAD */
> +	KERN_CADPID=54		/* int: PID of the process to notify on CAD */
>  };

Please don't do such changes, there's a reason for the trailing comma:
Making it easier to extend structures and enums.

-- 
Servus,
       Daniel

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] 2.5.27 sysctl

[Ray Lee]

Hello there,

> This is making the sysctl code acutally be written in C.
> It wasn't mostly due to georgeous ommitted size array "forward
> declarations". As a side effect it makes the table structure easier to
> deduce.
>
> diff -urN linux-2.5.27/include/linux/sysctl.h linux/include/linux/sysctl.h
> --- linux-2.5.27/include/linux/sysctl.h 2002-07-20 21:11:05.000000000 +0200
> +++ linux/include/linux/sysctl.h 2002-07-21 19:30:43.000000000 +0200
> @@ -126,7 +126,7 @@
>          KERN_S390_USER_DEBUG_LOGGING=51, /* int: dumps of user faults */
>          KERN_CORE_USES_PID=52, /* int: use core or core.%pid */
>          KERN_TAINTED=53, /* int: various kernel tainted flags */
> - KERN_CADPID=54, /* int: PID of the process to notify on CAD */
> + KERN_CADPID=54 /* int: PID of the process to notify on CAD */
>  };

<snip>
 
The comma changes are gratuitous, as pure ANSI C explicitly allows such
constructs. (It was intended to simplify automatic code generation, as
well as for programmer ease to automatically deal with initializer
lists.)

>From the grammar section of the 2nd edition (ca. 1988) of K&R:
	initializer:
		assignment-expression
		{ initializer-list }
		{ initializer-list , }

...where initializer list is what one would expect.

Removing the size forward declarations does make the code quicker to
read, though.

Ray

Re: [Patch] 2.5.27 sysctl

[Marco C. Mason]

> > This is making the sysctl code acutally be written in C.
> > It wasn't mostly due to georgeous ommitted size array "forward
> > declarations". As a side effect it makes the table structure easier
to
> > deduce.

<snip>

> The comma changes are gratuitous, as pure ANSI C explicitly allows
such
> constructs. (It was intended to simplify automatic code generation, as

> well as for programmer ease to automatically deal with initializer
> lists.)

> >From the grammar section of the 2nd edition (ca. 1988) of K&R:
>        initializer:
>                assignment-expression
>                { initializer-list }
>                { initializer-list , }
>
> ...where initializer list is what one would expect.

Yeah, it's hard to see it as an "extension" when my copy of K&R (1978)
shows the same thing...

--marco