LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 05-30-2011, 04:23 PM   #16
55020
Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 370
Blog Entries: 4

Rep: Reputation: 342Reputation: 342Reputation: 342Reputation: 342

Yes, the general approach sounds good and I've grabbed a copy of your rc script. It's too late for the 2.96 update, which has already been approved, but I'll definitely include this with the SBo SlackBuild next time, though it probably won't be fully enabled by default, to avoid surprises for people upgrading. gpsd 3.0 will be a big update anyway, as it's going over to cmake -- I already have an early draft and I'll update it and put it on github in the very near future.

As I said before, thanks for poking this with a pointy stick. It's been on my TODO list (near the bottom, just above "do proper backups") for a very long time and you've helped a lot
 
Old 05-30-2011, 05:45 PM   #17
xj25vm
Member
 
Registered: Jun 2008
Posts: 262

Original Poster
Rep: Reputation: 17
I am the one who should thank you for answering my questions, throwing in ideas and generally for any work you do for SBo. As a slacker, I find it very useful.

I've sent an email to both the gpsd-users and gpsd-dev lists suggesting that they might consider moving to a standard /etc/gpsd.conf file, with [global] and [device_name] type sections, based on serial number of devices (as hardware id's are unreliable for gps devices), and a gpsdconf command line wizard which can be run every time a new usb adapter is used for the first time - which would update gpsd.conf with the correct serial number, and any options the user might wish for that adapter. The whole process would be akin to pairing up with a gpsd adapter/receiver - the way bluetooth devices get paired up the first time they connect. This way, gpsd could use inotify (or something else) to know when a new ttyUSBx or ttySx device is plugged in, and if the serial number is in gpsd.conf, it would connect to it automatically. No more udev, no more gpsd.hotplug and gpsd.hotplug.wrapper and the rest of the complication. All would one do is start the gpsd binary on system startup, and be done with it.

In my mind, this would be a wonderfully simplified system - but I'm not holding my breath over it getting any traction. I could have equally missed something important in my grand scheming anyway :-)

I'll mark this thread as solved now - as I think it is as solved as it will ever get considering all factors involved. Thanks again for all your help.



P.S. Here is my idea of a /etc/gpsd.conf file:

Code:
#/etc/gpsd.conf
[global]
# port gpsd is listening on
port = "2947"
# socket for clients passing commands to gpsd
socket = "/var/run/gpsd.sock"
# start poling devices immediately
no_wait = "yes"
# don't re-configure the device
bt_safe = "no"

[my_gps_1]
serial = "0490r39c99d40"
# overwrite global setting
bt_safe = yes

[my_gps_2]
serial = "4999dfleklj5534"
# span a different daemon for this one
# and listen on different port
port = "3011"

[my_gps_3]
serial = "994sle4900032"
# this adapter is temporarily disabled
enable = "no"
 
Old 06-11-2011, 03:22 AM   #18
xj25vm
Member
 
Registered: Jun 2008
Posts: 262

Original Poster
Rep: Reputation: 17
I'm attaching a modified version of the rc.gpsd script as I've discovered two bugs in the previous version. I've also added some comments at the top to explain why this script is necessary under Slackware. I'm hoping 55020 you are still monitoring this thread.
Attached Files
File Type: txt rc.gpsd.txt (1.5 KB, 14 views)

Last edited by xj25vm; 06-11-2011 at 03:25 AM.
 
Old 06-12-2011, 05:53 AM   #19
55020
Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 370
Blog Entries: 4

Rep: Reputation: 342Reputation: 342Reputation: 342Reputation: 342
Hi Sebastian, have a look at http://github.com/idlemoor/SBo-fork/...edingEdge/gpsd which I have been working on for a while -- this is a experimental preview of what will become the SBo SlackBuild when gpsd-3.0 is released. It now includes your new rc.gpsd, revised somewhat. Among the changes, it uses /dev/gps0 instead of /dev/ttyUSB0 (thus allowing coexistence of a GPS with any other USB serial devices, if they are distinguishable to udev). This isn't enabled by default. Read the README.

The README also points out that there is now a dependency on scons, which is available from SBo.

Before building gpsd, you'll need to make a tarball from the gpsd project's git repository. If you're comfortable doing that, fine, otherwise you can use the repo2tarball script I've been hacking lately, which is in a parallel subdirectory in the BleedingEdge section of my github. This will clone/pull from the remote git repo, and create a tarball named something like gpsd-master.6bf5d9e.tar.gz. You then build gpsd from this tarball and install/upgrade the package as usual:

Code:
repo2tarball gpsd
VERSION=master.6bf5d9e sh gpsd.SlackBuild
upgradepkg /tmp/gpsd-master.6bf5d9e-x86_64-1_SBo.tgz
To reiterate, this is experimental - handle with care, feedback is welcome.
 
Old 06-12-2011, 10:28 AM   #20
xj25vm
Member
 
Registered: Jun 2008
Posts: 262

Original Poster
Rep: Reputation: 17
I've had a look at github and I like the look of things. One minor suggestion. If it would be me, I would keep all the options inside rc.gpsd - and keep the part that goes into rc.local as minimal as possible. So in rc.local I'd put something like:

Code:
if [ -x /etc/rc.d/rc.gpsd ]; then
  /etc/rc.d/rc.gpsd start
fi
While I would add the following to rc.gpsd somewhere towards the top:

Code:
if [ ! -e $GPSD_DEVICE ]; then
  exit 1
