From owner-freebsd-chat Tue Sep 29 22:45:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA27220 for freebsd-chat-outgoing; Tue, 29 Sep 1998 22:45:30 -0700 (PDT) (envelope-from owner-freebsd-chat@FreeBSD.ORG) Received: from ha1.rdc1.nj.home.com (ha1.rdc1.nj.home.com [24.3.128.66]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA27190 for ; Tue, 29 Sep 1998 22:45:26 -0700 (PDT) (envelope-from garycor@home.com) Received: from home.com ([24.3.185.85]) by ha1.rdc1.nj.home.com (Netscape Mail Server v2.02) with ESMTP id AAA12487; Tue, 29 Sep 1998 22:45:10 -0700 Message-ID: <3611C5C0.32A4D798@home.com> Date: Wed, 30 Sep 1998 01:46:40 -0400 From: "Gary T. Corcoran" X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: "Eugene M. Kim" CC: FreeBSD Chat Mailing List Subject: Re: Win95/NT drivers on FreeBSD? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Eugene M. Kim wrote: > > Well, this is just a wild idea, so please don't throw a stone at me :-) Actually I had a very similar idea a few months ago, as I'll explain below. > If we could provide a device driver framework that is identical to M$ > Win95/98 DDK's one, then it would be a good incentive to the device > driver developers to release a FreeBSD driver. It's a sort of ``get the > FreeBSD Win95 Compatibility DDK, compile your source on it, and there > you go!'' type of thing. > > Well, the resulting driver code probably will be less efficient than > FreeBSD ``native'' drivers, but it's still better than nothing... I don't think providing a new 'framework' to *write* FreeBSD drivers buys you anything. If you're going to write a *new* driver, write a standard one... > Or maybe we could even maintain the binary compatibility with Win95 > device drivers, if Microsoft didn't plant anything secret in their DDK > so that every device driver file would have some ``blackbox'' code. > This is closer to the right idea. I considered proposing the below to -hackers, but since I have no time to implement such a grandiose idea, I decided not to waste people's time. My idea was that it would be most useful and practical if FreeBSD supported WinNT (and some Win98) device drivers, as shipped by the OEM. Why WinNT and not Win95? Because WinNT drivers are more like Unix device drivers. They have well defined interfaces to the O/S, and are _not_ allowed to do whatever they want with the system. Win95 VxD's, on the other hand, have no such constraints, and are sort of a Wild, Wild, West (do whatever they feel they need/want to do). Microsoft NDIS (Network Driver Interface Specification) miniport drivers (and SCSI miniport drivers) are clean interface .SYS drivers that also run on Win98. The newer WDM (Win32 Driver Model) drivers also have the same binary for running on Win98 and WinNT and could be supported. Supporting NDIS miniports on FreeBSD would be a good starting point. Besides the obvious advantage of giving FreeBSD the ability to drive a new piece of hardware *immediately* using the OEM (or chip manufacturer) developed driver, where they know about all the 'quirks' of the hardware, there is a subtler, but more important reason to support them. As the main CPU has become more powerful, it has become possible to do functions in software that have previously required dedicated hardware. The advantage to this is lower cost hardware (something the computer manufacturers demand these days). The downside is that if a large part of the functionality of a peripheral is in software, that peripheral will only function on the O/S's for which the manufacturer wrote a device driver. And these days drivers are (mostly) being written only for Win9x and WinNT by the manufacturers. But, if FreeBSD provided (for example) an NDIS miniport framework, you would be able to run your new 'gronkulator', including the software- provided functionality. This is quite possible technically (after all, the miniport drivers are just x86 code, why couldn't we execute it?). But providing the 'framework' means more than just providing a translation API. You also need to provide the calls (for example, initialization) _into_ the NDIS driver that it expects. This subject is dear to me because I've been working on NDIS drivers for the past year for a new peripheral (chip) where some of the low-level protocol is done in the driver. Furthermore, due to the latest 'standards', we're being forced to include an object file in the driver provided by a third party for which we won't get source code. So the *only* way this thing would ever work under FreeBSD is to be able to directly execute the NDIS driver binary that we're developing... So, yes, I think it's a "good" idea. Whether anyone will ever get around to making it work on FreeBSD is another question... Gary (just for the record, these are my opinions only, and not necessarily those of my employer...) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message