Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!solace!nntp.uio.no!news.cais.net!news.mathworks.com!uunet!in1.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Linux vs. FreeBSD ...
Date: Fri, 10 May 1996 21:16:13 -0700
Organization: Me
Lines: 102
Message-ID: <3194148D.5605262D@lambert.org>
References: <3188C1E2.45AE@onramp.net> <4mnsc5$6qo@sundial.sundial.net> <Dr1wrL.My0@kithrup.com> <3191B103.167EB0E7@FreeBSD.org> <4mtsek$rbs@samba.rahul.net>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Rahul Dhesi wrote:
] A generic question:
]
] Given that the hardest thing about maintaining two parallel
] operating systems is the device support,
]
] How hard would it be for both Linux and FreeBSD teams to
] revise their respective oeprating systems to accept
] virtually identical device driver code?
]
] It would be so nice if either could grab a device driver
] from the other and just plug it in.
]
] Maybe through a generous set of macros that allow for low-level
] differences? Or a little device-driver writing language that
] translates high-level code into C?
Device drivers, per se, are quite close in architecture. Form
follows function.
There are several issues to resolve:
1) FreeBSD is evolving to a full devfs-based /dev for
device interfaces. This means that device nodes
will be artifacts of device driver instantiation
rather than requiring a user to make the connection
on behalf of the kernel with "mknod" or "MAKEDEV",
etc..
This is, in fact, "high magic". There are serious
implications for device implementations, although
most differences will be able to be isolated to
the init/probe/attach/detach/deinit code... which
if it is correctly written is a small portion of
the code.
Someone will need to do a similar feat for Linux,
or will need to maintain the unshared code
seperately (Linux could also benefit from a full
devfs implementation, FWIW).
2) Linux Licensing is antithetical to code reuse in
binary distributions.
This is not flame bait. Linux does this on purpose;
the idea is conformant with the spirit of the GPL
and the intent of the FSF.
Specifically, the device drivers, if they aren't
"UCB'ed", need to be "LGPL'ed". Currently, they
are "GPL'ed" in Linux, which means that an LKM
based soloution to driver loading for any non
boot-critical devices won't work. Loading via
LKM *will*, however, satisfy the LGPL relink
clause. If the drivers are LGPL'ed instead of
GPL'ed, then the licensing porblems go away.
I've actually been asking for this change for over
2 years now (I wrote LKM's for BSD in March of
1994). About the same amount of time I've been
asking for LGPL recognition of BSD-style shared
libraries in the LGPL relink clause. Since LKM's
are fully stand-alone modules consumed by the
kernel, there is no conflict with the LGPL, as
there is with UCB style shared library technology
(note Linux ELF shared library technology has this
same potential risk).
3) Any boot-critical drivers -- like the console or a
disk controller driver for a particular controller
-- must be released under both licenses. Until such
time as VM86() fallback driver support for boot
devices exists (the x86 moral equivalent of the
OpenFirmware objective), boot-critical drivers must
be statically linked into the kernel. To fit the
requirements of both camps, either dual licensing
is required, or the GPL must be relaxed on the
Linux kernel as a whole, and it must treat devices
as seperate agregations.
This is an extremely dangerous step for the BSD
camp to take, since the exposure risk is that
changes to the drivers will be GPL'ed and thus
can not be reintegrated into the BSD coude base,
even if a similar driver exists.
In my opinion, it is unlikely that an agreement
could be reached on boot-critical devices until
such time as it became possile to demand-load them
-- ie: they, if fact, became no longer boot-critical.
Also in my opinion, it would be unwise to enter into
such an agreement for boot-critical devices until
that time, as well.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.