On Tue, 25 Jul 2000, James Sutherland wrote:
> 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.
So we leave an option to the user to disable the checks, and
> > 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...
That's very unlikely to be the case. On a large system with lots
of users logging in all the time upgrading the flash on a disk not
currently in use shouldn't be a cause to reboot the machine. I doubt
you'd upgrade the firmware on a disk currently in use, that might be messy,
but with the RAID ability we're working towards there is the possiblity
that one could slowly go through and upgrade all of the disks without
the users knowing anything.
This is the kind of mainframe-like ability large data centers and
organizations are likely to find useful. Yes, Linux still has a long way
to go, but it's working on it, and hopefully we can keep it nice and clean
all the way.
> 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!
This could possibly work as well, and in general is what is done
now on small systems, but that doesn't mean we should limit ourselves to
it.
Stephen
-
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