 Znači, imam Stefano. Prezete narediti, da ga nekaj, da počekajte, zelo pačo, da ima prezistiti naredite radova. To je še najbolje, da se tako nekaj, ali v svoj tem razlizovati, ker, z koncem linoske, lepo, je poznaš, da ima svoje software, kako ima prezipovanjo k scoopranje z njega. Skupaj zbi potrebno. Kukaj? Daj tudi tudi je prezipovanje zpraviljane in potrebno vzvede kako je po njega. Kako bomo pošto tega vžudniti? Maybe because we have a software that we can test, we can have to test, but this software runs in a specific target. I work with embedded, so if I wanted to test a software for an embedded target, I have to emulate also the hardware of this embedded device. So, what I can do? I can, for example, for testing connection code in a desktop computer with a Wi-Fi or GSM network, I have to buy an angle to have this functionality, but it's not a tool where to do this. Why I have to check if this connection code works? Because it's powerful to have a connection code in an embedded device that works very well, because if you have some problem with this code, your device is an azubel. And also with the battery. How I can check if the battery is low? I can pop up a notification to the user if the battery is low in my desktop computer that I can have any battery, so what I can check. And also, with other devices that can be connected to an embedded device, or are already present in an embedded device like GPS, or like another tracker tools that are common, like some specific devices that are connected to your body. And all this you can test your software using Python. But in which way? The standard Linux architecture here is very simplified, but at the bottom you have the hardware that is connected to kernel. The kernel uses a functionality after 2.6 that is called Inotify. Inotify is a module of the kernel that thanks to this module is possible to connect, to check if something is connecting to the real computer and get a notification immediately. And also with devices that are not real device, but emulated one. And so when I connect a periphery, or I change a file of a system, Inotify can detect this if you enable this functionality of the kernel. In the upper level, in the Unix system, in Linux system, you have some demon that are running. One of death is this debas. Debas is used commonly to send a message from an application to another, but also by the system demon, like upower. Upower is the demon that generates all the signal from your battery to your system. And debas is the message bus that is used by this program. Also, Udev is used when you connect a pendongle to your computer, it generates a Udev message that it runs again on the bus. On the top of this, you have your software to test. So you can emulate this hardware, how? The software to test is connecting not to your real hardware, but bypass by kernel. Other utilities I will show in previous slide, there are debas and Udev. But Udev, you can emulate. Why? Because it's connected to debas. So I can emulate Udev behavior using debas messages. So I can try to detect when the application want to retrieve data from a device using inotify, because inotify can permit me to say, OK, I'm reading from this file, this file is a device. Device is not present, I created this device. It's not a problem. And also Upower generate the message from the batteries from your power supplier. OK, I can sniff this information for a real hardware, a real battery, and then regenerate with debasmok. This basmok is only a library that can help you to create this simulation because they are in higher level, because it's not a kernel driver emulation. It's only a software using debasmessage. And so what are the libraries we can use in Python to use this functionality for Linux? Sure, pynotify is a library that is connected directly to this module of kernel. They are available in all Linux kernel to the 2.5 and permits in simple way to use inotify in a easy way. Then the bus python that is abiding from library debas, they are included in a lot of distribution, because a lot of program in a distribution of Linux is bus python to manage and create software they are based on. Python debasmok is a collection or template to generate emulated hardware. So inside of this library, this is only a collected library on top of the bus, because you have a network manager device that can create a network wireless network or a power template that can create battery power supply real simulator hardware. And then pyodev. Pyodev, why? Because when you want to investigate outworks on real hardware, you have to sniff to monitor with udev. udev with pyodev, you can control udev with python and then so monitor each device. Why? Because an hardware use to send message to the system using udev. So with this pyodev you can see all messages that arrive from a device. So when data reach the system and so on. And so this is a first debas service. You can create in a few lines. This is only using debas library. So the binding of debas library that are included in debas project. So they are maintaining the same version. So with this library you have no problem if debas is higher version that you are binding. They are maintaining the same. And so what you can see, you can create a test service using the session bus default that is for user. They choose session bus in debas system and user. The default, if you run your program without any parameter, it creates a bus in user space. And if you want to recreate a demo, like upower, you have to remember that upower creates a system service. So you have to use the debas like system. And then you can create a service with your path. Debas is create a path like linux standard. So a folder with a service and a service name. And then there is a simple function listen to create a loop to maintain this server. So it is like a demo that listen for each request you receive. And then you have the function. So the function is test service allow that returns only the word hello world. And this is what you can create with a template. So with debas mock you have a template. We can join to debas the functionality of what you want. So you can create a network manager device like this. You can create a Wi-Fi adapter. So if you have a specific specification of an hardware, you can recreate with this library. So you can attach a virtual Wi-Fi adapter to network manager. And then add actions point. If you want to try the scan, this is possible now, because you can recreate your Wi-Fi network without a Wi-Fi dongle. This is very cool. Also we can recreate the customer problem with a specific network, because you can create this network with the same key, the same protection, the same encryption. And then check if it is a double problem or a software network manager, for example. And then you can create the connection. So with a simple comma you can establish the connection with your fake access point. And so on. This is also useful for U-Power. With U-Power you have the same mock. So you have the possibility to create a battery with the same specification. So we can check all the specifications of battery with debas monitor. And then recreate with all specifications the duration of the battery, the state of power supply, whether it is connected or not connected. And so on. And what about iNotify? Before I say that if a software check a device, it access to a file. So it's open. If you have something that check that this file is open, I can run this simulation not always, but always what is necessary. Why this? Because if this is work full of time, you can have some devices that are not present, virtualized, they are always present in your system that is long. And iNotify prevent this. So the device are created each time the software in need. So with iNotify I can detect with the path, which is the device I can connect. So for example, if you wanted to access to Vulan zero, I put here the path of Vulan zero and then recreate all my network on the fly with the mock before I show. And also for the battery, also for if I wanted to recreate some device that are not present in a mock. I can create a mock myself because with SNF you have monitor, iNotify monitor. Yes, with iNotify I can read each requested from a software also by system to a specific path. So I can show when a file is created, deleted or modified. And this is very powerful because it's possible to have the same behavior of hardware device without anything, without anything else. And so this is what you can do with hardware emulation in Python and this is a small example of what you can do. But the possibility is very, very, you can reach everything. So if you have a device that you cannot have, but you have the specification, so you have only the data sheet, you can only recreate this also with Python. And this is very cool. Thank you. Any question? Having a debas message which claims there is an interface does not create the interface. So how does it help? In case of network, you can create a debas message and claim now you got connectivity, but you still don't have connectivity. The connectivity is not a problem. In the network connectivity, it's not a problem because if your system is connected to an ethernet, you can use this network. This is only an emulation of other devices that are not existent, but when you create a ping or whatever in your network, it goes forward a real network. So network manager is deviated by something, but in your program, in your emulation program, you can say, okay, we create all the network, but when we receive something request for a network connection, we write it to a real one. So it's not a real problem. I accept the answer. Are there any more questions? If I understood you correctly, your main purpose was to test hardware parts that are not available or that are rather hard to influence that they have this condition that you actually want to check with your program. Therefore, your field was embedded, I assume, and using embedded Linux, and using a normal Linux to basically test the whole stuff. Is that correct? This is used for testing software for embedded targets. So we need to recreate some hardware specific in a desktop computer. So we recreate some hardware device that are not possible to attach to a desktop computer. Another question? Do you also intend to build a virtual library for that or a library of virtual devices? It's possible. It would be very nice to have a virtualized library. In this library, the bus market is a lot of examples, but yes, it's not very well documented. Inside there is a network manager device, U-Power, and other system-based recreatable devices, and yes, it's not very well documented. But yes, it's possible to create some library, maybe in future, yes. Any other questions? Then thanks a lot for your talk. Oh, sorry. Have you tried to use this library when you interact with some proprietary hardware that runs only on Windows and you have virtual box or VMware, and would it be possible to sniff some of these events through this library? Would it be useful? If you use some emulation, it's not a problem, because in a virtual box, for example, if you attach a USB device, you can attach it directly to the machine. So you can sniff in a simple way. It's not a problem. Thank you. Thanks a lot for your talk.