Prev: ACPI / PM: Do not enable GPEs for system wakeup in advance
Next: per_cpu_ptr_to_phys() failure on UV x86_64
From: Matthew Garrett on 22 Jun 2010 23:40
On Wed, Jun 23, 2010 at 12:06:38PM +0900, Paul Mundt wrote:

> What exactly is the use case supposed to be? If drivers are supposed to
> call in to it for specific devices then they already have all of the
> information they need for constructing a device blacklist and providing
> more detailed information. If it's a configuration issue then we have
> device quirks, which could also be extended to other busses as needed. In
> either case, the context ought to be fairly explicit. I would much rather
> see a message from the bus code stating that a specific device has been
> disabled and skip the probe path entirely rather than trying to bolt on a
> system-wide unsupported hardware state.

Hardware may work, it may just not work well enough that a software
vendor (eg, Red Hat) wants to deal with problem reports (eg, oopses
caused by a network card DMAing to the wrong place) from systems with
specific bits of hardware (eg, network cards that enjoy DMAing to the
wrong place occasionally). It may not even be down to technical issues -
the vendor may just have chosen to refuse to support systems with old
CPU families. It'd be straightforward to make the kernel simply refuse
to boot on them, but it seems more elegant to let it boot and alert the
user to the situation.

I don't think it's a flag that would ever be used in mainline, and
Alan's suggestion to just keep a range of taint flags as vendor-specific
would avoid the risk of collisions in future. But there's a minor
incentive to maintain standardisation over these things in order to
encourage commonality of report code.

--
Matthew Garrett | mjg59(a)srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Don Zickus on 23 Jun 2010 16:10
On Wed, Jun 23, 2010 at 04:30:47AM +0100, Matthew Garrett wrote:
> I don't think it's a flag that would ever be used in mainline, and
> Alan's suggestion to just keep a range of taint flags as vendor-specific
> would avoid the risk of collisions in future. But there's a minor
> incentive to maintain standardisation over these things in order to
> encourage commonality of report code.

Exactly. This was why we posted this upstream to see if there were other
distros interested in a mechanism like this.

Cheers,
Don
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Don Zickus on 6 Jul 2010 16:40
On Tue, Jun 22, 2010 at 02:58:12PM -0400, Don Zickus wrote:
> This patch reserves taint bits for distributions to use as they seem fit
> without the fear of them being stepped up in future kernels.
>
> V4: just reserve the bits

Any acks or naks on this version of the patch?

Cheers,
Don

>
> Signed-off-by: Don Zickus <dzickus(a)redhat.com>
>
> ---
>
> Not sure if this is sufficient for reserving or if there is some other code
> I have to add elsewhere too.
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index cc5e3ff..c7b9e2c 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -347,6 +347,11 @@ extern enum system_states {
> #define TAINT_WARN 9
> #define TAINT_CRAP 10
> #define TAINT_FIRMWARE_WORKAROUND 11
> +/* Reserving bits for vendor specific uses */
> +#define TAINT_RESERVED28 28
> +#define TAINT_RESERVED29 29
> +#define TAINT_RESERVED30 30
> +#define TAINT_RESERVED31 31
>
> extern void dump_stack(void) __cold;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 6 Jul 2010 18:20
On Tue, 6 Jul 2010 16:33:09 -0400
Don Zickus <dzickus(a)redhat.com> wrote:

> On Tue, Jun 22, 2010 at 02:58:12PM -0400, Don Zickus wrote:
> > This patch reserves taint bits for distributions to use as they seem fit
> > without the fear of them being stepped up in future kernels.
> >
> > V4: just reserve the bits
>
> Any acks or naks on this version of the patch?

You can have my ack for it.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2 3 4
Prev: ACPI / PM: Do not enable GPEs for system wakeup in advance
Next: per_cpu_ptr_to_phys() failure on UV x86_64