Re: LCC and blobs
[just some minor additions.]
> On Thu, Dec 16, 2004 at 09:20:14PM -0500, Brian Thomas Sniffen wrote:
> > No, I argue that because you've pried chips off the board, the
> > hardware is broken.
On Thu, Dec 16, 2004 at 09:39:59PM -0500, Glenn Maynard wrote:
> Er, no. Flash can be overwritten with invalid data (eg. nulls or
> interrupting a flash process), rendering drivers that expect a working
> flash to not work.
And some monitors can be driven in ways that cause them to burn out.
In both cases, there's a change in the electrical characteristics of
the device which renders it non-functional.
> It's not correct in the general case to say that "no driver can
> drive that"; some hardware can still be re-flashed to correct the data,
> so a driver that does have a (usually redundant) copy of the firmware
> and code to upload it can, in fact, drive the device.
In principle (depending on the board design), the flash data can be pulled
off the device. We don't have to distribute the data to allow users to
reflash their devices. [And, in the general case, we probably shouldn't
-- because we're not set up to track all the potential hardware changes,
and we're not in a position to make sure we're providing the proper
version of the data for the instance of hardware that the user has.
Of course, we'd also get it right in a number of cases.]
Fundamentally, the DFSG is aimed at making sure that we can provide the
software that we can support. Restrictions that leave us writing an
opaque blob of bits which drives an unknown API very much put us into
a context where we can't know that we're doing the right thing.
> However, unlike non-flash devices that need the firmware uploaded
> every time, the driver is still useful without it.
Yes.
> Whether or not the "misflashed hardware is a broken device" analogy is
> bought, the fact remains that many copies of the hardware still do
> function, having working firmware. The existance of non-working
> hardware is irrelevant.
Exactly.
--
Raul
Reply to: