From Martin.Oberhuber at windriver.com Mon Sep 1 08:59:20 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 1 Sep 2008 16:59:20 +0200 Subject: [Rxtx] [Suspected Spam][Blocked Sender]Re: Towards an RXTX release - CSR BT/USB chipset In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com><13557-75390@sneakemail.com><20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848074C4259@ism-mail03.corp.ad.wrs.com> Hi Bruce, I think that the only way to avoid temparary disconnect during port scanning, is to avoid the temporary open() during port scanning. That, however, can only be avoided if there is some external means to enumerate the candidates for valid port names. The javax.comm implementations by Sun and IBM use a file named "javax.comm.properties" for this. On Linux and Solaris, it enumerates the allowed prefixes for device names to be used. Those prefixes known, the library treats all existing files with such prefixes as valid ports, without trying to actually open them. See http://java.sun.com/products/javacomm/ I'd think that one option to simplify the port scanning would be to use a Java System Property to specify the Policy for port scanning. For instance: -Dgnu.io.rxtx.PortScanningPolicy=read # try to open & read scanned ports -Dgnu.io.rxtx.PortScanningPolicy=existing # treat ports as valid if they exist For enumerating the candidates to check, the "gnu.io.rxtx.properties" file already exists as well as the "gnu.io.rxtx.SerialPorts" and "gnu.io.rxtx.ParallelPorts" System Properties. These support explicit enumeration of port candidates. So, a second possible enhancement in addition to support specifying the PortScanningPolicy could be to support specifying prefix names for port enumeration rather than just explicit enumeration. What do others think about these ideas? Could these improve the long-standing performance issues with USB / Bluetooth adapters during port scanning? Why does RXTX try to open scanned ports in the first place, rather than relying on plain existence of the devices? I'd guess that a Patch providing these enhancements would be appreciated by the RXTX community. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Bruce Boyes Sent: Tuesday, August 05, 2008 3:13 AM To: Rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender]Re: [Rxtx] Towards an RXTX release - CSR BT/USB chipset At 18:37 07/29/2008, you wrote: All, Is there any chance that the next official release could improve on the port scanning (getPortIdentifiers)? It would be nice if rxtx could also not cause a connect/disconnect and subsequent problems with a USB Bluetooth BlueSoleil adapter (using the CSR chipset), as documented in a previous email from me. best regards Bruce ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080901/f3cb9a8e/attachment-0002.html From Martin.Oberhuber at windriver.com Mon Sep 1 09:36:31 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 1 Sep 2008 17:36:31 +0200 Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> Hi all, I made some experiments with the Sun and IBM implementations of javax.comm (on Linux and Solaris), in order to understand how these treat port locking and lockfiles and in what way they report failure to obtain a port to the client. Here are the results: * Neither Sun nor IBM check or create any lockfiles. As a result, minicom can open the same serial port as my test java application without error. * Sun uses Kernel locking with fcntl, according to an strace (truss) that I had run with my test app: open("/dev/ttyS1", O_RDWR|O_NONBLOCK|O_EXCL) = 5 fcntl64(5, F_SETLK, {type=F_WRLCK, ...}) = 0 As a result, multiple instances of the same Java test program are protected against each other; minicom, however, is *not* protected since it does open("/dev/ttyS1", O_RDWR|O_NONBLOCK) on Linux RHEL 4 at least. * IBM seems to use some memory sharing between multiple instances of Java programs: CommPortOwnershipListener is called even if a different instance of the program tries to access the port. No port locking of any kind seems to be done though. As a result, IBM apps are protected against each other but not against minicom. * When opening a port fails due to missing permissions on the device file, or due to an exclusive lock owned by another instance of itself, - IBM throws a PortInUseException after the timeout (currentOwner="Unknown Application") - Sun throws a java.lang.RuntimeException immediately (message=one of the following two: "\n Error opening \"/dev/ttyS1\"\n Permission denied" "\n Error opening \"/dev/cua/a\"\n Error in lockf()" What I learn from this is that 1. Neither the Sun nor the IBM implementation are really useable in terms of port locking, since they do not respect minicom. 2. Sun's throwing a RuntimeException from CommPortIdentifier.open() is undocumented and may break client applications in an unexpected way. 3. Kernel locks through fcntl are not sufficient for minicom to keep it off the port. 4. Kernel locks give no indication what application is currently owning the port (lockfiles could give that information but minicom does not evaluate it). Does anybody on this list know the difference between fcntl(F_SETLK, {type=F_WRLCK}) and ioctl(fd, TIOCEXCL, 0); ? What do folks think about throwing a RuntimeException from CommPortIdentifier.open() ? I'll follow up with a separate E-Mail proposing a strategy for RXTX to handle port locking. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, July 30, 2008 4:16 AM > To: Oberhuber, Martin > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Port locking on Linux: Redhat lockdev-baudboy > Instead, I would suggest we do an exclusive open and try to > lock as is if > lockfiles are not disabled. Warn if the lock fails. Always respect > lockfiles prior to opening. > > Exclusive opens should work on linux, mac, sol, bsd, ... > > The code is simple and does not introduce any new dependencies. > > ... > open > ... > do { > res = ioctl(fd, TIOCEXCL, 0); > } while ( (errno == EINTR || errno == EAGAIN ) && res != 0 ); > > > if( res != 0 ) > fail > > > In the worst case, minicom or another application may not be > able to find a lockfile but their open will fail. We locked > the port. Other applications may not do this so we should > always respect lockfiles. > > -- > Trent Jarvi > tjarvi at qbang.org > From Martin.Oberhuber at windriver.com Mon Sep 1 10:05:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 1 Sep 2008 18:05:02 +0200 Subject: [Rxtx] RXTX Port Locking Improvements Message-ID: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> Hi all, here is my proposal for improving port locking in RXTX. 1. Goals of the Proposal * Support enabling / disabling / configuring port locking at runtime without re-compiling RXTX. * Support port locking by Kernel call even if permissions for lockfiles are not sufficient. * Report exact reason for failure to acquire a port to the client application (including the file system path of a lockfile for instance). 2. Getting the settings into RXTX * Use Java System Properties for tuning behavior (since the RXTX / javax.comm API is frozen): * -Dgnu.io.rxtx.LockfileDir=/var/lock # specify location of lockfile directory, similar to minicom * -Dgnu.io.rxtx.LockPolicy=none # no port locking, no warnings or anything * -Dgnu.io.rxtx.LockPolicy=default # try lockfiles, in case of missing permission fall back to kernel locks without warning * -Dgnu.io.rxtx.LockPolicy=warn # try lockfiles, in case of missing permission fall back to kernel locks with warning to stdout * -Dgnu.io.rxtx.LockPolicy=strict # require lockfiles, throw exception if they cannot be created. The "default" policy would try to be as good a citizen as possible (create lockfiles if possible, create Kernel exclusive lock if possible), but without guarantee and without warning in case it fails creating any lock. The warning to stdout would be something like "Warning: RXTX failed to create a lockfile in /var/lock/LCK..ttyS0. Check file system permissions or specify -Dgnu.io.rxtx.LockfileDir in order to enable proper locking of serial ports against other applications". 3. Error Reporting out of RXTX * All errors acquiring a port are reported by means of a gnu.io.rxtx.PortInUseException on CommPortIdentifier#open(). * In case of missing permissions or other unexpected failure running through open(), the "currentOwner" field is filled with the String "Unexpected Error", and the message field of the exception is filled with a String like "/dev/ttyS0 : Permission denied in open()" or "/var/lock/LCK..ttyS0 : Permission denied in write()" * In case of properly running through open() but not being able to lock the port, the "currentOwner" field is populated with the name and PID of the external process locking the port if it can be obtained, or "Unknown Application" otherwise. In other words, I'm proposing to replace Sun's RuntimeException for reporting unexpected errors with a PortInUseException with the owner String set to "Unexpected Error" and detail information in the message field of the exception. In case any file system resource is related to the unexpected error, it must be mentioned first and separated by a " : " String such that clients can parse the actual file system resource out of the message automatically. I thought about subclassing PortInUseException to provide more error details and type-safe parsing of the affected resource but wasn't so sure about it in the end. What do others think about this proposal? Would it make more sense to throw a RuntimeException for unexpected errors, rather than a PortInUseException with the String "Unexpected Error" ? Do the proposed port locking policies make sense? Is the naming proper? I'll next work on a patch to implement the proposal (or any modification as discussed on this list). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080901/5d1811e0/attachment-0002.html From Steffen.DETTMER at ingenico.com Mon Sep 1 10:50:56 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 1 Sep 2008 18:50:56 +0200 Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> Message-ID: <20080901165055.GD17898@elberon.bln.de.ingenico.com> Hi, thanks for this nice list! * Oberhuber, Martin wrote on Mon, Sep 01, 2008 at 17:36 +0200: > 1. Neither the Sun nor the IBM implementation are really > useable in terms of port locking, since they do not > respect minicom. > 2. Sun's throwing a RuntimeException from > CommPortIdentifier.open() is undocumented and may break > client applications in an unexpected way. Yes, someone may expect a PortInUseException if the port is in use, but since RuntimeExceptions can be thrown always anyway, I think there is not much a client application can do than catching the `known expected' unexpected (unspecified by throws) exceptions. Client applications probably want to wrap CommPortIdentifier.open(), catching at least PortInUseException and/or RuntimeException and throwing a well-defined exception (that should also include the port name and/or other helpful detail for the user, such as why the access was tried etc) > 3. Kernel locks through fcntl are not sufficient for > minicom to keep it off the port. I think it could be sufficient if mandatory file locking is enabled (on systems that support it). Linux for instance in general should support mandatory file locking, but I don't know if it really works for device files. > 4. Kernel locks give no indication what application is > currently owning the port (lockfiles could give that > information but minicom does not evaluate it). > > Does anybody on this list know the difference between > fcntl(F_SETLK, {type=F_WRLCK}) > and > ioctl(fd, TIOCEXCL, 0); > ? maybe the first one could be considered more general (and modern :)), should work for all files and file systems and it is POSIX; the second one as some specific function of some serial/tty driver. I think on POSIX systems (whatever this means in practice), someone should be able to expect fcntl(F_SETLK, ...) to work, but no rule without an exception (sometimes, just exceptions without any rule ;)). ioctl TIOCEXCL prevents a second open (unless executed by root), but fcntl(F_SETLK) another F_SETLK (when advisory locking) or write (when mandatory locking). Some serial implementations do (or try) both. > What do folks think about throwing a RuntimeException from > CommPortIdentifier.open()? (I think it shows that those mandatory throws() clause and its exceptions were not the best ideas when defining the java language, sometimes workarounded by `throws Throwable' :)) I'd expect such an exception (only) in the fatal cases where an application usually cannot do anything reasonable, let's say some OutOfMemory (yes, this is an Error I know) or SecurityException. We had quite some issues with things like that (not rxtx related) and with applications catching RuntimeException (or even Throwable) on some high level sometimes resulting in strange effects, so I think it should be avoided, for instance, by wrapping calls to such methods, also needed to add more details about the region where the problem occured (often, higher layers know additional details more interesting for the user, for instance, why something was attempted, where it was configured or which subsystem tried it what for, ...). Unfortunality it is not always straightforward/possible to overwrite to get such a behavior. Actually, I think usually it is not that easy (either you cannot call a needed method because it is private or you cannot put your wrapper because the constructing class cannot be overwritten easily, ... etc). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From tjarvi at qbang.org Mon Sep 1 11:28:37 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 1 Sep 2008 11:28:37 -0600 (MDT) Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: <20080901165055.GD17898@elberon.bln.de.ingenico.com> References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> <20080901165055.GD17898@elberon.bln.de.ingenico.com> Message-ID: On Mon, 1 Sep 2008, Steffen DETTMER wrote: > >> 4. Kernel locks give no indication what application is >> currently owning the port (lockfiles could give that >> information but minicom does not evaluate it). >> >> Does anybody on this list know the difference between >> fcntl(F_SETLK, {type=F_WRLCK}) >> and >> ioctl(fd, TIOCEXCL, 0); >> ? > > maybe the first one could be considered more general (and modern > :)), should work for all files and file systems and it is POSIX; > the second one as some specific function of some serial/tty driver. > > I think on POSIX systems (whatever this means in practice), > someone should be able to expect fcntl(F_SETLK, ...) to work, but > no rule without an exception (sometimes, just exceptions without > any rule ;)). > > ioctl TIOCEXCL prevents a second open (unless executed by root), > but fcntl(F_SETLK) another F_SETLK (when advisory locking) or > write (when mandatory locking). Some serial implementations do > (or try) both. > I couldn't parse the last comment about F_SETLK. I guess you ment F_SETLK prevents other F_SETLK attempts (advisory) or writing (mandatory). Presumably that applies to all users. While F_SETLK is possibly something we can add, I just want to point out that the TIOCEXCL will work on all UNIX like systems and is very specific to our needs; it only applies to ttys. F_SETLK also appears to be used for other things like trying to lock portions of a file over networked filesystems. -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Mon Sep 1 11:33:53 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 1 Sep 2008 19:33:53 +0200 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> Message-ID: <20080901173353.GE17898@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Mon, Sep 01, 2008 at 18:05 +0200: > 2. Getting the settings into RXTX > > * Use Java System Properties for tuning behavior (since the RXTX / > javax.comm API is frozen): I think supporting -D system properties is a similar API change to add some new config-classes/method (except that system properties are better hidden :)). I'd like to add that spplications should be able to overwrite this (for instance, if they support config files or some GUI to configure it), here they could use setProperty. > * -Dgnu.io.rxtx.LockfileDir=/var/lock # specify location of > lockfile directory, similar to minicom > * -Dgnu.io.rxtx.LockPolicy=none # no port locking, no > warnings or anything > * -Dgnu.io.rxtx.LockPolicy=default # try lockfiles, in case of > missing permission fall back to kernel locks without warning > * -Dgnu.io.rxtx.LockPolicy=warn # try lockfiles, in case of > missing permission fall back to kernel locks with warning to stdout > * -Dgnu.io.rxtx.LockPolicy=strict # require lockfiles, throw > exception if they cannot be created. > > The "default" policy would try to be as good a citizen as possible > (create lockfiles if possible, create Kernel > exclusive lock if possible), but without guarantee and without warning > in case it fails creating any lock. Nice, I think the important things would be configurable then! so default is no one of `none', `warn' and `strict'? I think it could be confusing if `default' is an option that must explicitely given, maybe -Dgnu.io.rxtx.LockPolicy=automatic and making this the default (i.e. when it is given, actually nothing changes)? Well, just a minor detail. Another minor detail could be that here someone might think that two things are joined: first, what should happen if locking fails and second how to lock. Maybe it could be splitted. Additionally, somone could want to distinguish between `lock always' and `lock at use', but I'm not sure if the javax style API supports this. On a (non rxtx related but C++) implementation alternatively it was used to have a `Policy' (always, at use, none, default[here: depending on the device]) and a `Kind' (classes for UUCP-lockfile and kernel locks). So back to rxtx, maybe here an additional option like some -Dgnu.io.rxtx.LockKind = [file] [ioctl] [fcntl], maybe separated by "," or as ORed integer number, and LockPolicy=(none|any|all)? I'd dislike warnings to stdout (if so, stderr, but better logging, because it can be configured). stdout may not be avialable or used by some text mode UI or alike. For GUI-applications an english language message may not be sufficient but national language support may be required (I have no idea how to do this, just name it for the list). I think for logging (in contrast to stdout) in most cases english-only logs are acceptable. Anyway, this really are just minor things. Your proposal seems to support all important things and the naming is OK. > The warning to stdout would be something like "Warning: RXTX failed to > create a lockfile in /var/lock/LCK..ttyS0. Check file system permissions > or specify -Dgnu.io.rxtx.LockfileDir in order to enable proper locking > of serial ports against other applications". yes, nice! Maybe add the device port name that was tried to open (maybe it was something symbolic like `modem' or alike)? > 3. Error Reporting out of RXTX > > * All errors acquiring a port are reported by means of a > gnu.io.rxtx.PortInUseException on CommPortIdentifier#open(). Yes, I think better than RuntimeExceptions! > * In case of missing permissions or other unexpected failure > running through open(), the "currentOwner" field is filled with the > String "Unexpected Error", and the message field of the exception is > filled with a String like "/dev/ttyS0 : Permission denied in open()" or > "/var/lock/LCK..ttyS0 : Permission denied in write()" or maybe defining a subclass of PortInUseException? Then applications could (theoretically) catch the permission denied (lets say if someone wants to write a config GUI or application that autodetects if lock files can be used) > * In case of properly running through open() but not being able to > lock the port, the "currentOwner" field is populated with the name and > PID of the external process locking the port if it can be obtained, or > "Unknown Application" otherwise. > > In other words, I'm proposing to replace Sun's RuntimeException for > reporting unexpected errors with a PortInUseException with the owner > String set to "Unexpected Error" and detail information in the message > field of the exception. In case any file system resource is related to > the unexpected error, it must be mentioned first and separated by a " : > " String such that clients can parse the actual file system resource out > of the message automatically. (or adding a new method getLockPath() or so to PortInUseException) > I thought about subclassing PortInUseException to provide more error > details and type-safe parsing of the affected resource but wasn't so > sure about it in the end. Yes, intuitively I feel the same, like adding some String getPath() method to PortInUseException or a (new) subclass. In some unrelated thing we used exception message string contents parsing (was considered a hack from the beginning), some years later hit some problem in which made the error-detail-determination fail and replaced it completely by heaps of subclasses (BTW, the sources for the subclasses were automatically generated), that's why I'd use subclasses in case of doubt, but probably this has other disadvantages. Sometimes, the problem is that people later that use this API may not know any of those details and discussions, but if they see some special methods or subclasses in the javadoc or so, I think chances are higher that those situations are treated better, which may make users happier; also example programs / example code snippets can be helpful. > What do others think about this proposal? Would it make more > sense to throw a RuntimeException for unexpected errors, rather > than a PortInUseException with the String "Unexpected Error" ? I think, Exceptions should be used for unexpected conditions (excepted `exceptions' should be returned, e.g. by bool methods or alike). (unrelated here, but) Working with throw and catch IMHO is a kind of `goto' programming, actually even worse, and IMHO should not be used for the `good case' (such as searching a free port). Here, I think the throws() clause with PortInUseException simply is wrong. It should throw something more generic with PortInUseException beeing one subclass, but this would be an API change. For compatiblity, I could imagine a subclass of it. > Do the proposed port locking policies make sense? Is the naming > proper? Yes, for me it makes sense and is proper. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From Steffen.DETTMER at ingenico.com Mon Sep 1 11:50:48 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 1 Sep 2008 19:50:48 +0200 Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> <20080901165055.GD17898@elberon.bln.de.ingenico.com> Message-ID: <20080901175048.GF17898@elberon.bln.de.ingenico.com> * Trent Jarvi wrote on Mon, Sep 01, 2008 at 11:28 -0600: > >ioctl TIOCEXCL prevents a second open (unless executed by root), > >but fcntl(F_SETLK) another F_SETLK (when advisory locking) or > >write (when mandatory locking). > > I couldn't parse the last comment about F_SETLK. I guess you ment > F_SETLK prevents other F_SETLK attempts (advisory) or writing > (mandatory). Presumably that applies to all users. Yes, thanks for the clarification. > While F_SETLK is possibly something we can add, I just want to point > out that the TIOCEXCL will work on all UNIX like systems and is very > specific to our needs; it only applies to ttys. I guess F_SETLK could make sense if it would prevent minicom to work if mandatory locking is enabled, otherwise and if TIOCEXCL is working, F_SETLK probably doesn't make much sense, does it? Bad would be, I think, if on some system TIOCEXCL works, but F_SETLK fails (e.g. not supported or so) and in the end rxtx would throw some exception instead of opening the port, so adding it could require tests on exotic systems... oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From Martin.Oberhuber at windriver.com Mon Sep 1 08:59:20 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 1 Sep 2008 16:59:20 +0200 Subject: [Rxtx] [Suspected Spam][Blocked Sender]Re: Towards an RXTX release - CSR BT/USB chipset In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com><13557-75390@sneakemail.com><20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848074C4259@ism-mail03.corp.ad.wrs.com> Hi Bruce, I think that the only way to avoid temparary disconnect during port scanning, is to avoid the temporary open() during port scanning. That, however, can only be avoided if there is some external means to enumerate the candidates for valid port names. The javax.comm implementations by Sun and IBM use a file named "javax.comm.properties" for this. On Linux and Solaris, it enumerates the allowed prefixes for device names to be used. Those prefixes known, the library treats all existing files with such prefixes as valid ports, without trying to actually open them. See http://java.sun.com/products/javacomm/ I'd think that one option to simplify the port scanning would be to use a Java System Property to specify the Policy for port scanning. For instance: -Dgnu.io.rxtx.PortScanningPolicy=read # try to open & read scanned ports -Dgnu.io.rxtx.PortScanningPolicy=existing # treat ports as valid if they exist For enumerating the candidates to check, the "gnu.io.rxtx.properties" file already exists as well as the "gnu.io.rxtx.SerialPorts" and "gnu.io.rxtx.ParallelPorts" System Properties. These support explicit enumeration of port candidates. So, a second possible enhancement in addition to support specifying the PortScanningPolicy could be to support specifying prefix names for port enumeration rather than just explicit enumeration. What do others think about these ideas? Could these improve the long-standing performance issues with USB / Bluetooth adapters during port scanning? Why does RXTX try to open scanned ports in the first place, rather than relying on plain existence of the devices? I'd guess that a Patch providing these enhancements would be appreciated by the RXTX community. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Bruce Boyes Sent: Tuesday, August 05, 2008 3:13 AM To: Rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender]Re: [Rxtx] Towards an RXTX release - CSR BT/USB chipset At 18:37 07/29/2008, you wrote: All, Is there any chance that the next official release could improve on the port scanning (getPortIdentifiers)? It would be nice if rxtx could also not cause a connect/disconnect and subsequent problems with a USB Bluetooth BlueSoleil adapter (using the CSR chipset), as documented in a previous email from me. best regards Bruce ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080901/f3cb9a8e/attachment-0003.html From Martin.Oberhuber at windriver.com Mon Sep 1 09:36:31 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 1 Sep 2008 17:36:31 +0200 Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> Hi all, I made some experiments with the Sun and IBM implementations of javax.comm (on Linux and Solaris), in order to understand how these treat port locking and lockfiles and in what way they report failure to obtain a port to the client. Here are the results: * Neither Sun nor IBM check or create any lockfiles. As a result, minicom can open the same serial port as my test java application without error. * Sun uses Kernel locking with fcntl, according to an strace (truss) that I had run with my test app: open("/dev/ttyS1", O_RDWR|O_NONBLOCK|O_EXCL) = 5 fcntl64(5, F_SETLK, {type=F_WRLCK, ...}) = 0 As a result, multiple instances of the same Java test program are protected against each other; minicom, however, is *not* protected since it does open("/dev/ttyS1", O_RDWR|O_NONBLOCK) on Linux RHEL 4 at least. * IBM seems to use some memory sharing between multiple instances of Java programs: CommPortOwnershipListener is called even if a different instance of the program tries to access the port. No port locking of any kind seems to be done though. As a result, IBM apps are protected against each other but not against minicom. * When opening a port fails due to missing permissions on the device file, or due to an exclusive lock owned by another instance of itself, - IBM throws a PortInUseException after the timeout (currentOwner="Unknown Application") - Sun throws a java.lang.RuntimeException immediately (message=one of the following two: "\n Error opening \"/dev/ttyS1\"\n Permission denied" "\n Error opening \"/dev/cua/a\"\n Error in lockf()" What I learn from this is that 1. Neither the Sun nor the IBM implementation are really useable in terms of port locking, since they do not respect minicom. 2. Sun's throwing a RuntimeException from CommPortIdentifier.open() is undocumented and may break client applications in an unexpected way. 3. Kernel locks through fcntl are not sufficient for minicom to keep it off the port. 4. Kernel locks give no indication what application is currently owning the port (lockfiles could give that information but minicom does not evaluate it). Does anybody on this list know the difference between fcntl(F_SETLK, {type=F_WRLCK}) and ioctl(fd, TIOCEXCL, 0); ? What do folks think about throwing a RuntimeException from CommPortIdentifier.open() ? I'll follow up with a separate E-Mail proposing a strategy for RXTX to handle port locking. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, July 30, 2008 4:16 AM > To: Oberhuber, Martin > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Port locking on Linux: Redhat lockdev-baudboy > Instead, I would suggest we do an exclusive open and try to > lock as is if > lockfiles are not disabled. Warn if the lock fails. Always respect > lockfiles prior to opening. > > Exclusive opens should work on linux, mac, sol, bsd, ... > > The code is simple and does not introduce any new dependencies. > > ... > open > ... > do { > res = ioctl(fd, TIOCEXCL, 0); > } while ( (errno == EINTR || errno == EAGAIN ) && res != 0 ); > > > if( res != 0 ) > fail > > > In the worst case, minicom or another application may not be > able to find a lockfile but their open will fail. We locked > the port. Other applications may not do this so we should > always respect lockfiles. > > -- > Trent Jarvi > tjarvi at qbang.org > From Martin.Oberhuber at windriver.com Mon Sep 1 10:05:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 1 Sep 2008 18:05:02 +0200 Subject: [Rxtx] RXTX Port Locking Improvements Message-ID: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> Hi all, here is my proposal for improving port locking in RXTX. 1. Goals of the Proposal * Support enabling / disabling / configuring port locking at runtime without re-compiling RXTX. * Support port locking by Kernel call even if permissions for lockfiles are not sufficient. * Report exact reason for failure to acquire a port to the client application (including the file system path of a lockfile for instance). 2. Getting the settings into RXTX * Use Java System Properties for tuning behavior (since the RXTX / javax.comm API is frozen): * -Dgnu.io.rxtx.LockfileDir=/var/lock # specify location of lockfile directory, similar to minicom * -Dgnu.io.rxtx.LockPolicy=none # no port locking, no warnings or anything * -Dgnu.io.rxtx.LockPolicy=default # try lockfiles, in case of missing permission fall back to kernel locks without warning * -Dgnu.io.rxtx.LockPolicy=warn # try lockfiles, in case of missing permission fall back to kernel locks with warning to stdout * -Dgnu.io.rxtx.LockPolicy=strict # require lockfiles, throw exception if they cannot be created. The "default" policy would try to be as good a citizen as possible (create lockfiles if possible, create Kernel exclusive lock if possible), but without guarantee and without warning in case it fails creating any lock. The warning to stdout would be something like "Warning: RXTX failed to create a lockfile in /var/lock/LCK..ttyS0. Check file system permissions or specify -Dgnu.io.rxtx.LockfileDir in order to enable proper locking of serial ports against other applications". 3. Error Reporting out of RXTX * All errors acquiring a port are reported by means of a gnu.io.rxtx.PortInUseException on CommPortIdentifier#open(). * In case of missing permissions or other unexpected failure running through open(), the "currentOwner" field is filled with the String "Unexpected Error", and the message field of the exception is filled with a String like "/dev/ttyS0 : Permission denied in open()" or "/var/lock/LCK..ttyS0 : Permission denied in write()" * In case of properly running through open() but not being able to lock the port, the "currentOwner" field is populated with the name and PID of the external process locking the port if it can be obtained, or "Unknown Application" otherwise. In other words, I'm proposing to replace Sun's RuntimeException for reporting unexpected errors with a PortInUseException with the owner String set to "Unexpected Error" and detail information in the message field of the exception. In case any file system resource is related to the unexpected error, it must be mentioned first and separated by a " : " String such that clients can parse the actual file system resource out of the message automatically. I thought about subclassing PortInUseException to provide more error details and type-safe parsing of the affected resource but wasn't so sure about it in the end. What do others think about this proposal? Would it make more sense to throw a RuntimeException for unexpected errors, rather than a PortInUseException with the String "Unexpected Error" ? Do the proposed port locking policies make sense? Is the naming proper? I'll next work on a patch to implement the proposal (or any modification as discussed on this list). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080901/5d1811e0/attachment-0003.html From Steffen.DETTMER at ingenico.com Mon Sep 1 10:50:56 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 1 Sep 2008 18:50:56 +0200 Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> Message-ID: <20080901165055.GD17898@elberon.bln.de.ingenico.com> Hi, thanks for this nice list! * Oberhuber, Martin wrote on Mon, Sep 01, 2008 at 17:36 +0200: > 1. Neither the Sun nor the IBM implementation are really > useable in terms of port locking, since they do not > respect minicom. > 2. Sun's throwing a RuntimeException from > CommPortIdentifier.open() is undocumented and may break > client applications in an unexpected way. Yes, someone may expect a PortInUseException if the port is in use, but since RuntimeExceptions can be thrown always anyway, I think there is not much a client application can do than catching the `known expected' unexpected (unspecified by throws) exceptions. Client applications probably want to wrap CommPortIdentifier.open(), catching at least PortInUseException and/or RuntimeException and throwing a well-defined exception (that should also include the port name and/or other helpful detail for the user, such as why the access was tried etc) > 3. Kernel locks through fcntl are not sufficient for > minicom to keep it off the port. I think it could be sufficient if mandatory file locking is enabled (on systems that support it). Linux for instance in general should support mandatory file locking, but I don't know if it really works for device files. > 4. Kernel locks give no indication what application is > currently owning the port (lockfiles could give that > information but minicom does not evaluate it). > > Does anybody on this list know the difference between > fcntl(F_SETLK, {type=F_WRLCK}) > and > ioctl(fd, TIOCEXCL, 0); > ? maybe the first one could be considered more general (and modern :)), should work for all files and file systems and it is POSIX; the second one as some specific function of some serial/tty driver. I think on POSIX systems (whatever this means in practice), someone should be able to expect fcntl(F_SETLK, ...) to work, but no rule without an exception (sometimes, just exceptions without any rule ;)). ioctl TIOCEXCL prevents a second open (unless executed by root), but fcntl(F_SETLK) another F_SETLK (when advisory locking) or write (when mandatory locking). Some serial implementations do (or try) both. > What do folks think about throwing a RuntimeException from > CommPortIdentifier.open()? (I think it shows that those mandatory throws() clause and its exceptions were not the best ideas when defining the java language, sometimes workarounded by `throws Throwable' :)) I'd expect such an exception (only) in the fatal cases where an application usually cannot do anything reasonable, let's say some OutOfMemory (yes, this is an Error I know) or SecurityException. We had quite some issues with things like that (not rxtx related) and with applications catching RuntimeException (or even Throwable) on some high level sometimes resulting in strange effects, so I think it should be avoided, for instance, by wrapping calls to such methods, also needed to add more details about the region where the problem occured (often, higher layers know additional details more interesting for the user, for instance, why something was attempted, where it was configured or which subsystem tried it what for, ...). Unfortunality it is not always straightforward/possible to overwrite to get such a behavior. Actually, I think usually it is not that easy (either you cannot call a needed method because it is private or you cannot put your wrapper because the constructing class cannot be overwritten easily, ... etc). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From tjarvi at qbang.org Mon Sep 1 11:28:37 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 1 Sep 2008 11:28:37 -0600 (MDT) Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: <20080901165055.GD17898@elberon.bln.de.ingenico.com> References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> <20080901165055.GD17898@elberon.bln.de.ingenico.com> Message-ID: On Mon, 1 Sep 2008, Steffen DETTMER wrote: > >> 4. Kernel locks give no indication what application is >> currently owning the port (lockfiles could give that >> information but minicom does not evaluate it). >> >> Does anybody on this list know the difference between >> fcntl(F_SETLK, {type=F_WRLCK}) >> and >> ioctl(fd, TIOCEXCL, 0); >> ? > > maybe the first one could be considered more general (and modern > :)), should work for all files and file systems and it is POSIX; > the second one as some specific function of some serial/tty driver. > > I think on POSIX systems (whatever this means in practice), > someone should be able to expect fcntl(F_SETLK, ...) to work, but > no rule without an exception (sometimes, just exceptions without > any rule ;)). > > ioctl TIOCEXCL prevents a second open (unless executed by root), > but fcntl(F_SETLK) another F_SETLK (when advisory locking) or > write (when mandatory locking). Some serial implementations do > (or try) both. > I couldn't parse the last comment about F_SETLK. I guess you ment F_SETLK prevents other F_SETLK attempts (advisory) or writing (mandatory). Presumably that applies to all users. While F_SETLK is possibly something we can add, I just want to point out that the TIOCEXCL will work on all UNIX like systems and is very specific to our needs; it only applies to ttys. F_SETLK also appears to be used for other things like trying to lock portions of a file over networked filesystems. -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Mon Sep 1 11:33:53 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 1 Sep 2008 19:33:53 +0200 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> Message-ID: <20080901173353.GE17898@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Mon, Sep 01, 2008 at 18:05 +0200: > 2. Getting the settings into RXTX > > * Use Java System Properties for tuning behavior (since the RXTX / > javax.comm API is frozen): I think supporting -D system properties is a similar API change to add some new config-classes/method (except that system properties are better hidden :)). I'd like to add that spplications should be able to overwrite this (for instance, if they support config files or some GUI to configure it), here they could use setProperty. > * -Dgnu.io.rxtx.LockfileDir=/var/lock # specify location of > lockfile directory, similar to minicom > * -Dgnu.io.rxtx.LockPolicy=none # no port locking, no > warnings or anything > * -Dgnu.io.rxtx.LockPolicy=default # try lockfiles, in case of > missing permission fall back to kernel locks without warning > * -Dgnu.io.rxtx.LockPolicy=warn # try lockfiles, in case of > missing permission fall back to kernel locks with warning to stdout > * -Dgnu.io.rxtx.LockPolicy=strict # require lockfiles, throw > exception if they cannot be created. > > The "default" policy would try to be as good a citizen as possible > (create lockfiles if possible, create Kernel > exclusive lock if possible), but without guarantee and without warning > in case it fails creating any lock. Nice, I think the important things would be configurable then! so default is no one of `none', `warn' and `strict'? I think it could be confusing if `default' is an option that must explicitely given, maybe -Dgnu.io.rxtx.LockPolicy=automatic and making this the default (i.e. when it is given, actually nothing changes)? Well, just a minor detail. Another minor detail could be that here someone might think that two things are joined: first, what should happen if locking fails and second how to lock. Maybe it could be splitted. Additionally, somone could want to distinguish between `lock always' and `lock at use', but I'm not sure if the javax style API supports this. On a (non rxtx related but C++) implementation alternatively it was used to have a `Policy' (always, at use, none, default[here: depending on the device]) and a `Kind' (classes for UUCP-lockfile and kernel locks). So back to rxtx, maybe here an additional option like some -Dgnu.io.rxtx.LockKind = [file] [ioctl] [fcntl], maybe separated by "," or as ORed integer number, and LockPolicy=(none|any|all)? I'd dislike warnings to stdout (if so, stderr, but better logging, because it can be configured). stdout may not be avialable or used by some text mode UI or alike. For GUI-applications an english language message may not be sufficient but national language support may be required (I have no idea how to do this, just name it for the list). I think for logging (in contrast to stdout) in most cases english-only logs are acceptable. Anyway, this really are just minor things. Your proposal seems to support all important things and the naming is OK. > The warning to stdout would be something like "Warning: RXTX failed to > create a lockfile in /var/lock/LCK..ttyS0. Check file system permissions > or specify -Dgnu.io.rxtx.LockfileDir in order to enable proper locking > of serial ports against other applications". yes, nice! Maybe add the device port name that was tried to open (maybe it was something symbolic like `modem' or alike)? > 3. Error Reporting out of RXTX > > * All errors acquiring a port are reported by means of a > gnu.io.rxtx.PortInUseException on CommPortIdentifier#open(). Yes, I think better than RuntimeExceptions! > * In case of missing permissions or other unexpected failure > running through open(), the "currentOwner" field is filled with the > String "Unexpected Error", and the message field of the exception is > filled with a String like "/dev/ttyS0 : Permission denied in open()" or > "/var/lock/LCK..ttyS0 : Permission denied in write()" or maybe defining a subclass of PortInUseException? Then applications could (theoretically) catch the permission denied (lets say if someone wants to write a config GUI or application that autodetects if lock files can be used) > * In case of properly running through open() but not being able to > lock the port, the "currentOwner" field is populated with the name and > PID of the external process locking the port if it can be obtained, or > "Unknown Application" otherwise. > > In other words, I'm proposing to replace Sun's RuntimeException for > reporting unexpected errors with a PortInUseException with the owner > String set to "Unexpected Error" and detail information in the message > field of the exception. In case any file system resource is related to > the unexpected error, it must be mentioned first and separated by a " : > " String such that clients can parse the actual file system resource out > of the message automatically. (or adding a new method getLockPath() or so to PortInUseException) > I thought about subclassing PortInUseException to provide more error > details and type-safe parsing of the affected resource but wasn't so > sure about it in the end. Yes, intuitively I feel the same, like adding some String getPath() method to PortInUseException or a (new) subclass. In some unrelated thing we used exception message string contents parsing (was considered a hack from the beginning), some years later hit some problem in which made the error-detail-determination fail and replaced it completely by heaps of subclasses (BTW, the sources for the subclasses were automatically generated), that's why I'd use subclasses in case of doubt, but probably this has other disadvantages. Sometimes, the problem is that people later that use this API may not know any of those details and discussions, but if they see some special methods or subclasses in the javadoc or so, I think chances are higher that those situations are treated better, which may make users happier; also example programs / example code snippets can be helpful. > What do others think about this proposal? Would it make more > sense to throw a RuntimeException for unexpected errors, rather > than a PortInUseException with the String "Unexpected Error" ? I think, Exceptions should be used for unexpected conditions (excepted `exceptions' should be returned, e.g. by bool methods or alike). (unrelated here, but) Working with throw and catch IMHO is a kind of `goto' programming, actually even worse, and IMHO should not be used for the `good case' (such as searching a free port). Here, I think the throws() clause with PortInUseException simply is wrong. It should throw something more generic with PortInUseException beeing one subclass, but this would be an API change. For compatiblity, I could imagine a subclass of it. > Do the proposed port locking policies make sense? Is the naming > proper? Yes, for me it makes sense and is proper. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From Steffen.DETTMER at ingenico.com Mon Sep 1 11:50:48 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 1 Sep 2008 19:50:48 +0200 Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> <20080901165055.GD17898@elberon.bln.de.ingenico.com> Message-ID: <20080901175048.GF17898@elberon.bln.de.ingenico.com> * Trent Jarvi wrote on Mon, Sep 01, 2008 at 11:28 -0600: > >ioctl TIOCEXCL prevents a second open (unless executed by root), > >but fcntl(F_SETLK) another F_SETLK (when advisory locking) or > >write (when mandatory locking). > > I couldn't parse the last comment about F_SETLK. I guess you ment > F_SETLK prevents other F_SETLK attempts (advisory) or writing > (mandatory). Presumably that applies to all users. Yes, thanks for the clarification. > While F_SETLK is possibly something we can add, I just want to point > out that the TIOCEXCL will work on all UNIX like systems and is very > specific to our needs; it only applies to ttys. I guess F_SETLK could make sense if it would prevent minicom to work if mandatory locking is enabled, otherwise and if TIOCEXCL is working, F_SETLK probably doesn't make much sense, does it? Bad would be, I think, if on some system TIOCEXCL works, but F_SETLK fails (e.g. not supported or so) and in the end rxtx would throw some exception instead of opening the port, so adding it could require tests on exotic systems... oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From Martin.Oberhuber at windriver.com Wed Sep 3 11:33:54 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 3 Sep 2008 19:33:54 +0200 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <20080901173353.GE17898@elberon.bln.de.ingenico.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Hello Steffen, some comments: > I think supporting -D system properties is a similar API change > to add some new config-classes/method (except that system > properties are better hidden :)). Well the point is that if System Properties are set but not understood by a different runtime implementation, it doesn't hurt and you can still link against / run the program. Creating new config-classes creates a compile-time API change such that you cannot easily port the program to other API implementations any more. In my opinion, it is still important that programs which use RXTX can be ported to the Sun javax.comm APIs easily (that is, just by doing a String replace of sed -e 's,gnu\.io\.,javax.comm,g' on all files. Creating new classes or interfaces makes that impossible. What do others on this list think? Is this still important, or can we fork off javax.comm since that's not really maintained any more anyways? Note that especially on embedded devices (J2ME), many vendors provide native javax.comm implementations, so porting an RXTX based program onto such a J2ME vm is much easier if we restrict ourselves to the original API. > I'd like to add that spplications should be able to overwrite > this Well, they can always System.setProperty("gnu.io.rxtx.LockfileDir", "/foo/bar"); or similar. We're doing that in our commercial app in order to add ports which RXTX doesn't discover automatically. > so default is no one of `none', `warn' and `strict'? I think it We can discuss what the default should be, it can be any of the other options of course. I had proposed "default" to be the default :-) I usually like the default to be that it "just works without fuss" :-) > Another minor detail could be that here someone might think that > two things are joined: first, what should happen if locking fails > and second how to lock. Maybe it could be splitted. It could probably be splitted. But I didn't want to expose too many implementation details to the outside, nor make the interface (configuration) too complex. Note that different locking mechanisms could be available on different OS's; the user won't care about the mechanisms but what to do in case one of them fails (fallback to others with or without warning, or fail). So far, we've been clear that the right thing to do is (1) observe and create lockfiles for legacy clients, and then (2) do the right thing which is the Kernel Lock. I don't see a need for more configuration at this point. If we should see a necessity for more fine-grained configuration we can add that in the future. > Policy differentiate between `lock always' and `lock at use' We lock when the client opens the port, javax.comm does not provide an API for locking even without opening the port if that's what you mean, so this doesn't seem an option. > some -Dgnu.io.rxtx.LockKind = [file] [ioctl] [fcntl] I see no sense in trying some locks only. Applications should try to acquire every lock they are aware of, no? Note that we don't know what other apps are installed, so we need to use all mechansims we can. On a Platform where some mechanism is not available, it will be removed at compile-time anyways (configure script). If it's available at compile-time it should be used at runtime. > I'd dislike warnings to stdout (if so, stderr, but better > logging, because it can be configured). stdout may not be > avialable or used by some text mode UI or alike. I know, that's why I wouldn't make that option the default. And yes, of course we'd log to stderr and not stdout. > For GUI-applications an english language message may not be > sufficient but national language support may be required RXTX is low-level. Translation is up to the higher level client app. What I take from that is, that the client app should be able to receive exactly the same warnings that would otherwise go to stdout. My current proposal doesn't account for that... but actually, RXTX's Zystem class provides for configurable logging through the "gnu.io.log.mode" System Property. I'm just not exactly sure how Zystem is to be used, but it should work somehow... Trent, any help > yes, nice! Maybe add the device port name that was tried to open > (maybe it was something symbolic like `modem' or alike)? Hm... that might indeed help in some cases. Thanks for the hint. > or maybe defining a subclass of PortInUseException? > (or adding a new method getLockPath() or so to PortInUseException) Again, that's not possible if we want to be source compatible with javax.comm -- but I'm in favor of this proposal if the Community thinks that this is not so important any more? Thanks, Martin From johnny.luong at trustcommerce.com Wed Sep 3 12:54:17 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Wed, 03 Sep 2008 11:54:17 -0700 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: <48BEDD59.5000908@trustcommerce.com> Oberhuber, Martin wrote: > Creating new config-classes creates a compile-time API change > such that you cannot easily port the program to other API > implementations any more. > > In my opinion, it is still important that programs which use > RXTX can be ported to the Sun javax.comm APIs easily (that is, > just by doing a String replace of > sed -e 's,gnu\.io\.,javax.comm,g' > on all files. Creating new classes or interfaces makes that > impossible. > > What do others on this list think? Is this still important, > or can we fork off javax.comm since that's not really maintained > any more anyways? > > Note that especially on embedded devices (J2ME), many vendors > provide native javax.comm implementations, so porting an RXTX > based program onto such a J2ME vm is much easier if we restrict > ourselves to the original API. Hi, I think it wouldn't be difficult for a person to create a separate facade of the javax.comm interface which talks to the RXTX library and perhaps if someone is willing to share that, then it can be improved on. If someone needs the older interface now, there are alternatives, e.g: RXTX 2.0, Sun javax.comm, serialio.com, etc. I only use the gnu.io namespace anyways with respect to RXTX and perhaps if there is a strong enough interest, someone with the resources/time could go through the JSR/JCP as there are probably some level of variation on the J2ME implementations of the API. Best, Johnny From Steffen.DETTMER at ingenico.com Thu Sep 4 02:42:15 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 4 Sep 2008 10:42:15 +0200 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: <20080904084215.GF30569@elberon.bln.de.ingenico.com> Hi! please let me repeat that I wrote about minor details only. I'm afraid that too much discussion about the minor, unimportant details could take focus from the important points. I just can't resist :-) Summary of my long OT below is that for me your proposal is OK, except that applications should parse error or warning messages e.g. for translation (if I understood correctly). * Oberhuber, Martin wrote on Wed, Sep 03, 2008 at 19:33 +0200: > > I think supporting -D system properties is a similar API change > > to add some new config-classes/method (except that system > > properties are better hidden :)). > > Well the point is that if System Properties are set but not > understood by a different runtime implementation, it doesn't > hurt and you can still link against / run the program. In Java, I think adding new classes is not problem also. Now I'm not really sure, but I think adding new methods also does work. So I think in the end similar to adding support for new -D options old implementations simply don't use it. (but I'm not against -D, I wrote by comment just BTW) > Creating new config-classes creates a compile-time API change > such that you cannot easily port the program to other API > implementations any more. > > In my opinion, it is still important that programs which use > RXTX can be ported to the Sun javax.comm APIs easily (that is, > just by doing a String replace of > sed -e 's,gnu\.io\.,javax.comm,g' > on all files. Creating new classes or interfaces makes that > impossible. Do you really consider source code modifying with sed or some other kind of preprocessing be a common use? I don't think that such techniques are used by many Java developers. Also, in this case of course your changed implementation will compile, but it would fail at runtime, because no locking is available, so you would need to implement it around (which BTW IMHO isn't a bad idea anyway), having something on top that adds locking support and stuff. I mean, if locking support is considered that important that the application cares about it, let's say by offering a GUI and internally calling setProperty, the ported version needs to implement all this on its own, simply because otherwise all those functions would have no effect. But if another application does not care much about locking and uses the defaults only (i.e. is not using -D options), then it would work in both cases. just BTW #2: If support for some javax.comm is needed, I think wrappers/adapters are needed anyway: you could have one implementation for javax.comm, a second for gnu.io and a third for thirdparty something I/O. Well, since I consider those Java APIs beeing weak and uncomfortable, I think adapters on top of it is needed anyway, for instance, supporting timeouts. Not only in some `global timeout that throws an exception if reached' or so, but something reasonable, powerfull that can be used to implement serial protocols, for instance. So in summary, I think the API should support something that makes all those usages /possible/, like let's say an operating system, but it is /not/ a generic communication library which abstracts from communications, physical and logical links and APIs. > Note that especially on embedded devices (J2ME), many vendors > provide native javax.comm implementations, so porting an RXTX > based program onto such a J2ME vm is much easier if we restrict > ourselves to the original API. I would expect those APIs to behave different in detail, especially at timeouts, that a 1:1 port wouldn't be possible anyway (at least that are my limited experiences with embedded C libs). > > I'd like to add that spplications should be able to overwrite > > this > > Well, they can always System.setProperty("gnu.io.rxtx.LockfileDir", > "/foo/bar"); or similar. We're doing that in our commercial > app in order to add ports which RXTX doesn't discover automatically. Yes, but this only would LOOK as if it would work on let's say the embeeded port, but in fact it would do nothing (which in this example probably would be OK). The only think I dislike here is that you will not get a compiler error, so a colleguage who ports such software probably would miss if the application to be ported requires/supports a lockfile directory. > > so default is no one of `none', `warn' and `strict'? I think it > > We can discuss what the default should be, it can be any of the > other options of course. I had proposed "default" to be the > default :-) I usually like the default to be that it "just works > without fuss" :-) What I meant was that the default should also have some meaningful name. I think specifying `myoption=default' makes no sense, either it should not be given at all or it should be `myoption=concretevalue1' which could be the same as if not given at all, but has at least some documentary purposes and keeps working even if defaults are changes, and finnally thus the default option IMHO also should have a speaking name - but this also is just a minor detail. > > Another minor detail could be that here someone might think that > > two things are joined: first, what should happen if locking fails > > and second how to lock. Maybe it could be splitted. > > It could probably be splitted. But I didn't want to expose too many > implementation details to the outside, nor make the interface > (configuration) too complex. Yes, this is a good point. As the discussion here shows that it is complex library users would probably just get confused and set options wrongly. However, for specific applications specific things may be needed. In this cases according to your proposal it can be configured to use `none' and the specific application can implement whatever locking. So your proposal is fine! > Note that different locking mechanisms could be available on > different OS's; the user won't care about the mechanisms but > what to do in case one of them fails (fallback to others with > or without warning, or fail). Yes, but also has influence on the defaults, doesn't it? I think on windows noone expect some UUCP style lock files, right? Defaults of course must work on all major systems. > So far, we've been clear that the right thing to do is (1) observe > and create lockfiles for legacy clients, and then (2) do the right > thing which is the Kernel Lock. > I don't see a need for more configuration at this point. If we > should see a necessity for more fine-grained configuration we > can add that in the future. (kernel lock means TIOCEXCL, right?) would the file locking stuff be implemented in java in an overwriteable way? Anyway, as long as it can be disabled its ok. I think for applications that rely on that, for instance servers searching a free modem at some multiport card or alike, some special implementation probably is needed anyway. Yes, I think you are right, it should be kept simple. > > Policy differentiate between `lock always' and `lock at use' > > We lock when the client opens the port, javax.comm does not provide > an API for locking even without opening the port if that's what you > mean, so this doesn't seem an option. > > > some -Dgnu.io.rxtx.LockKind = [file] [ioctl] [fcntl] > > I see no sense in trying some locks only. Applications should try > to acquire every lock they are aware of, no? Note that we don't > know what other apps are installed, so we need to use all mechansims > we can. On a Platform where some mechanism is not available, it > will be removed at compile-time anyways (configure script). If it's > available at compile-time it should be used at runtime. Yes, but if a lock fails, how to know if it fails because the OS does not supports it or permissions are insufficient - or the port really is busy? Ignoring whether a lock could made probably makes not much sense, but aborting could lead to unsable rxtx (maybe on `broken' OSes only). But you are right, since it can be disabled, applications can implement around it what they need. > > For GUI-applications an english language message may not be > > sufficient but national language support may be required > > RXTX is low-level. > Translation is up to the higher level client > app. What I take from that is, that the client app should be > able to receive exactly the same warnings that would otherwise > go to stdout. to allow to parse the string? but what if the message is changed in the next version of rxtx? I found such constructions in some functions (unrelated to rxtx) and I had to search them because they didn't work, so I think parsing informal messages isn't a good idea, usually. > > or maybe defining a subclass of PortInUseException? > > (or adding a new method getLockPath() or so to PortInUseException) > > Again, that's not possible if we want to be source compatible > with javax.comm -- but I'm in favor of this proposal if the > Community thinks that this is not so important any more? OK. (ok, if you consider similar names in different java packages as compatible as you explained below with sed, yes, I see your point) just BTW again: I would not rely that no javax.comm.something implementation defines reasonable exceptions. I know that for some reason it is common in the Java world not to define too many reasonable exceptions, maybe because it is slow or writing all those .java files is too annoying and source code generation not known to many developers, don't know, but the APIs do not necessarily tell if additional classes are used for the implementation (and thus IMHO do not forbid to do so). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From petr.czekaj at vaecontrols.cz Thu Sep 4 07:07:11 2008 From: petr.czekaj at vaecontrols.cz (Petr Czekaj) Date: Thu, 4 Sep 2008 15:07:11 +0200 Subject: [Rxtx] Undisplay "Stable library" Message-ID: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> Hi, is there a way to use RXTX library without writing text: "Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7" into console window just after calling "getPortIdentifiers()" method? Thank you Peter -------------------------------------------- VAE Controls - mailto:info at vaecontrols.cz tel. +420 596 240 011 ; fax. +420 596 242 153 Tato zprava a pripadne prilohy jsou duverne a jsou vyhradne urceny pro pouziti adresata. Jestlize jste ji obdrzeli omylem, ozvete se prosim na vyse uvedenou adresu. Vsechny nazory a myslenky jsou vyhradne odesilatele a nemusi nutne prezentovat stanovisko VAE Controls s.r.o. VAE Controls si rezervuje veskera prava na monitoring elektronicke posty, prochazejici z/do vlastni firemni site. Tato zprava byla zkontrolovana antivirovym programem, nicmene firma VAE Controls neni zodpovedna za pripadne skody zpusobene prijmem nedetekovanych viru. CONFIDENTIALITY NOTICE: The information in this e-mail, including any attachment, is confidential and may be legally privileged. This e-mail is intended solely for the addressee. If you are not the addressee, dissemination, copying or other use of this e-mail or any of its content is strictly prohibited and may be unlawful. If you are not the intended recipient please inform the sender immediately and destroy the e-mail and any copies. E-mails and unencrypted attachments are scanned for all known viruses. Always scan e-mail attachments for viruses before opening them. All liability for viruses is excluded to the fullest extent permitted by law. Any views expressed in this message are those of the individual sender. -------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080904/10087013/attachment.html From Martin.Oberhuber at windriver.com Mon Sep 1 08:59:20 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 1 Sep 2008 16:59:20 +0200 Subject: [Rxtx] [Suspected Spam][Blocked Sender]Re: Towards an RXTX release - CSR BT/USB chipset In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com><13557-75390@sneakemail.com><20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848074C4259@ism-mail03.corp.ad.wrs.com> Hi Bruce, I think that the only way to avoid temparary disconnect during port scanning, is to avoid the temporary open() during port scanning. That, however, can only be avoided if there is some external means to enumerate the candidates for valid port names. The javax.comm implementations by Sun and IBM use a file named "javax.comm.properties" for this. On Linux and Solaris, it enumerates the allowed prefixes for device names to be used. Those prefixes known, the library treats all existing files with such prefixes as valid ports, without trying to actually open them. See http://java.sun.com/products/javacomm/ I'd think that one option to simplify the port scanning would be to use a Java System Property to specify the Policy for port scanning. For instance: -Dgnu.io.rxtx.PortScanningPolicy=read # try to open & read scanned ports -Dgnu.io.rxtx.PortScanningPolicy=existing # treat ports as valid if they exist For enumerating the candidates to check, the "gnu.io.rxtx.properties" file already exists as well as the "gnu.io.rxtx.SerialPorts" and "gnu.io.rxtx.ParallelPorts" System Properties. These support explicit enumeration of port candidates. So, a second possible enhancement in addition to support specifying the PortScanningPolicy could be to support specifying prefix names for port enumeration rather than just explicit enumeration. What do others think about these ideas? Could these improve the long-standing performance issues with USB / Bluetooth adapters during port scanning? Why does RXTX try to open scanned ports in the first place, rather than relying on plain existence of the devices? I'd guess that a Patch providing these enhancements would be appreciated by the RXTX community. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Bruce Boyes Sent: Tuesday, August 05, 2008 3:13 AM To: Rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender]Re: [Rxtx] Towards an RXTX release - CSR BT/USB chipset At 18:37 07/29/2008, you wrote: All, Is there any chance that the next official release could improve on the port scanning (getPortIdentifiers)? It would be nice if rxtx could also not cause a connect/disconnect and subsequent problems with a USB Bluetooth BlueSoleil adapter (using the CSR chipset), as documented in a previous email from me. best regards Bruce ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080901/f3cb9a8e/attachment-0004.html From Martin.Oberhuber at windriver.com Mon Sep 1 09:36:31 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 1 Sep 2008 17:36:31 +0200 Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> Hi all, I made some experiments with the Sun and IBM implementations of javax.comm (on Linux and Solaris), in order to understand how these treat port locking and lockfiles and in what way they report failure to obtain a port to the client. Here are the results: * Neither Sun nor IBM check or create any lockfiles. As a result, minicom can open the same serial port as my test java application without error. * Sun uses Kernel locking with fcntl, according to an strace (truss) that I had run with my test app: open("/dev/ttyS1", O_RDWR|O_NONBLOCK|O_EXCL) = 5 fcntl64(5, F_SETLK, {type=F_WRLCK, ...}) = 0 As a result, multiple instances of the same Java test program are protected against each other; minicom, however, is *not* protected since it does open("/dev/ttyS1", O_RDWR|O_NONBLOCK) on Linux RHEL 4 at least. * IBM seems to use some memory sharing between multiple instances of Java programs: CommPortOwnershipListener is called even if a different instance of the program tries to access the port. No port locking of any kind seems to be done though. As a result, IBM apps are protected against each other but not against minicom. * When opening a port fails due to missing permissions on the device file, or due to an exclusive lock owned by another instance of itself, - IBM throws a PortInUseException after the timeout (currentOwner="Unknown Application") - Sun throws a java.lang.RuntimeException immediately (message=one of the following two: "\n Error opening \"/dev/ttyS1\"\n Permission denied" "\n Error opening \"/dev/cua/a\"\n Error in lockf()" What I learn from this is that 1. Neither the Sun nor the IBM implementation are really useable in terms of port locking, since they do not respect minicom. 2. Sun's throwing a RuntimeException from CommPortIdentifier.open() is undocumented and may break client applications in an unexpected way. 3. Kernel locks through fcntl are not sufficient for minicom to keep it off the port. 4. Kernel locks give no indication what application is currently owning the port (lockfiles could give that information but minicom does not evaluate it). Does anybody on this list know the difference between fcntl(F_SETLK, {type=F_WRLCK}) and ioctl(fd, TIOCEXCL, 0); ? What do folks think about throwing a RuntimeException from CommPortIdentifier.open() ? I'll follow up with a separate E-Mail proposing a strategy for RXTX to handle port locking. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, July 30, 2008 4:16 AM > To: Oberhuber, Martin > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Port locking on Linux: Redhat lockdev-baudboy > Instead, I would suggest we do an exclusive open and try to > lock as is if > lockfiles are not disabled. Warn if the lock fails. Always respect > lockfiles prior to opening. > > Exclusive opens should work on linux, mac, sol, bsd, ... > > The code is simple and does not introduce any new dependencies. > > ... > open > ... > do { > res = ioctl(fd, TIOCEXCL, 0); > } while ( (errno == EINTR || errno == EAGAIN ) && res != 0 ); > > > if( res != 0 ) > fail > > > In the worst case, minicom or another application may not be > able to find a lockfile but their open will fail. We locked > the port. Other applications may not do this so we should > always respect lockfiles. > > -- > Trent Jarvi > tjarvi at qbang.org > From Martin.Oberhuber at windriver.com Mon Sep 1 10:05:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 1 Sep 2008 18:05:02 +0200 Subject: [Rxtx] RXTX Port Locking Improvements Message-ID: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> Hi all, here is my proposal for improving port locking in RXTX. 1. Goals of the Proposal * Support enabling / disabling / configuring port locking at runtime without re-compiling RXTX. * Support port locking by Kernel call even if permissions for lockfiles are not sufficient. * Report exact reason for failure to acquire a port to the client application (including the file system path of a lockfile for instance). 2. Getting the settings into RXTX * Use Java System Properties for tuning behavior (since the RXTX / javax.comm API is frozen): * -Dgnu.io.rxtx.LockfileDir=/var/lock # specify location of lockfile directory, similar to minicom * -Dgnu.io.rxtx.LockPolicy=none # no port locking, no warnings or anything * -Dgnu.io.rxtx.LockPolicy=default # try lockfiles, in case of missing permission fall back to kernel locks without warning * -Dgnu.io.rxtx.LockPolicy=warn # try lockfiles, in case of missing permission fall back to kernel locks with warning to stdout * -Dgnu.io.rxtx.LockPolicy=strict # require lockfiles, throw exception if they cannot be created. The "default" policy would try to be as good a citizen as possible (create lockfiles if possible, create Kernel exclusive lock if possible), but without guarantee and without warning in case it fails creating any lock. The warning to stdout would be something like "Warning: RXTX failed to create a lockfile in /var/lock/LCK..ttyS0. Check file system permissions or specify -Dgnu.io.rxtx.LockfileDir in order to enable proper locking of serial ports against other applications". 3. Error Reporting out of RXTX * All errors acquiring a port are reported by means of a gnu.io.rxtx.PortInUseException on CommPortIdentifier#open(). * In case of missing permissions or other unexpected failure running through open(), the "currentOwner" field is filled with the String "Unexpected Error", and the message field of the exception is filled with a String like "/dev/ttyS0 : Permission denied in open()" or "/var/lock/LCK..ttyS0 : Permission denied in write()" * In case of properly running through open() but not being able to lock the port, the "currentOwner" field is populated with the name and PID of the external process locking the port if it can be obtained, or "Unknown Application" otherwise. In other words, I'm proposing to replace Sun's RuntimeException for reporting unexpected errors with a PortInUseException with the owner String set to "Unexpected Error" and detail information in the message field of the exception. In case any file system resource is related to the unexpected error, it must be mentioned first and separated by a " : " String such that clients can parse the actual file system resource out of the message automatically. I thought about subclassing PortInUseException to provide more error details and type-safe parsing of the affected resource but wasn't so sure about it in the end. What do others think about this proposal? Would it make more sense to throw a RuntimeException for unexpected errors, rather than a PortInUseException with the String "Unexpected Error" ? Do the proposed port locking policies make sense? Is the naming proper? I'll next work on a patch to implement the proposal (or any modification as discussed on this list). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080901/5d1811e0/attachment-0004.html From Steffen.DETTMER at ingenico.com Mon Sep 1 10:50:56 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 1 Sep 2008 18:50:56 +0200 Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> Message-ID: <20080901165055.GD17898@elberon.bln.de.ingenico.com> Hi, thanks for this nice list! * Oberhuber, Martin wrote on Mon, Sep 01, 2008 at 17:36 +0200: > 1. Neither the Sun nor the IBM implementation are really > useable in terms of port locking, since they do not > respect minicom. > 2. Sun's throwing a RuntimeException from > CommPortIdentifier.open() is undocumented and may break > client applications in an unexpected way. Yes, someone may expect a PortInUseException if the port is in use, but since RuntimeExceptions can be thrown always anyway, I think there is not much a client application can do than catching the `known expected' unexpected (unspecified by throws) exceptions. Client applications probably want to wrap CommPortIdentifier.open(), catching at least PortInUseException and/or RuntimeException and throwing a well-defined exception (that should also include the port name and/or other helpful detail for the user, such as why the access was tried etc) > 3. Kernel locks through fcntl are not sufficient for > minicom to keep it off the port. I think it could be sufficient if mandatory file locking is enabled (on systems that support it). Linux for instance in general should support mandatory file locking, but I don't know if it really works for device files. > 4. Kernel locks give no indication what application is > currently owning the port (lockfiles could give that > information but minicom does not evaluate it). > > Does anybody on this list know the difference between > fcntl(F_SETLK, {type=F_WRLCK}) > and > ioctl(fd, TIOCEXCL, 0); > ? maybe the first one could be considered more general (and modern :)), should work for all files and file systems and it is POSIX; the second one as some specific function of some serial/tty driver. I think on POSIX systems (whatever this means in practice), someone should be able to expect fcntl(F_SETLK, ...) to work, but no rule without an exception (sometimes, just exceptions without any rule ;)). ioctl TIOCEXCL prevents a second open (unless executed by root), but fcntl(F_SETLK) another F_SETLK (when advisory locking) or write (when mandatory locking). Some serial implementations do (or try) both. > What do folks think about throwing a RuntimeException from > CommPortIdentifier.open()? (I think it shows that those mandatory throws() clause and its exceptions were not the best ideas when defining the java language, sometimes workarounded by `throws Throwable' :)) I'd expect such an exception (only) in the fatal cases where an application usually cannot do anything reasonable, let's say some OutOfMemory (yes, this is an Error I know) or SecurityException. We had quite some issues with things like that (not rxtx related) and with applications catching RuntimeException (or even Throwable) on some high level sometimes resulting in strange effects, so I think it should be avoided, for instance, by wrapping calls to such methods, also needed to add more details about the region where the problem occured (often, higher layers know additional details more interesting for the user, for instance, why something was attempted, where it was configured or which subsystem tried it what for, ...). Unfortunality it is not always straightforward/possible to overwrite to get such a behavior. Actually, I think usually it is not that easy (either you cannot call a needed method because it is private or you cannot put your wrapper because the constructing class cannot be overwritten easily, ... etc). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From tjarvi at qbang.org Mon Sep 1 11:28:37 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 1 Sep 2008 11:28:37 -0600 (MDT) Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: <20080901165055.GD17898@elberon.bln.de.ingenico.com> References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> <20080901165055.GD17898@elberon.bln.de.ingenico.com> Message-ID: On Mon, 1 Sep 2008, Steffen DETTMER wrote: > >> 4. Kernel locks give no indication what application is >> currently owning the port (lockfiles could give that >> information but minicom does not evaluate it). >> >> Does anybody on this list know the difference between >> fcntl(F_SETLK, {type=F_WRLCK}) >> and >> ioctl(fd, TIOCEXCL, 0); >> ? > > maybe the first one could be considered more general (and modern > :)), should work for all files and file systems and it is POSIX; > the second one as some specific function of some serial/tty driver. > > I think on POSIX systems (whatever this means in practice), > someone should be able to expect fcntl(F_SETLK, ...) to work, but > no rule without an exception (sometimes, just exceptions without > any rule ;)). > > ioctl TIOCEXCL prevents a second open (unless executed by root), > but fcntl(F_SETLK) another F_SETLK (when advisory locking) or > write (when mandatory locking). Some serial implementations do > (or try) both. > I couldn't parse the last comment about F_SETLK. I guess you ment F_SETLK prevents other F_SETLK attempts (advisory) or writing (mandatory). Presumably that applies to all users. While F_SETLK is possibly something we can add, I just want to point out that the TIOCEXCL will work on all UNIX like systems and is very specific to our needs; it only applies to ttys. F_SETLK also appears to be used for other things like trying to lock portions of a file over networked filesystems. -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Mon Sep 1 11:33:53 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 1 Sep 2008 19:33:53 +0200 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> Message-ID: <20080901173353.GE17898@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Mon, Sep 01, 2008 at 18:05 +0200: > 2. Getting the settings into RXTX > > * Use Java System Properties for tuning behavior (since the RXTX / > javax.comm API is frozen): I think supporting -D system properties is a similar API change to add some new config-classes/method (except that system properties are better hidden :)). I'd like to add that spplications should be able to overwrite this (for instance, if they support config files or some GUI to configure it), here they could use setProperty. > * -Dgnu.io.rxtx.LockfileDir=/var/lock # specify location of > lockfile directory, similar to minicom > * -Dgnu.io.rxtx.LockPolicy=none # no port locking, no > warnings or anything > * -Dgnu.io.rxtx.LockPolicy=default # try lockfiles, in case of > missing permission fall back to kernel locks without warning > * -Dgnu.io.rxtx.LockPolicy=warn # try lockfiles, in case of > missing permission fall back to kernel locks with warning to stdout > * -Dgnu.io.rxtx.LockPolicy=strict # require lockfiles, throw > exception if they cannot be created. > > The "default" policy would try to be as good a citizen as possible > (create lockfiles if possible, create Kernel > exclusive lock if possible), but without guarantee and without warning > in case it fails creating any lock. Nice, I think the important things would be configurable then! so default is no one of `none', `warn' and `strict'? I think it could be confusing if `default' is an option that must explicitely given, maybe -Dgnu.io.rxtx.LockPolicy=automatic and making this the default (i.e. when it is given, actually nothing changes)? Well, just a minor detail. Another minor detail could be that here someone might think that two things are joined: first, what should happen if locking fails and second how to lock. Maybe it could be splitted. Additionally, somone could want to distinguish between `lock always' and `lock at use', but I'm not sure if the javax style API supports this. On a (non rxtx related but C++) implementation alternatively it was used to have a `Policy' (always, at use, none, default[here: depending on the device]) and a `Kind' (classes for UUCP-lockfile and kernel locks). So back to rxtx, maybe here an additional option like some -Dgnu.io.rxtx.LockKind = [file] [ioctl] [fcntl], maybe separated by "," or as ORed integer number, and LockPolicy=(none|any|all)? I'd dislike warnings to stdout (if so, stderr, but better logging, because it can be configured). stdout may not be avialable or used by some text mode UI or alike. For GUI-applications an english language message may not be sufficient but national language support may be required (I have no idea how to do this, just name it for the list). I think for logging (in contrast to stdout) in most cases english-only logs are acceptable. Anyway, this really are just minor things. Your proposal seems to support all important things and the naming is OK. > The warning to stdout would be something like "Warning: RXTX failed to > create a lockfile in /var/lock/LCK..ttyS0. Check file system permissions > or specify -Dgnu.io.rxtx.LockfileDir in order to enable proper locking > of serial ports against other applications". yes, nice! Maybe add the device port name that was tried to open (maybe it was something symbolic like `modem' or alike)? > 3. Error Reporting out of RXTX > > * All errors acquiring a port are reported by means of a > gnu.io.rxtx.PortInUseException on CommPortIdentifier#open(). Yes, I think better than RuntimeExceptions! > * In case of missing permissions or other unexpected failure > running through open(), the "currentOwner" field is filled with the > String "Unexpected Error", and the message field of the exception is > filled with a String like "/dev/ttyS0 : Permission denied in open()" or > "/var/lock/LCK..ttyS0 : Permission denied in write()" or maybe defining a subclass of PortInUseException? Then applications could (theoretically) catch the permission denied (lets say if someone wants to write a config GUI or application that autodetects if lock files can be used) > * In case of properly running through open() but not being able to > lock the port, the "currentOwner" field is populated with the name and > PID of the external process locking the port if it can be obtained, or > "Unknown Application" otherwise. > > In other words, I'm proposing to replace Sun's RuntimeException for > reporting unexpected errors with a PortInUseException with the owner > String set to "Unexpected Error" and detail information in the message > field of the exception. In case any file system resource is related to > the unexpected error, it must be mentioned first and separated by a " : > " String such that clients can parse the actual file system resource out > of the message automatically. (or adding a new method getLockPath() or so to PortInUseException) > I thought about subclassing PortInUseException to provide more error > details and type-safe parsing of the affected resource but wasn't so > sure about it in the end. Yes, intuitively I feel the same, like adding some String getPath() method to PortInUseException or a (new) subclass. In some unrelated thing we used exception message string contents parsing (was considered a hack from the beginning), some years later hit some problem in which made the error-detail-determination fail and replaced it completely by heaps of subclasses (BTW, the sources for the subclasses were automatically generated), that's why I'd use subclasses in case of doubt, but probably this has other disadvantages. Sometimes, the problem is that people later that use this API may not know any of those details and discussions, but if they see some special methods or subclasses in the javadoc or so, I think chances are higher that those situations are treated better, which may make users happier; also example programs / example code snippets can be helpful. > What do others think about this proposal? Would it make more > sense to throw a RuntimeException for unexpected errors, rather > than a PortInUseException with the String "Unexpected Error" ? I think, Exceptions should be used for unexpected conditions (excepted `exceptions' should be returned, e.g. by bool methods or alike). (unrelated here, but) Working with throw and catch IMHO is a kind of `goto' programming, actually even worse, and IMHO should not be used for the `good case' (such as searching a free port). Here, I think the throws() clause with PortInUseException simply is wrong. It should throw something more generic with PortInUseException beeing one subclass, but this would be an API change. For compatiblity, I could imagine a subclass of it. > Do the proposed port locking policies make sense? Is the naming > proper? Yes, for me it makes sense and is proper. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From Steffen.DETTMER at ingenico.com Mon Sep 1 11:50:48 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 1 Sep 2008 19:50:48 +0200 Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> <20080901165055.GD17898@elberon.bln.de.ingenico.com> Message-ID: <20080901175048.GF17898@elberon.bln.de.ingenico.com> * Trent Jarvi wrote on Mon, Sep 01, 2008 at 11:28 -0600: > >ioctl TIOCEXCL prevents a second open (unless executed by root), > >but fcntl(F_SETLK) another F_SETLK (when advisory locking) or > >write (when mandatory locking). > > I couldn't parse the last comment about F_SETLK. I guess you ment > F_SETLK prevents other F_SETLK attempts (advisory) or writing > (mandatory). Presumably that applies to all users. Yes, thanks for the clarification. > While F_SETLK is possibly something we can add, I just want to point > out that the TIOCEXCL will work on all UNIX like systems and is very > specific to our needs; it only applies to ttys. I guess F_SETLK could make sense if it would prevent minicom to work if mandatory locking is enabled, otherwise and if TIOCEXCL is working, F_SETLK probably doesn't make much sense, does it? Bad would be, I think, if on some system TIOCEXCL works, but F_SETLK fails (e.g. not supported or so) and in the end rxtx would throw some exception instead of opening the port, so adding it could require tests on exotic systems... oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From Martin.Oberhuber at windriver.com Wed Sep 3 11:33:54 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 3 Sep 2008 19:33:54 +0200 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <20080901173353.GE17898@elberon.bln.de.ingenico.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Hello Steffen, some comments: > I think supporting -D system properties is a similar API change > to add some new config-classes/method (except that system > properties are better hidden :)). Well the point is that if System Properties are set but not understood by a different runtime implementation, it doesn't hurt and you can still link against / run the program. Creating new config-classes creates a compile-time API change such that you cannot easily port the program to other API implementations any more. In my opinion, it is still important that programs which use RXTX can be ported to the Sun javax.comm APIs easily (that is, just by doing a String replace of sed -e 's,gnu\.io\.,javax.comm,g' on all files. Creating new classes or interfaces makes that impossible. What do others on this list think? Is this still important, or can we fork off javax.comm since that's not really maintained any more anyways? Note that especially on embedded devices (J2ME), many vendors provide native javax.comm implementations, so porting an RXTX based program onto such a J2ME vm is much easier if we restrict ourselves to the original API. > I'd like to add that spplications should be able to overwrite > this Well, they can always System.setProperty("gnu.io.rxtx.LockfileDir", "/foo/bar"); or similar. We're doing that in our commercial app in order to add ports which RXTX doesn't discover automatically. > so default is no one of `none', `warn' and `strict'? I think it We can discuss what the default should be, it can be any of the other options of course. I had proposed "default" to be the default :-) I usually like the default to be that it "just works without fuss" :-) > Another minor detail could be that here someone might think that > two things are joined: first, what should happen if locking fails > and second how to lock. Maybe it could be splitted. It could probably be splitted. But I didn't want to expose too many implementation details to the outside, nor make the interface (configuration) too complex. Note that different locking mechanisms could be available on different OS's; the user won't care about the mechanisms but what to do in case one of them fails (fallback to others with or without warning, or fail). So far, we've been clear that the right thing to do is (1) observe and create lockfiles for legacy clients, and then (2) do the right thing which is the Kernel Lock. I don't see a need for more configuration at this point. If we should see a necessity for more fine-grained configuration we can add that in the future. > Policy differentiate between `lock always' and `lock at use' We lock when the client opens the port, javax.comm does not provide an API for locking even without opening the port if that's what you mean, so this doesn't seem an option. > some -Dgnu.io.rxtx.LockKind = [file] [ioctl] [fcntl] I see no sense in trying some locks only. Applications should try to acquire every lock they are aware of, no? Note that we don't know what other apps are installed, so we need to use all mechansims we can. On a Platform where some mechanism is not available, it will be removed at compile-time anyways (configure script). If it's available at compile-time it should be used at runtime. > I'd dislike warnings to stdout (if so, stderr, but better > logging, because it can be configured). stdout may not be > avialable or used by some text mode UI or alike. I know, that's why I wouldn't make that option the default. And yes, of course we'd log to stderr and not stdout. > For GUI-applications an english language message may not be > sufficient but national language support may be required RXTX is low-level. Translation is up to the higher level client app. What I take from that is, that the client app should be able to receive exactly the same warnings that would otherwise go to stdout. My current proposal doesn't account for that... but actually, RXTX's Zystem class provides for configurable logging through the "gnu.io.log.mode" System Property. I'm just not exactly sure how Zystem is to be used, but it should work somehow... Trent, any help > yes, nice! Maybe add the device port name that was tried to open > (maybe it was something symbolic like `modem' or alike)? Hm... that might indeed help in some cases. Thanks for the hint. > or maybe defining a subclass of PortInUseException? > (or adding a new method getLockPath() or so to PortInUseException) Again, that's not possible if we want to be source compatible with javax.comm -- but I'm in favor of this proposal if the Community thinks that this is not so important any more? Thanks, Martin From johnny.luong at trustcommerce.com Wed Sep 3 12:54:17 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Wed, 03 Sep 2008 11:54:17 -0700 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: <48BEDD59.5000908@trustcommerce.com> Oberhuber, Martin wrote: > Creating new config-classes creates a compile-time API change > such that you cannot easily port the program to other API > implementations any more. > > In my opinion, it is still important that programs which use > RXTX can be ported to the Sun javax.comm APIs easily (that is, > just by doing a String replace of > sed -e 's,gnu\.io\.,javax.comm,g' > on all files. Creating new classes or interfaces makes that > impossible. > > What do others on this list think? Is this still important, > or can we fork off javax.comm since that's not really maintained > any more anyways? > > Note that especially on embedded devices (J2ME), many vendors > provide native javax.comm implementations, so porting an RXTX > based program onto such a J2ME vm is much easier if we restrict > ourselves to the original API. Hi, I think it wouldn't be difficult for a person to create a separate facade of the javax.comm interface which talks to the RXTX library and perhaps if someone is willing to share that, then it can be improved on. If someone needs the older interface now, there are alternatives, e.g: RXTX 2.0, Sun javax.comm, serialio.com, etc. I only use the gnu.io namespace anyways with respect to RXTX and perhaps if there is a strong enough interest, someone with the resources/time could go through the JSR/JCP as there are probably some level of variation on the J2ME implementations of the API. Best, Johnny From Steffen.DETTMER at ingenico.com Thu Sep 4 02:42:15 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 4 Sep 2008 10:42:15 +0200 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: <20080904084215.GF30569@elberon.bln.de.ingenico.com> Hi! please let me repeat that I wrote about minor details only. I'm afraid that too much discussion about the minor, unimportant details could take focus from the important points. I just can't resist :-) Summary of my long OT below is that for me your proposal is OK, except that applications should parse error or warning messages e.g. for translation (if I understood correctly). * Oberhuber, Martin wrote on Wed, Sep 03, 2008 at 19:33 +0200: > > I think supporting -D system properties is a similar API change > > to add some new config-classes/method (except that system > > properties are better hidden :)). > > Well the point is that if System Properties are set but not > understood by a different runtime implementation, it doesn't > hurt and you can still link against / run the program. In Java, I think adding new classes is not problem also. Now I'm not really sure, but I think adding new methods also does work. So I think in the end similar to adding support for new -D options old implementations simply don't use it. (but I'm not against -D, I wrote by comment just BTW) > Creating new config-classes creates a compile-time API change > such that you cannot easily port the program to other API > implementations any more. > > In my opinion, it is still important that programs which use > RXTX can be ported to the Sun javax.comm APIs easily (that is, > just by doing a String replace of > sed -e 's,gnu\.io\.,javax.comm,g' > on all files. Creating new classes or interfaces makes that > impossible. Do you really consider source code modifying with sed or some other kind of preprocessing be a common use? I don't think that such techniques are used by many Java developers. Also, in this case of course your changed implementation will compile, but it would fail at runtime, because no locking is available, so you would need to implement it around (which BTW IMHO isn't a bad idea anyway), having something on top that adds locking support and stuff. I mean, if locking support is considered that important that the application cares about it, let's say by offering a GUI and internally calling setProperty, the ported version needs to implement all this on its own, simply because otherwise all those functions would have no effect. But if another application does not care much about locking and uses the defaults only (i.e. is not using -D options), then it would work in both cases. just BTW #2: If support for some javax.comm is needed, I think wrappers/adapters are needed anyway: you could have one implementation for javax.comm, a second for gnu.io and a third for thirdparty something I/O. Well, since I consider those Java APIs beeing weak and uncomfortable, I think adapters on top of it is needed anyway, for instance, supporting timeouts. Not only in some `global timeout that throws an exception if reached' or so, but something reasonable, powerfull that can be used to implement serial protocols, for instance. So in summary, I think the API should support something that makes all those usages /possible/, like let's say an operating system, but it is /not/ a generic communication library which abstracts from communications, physical and logical links and APIs. > Note that especially on embedded devices (J2ME), many vendors > provide native javax.comm implementations, so porting an RXTX > based program onto such a J2ME vm is much easier if we restrict > ourselves to the original API. I would expect those APIs to behave different in detail, especially at timeouts, that a 1:1 port wouldn't be possible anyway (at least that are my limited experiences with embedded C libs). > > I'd like to add that spplications should be able to overwrite > > this > > Well, they can always System.setProperty("gnu.io.rxtx.LockfileDir", > "/foo/bar"); or similar. We're doing that in our commercial > app in order to add ports which RXTX doesn't discover automatically. Yes, but this only would LOOK as if it would work on let's say the embeeded port, but in fact it would do nothing (which in this example probably would be OK). The only think I dislike here is that you will not get a compiler error, so a colleguage who ports such software probably would miss if the application to be ported requires/supports a lockfile directory. > > so default is no one of `none', `warn' and `strict'? I think it > > We can discuss what the default should be, it can be any of the > other options of course. I had proposed "default" to be the > default :-) I usually like the default to be that it "just works > without fuss" :-) What I meant was that the default should also have some meaningful name. I think specifying `myoption=default' makes no sense, either it should not be given at all or it should be `myoption=concretevalue1' which could be the same as if not given at all, but has at least some documentary purposes and keeps working even if defaults are changes, and finnally thus the default option IMHO also should have a speaking name - but this also is just a minor detail. > > Another minor detail could be that here someone might think that > > two things are joined: first, what should happen if locking fails > > and second how to lock. Maybe it could be splitted. > > It could probably be splitted. But I didn't want to expose too many > implementation details to the outside, nor make the interface > (configuration) too complex. Yes, this is a good point. As the discussion here shows that it is complex library users would probably just get confused and set options wrongly. However, for specific applications specific things may be needed. In this cases according to your proposal it can be configured to use `none' and the specific application can implement whatever locking. So your proposal is fine! > Note that different locking mechanisms could be available on > different OS's; the user won't care about the mechanisms but > what to do in case one of them fails (fallback to others with > or without warning, or fail). Yes, but also has influence on the defaults, doesn't it? I think on windows noone expect some UUCP style lock files, right? Defaults of course must work on all major systems. > So far, we've been clear that the right thing to do is (1) observe > and create lockfiles for legacy clients, and then (2) do the right > thing which is the Kernel Lock. > I don't see a need for more configuration at this point. If we > should see a necessity for more fine-grained configuration we > can add that in the future. (kernel lock means TIOCEXCL, right?) would the file locking stuff be implemented in java in an overwriteable way? Anyway, as long as it can be disabled its ok. I think for applications that rely on that, for instance servers searching a free modem at some multiport card or alike, some special implementation probably is needed anyway. Yes, I think you are right, it should be kept simple. > > Policy differentiate between `lock always' and `lock at use' > > We lock when the client opens the port, javax.comm does not provide > an API for locking even without opening the port if that's what you > mean, so this doesn't seem an option. > > > some -Dgnu.io.rxtx.LockKind = [file] [ioctl] [fcntl] > > I see no sense in trying some locks only. Applications should try > to acquire every lock they are aware of, no? Note that we don't > know what other apps are installed, so we need to use all mechansims > we can. On a Platform where some mechanism is not available, it > will be removed at compile-time anyways (configure script). If it's > available at compile-time it should be used at runtime. Yes, but if a lock fails, how to know if it fails because the OS does not supports it or permissions are insufficient - or the port really is busy? Ignoring whether a lock could made probably makes not much sense, but aborting could lead to unsable rxtx (maybe on `broken' OSes only). But you are right, since it can be disabled, applications can implement around it what they need. > > For GUI-applications an english language message may not be > > sufficient but national language support may be required > > RXTX is low-level. > Translation is up to the higher level client > app. What I take from that is, that the client app should be > able to receive exactly the same warnings that would otherwise > go to stdout. to allow to parse the string? but what if the message is changed in the next version of rxtx? I found such constructions in some functions (unrelated to rxtx) and I had to search them because they didn't work, so I think parsing informal messages isn't a good idea, usually. > > or maybe defining a subclass of PortInUseException? > > (or adding a new method getLockPath() or so to PortInUseException) > > Again, that's not possible if we want to be source compatible > with javax.comm -- but I'm in favor of this proposal if the > Community thinks that this is not so important any more? OK. (ok, if you consider similar names in different java packages as compatible as you explained below with sed, yes, I see your point) just BTW again: I would not rely that no javax.comm.something implementation defines reasonable exceptions. I know that for some reason it is common in the Java world not to define too many reasonable exceptions, maybe because it is slow or writing all those .java files is too annoying and source code generation not known to many developers, don't know, but the APIs do not necessarily tell if additional classes are used for the implementation (and thus IMHO do not forbid to do so). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From petr.czekaj at vaecontrols.cz Thu Sep 4 07:07:11 2008 From: petr.czekaj at vaecontrols.cz (Petr Czekaj) Date: Thu, 4 Sep 2008 15:07:11 +0200 Subject: [Rxtx] Undisplay "Stable library" Message-ID: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> Hi, is there a way to use RXTX library without writing text: "Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7" into console window just after calling "getPortIdentifiers()" method? Thank you Peter -------------------------------------------- VAE Controls - mailto:info at vaecontrols.cz tel. +420 596 240 011 ; fax. +420 596 242 153 Tato zprava a pripadne prilohy jsou duverne a jsou vyhradne urceny pro pouziti adresata. Jestlize jste ji obdrzeli omylem, ozvete se prosim na vyse uvedenou adresu. Vsechny nazory a myslenky jsou vyhradne odesilatele a nemusi nutne prezentovat stanovisko VAE Controls s.r.o. VAE Controls si rezervuje veskera prava na monitoring elektronicke posty, prochazejici z/do vlastni firemni site. Tato zprava byla zkontrolovana antivirovym programem, nicmene firma VAE Controls neni zodpovedna za pripadne skody zpusobene prijmem nedetekovanych viru. CONFIDENTIALITY NOTICE: The information in this e-mail, including any attachment, is confidential and may be legally privileged. This e-mail is intended solely for the addressee. If you are not the addressee, dissemination, copying or other use of this e-mail or any of its content is strictly prohibited and may be unlawful. If you are not the intended recipient please inform the sender immediately and destroy the e-mail and any copies. E-mails and unencrypted attachments are scanned for all known viruses. Always scan e-mail attachments for viruses before opening them. All liability for viruses is excluded to the fullest extent permitted by law. Any views expressed in this message are those of the individual sender. -------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080904/10087013/attachment-0001.html From Martin.Oberhuber at windriver.com Thu Sep 4 07:34:45 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 4 Sep 2008 15:34:45 +0200 Subject: [Rxtx] Undisplay "Stable library" In-Reply-To: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> References: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> Message-ID: <460801A4097E3D4CA04CC64EE6485848075ABFE4@ism-mail03.corp.ad.wrs.com> You can do java -Dgnu.io.rxtx.NoVersionOutput or programmatically set that System Property in your App. Unfortunately the feature of muting the version info was added only shortly after releasing RXTX 2.1-7r2 so you either need to build RXTX from the sources out of CVS, or you get the Eclipse variant binaries from http://rxtx.qbang.org/eclipse/downloads Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Petr Czekaj Sent: Thursday, September 04, 2008 3:07 PM To: rxtx at qbang.org Subject: [Rxtx] Undisplay "Stable library" Hi, is there a way to use RXTX library without writing text: "Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7" into console window just after calling "getPortIdentifiers()" method? Thank you Peter -------------------------------------------- VAE Controls - mailto:info at vaecontrols.cz tel. +420 596 240 011 ; fax. +420 596 242 153 Tato zprava a pripadne prilohy jsou duverne a jsou vyhradne urceny pro pouziti adresata. Jestlize jste ji obdrzeli omylem, ozvete se prosim na vyse uvedenou adresu. Vsechny nazory a myslenky jsou vyhradne odesilatele a nemusi nutne prezentovat stanovisko VAE Controls s.r.o. VAE Controls si rezervuje veskera prava na monitoring elektronicke posty, prochazejici z/do vlastni firemni site. Tato zprava byla zkontrolovana antivirovym programem, nicmene firma VAE Controls neni zodpovedna za pripadne skody zpusobene prijmem nedetekovanych viru. CONFIDENTIALITY NOTICE: The information in this e-mail, including any attachment, is confidential and may be legally privileged. This e-mail is intended solely for the addressee. If you are not the addressee, dissemination, copying or other use of this e-mail or any of its content is strictly prohibited and may be unlawful. If you are not the intended recipient please inform the sender immediately and destroy the e-mail and any copies. E-mails and unencrypted attachments are scanned for all known viruses. Always scan e-mail attachments for viruses before opening them. All liability for viruses is excluded to the fullest extent permitted by law. Any views expressed in this message are those of the individual sender. -------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080904/d70fbd85/attachment-0001.html From michael.erskine at ketech.com Thu Sep 4 07:36:36 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Thu, 4 Sep 2008 14:36:36 +0100 Subject: [Rxtx] Undisplay "Stable library" In-Reply-To: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> References: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> Message-ID: <06BA3262D918014F9183B66425D5A8D43608077CBD@no-sv-03.ketech.local> > Hi, is there a way to use RXTX library without writing text: > "Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7" > > into console window just after calling "getPortIdentifiers()" method? Yes, prior to any calls that would cause the classloader to pull in RXTX, redirect standard output to a temporary PrintStream (with java.lang.System.setOut() ) and then restore later if required! Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Mon Sep 1 08:59:20 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 1 Sep 2008 16:59:20 +0200 Subject: [Rxtx] [Suspected Spam][Blocked Sender]Re: Towards an RXTX release - CSR BT/USB chipset In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com><13557-75390@sneakemail.com><20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848074C4259@ism-mail03.corp.ad.wrs.com> Hi Bruce, I think that the only way to avoid temparary disconnect during port scanning, is to avoid the temporary open() during port scanning. That, however, can only be avoided if there is some external means to enumerate the candidates for valid port names. The javax.comm implementations by Sun and IBM use a file named "javax.comm.properties" for this. On Linux and Solaris, it enumerates the allowed prefixes for device names to be used. Those prefixes known, the library treats all existing files with such prefixes as valid ports, without trying to actually open them. See http://java.sun.com/products/javacomm/ I'd think that one option to simplify the port scanning would be to use a Java System Property to specify the Policy for port scanning. For instance: -Dgnu.io.rxtx.PortScanningPolicy=read # try to open & read scanned ports -Dgnu.io.rxtx.PortScanningPolicy=existing # treat ports as valid if they exist For enumerating the candidates to check, the "gnu.io.rxtx.properties" file already exists as well as the "gnu.io.rxtx.SerialPorts" and "gnu.io.rxtx.ParallelPorts" System Properties. These support explicit enumeration of port candidates. So, a second possible enhancement in addition to support specifying the PortScanningPolicy could be to support specifying prefix names for port enumeration rather than just explicit enumeration. What do others think about these ideas? Could these improve the long-standing performance issues with USB / Bluetooth adapters during port scanning? Why does RXTX try to open scanned ports in the first place, rather than relying on plain existence of the devices? I'd guess that a Patch providing these enhancements would be appreciated by the RXTX community. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Bruce Boyes Sent: Tuesday, August 05, 2008 3:13 AM To: Rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender]Re: [Rxtx] Towards an RXTX release - CSR BT/USB chipset At 18:37 07/29/2008, you wrote: All, Is there any chance that the next official release could improve on the port scanning (getPortIdentifiers)? It would be nice if rxtx could also not cause a connect/disconnect and subsequent problems with a USB Bluetooth BlueSoleil adapter (using the CSR chipset), as documented in a previous email from me. best regards Bruce ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080901/f3cb9a8e/attachment-0005.html From Martin.Oberhuber at windriver.com Mon Sep 1 09:36:31 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 1 Sep 2008 17:36:31 +0200 Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> Hi all, I made some experiments with the Sun and IBM implementations of javax.comm (on Linux and Solaris), in order to understand how these treat port locking and lockfiles and in what way they report failure to obtain a port to the client. Here are the results: * Neither Sun nor IBM check or create any lockfiles. As a result, minicom can open the same serial port as my test java application without error. * Sun uses Kernel locking with fcntl, according to an strace (truss) that I had run with my test app: open("/dev/ttyS1", O_RDWR|O_NONBLOCK|O_EXCL) = 5 fcntl64(5, F_SETLK, {type=F_WRLCK, ...}) = 0 As a result, multiple instances of the same Java test program are protected against each other; minicom, however, is *not* protected since it does open("/dev/ttyS1", O_RDWR|O_NONBLOCK) on Linux RHEL 4 at least. * IBM seems to use some memory sharing between multiple instances of Java programs: CommPortOwnershipListener is called even if a different instance of the program tries to access the port. No port locking of any kind seems to be done though. As a result, IBM apps are protected against each other but not against minicom. * When opening a port fails due to missing permissions on the device file, or due to an exclusive lock owned by another instance of itself, - IBM throws a PortInUseException after the timeout (currentOwner="Unknown Application") - Sun throws a java.lang.RuntimeException immediately (message=one of the following two: "\n Error opening \"/dev/ttyS1\"\n Permission denied" "\n Error opening \"/dev/cua/a\"\n Error in lockf()" What I learn from this is that 1. Neither the Sun nor the IBM implementation are really useable in terms of port locking, since they do not respect minicom. 2. Sun's throwing a RuntimeException from CommPortIdentifier.open() is undocumented and may break client applications in an unexpected way. 3. Kernel locks through fcntl are not sufficient for minicom to keep it off the port. 4. Kernel locks give no indication what application is currently owning the port (lockfiles could give that information but minicom does not evaluate it). Does anybody on this list know the difference between fcntl(F_SETLK, {type=F_WRLCK}) and ioctl(fd, TIOCEXCL, 0); ? What do folks think about throwing a RuntimeException from CommPortIdentifier.open() ? I'll follow up with a separate E-Mail proposing a strategy for RXTX to handle port locking. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, July 30, 2008 4:16 AM > To: Oberhuber, Martin > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Port locking on Linux: Redhat lockdev-baudboy > Instead, I would suggest we do an exclusive open and try to > lock as is if > lockfiles are not disabled. Warn if the lock fails. Always respect > lockfiles prior to opening. > > Exclusive opens should work on linux, mac, sol, bsd, ... > > The code is simple and does not introduce any new dependencies. > > ... > open > ... > do { > res = ioctl(fd, TIOCEXCL, 0); > } while ( (errno == EINTR || errno == EAGAIN ) && res != 0 ); > > > if( res != 0 ) > fail > > > In the worst case, minicom or another application may not be > able to find a lockfile but their open will fail. We locked > the port. Other applications may not do this so we should > always respect lockfiles. > > -- > Trent Jarvi > tjarvi at qbang.org > From Martin.Oberhuber at windriver.com Mon Sep 1 10:05:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 1 Sep 2008 18:05:02 +0200 Subject: [Rxtx] RXTX Port Locking Improvements Message-ID: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> Hi all, here is my proposal for improving port locking in RXTX. 1. Goals of the Proposal * Support enabling / disabling / configuring port locking at runtime without re-compiling RXTX. * Support port locking by Kernel call even if permissions for lockfiles are not sufficient. * Report exact reason for failure to acquire a port to the client application (including the file system path of a lockfile for instance). 2. Getting the settings into RXTX * Use Java System Properties for tuning behavior (since the RXTX / javax.comm API is frozen): * -Dgnu.io.rxtx.LockfileDir=/var/lock # specify location of lockfile directory, similar to minicom * -Dgnu.io.rxtx.LockPolicy=none # no port locking, no warnings or anything * -Dgnu.io.rxtx.LockPolicy=default # try lockfiles, in case of missing permission fall back to kernel locks without warning * -Dgnu.io.rxtx.LockPolicy=warn # try lockfiles, in case of missing permission fall back to kernel locks with warning to stdout * -Dgnu.io.rxtx.LockPolicy=strict # require lockfiles, throw exception if they cannot be created. The "default" policy would try to be as good a citizen as possible (create lockfiles if possible, create Kernel exclusive lock if possible), but without guarantee and without warning in case it fails creating any lock. The warning to stdout would be something like "Warning: RXTX failed to create a lockfile in /var/lock/LCK..ttyS0. Check file system permissions or specify -Dgnu.io.rxtx.LockfileDir in order to enable proper locking of serial ports against other applications". 3. Error Reporting out of RXTX * All errors acquiring a port are reported by means of a gnu.io.rxtx.PortInUseException on CommPortIdentifier#open(). * In case of missing permissions or other unexpected failure running through open(), the "currentOwner" field is filled with the String "Unexpected Error", and the message field of the exception is filled with a String like "/dev/ttyS0 : Permission denied in open()" or "/var/lock/LCK..ttyS0 : Permission denied in write()" * In case of properly running through open() but not being able to lock the port, the "currentOwner" field is populated with the name and PID of the external process locking the port if it can be obtained, or "Unknown Application" otherwise. In other words, I'm proposing to replace Sun's RuntimeException for reporting unexpected errors with a PortInUseException with the owner String set to "Unexpected Error" and detail information in the message field of the exception. In case any file system resource is related to the unexpected error, it must be mentioned first and separated by a " : " String such that clients can parse the actual file system resource out of the message automatically. I thought about subclassing PortInUseException to provide more error details and type-safe parsing of the affected resource but wasn't so sure about it in the end. What do others think about this proposal? Would it make more sense to throw a RuntimeException for unexpected errors, rather than a PortInUseException with the String "Unexpected Error" ? Do the proposed port locking policies make sense? Is the naming proper? I'll next work on a patch to implement the proposal (or any modification as discussed on this list). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080901/5d1811e0/attachment-0005.html From Steffen.DETTMER at ingenico.com Mon Sep 1 10:50:56 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 1 Sep 2008 18:50:56 +0200 Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> Message-ID: <20080901165055.GD17898@elberon.bln.de.ingenico.com> Hi, thanks for this nice list! * Oberhuber, Martin wrote on Mon, Sep 01, 2008 at 17:36 +0200: > 1. Neither the Sun nor the IBM implementation are really > useable in terms of port locking, since they do not > respect minicom. > 2. Sun's throwing a RuntimeException from > CommPortIdentifier.open() is undocumented and may break > client applications in an unexpected way. Yes, someone may expect a PortInUseException if the port is in use, but since RuntimeExceptions can be thrown always anyway, I think there is not much a client application can do than catching the `known expected' unexpected (unspecified by throws) exceptions. Client applications probably want to wrap CommPortIdentifier.open(), catching at least PortInUseException and/or RuntimeException and throwing a well-defined exception (that should also include the port name and/or other helpful detail for the user, such as why the access was tried etc) > 3. Kernel locks through fcntl are not sufficient for > minicom to keep it off the port. I think it could be sufficient if mandatory file locking is enabled (on systems that support it). Linux for instance in general should support mandatory file locking, but I don't know if it really works for device files. > 4. Kernel locks give no indication what application is > currently owning the port (lockfiles could give that > information but minicom does not evaluate it). > > Does anybody on this list know the difference between > fcntl(F_SETLK, {type=F_WRLCK}) > and > ioctl(fd, TIOCEXCL, 0); > ? maybe the first one could be considered more general (and modern :)), should work for all files and file systems and it is POSIX; the second one as some specific function of some serial/tty driver. I think on POSIX systems (whatever this means in practice), someone should be able to expect fcntl(F_SETLK, ...) to work, but no rule without an exception (sometimes, just exceptions without any rule ;)). ioctl TIOCEXCL prevents a second open (unless executed by root), but fcntl(F_SETLK) another F_SETLK (when advisory locking) or write (when mandatory locking). Some serial implementations do (or try) both. > What do folks think about throwing a RuntimeException from > CommPortIdentifier.open()? (I think it shows that those mandatory throws() clause and its exceptions were not the best ideas when defining the java language, sometimes workarounded by `throws Throwable' :)) I'd expect such an exception (only) in the fatal cases where an application usually cannot do anything reasonable, let's say some OutOfMemory (yes, this is an Error I know) or SecurityException. We had quite some issues with things like that (not rxtx related) and with applications catching RuntimeException (or even Throwable) on some high level sometimes resulting in strange effects, so I think it should be avoided, for instance, by wrapping calls to such methods, also needed to add more details about the region where the problem occured (often, higher layers know additional details more interesting for the user, for instance, why something was attempted, where it was configured or which subsystem tried it what for, ...). Unfortunality it is not always straightforward/possible to overwrite to get such a behavior. Actually, I think usually it is not that easy (either you cannot call a needed method because it is private or you cannot put your wrapper because the constructing class cannot be overwritten easily, ... etc). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From tjarvi at qbang.org Mon Sep 1 11:28:37 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 1 Sep 2008 11:28:37 -0600 (MDT) Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: <20080901165055.GD17898@elberon.bln.de.ingenico.com> References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> <20080901165055.GD17898@elberon.bln.de.ingenico.com> Message-ID: On Mon, 1 Sep 2008, Steffen DETTMER wrote: > >> 4. Kernel locks give no indication what application is >> currently owning the port (lockfiles could give that >> information but minicom does not evaluate it). >> >> Does anybody on this list know the difference between >> fcntl(F_SETLK, {type=F_WRLCK}) >> and >> ioctl(fd, TIOCEXCL, 0); >> ? > > maybe the first one could be considered more general (and modern > :)), should work for all files and file systems and it is POSIX; > the second one as some specific function of some serial/tty driver. > > I think on POSIX systems (whatever this means in practice), > someone should be able to expect fcntl(F_SETLK, ...) to work, but > no rule without an exception (sometimes, just exceptions without > any rule ;)). > > ioctl TIOCEXCL prevents a second open (unless executed by root), > but fcntl(F_SETLK) another F_SETLK (when advisory locking) or > write (when mandatory locking). Some serial implementations do > (or try) both. > I couldn't parse the last comment about F_SETLK. I guess you ment F_SETLK prevents other F_SETLK attempts (advisory) or writing (mandatory). Presumably that applies to all users. While F_SETLK is possibly something we can add, I just want to point out that the TIOCEXCL will work on all UNIX like systems and is very specific to our needs; it only applies to ttys. F_SETLK also appears to be used for other things like trying to lock portions of a file over networked filesystems. -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Mon Sep 1 11:33:53 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 1 Sep 2008 19:33:53 +0200 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> Message-ID: <20080901173353.GE17898@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Mon, Sep 01, 2008 at 18:05 +0200: > 2. Getting the settings into RXTX > > * Use Java System Properties for tuning behavior (since the RXTX / > javax.comm API is frozen): I think supporting -D system properties is a similar API change to add some new config-classes/method (except that system properties are better hidden :)). I'd like to add that spplications should be able to overwrite this (for instance, if they support config files or some GUI to configure it), here they could use setProperty. > * -Dgnu.io.rxtx.LockfileDir=/var/lock # specify location of > lockfile directory, similar to minicom > * -Dgnu.io.rxtx.LockPolicy=none # no port locking, no > warnings or anything > * -Dgnu.io.rxtx.LockPolicy=default # try lockfiles, in case of > missing permission fall back to kernel locks without warning > * -Dgnu.io.rxtx.LockPolicy=warn # try lockfiles, in case of > missing permission fall back to kernel locks with warning to stdout > * -Dgnu.io.rxtx.LockPolicy=strict # require lockfiles, throw > exception if they cannot be created. > > The "default" policy would try to be as good a citizen as possible > (create lockfiles if possible, create Kernel > exclusive lock if possible), but without guarantee and without warning > in case it fails creating any lock. Nice, I think the important things would be configurable then! so default is no one of `none', `warn' and `strict'? I think it could be confusing if `default' is an option that must explicitely given, maybe -Dgnu.io.rxtx.LockPolicy=automatic and making this the default (i.e. when it is given, actually nothing changes)? Well, just a minor detail. Another minor detail could be that here someone might think that two things are joined: first, what should happen if locking fails and second how to lock. Maybe it could be splitted. Additionally, somone could want to distinguish between `lock always' and `lock at use', but I'm not sure if the javax style API supports this. On a (non rxtx related but C++) implementation alternatively it was used to have a `Policy' (always, at use, none, default[here: depending on the device]) and a `Kind' (classes for UUCP-lockfile and kernel locks). So back to rxtx, maybe here an additional option like some -Dgnu.io.rxtx.LockKind = [file] [ioctl] [fcntl], maybe separated by "," or as ORed integer number, and LockPolicy=(none|any|all)? I'd dislike warnings to stdout (if so, stderr, but better logging, because it can be configured). stdout may not be avialable or used by some text mode UI or alike. For GUI-applications an english language message may not be sufficient but national language support may be required (I have no idea how to do this, just name it for the list). I think for logging (in contrast to stdout) in most cases english-only logs are acceptable. Anyway, this really are just minor things. Your proposal seems to support all important things and the naming is OK. > The warning to stdout would be something like "Warning: RXTX failed to > create a lockfile in /var/lock/LCK..ttyS0. Check file system permissions > or specify -Dgnu.io.rxtx.LockfileDir in order to enable proper locking > of serial ports against other applications". yes, nice! Maybe add the device port name that was tried to open (maybe it was something symbolic like `modem' or alike)? > 3. Error Reporting out of RXTX > > * All errors acquiring a port are reported by means of a > gnu.io.rxtx.PortInUseException on CommPortIdentifier#open(). Yes, I think better than RuntimeExceptions! > * In case of missing permissions or other unexpected failure > running through open(), the "currentOwner" field is filled with the > String "Unexpected Error", and the message field of the exception is > filled with a String like "/dev/ttyS0 : Permission denied in open()" or > "/var/lock/LCK..ttyS0 : Permission denied in write()" or maybe defining a subclass of PortInUseException? Then applications could (theoretically) catch the permission denied (lets say if someone wants to write a config GUI or application that autodetects if lock files can be used) > * In case of properly running through open() but not being able to > lock the port, the "currentOwner" field is populated with the name and > PID of the external process locking the port if it can be obtained, or > "Unknown Application" otherwise. > > In other words, I'm proposing to replace Sun's RuntimeException for > reporting unexpected errors with a PortInUseException with the owner > String set to "Unexpected Error" and detail information in the message > field of the exception. In case any file system resource is related to > the unexpected error, it must be mentioned first and separated by a " : > " String such that clients can parse the actual file system resource out > of the message automatically. (or adding a new method getLockPath() or so to PortInUseException) > I thought about subclassing PortInUseException to provide more error > details and type-safe parsing of the affected resource but wasn't so > sure about it in the end. Yes, intuitively I feel the same, like adding some String getPath() method to PortInUseException or a (new) subclass. In some unrelated thing we used exception message string contents parsing (was considered a hack from the beginning), some years later hit some problem in which made the error-detail-determination fail and replaced it completely by heaps of subclasses (BTW, the sources for the subclasses were automatically generated), that's why I'd use subclasses in case of doubt, but probably this has other disadvantages. Sometimes, the problem is that people later that use this API may not know any of those details and discussions, but if they see some special methods or subclasses in the javadoc or so, I think chances are higher that those situations are treated better, which may make users happier; also example programs / example code snippets can be helpful. > What do others think about this proposal? Would it make more > sense to throw a RuntimeException for unexpected errors, rather > than a PortInUseException with the String "Unexpected Error" ? I think, Exceptions should be used for unexpected conditions (excepted `exceptions' should be returned, e.g. by bool methods or alike). (unrelated here, but) Working with throw and catch IMHO is a kind of `goto' programming, actually even worse, and IMHO should not be used for the `good case' (such as searching a free port). Here, I think the throws() clause with PortInUseException simply is wrong. It should throw something more generic with PortInUseException beeing one subclass, but this would be an API change. For compatiblity, I could imagine a subclass of it. > Do the proposed port locking policies make sense? Is the naming > proper? Yes, for me it makes sense and is proper. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From Steffen.DETTMER at ingenico.com Mon Sep 1 11:50:48 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 1 Sep 2008 19:50:48 +0200 Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> <20080901165055.GD17898@elberon.bln.de.ingenico.com> Message-ID: <20080901175048.GF17898@elberon.bln.de.ingenico.com> * Trent Jarvi wrote on Mon, Sep 01, 2008 at 11:28 -0600: > >ioctl TIOCEXCL prevents a second open (unless executed by root), > >but fcntl(F_SETLK) another F_SETLK (when advisory locking) or > >write (when mandatory locking). > > I couldn't parse the last comment about F_SETLK. I guess you ment > F_SETLK prevents other F_SETLK attempts (advisory) or writing > (mandatory). Presumably that applies to all users. Yes, thanks for the clarification. > While F_SETLK is possibly something we can add, I just want to point > out that the TIOCEXCL will work on all UNIX like systems and is very > specific to our needs; it only applies to ttys. I guess F_SETLK could make sense if it would prevent minicom to work if mandatory locking is enabled, otherwise and if TIOCEXCL is working, F_SETLK probably doesn't make much sense, does it? Bad would be, I think, if on some system TIOCEXCL works, but F_SETLK fails (e.g. not supported or so) and in the end rxtx would throw some exception instead of opening the port, so adding it could require tests on exotic systems... oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From Martin.Oberhuber at windriver.com Wed Sep 3 11:33:54 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 3 Sep 2008 19:33:54 +0200 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <20080901173353.GE17898@elberon.bln.de.ingenico.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Hello Steffen, some comments: > I think supporting -D system properties is a similar API change > to add some new config-classes/method (except that system > properties are better hidden :)). Well the point is that if System Properties are set but not understood by a different runtime implementation, it doesn't hurt and you can still link against / run the program. Creating new config-classes creates a compile-time API change such that you cannot easily port the program to other API implementations any more. In my opinion, it is still important that programs which use RXTX can be ported to the Sun javax.comm APIs easily (that is, just by doing a String replace of sed -e 's,gnu\.io\.,javax.comm,g' on all files. Creating new classes or interfaces makes that impossible. What do others on this list think? Is this still important, or can we fork off javax.comm since that's not really maintained any more anyways? Note that especially on embedded devices (J2ME), many vendors provide native javax.comm implementations, so porting an RXTX based program onto such a J2ME vm is much easier if we restrict ourselves to the original API. > I'd like to add that spplications should be able to overwrite > this Well, they can always System.setProperty("gnu.io.rxtx.LockfileDir", "/foo/bar"); or similar. We're doing that in our commercial app in order to add ports which RXTX doesn't discover automatically. > so default is no one of `none', `warn' and `strict'? I think it We can discuss what the default should be, it can be any of the other options of course. I had proposed "default" to be the default :-) I usually like the default to be that it "just works without fuss" :-) > Another minor detail could be that here someone might think that > two things are joined: first, what should happen if locking fails > and second how to lock. Maybe it could be splitted. It could probably be splitted. But I didn't want to expose too many implementation details to the outside, nor make the interface (configuration) too complex. Note that different locking mechanisms could be available on different OS's; the user won't care about the mechanisms but what to do in case one of them fails (fallback to others with or without warning, or fail). So far, we've been clear that the right thing to do is (1) observe and create lockfiles for legacy clients, and then (2) do the right thing which is the Kernel Lock. I don't see a need for more configuration at this point. If we should see a necessity for more fine-grained configuration we can add that in the future. > Policy differentiate between `lock always' and `lock at use' We lock when the client opens the port, javax.comm does not provide an API for locking even without opening the port if that's what you mean, so this doesn't seem an option. > some -Dgnu.io.rxtx.LockKind = [file] [ioctl] [fcntl] I see no sense in trying some locks only. Applications should try to acquire every lock they are aware of, no? Note that we don't know what other apps are installed, so we need to use all mechansims we can. On a Platform where some mechanism is not available, it will be removed at compile-time anyways (configure script). If it's available at compile-time it should be used at runtime. > I'd dislike warnings to stdout (if so, stderr, but better > logging, because it can be configured). stdout may not be > avialable or used by some text mode UI or alike. I know, that's why I wouldn't make that option the default. And yes, of course we'd log to stderr and not stdout. > For GUI-applications an english language message may not be > sufficient but national language support may be required RXTX is low-level. Translation is up to the higher level client app. What I take from that is, that the client app should be able to receive exactly the same warnings that would otherwise go to stdout. My current proposal doesn't account for that... but actually, RXTX's Zystem class provides for configurable logging through the "gnu.io.log.mode" System Property. I'm just not exactly sure how Zystem is to be used, but it should work somehow... Trent, any help > yes, nice! Maybe add the device port name that was tried to open > (maybe it was something symbolic like `modem' or alike)? Hm... that might indeed help in some cases. Thanks for the hint. > or maybe defining a subclass of PortInUseException? > (or adding a new method getLockPath() or so to PortInUseException) Again, that's not possible if we want to be source compatible with javax.comm -- but I'm in favor of this proposal if the Community thinks that this is not so important any more? Thanks, Martin From johnny.luong at trustcommerce.com Wed Sep 3 12:54:17 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Wed, 03 Sep 2008 11:54:17 -0700 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: <48BEDD59.5000908@trustcommerce.com> Oberhuber, Martin wrote: > Creating new config-classes creates a compile-time API change > such that you cannot easily port the program to other API > implementations any more. > > In my opinion, it is still important that programs which use > RXTX can be ported to the Sun javax.comm APIs easily (that is, > just by doing a String replace of > sed -e 's,gnu\.io\.,javax.comm,g' > on all files. Creating new classes or interfaces makes that > impossible. > > What do others on this list think? Is this still important, > or can we fork off javax.comm since that's not really maintained > any more anyways? > > Note that especially on embedded devices (J2ME), many vendors > provide native javax.comm implementations, so porting an RXTX > based program onto such a J2ME vm is much easier if we restrict > ourselves to the original API. Hi, I think it wouldn't be difficult for a person to create a separate facade of the javax.comm interface which talks to the RXTX library and perhaps if someone is willing to share that, then it can be improved on. If someone needs the older interface now, there are alternatives, e.g: RXTX 2.0, Sun javax.comm, serialio.com, etc. I only use the gnu.io namespace anyways with respect to RXTX and perhaps if there is a strong enough interest, someone with the resources/time could go through the JSR/JCP as there are probably some level of variation on the J2ME implementations of the API. Best, Johnny From Steffen.DETTMER at ingenico.com Thu Sep 4 02:42:15 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 4 Sep 2008 10:42:15 +0200 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: <20080904084215.GF30569@elberon.bln.de.ingenico.com> Hi! please let me repeat that I wrote about minor details only. I'm afraid that too much discussion about the minor, unimportant details could take focus from the important points. I just can't resist :-) Summary of my long OT below is that for me your proposal is OK, except that applications should parse error or warning messages e.g. for translation (if I understood correctly). * Oberhuber, Martin wrote on Wed, Sep 03, 2008 at 19:33 +0200: > > I think supporting -D system properties is a similar API change > > to add some new config-classes/method (except that system > > properties are better hidden :)). > > Well the point is that if System Properties are set but not > understood by a different runtime implementation, it doesn't > hurt and you can still link against / run the program. In Java, I think adding new classes is not problem also. Now I'm not really sure, but I think adding new methods also does work. So I think in the end similar to adding support for new -D options old implementations simply don't use it. (but I'm not against -D, I wrote by comment just BTW) > Creating new config-classes creates a compile-time API change > such that you cannot easily port the program to other API > implementations any more. > > In my opinion, it is still important that programs which use > RXTX can be ported to the Sun javax.comm APIs easily (that is, > just by doing a String replace of > sed -e 's,gnu\.io\.,javax.comm,g' > on all files. Creating new classes or interfaces makes that > impossible. Do you really consider source code modifying with sed or some other kind of preprocessing be a common use? I don't think that such techniques are used by many Java developers. Also, in this case of course your changed implementation will compile, but it would fail at runtime, because no locking is available, so you would need to implement it around (which BTW IMHO isn't a bad idea anyway), having something on top that adds locking support and stuff. I mean, if locking support is considered that important that the application cares about it, let's say by offering a GUI and internally calling setProperty, the ported version needs to implement all this on its own, simply because otherwise all those functions would have no effect. But if another application does not care much about locking and uses the defaults only (i.e. is not using -D options), then it would work in both cases. just BTW #2: If support for some javax.comm is needed, I think wrappers/adapters are needed anyway: you could have one implementation for javax.comm, a second for gnu.io and a third for thirdparty something I/O. Well, since I consider those Java APIs beeing weak and uncomfortable, I think adapters on top of it is needed anyway, for instance, supporting timeouts. Not only in some `global timeout that throws an exception if reached' or so, but something reasonable, powerfull that can be used to implement serial protocols, for instance. So in summary, I think the API should support something that makes all those usages /possible/, like let's say an operating system, but it is /not/ a generic communication library which abstracts from communications, physical and logical links and APIs. > Note that especially on embedded devices (J2ME), many vendors > provide native javax.comm implementations, so porting an RXTX > based program onto such a J2ME vm is much easier if we restrict > ourselves to the original API. I would expect those APIs to behave different in detail, especially at timeouts, that a 1:1 port wouldn't be possible anyway (at least that are my limited experiences with embedded C libs). > > I'd like to add that spplications should be able to overwrite > > this > > Well, they can always System.setProperty("gnu.io.rxtx.LockfileDir", > "/foo/bar"); or similar. We're doing that in our commercial > app in order to add ports which RXTX doesn't discover automatically. Yes, but this only would LOOK as if it would work on let's say the embeeded port, but in fact it would do nothing (which in this example probably would be OK). The only think I dislike here is that you will not get a compiler error, so a colleguage who ports such software probably would miss if the application to be ported requires/supports a lockfile directory. > > so default is no one of `none', `warn' and `strict'? I think it > > We can discuss what the default should be, it can be any of the > other options of course. I had proposed "default" to be the > default :-) I usually like the default to be that it "just works > without fuss" :-) What I meant was that the default should also have some meaningful name. I think specifying `myoption=default' makes no sense, either it should not be given at all or it should be `myoption=concretevalue1' which could be the same as if not given at all, but has at least some documentary purposes and keeps working even if defaults are changes, and finnally thus the default option IMHO also should have a speaking name - but this also is just a minor detail. > > Another minor detail could be that here someone might think that > > two things are joined: first, what should happen if locking fails > > and second how to lock. Maybe it could be splitted. > > It could probably be splitted. But I didn't want to expose too many > implementation details to the outside, nor make the interface > (configuration) too complex. Yes, this is a good point. As the discussion here shows that it is complex library users would probably just get confused and set options wrongly. However, for specific applications specific things may be needed. In this cases according to your proposal it can be configured to use `none' and the specific application can implement whatever locking. So your proposal is fine! > Note that different locking mechanisms could be available on > different OS's; the user won't care about the mechanisms but > what to do in case one of them fails (fallback to others with > or without warning, or fail). Yes, but also has influence on the defaults, doesn't it? I think on windows noone expect some UUCP style lock files, right? Defaults of course must work on all major systems. > So far, we've been clear that the right thing to do is (1) observe > and create lockfiles for legacy clients, and then (2) do the right > thing which is the Kernel Lock. > I don't see a need for more configuration at this point. If we > should see a necessity for more fine-grained configuration we > can add that in the future. (kernel lock means TIOCEXCL, right?) would the file locking stuff be implemented in java in an overwriteable way? Anyway, as long as it can be disabled its ok. I think for applications that rely on that, for instance servers searching a free modem at some multiport card or alike, some special implementation probably is needed anyway. Yes, I think you are right, it should be kept simple. > > Policy differentiate between `lock always' and `lock at use' > > We lock when the client opens the port, javax.comm does not provide > an API for locking even without opening the port if that's what you > mean, so this doesn't seem an option. > > > some -Dgnu.io.rxtx.LockKind = [file] [ioctl] [fcntl] > > I see no sense in trying some locks only. Applications should try > to acquire every lock they are aware of, no? Note that we don't > know what other apps are installed, so we need to use all mechansims > we can. On a Platform where some mechanism is not available, it > will be removed at compile-time anyways (configure script). If it's > available at compile-time it should be used at runtime. Yes, but if a lock fails, how to know if it fails because the OS does not supports it or permissions are insufficient - or the port really is busy? Ignoring whether a lock could made probably makes not much sense, but aborting could lead to unsable rxtx (maybe on `broken' OSes only). But you are right, since it can be disabled, applications can implement around it what they need. > > For GUI-applications an english language message may not be > > sufficient but national language support may be required > > RXTX is low-level. > Translation is up to the higher level client > app. What I take from that is, that the client app should be > able to receive exactly the same warnings that would otherwise > go to stdout. to allow to parse the string? but what if the message is changed in the next version of rxtx? I found such constructions in some functions (unrelated to rxtx) and I had to search them because they didn't work, so I think parsing informal messages isn't a good idea, usually. > > or maybe defining a subclass of PortInUseException? > > (or adding a new method getLockPath() or so to PortInUseException) > > Again, that's not possible if we want to be source compatible > with javax.comm -- but I'm in favor of this proposal if the > Community thinks that this is not so important any more? OK. (ok, if you consider similar names in different java packages as compatible as you explained below with sed, yes, I see your point) just BTW again: I would not rely that no javax.comm.something implementation defines reasonable exceptions. I know that for some reason it is common in the Java world not to define too many reasonable exceptions, maybe because it is slow or writing all those .java files is too annoying and source code generation not known to many developers, don't know, but the APIs do not necessarily tell if additional classes are used for the implementation (and thus IMHO do not forbid to do so). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From petr.czekaj at vaecontrols.cz Thu Sep 4 07:07:11 2008 From: petr.czekaj at vaecontrols.cz (Petr Czekaj) Date: Thu, 4 Sep 2008 15:07:11 +0200 Subject: [Rxtx] Undisplay "Stable library" Message-ID: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> Hi, is there a way to use RXTX library without writing text: "Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7" into console window just after calling "getPortIdentifiers()" method? Thank you Peter -------------------------------------------- VAE Controls - mailto:info at vaecontrols.cz tel. +420 596 240 011 ; fax. +420 596 242 153 Tato zprava a pripadne prilohy jsou duverne a jsou vyhradne urceny pro pouziti adresata. Jestlize jste ji obdrzeli omylem, ozvete se prosim na vyse uvedenou adresu. Vsechny nazory a myslenky jsou vyhradne odesilatele a nemusi nutne prezentovat stanovisko VAE Controls s.r.o. VAE Controls si rezervuje veskera prava na monitoring elektronicke posty, prochazejici z/do vlastni firemni site. Tato zprava byla zkontrolovana antivirovym programem, nicmene firma VAE Controls neni zodpovedna za pripadne skody zpusobene prijmem nedetekovanych viru. CONFIDENTIALITY NOTICE: The information in this e-mail, including any attachment, is confidential and may be legally privileged. This e-mail is intended solely for the addressee. If you are not the addressee, dissemination, copying or other use of this e-mail or any of its content is strictly prohibited and may be unlawful. If you are not the intended recipient please inform the sender immediately and destroy the e-mail and any copies. E-mails and unencrypted attachments are scanned for all known viruses. Always scan e-mail attachments for viruses before opening them. All liability for viruses is excluded to the fullest extent permitted by law. Any views expressed in this message are those of the individual sender. -------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080904/10087013/attachment-0003.html From Martin.Oberhuber at windriver.com Thu Sep 4 07:34:45 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 4 Sep 2008 15:34:45 +0200 Subject: [Rxtx] Undisplay "Stable library" In-Reply-To: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> References: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> Message-ID: <460801A4097E3D4CA04CC64EE6485848075ABFE4@ism-mail03.corp.ad.wrs.com> You can do java -Dgnu.io.rxtx.NoVersionOutput or programmatically set that System Property in your App. Unfortunately the feature of muting the version info was added only shortly after releasing RXTX 2.1-7r2 so you either need to build RXTX from the sources out of CVS, or you get the Eclipse variant binaries from http://rxtx.qbang.org/eclipse/downloads Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Petr Czekaj Sent: Thursday, September 04, 2008 3:07 PM To: rxtx at qbang.org Subject: [Rxtx] Undisplay "Stable library" Hi, is there a way to use RXTX library without writing text: "Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7" into console window just after calling "getPortIdentifiers()" method? Thank you Peter -------------------------------------------- VAE Controls - mailto:info at vaecontrols.cz tel. +420 596 240 011 ; fax. +420 596 242 153 Tato zprava a pripadne prilohy jsou duverne a jsou vyhradne urceny pro pouziti adresata. Jestlize jste ji obdrzeli omylem, ozvete se prosim na vyse uvedenou adresu. Vsechny nazory a myslenky jsou vyhradne odesilatele a nemusi nutne prezentovat stanovisko VAE Controls s.r.o. VAE Controls si rezervuje veskera prava na monitoring elektronicke posty, prochazejici z/do vlastni firemni site. Tato zprava byla zkontrolovana antivirovym programem, nicmene firma VAE Controls neni zodpovedna za pripadne skody zpusobene prijmem nedetekovanych viru. CONFIDENTIALITY NOTICE: The information in this e-mail, including any attachment, is confidential and may be legally privileged. This e-mail is intended solely for the addressee. If you are not the addressee, dissemination, copying or other use of this e-mail or any of its content is strictly prohibited and may be unlawful. If you are not the intended recipient please inform the sender immediately and destroy the e-mail and any copies. E-mails and unencrypted attachments are scanned for all known viruses. Always scan e-mail attachments for viruses before opening them. All liability for viruses is excluded to the fullest extent permitted by law. Any views expressed in this message are those of the individual sender. -------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080904/d70fbd85/attachment-0002.html From michael.erskine at ketech.com Thu Sep 4 07:36:36 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Thu, 4 Sep 2008 14:36:36 +0100 Subject: [Rxtx] Undisplay "Stable library" In-Reply-To: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> References: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> Message-ID: <06BA3262D918014F9183B66425D5A8D43608077CBD@no-sv-03.ketech.local> > Hi, is there a way to use RXTX library without writing text: > "Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7" > > into console window just after calling "getPortIdentifiers()" method? Yes, prior to any calls that would cause the classloader to pull in RXTX, redirect standard output to a temporary PrintStream (with java.lang.System.setOut() ) and then restore later if required! Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Sep 5 14:18:30 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 5 Sep 2008 22:18:30 +0200 Subject: [Rxtx] Why does testRead() lock the port? Message-ID: <460801A4097E3D4CA04CC64EE6485848076760E1@ism-mail03.corp.ad.wrs.com> Hi all, When RXTX initializes, it scans available (serial) ports. It does so by calling a testRead() native method, which tries to open each port and get some settings. What I don't understand, is why in SerialImp.c line 4322 the code tries to LOCK the port in this context? The result seems to be, that if a different application (e.g. minicom) currently owns the port, the port won't even be scanned. Users don't see the port listed in their Java app and never get the idea that this might be due to another App currently owning the port. That doesn't seem desired, and port locking doesn't seem necessary since the code only reads the port. Does anybody have a clue why the port is locked here? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080905/c5c94c2d/attachment.html From shaney at basis.com Fri Sep 5 15:47:02 2008 From: shaney at basis.com (Shaun Haney) Date: Fri, 5 Sep 2008 15:47:02 -0600 Subject: [Rxtx] Rxtx is not finding serial ports on Solaris Message-ID: <07CB4F76556D489DBA9D17963C41CB0D@basis.com> Hi. I am wondering if anyone has tried using RXTX on Solaris/SPARC or Solaris/Intel. The problem that I am experiencing on both platforms is CommPortIdentifier.getPortIdentifiers() is returning a completely empty list of ports. On both systems, I have a modem attached to the serial port. The serial port device on both systems is /dev/cua/a. At the commandline, I can type 'echo "Hello There Nice Day Isnt it" > /dev/cua/a' and the modem will flicker indicating it's received information. The test program I am using is: ============================================================================ ========= // /SerialFinder.java // import gnu.io.*; import java.util.*; public class SerialFinder { public static final void main(String args[]) throws gnu.io.NoSuchPortException { Enumeration portList; CommPortIdentifier current; portList=CommPortIdentifier.getPortIdentifiers(); System.out.println("gnu.io.rxtx.SerialPorts="+System.getProperty("gnu.io.rxt x.SerialPorts")); System.out.println("List>>>"); while (portList.hasMoreElements()) { current=(CommPortIdentifier)portList.nextElement(); System.out.println(current.getName()); } System.out.println("<<>> << References: <07CB4F76556D489DBA9D17963C41CB0D@basis.com> Message-ID: <081660F391DA4B05A6DC90FCAF42403E@basis.com> I found some more information, so I thought I'd include it. It's Solaris 10/SunOS 5.10 on both the Sparc and Intel platforms that do not produce a list of ports. I just tried the same sample program on a Solaris 8 Intel machine and it listed /dev/term/a and /dev/term/b. Has anyone ever used RXTX on Solaris 10? Shaun Haney Software Test Engineer BASIS International Ltd. shaney at basis.com _____ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Shaun Haney Sent: Friday, September 05, 2008 3:47 PM To: rxtx at qbang.org Subject: [Rxtx] Rxtx is not finding serial ports on Solaris Hi. I am wondering if anyone has tried using RXTX on Solaris/SPARC or Solaris/Intel. The problem that I am experiencing on both platforms is CommPortIdentifier.getPortIdentifiers() is returning a completely empty list of ports. On both systems, I have a modem attached to the serial port. The serial port device on both systems is /dev/cua/a. At the commandline, I can type 'echo "Hello There Nice Day Isnt it" > /dev/cua/a' and the modem will flicker indicating it's received information. The test program I am using is: ============================================================================ ========= // /SerialFinder.java // import gnu.io.*; import java.util.*; public class SerialFinder { public static final void main(String args[]) throws gnu.io.NoSuchPortException { Enumeration portList; CommPortIdentifier current; portList=CommPortIdentifier.getPortIdentifiers(); System.out.println("gnu.io.rxtx.SerialPorts="+System.getProperty("gnu.io.rxt x.SerialPorts")); System.out.println("List>>>"); while (portList.hasMoreElements()) { current=(CommPortIdentifier)portList.nextElement(); System.out.println(current.getName()); } System.out.println("<<>> << References: <460801A4097E3D4CA04CC64EE6485848076760E1@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 5 Sep 2008, Oberhuber, Martin wrote: > Hi all, > > When RXTX initializes, it scans available (serial) ports. > It does so by calling a testRead() native method, which > tries to open each port and get some settings. > > What I don't understand, is why in SerialImp.c line 4322 > the code tries to LOCK the port in this context? > > The result seems to be, that if a different application (e.g. > minicom) currently owns the port, the port won't even be > scanned. Users don't see the port listed in their Java app > and never get the idea that this might be due to another > App currently owning the port. > > That doesn't seem desired, and port locking doesn't seem > necessary since the code only reads the port. > > Does anybody have a clue why the port is locked here? > Hi Martin, The port is locked because reading can cause problems for other applications. If a critical application opens a port and does a quick read (such as getting NMEA information from a GPS), some of the data will be taken by rxtx corrupting the incomming stream. The port scanning with locked ports is intended to behave the same on all systems. Windows will not enumerate a port if it is open by hyperterm also. I'm not against changing the reporting ports that are in use if a way is found to be consistant between systems. I think it must be possible as hyperterm can open ports rxtx has open as I recall. There are also the registry, hald and others that wouldnt require opening ports. I'm not sure that changing in a consitant way is going to be all that easy. More historical than important; when I put the code in, I figured if the port was locked, there was no way we could get the port for the user so there wasn't any point in reporting it as available. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 5 20:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 5 Sep 2008 20:38:30 -0600 (MDT) Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> Message-ID: On Mon, 1 Sep 2008, Oberhuber, Martin wrote: > Hi all, > > here is my proposal for improving port locking in RXTX. > > 1. Goals of the Proposal > > * Support enabling / disabling / configuring port locking at > runtime without re-compiling RXTX. > * Support port locking by Kernel call even if permissions for > lockfiles are not sufficient. > * Report exact reason for failure to acquire a port to the client > application (including the file system path of a lockfile for instance). > > 2. Getting the settings into RXTX > > * Use Java System Properties for tuning behavior (since the RXTX / > javax.comm API is frozen): > * -Dgnu.io.rxtx.LockfileDir=/var/lock # specify location of > lockfile directory, similar to minicom > * -Dgnu.io.rxtx.LockPolicy=none # no port locking, no > warnings or anything > * -Dgnu.io.rxtx.LockPolicy=default # try lockfiles, in case of > missing permission fall back to kernel locks without warning > * -Dgnu.io.rxtx.LockPolicy=warn # try lockfiles, in case of > missing permission fall back to kernel locks with warning to stdout > * -Dgnu.io.rxtx.LockPolicy=strict # require lockfiles, throw > exception if they cannot be created. > > The "default" policy would try to be as good a citizen as possible > (create lockfiles if possible, create Kernel > exclusive lock if possible), but without guarantee and without warning > in case it fails creating any lock. > > The warning to stdout would be something like "Warning: RXTX failed to > create a lockfile in /var/lock/LCK..ttyS0. Check file system permissions > or specify -Dgnu.io.rxtx.LockfileDir in order to enable proper locking > of serial ports against other applications". > > 3. Error Reporting out of RXTX > > * All errors acquiring a port are reported by means of a > gnu.io.rxtx.PortInUseException on CommPortIdentifier#open(). > * In case of missing permissions or other unexpected failure > running through open(), the "currentOwner" field is filled with the > String "Unexpected Error", and the message field of the exception is > filled with a String like "/dev/ttyS0 : Permission denied in open()" or > "/var/lock/LCK..ttyS0 : Permission denied in write()" > * In case of properly running through open() but not being able to > lock the port, the "currentOwner" field is populated with the name and > PID of the external process locking the port if it can be obtained, or > "Unknown Application" otherwise. > > In other words, I'm proposing to replace Sun's RuntimeException for > reporting unexpected errors with a PortInUseException with the owner > String set to "Unexpected Error" and detail information in the message > field of the exception. In case any file system resource is related to > the unexpected error, it must be mentioned first and separated by a " : > " String such that clients can parse the actual file system resource out > of the message automatically. > > I thought about subclassing PortInUseException to provide more error > details and type-safe parsing of the affected resource but wasn't so > sure about it in the end. > > What do others think about this proposal? Would it make more sense to > throw a RuntimeException for unexpected errors, rather than a > PortInUseException with the String "Unexpected Error" ? Do the proposed > port locking policies make sense? Is the naming proper? > > I'll next work on a patch to implement the proposal (or any modification > as discussed on this list). > This is all fine by me. You may want to look at Werner Almesberger's code in src/psmisc. He gave permission to use that code in RXTX. But a better solution would be something that was in a shared library provided by distros. The psmisc code reports PID and application name when the port is in use. It probably has a bit of bitrot and is not light reading. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 5 20:42:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 5 Sep 2008 20:42:45 -0600 (MDT) Subject: [Rxtx] [Suspected Spam][Blocked Sender]Re: Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <460801A4097E3D4CA04CC64EE6485848074C4259@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com><13557-75390@sneakemail.com><20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> <460801A4097E3D4CA04CC64EE6485848074C4259@ism-mail03.corp.ad.wrs.com> Message-ID: No problems here. Sounds great. On Mon, 1 Sep 2008, Oberhuber, Martin wrote: > Hi Bruce, > > I think that the only way to avoid temparary disconnect during port > scanning, > is to avoid the temporary open() during port scanning. That, however, > can only > be avoided if there is some external means to enumerate the candidates > for > valid port names. > > The javax.comm implementations by Sun and IBM use a file named > "javax.comm.properties" for this. On Linux and Solaris, it enumerates > the allowed prefixes for device names to be used. Those prefixes known, > the library treats all existing files with such prefixes as valid ports, > without > trying to actually open them. See http://java.sun.com/products/javacomm/ > > I'd think that one option to simplify the port scanning would be to use > a Java System Property to specify the Policy for port scanning. > For instance: > -Dgnu.io.rxtx.PortScanningPolicy=read # try to open & read > scanned ports > -Dgnu.io.rxtx.PortScanningPolicy=existing # treat ports as valid if > they exist > > For enumerating the candidates to check, the "gnu.io.rxtx.properties" > file already exists as well as the "gnu.io.rxtx.SerialPorts" and > "gnu.io.rxtx.ParallelPorts" System Properties. These support > explicit enumeration of port candidates. > > So, a second possible enhancement in addition to support > specifying the PortScanningPolicy could be to support > specifying prefix names for port enumeration rather than > just explicit enumeration. > > What do others think about these ideas? Could these improve > the long-standing performance issues with USB / Bluetooth > adapters during port scanning? Why does RXTX try to open > scanned ports in the first place, rather than relying on plain > existence of the devices? > > I'd guess that a Patch providing these enhancements would be > appreciated by the RXTX community. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > > ________________________________ > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On > Behalf Of Bruce Boyes > Sent: Tuesday, August 05, 2008 3:13 AM > To: Rxtx at qbang.org > Subject: [Suspected Spam][Blocked Sender]Re: [Rxtx] Towards an > RXTX release - CSR BT/USB chipset > > > At 18:37 07/29/2008, you wrote: > > > All, > > Is there any chance that the next official release could > improve on the port scanning (getPortIdentifiers)? > > > It would be nice if rxtx could also not cause a > connect/disconnect and subsequent problems with a USB Bluetooth > BlueSoleil adapter (using the CSR chipset), as documented in a previous > email from me. > > best regards > > Bruce > > > > ------- WWW.SYSTRONIX.COM > ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > From tjarvi at qbang.org Fri Sep 5 21:03:03 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 5 Sep 2008 21:03:03 -0600 (MDT) Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: > I'm just not exactly sure how Zystem is to be used, but it > should work somehow... Trent, any help Zystem was a total hack (Zystem is System with the S turned around) to get critical timing information out of RXTX for debugging. I never committed the source, but most of Zystem's functionality for me was yanked out of Python's native code and used as a one off debug tool to timestamp events. I submited the Java shell with options for turning on and off debugging. There would have been license issues with submitting the timestamp code. Since then some others have contributed pieces in that add j2ee logging and such. I think Zystem would be usable if some static vars came from properties with quiet defaults. The main place Zystem is used is in RXTXPort.java right now.. These may not make sense anymore. We could jerrymander (alter) the flags to suit new needs. protected final static boolean debug = false; protected final static boolean debug_read = false; protected final static boolean debug_read_results = false; protected final static boolean debug_write = false; protected final static boolean debug_events = false; protected final static boolean debug_verbose = false; private static Zystem z; static { try { z = new Zystem(); } catch ( Exception e ) {}; if(debug ) z.reportln( "RXTXPort {}"); ... I no longer have plans for Zystem. If something shipping with the JRE makes more sense, we could take it out. If it is close enough to fit into a new role, we can alter it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 5 21:40:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 5 Sep 2008 21:40:42 -0600 (MDT) Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: > In my opinion, it is still important that programs which use > RXTX can be ported to the Sun javax.comm APIs easily (that is, > just by doing a String replace of > sed -e 's,gnu\.io\.,javax.comm,g' > on all files. Creating new classes or interfaces makes that > impossible. > > What do others on this list think? Is this still important, > or can we fork off javax.comm since that's not really maintained > any more anyways? > > Note that especially on embedded devices (J2ME), many vendors > provide native javax.comm implementations, so porting an RXTX > based program onto such a J2ME vm is much easier if we restrict > ourselves to the original API. > In the end, everyone has a say. Answering what I think. I would consider breaking away from javax.comm 2.0 to be when we should call a version rxtx 3.0. I know you mentioned wanting to call the next release 3.0 but that really is for letting people know we intentionally broke the API. Right now, I suspect that doing so will not be a win in the end for users or developers. I have no problem starting a 3.0 branch to see what happens. Let it turn, churn and burn. If it becomes popular all the better. Until such a venture is obviously better, we should probably be conservative. Communicating such a final transition should be very deliberate if we do it. Just pulling the rug out from under existing applications would not be nice. We can add, extend, offer hooks for changing behavior and more without breaking applications using rxtx 2.1. We can become more liberal with such extensions - the rules for what is right have most definitely changed by example. Until it is obviously impossible to work with what we have, I'd suggest going that route. Any such features should probably be downplayed so applications can work realitivley easily on things like J2ME solutions as you mentioned. In the end, it would be nice to agree with other solutions what is right. We should remain very receptive towards such efforts and perhaps lead one if we have the resources. Multiple different solutions will hurt everyone. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 5 22:13:01 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 5 Sep 2008 22:13:01 -0600 (MDT) Subject: [Rxtx] Test bins comming soon. Message-ID: I've been working on getting rxtx binaries together for Win64 and Maci64. This has gone fairly well. There are some minor bugs I'll be reporting in bugzilla and fixing. I'd like to put out a 2.1-8pre1 collection of bins Sunday. We can discuss the version information also. Please start a new thread if you would like to discuss that. I assume we will be making a few of these regardless of the version. If there is something you would like to get in to the first iteration, you may want to let me know. I'm assuming there will be more changes comming. I just want to start the process so it isn't a big deal when the time comes. I also have some minor fixes that will be comming in after the first prerelease. I'll be putting those in bugzilla also. Obviously, Martin has work he is looking into that would be comming. My actual coding efforts will be more along the lines of cleaning up minor details in rxtx that are long standing bugs. I have a list of about 5 minor bugs not yet in bugzilla but in rxtx I want to clean up. If I have more time, I'll see what I can do for others also. What do people think about having the mail-list cc'd when there are new bugs and or changes to bugs? The activity is low enough for now that it shouldn't be a significant increase in traffic. Right now, it all goes into my inbox. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Mon Sep 1 08:59:20 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 1 Sep 2008 16:59:20 +0200 Subject: [Rxtx] [Suspected Spam][Blocked Sender]Re: Towards an RXTX release - CSR BT/USB chipset In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com><13557-75390@sneakemail.com><20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848074C4259@ism-mail03.corp.ad.wrs.com> Hi Bruce, I think that the only way to avoid temparary disconnect during port scanning, is to avoid the temporary open() during port scanning. That, however, can only be avoided if there is some external means to enumerate the candidates for valid port names. The javax.comm implementations by Sun and IBM use a file named "javax.comm.properties" for this. On Linux and Solaris, it enumerates the allowed prefixes for device names to be used. Those prefixes known, the library treats all existing files with such prefixes as valid ports, without trying to actually open them. See http://java.sun.com/products/javacomm/ I'd think that one option to simplify the port scanning would be to use a Java System Property to specify the Policy for port scanning. For instance: -Dgnu.io.rxtx.PortScanningPolicy=read # try to open & read scanned ports -Dgnu.io.rxtx.PortScanningPolicy=existing # treat ports as valid if they exist For enumerating the candidates to check, the "gnu.io.rxtx.properties" file already exists as well as the "gnu.io.rxtx.SerialPorts" and "gnu.io.rxtx.ParallelPorts" System Properties. These support explicit enumeration of port candidates. So, a second possible enhancement in addition to support specifying the PortScanningPolicy could be to support specifying prefix names for port enumeration rather than just explicit enumeration. What do others think about these ideas? Could these improve the long-standing performance issues with USB / Bluetooth adapters during port scanning? Why does RXTX try to open scanned ports in the first place, rather than relying on plain existence of the devices? I'd guess that a Patch providing these enhancements would be appreciated by the RXTX community. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Bruce Boyes Sent: Tuesday, August 05, 2008 3:13 AM To: Rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender]Re: [Rxtx] Towards an RXTX release - CSR BT/USB chipset At 18:37 07/29/2008, you wrote: All, Is there any chance that the next official release could improve on the port scanning (getPortIdentifiers)? It would be nice if rxtx could also not cause a connect/disconnect and subsequent problems with a USB Bluetooth BlueSoleil adapter (using the CSR chipset), as documented in a previous email from me. best regards Bruce ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080901/f3cb9a8e/attachment-0006.html From Martin.Oberhuber at windriver.com Mon Sep 1 09:36:31 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 1 Sep 2008 17:36:31 +0200 Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> Hi all, I made some experiments with the Sun and IBM implementations of javax.comm (on Linux and Solaris), in order to understand how these treat port locking and lockfiles and in what way they report failure to obtain a port to the client. Here are the results: * Neither Sun nor IBM check or create any lockfiles. As a result, minicom can open the same serial port as my test java application without error. * Sun uses Kernel locking with fcntl, according to an strace (truss) that I had run with my test app: open("/dev/ttyS1", O_RDWR|O_NONBLOCK|O_EXCL) = 5 fcntl64(5, F_SETLK, {type=F_WRLCK, ...}) = 0 As a result, multiple instances of the same Java test program are protected against each other; minicom, however, is *not* protected since it does open("/dev/ttyS1", O_RDWR|O_NONBLOCK) on Linux RHEL 4 at least. * IBM seems to use some memory sharing between multiple instances of Java programs: CommPortOwnershipListener is called even if a different instance of the program tries to access the port. No port locking of any kind seems to be done though. As a result, IBM apps are protected against each other but not against minicom. * When opening a port fails due to missing permissions on the device file, or due to an exclusive lock owned by another instance of itself, - IBM throws a PortInUseException after the timeout (currentOwner="Unknown Application") - Sun throws a java.lang.RuntimeException immediately (message=one of the following two: "\n Error opening \"/dev/ttyS1\"\n Permission denied" "\n Error opening \"/dev/cua/a\"\n Error in lockf()" What I learn from this is that 1. Neither the Sun nor the IBM implementation are really useable in terms of port locking, since they do not respect minicom. 2. Sun's throwing a RuntimeException from CommPortIdentifier.open() is undocumented and may break client applications in an unexpected way. 3. Kernel locks through fcntl are not sufficient for minicom to keep it off the port. 4. Kernel locks give no indication what application is currently owning the port (lockfiles could give that information but minicom does not evaluate it). Does anybody on this list know the difference between fcntl(F_SETLK, {type=F_WRLCK}) and ioctl(fd, TIOCEXCL, 0); ? What do folks think about throwing a RuntimeException from CommPortIdentifier.open() ? I'll follow up with a separate E-Mail proposing a strategy for RXTX to handle port locking. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, July 30, 2008 4:16 AM > To: Oberhuber, Martin > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Port locking on Linux: Redhat lockdev-baudboy > Instead, I would suggest we do an exclusive open and try to > lock as is if > lockfiles are not disabled. Warn if the lock fails. Always respect > lockfiles prior to opening. > > Exclusive opens should work on linux, mac, sol, bsd, ... > > The code is simple and does not introduce any new dependencies. > > ... > open > ... > do { > res = ioctl(fd, TIOCEXCL, 0); > } while ( (errno == EINTR || errno == EAGAIN ) && res != 0 ); > > > if( res != 0 ) > fail > > > In the worst case, minicom or another application may not be > able to find a lockfile but their open will fail. We locked > the port. Other applications may not do this so we should > always respect lockfiles. > > -- > Trent Jarvi > tjarvi at qbang.org > From Martin.Oberhuber at windriver.com Mon Sep 1 10:05:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 1 Sep 2008 18:05:02 +0200 Subject: [Rxtx] RXTX Port Locking Improvements Message-ID: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> Hi all, here is my proposal for improving port locking in RXTX. 1. Goals of the Proposal * Support enabling / disabling / configuring port locking at runtime without re-compiling RXTX. * Support port locking by Kernel call even if permissions for lockfiles are not sufficient. * Report exact reason for failure to acquire a port to the client application (including the file system path of a lockfile for instance). 2. Getting the settings into RXTX * Use Java System Properties for tuning behavior (since the RXTX / javax.comm API is frozen): * -Dgnu.io.rxtx.LockfileDir=/var/lock # specify location of lockfile directory, similar to minicom * -Dgnu.io.rxtx.LockPolicy=none # no port locking, no warnings or anything * -Dgnu.io.rxtx.LockPolicy=default # try lockfiles, in case of missing permission fall back to kernel locks without warning * -Dgnu.io.rxtx.LockPolicy=warn # try lockfiles, in case of missing permission fall back to kernel locks with warning to stdout * -Dgnu.io.rxtx.LockPolicy=strict # require lockfiles, throw exception if they cannot be created. The "default" policy would try to be as good a citizen as possible (create lockfiles if possible, create Kernel exclusive lock if possible), but without guarantee and without warning in case it fails creating any lock. The warning to stdout would be something like "Warning: RXTX failed to create a lockfile in /var/lock/LCK..ttyS0. Check file system permissions or specify -Dgnu.io.rxtx.LockfileDir in order to enable proper locking of serial ports against other applications". 3. Error Reporting out of RXTX * All errors acquiring a port are reported by means of a gnu.io.rxtx.PortInUseException on CommPortIdentifier#open(). * In case of missing permissions or other unexpected failure running through open(), the "currentOwner" field is filled with the String "Unexpected Error", and the message field of the exception is filled with a String like "/dev/ttyS0 : Permission denied in open()" or "/var/lock/LCK..ttyS0 : Permission denied in write()" * In case of properly running through open() but not being able to lock the port, the "currentOwner" field is populated with the name and PID of the external process locking the port if it can be obtained, or "Unknown Application" otherwise. In other words, I'm proposing to replace Sun's RuntimeException for reporting unexpected errors with a PortInUseException with the owner String set to "Unexpected Error" and detail information in the message field of the exception. In case any file system resource is related to the unexpected error, it must be mentioned first and separated by a " : " String such that clients can parse the actual file system resource out of the message automatically. I thought about subclassing PortInUseException to provide more error details and type-safe parsing of the affected resource but wasn't so sure about it in the end. What do others think about this proposal? Would it make more sense to throw a RuntimeException for unexpected errors, rather than a PortInUseException with the String "Unexpected Error" ? Do the proposed port locking policies make sense? Is the naming proper? I'll next work on a patch to implement the proposal (or any modification as discussed on this list). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080901/5d1811e0/attachment-0006.html From Steffen.DETTMER at ingenico.com Mon Sep 1 10:50:56 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 1 Sep 2008 18:50:56 +0200 Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> Message-ID: <20080901165055.GD17898@elberon.bln.de.ingenico.com> Hi, thanks for this nice list! * Oberhuber, Martin wrote on Mon, Sep 01, 2008 at 17:36 +0200: > 1. Neither the Sun nor the IBM implementation are really > useable in terms of port locking, since they do not > respect minicom. > 2. Sun's throwing a RuntimeException from > CommPortIdentifier.open() is undocumented and may break > client applications in an unexpected way. Yes, someone may expect a PortInUseException if the port is in use, but since RuntimeExceptions can be thrown always anyway, I think there is not much a client application can do than catching the `known expected' unexpected (unspecified by throws) exceptions. Client applications probably want to wrap CommPortIdentifier.open(), catching at least PortInUseException and/or RuntimeException and throwing a well-defined exception (that should also include the port name and/or other helpful detail for the user, such as why the access was tried etc) > 3. Kernel locks through fcntl are not sufficient for > minicom to keep it off the port. I think it could be sufficient if mandatory file locking is enabled (on systems that support it). Linux for instance in general should support mandatory file locking, but I don't know if it really works for device files. > 4. Kernel locks give no indication what application is > currently owning the port (lockfiles could give that > information but minicom does not evaluate it). > > Does anybody on this list know the difference between > fcntl(F_SETLK, {type=F_WRLCK}) > and > ioctl(fd, TIOCEXCL, 0); > ? maybe the first one could be considered more general (and modern :)), should work for all files and file systems and it is POSIX; the second one as some specific function of some serial/tty driver. I think on POSIX systems (whatever this means in practice), someone should be able to expect fcntl(F_SETLK, ...) to work, but no rule without an exception (sometimes, just exceptions without any rule ;)). ioctl TIOCEXCL prevents a second open (unless executed by root), but fcntl(F_SETLK) another F_SETLK (when advisory locking) or write (when mandatory locking). Some serial implementations do (or try) both. > What do folks think about throwing a RuntimeException from > CommPortIdentifier.open()? (I think it shows that those mandatory throws() clause and its exceptions were not the best ideas when defining the java language, sometimes workarounded by `throws Throwable' :)) I'd expect such an exception (only) in the fatal cases where an application usually cannot do anything reasonable, let's say some OutOfMemory (yes, this is an Error I know) or SecurityException. We had quite some issues with things like that (not rxtx related) and with applications catching RuntimeException (or even Throwable) on some high level sometimes resulting in strange effects, so I think it should be avoided, for instance, by wrapping calls to such methods, also needed to add more details about the region where the problem occured (often, higher layers know additional details more interesting for the user, for instance, why something was attempted, where it was configured or which subsystem tried it what for, ...). Unfortunality it is not always straightforward/possible to overwrite to get such a behavior. Actually, I think usually it is not that easy (either you cannot call a needed method because it is private or you cannot put your wrapper because the constructing class cannot be overwritten easily, ... etc). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From tjarvi at qbang.org Mon Sep 1 11:28:37 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 1 Sep 2008 11:28:37 -0600 (MDT) Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: <20080901165055.GD17898@elberon.bln.de.ingenico.com> References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> <20080901165055.GD17898@elberon.bln.de.ingenico.com> Message-ID: On Mon, 1 Sep 2008, Steffen DETTMER wrote: > >> 4. Kernel locks give no indication what application is >> currently owning the port (lockfiles could give that >> information but minicom does not evaluate it). >> >> Does anybody on this list know the difference between >> fcntl(F_SETLK, {type=F_WRLCK}) >> and >> ioctl(fd, TIOCEXCL, 0); >> ? > > maybe the first one could be considered more general (and modern > :)), should work for all files and file systems and it is POSIX; > the second one as some specific function of some serial/tty driver. > > I think on POSIX systems (whatever this means in practice), > someone should be able to expect fcntl(F_SETLK, ...) to work, but > no rule without an exception (sometimes, just exceptions without > any rule ;)). > > ioctl TIOCEXCL prevents a second open (unless executed by root), > but fcntl(F_SETLK) another F_SETLK (when advisory locking) or > write (when mandatory locking). Some serial implementations do > (or try) both. > I couldn't parse the last comment about F_SETLK. I guess you ment F_SETLK prevents other F_SETLK attempts (advisory) or writing (mandatory). Presumably that applies to all users. While F_SETLK is possibly something we can add, I just want to point out that the TIOCEXCL will work on all UNIX like systems and is very specific to our needs; it only applies to ttys. F_SETLK also appears to be used for other things like trying to lock portions of a file over networked filesystems. -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Mon Sep 1 11:33:53 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 1 Sep 2008 19:33:53 +0200 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> Message-ID: <20080901173353.GE17898@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Mon, Sep 01, 2008 at 18:05 +0200: > 2. Getting the settings into RXTX > > * Use Java System Properties for tuning behavior (since the RXTX / > javax.comm API is frozen): I think supporting -D system properties is a similar API change to add some new config-classes/method (except that system properties are better hidden :)). I'd like to add that spplications should be able to overwrite this (for instance, if they support config files or some GUI to configure it), here they could use setProperty. > * -Dgnu.io.rxtx.LockfileDir=/var/lock # specify location of > lockfile directory, similar to minicom > * -Dgnu.io.rxtx.LockPolicy=none # no port locking, no > warnings or anything > * -Dgnu.io.rxtx.LockPolicy=default # try lockfiles, in case of > missing permission fall back to kernel locks without warning > * -Dgnu.io.rxtx.LockPolicy=warn # try lockfiles, in case of > missing permission fall back to kernel locks with warning to stdout > * -Dgnu.io.rxtx.LockPolicy=strict # require lockfiles, throw > exception if they cannot be created. > > The "default" policy would try to be as good a citizen as possible > (create lockfiles if possible, create Kernel > exclusive lock if possible), but without guarantee and without warning > in case it fails creating any lock. Nice, I think the important things would be configurable then! so default is no one of `none', `warn' and `strict'? I think it could be confusing if `default' is an option that must explicitely given, maybe -Dgnu.io.rxtx.LockPolicy=automatic and making this the default (i.e. when it is given, actually nothing changes)? Well, just a minor detail. Another minor detail could be that here someone might think that two things are joined: first, what should happen if locking fails and second how to lock. Maybe it could be splitted. Additionally, somone could want to distinguish between `lock always' and `lock at use', but I'm not sure if the javax style API supports this. On a (non rxtx related but C++) implementation alternatively it was used to have a `Policy' (always, at use, none, default[here: depending on the device]) and a `Kind' (classes for UUCP-lockfile and kernel locks). So back to rxtx, maybe here an additional option like some -Dgnu.io.rxtx.LockKind = [file] [ioctl] [fcntl], maybe separated by "," or as ORed integer number, and LockPolicy=(none|any|all)? I'd dislike warnings to stdout (if so, stderr, but better logging, because it can be configured). stdout may not be avialable or used by some text mode UI or alike. For GUI-applications an english language message may not be sufficient but national language support may be required (I have no idea how to do this, just name it for the list). I think for logging (in contrast to stdout) in most cases english-only logs are acceptable. Anyway, this really are just minor things. Your proposal seems to support all important things and the naming is OK. > The warning to stdout would be something like "Warning: RXTX failed to > create a lockfile in /var/lock/LCK..ttyS0. Check file system permissions > or specify -Dgnu.io.rxtx.LockfileDir in order to enable proper locking > of serial ports against other applications". yes, nice! Maybe add the device port name that was tried to open (maybe it was something symbolic like `modem' or alike)? > 3. Error Reporting out of RXTX > > * All errors acquiring a port are reported by means of a > gnu.io.rxtx.PortInUseException on CommPortIdentifier#open(). Yes, I think better than RuntimeExceptions! > * In case of missing permissions or other unexpected failure > running through open(), the "currentOwner" field is filled with the > String "Unexpected Error", and the message field of the exception is > filled with a String like "/dev/ttyS0 : Permission denied in open()" or > "/var/lock/LCK..ttyS0 : Permission denied in write()" or maybe defining a subclass of PortInUseException? Then applications could (theoretically) catch the permission denied (lets say if someone wants to write a config GUI or application that autodetects if lock files can be used) > * In case of properly running through open() but not being able to > lock the port, the "currentOwner" field is populated with the name and > PID of the external process locking the port if it can be obtained, or > "Unknown Application" otherwise. > > In other words, I'm proposing to replace Sun's RuntimeException for > reporting unexpected errors with a PortInUseException with the owner > String set to "Unexpected Error" and detail information in the message > field of the exception. In case any file system resource is related to > the unexpected error, it must be mentioned first and separated by a " : > " String such that clients can parse the actual file system resource out > of the message automatically. (or adding a new method getLockPath() or so to PortInUseException) > I thought about subclassing PortInUseException to provide more error > details and type-safe parsing of the affected resource but wasn't so > sure about it in the end. Yes, intuitively I feel the same, like adding some String getPath() method to PortInUseException or a (new) subclass. In some unrelated thing we used exception message string contents parsing (was considered a hack from the beginning), some years later hit some problem in which made the error-detail-determination fail and replaced it completely by heaps of subclasses (BTW, the sources for the subclasses were automatically generated), that's why I'd use subclasses in case of doubt, but probably this has other disadvantages. Sometimes, the problem is that people later that use this API may not know any of those details and discussions, but if they see some special methods or subclasses in the javadoc or so, I think chances are higher that those situations are treated better, which may make users happier; also example programs / example code snippets can be helpful. > What do others think about this proposal? Would it make more > sense to throw a RuntimeException for unexpected errors, rather > than a PortInUseException with the String "Unexpected Error" ? I think, Exceptions should be used for unexpected conditions (excepted `exceptions' should be returned, e.g. by bool methods or alike). (unrelated here, but) Working with throw and catch IMHO is a kind of `goto' programming, actually even worse, and IMHO should not be used for the `good case' (such as searching a free port). Here, I think the throws() clause with PortInUseException simply is wrong. It should throw something more generic with PortInUseException beeing one subclass, but this would be an API change. For compatiblity, I could imagine a subclass of it. > Do the proposed port locking policies make sense? Is the naming > proper? Yes, for me it makes sense and is proper. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From Steffen.DETTMER at ingenico.com Mon Sep 1 11:50:48 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 1 Sep 2008 19:50:48 +0200 Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> <20080901165055.GD17898@elberon.bln.de.ingenico.com> Message-ID: <20080901175048.GF17898@elberon.bln.de.ingenico.com> * Trent Jarvi wrote on Mon, Sep 01, 2008 at 11:28 -0600: > >ioctl TIOCEXCL prevents a second open (unless executed by root), > >but fcntl(F_SETLK) another F_SETLK (when advisory locking) or > >write (when mandatory locking). > > I couldn't parse the last comment about F_SETLK. I guess you ment > F_SETLK prevents other F_SETLK attempts (advisory) or writing > (mandatory). Presumably that applies to all users. Yes, thanks for the clarification. > While F_SETLK is possibly something we can add, I just want to point > out that the TIOCEXCL will work on all UNIX like systems and is very > specific to our needs; it only applies to ttys. I guess F_SETLK could make sense if it would prevent minicom to work if mandatory locking is enabled, otherwise and if TIOCEXCL is working, F_SETLK probably doesn't make much sense, does it? Bad would be, I think, if on some system TIOCEXCL works, but F_SETLK fails (e.g. not supported or so) and in the end rxtx would throw some exception instead of opening the port, so adding it could require tests on exotic systems... oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From Martin.Oberhuber at windriver.com Wed Sep 3 11:33:54 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 3 Sep 2008 19:33:54 +0200 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <20080901173353.GE17898@elberon.bln.de.ingenico.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Hello Steffen, some comments: > I think supporting -D system properties is a similar API change > to add some new config-classes/method (except that system > properties are better hidden :)). Well the point is that if System Properties are set but not understood by a different runtime implementation, it doesn't hurt and you can still link against / run the program. Creating new config-classes creates a compile-time API change such that you cannot easily port the program to other API implementations any more. In my opinion, it is still important that programs which use RXTX can be ported to the Sun javax.comm APIs easily (that is, just by doing a String replace of sed -e 's,gnu\.io\.,javax.comm,g' on all files. Creating new classes or interfaces makes that impossible. What do others on this list think? Is this still important, or can we fork off javax.comm since that's not really maintained any more anyways? Note that especially on embedded devices (J2ME), many vendors provide native javax.comm implementations, so porting an RXTX based program onto such a J2ME vm is much easier if we restrict ourselves to the original API. > I'd like to add that spplications should be able to overwrite > this Well, they can always System.setProperty("gnu.io.rxtx.LockfileDir", "/foo/bar"); or similar. We're doing that in our commercial app in order to add ports which RXTX doesn't discover automatically. > so default is no one of `none', `warn' and `strict'? I think it We can discuss what the default should be, it can be any of the other options of course. I had proposed "default" to be the default :-) I usually like the default to be that it "just works without fuss" :-) > Another minor detail could be that here someone might think that > two things are joined: first, what should happen if locking fails > and second how to lock. Maybe it could be splitted. It could probably be splitted. But I didn't want to expose too many implementation details to the outside, nor make the interface (configuration) too complex. Note that different locking mechanisms could be available on different OS's; the user won't care about the mechanisms but what to do in case one of them fails (fallback to others with or without warning, or fail). So far, we've been clear that the right thing to do is (1) observe and create lockfiles for legacy clients, and then (2) do the right thing which is the Kernel Lock. I don't see a need for more configuration at this point. If we should see a necessity for more fine-grained configuration we can add that in the future. > Policy differentiate between `lock always' and `lock at use' We lock when the client opens the port, javax.comm does not provide an API for locking even without opening the port if that's what you mean, so this doesn't seem an option. > some -Dgnu.io.rxtx.LockKind = [file] [ioctl] [fcntl] I see no sense in trying some locks only. Applications should try to acquire every lock they are aware of, no? Note that we don't know what other apps are installed, so we need to use all mechansims we can. On a Platform where some mechanism is not available, it will be removed at compile-time anyways (configure script). If it's available at compile-time it should be used at runtime. > I'd dislike warnings to stdout (if so, stderr, but better > logging, because it can be configured). stdout may not be > avialable or used by some text mode UI or alike. I know, that's why I wouldn't make that option the default. And yes, of course we'd log to stderr and not stdout. > For GUI-applications an english language message may not be > sufficient but national language support may be required RXTX is low-level. Translation is up to the higher level client app. What I take from that is, that the client app should be able to receive exactly the same warnings that would otherwise go to stdout. My current proposal doesn't account for that... but actually, RXTX's Zystem class provides for configurable logging through the "gnu.io.log.mode" System Property. I'm just not exactly sure how Zystem is to be used, but it should work somehow... Trent, any help > yes, nice! Maybe add the device port name that was tried to open > (maybe it was something symbolic like `modem' or alike)? Hm... that might indeed help in some cases. Thanks for the hint. > or maybe defining a subclass of PortInUseException? > (or adding a new method getLockPath() or so to PortInUseException) Again, that's not possible if we want to be source compatible with javax.comm -- but I'm in favor of this proposal if the Community thinks that this is not so important any more? Thanks, Martin From johnny.luong at trustcommerce.com Wed Sep 3 12:54:17 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Wed, 03 Sep 2008 11:54:17 -0700 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: <48BEDD59.5000908@trustcommerce.com> Oberhuber, Martin wrote: > Creating new config-classes creates a compile-time API change > such that you cannot easily port the program to other API > implementations any more. > > In my opinion, it is still important that programs which use > RXTX can be ported to the Sun javax.comm APIs easily (that is, > just by doing a String replace of > sed -e 's,gnu\.io\.,javax.comm,g' > on all files. Creating new classes or interfaces makes that > impossible. > > What do others on this list think? Is this still important, > or can we fork off javax.comm since that's not really maintained > any more anyways? > > Note that especially on embedded devices (J2ME), many vendors > provide native javax.comm implementations, so porting an RXTX > based program onto such a J2ME vm is much easier if we restrict > ourselves to the original API. Hi, I think it wouldn't be difficult for a person to create a separate facade of the javax.comm interface which talks to the RXTX library and perhaps if someone is willing to share that, then it can be improved on. If someone needs the older interface now, there are alternatives, e.g: RXTX 2.0, Sun javax.comm, serialio.com, etc. I only use the gnu.io namespace anyways with respect to RXTX and perhaps if there is a strong enough interest, someone with the resources/time could go through the JSR/JCP as there are probably some level of variation on the J2ME implementations of the API. Best, Johnny From Steffen.DETTMER at ingenico.com Thu Sep 4 02:42:15 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 4 Sep 2008 10:42:15 +0200 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: <20080904084215.GF30569@elberon.bln.de.ingenico.com> Hi! please let me repeat that I wrote about minor details only. I'm afraid that too much discussion about the minor, unimportant details could take focus from the important points. I just can't resist :-) Summary of my long OT below is that for me your proposal is OK, except that applications should parse error or warning messages e.g. for translation (if I understood correctly). * Oberhuber, Martin wrote on Wed, Sep 03, 2008 at 19:33 +0200: > > I think supporting -D system properties is a similar API change > > to add some new config-classes/method (except that system > > properties are better hidden :)). > > Well the point is that if System Properties are set but not > understood by a different runtime implementation, it doesn't > hurt and you can still link against / run the program. In Java, I think adding new classes is not problem also. Now I'm not really sure, but I think adding new methods also does work. So I think in the end similar to adding support for new -D options old implementations simply don't use it. (but I'm not against -D, I wrote by comment just BTW) > Creating new config-classes creates a compile-time API change > such that you cannot easily port the program to other API > implementations any more. > > In my opinion, it is still important that programs which use > RXTX can be ported to the Sun javax.comm APIs easily (that is, > just by doing a String replace of > sed -e 's,gnu\.io\.,javax.comm,g' > on all files. Creating new classes or interfaces makes that > impossible. Do you really consider source code modifying with sed or some other kind of preprocessing be a common use? I don't think that such techniques are used by many Java developers. Also, in this case of course your changed implementation will compile, but it would fail at runtime, because no locking is available, so you would need to implement it around (which BTW IMHO isn't a bad idea anyway), having something on top that adds locking support and stuff. I mean, if locking support is considered that important that the application cares about it, let's say by offering a GUI and internally calling setProperty, the ported version needs to implement all this on its own, simply because otherwise all those functions would have no effect. But if another application does not care much about locking and uses the defaults only (i.e. is not using -D options), then it would work in both cases. just BTW #2: If support for some javax.comm is needed, I think wrappers/adapters are needed anyway: you could have one implementation for javax.comm, a second for gnu.io and a third for thirdparty something I/O. Well, since I consider those Java APIs beeing weak and uncomfortable, I think adapters on top of it is needed anyway, for instance, supporting timeouts. Not only in some `global timeout that throws an exception if reached' or so, but something reasonable, powerfull that can be used to implement serial protocols, for instance. So in summary, I think the API should support something that makes all those usages /possible/, like let's say an operating system, but it is /not/ a generic communication library which abstracts from communications, physical and logical links and APIs. > Note that especially on embedded devices (J2ME), many vendors > provide native javax.comm implementations, so porting an RXTX > based program onto such a J2ME vm is much easier if we restrict > ourselves to the original API. I would expect those APIs to behave different in detail, especially at timeouts, that a 1:1 port wouldn't be possible anyway (at least that are my limited experiences with embedded C libs). > > I'd like to add that spplications should be able to overwrite > > this > > Well, they can always System.setProperty("gnu.io.rxtx.LockfileDir", > "/foo/bar"); or similar. We're doing that in our commercial > app in order to add ports which RXTX doesn't discover automatically. Yes, but this only would LOOK as if it would work on let's say the embeeded port, but in fact it would do nothing (which in this example probably would be OK). The only think I dislike here is that you will not get a compiler error, so a colleguage who ports such software probably would miss if the application to be ported requires/supports a lockfile directory. > > so default is no one of `none', `warn' and `strict'? I think it > > We can discuss what the default should be, it can be any of the > other options of course. I had proposed "default" to be the > default :-) I usually like the default to be that it "just works > without fuss" :-) What I meant was that the default should also have some meaningful name. I think specifying `myoption=default' makes no sense, either it should not be given at all or it should be `myoption=concretevalue1' which could be the same as if not given at all, but has at least some documentary purposes and keeps working even if defaults are changes, and finnally thus the default option IMHO also should have a speaking name - but this also is just a minor detail. > > Another minor detail could be that here someone might think that > > two things are joined: first, what should happen if locking fails > > and second how to lock. Maybe it could be splitted. > > It could probably be splitted. But I didn't want to expose too many > implementation details to the outside, nor make the interface > (configuration) too complex. Yes, this is a good point. As the discussion here shows that it is complex library users would probably just get confused and set options wrongly. However, for specific applications specific things may be needed. In this cases according to your proposal it can be configured to use `none' and the specific application can implement whatever locking. So your proposal is fine! > Note that different locking mechanisms could be available on > different OS's; the user won't care about the mechanisms but > what to do in case one of them fails (fallback to others with > or without warning, or fail). Yes, but also has influence on the defaults, doesn't it? I think on windows noone expect some UUCP style lock files, right? Defaults of course must work on all major systems. > So far, we've been clear that the right thing to do is (1) observe > and create lockfiles for legacy clients, and then (2) do the right > thing which is the Kernel Lock. > I don't see a need for more configuration at this point. If we > should see a necessity for more fine-grained configuration we > can add that in the future. (kernel lock means TIOCEXCL, right?) would the file locking stuff be implemented in java in an overwriteable way? Anyway, as long as it can be disabled its ok. I think for applications that rely on that, for instance servers searching a free modem at some multiport card or alike, some special implementation probably is needed anyway. Yes, I think you are right, it should be kept simple. > > Policy differentiate between `lock always' and `lock at use' > > We lock when the client opens the port, javax.comm does not provide > an API for locking even without opening the port if that's what you > mean, so this doesn't seem an option. > > > some -Dgnu.io.rxtx.LockKind = [file] [ioctl] [fcntl] > > I see no sense in trying some locks only. Applications should try > to acquire every lock they are aware of, no? Note that we don't > know what other apps are installed, so we need to use all mechansims > we can. On a Platform where some mechanism is not available, it > will be removed at compile-time anyways (configure script). If it's > available at compile-time it should be used at runtime. Yes, but if a lock fails, how to know if it fails because the OS does not supports it or permissions are insufficient - or the port really is busy? Ignoring whether a lock could made probably makes not much sense, but aborting could lead to unsable rxtx (maybe on `broken' OSes only). But you are right, since it can be disabled, applications can implement around it what they need. > > For GUI-applications an english language message may not be > > sufficient but national language support may be required > > RXTX is low-level. > Translation is up to the higher level client > app. What I take from that is, that the client app should be > able to receive exactly the same warnings that would otherwise > go to stdout. to allow to parse the string? but what if the message is changed in the next version of rxtx? I found such constructions in some functions (unrelated to rxtx) and I had to search them because they didn't work, so I think parsing informal messages isn't a good idea, usually. > > or maybe defining a subclass of PortInUseException? > > (or adding a new method getLockPath() or so to PortInUseException) > > Again, that's not possible if we want to be source compatible > with javax.comm -- but I'm in favor of this proposal if the > Community thinks that this is not so important any more? OK. (ok, if you consider similar names in different java packages as compatible as you explained below with sed, yes, I see your point) just BTW again: I would not rely that no javax.comm.something implementation defines reasonable exceptions. I know that for some reason it is common in the Java world not to define too many reasonable exceptions, maybe because it is slow or writing all those .java files is too annoying and source code generation not known to many developers, don't know, but the APIs do not necessarily tell if additional classes are used for the implementation (and thus IMHO do not forbid to do so). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From petr.czekaj at vaecontrols.cz Thu Sep 4 07:07:11 2008 From: petr.czekaj at vaecontrols.cz (Petr Czekaj) Date: Thu, 4 Sep 2008 15:07:11 +0200 Subject: [Rxtx] Undisplay "Stable library" Message-ID: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> Hi, is there a way to use RXTX library without writing text: "Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7" into console window just after calling "getPortIdentifiers()" method? Thank you Peter -------------------------------------------- VAE Controls - mailto:info at vaecontrols.cz tel. +420 596 240 011 ; fax. +420 596 242 153 Tato zprava a pripadne prilohy jsou duverne a jsou vyhradne urceny pro pouziti adresata. Jestlize jste ji obdrzeli omylem, ozvete se prosim na vyse uvedenou adresu. Vsechny nazory a myslenky jsou vyhradne odesilatele a nemusi nutne prezentovat stanovisko VAE Controls s.r.o. VAE Controls si rezervuje veskera prava na monitoring elektronicke posty, prochazejici z/do vlastni firemni site. Tato zprava byla zkontrolovana antivirovym programem, nicmene firma VAE Controls neni zodpovedna za pripadne skody zpusobene prijmem nedetekovanych viru. CONFIDENTIALITY NOTICE: The information in this e-mail, including any attachment, is confidential and may be legally privileged. This e-mail is intended solely for the addressee. If you are not the addressee, dissemination, copying or other use of this e-mail or any of its content is strictly prohibited and may be unlawful. If you are not the intended recipient please inform the sender immediately and destroy the e-mail and any copies. E-mails and unencrypted attachments are scanned for all known viruses. Always scan e-mail attachments for viruses before opening them. All liability for viruses is excluded to the fullest extent permitted by law. Any views expressed in this message are those of the individual sender. -------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080904/10087013/attachment-0004.html From Martin.Oberhuber at windriver.com Thu Sep 4 07:34:45 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 4 Sep 2008 15:34:45 +0200 Subject: [Rxtx] Undisplay "Stable library" In-Reply-To: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> References: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> Message-ID: <460801A4097E3D4CA04CC64EE6485848075ABFE4@ism-mail03.corp.ad.wrs.com> You can do java -Dgnu.io.rxtx.NoVersionOutput or programmatically set that System Property in your App. Unfortunately the feature of muting the version info was added only shortly after releasing RXTX 2.1-7r2 so you either need to build RXTX from the sources out of CVS, or you get the Eclipse variant binaries from http://rxtx.qbang.org/eclipse/downloads Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Petr Czekaj Sent: Thursday, September 04, 2008 3:07 PM To: rxtx at qbang.org Subject: [Rxtx] Undisplay "Stable library" Hi, is there a way to use RXTX library without writing text: "Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7" into console window just after calling "getPortIdentifiers()" method? Thank you Peter -------------------------------------------- VAE Controls - mailto:info at vaecontrols.cz tel. +420 596 240 011 ; fax. +420 596 242 153 Tato zprava a pripadne prilohy jsou duverne a jsou vyhradne urceny pro pouziti adresata. Jestlize jste ji obdrzeli omylem, ozvete se prosim na vyse uvedenou adresu. Vsechny nazory a myslenky jsou vyhradne odesilatele a nemusi nutne prezentovat stanovisko VAE Controls s.r.o. VAE Controls si rezervuje veskera prava na monitoring elektronicke posty, prochazejici z/do vlastni firemni site. Tato zprava byla zkontrolovana antivirovym programem, nicmene firma VAE Controls neni zodpovedna za pripadne skody zpusobene prijmem nedetekovanych viru. CONFIDENTIALITY NOTICE: The information in this e-mail, including any attachment, is confidential and may be legally privileged. This e-mail is intended solely for the addressee. If you are not the addressee, dissemination, copying or other use of this e-mail or any of its content is strictly prohibited and may be unlawful. If you are not the intended recipient please inform the sender immediately and destroy the e-mail and any copies. E-mails and unencrypted attachments are scanned for all known viruses. Always scan e-mail attachments for viruses before opening them. All liability for viruses is excluded to the fullest extent permitted by law. Any views expressed in this message are those of the individual sender. -------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080904/d70fbd85/attachment-0003.html From michael.erskine at ketech.com Thu Sep 4 07:36:36 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Thu, 4 Sep 2008 14:36:36 +0100 Subject: [Rxtx] Undisplay "Stable library" In-Reply-To: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> References: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> Message-ID: <06BA3262D918014F9183B66425D5A8D43608077CBD@no-sv-03.ketech.local> > Hi, is there a way to use RXTX library without writing text: > "Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7" > > into console window just after calling "getPortIdentifiers()" method? Yes, prior to any calls that would cause the classloader to pull in RXTX, redirect standard output to a temporary PrintStream (with java.lang.System.setOut() ) and then restore later if required! Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Sep 5 14:18:30 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 5 Sep 2008 22:18:30 +0200 Subject: [Rxtx] Why does testRead() lock the port? Message-ID: <460801A4097E3D4CA04CC64EE6485848076760E1@ism-mail03.corp.ad.wrs.com> Hi all, When RXTX initializes, it scans available (serial) ports. It does so by calling a testRead() native method, which tries to open each port and get some settings. What I don't understand, is why in SerialImp.c line 4322 the code tries to LOCK the port in this context? The result seems to be, that if a different application (e.g. minicom) currently owns the port, the port won't even be scanned. Users don't see the port listed in their Java app and never get the idea that this might be due to another App currently owning the port. That doesn't seem desired, and port locking doesn't seem necessary since the code only reads the port. Does anybody have a clue why the port is locked here? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080905/c5c94c2d/attachment-0002.html From shaney at basis.com Fri Sep 5 15:47:02 2008 From: shaney at basis.com (Shaun Haney) Date: Fri, 5 Sep 2008 15:47:02 -0600 Subject: [Rxtx] Rxtx is not finding serial ports on Solaris Message-ID: <07CB4F76556D489DBA9D17963C41CB0D@basis.com> Hi. I am wondering if anyone has tried using RXTX on Solaris/SPARC or Solaris/Intel. The problem that I am experiencing on both platforms is CommPortIdentifier.getPortIdentifiers() is returning a completely empty list of ports. On both systems, I have a modem attached to the serial port. The serial port device on both systems is /dev/cua/a. At the commandline, I can type 'echo "Hello There Nice Day Isnt it" > /dev/cua/a' and the modem will flicker indicating it's received information. The test program I am using is: ============================================================================ ========= // /SerialFinder.java // import gnu.io.*; import java.util.*; public class SerialFinder { public static final void main(String args[]) throws gnu.io.NoSuchPortException { Enumeration portList; CommPortIdentifier current; portList=CommPortIdentifier.getPortIdentifiers(); System.out.println("gnu.io.rxtx.SerialPorts="+System.getProperty("gnu.io.rxt x.SerialPorts")); System.out.println("List>>>"); while (portList.hasMoreElements()) { current=(CommPortIdentifier)portList.nextElement(); System.out.println(current.getName()); } System.out.println("<<>> << References: <07CB4F76556D489DBA9D17963C41CB0D@basis.com> Message-ID: <081660F391DA4B05A6DC90FCAF42403E@basis.com> I found some more information, so I thought I'd include it. It's Solaris 10/SunOS 5.10 on both the Sparc and Intel platforms that do not produce a list of ports. I just tried the same sample program on a Solaris 8 Intel machine and it listed /dev/term/a and /dev/term/b. Has anyone ever used RXTX on Solaris 10? Shaun Haney Software Test Engineer BASIS International Ltd. shaney at basis.com _____ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Shaun Haney Sent: Friday, September 05, 2008 3:47 PM To: rxtx at qbang.org Subject: [Rxtx] Rxtx is not finding serial ports on Solaris Hi. I am wondering if anyone has tried using RXTX on Solaris/SPARC or Solaris/Intel. The problem that I am experiencing on both platforms is CommPortIdentifier.getPortIdentifiers() is returning a completely empty list of ports. On both systems, I have a modem attached to the serial port. The serial port device on both systems is /dev/cua/a. At the commandline, I can type 'echo "Hello There Nice Day Isnt it" > /dev/cua/a' and the modem will flicker indicating it's received information. The test program I am using is: ============================================================================ ========= // /SerialFinder.java // import gnu.io.*; import java.util.*; public class SerialFinder { public static final void main(String args[]) throws gnu.io.NoSuchPortException { Enumeration portList; CommPortIdentifier current; portList=CommPortIdentifier.getPortIdentifiers(); System.out.println("gnu.io.rxtx.SerialPorts="+System.getProperty("gnu.io.rxt x.SerialPorts")); System.out.println("List>>>"); while (portList.hasMoreElements()) { current=(CommPortIdentifier)portList.nextElement(); System.out.println(current.getName()); } System.out.println("<<>> << References: <460801A4097E3D4CA04CC64EE6485848076760E1@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 5 Sep 2008, Oberhuber, Martin wrote: > Hi all, > > When RXTX initializes, it scans available (serial) ports. > It does so by calling a testRead() native method, which > tries to open each port and get some settings. > > What I don't understand, is why in SerialImp.c line 4322 > the code tries to LOCK the port in this context? > > The result seems to be, that if a different application (e.g. > minicom) currently owns the port, the port won't even be > scanned. Users don't see the port listed in their Java app > and never get the idea that this might be due to another > App currently owning the port. > > That doesn't seem desired, and port locking doesn't seem > necessary since the code only reads the port. > > Does anybody have a clue why the port is locked here? > Hi Martin, The port is locked because reading can cause problems for other applications. If a critical application opens a port and does a quick read (such as getting NMEA information from a GPS), some of the data will be taken by rxtx corrupting the incomming stream. The port scanning with locked ports is intended to behave the same on all systems. Windows will not enumerate a port if it is open by hyperterm also. I'm not against changing the reporting ports that are in use if a way is found to be consistant between systems. I think it must be possible as hyperterm can open ports rxtx has open as I recall. There are also the registry, hald and others that wouldnt require opening ports. I'm not sure that changing in a consitant way is going to be all that easy. More historical than important; when I put the code in, I figured if the port was locked, there was no way we could get the port for the user so there wasn't any point in reporting it as available. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 5 20:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 5 Sep 2008 20:38:30 -0600 (MDT) Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> Message-ID: On Mon, 1 Sep 2008, Oberhuber, Martin wrote: > Hi all, > > here is my proposal for improving port locking in RXTX. > > 1. Goals of the Proposal > > * Support enabling / disabling / configuring port locking at > runtime without re-compiling RXTX. > * Support port locking by Kernel call even if permissions for > lockfiles are not sufficient. > * Report exact reason for failure to acquire a port to the client > application (including the file system path of a lockfile for instance). > > 2. Getting the settings into RXTX > > * Use Java System Properties for tuning behavior (since the RXTX / > javax.comm API is frozen): > * -Dgnu.io.rxtx.LockfileDir=/var/lock # specify location of > lockfile directory, similar to minicom > * -Dgnu.io.rxtx.LockPolicy=none # no port locking, no > warnings or anything > * -Dgnu.io.rxtx.LockPolicy=default # try lockfiles, in case of > missing permission fall back to kernel locks without warning > * -Dgnu.io.rxtx.LockPolicy=warn # try lockfiles, in case of > missing permission fall back to kernel locks with warning to stdout > * -Dgnu.io.rxtx.LockPolicy=strict # require lockfiles, throw > exception if they cannot be created. > > The "default" policy would try to be as good a citizen as possible > (create lockfiles if possible, create Kernel > exclusive lock if possible), but without guarantee and without warning > in case it fails creating any lock. > > The warning to stdout would be something like "Warning: RXTX failed to > create a lockfile in /var/lock/LCK..ttyS0. Check file system permissions > or specify -Dgnu.io.rxtx.LockfileDir in order to enable proper locking > of serial ports against other applications". > > 3. Error Reporting out of RXTX > > * All errors acquiring a port are reported by means of a > gnu.io.rxtx.PortInUseException on CommPortIdentifier#open(). > * In case of missing permissions or other unexpected failure > running through open(), the "currentOwner" field is filled with the > String "Unexpected Error", and the message field of the exception is > filled with a String like "/dev/ttyS0 : Permission denied in open()" or > "/var/lock/LCK..ttyS0 : Permission denied in write()" > * In case of properly running through open() but not being able to > lock the port, the "currentOwner" field is populated with the name and > PID of the external process locking the port if it can be obtained, or > "Unknown Application" otherwise. > > In other words, I'm proposing to replace Sun's RuntimeException for > reporting unexpected errors with a PortInUseException with the owner > String set to "Unexpected Error" and detail information in the message > field of the exception. In case any file system resource is related to > the unexpected error, it must be mentioned first and separated by a " : > " String such that clients can parse the actual file system resource out > of the message automatically. > > I thought about subclassing PortInUseException to provide more error > details and type-safe parsing of the affected resource but wasn't so > sure about it in the end. > > What do others think about this proposal? Would it make more sense to > throw a RuntimeException for unexpected errors, rather than a > PortInUseException with the String "Unexpected Error" ? Do the proposed > port locking policies make sense? Is the naming proper? > > I'll next work on a patch to implement the proposal (or any modification > as discussed on this list). > This is all fine by me. You may want to look at Werner Almesberger's code in src/psmisc. He gave permission to use that code in RXTX. But a better solution would be something that was in a shared library provided by distros. The psmisc code reports PID and application name when the port is in use. It probably has a bit of bitrot and is not light reading. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 5 20:42:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 5 Sep 2008 20:42:45 -0600 (MDT) Subject: [Rxtx] [Suspected Spam][Blocked Sender]Re: Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <460801A4097E3D4CA04CC64EE6485848074C4259@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com><13557-75390@sneakemail.com><20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> <460801A4097E3D4CA04CC64EE6485848074C4259@ism-mail03.corp.ad.wrs.com> Message-ID: No problems here. Sounds great. On Mon, 1 Sep 2008, Oberhuber, Martin wrote: > Hi Bruce, > > I think that the only way to avoid temparary disconnect during port > scanning, > is to avoid the temporary open() during port scanning. That, however, > can only > be avoided if there is some external means to enumerate the candidates > for > valid port names. > > The javax.comm implementations by Sun and IBM use a file named > "javax.comm.properties" for this. On Linux and Solaris, it enumerates > the allowed prefixes for device names to be used. Those prefixes known, > the library treats all existing files with such prefixes as valid ports, > without > trying to actually open them. See http://java.sun.com/products/javacomm/ > > I'd think that one option to simplify the port scanning would be to use > a Java System Property to specify the Policy for port scanning. > For instance: > -Dgnu.io.rxtx.PortScanningPolicy=read # try to open & read > scanned ports > -Dgnu.io.rxtx.PortScanningPolicy=existing # treat ports as valid if > they exist > > For enumerating the candidates to check, the "gnu.io.rxtx.properties" > file already exists as well as the "gnu.io.rxtx.SerialPorts" and > "gnu.io.rxtx.ParallelPorts" System Properties. These support > explicit enumeration of port candidates. > > So, a second possible enhancement in addition to support > specifying the PortScanningPolicy could be to support > specifying prefix names for port enumeration rather than > just explicit enumeration. > > What do others think about these ideas? Could these improve > the long-standing performance issues with USB / Bluetooth > adapters during port scanning? Why does RXTX try to open > scanned ports in the first place, rather than relying on plain > existence of the devices? > > I'd guess that a Patch providing these enhancements would be > appreciated by the RXTX community. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > > ________________________________ > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On > Behalf Of Bruce Boyes > Sent: Tuesday, August 05, 2008 3:13 AM > To: Rxtx at qbang.org > Subject: [Suspected Spam][Blocked Sender]Re: [Rxtx] Towards an > RXTX release - CSR BT/USB chipset > > > At 18:37 07/29/2008, you wrote: > > > All, > > Is there any chance that the next official release could > improve on the port scanning (getPortIdentifiers)? > > > It would be nice if rxtx could also not cause a > connect/disconnect and subsequent problems with a USB Bluetooth > BlueSoleil adapter (using the CSR chipset), as documented in a previous > email from me. > > best regards > > Bruce > > > > ------- WWW.SYSTRONIX.COM > ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > From tjarvi at qbang.org Fri Sep 5 21:03:03 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 5 Sep 2008 21:03:03 -0600 (MDT) Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: > I'm just not exactly sure how Zystem is to be used, but it > should work somehow... Trent, any help Zystem was a total hack (Zystem is System with the S turned around) to get critical timing information out of RXTX for debugging. I never committed the source, but most of Zystem's functionality for me was yanked out of Python's native code and used as a one off debug tool to timestamp events. I submited the Java shell with options for turning on and off debugging. There would have been license issues with submitting the timestamp code. Since then some others have contributed pieces in that add j2ee logging and such. I think Zystem would be usable if some static vars came from properties with quiet defaults. The main place Zystem is used is in RXTXPort.java right now.. These may not make sense anymore. We could jerrymander (alter) the flags to suit new needs. protected final static boolean debug = false; protected final static boolean debug_read = false; protected final static boolean debug_read_results = false; protected final static boolean debug_write = false; protected final static boolean debug_events = false; protected final static boolean debug_verbose = false; private static Zystem z; static { try { z = new Zystem(); } catch ( Exception e ) {}; if(debug ) z.reportln( "RXTXPort {}"); ... I no longer have plans for Zystem. If something shipping with the JRE makes more sense, we could take it out. If it is close enough to fit into a new role, we can alter it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 5 21:40:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 5 Sep 2008 21:40:42 -0600 (MDT) Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: > In my opinion, it is still important that programs which use > RXTX can be ported to the Sun javax.comm APIs easily (that is, > just by doing a String replace of > sed -e 's,gnu\.io\.,javax.comm,g' > on all files. Creating new classes or interfaces makes that > impossible. > > What do others on this list think? Is this still important, > or can we fork off javax.comm since that's not really maintained > any more anyways? > > Note that especially on embedded devices (J2ME), many vendors > provide native javax.comm implementations, so porting an RXTX > based program onto such a J2ME vm is much easier if we restrict > ourselves to the original API. > In the end, everyone has a say. Answering what I think. I would consider breaking away from javax.comm 2.0 to be when we should call a version rxtx 3.0. I know you mentioned wanting to call the next release 3.0 but that really is for letting people know we intentionally broke the API. Right now, I suspect that doing so will not be a win in the end for users or developers. I have no problem starting a 3.0 branch to see what happens. Let it turn, churn and burn. If it becomes popular all the better. Until such a venture is obviously better, we should probably be conservative. Communicating such a final transition should be very deliberate if we do it. Just pulling the rug out from under existing applications would not be nice. We can add, extend, offer hooks for changing behavior and more without breaking applications using rxtx 2.1. We can become more liberal with such extensions - the rules for what is right have most definitely changed by example. Until it is obviously impossible to work with what we have, I'd suggest going that route. Any such features should probably be downplayed so applications can work realitivley easily on things like J2ME solutions as you mentioned. In the end, it would be nice to agree with other solutions what is right. We should remain very receptive towards such efforts and perhaps lead one if we have the resources. Multiple different solutions will hurt everyone. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 5 22:13:01 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 5 Sep 2008 22:13:01 -0600 (MDT) Subject: [Rxtx] Test bins comming soon. Message-ID: I've been working on getting rxtx binaries together for Win64 and Maci64. This has gone fairly well. There are some minor bugs I'll be reporting in bugzilla and fixing. I'd like to put out a 2.1-8pre1 collection of bins Sunday. We can discuss the version information also. Please start a new thread if you would like to discuss that. I assume we will be making a few of these regardless of the version. If there is something you would like to get in to the first iteration, you may want to let me know. I'm assuming there will be more changes comming. I just want to start the process so it isn't a big deal when the time comes. I also have some minor fixes that will be comming in after the first prerelease. I'll be putting those in bugzilla also. Obviously, Martin has work he is looking into that would be comming. My actual coding efforts will be more along the lines of cleaning up minor details in rxtx that are long standing bugs. I have a list of about 5 minor bugs not yet in bugzilla but in rxtx I want to clean up. If I have more time, I'll see what I can do for others also. What do people think about having the mail-list cc'd when there are new bugs and or changes to bugs? The activity is low enough for now that it shouldn't be a significant increase in traffic. Right now, it all goes into my inbox. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Sat Sep 6 14:46:57 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 6 Sep 2008 22:46:57 +0200 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584807676151@ism-mail03.corp.ad.wrs.com> Hi all, after revolving around the port locking configuration in my mind for a bit, I thought that the following would be a good idea: (*) Keep as much of the dynamic config in Java as possible, and put as little as possible into the native libs. Try to be as flexible as possible. The concrete idea for doing this is as follows: Add to RXTXCommDriver { public static void setPortLockingPolicy(PortLockingPolicy p) } Add public class PortLockingPolicy { public String getLockfileDir() { return System.getProperty("gnu.io.rxtx.LockfileDir"); } public boolean getOpenExclMode(String portName) { return true; } public boolean getLockfileWarningMode(String portName) { return System.getProperty(... } } That is, the default impl of PortLockingPolicy is registered by default and uses System Properties as discussed previously. But anybody who needs more fine-grained control can subclass PortLockingPolicy and register it. Even separate settings per port get possible. We could also think about a PortLockingDelegate in order to modify existing behavior without overriding it, if we want. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Saturday, September 06, 2008 5:41 AM > To: Oberhuber, Martin > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: Re: [Rxtx] RXTX Port Locking Improvements > > > In my opinion, it is still important that programs which use > > RXTX can be ported to the Sun javax.comm APIs easily (that is, > > just by doing a String replace of > > sed -e 's,gnu\.io\.,javax.comm,g' > > on all files. Creating new classes or interfaces makes that > > impossible. > > > > What do others on this list think? Is this still important, > > or can we fork off javax.comm since that's not really maintained > > any more anyways? > > > > Note that especially on embedded devices (J2ME), many vendors > > provide native javax.comm implementations, so porting an RXTX > > based program onto such a J2ME vm is much easier if we restrict > > ourselves to the original API. > > > > In the end, everyone has a say. > > Answering what I think. > > I would consider breaking away from javax.comm 2.0 to be when > we should > call a version rxtx 3.0. I know you mentioned wanting to > call the next > release 3.0 but that really is for letting people know we > intentionally > broke the API. Right now, I suspect that doing so will not > be a win in > the end for users or developers. > > I have no problem starting a 3.0 branch to see what happens. Let it > turn, churn and burn. If it becomes popular all the better. > > Until such a venture is obviously better, we should probably be > conservative. Communicating such a final transition should be very > deliberate if we do it. Just pulling the rug out from under existing > applications would not be nice. > > We can add, extend, offer hooks for changing behavior and > more without > breaking applications using rxtx 2.1. We can become more > liberal with > such extensions - the rules for what is right have most > definitely changed > by example. Until it is obviously impossible to work with > what we have, > I'd suggest going that route. Any such features should probably be > downplayed so applications can work realitivley easily on > things like J2ME > solutions as you mentioned. > > In the end, it would be nice to agree with other solutions what is > right. We should remain very receptive towards such efforts > and perhaps > lead one if we have the resources. Multiple different > solutions will hurt > everyone. > > -- > Trent Jarvi > tjarvi at qbang.org > From Martin.Oberhuber at windriver.com Sat Sep 6 14:47:45 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 6 Sep 2008 22:47:45 +0200 Subject: [Rxtx] RXTX Port Locking Improvements References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584807676152@ism-mail03.corp.ad.wrs.com> PS Given that such an addition of an API Class would be adding API in a non-breaking way, the correct version number would be RXTX-2.2 IMHO. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Saturday, September 06, 2008 10:47 PM > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX Port Locking Improvements > > Hi all, > > after revolving around the port locking configuration in my > mind for a bit, I thought that the following would be a good > idea: > > (*) Keep as much of the dynamic config in Java as possible, > and put as little as possible into the native libs. > Try to be as flexible as possible. > > The concrete idea for doing this is as follows: > > Add to RXTXCommDriver { > public static void setPortLockingPolicy(PortLockingPolicy p) > } > > Add public class PortLockingPolicy { > public String getLockfileDir() { > return System.getProperty("gnu.io.rxtx.LockfileDir"); > } > > public boolean getOpenExclMode(String portName) { > return true; > } > > public boolean getLockfileWarningMode(String portName) { > return System.getProperty(... > } > } > > That is, the default impl of PortLockingPolicy is registered > by default and uses System Properties as discussed previously. > But anybody who needs more fine-grained control can subclass > PortLockingPolicy and register it. Even separate settings per > port get possible. We could also think about a PortLockingDelegate > in order to modify existing behavior without overriding it, > if we want. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Saturday, September 06, 2008 5:41 AM > > To: Oberhuber, Martin > > Cc: Steffen DETTMER; rxtx at qbang.org > > Subject: Re: [Rxtx] RXTX Port Locking Improvements > > > > > In my opinion, it is still important that programs which use > > > RXTX can be ported to the Sun javax.comm APIs easily (that is, > > > just by doing a String replace of > > > sed -e 's,gnu\.io\.,javax.comm,g' > > > on all files. Creating new classes or interfaces makes that > > > impossible. > > > > > > What do others on this list think? Is this still important, > > > or can we fork off javax.comm since that's not really maintained > > > any more anyways? > > > > > > Note that especially on embedded devices (J2ME), many vendors > > > provide native javax.comm implementations, so porting an RXTX > > > based program onto such a J2ME vm is much easier if we restrict > > > ourselves to the original API. > > > > > > > In the end, everyone has a say. > > > > Answering what I think. > > > > I would consider breaking away from javax.comm 2.0 to be when > > we should > > call a version rxtx 3.0. I know you mentioned wanting to > > call the next > > release 3.0 but that really is for letting people know we > > intentionally > > broke the API. Right now, I suspect that doing so will not > > be a win in > > the end for users or developers. > > > > I have no problem starting a 3.0 branch to see what > happens. Let it > > turn, churn and burn. If it becomes popular all the better. > > > > Until such a venture is obviously better, we should probably be > > conservative. Communicating such a final transition should be very > > deliberate if we do it. Just pulling the rug out from > under existing > > applications would not be nice. > > > > We can add, extend, offer hooks for changing behavior and > > more without > > breaking applications using rxtx 2.1. We can become more > > liberal with > > such extensions - the rules for what is right have most > > definitely changed > > by example. Until it is obviously impossible to work with > > what we have, > > I'd suggest going that route. Any such features should probably be > > downplayed so applications can work realitivley easily on > > things like J2ME > > solutions as you mentioned. > > > > In the end, it would be nice to agree with other solutions what is > > right. We should remain very receptive towards such efforts > > and perhaps > > lead one if we have the resources. Multiple different > > solutions will hurt > > everyone. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > From Martin.Oberhuber at windriver.com Sat Sep 6 14:51:08 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 6 Sep 2008 22:51:08 +0200 Subject: [Rxtx] Rxtx is not finding serial ports on Solaris In-Reply-To: <081660F391DA4B05A6DC90FCAF42403E@basis.com> References: <07CB4F76556D489DBA9D17963C41CB0D@basis.com> <081660F391DA4B05A6DC90FCAF42403E@basis.com> Message-ID: <460801A4097E3D4CA04CC64EE648584807676153@ism-mail03.corp.ad.wrs.com> Hm, it's working fine on Sol10-sparc for us commercially. Try the RXTX version on http://rxtx.qbang.org/eclipse/downloads read the README there for more info. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Shaun Haney Sent: Saturday, September 06, 2008 12:31 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Rxtx is not finding serial ports on Solaris I found some more information, so I thought I'd include it. It's Solaris 10/SunOS 5.10 on both the Sparc and Intel platforms that do not produce a list of ports. I just tried the same sample program on a Solaris 8 Intel machine and it listed /dev/term/a and /dev/term/b. Has anyone ever used RXTX on Solaris 10? Shaun Haney Software Test Engineer BASIS International Ltd. shaney at basis.com ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Shaun Haney Sent: Friday, September 05, 2008 3:47 PM To: rxtx at qbang.org Subject: [Rxtx] Rxtx is not finding serial ports on Solaris Hi. I am wondering if anyone has tried using RXTX on Solaris/SPARC or Solaris/Intel. The problem that I am experiencing on both platforms is CommPortIdentifier.getPortIdentifiers() is returning a completely empty list of ports. On both systems, I have a modem attached to the serial port. The serial port device on both systems is /dev/cua/a. At the commandline, I can type 'echo "Hello There Nice Day Isnt it" > /dev/cua/a' and the modem will flicker indicating it's received information. The test program I am using is: ======================================================================== ============= // /SerialFinder.java // import gnu.io.*; import java.util.*; public class SerialFinder { public static final void main(String args[]) throws gnu.io.NoSuchPortException { Enumeration portList; CommPortIdentifier current; portList=CommPortIdentifier.getPortIdentifiers(); System.out.println("gnu.io.rxtx.SerialPorts="+System.getProperty("gnu.io .rxtx.SerialPorts")); System.out.println("List>>>"); while (portList.hasMoreElements()) { current=(CommPortIdentifier)portList.nextElement(); System.out.println(current.getName()); } System.out.println("<<>> << References: <460801A4097E3D4CA04CC64EE6485848076760E1@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584807676154@ism-mail03.corp.ad.wrs.com> Hm, I see, thanks for the info. The original intention of my question was because I thought that with lockfiles enabled, locking each port in turn can be a performance hit when lots of ports are to be probed. Especially on Redhat / Fedora, where (if I add the baudboy support to be consistent), each lock operation leads to calling an external executable. I'd be interested in finding a way to see what port candidates are impossible (without doing a testRead), such that the testRead() can be applied to fewer candidates. > More historical than important; when I put the code in, I > figured if the port was locked, there was no way we could > get the port for the user so there wasn't any point in > reporting it as available. Our users tend to "forget" (or not even be aware) that some program is still hogging a port. So, when they don't see the port in our main app they think there's a bug and don't understand how to make the port visible. What I'd love to see from a User's point of view, is having a port list like /dev/ttyS0 /dev/ttyS1 (locked by 12235) /dev/ttyS2 (no permission) /dev/ttyS3 (locked by unknown) Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Saturday, September 06, 2008 4:31 AM > To: Oberhuber, Martin > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Why does testRead() lock the port? > > On Fri, 5 Sep 2008, Oberhuber, Martin wrote: > > > Hi all, > > > > When RXTX initializes, it scans available (serial) ports. > > It does so by calling a testRead() native method, which > > tries to open each port and get some settings. > > > > What I don't understand, is why in SerialImp.c line 4322 > > the code tries to LOCK the port in this context? > > > > The result seems to be, that if a different application (e.g. > > minicom) currently owns the port, the port won't even be > > scanned. Users don't see the port listed in their Java app > > and never get the idea that this might be due to another > > App currently owning the port. > > > > That doesn't seem desired, and port locking doesn't seem > > necessary since the code only reads the port. > > > > Does anybody have a clue why the port is locked here? > > > > Hi Martin, > > The port is locked because reading can cause problems for other > applications. If a critical application opens a port and > does a quick > read (such as getting NMEA information from a GPS), some of > the data will > be taken by rxtx corrupting the incomming stream. > > The port scanning with locked ports is intended to behave the > same on all > systems. Windows will not enumerate a port if it is open by > hyperterm also. > > I'm not against changing the reporting ports that are in use > if a way is > found to be consistant between systems. I think it must be > possible as > hyperterm can open ports rxtx has open as I recall. There > are also the > registry, hald and others that wouldnt require opening ports. > I'm not > sure that changing in a consitant way is going to be all that easy. > > More historical than important; when I put the code in, I > figured if the > port was locked, there was no way we could get the port for > the user so > there wasn't any point in reporting it as available. > > -- > Trent Jarvi > tjarvi at qbang.org > From tjarvi at qbang.org Sat Sep 6 15:07:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 6 Sep 2008 15:07:54 -0600 (MDT) Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE648584807676151@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584807676151@ism-mail03.corp.ad.wrs.com> Message-ID: Hi Martin, I would consider using Serial in the new classname - perhaps with a more generic parent class. As an example of why, one possible direction for RXTX in the future could be contributing to of Java implementation of the well defined VISA standard; an abstraction of serial, tcpip, udp, gpib, vxi-11, usb, ... used in instrumentation that does away with having to worry about what the port name is. You just use resource strings that work on all systems: "ASRL1::instr" There may be several types of ports in such a case. It is fairly inexpensive timewise to create a generic parent class. The methods may then throw UnsupportedLockOperation exceptions or such. On Sat, 6 Sep 2008, Oberhuber, Martin wrote: > Hi all, > > after revolving around the port locking configuration in my > mind for a bit, I thought that the following would be a good > idea: > > (*) Keep as much of the dynamic config in Java as possible, > and put as little as possible into the native libs. > Try to be as flexible as possible. > > The concrete idea for doing this is as follows: > > Add to RXTXCommDriver { > public static void setPortLockingPolicy(PortLockingPolicy p) > } > > Add public class PortLockingPolicy { > public String getLockfileDir() { > return System.getProperty("gnu.io.rxtx.LockfileDir"); > } > > public boolean getOpenExclMode(String portName) { > return true; > } > > public boolean getLockfileWarningMode(String portName) { > return System.getProperty(... > } > } > > That is, the default impl of PortLockingPolicy is registered > by default and uses System Properties as discussed previously. > But anybody who needs more fine-grained control can subclass > PortLockingPolicy and register it. Even separate settings per > port get possible. We could also think about a PortLockingDelegate > in order to modify existing behavior without overriding it, > if we want. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Saturday, September 06, 2008 5:41 AM >> To: Oberhuber, Martin >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: Re: [Rxtx] RXTX Port Locking Improvements >> >>> In my opinion, it is still important that programs which use >>> RXTX can be ported to the Sun javax.comm APIs easily (that is, >>> just by doing a String replace of >>> sed -e 's,gnu\.io\.,javax.comm,g' >>> on all files. Creating new classes or interfaces makes that >>> impossible. >>> >>> What do others on this list think? Is this still important, >>> or can we fork off javax.comm since that's not really maintained >>> any more anyways? >>> >>> Note that especially on embedded devices (J2ME), many vendors >>> provide native javax.comm implementations, so porting an RXTX >>> based program onto such a J2ME vm is much easier if we restrict >>> ourselves to the original API. >>> >> >> In the end, everyone has a say. >> >> Answering what I think. >> >> I would consider breaking away from javax.comm 2.0 to be when >> we should >> call a version rxtx 3.0. I know you mentioned wanting to >> call the next >> release 3.0 but that really is for letting people know we >> intentionally >> broke the API. Right now, I suspect that doing so will not >> be a win in >> the end for users or developers. >> >> I have no problem starting a 3.0 branch to see what happens. Let it >> turn, churn and burn. If it becomes popular all the better. >> >> Until such a venture is obviously better, we should probably be >> conservative. Communicating such a final transition should be very >> deliberate if we do it. Just pulling the rug out from under existing >> applications would not be nice. >> >> We can add, extend, offer hooks for changing behavior and >> more without >> breaking applications using rxtx 2.1. We can become more >> liberal with >> such extensions - the rules for what is right have most >> definitely changed >> by example. Until it is obviously impossible to work with >> what we have, >> I'd suggest going that route. Any such features should probably be >> downplayed so applications can work realitivley easily on >> things like J2ME >> solutions as you mentioned. >> >> In the end, it would be nice to agree with other solutions what is >> right. We should remain very receptive towards such efforts >> and perhaps >> lead one if we have the resources. Multiple different >> solutions will hurt >> everyone. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > From tjarvi at qbang.org Sat Sep 6 18:39:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 6 Sep 2008 18:39:59 -0600 (MDT) Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE648584807676152@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584807676152@ism-mail03.corp.ad.wrs.com> Message-ID: Fair enough. As we add to the API and retain backwards compatability it will be 2.1+n if there is no objection. Dot (aka dash) releases will not change the API or properties used at all. On Sat, 6 Sep 2008, Oberhuber, Martin wrote: > PS > > Given that such an addition of an API Class would be > adding API in a non-breaking way, the correct version > number would be RXTX-2.2 IMHO. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Saturday, September 06, 2008 10:47 PM >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX Port Locking Improvements >> >> Hi all, >> >> after revolving around the port locking configuration in my >> mind for a bit, I thought that the following would be a good >> idea: >> >> (*) Keep as much of the dynamic config in Java as possible, >> and put as little as possible into the native libs. >> Try to be as flexible as possible. >> >> The concrete idea for doing this is as follows: >> >> Add to RXTXCommDriver { >> public static void setPortLockingPolicy(PortLockingPolicy p) >> } >> >> Add public class PortLockingPolicy { >> public String getLockfileDir() { >> return System.getProperty("gnu.io.rxtx.LockfileDir"); >> } >> >> public boolean getOpenExclMode(String portName) { >> return true; >> } >> >> public boolean getLockfileWarningMode(String portName) { >> return System.getProperty(... >> } >> } >> >> That is, the default impl of PortLockingPolicy is registered >> by default and uses System Properties as discussed previously. >> But anybody who needs more fine-grained control can subclass >> PortLockingPolicy and register it. Even separate settings per >> port get possible. We could also think about a PortLockingDelegate >> in order to modify existing behavior without overriding it, >> if we want. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Saturday, September 06, 2008 5:41 AM >>> To: Oberhuber, Martin >>> Cc: Steffen DETTMER; rxtx at qbang.org >>> Subject: Re: [Rxtx] RXTX Port Locking Improvements >>> >>>> In my opinion, it is still important that programs which use >>>> RXTX can be ported to the Sun javax.comm APIs easily (that is, >>>> just by doing a String replace of >>>> sed -e 's,gnu\.io\.,javax.comm,g' >>>> on all files. Creating new classes or interfaces makes that >>>> impossible. >>>> >>>> What do others on this list think? Is this still important, >>>> or can we fork off javax.comm since that's not really maintained >>>> any more anyways? >>>> >>>> Note that especially on embedded devices (J2ME), many vendors >>>> provide native javax.comm implementations, so porting an RXTX >>>> based program onto such a J2ME vm is much easier if we restrict >>>> ourselves to the original API. >>>> >>> >>> In the end, everyone has a say. >>> >>> Answering what I think. >>> >>> I would consider breaking away from javax.comm 2.0 to be when >>> we should >>> call a version rxtx 3.0. I know you mentioned wanting to >>> call the next >>> release 3.0 but that really is for letting people know we >>> intentionally >>> broke the API. Right now, I suspect that doing so will not >>> be a win in >>> the end for users or developers. >>> >>> I have no problem starting a 3.0 branch to see what >> happens. Let it >>> turn, churn and burn. If it becomes popular all the better. >>> >>> Until such a venture is obviously better, we should probably be >>> conservative. Communicating such a final transition should be very >>> deliberate if we do it. Just pulling the rug out from >> under existing >>> applications would not be nice. >>> >>> We can add, extend, offer hooks for changing behavior and >>> more without >>> breaking applications using rxtx 2.1. We can become more >>> liberal with >>> such extensions - the rules for what is right have most >>> definitely changed >>> by example. Until it is obviously impossible to work with >>> what we have, >>> I'd suggest going that route. Any such features should probably be >>> downplayed so applications can work realitivley easily on >>> things like J2ME >>> solutions as you mentioned. >>> >>> In the end, it would be nice to agree with other solutions what is >>> right. We should remain very receptive towards such efforts >>> and perhaps >>> lead one if we have the resources. Multiple different >>> solutions will hurt >>> everyone. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> > From Martin.Oberhuber at windriver.com Mon Sep 1 08:59:20 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 1 Sep 2008 16:59:20 +0200 Subject: [Rxtx] [Suspected Spam][Blocked Sender]Re: Towards an RXTX release - CSR BT/USB chipset In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com><13557-75390@sneakemail.com><20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848074C4259@ism-mail03.corp.ad.wrs.com> Hi Bruce, I think that the only way to avoid temparary disconnect during port scanning, is to avoid the temporary open() during port scanning. That, however, can only be avoided if there is some external means to enumerate the candidates for valid port names. The javax.comm implementations by Sun and IBM use a file named "javax.comm.properties" for this. On Linux and Solaris, it enumerates the allowed prefixes for device names to be used. Those prefixes known, the library treats all existing files with such prefixes as valid ports, without trying to actually open them. See http://java.sun.com/products/javacomm/ I'd think that one option to simplify the port scanning would be to use a Java System Property to specify the Policy for port scanning. For instance: -Dgnu.io.rxtx.PortScanningPolicy=read # try to open & read scanned ports -Dgnu.io.rxtx.PortScanningPolicy=existing # treat ports as valid if they exist For enumerating the candidates to check, the "gnu.io.rxtx.properties" file already exists as well as the "gnu.io.rxtx.SerialPorts" and "gnu.io.rxtx.ParallelPorts" System Properties. These support explicit enumeration of port candidates. So, a second possible enhancement in addition to support specifying the PortScanningPolicy could be to support specifying prefix names for port enumeration rather than just explicit enumeration. What do others think about these ideas? Could these improve the long-standing performance issues with USB / Bluetooth adapters during port scanning? Why does RXTX try to open scanned ports in the first place, rather than relying on plain existence of the devices? I'd guess that a Patch providing these enhancements would be appreciated by the RXTX community. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Bruce Boyes Sent: Tuesday, August 05, 2008 3:13 AM To: Rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender]Re: [Rxtx] Towards an RXTX release - CSR BT/USB chipset At 18:37 07/29/2008, you wrote: All, Is there any chance that the next official release could improve on the port scanning (getPortIdentifiers)? It would be nice if rxtx could also not cause a connect/disconnect and subsequent problems with a USB Bluetooth BlueSoleil adapter (using the CSR chipset), as documented in a previous email from me. best regards Bruce ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080901/f3cb9a8e/attachment-0007.html From Martin.Oberhuber at windriver.com Mon Sep 1 09:36:31 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 1 Sep 2008 17:36:31 +0200 Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> Hi all, I made some experiments with the Sun and IBM implementations of javax.comm (on Linux and Solaris), in order to understand how these treat port locking and lockfiles and in what way they report failure to obtain a port to the client. Here are the results: * Neither Sun nor IBM check or create any lockfiles. As a result, minicom can open the same serial port as my test java application without error. * Sun uses Kernel locking with fcntl, according to an strace (truss) that I had run with my test app: open("/dev/ttyS1", O_RDWR|O_NONBLOCK|O_EXCL) = 5 fcntl64(5, F_SETLK, {type=F_WRLCK, ...}) = 0 As a result, multiple instances of the same Java test program are protected against each other; minicom, however, is *not* protected since it does open("/dev/ttyS1", O_RDWR|O_NONBLOCK) on Linux RHEL 4 at least. * IBM seems to use some memory sharing between multiple instances of Java programs: CommPortOwnershipListener is called even if a different instance of the program tries to access the port. No port locking of any kind seems to be done though. As a result, IBM apps are protected against each other but not against minicom. * When opening a port fails due to missing permissions on the device file, or due to an exclusive lock owned by another instance of itself, - IBM throws a PortInUseException after the timeout (currentOwner="Unknown Application") - Sun throws a java.lang.RuntimeException immediately (message=one of the following two: "\n Error opening \"/dev/ttyS1\"\n Permission denied" "\n Error opening \"/dev/cua/a\"\n Error in lockf()" What I learn from this is that 1. Neither the Sun nor the IBM implementation are really useable in terms of port locking, since they do not respect minicom. 2. Sun's throwing a RuntimeException from CommPortIdentifier.open() is undocumented and may break client applications in an unexpected way. 3. Kernel locks through fcntl are not sufficient for minicom to keep it off the port. 4. Kernel locks give no indication what application is currently owning the port (lockfiles could give that information but minicom does not evaluate it). Does anybody on this list know the difference between fcntl(F_SETLK, {type=F_WRLCK}) and ioctl(fd, TIOCEXCL, 0); ? What do folks think about throwing a RuntimeException from CommPortIdentifier.open() ? I'll follow up with a separate E-Mail proposing a strategy for RXTX to handle port locking. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, July 30, 2008 4:16 AM > To: Oberhuber, Martin > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Port locking on Linux: Redhat lockdev-baudboy > Instead, I would suggest we do an exclusive open and try to > lock as is if > lockfiles are not disabled. Warn if the lock fails. Always respect > lockfiles prior to opening. > > Exclusive opens should work on linux, mac, sol, bsd, ... > > The code is simple and does not introduce any new dependencies. > > ... > open > ... > do { > res = ioctl(fd, TIOCEXCL, 0); > } while ( (errno == EINTR || errno == EAGAIN ) && res != 0 ); > > > if( res != 0 ) > fail > > > In the worst case, minicom or another application may not be > able to find a lockfile but their open will fail. We locked > the port. Other applications may not do this so we should > always respect lockfiles. > > -- > Trent Jarvi > tjarvi at qbang.org > From Martin.Oberhuber at windriver.com Mon Sep 1 10:05:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 1 Sep 2008 18:05:02 +0200 Subject: [Rxtx] RXTX Port Locking Improvements Message-ID: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> Hi all, here is my proposal for improving port locking in RXTX. 1. Goals of the Proposal * Support enabling / disabling / configuring port locking at runtime without re-compiling RXTX. * Support port locking by Kernel call even if permissions for lockfiles are not sufficient. * Report exact reason for failure to acquire a port to the client application (including the file system path of a lockfile for instance). 2. Getting the settings into RXTX * Use Java System Properties for tuning behavior (since the RXTX / javax.comm API is frozen): * -Dgnu.io.rxtx.LockfileDir=/var/lock # specify location of lockfile directory, similar to minicom * -Dgnu.io.rxtx.LockPolicy=none # no port locking, no warnings or anything * -Dgnu.io.rxtx.LockPolicy=default # try lockfiles, in case of missing permission fall back to kernel locks without warning * -Dgnu.io.rxtx.LockPolicy=warn # try lockfiles, in case of missing permission fall back to kernel locks with warning to stdout * -Dgnu.io.rxtx.LockPolicy=strict # require lockfiles, throw exception if they cannot be created. The "default" policy would try to be as good a citizen as possible (create lockfiles if possible, create Kernel exclusive lock if possible), but without guarantee and without warning in case it fails creating any lock. The warning to stdout would be something like "Warning: RXTX failed to create a lockfile in /var/lock/LCK..ttyS0. Check file system permissions or specify -Dgnu.io.rxtx.LockfileDir in order to enable proper locking of serial ports against other applications". 3. Error Reporting out of RXTX * All errors acquiring a port are reported by means of a gnu.io.rxtx.PortInUseException on CommPortIdentifier#open(). * In case of missing permissions or other unexpected failure running through open(), the "currentOwner" field is filled with the String "Unexpected Error", and the message field of the exception is filled with a String like "/dev/ttyS0 : Permission denied in open()" or "/var/lock/LCK..ttyS0 : Permission denied in write()" * In case of properly running through open() but not being able to lock the port, the "currentOwner" field is populated with the name and PID of the external process locking the port if it can be obtained, or "Unknown Application" otherwise. In other words, I'm proposing to replace Sun's RuntimeException for reporting unexpected errors with a PortInUseException with the owner String set to "Unexpected Error" and detail information in the message field of the exception. In case any file system resource is related to the unexpected error, it must be mentioned first and separated by a " : " String such that clients can parse the actual file system resource out of the message automatically. I thought about subclassing PortInUseException to provide more error details and type-safe parsing of the affected resource but wasn't so sure about it in the end. What do others think about this proposal? Would it make more sense to throw a RuntimeException for unexpected errors, rather than a PortInUseException with the String "Unexpected Error" ? Do the proposed port locking policies make sense? Is the naming proper? I'll next work on a patch to implement the proposal (or any modification as discussed on this list). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080901/5d1811e0/attachment-0007.html From Steffen.DETTMER at ingenico.com Mon Sep 1 10:50:56 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 1 Sep 2008 18:50:56 +0200 Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> Message-ID: <20080901165055.GD17898@elberon.bln.de.ingenico.com> Hi, thanks for this nice list! * Oberhuber, Martin wrote on Mon, Sep 01, 2008 at 17:36 +0200: > 1. Neither the Sun nor the IBM implementation are really > useable in terms of port locking, since they do not > respect minicom. > 2. Sun's throwing a RuntimeException from > CommPortIdentifier.open() is undocumented and may break > client applications in an unexpected way. Yes, someone may expect a PortInUseException if the port is in use, but since RuntimeExceptions can be thrown always anyway, I think there is not much a client application can do than catching the `known expected' unexpected (unspecified by throws) exceptions. Client applications probably want to wrap CommPortIdentifier.open(), catching at least PortInUseException and/or RuntimeException and throwing a well-defined exception (that should also include the port name and/or other helpful detail for the user, such as why the access was tried etc) > 3. Kernel locks through fcntl are not sufficient for > minicom to keep it off the port. I think it could be sufficient if mandatory file locking is enabled (on systems that support it). Linux for instance in general should support mandatory file locking, but I don't know if it really works for device files. > 4. Kernel locks give no indication what application is > currently owning the port (lockfiles could give that > information but minicom does not evaluate it). > > Does anybody on this list know the difference between > fcntl(F_SETLK, {type=F_WRLCK}) > and > ioctl(fd, TIOCEXCL, 0); > ? maybe the first one could be considered more general (and modern :)), should work for all files and file systems and it is POSIX; the second one as some specific function of some serial/tty driver. I think on POSIX systems (whatever this means in practice), someone should be able to expect fcntl(F_SETLK, ...) to work, but no rule without an exception (sometimes, just exceptions without any rule ;)). ioctl TIOCEXCL prevents a second open (unless executed by root), but fcntl(F_SETLK) another F_SETLK (when advisory locking) or write (when mandatory locking). Some serial implementations do (or try) both. > What do folks think about throwing a RuntimeException from > CommPortIdentifier.open()? (I think it shows that those mandatory throws() clause and its exceptions were not the best ideas when defining the java language, sometimes workarounded by `throws Throwable' :)) I'd expect such an exception (only) in the fatal cases where an application usually cannot do anything reasonable, let's say some OutOfMemory (yes, this is an Error I know) or SecurityException. We had quite some issues with things like that (not rxtx related) and with applications catching RuntimeException (or even Throwable) on some high level sometimes resulting in strange effects, so I think it should be avoided, for instance, by wrapping calls to such methods, also needed to add more details about the region where the problem occured (often, higher layers know additional details more interesting for the user, for instance, why something was attempted, where it was configured or which subsystem tried it what for, ...). Unfortunality it is not always straightforward/possible to overwrite to get such a behavior. Actually, I think usually it is not that easy (either you cannot call a needed method because it is private or you cannot put your wrapper because the constructing class cannot be overwritten easily, ... etc). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From tjarvi at qbang.org Mon Sep 1 11:28:37 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 1 Sep 2008 11:28:37 -0600 (MDT) Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: <20080901165055.GD17898@elberon.bln.de.ingenico.com> References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> <20080901165055.GD17898@elberon.bln.de.ingenico.com> Message-ID: On Mon, 1 Sep 2008, Steffen DETTMER wrote: > >> 4. Kernel locks give no indication what application is >> currently owning the port (lockfiles could give that >> information but minicom does not evaluate it). >> >> Does anybody on this list know the difference between >> fcntl(F_SETLK, {type=F_WRLCK}) >> and >> ioctl(fd, TIOCEXCL, 0); >> ? > > maybe the first one could be considered more general (and modern > :)), should work for all files and file systems and it is POSIX; > the second one as some specific function of some serial/tty driver. > > I think on POSIX systems (whatever this means in practice), > someone should be able to expect fcntl(F_SETLK, ...) to work, but > no rule without an exception (sometimes, just exceptions without > any rule ;)). > > ioctl TIOCEXCL prevents a second open (unless executed by root), > but fcntl(F_SETLK) another F_SETLK (when advisory locking) or > write (when mandatory locking). Some serial implementations do > (or try) both. > I couldn't parse the last comment about F_SETLK. I guess you ment F_SETLK prevents other F_SETLK attempts (advisory) or writing (mandatory). Presumably that applies to all users. While F_SETLK is possibly something we can add, I just want to point out that the TIOCEXCL will work on all UNIX like systems and is very specific to our needs; it only applies to ttys. F_SETLK also appears to be used for other things like trying to lock portions of a file over networked filesystems. -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Mon Sep 1 11:33:53 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 1 Sep 2008 19:33:53 +0200 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> Message-ID: <20080901173353.GE17898@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Mon, Sep 01, 2008 at 18:05 +0200: > 2. Getting the settings into RXTX > > * Use Java System Properties for tuning behavior (since the RXTX / > javax.comm API is frozen): I think supporting -D system properties is a similar API change to add some new config-classes/method (except that system properties are better hidden :)). I'd like to add that spplications should be able to overwrite this (for instance, if they support config files or some GUI to configure it), here they could use setProperty. > * -Dgnu.io.rxtx.LockfileDir=/var/lock # specify location of > lockfile directory, similar to minicom > * -Dgnu.io.rxtx.LockPolicy=none # no port locking, no > warnings or anything > * -Dgnu.io.rxtx.LockPolicy=default # try lockfiles, in case of > missing permission fall back to kernel locks without warning > * -Dgnu.io.rxtx.LockPolicy=warn # try lockfiles, in case of > missing permission fall back to kernel locks with warning to stdout > * -Dgnu.io.rxtx.LockPolicy=strict # require lockfiles, throw > exception if they cannot be created. > > The "default" policy would try to be as good a citizen as possible > (create lockfiles if possible, create Kernel > exclusive lock if possible), but without guarantee and without warning > in case it fails creating any lock. Nice, I think the important things would be configurable then! so default is no one of `none', `warn' and `strict'? I think it could be confusing if `default' is an option that must explicitely given, maybe -Dgnu.io.rxtx.LockPolicy=automatic and making this the default (i.e. when it is given, actually nothing changes)? Well, just a minor detail. Another minor detail could be that here someone might think that two things are joined: first, what should happen if locking fails and second how to lock. Maybe it could be splitted. Additionally, somone could want to distinguish between `lock always' and `lock at use', but I'm not sure if the javax style API supports this. On a (non rxtx related but C++) implementation alternatively it was used to have a `Policy' (always, at use, none, default[here: depending on the device]) and a `Kind' (classes for UUCP-lockfile and kernel locks). So back to rxtx, maybe here an additional option like some -Dgnu.io.rxtx.LockKind = [file] [ioctl] [fcntl], maybe separated by "," or as ORed integer number, and LockPolicy=(none|any|all)? I'd dislike warnings to stdout (if so, stderr, but better logging, because it can be configured). stdout may not be avialable or used by some text mode UI or alike. For GUI-applications an english language message may not be sufficient but national language support may be required (I have no idea how to do this, just name it for the list). I think for logging (in contrast to stdout) in most cases english-only logs are acceptable. Anyway, this really are just minor things. Your proposal seems to support all important things and the naming is OK. > The warning to stdout would be something like "Warning: RXTX failed to > create a lockfile in /var/lock/LCK..ttyS0. Check file system permissions > or specify -Dgnu.io.rxtx.LockfileDir in order to enable proper locking > of serial ports against other applications". yes, nice! Maybe add the device port name that was tried to open (maybe it was something symbolic like `modem' or alike)? > 3. Error Reporting out of RXTX > > * All errors acquiring a port are reported by means of a > gnu.io.rxtx.PortInUseException on CommPortIdentifier#open(). Yes, I think better than RuntimeExceptions! > * In case of missing permissions or other unexpected failure > running through open(), the "currentOwner" field is filled with the > String "Unexpected Error", and the message field of the exception is > filled with a String like "/dev/ttyS0 : Permission denied in open()" or > "/var/lock/LCK..ttyS0 : Permission denied in write()" or maybe defining a subclass of PortInUseException? Then applications could (theoretically) catch the permission denied (lets say if someone wants to write a config GUI or application that autodetects if lock files can be used) > * In case of properly running through open() but not being able to > lock the port, the "currentOwner" field is populated with the name and > PID of the external process locking the port if it can be obtained, or > "Unknown Application" otherwise. > > In other words, I'm proposing to replace Sun's RuntimeException for > reporting unexpected errors with a PortInUseException with the owner > String set to "Unexpected Error" and detail information in the message > field of the exception. In case any file system resource is related to > the unexpected error, it must be mentioned first and separated by a " : > " String such that clients can parse the actual file system resource out > of the message automatically. (or adding a new method getLockPath() or so to PortInUseException) > I thought about subclassing PortInUseException to provide more error > details and type-safe parsing of the affected resource but wasn't so > sure about it in the end. Yes, intuitively I feel the same, like adding some String getPath() method to PortInUseException or a (new) subclass. In some unrelated thing we used exception message string contents parsing (was considered a hack from the beginning), some years later hit some problem in which made the error-detail-determination fail and replaced it completely by heaps of subclasses (BTW, the sources for the subclasses were automatically generated), that's why I'd use subclasses in case of doubt, but probably this has other disadvantages. Sometimes, the problem is that people later that use this API may not know any of those details and discussions, but if they see some special methods or subclasses in the javadoc or so, I think chances are higher that those situations are treated better, which may make users happier; also example programs / example code snippets can be helpful. > What do others think about this proposal? Would it make more > sense to throw a RuntimeException for unexpected errors, rather > than a PortInUseException with the String "Unexpected Error" ? I think, Exceptions should be used for unexpected conditions (excepted `exceptions' should be returned, e.g. by bool methods or alike). (unrelated here, but) Working with throw and catch IMHO is a kind of `goto' programming, actually even worse, and IMHO should not be used for the `good case' (such as searching a free port). Here, I think the throws() clause with PortInUseException simply is wrong. It should throw something more generic with PortInUseException beeing one subclass, but this would be an API change. For compatiblity, I could imagine a subclass of it. > Do the proposed port locking policies make sense? Is the naming > proper? Yes, for me it makes sense and is proper. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From Steffen.DETTMER at ingenico.com Mon Sep 1 11:50:48 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 1 Sep 2008 19:50:48 +0200 Subject: [Rxtx] Port locking on Linux (lockfiles) In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584806CF1AA4@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848074C4277@ism-mail03.corp.ad.wrs.com> <20080901165055.GD17898@elberon.bln.de.ingenico.com> Message-ID: <20080901175048.GF17898@elberon.bln.de.ingenico.com> * Trent Jarvi wrote on Mon, Sep 01, 2008 at 11:28 -0600: > >ioctl TIOCEXCL prevents a second open (unless executed by root), > >but fcntl(F_SETLK) another F_SETLK (when advisory locking) or > >write (when mandatory locking). > > I couldn't parse the last comment about F_SETLK. I guess you ment > F_SETLK prevents other F_SETLK attempts (advisory) or writing > (mandatory). Presumably that applies to all users. Yes, thanks for the clarification. > While F_SETLK is possibly something we can add, I just want to point > out that the TIOCEXCL will work on all UNIX like systems and is very > specific to our needs; it only applies to ttys. I guess F_SETLK could make sense if it would prevent minicom to work if mandatory locking is enabled, otherwise and if TIOCEXCL is working, F_SETLK probably doesn't make much sense, does it? Bad would be, I think, if on some system TIOCEXCL works, but F_SETLK fails (e.g. not supported or so) and in the end rxtx would throw some exception instead of opening the port, so adding it could require tests on exotic systems... oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From Martin.Oberhuber at windriver.com Wed Sep 3 11:33:54 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 3 Sep 2008 19:33:54 +0200 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <20080901173353.GE17898@elberon.bln.de.ingenico.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Hello Steffen, some comments: > I think supporting -D system properties is a similar API change > to add some new config-classes/method (except that system > properties are better hidden :)). Well the point is that if System Properties are set but not understood by a different runtime implementation, it doesn't hurt and you can still link against / run the program. Creating new config-classes creates a compile-time API change such that you cannot easily port the program to other API implementations any more. In my opinion, it is still important that programs which use RXTX can be ported to the Sun javax.comm APIs easily (that is, just by doing a String replace of sed -e 's,gnu\.io\.,javax.comm,g' on all files. Creating new classes or interfaces makes that impossible. What do others on this list think? Is this still important, or can we fork off javax.comm since that's not really maintained any more anyways? Note that especially on embedded devices (J2ME), many vendors provide native javax.comm implementations, so porting an RXTX based program onto such a J2ME vm is much easier if we restrict ourselves to the original API. > I'd like to add that spplications should be able to overwrite > this Well, they can always System.setProperty("gnu.io.rxtx.LockfileDir", "/foo/bar"); or similar. We're doing that in our commercial app in order to add ports which RXTX doesn't discover automatically. > so default is no one of `none', `warn' and `strict'? I think it We can discuss what the default should be, it can be any of the other options of course. I had proposed "default" to be the default :-) I usually like the default to be that it "just works without fuss" :-) > Another minor detail could be that here someone might think that > two things are joined: first, what should happen if locking fails > and second how to lock. Maybe it could be splitted. It could probably be splitted. But I didn't want to expose too many implementation details to the outside, nor make the interface (configuration) too complex. Note that different locking mechanisms could be available on different OS's; the user won't care about the mechanisms but what to do in case one of them fails (fallback to others with or without warning, or fail). So far, we've been clear that the right thing to do is (1) observe and create lockfiles for legacy clients, and then (2) do the right thing which is the Kernel Lock. I don't see a need for more configuration at this point. If we should see a necessity for more fine-grained configuration we can add that in the future. > Policy differentiate between `lock always' and `lock at use' We lock when the client opens the port, javax.comm does not provide an API for locking even without opening the port if that's what you mean, so this doesn't seem an option. > some -Dgnu.io.rxtx.LockKind = [file] [ioctl] [fcntl] I see no sense in trying some locks only. Applications should try to acquire every lock they are aware of, no? Note that we don't know what other apps are installed, so we need to use all mechansims we can. On a Platform where some mechanism is not available, it will be removed at compile-time anyways (configure script). If it's available at compile-time it should be used at runtime. > I'd dislike warnings to stdout (if so, stderr, but better > logging, because it can be configured). stdout may not be > avialable or used by some text mode UI or alike. I know, that's why I wouldn't make that option the default. And yes, of course we'd log to stderr and not stdout. > For GUI-applications an english language message may not be > sufficient but national language support may be required RXTX is low-level. Translation is up to the higher level client app. What I take from that is, that the client app should be able to receive exactly the same warnings that would otherwise go to stdout. My current proposal doesn't account for that... but actually, RXTX's Zystem class provides for configurable logging through the "gnu.io.log.mode" System Property. I'm just not exactly sure how Zystem is to be used, but it should work somehow... Trent, any help > yes, nice! Maybe add the device port name that was tried to open > (maybe it was something symbolic like `modem' or alike)? Hm... that might indeed help in some cases. Thanks for the hint. > or maybe defining a subclass of PortInUseException? > (or adding a new method getLockPath() or so to PortInUseException) Again, that's not possible if we want to be source compatible with javax.comm -- but I'm in favor of this proposal if the Community thinks that this is not so important any more? Thanks, Martin From johnny.luong at trustcommerce.com Wed Sep 3 12:54:17 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Wed, 03 Sep 2008 11:54:17 -0700 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: <48BEDD59.5000908@trustcommerce.com> Oberhuber, Martin wrote: > Creating new config-classes creates a compile-time API change > such that you cannot easily port the program to other API > implementations any more. > > In my opinion, it is still important that programs which use > RXTX can be ported to the Sun javax.comm APIs easily (that is, > just by doing a String replace of > sed -e 's,gnu\.io\.,javax.comm,g' > on all files. Creating new classes or interfaces makes that > impossible. > > What do others on this list think? Is this still important, > or can we fork off javax.comm since that's not really maintained > any more anyways? > > Note that especially on embedded devices (J2ME), many vendors > provide native javax.comm implementations, so porting an RXTX > based program onto such a J2ME vm is much easier if we restrict > ourselves to the original API. Hi, I think it wouldn't be difficult for a person to create a separate facade of the javax.comm interface which talks to the RXTX library and perhaps if someone is willing to share that, then it can be improved on. If someone needs the older interface now, there are alternatives, e.g: RXTX 2.0, Sun javax.comm, serialio.com, etc. I only use the gnu.io namespace anyways with respect to RXTX and perhaps if there is a strong enough interest, someone with the resources/time could go through the JSR/JCP as there are probably some level of variation on the J2ME implementations of the API. Best, Johnny From Steffen.DETTMER at ingenico.com Thu Sep 4 02:42:15 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Thu, 4 Sep 2008 10:42:15 +0200 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: <20080904084215.GF30569@elberon.bln.de.ingenico.com> Hi! please let me repeat that I wrote about minor details only. I'm afraid that too much discussion about the minor, unimportant details could take focus from the important points. I just can't resist :-) Summary of my long OT below is that for me your proposal is OK, except that applications should parse error or warning messages e.g. for translation (if I understood correctly). * Oberhuber, Martin wrote on Wed, Sep 03, 2008 at 19:33 +0200: > > I think supporting -D system properties is a similar API change > > to add some new config-classes/method (except that system > > properties are better hidden :)). > > Well the point is that if System Properties are set but not > understood by a different runtime implementation, it doesn't > hurt and you can still link against / run the program. In Java, I think adding new classes is not problem also. Now I'm not really sure, but I think adding new methods also does work. So I think in the end similar to adding support for new -D options old implementations simply don't use it. (but I'm not against -D, I wrote by comment just BTW) > Creating new config-classes creates a compile-time API change > such that you cannot easily port the program to other API > implementations any more. > > In my opinion, it is still important that programs which use > RXTX can be ported to the Sun javax.comm APIs easily (that is, > just by doing a String replace of > sed -e 's,gnu\.io\.,javax.comm,g' > on all files. Creating new classes or interfaces makes that > impossible. Do you really consider source code modifying with sed or some other kind of preprocessing be a common use? I don't think that such techniques are used by many Java developers. Also, in this case of course your changed implementation will compile, but it would fail at runtime, because no locking is available, so you would need to implement it around (which BTW IMHO isn't a bad idea anyway), having something on top that adds locking support and stuff. I mean, if locking support is considered that important that the application cares about it, let's say by offering a GUI and internally calling setProperty, the ported version needs to implement all this on its own, simply because otherwise all those functions would have no effect. But if another application does not care much about locking and uses the defaults only (i.e. is not using -D options), then it would work in both cases. just BTW #2: If support for some javax.comm is needed, I think wrappers/adapters are needed anyway: you could have one implementation for javax.comm, a second for gnu.io and a third for thirdparty something I/O. Well, since I consider those Java APIs beeing weak and uncomfortable, I think adapters on top of it is needed anyway, for instance, supporting timeouts. Not only in some `global timeout that throws an exception if reached' or so, but something reasonable, powerfull that can be used to implement serial protocols, for instance. So in summary, I think the API should support something that makes all those usages /possible/, like let's say an operating system, but it is /not/ a generic communication library which abstracts from communications, physical and logical links and APIs. > Note that especially on embedded devices (J2ME), many vendors > provide native javax.comm implementations, so porting an RXTX > based program onto such a J2ME vm is much easier if we restrict > ourselves to the original API. I would expect those APIs to behave different in detail, especially at timeouts, that a 1:1 port wouldn't be possible anyway (at least that are my limited experiences with embedded C libs). > > I'd like to add that spplications should be able to overwrite > > this > > Well, they can always System.setProperty("gnu.io.rxtx.LockfileDir", > "/foo/bar"); or similar. We're doing that in our commercial > app in order to add ports which RXTX doesn't discover automatically. Yes, but this only would LOOK as if it would work on let's say the embeeded port, but in fact it would do nothing (which in this example probably would be OK). The only think I dislike here is that you will not get a compiler error, so a colleguage who ports such software probably would miss if the application to be ported requires/supports a lockfile directory. > > so default is no one of `none', `warn' and `strict'? I think it > > We can discuss what the default should be, it can be any of the > other options of course. I had proposed "default" to be the > default :-) I usually like the default to be that it "just works > without fuss" :-) What I meant was that the default should also have some meaningful name. I think specifying `myoption=default' makes no sense, either it should not be given at all or it should be `myoption=concretevalue1' which could be the same as if not given at all, but has at least some documentary purposes and keeps working even if defaults are changes, and finnally thus the default option IMHO also should have a speaking name - but this also is just a minor detail. > > Another minor detail could be that here someone might think that > > two things are joined: first, what should happen if locking fails > > and second how to lock. Maybe it could be splitted. > > It could probably be splitted. But I didn't want to expose too many > implementation details to the outside, nor make the interface > (configuration) too complex. Yes, this is a good point. As the discussion here shows that it is complex library users would probably just get confused and set options wrongly. However, for specific applications specific things may be needed. In this cases according to your proposal it can be configured to use `none' and the specific application can implement whatever locking. So your proposal is fine! > Note that different locking mechanisms could be available on > different OS's; the user won't care about the mechanisms but > what to do in case one of them fails (fallback to others with > or without warning, or fail). Yes, but also has influence on the defaults, doesn't it? I think on windows noone expect some UUCP style lock files, right? Defaults of course must work on all major systems. > So far, we've been clear that the right thing to do is (1) observe > and create lockfiles for legacy clients, and then (2) do the right > thing which is the Kernel Lock. > I don't see a need for more configuration at this point. If we > should see a necessity for more fine-grained configuration we > can add that in the future. (kernel lock means TIOCEXCL, right?) would the file locking stuff be implemented in java in an overwriteable way? Anyway, as long as it can be disabled its ok. I think for applications that rely on that, for instance servers searching a free modem at some multiport card or alike, some special implementation probably is needed anyway. Yes, I think you are right, it should be kept simple. > > Policy differentiate between `lock always' and `lock at use' > > We lock when the client opens the port, javax.comm does not provide > an API for locking even without opening the port if that's what you > mean, so this doesn't seem an option. > > > some -Dgnu.io.rxtx.LockKind = [file] [ioctl] [fcntl] > > I see no sense in trying some locks only. Applications should try > to acquire every lock they are aware of, no? Note that we don't > know what other apps are installed, so we need to use all mechansims > we can. On a Platform where some mechanism is not available, it > will be removed at compile-time anyways (configure script). If it's > available at compile-time it should be used at runtime. Yes, but if a lock fails, how to know if it fails because the OS does not supports it or permissions are insufficient - or the port really is busy? Ignoring whether a lock could made probably makes not much sense, but aborting could lead to unsable rxtx (maybe on `broken' OSes only). But you are right, since it can be disabled, applications can implement around it what they need. > > For GUI-applications an english language message may not be > > sufficient but national language support may be required > > RXTX is low-level. > Translation is up to the higher level client > app. What I take from that is, that the client app should be > able to receive exactly the same warnings that would otherwise > go to stdout. to allow to parse the string? but what if the message is changed in the next version of rxtx? I found such constructions in some functions (unrelated to rxtx) and I had to search them because they didn't work, so I think parsing informal messages isn't a good idea, usually. > > or maybe defining a subclass of PortInUseException? > > (or adding a new method getLockPath() or so to PortInUseException) > > Again, that's not possible if we want to be source compatible > with javax.comm -- but I'm in favor of this proposal if the > Community thinks that this is not so important any more? OK. (ok, if you consider similar names in different java packages as compatible as you explained below with sed, yes, I see your point) just BTW again: I would not rely that no javax.comm.something implementation defines reasonable exceptions. I know that for some reason it is common in the Java world not to define too many reasonable exceptions, maybe because it is slow or writing all those .java files is too annoying and source code generation not known to many developers, don't know, but the APIs do not necessarily tell if additional classes are used for the implementation (and thus IMHO do not forbid to do so). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From petr.czekaj at vaecontrols.cz Thu Sep 4 07:07:11 2008 From: petr.czekaj at vaecontrols.cz (Petr Czekaj) Date: Thu, 4 Sep 2008 15:07:11 +0200 Subject: [Rxtx] Undisplay "Stable library" Message-ID: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> Hi, is there a way to use RXTX library without writing text: "Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7" into console window just after calling "getPortIdentifiers()" method? Thank you Peter -------------------------------------------- VAE Controls - mailto:info at vaecontrols.cz tel. +420 596 240 011 ; fax. +420 596 242 153 Tato zprava a pripadne prilohy jsou duverne a jsou vyhradne urceny pro pouziti adresata. Jestlize jste ji obdrzeli omylem, ozvete se prosim na vyse uvedenou adresu. Vsechny nazory a myslenky jsou vyhradne odesilatele a nemusi nutne prezentovat stanovisko VAE Controls s.r.o. VAE Controls si rezervuje veskera prava na monitoring elektronicke posty, prochazejici z/do vlastni firemni site. Tato zprava byla zkontrolovana antivirovym programem, nicmene firma VAE Controls neni zodpovedna za pripadne skody zpusobene prijmem nedetekovanych viru. CONFIDENTIALITY NOTICE: The information in this e-mail, including any attachment, is confidential and may be legally privileged. This e-mail is intended solely for the addressee. If you are not the addressee, dissemination, copying or other use of this e-mail or any of its content is strictly prohibited and may be unlawful. If you are not the intended recipient please inform the sender immediately and destroy the e-mail and any copies. E-mails and unencrypted attachments are scanned for all known viruses. Always scan e-mail attachments for viruses before opening them. All liability for viruses is excluded to the fullest extent permitted by law. Any views expressed in this message are those of the individual sender. -------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080904/10087013/attachment-0005.html From Martin.Oberhuber at windriver.com Thu Sep 4 07:34:45 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 4 Sep 2008 15:34:45 +0200 Subject: [Rxtx] Undisplay "Stable library" In-Reply-To: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> References: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> Message-ID: <460801A4097E3D4CA04CC64EE6485848075ABFE4@ism-mail03.corp.ad.wrs.com> You can do java -Dgnu.io.rxtx.NoVersionOutput or programmatically set that System Property in your App. Unfortunately the feature of muting the version info was added only shortly after releasing RXTX 2.1-7r2 so you either need to build RXTX from the sources out of CVS, or you get the Eclipse variant binaries from http://rxtx.qbang.org/eclipse/downloads Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Petr Czekaj Sent: Thursday, September 04, 2008 3:07 PM To: rxtx at qbang.org Subject: [Rxtx] Undisplay "Stable library" Hi, is there a way to use RXTX library without writing text: "Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7" into console window just after calling "getPortIdentifiers()" method? Thank you Peter -------------------------------------------- VAE Controls - mailto:info at vaecontrols.cz tel. +420 596 240 011 ; fax. +420 596 242 153 Tato zprava a pripadne prilohy jsou duverne a jsou vyhradne urceny pro pouziti adresata. Jestlize jste ji obdrzeli omylem, ozvete se prosim na vyse uvedenou adresu. Vsechny nazory a myslenky jsou vyhradne odesilatele a nemusi nutne prezentovat stanovisko VAE Controls s.r.o. VAE Controls si rezervuje veskera prava na monitoring elektronicke posty, prochazejici z/do vlastni firemni site. Tato zprava byla zkontrolovana antivirovym programem, nicmene firma VAE Controls neni zodpovedna za pripadne skody zpusobene prijmem nedetekovanych viru. CONFIDENTIALITY NOTICE: The information in this e-mail, including any attachment, is confidential and may be legally privileged. This e-mail is intended solely for the addressee. If you are not the addressee, dissemination, copying or other use of this e-mail or any of its content is strictly prohibited and may be unlawful. If you are not the intended recipient please inform the sender immediately and destroy the e-mail and any copies. E-mails and unencrypted attachments are scanned for all known viruses. Always scan e-mail attachments for viruses before opening them. All liability for viruses is excluded to the fullest extent permitted by law. Any views expressed in this message are those of the individual sender. -------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080904/d70fbd85/attachment-0004.html From michael.erskine at ketech.com Thu Sep 4 07:36:36 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Thu, 4 Sep 2008 14:36:36 +0100 Subject: [Rxtx] Undisplay "Stable library" In-Reply-To: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> References: <13AD0DE4CD302F4E95A685BFEC811BAA018DB8BD@Simpson> Message-ID: <06BA3262D918014F9183B66425D5A8D43608077CBD@no-sv-03.ketech.local> > Hi, is there a way to use RXTX library without writing text: > "Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7" > > into console window just after calling "getPortIdentifiers()" method? Yes, prior to any calls that would cause the classloader to pull in RXTX, redirect standard output to a temporary PrintStream (with java.lang.System.setOut() ) and then restore later if required! Regards, Michael Erskine. From Martin.Oberhuber at windriver.com Fri Sep 5 14:18:30 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 5 Sep 2008 22:18:30 +0200 Subject: [Rxtx] Why does testRead() lock the port? Message-ID: <460801A4097E3D4CA04CC64EE6485848076760E1@ism-mail03.corp.ad.wrs.com> Hi all, When RXTX initializes, it scans available (serial) ports. It does so by calling a testRead() native method, which tries to open each port and get some settings. What I don't understand, is why in SerialImp.c line 4322 the code tries to LOCK the port in this context? The result seems to be, that if a different application (e.g. minicom) currently owns the port, the port won't even be scanned. Users don't see the port listed in their Java app and never get the idea that this might be due to another App currently owning the port. That doesn't seem desired, and port locking doesn't seem necessary since the code only reads the port. Does anybody have a clue why the port is locked here? Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080905/c5c94c2d/attachment-0003.html From shaney at basis.com Fri Sep 5 15:47:02 2008 From: shaney at basis.com (Shaun Haney) Date: Fri, 5 Sep 2008 15:47:02 -0600 Subject: [Rxtx] Rxtx is not finding serial ports on Solaris Message-ID: <07CB4F76556D489DBA9D17963C41CB0D@basis.com> Hi. I am wondering if anyone has tried using RXTX on Solaris/SPARC or Solaris/Intel. The problem that I am experiencing on both platforms is CommPortIdentifier.getPortIdentifiers() is returning a completely empty list of ports. On both systems, I have a modem attached to the serial port. The serial port device on both systems is /dev/cua/a. At the commandline, I can type 'echo "Hello There Nice Day Isnt it" > /dev/cua/a' and the modem will flicker indicating it's received information. The test program I am using is: ============================================================================ ========= // /SerialFinder.java // import gnu.io.*; import java.util.*; public class SerialFinder { public static final void main(String args[]) throws gnu.io.NoSuchPortException { Enumeration portList; CommPortIdentifier current; portList=CommPortIdentifier.getPortIdentifiers(); System.out.println("gnu.io.rxtx.SerialPorts="+System.getProperty("gnu.io.rxt x.SerialPorts")); System.out.println("List>>>"); while (portList.hasMoreElements()) { current=(CommPortIdentifier)portList.nextElement(); System.out.println(current.getName()); } System.out.println("<<>> << References: <07CB4F76556D489DBA9D17963C41CB0D@basis.com> Message-ID: <081660F391DA4B05A6DC90FCAF42403E@basis.com> I found some more information, so I thought I'd include it. It's Solaris 10/SunOS 5.10 on both the Sparc and Intel platforms that do not produce a list of ports. I just tried the same sample program on a Solaris 8 Intel machine and it listed /dev/term/a and /dev/term/b. Has anyone ever used RXTX on Solaris 10? Shaun Haney Software Test Engineer BASIS International Ltd. shaney at basis.com _____ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Shaun Haney Sent: Friday, September 05, 2008 3:47 PM To: rxtx at qbang.org Subject: [Rxtx] Rxtx is not finding serial ports on Solaris Hi. I am wondering if anyone has tried using RXTX on Solaris/SPARC or Solaris/Intel. The problem that I am experiencing on both platforms is CommPortIdentifier.getPortIdentifiers() is returning a completely empty list of ports. On both systems, I have a modem attached to the serial port. The serial port device on both systems is /dev/cua/a. At the commandline, I can type 'echo "Hello There Nice Day Isnt it" > /dev/cua/a' and the modem will flicker indicating it's received information. The test program I am using is: ============================================================================ ========= // /SerialFinder.java // import gnu.io.*; import java.util.*; public class SerialFinder { public static final void main(String args[]) throws gnu.io.NoSuchPortException { Enumeration portList; CommPortIdentifier current; portList=CommPortIdentifier.getPortIdentifiers(); System.out.println("gnu.io.rxtx.SerialPorts="+System.getProperty("gnu.io.rxt x.SerialPorts")); System.out.println("List>>>"); while (portList.hasMoreElements()) { current=(CommPortIdentifier)portList.nextElement(); System.out.println(current.getName()); } System.out.println("<<>> << References: <460801A4097E3D4CA04CC64EE6485848076760E1@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 5 Sep 2008, Oberhuber, Martin wrote: > Hi all, > > When RXTX initializes, it scans available (serial) ports. > It does so by calling a testRead() native method, which > tries to open each port and get some settings. > > What I don't understand, is why in SerialImp.c line 4322 > the code tries to LOCK the port in this context? > > The result seems to be, that if a different application (e.g. > minicom) currently owns the port, the port won't even be > scanned. Users don't see the port listed in their Java app > and never get the idea that this might be due to another > App currently owning the port. > > That doesn't seem desired, and port locking doesn't seem > necessary since the code only reads the port. > > Does anybody have a clue why the port is locked here? > Hi Martin, The port is locked because reading can cause problems for other applications. If a critical application opens a port and does a quick read (such as getting NMEA information from a GPS), some of the data will be taken by rxtx corrupting the incomming stream. The port scanning with locked ports is intended to behave the same on all systems. Windows will not enumerate a port if it is open by hyperterm also. I'm not against changing the reporting ports that are in use if a way is found to be consistant between systems. I think it must be possible as hyperterm can open ports rxtx has open as I recall. There are also the registry, hald and others that wouldnt require opening ports. I'm not sure that changing in a consitant way is going to be all that easy. More historical than important; when I put the code in, I figured if the port was locked, there was no way we could get the port for the user so there wasn't any point in reporting it as available. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 5 20:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 5 Sep 2008 20:38:30 -0600 (MDT) Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> Message-ID: On Mon, 1 Sep 2008, Oberhuber, Martin wrote: > Hi all, > > here is my proposal for improving port locking in RXTX. > > 1. Goals of the Proposal > > * Support enabling / disabling / configuring port locking at > runtime without re-compiling RXTX. > * Support port locking by Kernel call even if permissions for > lockfiles are not sufficient. > * Report exact reason for failure to acquire a port to the client > application (including the file system path of a lockfile for instance). > > 2. Getting the settings into RXTX > > * Use Java System Properties for tuning behavior (since the RXTX / > javax.comm API is frozen): > * -Dgnu.io.rxtx.LockfileDir=/var/lock # specify location of > lockfile directory, similar to minicom > * -Dgnu.io.rxtx.LockPolicy=none # no port locking, no > warnings or anything > * -Dgnu.io.rxtx.LockPolicy=default # try lockfiles, in case of > missing permission fall back to kernel locks without warning > * -Dgnu.io.rxtx.LockPolicy=warn # try lockfiles, in case of > missing permission fall back to kernel locks with warning to stdout > * -Dgnu.io.rxtx.LockPolicy=strict # require lockfiles, throw > exception if they cannot be created. > > The "default" policy would try to be as good a citizen as possible > (create lockfiles if possible, create Kernel > exclusive lock if possible), but without guarantee and without warning > in case it fails creating any lock. > > The warning to stdout would be something like "Warning: RXTX failed to > create a lockfile in /var/lock/LCK..ttyS0. Check file system permissions > or specify -Dgnu.io.rxtx.LockfileDir in order to enable proper locking > of serial ports against other applications". > > 3. Error Reporting out of RXTX > > * All errors acquiring a port are reported by means of a > gnu.io.rxtx.PortInUseException on CommPortIdentifier#open(). > * In case of missing permissions or other unexpected failure > running through open(), the "currentOwner" field is filled with the > String "Unexpected Error", and the message field of the exception is > filled with a String like "/dev/ttyS0 : Permission denied in open()" or > "/var/lock/LCK..ttyS0 : Permission denied in write()" > * In case of properly running through open() but not being able to > lock the port, the "currentOwner" field is populated with the name and > PID of the external process locking the port if it can be obtained, or > "Unknown Application" otherwise. > > In other words, I'm proposing to replace Sun's RuntimeException for > reporting unexpected errors with a PortInUseException with the owner > String set to "Unexpected Error" and detail information in the message > field of the exception. In case any file system resource is related to > the unexpected error, it must be mentioned first and separated by a " : > " String such that clients can parse the actual file system resource out > of the message automatically. > > I thought about subclassing PortInUseException to provide more error > details and type-safe parsing of the affected resource but wasn't so > sure about it in the end. > > What do others think about this proposal? Would it make more sense to > throw a RuntimeException for unexpected errors, rather than a > PortInUseException with the String "Unexpected Error" ? Do the proposed > port locking policies make sense? Is the naming proper? > > I'll next work on a patch to implement the proposal (or any modification > as discussed on this list). > This is all fine by me. You may want to look at Werner Almesberger's code in src/psmisc. He gave permission to use that code in RXTX. But a better solution would be something that was in a shared library provided by distros. The psmisc code reports PID and application name when the port is in use. It probably has a bit of bitrot and is not light reading. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 5 20:42:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 5 Sep 2008 20:42:45 -0600 (MDT) Subject: [Rxtx] [Suspected Spam][Blocked Sender]Re: Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <460801A4097E3D4CA04CC64EE6485848074C4259@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com><13557-75390@sneakemail.com><20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> <460801A4097E3D4CA04CC64EE6485848074C4259@ism-mail03.corp.ad.wrs.com> Message-ID: No problems here. Sounds great. On Mon, 1 Sep 2008, Oberhuber, Martin wrote: > Hi Bruce, > > I think that the only way to avoid temparary disconnect during port > scanning, > is to avoid the temporary open() during port scanning. That, however, > can only > be avoided if there is some external means to enumerate the candidates > for > valid port names. > > The javax.comm implementations by Sun and IBM use a file named > "javax.comm.properties" for this. On Linux and Solaris, it enumerates > the allowed prefixes for device names to be used. Those prefixes known, > the library treats all existing files with such prefixes as valid ports, > without > trying to actually open them. See http://java.sun.com/products/javacomm/ > > I'd think that one option to simplify the port scanning would be to use > a Java System Property to specify the Policy for port scanning. > For instance: > -Dgnu.io.rxtx.PortScanningPolicy=read # try to open & read > scanned ports > -Dgnu.io.rxtx.PortScanningPolicy=existing # treat ports as valid if > they exist > > For enumerating the candidates to check, the "gnu.io.rxtx.properties" > file already exists as well as the "gnu.io.rxtx.SerialPorts" and > "gnu.io.rxtx.ParallelPorts" System Properties. These support > explicit enumeration of port candidates. > > So, a second possible enhancement in addition to support > specifying the PortScanningPolicy could be to support > specifying prefix names for port enumeration rather than > just explicit enumeration. > > What do others think about these ideas? Could these improve > the long-standing performance issues with USB / Bluetooth > adapters during port scanning? Why does RXTX try to open > scanned ports in the first place, rather than relying on plain > existence of the devices? > > I'd guess that a Patch providing these enhancements would be > appreciated by the RXTX community. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > > ________________________________ > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On > Behalf Of Bruce Boyes > Sent: Tuesday, August 05, 2008 3:13 AM > To: Rxtx at qbang.org > Subject: [Suspected Spam][Blocked Sender]Re: [Rxtx] Towards an > RXTX release - CSR BT/USB chipset > > > At 18:37 07/29/2008, you wrote: > > > All, > > Is there any chance that the next official release could > improve on the port scanning (getPortIdentifiers)? > > > It would be nice if rxtx could also not cause a > connect/disconnect and subsequent problems with a USB Bluetooth > BlueSoleil adapter (using the CSR chipset), as documented in a previous > email from me. > > best regards > > Bruce > > > > ------- WWW.SYSTRONIX.COM > ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > From tjarvi at qbang.org Fri Sep 5 21:03:03 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 5 Sep 2008 21:03:03 -0600 (MDT) Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: > I'm just not exactly sure how Zystem is to be used, but it > should work somehow... Trent, any help Zystem was a total hack (Zystem is System with the S turned around) to get critical timing information out of RXTX for debugging. I never committed the source, but most of Zystem's functionality for me was yanked out of Python's native code and used as a one off debug tool to timestamp events. I submited the Java shell with options for turning on and off debugging. There would have been license issues with submitting the timestamp code. Since then some others have contributed pieces in that add j2ee logging and such. I think Zystem would be usable if some static vars came from properties with quiet defaults. The main place Zystem is used is in RXTXPort.java right now.. These may not make sense anymore. We could jerrymander (alter) the flags to suit new needs. protected final static boolean debug = false; protected final static boolean debug_read = false; protected final static boolean debug_read_results = false; protected final static boolean debug_write = false; protected final static boolean debug_events = false; protected final static boolean debug_verbose = false; private static Zystem z; static { try { z = new Zystem(); } catch ( Exception e ) {}; if(debug ) z.reportln( "RXTXPort {}"); ... I no longer have plans for Zystem. If something shipping with the JRE makes more sense, we could take it out. If it is close enough to fit into a new role, we can alter it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 5 21:40:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 5 Sep 2008 21:40:42 -0600 (MDT) Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: > In my opinion, it is still important that programs which use > RXTX can be ported to the Sun javax.comm APIs easily (that is, > just by doing a String replace of > sed -e 's,gnu\.io\.,javax.comm,g' > on all files. Creating new classes or interfaces makes that > impossible. > > What do others on this list think? Is this still important, > or can we fork off javax.comm since that's not really maintained > any more anyways? > > Note that especially on embedded devices (J2ME), many vendors > provide native javax.comm implementations, so porting an RXTX > based program onto such a J2ME vm is much easier if we restrict > ourselves to the original API. > In the end, everyone has a say. Answering what I think. I would consider breaking away from javax.comm 2.0 to be when we should call a version rxtx 3.0. I know you mentioned wanting to call the next release 3.0 but that really is for letting people know we intentionally broke the API. Right now, I suspect that doing so will not be a win in the end for users or developers. I have no problem starting a 3.0 branch to see what happens. Let it turn, churn and burn. If it becomes popular all the better. Until such a venture is obviously better, we should probably be conservative. Communicating such a final transition should be very deliberate if we do it. Just pulling the rug out from under existing applications would not be nice. We can add, extend, offer hooks for changing behavior and more without breaking applications using rxtx 2.1. We can become more liberal with such extensions - the rules for what is right have most definitely changed by example. Until it is obviously impossible to work with what we have, I'd suggest going that route. Any such features should probably be downplayed so applications can work realitivley easily on things like J2ME solutions as you mentioned. In the end, it would be nice to agree with other solutions what is right. We should remain very receptive towards such efforts and perhaps lead one if we have the resources. Multiple different solutions will hurt everyone. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 5 22:13:01 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 5 Sep 2008 22:13:01 -0600 (MDT) Subject: [Rxtx] Test bins comming soon. Message-ID: I've been working on getting rxtx binaries together for Win64 and Maci64. This has gone fairly well. There are some minor bugs I'll be reporting in bugzilla and fixing. I'd like to put out a 2.1-8pre1 collection of bins Sunday. We can discuss the version information also. Please start a new thread if you would like to discuss that. I assume we will be making a few of these regardless of the version. If there is something you would like to get in to the first iteration, you may want to let me know. I'm assuming there will be more changes comming. I just want to start the process so it isn't a big deal when the time comes. I also have some minor fixes that will be comming in after the first prerelease. I'll be putting those in bugzilla also. Obviously, Martin has work he is looking into that would be comming. My actual coding efforts will be more along the lines of cleaning up minor details in rxtx that are long standing bugs. I have a list of about 5 minor bugs not yet in bugzilla but in rxtx I want to clean up. If I have more time, I'll see what I can do for others also. What do people think about having the mail-list cc'd when there are new bugs and or changes to bugs? The activity is low enough for now that it shouldn't be a significant increase in traffic. Right now, it all goes into my inbox. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Sat Sep 6 14:46:57 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 6 Sep 2008 22:46:57 +0200 Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584807676151@ism-mail03.corp.ad.wrs.com> Hi all, after revolving around the port locking configuration in my mind for a bit, I thought that the following would be a good idea: (*) Keep as much of the dynamic config in Java as possible, and put as little as possible into the native libs. Try to be as flexible as possible. The concrete idea for doing this is as follows: Add to RXTXCommDriver { public static void setPortLockingPolicy(PortLockingPolicy p) } Add public class PortLockingPolicy { public String getLockfileDir() { return System.getProperty("gnu.io.rxtx.LockfileDir"); } public boolean getOpenExclMode(String portName) { return true; } public boolean getLockfileWarningMode(String portName) { return System.getProperty(... } } That is, the default impl of PortLockingPolicy is registered by default and uses System Properties as discussed previously. But anybody who needs more fine-grained control can subclass PortLockingPolicy and register it. Even separate settings per port get possible. We could also think about a PortLockingDelegate in order to modify existing behavior without overriding it, if we want. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Saturday, September 06, 2008 5:41 AM > To: Oberhuber, Martin > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: Re: [Rxtx] RXTX Port Locking Improvements > > > In my opinion, it is still important that programs which use > > RXTX can be ported to the Sun javax.comm APIs easily (that is, > > just by doing a String replace of > > sed -e 's,gnu\.io\.,javax.comm,g' > > on all files. Creating new classes or interfaces makes that > > impossible. > > > > What do others on this list think? Is this still important, > > or can we fork off javax.comm since that's not really maintained > > any more anyways? > > > > Note that especially on embedded devices (J2ME), many vendors > > provide native javax.comm implementations, so porting an RXTX > > based program onto such a J2ME vm is much easier if we restrict > > ourselves to the original API. > > > > In the end, everyone has a say. > > Answering what I think. > > I would consider breaking away from javax.comm 2.0 to be when > we should > call a version rxtx 3.0. I know you mentioned wanting to > call the next > release 3.0 but that really is for letting people know we > intentionally > broke the API. Right now, I suspect that doing so will not > be a win in > the end for users or developers. > > I have no problem starting a 3.0 branch to see what happens. Let it > turn, churn and burn. If it becomes popular all the better. > > Until such a venture is obviously better, we should probably be > conservative. Communicating such a final transition should be very > deliberate if we do it. Just pulling the rug out from under existing > applications would not be nice. > > We can add, extend, offer hooks for changing behavior and > more without > breaking applications using rxtx 2.1. We can become more > liberal with > such extensions - the rules for what is right have most > definitely changed > by example. Until it is obviously impossible to work with > what we have, > I'd suggest going that route. Any such features should probably be > downplayed so applications can work realitivley easily on > things like J2ME > solutions as you mentioned. > > In the end, it would be nice to agree with other solutions what is > right. We should remain very receptive towards such efforts > and perhaps > lead one if we have the resources. Multiple different > solutions will hurt > everyone. > > -- > Trent Jarvi > tjarvi at qbang.org > From Martin.Oberhuber at windriver.com Sat Sep 6 14:47:45 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 6 Sep 2008 22:47:45 +0200 Subject: [Rxtx] RXTX Port Locking Improvements References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584807676152@ism-mail03.corp.ad.wrs.com> PS Given that such an addition of an API Class would be adding API in a non-breaking way, the correct version number would be RXTX-2.2 IMHO. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Saturday, September 06, 2008 10:47 PM > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX Port Locking Improvements > > Hi all, > > after revolving around the port locking configuration in my > mind for a bit, I thought that the following would be a good > idea: > > (*) Keep as much of the dynamic config in Java as possible, > and put as little as possible into the native libs. > Try to be as flexible as possible. > > The concrete idea for doing this is as follows: > > Add to RXTXCommDriver { > public static void setPortLockingPolicy(PortLockingPolicy p) > } > > Add public class PortLockingPolicy { > public String getLockfileDir() { > return System.getProperty("gnu.io.rxtx.LockfileDir"); > } > > public boolean getOpenExclMode(String portName) { > return true; > } > > public boolean getLockfileWarningMode(String portName) { > return System.getProperty(... > } > } > > That is, the default impl of PortLockingPolicy is registered > by default and uses System Properties as discussed previously. > But anybody who needs more fine-grained control can subclass > PortLockingPolicy and register it. Even separate settings per > port get possible. We could also think about a PortLockingDelegate > in order to modify existing behavior without overriding it, > if we want. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Saturday, September 06, 2008 5:41 AM > > To: Oberhuber, Martin > > Cc: Steffen DETTMER; rxtx at qbang.org > > Subject: Re: [Rxtx] RXTX Port Locking Improvements > > > > > In my opinion, it is still important that programs which use > > > RXTX can be ported to the Sun javax.comm APIs easily (that is, > > > just by doing a String replace of > > > sed -e 's,gnu\.io\.,javax.comm,g' > > > on all files. Creating new classes or interfaces makes that > > > impossible. > > > > > > What do others on this list think? Is this still important, > > > or can we fork off javax.comm since that's not really maintained > > > any more anyways? > > > > > > Note that especially on embedded devices (J2ME), many vendors > > > provide native javax.comm implementations, so porting an RXTX > > > based program onto such a J2ME vm is much easier if we restrict > > > ourselves to the original API. > > > > > > > In the end, everyone has a say. > > > > Answering what I think. > > > > I would consider breaking away from javax.comm 2.0 to be when > > we should > > call a version rxtx 3.0. I know you mentioned wanting to > > call the next > > release 3.0 but that really is for letting people know we > > intentionally > > broke the API. Right now, I suspect that doing so will not > > be a win in > > the end for users or developers. > > > > I have no problem starting a 3.0 branch to see what > happens. Let it > > turn, churn and burn. If it becomes popular all the better. > > > > Until such a venture is obviously better, we should probably be > > conservative. Communicating such a final transition should be very > > deliberate if we do it. Just pulling the rug out from > under existing > > applications would not be nice. > > > > We can add, extend, offer hooks for changing behavior and > > more without > > breaking applications using rxtx 2.1. We can become more > > liberal with > > such extensions - the rules for what is right have most > > definitely changed > > by example. Until it is obviously impossible to work with > > what we have, > > I'd suggest going that route. Any such features should probably be > > downplayed so applications can work realitivley easily on > > things like J2ME > > solutions as you mentioned. > > > > In the end, it would be nice to agree with other solutions what is > > right. We should remain very receptive towards such efforts > > and perhaps > > lead one if we have the resources. Multiple different > > solutions will hurt > > everyone. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > From Martin.Oberhuber at windriver.com Sat Sep 6 14:51:08 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 6 Sep 2008 22:51:08 +0200 Subject: [Rxtx] Rxtx is not finding serial ports on Solaris In-Reply-To: <081660F391DA4B05A6DC90FCAF42403E@basis.com> References: <07CB4F76556D489DBA9D17963C41CB0D@basis.com> <081660F391DA4B05A6DC90FCAF42403E@basis.com> Message-ID: <460801A4097E3D4CA04CC64EE648584807676153@ism-mail03.corp.ad.wrs.com> Hm, it's working fine on Sol10-sparc for us commercially. Try the RXTX version on http://rxtx.qbang.org/eclipse/downloads read the README there for more info. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Shaun Haney Sent: Saturday, September 06, 2008 12:31 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Rxtx is not finding serial ports on Solaris I found some more information, so I thought I'd include it. It's Solaris 10/SunOS 5.10 on both the Sparc and Intel platforms that do not produce a list of ports. I just tried the same sample program on a Solaris 8 Intel machine and it listed /dev/term/a and /dev/term/b. Has anyone ever used RXTX on Solaris 10? Shaun Haney Software Test Engineer BASIS International Ltd. shaney at basis.com ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Shaun Haney Sent: Friday, September 05, 2008 3:47 PM To: rxtx at qbang.org Subject: [Rxtx] Rxtx is not finding serial ports on Solaris Hi. I am wondering if anyone has tried using RXTX on Solaris/SPARC or Solaris/Intel. The problem that I am experiencing on both platforms is CommPortIdentifier.getPortIdentifiers() is returning a completely empty list of ports. On both systems, I have a modem attached to the serial port. The serial port device on both systems is /dev/cua/a. At the commandline, I can type 'echo "Hello There Nice Day Isnt it" > /dev/cua/a' and the modem will flicker indicating it's received information. The test program I am using is: ======================================================================== ============= // /SerialFinder.java // import gnu.io.*; import java.util.*; public class SerialFinder { public static final void main(String args[]) throws gnu.io.NoSuchPortException { Enumeration portList; CommPortIdentifier current; portList=CommPortIdentifier.getPortIdentifiers(); System.out.println("gnu.io.rxtx.SerialPorts="+System.getProperty("gnu.io .rxtx.SerialPorts")); System.out.println("List>>>"); while (portList.hasMoreElements()) { current=(CommPortIdentifier)portList.nextElement(); System.out.println(current.getName()); } System.out.println("<<>> << References: <460801A4097E3D4CA04CC64EE6485848076760E1@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584807676154@ism-mail03.corp.ad.wrs.com> Hm, I see, thanks for the info. The original intention of my question was because I thought that with lockfiles enabled, locking each port in turn can be a performance hit when lots of ports are to be probed. Especially on Redhat / Fedora, where (if I add the baudboy support to be consistent), each lock operation leads to calling an external executable. I'd be interested in finding a way to see what port candidates are impossible (without doing a testRead), such that the testRead() can be applied to fewer candidates. > More historical than important; when I put the code in, I > figured if the port was locked, there was no way we could > get the port for the user so there wasn't any point in > reporting it as available. Our users tend to "forget" (or not even be aware) that some program is still hogging a port. So, when they don't see the port in our main app they think there's a bug and don't understand how to make the port visible. What I'd love to see from a User's point of view, is having a port list like /dev/ttyS0 /dev/ttyS1 (locked by 12235) /dev/ttyS2 (no permission) /dev/ttyS3 (locked by unknown) Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Saturday, September 06, 2008 4:31 AM > To: Oberhuber, Martin > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Why does testRead() lock the port? > > On Fri, 5 Sep 2008, Oberhuber, Martin wrote: > > > Hi all, > > > > When RXTX initializes, it scans available (serial) ports. > > It does so by calling a testRead() native method, which > > tries to open each port and get some settings. > > > > What I don't understand, is why in SerialImp.c line 4322 > > the code tries to LOCK the port in this context? > > > > The result seems to be, that if a different application (e.g. > > minicom) currently owns the port, the port won't even be > > scanned. Users don't see the port listed in their Java app > > and never get the idea that this might be due to another > > App currently owning the port. > > > > That doesn't seem desired, and port locking doesn't seem > > necessary since the code only reads the port. > > > > Does anybody have a clue why the port is locked here? > > > > Hi Martin, > > The port is locked because reading can cause problems for other > applications. If a critical application opens a port and > does a quick > read (such as getting NMEA information from a GPS), some of > the data will > be taken by rxtx corrupting the incomming stream. > > The port scanning with locked ports is intended to behave the > same on all > systems. Windows will not enumerate a port if it is open by > hyperterm also. > > I'm not against changing the reporting ports that are in use > if a way is > found to be consistant between systems. I think it must be > possible as > hyperterm can open ports rxtx has open as I recall. There > are also the > registry, hald and others that wouldnt require opening ports. > I'm not > sure that changing in a consitant way is going to be all that easy. > > More historical than important; when I put the code in, I > figured if the > port was locked, there was no way we could get the port for > the user so > there wasn't any point in reporting it as available. > > -- > Trent Jarvi > tjarvi at qbang.org > From tjarvi at qbang.org Sat Sep 6 15:07:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 6 Sep 2008 15:07:54 -0600 (MDT) Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE648584807676151@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584807676151@ism-mail03.corp.ad.wrs.com> Message-ID: Hi Martin, I would consider using Serial in the new classname - perhaps with a more generic parent class. As an example of why, one possible direction for RXTX in the future could be contributing to of Java implementation of the well defined VISA standard; an abstraction of serial, tcpip, udp, gpib, vxi-11, usb, ... used in instrumentation that does away with having to worry about what the port name is. You just use resource strings that work on all systems: "ASRL1::instr" There may be several types of ports in such a case. It is fairly inexpensive timewise to create a generic parent class. The methods may then throw UnsupportedLockOperation exceptions or such. On Sat, 6 Sep 2008, Oberhuber, Martin wrote: > Hi all, > > after revolving around the port locking configuration in my > mind for a bit, I thought that the following would be a good > idea: > > (*) Keep as much of the dynamic config in Java as possible, > and put as little as possible into the native libs. > Try to be as flexible as possible. > > The concrete idea for doing this is as follows: > > Add to RXTXCommDriver { > public static void setPortLockingPolicy(PortLockingPolicy p) > } > > Add public class PortLockingPolicy { > public String getLockfileDir() { > return System.getProperty("gnu.io.rxtx.LockfileDir"); > } > > public boolean getOpenExclMode(String portName) { > return true; > } > > public boolean getLockfileWarningMode(String portName) { > return System.getProperty(... > } > } > > That is, the default impl of PortLockingPolicy is registered > by default and uses System Properties as discussed previously. > But anybody who needs more fine-grained control can subclass > PortLockingPolicy and register it. Even separate settings per > port get possible. We could also think about a PortLockingDelegate > in order to modify existing behavior without overriding it, > if we want. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Saturday, September 06, 2008 5:41 AM >> To: Oberhuber, Martin >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: Re: [Rxtx] RXTX Port Locking Improvements >> >>> In my opinion, it is still important that programs which use >>> RXTX can be ported to the Sun javax.comm APIs easily (that is, >>> just by doing a String replace of >>> sed -e 's,gnu\.io\.,javax.comm,g' >>> on all files. Creating new classes or interfaces makes that >>> impossible. >>> >>> What do others on this list think? Is this still important, >>> or can we fork off javax.comm since that's not really maintained >>> any more anyways? >>> >>> Note that especially on embedded devices (J2ME), many vendors >>> provide native javax.comm implementations, so porting an RXTX >>> based program onto such a J2ME vm is much easier if we restrict >>> ourselves to the original API. >>> >> >> In the end, everyone has a say. >> >> Answering what I think. >> >> I would consider breaking away from javax.comm 2.0 to be when >> we should >> call a version rxtx 3.0. I know you mentioned wanting to >> call the next >> release 3.0 but that really is for letting people know we >> intentionally >> broke the API. Right now, I suspect that doing so will not >> be a win in >> the end for users or developers. >> >> I have no problem starting a 3.0 branch to see what happens. Let it >> turn, churn and burn. If it becomes popular all the better. >> >> Until such a venture is obviously better, we should probably be >> conservative. Communicating such a final transition should be very >> deliberate if we do it. Just pulling the rug out from under existing >> applications would not be nice. >> >> We can add, extend, offer hooks for changing behavior and >> more without >> breaking applications using rxtx 2.1. We can become more >> liberal with >> such extensions - the rules for what is right have most >> definitely changed >> by example. Until it is obviously impossible to work with >> what we have, >> I'd suggest going that route. Any such features should probably be >> downplayed so applications can work realitivley easily on >> things like J2ME >> solutions as you mentioned. >> >> In the end, it would be nice to agree with other solutions what is >> right. We should remain very receptive towards such efforts >> and perhaps >> lead one if we have the resources. Multiple different >> solutions will hurt >> everyone. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > From tjarvi at qbang.org Sat Sep 6 18:39:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 6 Sep 2008 18:39:59 -0600 (MDT) Subject: [Rxtx] RXTX Port Locking Improvements In-Reply-To: <460801A4097E3D4CA04CC64EE648584807676152@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848074C4286@ism-mail03.corp.ad.wrs.com> <20080901173353.GE17898@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848075AB9B0@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584807676152@ism-mail03.corp.ad.wrs.com> Message-ID: Fair enough. As we add to the API and retain backwards compatability it will be 2.1+n if there is no objection. Dot (aka dash) releases will not change the API or properties used at all. On Sat, 6 Sep 2008, Oberhuber, Martin wrote: > PS > > Given that such an addition of an API Class would be > adding API in a non-breaking way, the correct version > number would be RXTX-2.2 IMHO. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Saturday, September 06, 2008 10:47 PM >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX Port Locking Improvements >> >> Hi all, >> >> after revolving around the port locking configuration in my >> mind for a bit, I thought that the following would be a good >> idea: >> >> (*) Keep as much of the dynamic config in Java as possible, >> and put as little as possible into the native libs. >> Try to be as flexible as possible. >> >> The concrete idea for doing this is as follows: >> >> Add to RXTXCommDriver { >> public static void setPortLockingPolicy(PortLockingPolicy p) >> } >> >> Add public class PortLockingPolicy { >> public String getLockfileDir() { >> return System.getProperty("gnu.io.rxtx.LockfileDir"); >> } >> >> public boolean getOpenExclMode(String portName) { >> return true; >> } >> >> public boolean getLockfileWarningMode(String portName) { >> return System.getProperty(... >> } >> } >> >> That is, the default impl of PortLockingPolicy is registered >> by default and uses System Properties as discussed previously. >> But anybody who needs more fine-grained control can subclass >> PortLockingPolicy and register it. Even separate settings per >> port get possible. We could also think about a PortLockingDelegate >> in order to modify existing behavior without overriding it, >> if we want. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Saturday, September 06, 2008 5:41 AM >>> To: Oberhuber, Martin >>> Cc: Steffen DETTMER; rxtx at qbang.org >>> Subject: Re: [Rxtx] RXTX Port Locking Improvements >>> >>>> In my opinion, it is still important that programs which use >>>> RXTX can be ported to the Sun javax.comm APIs easily (that is, >>>> just by doing a String replace of >>>> sed -e 's,gnu\.io\.,javax.comm,g' >>>> on all files. Creating new classes or interfaces makes that >>>> impossible. >>>> >>>> What do others on this list think? Is this still important, >>>> or can we fork off javax.comm since that's not really maintained >>>> any more anyways? >>>> >>>> Note that especially on embedded devices (J2ME), many vendors >>>> provide native javax.comm implementations, so porting an RXTX >>>> based program onto such a J2ME vm is much easier if we restrict >>>> ourselves to the original API. >>>> >>> >>> In the end, everyone has a say. >>> >>> Answering what I think. >>> >>> I would consider breaking away from javax.comm 2.0 to be when >>> we should >>> call a version rxtx 3.0. I know you mentioned wanting to >>> call the next >>> release 3.0 but that really is for letting people know we >>> intentionally >>> broke the API. Right now, I suspect that doing so will not >>> be a win in >>> the end for users or developers. >>> >>> I have no problem starting a 3.0 branch to see what >> happens. Let it >>> turn, churn and burn. If it becomes popular all the better. >>> >>> Until such a venture is obviously better, we should probably be >>> conservative. Communicating such a final transition should be very >>> deliberate if we do it. Just pulling the rug out from >> under existing >>> applications would not be nice. >>> >>> We can add, extend, offer hooks for changing behavior and >>> more without >>> breaking applications using rxtx 2.1. We can become more >>> liberal with >>> such extensions - the rules for what is right have most >>> definitely changed >>> by example. Until it is obviously impossible to work with >>> what we have, >>> I'd suggest going that route. Any such features should probably be >>> downplayed so applications can work realitivley easily on >>> things like J2ME >>> solutions as you mentioned. >>> >>> In the end, it would be nice to agree with other solutions what is >>> right. We should remain very receptive towards such efforts >>> and perhaps >>> lead one if we have the resources. Multiple different >>> solutions will hurt >>> everyone. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> > From chris_j_collins at yahoo.com Sun Sep 7 17:43:13 2008 From: chris_j_collins at yahoo.com (Chris Collins) Date: Sun, 7 Sep 2008 16:43:13 -0700 Subject: [Rxtx] Compiling rxtx for 64 bit java vm macosx Message-ID: <8B6E2F97-521A-45D3-AF9E-1138C38EB373@yahoo.com> Has anyone had any luck getting rxtx working with 64 bit mac osx running 1.6? Thanks Chris Collins From tjarvi at qbang.org Sun Sep 7 18:36:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 7 Sep 2008 18:36:55 -0600 (MDT) Subject: [Rxtx] Compiling rxtx for 64 bit java vm macosx In-Reply-To: <8B6E2F97-521A-45D3-AF9E-1138C38EB373@yahoo.com> References: <8B6E2F97-521A-45D3-AF9E-1138C38EB373@yahoo.com> Message-ID: On Sun, 7 Sep 2008, Chris Collins wrote: > Has anyone had any luck getting rxtx working with 64 bit mac osx > running 1.6? > Hi Chris, On MAC OS X, I'm using the 1.5 JRE without major issues. What are you running into with 1.6? -- Trent Jarvi tjarvi at qbang.org From chris_j_collins at yahoo.com Sun Sep 7 20:05:22 2008 From: chris_j_collins at yahoo.com (Chris Collins) Date: Sun, 7 Sep 2008 19:05:22 -0700 Subject: [Rxtx] Compiling rxtx for 64 bit java vm macosx In-Reply-To: References: <8B6E2F97-521A-45D3-AF9E-1138C38EB373@yahoo.com> Message-ID: <3CE43973-E515-4F5C-A2B4-5B7FEC779A95@yahoo.com> If I build it, I see that with lipo -info that the jnilib is built for ppc and i386. There is no x86_64 architecture. I would of liked a fat binary for both 32 bit and 64 bit since I now usually use a 64 bit vm. regards Chris On Sep 7, 2008, at 5:36 PM, Trent Jarvi wrote: > On Sun, 7 Sep 2008, Chris Collins wrote: > >> Has anyone had any luck getting rxtx working with 64 bit mac osx >> running 1.6? >> > > > Hi Chris, > > On MAC OS X, I'm using the 1.5 JRE without major issues. What are > you running into with 1.6? > > -- > Trent Jarvi > tjarvi at qbang.org From tjarvi at qbang.org Sun Sep 7 20:47:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 7 Sep 2008 20:47:23 -0600 (MDT) Subject: [Rxtx] Compiling rxtx for 64 bit java vm macosx In-Reply-To: <3CE43973-E515-4F5C-A2B4-5B7FEC779A95@yahoo.com> References: <8B6E2F97-521A-45D3-AF9E-1138C38EB373@yahoo.com> <3CE43973-E515-4F5C-A2B4-5B7FEC779A95@yahoo.com> Message-ID: Hi Chris, With the xcode build, you just need to add the x86_64 architecture via the project menus. I was able to build i386 and x86_64 that way with leopard 10.5 but didnt see that it was possible to include ppc. I still need to get the makefiles working. On Sun, 7 Sep 2008, Chris Collins wrote: > If I build it, I see that with lipo -info that the jnilib is built for > ppc and i386. There is no x86_64 architecture. I would of liked a fat > binary for both 32 bit and 64 bit since I now usually use a 64 bit vm. > > regards > > Chris > On Sep 7, 2008, at 5:36 PM, Trent Jarvi wrote: > >> On Sun, 7 Sep 2008, Chris Collins wrote: >> >>> Has anyone had any luck getting rxtx working with 64 bit mac osx >>> running 1.6? >>> >> >> >> Hi Chris, >> >> On MAC OS X, I'm using the 1.5 JRE without major issues. What are >> you running into with 1.6? >> >> -- >> Trent Jarvi >> tjarvi at qbang.org From chris_j_collins at yahoo.com Sun Sep 7 20:52:11 2008 From: chris_j_collins at yahoo.com (Chris Collins) Date: Sun, 7 Sep 2008 19:52:11 -0700 Subject: [Rxtx] Compiling rxtx for 64 bit java vm macosx In-Reply-To: References: <8B6E2F97-521A-45D3-AF9E-1138C38EB373@yahoo.com> <3CE43973-E515-4F5C-A2B4-5B7FEC779A95@yahoo.com> Message-ID: <0DF34129-BC82-4D94-8209-93EC21B866F4@yahoo.com> Thanks Trent. I will try that out. regards Chris On Sep 7, 2008, at 7:47 PM, Trent Jarvi wrote: > > Hi Chris, > > With the xcode build, you just need to add the x86_64 architecture > via the project menus. I was able to build i386 and x86_64 that way > with leopard 10.5 but didnt see that it was possible to include > ppc. I still need to get the makefiles working. > > On Sun, 7 Sep 2008, Chris Collins wrote: > >> If I build it, I see that with lipo -info that the jnilib is built >> for ppc and i386. There is no x86_64 architecture. I would of >> liked a fat binary for both 32 bit and 64 bit since I now usually >> use a 64 bit vm. >> >> regards >> >> Chris >> On Sep 7, 2008, at 5:36 PM, Trent Jarvi wrote: >> >>> On Sun, 7 Sep 2008, Chris Collins wrote: >>>> Has anyone had any luck getting rxtx working with 64 bit mac osx >>>> running 1.6? >>> Hi Chris, >>> On MAC OS X, I'm using the 1.5 JRE without major issues. What are >>> you running into with 1.6? >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org From chris_j_collins at yahoo.com Sun Sep 7 22:14:53 2008 From: chris_j_collins at yahoo.com (Chris Collins) Date: Sun, 7 Sep 2008 21:14:53 -0700 Subject: [Rxtx] Compiling rxtx for 64 bit java vm macosx In-Reply-To: <0DF34129-BC82-4D94-8209-93EC21B866F4@yahoo.com> References: <8B6E2F97-521A-45D3-AF9E-1138C38EB373@yahoo.com> <3CE43973-E515-4F5C-A2B4-5B7FEC779A95@yahoo.com> <0DF34129-BC82-4D94-8209-93EC21B866F4@yahoo.com> Message-ID: <40342835-1818-4738-AA5C-70C86318E229@yahoo.com> Didnt go down too well. I assume I load the On Sep 7, 2008, at 7:52 PM, Chris Collins wrote: MACOSX_IDE/PB/ LibSerialUniversal.xcodeproj Anyway, when I compile with xcode 3.1 I get. I have no clue what JAM is: Building target ?RXTXcomm? of project ?LibSerialUniversal? with configuration ?Deployment? ? (1 error, 1 warning) Checking Dependencies Jam is deprecated; targets that use Jam should be upgraded to native targets. For more information on doing this, consult the Xcode documentation. Jam is deprecated; targets that use Jam should be upgraded to native targets. For more information on doing this, consult the Xcode documentation. cd /Users/chris/pubsource/rxtx-2.1.1-7r2/MACOSX_IDE/PB /Developer/Private/jam -d1 -k -j8 JAMBASE=/Developer/Makefiles/ pbx_jamfiles/ProjectBuilderJambase JAMFILE=/Users/chris/pubsource/ rxtx-2.1.1-7r2/MACOSX_IDE/PB/build/LibSerialUniversal.build/Deployment/ RXTXcomm.build/RXTXcomm.jam build ACTION=build _DEFAULT_GCC_VERSION=4.0 GCC_VERSION_IDENTIFIER=__0 CONFIGURATION=Deployment BUILD_STYLE=Deployment CPP_HEADERMAP_FILE=/ Users/chris/pubsource/rxtx-2.1.1-7r2/MACOSX_IDE/PB/build/ LibSerialUniversal.build/Deployment/RXTXcomm.build/RXTXcomm.hmap SRCROOT=/Users/chris/pubsource/rxtx-2.1.1-7r2/MACOSX_IDE/PB OBJROOT=/ Users/chris/pubsource/rxtx-2.1.1-7r2/MACOSX_IDE/PB/build SYMROOT=/ Users/chris/pubsource/rxtx-2.1.1-7r2/MACOSX_IDE/PB/build DSTROOT=/tmp/ LibSerialUniversal.dst PLATFORM_DIR= EFFECTIVE_PLATFORM_NAME= PhaseScriptExecution /Users/chris/pubsource/rxtx-2.1.1-7r2/ MACOSX_IDE/PB/build/LibSerialUniversal.build/Deployment/RXTXcomm.build/ BPTag003-script.sh ...failed PhaseScriptExecution /Users/chris/pubsource/ rxtx-2.1.1-7r2/MACOSX_IDE/PB/build/LibSerialUniversal.build/Deployment/ RXTXcomm.build/BPTag003-script.sh ... ...skipped