[2.6 patch] make UNIX a bool

[2.6 patch] make UNIX a bool

[Adrian Bunk]

CONFIG_UNIX=m doesn't make much sense.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 20 Feb 2006

--- linux-2.6.16-rc4-mm1-full/net/unix/Kconfig.old	2006-02-20 14:40:19.000000000 +0100
+++ linux-2.6.16-rc4-mm1-full/net/unix/Kconfig	2006-02-20 14:40:27.000000000 +0100
@@ -3,7 +3,7 @@
 #
 
 config UNIX
-	tristate "Unix domain sockets"
+	bool "Unix domain sockets"
 	---help---
 	  If you say Y here, you will include support for Unix domain sockets;
 	  sockets are the standard Unix mechanism for establishing and

Re: [2.6 patch] make UNIX a bool

[Stephen Hemminger]

Adrian Bunk wrote:
> CONFIG_UNIX=m doesn't make much sense.
>
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
>
>   
Why? You can build unix domain sockets as a loadable module and
it runs fine (or it did last I tried). Whether that makes sense from a 
distribution point of
view, because everybody wants it, is another story.

Re: [2.6 patch] make UNIX a bool

[Arjan van de Ven]

On Sat, 2006-02-25 at 09:13 -0800, Stephen Hemminger wrote:
> Adrian Bunk wrote:
> > CONFIG_UNIX=m doesn't make much sense.
> >
> >
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
> >
> >
> >   
> Why? You can build unix domain sockets as a loadable module and
> it runs fine (or it did last I tried). Whether that makes sense from a 
> distribution point of
you didn't use to when modutils used unix sockets internally :)

unix also needs a bunch of deeply internals exported that apparently
people want to play with...

Re: [2.6 patch] make UNIX a bool

[Diego Calleja]

El Sat, 25 Feb 2006 09:13:08 -0800,
Stephen Hemminger <shemminger@osdl.org> escribió:

> Why? You can build unix domain sockets as a loadable module and
> it runs fine (or it did last I tried). Whether that makes sense from a 

I've been running with CONFIG_UNIX=m since the dawn of time and everything
seems to work - not that I care if it's disabled, I just wanted to
confirm that it works.

Re: [2.6 patch] make UNIX a bool

[Olaf Hering]

 On Sat, Feb 25, Adrian Bunk wrote:

> CONFIG_UNIX=m doesn't make much sense.

There is likely more code to support a modular unix.ko, this has to go
as well.

[2.6 patch] make UNIX a bool

[Adrian Bunk]

On Sat, Feb 25, 2006 at 11:46:31PM +0100, Olaf Hering wrote:
>  On Sat, Feb 25, Adrian Bunk wrote:
> 
> > CONFIG_UNIX=m doesn't make much sense.
> 
> There is likely more code to support a modular unix.ko, this has to go
> as well.

Sounds resonable, updated patch below.

cu
Adrian


<--  snip  -->


CONFIG_UNIX=m doesn't make that much sense and requires us to export 
things we don't want to export to modules.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 fs/file_table.c            |    1 -
 include/net/af_unix.h      |    2 --
 net/unix/Kconfig           |    2 +-
 net/unix/af_unix.c         |   18 ------------------
 net/unix/sysctl_net_unix.c |    9 +--------
 5 files changed, 2 insertions(+), 30 deletions(-)

--- linux-2.6.16-mm1-full/net/unix/Kconfig.old	2006-03-25 20:10:47.000000000 +0100
+++ linux-2.6.16-mm1-full/net/unix/Kconfig	2006-03-25 20:10:54.000000000 +0100
@@ -3,7 +3,7 @@
 #
 
 config UNIX
-	tristate "Unix domain sockets"
+	bool "Unix domain sockets"
 	---help---
 	  If you say Y here, you will include support for Unix domain sockets;
 	  sockets are the standard Unix mechanism for establishing and
--- linux-2.6.16-mm1-full/include/net/af_unix.h.old	2006-03-25 20:13:33.000000000 +0100
+++ linux-2.6.16-mm1-full/include/net/af_unix.h	2006-03-25 20:13:40.000000000 +0100
@@ -85,10 +85,8 @@
 #ifdef CONFIG_SYSCTL
 extern int sysctl_unix_max_dgram_qlen;
 extern void unix_sysctl_register(void);
-extern void unix_sysctl_unregister(void);
 #else
 static inline void unix_sysctl_register(void) {}
-static inline void unix_sysctl_unregister(void) {}
 #endif
 #endif
 #endif
