On Mon, Apr 13, 2015 at 2:01 AM, Greg KH wrote:
> On Wed, Mar 25, 2015 at 10:00:26AM -0700, Dan Williams wrote:
>> On Wed, Mar 25, 2015 at 9:44 AM, Christoph Hellwig wrote:
>> > On Wed, Mar 25, 2015 at 09:33:52AM -0700, Dan Williams wrote:
>> >> This is mostly ok and does not collide too much
On Wed, Mar 25, 2015 at 10:00:26AM -0700, Dan Williams wrote:
> On Wed, Mar 25, 2015 at 9:44 AM, Christoph Hellwig wrote:
> > On Wed, Mar 25, 2015 at 09:33:52AM -0700, Dan Williams wrote:
> >> This is mostly ok and does not collide too much with the upcoming ACPI
> >> mechanism for this stuff. I
On Wed, Mar 25, 2015 at 10:00:26AM -0700, Dan Williams wrote:
On Wed, Mar 25, 2015 at 9:44 AM, Christoph Hellwig h...@lst.de wrote:
On Wed, Mar 25, 2015 at 09:33:52AM -0700, Dan Williams wrote:
This is mostly ok and does not collide too much with the upcoming ACPI
mechanism for this stuff.
On Mon, Apr 13, 2015 at 2:01 AM, Greg KH gre...@linuxfoundation.org wrote:
On Wed, Mar 25, 2015 at 10:00:26AM -0700, Dan Williams wrote:
On Wed, Mar 25, 2015 at 9:44 AM, Christoph Hellwig h...@lst.de wrote:
On Wed, Mar 25, 2015 at 09:33:52AM -0700, Dan Williams wrote:
This is mostly ok and
On 04/01/2015 10:50 AM, Ingo Molnar wrote:
>
> * Dan Williams wrote:
>
>> On Tue, Mar 31, 2015 at 10:24 AM, Christoph Hellwig wrote:
>>> On Tue, Mar 31, 2015 at 06:44:56PM +0200, Ingo Molnar wrote:
I'd be fine with that too - mind sending an updated series?
>>>
>>> I will send an updated
* Dan Williams wrote:
> On Tue, Mar 31, 2015 at 10:24 AM, Christoph Hellwig wrote:
> > On Tue, Mar 31, 2015 at 06:44:56PM +0200, Ingo Molnar wrote:
> >> I'd be fine with that too - mind sending an updated series?
> >
> > I will send an updated one tonight or early tomorrow.
> >
> > Btw, do you
On 04/01/2015 10:50 AM, Ingo Molnar wrote:
* Dan Williams dan.j.willi...@intel.com wrote:
On Tue, Mar 31, 2015 at 10:24 AM, Christoph Hellwig h...@lst.de wrote:
On Tue, Mar 31, 2015 at 06:44:56PM +0200, Ingo Molnar wrote:
I'd be fine with that too - mind sending an updated series?
I will
* Dan Williams dan.j.willi...@intel.com wrote:
On Tue, Mar 31, 2015 at 10:24 AM, Christoph Hellwig h...@lst.de wrote:
On Tue, Mar 31, 2015 at 06:44:56PM +0200, Ingo Molnar wrote:
I'd be fine with that too - mind sending an updated series?
I will send an updated one tonight or early
On Tue, Mar 31, 2015 at 10:24 AM, Christoph Hellwig wrote:
> On Tue, Mar 31, 2015 at 06:44:56PM +0200, Ingo Molnar wrote:
>> I'd be fine with that too - mind sending an updated series?
>
> I will send an updated one tonight or early tomorrow.
>
> Btw, do you want to keep the E820_PRAM name
On Tue, Mar 31, 2015 at 10:24 AM, Christoph Hellwig h...@lst.de wrote:
On Tue, Mar 31, 2015 at 06:44:56PM +0200, Ingo Molnar wrote:
I'd be fine with that too - mind sending an updated series?
I will send an updated one tonight or early tomorrow.
Btw, do you want to keep the E820_PRAM name
Hi Adam,
we're all well aware of the deficits of the current interface, but for now
that's all we have, and due to lead times in implementing bioses it will
be all we have for quite a while.
We're all eagerly looking forward to better interfaces and bioses that will
support them.
But for now
>The other two patches are a heavily rewritten version of the code that
>Intel gave to various storage vendors to discover the type 12 (and earlier
>type 6) nvdimms, which I massaged into a form that is hopefully suitable
>for mainline.
The problem is that the e820 or the UEFI Memory Map Table on
On Wed, Mar 25, 2015 at 10:04 AM, Christoph Hellwig wrote:
> On Wed, Mar 25, 2015 at 10:00:26AM -0700, Dan Williams wrote:
>> The kernel command line would simply be the standard/existing memmap=
>> to reserve a memory range. Then, when the platform device loads, it
>> does a request_firmware()
On Wed, Mar 25, 2015 at 10:00:26AM -0700, Dan Williams wrote:
> The kernel command line would simply be the standard/existing memmap=
> to reserve a memory range. Then, when the platform device loads, it
> does a request_firmware() to inject a binary table that further carves
> memory into ranges
On Wed, Mar 25, 2015 at 9:44 AM, Christoph Hellwig wrote:
> On Wed, Mar 25, 2015 at 09:33:52AM -0700, Dan Williams wrote:
>> This is mostly ok and does not collide too much with the upcoming ACPI
>> mechanism for this stuff. I do worry that the new
>> "memmap=nn[KMG]!ss[KMG]" kernel command line
On Wed, Mar 25, 2015 at 09:33:52AM -0700, Dan Williams wrote:
> This is mostly ok and does not collide too much with the upcoming ACPI
> mechanism for this stuff. I do worry that the new
> "memmap=nn[KMG]!ss[KMG]" kernel command line option will only be
> relevant for at most one kernel cycle
On Wed, Mar 25, 2015 at 9:04 AM, Christoph Hellwig wrote:
> Here is another version of the same trivial pmem driver, because two
> obviously aren't enough.
Welcome to the party! :-)
> The first patch is the same pmem driver
> that Ross posted a short time ago, just modified to use
On Wed, Mar 25, 2015 at 9:04 AM, Christoph Hellwig h...@lst.de wrote:
Here is another version of the same trivial pmem driver, because two
obviously aren't enough.
Welcome to the party! :-)
The first patch is the same pmem driver
that Ross posted a short time ago, just modified to use
On Wed, Mar 25, 2015 at 9:44 AM, Christoph Hellwig h...@lst.de wrote:
On Wed, Mar 25, 2015 at 09:33:52AM -0700, Dan Williams wrote:
This is mostly ok and does not collide too much with the upcoming ACPI
mechanism for this stuff. I do worry that the new
memmap=nn[KMG]!ss[KMG] kernel command
On Wed, Mar 25, 2015 at 10:00:26AM -0700, Dan Williams wrote:
The kernel command line would simply be the standard/existing memmap=
to reserve a memory range. Then, when the platform device loads, it
does a request_firmware() to inject a binary table that further carves
memory into ranges to
On Wed, Mar 25, 2015 at 09:33:52AM -0700, Dan Williams wrote:
This is mostly ok and does not collide too much with the upcoming ACPI
mechanism for this stuff. I do worry that the new
memmap=nn[KMG]!ss[KMG] kernel command line option will only be
relevant for at most one kernel cycle given the
On Wed, Mar 25, 2015 at 10:04 AM, Christoph Hellwig h...@lst.de wrote:
On Wed, Mar 25, 2015 at 10:00:26AM -0700, Dan Williams wrote:
The kernel command line would simply be the standard/existing memmap=
to reserve a memory range. Then, when the platform device loads, it
does a
The other two patches are a heavily rewritten version of the code that
Intel gave to various storage vendors to discover the type 12 (and earlier
type 6) nvdimms, which I massaged into a form that is hopefully suitable
for mainline.
The problem is that the e820 or the UEFI Memory Map Table on
Hi Adam,
we're all well aware of the deficits of the current interface, but for now
that's all we have, and due to lead times in implementing bioses it will
be all we have for quite a while.
We're all eagerly looking forward to better interfaces and bioses that will
support them.
But for now
24 matches
Mail list logo
