As suggested by Adrian Bunk, UNIX domain sockets should always be built in
on normal systems. This is especially true since udev needs these sockets
and fails to run if UNIX=m.
Signed-Off-By: Bodo Eggert <[email protected]>
---
Last minute change: I decided against making it a bool because embedded
folks might depend on a small kernel image. Edited in the patch below.
diff -X dontdiff -pruN linux-2.6.23.base/net/unix/Kconfig linux-2.6.23.socket-y/net/unix/Kconfig
--- linux-2.6.23.base/net/unix/Kconfig 2006-11-29 22:57:37.000000000 +0100
+++ linux-2.6.23.socket-y/net/unix/Kconfig 2007-12-31 12:57:44.000000000 +0100
@@ -3,7 +3,8 @@
#
config UNIX
- tristate "Unix domain sockets"
+ tristate "Unix domain sockets" if EMBEDDED
+ default y
---help---
If you say Y here, you will include support for Unix domain sockets;
sockets are the standard Unix mechanism for establishing and
--
A. Top posters
Q. What's the most annoying thing on Usenet?
From: Bodo Eggert <[email protected]>
Date: Mon, 31 Dec 2007 13:09:43 +0100 (CET)
> As suggested by Adrian Bunk, UNIX domain sockets should always be built in
> on normal systems. This is especially true since udev needs these sockets
> and fails to run if UNIX=m.
>
> Signed-Off-By: Bodo Eggert <[email protected]>
People who use udev can make sure they have it built into their kernel
if they have such a dependency.
Not everyone uses udev, and therefore needs AF_UNIX non-modular.
I keep seeing this crap patch get submitted and I'm going to keep
dropping it because it's bogus.
It seems to stem from some filesystem interface or whatever that the
VFS folks don't want to export or one they want to now stop exporting.
But that is a really cruddy reason to want to force AF_UNIX to not
be allowed to be modular, and the udev thing just makes it more of a
joke rather than a good technical reason.
On Mon, Dec 31, 2007 at 01:09:43PM +0100, Bodo Eggert wrote:
> As suggested by Adrian Bunk, UNIX domain sockets should always be built in
> on normal systems. This is especially true since udev needs these sockets
> and fails to run if UNIX=m.
>
> Signed-Off-By: Bodo Eggert <[email protected]>
>
> ---
> Last minute change: I decided against making it a bool because embedded
> folks might depend on a small kernel image. Edited in the patch below.
>...
Is this just a purely theoretical thought or is this a reasonable use
case people actually use in practice?
After all, changing it to a bool will allow us to make the kernel image
for nearly everyone smaller by a few hundred bytes...
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
when i had that module modular and added to the initrd, udev didn`t work, though.
same error message:
udevd[1226]: init_udev_socket: error getting socket: Address family not supported by protocol
not sure if i did a mistake here....
anyway, this message is not obvious to the end user.
i like the kernel being modular, but i also like it if things "just work" - and with "allmodconfig", modular UNIX domain sockets seem to create hassle.
(see http://forums.gentoo.org/viewtopic-t-476363-highlight-.html or http://forums.gentoo.org/viewtopic-t-463793-highlight-.html )
so, if this patch is being rejected, maybe it would be useful if udev would give a proper hint, if it`s missing this kernel feature.
btw, udev documentation telling this:
- The kernel must have sysfs, unix domain sockets and networking enabled.
(unix domain sockets (CONFIG_UNIX) as a loadable kernel module may work,
but it is completely silly - don't complain if anything goes wrong.)
furthermore, if this needs to be modular, then i`d please have tcp/ip networking modular, too. :)
regards
roland
ps:
not being a skilled programmer, so this is mostly an admins/users perspective.
>
> From: Bodo Eggert <[email protected]>
> Date: Mon, 31 Dec 2007 13:09:43 +0100 (CET)
>
> > As suggested by Adrian Bunk, UNIX domain sockets should always be built in
> > on normal systems. This is especially true since udev needs these sockets
> > and fails to run if UNIX=m.
> >
> > Signed-Off-By: Bodo Eggert <[email protected]>
>
> People who use udev can make sure they have it built into their kernel
> if they have such a dependency.
>
> Not everyone uses udev, and therefore needs AF_UNIX non-modular.
>
> I keep seeing this crap patch get submitted and I'm going to keep
> dropping it because it's bogus.
>
> It seems to stem from some filesystem interface or whatever that the
> VFS folks don't want to export or one they want to now stop exporting.
>
> But that is a really cruddy reason to want to force AF_UNIX to not
> be allowed to be modular, and the udev thing just makes it more of a
> joke rather than a good technical reason.
>
_______________________________________________________________________
Jetzt neu! Sch?tzen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220
On Mon, 31 Dec 2007, Adrian Bunk wrote:
> On Mon, Dec 31, 2007 at 01:09:43PM +0100, Bodo Eggert wrote:
> > As suggested by Adrian Bunk, UNIX domain sockets should always be built in
> > on normal systems. This is especially true since udev needs these sockets
> > and fails to run if UNIX=m.
> >
> > Signed-Off-By: Bodo Eggert <[email protected]>
> >
> > ---
> > Last minute change: I decided against making it a bool because embedded
> > folks might depend on a small kernel image. Edited in the patch below.
> >...
>
> Is this just a purely theoretical thought or is this a reasonable use
> case people actually use in practice?
For now, it's a theoretical thought, but having an embedded device, I can
see the reason for $EVERYTHING=m there.
> After all, changing it to a bool will allow us to make the kernel image
> for nearly everyone smaller by a few hundred bytes...
I can't see why optionally building it as a module would force us to make
the kernel bigger. It may be a little more ugly to support =m, but thats it,
isn't it?
--
Logic: The art of being wrong with confidence...
On Mon, 31 Dec 2007, David Miller wrote:
> From: Bodo Eggert <[email protected]>
> > As suggested by Adrian Bunk, UNIX domain sockets should always be built in
> > on normal systems. This is especially true since udev needs these sockets
> > and fails to run if UNIX=m.
> >
> > Signed-Off-By: Bodo Eggert <[email protected]>
>
> People who use udev can make sure they have it built into their kernel
> if they have such a dependency.
>
> Not everyone uses udev, and therefore needs AF_UNIX non-modular.
That's why I kept this option for embedded folks.
Is there any benefit for non-embedded systems from having UNIX=m?
--
Top 100 things you don't want the sysadmin to say:
89. I got a better job at Lockheed...
On Mon, Dec 31, 2007 at 02:26:42PM +0100, Bodo Eggert wrote:
> On Mon, 31 Dec 2007, Adrian Bunk wrote:
> > On Mon, Dec 31, 2007 at 01:09:43PM +0100, Bodo Eggert wrote:
>
> > > As suggested by Adrian Bunk, UNIX domain sockets should always be built in
> > > on normal systems. This is especially true since udev needs these sockets
> > > and fails to run if UNIX=m.
> > >
> > > Signed-Off-By: Bodo Eggert <[email protected]>
> > >
> > > ---
> > > Last minute change: I decided against making it a bool because embedded
> > > folks might depend on a small kernel image. Edited in the patch below.
> > >...
> >
> > Is this just a purely theoretical thought or is this a reasonable use
> > case people actually use in practice?
>
> For now, it's a theoretical thought, but having an embedded device, I can
> see the reason for $EVERYTHING=m there.
The only advantage I see is that the kernel image you have to flash
can be made smaller - with the disadvantage that the running kernel
is bigger by more than 10%.
If you don't believe me, try it yourself:
Build all drivers statically into your kernel, and then compare the
vmlinux sizes with CONFIG_MODULES=n and CONFIG_MODULES=y.
> > After all, changing it to a bool will allow us to make the kernel image
> > for nearly everyone smaller by a few hundred bytes...
>
> I can't see why optionally building it as a module would force us to make
> the kernel bigger. It may be a little more ugly to support =m, but thats it,
> isn't it?
On architectures like x86 where __exit code is freed at runtime
af_unix_exit() makes your kernel image (but not the running kernel)
bigger.
With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for the
theoretical possibility of CONIG_UNIX=m waste a few hundred bytes
of memory.
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, 31 Dec 2007, Adrian Bunk wrote:
> On Mon, Dec 31, 2007 at 02:26:42PM +0100, Bodo Eggert wrote:
> > On Mon, 31 Dec 2007, Adrian Bunk wrote:
> > > On Mon, Dec 31, 2007 at 01:09:43PM +0100, Bodo Eggert wrote:
> > > > As suggested by Adrian Bunk, UNIX domain sockets should always be built in
> > > > on normal systems. This is especially true since udev needs these sockets
> > > > and fails to run if UNIX=m.
> > > >
> > > > Signed-Off-By: Bodo Eggert <[email protected]>
> > > >
> > > > ---
> > > > Last minute change: I decided against making it a bool because embedded
> > > > folks might depend on a small kernel image. Edited in the patch below.
> > > >...
> > >
> > > Is this just a purely theoretical thought or is this a reasonable use
> > > case people actually use in practice?
> >
> > For now, it's a theoretical thought, but having an embedded device, I can
> > see the reason for $EVERYTHING=m there.
>
> The only advantage I see is that the kernel image you have to flash
> can be made smaller - with the disadvantage that the running kernel
> is bigger by more than 10%.
>
> If you don't believe me, try it yourself:
> Build all drivers statically into your kernel, and then compare the
> vmlinux sizes with CONFIG_MODULES=n and CONFIG_MODULES=y.
If you'd aim for a small kernel image, you would build anything as a module
that is not requred for booting.
> > > After all, changing it to a bool will allow us to make the kernel image
> > > for nearly everyone smaller by a few hundred bytes...
> >
> > I can't see why optionally building it as a module would force us to make
> > the kernel bigger. It may be a little more ugly to support =m, but thats it,
> > isn't it?
>
> On architectures like x86 where __exit code is freed at runtime
> af_unix_exit() makes your kernel image (but not the running kernel)
> bigger.
>
> With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for the
> theoretical possibility of CONIG_UNIX=m waste a few hundred bytes
> of memory.
#define m='m'
#if CONIG_UNIX=='m'
#define EXPORT_SYMBOL_AF_UNIX EXPORT_SYMBOL
#else
#define EXPORT_SYMBOL_AF_UNIX()
#endif
#undef m
You could also use "#if defined(C_U) && (C_U == m)".
--
Funny quotes:
36. You never really learn to swear until you learn to drive.
On Dec 31 2007 16:19, Bodo Eggert wrote:
>Adrian Bunk wrote:
>>
>> The only advantage I see is that the kernel image you have to flash
>> can be made smaller - with the disadvantage that the running kernel
>> is bigger by more than 10%.
>>
>> If you don't believe me, try it yourself:
>> Build all drivers statically into your kernel, and then compare the
>> vmlinux sizes with CONFIG_MODULES=n and CONFIG_MODULES=y.
>
>If you'd aim for a small kernel image, you would build anything as a module
>that is not requred for booting.
>
Yes, there is a tradeoff for both.
Example:
16:30 ichi:../net/802 > l fc.o fc.ko
-rw-r--r-- 1 jengelh users 7961 Dec 27 15:19 fc.ko
-rw-r--r-- 1 jengelh users 2453 Dec 28 23:58 fc.o
(from a recent not-so-complete patch turning CONFIG_FC etc. into =m)
If fc was modular, it might save the 2453 bytes off the core kernel image,
but adds ~5508 bytes to disk.
So one has to pick =y or =m depending on whatever suits his/her situation.
But the choice should be _available_.
>>>> After all, changing it to a bool will allow us to make the
>>>> kernel image for nearly everyone smaller by a few hundred
>>>> bytes...
>>>
>>> I can't see why optionally building it as a module would force us
>>> to make the kernel bigger. It may be a little more ugly to
>>> support =m, but thats it, isn't it?
>>
>> On architectures like x86 where __exit code is freed at runtime
>> af_unix_exit() makes your kernel image (but not the running kernel)
>> bigger.
>>
>> With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for
>> the theoretical possibility of CONIG_UNIX=m waste a few hundred
>> bytes of memory.
On Dec 31, 2007 3:42 PM, Adrian Bunk <[email protected]> wrote:
> With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for the
> theoretical possibility of CONIG_UNIX=m waste a few hundred bytes
> of memory.
One thing I always wondered about in this discussion about wasted
EXPORT_SYMBOL's:
Shouldn't it be possible to garbage collect these?
depmod already contains code to analyze all modules to create a
dependency tree. It should not be too difficult to extend it to create
a list of all symbols that really are used by the current modules.
Everything else could be stripped to save space.
The problem with that:
* out-of-tree modules would break if they don't get lucky to only use
the remaining symbol. I would not see this as a problem, if the help
text of the garbage-collect-option would contain a note like "don't
enable this if you want out-of-tree modules".
* if you later change your .config to include additional modules you
might need to rebuild vmlinux and reboot into the new kernel.
Currently you can probably build and load new modules without a
reboot. (for example: usb drivers)
Torsten
On Monday 31 December 2007 16:55:57 Torsten Kaiser wrote:
> On Dec 31, 2007 3:42 PM, Adrian Bunk <[email protected]> wrote:
> > With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for the
> > theoretical possibility of CONIG_UNIX=m waste a few hundred bytes
> > of memory.
>
> One thing I always wondered about in this discussion about wasted
> EXPORT_SYMBOL's:
> Shouldn't it be possible to garbage collect these?
>
> depmod already contains code to analyze all modules to create a
> dependency tree. It should not be too difficult to extend it to create
> a list of all symbols that really are used by the current modules.
> Everything else could be stripped to save space.
>
> The problem with that:
> * out-of-tree modules would break if they don't get lucky to only use
> the remaining symbol. I would not see this as a problem, if the help
> text of the garbage-collect-option would contain a note like "don't
> enable this if you want out-of-tree modules".
> * if you later change your .config to include additional modules you
> might need to rebuild vmlinux and reboot into the new kernel.
> Currently you can probably build and load new modules without a
> reboot. (for example: usb drivers)
I'd say the practical advantage to the user would be almost zero.
Which distribution is going to enable this option and defacto
banning external modules?
--
Greetings Michael.
> I'd say the practical advantage to the user would be almost zero.
> Which distribution is going to enable this option and defacto
> banning external modules?
It would be a real nuisance for developing code let alone for using it.
The entries are currently far bigger than is needed and fixing that would
be much more productive.
Alan
On Dec 31, 2007 4:59 PM, Michael Buesch <[email protected]> wrote:
> On Monday 31 December 2007 16:55:57 Torsten Kaiser wrote:
> > One thing I always wondered about in this discussion about wasted
> > EXPORT_SYMBOL's:
> > Shouldn't it be possible to garbage collect these?
> >
> > depmod already contains code to analyze all modules to create a
> > dependency tree. It should not be too difficult to extend it to create
> > a list of all symbols that really are used by the current modules.
> > Everything else could be stripped to save space.
> >
> > The problem with that:
> > * out-of-tree modules would break if they don't get lucky to only use
> > the remaining symbol. I would not see this as a problem, if the help
> > text of the garbage-collect-option would contain a note like "don't
> > enable this if you want out-of-tree modules".
> > * if you later change your .config to include additional modules you
> > might need to rebuild vmlinux and reboot into the new kernel.
> > Currently you can probably build and load new modules without a
> > reboot. (for example: usb drivers)
>
> I'd say the practical advantage to the user would be almost zero.
> Which distribution is going to enable this option and defacto
> banning external modules?
I would default this option to not remove used symbols, because it
could break something.
For distributions it could be used in both ways:
* enabled -> only "distro approved" modules can be loaded
* disabled -> works as of now
For every other user who compiles own kernels without external modules
(Not including out-of-tree drivers that get patched into the kernel
code! Only modules that get compiled later independent from the kernel
build!) it will save space.
If this space would not matter there would be no need to be so hard on
currently unused EXPORT_SYMBOLs.
Torsten
On Dec 31, 2007 5:01 PM, Alan Cox <[email protected]> wrote:
> > I'd say the practical advantage to the user would be almost zero.
> > Which distribution is going to enable this option and defacto
> > banning external modules?
>
> It would be a real nuisance for developing code let alone for using it.
Hmm... Why?
a) this could be disabled during development if you want this
b) this would even only affect development if you add new code that
now needs a EXPORT_SYMBOL that was removed on an earlier build. And
right now this would also need to trigger a rerun of depmod. And the
same trigger could redo this garbage collect.
Or am I missing something obvious?
> The entries are currently far bigger than is needed and fixing that would
> be much more productive.
Can't say anything about that. ;)
Torsten
On Mon, 31 Dec 2007 17:17:19 +0100
"Torsten Kaiser" <[email protected]> wrote:
> a) this could be disabled during development if you want this
> b) this would even only affect development if you add new code that
> now needs a EXPORT_SYMBOL that was removed on an earlier build. And
> right now this would also need to trigger a rerun of depmod. And the
> same trigger could redo this garbage collect.
>
> Or am I missing something obvious?
Development is not a phase seperate from use or distribution. A lot of
module testers for distributions will not be compiling their own modules
but loading in ones to test provided by their vendor - which may of
course then need different ksyms
Alan
On Monday 31 December 2007 17:38:03 Alan Cox wrote:
> On Mon, 31 Dec 2007 17:17:19 +0100
> "Torsten Kaiser" <[email protected]> wrote:
>
> > a) this could be disabled during development if you want this
> > b) this would even only affect development if you add new code that
> > now needs a EXPORT_SYMBOL that was removed on an earlier build. And
> > right now this would also need to trigger a rerun of depmod. And the
> > same trigger could redo this garbage collect.
> >
> > Or am I missing something obvious?
>
> Development is not a phase seperate from use or distribution. A lot of
> module testers for distributions will not be compiling their own modules
> but loading in ones to test provided by their vendor - which may of
> course then need different ksyms
As an example, the whole purpose wireless-compat package is
to load latest bleeding edge wireless stuff into a distribution kernel.
So people are not required to recompile their kernels for using
drivers that support their hardware.
And guess what, it is used a _lot_. And lots of bugs are found with it.
It increases our testing community a lot.
So, all this wouldn't work, if kernel symbols could randomly get
nuked by some "garbage collector".
In practice, no distribution would use symbol garbage collection, as the
only benefit from it would be an increased level of bugreports.
--
Greetings Michael.
On Mon, Dec 31, 2007 at 04:19:23PM +0100, Bodo Eggert wrote:
> On Mon, 31 Dec 2007, Adrian Bunk wrote:
> > On Mon, Dec 31, 2007 at 02:26:42PM +0100, Bodo Eggert wrote:
> > > On Mon, 31 Dec 2007, Adrian Bunk wrote:
> > > > On Mon, Dec 31, 2007 at 01:09:43PM +0100, Bodo Eggert wrote:
>
> > > > > As suggested by Adrian Bunk, UNIX domain sockets should always be built in
> > > > > on normal systems. This is especially true since udev needs these sockets
> > > > > and fails to run if UNIX=m.
> > > > >
> > > > > Signed-Off-By: Bodo Eggert <[email protected]>
> > > > >
> > > > > ---
> > > > > Last minute change: I decided against making it a bool because embedded
> > > > > folks might depend on a small kernel image. Edited in the patch below.
> > > > >...
> > > >
> > > > Is this just a purely theoretical thought or is this a reasonable use
> > > > case people actually use in practice?
> > >
> > > For now, it's a theoretical thought, but having an embedded device, I can
> > > see the reason for $EVERYTHING=m there.
> >
> > The only advantage I see is that the kernel image you have to flash
> > can be made smaller - with the disadvantage that the running kernel
> > is bigger by more than 10%.
> >
> > If you don't believe me, try it yourself:
> > Build all drivers statically into your kernel, and then compare the
> > vmlinux sizes with CONFIG_MODULES=n and CONFIG_MODULES=y.
>
> If you'd aim for a small kernel image, you would build anything as a module
> that is not requred for booting.
>
> > > > After all, changing it to a bool will allow us to make the kernel image
> > > > for nearly everyone smaller by a few hundred bytes...
> > >
> > > I can't see why optionally building it as a module would force us to make
> > > the kernel bigger. It may be a little more ugly to support =m, but thats it,
> > > isn't it?
> >
> > On architectures like x86 where __exit code is freed at runtime
> > af_unix_exit() makes your kernel image (but not the running kernel)
> > bigger.
> >
> > With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for the
> > theoretical possibility of CONIG_UNIX=m waste a few hundred bytes
> > of memory.
>
> #define m='m'
> #if CONIG_UNIX=='m'
> #define EXPORT_SYMBOL_AF_UNIX EXPORT_SYMBOL
> #else
> #define EXPORT_SYMBOL_AF_UNIX()
> #endif
> #undef m
>
> You could also use "#if defined(C_U) && (C_U == m)".
Look at the number of exports in the kernel and the number of lines
changed per months, and it becomes obvious that somwthing like that
would not be maintainable.
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, Dec 31, 2007 at 04:34:55PM +0100, Jan Engelhardt wrote:
> >
> >If you'd aim for a small kernel image, you would build anything as a module
> >that is not requred for booting.
> >
> Yes, there is a tradeoff for both.
>
> Example:
> 16:30 ichi:../net/802 > l fc.o fc.ko
> -rw-r--r-- 1 jengelh users 7961 Dec 27 15:19 fc.ko
> -rw-r--r-- 1 jengelh users 2453 Dec 28 23:58 fc.o
> (from a recent not-so-complete patch turning CONFIG_FC etc. into =m)
>
> If fc was modular, it might save the 2453 bytes off the core kernel image,
> but adds ~5508 bytes to disk.
> So one has to pick =y or =m depending on whatever suits his/her situation.
May I ask something that might be obvious for most of the
development community:
Modules have to be loaded in seperate pages, right ?
Does that mean that each module wastes partially used
pages of memory at runtime ?
I've always tried to build as much into the kernel image as
possible, because all of my systems have only 512M memory.
Thanks,
Patrick
On Mon, Dec 31, 2007 at 04:19:23PM +0100, Bodo Eggert wrote:
> On Mon, 31 Dec 2007, Adrian Bunk wrote:
> > On Mon, Dec 31, 2007 at 02:26:42PM +0100, Bodo Eggert wrote:
> > > On Mon, 31 Dec 2007, Adrian Bunk wrote:
> > > > On Mon, Dec 31, 2007 at 01:09:43PM +0100, Bodo Eggert wrote:
>
> > > > > As suggested by Adrian Bunk, UNIX domain sockets should always be built in
> > > > > on normal systems. This is especially true since udev needs these sockets
> > > > > and fails to run if UNIX=m.
> > > > >
> > > > > Signed-Off-By: Bodo Eggert <[email protected]>
> > > > >
> > > > > ---
> > > > > Last minute change: I decided against making it a bool because embedded
> > > > > folks might depend on a small kernel image. Edited in the patch below.
> > > > >...
> > > >
> > > > Is this just a purely theoretical thought or is this a reasonable use
> > > > case people actually use in practice?
> > >
> > > For now, it's a theoretical thought, but having an embedded device, I can
> > > see the reason for $EVERYTHING=m there.
> >
> > The only advantage I see is that the kernel image you have to flash
> > can be made smaller - with the disadvantage that the running kernel
> > is bigger by more than 10%.
> >
> > If you don't believe me, try it yourself:
> > Build all drivers statically into your kernel, and then compare the
> > vmlinux sizes with CONFIG_MODULES=n and CONFIG_MODULES=y.
>
> If you'd aim for a small kernel image, you would build anything as a module
> that is not requred for booting.
>...
Small kernel image to flash (e.g. due to a size limit there), if you
would aim for a small running kernel you wouldn't use modules.
And I'm not so sure about the image size without seeing actual numbers,
e.g. for your device.
Especially comparing your all-modular approach with a CONFIG_MODULES=n
kernel using Denys' section garbage collection patches in both cases
would be interesting.
I'm not claiming you are wrong, all I say is that I'm not convinced
without actual numbers that you are right.
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 Dec 31, 2007 6:18 PM, Michael Buesch <[email protected]> wrote:
> On Monday 31 December 2007 17:38:03 Alan Cox wrote:
> > On Mon, 31 Dec 2007 17:17:19 +0100
> > "Torsten Kaiser" <[email protected]> wrote:
> >
> > > a) this could be disabled during development if you want this
> > > b) this would even only affect development if you add new code that
> > > now needs a EXPORT_SYMBOL that was removed on an earlier build. And
> > > right now this would also need to trigger a rerun of depmod. And the
> > > same trigger could redo this garbage collect.
> > >
> > > Or am I missing something obvious?
> >
> > Development is not a phase seperate from use or distribution. A lot of
> > module testers for distributions will not be compiling their own modules
> > but loading in ones to test provided by their vendor - which may of
> > course then need different ksyms
I understand that point.
I just always assumed that kernel tests meant 'please test this patch'
and doing the compile yourself.
But I'm not convinced be the following:
> As an example, the whole purpose wireless-compat package is
> to load latest bleeding edge wireless stuff into a distribution kernel.
> So people are not required to recompile their kernels for using
> drivers that support their hardware.
> And guess what, it is used a _lot_. And lots of bugs are found with it.
> It increases our testing community a lot.
This looks more like a "regular" out-of-tree module for the purpose of
the suggested symbol garbage collector.
And for that case I already a 'don't use it then'-note.
The base problem is that there already are many options to break
external modules. (CONFIG_MODULES=n ;) )
Or in the case of this wireless module: CONFIG_CRYPTO_ARC4=n
(Without 'arc4' ieee80211_wep_init() will fail, that will fail
ieee80211_register_hw() and so no mac80211 driver could be loaded)
> So, all this wouldn't work, if kernel symbols could randomly get
> nuked by some "garbage collector".
>
> In practice, no distribution would use symbol garbage collection, as the
> only benefit from it would be an increased level of bugreports.
The question I can't answer in this context is: Do distributions want
to support external modules?
Only if yes, your argument is valid. But then they could just disable
this feature and prevent this kind of bugreports.
Torsten
On Monday 31 December 2007 19:37:43 Torsten Kaiser wrote:
> The base problem is that there already are many options to break
> external modules. (CONFIG_MODULES=n ;) )
Exactly. There already are enough ways to break external modules.
No need to introduce more. ;)
> The question I can't answer in this context is: Do distributions want
> to support external modules?
> Only if yes, your argument is valid. But then they could just disable
> this feature and prevent this kind of bugreports.
That's my point. Nobody will risk bugs to save a few bytes of memory.
--
Greetings Michael.
On Mon, Dec 31, 2007 at 03:03:20PM +0100, Bodo Eggert wrote:
> On Mon, 31 Dec 2007, David Miller wrote:
> > From: Bodo Eggert <[email protected]>
>
> > > As suggested by Adrian Bunk, UNIX domain sockets should always be built in
> > > on normal systems. This is especially true since udev needs these sockets
> > > and fails to run if UNIX=m.
> > >
> > > Signed-Off-By: Bodo Eggert <[email protected]>
> >
> > People who use udev can make sure they have it built into their kernel
> > if they have such a dependency.
> >
> > Not everyone uses udev, and therefore needs AF_UNIX non-modular.
>
> That's why I kept this option for embedded folks.
>
> Is there any benefit for non-embedded systems from having UNIX=m?
udev-free != embedded.
On Dec 31 2007 18:43, Patrick Mau wrote:
>
>May I ask something that might be obvious for most of the
>development community:
>
>Modules have to be loaded in seperate pages, right ?
That seems to be the case, judging from /proc/modules always ending in 000,
meaning each module is aligned at 0x1000 (4096, a page on i386).
Additionally, it looks like 48% of all kernel symbols (from System.map)
are aligned to 16 byte boundaries (what a waste! ;-))
On Mon, 31 Dec 2007, Al Viro wrote:
> On Mon, Dec 31, 2007 at 03:03:20PM +0100, Bodo Eggert wrote:
> > On Mon, 31 Dec 2007, David Miller wrote:
> > > From: Bodo Eggert <[email protected]>
> > > > As suggested by Adrian Bunk, UNIX domain sockets should always be built in
> > > > on normal systems. This is especially true since udev needs these sockets
> > > > and fails to run if UNIX=m.
> > > >
> > > > Signed-Off-By: Bodo Eggert <[email protected]>
> > >
> > > People who use udev can make sure they have it built into their kernel
> > > if they have such a dependency.
> > >
> > > Not everyone uses udev, and therefore needs AF_UNIX non-modular.
> >
> > That's why I kept this option for embedded folks.
> >
> > Is there any benefit for non-embedded systems from having UNIX=m?
>
> udev-free != embedded.
But UNIX=m == waste RAM and have an effectively b0rken system until the
module is loaded. It would be silly to do this unless you have a very small
space for the kernel image and some free space for storing the needed
modules. The big question is: Is there any non-embedded system where you
have to aim for a small kernel image?
--
Fun things to slip into your budget
Half a million dollars for consultants to design a web site that was being
done by an intern in his spare time.
From: Bodo Eggert <[email protected]>
Date: Tue, 1 Jan 2008 04:45:21 +0100 (CET)
> The big question is: Is there any non-embedded system where you have
> to aim for a small kernel image?
One some platforms, due to bootloader restrictions or whatever,
there are hard limits on how large the main kernel image can be.
On sparc64 for example the limit is around 6.5MB
But this "big question" isn't the important issue, in fact it's
tangental and has no bearing on the final decision we make
here.
Rather, choice is, and taking choice away is bad. I may have a reason
to make AF_UNIX modular, I might not, but either way taking that
option away from me is not the right thing to do.
On Mon, 31 Dec 2007, David Miller wrote:
> From: Bodo Eggert <[email protected]>
> > The big question is: Is there any non-embedded system where you have
> > to aim for a small kernel image?
>
> One some platforms, due to bootloader restrictions or whatever,
> there are hard limits on how large the main kernel image can be.
>
> On sparc64 for example the limit is around 6.5MB
That would be about the size of a complete rescue system. I don't think we
need to worry about unix sockets there, do we?
> But this "big question" isn't the important issue, in fact it's
> tangental and has no bearing on the final decision we make
> here.
>
> Rather, choice is, and taking choice away is bad. I may have a reason
> to make AF_UNIX modular, I might not, but either way taking that
> option away from me is not the right thing to do.
_You_'ll still have the option, because you have selected EMBEDDED=y
(otherwise, you'd miss all other valuable options to cripple your kernel),
while the folks that just care for a working systems will have what they'd
select anyway without being bothered with useless questions.
--
Top 100 things you don't want the sysadmin to say:
5. Just add yourself to the password file and make a directory...
On Tue, Jan 01, 2008 at 04:45:21AM +0100, Bodo Eggert wrote:
> > udev-free != embedded.
>
> But UNIX=m == waste RAM and have an effectively b0rken system until the
> module is loaded.
Well, the system isn't necessarily totally broken. If you don't use
udev, then system will be crippled, but not totally broken. Then
again, besides udev, packages such as dbus, gdm, and acpid all use
Unix Domain Sockets --- not to mention cups, avahi-daemon, bluez,
emacsclient, and any X program when the DISPLAY is :0.0.
The question is whether the size of the Unix domain sockets support is
worth the complexity of yet another config option that we expose to
the user. For the embedded world, OK, maybe they want to save 14k of
non-swappable memory. But for the non-embedded world, given the 117k
mandatory memory usage of sysfs, or the 124k memory usage of the core
networking stack, never mind the 3 megabytes of memory used by objects
in the kernel subdirectory, it's not clear that it's worth worrying
over 14k of memory, especially when many Unix programs assume
that Unix Domain Sockets are present.
- Ted
Theodore Tso <[email protected]> wrote:
>
> The question is whether the size of the Unix domain sockets support is
> worth the complexity of yet another config option that we expose to
> the user. For the embedded world, OK, maybe they want to save 14k of
> non-swappable memory. But for the non-embedded world, given the 117k
> mandatory memory usage of sysfs, or the 124k memory usage of the core
> networking stack, never mind the 3 megabytes of memory used by objects
> in the kernel subdirectory, it's not clear that it's worth worrying
> over 14k of memory, especially when many Unix programs assume
> that Unix Domain Sockets are present.
That would make sense if we were proposing to get rid of the CONFIG_UNIX
question altogether for !CONFIG_EMBEDDED. However, the proposal here is
merely to eliminate the modular option but the CONFIG_UNIX prompt itself
will remain even without CONFIG_EMBEDDED.
This I think is quite pointless.
Cheers,
--
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 Wed, 2 Jan 2008, Herbert Xu wrote:
> Theodore Tso <[email protected]> wrote:
> > The question is whether the size of the Unix domain sockets support is
> > worth the complexity of yet another config option that we expose to
> > the user. For the embedded world, OK, maybe they want to save 14k of
> > non-swappable memory. But for the non-embedded world, given the 117k
> > mandatory memory usage of sysfs, or the 124k memory usage of the core
> > networking stack, never mind the 3 megabytes of memory used by objects
> > in the kernel subdirectory, it's not clear that it's worth worrying
> > over 14k of memory, especially when many Unix programs assume
> > that Unix Domain Sockets are present.
>
> That would make sense if we were proposing to get rid of the CONFIG_UNIX
> question altogether for !CONFIG_EMBEDDED.
Exactly this is what my patch does: The question is not to be displayed
unless EMBEDDED, and the default is changed to y.
> However, the proposal here is
> merely to eliminate the modular option but the CONFIG_UNIX prompt itself
> will remain even without CONFIG_EMBEDDED.
>
> This I think is quite pointless.
That's what another patch would do. I decided that s/tristate/bool/ is
something completely different from adding the default and hiding the
option, and that I'd avoid this discussion by not eliminating UNIX=m.
--
Top 100 things you don't want the sysadmin to say:
96. That's SOOOOO bizarre.