Re: [systemd-devel] systemd unit review requested

2013-12-11 Thread Lennart Poettering
On Wed, 11.12.13 12:34, Peter Hutterer (peter.hutte...@who-t.net) wrote:

  If a module exposes those alias lines then the module is auto-loaded by
  udev as soon as matching hardware shows up. That's the preferable way to
  load kernel modules these days, instead of loading them explicitly they
  way you are doing it.
  
  Of course, what's behind an rs232 port is generally not automatically
  discoverable, that's why Kay was asking whether the modalias line is
  insufficient.
 
 ok, after spending half the day going down the most likely wrong track: are
 we talking about auto-loading the module once inputattach is launched, or
 dropping the need for inputattach?
 
 because if it's the former then yes, I can confirm that works and the module
 is loaded correctly so the modalias seems to work here. we can drop the kmod
 from the udev rule.

Well, it's udev that loads the kmod as the hw shows up, not inputattach
that triggers the loading. inputattach comes later...

  It sounds like a good idea to get rid of the explicit module loading and
  simply rely on the modalias stuff for that. Then, if your program really
  only does what you list above (i.e. nothing that can block for longer or
  that needs to stay around during runtime), then you could just do this
  synchronously as part of an udev rule, no?
 
 sorry, I wasn't clear enough. inputattach does the above and then just sits
 with a 0-byte read() to keep the line open. as soon as inputattach finishes
 the device will revert back to just being a serial device.
 so it's definitely not a one-shot, we need it to sit there.

OK, then doing this as systemd service is the right thing.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd unit review requested

2013-12-10 Thread Lennart Poettering
On Mon, 09.12.13 12:18, Peter Hutterer (peter.hutte...@who-t.net) wrote:

 
 On Fri, Dec 06, 2013 at 04:10:02PM +0100, Kay Sievers wrote:
  On Fri, Dec 6, 2013 at 7:20 AM, Peter Hutterer peter.hutte...@who-t.net 
  wrote:
  
   It also depends on the wacom_w8001 and how it reacts when it's loaded
   and no hardware is present.
   
   Peter, couldn't this module be autoloaded?
  
   the module just sits there, it needs to be triggered by
   inputattach to actually hook onto the device. there's a small number of
   devices only that need it, so unconditionally modprobing it seems a bit
   wasteful.
  
  Just curious:
  
  There is one auto-loading alias in the module for the serio bus:
$ modinfo wacom_w8001 | grep alias
alias:  serio:ty02pr39id*ex*
  
  Does that work? For all devices or only a few?
  Can the serial device be detected that way?
  Does inputattach talk to the device to find out what it is?
 
 tbh, I'm not sure how to answer these questions, it's not something I've had
 to deal with in the past so I've got little to no knowledge of this.

If a module exposes those alias lines then the module is auto-loaded by
udev as soon as matching hardware shows up. That's the preferable way to
load kernel modules these days, instead of loading them explicitly they
way you are doing it.

Of course, what's behind an rs232 port is generally not automatically
discoverable, that's why Kay was asking whether the modalias line is
insufficient.

 inputattach does not talk to the device, it merely sets various fields as
 provided by the user, hence the --w8001 flag. other than that, it's pretty
 much down to four commands:
 open(dev/ttyS0)
 setline(fd, CS8, baudrate)
 ioctl(fd, TIOSETD, N_MOUSE)
 ioctl(fd, SPIOCSTYPE, SERIO_W8001)
 
 That's why we need the udev rule to match the pnpid, because inputattach
 doesn't do any matching and we need to provide the right arguments already.
 afaik the only way to detect the device is to search for e.g. WACf in
 the pnpid.

It sounds like a good idea to get rid of the explicit module loading and
simply rely on the modalias stuff for that. Then, if your program really
only does what you list above (i.e. nothing that can block for longer or
that needs to stay around during runtime), then you could just do this
synchronously as part of an udev rule, no?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd unit review requested

