Re: CAM-ification - documentation
> > Ick. Polling == bad. Interrupts == good. This isn't a single- > > tasking OS ala Win9x. This goes double for SCSI drivers, which are > > inherently async and overlapped. > > I never said polling was good. Nick just asked about polling, and I > commented on how it could be done. I have no idea why he wanted to know > about polling, though. Well, I am not sure whether I need polling, but there are some problems related to the fact that multiple USB transactions are needed for one SCSI transaction. Combined with the fact that some requests are done asynchronously (clear endpoint halt at the end of a transaction if the transaction failed) it might be useful to do polling to avoid massively complex code. Nick -- e-Mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CAM-ification - documentation
Randell Jesup wrote... > This discussion should probably move to the freebsd-scsi list... > > "Kenneth D. Merry" <[EMAIL PROTECTED]> writes: > >Nick Hibma wrote... > >> Especially some help on the topic of polling would be appreciated. > >> Otherwise I'll have to resort to figuring out how to do things in > >> interrupt context, and that is going to be dirty. > > >If you're talking about polling for transaction completion in a device > >driver, my guess is that you're going to have to do things in an interrupt > >context. (Unless you use a kernel process to do it.) > > > >The thing to remember is that when you get CCBs down in a CAM device > >driver, it may well be in an interrupt context. You have to be able to > >deal with that. My guess is that it might be easiest to just use a timeout > >handler to poll the device for completion every so often. A kernel process > >may also be an option, depending on how nasty the device is. > > Ick. Polling == bad. Interrupts == good. This isn't a single- > tasking OS ala Win9x. This goes double for SCSI drivers, which are > inherently async and overlapped. I never said polling was good. Nick just asked about polling, and I commented on how it could be done. I have no idea why he wanted to know about polling, though. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CAM-ification - documentation
This discussion should probably move to the freebsd-scsi list...
"Kenneth D. Merry" <[EMAIL PROTECTED]> writes:
>Nick Hibma wrote...
>> Especially some help on the topic of polling would be appreciated.
>> Otherwise I'll have to resort to figuring out how to do things in
>> interrupt context, and that is going to be dirty.
>If you're talking about polling for transaction completion in a device
>driver, my guess is that you're going to have to do things in an interrupt
>context. (Unless you use a kernel process to do it.)
>
>The thing to remember is that when you get CCBs down in a CAM device
>driver, it may well be in an interrupt context. You have to be able to
>deal with that. My guess is that it might be easiest to just use a timeout
>handler to poll the device for completion every so often. A kernel process
>may also be an option, depending on how nasty the device is.
Ick. Polling == bad. Interrupts == good. This isn't a single-
tasking OS ala Win9x. This goes double for SCSI drivers, which are
inherently async and overlapped.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: CAM-ification - documentation
[ reply moved the bottom... ] Nick Hibma wrote... > > Warner Losh wrote... > > > In message <[EMAIL PROTECTED]> Wilko Bulte writes: > > > : How difficult would CAMifying a driver be? > > > > > > Speaking of which, has a "How to CAMify a driver" doc been written? > > > > Nope. You've CAMified a driver, would you like to write it? :) > > > > Ken > > > > While on the topic: What documentation is there for CAM? I've found the > following, but would like to know whether there is more > > - CAM specification (at Digital?) www.t10.org, as Matt pointed out. FreeBSD/CAM is mostly CAM-2, with some CAM-3 thrown in. > - justin's docu on freefall. > > Especially some help on the topic of polling would be appreciated. > Otherwise I'll have to resort to figuring out how to do things in > interrupt context, and that is going to be dirty. Well, first off, are you talking about polling for completion in a peripheral driver or a SIM/HBA driver? If you're looking to poll for CCB completion in a peripheral driver, there's already xpt_polled_action() and an example of how to use it in dadump() in scsi_da.c. If you're talking about polling for transaction completion in a device driver, my guess is that you're going to have to do things in an interrupt context. (Unless you use a kernel process to do it.) The thing to remember is that when you get CCBs down in a CAM device driver, it may well be in an interrupt context. You have to be able to deal with that. My guess is that it might be easiest to just use a timeout handler to poll the device for completion every so often. A kernel process may also be an option, depending on how nasty the device is. I would recommend talking to Justin about it. I'm sure he'll be glad to give you some recommendations on how to proceed. He's also not the only one who knows about this sort of stuff. By now, Matt Jacob has a reasonable amount of experience with CAM drivers and he may also be able to give you some advice. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CAM-ification - documentation
There's a CAM ANSI spec at http://www.t10.org. But the lack of implementatio for FreeBSD docs is probably the biggest missing piece for FreeBSD's implementation. On Fri, 8 Oct 1999, Nick Hibma wrote: > > While on the topic: What documentation is there for CAM? I've found the > following, but would like to know whether there is more > > - CAM specification (at Digital?) > - justin's docu on freefall. > > Especially some help on the topic of polling would be appreciated. > Otherwise I'll have to resort to figuring out how to do things in > interrupt context, and that is going to be dirty. > > Nick > > > Warner Losh wrote... > > > In message <[EMAIL PROTECTED]> Wilko Bulte writes: > > > : How difficult would CAMifying a driver be? > > > > > > Speaking of which, has a "How to CAMify a driver" doc been written? > > > > Nope. You've CAMified a driver, would you like to write it? :) > > > > Ken > > > > -- > ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
CAM-ification - documentation
While on the topic: What documentation is there for CAM? I've found the following, but would like to know whether there is more - CAM specification (at Digital?) - justin's docu on freefall. Especially some help on the topic of polling would be appreciated. Otherwise I'll have to resort to figuring out how to do things in interrupt context, and that is going to be dirty. Nick > Warner Losh wrote... > > In message <[EMAIL PROTECTED]> Wilko Bulte writes: > > : How difficult would CAMifying a driver be? > > > > Speaking of which, has a "How to CAMify a driver" doc been written? > > Nope. You've CAMified a driver, would you like to write it? :) > > Ken > -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
