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 <[email protected]> wrote:
> > > On Thu, Mar 02, 2006 at 12:31:34PM +1100, Herbert Xu wrote:
> > > > Adrian Bunk <[email protected]> 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 <[email protected]>
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 <[email protected]> wrote:
> > > On Thu, Mar 02, 2006 at 12:31:34PM +1100, Herbert Xu wrote:
> > > > Adrian Bunk <[email protected]> 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 <[email protected]>
On Thu, 02 Mar 2006 23:14:38 -0500 "James C. Georgas" <[email protected]> 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
On Thu, 2006-02-03 at 23:32 -0500, Kyle Moffett wrote:
> On Thu, 02 Mar 2006 23:14:38 -0500 "James C. Georgas" <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
James C. Georgas <[email protected]>
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
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 <[email protected]>
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 <[email protected]>