2013-12-10 Thread Peter Hutterer
On Tue, Dec 10, 2013 at 08:20:17PM +0100, Lennart Poettering wrote:
 On Mon, 09.12.13 12:18, Peter Hutterer (peter.hutte...@who-t.net) wrote:
 
  
  On Fri, Dec 06, 2013 at 04:10:02PM +0100, Kay Sievers wrote:
   On Fri, Dec 6, 2013 at 7:20 AM, Peter Hutterer peter.hutte...@who-t.net 
   wrote:
   
It also depends on the wacom_w8001 and how it reacts when it's loaded
and no hardware is present.

Peter, couldn't this module be autoloaded?
   
the module just sits there, it needs to be triggered by
inputattach to actually hook onto the device. there's a small number of
devices only that need it, so unconditionally modprobing it seems a bit
wasteful.
   
   Just curious:
   
   There is one auto-loading alias in the module for the serio bus:
 $ modinfo wacom_w8001 | grep alias
 alias:  serio:ty02pr39id*ex*
   
   Does that work? For all devices or only a few?
   Can the serial device be detected that way?
   Does inputattach talk to the device to find out what it is?
  
  tbh, I'm not sure how to answer these questions, it's not something I've had
  to deal with in the past so I've got little to no knowledge of this.
 
 If a module exposes those alias lines then the module is auto-loaded by
 udev as soon as matching hardware shows up. That's the preferable way to
 load kernel modules these days, instead of loading them explicitly they
 way you are doing it.
 
 Of course, what's behind an rs232 port is generally not automatically
 discoverable, that's why Kay was asking whether the modalias line is
 insufficient.

ok, after spending half the day going down the most likely wrong track: are
we talking about auto-loading the module once inputattach is launched, or
dropping the need for inputattach?

because if it's the former then yes, I can confirm that works and the module
is loaded correctly so the modalias seems to work here. we can drop the kmod
from the udev rule.

if it's the latter, I've got nfi how to get there.  it's a maze of
callbacks and somewhere something is missing or I'm just not understanding
the approach correctly. that'll take more time to figure out than I want to
spend on it (wacom serial devices are discontinued, and not particularly
plentyful to begin with).

  inputattach does not talk to the device, it merely sets various fields as
  provided by the user, hence the --w8001 flag. other than that, it's pretty
  much down to four commands:
  open(dev/ttyS0)
  setline(fd, CS8, baudrate)
  ioctl(fd, TIOSETD, N_MOUSE)
  ioctl(fd, SPIOCSTYPE, SERIO_W8001)
  
  That's why we need the udev rule to match the pnpid, because inputattach
  doesn't do any matching and we need to provide the right arguments already.
  afaik the only way to detect the device is to search for e.g. WACf in
  the pnpid.
 
 It sounds like a good idea to get rid of the explicit module loading and
 simply rely on the modalias stuff for that. Then, if your program really
 only does what you list above (i.e. nothing that can block for longer or
 that needs to stay around during runtime), then you could just do this
 synchronously as part of an udev rule, no?

sorry, I wasn't clear enough. inputattach does the above and then just sits
with a 0-byte read() to keep the line open. as soon as inputattach finishes
the device will revert back to just being a serial device.
so it's definitely not a one-shot, we need it to sit there.

Cheers,
   Peter

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd unit review requested

2013-12-10 Thread Kay Sievers
On Wed, Dec 11, 2013 at 3:34 AM, Peter Hutterer
peter.hutte...@who-t.net wrote:

 ok, after spending half the day going down the most likely wrong track: are
 we talking about auto-loading the module once inputattach is launched, or
 dropping the need for inputattach?

 because if it's the former then yes, I can confirm that works and the module
 is loaded correctly so the modalias seems to work here. we can drop the kmod
 from the udev rule.

It think the kmod and auto-loading stuff was all this was about.

Thanks for digging all that out. It was interesting to hear how this works.

Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd unit review requested

2013-12-08 Thread Peter Hutterer
On Fri, Dec 06, 2013 at 04:10:02PM +0100, Kay Sievers wrote:
 On Fri, Dec 6, 2013 at 7:20 AM, Peter Hutterer peter.hutte...@who-t.net 
 wrote:
 
  It also depends on the wacom_w8001 and how it reacts when it's loaded
  and no hardware is present.
  
  Peter, couldn't this module be autoloaded?
 
  the module just sits there, it needs to be triggered by
  inputattach to actually hook onto the device. there's a small number of
  devices only that need it, so unconditionally modprobing it seems a bit
  wasteful.
 
 Just curious:
 
 There is one auto-loading alias in the module for the serio bus:
   $ modinfo wacom_w8001 | grep alias
   alias:  serio:ty02pr39id*ex*
 
 Does that work? For all devices or only a few?
 Can the serial device be detected that way?
 Does inputattach talk to the device to find out what it is?

tbh, I'm not sure how to answer these questions, it's not something I've had
to deal with in the past so I've got little to no knowledge of this.

inputattach does not talk to the device, it merely sets various fields as
provided by the user, hence the --w8001 flag. other than that, it's pretty
much down to four commands:
open(dev/ttyS0)
setline(fd, CS8, baudrate)
ioctl(fd, TIOSETD, N_MOUSE)
ioctl(fd, SPIOCSTYPE, SERIO_W8001)

That's why we need the udev rule to match the pnpid, because inputattach
doesn't do any matching and we need to provide the right arguments already.
afaik the only way to detect the device is to search for e.g. WACf in
the pnpid.

Cheers,
   Peter
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd unit review requested

2013-12-08 Thread Peter Hutterer
On Thu, Dec 05, 2013 at 01:24:10PM +, Jóhann B. Guðmundsson wrote:
[...]
 So we need an udev wacom-serial-driver rule that might look like
 this for the wacom serial devices
 
 ACTION==remove, GOTO=drivers_end
 ENV{MODALIAS}==?*, RUN{builtin}=kmod load $env{MODALIAS}
 SUBSYSTEM==tty|pnp, SUBSYSTEMS==pnp, ATTRS{id}==WACf*,
 ENV{ID_MODEL}=Serial Wacom Tablet $attr{id}, ENV{ID_INPUT}=1,
 ENV{ID_INPUT_TABLET}=1, ENV{NAME}=Serial Wacom Tablet $attr{id}
 ,RUN{builtin}=kmod load wacom_w8001
 SUBSYSTEM==tty|pnp, SUBSYSTEMS==pnp, ATTRS{id}==FUJ*,
 ENV{ID_MODEL}=Serial Wacom Tablet $attr{id}, ENV{ID_INPUT}=1,
 ENV{ID_INPUT_TABLET}=1, ENV{NAME}=Serial Wacom Tablet $attr{id}
 ,RUN{builtin}=kmod load wacom_w8001
 LABEL=drivers_end
 
 Followed by an systemd rule that looks something like this
 
 SUBSYSTEM==module, KERNEL==wacom*, TAG+=systemd,
 ENV{SYSTEMD_WANTS}+=wacom-inputattach@%k.service
 
 And the modprobe would be dropped from that unit file but as I say
 I'm not all that familiar with udev policy rules and I personally
 had not planned on mastering udev until I started the cleanup
 process in Fedora which might never happen today thanks to the that
 WG process.
 
I tested this today and it works, except for one issue where I got stuck:
since the actual service is now triggered by the module loading, %k now
refers to the module name, not to the actual device anymore. I'm not sure
how to get the device path (which I need for inputattach) from that.

otherwise it woks just fine :)

Cheers,
   Peter
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd unit review requested

2013-12-06 Thread Kay Sievers
On Fri, Dec 6, 2013 at 7:20 AM, Peter Hutterer peter.hutte...@who-t.net wrote:

 It also depends on the wacom_w8001 and how it reacts when it's loaded
 and no hardware is present.
 
 Peter, couldn't this module be autoloaded?

 the module just sits there, it needs to be triggered by
 inputattach to actually hook onto the device. there's a small number of
 devices only that need it, so unconditionally modprobing it seems a bit
 wasteful.

