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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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,
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
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
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
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
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
36 matches
Mail list logo