--- linux-2.6.16-mm1-full/net/unix/af_unix.c.old	2006-03-25 20:11:07.000000000 +0100
+++ linux-2.6.16-mm1-full/net/unix/af_unix.c	2006-03-25 20:14:05.000000000 +0100
@@ -475,7 +475,6 @@
 
 static const struct proto_ops unix_stream_ops = {
 	.family =	PF_UNIX,
-	.owner =	THIS_MODULE,
 	.release =	unix_release,
 	.bind =		unix_bind,
 	.connect =	unix_stream_connect,
@@ -496,7 +495,6 @@
 
 static const struct proto_ops unix_dgram_ops = {
 	.family =	PF_UNIX,
-	.owner =	THIS_MODULE,
 	.release =	unix_release,
 	.bind =		unix_bind,
 	.connect =	unix_dgram_connect,
@@ -517,7 +515,6 @@
 
 static const struct proto_ops unix_seqpacket_ops = {
 	.family =	PF_UNIX,
-	.owner =	THIS_MODULE,
 	.release =	unix_release,
 	.bind =		unix_bind,
 	.connect =	unix_stream_connect,
@@ -538,7 +535,6 @@
 
 static struct proto unix_proto = {
 	.name	  = "UNIX",
-	.owner	  = THIS_MODULE,
 	.obj_size = sizeof(struct unix_sock),
 };
 
@@ -2012,7 +2008,6 @@
 }
 
 static struct file_operations unix_seq_fops = {
-	.owner		= THIS_MODULE,
 	.open		= unix_seq_open,
 	.read		= seq_read,
 	.llseek		= seq_lseek,
@@ -2024,7 +2019,6 @@
 static struct net_proto_family unix_family_ops = {
 	.family = PF_UNIX,
 	.create = unix_create,
-	.owner	= THIS_MODULE,
 };
 
 static int __init af_unix_init(void)
@@ -2053,16 +2047,4 @@
 	return rc;
 }
 
-static void __exit af_unix_exit(void)
-{
-	sock_unregister(PF_UNIX);
-	unix_sysctl_unregister();
-	proc_net_remove("unix");
-	proto_unregister(&unix_proto);
-}
-
 module_init(af_unix_init);
-module_exit(af_unix_exit);
-
-MODULE_LICENSE("GPL");
-MODULE_ALIAS_NETPROTO(PF_UNIX);
--- linux-2.6.16-mm1-full/net/unix/sysctl_net_unix.c.old	2006-03-25 20:14:10.000000000 +0100
+++ linux-2.6.16-mm1-full/net/unix/sysctl_net_unix.c	2006-03-25 20:15:21.000000000 +0100
@@ -46,15 +46,8 @@
 	{ .ctl_name = 0 }
 };
 
-static struct ctl_table_header * unix_sysctl_header;
-
 void unix_sysctl_register(void)
 {
-	unix_sysctl_header = register_sysctl_table(unix_root_table, 0);
-}
-
-void unix_sysctl_unregister(void)
-{
-	unregister_sysctl_table(unix_sysctl_header);
+	register_sysctl_table(unix_root_table, 0);
 }
 
--- linux-2.6.16-mm1-full/fs/file_table.c.old	2006-03-25 20:39:30.000000000 +0100
+++ linux-2.6.16-mm1-full/fs/file_table.c	2006-03-25 20:39:44.000000000 +0100
@@ -62,7 +62,6 @@
 {
 	return files_stat.max_files;
 }
-EXPORT_SYMBOL_GPL(get_max_files);
 
 /*
  * Handle nr_files sysctl

Re: [2.6 patch] make UNIX a bool

[Jan-Benedict Glaw]

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

On Sat, 2006-03-25 20:47:39 +0100, Adrian Bunk <bunk@stusta.de> wrote:
> On Sat, Feb 25, 2006 at 11:46:31PM +0100, Olaf Hering wrote:
> >  On Sat, Feb 25, Adrian Bunk wrote:
> > > CONFIG_UNIX=m doesn't make much sense.
> > 
> > There is likely more code to support a modular unix.ko, this has to go
> > as well.
> 
> Sounds resonable, updated patch below.

Thanks for the patch. I'll save it somewhere to have it handy for
"patch -R" use IFF it makes its ways into Linus's repo.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [2.6 patch] make UNIX a bool

[Joshua Hudson]

I've got a dumb idea. Why not export said symbols only if CONFIG_UNIX=m.
Probably dumb because I know the pain of an important symbol not being exported.
In my case, it was __iget(struct inode *).

Re: [2.6 patch] make UNIX a bool

[James C. Georgas]

On Sat, 2006-25-02 at 17:01 +0100, Adrian Bunk wrote:
> CONFIG_UNIX=m doesn't make much sense.

I've been building it as a module forever. I often load kernels from
floppy disk, and building CONFIG_UNIX as a module often makes the
difference between the kernel fitting or not fitting on the disk. Could
we please keep this functionality?

-- 
James C. Georgas <jgeorgas@rogers.com>

Re: [2.6 patch] make UNIX a bool

[Adrian Bunk]

On Mon, Feb 27, 2006 at 05:18:06PM -0500, James C. Georgas wrote:
> On Sat, 2006-25-02 at 17:01 +0100, Adrian Bunk wrote:
> > CONFIG_UNIX=m doesn't make much sense.
> 
> I've been building it as a module forever. I often load kernels from
> floppy disk, and building CONFIG_UNIX as a module often makes the
> difference between the kernel fitting or not fitting on the disk. Could
> we please keep this functionality?

If size is important for you, you should consider completely disabling 
module support in your kernels:

In my testing, disabling module support brings you a space gain in the 
range of 10%.

> James C. Georgas <jgeorgas@rogers.com>

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

Re: [2.6 patch] make UNIX a bool

[Dmitry Torokhov]

On Monday 27 February 2006 17:29, Adrian Bunk wrote:
> On Mon, Feb 27, 2006 at 05:18:06PM -0500, James C. Georgas wrote:
> > On Sat, 2006-25-02 at 17:01 +0100, Adrian Bunk wrote:
> > > CONFIG_UNIX=m doesn't make much sense.
> > 
> > I've been building it as a module forever. I often load kernels from
> > floppy disk, and building CONFIG_UNIX as a module often makes the
> > difference between the kernel fitting or not fitting on the disk. Could
> > we please keep this functionality?
> 
> If size is important for you, you should consider completely disabling 
> module support in your kernels:
> 
> In my testing, disabling module support brings you a space gain in the 
> range of 10%.
>

This only matters when you tight on memory - in the scenario above memory
may not be a great concern but kernel image size is because modules could
go on other medium.

-- 
Dmitry

Re: [2.6 patch] make UNIX a bool

[Adrian Bunk]

On Tue, Feb 28, 2006 at 10:09:52PM -0500, Dmitry Torokhov wrote:
> On Monday 27 February 2006 17:29, Adrian Bunk wrote:
> > On Mon, Feb 27, 2006 at 05:18:06PM -0500, James C. Georgas wrote:
> > > On Sat, 2006-25-02 at 17:01 +0100, Adrian Bunk wrote:
> > > > CONFIG_UNIX=m doesn't make much sense.
> > > 
> > > I've been building it as a module forever. I often load kernels from
> > > floppy disk, and building CONFIG_UNIX as a module often makes the
> > > difference between the kernel fitting or not fitting on the disk. Could
> > > we please keep this functionality?
> > 
> > If size is important for you, you should consider completely disabling 
> > module support in your kernels:
> > 
> > In my testing, disabling module support brings you a space gain in the 
> > range of 10%.
> >
> 
> This only matters when you tight on memory - in the scenario above memory
> may not be a great concern but kernel image size is because modules could
> go on other medium.

It does also matter in the kernel image size case, since you have to put 
enough modules to the other medium for having a effect bigger than the
kernel image size increase from setting CONFIG_MODULES=y.

> Dmitry

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

Re: [2.6 patch] make UNIX a bool

[Herbert Xu]

Adrian Bunk <bunk@stusta.de> wrote:
> 
> It does also matter in the kernel image size case, since you have to put 
> enough modules to the other medium for having a effect bigger than the
> kernel image size increase from setting CONFIG_MODULES=y.

That's not very difficult considering the large number of modules that's
out there that a system may wish to use.

Anyway, getting back to the original point if AF_UNIX is using something
that's so under the hood that it has to be hidden, perhaps what we really
need is a better abstraction?
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [2.6 patch] make UNIX a bool

[Adrian Bunk]

On Thu, Mar 02, 2006 at 12:31:34PM +1100, Herbert Xu wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> > 
> > It does also matter in the kernel image size case, since you have to put 
> > enough modules to the other medium for having a effect bigger than the
> > kernel image size increase from setting CONFIG_MODULES=y.
> 
> That's not very difficult considering the large number of modules that's
> out there that a system may wish to use.
>...

This might be true for full-blown desktop systems - but these do not 
tend to be the systems where kernel image size matters that much.
Smaller kernel image size might be an issue e.g. for distribution 
kernels, but in a much less pressing way.

The systems where kernel image size really matters are systems with few 
modules where you know in advance which modules you might need. I played 
a bit with the ARM defconfigs, and if you consider that you can't build 
the filesystem for accessing your modules modular I haven't found any 
where making everything modular would have given a real kernel image 
size gain compared to the CONFIG_MODULES=n case.

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

Re: [2.6 patch] make UNIX a bool

[Jan-Benedict Glaw]

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

On Thu, 2006-03-02 18:38:40 +0100, Adrian Bunk <bunk@stusta.de> wrote:
> On Thu, Mar 02, 2006 at 12:31:34PM +1100, Herbert Xu wrote:
> > Adrian Bunk <bunk@stusta.de> wrote:
> > > It does also matter in the kernel image size case, since you have to put 
> > > enough modules to the other medium for having a effect bigger than the
> > > kernel image size increase from setting CONFIG_MODULES=y.
> > That's not very difficult considering the large number of modules that's
> > out there that a system may wish to use.
> This might be true for full-blown desktop systems - but these do not 
> tend to be the systems where kernel image size matters that much.
> Smaller kernel image size might be an issue e.g. for distribution 
> kernels, but in a much less pressing way.

Kernel image size matters if you try to make it boot off a floppy.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [2.6 patch] make UNIX a bool

[Adrian Bunk]

On Thu, Mar 02, 2006 at 08:51:06PM +0100, Jan-Benedict Glaw wrote:
> On Thu, 2006-03-02 18:38:40 +0100, Adrian Bunk <bunk@stusta.de> wrote:
> > On Thu, Mar 02, 2006 at 12:31:34PM +1100, Herbert Xu wrote:
> > > Adrian Bunk <bunk@stusta.de> wrote:
> > > > It does also matter in the kernel image size case, since you have to put 
> > > > enough modules to the other medium for having a effect bigger than the
> > > > kernel image size increase from setting CONFIG_MODULES=y.
> > > That's not very difficult considering the large number of modules that's
> > > out there that a system may wish to use.
> > This might be true for full-blown desktop systems - but these do not 
> > tend to be the systems where kernel image size matters that much.
> > Smaller kernel image size might be an issue e.g. for distribution 
> > kernels, but in a much less pressing way.
> 
> Kernel image size matters if you try to make it boot off a floppy.

Sure, but the usual router-on-a-floppy cases are similar cases where 
CONFIG_MODULES=n brings at least as much gain as making things modular.

> MfG, JBG

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

Re: [2.6 patch] make UNIX a bool

[Jan-Benedict Glaw]

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

On Thu, 2006-03-02 21:39:22 +0100, Adrian Bunk <bunk@stusta.de> wrote:
> On Thu, Mar 02, 2006 at 08:51:06PM +0100, Jan-Benedict Glaw wrote:
> > On Thu, 2006-03-02 18:38:40 +0100, Adrian Bunk <bunk@stusta.de> wrote:
> > > On Thu, Mar 02, 2006 at 12:31:34PM +1100, Herbert Xu wrote:
> > > > Adrian Bunk <bunk@stusta.de> wrote:
> > > > > It does also matter in the kernel image size case, since you have to put 
> > > > > enough modules to the other medium for having a effect bigger than the
> > > > > kernel image size increase from setting CONFIG_MODULES=y.
> > > > That's not very difficult considering the large number of modules that's
> > > > out there that a system may wish to use.
> > > This might be true for full-blown desktop systems - but these do not 
> > > tend to be the systems where kernel image size matters that much.
> > > Smaller kernel image size might be an issue e.g. for distribution 
> > > kernels, but in a much less pressing way.
> > Kernel image size matters if you try to make it boot off a floppy.
> 
> Sure, but the usual router-on-a-floppy cases are similar cases where 
> CONFIG_MODULES=n brings at least as much gain as making things modular.

You may want to have a chance to load modules from an initrd with is
on a 2nd floppy.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [2.6 patch] make UNIX a bool

[Adrian Bunk]

On Thu, Mar 02, 2006 at 09:51:06PM +0100, Jan-Benedict Glaw wrote:
> On Thu, 2006-03-02 21:39:22 +0100, Adrian Bunk <bunk@stusta.de> wrote:
> > On Thu, Mar 02, 2006 at 08:51:06PM +0100, Jan-Benedict Glaw wrote:
> > > On Thu, 2006-03-02 18:38:40 +0100, Adrian Bunk <bunk@stusta.de> wrote:
> > > > On Thu, Mar 02, 2006 at 12:31:34PM +1100, Herbert Xu wrote:
> > > > > Adrian Bunk <bunk@stusta.de> wrote:
> > > > > > It does also matter in the kernel image size case, since you have to put 
> > > > > > enough modules to the other medium for having a effect bigger than the
> > > > > > kernel image size increase from setting CONFIG_MODULES=y.
> > > > > That's not very difficult considering the large number of modules that's
> > > > > out there that a system may wish to use.
> > > > This might be true for full-blown desktop systems - but these do not 
> > > > tend to be the systems where kernel image size matters that much.
> > > > Smaller kernel image size might be an issue e.g. for distribution 
> > > > kernels, but in a much less pressing way.
> > > Kernel image size matters if you try to make it boot off a floppy.
> > 
> > Sure, but the usual router-on-a-floppy cases are similar cases where 
> > CONFIG_MODULES=n brings at least as much gain as making things modular.
> 
> You may want to have a chance to load modules from an initrd with is
> on a 2nd floppy.

In these cases, CONFIG_UNIX shouldn't make the difference between the 
kernel fitting on the first floppy and the kernel not fitting on the 
first floppy.

> MfG, JBG

cu
Adrian

BTW: Don't remove people from the Cc when replying to linux-kernel
     (my MUA honors your Mail-Followup-To, but there was no reason
      for you to not send me a copy of your email).

-- 

       "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

Re: [2.6 patch] make UNIX a bool

[Jan-Benedict Glaw]

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

On Thu, 2006-03-02 22:28:05 +0100, Adrian Bunk <bunk@stusta.de> wrote:
> On Thu, Mar 02, 2006 at 09:51:06PM +0100, Jan-Benedict Glaw wrote:
> > You may want to have a chance to load modules from an initrd with is
> > on a 2nd floppy.
> 
> In these cases, CONFIG_UNIX shouldn't make the difference between the 
> kernel fitting on the first floppy and the kernel not fitting on the 
> first floppy.

Heh. By Linus' Law, kernel footprint grows. To get a nice useable
floppy disk, you may need to do *quite* some jumps to make it fit.

In the worst case I had, I even started to throw out some of the
device ID tables (unneeded entries), killed printk() by defining a
no-op for it etc. to save some *bytes*. Yes, it's a nice dance:-)

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [2.6 patch] make UNIX a bool

[Jesper Juhl]

On 3/2/06, Adrian Bunk <bunk@stusta.de> wrote:
> On Thu, Mar 02, 2006 at 12:31:34PM +1100, Herbert Xu wrote:
> > Adrian Bunk <bunk@stusta.de> wrote:
> > >
> > > It does also matter in the kernel image size case, since you have to put
> > > enough modules to the other medium for having a effect bigger than the
> > > kernel image size increase from setting CONFIG_MODULES=y.
> >
> > That's not very difficult considering the large number of modules that's
> > out there that a system may wish to use.
> >...
>
> This might be true for full-blown desktop systems - but these do not
> tend to be the systems where kernel image size matters that much.
> Smaller kernel image size might be an issue e.g. for distribution
> kernels, but in a much less pressing way.
>
> The systems where kernel image size really matters are systems with few
> modules where you know in advance which modules you might need. I played
> a bit with the ARM defconfigs, and if you consider that you can't build
> the filesystem for accessing your modules modular I haven't found any
> where making everything modular would have given a real kernel image
> size gain compared to the CONFIG_MODULES=n case.
>

I believe the basic question is this: What do we win by making
CONFIG_UNIX a bool?

As it is now eople have the option of building it in, building a
module or not build it at all - I don't see why that's a bad thing.
For people who want a small core kernel (for whatever reason) and then
load additional capabilities as modules, the current situation is
good. If we remove the modular option who will bennefit?
Why not just leave it as it is?

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [2.6 patch] make UNIX a bool

[Adrian Bunk]

On Thu, Mar 02, 2006 at 09:28:15PM +0100, Jesper Juhl wrote:
> On 3/2/06, Adrian Bunk <bunk@stusta.de> wrote:
> > On Thu, Mar 02, 2006 at 12:31:34PM +1100, Herbert Xu wrote:
> > > Adrian Bunk <bunk@stusta.de> wrote:
> > > >
> > > > It does also matter in the kernel image size case, since you have to put
> > > > enough modules to the other medium for having a effect bigger than the
> > > > kernel image size increase from setting CONFIG_MODULES=y.
> > >
> > > That's not very difficult considering the large number of modules that's
> > > out there that a system may wish to use.
> > >...
> >
> > This might be true for full-blown desktop systems - but these do not
> > tend to be the systems where kernel image size matters that much.
> > Smaller kernel image size might be an issue e.g. for distribution
> > kernels, but in a much less pressing way.
> >
> > The systems where kernel image size really matters are systems with few
> > modules where you know in advance which modules you might need. I played
> > a bit with the ARM defconfigs, and if you consider that you can't build
> > the filesystem for accessing your modules modular I haven't found any
> > where making everything modular would have given a real kernel image
> > size gain compared to the CONFIG_MODULES=n case.
> >
> 
> I believe the basic question is this: What do we win by making
> CONFIG_UNIX a bool?
>...

We do not have to export symbols we don't want to export to modules but 
needed by CONFIG_UNIX.

> Jesper Juhl <jesper.juhl@gmail.com>

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

Re: [2.6 patch] make UNIX a bool

[Jesper Juhl]

On 3/2/06, Adrian Bunk <bunk@stusta.de> wrote:
> On Thu, Mar 02, 2006 at 09:28:15PM +0100, Jesper Juhl wrote:
> > On 3/2/06, Adrian Bunk <bunk@stusta.de> wrote:
> > > On Thu, Mar 02, 2006 at 12:31:34PM +1100, Herbert Xu wrote:
> > > > Adrian Bunk <bunk@stusta.de> wrote:
> > > > >
> > > > > It does also matter in the kernel image size case, since you have to put
> > > > > enough modules to the other medium for having a effect bigger than the
> > > > > kernel image size increase from setting CONFIG_MODULES=y.
> > > >
> > > > That's not very difficult considering the large number of modules that's
> > > > out there that a system may wish to use.
> > > >...
> > >
> > > This might be true for full-blown desktop systems - but these do not
> > > tend to be the systems where kernel image size matters that much.
> > > Smaller kernel image size might be an issue e.g. for distribution
> > > kernels, but in a much less pressing way.
> > >
> > > The systems where kernel image size really matters are systems with few
> > > modules where you know in advance which modules you might need. I played
> > > a bit with the ARM defconfigs, and if you consider that you can't build
> > > the filesystem for accessing your modules modular I haven't found any
> > > where making everything modular would have given a real kernel image
> > > size gain compared to the CONFIG_MODULES=n case.
> > >
> >
> > I believe the basic question is this: What do we win by making
> > CONFIG_UNIX a bool?
> >...
>
> We do not have to export symbols we don't want to export to modules but
> needed by CONFIG_UNIX.
>

I'm probably exposing my ignorance here, but, what symbols would those be?

and does it outweigh the harm done to people who want or need
CONFIG_UNIX modular ?

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [2.6 patch] make UNIX a bool

[Adrian Bunk]

On Thu, Mar 02, 2006 at 09:40:17PM +0100, Jesper Juhl wrote:
> On 3/2/06, Adrian Bunk <bunk@stusta.de> wrote:
> > On Thu, Mar 02, 2006 at 09:28:15PM +0100, Jesper Juhl wrote:
> > > On 3/2/06, Adrian Bunk <bunk@stusta.de> wrote:
> > > > On Thu, Mar 02, 2006 at 12:31:34PM +1100, Herbert Xu wrote:
> > > > > Adrian Bunk <bunk@stusta.de> wrote:
> > > > > >
> > > > > > It does also matter in the kernel image size case, since you have to put
> > > > > > enough modules to the other medium for having a effect bigger than the
> > > > > > kernel image size increase from setting CONFIG_MODULES=y.
> > > > >
> > > > > That's not very difficult considering the large number of modules that's
> > > > > out there that a system may wish to use.
> > > > >...
> > > >
> > > > This might be true for full-blown desktop systems - but these do not
> > > > tend to be the systems where kernel image size matters that much.
> > > > Smaller kernel image size might be an issue e.g. for distribution
> > > > kernels, but in a much less pressing way.
> > > >
> > > > The systems where kernel image size really matters are systems with few
> > > > modules where you know in advance which modules you might need. I played
> > > > a bit with the ARM defconfigs, and if you consider that you can't build
> > > > the filesystem for accessing your modules modular I haven't found any
> > > > where making everything modular would have given a real kernel image
> > > > size gain compared to the CONFIG_MODULES=n case.
> > > >
> > >
> > > I believe the basic question is this: What do we win by making
> > > CONFIG_UNIX a bool?
> > >...
> >
> > We do not have to export symbols we don't want to export to modules but
> > needed by CONFIG_UNIX.
> >
> 
> I'm probably exposing my ignorance here, but, what symbols would those be?
> 
> and does it outweigh the harm done to people who want or need
> CONFIG_UNIX modular ?


Can anyone bring real life examples for this pretended harm?

All examples I have heard until now fall under one of the following:
- CONFIG_MODULES=n wouldn't be worse
- if you want your kernel to fit on a floppy, CONFIG_UNIX shouldn't be 
  the thing making the difference between the kernel fitting on the
  floppy and the kernel not fitting on the floppy


And I'm surprised that everyone thinks the world would stop turning if 
the kernel image size is increased by CONFIG_UNIX=y, but the same people 
were quiet when during the 2.5 development the discarding of __exit code 
moved from link time to run time on some architectures (e.g. i386) 
making the kernel image size bigger for everyone.

Is there much FUD in this thread or why do people pretend to care in the 
CONFIG_UNIX case but don't care when the __exit code is discarded?


> Jesper Juhl <jesper.juhl@gmail.com>

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

Re: [2.6 patch] make UNIX a bool

[Jan Engelhardt]

>
>Can anyone bring real life examples for this pretended harm?
>
>All examples I have heard until now fall under one of the following:
>- CONFIG_MODULES=n wouldn't be worse
>- if you want your kernel to fit on a floppy, CONFIG_UNIX shouldn't be 
>  the thing making the difference between the kernel fitting on the
>  floppy and the kernel not fitting on the floppy
>
Well, not directly topic'ed to CONFIG_UNIX, but if the IPv4 stack was modular
(like IPv6), we'd probably gain some 100 KB and would not have to worry about
CONFIG_UNIX for a while.


Jan Engelhardt
-- 

Re: [2.6 patch] make UNIX a bool

[Adrian Bunk]

On Thu, Mar 02, 2006 at 10:53:30PM +0100, Jan Engelhardt wrote:
> >
> >Can anyone bring real life examples for this pretended harm?
> >
> >All examples I have heard until now fall under one of the following:
> >- CONFIG_MODULES=n wouldn't be worse
> >- if you want your kernel to fit on a floppy, CONFIG_UNIX shouldn't be 
> >  the thing making the difference between the kernel fitting on the
> >  floppy and the kernel not fitting on the floppy
> >
> Well, not directly topic'ed to CONFIG_UNIX, but if the IPv4 stack was modular
> (like IPv6), we'd probably gain some 100 KB and would not have to worry about
> CONFIG_UNIX for a while.

I doubt making the IPv4 stack modular is worth the trouble, but feel 
free to send a patch as a basis for a discussion...

> Jan Engelhardt

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

Re: make IPV4 modular (was: [2.6 patch] make UNIX a bool)

[Jan Engelhardt]

>> Well, not directly topic'ed to CONFIG_UNIX, but if the IPv4 stack was modular
>> (like IPv6), we'd probably gain some 100 KB and would not have to worry about
>> CONFIG_UNIX for a while.
>
>I doubt making the IPv4 stack modular is worth the trouble, but feel 
>free to send a patch as a basis for a discussion...
>
It would possibly require EXPORT_SYMBOLs, which you seem to be opposed to...


Jan Engelhardt
-- 

Re: make IPV4 modular (was: [2.6 patch] make UNIX a bool)

[Adrian Bunk]

On Fri, Mar 03, 2006 at 02:31:04PM +0100, Jan Engelhardt wrote:
> >> Well, not directly topic'ed to CONFIG_UNIX, but if the IPv4 stack was modular
> >> (like IPv6), we'd probably gain some 100 KB and would not have to worry about
> >> CONFIG_UNIX for a while.
> >
> >I doubt making the IPv4 stack modular is worth the trouble, but feel 
> >free to send a patch as a basis for a discussion...
> >
> It would possibly require EXPORT_SYMBOLs, which you seem to be opposed to...

That's not the only point.

There are many cases you have to handle correctly. As a simple example,
CONFIG_W1=y, CONFIG_NET=m or CONFIG_W1=m, CONFIG_NET=m should compile as 
expected.

But hey, it's open source and much is possible. If you think this would 
be important send a patch and we have a basis for a discussion. 
Discussions about probable patches tend to become extremely fruitless.

> Jan Engelhardt

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

Re: [2.6 patch] make UNIX a bool

[Adrian Bunk]

On Thu, Mar 02, 2006 at 09:40:17PM +0100, Jesper Juhl wrote:
> On 3/2/06, Adrian Bunk <bunk@stusta.de> wrote:
> >
> > We do not have to export symbols we don't want to export to modules but
> > needed by CONFIG_UNIX.
> >
> 
> I'm probably exposing my ignorance here, but, what symbols would those be?
>...

  http://lkml.org/lkml/2006/2/18/44

> Jesper Juhl <jesper.juhl@gmail.com>

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

Re: [2.6 patch] make UNIX a bool

[Jan-Benedict Glaw]

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

On Thu, 2006-03-02 22:46:02 +0100, Adrian Bunk <bunk@stusta.de> wrote:
> On Thu, Mar 02, 2006 at 09:40:17PM +0100, Jesper Juhl wrote:
> > On 3/2/06, Adrian Bunk <bunk@stusta.de> wrote:
> > > We do not have to export symbols we don't want to export to modules but
> > > needed by CONFIG_UNIX.
> > I'm probably exposing my ignorance here, but, what symbols would those be?
>   http://lkml.org/lkml/2006/2/18/44

That names *one* symbol.

*plonk*, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [2.6 patch] make UNIX a bool

[James C. Georgas]

On Thu, 2006-02-03 at 21:32 +0100, Adrian Bunk wrote:
> On Thu, Mar 02, 2006 at 09:28:15PM +0100, Jesper Juhl wrote:
> > On 3/2/06, Adrian Bunk <bunk@stusta.de> wrote:
> > > On Thu, Mar 02, 2006 at 12:31:34PM +1100, Herbert Xu wrote:
> > > > Adrian Bunk <bunk@stusta.de> wrote:
> > > > >
> > > > > It does also matter in the kernel image size case, since you have to put
> > > > > enough modules to the other medium for having a effect bigger than the
> > > > > kernel image size increase from setting CONFIG_MODULES=y.
> > > >
> > > > That's not very difficult considering the large number of modules that's
> > > > out there that a system may wish to use.
> > > >...
> > >
> > > This might be true for full-blown desktop systems - but these do not
> > > tend to be the systems where kernel image size matters that much.
> > > Smaller kernel image size might be an issue e.g. for distribution
> > > kernels, but in a much less pressing way.
> > >
> > > The systems where kernel image size really matters are systems with few
> > > modules where you know in advance which modules you might need. I played
> > > a bit with the ARM defconfigs, and if you consider that you can't build
> > > the filesystem for accessing your modules modular I haven't found any
> > > where making everything modular would have given a real kernel image
> > > size gain compared to the CONFIG_MODULES=n case.
> > >
> > 
> > I believe the basic question is this: What do we win by making
> > CONFIG_UNIX a bool?
> >...
> 
> We do not have to export symbols we don't want to export to modules but 
> needed by CONFIG_UNIX.
> 
> > Jesper Juhl <jesper.juhl@gmail.com>
> 
> cu
> Adrian
> 

Sorry, I must just be dense, or something.

Is not the only difference between a modular driver and a built in
driver supposed to be the initialization and cleanup functions?

I don't see why you would have to expose any additional symbols, over
and above the existing required symbols, to load your module.

-- 
James C. Georgas <jgeorgas@rogers.com>

Re: [2.6 patch] make UNIX a bool

[James C. Georgas]

On Thu, 2006-02-03 at 22:44 +0100, Adrian Bunk wrote:

> > > 
> > > We do not have to export symbols we don't want to export to modules but 
> > > needed by CONFIG_UNIX.
> > 
> > Sorry, I must just be dense, or something.
> > 
> > Is not the only difference between a modular driver and a built in
> > driver supposed to be the initialization and cleanup functions?
> > 
> > I don't see why you would have to expose any additional symbols, over
> > and above the existing required symbols, to load your module.
> 
> Every kernel symbol a module uses must be explicitely exported with 
> EXPORT_SYMBOL.
> 

Yes, I understand that I need to export symbols to define the interface
to my driver. whether its a module or compiled in. This is how other
systems interact with my driver, right?

> CONFIG_UNIX uses symbols that are neither used by any other in-kernel 
> modules nor should be exported.
> 

Are you saying that AF_UNIX has to export symbols for its own private
functions in order to call them? I guess I don't understand this. Why
not just call them. They're in scope within the driver code, aren't
they?


> > James C. Georgas <jgeorgas@rogers.com>
> 
> cu
> Adrian
> 

-- 
James C. Georgas <jgeorgas@rogers.com>

Re: [2.6 patch] make UNIX a bool

[Adrian Bunk]

On Thu, Mar 02, 2006 at 11:44:57PM -0500, James C. Georgas wrote:
> On Thu, 2006-02-03 at 22:44 +0100, Adrian Bunk wrote:
> 
> > > > 
> > > > We do not have to export symbols we don't want to export to modules but 
> > > > needed by CONFIG_UNIX.
> > > 
> > > Sorry, I must just be dense, or something.
> > > 
> > > Is not the only difference between a modular driver and a built in
> > > driver supposed to be the initialization and cleanup functions?
> > > 
> > > I don't see why you would have to expose any additional symbols, over
> > > and above the existing required symbols, to load your module.
> > 
> > Every kernel symbol a module uses must be explicitely exported with 
> > EXPORT_SYMBOL.
> 
> Yes, I understand that I need to export symbols to define the interface
> to my driver. whether its a module or compiled in. This is how other
> systems interact with my driver, right?

EXPORT_SYMBOL is only required for modules.

> > CONFIG_UNIX uses symbols that are neither used by any other in-kernel 
> > modules nor should be exported.
> 
> Are you saying that AF_UNIX has to export symbols for its own private
> functions in order to call them? I guess I don't understand this. Why
> not just call them. They're in scope within the driver code, aren't
> they?

No, this is about functions defined in other parts of the kernel.

> James C. Georgas <jgeorgas@rogers.com>

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

Re: [2.6 patch] make UNIX a bool

[James C. Georgas]

On Fri, 2006-03-03 at 12:46 +0100, Adrian Bunk wrote:
> On Thu, Mar 02, 2006 at 11:44:57PM -0500, James C. Georgas wrote:
> > On Thu, 2006-02-03 at 22:44 +0100, Adrian Bunk wrote:
> > 
> > > > > 
> > > > > We do not have to export symbols we don't want to export to modules but 
> > > > > needed by CONFIG_UNIX.
> > > > 
> > > > Sorry, I must just be dense, or something.
> > > > 
> > > > Is not the only difference between a modular driver and a built in
> > > > driver supposed to be the initialization and cleanup functions?
> > > > 
> > > > I don't see why you would have to expose any additional symbols, over
> > > > and above the existing required symbols, to load your module.
> > > 
> > > Every kernel symbol a module uses must be explicitely exported with 
> > > EXPORT_SYMBOL.
> > 
> > Yes, I understand that I need to export symbols to define the interface
> > to my driver. whether its a module or compiled in. This is how other
> > systems interact with my driver, right?
> 
> EXPORT_SYMBOL is only required for modules.
> 
> > > CONFIG_UNIX uses symbols that are neither used by any other in-kernel 
> > > modules nor should be exported.
> > 
> > Are you saying that AF_UNIX has to export symbols for its own private
> > functions in order to call them? I guess I don't understand this. Why
> > not just call them. They're in scope within the driver code, aren't
> > they?
> 
> No, this is about functions defined in other parts of the kernel.
> 

Ok, if I understand you correctly now, there is a function defined in
another part of the kernel, which is _called_ by AF_UNIX, and it is for
this function that the other part of the kernel must export a symbol?

But you only need to do this so that modules can use the function,
because if, instead, the driver is built in, then the function is
directly in scope, and can be called explicitly?


> > James C. Georgas <jgeorgas@rogers.com>
> 
> cu
> Adrian
> 
-- 
James C. Georgas <jgeorgas@rogers.com>

Re: [2.6 patch] make UNIX a bool

[Adrian Bunk]

On Fri, Mar 03, 2006 at 09:48:46AM -0500, James C. Georgas wrote:
> On Fri, 2006-03-03 at 12:46 +0100, Adrian Bunk wrote:
> > On Thu, Mar 02, 2006 at 11:44:57PM -0500, James C. Georgas wrote:
> > > On Thu, 2006-02-03 at 22:44 +0100, Adrian Bunk wrote:
> > > 
> > > > > > 
> > > > > > We do not have to export symbols we don't want to export to modules but 
> > > > > > needed by CONFIG_UNIX.
> > > > > 
> > > > > Sorry, I must just be dense, or something.
> > > > > 
> > > > > Is not the only difference between a modular driver and a built in
> > > > > driver supposed to be the initialization and cleanup functions?
> > > > > 
> > > > > I don't see why you would have to expose any additional symbols, over
> > > > > and above the existing required symbols, to load your module.
> > > > 
> > > > Every kernel symbol a module uses must be explicitely exported with 
> > > > EXPORT_SYMBOL.
> > > 
> > > Yes, I understand that I need to export symbols to define the interface
> > > to my driver. whether its a module or compiled in. This is how other
> > > systems interact with my driver, right?
> > 
> > EXPORT_SYMBOL is only required for modules.
> > 
> > > > CONFIG_UNIX uses symbols that are neither used by any other in-kernel 
> > > > modules nor should be exported.
> > > 
> > > Are you saying that AF_UNIX has to export symbols for its own private
> > > functions in order to call them? I guess I don't understand this. Why
> > > not just call them. They're in scope within the driver code, aren't
> > > they?
> > 
> > No, this is about functions defined in other parts of the kernel.
> > 
> 
> Ok, if I understand you correctly now, there is a function defined in
> another part of the kernel, which is _called_ by AF_UNIX, and it is for
> this function that the other part of the kernel must export a symbol?
> 
> But you only need to do this so that modules can use the function,
> because if, instead, the driver is built in, then the function is
> directly in scope, and can be called explicitly?

Correct.

> James C. Georgas <jgeorgas@rogers.com>

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

Re: [2.6 patch] make UNIX a bool

[James C. Georgas]

On Fri, 2006-03-03 at 16:10 +0100, Adrian Bunk wrote:
> On Fri, Mar 03, 2006 at 09:48:46AM -0500, James C. Georgas wrote:
> > On Fri, 2006-03-03 at 12:46 +0100, Adrian Bunk wrote:
> > > On Thu, Mar 02, 2006 at 11:44:57PM -0500, James C. Georgas wrote:
> > > > On Thu, 2006-02-03 at 22:44 +0100, Adrian Bunk wrote:
> > > > 
> > > > > > > 
> > > > > > > We do not have to export symbols we don't want to export to modules but 
> > > > > > > needed by CONFIG_UNIX.
> > > > > > 
> > > > > > Sorry, I must just be dense, or something.
> > > > > > 
> > > > > > Is not the only difference between a modular driver and a built in
> > > > > > driver supposed to be the initialization and cleanup functions?
> > > > > > 
> > > > > > I don't see why you would have to expose any additional symbols, over
> > > > > > and above the existing required symbols, to load your module.
> > > > > 
> > > > > Every kernel symbol a module uses must be explicitely exported with 
> > > > > EXPORT_SYMBOL.
> > > > 
> > > > Yes, I understand that I need to export symbols to define the interface
> > > > to my driver. whether its a module or compiled in. This is how other
> > > > systems interact with my driver, right?
> > > 
> > > EXPORT_SYMBOL is only required for modules.
> > > 
> > > > > CONFIG_UNIX uses symbols that are neither used by any other in-kernel 
> > > > > modules nor should be exported.
> > > > 
> > > > Are you saying that AF_UNIX has to export symbols for its own private
> > > > functions in order to call them? I guess I don't understand this. Why
> > > > not just call them. They're in scope within the driver code, aren't
> > > > they?
> > > 
> > > No, this is about functions defined in other parts of the kernel.
> > > 
> > 
> > Ok, if I understand you correctly now, there is a function defined in
> > another part of the kernel, which is _called_ by AF_UNIX, and it is for
> > this function that the other part of the kernel must export a symbol?
> > 
> > But you only need to do this so that modules can use the function,
> > because if, instead, the driver is built in, then the function is
> > directly in scope, and can be called explicitly?
> 
> Correct.

Ok, I understand.

What are the exported symbols, and where are they defined?

I read the post you linked to earlier, but I got nothing when I grepped
for "get_max_files", which was mentioned.
-- 
James C. Georgas <jgeorgas@rogers.com>

Re: [2.6 patch] make UNIX a bool

[Adrian Bunk]

On Fri, Mar 03, 2006 at 12:50:51PM -0500, James C. Georgas wrote:
> On Fri, 2006-03-03 at 16:10 +0100, Adrian Bunk wrote:
> > On Fri, Mar 03, 2006 at 09:48:46AM -0500, James C. Georgas wrote:
> > > 
> > > Ok, if I understand you correctly now, there is a function defined in
> > > another part of the kernel, which is _called_ by AF_UNIX, and it is for
> > > this function that the other part of the kernel must export a symbol?
> > > 
> > > But you only need to do this so that modules can use the function,
> > > because if, instead, the driver is built in, then the function is
> > > directly in scope, and can be called explicitly?
> > 
> > Correct.
> 
> Ok, I understand.
> 
> What are the exported symbols, and where are they defined?
> 
> I read the post you linked to earlier, but I got nothing when I grepped
> for "get_max_files", which was mentioned.

You must look at the latest -mm.

> James C. Georgas <jgeorgas@rogers.com>

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

Re: [2.6 patch] make UNIX a bool

[James C. Georgas]

On Fri, 2006-03-03 at 18:55 +0100, Adrian Bunk wrote:
> On Fri, Mar 03, 2006 at 12:50:51PM -0500, James C. Georgas wrote:
> > On Fri, 2006-03-03 at 16:10 +0100, Adrian Bunk wrote:
> > > On Fri, Mar 03, 2006 at 09:48:46AM -0500, James C. Georgas wrote:
> > > > 
> > > > Ok, if I understand you correctly now, there is a function defined in
> > > > another part of the kernel, which is _called_ by AF_UNIX, and it is for
> > > > this function that the other part of the kernel must export a symbol?
> > > > 
> > > > But you only need to do this so that modules can use the function,
> > > > because if, instead, the driver is built in, then the function is
> > > > directly in scope, and can be called explicitly?
> > > 
> > > Correct.
> > 
> > Ok, I understand.
> > 
> > What are the exported symbols, and where are they defined?
> > 
> > I read the post you linked to earlier, but I got nothing when I grepped
> > for "get_max_files", which was mentioned.
> 
> You must look at the latest -mm.

OK, I see. It's a wrapper function for files_stat.max_files, which was
the current exported symbol in the mainline kernel.

It's used here, basically, to cap the number of sockets in existence, to
prevent rogue processes from chewing up all your memory.

If I understand your position correctly, you believe that it is
inappropriate for this symbol to be publicly visible to a subsystem that
is dynamically linked, but that it is OK for it to be publicly visible
to the same subsystem, when it is statically linked instead.

Did I misunderstand you?

-- 
James C. Georgas <jgeorgas@rogers.com>

Re: [2.6 patch] make UNIX a bool

[Randy.Dunlap]

On Thu, 2 Mar 2006 21:28:15 +0100 Jesper Juhl wrote:

> On 3/2/06, Adrian Bunk <bunk@stusta.de> wrote:
> > On Thu, Mar 02, 2006 at 12:31:34PM +1100, Herbert Xu wrote:
> > > Adrian Bunk <bunk@stusta.de> wrote:
> > > >
> > > > It does also matter in the kernel image size case, since you have to put
> > > > enough modules to the other medium for having a effect bigger than the
> > > > kernel image size increase from setting CONFIG_MODULES=y.
> > >
> > > That's not very difficult considering the large number of modules that's
> > > out there that a system may wish to use.
> > >...
> >
> > This might be true for full-blown desktop systems - but these do not
> > tend to be the systems where kernel image size matters that much.
> > Smaller kernel image size might be an issue e.g. for distribution
> > kernels, but in a much less pressing way.
> >
> > The systems where kernel image size really matters are systems with few
> > modules where you know in advance which modules you might need. I played
> > a bit with the ARM defconfigs, and if you consider that you can't build
> > the filesystem for accessing your modules modular I haven't found any
> > where making everything modular would have given a real kernel image
> > size gain compared to the CONFIG_MODULES=n case.
> >
> 
> I believe the basic question is this: What do we win by making
> CONFIG_UNIX a bool?
> 
> As it is now eople have the option of building it in, building a
> module or not build it at all - I don't see why that's a bad thing.
> For people who want a small core kernel (for whatever reason) and then
> load additional capabilities as modules, the current situation is
> good. If we remove the modular option who will bennefit?
> Why not just leave it as it is?

amen, agreed.

---
~Randy

Re: [2.6 patch] make UNIX a bool

[Jan-Benedict Glaw]

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

On Mon, 2006-02-27 17:18:06 -0500, James C. Georgas <jgeorgas@rogers.com> wrote:
> On Sat, 2006-25-02 at 17:01 +0100, Adrian Bunk wrote:
> > CONFIG_UNIX=m doesn't make much sense.
> 
> I've been building it as a module forever. I often load kernels from
> floppy disk, and building CONFIG_UNIX as a module often makes the
> difference between the kernel fitting or not fitting on the disk. Could
> we please keep this functionality?

Same for me. Maybe make the offer of CONFIG_UNIX=m dependant on the
small/embedded stuff?

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [2.6 patch] make UNIX a bool

[James C. Georgas]

On a philosophical note, I like being able to unload a module and
replace it at runtime, without having to reboot. I might want to play
around with the code in a module, for educational purposes, and being
able to reload an altered module makes a huge difference in how quickly
I can test my changes.

Also, I suspect that if the modular option were removed then eventually
the code would evolve to a state where it would be impossible to
reinstate the option (i.e. the driver would become tightly coupled to
other kernel code). There have been drivers in the past that would not
build as modules, because they made the assumption that their
dependencies were built into the kernel.

A good example is the old 2.4 kernel IDE stuff, where the IDE disk
driver would barf on compilation if the IDE base driver was built as a
module instead of compiled into the kernel.

I guess it just gives me the creeps to think that we're setting up
conditions that would allow tight coupling of drivers to arise once
again.

Of course, I'm not an expert or anything. What /are/ the disadvantages
to having a modular driver, as opposed to having it built in to the
kernel?
-- 
James C. Georgas <jgeorgas@rogers.com>

Re: [2.6 patch] make UNIX a bool

[Jan Engelhardt]

>> > CONFIG_UNIX=m doesn't make much sense.
>> 
>> I've been building it as a module forever. I often load kernels from
>> floppy disk, and building CONFIG_UNIX as a module often makes the
>> difference between the kernel fitting or not fitting on the disk. Could
>> we please keep this functionality?
>
>Same for me. Maybe make the offer of CONFIG_UNIX=m dependant on the
>small/embedded stuff?

<irony> You mean CONFIG_EXPERT.


Jan Engelhardt
-- 

Re: [2.6 patch] make UNIX a bool

[Adrian Bunk]

On Tue, Feb 28, 2006 at 03:52:17PM +0100, Jan-Benedict Glaw wrote:
> On Mon, 2006-02-27 17:18:06 -0500, James C. Georgas <jgeorgas@rogers.com> wrote:
> > On Sat, 2006-25-02 at 17:01 +0100, Adrian Bunk wrote:
> > > CONFIG_UNIX=m doesn't make much sense.
> > 
> > I've been building it as a module forever. I often load kernels from
> > floppy disk, and building CONFIG_UNIX as a module often makes the
> > difference between the kernel fitting or not fitting on the disk. Could
> > we please keep this functionality?
> 
> Same for me. Maybe make the offer of CONFIG_UNIX=m dependant on the
> small/embedded stuff?

This wouldn't solve the problem that CONFIG_UNIX=m forces us to export 
symbols that shouldn't be exported:
  http://lkml.org/lkml/2006/2/18/44

> MfG, JBG

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

[Fwd: Re: [2.6 patch] make UNIX a bool]

[James C. Georgas]

On Thu, 2006-02-03 at 21:32 +0100, Adrian Bunk wrote:
> On Thu, Mar 02, 2006 at 09:28:15PM +0100, Jesper Juhl wrote:
> > On 3/2/06, Adrian Bunk <bunk@stusta.de> wrote:
> > > On Thu, Mar 02, 2006 at 12:31:34PM +1100, Herbert Xu wrote:
> > > > Adrian Bunk <bunk@stusta.de> wrote:
> > > > >
> > > > > It does also matter in the kernel image size case, since you
have to put
> > > > > enough modules to the other medium for having a effect bigger
than the
> > > > > kernel image size increase from setting CONFIG_MODULES=y.
> > > >
> > > > That's not very difficult considering the large number of
modules that's
> > > > out there that a system may wish to use.
> > > >...
> > >
> > > This might be true for full-blown desktop systems - but these do
not
> > > tend to be the systems where kernel image size matters that much.
> > > Smaller kernel image size might be an issue e.g. for distribution
> > > kernels, but in a much less pressing way.
> > >
> > > The systems where kernel image size really matters are systems
with few
> > > modules where you know in advance which modules you might need. I
played
> > > a bit with the ARM defconfigs, and if you consider that you can't
build
> > > the filesystem for accessing your modules modular I haven't found
any
> > > where making everything modular would have given a real kernel
image
> > > size gain compared to the CONFIG_MODULES=n case.
> > >
> > 
> > I believe the basic question is this: What do we win by making
> > CONFIG_UNIX a bool?
> >...
> 
> We do not have to export symbols we don't want to export to modules
but 
> needed by CONFIG_UNIX.

Sorry, I must just be dense, or something.

Is not the only difference between a modular driver and a built in
driver supposed to be the initialization and cleanup functions?

I don't see why you would have to expose any additional symbols, over
and above the existing required symbols, to load your module.

-- 
James C. Georgas <jgeorgas@rogers.com>

Re: [2.6 patch] make UNIX a bool

[James C. Georgas]

On Thu, 2006-02-03 at 21:32 +0100, Adrian Bunk wrote:
> On Thu, Mar 02, 2006 at 09:28:15PM +0100, Jesper Juhl wrote:
> > On 3/2/06, Adrian Bunk <bunk@stusta.de> wrote:
> > > On Thu, Mar 02, 2006 at 12:31:34PM +1100, Herbert Xu wrote:
> > > > Adrian Bunk <bunk@stusta.de> wrote:
> > > > >
> > > > > It does also matter in the kernel image size case, since you
have to put
> > > > > enough modules to the other medium for having a effect bigger
than the
> > > > > kernel image size increase from setting CONFIG_MODULES=y.
> > > >
> > > > That's not very difficult considering the large number of
modules that's
> > > > out there that a system may wish to use.
> > > >...
> > >
> > > This might be true for full-blown desktop systems - but these do
not
> > > tend to be the systems where kernel image size matters that much.
> > > Smaller kernel image size might be an issue e.g. for distribution
> > > kernels, but in a much less pressing way.
> > >
> > > The systems where kernel image size really matters are systems
with few
> > > modules where you know in advance which modules you might need. I
played
> > > a bit with the ARM defconfigs, and if you consider that you can't
build
> > > the filesystem for accessing your modules modular I haven't found
any
> > > where making everything modular would have given a real kernel
image
> > > size gain compared to the CONFIG_MODULES=n case.
> > >
> > 
> > I believe the basic question is this: What do we win by making
> > CONFIG_UNIX a bool?
> >...
> 
> We do not have to export symbols we don't want to export to modules
but 
> needed by CONFIG_UNIX.

Sorry, I must just be dense, or something.

Is not the only difference between a modular driver and a built in
driver supposed to be the initialization and cleanup functions?

I don't see why you would have to expose any additional symbols, over
and above the existing required symbols, to load your module.

-- 
James C. Georgas <jgeorgas@rogers.com>

Re: [2.6 patch] make UNIX a bool

[Kyle Moffett]

On Thu, 02 Mar 2006 23:14:38 -0500 "James C. Georgas" <jgeorgas@rogers.com> wrote: 
> On Thu, 2006-02-03 at 21:32 +0100, Adrian Bunk wrote:
> > We do not have to export symbols we don't want to export to modules but 
> > needed by CONFIG_UNIX.
> 
> Sorry, I must just be dense, or something.
> 
> Is not the only difference between a modular driver and a built in
> driver supposed to be the initialization and cleanup functions?
> 
> I don't see why you would have to expose any additional symbols, over
> and above the existing required symbols, to load your module.

af_unix (IE: CONFIG_UNIX) currently uses the symbol get_max_files.  It 
is the only module that uses that symbol, and that symbol probably should 
not be exported as it's kind of an internal API.  Therefore if we mandate 
that CONFIG_UNIX != m, then that symbol may be properly unexported and 
made private, because nothing modular would use it.  Does that clear 
things up?

P.S.: Please don't remove people from the CC list if you expect them to 
respond to your message (Adrian Bunk readded to CC).

Cheers,
Kyle Moffett

Re: [2.6 patch] make UNIX a bool

[James C. Georgas]

On Thu, 2006-02-03 at 23:32 -0500, Kyle Moffett wrote:
> On Thu, 02 Mar 2006 23:14:38 -0500 "James C. Georgas" <jgeorgas@rogers.com> wrote: 
> > On Thu, 2006-02-03 at 21:32 +0100, Adrian Bunk wrote:
> > > We do not have to export symbols we don't want to export to modules but 
> > > needed by CONFIG_UNIX.
> > 
> > Sorry, I must just be dense, or something.
> > 
> > Is not the only difference between a modular driver and a built in
> > driver supposed to be the initialization and cleanup functions?
> > 
> > I don't see why you would have to expose any additional symbols, over
> > and above the existing required symbols, to load your module.
> 
> af_unix (IE: CONFIG_UNIX) currently uses the symbol get_max_files.  It 
> is the only module that uses that symbol, and that symbol probably should 
> not be exported as it's kind of an internal API.  Therefore if we mandate 
> that CONFIG_UNIX != m, then that symbol may be properly unexported and 
> made private, because nothing modular would use it.  Does that clear 
> things up?
> 

Yes, I think I understand.

However, even if you don't export the symbol, I don't see how you can
make it private (i.e. static declaration) to file_table.c, since it has
to remain extern, in order to be visible to af_unix.c.

> P.S.: Please don't remove people from the CC list if you expect them to 
> respond to your message (Adrian Bunk readded to CC).

Whoops. I should've hit "reply to all" instead of just hitting "reply".
Thanks. I also somehow got this post split off from the main thread.
I've been responding there.

> 
> Cheers,
> Kyle Moffett
> -
> 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/
-- 
James C. Georgas <jgeorgas@rogers.com>

Re: [2.6 patch] make UNIX a bool

[Kyle Moffett]

On Mar 3, 2006, at 16:31:51, James C. Georgas wrote:
> On Thu, 2006-02-03 at 23:32 -0500, Kyle Moffett wrote:
>> af_unix (IE: CONFIG_UNIX) currently uses the symbol  
>> get_max_files.  It is the only module that uses that symbol, and  
>> that symbol probably should not be exported as it's kind of an  
>> internal API.  Therefore if we mandate that CONFIG_UNIX != m, then  
>> that symbol may be properly unexported and made private, because  
>> nothing modular would use it.  Does that clear things up?
>
> Yes, I think I understand.
>
> However, even if you don't export the symbol, I don't see how you  
> can make it private (i.e. static declaration) to file_table.c,  
> since it has to remain extern, in order to be visible to af_unix.c.

You're missing some crucial information about how Linux operates.   
EXPORT_SYMBOL != extern.  Basically, Linux maintains a list of  
symbols that dynamically loaded modules are allowed to use, along  
with some technical usage restrictions on each  (Symbols exported  
with EXPORT_SYMBOL_GPL may only be used by modules that declare  
'MODULE_LICENSE("GPL");'.)  Exporting a symbol increases the  
likliehood that some module author will use it inappropriately, and  
bloats the kernel.  In this case, removing the EXPORT_SYMBOL() would  
be a good thing.

Cheers,
Kyle Moffett

Re: [2.6 patch] make UNIX a bool

[James C. Georgas]

On Sat, 2006-04-03 at 17:57 -0500, Kyle Moffett wrote:
> On Mar 3, 2006, at 16:31:51, James C. Georgas wrote:
> > On Thu, 2006-02-03 at 23:32 -0500, Kyle Moffett wrote:
> >> af_unix (IE: CONFIG_UNIX) currently uses the symbol  
> >> get_max_files.  It is the only module that uses that symbol, and  
> >> that symbol probably should not be exported as it's kind of an  
> >> internal API.  Therefore if we mandate that CONFIG_UNIX != m, then  
> >> that symbol may be properly unexported and made private, because  
> >> nothing modular would use it.  Does that clear things up?
> >
> > Yes, I think I understand.
> >
> > However, even if you don't export the symbol, I don't see how you  
> > can make it private (i.e. static declaration) to file_table.c,  
> > since it has to remain extern, in order to be visible to af_unix.c.
> 
> You're missing some crucial information about how Linux operates.   
> EXPORT_SYMBOL != extern.  Basically, Linux maintains a list of  
> symbols that dynamically loaded modules are allowed to use, along  
> with some technical usage restrictions on each  (Symbols exported  
> with EXPORT_SYMBOL_GPL may only be used by modules that declare  
> 'MODULE_LICENSE("GPL");'.) Exporting a symbol increases the 
> likliehood that some module author will use it inappropriately, and  
> bloats the kernel.  In this case, removing the EXPORT_SYMBOL() would  
> be a good thing.

Isn't it kind of pointless to not EXPORT a symbol if the symbol is still
declared globally in an include/linux/ header file? If the intent is to
prevent abuse of the symbol, then this doesn't do it, because I can just
statically compile my module into the kernel, and keep on using that
symbol.

It makes sense to me to remove the EXPORT of geget_max_filest_max_files,
if the intent is to eventually remove 




I was under the impression that Adrian wanted 
> 
> Cheers,
> Kyle Moffett
> 
-- 
James C. Georgas <jgeorgas@rogers.com>

Re: [2.6 patch] make UNIX a bool

[James C. Georgas]

Excuse me - sent half a response earlier.

On Sat, 2006-04-03 at 17:57 -0500, Kyle Moffett wrote:
> On Mar 3, 2006, at 16:31:51, James C. Georgas wrote:
> > On Thu, 2006-02-03 at 23:32 -0500, Kyle Moffett wrote:
> >> af_unix (IE: CONFIG_UNIX) currently uses the symbol  
> >> get_max_files.  It is the only module that uses that symbol, and  
> >> that symbol probably should not be exported as it's kind of an  
> >> internal API.  Therefore if we mandate that CONFIG_UNIX != m, then  
> >> that symbol may be properly unexported and made private, because  
> >> nothing modular would use it.  Does that clear things up?
> >
> > Yes, I think I understand.
> >
> > However, even if you don't export the symbol, I don't see how you  
> > can make it private (i.e. static declaration) to file_table.c,  
> > since it has to remain extern, in order to be visible to af_unix.c.
> 
> You're missing some crucial information about how Linux operates.   
> EXPORT_SYMBOL != extern.  Basically, Linux maintains a list of  
> symbols that dynamically loaded modules are allowed to use, along  
> with some technical usage restrictions on each  (Symbols exported  
> with EXPORT_SYMBOL_GPL may only be used by modules that declare  
> 'MODULE_LICENSE("GPL");'.)  Exporting a symbol increases the  
> likliehood that some module author will use it inappropriately, and  
> bloats the kernel.  In this case, removing the EXPORT_SYMBOL() would  
> be a good thing.


Isn't it kind of pointless to not EXPORT a symbol if the symbol is still
declared globally in an include/linux/ header file? If the intent is to
prevent abuse of the symbol, then this doesn't do it, because I can just
statically compile my module into the kernel, and keep on using that
symbol.

It makes sense to me to remove the EXPORT of get_max_files only if the
intent is to eventually remove the get_max_files function from
include/linux/fs.h.

This would require that af_unix.c calculate the maximum number of
allowed open Unix sockets from information other than the
files_stat.max_files value is fs/file_table.c.

If that's the intent, then there's no point in disallowing AF_UNIX=m.
Doing this just so one can unEXPORT a symbol only fixes half the issue.

> Cheers,
> Kyle Moffett
> 
-- 
James C. Georgas <jgeorgas@rogers.com>

[PATCH 0/2] RCU updates

[Dipankar Sarma]

Here are the patches that I have been testing that should help
some of the latency and OOM issues (file limit) that we had
discussed in the past. If the patchset looks ok,
we should queue them up in -mm for some testing before
merging. I have lightly tested the patchset on both ppc64 and x86_64
using ltp, dbench etc.

Update since the last time I published - file counting stuff uses
percpu_counter.

Thanks
Dipankar

Re: [PATCH 1/2] rcu batch tuning

[Dipankar Sarma]

This patch adds new tunables for RCU queue and finished batches.
There are two types of controls - number of completed RCU updates
invoked in a batch (blimit) and monitoring for high rate of
incoming RCUs on a cpu (qhimark, qlowmark). By default,
the per-cpu batch limit is set to a small value. If
the input RCU rate exceeds the high watermark, we do two things -
force quiescent state on all cpus and set the batch limit
of the CPU to INTMAX. Setting batch limit to INTMAX forces all
finished RCUs to be processed in one shot. If we have more than
INTMAX RCUs queued up, then we have bigger problems anyway.
Once the incoming queued RCUs fall below the low watermark, the batch limit
is set to the default.

Signed-off-by: Dipankar Sarma <dipankar@in.ibm.com>
---


 include/linux/rcupdate.h |    6 +++
 kernel/rcupdate.c        |   76 +++++++++++++++++++++++++++++++++++------------
 2 files changed, 63 insertions(+), 19 deletions(-)

diff -puN include/linux/rcupdate.h~rcu-batch-tuning include/linux/rcupdate.h
--- linux-2.6.16-rc3-rcu/include/linux/rcupdate.h~rcu-batch-tuning	2006-02-15 16:00:02.000000000 +0530
+++ linux-2.6.16-rc3-rcu-dipankar/include/linux/rcupdate.h	2006-02-15 16:00:02.000000000 +0530
@@ -98,13 +98,17 @@ struct rcu_data {
 	long  	       	batch;           /* Batch # for current RCU batch */
 	struct rcu_head *nxtlist;
 	struct rcu_head **nxttail;
-	long            count; /* # of queued items */
+	long            qlen; 	 	 /* # of queued callbacks */
 	struct rcu_head *curlist;
 	struct rcu_head **curtail;
 	struct rcu_head *donelist;
 	struct rcu_head **donetail;
+	long		blimit;		 /* Upper limit on a processed batch */
 	int cpu;
 	struct rcu_head barrier;
+#ifdef CONFIG_SMP
+	long		last_rs_qlen;	 /* qlen during the last resched */
+#endif
 };
 
 DECLARE_PER_CPU(struct rcu_data, rcu_data);
