Re: [linux-usb-devel] urbs are REFERENCE COUNTED!!! [was Re: [PATCH]generic usb serial driver]
On Sunday 01 April 2007 8:16 pm, Greg KH wrote: > > The way to properly solve this is to just never care about recycling > urbs. Look at what the visor driver does as an example of how you can > just create a new urb for _every_ instance, fire it off, and then forget > about it. It gets used and then automatically cleaned up. That can certainly work, and it has the advantages of simplicity. I wouldn't use that strategy in every driver of course, but I'd guess it's fine for the serial and usblp cases mentioned here. - Dave - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] urbs are REFERENCE COUNTED!!! [was Re: [PATCH]generic usb serial driver]
On Mon, Apr 02, 2007 at 01:05:21AM -0700, David Brownell wrote: > On Sunday 01 April 2007 8:16 pm, Greg KH wrote: > > > > The way to properly solve this is to just never care about recycling > > urbs. Look at what the visor driver does as an example of how you can > > just create a new urb for _every_ instance, fire it off, and then forget > > about it. It gets used and then automatically cleaned up. > > That can certainly work, and it has the advantages of simplicity. > I wouldn't use that strategy in every driver of course, but I'd > guess it's fine for the serial and usblp cases mentioned here. Why would you not want it in every driver? As Oliver is finding out, a lot of these "simple" drivers have races all due to their use of a pre-allocated urb. For what kind of situation would you feel this would not work? thanks, greg k-h - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] urbs are REFERENCE COUNTED!!! [was Re: [PATCH]generic usb serial driver]
On Mon, 2 Apr 2007, Greg KH wrote: > On Mon, Apr 02, 2007 at 01:05:21AM -0700, David Brownell wrote: > > On Sunday 01 April 2007 8:16 pm, Greg KH wrote: > > > > > > The way to properly solve this is to just never care about recycling > > > urbs. Look at what the visor driver does as an example of how you can > > > just create a new urb for _every_ instance, fire it off, and then forget > > > about it. It gets used and then automatically cleaned up. > > > > That can certainly work, and it has the advantages of simplicity. > > I wouldn't use that strategy in every driver of course, but I'd > > guess it's fine for the serial and usblp cases mentioned here. > > Why would you not want it in every driver? As Oliver is finding out, a > lot of these "simple" drivers have races all due to their use of a > pre-allocated urb. For what kind of situation would you feel this would > not work? You don't need to do it in drivers that run in a single kernel thread, just using the same URB over and over (like usb-storage). Or in drivers that simply resubmit the same URB from within the completion handler (like khubd). The difficulties arise because requests are generated from userspace asynchronously with respect to completions. Alan Stern - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] urbs are REFERENCE COUNTED!!! [was Re: [PATCH]generic usb serial driver]
On Mon, 2 Apr 2007 01:52:22 -0700, Greg KH <[EMAIL PROTECTED]> wrote: > Why would you not want it in every driver? As Oliver is finding out, a > lot of these "simple" drivers have races all due to their use of a > pre-allocated urb. For what kind of situation would you feel this would > not work? We need some kind of sample code which works. I had to patch airprime because your implementation of the read path was erroneous. The write path was ok, presumably because you took it out of visor where it was tested before. So perhaps we want to start with some driver and declare it "ideal", then steal code from it. The usblp would be a good choice, but we had so many regressions over time in it... It seems to be trickier than it looks. If you want, I can try that later, since I have to answer Oliver's challenge of mb()-less code anyway. -- Pete - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] urbs are REFERENCE COUNTED!!! [was Re: [PATCH]generic usb serial driver]
On Mon, Apr 02, 2007 at 09:58:00AM -0400, Alan Stern wrote: > On Mon, 2 Apr 2007, Greg KH wrote: > > > On Mon, Apr 02, 2007 at 01:05:21AM -0700, David Brownell wrote: > > > On Sunday 01 April 2007 8:16 pm, Greg KH wrote: > > > > > > > > The way to properly solve this is to just never care about recycling > > > > urbs. Look at what the visor driver does as an example of how you can > > > > just create a new urb for _every_ instance, fire it off, and then forget > > > > about it. It gets used and then automatically cleaned up. > > > > > > That can certainly work, and it has the advantages of simplicity. > > > I wouldn't use that strategy in every driver of course, but I'd > > > guess it's fine for the serial and usblp cases mentioned here. > > > > Why would you not want it in every driver? As Oliver is finding out, a > > lot of these "simple" drivers have races all due to their use of a > > pre-allocated urb. For what kind of situation would you feel this would > > not work? > > You don't need to do it in drivers that run in a single kernel thread, > just using the same URB over and over (like usb-storage). Or in drivers > that simply resubmit the same URB from within the completion handler > (like khubd). > > The difficulties arise because requests are generated from userspace > asynchronously with respect to completions. Yes, which is usually the majority of the drivers we have :) thanks, greg k-h - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] urbs are REFERENCE COUNTED!!! [was Re: [PATCH]generic usb serial driver]
On Mon, Apr 02, 2007 at 08:03:27AM -0700, Pete Zaitcev wrote: > On Mon, 2 Apr 2007 01:52:22 -0700, Greg KH <[EMAIL PROTECTED]> wrote: > > > Why would you not want it in every driver? As Oliver is finding out, a > > lot of these "simple" drivers have races all due to their use of a > > pre-allocated urb. For what kind of situation would you feel this would > > not work? > > We need some kind of sample code which works. I had to patch airprime > because your implementation of the read path was erroneous. The write > path was ok, presumably because you took it out of visor where it was > tested before. So perhaps we want to start with some driver and declare > it "ideal", then steal code from it. The usblp would be a good choice, > but we had so many regressions over time in it... It seems to be > trickier than it looks. If you want, I can try that later, since I have > to answer Oliver's challenge of mb()-less code anyway. Yes, after writing the above, I spent the day with Oliver talking all about these issues. And I agree that we need a good example driver, I'll take a look at getting the usb-skeleton driver working properly for all of this. thanks, greg k-h - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
