4:41 p.m.
On Tue, 2014-11-04 at 16:26 +0000, Elliott, Robert (Server Storage)
wrote:
> -----Original Message-----
> From: Boaz Harrosh [mailto:boaz@plexistor.com]
> Sent: Tuesday, 04 November, 2014 4:38 AM
> To: Wilcox, Matthew R; Elliott, Robert (Server Storage); Ross
> Zwisler; Jens Axboe; Nick Piggin; Kani, Toshimitsu; Knippers, Linda;
> linux-fsdevel(a)vger.kernel.org; linux-kernel(a)vger.kernel.org; linux-
> nvdimm(a)lists.01.org; Matthew Wilcox
> Subject: Re: [PATCH 1/4] pmem: Initial version of persistent memory
> driver
>
> On 11/03/2014 06:19 PM, Wilcox, Matthew R wrote:
...
>
> I wish you guys would actually review the correct code.
>
> In the actual good driver that has any shape of proper code all these
> issue are gone.
>
> * config defaults gone, multiple-devices multiple-memory ranges fully
> supported hot plug style.
> * above shifts cruft completely gone it is left overs from brd.c and
> its page usage.
> * getgeo fixed to do what we realy want by the only application on earth
> that still uses it, fdisk. All other partitioners do not call it at
> all.
>
> Why are we reviewing dead code ?
>
> Cheers
> Boaz
Ross, what's the status of Boaz' patches (available in
git://git.open-osd.org/pmem.git)?
https://github.com/01org/prd.git doesn't include any of
them yet.
Hey Robert,
The UEFI organization is in the process of defining a generic specification
for platform non-volatile memory resources. Essentially the thought was to
wait until that was publicly available before adding any new device discovery
capabilities to pmem.
What Boaz has suggested and coded up is certainly useful, but the worry is
that it will end up being incompatible with what comes out of UEFI. If we
stay with the dead-simple module parameter method, we will have less code to
unwind later.
Thanks,
- Ross
5:06 p.m.
New subject: [Linux-nvdimm] [PATCH 1/4] pmem: Initial version of persistent memory driver
On 11/04/2014 06:41 PM, Ross Zwisler wrote:
<>
The UEFI organization is in the process of defining a generic specification
for platform non-volatile memory resources. Essentially the thought was to
wait until that was publicly available before adding any new device discovery
capabilities to pmem.
What Boaz has suggested and coded up is certainly useful, but the worry is
that it will end up being incompatible with what comes out of UEFI. If we
stay with the dead-simple module parameter method, we will have less code to
unwind later.
What ??
What I coded up is a exactly "dead-simple module parameter method"
that will not need to be changed in future, that is actually sane.
Actually your version of the code needs changing with the global parameters,
one range support, and same size devices.
My version of the code is specifically made very probe() ready and dynamic
ready. It was the point of it all. Including bugs and ugliness fixed.
(I have a small patch that dynamically addes/removes devices on the fly
through the same module-param interface)
There is not a line in all of my patches that might be affected by
that UEFI comity. (Again actually fixing what needed changing). And in
addition to that comity and the new HW they will define, my system
also supports all the current NvDIMMs in the market.
I really can not understand what you guys are saying? Have you actually
looked at the code and used it, compared to the unusable thing you guys
have now ??
[Like you are saying "before adding any new device discovery capabilities"
But I have not added any? All I did was fix and simplify the module-param
interface. Which makes me think that you might not have looked at any of
my fixes?
]
Thanks,
- Ross
Cheers
Boaz
2182
days inactive
2182
days old
1 comments
2 participants
participants (2)
-
Boaz Harrosh -
Ross Zwisler