diff -puN kernel/rcupdate.c~rcu-batch-tuning kernel/rcupdate.c
--- linux-2.6.16-rc3-rcu/kernel/rcupdate.c~rcu-batch-tuning	2006-02-15 16:00:02.000000000 +0530
+++ linux-2.6.16-rc3-rcu-dipankar/kernel/rcupdate.c	2006-02-15 16:00:02.000000000 +0530
@@ -67,7 +67,43 @@ DEFINE_PER_CPU(struct rcu_data, rcu_bh_d
 
 /* Fake initialization required by compiler */
 static DEFINE_PER_CPU(struct tasklet_struct, rcu_tasklet) = {NULL};
-static int maxbatch = 10000;
+static int blimit = 10;
+static int qhimark = 10000;
+static int qlowmark = 100;
+#ifdef CONFIG_SMP
+static int rsinterval = 1000;
+#endif
+
+static atomic_t rcu_barrier_cpu_count;
+static struct semaphore rcu_barrier_sema;
+static struct completion rcu_barrier_completion;
+
+#ifdef CONFIG_SMP
+static void force_quiescent_state(struct rcu_data *rdp,
+			struct rcu_ctrlblk *rcp)
+{
+	int cpu;
+	cpumask_t cpumask;
+	set_need_resched();
+	if (unlikely(rdp->qlen - rdp->last_rs_qlen > rsinterval)) {
+		rdp->last_rs_qlen = rdp->qlen;
+		/*
+		 * Don't send IPI to itself. With irqs disabled,
+		 * rdp->cpu is the current cpu.
+		 */
+		cpumask = rcp->cpumask;
+		cpu_clear(rdp->cpu, cpumask);
+		for_each_cpu_mask(cpu, cpumask)
+			smp_send_reschedule(cpu);
+	}
+}
+#else 
+static inline void force_quiescent_state(struct rcu_data *rdp,
+			struct rcu_ctrlblk *rcp)
+{
+	set_need_resched();
+}
+#endif
 
 /**
  * call_rcu - Queue an RCU callback for invocation after a grace period.
@@ -92,17 +128,13 @@ void fastcall call_rcu(struct rcu_head *
 	rdp = &__get_cpu_var(rcu_data);
 	*rdp->nxttail = head;
 	rdp->nxttail = &head->next;
-
-	if (unlikely(++rdp->count > 10000))
-		set_need_resched();
-
+	if (unlikely(++rdp->qlen > qhimark)) {
+		rdp->blimit = INT_MAX;
+		force_quiescent_state(rdp, &rcu_ctrlblk);
+	}
 	local_irq_restore(flags);
 }
 
-static atomic_t rcu_barrier_cpu_count;
-static struct semaphore rcu_barrier_sema;
-static struct completion rcu_barrier_completion;
-
 /**
  * call_rcu_bh - Queue an RCU for invocation after a quicker grace period.
  * @head: structure to be used for queueing the RCU updates.
@@ -131,12 +163,12 @@ void fastcall call_rcu_bh(struct rcu_hea
 	rdp = &__get_cpu_var(rcu_bh_data);
 	*rdp->nxttail = head;
 	rdp->nxttail = &head->next;
-	rdp->count++;
-/*
- *  Should we directly call rcu_do_batch() here ?
- *  if (unlikely(rdp->count > 10000))
- *      rcu_do_batch(rdp);
- */
+
+	if (unlikely(++rdp->qlen > qhimark)) {
+		rdp->blimit = INT_MAX;
+		force_quiescent_state(rdp, &rcu_bh_ctrlblk);
+	}
+
 	local_irq_restore(flags);
 }
 