fi
for a quiet exit, or make it more verbose. This way the bit in rc.local looks more "traditional" or in line with other similar statements that go in rc.local, and /dev/gps0 doesn't end up being hardwired in rc.local - so that it would need changing in two different locations (rc.local and rc.gpsd) if somebody wants to use a different device name for any reason.

I like your "GPSD_SOCKARG" idea - I couldn't think of a suitable name for that variable.
 
Old 06-12-2011, 11:03 AM   #21
55020
Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 370
Blog Entries: 4

Rep: Reputation: 342Reputation: 342Reputation: 342Reputation: 342
Will do. In particular, you're right about the device name and it makes mincemeat of the bogus reason why I did it that way. Ta!
 
Old 06-12-2011, 11:22 AM   #22
xj25vm
Member
 
Registered: Jun 2008
Posts: 262

Original Poster
Rep: Reputation: 17
I was just looking at the udev rule supplied by the gpsd team. I just realised that, if several usb-to-serial devices are plugged in (not necessarily all gps receivers) - there is no guarantee that the gps receiver will end up under /dev/gps0. They use "SYMLINK+="gps%n" which I believe means that it will take the same number assigned by the kernel to /dev/ttyUSBx which is linking to. There could be only one gps receiver plugged (next to other usb-to-serial devices) and still end up as /dev/gps3 or /dev/gps4. And no way to control this with the current settings. In the light of this, the way I see it there are two options:

1. Modify the udev rule and recommendation, so that people hardwire their own device number e.g. instead of using "SYMLINK+="gps%n" use "SYMLINK+=gps0".
2. Or, modify rc.gpsd, by removing GPSD_DEVICE variable, and instead do something like "ls /dev/gps*", check if anything comes out of that, and if yes, for first device found start gpsd on it. That of course makes the willing assumption there is only one gps receiver plugged in when the computer starts, and/or ignores any other.

Otherwise we would deal with a situation where rc.gpsd relies on the chance that the gps receiver is the first one to be polled by udev of any serial-to-usb devices connected - which, I would think, is very flimsy. It also pretty much ruins one of the main purposes of using udev for this - which, I believe, was to deal with having several usb-to-serial devices plugged in.

Unless I'm misunderstanding the udev rules.

Last edited by xj25vm; 06-12-2011 at 11:28 AM.
 
Old 06-12-2011, 02:16 PM   #23
xj25vm
Member
 
Registered: Jun 2008
Posts: 262

Original Poster
Rep: Reputation: 17
I worked a bit on the latest version of rc.gpsd and I adapted it to cope with /dev/gpsx devices numbered in an unpredictable fashion. Also, I adapted it to cope with an unknown number of gps devices plugged in when the computer starts. I know this is somewhat unlikely - but I think this way it is more flexible and robust. If you think this is overkill, it could be changed to just start gpsd on the first device encountered. Here is the part of it I've modified:

Code:
# No need for the options or socket variables - as they get read
# by the hotplug script from /etc/default/gpsd. No point in having two sets of settings

gpsd_start() {

  GPS_DEVICE_COUNT=`ls -l /dev/gps* 2>/dev/null | wc -l`

  if [ "$GPS_DEVICE_COUNT" -eq "0" ]; then
    echo "$0: No /dev/gps found. Will not start gpsd"
    exit 1
  fi

  #  will check only for hotplug scripts - the only ones we need directly
  if [ ! -x /lib/udev/gpsd.hotplug -o ! -x /lib/udev/gpsd.hotplug.wrapper ]; then
    echo "$0: no gpsd hotplug scripts (or not executable); cannot start."
  fi

  # Now start one by one all devices
  for GPS_RECEIVER in /dev/gps*; do
    # the hotplug scripts expect the variables below in the environment
    export OPTIONS="$GPSD_OPTIONS"
    export ACTION="add"
    export DEVNAME="$GPS_RECEIVER"
    echo "$0: Starting $GPS_RECEIVER"
    /lib/udev/gpsd.hotplug.wrapper
  done

}
It feels a bit like going in one big circle - and ending close to where I started - but I think the code above should take care of everything. One of these days when I'll grow some extra cells on the brain I'll have to sit down and write a C wrapper which takes care of everything properly and does all the checks - three layers of scripts to start one piece of software is really silly from where I'm standing. Then again, after trying for 2 days to convince the project leader for gpsd to make life a bit easier for those who interact with his software - I'm not holding my breath there will be any change from that direction.

Last edited by xj25vm; 06-12-2011 at 02:28 PM.
 
Old 06-14-2011, 11:55 AM   #24
55020
Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 370
Blog Entries: 4

Rep: Reputation: 342Reputation: 342Reputation: 342Reputation: 342
Sorry for using this thread to conduct a dialogue of diminishing public interest, but I've just pushed a new set of gpsd files to Github, including fixes for the device numbering issue Sebastian pointed out, the config issue, and patches for a number of ghastly upstream problems.

There is now a config file at /etc/rc.d/rc.gpsd.conf, which is where it should be in any distro of good taste and discernment

I might try to do an LQ Blog about this, so that we have somewhere else to discuss any matters arising.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
First UDEV Rule, Not quite there ... orbit Slackware 7 02-22-2009 10:08 PM
udev rule: need help DPenguin Linux - Hardware 0 08-04-2008 07:29 PM
Udev Rule Help Please Toods Slackware 1 11-23-2007 08:55 AM
Starting udev fails ,kernel doesnt boot properly........ raklo Linux - Kernel 3 09-24-2007 12:20 AM
need help with udev rule hussam Linux - Software 2 12-05-2006 03:30 AM


All times are GMT -5. The time now is 11:47 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration