I think it is better to discuss driver roster part separately (another forum topic etc.) to be more productive. Otherwise all discussion will again derail to driver roster discussion, forgetting everything else.
1 Like
A concept is that system consist of 2 parts: driver roster and device manager. Device manager manages device node tree. Driver roster manage driver compatible devices information and perform driver-device matching. So it can be though as 2 lists: driver info list in driver roster and device node list in device manager. Driver roster make a connection (attachment) between items of this 2 lists using attribute matching. Both lists can change at runtime and driver attachments will be recalculated accordingly.
Driver compat info list is initially populated from boot driver list, loaded by boot loader. After boot volume is mounted, driver roster will scan all driver add-ons and read compat info into list in memory. Add-ons are not loaded here, only compatibility information is read. Then it will setup node monitoring so installed/uninstalled driver add-ons will be automatically reflected in driver roster list and then driver attachments.
User can also add items driver roster list manually by using config files. It can be used for example to disable some driver: user define compat info with target device attributes, but higher score and no add-on set, so it will override installed driver add-on and replace it with nothing.
It is also possible to add/remove driver roster entries using an API available from userland to handle things like libusb or other userland drivers. Program that use libusb may override kernel driver by registering driver roster entry with higher score.
3 Likes
From my side, I think the hardest part of the job will be convincing Waddlesplash that it is OK to merge this. Surely the new device manager is not perfect, but as long as it is better than the previous one, and someone (x512 in this case) is willing to work on it and improve it, I’m happy that I don’t have to do it myself.
However, at the moment I have no energy to try to argue about this with Waddlesplash, so I will let other people handle this.
I will request only two things:
- That we don’t end up with 3 different driver APIs (BeOS “old style”, Device Manager v1 and Device Manager v2). One solution is to migrate all v1 drivers to the v2 API.
- That the Device Manager v2 is somewhat documented in the developer docs, at least as much as the device manager v1 was. I think we can extract some design rationale and overview from the discussions in this forum thread.
13 Likes
May I ask a 3rd thing ? That the model for developing drivers for the new model be clearly documented, with a complete example, even if for a simple thing ? Having to parse incomplete clues from many places, and with obsolete pages/articles/discussions appearing, ends up being very frustrating.
2 Likes
Sure, but I’m basing my requirements on “let’s not make things worse than they already are”. Otherwise it’s too easy to have things blocked in merge requests, and you end up having documentation for code that doesn’t exist yet, which is equally frustrating.
Let’s get migrated to this new device manager. Then I (or someone else) can take care of improving the documentation, and it will be more motivating to do so than it is for the current device_manager, when everyone opinion on it is that it should be rewritten. Documenting code that will be thrown away is something no one wants to do 
1 Like
I propose before we do this, we issue an R1 / beta5. I get the feeling DMv2 is going to offset the next release quite a bit while the bugs are worked out and all drivers converted over.
Are there any big tasks that need to happen before R1 / beta5 is branched?
2 Likes
Yes, of course, it’s not the time for big new changes.
Yes. My personal list:
- Update to ffmpeg 6
- Update to openssl 3 (the version we use is end of life and will not be getting security fixes)
- Update to ICU 76 or some other version (the one used by Haiku is too old for webkit, so we would have to ship two different versions)
- Fix buttons rendering in WebKit (I already did checkboxes and radiobuttons, it’s just a few calls to BControlLook) and make a new release of it
10 Likes
I believe that the points raised are reasons for migrating to DMv2, just @X512 needs to finalize details and some implementation ideas, @waddlesplash could carry out performance tests, BSDs have good ideas, but we have our own needs.
However, at the moment I have no energy to try to argue about this with Waddlesplash, so I will let other people handle this.
Same here!
These type of comments are not helpful at all.
While it might be hard to discuss things sometimes, it’s not like he has no point. I think all three of his points are valid points that actually deserve discussion.
Furthermore, I’d bring another issue to the table: way invent a new way to resources now? Those two things could be introduced completely separate from each other, which is likely to cause less headaches.
There is no point in saying “let’s integrate this now” when it’s not even done yet. What we can do now is have an actual discussion if that is the road we want to take or not.
And that we should have.
8 Likes
To clarify what I meant: there has been a lot of discussions going on, not only on the forum (where indeed I think it was constructive and useful) but also on the IRC channel, where it is a lot less organized and I have a lot of difficulty following it. There is no summary of this IRC discussion and the arguments were not very clear to me.
It would take a lot of time for me to read back all the logs, and try to understand the up to date arguments. The last discussion was about x512 prototype and his decision to use C++ instead of C structs of function pointers for the interfacing between the modules, as we did before. It seems waddlesplash does not like this approach, but I do not understand the arguments, and the format of the discussion does not allow me to follow why.
It would be much easier for me if the discussion was summarized into a wiki page, with the different design decisions (wether to use C or C++ for the interfacing, wether the drivers export info as xattrs, or as an ELF section as in FreeBSD, or we keep things hardcoded in the device manager, and so on), with the pros and cons of each option, what is already implemented, etc. At the moment I am busy with other things and I don’t have time to do this myself.
I think there is also a tendency to focus on minor details that are not so important (both in this discussions and in other ones), but I have already discussed this with waddlesplash directly to clarify it.
6 Likes
Considering you can inline c in c++, there’s no downside, and if using STL code, there’s nothing but benefits.
I like C, i use it, but if i could use c++ for my industrial control projects I would.
The argument isn’t rational, there’s only cons using c over c++. If you need inkine c functions not a big deal, if you need c++ virtual methods and inheritance, with c, your stuck.
It’s also harder to keep extensibility with c. So if there’s a argument there, it’s not rooted in first principles for design coherence and use.
There was a lot more discussion about it in the IRC channel.
There are some quirks to using “full” C++ in the kernel especially when modules are involved. For example, it will not be possible (in a straightforward way) to have a default implementation of a virtual method in one kernel module, and a subclass in another module that will use it. Pure virtual methods should be fine (and I think that’s the plan in x512 implementation).
You cannot know if the argument is rational or not if you have not followed that discussion. Which is what I am complaining about: it is difficult to follow on all the arguments, because this discussion exists only on IRC and I’m not going to spend hours finding it in the backlog and summing it up.
So, please, if you have a meeting on IRC or in real life about something, that’s great, but make sure there are meeting notes for the people who weren’t there. If you don’t want to write meeting notes, please use the forums or mailing list where there will be something reasonable to read. And, if you didn’t attend the meetings, we don’t really need your opinion on what was said in the meeting, because that will just add more confusion and we will end up debating about things that people didn’t actually say. The situation is already complicated enough as it is, thanks.
5 Likes
I’d have to look at the aforementioned quirks with c++ regarding your concerns, but it is probably a problem someone else has already solved somewhere. So I’d bet a bit of research would yield a solution that’s practical. X512 is also from what I can see, a very talented developer, who has a very logical pattern of thinking. I’ll go dive through the discussion but I’m sure it probably boils down to some artifice of routine at it’s core
No one has said otherwise…
There are interesting technical questions and problems to solve here. And there are different ways to approach them. Mine is to use what’s available and already developped, push it to the limits and then make changes incrementally to remove these limits as needed.
Here we have already decided that the existing device_manager has structural problems and needs a rewrite. X512 has already started such a rewrite, but at the moment it does not (yet) solve the problems identified with the existing design. This has happened several times already, also with other people, and it is hard to do a code review on such a thing: either it is submitted ine one big patchset in the end, and it’s a lot to review, or, it’s submitted progressively in a lot of small changes, and it’s hard to understand the general direction and why each change is needed.
How do we solve this? I think one way is by properly documenting the problems and the solutions. This is what I’m asking here. I think x512 doesn’t like writing docs a lot. I have done it for some of the previous changes (adding some comments in the code after he explained it in code reviews).
All these things are not problems of talent, but of communicating what you’re working on, sharing the ideas with other developers, and working as a team. If you let just one “talented” developer work on their own, maybe they can add a lot of features very fast, but you will get code that no one else can understand and fix. And we prefer to avoid that in Haiku. So, the code has to be written after discussion with other people or come with good documentation and be well architectured, so we can understand it.
I think this is not a completely crazy thing to ask.
So you are commenting based on my comments on a discussion that I didn’t fully read because it was too long and I asked for a summary. I think we can all admit that this is not going to provide any useful insight.
7 Likes
That is not true. I plan to write a documentation for DM v2, but there are currently 2 issues:
-
Some significant changes can be introduced that will invalidate most part of already written documentation.
-
I am not sure about format of documentation. Separate articles (using Markdown? AsciiDoc? RST?)? Or Javadoc style? I suppose some separate article is needed that explains core concepts in addition to per API calls documentation.
6 Likes
If you write it, even txt is good enough. “Prettyfying” it can be done later, since it will not add information to the thing.
An article that explain the core concepts, with some ties to the APIs involved would surely help a lot, also.
2 Likes
Good to hear!
I think articles would be what I need most at this point. Javadoc is helpful when already digging into the code, but I am not in a state where I can do that. What I need is more a design overview.
I think the logical places would be in the Trac wiki (but maybe you don’t have permissions to edit it, and maybe we should consider giving you such permissions), or in a format that can be integrated in the Sphinx docs (that’s usually written in RST). Or it could also be blog posts.
And, yes, things can change, of course, and the documentation can change as well. Even having some notes on “here’s what we’re experimenting with currently” would be useful to me.
5 Likes
It is necessary to make a list of device_manager problems and limitations.
1 Like
One of reasons that it is difficult to declare hierarchical key - value pairs structure that may contain strings or other arbitrary size data and fit it into separate section. If you use string literals, compiler will put it into .rdata section no matter what section is declared for parent data structure. So you are required to declare each string or other variable size data as separate global variable and reference it in key-value array that will be ugly and hard to maintain compared to *.rdef resource language.
See 37506 – attribute section is not working with constant strings.
1 Like