On Tue, 25 Jul 2000, James Sutherland wrote:
> On Tue, 25 Jul 2000, Stephen Frost wrote:
>
> > That is a possibility, though it's also more of a pain. It also
> > doesn't work in the more general case of other pieces of the system which
> > can be taken offline and upgraded but perhaps not easily removed.
>
> I'd rather have it disconnected from the host system for the upgrade,
> personally. Just imagine if that new RAID array firmware b0rks, flooding
> the host's SCSI bus with random crap...
One would tend to assume that the firmware had been tested by the
vendor to some extent. Also most every firmware I've seen has at least a
CRC check which makes it unlikely the firmware upgrade is going to fail.
Actually, I've honestly yet to have a firmware upgrade fail or do anything
as you describe.
> > You'd prefer large patches intended solely to filter a clean
> > interface better than letting root use a clean interface to do things
> > which *might* be bad?
>
> It shouldn't be a large patch - little more than an if statement - and the
> things in question are not potentially bad - they are DEFINED to be bad,
> with a single rare exception.
There are other exceptions, unless we know *exactly* what commands
are used to upgrade the firmware on every drive out there (we don't
currently), and then if we did we'd have to have an if statement for every
drive type and every command for every drive.
> > They aren't low-level diagnostics. A firmware upgrade doesn't go
> > probing all around the bus looking for stuff like a diagnostic might. Nor
> > does it probe the drive in funny ways, it uses a known (to the vendor, who
> > is writing the code) set of commands to pass a new firmware to the drive.
>
> That new firmware is a very low-level operation. Any problems with it, and
> you just broke the system.
It may be a low-level operation, but it certainly isn't a diagnostic.
Also, if there are problems with it you only *might* break the system. I
would actually tend to suspect the worst that would happen would be that the
drive would be useless, and that just means you have to default back to
making arrangements to down the machine, so you're unlikely to have *lost*
anything.
> > > I certainly don't want to see my hard drive tied to ANY particular OS, or
> > > group of OSs, which the vendor deigns to support. How could this be
> > > avoided with your method??
> >
> > There likely would be an option for either. My method does not
> > deny the existance of your method. Your method, however, is intended to
> > not allow mine.
>
> That's because I think your method is a bad thing in itself. I do NOT want
> to see things like this tied to any particular OS, Linux included. Nor do
> I like the idea of attempting low-level procedures online on a production
> system, but that's another issue.
They are already tied to a particular OS, having the ability to
do the upgrade in another OS cleanly may be a way to get it ported to
something that doesn't require a specific OS, or rather, doesn't require
the vendors to license the OS in order to provide floppy images.
> Anyway, the whole matter is largely void now - Andre expects the vendors
> to block these commands at the drive level anyway.
Hopefully they'll be able to do this in a sane and useful manner.
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:20 EST