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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
>
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
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:
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.
> >
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
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]>
>
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
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
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
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
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]
---
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
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.
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
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
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 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
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:
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
58 matches
Mail list logo
