[SM 0]

Такой вопрос. Как я понимаю, для булок в либусб есть только вот это:

 

int usb_bulk_read(usb_dev_handle *dev, int ep, char *bytes, int size, int timeout);

 

А я хочу сделать большой и длинный write, и в параллель ему пустить большой и длинный read (на каждые два полученных слов девайс отдает одно обратно). И что делать? Вижу два выхода. Первый - в одном треде дать write, в другом read. А как оно, жить-то будет? либусб нормально мультитредность переносит? Второй... Пока не вижу... Есть ли в либусб асинхронные операции ? И какие есть альтернативы либусб вообще?

[Harbour 0]

async режим поддерживается в libusb-1.x, как уже было замечено в треде по altera jtagd. там при заполнении структуры операции есть поле libusb_transfer_cb_fn - callback ф-ии, которая вызывается при ошибке/завершении операции. треды libusb всегда херово поддерживала, но при наличии async интерфейса они собственно и не нужны. альтернатива libsub, насколько мне известно - это написать модуль/драйвер своего устройства в ядре.

[SM 0]

А вот такой вопрос - ее лучше статически прилинковать? Или как? А то вот например в centos ее нет по дефолту (rpm -ql libusb показывает только нулевую). И yum-ом она не находится.

 

И... LGPL.... Кто-нить, разъясните плиз:

 

The "Minimal Corresponding Source" for a Combined Work means the Corresponding Source for the Combined Work, excluding any source code for portions of the Combined Work that, considered in isolation, are based on the Application, and not on the Linked Version.

 

т.е. я должен какие-то куски кода открыть? Т.е. сделать типа свою опенсурс-либу, которая будет между моим приложением и либусб? При том, что проект не опенсурс (я другие куски кода просто не имею права открывать по NDA). А как тогда альтера - она ведь jtagd явно статически слинковала, и сырцами там и не пахнет.

[Harbour 0]

До спины как ее линковать, если не стоит вопрос с лицензией. качают ее обычно с SF. LGPL (есть где-то фак в сети на русском) подразумевает использование в коммерческих проектах при динамической линковке и предоставление всех исходников/обьектных файлов при статической. Т.е. линкуем динамически - и ничего открывать не нужно. Альтера когда-то применяла libusb, сейчас, судя по предварительным результатам дизассемблирования, они работают напрямую с usbfs - т.е. ничего и никому они не обязаны.

[SM 0]

До спины как ее линковать, если не стоит вопрос с лицензией. качают ее обычно с SF. LGPL (есть где-то фак в сети на русском) подразумевает использование в коммерческих проектах при динамической линковке и предоставление всех исходников/обьектных файлов при статической.

 

Где скачать я знаю, у меня больше вопросов именно с лицензией. Планируется бесплатный софт в виде расширения Tcl/Tk, свободно лежащий на сайте производителя неких девайсов (тот самый флешепрошиватель для TI DSP, который будет представлять собой доступ через xds510 к отладочным возможностям всех чипов TI через TCL, типа там "загрузить .out", поставить брейкпойнт, выполнить, изменить регистр, и т.п.). Т.е. проект некоммерческий, freeware, но не opensource. Да я и не могу открыть исходники, так как я использую в ее составе EPK от TI, который под NDA. Мне, судя по всему, нужно libusb 1.0, так как работать напрямую с usbfs мне влом (кстати, сложно это? Может зря мне влом?). Проблемы (так как техподдержкой занимаюсь не первый год) предвижу сразу и серьезные, так как у юзеров не будет в дистрах libusb нужной. И посыпятся вопросы - почему, как, что... Я хочу их избежать, отсюда хочется статически слинковать. Вопрос - LGPL позволит мне не открывать то, что я не имею права открывать, при статической линковке? Или как эту проблему обойти? Рядом с софтом положить libusb-1 (ну типа готовый rpm для RHEL), а у кого не RHEL, возитесь, как хотите? Так как впервые связался с такой вещью, прошу советов.

 

И.. вдогонку. А свой драйвер уровня ядра - это сложно? Проще/сложнее дров для винды (которые я пишу совершенно свободно)? Я под линуксом дальше простых патчилок и всевозможных скриптов пока еще ничего не писал.

[al333 0]

