Date: Tue, 15 Jul 2003 15:02:09 -0600 From: Mike Porter <mupi@mknet.org> To: multimedia@freebsd.org Subject: Re: Looking at darwin? (was: Re: BSD video capture emulation question) Message-ID: <200307151502.14625.mupi@mknet.org> In-Reply-To: <20030715090724.GH35337@funkthat.com> References: <20030714064137.GT35337@funkthat.com> <20030715075307.GD17691@cobweb.example.org> <20030715090724.GH35337@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200307151502.14625.mupi>