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