This is a multi-part message in MIME format.
--------------020703070202000108000401
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dieter wrote:

>>It would certainly be interesting to develop a device driver interface 
>>layer that allows drivers from other operating systems to become virtual 
>>NetBSD drivers.  In principle this shouldn't be difficult, but this is 
>>certainly one of those instances where the devil would be in the 
>>details.
>>    
>>
>
>That's *daemon* in the details.  :-)
>
>  
>
>>My view is that, if something like this is to be attempted, it should be 
>>part of a general capability which allows the addition of libraries that 
>>act like "plug-ins" for a given O/S device driver interface.  The place 
>>to start (again IMO) is an analysis and comparison of the currently 
>>available open source device driver interfaces; Dieter's list 
>>(Free/OpenBSD, and Linux) should certainly be part of this.  If there 
>>are others that should be considered in such an effort, I'm sure people 
>>on the list will provide that information.
>>    
>>
>
>You could add DragonflyBSD.  Maybe Solaris, they are supposedly
>becoming some form of open source.  Maybe Apple's OS X, although
>I wonder if there are or will be any open source OS X drivers.
>
>It appears that the popular platforms at the moment are wintel,
>Linux/x86 and OS X.  Therefore they are the platforms most
>likely to have drivers we might want.  Note that I haven't
>suggested adding ms virus server to the list.
>
>  
>
>>That's assuming, of course, that there is a consensus that such an 
>>effort would be valuable.
>>    
>>
>
>In addition to being valuable to those of us currently running NetBSD,
>adding significant new capabilities, it would help change the perception
>of NetBSD.  Currently the view seems to be "Yeah NetBSD runs on anything
>with more computing power than a light bulb, but in many cases all that
>means is you can get a login prompt, and there is poor driver support.
>NetBSD is something to run on old, oddball hardware, shoved into a corner
>of the server room."  I'm not sure what the just-a-login-prompt thing is
>all about, but the rest of it has a lot of truth to it.  :-(
>
>And someone (not me) could get a Usenix paper out of it.  :-)
>
>  
>
>>It should be considered that such a 
>>capability has the potential to reduce NetBSD stability, because the 
>>quality of device drivers (in Linux particularly) varies from very good 
>>to almost useless.
>>    
>>
>
>I think the sort of people running NetBSD are bright enough to not
>blame NetBSD for problems caused by 3rd party software.  I've found
>some pkgs to be completely useless (non-functional) but I don't
>see anyone blaming NetBSD for bad pkgs.
>
>  
>
>>You could build into an abstraction layer of this type either a fixed 
>>(updatable) list of allowable drivers, or you could have a site with a 
>>dynamic list of acceptable drivers that the abstraction layer consults 
>>before allowing a driver to be used.  This sounds good, but it means 
>>that somebody (or somebodies) would have to spend significant amounts of 
>>time judging the stability of drivers, which means of course that they 
>>probably need to have the hardware associated with the driver.
>>    
>>
>
>I'm thinking that this is a bit more than we need.  I'd suggest a web page
>with a list of drivers that people have tried, and the results they got.
>	"Works great, fast, no problems."
>	"Works, but uses lots of CPU."
>	"Sorta works, but kinda flaky.  Needs work."
>	"Works, except for the FOO feature."
>	"Works but throughput is terrible."
>	"Panics the OS.  Not recommended."
>
>A similar list for hardware (Ethernet cards, video cards, disks, whatever)
>would be very useful as well.  By make and model, as it may not be easy to
>detirmine what chip a product uses.  And there more to a card than just the
>biggest chip.
>  
>
That's probably a simpler and better idea than mine, certainly for an 
initial cut.

I take your point about packages.

The Solaris device driver interface (really, all System V device driver 
interfaces) have two classes of driver: ordinary and streams.  (Ordinary 
is the wrong word but I hope the meaning is clear.)  Interfacing to a 
streams driver would be non-trivial.  Of course, if sun never opens the 
driver source the issue is moot, so it is safe to ignore it for now.

Are there OSX drivers that are not available in the Darwin source code 
that are open source?

In discussing stability I was thinking more about end users.  Rethinking 
that issue, stability wouldn't be a big issue if the capability were 
disabled by default and enabling it requires more technical savvy than a 
bozo would have.

I'm going to take a crack at a very high level design and estimation of 
the scope and logistics that might be involved.  Then we can have a more 
valuable discussion as to the practicality of the idea.

Seth

>!DSPAM:41f5f2a1104231881510136!
>
>  
>


--------------020703070202000108000401
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Dieter wrote:
<blockquote cite="mid200501250656.GAA03460@sopwith.solgatos.com"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">It would certainly be interesting to develop a device driver interface 
layer that allows drivers from other operating systems to become virtual 
NetBSD drivers.  In principle this shouldn't be difficult, but this is 
certainly one of those instances where the devil would be in the 
details.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
That's *daemon* in the details.  :-)

  </pre>
  <blockquote type="cite">
    <pre wrap="">My view is that, if something like this is to be attempted, it should be 
part of a general capability which allows the addition of libraries that 
act like "plug-ins" for a given O/S device driver interface.  The place 
to start (again IMO) is an analysis and comparison of the currently 
available open source device driver interfaces; Dieter's list 
(Free/OpenBSD, and Linux) should certainly be part of this.  If there 
are others that should be considered in such an effort, I'm sure people 
on the list will provide that information.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
You could add DragonflyBSD.  Maybe Solaris, they are supposedly
becoming some form of open source.  Maybe Apple's OS X, although
I wonder if there are or will be any open source OS X drivers.

It appears that the popular platforms at the moment are wintel,
Linux/x86 and OS X.  Therefore they are the platforms most
likely to have drivers we might want.  Note that I haven't
suggested adding ms virus server to the list.

  </pre>
  <blockquote type="cite">
    <pre wrap="">That's assuming, of course, that there is a consensus that such an 
effort would be valuable.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
In addition to being valuable to those of us currently running NetBSD,
adding significant new capabilities, it would help change the perception
of NetBSD.  Currently the view seems to be "Yeah NetBSD runs on anything
with more computing power than a light bulb, but in many cases all that
means is you can get a login prompt, and there is poor driver support.
NetBSD is something to run on old, oddball hardware, shoved into a corner
of the server room."  I'm not sure what the just-a-login-prompt thing is
all about, but the rest of it has a lot of truth to it.  :-(

And someone (not me) could get a Usenix paper out of it.  :-)

  </pre>
  <blockquote type="cite">
    <pre wrap="">It should be considered that such a 
capability has the potential to reduce NetBSD stability, because the 
quality of device drivers (in Linux particularly) varies from very good 
to almost useless.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I think the sort of people running NetBSD are bright enough to not
blame NetBSD for problems caused by 3rd party software.  I've found
some pkgs to be completely useless (non-functional) but I don't
see anyone blaming NetBSD for bad pkgs.

  </pre>
  <blockquote type="cite">
    <pre wrap="">You could build into an abstraction layer of this type either a fixed 
(updatable) list of allowable drivers, or you could have a site with a 
dynamic list of acceptable drivers that the abstraction layer consults 
before allowing a driver to be used.  This sounds good, but it means 
that somebody (or somebodies) would have to spend significant amounts of 
time judging the stability of drivers, which means of course that they 
probably need to have the hardware associated with the driver.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I'm thinking that this is a bit more than we need.  I'd suggest a web page
with a list of drivers that people have tried, and the results they got.
	"Works great, fast, no problems."
	"Works, but uses lots of CPU."
	"Sorta works, but kinda flaky.  Needs work."
	"Works, except for the FOO feature."
	"Works but throughput is terrible."
	"Panics the OS.  Not recommended."

A similar list for hardware (Ethernet cards, video cards, disks, whatever)
would be very useful as well.  By make and model, as it may not be easy to
detirmine what chip a product uses.  And there more to a card than just the
biggest chip.
  </pre>
</blockquote>
That's probably a simpler and better idea than mine, certainly for an
initial cut.<br>
<br>
I take your point about packages.<br>
<br>
The Solaris device driver interface (really, all System V device driver
interfaces) have two classes of driver: ordinary and streams.&nbsp;
(Ordinary is the wrong word but I hope the meaning is clear.)&nbsp;
Interfacing to a streams driver would be non-trivial.&nbsp; Of course, if
sun never opens the driver source the issue is moot, so it is safe to
ignore it for now.<br>
<br>
Are there OSX drivers that are not available in the Darwin source code
that are open source?<br>
<br>
In discussing stability I was thinking more about end users.&nbsp;
Rethinking that issue, stability wouldn't be a big issue if the
capability were disabled by default and enabling it requires more
technical savvy than a bozo would have.<br>
<br>
I'm going to take a crack at a very high level design and estimation of
the scope and logistics that might be involved.&nbsp; Then we can have a
more valuable discussion as to the practicality of the idea.<br>
<br>
Seth<br>
<br>
<blockquote cite="mid200501250656.GAA03460@sopwith.solgatos.com"
 type="cite">
  <pre wrap="">
!DSPAM:41f5f2a1104231881510136!

  </pre>
</blockquote>
<br>
</body>
</html>

--------------020703070202000108000401--