* Matthew Wilcox <matthew@wil.cx> wrote:

quoted text
> On Tue, Apr 08, 2008 at 09:59:49PM +0200, Ingo Molnar wrote:
> > Btw., a sidenote: this is another generally annoying property of Linux: 
> > there's no easy and user-visible enumeration of PCI IDs (devices) that 
> > we _could_ support but dont enable for some reason. It is a royal PITA 
> > to track down when some driver decides to (silently) ignore a piece of 
> > hardware.
> > 
> > Having a seemingly dead piece of hardware component is one of the most 
> > frustrating user experiences possible - the first instinctive reaction 
> > is "did my hw break???". The kernel should proactively know about all 
> > inactive pieces of hardware and should have a one-stop-shop for users 
> > where they can reassure themselves which devices are not active and why.
> 
> It's almost trivial to add new string attributes to sysfs.  We could 
> have a file, say, /sys/bus/pci/devices/0000:07:03.0/broken which lspci 
> could read to see if anything's left a message for us.
> 
> Is that the kind of thing you had in mind?

yep, that would be fantastic.

i guess more could be done as well - this was just the result of 10 
seconds of thinking - please try to think all such scenarios through 
with the mindset of the user who is faced with a non-working device. Our 
failure diagnostics are rather ad-hoc in general. Say an USB stick did 
not come up. Or some card isnt working. Or the mouse is dead. Plain 
everyday annoyances - we need good, unified, understandable interfaces 
for users to get reassurances and vectors of action from. Maybe even a 
WARN_ON() for kerneloops.org to pick up automatically. _Anything_ that 
is actionable by plain users. Because failures in hw functionality is 
one of the most serious failure an OS can impose on users (it's only 
slightly better than say data loss, and clearly worse to most users than 
say sporadic crashes), and it is the main area where we _lose_ users 
every day.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html