Just curious:

There is one auto-loading alias in the module for the serio bus:
  $ modinfo wacom_w8001 | grep alias
  alias:  serio:ty02pr39id*ex*

Does that work? For all devices or only a few?
Can the serial device be detected that way?
Does inputattach talk to the device to find out what it is?

Thanks,
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd unit review requested

2013-12-05 Thread Jóhann B. Guðmundsson


On 12/05/2013 06:50 AM, Peter Hutterer wrote:

ExecStartPre=/usr/sbin/modprobe wacom_w8001


Add a configuration file called wacom-w8001.conf to /etc/modules-load.d 
directory with the following content to load the module

( /etc/modules-load.d/wacom-w8001.conf )
# Load wacom_w8001 at boot
wacom_w8001

If necessary add any additional module options to same named file under 
/etc/modprobe.d directory if necessary as in...

( /etc/modprobe.d/wacom-w8001.conf )
#Wacom w8001 module options
options foo bar

Never use a systemd unit to call modprobe.

Each time you do so someone's beer goes flat...

JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd unit review requested

2013-12-05 Thread Michael Biebl
2013/12/5 Jóhann B. Guðmundsson johan...@gmail.com:

 On 12/05/2013 06:50 AM, Peter Hutterer wrote:

 ExecStartPre=/usr/sbin/modprobe wacom_w8001


 Add a configuration file called wacom-w8001.conf to /etc/modules-load.d
 directory with the following content to load the module
 ( /etc/modules-load.d/wacom-w8001.conf )
 # Load wacom_w8001 at boot
 wacom_w8001

Well, this loads the kernel module unconditionally, though. Even for
users which don't have that hardware. So this approach isn't that
great.

It also depends on the wacom_w8001 and how it reacts when it's loaded
and no hardware is present.

Peter, couldn't this module be autoloaded?

Michael








-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd unit review requested

2013-12-05 Thread Jóhann B. Guðmundsson


On 12/05/2013 12:28 PM, Michael Biebl wrote:

2013/12/5 Jóhann B. Guðmundssonjohan...@gmail.com:

On 12/05/2013 06:50 AM, Peter Hutterer wrote:

ExecStartPre=/usr/sbin/modprobe wacom_w8001

Add a configuration file called wacom-w8001.conf to /etc/modules-load.d
directory with the following content to load the module
( /etc/modules-load.d/wacom-w8001.conf )
# Load wacom_w8001 at boot
wacom_w8001

Well, this loads the kernel module unconditionally, though. Even for
users which don't have that hardware. So this approach isn't that
great.

It also depends on the wacom_w8001 and how it reacts when it's loaded
and no hardware is present.

Peter, couldn't this module be autoloaded?


I'm not that familiar with udev policy regarding rules rule but I would 
think that if you autoload module you tie the startup of the systemd 
unit to the module being loaded ( if the intent is to trigger a unit )


So we need an udev wacom-serial-driver rule that might look like this 
for the wacom serial devices


ACTION==remove, GOTO=drivers_end
ENV{MODALIAS}==?*, RUN{builtin}=kmod load $env{MODALIAS}
SUBSYSTEM==tty|pnp, SUBSYSTEMS==pnp, ATTRS{id}==WACf*, 
ENV{ID_MODEL}=Serial Wacom Tablet $attr{id}, ENV{ID_INPUT}=1, 
ENV{ID_INPUT_TABLET}=1, ENV{NAME}=Serial Wacom Tablet $attr{id} 
,RUN{builtin}=kmod load wacom_w8001
SUBSYSTEM==tty|pnp, SUBSYSTEMS==pnp, ATTRS{id}==FUJ*, 
ENV{ID_MODEL}=Serial Wacom Tablet $attr{id}, ENV{ID_INPUT}=1, 
ENV{ID_INPUT_TABLET}=1, ENV{NAME}=Serial Wacom Tablet $attr{id} 
,RUN{builtin}=kmod load wacom_w8001

