On Thu, Jun 08, 2006 at 05:22:50PM -0300, Luiz Fernando N. Capitulino wrote: > On Wed, 7 Jun 2006 15:40:13 -0700 > Greg KH <[EMAIL PROTECTED]> wrote: > > | On Wed, Jun 07, 2006 at 04:53:33PM -0300, Luiz Fernando N. Capitulino wrote: > | > > | > Hi Sergei, > | > > | > On Wed, 07 Jun 2006 21:54:16 +0400 > | > Sergei Organov <[EMAIL PROTECTED]> wrote: > | > > | > | Would it be a welcome contribution if I try to split the "generic" into, > | > | say, usb-serial-core and usb-serial-generic, the latter being really > | > | tiny at the beginning, and then improve it for speed? I've actually done > | > | it (speed improvement for bulk transfers) one time for 2.4.x, but at > | > | that time interface to the tty layer was not suitable for high-speed > | > | transfers and therefore my code had quite a few ugly kludges and finally > | > | I wasn't able to match raw USB bulk speeds anyway. Now, AFAIK, the tty > | > | layer interface has been improved and I hope to have better experience. > | > > | > Yes, it was. > | > > | > Considering the current design, one thing I'd like to have is the generic > | > code completely decoupled from the usbserial module, ie, a real > | > usbserial-generic module. > | > > | > This would also force us to kill the fix_up_generic() function. > | > I don't like the way it works, IMHO, it's C black magic, and it > | > can lead to trouble. > | > | How? It works like other kernel functions, if you don't define your own > | function pointer, it defaults to the "generic" one. > > My theoretical trouble may happen when you're new to the usbserial > layer and are hacking a new driver and forget to assign, let's say, > open(). Then you run the driver, and realizes that a magical function > ran. After some time debugging it, you discover fixup_generic().
If you load usbserial with debugging enabled, you see the message explicitly when you load your module that the overloading is happening. > | I created the fix_up_generic() function to make it easier than doing the > | check on every test for the different function pointers. One test at > | module load time is better than a test for every time write() is called > | :) > > Sure, and that's really good. > > But I'd check whether it's NULL, if so, I wouldn't load the driver > and would print a message, something like "open() not assigned". But what about the drivers that _want_ open to use the generic one. Drivers like funsoft.c? hp4x.c? Should they be forced to specify the generic function? Well, ok, they might, but that goes against the default way the kernel handles structures of data pointers... thanks, greg k-h _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