Где скачать я знаю, у меня больше вопросов именно с лицензией. Планируется бесплатный софт в виде расширения Tcl/Tk, свободно лежащий на сайте производителя неких девайсов (тот самый флешепрошиватель для TI DSP, который будет представлять собой доступ через xds510 к отладочным возможностям всех чипов TI через TCL, типа там "загрузить .out", поставить брейкпойнт, выполнить, изменить регистр, и т.п.). Т.е. проект некоммерческий, freeware, но не opensource. Да я и не могу открыть исходники, так как я использую в ее составе EPK от TI, который под NDA. Мне, судя по всему, нужно libusb 1.0, так как работать напрямую с usbfs мне влом (кстати, сложно это? Может зря мне влом?). Проблемы (так как техподдержкой занимаюсь не первый год) предвижу сразу и серьезные, так как у юзеров не будет в дистрах libusb нужной. И посыпятся вопросы - почему, как, что... Я хочу их избежать, отсюда хочется статически слинковать. Вопрос - LGPL позволит мне не открывать то, что я не имею права открывать, при статической линковке? Или как эту проблему обойти? Рядом с софтом положить libusb-1 (ну типа готовый rpm для RHEL), а у кого не RHEL, возитесь, как хотите? Так как впервые связался с такой вещью, прошу советов.

 

И.. вдогонку. А свой драйвер уровня ядра - это сложно? Проще/сложнее дров для винды (которые я пишу совершенно свободно)? Я под линуксом дальше простых патчилок и всевозможных скриптов пока еще ничего не писал.

1. сейчас libusb-0.1.12 и это на арче, так что libusb-1. сырой и нет даже в testing

2. libusb-0.1.12 с тредами там тяжко.

3. lgpl только динамически без открытия кода.

4. если глыбоко не углублятся то один и тот же модуль ядра работает с 12 по 22 версию, но в 29-й в функции изменился тип данных. Поэтому может быть надежнее libusb.

5. комбинировал из sisusb.c usbtest.c и скелет из исходников ядра.

[SM 0]

3. lgpl только динамически без открытия кода.

А если сделать свою либу, статически линкованную с libusb, ну тоже lgpl, ее код соотв. открыть полностью.. Кода там немного совсем добавить - чтобы искала нужные устройства, открывала их, ну и т.п., и ничего проприетарного, такого, чтобы я не имел права открывать. А основной мой модуль линковать уже с ней динамически. Так можно?

[Harbour 0]

Гы ;), не конает - коммерческая программа, не должна, по LGPL, содержать внутри свободного обьектного кода, допускается только динамическая линковка. Че за проблем - слепить S/RPM с libusb-1.x или просто положить ее вместе с прогой - этого никакая лицензия не запрещает. Драйвер будет не сложнее, чем вариант с libusb, но гембеля по сопровождению в N раз больше.

[SM 0]

Гы ;), не конает - коммерческая программа, не должна, по LGPL, содержать внутри свободного обьектного кода, допускается только динамическая линковка.

 

Дык, идея такая - я слеплю libxdsaccess.so, которая будет открытая по самые помидоры и статически слинкованная с libusb. И моя софтина будет состоять из пакета libxdsaccess (с src, devel и т.д. как положено), и libtclxds.so - которая уже без сырцов, в которой вся проприетарщина, и которая будет динамически линковаться с libxdsaccess. Вроде же ничего не нарушено. Хотя, конечно, если я в состав дистра могу включить libusb как она есть в виде rpm - то все вопросы сняты (я почему-то думал, что это априори нельзя).

 

ЗЫ какая нахрен коммерцеская софтина, если она freeware.

 

но гембеля по сопровождению в N раз больше.

А в чем суть этого гембеля? Пойти по пути nvidia, чтобы инсталлятор сам собирал дровину под ядро.

[Harbour 0]

Так можно - главное чтобы libtclxds.so не содержала в себе libusb ни в каком виде, токмо как в dynamic linked, неважно через какие промежуточные либы. А то что Freeware или ХренWare - если недоступны исходники, то уже нарушаем LGPL.

 

А гембель в том, что никто модуль этот собирать сам не будет, по причине того что binutils/gcc/kernel headers мало у кого стоит - и придется или как у Nvidi'и иметь херову тучу уже собранных или писать инсталлятор. тут наступаем на новые грабли, так как у юзеров N^N вариантов конфигурирования ядра, X^Y вариантов binutils/gcc - будут присылать неудачные логи, придется их разгребать и решать одни и те же вопросы, которые давно описаны в факе, который, в свою очередь никто не читает ... и все это на расплодившемся множестве дистров ... вобщем волосы дыбом на одном месте обеспечены.

 

То ли дело бинарная libusb - кинул и забыл

[SM 0]

То ли дело бинарная libusb - кинул и забыл

Собственно, если так можно - то гуд. Действительно, проще всего. Да и пока софтина выйдет до не-бета-уровня, х.з. еще сколько времени пройдет (мне ведь в либу собирать полностью весь xdsfast3 и *.dvr из композера - а это не так и просто. Если xdsfast3 более-менее кроссплатформенный (по крайней мере win и dsp/bios), то dvr....), ну а за это время libusb-1 мож и stable станет и во всех репозиторях апдейтов лежать будет....

 

