[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rxtx
Subject:    Re: [Rxtx] Deployment Troubleshooting
From:       Trent Jarvi <taj () linuxgrrls ! org>
Date:       2003-08-04 15:07:14
[Download RAW message or body]



On Mon, 4 Aug 2003, Paul Holmes wrote:

> OK, so you develop an application using RXTX and the
> javax.comm API, you get it working just fine, you build
> an installer and after a few trials and tribulations
> get that going (on your favourite distro), and with a
> great sense of satisfaction, you send out your software.
> 
> The next day, you get your first call from a user -
> "I'm using Red Cat 7.8 and I can't see any serial ports."
> Half an hour later, 
> "I'm using Deviant 9.1 and I can't see any serial ports."
> Minutes after that,
> "I'm using Whizz-Bang 106.32 and I can't see any serial ports."
> ... and the rest of the day is like that.
> 
> You send them the RXTX troubleshooting guide, and they say,
> "Well thanks, but this is all new to me - it'll take
> me ages. Couldn't you have sorted this stuff out before
> you shipped your application?"
> 
> Turns out, each of them had a different thing go wrong.
> 
> This hasn't happened yet, to me at least, but sometime soon
> it might, and I'd like to prevent it if I can. Has anyone
> got any tips about how to write application code so that it
> can distinguish for itself between the several different
> mishaps that can make the ports disappear, and set each user
> on the right track from the outset?
> 
> Also, the guide lists a lot of requirements, but I'm
> getting the impression that some of these apply at compile
> time and others at run time. Does anyone have a list of
> these, so we can avoid chasing compile-time-only requirements
> at install time? (I don't expect many users to recompile,
> or to know how to.)
> 
> Does anyone have a good workaround for the fact that
> javax.comm "swallows" some exceptions generated by RXTX,
> instead of propagating them up as exceptions to the app
> code?
> 
> Paul.
> 
<snip>

I'm not sure which guidelines you mention.  Some are written by others 
just sharing their experiences.  Some are intended for developers or 
hobbiests.

You are probably going to run into 3 user errors.

1) Misconfigured BIOS or missing kernel drivers.

	"Can minicom open the port?"

2) Permissions on the port and lock directory

	"Does the application work as superuser?"

3) Distros moving lock directories, changing groups, or just generally
   being even more stupid than they have in the past.

	Suggestion is to start a fan club for standards like the FHS.


You could probably write a shell script that runs at install time that
tests most of this.  I don't know of anything that has been done in that
area yet.  The only right way to do this for customers is test what you
will support and list in detail what is supported.  It's not only port
enumeration that can go wrong.

With the Sun comm.jar eating exceptions, one can always opt to replace it.
rxtx 2.1 will give you complete code but be in the gnu.io name space.  
Kaffe is working on their own modification of rxtx 2.1 that will be in 
javax.comm - fairly early at this point though.  IBM also had something of 
a commapi for linux which is probably based on Sun's comm.jar.
_______________________________________________
Rxtx mailing list
Rxtx@linuxgrrls.org
http://hex.linuxgrrls.org/mailman/listinfo/rxtx
[prev in list] [next in list] [prev in thread] [next in thread]