From time to time I notice things, or others do, in newbus that need to be cleaned up. These things aren't all that hard to do, usually, but finding all the places that need to do them can be a daunting task.
So I'll just report a couple that I've noticed in the past couple days, along with one from Hans Petter Selasky.
Callers of device_get_children do not check the return value. It can only fail when memory is low and the allocation fails for the children. However, it should still be checked. Going through the tree and doing sane things when it does would take some doing. This is the problem that Hans found, and many places in his usb tree he just made sure that nothing bad happened, but there might be other things necessary in some cases.
Next, not busses free up their ivars. Some just need to have a simple free(ivar) call, while others need more complicated freeing. One pass would be to audit all busses to make sure they do the right thing. This is complicated by the fact that almost all network drivers are now bus drivers too because they add mii bus to the mix.
Perhaps an idea might be to combine these two issues. device_delete_child, which would delete all the children automatically. Busses could register a bus_child_about_to_be_deleted callback which could cleanup the ivars. The default should be to just free device_get_ivar of the child deleted. Coding this up shouldn't take long, but modifying busses to use this, as well as making sure it is sufficiently general might be a bit if a challenge.
I've also done some work in p4 to create an obio concept. In this concept, all the busses in things like SoC that need help with enumeration would derive from obio (or maybe just use obio routines) which should help cut down on the large amounts of duplicated code currently present in the system. OK, small amounts, but each done almost right, but with niggling little (or large) hacks that a more regular system would solve.
I'm sure other people can suggest improvements for other problems they have noticed. Leave comments if you've seen something specific in FreeBSD and I'll update this article, or do a followup, as necessary.
You could write an entry for the ideas list for such things. Typically small and well defined stuff is more likely to get picked up by a volunteer than large stuff with a vague description. Joel or I will review/commit it for you if you don't want to commit it yourself.
ReplyDeleteGreat idea!
ReplyDelete