Re: [patch] My AMD IDE driver, v2.7

Bill Davidsen
2002-03-12T16:35:28Z

On Mon, 11 Mar 2002, Linus Torvalds wrote:

>
>
> On Mon, 11 Mar 2002, Bill Davidsen wrote:
> >
> > I think you might want to offer an opinion (or edict, mandate, whatever)
> > WRT taskfile. While I think that some protective editing of commands is
> > desirable, useful, etc, I'm damn sure that some form of raw access is
> > required long term to allow diagmostics. I wouldn't argue if that
> > interface was required for low level format and other really drastic
> > operations as well.
>
> Quite frankly, my personal opinion is that there's no point in trying to
> parse the commands too much at all. The _only_ thing the kernel should try
> to care about is that the buffers passed to the command are valid (ie the
> actual data in/out area pointer should be a kernel buffer as far as
> possible, not under user control).
>
> Basically, there are three "modes" of operation here:
>
> - regular kernel access (ie the normal read/write stuff)
>
> parsing: none. The kernel originated the request.
>
> - common ioctl's that have nothing to do with IDE per se (ie all the
> stuff to open/close/lock removable media, unlocking DVD's, reading
> sound sectors etc - stuff that really exists elsewhere too, and where
> the kernel should do the translation from the generic problem space to
> the specific commands for the bus in quesion)
>
> Parsing: common ioctl turning stuff into common SCSI commands in the
> "struct request".

This next part is the one I believe should be a compile/boot option, since
it is the one which provides full access to the device.

> - totally IDE-only stuff, where the kernel simply doesn't add any value,
> and only has a way of passing it down to the drive, and passing back
> the requests.
>
> Parsing: none. The kernel simply doesn't have anything to do with the
> request, except to synchronize it with all other requests.

[observations on sync and queue issues understood and snipped]
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.