@@ -199,10 +231,12 @@ static void rcu_do_batch(struct rcu_data
 		next = rdp->donelist = list->next;
 		list->func(list);
 		list = next;
-		rdp->count--;
-		if (++count >= maxbatch)
+		rdp->qlen--;
+		if (++count >= rdp->blimit)
 			break;
 	}
+	if (rdp->blimit == INT_MAX && rdp->qlen <= qlowmark)
+		rdp->blimit = blimit;
 	if (!rdp->donelist)
 		rdp->donetail = &rdp->donelist;
 	else
@@ -473,6 +507,7 @@ static void rcu_init_percpu_data(int cpu
 	rdp->quiescbatch = rcp->completed;
 	rdp->qs_pending = 0;
 	rdp->cpu = cpu;
+	rdp->blimit = blimit;
 }
 
 static void __devinit rcu_online_cpu(int cpu)
@@ -567,7 +602,12 @@ void synchronize_kernel(void)
 	synchronize_rcu();
 }
 
-module_param(maxbatch, int, 0);
+module_param(blimit, int, 0);
+module_param(qhimark, int, 0);
+module_param(qlowmark, int, 0);
+#ifdef CONFIG_SMP
+module_param(rsinterval, int, 0);
+#endif
 EXPORT_SYMBOL_GPL(rcu_batches_completed);
 EXPORT_SYMBOL(call_rcu);  /* WARNING: GPL-only in April 2006. */
 EXPORT_SYMBOL(call_rcu_bh);  /* WARNING: GPL-only in April 2006. */

