On Tue, 25 Jul 2000, Stephen Frost wrote:
> DOS was a example, and personally I'd prefer to not have the vendors
> having the hack the linux kernel in order to be able to provide an ability
> to upgrade the firmware. As it is now there is a nice simple interface they
> may be able to use.
They don't have to. They just compile a kernel with the checks disabled,
and use the interface as before.
> You only have to reset the device you flash. Sometimes you
> don't *have* to do that. With SCSI a system can be configured such that
> you could do the upgrade w/ the machine running and then just reset the
> device. Similar can be done with IDE, though I've only done it on IDE
> CDROM drives and not yet with a HD. I do suspect it would work though.
Upgrading firmware would typically be an unusual enough event the reboot
wouldn't be an issue. In the environments where a reboot is unacceptable,
a firmware change on-the-fly would probably be unacceptable too...
I'd rather like to see a nice "Manufacturer's Diagnostics/Update Disk"
available for my hardware. Easier and cheaper for them than supporting
Windows 98/ME, Windows NT/2k, Linux, Solaris/x86, BeOS, MacOS,
Solaris/SPARC, and every other OS which might be used with the drive!
(In fact, with Linux, they should be able to write one CPU-neutral
utility to do the work, then just recompile for each hardware platform
supported, along with a suitable kernel. Much better than the
alternatives...)
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:19 EST