On Fri, 9 Jun 2006 09:16:37 -0700 Greg KH <[EMAIL PROTECTED]> wrote: | 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.
Oh, that's right. | > | 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? Yes, that's a case where I like the feature 'only do what I've asked you to do'. | Well, ok, they might, but that goes against the default way the kernel | handles structures of data pointers... I _think_ it's not true for callback functions in 'operations' structures. -- Luiz Fernando N. Capitulino _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