binutils/gcc/kernel headers мало у кого стоит

опа... А я считал, что это у всех поголовно в обязательном порядке :)

[Harbour 0]

процент разрабов всегда сурьезно меньше чем юзеров - количество пакетов в репах неуклонно растет - зачем собирать, если можно и так уже готовое скачать. другое дело - целевая аудитория прикладухи - если это по определению разрабы, то вопросов нет.

[al333 0]

А гембель в том, что никто модуль этот собирать сам не будет, по причине того что binutils/gcc/kernel headers мало у кого стоит - и придется или как у Nvidi'и иметь херову тучу уже собранных или писать инсталлятор. тут наступаем на новые грабли, так как у юзеров N^N вариантов конфигурирования ядра, X^Y вариантов binutils/gcc - будут присылать неудачные логи, придется их разгребать и решать одни и те же вопросы, которые давно описаны в факе, который, в свою очередь никто не читает ... и все это на расплодившемся множестве дистров ... вобщем волосы дыбом на одном месте обеспечены.

 

То ли дело бинарная libusb - кинул и забыл

Если дело касается "крутых" убунтоидов, то возможно headers нет, а так Nvidia со своего сайта выдает sh-скрипт в котором и открытые исходники и уже собранные. Главное прописать зависимости. Ну и для каждой версии ядра придется проверять.

И поэтому,на мой взгляд, если в твоей закрытой проге супер навороченные функции, то лучше модуль. Ну, а если тебя устраивают libusb-функции, то лучше libusb. Статически слинкованный тоже обращается в конечном итоге к ядру, поэтому уж лучше модуль.

[SM 0]

И поэтому,на мой взгляд, если в твоей закрытой проге супер навороченные функции, то лучше модуль.

 

У меня оказывается все еще хуже. А именно вот что (вырезка из лицензии на то, что есть в модуле)

 

You shall maintain the source code portions of the Licensed Materials under password control protection at a secure location and shall not disclose such source code portions

of the Licensed Materials, or any portion or derivative thereof, to any third parties. You shall not (i) incorporate, combine, or distribute the Licensed Materials, or any derivative thereof, with any Public Software, or (ii) use Public Software in the development of any derivatives of the Licensed Materials, each in such a way that would cause the Licensed Materials, or any derivative thereof, to be subject to all or part of the license obligations or other intellectual property related terms with respect to such Public Software, including but not limited to, the obligations that the Licensed Materials, or any derivative thereof, incorporated into, combined, or distributed with such Public Software (x) be disclosed or distributed in source code form, be licensed for the purpose of making derivatives of such software, or be redistributed free of charge, contrary to the terms and conditions of this Agreement, or (y) be otherwise used or distributed in a manner contrary to the terms and conditions of this Agreement. As used in this Section 1©, ”Public Software” means any software that contains, or is derived in whole or in part from, any software distributed as open source software, including but not limited to software licensed under the following or similar models: (A) GNU’s General Public License (GPL) or Lesser/Library GPL (LGPL), (B) the Artistic License (e.g., PERL), © the Mozilla Public License, (D) the Netscape Public License, (E) the Sun Community Source License (SCSL), (F) the Sun Industry Standards Source License (SISL), (G) the Apache Server license, (H) QT Free Edition License, (I) IBM Public License, and (J) BitKeeper.

 

Т.е. жестоко запрещено любое приближение к public software, которое тянет за собой какие-то лицензионные требования, противоречащие этой лицензии. Т.е. придется делать лицензию на мой модуль в соответствии именно с этой лицензией, из которой выдержка. А там из серии "только на одном компе, только одна бэкап-копия, только для использования в целях отладки и программирования определенных процессоров, и т.п.". Бред, конечно, для фриварной программы, которую можно свободно скачать с сайта производителя, но... Что поделать...

 

Касаемо Tcl - там в TCL-лицензии вроде как вообще ограничений нет, типа копирайты не трогай, и делай что хочешь. Таким образом, распространяя TCL рядом с этим модулем хоть под такой аццкой лицензией, хоть под родной, я ничего вроде не нарушаю, так как TCL на меня вообще ничего не налагает, а вот LGPL - это уже другой вопрос, особенно с учетом того, что я не лучшим образом понимаю юридические тонкости англоязычных документов.

 

Блин, офтопик сплошной получитлся... Выделить бы как это в "вопросы лицензирования". И не ясно в какой раздел...

[Harbour 0]

следовало бы с работодателем эти вопросы оговорить и устаканить, что бы не вылезало подобное в середине проекта, потому как теперь есть куча моментов, например сборка части приложения под Linux подразумевает использование libc и ее header'ов - она как известно LGPL и это как ни крути есть "combining" ;)