LABEL=drivers_end

Followed by an systemd rule that looks something like this

SUBSYSTEM==module, KERNEL==wacom*, TAG+=systemd, 
ENV{SYSTEMD_WANTS}+=wacom-inputattach@%k.service


And the modprobe would be dropped from that unit file but as I say I'm 
not all that familiar with udev policy rules and I personally had not 
planned on mastering udev until I started the cleanup process in Fedora 
which might never happen today thanks to the that WG process.


JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd unit review requested

2013-12-05 Thread David Timothy Strauss
On Thu, Dec 5, 2013 at 3:53 AM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
 Never use a systemd unit to call modprobe.

And, even if you did, modprobe would be Type=oneshot (maybe also with
RemainAfterExit=true), definitely not Type=simple.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd unit review requested

2013-12-05 Thread Jóhann B. Guðmundsson


On 12/05/2013 01:57 PM, David Timothy Strauss wrote:

On Thu, Dec 5, 2013 at 3:53 AM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:

Never use a systemd unit to call modprobe.

And, even if you did, modprobe would be Type=oneshot (maybe also with
RemainAfterExit=true), definitely not Type=simple.


You never and I mean never should load or unload modules in systemd 
units so it's irrelevant what those type should be.


JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd unit review requested

2013-12-05 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Dec 05, 2013 at 04:50:54PM +1000, Peter Hutterer wrote:
 the new rule now is:
 
 SUBSYSTEM==tty|pnp, KERNEL==ttyS[0-9]*, ATTRS{id}==WACf*, \
 ENV{SYSTEMD_WANTS}=wacom-inputattach@%k.service,TAG+=systemd
 
 
 And the matching wacom-inputattach@.service file shows:
 
 [Unit]
 Description=Start inputattach for Wacom ISDv4-compatible serial devices
 
 [Service]
 Type=simple
 ExecStartPre=/usr/sbin/modprobe wacom_w8001
 ExecStart=/usr/bin/inputattach -w8001 /dev/%I
 
 Anything I'm missing, anything I should change?
Looks OK, except for the question where the module should be loaded from,
discussed in the other part of this thread.

 Also, do I need this in any target, or is dropping this into
 /usr/lib/systemd/system/ enough?
Yes, but wait until https://bugzilla.redhat.com/show_bug.cgi?id=1026860
is fixed (hopefully today).

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd unit review requested

2013-12-05 Thread Colin Guthrie
'Twas brillig, and Jóhann B. Guðmundsson at 05/12/13 14:30 did gyre
and gimble:
 
 On 12/05/2013 01:57 PM, David Timothy Strauss wrote:
 On Thu, Dec 5, 2013 at 3:53 AM, Jóhann B. Guðmundsson
 johan...@gmail.com wrote:
 Never use a systemd unit to call modprobe.
 And, even if you did, modprobe would be Type=oneshot (maybe also with
 RemainAfterExit=true), definitely not Type=simple.
 
 You never and I mean never should load or unload modules in systemd
 units so it's irrelevant what those type should be.

The above statement not withstanding, but the Type and RemainAfterExit
applies only to ExecStart. This unit calls modprobe in ExecStartPre
which is always expected to do something and return. So this branch of
the thread really doesn't apply to this unit.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd unit review requested

2013-12-05 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Dec 05, 2013 at 04:27:51PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Thu, Dec 05, 2013 at 04:50:54PM +1000, Peter Hutterer wrote:
  the new rule now is:
  
  SUBSYSTEM==tty|pnp, KERNEL==ttyS[0-9]*, ATTRS{id}==WACf*, \
  ENV{SYSTEMD_WANTS}=wacom-inputattach@%k.service,TAG+=systemd
  
  
  And the matching wacom-inputattach@.service file shows:
  
  [Unit]
  Description=Start inputattach for Wacom ISDv4-compatible serial devices
