From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 18:58:15 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D47A16A420 for ; Wed, 9 Nov 2005 18:58:15 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9414743D53 for ; Wed, 9 Nov 2005 18:58:14 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.117]) ([10.251.23.117]) by a50.ironport.com with ESMTP; 09 Nov 2005 10:58:14 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <437246C5.2030607@elischer.org> Date: Wed, 09 Nov 2005 10:58:13 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcin Jessa References: <20051108232855.2d1b7df5.lists@yazzy.org> <437145DF.2040508@samsco.org> <20051109093552.3082c51b.lists@yazzy.org> In-Reply-To: <20051109093552.3082c51b.lists@yazzy.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 18:58:15 -0000 Marcin Jessa wrote: >On Tue, 08 Nov 2005 17:42:07 -0700 >Scott Long wrote: > > > >>Marcin Jessa wrote: >> >> >>>Hi guys. >>> >>>I just came across an article of Mr. Greg Kroah-Hartman in his blog >>>http://www.kroah.com/log/2005/11/03/ >>>about generic kernel API which could make it possible for hardware >>>vendors to supply us with their own drivers. >>>To be honest I disagree with Greg and consider this a good idea. >>>Especially if we had a system which could isolate each device driver >>>running as a separate user-mode process so it would not bring down >>>the entire OS in case the driver was buggy. >>>An API like that would both boost up FreeBSD's popularity and make >>>it possible to use a way larger variety of hardware. >>>I mean, lets not fool ourselves, the majority of hardware vendors is >>>not interested in revealing of their secrets publishing freely >>>avaliable documentation of their products. >>>We could have a new choice to use (or not) binary drivers the >>>same way the popular commercial O.Ss do. >>>What do you guys think? What is the view of the >>>FreeBSD community on this metter? >>>Could this be concerned as a good idea ? >>> >>> >>>Cheers, >>>Marcin Jessa. >>> >>> >>Please don't take this the wrong way, but google for 'Universal Driver >>Interface'. Yes, this topic comes up every few years. It sounds >>like a good idea, but every OS has unique and incompatible ways of >>doing things. >> >> > >You've misunderstood me Scott. >I never meant it to be an universal API but a FreeBSD one only. >I understand an universal closs-platform driver API would me a nearly >impossible project. >My idea is to create an API for binary vendor drivers to make it >easier for hardware vendors to create FreeBSD drivers the same way >they can do for Windows or Mac OS X. > > > well, you could port the Darwin driver interface in the form of a shim, or extend "project evil" to cover more kinds of drivers.. > > >>Sure, it's easy to map malloc in FreeBSD to kmalloc in >>Linux, but how do you map ithreads in FreeBSD and Solaris to Linux? >>How do you map busdma in FreeBSD to busdma in NetBSD, let alone Linux >>where there is little concept of a DMA abstraction? How do you map >>newbus in FreeBSD to, um, nothing in Linux? How do you map VFS on >>FreeBSD to VFS on Linux or Solaris? All of these things make such a >>unification effort impossible to do without watering it down to where >>it is either functionally useless or too slow and abstract to >>matter. Ironically, Project Evil has bridged the gap the best, but >>it limits its scope to the Windows NDIS API. It might be possible to >>expand it to cover StorPort also, but forget about much more than >>that. >> >> >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >