On Mar 20, 2016 2:04 PM, "Cristina-Gabriela Moraru" <cristina.moraru09@xxxxxxxxx> wrote: > > 2016-03-14 10:56 GMT+02:00 Julia Lawall <julia.lawall@xxxxxxx>: > > > > > > On Sat, 12 Mar 2016, Cristina-Gabriela Moraru wrote: > > > >> Hi, > >> > >> My name is Cristina Moraru and I am a software engineer from Romania > >> currently a student in a Master's program. I am interested in Driver > >> Backports project from GSoC and I would like to familiarize with it > >> and start contributing. My experience so far with Linux Kernel > >> includes an university course of driver development and an internship > >> at The Linux Foundation within Outreachy program (December 2015-March > >> 2016) in which I developed drivers in the Industrial I/O subsystem. I > >> have checked the TODO's page and I think the most interesting idea is > >> adding make localmodconfig support. Any suggestion of what to start > >> with ? > > > > Hi, > > > > Sorry not to have gotten back to you. I will discuss with Luis about what > > we are interested in supervising in the context of GSoC, and get back to > > you. > > > > julia > > Hello, > > Do you have any update ? Cc'ing the kconfig-sat list as well. Sorry for the delay. I can certainly mentor you on the localmodconfig support for backports. You actually may be able to get this done fast though, so I'd like you to also think a bit also about perhaps expanding this to something a bit ambitious should you have more time or want to really extend your work to be useful outside of the context of just backporting. For instance, the Linux kernel upstream 'make localmodconfig' has some issues, and adding support for 'make localmodconfig' support on backports may actually fill in some gaps that may help upstream. Although Linux backports helps complement Linux upstsream, Linux upstream historically has not needed to care about older kernels other than to ensuring we don't break ABIs, but since the work you do helps identify what backported drivers you need you're essentially attempting to resolve the question of 'what old drivers do I have enabled on old kernel X which I actually need in a new kernel Y?' While addressing this question is very backports specific, it also has an application upstream as well: it could mean leveraging the same solution on Linux upstream. When you download the latest kernel you are essentially asking the very same exact question, only we don't address this right now through 'make localmodconfig'. Because of this, it also makes sense to see if we can come up with a reasonable compromise which might actually help address this upstream as an optional enhancement, somehow -- with either a map or perhaps some optional driver annotations. Historically Linux upstream has not cared about backporting, but through the years we've identified a few changes in coding practices that may help make Linux backporting more automatic and safe, given the gains, we've already started to slowly justify some changes upstream to help with this. I'm not saying it is a requirement and we are sure we will do upstream changes to help with this problem, I am saying we should keep an open mind about that possibility. As another example, in terms of backports you also have some situations where a user is using an old distro kernel which lacks a driver to support a piece of hardware only available on future kernels, the backports project would carry a driver which would enable such piece of hardware without requiring the user to upgrade the full kernel. In these cases 'make localmodconfig' on Linux upstream should have have no heuristics currently available that help it identify that a new driver can help support your old piece of hardware, as it really only relies on your currently loaded set of modules. Resolving this gap clearly is not only something applicable to Linux backports, it can be used upstream as well. For your project I'd like to recommend you consider studying the core basic driver model, in particular you can study these things from Linux upstream sources: Documentation/kobject.txt Documentation/kref.txt Documentation/driver-model/ To extend your project in more challenging and interesting ways you may want to start think about how to project current available set of output from bus / standard tools (lspci, lsusb, dmidecode, acpidump) onto an existing kernel .config / Kconfig language, and perhaps maps between old kernels and new kernels. One thing you can take into consideration that may help for more ambitious goals is knowing that the prospect of kconfig getting SAT solver support may soon be reality thanks to the work of a quite a bit of people [0], and if you want to project your own goals with a SAT solver already in place it means the set of toolbox available for your solution to the problems you need to address grows. Doing this means you'd be projecting either future goals or other building your own solution on a piece of technology which may soon be able to reap benefit from. This is good for both short term and long term. Its good for the short term so you think outside the box, and gets you thinking of the larger picture, for the long term it may extend the goals of your own work in alignment with future technology we may have. [0] http://kernelnewbies.org/KernelProjects/kconfig-sat Luis -- To unsubscribe from this list: send the line "unsubscribe backports" in
