[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18531.20387.111875.576837@harpo.it.uu.se>
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