Henning Nielsen Lund wrote:

Rene W. Olsen wrote:

...

Hello

I have BIG trouble with my library for libusb and I cant find any error in the source code :(

So if there is a library guru in here thats want to help me track down my error(s)..

I can compile the barebone library with no problem but I cant open the library without the system freezing, and the openlib program never returns.

I looks like it hangs in the library init function.

I have striped all the function to track down the nasty error

HELP PLEASE

The source files can be found here: http://www.rwo.dk/libusb.lha

I am no guru, but one little thing... #include <proto/Libusb.h> in loadlib.c should have been #include <proto/libusb.h>. I will try to test it later, to see if I get some errors too (have tried to compile the library and loadlib with newlib instead, to see if it can be a little clib2 thing).

I did just try the one that I had recompiled using newlib (cross compiled)... it crashed :-( But as I have not tried to use newlib before with the crosscompiler, did I try to compile it nativly, and it worked :-D

LibusbBase 0283fc38 ILibusb 02857550 OK TheEnd

So at least loadlib is able to open libusb.library :-D

And remember if it is compiled using newlib.library, can the programs using the library also only use newlib.library as the standard-C library (the same goes for clib2).

...

Kind regards Rene W. Olsen

---

Openoffice-os4 mailing list Openoffice-os4@samfundet.no https://lists.samfundet.no/mailman/listinfo/openoffice-os4

Rene W. Olsen wrote:

On 2005/03/26, Henning Nielsen Lund wrote:

...

Henning Nielsen Lund wrote:

...

...

I am no guru, but one little thing... #include <proto/Libusb.h> in loadlib.c should have been #include <proto/libusb.h>. I will try to test it later, to see if I get some errors too (have tried to compile the library and loadlib with newlib instead, to see if it can be a little clib2 thing).

I did just try the one that I had recompiled using newlib (cross compiled)... it crashed :-( But as I have not tried to use newlib before with the crosscompiler, did I try to compile it nativly, and it worked :-D

LibusbBase 0283fc38 ILibusb 02857550 OK TheEnd

So at least loadlib is able to open libusb.library :-D

Okey then you get futher than me. I dont get any text at all

...

And remember if it is compiled using newlib.library, can the programs using the library also only use newlib.library as the standard-C library (the same goes for clib2).

I dident think of that, I guess that I am using clib2 but I dont think there any clib2 function in the library code.

I thought that I saw something, but I might be wrong...

Regards Rene

---

Openoffice-os4 mailing list Openoffice-os4@samfundet.no https://lists.samfundet.no/mailman/listinfo/openoffice-os4

Rene W. Olsen wrote:

well now I just have to figure out where to open the device and I'm back on track.

Try to open it in the library's Open vector instead of the init code. The init code is executed on a separate thread within ramlib (under OS 4 at least). The open code is executed in the caller's context, so this is the better place to open it.

Regards,

Rene W. Olsen wrote:

I have been thinking about the sharing msgport and signal that is used in the open device and I dont really think its a good idea to share.. but where do I store the allocated stuff ?

You cannot easily share a signal between openers because the signal is task-specific, i.e. if you open from two different tasks then this will not work at all, not even if both tasks use the same signal bit because you cannot have a message port owned by two tasks.

Can I clone the libray base and return a clone to the user every time open lib is called?

It might be a better idea to have a "server process" that does the device handling, and communicate via messages with any opener. If you need to have opener-specific data, it might also be a better idea to do this in the interface instead of the library base - this is directly supported by the system and not as hacky in nature as cloning a library base.

Regards,

Rene W. Olsen wrote:

I dont like the "server process" method... when moving lots of data that method will be really slow becorse it has to enter wait state so offen.

The problem is, like I said, that a device must be opened by the same task that is going to use it. A server process might not be a nice solution, but it *is* a solution to this problem.

It need not be slow either. You don't need to copy data. This will really only pose a problem if there is a lot of small data items being moved around.

I have looked at clone interface, this really looks promessing especially if I can use one of the reserved fields in InterfaceData struct as a userdata field..

No, you shouldn't use these. Use a data size. For example, something like this:

struct Foo { uint32 field1; void *field2; char field3[20]; float field4; };

During creation of the interface, pass

MIT_Flags, IFLF_PRIVATE, MIT_DataSize, sizeof(struct Foo),

In your method, use

struct Foo *instanceData = (struct Foo *)((uint8 *)Self -sizeof(struct Foo));

to obtain the private instance data of your interface (looking at this I guess we should add a macro for that to the header file ;-)

Best regards,

Rene W. Olsen wrote:

If I enable the IFLF_PRIVATE flag my GetInterface failes... looks like I need to use Clone/Expunge.

Can you point me to an example?

Hmm, I thought that the default Clone would be sufficient... I'll have to check that.

Regards,

On 2005/04/01, Thomas Frieden wrote:

I've uploaded a file to the development section's file are (testlib.lha). Note that this is a pretty bad example since it still contains bugs, but I lack the time to come up with a better one.

Many thanks for this and it works

Okey now I have almost used 2 days trying too make my library do that same as you did with little luck :(

Now I have found whats is wrong.. if I calles my main interface "main" I get an extra Obtain() call like this

_main_Obtain() RefCount = 1 _manager_Open() _main_Clone() RefCount = 1 _main_Obtain() RefCount = 2 _main_Clone() RefCount = 1 _main_Obtain() RefCount = 2 _main_Clone() RefCount = 1 _main_Obtain() RefCount = 2 _main_Release() _main_Release() _main_Release() _manager_Close() _manager_Expunge()

Resulting in my RefCount being one highere than it should be and that means my interfaces never gets Expunge()'d, and futher my interface get too calls to free my orginal interface twice meaning an Aleart about mem freed twice guru...

If I rename the interface from "main" to "tmain" like yours every things work nicely no extra Obtain().. see

_manager_Open() _main_Clone() RefCount = 0 _main_Obtain() RefCount = 1 _main_Clone() RefCount = 0 _main_Obtain() RefCount = 1 _main_Clone() RefCount = 0 _main_Obtain() RefCount = 1 _main_Release() _main_Release()->Expunge() _main_Expunge() _main_Release() _main_Release()->Expunge() _main_Expunge() _main_Release() _main_Release()->Expunge() _main_Expunge() _manager_Close() _manager_Expunge()

So that do I do know?

Regards Rene W. Olsen

On 2005/04/03, Thomas Frieden wrote:

What you see is an oversight in Exec: Normally, old libraries provide a main interface with all the previous functionality, named "main". When calling OpenLibrary, it automatically executes GetInterface(.., "main", ...), since this is used by legacy jump tables.

ahh okey

To prevent this from happening, add the tag item

CLT_NoLegacyIFace, TRUE,

to the CreateLibrary tag list.

Added and it did the trick

I'm not sure, though, if that's already in the released kernel. You might want to add the tag nontheless (it's not rejected because of this). If it's not part of your header files, it's defined as

#define CLT_NoLegacyIFace (TAG_USER + 12)

Yep its in my realease

If in doubt, give the interface a meaninngful name. In the case of libusb, "usb" might be a good idea.

I prepeare 'main'

I know I have been a pain in the butt so many thanks fore your and your brothers help, now I can get back to porting (I hope)

Regards Rene W. Olsen

On 2005/04/03, Rose Humphrey wrote:

Le 03/04/2005, Rene W. Olsen a écrit :

...

I know I have been a pain in the butt so many thanks fore your and your brothers help, now I can get back to porting (I hope)

I rather suspect you don't qualify for the title. A true PIB asks questions and creates nothing. Not your case. Go away, and if you can't think of a better way of denigrating yourself, port another app ;)

So fare I havent created any thing but I took youre advise and ported a test programe for libusb now I only have to finish the library :)

Regards Rene W. Olsen