This will be displayed as Starting Start inputattach for Wacom
ISDv4-compatible serial devices, and later Stopping Start 

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd unit review requested

2013-12-05 Thread David Timothy Strauss
On Thu, Dec 5, 2013 at 7:29 AM, Colin Guthrie gm...@colin.guthr.ie wrote:
 The above statement not withstanding, but the Type and RemainAfterExit
 applies only to ExecStart. This unit calls modprobe in ExecStartPre
 which is always expected to do something and return. So this branch of
 the thread really doesn't apply to this unit.

Oh, indeed. I misread the unit.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd unit review requested

2013-12-05 Thread Tom Gundersen
On 5 Dec 2013 07:48, Peter Hutterer peter.hutte...@who-t.net wrote:

 When I fired up F20 on one of my laptops here I noticed that inputattach
 doesn't work anymore for serial Wacom devices. It used to be started
through
 udev, but that doesn't work anymore. So moving to a systemd service it is,
 but I'd like a review of the changes please.

 The goal is to start inputattach for a serial Wacom device if the pnpid
 matches a certain set. The old udev rule was:

 SUBSYSTEM==tty|pnp, KERNEL==ttyS[0-9]*, ATTRS{id}==WACf*, \
 RUN+=/usr/sbin/modprobe wacom_w8001, \
 RUN+=/usr/sbin/inputattach --daemon -w8001 /dev/%k

 the new rule now is:

 SUBSYSTEM==tty|pnp, KERNEL==ttyS[0-9]*, ATTRS{id}==WACf*, \
 ENV{SYSTEMD_WANTS}=wacom-inputattach@%k.service,TAG+=systemd


 And the matching wacom-inputattach@.service file shows:

 [Unit]
 Description=Start inputattach for Wacom ISDv4-compatible serial devices

 [Service]
 Type=simple
 ExecStartPre=/usr/sbin/modprobe wacom_w8001

Seems like this should be auto loaded? If not, you might want to load it
directly from the udev rule using the kmod built-in.

Cheers,

Tom

 ExecStart=/usr/bin/inputattach -w8001 /dev/%I

 Anything I'm missing, anything I should change?

 Also, do I need this in any target, or is dropping this into
 /usr/lib/systemd/system/ enough?

 Thanks in advance.

 Cheers,
Peter
 ~

 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd unit review requested

2013-12-05 Thread Peter Hutterer
On Thu, Dec 05, 2013 at 04:38:45PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Thu, Dec 05, 2013 at 04:27:51PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
  On Thu, Dec 05, 2013 at 04:50:54PM +1000, Peter Hutterer wrote:
   the new rule now is:
   
   SUBSYSTEM==tty|pnp, KERNEL==ttyS[0-9]*, ATTRS{id}==WACf*, \
   ENV{SYSTEMD_WANTS}=wacom-inputattach@%k.service,TAG+=systemd
   
   
   And the matching wacom-inputattach@.service file shows:
   
   [Unit]
   Description=Start inputattach for Wacom ISDv4-compatible serial devices
 This will be displayed as Starting Start inputattach for Wacom
 ISDv4-compatible serial devices, and later Stopping Start 

easy fix, thanks.

Cheers,
   Peter
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd unit review requested

2013-12-05 Thread Peter Hutterer
On Thu, Dec 05, 2013 at 01:24:10PM +, Jóhann B. Guðmundsson wrote:
 
 On 12/05/2013 12:28 PM, Michael Biebl wrote:
 2013/12/5 Jóhann B. Guðmundssonjohan...@gmail.com:
 On 12/05/2013 06:50 AM, Peter Hutterer wrote:
 ExecStartPre=/usr/sbin/modprobe wacom_w8001
 Add a configuration file called wacom-w8001.conf to /etc/modules-load.d
 directory with the following content to load the module
 ( /etc/modules-load.d/wacom-w8001.conf )
 # Load wacom_w8001 at boot
 wacom_w8001
 Well, this loads the kernel module unconditionally, though. Even for
 users which don't have that hardware. So this approach isn't that
 great.
 
 It also depends on the wacom_w8001 and how it reacts when it's loaded
 and no hardware is present.
 
 Peter, couldn't this module be autoloaded?

