netdev - Re: [PATCH] Force UNIX domain sockets to be built in

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071231174302.GA1627@oscar.prima.de>
Date:	Mon, 31 Dec 2007 18:43:02 +0100
From:	Patrick Mau <mau@...ar.ping.de>
To:	Jan Engelhardt <jengelh@...putergmbh.de>
Cc:	Bodo Eggert <7eggert@....de>, Adrian Bunk <bunk@...nel.org>,
	devzero@....de, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH] Force UNIX domain sockets to be built in

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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html