This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Sun May 5 21:41:24 2024 Received: from lml.valinux.com (postfix@lml.valinux.com [198.186.203.19]) by herbie.ucs.indiana.edu (8.9.3/8.9.3) with ESMTP id FAA05675 for ; Thu, 3 Feb 2000 05:04:48 -0500 (EST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by lml.valinux.com (Postfix) with ESMTP id E70D65917B; Thu, 3 Feb 2000 01:32:31 -0800 (PST) Received: by vger.rutgers.edu via listexpand id ; Wed, 2 Feb 2000 23:57:58 -0500 Received: by vger.rutgers.edu id ; Wed, 2 Feb 2000 23:54:30 -0500 Received: from mailout00.sul.t-online.de ([194.25.134.16]:3409 "EHLO mailout00.sul.t-online.de") by vger.rutgers.edu with ESMTP id convert rfc822-to-8bit; Wed, 2 Feb 2000 23:52:36 -0500 Received: from fwd00.sul.t-online.de by mailout00.sul.t-online.de with smtp id 12GICa-0007AP-02; Thu, 3 Feb 2000 10:05:24 +0100 Received: from t-online.de (04255541-0038@[193.159.144.21]) by fwd00.sul.t-online.de with esmtp id 12GICK-1RWnFAC; Thu, 3 Feb 2000 10:05:08 +0100 Message-Id: <3899436D.8EC883CA@t-online.de> Date: Thu, 03 Feb 2000 09:59:25 +0100 From: M.Hunold@t-online.de (Michael Hunold) Reply-To: m.hunold@gmx.de X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12 i686) X-Accept-Language: de, en Mime-Version: 1.0 To: kernel Subject: Design issues for a kernel-driver Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT X-Sender: 04255541-0038@t-dialin.net Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu X-Orcpt: rfc822;linux-kernel-outgoing-dig Hello, I have some questions concerning the design of a kernel-driver. First of all the background of the story: I have written a driver-package for video-hardware that is based on the SAA7146-chipset by Philips Semiconductors. The driver can be found at http://www.mihu.de/linux/ The package includes a driver for a tv-card called "MXB", too. There is something special about the SAA7146 that cleary separates it from chipsets like the BT848: The SAA7146 can be used in a more generic fashion. It features input- and output-ports rather than simple connectors for external video-sources. It features two busses (i2c and DEBI) that can be used to control external hardware. Because of that, SAA7146-based hardware can differ very much and it is impossible to write a generic driver for all the hardware out there. Until now, the driver can only be compiled as a module. I'd like to incorporate it in the kernel and so it must become very more -- well -- suitable. Please donīt get me wrong: the driver itself is very stable and useful, but the integration into the kernel-environment is quite terrible at the moment. There is a "saa7146-core"-module, which works like this: When the module is inserted, it scans the pci-bus for any available SAA7146 and allocates various things like irqs, memory for grabbing-buffers, etc. for all of the SAA7146 in the system. The module then exports some functions to provide the functionality to any "real" hardware-specific device-driver: EXPORT_SYMBOL(saa7146_get_handle); EXPORT_SYMBOL(saa7146_command); All "real" functionality lies under the "saa7146_command", which can be called with a handle obtained by "saa7146_get_handle". An example: lets assume that I have inserted the "saa7146-core.o"-module and then insert my "mxb.o"-module. The "init_function" of the module then calls "saa7146_get_handle" as often as it returns different handles and then checks if a MXB is present. Of course this does not work very well, when I have different SAA7146-based hardware in my system and I want to insert different drivers. You should get the idea of how it works. The good thing of this architecture is, that the real hardware-driver does not have to worry about stuff like irq-allocation, memory-allocation and similar at all. It can implement an interface to a higher API like video4linux and use the functions exported by the core-driver. So the drivers for different hardwares do not have to include the same code over and over again. Ok, now I'd like to integrate the driver properly into the kernel and I can think of only one real solution of the problem: The core-modules gets some real locking/unlocking mechanisms with real handle-handling. External drivers must attach and detach to the core in order to be able to call the functions. If they want to probe for a specific hardware for example, they have to attach, then call some probing-functions and have to detach if the hardware does not fit. There is a second way in my mind, but I don't think that it is as stable as the above one: The core-module "knows" about all SAA7146-based hardware out there. I think any hardware can be determined by a specific combination of helper-chipsets sitting on the two busses, but I am not completely sure about that. Then the core-driver can probe for the devices and select the one that fits best... I had a look through various kernel-drivers, but I did not find anything that uses a mechanism like a described above. So I am a little confused on how to actually design my driver. I would really appreciate it, if you comment on my design I suggested above. I am interested in any other documents dealing withthis issue, too. Thanks, Michael. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/