[systemd-devel] gps.target

[Lennart Poettering]

On Sat, 15.09.12 00:35, shawn (shawnlandden at gmail.com) wrote:

> I noticed that "gps.target" (along with: fingerprint.target,
> wireless.target, netdevice.target) were in the proposed feature list,
> and I am wonder how this would work.
> 
> most usb gps devices, which are the vast majority of devices out there
> and supported by gpsd, are usb-to-serial converters, and by product:id
> and in udev are  not distinguishable as gps devices: udev must call gpsd
> which will then probe the device and figure out if it is a gps device
> before letting go of it.
> 
> Anyways, I was wonder what the gps.target idea was--what would trigger
> it? gpsd through this udev stuff already launches automatically when a
> usb gps device is inserted (although it never shuts down by itsself)

Well, the TODO list is mostly about things we should investigate I
guess, not necessarily stuff we should implement 1:1... ;-)

I have no experience with GPS devices I must say. I assumed we could
detect many of them (not necessarily all) and pull in a target, which
then could pull in things. I kinda like the indirection of that, since
it makes it easily possible to enable/these services with "systemctl
enable" and friends.

We often have the probs of not being able to detect many devices
properly. But there are always chances to get something working, for
example a tiny udev helper which looks in some meta data (or even talks
over the serial) and adds the results as udev props to the
device. 

How is gpsd currently started from udev? Note that on systemd systems
udev will kill all long running processes spawned from udev rules these
days, people need to do things with SYSTEMD_WANTS instead. udev is not
supposed to be a framework for spawning forking daemons inline...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.