Tag: bsd

Remov­ing super­flous calls to basename/dirname in bsd.port.mk

I just sub­mit­ted my patch to remove calls (exec()ing) to basename/dirname in bsd.port.mk to GNATS. I did­n’t time if this improves any­thing, but I assume doing a regex replace­ment in a make-variable uses less resources than doing a fork()&exec() or a sys­tem() call.

I don’t think this gives a huge improve­ment at all, it’s maybe even below the mea­sure­ment thresh­old, but hey, why using exter­nal tools if the inter­nal fea­tures are enough to do what you want? At least this patch is record­ed now somewhere…

Share/Save

Some fix­es to lin­ux­u­la­tor stuff

Today I fixed 3 lin­ux ports (con­vert­ing to the “new” world order) to not use RPM direct­ly (the right thing is to use rpm2cpio, and bsd.linux-rpm.mk pro­vides some nice stuff to han­dle this).

In the last week I fixed some stuff in the linuxulator-MFC patch. It should now com­pile on amd64 and i386 with­out prob­lems (at least the code which I have local­ly). There’s one (strange) pan­ic report which I want to ana­lyze and fix (if it is lin­ux­u­la­tor relat­ed) with Roman before I update the patch on my site.

Share/Save

A way to encour­age hard­ware com­pa­nies to sup­port *BSD

In multimedia@ we have a dis­cus­sion about the envy24* chips. One ques­tion is how to con­vince com­pa­nies to pro­vide some tech­ni­cal infor­ma­tion or at least free hard­ware sam­ples. As part of the answer I point­ed to http://www.bsdstats.org/ which may be able to pro­vide some num­bers (e.g. envy24* chips with­out a match­ing dri­ver) which may help in nego­ti­at­ing some stuff with a com­pa­ny. Unfor­tu­nate­ly not many envy24 chips show up there. Part of the prob­lem may be that not enough peo­ple run the bsd­stats port (and enable peri­od­ic report­ing of at least the devices).

So do you have any unsup­port­ed hard­ware (not only lim­it­ed to sound­cards) or some hard­ware which is still up-to-date but lacks some fea­tures in the dri­ver (this is at least the case for all recent sound­cards like envy24* or HDA based ones)? Fine, run bsd­stats and enable the peri­od­ic report­ing. Maybe we are able to get enough num­bers to show to com­pa­nies so that they think it would be finan­cial­ly ben­e­fi­cial to sup­port us in some way (free hard­ware, docs, tech­ni­cal hints, whatever).

Oh… while we are at it, the ALSA peo­ple added sup­port for some envy24 based cards based upon the reverse engi­neer­ing effort which was need­ed to write our dri­ver as it is now. So if you are work­ing for a com­pa­ny and read­ing this: if you sup­port us, you get the Lin­ux stuff for free too. 🙂 And as an addi­tion­al bonus, you can show a work­ing dri­ver with­out any bad legal strings (e.g. GPL infec­tion) to OEMs. So go and cal­cu­late how much sales you can do with embed­ded stuff and come back to us with some tech­ni­cal hints and/or free hard­ware (it costs some few bucks for you to pro­vide this: not much if it fails but a large amount of return if it works out).

Share/Save

I got some­thing done in the last days

Wow, some of the TODO items in the last post are done:

  • emu10k1 low­er pri­or­i­ty on attach (allows emu10kx to attach when loaded too)
  • sade com­mit­ted (and code improved)

And I did some more things:

  • emu10kx fix­es (sub­mit­ted by Yuriy)
  • enhance­ment of the bsd to lin­ux errno map­ping (sub­mit­ted by “Intron”)
  • added some more files to ObsoleteFiles.inc (sub­mit­ted by kris@)
  • had a look at linux_kdump and deter­mined that we should update it with what we have in ‑cur­rent

There’s also a sub­mis­sion of sup­port for Envy24HT chips from Kon­stan­tin (he also has a page with a lot of docs for envy* chips).

Share/Save