Video For BSD --- New project to develop V4L compatible drivers for BSD
 

Video For BSD (( new project at SourceForge ))

Because of the success of the Video4Linux project, there are large numbers of device drivers available for multimedia cards, digital cameras, and USB devices currently on the market. Since V4L is an active, dynamic project with numerous contributing developers, new hardware drivers are created and bugs are addressed

On the other hand, BSD supports older Brooktree 'bktr' tuner chips that are no longer in production. If you want to watch TV on your FreeBSD system you might be able to find an old analog 'bktr' card on eBay. But why bother? In a few months (February 2009) there won't be any NTSC broadcasts in the USA, only ATSC will be available. In many other places, broadcasts are switching from PAL/SECAM to DVB-T.

Why BSD?

• BSD systems are secure and stable. "Uptimes are measured in years". The occasional blue-screen, hang, hex-dump, hardware & software incompatibility, and virus infection is accepted as typical by a Windows-Vista user. Many companies don't want to base their consumer products on Microsoft because support for buggy systems and license fees eat into profits. Consumers have a choice and they won't buy a TV with a reputation that it periodically hangs and reboots.
• BSD systems are developer friendly. Tools available on Linux are also available on BSD.
• Many corporations find BSD a more 'business friendly' platform to take their product to market.

Philosophical Differences

There are fundamental philosophical differences in support for multimedia on Linux and BSD.

Linux has moved V4L support into the kernel. This certainly makes the kernel more complex, bloated, and prone to potential problems. Hundreds of devices, most of which are not currently in your system, are supported. When a hardware is no longer used, dead code will remain in the Linux kernel for years to come. New hardware will require newer kernels.

The BSD philosophy is that putting non-time critical code in the kernel only bloats the kernel. BSD seeks to protect the hardware by providing a level of abstraction between user programs and critical hardware. This is probably the main reason for BSD's vaunted stability.

Of course, if BSD doesn't support V4L, much work will have to be repeated in re-writing new hardware drivers. Most hardware which just 'plugs-n-plays' on Linux will never work on BSD. Bugs fixed in V4L will not be propagated to BSD.

There's similar project at: http://wiki.freebsd.org/HDTV Support for HDTV on FreeBSD is just starting out. John-Mark Gurney has added support an ATSC based card with work underway for a second. There is no known support for the DVB family. John-Mark Gurney has also written the beginning of a design document on how to provide generic multimedia support under FreeBSD.

Project Goal

This project will implement a V4L compatible API and device drivers for the BSD systems, enabling you to run Linux video applications on BSD. Our goal is to provide an emulation layer that would let us recompile the linux source code on BSD, and provide a sufficiently complete emulation of the Linux kernel APIs so that device drivers can be used without significant modifications to their source code.

Source for working device drivers, ports of Linux multimedia applications, along with notes on how to install various multimedia devices on BSD will be made available in this SourceForge repository. Project releases will have the FreeBSD copyright a simple, permissive, non-copyleft free software license, compatible with the GNU GPL.

Can it be done? Here's an example by Luigi Rizzo on Building Linux Device Drivers on FreeBSD for several webcams. Here's another example on porting a DVB-T television USB-Stick driver. (NOTE: the HW manufacturer has released a new revision of their DVB-T USB stick that is not supported by this driver. --- this is the reason this project is needed. If BSD had a central location providing HW drivers; updates, fixes, and new HW could be supported ).

The port available in: /usr/ports/devel/linux-kmod-compat claims that the "porting of a linux driver should be as simple as downloading the linux driver sources, writing a simple Makefile.kmod, and running "make -f Makefile.kld" to produce the driver.ko". Of course, current reality is not that simple --- not yet. In the words of Admiral Horatio Hornblower and Captain Jean-Luc Picard the goal of this project is to "Make it so".

Support this Project

