Re: [systemd-devel] systemd unit review requested
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
On Wed, Dec 11, 2013 at 3:34 AM, Peter Hutterer 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
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 > > > 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
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 > > 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
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
On Fri, Dec 06, 2013 at 04:10:02PM +0100, Kay Sievers wrote: > On Fri, Dec 6, 2013 at 7:20 AM, Peter Hutterer > 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
On Fri, Dec 6, 2013 at 7:20 AM, Peter Hutterer 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
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ð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
> >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
Re: [systemd-devel] systemd unit review requested
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
On 5 Dec 2013 07:48, "Peter Hutterer" 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
On Thu, Dec 5, 2013 at 7:29 AM, Colin Guthrie 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
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
'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" >> 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
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
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" 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
On Thu, Dec 5, 2013 at 3:53 AM, "Jóhann B. Guðmundsson" 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
On 12/05/2013 12:28 PM, Michael Biebl wrote:
2013/12/5 "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
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/5 "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 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
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