_

Re: [PATCH 2/2] fix file counting

[Dipankar Sarma]

I have benchmarked this on an x86_64 NUMA system and see no
significant performance difference on kernbench. Tested on
both x86_64 and powerpc.

The way we do file struct accounting is not very suitable for batched
freeing. For scalability reasons, file accounting was constructor/destructor
based. This meant that nr_files was decremented only when
the object was removed from the slab cache. This is
susceptible to slab fragmentation. With RCU based file structure,
consequent batched freeing and a test program like Serge's,
we just speed this up and end up with a very fragmented slab -

llm22:~ # cat /proc/sys/fs/file-nr
587730  0       758844

At the same time, I see only a 2000+ objects in filp cache.
The following patch I fixes this problem. 

This patch changes the file counting by removing the filp_count_lock.
Instead we use a separate percpu counter, nr_files, for now and all
accesses to it are through get_nr_files() api. In the sysctl
handler for nr_files, we populate files_stat.nr_files before returning
to user.

Counting files as an when they are created and destroyed (as opposed
to inside slab) allows us to correctly count open files with RCU.

Signed-off-by: Dipankar Sarma <dipankar@in.ibm.com>
---




 fs/dcache.c          |    2 -
 fs/file_table.c      |   80 +++++++++++++++++++++++++++++++--------------------
 include/linux/file.h |    2 -
 include/linux/fs.h   |    2 +
 kernel/sysctl.c      |    5 ++-
 net/unix/af_unix.c   |    2 -
 6 files changed, 57 insertions(+), 36 deletions(-)

