On Tue, 25 Jul 2000, James Sutherland wrote:
> On Tue, 25 Jul 2000, Stephen Frost wrote:
>
> > > Making that sort of thing available to userland is not a good idea, IMO.
> >
> > It's already availible, as others have mentioned. There are other
> > ways to do it, this just provides a nice clean way instead of horrible
> > hacks.
>
> What horrible hacks? All that is needed in the kernel is a simple if
> statement, to reject these commands. Anyway, Andre is now proposing to T13
> that the drive itself enforce these limits, logging any violations to
> invalidate the warranty. End of problem: the drive does it for us.
Horrible hacks would be what would be required to get a firmware
upgrade to work under Linux with the restrictions in place. I sure hope
Andre isn't trying to convince drive makers that they can void their
warrentee if something hits those commands the wrong way.
> > > A vendor supplied bootdisk is completely OS neutral, since the OS is out
> > > of the equation. I could use that bootdisk whether my main OS is Linux,
> > > NT, FreeBSD, Netware, whatever I want.
> >
> > In the end, mainly this is because of the attempts to make it
> > simple for the users.
>
> Sorry, I can't parse that. WHAT is because of attemts to make WHAT simple
> for users - the restriction to a specific platform group, just so users
> can have a nice point&drool interface for firmware changes?
The comments you left out regarding that you didn't like having to
have things be OS dependant. The reason they are now is because of end
users.
> > > > This keeps the vendor specific *junk* out of the kernel and in
> > > > userland.
> > >
> > > I'd rather keep it out completely.
> >
> > Personally, I like my CD burner.
>
> WTF does that come in - we're talking about writing firmware in devices,
> not writing to a CD-R. TOTALLY different issue.
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.
> > > It's dangerous - and the only legitimate use of this "feature" is one
> > > which shouldn't be done from within Linux in the first place.
> >
> > There are other uses of this direct access I suspect, perhaps not
> > as many under IDE as under SCSI, but they're there.
>
> 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.
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