CONFIG_UNIX=m doesn't make much sense.
Signed-off-by: Adrian Bunk <[email protected]>
---
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
Adrian Bunk wrote:
> CONFIG_UNIX=m doesn't make much sense.
>
>
> Signed-off-by: Adrian Bunk <[email protected]>
>
>
>
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.
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 <[email protected]>
> >
> >
> >
> 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...
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.
El Sat, 25 Feb 2006 09:13:08 -0800,
Stephen Hemminger <[email protected]> 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.
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 <[email protected]>
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 <[email protected]>
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
On Mon, 2006-02-27 17:18:06 -0500, James C. Georgas <[email protected]> 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 [email protected] . +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));
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 <[email protected]>
>> > 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
--
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
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
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.
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~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
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.
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
On Thu, 2006-03-02 18:38:40 +0100, 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.
Kernel image size matters if you try to make it boot off a floppy.
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +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));
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?
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 <[email protected]>
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
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.
> Jesper Juhl <[email protected]>
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
On Thu, 2 Mar 2006 21:28:15 +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?
>
> 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
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 <[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.
>
> 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
On 3/2/06, Adrian Bunk <[email protected]> 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.
>
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 <[email protected]>
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
On Thu, 2006-03-02 21:39:22 +0100, Adrian Bunk <[email protected]> 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 <[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.
> > 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 [email protected] . +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));
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 <[email protected]> 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 <[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.
> > > 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
On Thu, Mar 02, 2006 at 09:40:17PM +0100, Jesper Juhl wrote:
> On 3/2/06, Adrian Bunk <[email protected]> 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.
> >
>
> 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 <[email protected]>
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
On Thu, Mar 02, 2006 at 09:40:17PM +0100, Jesper Juhl wrote:
> On 3/2/06, Adrian Bunk <[email protected]> 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 <[email protected]>
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
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 <[email protected]> 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
>
>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
--
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
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.
>
> > Jesper Juhl <[email protected]>
>
> 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 <[email protected]>
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 <[email protected]>
>
> cu
> Adrian
>
--
James C. Georgas <[email protected]>
On Thu, 2006-03-02 22:28:05 +0100, Adrian Bunk <[email protected]> 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 [email protected] . +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));
On Thu, 2006-03-02 22:46:02 +0100, Adrian Bunk <[email protected]> wrote:
> On Thu, Mar 02, 2006 at 09:40:17PM +0100, Jesper Juhl wrote:
> > On 3/2/06, Adrian Bunk <[email protected]> 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 [email protected] . +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));
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 <[email protected]>
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
>> Well, not directly topic'ed to CONFIG_UNIX, but if the IPv4 stack was modular
>> (like IPv6), we'd probably gain some 100 KB and would not have to worry about
>> CONFIG_UNIX for a while.
>
>I doubt making the IPv4 stack modular is worth the trouble, but feel
>free to send a patch as a basis for a discussion...
>
It would possibly require EXPORT_SYMBOLs, which you seem to be opposed to...
Jan Engelhardt
--
On Fri, Mar 03, 2006 at 02:31:04PM +0100, Jan Engelhardt wrote:
> >> Well, not directly topic'ed to CONFIG_UNIX, but if the IPv4 stack was modular
> >> (like IPv6), we'd probably gain some 100 KB and would not have to worry about
> >> CONFIG_UNIX for a while.
> >
> >I doubt making the IPv4 stack modular is worth the trouble, but feel
> >free to send a patch as a basis for a discussion...
> >
> It would possibly require EXPORT_SYMBOLs, which you seem to be opposed to...
That's not the only point.
There are many cases you have to handle correctly. As a simple example,
CONFIG_W1=y, CONFIG_NET=m or CONFIG_W1=m, CONFIG_NET=m should compile as
expected.
But hey, it's open source and much is possible. If you think this would
be important send a patch and we have a basis for a discussion.
Discussions about probable patches tend to become extremely fruitless.
> Jan Engelhardt
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
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 <[email protected]>
>
> cu
> Adrian
>
--
James C. Georgas <[email protected]>
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 <[email protected]>
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
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 <[email protected]>
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 <[email protected]>
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
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 <[email protected]>
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 <[email protected]>
---
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
On Sat, 2006-03-25 20:47:39 +0100, Adrian Bunk <[email protected]> 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 [email protected] . +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));
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 *).