diff -puN fs/dcache.c~fix-file-counting fs/dcache.c
--- linux-2.6.16-rc3-rcu/fs/dcache.c~fix-file-counting	2006-02-15 16:00:02.000000000 +0530
+++ linux-2.6.16-rc3-rcu-dipankar/fs/dcache.c	2006-02-15 16:00:02.000000000 +0530
@@ -1736,7 +1736,7 @@ void __init vfs_caches_init(unsigned lon
 			SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL, NULL);
 
 	filp_cachep = kmem_cache_create("filp", sizeof(struct file), 0,
-			SLAB_HWCACHE_ALIGN|SLAB_PANIC, filp_ctor, filp_dtor);
+			SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL, NULL);
 
 	dcache_init(mempages);
 	inode_init(mempages);
diff -puN fs/file_table.c~fix-file-counting fs/file_table.c
--- linux-2.6.16-rc3-rcu/fs/file_table.c~fix-file-counting	2006-02-15 16:00:02.000000000 +0530
+++ linux-2.6.16-rc3-rcu-dipankar/fs/file_table.c	2006-02-16 21:52:35.000000000 +0530
@@ -5,6 +5,7 @@
  *  Copyright (C) 1997 David S. Miller (davem@caip.rutgers.edu)
  */
 
+#include <linux/config.h>
 #include <linux/string.h>
 #include <linux/slab.h>
 #include <linux/file.h>
