On Tue, 25 Jul 2000, James Sutherland wrote:
> 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.
That may be true, and maybe they'll do it in the future. Though
they'll need something other than MSDOS if they do it with disk images since
they'd have to license MSDOS. Personally I don't particularly care what
they use for this alternative method, but I would like to see an ability to
do it under Linux.
> > 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.
And you'll just clutter the kernel up more and more with this
filtering junk. "Oh, this is okay, and that is okay, and this, and that..."
Blech, no thanks.
> > > 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.
Doing it at the drive level is the correct place for it, via a
jumper or a piece of encryption/authentication.
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