<div class="gmail_quote">2011/3/9 ABC <span dir="ltr"><<a href="mailto:abc@telekom.ru">abc@telekom.ru</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">| š for (tr = available_transports; tr->ttype; tr++) {<br>
|<br>
</div>| š šDBG (4, "%s: %s: tr->ttype=%s\n", __FUNCTION__, devname, tr->ttype);<br>
<div class="im">|<br>
| š šif (!strncmp (devname, tr->ttype, strlen(tr->ttype)) ||<br>
</div>| š š š š(!strncmp (devname, "libusb", strlen("libusb")) &&<br>
| š š š š !strncmp (tr->ttype, "usb", strlen("usb"))))<br>
| š š šbreak;<br>
<br>
That is more hacky to me, becasue 1) you using/duplicating internal<br>
representation of device name "usb" from available_transports struct which<br>
somewhere else in the code; 2) you using/duping internal representation of<br>
"libusb" which is very very far away somewhere else in deepness of sanei<br>
(or libusb?) code. If we using what sanei gives us then we should not assume<br>
what library it is using for usb access and it's device names. But for<br>
"tcp" - that is what we invented to handle intentionally. So we only<br>
need work out special case of "tcp" and keep rest logic unchanged.<br></blockquote><div><br></div><div>I couldn't agree more. That's why I didn't want my patch to be committed to the code base.</div>
<div><br></div><div>šWhat i think should actually happen is that sanei should have it's own method for dealing with usb (and other busses) in whatever form it takes (e.g. /dev/scanner dev file or libusb or scsi device or whatever). Sanei should call any callbacks into the backend with a generic form for the bus type instead of exposing it's innards. Assuming that a string is the best form for that generic form, something like "usb:vendor_id:product_id" is probably reasonable.</div>
<div><br></div><div>Even more useful might be a struct with a type field (maybe a string or integer) and a union field that allows a pointer to a struct for each of the different busses that is supported by SANE. For example, I think it would be similar to the following:</div>
<div>enum device_type {</div><div>ššUSB_DEVICE_TYPE,</div><div>ššSCSI_DEVICE_TYPE,</div><div>ššPARALLEL_DEVICE_TYPE,</div><div>};</div><div><br></div><div>struct device {</div><div>ššenum device_type device_type;</div><div>
ššunion info {</div><div>šš šstruct usb_device_info* usb;</div><div>šš šstruct scsi_device_info* scsi;</div><div>šš šstruct parallel_device_info* parallel;</div><div>šš};</div><div>};</div><div><br></div><div>struct usb_device_info {</div>
<div>ššint16_t vendor_id;</div><div>ššint16_t product_id;</div><div>šš...other fields...</div><div>};</div><div><br></div><div>Then the attach callback signature could be:</div><div>static SANE_Status</div><div>attach(struct device)</div>
<div><br></div><div>One could even take it a step further and have an attach_funcs struct that we could register handlers for different busses:</div><div>stuct attach_funcs {</div><div>ššSANE_Status (*usb_attach)(struct usb_device_info*);</div>
<div>ššSANE_Status (*scsi_attach)(struct scsi_device_info*);</div><div>ššSANE_Status (*parallel_attach)(struct parallel_device_info*);</div><div>};</div><div><br></div><div>const struct attach_funcs DEFAULT_ATTACH_FUNCS = {</div>
<div>ššusb_attach = NULL;</div><div>ššscsi_attach = NULL;</div><div>ššparallel_attach = NULL;</div><div>};</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div>Then one could just do something like the following for a USB only backend:</div>
<div>struct attach_funcs xerox_mfp_attach_funcs =šDEFAULT_ATTACH_FUNCS;</div><div>xerox_mfp_attach_funcs.usb_attach = xerox_mfp_usb_attach;</div><div><br></div><div>Then a pointer to that struct can be passed instead of a single function pointer that takes a string. The sanei code could know to call the appropriate bus function if it's not NULL. The primary point of this design is that the sanei code could decide which bus to use and call the appropriate callback. I think that could actually improve debugability.</div>
<div><br></div><div>I'm sure I could take this further, but I am going to stop now. :) However, I would like to say that I think using ideas like this across all backends could make the backend code much easier to read since it has the potential to normalize some of the code used in the backends.</div>
<div>š</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">And 3) original intent of tr->ttype name is not fulfilled a) it was<br>
wrong becasue it assumes usb device names which it should' not,<br>
b) we still need to compare to "libusb" as for "usb".<br></blockquote><div><br></div><div>I agree.</div><div><br></div><div>I just think that there is a lot room for improvement in the backend code in general.</div>
<div><br></div><div>I know my original patch was a hack. It was an attempt to point out the real problem. It seems to have worked. :)</div><div>š</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Thanks for your valuable help. :)</blockquote><div><br></div><div>No problem. Thanks for discussing the solution. This is really what make free software great in my opinion. I really only do this because I want to see SANE and other projects improve and become more useful to users.</div>
<div><br></div><div>wtš</div></div>