Hardware manufacturers wanting to expand their customer base world-wide should consider donating hardware, specifications, and expertise to the Video-4-BSD project. Video-4-Linux has often been forced to valiantly create drivers via reverse engineering with USB and PCI bus sniffers. Some corporate legal departments are frightened by the GNU-GPL but have no problem with the FreeBSD license. By making hardware and software specifications available under the FreeBSD license, this project hopes to return/provide assistance to the Video-4-Linux project and a 'Thank You' for making it all possible.

Join and Contribute to this Project

To join this effort, first join SourceForge and then send an email to the members discussion list containing your SourceForge username.

• Video-4-BSD project home
• Public Forum
• Members e-Mail discussion list

Just a quick comment: while I've wanted to try FreeBSD for years, I've been unable to for various reasons, so I use Slackware instead. I got my first exposure to UNIX at college with BSD 4.3, in fact, though I used a multi-user OS before that in the form of Microware's OS-9 on my Color Computer. :)

Now specifically on what you said above: I totally agree on your comments about drivers in the Linux kernel, and have been wondering for years why so much of this is ending up in kernel space, with all the security problems, bloat, and so on that this produces. Another example would be the net filtering code: why can't it be chrooted in user space to keep any possible exploits of the filter itself out of kernel space since by definition its exposed to the worst of the network. I just downloaded Linux kernel 2.6.26: 47 MB in bzip2 and a whopping 60 MB in gzip! I have no idea how much it is uncompressed, but it sure takes a while! All that and I'm probably compiling less than a tenth of that code into a working kernel. It's also why Damn Small Linux, for instance, only uses the 2.4 series because they say (I haven't tried it) 2.6 is so bloated now it won't load into old machines!

Anyway, I'm hoping to finally give FreeBSD 7 a shot when I build my next machine.

Mike

Linux is about 200MB these days.

If DSL claims that 2.6 is so bloated it won't load on old machines, I have to wonder how old an "old machine" is. I have 2.6.21 booting on a 300MHz Geode with 128MB memory. The kernel and all tools used produce a cpio archive (initrd - well, actually initramfs) about 16MB in size.

I really don't get all this stuff about security and running drivers in 'kernel space'. I suspect it's mostly people who don't know what they're talking about worrying about something which doesn't exist. Linux handles bad drivers remarkably well; I haven't seen a driver take the system down for over 2 years now. "user space drivers" is a solution to a largely non-existent problem. There are a few niche uses, but for the most part there is no compelling reason for a user-space driver; there was a bug in the kernel's network layer which would result essentially in taking out the network on that specific computer, but the kernel team fixed the problem rather than moving the network layer to user space - there was no obvious way of exploiting the bug to gain root control or even shut down the machine. Now think about this - who would be running a multi-user system with a video driver loaded? I can imagine something like a MythTV server, but for most uses a video driver running in kernel space is not of the least concern. So for those who would claim that a video driver in kernel space is any sort of security threat, people like me are waiting for you to demonstrate your 1337 skillz and prove that there is a problem.

Ugh...

I think they're referring to running code in memory. And by old I think many others call "ancient": stuff that by today's standards is considered embedded with 200 MHz or less processors and 64 MB or less memory.

Personally, I have an old P1 non-MMX laptop from 1996 with 16 MB RAM that I'd love to get working. It has a copy of Win-95 1st edition on its 800 MB hard drive. With Linux, I may be able to get wireless working and thus a kind of EEE-PC (but slower :). I have a feeling that even DSL is too big for this.

Point taken! :)

Mike

Well, a severely cut-down version of the 2.6 kernel may juuuust get in there. Forget about any graphics though - X is a pig and I suspect the HD will be thrashing even just to run a "lightweight" windows manager. Now if you had 64M that would be a different story... Computers sure have changed since then - that machine probably consumed about 75W power or even more; an AMD Geode at 300MHz with 128MB, hard disk, 128M memory only consumes about 10W (but my LCD screen takes close to 50W).

I played with DSL on 16MB of RAM on VirtualBox and while it does boot, it just freezes when it loads X.

This may be your best bet: http://www.delilinux.org/ Otherwise, run DSL and don't load the GUI.