USB Query - Linux

This is a discussion on USB Query - Linux ; Hi, I want to trigger an application in the user space when a usb device is plugged into the system. How do i get the notification of a usb device plug in the user space. Requesting pointers. Thanks MAx...

+ Reply to Thread
Results 1 to 11 of 11

Thread: USB Query

  1. USB Query

    Hi,
    I want to trigger an application in the user space when a usb
    device is plugged into the system.
    How do i get the notification of a usb device plug in the user space.

    Requesting pointers.

    Thanks
    MAx

  2. Re: USB Query

    MAx writes:
    > I want to trigger an application in the user space when a usb
    > device is plugged into the system.
    > How do i get the notification of a usb device plug in the user space.


    The kernel will execute the program whose name is stored in
    /proc/sys/kernel/hotplug whenever a 'hot plug'-event occurs, passing
    the name of a subsystem as argv[1] and setting up some environment
    variables with 'relevant details'. For a network interface, this looks
    like below:

    Jun 24 09:02:02 hotplug-dispatch[8853]: unhandled hotplug event, subsystem 'net'
    Jun 24 09:02:02 hotplug-dispatch[8853]: env #0: 'HOME=/'
    Jun 24 09:02:02 hotplug-dispatch[8853]: env #1: 'PATH=/sbin:/bin:/usr/sbin:/usr/bin'
    Jun 24 09:02:02 hotplug-dispatch[8853]: env #2: 'INTERFACE=vpn0'
    Jun 24 09:02:02 hotplug-dispatch[8853]: env #3: 'ACTION=register'

    More information:

    http://linux-hotplug.sourceforge.net/

  3. Re: USB Query

    Rainer Weikusat wrote:
    > MAx writes:
    >> I want to trigger an application in the user space when a usb
    >> device is plugged into the system.
    >> How do i get the notification of a usb device plug in the user space.

    >
    > The kernel will execute the program whose name is stored in
    > /proc/sys/kernel/hotplug whenever a 'hot plug'-event occurs, passing
    > the name of a subsystem as argv[1] and setting up some environment
    > variables with 'relevant details'. For a network interface, this looks
    > like below:
    >
    > Jun 24 09:02:02 hotplug-dispatch[8853]: unhandled hotplug event, subsystem 'net'
    > Jun 24 09:02:02 hotplug-dispatch[8853]: env #0: 'HOME=/'
    > Jun 24 09:02:02 hotplug-dispatch[8853]: env #1: 'PATH=/sbin:/bin:/usr/sbin:/usr/bin'
    > Jun 24 09:02:02 hotplug-dispatch[8853]: env #2: 'INTERFACE=vpn0'
    > Jun 24 09:02:02 hotplug-dispatch[8853]: env #3: 'ACTION=register'
    >
    > More information:
    >
    > http://linux-hotplug.sourceforge.net/


    While there, that was designed for the transition until udev and dbus.
    You can sit on the system dbus and see this stuff when it happens now.
    I consider that plug to be deprecated (which is why it's empty on
    most systems now).

    It's pretty easy to code something to fire up from the udev rules.

    See:

    udev
    udevmonitor
    udevinfo
    udevtest (to test out your rules)


    http://www.ntlug.org/Articles/Hotplug?action=login
    (login using GuestReader password guestguest)
    It's protected because the article isn't finished yet.


  4. Re: USB Query

    Chris Cox writes:
    > Rainer Weikusat wrote:
    >> MAx writes:
    >>> I want to trigger an application in the user space when a usb
    >>> device is plugged into the system.
    >>> How do i get the notification of a usb device plug in the user space.

    >>
    >> The kernel will execute the program whose name is stored in
    >> /proc/sys/kernel/hotplug whenever a 'hot plug'-event occurs, passing
    >> the name of a subsystem as argv[1] and setting up some environment
    >> variables with 'relevant details'. For a network interface, this looks
    >> like below:
    >>
    >> Jun 24 09:02:02 hotplug-dispatch[8853]: unhandled hotplug event, subsystem 'net'
    >> Jun 24 09:02:02 hotplug-dispatch[8853]: env #0: 'HOME=/'
    >> Jun 24 09:02:02 hotplug-dispatch[8853]: env #1: 'PATH=/sbin:/bin:/usr/sbin:/usr/bin'
    >> Jun 24 09:02:02 hotplug-dispatch[8853]: env #2: 'INTERFACE=vpn0'
    >> Jun 24 09:02:02 hotplug-dispatch[8853]: env #3: 'ACTION=register'
    >>
    >> More information:
    >>
    >> http://linux-hotplug.sourceforge.net/

    >
    > While there, that was designed for the transition until udev and
    > dbus.


    I know of a couple of systems using a Linux-kernel which have no dbus
    anywhere. Some of them use udev, but only because that was the default
    setup, and except insofar this caused problems because of missing
    device nodes, I haven't seen a reason to spent further time
    with it. One of them is actually a desktop.

    > You can sit on the system dbus


    There is no such thing as a 'system dbus'. 'dbus' is an IPC-protocol
    originally designed for communication among 'desktop components' and
    provided by an application which may or may not be in use on any
    actual installation. Eg, it is somewhat inconceivable that a lot of
    existing embedded systems run it. Not everything is a 'modern PC' with a
    random Fedora version installed on it.

    > I consider that plug to be deprecated (which is why it's empty on
    > most systems now).


    Is it really empty because you consider it to be deprecated? Or
    rather, because designing universal IPC-systems incompatible to the
    last round of universal IPC-systems, to be obsoleted by the next round
    of universal IPC-systems is, like using topological sorting to
    construct a 'booting sequence' from 'dependencies' or replacing init,
    one of the 'classics' CS students program all the time?


  5. Re: USB Query

    Rainer Weikusat wrote:

    >Chris Cox writes:
    >
    >> I consider that plug to be deprecated (which is why it's empty on
    >> most systems now).

    >
    >Is it really empty because you consider it to be deprecated? Or
    >rather, because designing universal IPC-systems incompatible to the
    >last round of universal IPC-systems, to be obsoleted by the next round
    >of universal IPC-systems is, like using topological sorting to
    >construct a 'booting sequence' from 'dependencies' or replacing init,
    >one of the 'classics' CS students program all the time?


    I don't understand what point you're trying to make here. It is simply a
    fact that hotplug has now been replaced by udev in the current
    distributions, and for good reason. However, as always, you are welcome to
    keep running hotplug if it works for you.
    --
    Tim Roberts, timr@probo.com
    Providenza & Boekelheide, Inc.

  6. Re: USB Query

    Tim Roberts writes:
    > Rainer Weikusat wrote:
    >>Chris Cox writes:
    >>
    >>> I consider that plug to be deprecated (which is why it's empty on
    >>> most systems now).

    >>
    >>Is it really empty because you consider it to be deprecated? Or
    >>rather, because designing universal IPC-systems incompatible to the
    >>last round of universal IPC-systems, to be obsoleted by the next round
    >>of universal IPC-systems is, like using topological sorting to
    >>construct a 'booting sequence' from 'dependencies' or replacing init,
    >>one of the 'classics' CS students program all the time?

    >
    > I don't understand what point you're trying to make here.


    Obviously.

  7. Re: USB Query

    Tim Roberts writes:
    > Rainer Weikusat wrote:
    >>Chris Cox writes:
    >>
    >>> I consider that plug to be deprecated (which is why it's empty on
    >>> most systems now).

    >>
    >>Is it really empty because you consider it to be deprecated? Or
    >>rather, because designing universal IPC-systems incompatible to the
    >>last round of universal IPC-systems, to be obsoleted by the next round
    >>of universal IPC-systems is, like using topological sorting to
    >>construct a 'booting sequence' from 'dependencies' or replacing init,
    >>one of the 'classics' CS students program all the time?

    >
    > I don't understand what point you're trying to make here. It is simply a
    > fact that hotplug has now been replaced by udev in the current
    > distributions, and for good reason.


    I will nevertheless try it again: udev is a highly complicated system
    mainly designed to deal with automatic management of device nodes. It
    actually includes a complete programming language stylistically
    reminding me of the sendmail configuration language exclusively using
    gotos for control flow. According to one of the authors, it started as
    'simple' device management program using the existing hotplug
    infrastructure, continously growing in reaction to external events
    until all of the already available functionality had been
    re-implemented as monolithic C-binary. The current version needs at
    least Linux 2.6.13 to work at all. It is generally used by 'current'
    distributions mostly targetted at 'modern PC or better' computers,
    because it solves an important problem for distribution builders: It
    is no longer necessary to create a device node for each possibly
    existing device to enable users to do an all defaults installation of
    a distribution and to immediatly be able to use all of their possibly
    numerous random fashionable USB gadgets (in theory, that is :->).

    But Linux-based system are used in quite different setups and they use
    a large variety of different kernel versions _most of which do not
    support udev_. Some of the 'problems' supposed to be solved by udev
    are actually just highly traditional pre-UNIX(*) fictions, specifically,
    the idea that systems must not be structured for performance reasons.
    It consists of 15156 LOC and the udevd binary eats more than two megs
    of virtual memory permanently without doing anything at all most of
    the time. And not all systems using a Linux-kernel can do paging. In
    contrast to this, a simple hotplugging subsystem based on a helper
    process which can be started on demand and which uses shell scripts,
    ie supports being programmed in standardized programming language,
    supporting such 'revolutionary concepts' as subroutines (did you know
    that the shell has functions as first order cititzens?) and control
    structures can be implemented in 636 lines of (C) code.

    Just executing something when a particular device is plugged can be
    made a lot simpler still by just having the kernel execute a script
    when this happens. And computers can really support using cooperating
    processes to accomplish complex task since the days of PDP-11 UNIX(*).
    Depending on what needs to be accomplished, a variety of system
    designs are possible and the one which happens to be used now by some
    subset of the versions of some subset of the 'popular'
    Linux-distributions isn't prima facie the most sensible solution for
    any other situation.

  8. Re: USB Query

    Rainer Weikusat wrote:
    > Chris Cox writes:
    >> Rainer Weikusat wrote:
    >>> MAx writes:
    >>>> I want to trigger an application in the user space when a usb
    >>>> device is plugged into the system.

    ....
    >>> More information:
    >>>
    >>> http://linux-hotplug.sourceforge.net/

    >> While there, that was designed for the transition until udev and
    >> dbus.

    >
    > I know of a couple of systems using a Linux-kernel which have no dbus
    > anywhere. Some of them use udev, but only because that was the default
    > setup, and except insofar this caused problems because of missing
    > device nodes, I haven't seen a reason to spent further time
    > with it. One of them is actually a desktop.
    >
    >> You can sit on the system dbus

    >
    > There is no such thing as a 'system dbus'. 'dbus' is an IPC-protocol
    > originally designed for communication among 'desktop components' and
    > provided by an application which may or may not be in use on any
    > actual installation. Eg, it is somewhat inconceivable that a lot of
    > existing embedded systems run it. Not everything is a 'modern PC' with a
    > random Fedora version installed on it.


    This is true.. (not the part about there not being a "system dbus") I was
    talking in reference to newer distributions
    of Linux using Gnome or KDE.... though you can certainly have KDE
    without dbus if running less than version 4 (might be somewhat
    painful in later KDE v3).

    On the more modern desktop systems there are actually two
    dbus's, the system dbus which gets kevent messages and the
    session dbus which is setup as a part of the graphical
    desktop (Gnome or KDE) and is more hal centered. The system dbus
    is the one where you can see the kernel hotplug events come in
    and that is where you have the udev ties.

    Yes... it's possible to create a Linux based system without
    all of this... but they're not incredibly common anymore.

    But you are right... Linux is VERY adaptable. But I
    think (?), I'm right about what the OP is wondering about.
    Now.. if the OP were doing embedded Linux or something like
    that, then certainly, there may not be a large scale
    desktop environment involved at all.

    >
    >> I consider that plug to be deprecated (which is why it's empty on
    >> most systems now).

    >
    > Is it really empty because you consider it to be deprecated? Or
    > rather, because designing universal IPC-systems incompatible to the
    > last round of universal IPC-systems, to be obsoleted by the next round
    > of universal IPC-systems is, like using topological sorting to
    > construct a 'booting sequence' from 'dependencies' or replacing init,
    > one of the 'classics' CS students program all the time?


    It's empty because it's use is deprecated. You can follow the
    kernel mailing lists if you want to know more about the state
    of hotplugging, udev, dbus, etc.


  9. Re: USB Query

    Chris Cox writes:
    > Rainer Weikusat wrote:
    >> Chris Cox writes:
    >>> Rainer Weikusat wrote:
    >>>> MAx writes:
    >>>>> I want to trigger an application in the user space when a usb
    >>>>> device is plugged into the system.

    > ...
    >>>> More information:
    >>>>
    >>>> http://linux-hotplug.sourceforge.net/
    >>> While there, that was designed for the transition until udev and
    >>> dbus.

    >>
    >> I know of a couple of systems using a Linux-kernel which have no dbus
    >> anywhere. Some of them use udev, but only because that was the default
    >> setup, and except insofar this caused problems because of missing
    >> device nodes, I haven't seen a reason to spent further time
    >> with it. One of them is actually a desktop.
    >>
    >>> You can sit on the system dbus

    >>
    >> There is no such thing as a 'system dbus'. 'dbus' is an IPC-protocol
    >> originally designed for communication among 'desktop components' and
    >> provided by an application which may or may not be in use on any
    >> actual installation. Eg, it is somewhat inconceivable that a lot of
    >> existing embedded systems run it. Not everything is a 'modern PC' with a
    >> random Fedora version installed on it.

    >
    > This is true.. (not the part about there not being a "system dbus")


    There is no such thing as 'a system dbus'. This is provided by a
    particular application, which may or may not be installed on any
    particular installation ...

    > I was talking in reference to newer distributions
    > of Linux using Gnome or KDE....


    .... including installations of newer versions of some
    Linux-distributions. Insofar you are making specific claims regarding
    random pieces of application software which can run on Linux-based
    systems, you should quote your references instead of asserting that
    they certainly exist.

    But all of this is a tangential point.

  10. Re: USB Query

    Rainer Weikusat wrote:
    > Chris Cox writes:
    >> Rainer Weikusat wrote:
    >>> Chris Cox writes:
    >>>> Rainer Weikusat wrote:
    >>>>> MAx writes:
    >>>>>> I want to trigger an application in the user space when a usb
    >>>>>> device is plugged into the system.

    >> ...
    >>>>> More information:
    >>>>>
    >>>>> http://linux-hotplug.sourceforge.net/
    >>>> While there, that was designed for the transition until udev and
    >>>> dbus.
    >>> I know of a couple of systems using a Linux-kernel which have no dbus
    >>> anywhere. Some of them use udev, but only because that was the default
    >>> setup, and except insofar this caused problems because of missing
    >>> device nodes, I haven't seen a reason to spent further time
    >>> with it. One of them is actually a desktop.
    >>>
    >>>> You can sit on the system dbus
    >>> There is no such thing as a 'system dbus'. 'dbus' is an IPC-protocol
    >>> originally designed for communication among 'desktop components' and
    >>> provided by an application which may or may not be in use on any
    >>> actual installation. Eg, it is somewhat inconceivable that a lot of
    >>> existing embedded systems run it. Not everything is a 'modern PC' with a
    >>> random Fedora version installed on it.

    >> This is true.. (not the part about there not being a "system dbus")

    >
    > There is no such thing as 'a system dbus'. This is provided by a
    > particular application, which may or may not be installed on any
    > particular installation ...


    There is such a thing as a system dbus where it has been
    setup at init time to handle system wide events.

    But you're right. It isn't a necessity. But it's not just for
    desktop components.... though they may be the primary user.

    Thanks for correcting me.

  11. Re: USB Query

    Keep Linux free
    Spam and smoke free as well



    Chris Cox wrote:
    > Rainer Weikusat wrote:
    > > Chris Cox writes:
    > >> Rainer Weikusat wrote:
    > >>> Chris Cox writes:
    > >>>> Rainer Weikusat wrote:
    > >>>>> MAx writes:
    > >>>>>> I want to trigger an application in the user space when a usb
    > >>>>>> device is plugged into the system.
    > >> ...
    > >>>>> More information:
    > >>>>>
    > >>>>> http://linux-hotplug.sourceforge.net/
    > >>>> While there, that was designed for the transition until udev and
    > >>>> dbus.
    > >>> I know of a couple of systems using a Linux-kernel which have no dbus
    > >>> anywhere. Some of them use udev, but only because that was the default
    > >>> setup, and except insofar this caused problems because of missing
    > >>> device nodes, I haven't seen a reason to spent further time
    > >>> with it. One of them is actually a desktop.
    > >>>
    > >>>> You can sit on the system dbus
    > >>> There is no such thing as a 'system dbus'. 'dbus' is an IPC-protocol
    > >>> originally designed for communication among 'desktop components' and
    > >>> provided by an application which may or may not be in use on any
    > >>> actual installation. Eg, it is somewhat inconceivable that a lot of
    > >>> existing embedded systems run it. Not everything is a 'modern PC' with a
    > >>> random Fedora version installed on it.
    > >> This is true.. (not the part about there not being a "system dbus")

    > >
    > > There is no such thing as 'a system dbus'. This is provided by a
    > > particular application, which may or may not be installed on any
    > > particular installation ...

    >
    > There is such a thing as a system dbus where it has been
    > setup at init time to handle system wide events.
    >
    > But you're right. It isn't a necessity. But it's not just for
    > desktop components.... though they may be the primary user.
    >
    > Thanks for correcting me.


+ Reply to Thread