On Tue, 25 Jul 2000, Stephen Frost wrote:
> So we leave an option to the user to disable the checks, and
A compile-time facility somewhere. The vendor can just compile a kernel as
needed, then compile their utils for that CPU.
> 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.
Do you want to do low-level maintenance/diagnostics on a drive in situ, on
a production machine? I wouldn't. At the very least, I'd prefer to pull
the drive, plug it into another machine and do the work there. On such a
machine, the drives will be hot-pluggable, I suspect...
> 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.
Nice and clean is not a term I'd apply to your approach.
> > 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.
You need to take the drive offline anyway. I'd prefer to avoid running any
low-level diagnostics on a production machine if I can avoid that.
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??
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