[lkml]   [2010]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
> Typically, one would push a config patch to enable and disable the feature and
> patch the distribution. However, in some cases this is not feasible in order

If you can push a patch to set the flag you can push a patch to panic or
reject that combination.

Devil's advocate time:

Also the fact some distributions chose a binary compatible interface for
their internal modules was their choice. It is one that has been
repeatedly rejected by upstream and at kernel summit.

So given we fundamnetally reject your approach why should we carry your
flag ?

> In some cases the distribution may want to allow booting of these features but
> explicitly notify a user that they are not "officially" supported. It is also

We have printk. You can add a module of your own which indicates
'support' status too.

> possible that the hardware is fixed via a firmware update at a later date,
> making it supported again.

IMHO it's not properly named in the first place. You are talking about
combinations of hardware/firmware and you actually mean 'configuration
not supported' ?

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

and why KERN_CRIT when the other printk's don't use that level ?

A suggestion: instead of all this push a single patch with a comment and
maybe defines indicating that taint flag bits 28-31 are 'reserved' for
experimental and out of tree applications.

That way anyone who has a requirement like yours can deal with it and
nobody has to worry about bit collisions, naming and the like. Nor if you
suddenely need an extra bit in 3 years time are you going to come unstuck
on your KABI. That will help other people doing experiments with taint or
with differing needs to the Red Hat one.


 \ /
  Last update: 2010-06-19 11:29    [W:0.063 / U:15.432 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site