 Hello everyone, my name is Olexiy Rinpe and I am talking today about updating old drivers for even older hardware, how to do new and trickier things with the latest kernel. This talk is mostly a motivation talk for new kernel developers, so if an old proven kernel developer, then you probably want to leave this room right now. You can see in this talk how to, what kind of pains you can experience by touching old code and probably see what kind of positive things you can take out of this. It will probably not hurt you much. Very old driver is a historically ground thing, so it is like a sensible old ecosystem like this old wall behind of me, which is like 100 years old. Why does anyone actually need to change your update or repair something? Well, if you want to provide some kind of new functionality. Why do we have actually drivers which don't work or don't do things which we expect to do it now? Well, developing software takes time. It is kind of evolution which stops at some point and we have no new updates or no new interfaces just because it is working good enough. The software is almost never completed. We can work and update it almost forever. Well it is completed only if you stop and do work and can this. If you provide some kind of functionality or start creating some driver, for example in the network driver case it will be basic functionality like transmitting or receiving pickets. Something more advanced like diagnostic is not often implemented or if it is implemented it is not using new good unified interfaces. So if I want to have something like new kind of good unified diagnostic interfaces which are reusable for almost every system administrator, then I would need to port part of my code to use good proven filip creates own driver for each file. So we can provide for example something like cable testing or provide MDI configuration capabilities and etc. In case of better Mac support we can extend all drivers to use unified hardware counters, packet counters and provide hardware or software time stamping. Starting from last year or something like this we can use self-test, generic self-test support almost on every Mac which currently not supporting this, probably existing self-test will be a bit harder to to port, but it needs some more work and more time. So why files, why do I care about files and what is actually is from first look it is kind of black box between cable and the Mac and do it actually has a driver. Yes it is, it is, has a driver which usually integrated into filip framework, sometimes or in older drivers we usually didn't have own driver for the file which has implemented this into the Mac driver. So here's one example the ASICS, ASICS based driver example. At the beginning I said took this task it was almost perfectly working driver for ages if I remember it correctly it was integrated upstream for 15 years or something like this and the file support is a tiny part of this Mac driver which is enough to detect link status of the file embedded into this file, into this Mac. In some cases there are devices with external files and most of them are actually not main lined driver it is provided by the downstream vendor driver. So we want to try to do something similar we want to create our own hardware based on ASICS x88772 with our own external file to do new interesting things you can see this new fancy hardware on this picture. So let's attach different file and make a new device with the external ASICS with the external file and ASICS driver we have different options for example we can do the same like it was done before and integrate some code into the Mac driver to handle five specific things inside of this or we can port ASICS driver to filip and use filip framework so potentially we'll be able to reuse every driver every file driver provided by filip with ASICS driver so let's do things properly and port ASICS driver to the filip what could possibly go wrong before my work was done before my changes ASICS was monitoring the link status by itself and if some kind of changes was detected the ASICS driver called MII at the tool.js set callback and tried to get all the generic file configuration and state registers so as soon as long as the file is implemented according the latest standards it would work after the change the driver is registering MII boosts and connecting the FI MII boosts was registered with MDIO boost register function and the FI was connected with FI connect function by linking ASICS adjust link callback the link change is now tracked by the five framework it is the main difference to previous code and the link reset function which was used before was replaced with the ASICS adjust link function which is now called by the five framework and state of the driver itself so after all of these changes i triggered at least six regressions which are fixed by now and the question is was it worth to do this change i mean do the pain i caused to other people by adding these regressions it's on payback and i will say yes it is worth because now we are able to support like every possible FI we file a framework and we able to use a cable tasting or to do cable tasting if the FI is capable of doing this and now the driver is using self-test generic self-test support so we can even run some self-test and to see if our hardware is actually working one other example is the switch wise switch well it is complicated enough and it is kind of black box with even more ports and it is part of it can be used as part of diagnostic for complicated network problems or it is part of the problem itself as my point of interest i was i took one of old chips from ateros r9331 which has which has like many integrated parts mips cpu with 200 mere here so something like this it has integrated switch for five ports and it has even integrated wi-fi but it is currently not interesting for me so how much of this 11 years old chip can be can provide of how much functionality can this chip provide for us by using latest and greatest kernel so i started this as a non-commercial project this means i have kind of limitless time and i can do this in between of work and my life it is a hobby job my point of interest of this chip is a switch but to make switchwalk i actually need to mainline internet mac driver as well so instead of teaching one driver new things i needed to teach two drivers this is mac driver ag 71 xx and the switch driver if it is interesting for you you can find non-mainline five-based driver inside of open verte repository it is you can see this on the screen and the new mainline driver after end of this work is inside of mainline kernel as part of the days i framework after starting this job some years later the mac driver ag 71 xx is mainline i it was based on the open verte version which was not mainline before and i removed five and switch specific functionality from downstream driver and reused the five lip and the sr frameworks where it was appropriate and i removed it the hard tools and the buffer phase interfaces to make first of all mainlining easier and to review and properly integrate this functionality into related frameworks and if needed to create needed interfaces the switch driver was written from scratch because i was not able to reuse code of the five base driver and at the end this new driver has a bit more functionality as the downstream driver the new driver is using some standard tools like ip root 2 and the hard tool so based on this experience which was made with these three drivers i would say that many of currently mainline ethernet drivers old ethernet drivers can be updated by using filip framework and it is possible to migrate at least part of them to use unified stats 64 interface to provide reusable counters for every driver every interface yes so you can just use ip tools and see this this counters working don't forget about flow control it looks like it is not really properly implemented by many drivers probably because it is not so trivial to test it and it needs some experience and attention to make it properly and from now it is possible to port almost every driver to use generic self-test code which has at least some basic functionality like sending ip tcp udp packets of a loopback provided by the phy potentially we can use even other kind of loopbacks for example provided by mac or other levels of phy but this needs more discussion and needs better integration so which is not currently implemented now what kind of lessons did i learned from all of this project first of all it takes time it takes time and money sometimes it depends if your company can give you some time to do this work so it will cost your company this money you will probably make some people unhappy because old interfaces was used and the new interfaces should be learned so old scripts may break or so in case of mainline drivers this will probably trigger other kind of discussion if you allowed to break these interfaces but if this driver was never mainline then you should break these interfaces to be able to mainline this driver and you should use actually new and latest frameworks at the end there's not only negative parts you will have a lot of pleasure using this hardware with latest and greatest tools and the latest bleeding edge kernel and your stone edge hardware my motivation to do this kind of work even by spending my personal time is uh imagination that uh i sitting in some airplane or train which is crushing and the reason why is crushing is my failing driver and i blaming myself not doing this not implementing this properly if you want to see what kind of work was done in for these three drivers for a6 ag 71 xx and the s a f 9 3 3 1 switch you can see all of these links on this page or you can use this git log snippet to read of changes commit changes for a6 driver or if you download this presentation as per the file you'll be able to click on this links and as usually don't forget to subscribe and press on this link to subscribe yourself to the netdev mailing list to see all of their cool work which is done by all of these developers who are working on network stack thank you and do you have any questions