@@ -19,52 +20,67 @@
 #include <linux/capability.h>
 #include <linux/cdev.h>
 #include <linux/fsnotify.h>
-
+#include <linux/sysctl.h>
+#include <linux/percpu_counter.h>
+#include <asm/atomic.h>
+  
 /* sysctl tunables... */
 struct files_stat_struct files_stat = {
 	.max_files = NR_FILE
 };
 
-EXPORT_SYMBOL(files_stat); /* Needed by unix.o */
-
 /* public. Not pretty! */
- __cacheline_aligned_in_smp DEFINE_SPINLOCK(files_lock);
+__cacheline_aligned_in_smp DEFINE_SPINLOCK(files_lock);
+  
+static struct percpu_counter nr_files __cacheline_aligned_in_smp;
 
-static DEFINE_SPINLOCK(filp_count_lock);
+static inline void file_free_rcu(struct rcu_head *head)
+{
+	struct file *f =  container_of(head, struct file, f_u.fu_rcuhead);
+	kmem_cache_free(filp_cachep, f);
+}
 
-/* slab constructors and destructors are called from arbitrary
- * context and must be fully threaded - use a local spinlock
- * to protect files_stat.nr_files
+static inline void file_free(struct file *f)
+{
+	percpu_counter_mod(&nr_files, -1L);
+	call_rcu(&f->f_u.fu_rcuhead, file_free_rcu);
+}
+  
+/*
+ * Return the total number of open files in the system
  */
-void filp_ctor(void *objp, struct kmem_cache *cachep, unsigned long cflags)
+int get_nr_files(void)
 {
-	if ((cflags & (SLAB_CTOR_VERIFY|SLAB_CTOR_CONSTRUCTOR)) ==
-	    SLAB_CTOR_CONSTRUCTOR) {
-		unsigned long flags;
-		spin_lock_irqsave(&filp_count_lock, flags);
-		files_stat.nr_files++;
-		spin_unlock_irqrestore(&filp_count_lock, flags);
-	}
+	return percpu_counter_read_positive(&nr_files);
 }
 
-void filp_dtor(void *objp, struct kmem_cache *cachep, unsigned long dflags)
+/*
+ * Return the maximum number of open files in the system
+ */
+int get_max_files(void)
 {
-	unsigned long flags;
-	spin_lock_irqsave(&filp_count_lock, flags);
-	files_stat.nr_files--;
-	spin_unlock_irqrestore(&filp_count_lock, flags);
+	return files_stat.max_files;
 }
 
-static inline void file_free_rcu(struct rcu_head *head)
+EXPORT_SYMBOL(get_max_files);
+
+/*
+ * Handle nr_files sysctl
+ */
+#if defined(CONFIG_SYSCTL) && defined(CONFIG_PROC_FS)
+int proc_nr_files(ctl_table *table, int write, struct file *filp,
+                     void __user *buffer, size_t *lenp, loff_t *ppos)
 {
-	struct file *f =  container_of(head, struct file, f_u.fu_rcuhead);
-	kmem_cache_free(filp_cachep, f);
+	files_stat.nr_files = get_nr_files();
+	return proc_dointvec(table, write, filp, buffer, lenp, ppos);
 }
-
-static inline void file_free(struct file *f)
+#else
+int proc_nr_files(ctl_table *table, int write, struct file *filp,
+                     void __user *buffer, size_t *lenp, loff_t *ppos)
 {
-	call_rcu(&f->f_u.fu_rcuhead, file_free_rcu);
+	return -ENOSYS;
 }
+#endif
 
 /* Find an unused file structure and return a pointer to it.
  * Returns NULL, if there are no more free file structures or
@@ -78,7 +94,7 @@ struct file *get_empty_filp(void)
 	/*
 	 * Privileged users can go above max_files
 	 */
