On Thu, Nov 14, 2013 at 08:44:04PM +0200, Pekka Enberg wrote:
> On Thu, Nov 14, 2013 at 8:04 PM, <jerry.hoemann@xxxxxx> wrote:
> > Making this issue a quirk will be a lot more practical. Its a small, focused
> > change whose implications are limited and more easily understood.
>
> There's nothing practical with requiring users to pass a kernel option
> to make kdump work. It's a workaround, sure, but it's not a proper
> fix.
One already has to specify command line arguments to enable kdump.
See "crashkernel=" in Documentation/kernel-parameters.txt.
As i said in an earlier mail we are working w/ distros. distros
can and do specify lots of interesting command line arguments for
their systems. Distros have tools for configuring kdump.
User must already use these tools or manually edit multiple config files,
to get kdump to work. I would work with distros to help integrate this
change into their tools.
As i said in earlier mail, i am willing to change implementation
to some type of black/white listing.
>
> And once you add whitelisting to make it practical, implications are
> no longer limited nor easily understood nor actually testable unless
> you happen to have access every single firmware out there.
Perhaps we have a different understanding of black/white listings.
Here is what i mean:
the use of efi_reserve_boot_services is a work around for system
with fw bugs.
Black list:
1. In general, assume systems don't need the work around.
2. The black list are those specific system on which the work around
is applied.
White list:
1. In general, assume systems require the work around.
2. The white list are those specific system in which the work around
is not applied.
In the white list case, the list of platforms would be the ones
that i specifically test and verify don't need the work around.
the only difference is whether BootService Code/Data is reserved/freed
early.
all other platforms remain the same.
>
> Yes, we have plenty of quirks in the x86 boot code but that doesn't
> mean it's a good idea to add more of the unless we absolutely must.
given that life is optional, how can one argue any piece of software be
an absolute must? :) :)
Jerry
>
> Pekka
--
----------------------------------------------------------------------------
Jerry Hoemann Software Engineer Hewlett-Packard/MODL
3404 E Harmony Rd. MS 57 phone: (970) 898-1022
Ft. Collins, CO 80528 FAX: (970) 898-XXXX
email: jerry.hoemann@xxxxxx
----------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
