We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Making the Linux Kernel better (without coding)

00:00

Formal Metadata

Title
Making the Linux Kernel better (without coding)
Title of Series
Number of Parts
199
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
In this presentation, I want to show little-known mechanisms to add hardware support to the kernel at runtime, i.e. without recompiling. After this presentation, the Linux kernel will have gained support for a previously unsupported USB device (without having to write any code). Not everyone is interested in becoming a kernel developer or being able to write device drivers from scratch. Yet, there are a number of people who would like to help the kernel development "just a little bit". Yay, this is easily done! I aim to enable people to improve the kernel by adding support for previously unsupported hardware. How? Consumer hardware often shares a common core which is then simply re-branded by the actual vendor. This branding often includes changing the USB-ID or PCI-ID. A kernel developer can make a driver for that core, but will not be able to know all the incarnations of that device, i.e. all the IDs. This is where the community comes in. Having all kinds of hardware, people can add missing pieces to the puzzle. In this presentation, I want to show some little-known mechanisms to add hardware support to the kernel at run-time, i.e. without recompiling. For that, I will also present ways to effectively obtain the required information about hardware to be added. Finally, information is given how to report the findings. Intended audience: Everyone who is interested in kernel hacking is invited. Basic shell knowledge (sudo, echo) and ability to send e-mail are enough
MereologyCodeKernel (computing)XMLUML
WordHacker (term)Kernel (computing)Open sourceComputer hardwareCuboidComputerMultiplication signVideo gameSoftware maintenancePhysical systemCodeSoftwareWebcamBus (computing)Device driverLecture/ConferenceComputer animation
Digital libraryDevice driverMessage passingInstallation artForm (programming)Survival analysisGoodness of fitExecution unitInformationComputer animationLecture/Conference
Function (mathematics)Electronic mailing listDevice driverDevice driverWebsiteError messageType theoryIntrusion detection systemProduct (business)InformationWeb 2.0Patch (Unix)EmailCASE <Informatik>String (computer science)Row (database)Term (mathematics)Bookmark (World Wide Web)Process capability indexBitSimilarity (geometry)Computer hardwareIdentifiabilityDatabaseRadical (chemistry)MereologyIdeal (ethics)HelixForm (programming)Search engine (computing)Numbering schemeAdditionComputer animation
Internet forumDistribution (mathematics)InformationKernel (computing)CASE <Informatik>Device driverSource codeComputer hardwareWindowDevice driverResultantForestWeb pagePrice indexComputer file1 (number)Line (geometry)BitRevision controlDifferent (Kate Ryan album)Uniform resource locatorDatabaseSimilarity (geometry)Numbering schemeInferenceWeb serviceTheory of relativityQuicksortMereologySlide ruleWeb 2.0EmailConditional-access moduleIntrusion detection systemInfinityCursor (computers)2 (number)Lecture/ConferenceXML
Term (mathematics)Bookmark (World Wide Web)Device driverInformationWeb browserSearch engine (computing)outputElectronic mailing listDevice driverSocial classLine (geometry)Function (mathematics)WindowOpen sourceKernel (computing)Computer hardwareGeneric programmingDatabaseModule (mathematics)Forcing (mathematics)Endliche ModelltheorieOrder (biology)Run time (program lifecycle phase)ComputerMultiplication signParametrische ErregungPatch (Unix)Fluid staticsException handlingDependent and independent variablesSubsetVariety (linguistics)Address spaceBitSoftwareMessage passingPattern languagePlastikkarteProcess capability indexSoftware testingBus (computing)Computer fileAsynchronous Transfer ModeInheritance (object-oriented programming)Physical systemIntrusion detection systemLogicOcean currentParameter (computer programming)Structural loadFlagConditional-access moduleRow (database)Expected valueFreewareLecture/ConferenceSource codeComputer animation
Line (geometry)Computer programmingBitComputer hardwareConditional-access moduleKernel (computing)Computer animationSource codeLecture/Conference
Computer hardwareDevice driverMechanism designKernel (computing)Open sourceSoftwareCAN busComputer programmingEmailPatch (Unix)Similarity (geometry)Data managementProcess (computing)WeightDevice driverRule of inferenceSource codeElectronic mailing listSoftware maintenanceSeries (mathematics)Address spaceOnline chatBitScripting languageHacker (term)Installation artLink (knot theory)HypermediaAuthorizationInformationModule (mathematics)Projective planeDatabaseScaling (geometry)Wave packetMultiplication signComputer configurationSet (mathematics)Slide rule2 (number)Case moddingDependent and independent variablesPointer (computer programming)Web pagePoint (geometry)StapeldateiQuicksortCodeEndliche ModelltheorieCASE <Informatik>Physical systemLecture/ConferenceComputer animation
CodeDevice driverLine (geometry)Computer fileWindowScripting languageVirtual machineReading (process)Combinational logicForm (programming)Associative propertyComputer hardwareTelecommunicationInformationPRINCE2outputOrder (biology)Point (geometry)Computer virusAddress spaceSoftwareACIDNumbering schemeGeometric quantizationFreewareMathematical analysisEmailAsynchronous Transfer ModeDevice driverKernel (computing)SmoothingCommunications protocolEvent horizonDescriptive statisticsIdeal (ethics)Product (business)CoroutineAdditionMonster groupWeightCartesian coordinate systemSet (mathematics)Intrusion detection systemInfinityTracing (software)Stack (abstract data type)Process capability indexConditional-access moduleDatabaseExpert systemType theoryThermal expansionHydraulic motorWebcamLecture/Conference
Type theoryText editorJSONXMLUML
Computer animation
Computer animation
Computer animationLecture/Conference
Transcript: English(auto-generated)
Welcome for the talk making the Linux kernel better without coding.
I would ask you if you want to leave during the talk or during the question and answer session following the talk, please make sure to leave quietly so the others have a chance to listen to the talk or to the question and answers. And especially if you leave through the lower back doors, please make sure the doors are shut after you,
because otherwise it's quite loud in here. Thank you. And thank you, Wolfram. Okay, hi, welcome. Thanks for coming to my talk. First things, a few words about me. I'm a Linux kernel hacker. I do make my living with that,
but besides that, I'm also a passionate hacker, so I also do it in my free time and like modifying the kernel. I happen to be the current maintainer for the I2C subsystem, which is a bus which is needed inside computers and embedded systems, and I take care about the master drivers.
And I do like to share my knowledge about what I find out when hacking the kernel, and I really like to enable people to participate in basically free and open source development, but especially in the Linux kernel, because I don't think it is that hard to hack on the kernel.
It is always said to be. It has some things you should know, but other than that, this is also a piece of software which is written in just C, and so it is possible to hack the kernel. And in this talk, I want to share some knowledge where you can even contribute to the kernel without knowing how to code at all.
One thing I noticed so far during this conference, I really do like muted devices during talks, both as a speaker and as a listener, so I'd really appreciate if you could silence your devices.
Thank you very much. So what is this about? It can happen when you set up a project, and maybe you want to monitor something with an old computer, and then you grab into your hardware box and found this old webcam that was cheap. You don't even know where it came from, but you just have it.
And you want to plug it in and see if it works. That's what I will actually be doing. This is a special talk for me because I will be showing quite some things live, and so you have the extra thrill of things failing here with me.
I plugged in the camera. Now I want to start some camera software, hope to get a picture, and I just get this very frustrating message. Please make sure the camera is connected. Yes, it obviously is. I can assure you. And make sure that the correct driver is installed.
And this is the problem we have. There is no driver for this camera, for this camera. The good thing is, as it is a very cheap camera, there are other variants of it already out there, so chances are pretty good that Linux has a driver for this camera.
It just does not know about this concrete instantiation of this camera. And this is what we are going to teach Linux here during this talk, and how to get the necessary information, how we can convince Linux to support this camera.
So this is how it all starts. I just repeated the error message again, just in case the back rows could not read it as well. And we are going to fix that. The first thing is obviously to know more about the camera, and names do not help very much.
We need a unique identifier, which in case for USB devices is a USB ID. PCI devices have something similar. And so you can just run these, probably you know them, commands to find out about the USB ID or PCI ID, and if there is a name connected to it.
If the output of those tools give you a name, that does not necessarily mean there is a driver already for it. Those two databases, the Linux drivers and the USB ID list are decoupled. And this is the first part, the first thing where you can take part.
Because for developers it is very, very useful to know which USB ID has which name. So if you have a camera, you type this command and see, hey, it does not show my camera name. There is a way for you to submit additional information.
I have mentioned here two websites which have two ways of contributing data. Here you can log on to the website and enter a web form, submit additional data, say hey, I have noticed that Alice USB does not list my camera.
This USB ID with that product ID has that name. And it will be included somewhere later. If you know how to generate patches, you can also send a patch to a mailing list. I will show you the, this is an example, yeah, that does not look very pretty.
This is basically the website, it is not very pretty but it is very effective. You see that you can here add IDs and stuff like that. Not very complicated yet very useful for developers because developers do not have a lot of cameras. So if you have hardware which is not detected by Alice USB, I would really encourage you to go there and add that string.
This camera has that name and developers can benefit from that.
Next step, if you found out the ID of that camera, obviously try using your favorite search engine, using that ID number, maybe the name and probably the term Linux and look for additional information.
You will usually find out a bit internals of the camera that might be needed or not. Usually you get results from distribution forums which may contain useful information but what I want to mention here is that you really have to watch out if the forum entries are like two or three years old.
Sometimes they mention that you have to compile an out of three driver from that source forge page or so. This is usually not the case anymore, most drivers are included in the main Linux kernel so it is not so complicated as it sometimes looks if you Google around.
So try to get information but try to think that this information might be outdated. What I find very helpful when adding this kind of hardware is get the information from the Windows drivers
which are usually supplied by some CD or you can still find them on the web. And besides the binary blobs which are totally uninteresting for this case, there is also an INF file which is a text file describing the driver. Of course drivers usually come some kind of package so you might need one of the classic ones, unzip, unshield,
to get rid of the packing headers. I found out that in most cases I even had to use wine to really install the drivers to some, somewhere it, sometimes it even fails to install the driver properly
but still you can get the INF file from that in the locations I wrote down there. Where does the mouse cursor come from? And so they are still available and they are still simple text files and we can parse them
and they show that most of these camera drivers even also on the Windows side are pretty generic. There is one driver handling all sorts of cameras and somehow these cameras are described in those files. Or at least relationships where you can guess, okay this camera must be similar to that one
or even the same one just with a different case. And there might be some other hardware relevant infos in there. There is one example from another cam where I once added support to Linux. And you really don't have to understand the details of that.
The first part is some kind of name of the descriptor and the second part is registering the actual USB ID which for the camera we want to support. The nice thing about here is that it gives a relationship. The red numbers also on the next slide, the red numbers are the USB of the camera we want to support.
That's our target. And the green number is a new information. The hey, that's the camera we know must be somehow similar to the camera we want to support. All fine? Okay. And just that those USB IDs are mentioned in one line gives a good indication that they are very similar.
This is the camera we want to support and even in the Windows driver the descriptor has this name. And so I back then could add support for this camera which was some Hewlett Packard camera
using the information for that camera which was, I don't know, some cheap company, probably Chinese. I don't want to say Chinese people do always cheap stuff but in that case it was really the case. So with this camera it's even a bit more luxury. We have lots of lines and with lots of USB IDs and as a comment after that there was even written some internals.
The first thing is the camera chip and the second is the sensor. So we can easily spot do we have some similar or exactly the same entries with different USB IDs.
So we gain the same. This is the camera we want to support. This is the genius something. And this is the camera which is exactly a rebranded version of my camera which is some micro-DR I don't know what.
So what we got is a similarity. We know the camera we want to support and we have a camera which is similar. Now we need to find out is this new camera or this new ID already supported by Linux? And then we can use a handy web service, the Linux kernel driver database or short LKDDB.
So if you enter the new ID we find out together with the search term LKDDB into favorite search engine, you will get information if this is supported by which driver and some extra information about that driver.
And this is what I wanted to show. So I open a new tab. I use Google. I enter 0C45624C. I typed this a lot during the last days. LKDDB.
Yay we got a hit. And this is from the database. Lots of generic information including listing all supported USB IDs so you can tell it's a pretty generic driver.
Here this is all different cameras which are already supported so it's not surprise that it's probably supporting yet another unknown one. The key information at the top here for us is the driver name. The module we need to load in order to add support.
This driver with our camera. This is what is called GSPCASN9Z20X.
Now comes a neat trick which is in the kernel for quite some time but it's not very well known that you can at runtime add a new USB ID to a driver and it will feel responsible for it. Every driver has a static list of drivers it feels responsible for but you can extend this list at runtime.
So first we go into super user mode so we can load modules, kernel modules. Remember the driver is not loaded yet. There's no device it feels responsible for so we have to do this manually loading the module. Once we have the module loaded the driver will get an entry in sysfs.
It's system, bus, USB drivers. It's long but it's kind of logical. GSPCA the driver name basically. And there there's this file new ID. It's a regular file and you can echo a USB ID into it. And the driver will start feeling responsible for that and making the best out of it.
This works for USB, PCI cards and if you still have a PCMCIA cards. And it's pretty good for testing new hardware with current drivers. And this is also one thing I want to do live.
Is that readable in the back? Hooray! Yeah, last row says yes. So GSPCA SN9C20X, CD-SYS bus, USB drivers, GSPCA.
So here we have the file new ID. I'll make it a little bit smaller. I hope it's still readable but I need more time. Still okay? Okay, thanks.
So this is the new ID of our camera where we found out which driver should feel responsible for that. And we echo it into there. Okay, let's see if something happened. I have another desktop where the Varlog messages is being locked.
And we see, okay, registered. GSPCA is probing. That's good. Oh shit, it failed. Yeah, that was for this talk expected.
That's one nice thing of the Linux kernel. It's free and open source software. I have given this a similar talk where exactly this pattern was needed and support was added. But there is a problem with generic drivers.
Yeah, we did that already. Generic drivers need parameters. The camera chip is supported but they support also a variety of sensors. So we need stuff like which sensor do we have and what address does it live and does it have special flags.
And if the parameters does not match the driver will fail and this is what exactly happened here. It worked for me when I tried it with the last cam but with this cam it failed. Not bad. My computer still lives and I can assure you the camera still lives. So you can really try around things and the chances that you break some hardware is very close to zero.
So just play around with that if you try to add hardware. Don't be too afraid. So now I had the problem. I had my talk accepted. I had the camera and still things did not work. So what did I do? I made it work.
I sent some patches to the Linux kernel which are accepted. Meanwhile they are already upstream. So I'm running here a kernel which is like three days old or something. And this introduces a concept of a reference ID. Remember we found out that there is a camera which is very very similar if not identical except for the casing to this one.
So I should be able to say to the driver feel responsible for that USB ID and use the parameter set from that USB ID.
And that is what I implemented. The first line here is of course if there is a new ID there is also a remove ID to get rid of like here broken entries. This is what we do. First we get rid of the broken entry. And then we say to the driver feel responsible for that USB ID.
Well we could assign a USB class. We won't need it here. We ignore it. Zero. And use the driver set for that camera we found from the Windows driver. Let's try that.
So echo remove ID.
Let's check again. I think this is correct. Okay there was a slight delay before the prompt returned. That gives some hope. Let's see the last lines of the output. It's probing again. Oh and it has a sensor detector. That sounds pretty well. It also created an input device. That's a button on top of the camera.
Pardon? Oh just the last lines are needed. Ah you can't see them. Oh sorry. Okay.
So that gives hope to start the camera program again. And here we go. We have a camera. So that was no C knowledge involved. It was echo. It was pseudo.
And just a bit of knowledge. Okay it's not very obvious knowledge I agree. But this is how people can add hardware to the Linux kernel. Because as a developer you only just have a few cams. You can write the driver for that but you can never have the bunch of hardware which is out there.
And this is also some kind of crowdsourcing. People users have all kinds of hardware. And so with such mechanisms we can make the Linux kernel support hardware even more hardware than it already does. I mean it's pretty good already but we can still be better.
So now the camera works for me or for you. But it wouldn't be free and open source software if we were keeping that for ourselves. What to do with that knowledge? If you're not into programming and creating patches it's totally fine to write a mail similar like this. Yeah I found this out and I don't really want to create a patch. That's all too complicated for me.
Here's the knowledge. Can somebody do something with it? That's perfectly fine. I'll give you some seconds to read it.
The key question here is whom to send the mail to. So somebody feels responsible. And there are some hints. The first is there's a comma and mod info which will give you module authors who wrote the module. You could have a look into that.
You could have a look at the beginning of the source file. And the nice thing about LKD, you know the Linux kernel driver database has links to the source file. So you don't even have to have the Linux kernel source installed. I just want to show that. Here's the page again. And if we go down, down, down, down, down, down.
You see here it has a link, drivers media USB. And then we have a link to some cross indexed source file. And then you can probably find here some email addresses as well.
And if you're interested in knowing a little bit of coding you can just also have a look how this driver works, what it does, what it maybe does not, if there are fixmes in it. And just have a look how such a driver looks like. It's not rocket science. If you have kernel sources installed, there's a nice script.
And the subdirectory scripts. It's called get maintainer. It will give you a list of people. Simply print a list of people you should have in your cc from the mail. I use it myself when I'm creating patch series. It's a good tool, very useful.
When in doubt, always lose a big famous LKML mailing list, which I wrote down there. And to be very sure, just add me and I will track if somebody from the subsystem will pick it up.
And if not, then I will just create the patch because it's a low hanging fruit. Totally okay if you say I don't want to do it, but you could even try. If not, I say it's a low hanging fruit, I will do it. Again, obviously, the camera will work for you.
The camera will work for the rest of the world. When everything went upstream and if everything went proper and there is a patch entering the Linux kernel, you will be credited. Like this, reported by and then you have your name in the history, git history of the Linux kernel.
For some, some don't care, for some it gives a warm and cozy feeling. So, you decide. So, you could stop there or you could move on. Next steps, possible steps I don't want to talk in detail about here are
create the patch yourself. I don't give any pointers for creating patches here. There are lots of them. One comment I want to make is that you don't necessarily have to use git if you want to create a simple patch. If you want to do serious kernel hacking, I really recommend learning git
if you don't know it already, but for such simple patches you can do like quilt or other more basic patch management software. That's totally fine. There are how-tos, how to work with that. On the net you will easily find them. For kernel related stuff I have added two pointers.
How the kernel development process works in general and what you should take care when submitting patches. I think it's worth reading even if you're not deciding on continuing working on the Linux kernel, but some of the rules are pretty good for, I think, most software projects.
It's not necessarily that every project should adopt the exact kernel rules, but it gives you an idea of what should be proper, what should be formalized to be working on a large scale project like the Linux kernel.
And if you do code, then you could also try playing around with the driver. When I first got the camera, I noticed there's an LED. It does not work. So one idea would be to check why this is a simple thing.
You could check the driver where the LED is controlled and what you could do about it. To be honest, this problem is already solved. When I traveled to Brussels, I had some free time in the train and I found out why, so I'm sorry this is already taken.
Or stuff like the camera can get pretty slow when there's not enough light because it has automatic exposure settings. And other cameras have an option to enable and disable automatic exposure. So you can disable it so the camera will be faster at the price of
two light or two dark pictures. This camera does not have that. It has always auto exposure, so it tries to make the best out of the light, but it can grow slow. So you could try to find out, is there a way to control that? Can I have a button for that so I can set it on and off?
That's how you could possibly get into driver hacking. Especially if it's a cheap cam, you really don't have to be afraid of doing any greater damage. It's really good for playing around.
Yeah, that was basically it. I'd like to have enough time for questions, so this is what the slides are, questions right now. I will be at FOSTA until tomorrow noon probably, so if you see me just approach me and ask me questions or come for a chat.
Well, there's my email address. You can write me a mail if you have questions. So that was this for now, and fire away. Yes, thank you for your presentation, and looking at what you are saying, I think it would be very valuable to have a script that you select a device,
like a PCI device or a USB device. You provide maybe the execution file from the Windows driver, and then inside the script making the INF analysis, and to compare automatically to the database you show, and try automatically the trick you showed until we have a new input device.
Or maybe it could help people to get a brand new camera as you did, give it the Windows driver which is obviously provided with it because the Windows set is much more bigger than the Linux one, and then automize all the detection and to say, okay, this ID is the one we are looking for.
So you're suggesting a script which passes the Windows driver and tries the combinations for the USB IDs and checks if it gets something to work? Maybe passing the INF file which is given with the camera, and then after reading the INF file, finding all the possible association
with existing USB devices that we already have in the Canada device, and then make your trick to try all the combinations that exist until it works. I think the idea is challenging, and if you like to do that, just feel free.
One thing I'd like to mention is that Windows drivers are still binary blocks, so we can't look inside them. And it might be that they have some extra code for some extra camera. So I'd really love, if a new USB ID is added to the kernel as a patch,
it should be tested on real hardware and not on speculation. This is what I would suggest. But it's really useful to have these files in mind and then look for potential cameras and you could try to find people on the net who had problems with that camera
and ask them if they could try this line and then echo the ID to a USB ID, to a new ID, do what I did here, and then you could check with someone who has a real hardware and then add the support to Linux.
Doing that totally automatically is not my preferred style. Hello. I think there are a lot of USB devices. Are there unknown USB IDs?
What about non-public specifications? Did people try to fetch inputs that are to send random stuff to a USB device in order to see what they get back? Not that I know of.
This is a side project. I'm not really a USB expert. I know that there are some companies using USB numbers which they shouldn't, but it's just laziness.
It looks like sloppiness or laziness or something in between. What I do know is that there are still a number of USB ID missing descriptions, like expansive cameras. If you type LSB, you just see the vendor but not the product name, so I really call again for crowdsourcing, check your USB devices,
check if they have proper names and maybe submit them to the USB ID list. That would be really great. Hi. Thank you for this talk and it inspires me to do something myself. I have a camera at home,
but the thing is I know already that this camera must have some initialization routine to get the webcam motors on. So what I need to do is I need to have some tracing also for the USB protocol to see what is needed to get the camera into this webcam mode.
So for sure I would have to do this on the windows where the drivers are running. Is there any tool that you can suggest to do such USB tracing? I haven't done that myself. There is USB snooping software for Windows,
so they intercept the USB stack and print out what has been sent back and forth. I think it's called USB snoop or USB snoopy or something like this. There is also hardware. They are quite expensive, very convenient but quite expensive.
Maybe I don't know of any free hardware, but I might be just lacking the information here. But I know there is software for Windows which intercepts the stack, USB stack and prints you the communication between the cam and the Windows host. And then you can reinvent it on Linux.
That sounds good. Please do that. One point about USB tracing. You can also run a virtual machine with Windows on it and try Wireshark with USBmon and then you can show the tracing.
Three, two, one. Last chance. Thank you very much for attending and have a great conference.
Thank you very much. We will continue here in Jonsou at three o'clock with your application versus GDB.