Am Mittwoch, 16. Januar 2008 16:26:03 schrieb Alan Stern:
> On Tue, 15 Jan 2008, Oliver Neukum wrote:
>
> > > > > Do all ioctls filter through this routine? It looks like requests
> > > > > coming through block/scsi_ioctl.c will bypass this code. Have you
> > > > > decided to ignore those requests for now?
> > > >
> > > > I found no way to deal with them without pushing the autosuspend code
> > > > into the generic code.
> > >
> > > I thought up something. It's a bit hackish, so people probably won't
> > > like it... You could define a new SCSI_IOCTL_AUTORESUME code, for
> > > internal use only, and pass it down to the driver from within the block
> > > layer.
> >
> > Argh. There's a limit to depth I'll sink. If you can't do better, please put
> > autoresume/autosuspend into the driver core.
>
> This entire issue needs more thought. There must be plenty of ioctl
> calls which shouldn't force a device to remain resumed.
Sure. The question is whether it is worth a lot of effort to filter them.
Are ioctl()s on block devices common?
> Also, your implementation in terms of a single bit will work only for
> single-open devices. If multiple-open is allowed then something would
> have to be stored in the file structure. More generic code...
Why? I don't think you can assume that a user intends an ioctl() to be
"valid" only for the duration of that particular file. I intentionally put the
put into release which is called for the last close().
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
