Lin­ux­u­la­tor progress

This week­end I made some progress in the lin­ux­u­la­tor:

  • I MFCed the report­ing of some linux-syscalls to 9‑stable and 8‑stable.
  • I updat­ed my lin­ux­u­la­tor-dtrace patch to a recent ‑cur­rent. I already com­piled it on i386 and arundel@ has it com­piled on amd64. I count­ed more than 500 new DTrace probes. Now that DTrace res­cans for SDT probes when a ker­nel mod­ule is loaded, there is no ker­nel pan­ic any­more when the lin­ux mod­ule is loaded after the DTrace mod­ules and you want to use DTrace. I try to com­mit this at a morn­ing of a day where I can fix things dur­ing the day in case some prob­lems show up which I did not notice dur­ing my test­ing.
  • I cre­at­ed a PR for portmgr@ to repocopy a new linux_base port.
  • I set the expi­ra­tion date of linux_base-fc4 (only used by 7.x and upstream way past its EoL) and all depen­dent ports. It is set to the EoL of the last 7.x release, which can not use a lat­er linux_base port. I also added a com­ment which explains that the date is the EoL of the last 7.x release.
Send to Kin­dle

Video for lin­ux (v4l) emu­la­tion com­ing to the lin­ux­u­la­tor

I am in the process of prepar­ing the import of code which makes v4l devices usable in the lin­ux­u­la­tor. Basi­cal­ly this means you can use your web­cam in skype (test­ed by the sub­mit­ter of the patch on amd64).

This is not a “apply patch and com­mit” thing, because the orig­i­nal videodev.h (with some mod­i­fi­ca­tions) is used. I was seek­ing the OK from core@ for this. As there is no license in the head­er, and the orig­i­nal author (Alan Cox, the lin­ux one, not our FreeB­SD one) gave per­mis­sions to use it, core@ is OK with the import.

I intent to do a ven­dor import of the lin­ux head­er (pre­pared today, togeth­er with some readme which explains where it comes from and some stuff to show that we are on the safe side regard­ing legal stuff), and then I want to copy this over to the lin­ux­u­la­tor as linux_videodev.h and com­mit the patch (prob­a­bly a lit­tle bit mod­i­fied in a few places). My plan is to com­mit it this week. Peo­ple which already want to play around with it now can have a look at the emu­la­tion mail­inglist, a link to the patch is post­ed there.

With the head­er being in a ven­dor branch, inter­est­ed peo­ple could then start to sub­mit new BSD licensed dri­vers or mod­i­fy exist­ing dri­vers which make use of the v4l inter­face, but I let the import of the head­er into the FreeB­SD include direc­to­ry up to the per­son which wants to com­mit the first native FreeBSD-v4l sup­port.

When such native FreeBSD-v4l sup­port is com­mit­ted, the lin­ux­u­la­tor code needs to be revised.

Send to Kin­dle

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.lin­ux-rpm.mk pro­vides some nice stuff to han­dle this).

In the last week I fixed some stuff in the lin­ux­u­la­tor-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.

Send to Kin­dle

Round-up of recent FreeB­SD work

I had a look at some USB PRs and wrote a list of those with patch­es to Warn­er (as he is work­ing on USB stuff cur­rent­ly). I also cat­e­go­rized them (easy, not easy, maybe already fixed, …). The easy ones he han­dled already, for the rest I don’t know his cur­rent plans.

Regard­ing lin­ux­u­la­tor stuff I’m work­ing on a MFC patch (no TLS, no futex­es). As I don’t have a -sta­ble box I need some help test­ing it before I can com­mit it. I only com­pile test­ed this on ‑cur­rent with the new gcc 4.2. What I need is:

  • test­ing on i386, amd64 (if I for­got some­thing, it may pan­ic your sys­tem)
  • make uni­verse” test (you have to grep all the logs for “Error 1” and inves­ti­gate the error if there’s one)
  • LTP test run, see the wiki for more (best would be a diff of the logs in the result direc­to­ry of no-patch/patch runs)
  • nor­mal lin­ux appli­ca­tion use-tests

What the patch pro­vides is:

  • mmap fix­es
  • fix mem­leaks
  • add mprotect/iopl/lstat/ftruncate/statfs64/timer_*/mq_*
  • more errno val­ue map­ping
  • don’t lim­it num­ber of syscalls to 255
  • allow to exec libs
  • ioctl TIOCGPTN
  • han­dle more sock­et options
  • de-COMPAT_43-ify
  • add dum­my syscalls so that we know what is need­ed (reports from users)
  • style(9)
  • lin­procfs enhance­ments
Send to Kin­dle

Catch­ing up… lin­ux­u­la­tor.

The lin­ux­u­la­tor is synced on amd64 with i386 (since a while). This means TLS is work­ing now and we have the same (a lit­tle bit bug­gy) futex­es.

Roman is slow­ly work­ing on the *at() com­mands. He also applied for the GSoC this year again. Kib is will­ing to men­tor (in case Roman gets a free seat in the SoC). I reject­ed the men­tor­ing posi­tion this time, as I don’t know if I will have enough time this sum­mer, but I hope I will be around.

Send to Kin­dle