Prev: ACPI / PM: Do not enable GPEs for system wakeup in advance
Next: per_cpu_ptr_to_phys() failure on UV x86_64
From: Alan Cox on 22 Jun 2010 11:50
On Tue, 22 Jun 2010 11:34:57 -0400
Don Zickus <dzickus(a)redhat.com> wrote:

> This patch is similar to Theordore Ts'o's TAINT_USER patch,
> linux-2.6 commit 34f5a39899f3f3e815da64f48ddb72942d86c366.

This seems to have gone backwards

> This patch introduces the TAINT_HARDWARE_UNSUPPORTED flag for distributions
> to use.

As I said before - just mark some as 'reserved'

Giving it a specific meaning means it can't freely be used for many
things by many distributions


> + printk(KERN_CRIT "UNSUPPORTED HARDWARE DEVICE: %s\n", msg);
> + WARN_TAINT(1, TAINT_HARDWARE_UNSUPPORTED,
> + "Your hardware is unsupported. Please do not report "
> + "bugs, panics, oopses, etc., on this hardware.\n");

And as already pointed out it's not unsupported hardware even in the case
you described

NAK
--
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: Matthew Garrett on 22 Jun 2010 12:40
On Tue, Jun 22, 2010 at 04:48:35PM +0100, Alan Cox wrote:
> > + printk(KERN_CRIT "UNSUPPORTED HARDWARE DEVICE: %s\n", msg);
> > + WARN_TAINT(1, TAINT_HARDWARE_UNSUPPORTED,
> > + "Your hardware is unsupported. Please do not report "
> > + "bugs, panics, oopses, etc., on this hardware.\n");
>
> And as already pointed out it's not unsupported hardware even in the case
> you described

It's hardware that isn't supported by the vendor. How is it not
unsupported hardware in that context?

--
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: Alan Cox on 22 Jun 2010 13:00
On Tue, 22 Jun 2010 17:38:17 +0100
Matthew Garrett <mjg(a)redhat.com> wrote:

> On Tue, Jun 22, 2010 at 04:48:35PM +0100, Alan Cox wrote:
> > > + printk(KERN_CRIT "UNSUPPORTED HARDWARE DEVICE: %s\n", msg);
> > > + WARN_TAINT(1, TAINT_HARDWARE_UNSUPPORTED,
> > > + "Your hardware is unsupported. Please do not report "
> > > + "bugs, panics, oopses, etc., on this hardware.\n");
> >
> > And as already pointed out it's not unsupported hardware even in the case
> > you described
>
> It's hardware that isn't supported by the vendor. How is it not
> unsupported hardware in that context?

Which vendor ? What do you mean by support ? Even in Red Hat you will
I suspect need to change that message because after the first 500 calls
received by Dell or HP or whoever about it they'll demand you add
"unsupported by Red Hat" or similar to avoid them getting support calls !

And then as I said originally the example given was not even
"unsupported hardware" for an obvious Red Hat definition of the two
because it was actually about firmware combinations on specific boards -
ie it was an unsupported configuration.

The trouble in part is that the moment you borrow a bit for Red Hat
private use and put that use into the kernel you've made it unusuable for
anyone else. If you simply mark a few bits 'private/experimental use'
then you can use it for "unsupported" but others can use it for things
like 'uncertified configuration' or 'test' or 'non vendor signed module
loaded' and so on. All valid uses in specific vendor customisations.

The other giggle of course is that the WARN says do not report, but the
existing oops capturing software will capture the WARN so auto-report it.

Alan
--
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: Matthew Garrett on 22 Jun 2010 13:10
On Tue, Jun 22, 2010 at 05:57:41PM +0100, Alan Cox wrote:

> And then as I said originally the example given was not even
> "unsupported hardware" for an obvious Red Hat definition of the two
> because it was actually about firmware combinations on specific boards -
> ie it was an unsupported configuration.

The two examples given were:

"a distribution may want to support PPC but not the Power5 chipset, or
the e1000e driver but not a card with a specific DeviceID because of
known firmware issues."

In both those cases it's specific hardware that's unsupported, not the
configuration.

--
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: Paul Mundt on 22 Jun 2010 23:10
On Tue, Jun 22, 2010 at 06:04:10PM +0100, Matthew Garrett wrote:
> On Tue, Jun 22, 2010 at 05:57:41PM +0100, Alan Cox wrote:
>
> > And then as I said originally the example given was not even
> > "unsupported hardware" for an obvious Red Hat definition of the two
> > because it was actually about firmware combinations on specific boards -
> > ie it was an unsupported configuration.
>
> The two examples given were:
>
> "a distribution may want to support PPC but not the Power5 chipset, or
> the e1000e driver but not a card with a specific DeviceID because of
> known firmware issues."
>
> In both those cases it's specific hardware that's unsupported, not the
> configuration.
>
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.
--
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  |  Next  |  Last
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