the module just sits there, it needs to be triggered by
inputattach to actually hook onto the device. there's a small number of
devices only that need it, so unconditionally modprobing it seems a bit
wasteful.

 I'm not that familiar with udev policy regarding rules rule but I
 would think that if you autoload module you tie the startup of the
 systemd unit to the module being loaded ( if the intent is to
 trigger a unit )
 
 So we need an udev wacom-serial-driver rule that might look like
 this for the wacom serial devices
 
 ACTION==remove, GOTO=drivers_end
 ENV{MODALIAS}==?*, RUN{builtin}=kmod load $env{MODALIAS}
 SUBSYSTEM==tty|pnp, SUBSYSTEMS==pnp, ATTRS{id}==WACf*,
 ENV{ID_MODEL}=Serial Wacom Tablet $attr{id}, ENV{ID_INPUT}=1,
 ENV{ID_INPUT_TABLET}=1, ENV{NAME}=Serial Wacom Tablet $attr{id}
 ,RUN{builtin}=kmod load wacom_w8001
 SUBSYSTEM==tty|pnp, SUBSYSTEMS==pnp, ATTRS{id}==FUJ*,
 ENV{ID_MODEL}=Serial Wacom Tablet $attr{id}, ENV{ID_INPUT}=1,
 ENV{ID_INPUT_TABLET}=1, ENV{NAME}=Serial Wacom Tablet $attr{id}
 ,RUN{builtin}=kmod load wacom_w8001
 LABEL=drivers_end
 
 Followed by an systemd rule that looks something like this
 
 SUBSYSTEM==module, KERNEL==wacom*, TAG+=systemd,
 ENV{SYSTEMD_WANTS}+=wacom-inputattach@%k.service
 
 And the modprobe would be dropped from that unit file but as I say
 I'm not all that familiar with udev policy rules and I personally
 had not planned on mastering udev until I started the cleanup
 process in Fedora which might never happen today thanks to the that
 WG process.

thanks, that seems to be the best solution so far (haven't tested it yet
though :). Can anyone confirm that this matches the current policies?

Thanks

Cheers,
   Peter
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] systemd unit review requested

2013-12-04 Thread Peter Hutterer
When I fired up F20 on one of my laptops here I noticed that inputattach
doesn't work anymore for serial Wacom devices. It used to be started through
udev, but that doesn't work anymore. So moving to a systemd service it is,
but I'd like a review of the changes please.

The goal is to start inputattach for a serial Wacom device if the pnpid
matches a certain set. The old udev rule was:

SUBSYSTEM==tty|pnp, KERNEL==ttyS[0-9]*, ATTRS{id}==WACf*, \
RUN+=/usr/sbin/modprobe wacom_w8001, \
RUN+=/usr/sbin/inputattach --daemon -w8001 /dev/%k

the new rule now is:

SUBSYSTEM==tty|pnp, KERNEL==ttyS[0-9]*, ATTRS{id}==WACf*, \
ENV{SYSTEMD_WANTS}=wacom-inputattach@%k.service,TAG+=systemd


And the matching wacom-inputattach@.service file shows:

[Unit]
Description=Start inputattach for Wacom ISDv4-compatible serial devices

[Service]
Type=simple
ExecStartPre=/usr/sbin/modprobe wacom_w8001
ExecStart=/usr/bin/inputattach -w8001 /dev/%I

Anything I'm missing, anything I should change?

Also, do I need this in any target, or is dropping this into
/usr/lib/systemd/system/ enough?

Thanks in advance.

Cheers,
   Peter
~   

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel