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

[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>

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

[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 --]

[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

[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

[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 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 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 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 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

[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

[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

[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

[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

[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: [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 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

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

[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

[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: 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

[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 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

[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

[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 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

[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 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

[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 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

[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

[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

[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-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

[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

[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

[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.

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

[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.

[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

[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