On Tue, 25 Jul 2000, Stephen Frost wrote:
> Horrible hacks would be what would be required to get a firmware
> upgrade to work under Linux with the restrictions in place. I sure hope
> Andre isn't trying to convince drive makers that they can void their
> warrentee if something hits those commands the wrong way.
They can and probably will. With the new approach he is advocating to
them, Linux doesn't need to filter the commands - the drive does, and logs
any inappropriate commands for the manufacturer.
> The comments you left out regarding that you didn't like having to
> have things be OS dependant. The reason they are now is because of end
> users.
Ah. Personally, I'd say a single boot disk could/should be MORE
user-friendly, not less. Any user attempting a flash upgrade should know
how to boot from a CD or floppy, at least - after that point, the vendor's
program can do whatever it wants by way of hand-holding.
> > WTF does that come in - we're talking about writing firmware in devices,
> > not writing to a CD-R. TOTALLY different issue.
>
> Not so, initially, and still currently actually, cdrecord and other
> programs used the SCSI generic interface to talk to CD burners. Obviously
> these commands sent to that kind of device initially wouldn't have been
> thought valid by the main SCSI layer, or even the SCSI cdrom driver. The
> same may be true in the future for some IDE devices.
These commands would not be regarded as potentially dangerous ones in the
same way. Writing CDs is a CD-R drive's function, so it won't block that.
> > Such as? A handful of standard things the kernel should provide anyway
> > (powersave, DMA mode, etc), and a block of commands which MUST NOT be
> > issued to the drive EVER (except by the drive vendor's maintenance
> > software.)
>
> Except those commands are vendor specific and we *don't* know
> exactly what all commands need to be blocked. Instead Andre took the
> approach of blocking everything he didn't recognize as a valid command
> with 'valid' commands to the device. Also other devices in the future
> may wish to issue other commands to the devices for various reasons and
> would find they have to get the kernel updated and upgraded on any
> machine they wish to use these devices on.
Andre is now trying to get the vendors to do this in the drive firmware
instead, which avoids the issue for Linux.
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:20 EST