[Bug 487665] Review Request: soud - Tools for hardware related services based on udev events

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=487665


Bill Nottingham <notting at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |harald at redhat.com




--- Comment #9 from Bill Nottingham <notting at redhat.com>  2009-03-03 20:30:32 EDT ---
(In reply to comment #7)
> Spec URL: http://plautrba.fedorapeople.org/soud/soud.spec
> SRPM URL: http://plautrba.fedorapeople.org/soud/soud-0.1.3-1.fc10.src.rpm
> 
> 2) Daemon was part of development process and it is now optional. 
> 
> Now it is based on udev rules created by soud-save-to-udev.pl from config file.

OK, but then I really don't see what purpose this serves at all.

All it does is create an obfuscation/abstraction layer between udev rules and
its own configuration. Instead of having the user write:

ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/sbin/initctl emit
bluetooth-start"

(which works on any distro), you have them write, somewhere else:

[bluetooth_start]
filter=SUBSYSTEM=bluetooth ACTION=add
action=/sbin/initctl emit bluetooth-start

which will only work on Fedora for now.

There's no actual value added in the process - it's just a translation layer.
And if you're packaging this config, and immediately post-processing it into
rules files in %post ... just package the rules files directly and skip the
processing.

I don't see how soud-watch.pl gives you anything you don't already have with
'udevadm monitor', and if we need more infrastructure there, we should get it
added upstream.

> 3) bluetooth event.d script checks hw after runlevel changed. if there is no
> hw, calls stop on service, same situation if hw is removed.

However, given the normal way things work, as this is written now:

No hardware:
1) runlevel service starts bluetooth daemon
2) after runlevel, event is kicked off, checks hardware, then stops service

Has bluetooth hardware:
1) get udev event, trigger off upstart event
2) since upstart event is running before we enter a runlevel, we won't start
the service
3) normal runlevel service will start bluetooth daemon
4) after runlevel, event is kicked off, checks hardware, then exits

So, for both the 'normal' boot cases, it adds code and complication to the boot
process, without much benefit.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.