Is there a clean way to detect or receive events when a user inserts or removes a CD on a Linux platform?
Udev monitors hardware and forwards events to dbus. You just need some dbus listener. A quick check using the dbus-monitor tool shows this in my system:
dbus-monitor --system
signal sender=:1.15 -> dest=(null destination) serial=144 path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks; member=DeviceChanged
object path "/org/freedesktop/UDisks/devices/sr0"
This is the DeviceChanged event from Udisks, and the device path is included.
So, in whatever programming language you want that supports dbus bindings you can listen for those (system bus) events.
Traditionally there has been HAL (Hardware Abstraction Layer) for this, but the web page says
HAL is in maintenance mode - no new
features are added. All future
development focuses on udisks, UPower
and other parts of the stack. See
Software/DeviceKit for more
information.
and the DeviceKit page lists
udisks, a D-Bus interface for dealing with storage devices
So udisks should probably be what you are asking for.
The best way I was able to find was Halevt. Halevt is apparently a higher level abstraction than using HAL directly. It uses an XML based configuration file that may or may not be to your liking. The configuration file properties documentation is somewhat lacking. A list of all the supported properties are listed here:
http://www.marcuscom.com/hal-spec/hal-spec.html
Also, the link to Halevt: http://www.nongnu.org/halevt/
Related
I tried to generate code for a device changing the implementation type to SharedLibrary and renaming the Entry Point to Device_Name.so. I was able to generate and build, but in main.cpp it kept a main function not a make_component to be called by ComponentHost. the device constructors deals with arguments that ComponentHost doesn't, like the Device Manager IOR. I believe this functionality extension implies changing the source code of ComponenHost. Is it part of REDHAWK roadmap? any comments on how can I make it work?
So are you trying to use the shared process space within a node to communicate between devices and services? Because I don't believe that there is tooling specifically for this yet, but I think there is a way to do this. Just to be clear I haven't tried this, but based on the test used by the bulkio ports to determine local vs remote transport usage, I think this will work.
If you look at the persona pattern, you'll see that there is a Programmable Device which is responsible for loading Persona Devices. Most of the details for this aren't necessary for what you're trying to do, but the pattern should be helpful. To accomplish communication between Devices using shared memory, you could generate a Programmable device whose sole purpose is to forward parameters from the DeviceManager to the Personas. The Personas would then act as your normal Devices normally do, just launched in the same process space as one another.
The code generators for the Programmable and Persona Devices are not yet integrated into the IDE, so you'll have to create a new Device project in eclipse for each Device you want (so that you'll have the spd files). Be sure to add the appropriate AggregateDevice interface to your Devices. This let's the framework know that multiple devices can technically be considered one entity, but you can also individually communicate with each. Also make sure that the Programmable is an Executable Device, since it needs to launch the Persona Devices. Then, from the command line, you can run redhawk-codegen - - pgdevice </path/to/programmable/spd> to generate a Programmable Device, and redhawk-codegen - - persona </path/to/persona/spd> to generate your Persona Device(s).
Once all of this is done, you'll notice the main function for your Programmable launches the Device like you described in your question. However, the main function for the Personas has code to launch the Device as either a standalone Device or as simply an object in its own thread.
This should allow the bulkio ports of the Programmable and Personas to communicate with each other via shared memory. Obviously this will break down if you attempt to push data out of the process, at least until someone adds interprocess shared memory via something like shm. Not sure if that's on the road map, but it would certainly be neat.
Update: It appears that interprocess shared memory was added in RH 2.1.2, so you should be able to communicate between collocated Devices, Services, and Components using that mechanism. This renders the above unnecessary, but I'm going to leave it for earlier versions of RH.
Let me know if you have any questions!
As of RH 2.1.2, the default behavior for Devices/Services/Components whose user code uses redhawk::buffer for the data memory allocator and the stream API for interaction with the bulkio port is to use a shared memory transport between C++ entities that are running in different processes
We want to write a custom Gatt Server Application for Bluez where we want to give some useful features. For example:
Start Gatt Server
Register/Unregister custom Service
Add/Remove custom Characteristics/Descriptor
Set/Get Value of Characteristics/Descriptor
Disconnect Client / Close Gatt Server etc.
Bluez don't have these features in command line tool but they have several APIs (functions) to do that, we need to call those internal functions.
In according to that we wrote an application in "bluez5.28/attrib/" directory from where we called several internal functions from files of
"bluez5.28/attrib/", "bluez5.28/profiles/" and "bluez5.28/src/" directories and tried to build it with bluez Makefile.
Since bluez have automated generated make file from automake it is quiet hard to make any change in that Makefile. But when we tried it showed lots of errors
regarding dependencies and libraries e.g. undefined references, no such files of directories, etc.
Is their any easier way to use bluez functions to make a GattServer Application ?
Thanks in advance for your valuable answers.....
bluez gatt dbus apis are now complete as of version 5.29. You may consider using those if going via the dbus rather than directly through library calls is acceptable for you.
correlate pg:1950 in bluetooth spec4.0 APPENDIX: EXAMPLE ATTRIBUTE SERVER
ATTRIBUTES with gatt-example.c in plugins in bluez5.28
I want to process certain types of files lets say pdfs, whenever they get copied/downloaded to the system.
Is there any why that we can register with OS for listening to this kind of events.
I am ready to implement separate solutions for windows, mac and linux if required.
Windows has a concept of filesystem filter drivers (kernel-mode ones). Using it your software can intercept any filesystem operations and alter the data or just perform some action (or even prevent the operation). You can write such driver yourself or use our CallbackFilter library which includes a pre-created driver and provides an API for use in user-mode.
The alternative approach on windows is to use FindFirstChangeNotification system function to register for notification. This function works differently from the filter driver.
MacOS X doesn't have a concept of filter drivers but they have FSEvents API.
Update: (missed the linux part) on Linux inotify exists.
I have an application for the USB interface in QT (Embedded linux).
When Pendrive inserted kernel sends a signal for that and i want to recognize that signal and want my QT application to detect it.
I went through the unix signal handling tutorial of QT but i could not find any way of my problem.
I implemented the same thing as done in the tutorial but i did not find the way to detect the pendrive. It only kills the processes.
Please go through the following link.
QT Unix Signal Handling
I have also found using QdBus library of qt. I cross compiled it but gave me the errors of lidbus version.
Is there any other way to detect the external pendrive from the application ?
The kernel is broadcasting netlink information. You can,
write a custom QSocket() to get netlink information. See: Qt Projects thread
write socket code directly to get the netlink info
use an off the shelf toolkit like libusb, which will use netlink.
add a script to udev.conf or mdev.conf to write a file and use QFileSystemWatcher; possibly /etc/fstab as well. udev and mdev are the standard hotplug handlers and they have configuration files that allow you to run a script on an event. The underlying mechanism is again netlink.
Parsing netlink or using /etc/fstab maybe better if you want to automount the file system. If you choose the parsing route, you need to parse the name=value informationSearch for netlink, which is quite easy.
I got the solution i Have used the busybox facility of mkdev.conf. In which i have added the support for the USB pendrive detection and used the udev utility to make the bridge between the linux and Application signal handler.
What's the simplest way to detect CDROM media removal and insertion in Linux? I want to write some simple code to handle this. For example, just bind an event for media insertion and implement the handler.
Thanks!
Try man udev, or man hotplug.
The desktop 'standards' have options for this.
For example I think Gnome uses dbus for this:
http://www.linuxcertification.co.za/linux-training-sysfs-udev-hald-dbus
[..] These applications are mainly used by desktop environment to carry out tasks when an event occurs such as open the file browser when a USB drive is inserted or image application when a camera is inserted.
D-Bus is used for example to launch media players when a audio CD is inserted and to notify other applications of the currently playing song for example.
Configuration
You could just have your desktop shell (e.g. Gnome/nautilus) call your application when the even happens:
http://library.gnome.org/users/user-guide/stable/gosnautilus-61.html.en
Non-desktop
For the non-desktop version of this, man udev is indeed your friend. Info on writing udev rules is here:
http://reactivated.net/writing_udev_rules.html
The simplest way from user space is to grep the output of the mount command, provided you have configured the CDROM for automount ( in /etc/fstab).But if you want to have an asynchronous notification, you might need to look into udev rules and uevents.