[Rxtx] [patch 29/12] serial_close in termios.c

[Gerrit Telkamp]

As proposed by Trent, I will describe my patches here:

1- The main patch was in termios.c line 1188, where a close-Method is
   called when an error occured (cause by check_port_capabilities). It is
   wrong to call close() here, because termios.c used CreateFile to open
   the port (in the function open_port). Therefore, "serial_close" has to
   be called, updating the internal port management structure.

   I think the origin is that in a previous release of RXTX this function
   has been named "close()", later renamed to "serial_close()". In
   several debug outputs you also find "close" instead of "serial_close"
   and "open" instead of "serial_open" (Lines
   606,615,632,668,863,1170,1178). I would also propose to update these
   debug outputs, because it confused me while reading the code.

2- in "Serial.def", Line 4, the export declaration of
   "nativeGetVersion" is wrong (the JNI method declaration
   is done in RXTXVersion.java, not in RXTXCommDriver.java)
   Line 4 Replaced by
     Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8

3- in "Configure.java", Line 160:
   Wrong message, because the name of the properties file is
     "gnu.io.rxtx.properties" (not "gnu.io.comm.properties")
   The message could cause some confusion.

4- In my environment, I get an error message because the JNI functions
   JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in
   SerialImp.c.
   The declaration in init.c is not used anymore, so I propose to
   comment it out.

Best regards,

Gerrit.

> On Thu, 29 Dec 2005, Gerrit Telkamp wrote:

>> Hi,
>>
>> I think I've had the same problem some months on a windows platform.
>> Please try out the attached patch. It simply replaces some files of
>> your the current source directory (I've made also some beautifications
>> here). If it works, give us a note, so my patches could be brought
>> into the current cvs repository.
>>
>> Best regards,
>>
>> Gerrit.

> Hi Gerrit

> I'm interested in getting patches into rxtx that would help all the 
> projects.  This is a little awkward as they are just files.

> If you break the patches into concepts (especially break out code cleanups 
> seperate) and post them here, we can put the changes in if everyone 
> agrees.

> The key is to have patches that everyone can understand so they can object 
> if it may break what they are doing.  With open source projects you see 
> patches go in like this thread from another mail-list:

> # [patch 09/11] mutex subsystem, debugging code 
> # [patch 06/11] mutex subsystem, add default include/asm-*/mutex.h files 
> # [patch 04/11] mutex subsystem, add include/asm-x86_64/mutex.h Ingo
>      * Re: [patch 04/11] mutex subsystem, add include/asm-x86_64/mutex.h
>            o Re: [patch 04/11] mutex subsystem, add add include/asm-x86_64/
>            o Re: [patch 04/11] mutex subsystem, add add include/asm-x86_64/

> http://www.ussg.iu.edu/hypermail/linux/kernel/0512.3/index.html

> Each patch is a concept.  Then if there are objections (as with 04/11) to 
> a specific concept, others can raise concerns.  If its hard for you to 
> break out, it is especially hard for members on the list that did not make 
> the changes to follow.

> --
> Trent Jarvi
> tjarvi at qbang.org