Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-24 Thread Toshi Kani
On Thu, 2015-12-24 at 20:58 +0100, Borislav Petkov wrote: > On Thu, Dec 24, 2015 at 10:08:57AM -0700, Toshi Kani wrote: > > As for checkpatch, I noticed that commit 9c0ece069b3 removed "feature > > -removal.txt" file, and checkpatch removed this check in commit > > 78e3f1f01d2. checkpatch does

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-24 Thread Borislav Petkov
On Thu, Dec 24, 2015 at 10:08:57AM -0700, Toshi Kani wrote: > As for checkpatch, I noticed that commit 9c0ece069b3 removed "feature > -removal.txt" file, and checkpatch removed this check in commit > 78e3f1f01d2. checkpatch does not have such check since then. So, I am > inclined not to add this

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-24 Thread Toshi Kani
On Wed, 2015-12-23 at 19:23 -0700, Toshi Kani wrote: > On Wed, 2015-12-23 at 15:23 +0100, Borislav Petkov wrote: > > On Tue, Dec 22, 2015 at 01:04:32PM -0700, Toshi Kani wrote: > : > > > I agree that we can add new interfaces with the type check. This > > > 'type' > > > may need some

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-24 Thread Toshi Kani
On Thu, 2015-12-24 at 20:58 +0100, Borislav Petkov wrote: > On Thu, Dec 24, 2015 at 10:08:57AM -0700, Toshi Kani wrote: > > As for checkpatch, I noticed that commit 9c0ece069b3 removed "feature > > -removal.txt" file, and checkpatch removed this check in commit > > 78e3f1f01d2. checkpatch does

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-24 Thread Borislav Petkov
On Thu, Dec 24, 2015 at 10:08:57AM -0700, Toshi Kani wrote: > As for checkpatch, I noticed that commit 9c0ece069b3 removed "feature > -removal.txt" file, and checkpatch removed this check in commit > 78e3f1f01d2. checkpatch does not have such check since then. So, I am > inclined not to add this

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-24 Thread Toshi Kani
On Wed, 2015-12-23 at 19:23 -0700, Toshi Kani wrote: > On Wed, 2015-12-23 at 15:23 +0100, Borislav Petkov wrote: > > On Tue, Dec 22, 2015 at 01:04:32PM -0700, Toshi Kani wrote: > : > > > I agree that we can add new interfaces with the type check. This > > > 'type' > > > may need some

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-23 Thread Toshi Kani
On Wed, 2015-12-23 at 15:23 +0100, Borislav Petkov wrote: > On Tue, Dec 22, 2015 at 01:04:32PM -0700, Toshi Kani wrote: : > > I agree that we can add new interfaces with the type check. This > > 'type' > > may need some clarification since it is an assigned type, which is > > different from I/O

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-23 Thread Borislav Petkov
On Tue, Dec 22, 2015 at 01:04:32PM -0700, Toshi Kani wrote: > The above example referred the case with distros, not with the upstream. > That is, one writes a new loadable module and makes it available in the > upstream. Then s/he makes it work on a distro used by the customers, but > may or

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-23 Thread Borislav Petkov
On Tue, Dec 22, 2015 at 01:04:32PM -0700, Toshi Kani wrote: > The above example referred the case with distros, not with the upstream. > That is, one writes a new loadable module and makes it available in the > upstream. Then s/he makes it work on a distro used by the customers, but > may or

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-23 Thread Toshi Kani
On Wed, 2015-12-23 at 15:23 +0100, Borislav Petkov wrote: > On Tue, Dec 22, 2015 at 01:04:32PM -0700, Toshi Kani wrote: : > > I agree that we can add new interfaces with the type check. This > > 'type' > > may need some clarification since it is an assigned type, which is > > different from I/O

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-22 Thread Toshi Kani
On Tue, 2015-12-22 at 12:34 +0100, Borislav Petkov wrote: > On Wed, Dec 16, 2015 at 02:52:38PM -0700, Toshi Kani wrote: > > This scheme may have a problem, though. For instance, when someone > > writes a loadable module that searches for "foo", but the "foo" entry > > may be initialized in a

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-22 Thread Borislav Petkov
On Wed, Dec 16, 2015 at 02:52:38PM -0700, Toshi Kani wrote: > This scheme may have a problem, though. For instance, when someone writes > a loadable module that searches for "foo", but the "foo" entry may be > initialized in a distro kernel/driver that cannot be modified. Since this > search is

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-22 Thread Toshi Kani
On Tue, 2015-12-22 at 12:34 +0100, Borislav Petkov wrote: > On Wed, Dec 16, 2015 at 02:52:38PM -0700, Toshi Kani wrote: > > This scheme may have a problem, though. For instance, when someone > > writes a loadable module that searches for "foo", but the "foo" entry > > may be initialized in a

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-22 Thread Borislav Petkov
On Wed, Dec 16, 2015 at 02:52:38PM -0700, Toshi Kani wrote: > This scheme may have a problem, though. For instance, when someone writes > a loadable module that searches for "foo", but the "foo" entry may be > initialized in a distro kernel/driver that cannot be modified. Since this > search is

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Toshi Kani
On Wed, 2015-12-16 at 19:17 +0100, Borislav Petkov wrote: > On Wed, Dec 16, 2015 at 09:52:37AM -0800, Dan Williams wrote: > > It's possible that as far as the resource table is concerned the > > resource type might just be "reserved". It may not be until after a > > driver loads that we discover

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Borislav Petkov
On Wed, Dec 16, 2015 at 10:57:52AM -0800, Dan Williams wrote: > Aside from "System RAM" checks I don't think any of these strcmp > usages are in fast paths. Sure, 0.1% slowdown here, 0.2% slowdown there... this is how you get a bloated kernel. In addition to that, using strings to identify

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Dan Williams
On Wed, Dec 16, 2015 at 10:17 AM, Borislav Petkov wrote: > On Wed, Dec 16, 2015 at 09:52:37AM -0800, Dan Williams wrote: [..] > Now, imagine you have to do this pretty often. Which is faster: a > strcmp() or an int comparison...? Aside from "System RAM" checks I don't think any of these strcmp

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Borislav Petkov
On Wed, Dec 16, 2015 at 09:52:37AM -0800, Dan Williams wrote: > It's possible that as far as the resource table is concerned the > resource type might just be "reserved". It may not be until after a > driver loads that we discover the memory range type. The identifying > string is driver

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Dan Williams
On Wed, Dec 16, 2015 at 9:45 AM, Borislav Petkov wrote: > On Wed, Dec 16, 2015 at 09:35:59AM -0700, Toshi Kani wrote: >> We do not have enough bits left to cover any potential future use-cases >> with other strings if we are going to get rid of strcmp() completely. > > Look at the examples I

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Borislav Petkov
On Wed, Dec 16, 2015 at 09:35:59AM -0700, Toshi Kani wrote: > We do not have enough bits left to cover any potential future use-cases > with other strings if we are going to get rid of strcmp() completely. Look at the examples I gave. I'm talking about having an additional identifier which can be

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Toshi Kani
On Wed, 2015-12-16 at 16:49 +0100, Borislav Petkov wrote: > On Wed, Dec 16, 2015 at 08:44:02AM -0700, Toshi Kani wrote: > > Besides "System RAM", which is commonly searched by multiple callers, > > we > > only have a few other uncommon cases: > > - crash.c searches for "GART", "ACPI Tables", and

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Borislav Petkov
On Wed, Dec 16, 2015 at 08:44:02AM -0700, Toshi Kani wrote: > Besides "System RAM", which is commonly searched by multiple callers, we > only have a few other uncommon cases: > - crash.c searches for "GART", "ACPI Tables", and "ACPI Non-volatile > Storage". > - kexec_file.c searches for "Crash

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Toshi Kani
On Wed, 2015-12-16 at 13:26 +0100, Borislav Petkov wrote: > On Mon, Dec 14, 2015 at 04:37:16PM -0700, Toshi Kani wrote: > > I/O resource type, IORESOURCE_MEM, is used for all types of > > memory-mapped ranges, ex. System RAM, System ROM, Video RAM, > > Persistent Memory, PCI Bus, PCI MMCONFIG,

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Borislav Petkov
On Mon, Dec 14, 2015 at 04:37:16PM -0700, Toshi Kani wrote: > I/O resource type, IORESOURCE_MEM, is used for all types of > memory-mapped ranges, ex. System RAM, System ROM, Video RAM, > Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC, > reserved, and so on. This requires

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Borislav Petkov
On Wed, Dec 16, 2015 at 09:35:59AM -0700, Toshi Kani wrote: > We do not have enough bits left to cover any potential future use-cases > with other strings if we are going to get rid of strcmp() completely. Look at the examples I gave. I'm talking about having an additional identifier which can be

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Borislav Petkov
On Wed, Dec 16, 2015 at 09:52:37AM -0800, Dan Williams wrote: > It's possible that as far as the resource table is concerned the > resource type might just be "reserved". It may not be until after a > driver loads that we discover the memory range type. The identifying > string is driver

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Borislav Petkov
On Wed, Dec 16, 2015 at 10:57:52AM -0800, Dan Williams wrote: > Aside from "System RAM" checks I don't think any of these strcmp > usages are in fast paths. Sure, 0.1% slowdown here, 0.2% slowdown there... this is how you get a bloated kernel. In addition to that, using strings to identify

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Dan Williams
On Wed, Dec 16, 2015 at 9:45 AM, Borislav Petkov wrote: > On Wed, Dec 16, 2015 at 09:35:59AM -0700, Toshi Kani wrote: >> We do not have enough bits left to cover any potential future use-cases >> with other strings if we are going to get rid of strcmp() completely. > > Look at the

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Dan Williams
On Wed, Dec 16, 2015 at 10:17 AM, Borislav Petkov wrote: > On Wed, Dec 16, 2015 at 09:52:37AM -0800, Dan Williams wrote: [..] > Now, imagine you have to do this pretty often. Which is faster: a > strcmp() or an int comparison...? Aside from "System RAM" checks I don't think any

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Toshi Kani
On Wed, 2015-12-16 at 19:17 +0100, Borislav Petkov wrote: > On Wed, Dec 16, 2015 at 09:52:37AM -0800, Dan Williams wrote: > > It's possible that as far as the resource table is concerned the > > resource type might just be "reserved". It may not be until after a > > driver loads that we discover

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Toshi Kani
On Wed, 2015-12-16 at 13:26 +0100, Borislav Petkov wrote: > On Mon, Dec 14, 2015 at 04:37:16PM -0700, Toshi Kani wrote: > > I/O resource type, IORESOURCE_MEM, is used for all types of > > memory-mapped ranges, ex. System RAM, System ROM, Video RAM, > > Persistent Memory, PCI Bus, PCI MMCONFIG,

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Borislav Petkov
On Mon, Dec 14, 2015 at 04:37:16PM -0700, Toshi Kani wrote: > I/O resource type, IORESOURCE_MEM, is used for all types of > memory-mapped ranges, ex. System RAM, System ROM, Video RAM, > Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC, > reserved, and so on. This requires

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Borislav Petkov
On Wed, Dec 16, 2015 at 08:44:02AM -0700, Toshi Kani wrote: > Besides "System RAM", which is commonly searched by multiple callers, we > only have a few other uncommon cases: > - crash.c searches for "GART", "ACPI Tables", and "ACPI Non-volatile > Storage". > - kexec_file.c searches for "Crash

Re: [PATCH 01/11] resource: Add System RAM resource type

2015-12-16 Thread Toshi Kani
On Wed, 2015-12-16 at 16:49 +0100, Borislav Petkov wrote: > On Wed, Dec 16, 2015 at 08:44:02AM -0700, Toshi Kani wrote: > > Besides "System RAM", which is commonly searched by multiple callers, > > we > > only have a few other uncommon cases: > > - crash.c searches for "GART", "ACPI Tables", and

[PATCH 01/11] resource: Add System RAM resource type

2015-12-14 Thread Toshi Kani
I/O resource type, IORESOURCE_MEM, is used for all types of memory-mapped ranges, ex. System RAM, System ROM, Video RAM, Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC, reserved, and so on. This requires walk_system_ram_range(), walk_system_ram_res(), and region_intersects() to use

[PATCH 01/11] resource: Add System RAM resource type

2015-12-14 Thread Toshi Kani
I/O resource type, IORESOURCE_MEM, is used for all types of memory-mapped ranges, ex. System RAM, System ROM, Video RAM, Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC, reserved, and so on. This requires walk_system_ram_range(), walk_system_ram_res(), and region_intersects() to use