Looking at darwin? (was: Re: BSD video capture emulation question)

[Mike Porter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 15 July 2003 03:07 am, John-Mark Gurney wrote:
> Marco Molteni wrote this message on Tue, Jul 15, 2003 at 09:53 +0200:
> > I appreciate your effort to provide a "video4bsd" facility.
> >
> > Since Apple is famous for being one of the OS of choice for multimedia
> > professional work, and Darwin is so closely related to FreeBSD, may I
> > suggest to check if Darwin already has some of the
> > APIs/services/subsystems/whatever that might be ported to FreeBSD?
> >
> > I don't follow Darwin so I cannot say for sure, but I think we should
> > try to avoid, if possible, the Not Invented Here syndrome ;-)
>
> Last I heard, there was an issue of licenses between Darwin and FreeBSD.
> I have sent mail to -core asking about it.
>
> That said, we might want to leverage their userland API for it, but
> I don't think we could use any of their hardware API.  They have a very
> different hardware framework.  One that would make adding shims a bit
> too complex.
>
> So, are you going to do the research and work on this?  You didn't
> even post any links to code, so all the video API may be apart of
> Mac OSX and not Darwin.  This means that we can't get the code.  So,
> if you really thing we should do this route, send your research to
> the list.

After some casual perusal of the Darwin website, it appears that 

1) IO/Kit (the device driver interface) is part of Darwin, not part of the 
"proprietary" part of OS/X

2) If we really wanted to, we could probably therefore use it, but a) we would 
have to including the original Apple licensing stuff (not a big deal, most of 
the stuff already includes a BSD disclaimer), and b) (more significantly, in 
my book) anything we do, we have to give back to Apple for them to possibly 
use and make money from.

However, it seems that it is not (just) a framework for video drivers, which 
is what we are looking at specifically.    Using it in that context would 
involve rewriting more or less that entire IO subsytem, something I don't 
think we are (or should be) willing to tackle.  I can see bringing some Audio 
capabilities along for the ride in the new framework, just becuase most video 
also has an audio component, so it makes sense to be able to streamline 
audio+video, which could possibly help maintain sync, but I don't see 
throwing out all the other IO pieces, or having to rewrite them (although 
some might argue that this could give us better devoce support overall, and 
its possible, but it doesn't seem worth it to me).  Also, using this 
framework would bring yet another licensing arrangement to bear, and while, 
as far as this non-lawyer can tell, the Apple license is less restrictive 
than, say, the GPL, it is still more restrictive than the BSD licesne we are 
trying to keep all the kernel under, and as much as possible of the thest of 
the base system.  Trying to figure out which bits are covered by which 
license is bad enough when there are only 2 licenses involved.

What IO/Kit DOES have that we want, is a way to interface from userland and 
control the device driver: "The I/O Kit is the device driver subsystem of Mac 
OS X, and is part of Darwin. The I/O Kit provides a set of C functions and 
C++ classes, including object-oriented abstractions common to various 
families of drivers. In addition, for many device types, the I/O Kit provides 
a device interface that enables an application to communicate with and 
control a device from user space." (from 
http://developer.apple.com/documentation/DeviceDrivers/DeviceDrivers.html )

This description does sound pretty much like what I've seen discussed here, 
except that the discussion here has focussed specifically on Video drivers, 
not "all" IO devices (and note that not necessarily all devices have (or 
need) userland access)

My gut feeling, based on all of this is that while we could probably benefit 
from some of the work already done, I don't think the headaches it would 
entail would be worth moving the entire structure over.  I don't think the 
licensing issue is one we want to tackle either, especially without approval 
from -core. (Although looking about some of the things apple is saying about 
themselves and how they work to get their changes implemented upstream 
(specifically citing Apache (anyone know the details on this?)) perhpas they 
would push such a change "upstream" (or perhaps they already tried and were 
rejected?)

What may be worth it (and there may be some legal ramifications here 
surrounding "derivative works") is looking to see how they do it, spcifically 
for video devices, and then see what it would take to provide something 
similar--but that is, if I understand it, exactly what we are discussing here 
anyway.

It occurs to me that better model to follow (if I correctly understood the 
goals) would be to look at the newpcm stuff, which provides a common 
interface for sound cards, rather than a unique all-encompassing device 
driver that provides the entire device's necessary support. 

Well, that's my 2CW, I better stop before I make a bigger fool of myself....

mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE/FGvVY30jZzkECLcRAveeAKCgg9H6b6s0VibUo5ZRUk/BK9balwCfYjG6
KHALei+iomYb4TeiVgZtJLI=
=ZtR2
-----END PGP SIGNATURE-----