> It may be sometimes difficult to avoid header files and keep
> compatibility, e.g. <a.out.h> or <ioctl.h>. Header files are
> public stuff, and it does not make very much sense to reorder
> them, but leaving its contents intact, just to get rid of the
> copyright. On the other hand, renaming all #defines, structures,
> functions to make this "own work", is also bad, because the headers
> describe interfaces other software is supposed to use. <stdio.h>
> with its non-AT&T FILE structure is an example for incompatibility
> introduced.

No, no no no no.  NetBSD contains re-implementations of all of the
above as done by CSRG (Berkeley).  This is ok, and is considered
original work.

Lets say you need a free version of eeprom.h (we do).  First try to
find a hardware spec of some sort that defines the various structures.
Unfortunately this doesn't exist in this case.

So, start with a blank file and rewrite the header file with your own
structures, nomenclature, etc.  This is the best you can do....


> Even more: I have no access to SunOS source (which is good), but
> for writing a device driver I would look at the interface 
> already given in the corresponding headers (with the option to
> invent a lookalike driver that I could try out in a SunOS Kernel).
> The source code of the driver would be (very likely) entirely
> different from the original. Sorta like MS-DOS vs. DR-DOS,
> the latter presenting the same public interface as the first,
> but extremely different in the non-public structures (and some
> unofficial INT21 functions).


you'll have no luck migrating drivers easily between sunos and NetBSD,
write to the interfaces specfied in the NetBSD source and you'll be fine.


we are shooting for functional compatibility, not source-level.  So if
i implement the ms driver for the mouse, I want it to have the same
external iinterface as in sunos, but the internal implementation will
likely be very different.

later,
Adam Glass

------------------------------------------------------------------------------