My name is Leo and I’m a first year Software engineering student at Polytechnique Montreal. I have discovered Haiku a couple months ago but have gotten more interested in the development side of things through GSoC.
I have successfully compiled a nightly image from source and I have it running on qemu. I read through the list of projects and found the Devices preferences/Hardware manager project interesting. I lack the kernel skills/knowledge (which I will work on), but I have experience working on micro-controllers such as Atmega324PA in C++ and building an interpreter in C, hoping that my experience will allow me too quickly understand the Haiku API and the Device codebase.
With that in mind, I have a couple of questions :
I have read the todo documentation in the devices path of the repo. Would doing one of these tasks a good start as my first contribution, or do you suggest I take on one of the tasks marked “easy”?
For the project itself, is the main goal to turn the Devices app into some kind of control center? Or should it stay an information viewer with certain capabilities like blocking a driver?
The goal of the project is to make the Devices application more useful and more friendly.
This can include:
Having icons for different device types (video cards, printers, …)
Knowing if a device is handled by a driver, and which one
An option to disable a device or a driver
Links to open other preference panels from the Devices one (for example to access display settings, mouse settings)
One part of this is just user interface changes. But there will also be work on the “backend” side of things. The information (for example, wether a driver is present and handling a given device) is not readily available to userspace applications. So this may need some kernel-side code.
This gives you two things to research to prepare a GSoC proposal:
Study the existing code to understand how the Devices app enumerates hardware and how it communicates with the kernel. Determine which new information would be needed and how to access it
From the user interface side: you can prepare some mockups of what the changes would look like. Maybe a review of how other operating systems expose similar information, what they did right, what they did wrong, what we can borrow from them.
Kernel side development is not as scary as it sounds. You can try to read the code of the Devices application (starting in Making sure you're not a bot!) and see how far you can get in the code layers. Then ask us if you need help at any step.
You can pick any task that seems in your reach. So if you found a TODO that you can start solving, that sounds good. If you identiifed one in particular, I can have a look and see if I can share some insights.
Thank you very much for your guidance! I will be studying the existing code of the devices app and attempt a task that I find within my reach. I’ll reach out with more specific questions once I’ve got a small contribution going. Thanks again!
I am especially looking for thoughts on my timeline. This is my first time taking on a project of this scope, and I want to make sure it’s realistic in the given time and if I am not missing anything.
Personally, I very much liked the way Mac OS X allows one to be notified when hardware appears / disappears. Writing an application that gets notifications when a USB-serial device is attached and making it available in a menu was possible using IOKit. -Unfortunately, to make my application complete, I had to find the /dev/… pathname - that part was a bit un-intuitive.
I think that the notifications are important and would fit Haiku very much (like the file-system can notify a subscriber that a file has changed).
Hello,
You can expand the “project proposal” section with a lot more technical details. You can include what you learnt of the current architecture of the application, some basic explanation of devfs and ioctl (we already know what these are, of course, but it’s to make sure you understand the concepts), and the architecture you plan to deploy. For example in your timeline you mention handling usb and blutooth devices specifically, why do these need special handling?
Have you read documentation about the device manager (in Welcome to Haiku internals’s documentation! — Haiku internals documentation) and about “olo style” drivers (probably in BeOS newsletter archives) to see how drivers work and interact with the kernel? Your proposal should include a summary of those and maybe of the kernel internal data structures .
The “goals” section can also be expanded. Maybe there is no need to go all the way to UI mockups, but at least listing what new fields and buttons would be added. For example: the name of the driver that is in chanrge of a device, the device path in /dev, the ui for “blocking” a driver or a device, maybe a way to export the system information, or to open the bugtracker with a pre-filled bug report? (These are just a few ideas I came up with, but there are many ways this application could evolve)
Hi,
Thank you very much for the feedback! I am sorry for the delay of my response. I had a long week of exams at school.
I took time to go through your suggestions and the haiku internal documentation. With those in mind, I updated my proposal by adding a technical approach section to my project proposal. I added some more details in the action plan of each phase.
You can view my updated proposal here : https://drive.google.com/file/d/1JLP5jr-W3niZFKCO_rKyLyu7eePE24lk/view?usp=sharing
Also, I made a patch for the devices application implementing the order by bus feature and is up on Gerrit (change 10481). It helped me understand how the application uses the fDevicesOutline tree to show devices. I would love some feedback on it!
Thank you again for your time.