From owner-freebsd-arch@FreeBSD.ORG Thu Apr 15 03:32:03 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB03016A4CE for ; Thu, 15 Apr 2004 03:32:03 -0700 (PDT) Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01F8943D67 for ; Thu, 15 Apr 2004 03:32:03 -0700 (PDT) (envelope-from kirma@cs.hut.fi) Received: from kirma (helo=localhost) by hutcs.cs.hut.fi with local-esmtp (Exim 4.30) id 1BE4A6-0001fG-2g for freebsd-arch@freebsd.org; Thu, 15 Apr 2004 13:32:02 +0300 Date: Thu, 15 Apr 2004 13:32:02 +0300 (EEST) From: Jari Kirma To: freebsd-arch@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Digital-tv card drivers and API discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2004 10:32:04 -0000 > Implementation in userspace would be quite interesting, as it does not > need any modifications to the kernel. I have no idea if this is feasible > with PCI-devices though. I have very strong doubts if this can be done. It would be possible to implement things such as MPEG TS PID and section filtering in userland although low level parts of the driver reside in kernel, but it is questionable if it's worth it, especially if one doesn't want to do some more complex conversions, such as MPEG TS -> PS replexing inside the framework. > I don't have enough experience to decide if it is ok for FreeBSD, as > Jari said that it may not be OS-independent enough. I would appreciate > some feedback on this matter, especially which is the best way to go > when considering the long-term dvb-support in FreeBSD. I agree on that support for Linux API is essential to make ports of DVB-related software easy. Linux API, in many respects, is probably good enough in what it provides. The big thing that I don't like in it is the fact that it exposes raw system call interface which practically requires implementation of at least a dummy device driver in kernel. If they would have cared to even wrap most of those operations inside library stub functions and specify reasonable semantics for them in addition to avoiding references of specific device files in /dev, it would be so much nicer to write a compatible implementation any way one wants (entirely in kernel, partly in kernel, or entirely in userland). Unfortunately they already adopted it and have applications that support it. ;) -kirma