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]
Date:	Thu, 26 Jun 2008 10:13:23 +0200
From:	Mikael Pettersson <mikpe@...uu.se>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Bernhard Walle <bwalle@...e.de>, x86@...nel.org,
	linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
	yhlu.kernel@...il.com
Subject: Re: [PATCH 1/2] Add /sys/firmware/memmap

Vivek Goyal writes:
 > On Wed, Jun 25, 2008 at 09:57:05PM +0200, Bernhard Walle wrote:
 > > This patch adds /sys/firmware/memmap interface that represents the BIOS
 > > (or Firmware) provided memory map. The tree looks like:
 > > 
 > >     /sys/firmware/memmap/0/start   (hex number)
 > >                            end     (hex number)
 > >                            type    (string)
 > >     ...                 /1/start
 > >                            end
 > >                            type
 > > 
 > > With the following shell snippet one can print the memory map in the same form
 > > the kernel prints itself when booting on x86 (the E820 map).
 > > 
 > >   --------- 8< --------------------------
 > >     #!/bin/sh
 > >     cd /sys/firmware/memmap
 > >     for dir in * ; do
 > >         start=$(cat $dir/start)
 > >         end=$(cat $dir/end)
 > >         type=$(cat $dir/type)
 > >         printf "%016x-%016x (%s)\n" $start $[ $end +1] "$type"
 > >     done
 > >   --------- >8 --------------------------
 > > 
 > > That patch only provides the needed interface:
 > > 
 > >  1. The sysfs interface.
 > >  2. The structure and enumeration definition.
 > >  3. The function firmware_map_add() and firmware_map_add_early()
 > >     that should be called from architecture code (E820/EFI, for
 > >     example) to add the contents to the interface.
 > > 
 > > If the kernel is compiled without CONFIG_FIRMWARE_MEMMAP, the interface does
 > > nothing without cluttering the architecture-specific code with #ifdef's.
 > > 
 > 
 > Hi Bernhard,
 > 
 > Thanks for the patch. Couple of thoughts.
 > 
 > Do we really need another CONFIG option (CONFIG_FIRMWARE_MEMMAP)? To,
 > me this does not seem to be a big chunk of code

It should be configurable. Whether it's done via CONFIG_KEXEC or its own
option I don't care.

 > at the same time I am
 > assuming that most of the people will use it (because of kexec). So
 > probably, it might not make lot of sense to put additional CONFIG option.

I question that assumption. Even if (and that's a big if) "most"
people use kexec (I don't), Linux is not about forcing unwanted
stuff down peoples' throats, we allow knowledgeable users to tune
their kernels.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