-	if (files_stat.nr_files >= files_stat.max_files &&
+	if (get_nr_files() >= files_stat.max_files &&
 				!capable(CAP_SYS_ADMIN))
 		goto over;
 
@@ -86,6 +102,7 @@ struct file *get_empty_filp(void)
 	if (f == NULL)
 		goto fail;
 
+	percpu_counter_mod(&nr_files, 1L);
 	memset(f, 0, sizeof(*f));
 	if (security_file_alloc(f))
 		goto fail_sec;
@@ -101,10 +118,10 @@ struct file *get_empty_filp(void)
 
 over:
 	/* Ran out of filps - report that */
-	if (files_stat.nr_files > old_max) {
+	if (get_nr_files() > old_max) {
 		printk(KERN_INFO "VFS: file-max limit %d reached\n",
-					files_stat.max_files);
-		old_max = files_stat.nr_files;
+					get_max_files());
+		old_max = get_nr_files();
 	}
 	goto fail;
 
@@ -276,4 +293,5 @@ void __init files_init(unsigned long mem
 	if (files_stat.max_files < NR_FILE)
 		files_stat.max_files = NR_FILE;
 	files_defer_init();
+	percpu_counter_init(&nr_files);
 } 
diff -puN include/linux/file.h~fix-file-counting include/linux/file.h
--- linux-2.6.16-rc3-rcu/include/linux/file.h~fix-file-counting	2006-02-15 16:00:02.000000000 +0530
+++ linux-2.6.16-rc3-rcu-dipankar/include/linux/file.h	2006-02-15 16:00:02.000000000 +0530
@@ -60,8 +60,6 @@ extern void put_filp(struct file *);
 extern int get_unused_fd(void);
 extern void FASTCALL(put_unused_fd(unsigned int fd));
 struct kmem_cache;
-extern void filp_ctor(void * objp, struct kmem_cache *cachep, unsigned long cflags);
-extern void filp_dtor(void * objp, struct kmem_cache *cachep, unsigned long dflags);
 
 extern struct file ** alloc_fd_array(int);
 extern void free_fd_array(struct file **, int);
diff -puN include/linux/fs.h~fix-file-counting include/linux/fs.h
--- linux-2.6.16-rc3-rcu/include/linux/fs.h~fix-file-counting	2006-02-15 16:00:02.000000000 +0530
+++ linux-2.6.16-rc3-rcu-dipankar/include/linux/fs.h	2006-02-15 16:00:02.000000000 +0530
@@ -35,6 +35,8 @@ struct files_stat_struct {
 	int max_files;		/* tunable */
 };
 extern struct files_stat_struct files_stat;
+extern int get_nr_files(void);
+extern int get_max_files(void);
 
 struct inodes_stat_t {
 	int nr_inodes;
diff -puN kernel/sysctl.c~fix-file-counting kernel/sysctl.c
--- linux-2.6.16-rc3-rcu/kernel/sysctl.c~fix-file-counting	2006-02-15 16:00:02.000000000 +0530
+++ linux-2.6.16-rc3-rcu-dipankar/kernel/sysctl.c	2006-02-15 16:00:02.000000000 +0530
@@ -52,6 +52,9 @@
 #include <linux/nfs_fs.h>
 #endif
 
+extern int proc_nr_files(ctl_table *table, int write, struct file *filp,
+                     void __user *buffer, size_t *lenp, loff_t *ppos);
+
 #if defined(CONFIG_SYSCTL)
 
 /* External variables not in a header file. */
@@ -921,7 +924,7 @@ static ctl_table fs_table[] = {
 		.data		= &files_stat,
 		.maxlen		= 3*sizeof(int),
 		.mode		= 0444,
-		.proc_handler	= &proc_dointvec,
+		.proc_handler	= &proc_nr_files,
 	},
 	{
 		.ctl_name	= FS_MAXFILE,
diff -puN net/unix/af_unix.c~fix-file-counting net/unix/af_unix.c
--- linux-2.6.16-rc3-rcu/net/unix/af_unix.c~fix-file-counting	2006-02-15 16:00:02.000000000 +0530
+++ linux-2.6.16-rc3-rcu-dipankar/net/unix/af_unix.c	2006-02-15 16:00:02.000000000 +0530
@@ -547,7 +547,7 @@ static struct sock * unix_create1(struct
 	struct sock *sk = NULL;
 	struct unix_sock *u;
 
-	if (atomic_read(&unix_nr_socks) >= 2*files_stat.max_files)
+	if (atomic_read(&unix_nr_socks) >= 2*get_max_files())
 		goto out;
 
 	sk = sk_alloc(PF_UNIX, GFP_KERNEL, &unix_proto, 1);

_

Re: [PATCH 2/2] fix file counting

[Andrew Morton]

Dipankar Sarma <dipankar@in.ibm.com> wrote:
>
> I have benchmarked this on an x86_64 NUMA system and see no
>  significant performance difference on kernbench. Tested on
>  both x86_64 and powerpc.
> 
>  The way we do file struct accounting is not very suitable for batched
>  freeing. For scalability reasons, file accounting was constructor/destructor
>  based. This meant that nr_files was decremented only when
>  the object was removed from the slab cache. This is
>  susceptible to slab fragmentation. With RCU based file structure,
>  consequent batched freeing and a test program like Serge's,
>  we just speed this up and end up with a very fragmented slab -
> 
>  llm22:~ # cat /proc/sys/fs/file-nr
>  587730  0       758844
> 
>  At the same time, I see only a 2000+ objects in filp cache.
>  The following patch I fixes this problem. 
> 
>  This patch changes the file counting by removing the filp_count_lock.
>  Instead we use a separate percpu counter, nr_files, for now and all
>  accesses to it are through get_nr_files() api. In the sysctl
>  handler for nr_files, we populate files_stat.nr_files before returning
>  to user.
> 
>  Counting files as an when they are created and destroyed (as opposed
>  to inside slab) allows us to correctly count open files with RCU.

Fair enough.

What do you think of these changes?




From: Andrew Morton <akpm@osdl.org>

- Nuke the blank line between "}" and EXPORT_SYMBOL().  That's never seemed
  pointful to me.

- Make the get_max_files export use _GPL - only unix.ko uses it.

- Use `-1' in the arg to percpu_counter_mod() rather than `-1L'.  The
  compiler will dtrt and we shouldn't be peering inside percpu_counter
  internals here anyway.

- Scrub that - use percpu_counter_dec() and percpu_counter_inc().

- percpu_counters can be inaccurate on big SMP.  Before we actually fail a
  get_empty_filp() attempt, use the (new in -mm) expensive
  percpu_counter_sum() to check whether we're really over the limit.

- Make get_nr_files() static.  Which is just as well - any callers might
  want the percpu_counter_sum() treatment.  In which case we'd be better off
  exporting some

	bool are_files_over_limit(how_many_i_want);

  API.

Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 fs/file_table.c    |   21 +++++++++++++--------
 include/linux/fs.h |    1 -
 2 files changed, 13 insertions(+), 9 deletions(-)

diff -puN fs/file_table.c~fix-file-counting-fixes fs/file_table.c
--- devel/fs/file_table.c~fix-file-counting-fixes	2006-02-18 01:02:43.000000000 -0800
+++ devel-akpm/fs/file_table.c	2006-02-18 01:02:43.000000000 -0800
@@ -22,6 +22,7 @@
 #include <linux/fsnotify.h>
 #include <linux/sysctl.h>
 #include <linux/percpu_counter.h>
+
 #include <asm/atomic.h>
 
 /* sysctl tunables... */
@@ -42,14 +43,14 @@ static inline void file_free_rcu(struct 
 
 static inline void file_free(struct file *f)
 {
-	percpu_counter_mod(&nr_files, -1L);
+	percpu_counter_dec(&nr_files);
 	call_rcu(&f->f_u.fu_rcuhead, file_free_rcu);
 }
 
 /*
  * Return the total number of open files in the system
  */
-int get_nr_files(void)
+static int get_nr_files(void)
 {
 	return percpu_counter_read_positive(&nr_files);
 }
@@ -61,8 +62,7 @@ int get_max_files(void)
 {
 	return files_stat.max_files;
 }
-
-EXPORT_SYMBOL(get_max_files);
+EXPORT_SYMBOL_GPL(get_max_files);
 
 /*
  * Handle nr_files sysctl
@@ -95,15 +95,20 @@ struct file *get_empty_filp(void)
 	/*
 	 * Privileged users can go above max_files
 	 */
-	if (get_nr_files() >= files_stat.max_files &&
-				!capable(CAP_SYS_ADMIN))
-		goto over;
+	if (get_nr_files() >= files_stat.max_files && !capable(CAP_SYS_ADMIN)) {
+		/*
+		 * percpu_counters are inaccurate.  Do an expensive check before
+		 * we go and fail.
+		 */
+		if (percpu_counter_sum(&nr_files) >= files_stat.max_files)
+			goto over;
+	}
 
 	f = kmem_cache_alloc(filp_cachep, GFP_KERNEL);
 	if (f == NULL)
 		goto fail;
 
-	percpu_counter_mod(&nr_files, 1L);
+	percpu_counter_inc(&nr_files);
 	memset(f, 0, sizeof(*f));
 	if (security_file_alloc(f))
 		goto fail_sec;
diff -puN include/linux/fs.h~fix-file-counting-fixes include/linux/fs.h
--- devel/include/linux/fs.h~fix-file-counting-fixes	2006-02-18 01:02:43.000000000 -0800
+++ devel-akpm/include/linux/fs.h	2006-02-18 01:02:43.000000000 -0800
@@ -35,7 +35,6 @@ struct files_stat_struct {
 	int max_files;		/* tunable */
 };
 extern struct files_stat_struct files_stat;
-extern int get_nr_files(void);
 extern int get_max_files(void);
 
 struct inodes_stat_t {
_

Re: [PATCH 2/2] fix file counting

[Dipankar Sarma]

On Sat, Feb 18, 2006 at 01:04:14AM -0800, Andrew Morton wrote:
> Dipankar Sarma <dipankar@in.ibm.com> wrote:
> Fair enough.
> 
> What do you think of these changes?
> 
> 
> - Nuke the blank line between "}" and EXPORT_SYMBOL().  That's never seemed
>   pointful to me.

Sounds good.

> 
> - Make the get_max_files export use _GPL - only unix.ko uses it.

Always good. I just didn't want to be the one :)

> - Use `-1' in the arg to percpu_counter_mod() rather than `-1L'.  The
>   compiler will dtrt and we shouldn't be peering inside percpu_counter
>   internals here anyway.
> 
> - Scrub that - use percpu_counter_dec() and percpu_counter_inc().

Gah! I missed those APIs. Makes perfect sense.

> 
> - percpu_counters can be inaccurate on big SMP.  Before we actually fail a
>   get_empty_filp() attempt, use the (new in -mm) expensive
>   percpu_counter_sum() to check whether we're really over the limit.


> -	if (get_nr_files() >= files_stat.max_files &&
> -				!capable(CAP_SYS_ADMIN))
> -		goto over;
> +	if (get_nr_files() >= files_stat.max_files && !capable(CAP_SYS_ADMIN)) {
> +		/*
> +		 * percpu_counters are inaccurate.  Do an expensive check before
> +		 * we go and fail.
> +		 */
> +		if (percpu_counter_sum(&nr_files) >= files_stat.max_files)
> +			goto over;
> +	}

Slight optimization -

	if (get_nr_files() >= files_stat.max_files) {
		if (capable(CAP_SYS_ADMIN)) {
		/*
		 * percpu_counters are inaccurate.  Do an expensive check before
		 * we go and fail.
		 */
			if (percpu_counter_sum(&nr_files) >= 
						files_stat.max_files)
				goto over;
		} else 
			goto over;
	}
	
>  
> 
> - Make get_nr_files() static.  Which is just as well - any callers might
>   want the percpu_counter_sum() treatment.  In which case we'd be better off
>   exporting some
> 
> 	bool are_files_over_limit(how_many_i_want);

Well, as of now there is none (xfs use was removed a few months ago).
So, I removed the EXPORT_SYMBOL for get_nr_files() and forgot to
make it static. Your patch does the right thing.

Thanks
Dipankar

Re: [PATCH 2/2] fix file counting

[Christoph Hellwig]

> > - Make the get_max_files export use _GPL - only unix.ko uses it.

The real question is, does af_unix really need to allow beeing built
modular?  It's quite different from other network protocol and deeply
tied to the kernel due to things like descriptor passing or using
the filesystem namespace.  I already had to export another symbol that
really should be internal just for it, and if one module acquires lots
of such hacks it's usually a bad sign..

Re: [PATCH 2/2] fix file counting

[Arjan van de Ven]

On Sat, 2006-02-18 at 12:14 +0000, Christoph Hellwig wrote:
> > > - Make the get_max_files export use _GPL - only unix.ko uses it.
> 
> The real question is, does af_unix really need to allow beeing built
> modular?  It's quite different from other network protocol and deeply
> tied to the kernel due to things like descriptor passing or using
> the filesystem namespace.  I already had to export another symbol that
> really should be internal just for it, and if one module acquires lots
> of such hacks it's usually a bad sign..

in 2.4 the answer would have been simple; modutils back then used
AF_UNIX stuff before it could load modules, so modular was in practice
impossible. 

Anyway I'd agree with making this non-modular... NOBODY will use this as
a module, or if they do loading it somehow is the very first thing done.
You just can't live without this, so making it a module is non-sensical.

[2.6 patch] make UNIX a bool

[Adrian Bunk]

On Sat, Feb 18, 2006 at 01:31:30PM +0100, Arjan van de Ven wrote:
> On Sat, 2006-02-18 at 12:14 +0000, Christoph Hellwig wrote:
> > > > - Make the get_max_files export use _GPL - only unix.ko uses it.
> > 
> > The real question is, does af_unix really need to allow beeing built
> > modular?  It's quite different from other network protocol and deeply
> > tied to the kernel due to things like descriptor passing or using
> > the filesystem namespace.  I already had to export another symbol that
> > really should be internal just for it, and if one module acquires lots
> > of such hacks it's usually a bad sign..
> 
> in 2.4 the answer would have been simple; modutils back then used
> AF_UNIX stuff before it could load modules, so modular was in practice
> impossible. 
> 
> Anyway I'd agree with making this non-modular... NOBODY will use this as
> a module, or if they do loading it somehow is the very first thing done.
> You just can't live without this, so making it a module is non-sensical.

So let's send a patch.  ;-)

cu
Adrian


<--  snip  -->


CONFIG_UNIX=m doesn't make much sense.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.16-rc4-mm1-full/net/unix/Kconfig.old	2006-02-20 14:40:19.000000000 +0100
+++ linux-2.6.16-rc4-mm1-full/net/unix/Kconfig	2006-02-20 14:40:27.000000000 +0100
@@ -3,7 +3,7 @@
 #
 
 config UNIX
-	tristate "Unix domain sockets"
+	bool "Unix domain sockets"
 	---help---
 	  If you say Y here, you will include support for Unix domain sockets;
 	  sockets are the standard Unix mechanism for establishing and