linux-kernel - Re: [PATCH] Open Firmware device tree virtual filesystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1167800731.6165.110.camel@localhost.localdomain>
Date:	Wed, 03 Jan 2007 16:05:31 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	David Miller <davem@...emloft.net>
Cc:	jengelh@...ux01.gwdg.de, segher@...nel.crashing.org,
	linux-kernel@...r.kernel.org, devel@...top.org, wmb@...mworks.com,
	jg@...top.org
Subject: Re: [PATCH] Open Firmware device tree virtual filesystem

> In fact, the 'ok' prompt is an ENORMOUS pain in the ass to support
> on machines with USB keyboards, because sharing the USB host
> controller is beyond non-trivial.  I've never implemented support
> for that on sparc64 and I frankly have no desire to do the work
> necessary to support that.  It simply is not worth it.

I was wondering about that .... :-)

Device sharing with a "live" OF is just an absolute pain in the ass and
I'm actually pretty happy not to have to do it. Segher and I, and more
recently, paulus and I, have been discussing about ways to deal with it
or make a version of SLOF (segher's pet OF implementation) that could
stay alive but the more I think about the burden, the more I'm inclined
to just give up...

There have been a recurring need for system vendors to provide
"firmware" type code to be called from the OS or to co-exist with the OS
though. Wether that's a good idea or not or wether those vendor
justifications for that are valid or not is of course debatable ;-)

Some of those attemptes resulted in horrors ranging from SMM BIOSes to
RTAS, via ACPI AML stuff or even worse, Apple's platform function
"scripts" in the device-tree.

I think every single of these approaches have proven that it actually
caused more problems than it solves.

Most of the time, the goal is to actually ease the OS work by
abstracting dodgy motherboard bits, like all the random IOs to toggle to
enable clocks on a given bus for power management etc... But every time,
it's been abused as a way to hide implementation details or hardware
specs, and everytime, bugs in those "firmware" provided blobs have
proven more damageable than having clear documentation for the HW and
proper driver code to deal with it.

Ben.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/