I just submitted my patch to remove calls (exec()ing) to basename/dirname in bsd.port.mk to GNATS. I didn’t time if this improves anything, but I assume doing a regex replacement in a make-variable uses less resources than doing a fork()&exec() or a system() call.
I don’t think this gives a huge improvement at all, it’s maybe even below the measurement threshold, but hey, why using external tools if the internal features are enough to do what you want? At least this patch is recorded now somewhere…
Today I fixed 3 linux ports (converting to the “new” world order) to not use RPM directly (the right thing is to use rpm2cpio, and bsd.linux-rpm.mk provides some nice stuff to handle this).
In the last week I fixed some stuff in the linuxulator-MFC patch. It should now compile on amd64 and i386 without problems (at least the code which I have locally). There’s one (strange) panic report which I want to analyze and fix (if it is linuxulator related) with Roman before I update the patch on my site.
In multimedia@ we have a discussion about the envy24* chips. One question is how to convince companies to provide some technical information or at least free hardware samples. As part of the answer I pointed to http://www.bsdstats.org/ which may be able to provide some numbers (e.g. envy24* chips without a matching driver) which may help in negotiating some stuff with a company. Unfortunately not many envy24 chips show up there. Part of the problem may be that not enough people run the bsdstats port (and enable periodic reporting of at least the devices).
So do you have any unsupported hardware (not only limited to soundcards) or some hardware which is still up-to-date but lacks some features in the driver (this is at least the case for all recent soundcards like envy24* or HDA based ones)? Fine, run bsdstats and enable the periodic reporting. Maybe we are able to get enough numbers to show to companies so that they think it would be financially beneficial to support us in some way (free hardware, docs, technical hints, whatever).
Oh… while we are at it, the ALSA people added support for some envy24 based cards based upon the reverse engineering effort which was needed to write our driver as it is now. So if you are working for a company and reading this: if you support us, you get the Linux stuff for free too. 🙂 And as an additional bonus, you can show a working driver without any bad legal strings (e.g. GPL infection) to OEMs. So go and calculate how much sales you can do with embedded stuff and come back to us with some technical hints and/or free hardware (it costs some few bucks for you to provide this: not much if it fails but a large amount of return if it works out).
Wow, some of the TODO items in the last post are done:
- emu10k1 lower priority on attach (allows emu10kx to attach when loaded too)
- sade committed (and code improved)
And I did some more things:
- emu10kx fixes (submitted by Yuriy)
- enhancement of the bsd to linux errno mapping (submitted by “Intron”)
- added some more files to ObsoleteFiles.inc (submitted by kris@)
- had a look at linux_kdump and determined that we should update it with what we have in -current
There’s also a submission of support for Envy24HT chips from Konstantin (he also has a page with a lot of docs for envy* chips).